- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Fri, 9 Sep 2016 14:05:43 +0200
- To: GALINDO Virginie <Virginie.Galindo@gemalto.com>
- Cc: "public-web-security@w3.org" <public-web-security@w3.org>
- Message-ID: <CAKaEYhLm0uUw4G4sLMe-Pg4SWw_257EmM=vfNDCW+pe3pTbQDQ@mail.gmail.com>
On 6 September 2016 at 15:41, GALINDO Virginie <Virginie.Galindo@gemalto.com > wrote: > Melvin, > Cant Let's encrypt help on this matter ? > Galindo a couple of extra notes on this matter, that I think would benefit the list readership. This is imho an excellent article by Tim Berners-Lee https://www.w3.org/DesignIssues/Security-NotTheS.html Notably: Web Security - "HTTPS Everywhere" harmful ================================= “The HTTPS is a safe space” has lead to the notion in bowser vendors that it should be ring-fenced. The Same Origin Policy in this spirit suggests that once a user enters the secure web by an https: link, then everything which affects the session at all must come also over authenticated TLS. This has led to a class of web apps being broken, in contrast with the usual rule of back compatibility with old content. class=“ramble”> (The last point is related to the common design failure that trust is as single-valued scalar thing. It has been more any more clear that we and our systems should not just trust things or not trust them, or even to trust them on a scale form 0 to 1. We trust different people for different things. We trust one person for recommendations on food, and another for movies, and to muddle these trusts could be disastrous. Similarly we allow different agents and services and code modules do access different things for different purposes. Our computer systems must reflect and implement that. A https: secure oil/water boundary does not do that. A symptom if that you can never find the perfect place to put that boundary.) Don’t break the web =============== The concerns behind the need for security are valid. There is a lot of abuse which it would prevent. The problem with HTTPS Everywhere drive is when the “S” is put into the URI. The problem is of course that moving things from http: space into https space, whether or not you keep the rest of the URI the same, breaks any links to. Put simply, *the HTTPS Everywhere campaign taken at face value completely breaks the web. In a way it is arguably a greater threat to the integrity for the web than anything else in its history*. The underlying speeds of connection of increased from 300bps to 300Gbps, IPv4 has being moved to IpV6, but none of this breaks the web of links in so doing. > Virginie > > > ---- Melvin Carvalho a écrit ---- > > > > > On 6 September 2016 at 11:25, GALINDO Virginie < > Virginie.Galindo@gemalto.com> wrote: > >> Dear all, >> >> FYI, a github project listing security good practices for development >> (including web dev). >> >> https://github.com/FallibleInc/security-guide-for- >> developers/blob/master/security-checklist.md >> <https://github.com/FallibleInc/security-guide-for-developers/blob/master/security-checklist.md?ref=producthunt> >> > > Re point 1 use HTTPS "everywhere", it would be nice, but that's simply not > affordable for many developers with wildcard certificates still being of > the order or $100 per year. > > >> >> Regards, >> >> Virginie >> >> >> ------------------------------ >> This message and any attachments are intended solely for the addressees >> and may contain confidential information. Any unauthorized use or >> disclosure, either whole or partial, is prohibited. >> E-mails are susceptible to alteration. Our company shall not be liable >> for the message if altered, changed or falsified. If you are not the >> intended recipient of this message, please delete it and notify the sender. >> Although all reasonable efforts have been made to keep this transmission >> free from viruses, the sender will not be liable for damages caused by a >> transmitted virus. >> > > ------------------------------ > This message and any attachments are intended solely for the addressees > and may contain confidential information. Any unauthorized use or > disclosure, either whole or partial, is prohibited. > E-mails are susceptible to alteration. Our company shall not be liable for > the message if altered, changed or falsified. If you are not the intended > recipient of this message, please delete it and notify the sender. > Although all reasonable efforts have been made to keep this transmission > free from viruses, the sender will not be liable for damages caused by a > transmitted virus. >
Received on Friday, 9 September 2016 12:06:12 UTC