Moving forward on improving HTTP's security
lists.w3.org
lists.w3.org
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.
The CA part is only to verify that the machine you are talking to is who it says it is.... in reality all this really verifies is that they filled out a form and there is probably a money trial somewhere leading to a real entity.
But I've never understood why the identity is so tied to the transport security. It would make everyone's life easier if HTTPS could be used WITHOUT identity verification (for 90% of cases this would make the world a better place)
We'd still want to purchase third-party identify verification... and browsers would still present this in the same way ("green padlocks" etc)... but even without verification every connection could be encrypted uniquely, and it would raise the bar considerably for a great number of sniffing-based issues would it not?
EDIT: I guess what I'm saying is a social issue: We've put so much effort into telling everyone that "HTTPS is totally secure", that we've left no room for a system that is "Mostly secure, unless someone has compromised the remote system/network" .... maybe it's too late to teach everyone the difference between "encrypting a letter" and "verifiying that the person you give the letter to is who they say they are"
I guess if you did something weird like flip the protocol upside down such that all people would have "internet licenses" and enter them into the browser they're using at that moment (or better yet, lets charge each user $50/yr PER BROWSER LICENSE) and it became the sites problem to encrypt to the end users key... One way or another I think you have to verify the identity of at least one side WRT MITM?
All this change is meant to ensure is that all HTTP/2.0 traffic is encrypted, not that it is all authenticated. For authenticated communication, we continue to have what HTTPS is today.
The main issue is retraining people to not think that "https" means "safe". That's something that browsers are already good at, however, because there is already a world of difference between the user experiences of visiting a site with a trusted cert and visiting a site with an untrusted cert.
The practicality of enormous secret drag-net operations like the NSA has been running would decrease dramatically if TLS had been the norm rather than the exception, even with unverified certificates. You can't opportunistically MITM 100% of connections without somebody noticing.
It is a shame that cleartext connections have to be the out-of-the-box default in every web server. Security should be the default, and I think the CA mess is to blame for that not being the case.
The sane thing to do would be generating a random self-signed certificate if the administrator didn't set up any explicit certificates. That would prevent passive attacks, and can be built on top of with technologies like certificate pinning and Convergence to mitigate active attacks.
It would be nice if there were two kinds of connections. Encrypted unauth and encrypted auth. That seems strictly better than offering unencrypted connections. Your browser could still display the "wide open to attack" icon for encrypted unauth if you like.
The entire reason people think TLS should have "unauthenticated encryption" (which is in the literature kind of an oxymoron) is that they don't like the SSL CAs.
I don't like them either.
But the SSL CAs are a UI issue. Instead of dinking around with the browser UI to make worthless "unauthenticated encryption" sessions appear different, why not just build a UI for TACK, let people sign their own certificates if they want, but then pin them in browsers so those sites can rely on key continuity instead of nothing.
Five years from now, if TACK pinning becomes the norm, I think it's a safe prediction that basic TLS certificates will be free from multiple vendors. Moreover, the corruption of the CA system will matter less, because unauthorized certificates will violate pins and be detected; the CAs that issue them can be evicted.
While we're at it, why don't we just fix the UI for managing CA roots? It hasn't changed since the mid-1990s.
I am baffled by why anyone would actively promote an insecure cryptosystem as a cure for UI problems, or even as an alternative for some entirely new cryptosystem like MinimaLT.
The perfect is the enemy of the better.
This is a perfect example of <strikethrough>"good enough is the enemy of good"</strikethrough> "not completely broken in every possible way is the enemy of barely good enough" that is so prevalent in web security. If we don't use this chance we have now to secure internet traffic we will continue to be completely vulnerable to rogue WiFi AP like http://www.troyhunt.com/2013/04/the-beginners-guide-to-break... and to companies as well as countries snooping their employers/citizens traffic via huge proxies for years to come.
You want to connect to it securely, but the fridge really has no way to prove to you who it is through any kind of third-channel.
Hell, forget about fridges. It's the router you just got at Best Buy.
It's not that you don't know who the guy is, you just don't rely on a 3rd party to tell you that. See how SSH fingerprinting works.
If browsers would make it easier to "permanently accept" a self-signed certificate (right now it's usually a multi-step process with blood-red warning messages at every step) we'd have the same situation as SSH keys.
It doesn't, as a MITM prevention technique, for a gullible population. It doesn't even work for non-gullible population that's been trained to always hit "Y" on first connection from a host to a new server... err... I mean first connection to a MITM who then talks to the new server for you.
There are ways to make the situation slightly harder like the extremely unpopular idea of putting SSH host keys in DNS and then securing DNS ... err .. probably securing DNS via a CA type backend.... Well even unsecured DNS holding SSH host keys is better than nothing, or at least it makes people more susceptible because they feel safer, or something like that.
If it does happen, then the attacker will have to keep doing it forever, or else you'll get a warning the moment you manage to connect directly to the site without the MITM.
If your first connection is direct, then you're safe from MITM forever. If your first connection is compromised, then at least you'll likely discover that fact quickly.
I think this qualifies as "works".
It is much more secure to visit a site with a self signed certificate than to visit the site over http. And yet, browsers start flashing red when you do that. At the least, they should show red on http, yellow on self signed https, and green on trusted https.
One actual use case that could be solved in a better way than today would be login portals where a user have to be logged in to access the Internet.
Today, this is typically solved by issuing a redirect of some kind to the client (in the future, I guess it will receive a 511).
For HTTPS, the choices are a: Dropping the packets, ensuring extra costs in the support organizations when users wonder why their internet doesn't work. b: Doing a MITM and issue a redirect to the login portal that way.
Different operators choose different solutions here. Neither choice is good. Having a way of telling the client, that yes, while the connection is still encrypted, it didn't end up at the place it expected.
Might it be possible to add to TLS so that there are some way of issuing gateway redirect? Perhaps, perhaps not. I've seen precious little action in that area.
Personally, I would find great use for the authentication function of OpenSSH as a separate program. In other words, a program that does one thing only: it verifies an endpoint is who it says it is.
Newer info about fiber splitters invalidate that assumption.
Low-cost SSL brands like PositiveSSL and RapidSSL are so cheap nowadays, some registrars hand them out for free if you buy a domain. And they're compatible with every version of IE on Windows XP, unlike those free certs from StartSSL.
That's still a lot of devices.
In this case, that's also going away hard next year when Microsoft discontinues support for Windows XP. At that point it'd be really tempting to suggest switching to Firefox or Chrome, both of which do support SNI.
IPv6 has 128-bit addresses, which works out to about 4 billion ^ 4 addresses, not 4 billion ^ 4 billion addresses.
Not everything on the web is sitting on a well-known server.
Think about printers for a moment: now all the printers providing http interfaces need to include a way to install an organizational cert on them (at least for a lot of organizations). That means that there needs to be an out of band step in setup (and maintenance) to add the cert, or a way to do so from an http interface. The later just screams "giant security risk" for a dozen reasons.
Oh, really?
http://www.washingtonpost.com/world/national-security/nsa-in...
I've spent a lot of time recently working out how to securely allow a set of christmas tree lights with an embedded linux controller[1] with wifi connect via OAuth to your Twitter or Facebook account while being controlled from your phone. The lack of workable/affordable ways to have SSL keys on the device that your phone will trust makes life _very_ interesting - and getting the password-equivalent OAuth tokens into the device has been a fun challenge.
[1] Gratuitous self promotion - http://moorescloud.com/ go pre-order one now to justify getting UL certification so we can sell 'em in North America! _Please!_ ;-)
This is false. Good security is layered security.
How on earth do you make such an argument make sense?
Services that really need an unlimited number of subdomains are a tiny minority, and market prices reflect this. For the time being, someone like WordPress.com can probably afford $60-$100/year for a wildcard certificate. Everyone else just sticks to subfolders like Twitter does.
After all, nobody will be preventing you from running a website. Your priorities and economic circumstances might prevent you from using pretty subdomains, but that's no different from the current reality where short and memorable dot-com domains cost thousands of dollars.
This matter has nothing to do with the version of IE and everything to do with whether Windows root cert update is turned on.
With that http will be encrypted with no certificate check and https will still have the good 'ol check.
CA's are a single point of failure for security.
The CA never gets the private key. Instead they get a certificate signing request (CSR), which only contains the public key part. They sign that.
Oh, and then there is perfect forward secrecy, which basically means that even the servers private key is not the one used to encrypt the actual data (after the initial handshaking, and only for suitable cipher suites, subject to downgrade attacks).
Disclaimer: at least, thats how its properly done. Some CAs offer a "send us your cert and we'll sign it", and dumb people who shouldn't be admins use it because it's (slightly) easier to use.
But you got the conclusion right, the notion of CAs is problematic.
This is what kills CA security. Anyone at a employer with over 5 people in the IT dept probably has someone who can insert a CDROM but has no idea how to set up CA and SSL stuff installing intranet internal servers using https and a self signed cert.
So we're carefully raising a whole generation of users programmed to accept any self signed cert, after all "thats how the benefits website is at work" or "thats how the source code mgmt site is at work". Then they go home, and oddly enough their bank presents a new self signed cert, or at least they think its their bank, and much as they have to click thru 10 times a day at work, they click thru the same popup at home and then enter their uname pword and ...
Paradoxically as a budget weapon its excellent because you probably have good enough physical security at work and frankly its usually not something worth protecting anyway, but it is incredibly annoying so you can bring up at budget meetings that IT can't afford to fix the SSL cert errors on some meaningless server because they can't afford it, etc. Not technically true but J Random MBA managing something he knows nothing about, can't figure it out, so its a great budget weapon. Highly annoying but doesn't really hurt anything.
To fix this you'd need something like an enterprise programers union standard union contract rule that enterprise programmers will never, ever, ship enterprise software that allows a self signed key. Good luck defining enterprise software, I suppose.
And in the spirit of idiot proofing leads to better idiots, requiring no self signed keys means idiots will create their own root and train users to import any root they ever see anytime they see one. Then distribute a non-self signed key signed by the imaginary "Innitech CA services" root. What could possibly go wrong with training users to do that?
In fairness if you have a heterogeneous network of legacy windows, some macs for real work, legacy blackberry and both real smartphones, distributing it "everywhere" can get kinda hard.
If you want pinning, there are better solutions: http://patrol.psyced.org/
CAs will always be able to MITM you. Like I said: "the notion of CAs is problematic."
There are two caveats:
1) certificate pinning: your browser has a hard-coded list of certificates for all major websites (e.g. Chromium: https://code.google.com/p/chromium/codesearch#chromium/src/n... (scroll down!))
2) there are add-ons (ie Certificate Patrol) that warn you when the certificate changes
Live within their means, or it will cost you $25 (because of "revocation costs").
StartCom are pretty awesome, but be aware of potential pitfalls.
To quote them:
"Class 1 certificates aren't revoked free because we receive too many requests daily (specially for the Class 1 free certs) and would we have revoked them all, our certificate revocation list (CRL) would have been blown out of every proportion."
In a further back-and-forth, the admin proceeded to tell me how much bandwidth I would cause them (I don't even care about being added to a CRL for a personal domain).
Edit: Sorry, you did say a wildcard cert, which sounds like a paid cert, so would offer more "service" I'm guessing.
1 - Not an NSA joke, more that "hey, voter registration and property tax rolls are public and online; you could just verify that, no?"
http:// is encrypted but performs NO certificate check.
https:// is encrypted but performs a certificate check.
Done.
The problem is how to get those certificates and be sure they are the right ones. The problem was already solved in the pre-Internet world: letterhead, signatures and postal mail.
Trustworthy commercial entities could really distribute their certificates in paper form (or maybe on a business card) as an official document. Customers then scan these into their computing devices and, if they choose, sign them.
I doubt that anyone is pushing HTTPS based on the authentication function. It is the need for encryption that is probably the impetus.
Is it a problem?
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.
I would assume that you pay more than $100/y (which is expensive for a domain validated SSL cert, btw) unless you're using a free hosting provider at which point it's not your decision what protocol to use anyways.
No, it wont let me run a multi-million user site, but that's not my aim, nor should it be needed to let people new at the game fool around.
Putting the bar higher and higher to just being able to fool around is so utterly the wrong way to go.
I wonder if anyone on this site remembers what is was like to be 8 years old and already being able to program your first program on your TRS-80 or Commodore 64.
No money needing to be spent, no need to seek permission. Just hack. Get immediate, direct feedback. Instantly gratifying. That appraoch gave us a generation of computer-professionals unlike any other. Why are we so eager to put the road-blocks on now?
that means you pay for your internet connection and for the hardware you run the website on. Why is also paying for a certificate a problem?
I get the hobbyists approach, but especially for hobbyists I think it's better to stay with HTTP/1.1 which, as a plain text protocol is a lot easier to learn than the complicated ugly mess of HTTP/2.0. Also because of the SSL requirement, development will probably never happen over HTTP/2.0 - or do you want to create or even purchase new certificates for all your development projects?
A HTTP/1.1 server is something normal people can implement.
A HTTP/2.0 server is something for others to implement and a pain to debug.
I see HTTP/2.0 as a new transport protocol to transmit what we know as HTTP/1.1. None of the request/response semantics has changed between 1.1 and 2.0 (minus server push, but if you want to support older clients, you'd have to use other techniques anyways).
If you're just running your own little page, nothing is stopping you from using HTTP/1.1. Once your site is big enough to actually benefit significantly from HTTP/2.0, you will have the money for a certificate.
It's the latency for your clients you can shrink with 2.0, but you'd get bigger benefits from moving off hosting on a cable modem than by moving to 2.0. At that point, you'll have other, bigger costs to pay than the certificate.
Because the internet access and the hardware would have been bought regardless of the activity, for other purposes. (S)he was already paying for it, and used it for other purposes. Running a web site _happens_ to be one of its use, but is not the one goal. The fact that it is free to run a web site means that I can run my website on my laptop.
On the other hand, the certificate would have to be bought _only_ for this, because it is its only use: be able to play the HTTP/2.0 game.
The internet is no longer predominantly a hobbiests' playground and hasn't been in some time. Mainstream success leads to this sort of transformation by definition.
Are you kidding? Just a few decades ago you would need to pay a lot for machine time to be able to use computer. Today you can sit near a cafe with a $200 netbook and have a free internet access. In the 90's a .com domain cost ~$100. Just a few years ago TLS certificate cost close to the hundred, today you can buy one at around $10 per year or sometimes get it for free.
You have 10mbps connection! At your home! How much do you pay for it?
The thing is you are both missing the point:
The tech landscape is growing increasingly complex. We shouldn't be adding more obstacles to getting involved than we already have.
That's how horrible Legacy-things get built. We don't need to do that to our internet.
http://www.reddit.com/r/technology/comments/1qj1tz/http_20_t...
So now it's NO choice after all. If you want to run a "real" site, not only must you pay rent for your DNS, you are now also being extorted into paying money to CAs. CAs which can be subverted by the NSA, so they're effectively worthless anyway.
That's a bad move. Internet should be getting cheaper, not more expensive.
This whole HTTP 2.0 affair is turning into a real piece of extremely short-sighted shenanigans. Given W3C's green-light on DRM in HTML, we should start questioning if we want to entrust them with these sort of tasks in the future. They have gone completely off the rails.
And, again, HTTP 2.0 has nothing to do with CA prices.
I hope you understand it's mbit. If so, I've got 50mbps over here and I pay €50 (that's about $67 USD) per month, which includes 50 TV channels and interactive TV (I'm Dutch, I hope I described it correctly)
The situation (s)he describes is fairly common; I've got a Raspberry Pi and an old laptop running as servers over here, on which I do experiments and host small websites. They've got StartSSL certs, which suck, but they do their job at least. If you put enough effort in the process and not just blindly fill in the forms, you'll get there.
Did you think typing source code from a magazine (which they didn't carry in your home town because nobody else was interested) wasn't a roadblock or barrier?
Waiting to have access to the family TV so you could plug in your microcomputer? Or saving up to buy a second-hand 12" TV set so you could use it in the bedroom? Paying $1500 (in inflation adjusted dollars) for a Commodore 64 was a pretty big barrier.
If none of those were barriers for you, then I'm sure your parents would have sprung the cash for an SSL certificate.
And if none of those float your boat, you can always self sign if your willing to put up with the warning messages.
Your argument seems extremely hyperbolic.
I predict that https only http/2 will be doomed.
We are also "stuck" on IPv4 which hasn't been a problem.
Some sites may stick with 1.1 for a while, but my guess is there will be a ton more sites who will be adopting HTTPS because of this.
(hint: in most of the design options there wouldn't be CAs unless you used the https url scheme. See other messages in the linked thread too)
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.
But, if you choose a well-established CA, I believe that the risk of fraudulent certificate is small enough to be accepted. Besides, how many cases of fraudulent certificates have been there? Very few actually, relatively speaking, when measured against millions of issued certificates every year.
The current arrangements where CAs are able to issue certificates for arbitrary sites without owners' consent is clearly unsatisfactory. Hopefully we'll get key pinning abilities one day to improve the situation.
At the end of the day, security is hard. The arrangement with public CAs is flawed, but we don't yet have a better solution that scales. For small (close) groups, a private CA with manual user pinning should work well enough, when deployed with HTTP Strict Transport Security.
That's exactly what this proposes!
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.
If implmentations ended up keeping some meaning for them, you could look at how most ssh server keys are generated - no configuration.
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
So this is not solving the problem, this is moving it elsewhere.
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.
- 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/
> Convergence is based on the ideas originally developed by the Perspectives Project at Carnegie Mellon University.
We (Qualys) are running several notaries and are part of the default configuration, and we're seeing very little traffic.
- 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.
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.
And to those bringing up the tired, old rebuttal of this providing "worse" security due to a false sense of protection: that's only relevant if the browser is written idiotically and suggests this is in some way the same security as the fully-authenticated version. They should not be showing a "closed padlock" and changing the address bar color for self-signed SSL!
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.
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.
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.
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."
Reverse proxies, in front of web applications will need to terminate the SSL before caching. Same as today.
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.
* 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.
Most clusters of linux boxes I've admined I end up with a dedicated APT proxy on one machine, not a generic http network level proxy. The proxy I use has varied over time but at this moment I'm mostly using the approx package.
I wonder if transparent proxy caches are a thing of the past now?
I think developing some sort of proxy discovery protocol and making it clear to users that their connection is proxied is a much better way forward.
Basically the problem is that the encryption possibilities available assume Internet is a dumb pipe between source and destination, but that is simply not the case.
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!
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.
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.
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.
SSL has a significant number of required packet exchanges at startup, so latency for small objects is much larger; this is especially noticeable if there's a high round trip time between the client and server. SSL blocks proxy caching. The CA situation isn't great; especially if you're supporting older mobile clients, which basically never update their root certs. Debugging is harder (and HTTP/2 already gets complaints about that)
This is improving, however – see e.g. http://www.igvita.com/2013/10/24/optimizing-tls-record-size-...
> SSL blocks proxy caching
This is only true for involuntary transparent proxying, which is also a huge source of reliability problems. After seeing how many times JavaScript is broken or images are degraded by "helpful" ISPs I'm quite happy to change the model to something which requires the client to opt-in to enable a proxy.
That's interesting (and I'll try to apply it where i'm running SSL), but what I'm more worried about is the very beginning of the connection. http://chimera.labs.oreilly.com/books/1230000000545/ch04.htm... SSL adds two extra round trips, which doubles the latency of a small request. This is really unfortunate when you're in a high latency environment already.
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.
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.
Globalsign has even developed a special service for those cases (https://www.globalsign.com/cloud/).
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:// 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:// URIs and if you want to use the newest version of HTTP."
See http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/...
Personally, I am against this, as I feel that this is a choice that should be made on a site by site basis.
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).
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....
Personally, I'd rather make life harder for the pervasive eavesdroppers and the semi-skilled attackers.
It's worth noting that in such an environment, he likely controls the client machines themselves (ie, only corporate machines on the corporate network), so it's straightforward to just push out a trusted Certificate Authority and intercept anyways.
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)
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.
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.
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?
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.
<I'll save my rant for why I hate HTTP 2 for another time>
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.
HTTP 2.0 is the standardized version of SPDY.
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.
Most people don't understand that a href needs to be absolute or how to easily fix it.
more likely legacy pages will remain HTTP/1