14 ms·

Moving forward on improving HTTP's security

489 points by iand 13y ago

willvarfar 13y ago
It would be really sad if we have a new standard gaining momentum and forcing people to stay supporting broken SSL/TLS. I hope they mandate using the newest TLS with the beast mitigation etc and also mandate perfect forward secrecy. 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.
metabrew 13y ago
Here'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..
- 1angryhacker 13y ago
  how could that work?
  - junto 13y ago
    Certificate currently has two goals: - Verification - Encryption The CA is supposed to verify and say "hey this certificate belongs to this company". What we need is for anyone to setup their cert without a CA (self-signed) and then the CA provides the verification is companies really want it. This is what happens when you try and dual purpose something. If the certificate was just about encryption then my assumption is that you wouldn't really need CAs.
    - icebraining 13y ago
      Encryption without verification only protects you from passive attackers, though. Frankly I fail to see the point, since it's not secure enough for sensitive data, but still has the disadvantages (performance, cache busting) of SSL.
      - XorNot 13y ago
        This. It's worse then useless because it's the illusion of security. It's too bad, because some type of web-of-trust mechanism for HTTP would be an incredible idea - it doesn't solve the trust problem entirely, but it would enable users to share their trust profiles amongst or against trusted individuals.
    - DrJokepu 13y ago
      Without validation, (public key) encryption is worthless, due to man in the middle attacks.
      - jules 13y ago
        Only if the middle man was already doing the attack on your first visit to the website. This is a whole lot better than no encryption at all.
        UnoriginalGuy 13y ago
        > Only if the middle man was already doing the attack on your first visit to the website. Keep in mind certificate pinning is a fairly (very!) recent addition to the internet security landscape. Before then MITM more or less completely broke encryption.
        dingaling 13y ago
        > Keep in mind certificate pinning is a fairly (very!) recent > addition to the internet security landscape As with much technology it is a re-invention of how we used to do things. Many corporate websites still use client-side certificates to ensure that the client is talking to the correct server. In the early days of Internet banking, some bank sites used to do the same; I received a cert from my bank on a shiny 'CD-ROM'. Sadly they discontinued that validation along with publishing their PGP key for secure e-mail. A step backwards.
      - ctz 13y ago
        It's worthless in the face on an active adversary, but it works very well as a countermeasure for passive mass surveillance. I do think it's a dangerous idea, though. The difference between 'secure' and 'insecure' is (at least partially) understood by most technical and non-technical people, and sometimes they can make a good decision on their requirements. The difference between passive and active adversaries is much more subtle, and I doubt people can think this through with as much clarity.
      - pdkl95 13y ago
  - icebraining 13y ago
    Moxie Marlinspike's Convergence (http://www.convergence.io/ http://www.convergence.io/) seems the best proposal, at least for the time being.
    - nhaehnle 13y ago
      That seems awfully similar to http://perspectives-project.org/ http://perspectives-project.org/ I don't know which one was first, but I wish they would cooperate to establish a standard protocol for notaries. The model of notaries that observe SSL certificates from multiple points in the internet seems greatly superior and ultimately more trustworthy than the CA model to me. It's not perfect, but it solves the most common man-in-the-middle scenarios and is potentially extensible to become even more robust.
      - gpvos 13y ago
        Convergence's "details" page sez: > Convergence is based on the ideas originally developed by the Perspectives Project at Carnegie Mellon University.
      - rakoo 13y ago
        Perspectives/Convergence really is a great system, but it unfortunately still has several problems: - it completely leaks your browsing history: you basically ask a notary "what's the certificate you see for kinkyneighbors.com?". Convergence addresses this, though - it requires network-heavy intermediaries for all the browsing of all the people around the world. - it still doesn't solve authenticity: an attacker could very well be controlling all connections arriving at your house, or leaving the target's server, and fool everyone Convergence/Perspectives should be coupled with certificate pinning, aka storing _really_ trusted authorities (ie verified by hand) on your computer. Guess what ? [Moxie's next project is just that [0] (For anyone curious, I highly recommend Moxie's talk [1] about Convergence, it does a great job at explaining what's the problem, what's Convergence and how it can solve at least part of it) [0] http://tack.io/ http://tack.io/ [1] http://www.youtube.com/watch?v=Z7Wl2FW2TcA http://www.youtube.com/watch?v=Z7Wl2FW2TcA
    - ivanr 13y ago
  - perlgeek 13y ago
    How about the TLD NICs sign your certificates when you register the domain? Ideally they have already verified your name, company and address, and you have to trust them to some extend anyway, because they are responsible for the name servers
    - dcc1 13y ago
      Ehm no thank you, not all of us want to give away such information for personal projects, there are many reasons for people wanting to register domains privately (beside spammers harvesting whois)
      - toast0 13y ago
        If you give your registrar invalid contact information, your domain is subject to deletion by policy. Proxy registration is OK, as long as the contact information works.
      - threeseed 13y ago
        At some point you have to give your information whether it's to the registrar or the proxy company. What is wrong with them using the same information to handle the certificates on your behalf ?
      - wmf 13y ago
        AFAIK DNSSec has no additional identity requirements compared to normal DNS.
    - rakoo 13y ago
      > and you have to trust them to some extend anyway, because they are responsible for the name servers So this is not solving the problem, this is moving it elsewhere.
- richardwhiuk 13y ago
  DANE TLSA is a possible (viable) alternative here.
- arantius 13y ago
  Recently learned of http://convergence.io/ http://convergence.io/ (talk: http://youtu.be/UawS3_iuHoA http://youtu.be/UawS3_iuHoA ) which sounds quite promising. It's not perfect (private, non routable sites?) but removes the certificate authority oligopoly from the picture without reducing security (AFAICT).
richbradshaw 13y ago
I'm not surprised, this does simplify things in many ways, and to be honest, there isn't a good reason not to use SSL anyway in many cases. 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.
- pedrocr 13y ago
  What we need is to do away with CAs entirely and use the DNS hierarchy to distribute keys (with DNSSEC for example). That way you only have to trust your own registrar (that you already need to trust anyway) and not any random CA in the world. So if you own example.com you get the COM registrar to sign your key and become your own CA for *.example.com.
  - marshray 13y ago
    Seems like you could accomplish the same thing by CA pinning your site to Verisign (who runs the DNSSEC root).
    - pedrocr 13y ago
      That and an expensive *.example.com certificate would get you half of the way there. You still wouldn't be able to be your own CA, signing certificates for foo.example.com that other people can use. And it would require everyone to buy certificates from Verisign. Nowadays national governments already setup their own CAs because they want to be able to issue certificates for all sorts of government organizations. With the setup I'm suggesting Germany would get .de signed, then they could sign gov.de and then have gov.de sign someagency.gov.de. somecompany.de would get their certificate from the DE registrar when they sign up for the domain and also be able to issue somepartner.somecompany.de or jabber.somecomapny.de certificates that if discovered only compromise part of their network, unlike having a wildcard certificate installed on every server.
  - joosters 13y ago
    Doesn't this just mean the registrar ends up (effectively) being the one who trusts all the random CAs instead?
ollymorgs 13y ago
And what about WebSockets? I know it's a different specification, but we should be using wss:// too.
Michael_Murray 13y ago
This made me sigh. Don't get me wrong... As a lifelong time security guy, I'm happy to see more encryption. But implementing more security at one layer adversely impacts security at other layers. (e.g. IDS) We're really bad (as a species) at unintended consequences....
- digitalWestie 13y ago
  As a security novice could you expand?
  - majelix 13y ago
    Snarky answer: He wants to be able to spy on his users in order to protect them from themselves.
- filipedeschamps 13y ago
  Also want more information about what you said.
  - Michael_Murray 13y ago
    IDS was only one example. When technology evolves, we tend to break the things that we used to work around the limitations in the previous technologies. There's a whole suite of technologies in security that rely on the idea that we can look at packets as they travel to figure out if anything malicious is going on - Intrusion Detection Systems, Data Loss/Leak Prevention, Deep Packet Inspection Firewalls, Web Content Filters, etc. Each of those systems relies on the ability to see the unencrypted traffic - to "spy" on users, as someone else so snarkily put it. As SSL has become more prevalent, we have turned to (as someone else pointed out) terminating the encrypted traffic once it's on a "trusted" network so we can do that - but, if HTTP/2 is ONLY over SSL, there will be no "termination" - it will be encrypted from one end to the other. That means that all of the traditional security technologies will be completely blind to anything that happens in that communication stream. I wasn't bemoaning progress - I think this is a good step. But it's also a step toward a temporary lack of security as the organizations catch up. It's because the security industry is a trailing industry (by definition) - you can't build a product that fixes security issues until you know: a) what the issues are, and b) how to fix them. So, for a while, the early adopters of HTTP/2 are going to fly without a net somewhat. (FYI - this same set of discussion points applies to IPv6 adoption)
kristofferR 13y ago
This is a dumb idea unless CAs becomes automatic and free or are completely replaced by something better. The reason why HTTPS isn't used more is because it's a major hassle and it's quite expensive (can easily double the yearly cost for smaller sites). 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.
- dchest 13y ago
  the smaller sites currently not using SSL will just be stuck on HTTP 1.1 forever Is it a problem?
  - esolyt 13y ago
    I don't think so. We are also "stuck" on IPv4 which hasn't been a problem.
  - josteink 13y ago
    Saying that you can only use this new technology if you are willing to hand out $100 a year to some third party provider which you really don't see the need for is a major hindrance to adoption. Imagine if every former "free" technology (tcp/ip, email, http, c-compiler, whatever) demanded you pay $100 annually to use it. How many hackers creating things which we now take for granted do you think would have been discouraged from doing just so? Security is nice, but that doesn't mean it's worth it or required all over, at any cost. De-facto requiring a paid "license" to operate on the internet is not the right way to go.
    - hrktb 13y ago
      If you think it as something similar to DNS it's not so shocking. Right now we are handing cash to get a usable domain name, or ask some other entity to share a space on their domains. Now you'll also pay for you SSL certificate or ask some other entity to let you share a piece of theirs.
    - dchest 13y ago
      There's nothing in this technology that demands payment. You can distribute your own root certificate to clients, or create a free certification authority (or join http://www.cacert.org/ http://www.cacert.org/), if you'd like.
ivanr 13y ago
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's not to like! I was really afraid that the standardisation of HTTP/2.0 will break this, but now all seems well after all. 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. 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. 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. 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/2.0 (and some possible improvements in TLS 1.3) those are going to be minimised, too.
- caf 13y ago
  It is worth noting that Windows XP is EOL April 8, 2014.
- fulafel 13y ago
  > 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 That's exactly what this proposes!
  - ivanr 13y ago
    No, not as far as I can tell. The linked document has two options for opportunistic encryption, one of which is without server authentication, but that does not mean without certificates. The draft http://tools.ietf.org/html/draft-nottingham-http2-encryption-01 http://tools.ietf.org/html/draft-nottingham-http2-encryption... also states that the certificates would be used, just not necessarily checked. My issue with the use of certificates is that it would in practice probably mean required manual server-side configuration, which would be a barrier to adoption (even if self-signed certificates are allowed). I would prefer a certificate-less approach that is available by default and for all sites. The proposal also requires HTTP/2.0 for opportunistic encryption, even though we could probably make it work with HTTP/1.x too.
rlpb 13y ago
What will this mean for caching proxies? These can be really useful in datacentre environments. 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's gpg and hash verification) to ensure integrity. The article says: "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."
- perbu 13y ago
  You might be confusing forward- and reverse proxies. Transparent forward proxies can now go bugger off. They will not be able to intercept HTTP/2.0 traffic. Reverse proxies, in front of web applications will need to terminate the SSL before caching. Same as today.
  - rlpb 13y ago
    Proxies don't have to be transparent. Non-transparent forward proxies that I set up and choose to use are very handy because I get a direct performance improvement out of them. As an aside, I hear that in much of the more distant parts of the world (Australia/New Zealand) transparent forward proxies are common amongst consumer ISPs to help with their high latency to the rest of the world.
    - leoc 13y ago
      What's wrong in principle with transparent forward proxying anyway? From almost any perspective other than security/anonymity, forcing a client to make a TCP connection to a publisher's computers every time the client wants to read one of the publisher's documents* is a terrible decision: stark, screaming madness. If transparent forward proxying breaks things with HTTP then that's a problem with HTTP. Even from a security/anonymity point of view, an end-to-end connection is no panacea either: if encrypted it (hopefully) prevents third parties from seeing the content of the data sent, but it also makes damned sure that the publisher gets the client's IP address every time the client GETs a webpage, and as recent events have illustrated publisher endpoints aren't super-trustworthy either. * Unless the client itself has an older copy which it knows hasn't expired; but a single client is much more unlikely to happen to have one of those than is a proxy which handles requests from many clients, and probably has more storage space to devote to caching too.
deleted 13y ago
[deleted]
tls 13y ago
this + IX would be perfect
pdkl95 13y ago
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 "the internet" 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. 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 "cable tv", with gatekeepers able to regulate what is published while taking in a publication fee as tribute. 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/whatever install, no outside approval needed. [1] - Note that I said "fairly", not "the same as authenticated certificates". Encryption without authentication is still a benefit, and should not be given the popup that scares people away currently. Just don't mark it as "secure" with the closed padlock!
RexRollman 13y ago
Won'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? Personally, I am against this, as I feel that this is a choice that should be made on a site by site basis.
- dubcanada 13y ago
  I'm 90% sure you can't disable someones SSL certificate once they have it. Which is why most of the time it takes a bit to actually get it.
  - grahamedgecombe 13y ago
    OCSP and CRLs allow a CA to revoke an SSL certificate (albeit with a varying degree of browser support).
- mnordhoff 13y ago
  Yes. They can already do this more reliably by disabling your domain name, though (not to mention your hosting). Edit (T+16 minutes): I said "more reliably" because not all TLS clients perform CRL or OCSP checks -- as mentioned in other comments -- so it's not 100% effective. Web browsers probably mostly all do, though. Certainly enough of them do that running a website with a revoked cert is impractical. As for disabling your domain name, if you don't know, that really does happen. US law enforcement seizes domains on US TLDs (such as .com) all the time. Edit (T+23 minutes): ... and registrars have been known to cave to strongly-worded letters from civilians, too (see e.g. Go Daddy, MySpace and seclists.org several years ago).
maxk42 13y ago
Secure is good, but SSL is not the right protocol.
- billwashere 13y ago
  What would you recommend instead?
  - kris121 13y ago
    NSA
- Sami_Lehtinen 13y ago
  I guess you haven't used IPsec, SSL is a lot better option.
Torn 13y ago
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?
- mtgx 13y ago
  Prevent? Not really. Make it much harder and expensive for them? Yes. But after we do this, the next target is definitely fixing the CA system so it's trustless, because we can be sure the CA's will be NSA's next targets, legally or illegally.
  - taeric 13y ago
    I'm curious on how you envision a trustless security system to work. Any links?
fulafel 13y ago
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...
itsbits 13y ago
Many small sites doesnt use certs like personal sites etc..why should i care as a blogger to make my site HTTPs..its cruel..
pilif 13y ago
The main issue I have with HTTPS is that it's still not reliably possible to use name based virtual hosting over SSL because SNI isn't supported in some OS/Browser combinations that are still in heavy use (any IE on Windows XP, Android < 3). This means that we're going to need many more IP addresses in cases where we want to host multiple HTTPs sites. This is a problem because we're running out of IPv4 addresses and IPv6 support within the range of systems not supporting SNI isn't that reliable either. This might not matter that much in the future, because larger sites should still have enough IPv4 addresses, but it will hurt smaller sites. In my case, I can'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's next to impossible (and very, very expensive) to get more nowadays.
- deleted 13y ago
  [deleted]
- bowlofpetunias 13y ago
  I'm using SAN certificates (multiple domains on single cert) for that purpose. It allows me to put up to 100 domains on a single IP/certificate, which is fine for a low-traffic SaaS service. Premium clients can still get their own IP and certificate. Globalsign has even developed a special service for those cases (https://www.globalsign.com/cloud/ https://www.globalsign.com/cloud/).
- SudoAlex 13y ago
  Windows XP support ends in April 2014. Android 2.2/2.3 is currently at 28% market share and dropping. There's a point at where you have to drop support - even if you've got laggards. Look at the stats for your sites, find out the percentage of IE users on Windows XP. A quick sampling of 2 popular sites I'm running shows it to be around 2-3% for IE/XP users - I wouldn't call that heavy use, but obviously it's going to be different for every site. Charge higher prices for those wanting a dedicated IP for their site - pass on the costs which you'll be facing due to IPv4 exhaustion. Prioritise the more important sites for dedicated IPs. If the site generates revenue - keep it on a dedicated IP for a bit longer, if not then it can share an IP with SNI.
- 13y ago
Yuioup 13y ago
Wasn't HTTP 2.0 a complete failure? I thought it was already obseleted.
- parasubvert 13y ago
  By what? HTTP 2.0 is the standardized version of SPDY.
  - Yuioup 13y ago
    From what I understood HTTP 2.0 was designed by a committee that failed to come up with a usable standard. That is why everybody still uses HTTP 1. I thought that 2.0 was skipped over in favor of another standard but I could be wrong.
    - parasubvert 13y ago
      IETF is a rather chaotic process, probably the closest thing to "anti-committee" in the standards world. The working group chair, Mark Nottingham, is a pretty respected guy in the web world. If you use Chrome or Firefox as a browser, you're probably already using SPDY as many larger servers (Google, Wordpress, Twitter, a bit of Facebook) support it.
carsonreinke 13y ago
Sounds like just unneeded overhead for some situations
Millennium 13y ago
I can'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. 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.
- hsivonen 13y ago
  TLS on port 443 is what makes SPDY / HTTP2 deployable. That way the new protocol is hidden from middle boxes that mess with port 80 traffic and would break things if the traffic didn't look like HTTP 1.x.
photon137 13y ago
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.
jimktrains2 13y ago
Wasn't this always part of the standard? What's new this time around? <I'll save my rant for why I hate HTTP 2 for another time>
anuraj 13y ago
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.
Sami_Lehtinen 13y ago
PFS = Perfect Forward Security, wait, what? It's not perfect nor it's security. Great post.
jjoe 13y ago
The cost to have someone fix absolute/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.
- parasubvert 13y ago
  Why would links suddenly break? It's not like HTTP/1 will ever go away.
  - jjoe 13y ago
    Non-ssl rendering of local hrefs is lenient. Browsers don't complain. With forced ssl, however, badly constructed hrefs will force the browser to complain that a SSL enabled website has non-ssl hrefs. Most people don't understand that a href needs to be absolute or how to easily fix it.
    - parasubvert 13y ago
      you're presuming that a web application would serve a page up with HTTP/2 and not test their embedded hrefs for the user experience? more likely legacy pages will remain HTTP/1
parasubvert 13y ago
HTTP 2.0 will still be defined for unencrypted operation, for deployment on Intranets. This default is for the open web. Since a number of people don't seem to be reading TFA, I'll help: "To be clear - we will still define how to use HTTP/2.0 with http:// http:// 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'll need to use https:// https:// URIs and if you want to use the newest version of HTTP."
- zurn 13y ago
  That's not what the proposals A and B say - only C says http:// http:// would be cleartext. Also the followup message(s) say the poster misrepresents the C option presented at the meeting. See http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0629.html http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/...
deleted 13y ago
[deleted]
- deleted 13y ago
  [deleted]
Scramblejams 13y ago
Why shouldn't we be (optionally) cutting CAs out of this? They're already known to be a weak link in the chain. 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'd?
jimktrains2 13y ago
Why is HTTP enveloping SSL? Shouldn't the transport layer be separate from the Application layer?
X-Istence 13y ago
What changes does HTTP/2.0 bring? What changes would it make that would want me to switch. 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.
voidr 13y ago
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. I understand messing around with SSL certificates is no issue for the likes of Google, but for the little guys, it's simply a lot of extra costs and work. I don't trust CAs and I think we should just use an approach like DKIM for SSL. I might want the performance benefits of HTTP 2.0 but might not care about security.
zaroth 13y ago
Wow, are they going about this entirely wrong? You don't screw around with the standard to try to drive adoption of encryption. You should solve a user interface problem by improving the user interface, right? It's also not about getting an SSL cert. If you'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. But at the end of the day, it's the green light/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. Ultimately people should get the level of security they ask for. I don't think the spec should be catering to users who don't even know that http must die and https is the only way forward. Nothing could be more obviously true. What's not obvious is the adoption rate once HTTP2 is baked. What the spec should 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't pervasive, some people will think it's hard to justify coding for it.

489 points by iand 13y ago

It would be really sad if we have a new standard gaining momentum and forcing people to stay supporting broken SSL/TLS. I hope they mandate using the newest TLS with the beast mitigation etc and also mandate perfect forward secrecy. 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.

metabrew 13y ago

Here'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..

1angryhacker 13y ago
how could that work?
- junto 13y ago
  Certificate currently has two goals: - Verification - Encryption The CA is supposed to verify and say "hey this certificate belongs to this company". What we need is for anyone to setup their cert without a CA (self-signed) and then the CA provides the verification is companies really want it. This is what happens when you try and dual purpose something. If the certificate was just about encryption then my assumption is that you wouldn't really need CAs.
  - icebraining 13y ago
    Encryption without verification only protects you from passive attackers, though. Frankly I fail to see the point, since it's not secure enough for sensitive data, but still has the disadvantages (performance, cache busting) of SSL.
    - XorNot 13y ago
      This. It's worse then useless because it's the illusion of security. It's too bad, because some type of web-of-trust mechanism for HTTP would be an incredible idea - it doesn't solve the trust problem entirely, but it would enable users to share their trust profiles amongst or against trusted individuals.
  - DrJokepu 13y ago
    Without validation, (public key) encryption is worthless, due to man in the middle attacks.
    - jules 13y ago
      Only if the middle man was already doing the attack on your first visit to the website. This is a whole lot better than no encryption at all.
      - UnoriginalGuy 13y ago
        > Only if the middle man was already doing the attack on your first visit to the website. Keep in mind certificate pinning is a fairly (very!) recent addition to the internet security landscape. Before then MITM more or less completely broke encryption.
        dingaling 13y ago
        > Keep in mind certificate pinning is a fairly (very!) recent > addition to the internet security landscape As with much technology it is a re-invention of how we used to do things. Many corporate websites still use client-side certificates to ensure that the client is talking to the correct server. In the early days of Internet banking, some bank sites used to do the same; I received a cert from my bank on a shiny 'CD-ROM'. Sadly they discontinued that validation along with publishing their PGP key for secure e-mail. A step backwards.
    - ctz 13y ago
      It's worthless in the face on an active adversary, but it works very well as a countermeasure for passive mass surveillance. I do think it's a dangerous idea, though. The difference between 'secure' and 'insecure' is (at least partially) understood by most technical and non-technical people, and sometimes they can make a good decision on their requirements. The difference between passive and active adversaries is much more subtle, and I doubt people can think this through with as much clarity.
    - pdkl95 13y ago
- icebraining 13y ago
  Moxie Marlinspike's Convergence (http://www.convergence.io/ http://www.convergence.io/) seems the best proposal, at least for the time being.
  - nhaehnle 13y ago
    That seems awfully similar to http://perspectives-project.org/ http://perspectives-project.org/ I don't know which one was first, but I wish they would cooperate to establish a standard protocol for notaries. The model of notaries that observe SSL certificates from multiple points in the internet seems greatly superior and ultimately more trustworthy than the CA model to me. It's not perfect, but it solves the most common man-in-the-middle scenarios and is potentially extensible to become even more robust.
    - gpvos 13y ago
      Convergence's "details" page sez: > Convergence is based on the ideas originally developed by the Perspectives Project at Carnegie Mellon University.
    - rakoo 13y ago
      Perspectives/Convergence really is a great system, but it unfortunately still has several problems: - it completely leaks your browsing history: you basically ask a notary "what's the certificate you see for kinkyneighbors.com?". Convergence addresses this, though - it requires network-heavy intermediaries for all the browsing of all the people around the world. - it still doesn't solve authenticity: an attacker could very well be controlling all connections arriving at your house, or leaving the target's server, and fool everyone Convergence/Perspectives should be coupled with certificate pinning, aka storing _really_ trusted authorities (ie verified by hand) on your computer. Guess what ? [Moxie's next project is just that [0] (For anyone curious, I highly recommend Moxie's talk [1] about Convergence, it does a great job at explaining what's the problem, what's Convergence and how it can solve at least part of it) [0] http://tack.io/ http://tack.io/ [1] http://www.youtube.com/watch?v=Z7Wl2FW2TcA http://www.youtube.com/watch?v=Z7Wl2FW2TcA
  - ivanr 13y ago
- perlgeek 13y ago
  How about the TLD NICs sign your certificates when you register the domain? Ideally they have already verified your name, company and address, and you have to trust them to some extend anyway, because they are responsible for the name servers
  - dcc1 13y ago
    Ehm no thank you, not all of us want to give away such information for personal projects, there are many reasons for people wanting to register domains privately (beside spammers harvesting whois)
    - toast0 13y ago
      If you give your registrar invalid contact information, your domain is subject to deletion by policy. Proxy registration is OK, as long as the contact information works.
    - threeseed 13y ago
      At some point you have to give your information whether it's to the registrar or the proxy company. What is wrong with them using the same information to handle the certificates on your behalf ?
    - wmf 13y ago
      AFAIK DNSSec has no additional identity requirements compared to normal DNS.
  - rakoo 13y ago
    > and you have to trust them to some extend anyway, because they are responsible for the name servers So this is not solving the problem, this is moving it elsewhere.
richardwhiuk 13y ago
DANE TLSA is a possible (viable) alternative here.
arantius 13y ago
Recently learned of http://convergence.io/ http://convergence.io/ (talk: http://youtu.be/UawS3_iuHoA http://youtu.be/UawS3_iuHoA ) which sounds quite promising. It's not perfect (private, non routable sites?) but removes the certificate authority oligopoly from the picture without reducing security (AFAICT).

richbradshaw 13y ago

I'm not surprised, this does simplify things in many ways, and to be honest, there isn't a good reason not to use SSL anyway in many cases. 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.

pedrocr 13y ago
What we need is to do away with CAs entirely and use the DNS hierarchy to distribute keys (with DNSSEC for example). That way you only have to trust your own registrar (that you already need to trust anyway) and not any random CA in the world. So if you own example.com you get the COM registrar to sign your key and become your own CA for *.example.com.
- marshray 13y ago
  Seems like you could accomplish the same thing by CA pinning your site to Verisign (who runs the DNSSEC root).
  - pedrocr 13y ago
    That and an expensive *.example.com certificate would get you half of the way there. You still wouldn't be able to be your own CA, signing certificates for foo.example.com that other people can use. And it would require everyone to buy certificates from Verisign. Nowadays national governments already setup their own CAs because they want to be able to issue certificates for all sorts of government organizations. With the setup I'm suggesting Germany would get .de signed, then they could sign gov.de and then have gov.de sign someagency.gov.de. somecompany.de would get their certificate from the DE registrar when they sign up for the domain and also be able to issue somepartner.somecompany.de or jabber.somecomapny.de certificates that if discovered only compromise part of their network, unlike having a wildcard certificate installed on every server.
- joosters 13y ago
  Doesn't this just mean the registrar ends up (effectively) being the one who trusts all the random CAs instead?

ollymorgs 13y ago

And what about WebSockets? I know it's a different specification, but we should be using wss:// too.

Michael_Murray 13y ago

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

digitalWestie 13y ago
As a security novice could you expand?
- majelix 13y ago
  Snarky answer: He wants to be able to spy on his users in order to protect them from themselves.
filipedeschamps 13y ago
Also want more information about what you said.
- Michael_Murray 13y ago
  IDS was only one example. When technology evolves, we tend to break the things that we used to work around the limitations in the previous technologies. There's a whole suite of technologies in security that rely on the idea that we can look at packets as they travel to figure out if anything malicious is going on - Intrusion Detection Systems, Data Loss/Leak Prevention, Deep Packet Inspection Firewalls, Web Content Filters, etc. Each of those systems relies on the ability to see the unencrypted traffic - to "spy" on users, as someone else so snarkily put it. As SSL has become more prevalent, we have turned to (as someone else pointed out) terminating the encrypted traffic once it's on a "trusted" network so we can do that - but, if HTTP/2 is ONLY over SSL, there will be no "termination" - it will be encrypted from one end to the other. That means that all of the traditional security technologies will be completely blind to anything that happens in that communication stream. I wasn't bemoaning progress - I think this is a good step. But it's also a step toward a temporary lack of security as the organizations catch up. It's because the security industry is a trailing industry (by definition) - you can't build a product that fixes security issues until you know: a) what the issues are, and b) how to fix them. So, for a while, the early adopters of HTTP/2 are going to fly without a net somewhat. (FYI - this same set of discussion points applies to IPv6 adoption)

kristofferR 13y ago

This is a dumb idea unless CAs becomes automatic and free or are completely replaced by something better. The reason why HTTPS isn't used more is because it's a major hassle and it's quite expensive (can easily double the yearly cost for smaller sites). 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.

dchest 13y ago
the smaller sites currently not using SSL will just be stuck on HTTP 1.1 forever Is it a problem?
- esolyt 13y ago
  I don't think so. We are also "stuck" on IPv4 which hasn't been a problem.
- josteink 13y ago
  Saying that you can only use this new technology if you are willing to hand out $100 a year to some third party provider which you really don't see the need for is a major hindrance to adoption. Imagine if every former "free" technology (tcp/ip, email, http, c-compiler, whatever) demanded you pay $100 annually to use it. How many hackers creating things which we now take for granted do you think would have been discouraged from doing just so? Security is nice, but that doesn't mean it's worth it or required all over, at any cost. De-facto requiring a paid "license" to operate on the internet is not the right way to go.
  - hrktb 13y ago
    If you think it as something similar to DNS it's not so shocking. Right now we are handing cash to get a usable domain name, or ask some other entity to share a space on their domains. Now you'll also pay for you SSL certificate or ask some other entity to let you share a piece of theirs.
  - dchest 13y ago
    There's nothing in this technology that demands payment. You can distribute your own root certificate to clients, or create a free certification authority (or join http://www.cacert.org/ http://www.cacert.org/), if you'd like.

ivanr 13y ago

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's not to like! I was really afraid that the standardisation of HTTP/2.0 will break this, but now all seems well after all. 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. 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. 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. 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/2.0 (and some possible improvements in TLS 1.3) those are going to be minimised, too.

caf 13y ago
It is worth noting that Windows XP is EOL April 8, 2014.
fulafel 13y ago
> 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 That's exactly what this proposes!
- ivanr 13y ago
  No, not as far as I can tell. The linked document has two options for opportunistic encryption, one of which is without server authentication, but that does not mean without certificates. The draft http://tools.ietf.org/html/draft-nottingham-http2-encryption-01 http://tools.ietf.org/html/draft-nottingham-http2-encryption... also states that the certificates would be used, just not necessarily checked. My issue with the use of certificates is that it would in practice probably mean required manual server-side configuration, which would be a barrier to adoption (even if self-signed certificates are allowed). I would prefer a certificate-less approach that is available by default and for all sites. The proposal also requires HTTP/2.0 for opportunistic encryption, even though we could probably make it work with HTTP/1.x too.

rlpb 13y ago

What will this mean for caching proxies? These can be really useful in datacentre environments. 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's gpg and hash verification) to ensure integrity. The article says: "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."

perbu 13y ago
You might be confusing forward- and reverse proxies. Transparent forward proxies can now go bugger off. They will not be able to intercept HTTP/2.0 traffic. Reverse proxies, in front of web applications will need to terminate the SSL before caching. Same as today.
- rlpb 13y ago
  Proxies don't have to be transparent. Non-transparent forward proxies that I set up and choose to use are very handy because I get a direct performance improvement out of them. As an aside, I hear that in much of the more distant parts of the world (Australia/New Zealand) transparent forward proxies are common amongst consumer ISPs to help with their high latency to the rest of the world.
  - leoc 13y ago
    What's wrong in principle with transparent forward proxying anyway? From almost any perspective other than security/anonymity, forcing a client to make a TCP connection to a publisher's computers every time the client wants to read one of the publisher's documents* is a terrible decision: stark, screaming madness. If transparent forward proxying breaks things with HTTP then that's a problem with HTTP. Even from a security/anonymity point of view, an end-to-end connection is no panacea either: if encrypted it (hopefully) prevents third parties from seeing the content of the data sent, but it also makes damned sure that the publisher gets the client's IP address every time the client GETs a webpage, and as recent events have illustrated publisher endpoints aren't super-trustworthy either. * Unless the client itself has an older copy which it knows hasn't expired; but a single client is much more unlikely to happen to have one of those than is a proxy which handles requests from many clients, and probably has more storage space to devote to caching too.

deleted 13y ago

[deleted]

tls 13y ago

this + IX would be perfect

pdkl95 13y ago

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 "the internet" 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. 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 "cable tv", with gatekeepers able to regulate what is published while taking in a publication fee as tribute. 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/whatever install, no outside approval needed. [1] - Note that I said "fairly", not "the same as authenticated certificates". Encryption without authentication is still a benefit, and should not be given the popup that scares people away currently. Just don't mark it as "secure" with the closed padlock!

RexRollman 13y ago

Won'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? Personally, I am against this, as I feel that this is a choice that should be made on a site by site basis.

dubcanada 13y ago
I'm 90% sure you can't disable someones SSL certificate once they have it. Which is why most of the time it takes a bit to actually get it.
- grahamedgecombe 13y ago
  OCSP and CRLs allow a CA to revoke an SSL certificate (albeit with a varying degree of browser support).
mnordhoff 13y ago
Yes. They can already do this more reliably by disabling your domain name, though (not to mention your hosting). Edit (T+16 minutes): I said "more reliably" because not all TLS clients perform CRL or OCSP checks -- as mentioned in other comments -- so it's not 100% effective. Web browsers probably mostly all do, though. Certainly enough of them do that running a website with a revoked cert is impractical. As for disabling your domain name, if you don't know, that really does happen. US law enforcement seizes domains on US TLDs (such as .com) all the time. Edit (T+23 minutes): ... and registrars have been known to cave to strongly-worded letters from civilians, too (see e.g. Go Daddy, MySpace and seclists.org several years ago).

maxk42 13y ago

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

billwashere 13y ago
What would you recommend instead?
- kris121 13y ago
  NSA
Sami_Lehtinen 13y ago
I guess you haven't used IPsec, SSL is a lot better option.

Torn 13y ago

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?

mtgx 13y ago
Prevent? Not really. Make it much harder and expensive for them? Yes. But after we do this, the next target is definitely fixing the CA system so it's trustless, because we can be sure the CA's will be NSA's next targets, legally or illegally.
- taeric 13y ago
  I'm curious on how you envision a trustless security system to work. Any links?

fulafel 13y ago

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...

itsbits 13y ago

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

pilif 13y ago

The main issue I have with HTTPS is that it's still not reliably possible to use name based virtual hosting over SSL because SNI isn't supported in some OS/Browser combinations that are still in heavy use (any IE on Windows XP, Android < 3). This means that we're going to need many more IP addresses in cases where we want to host multiple HTTPs sites. This is a problem because we're running out of IPv4 addresses and IPv6 support within the range of systems not supporting SNI isn't that reliable either. This might not matter that much in the future, because larger sites should still have enough IPv4 addresses, but it will hurt smaller sites. In my case, I can'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's next to impossible (and very, very expensive) to get more nowadays.

deleted 13y ago
[deleted]
bowlofpetunias 13y ago
I'm using SAN certificates (multiple domains on single cert) for that purpose. It allows me to put up to 100 domains on a single IP/certificate, which is fine for a low-traffic SaaS service. Premium clients can still get their own IP and certificate. Globalsign has even developed a special service for those cases (https://www.globalsign.com/cloud/ https://www.globalsign.com/cloud/).
SudoAlex 13y ago
Windows XP support ends in April 2014. Android 2.2/2.3 is currently at 28% market share and dropping. There's a point at where you have to drop support - even if you've got laggards. Look at the stats for your sites, find out the percentage of IE users on Windows XP. A quick sampling of 2 popular sites I'm running shows it to be around 2-3% for IE/XP users - I wouldn't call that heavy use, but obviously it's going to be different for every site. Charge higher prices for those wanting a dedicated IP for their site - pass on the costs which you'll be facing due to IPv4 exhaustion. Prioritise the more important sites for dedicated IPs. If the site generates revenue - keep it on a dedicated IP for a bit longer, if not then it can share an IP with SNI.
13y ago

Yuioup 13y ago

Wasn't HTTP 2.0 a complete failure? I thought it was already obseleted.

parasubvert 13y ago
By what? HTTP 2.0 is the standardized version of SPDY.
- Yuioup 13y ago
  From what I understood HTTP 2.0 was designed by a committee that failed to come up with a usable standard. That is why everybody still uses HTTP 1. I thought that 2.0 was skipped over in favor of another standard but I could be wrong.
  - parasubvert 13y ago
    IETF is a rather chaotic process, probably the closest thing to "anti-committee" in the standards world. The working group chair, Mark Nottingham, is a pretty respected guy in the web world. If you use Chrome or Firefox as a browser, you're probably already using SPDY as many larger servers (Google, Wordpress, Twitter, a bit of Facebook) support it.

carsonreinke 13y ago

Sounds like just unneeded overhead for some situations

Millennium 13y ago

I can'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. 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.

hsivonen 13y ago
TLS on port 443 is what makes SPDY / HTTP2 deployable. That way the new protocol is hidden from middle boxes that mess with port 80 traffic and would break things if the traffic didn't look like HTTP 1.x.

photon137 13y ago

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.

jimktrains2 13y ago

Wasn't this always part of the standard? What's new this time around? <I'll save my rant for why I hate HTTP 2 for another time>

anuraj 13y ago

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.

Sami_Lehtinen 13y ago

PFS = Perfect Forward Security, wait, what? It's not perfect nor it's security. Great post.

jjoe 13y ago

The cost to have someone fix absolute/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.

parasubvert 13y ago
Why would links suddenly break? It's not like HTTP/1 will ever go away.
- jjoe 13y ago
  Non-ssl rendering of local hrefs is lenient. Browsers don't complain. With forced ssl, however, badly constructed hrefs will force the browser to complain that a SSL enabled website has non-ssl hrefs. Most people don't understand that a href needs to be absolute or how to easily fix it.
  - parasubvert 13y ago
    you're presuming that a web application would serve a page up with HTTP/2 and not test their embedded hrefs for the user experience? more likely legacy pages will remain HTTP/1

parasubvert 13y ago

HTTP 2.0 will still be defined for unencrypted operation, for deployment on Intranets. This default is for the open web. Since a number of people don't seem to be reading TFA, I'll help: "To be clear - we will still define how to use HTTP/2.0 with http:// http:// 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'll need to use https:// https:// URIs and if you want to use the newest version of HTTP."

zurn 13y ago
That's not what the proposals A and B say - only C says http:// http:// would be cleartext. Also the followup message(s) say the poster misrepresents the C option presented at the meeting. See http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0629.html http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/...

deleted 13y ago

[deleted]

deleted 13y ago
[deleted]

Scramblejams 13y ago

Why shouldn't we be (optionally) cutting CAs out of this? They're already known to be a weak link in the chain. 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'd?

jimktrains2 13y ago

Why is HTTP enveloping SSL? Shouldn't the transport layer be separate from the Application layer?

X-Istence 13y ago

What changes does HTTP/2.0 bring? What changes would it make that would want me to switch. 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.

voidr 13y ago

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. I understand messing around with SSL certificates is no issue for the likes of Google, but for the little guys, it's simply a lot of extra costs and work. I don't trust CAs and I think we should just use an approach like DKIM for SSL. I might want the performance benefits of HTTP 2.0 but might not care about security.

zaroth 13y ago

Wow, are they going about this entirely wrong? You don't screw around with the standard to try to drive adoption of encryption. You should solve a user interface problem by improving the user interface, right? It's also not about getting an SSL cert. If you'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. But at the end of the day, it's the green light/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. Ultimately people should get the level of security they ask for. I don't think the spec should be catering to users who don't even know that http must die and https is the only way forward. Nothing could be more obviously true. What's not obvious is the adoption rate once HTTP2 is baked. What the spec should 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't pervasive, some people will think it's hard to justify coding for it.