Moving forward on improving HTTP's security

This is a dumb idea unless CAs becomes automatic and free or are completely replaced by something better.<p>The reason why HTTPS isn&#x27;t used more is because it&#x27;s a major hassle and it&#x27;s quite expensive (can easily double the yearly cost for smaller sites).<p>If using HTTP 2.0 requires buying SSL certificates, the smaller sites currently not using SSL will just be stuck on HTTP 1.1 forever.

Great decision! When Google started to work on SPDY and made it SSL-only, we saw what the future could be: people upgrade to the new protocol for performance, but get better security too. What&#x27;s not to like! I was really afraid that the standardisation of HTTP&#x2F;2.0 will break this, but now all seems well after all.<p>But this is not enough; we also need to work on opportunistic encryption, to be used for sites that do not use SSL today, without any certificates, in a completely transparent fashion that requires no end-user configuration. Such encryption would not be enough to defeat active main in the middle attacks, but it would defeat passive monitoring of non-encrypted communication.<p>To those complaining about the hassle of SSL: The biggest problem today is the fact that virtual SSL hosting (multiple sites sharing an IP address without sharing the certificate, otherwise known as Server Name Indication, or SNI) is not feasible. As soon as Windows XP (the only major platform that does not support SNI) goes away, SSL will become much easier; especially for hosted services.<p>That the cost (of certificates) is a problem is a myth. It might have been a problem in the past, but today there are so many CAs to choose from. There are CAs that give away free domain-validated certificates. There are CAs that give away free certificates to open source projects. And there are also companies that sell certificates for a couple of dollars only.<p>Obtaining certificates is, no doubt, a hassle, but the fact remains that CA-issued certificates is the only practical option to deploy a secure web site today. There are also some issues with latency, but perhaps with HTTP&#x2F;2.0 (and some possible improvements in TLS 1.3) those are going to be minimised, too.

Here&#x27;s hoping we have a viable, popular alternative to the current (expensive, corrupt..) system of SSL certificate signing long before HTTP(S) 2.0 becomes prevalent..

What will this mean for caching proxies? These can be really useful in datacentre environments.<p>For data that is nominally public anyway, I prefer to be able to stick a caching proxy somewhere, and rely on other means (eg. apt&#x27;s gpg and hash verification) to ensure integrity.<p>The article says: &quot;Alternate approaches to proxy caching (such as peer-to-peer caching protocols) may be proposed here or elsewhere, since traditional proxy caching use cases will no longer be met when TLS is in wider use.&quot;

With the way Firefox gives that scare-popup on a self-signed cert, mandating SSL would only make people that cannot afford (or cannot get) a signed cert into second-class citizens on the web. Remember that one of the primary benefits to &quot;the internet&quot; is that the all peers are equal as far as the network is concerned, and the barrier to entry for publication is reduced to zero.<p>Anything that ends up as a barrier to increase that cost only serves the interests of those that wish the internet could be reduced back to &quot;cable tv&quot;, with gatekeepers able to regulate what is published while taking in a publication fee as tribute.<p>I am usually one pushing hard for encryption, but more PKI is not what is needed. The idea above about using DNS to distribute keys is a good idea; I would also suggest simply mandating that self-signed certificates [1] be treated fairly, without the scare-box. Either would still allow somebody to setup a home server with a simple apache&#x2F;whatever install, no outside approval needed.<p>[1] - Note that I said &quot;fairly&quot;, not &quot;the same as authenticated certificates&quot;. Encryption without authentication is still a benefit, and should not be given the popup that scares people away currently. <i>Just don&#x27;t mark it as &quot;secure&quot;</i> with the closed padlock!

I can&#x27;t say I agree with this. I am all for ubiquitous encryption, but this smacks of inappropriate mixing of layers. HTTP should not care about the underlying transport.<p>Someday, TLS will be replaced. I cannot imagine when this will happen, or what the replacement will be like; I am only certain that, given enough time, it will happen. When it does, HTTP should still work without modification. The proposed standard fails that test.

I&#x27;m not surprised, this does simplify things in many ways, and to be honest, there isn&#x27;t a good reason not to use SSL anyway in many cases.<p>What we need next is a browser happy way to use HTTPS only for encryption and not for verification (yes, I know!), but it would make this migration much easier. This would reduce the reliance on CAs, and would make SSL certs free in many cases.

The main issue I have with HTTPS is that it&#x27;s still not reliably possible to use name based virtual hosting over SSL because SNI isn&#x27;t supported in some OS&#x2F;Browser combinations that are still in heavy use (any IE on Windows XP, Android &lt; 3).<p>This means that we&#x27;re going to need many more IP addresses in cases where we want to host multiple HTTPs sites. This is a problem because we&#x27;re running out of IPv4 addresses and IPv6 support within the range of systems not supporting SNI isn&#x27;t that reliable either.<p>This might not matter that much in the future, because larger sites should still have enough IPv4 addresses, but it will hurt smaller sites.<p>In my case, I can&#x27;t possibly offer SSL for all of our customers (most of them are using their own domain names, so no wildcard certificates) as back when I only got 32 addresses and it&#x27;s next to impossible (and very, very expensive) to get more nowadays.

HTTP 2.0 will still be defined for unencrypted operation, for deployment on Intranets. This default is for the open web.<p>Since a number of people don&#x27;t seem to be reading TFA, I&#x27;ll help:<p><i>&quot;To be clear - we will still define how to use HTTP&#x2F;2.0 with <a href="http://" rel="nofollow">http:&#x2F;&#x2F;</a> URIs, because in some use cases, an implementer may make an informed choice to use the protocol without encryption. However, for the common case -- browsing the open Web -- you&#x27;ll need to use <a href="https://" rel="nofollow">https:&#x2F;&#x2F;</a> URIs and if you want to use the newest version of HTTP.&quot;</i>

Won&#x27;t this create the ability for a 3rd party to disable your site by having the CA revoked against your will? For example, in regards to a copyright issue?<p>Personally, I am against this, as I feel that this is a choice that should be made on a site by site basis.

This made me sigh.<p>Don&#x27;t get me wrong... As a lifelong time security guy, I&#x27;m happy to see more encryption. But implementing more security at one layer adversely impacts security at other layers. (e.g. IDS)<p>We&#x27;re really bad (as a species) at unintended consequences....

And what about WebSockets? I know it&#x27;s a different specification, but we should be using wss:&#x2F;&#x2F; too.

Wow, are they going about this entirely wrong?<p>You don&#x27;t screw around with the standard to try to drive adoption of encryption. You should solve a user interface problem by improving the <i>user interface</i>, right?<p>It&#x27;s also not about getting an SSL cert. If you&#x27;re doing anything interesting at all, you need an SSL cert, even if only for some percentage of your population. You also do need decent ways for people to distribute keys to their devices.<p>But at the end of the day, it&#x27;s the green light&#x2F;red light which is going to drive user adoption. The browser which capitalizes on privacy features and presents them best is a huge winner over the next 5 years.<p>Ultimately people should get the level of security they ask for. I don&#x27;t think the spec should be catering to users who don&#x27;t even know that http must die and https is the only way forward. Nothing could be more obviously true.<p>What&#x27;s not obvious is the adoption rate once HTTP2 is baked. What the spec <i>should</i> be contemplating is how they can get the best roll out. There are so many awesome features we want to start being able to rely on, but if the new stack isn&#x27;t pervasive, some people will think it&#x27;s hard to justify coding for it.

It would be really sad if we have a new standard gaining momentum and forcing people to stay supporting broken SSL&#x2F;TLS.<p>I hope they mandate using the newest TLS with the beast mitigation etc and also mandate perfect forward secrecy.<p>Generally, the whole CA approach also needs a rethink, but its less straightforward to trot out solutions to that problem. Hopefully Moxie and other experts will weigh in.

Why shouldn&#x27;t we be (optionally) cutting CAs out of this? They&#x27;re already known to be a weak link in the chain.<p>How about they make it an option to put your own certificate chain in your DNS records, require DNSSEC and use pinning to cover the fact that the DNS server might get intermittently MITM&#x27;d?

Now we are coupling data transfer with encryption, which we couple with validation, I thought people would learn from SOAP that this is a horrible idea.<p>I understand messing around with SSL certificates is no issue for the likes of Google, but for the little guys, it&#x27;s simply a lot of extra costs and work.<p>I don&#x27;t trust CAs and I think we should just use an approach like DKIM for SSL.<p>I might want the performance benefits of HTTP 2.0 but might not care about security.

Wasn&#x27;t this always part of the standard? What&#x27;s new this time around?<p>&lt;I&#x27;ll save my rant for why I hate HTTP 2 for another time&gt;

What changes does HTTP&#x2F;2.0 bring? What changes would it make that would want me to switch.<p>The one I would love to see solved is the state problem, cookies are not the best way to solve that problem. If there was a standard way to accomplish that within HTTP without all the mess that is Set-Cookie and the domain rules and all that fun stuff I would be very happy.

Many small sites doesnt use certs like personal sites etc..why should i care as a blogger to make my site HTTPs..its cruel..

Wasn&#x27;t HTTP 2.0 a complete failure? I thought it was already obseleted.

The cost to have someone fix absolute&#x2F;non-absolute href links will far exceed the cost of SSL or an extra IP. So expect to see a broken landscape of websites post implementation.

Fun fact: Cert-free SSL used to work with some browsers, at least Mozilla, but then they disabled the anonymous SSL modes from the browser. I was using it and was saddened...

Very good idea - will make snooping and tracking impossible. So end of targeted ads. If we can now snooze the surveillance regime as well - all the better.

So will this prevent NSA et al. spying? Or have we reached the stage where they have all of the relevant certs already embedded into their ISP black boxes?

Why is HTTP enveloping SSL? Shouldn&#x27;t the transport layer be separate from the Application layer?

PFS = Perfect Forward Security, wait, what? It&#x27;s not perfect nor it&#x27;s security. Great post.

Sounds like just unneeded overhead for some situations

Secure is good, but SSL is not the right protocol.

With Chrome rolling out AES GCM (and other browsers likely to follow suit) - this seems to be a really plausible future state of the world.

this + IX would be perfect