Slashdot Mirror
HTTP 2.0 May Be SSL-Only
An anonymous reader writes "In an email to the HTTP working group, Mark Nottingham laid out the three top proposals about how HTTP 2.0 will handle encryption. The frontrunner right now is this: 'HTTP/2 to only be used with https:// URIs on the "open" Internet. http:// URIs would continue to use HTTP/1.' This isn't set in stone yet, but Nottingham said they will 'discuss formalising this with suitable requirements to encourage interoperability.' There appears to be support from browser vendors; he says they have been 'among those most strongly advocating more use of encryption.' The big goal here is to increase the use of encryption on the open web. One big point in favor of this plan is that if it doesn't work well (i.e., if adoption is poor), then they can add support for opportunistic encryption later. Going from opportunistic to mandatory encryption would be a much harder task. Nottingham adds, '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.'"
otherwise this sounds like extortion from CAs
I predict that the Unknown Powers will convince the committee to bail out and either (a) drop this idea overall (b) default to some old broken/flawed crypto protocol. Check back in 1 year.
My first program:
Hell Segmentation fault
People think that adding encryption to something makes it more secure. No, it does not. Encryption is worthless without secure key exchange, and no matter how you dress it up, our existing SSL infrastructure doesn't cut it. It never has. It was built insecure. All you're doing is adding a middle man, the certificate authority, that somehow you're supposed to blindly trust to never, not even once, fuck it up and issue a certificate that is later used to fuck you with. www.microsoft.com can be signed by any of the over one hundred certificate authorities in your browser. The SSL protocol doesn't tell the browser to check all hundred plus for duplicates; it just goes to the one that signed it and asks: Are you valid?
The CA system is broken. It is so broken it needs to be put on a giant thousand mile wide sign and hoisted int orbit so it can be seen at night saying: "This system is fucked." Mandating a fucked system isn't improving security!
Show me where and how you plan on making key exchange secure over a badly compromised and inherently insecure medium, aka the internet, using the internet. It can't be done. No matter how you cut it, you need another medium through which to do the initial key exchange. And everything about SSL comes down to one simple question: Who do you trust? And who does the person you trusted, in turn, trust? Because that's all SSL is: It's a trust chain. And chains are only as strong as the weakest link.
Break the chain, people. Let the browser user take control over who, how, and when, to trust. Establish places in the real world, in meat space, in bricks and mortar land, where people can go to obtain and validate keys from multiple trusted parties. That's the only way you're going to get real security... otherwise you're going to be taking a butt torpedo stamped Made At NSA Headquarters up your browser backside. And pardon me for being so blunt, but explaining the technical ins and outs is frankly beyond this crowd today. Most of you don't have the technical comprehension skills you think you do -- so I'm breaking it down for you in everyday english: Do not trust certificate authorities. Period. The end. No debate, no bullshit, no anti-government or pro-government or any politics. The system is inherently flawed, at the atomic level. It cannot be fixed with a patch. It cannot be sufficiently altered to make it safe. It is not about who we allow to be certificate authorities, or whether this organization or that organization can be trusted. We're talking hundreds of billions of dollars in revenue riding on someone's word. You would have to be weapons grade stupid to think they will never be tempted to abuse that power -- and it does not matter who you put in that position. Does. Not. Matter.
#fuckbeta #iamslashdot #dicemustdie
We save about 10% of our Internet bandwidth by running all http traffic through a caching proxy. This would seem to prevent this bandwidth saving for things that just don't need encryption. This would be any public site that is largely consumable content. All in favour of it for anything more personal.
Also how are companies supposed to effectively web filter if everything is HTTPS. DNS filtering is, in general, too broad as brush. We may not like our web filtered, but companies have a legal duty that employees shouldn't be see questionable material, even if on someone else's computer. Companies have been sued for allowing this to happen.
If there is, I do not see it. Strikes me as people that cannot stop standardizing when the problem is solved. Pretty bad. Usually ends in the "Second System Effect" (Brooks), where the second system has all the features missing in the first one and becomes unusable due to complexity.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
StartSSL was without charge for individuals the last time I checked. The most expensive part of SSL nowadays for a small site operated as a hobby is the dedicated IP address that you need if you want users of IE on Windows XP and Android Browser on Android 2.x to be able to access your site. These browsers don't support SNI, which allows name-based virtual hosting to work on SSL.
(I the user) am the one who should be purchasing trust from a vendor. A vast network of obviously compromised cert vendors should not be in my browser. They don't work for me so why are they even mentioned in my browser? There should be just one: The one I have chosen to trust. The one I pay to trust and will go out of business if they ever break the trust of their customers.
Frankly, I would prefer the trust vendor to be the same as the browser vendor. I am trusting them both, so I would rather they be the same thing.
The problem is that all http clients see 'https' as meaning the client has a level of expectation about 'security'. Browsers have long started to do things to very obvious to denote 'good ssl' from 'bad ssl', but the expectation remains that 's' means 'meaningfully secure'.
So how best to convey 'encrypted, but don't really care about third party cert validation', which would be a must-have in a world where *every* public facing site has a TLS protected socket. Maybe a different uri scheme like 'httpe://', complete with the scare strikethroughs and such, but not with the 'are you sure, are you really really sure' that https does today...
XML is like violence. If it doesn't solve the problem, use more.
You are still relying upon a third party to attest to your identity. In the DNS case, your DNS provider takes over the role of signing your stuff, and they can 'extort' you too.
XML is like violence. If it doesn't solve the problem, use more.
If http:// will fall back to HTTP 1.0, how does that make the Internet a more secure place? Will the users actually care that the page is being served by an older protocol, enough to type it again with https? Will they even notice?
This is already a pain in the ass for me. I use a local proxy/filter (Proxomitron) to allow me to filter my HTTP streams for any application w/o having to configure them individually - or in cases where something like AdBlock would be browser specific. This doesn't work for HTTPS.
For example, Google's switch to HTTPS-only annoys me to no end as I use Proxomitron to clean up and/or disable their various shenanigans - like the damn sidebar, URL redirects, suggestions, etc... At this time using "nosslsearch.google.com" with CNAME of "www.google.com" works to get a non-encrypted page (in Proxomitron, I simply edit the "Host:" header for nosslsearch.google.com hits to be www.google.com) but who know how much longer that will last.
Thankfully, DuckDuckGo and StartPage allow me to customize their display to my liking w/o having to edit it on the fly. If only Google would get their head out of the ass and support the same, rather than only allowing their definition of "enhanced user experience".
Seriously, do we really *need* HTTPS for everything - like *most* web searches, browsing Wikipedia or News? I think not.
It must have been something you assimilated. . . .
If everything is to go SSL, we now need widespread "man-in-the-middle" intercept detection. This requires a few things:
I think HTTP/2 should resist the temptation to concern itself with security, concentrate on efficiently spewing hypertext and address security abstractly and cleanly at a separate layer from HTTP/2. Obviously as with HTTP/1 there are some layer dependencies but that is no excuse for even having a conversation about http vs https or opportunistic encryption. It is the wrong place.
Things change who knows some day someone may want to use something other than TLS with HTTP/2. They should be able to do so without having to suffer. Not respecting layers is how you end up with unnecessarily complex and ridged garbage.
For example who is to say there is no value in HTTP/2 over an IPsec protected link without TLS?
Why not separate the "here is proof I am who I say I am" from "let's encrypt our conversation"? Web servers could easily use self-generated random certs to encrypt traffic. If you want to validate you are who you say you are, then you add a cert from a "trusted" CA to do just that. It's no different that what we have today with HTTP vs HTTPS. If I go HTTP to a site I have no assurance that they are who they say they are. At least this way the traffic is encrypted even at the lowest trust tier.
I browse on +1 so AC's need not respond, I won't see it.
Why not separate the "here is proof I am who I say I am" from "let's encrypt our conversation"?
Because if you aren't authenticating, you're encrypting to the man in the middle.
If I go HTTP to a site I have no assurance that they are who they say they are.
When the scheme is HTTP, you have no expectation of assurance.
This problem was solved by Phillip Zimmerman, the creator of PGP... in the late 90s.
Yeah, I expected someone to mention the PGP web of trust. But here's something I don't understand: just because I met Aeris at a key signing party and verified her identity at a key signing party doesn't necessarily mean I feel confident in vouching for her diligence in verifying other people's identities or especially the diligence of the other people whose identity she verified.
Seven degrees of separation
It's like playing a game of telephone.
No it does not, the only proxy that can cache will be a proxy you trust (or preconfigured in your browser by your employer on the computer of your employer).
New things are always on the horizon