HTTP 2.0 May Be SSL-Only 320
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.'"
Only if I can use self signed certs (Score:5, Insightful)
otherwise this sounds like extortion from CAs
Re:Only if I can use self signed certs (Score:5, Interesting)
In the similar thread on Reddit, someone mentioned RFC 6698, which uses DNS (with DNSSEC) to validate certificates, rather than CAs. If we could make both of them a requirement, that'd fit the bill and get rid of the extortion.
Still extortion... (Score:3)
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.
Re: (Score:3)
Unless I run my own DNS, which is far easier than running a CA.
Re: (Score:3)
Unless I run my own DNS, which is far easier than running a CA.
Not if you are using DNSSEC, it isn't. You talk about running your own DNS under those conditions as though a self-signed cert doesn't require a CA; it does. There's no such thing as certs without a CA. So, we're back to the "extortion" challenge again...either you run your own CA or are forced to pay someone else so that you can have a cert from theirs. I will say that at least the DNSSEC approach gets rid of the situation where any CA can give out a cert that would impersonate the valid one. In oth
Re:Still extortion... (Score:5, Informative)
Unless I run my own DNS, which is far easier than running a CA.
Not if you are using DNSSEC, it isn't. You talk about running your own DNS under those conditions as though a self-signed cert doesn't require a CA; it does. There's no such thing as certs without a CA...
DANE (DNS-based Authentication of Named Entities) RFC6698 does NOT require the use of a recognized CA, although it does not disallow it. There are four "usage" types for certificates (excerpts from the RFC follows):
Both Certificate usage 2 and Certificate usage 3 allow a domain's administrator to issue a certificate without requiring the involvement of a third party CA. For more information on DANE, refer to either rfc6698 [ietf.org] or the the wikipedia article [wikipedia.org].
Re:Still extortion... (Score:5, Insightful)
You're confusing "CA" with "third party CA." You need a CA to have a certificate. Hint: the "C" in "CA" stands for "Certificate."
You are confusing a certificate with a certificate which most users trust (aka a Certificate Authority). A root certificate from a known Certificate Authority (i.e. an organization) is just a self signed certificate which is trusted by a large group of users. You need to have a certificate to have a CA, a CA without a certificate is well, useless.
The certificate usages 2 and 3 in the DANE specification should work with a self-signed X.509 cert and thus work without needing to involve a recognized CA, third-party CA, formal CA, or what ever you choose to call it.
I mean, I guess you could just open an editor and type something out that looks like a certificate pair, but it won't be mathematically usable, and it won't work when you try to do a Diffie-Hellman key exchange with it :)
Was this even suggested or are you trying to make yourself appear more intelligent by refuting an unmade claim which is condescendingly absurd?
Re:Only if I can use self signed certs (Score:5, Interesting)
My predictions:
- TLS will be required. No bullshit, no compromise, no whining. On by default, no turning it off.
- RFC6698 DNSSEC/DANE (or similar) certificate pinning support required.
- DANE (or similar) to authenticate the TLS endpoint hostname via DNSSEC - that is the MITM defense, not a CA
- CA not required - if present, authenticates ownership of the domain, but not whether there's an MITM
We have a shot at a potentially clearer hierarchy with DNSSEC than we do with CAs, where it's anything-goes, anyone can sign anything - and to state-sponsored attackers, clearly have, and do (whether they know it or not). We might need to fix DNSSEC a bit first, along the lines of TLS 1.3 (see below).
Also, TLS 1.3 ideas are being thrown around. It will be considerably revised (might even end up being TLS 2.0, if not in version number then at least in intent). Here are my predictions based on what's currently being plotted:
- Handshake changed, possibly for one with less round-trips/bullshit
- Cipher suites separated into an authentication/key exchange technique and an authenticated encryption technique (rather than the unique combination of the two)
- Renegotiation might not stay in or redesigned?
- Channel multiplexing?
- MD5, SHA-1, and hopefully also SHA-2 removed, replaced with SHA-3 finalists: Skein-512-512? Keccak-512 (as in final competition round 3 winner, but hopefully NOT as specified in the weakened SHA-3 draft)?
- Curve25519 / Ed25519 (and possibly also Curve3617) for key exchange and authentication: replace NIST curves with safecurves
- RSA still available (some, such as Schneier, are wary of ECC techniques as NSA have a head start thanks to Certicom involvement and almost definitely know at least one cryptanalysis result we don't), but hardened - blinding mandated, minimum key size changed (2048 bit? 3072 bit? 4096 bit?)
- PFS required; all non-PFS key exchanges removed; Curve25519 provides very very fast PFS, there's very little/no excuse to not have it
- All known or believed insecure cipher suites removed. (Not merely deprecated; completely removed and unavailable.)
- Most definitely RC4 gone, beyond a doubt, that's 100% toast. There may be strong pushes for client support for RC4-SHA/RC4-MD5 to be disabled THIS YEAR in security patches if at all possible! It is DEFINITELY broken in the wild! (This is probably BULLRUN)
- Possibly some more stream cipher suites to replace it; notably ChaCha20_Poly1305 (this is live in TLS 1.2 on Google with Adam Langley's draft and in Chrome 33 right now and will more than likely replace RC4 in TLS 1.2 as an emergency patch)
- AES-CBC either removed or completely redesigned with true-random IVs but using a stronger authenticator
- Probably counter-based modes replacing CBC modes (CCM? GCM? Other? Later, output of CAESAR competition?)
- The NPN->ALPN movement has pretty much done a complete 180 flip. We will likely revert to NPN, or a new variant similar to NPN, because any plaintext metadata should be avoided where possible, and eliminated entirely where practical - ALPN is a backwards step. IE11 supports it in the wild right now, but that can always be security-patched (and it WILL be a security patch).
Of course, discussions are ongoing. This is only my impression of what would be good ideas, and what I have already seen suggested and discussed, and where I think the discussions are going to end up - but a lot of people have their own shopping lists, and we're a long way from consensus - we need to bash this one out pretty thoroughly.
Last week's technical plenary was a tremendous kick up the ass (thanks Bruce! - honestly, FERRETCANNON... someone there reads Sluggy Freelance...). We all knew something had to be done. Now we're scratching our heads to figure out what we CAN do; as soon as we've done that, we'll be rolling our sleeves up to actually DO it. After consensus is achieved, and when the standard is finished, we'll be pushing very, very strongly to get it deployed forthwith - delays for compatibility because of client bugs will not be an acceptable excuse.
Re: (Score:2)
My predictions:
It don't matter. The NSA will simply require the root certs of all CAs and make all this work moot.
Re: (Score:3)
Having access to root CA private keys doesn't help the NSA much if PFS is employed.
Re:Only if I can use self signed certs (Score:4, Interesting)
If we use DNSSEC to pin a chain of trust all the way to the root, we have, hopefully, authenticated that certificate to its hostname. That, alone, mitigates an MITM, and it is even within scope of the DNS hierarchy
Contrast: CAs have a flat, global authenticative fiat - therefore, they are fundamentally less secure, as instead of multiplying with the depth of hierarchy, the potential weaknesses multiply with the number of commonly-accepted CAs.
Of course, you can then (optionally) also choose to use a CA to countersign your certificate in a chain, if you want; presumably you pay them to certify who owns the domain.
In the event of any disagreement, you just detected (and therefore prevented) an active, real MITM attack. An attacker would have to subvert not just a random CA, but hierarchically the correct DNS registry and/or registrar -and- a CA used to countersign, if present. We can make that a harder problem for them. It increases the cost. We like solutions that make a panopticon of surveillance harder - anything that makes it more expensive is good, because hopefully we can make it prohibitively expensive again, or at least, noisy enough to be globally detectable.
There's also the separate question of the US Government holding the DNS root. Someone has to. Obviously it can't be them anymore. Even if we saw it, we can no longer trust it.
We are also welcome to potential more distributed solutions. If you happen to have a really nice, secure protocol for a distributed namespace (although please something that works better than, say, NameCoin), please publish.
Re: (Score:3)
Actually, it would still help. There's a huge difference in resource requirements between listening in on a connection and doing a MITM for it. Mass surveillance is only possible because modern technology makes it cheap; every speedbumb, no matter how trivial, helps when it applies to every single connection.
Re: (Score:3)
- MD5, SHA-1, and hopefully also SHA-2 removed, replaced with SHA-3 finalists: Skein-512-512? Keccak-512 (as in final competition round 3 winner, but hopefully NOT as specified in the weakened SHA-3 draft)?
The SHA-2 family are still unbroken, and I don't believe there are even any substantial weaknesses known. No reason to drop support for them at all.
Re: (Score:3, Interesting)
We do not want to fragment the internet, but this enormous subversion of trust already threatens it. Last week's technical plenary's hums clearly (overwhelmingly, even unanimously) agreed that what is happening - massive, state-sponsored surveillance - is an attack on the Internet as a whole. Clearly the US government (not the only attacker, but the biggest) appointing IANA is a conflict of interest. That is not even a point of debate anymore.
Bruce actually openly pointed this out during the prior talk: "..
Re:Only if I can use self signed certs (Score:5, Interesting)
Except for this nagging problem that DNS, and DNSsec, is still hierarchical and thus we still have single points of extortion, with as ultimate root... the US government.
The DNS system by nature has a single root, the trust chain doesn't necessarily have that. You could for example require that all TLDs be signed with the keys of the five permanent members of the UN security council and require all of them to be present. So Canada would own the keys to the ".ca" domain and they would be signed by the US, Russia, China, UK and France. Canada gets to do whatever they want under their domain and nobody can spoof them unless they a) steal Canada's private keys or b) steal all the other five private keys. Of course the tin foil hat brigade don't trust any authority and that's fine, you can always check the fingerprint. But I don't see how it hurts your security to have the ".com" server certifying that you own "yourdomain.com" versus a totally self-signed certificate with yourself as CA. At worst it's no trust vs no trust.
As for being "blackmailed", well if they're being nasty they're already holding all your traffic hostage (except direct IP access). The base certificate "owner of yourdomain.com" should be free with the DNS service, if you want something to actually certify who you are that's different. Really it's nothing more than the service they're doing already with DNS and DNSSEC, making sure that they're pointing you to the right server.
Re:Only if I can use self signed certs (Score:4, Interesting)
The SPKI guys back in the 90s figured this stuff out really, really well. Ideally, one would have: a DNS trust chain indicating that b24e:6f99:2f6f:34d8:9c8a:c6da:daaf:e3bb:002e:2ba4:2622:4cf9:cd8b:14a5:71d8:5a9c:18dc:47a2:9a2d:2951:a26b:26fa:2165:85fc:7006:0d66:1c8e:a4f4:ea36:4d04:57a0:8ae4 speaks on behalf of owns example.net; an IP trust chain indicating that b24e:6f99:2f6f:34d8:9c8a:c6da:daaf:e3bb:002e:2ba4:2622:4cf9:cd8b:14a5:71d8:5a9c:18dc:47a2:9a2d:2951:a26b:26fa:2165:85fc:7006:0d66:1c8e:a4f4:ea36:4d04:57a0:8ae4 speaks on behalf of the owner of 192.0.2.7, and possibly certifications from other organisations (Better Business Bureau perhaps) that b24e:6f99:2f6f:34d8:9c8a:c6da:daaf:e3bb:002e:2ba4:2622:4cf9:cd8b:14a5:71d8:5a9c:18dc:47a2:9a2d:2951:a26b:26fa:2165:85fc:7006:0d66:1c8e:a4f4:ea36:4d04:57a0:8ae4 speaks on behalf of a decent dude; users' browsers might demand the first two and show more confidence for further certifications.
SPKI's contributions included a k-of-n standard and, more importantly, transitive authorisations. So once I am granted authorisations from .com to use example.com, I can pass that authorisation on to any machines under my control; I can delegate mail.example.com to my mail-handling group without also giving them financials.example.com. I can do the same thing with my IP address space, my bank account information &c. I could add third-party attestations to my identity, perhaps third parties more resistant to rubber-hose persuasion than the standard ones. Pinning might rely on my personal closely-held private key, which is never online at all but which delegates to online (time-limited and/or revocable) keys. Calculating this stuff is very, very simple and fast. There's no need for any fees along the way. It's easy to reason about.
You can see how this might work with internet governance: each organisation would be responsible for the namespace it was assigned, and be easily able to segment that namespace however it wished. Anyone at any level could cross-certify; damage to the trust chains could be contained.
SPKI is, in every way save uptake, superior to XPKI.
Re: (Score:3, Insightful)
Downside with self signed certs is that you get that pop up warning about trusting the cert. For HTTP 2.0 to take off and require SSL (which is a good idea) there needs to be cheap access to valid certificates. Right now, the most reputable SSL vendors are way too expensive.
StartSSL (Score:5, Informative)
Re: (Score:2)
Re: (Score:3, Insightful)
Something tells me that attrition will solve the problem of Android 2.x devices and Windows XP boxes long before HTTP 2.0 is finalized. It'll be the same non-problem as the fact that I can't get a decent HTML 5 browser on my Windows 3.1 machine.
Re: StartSSL (Score:2)
Usability issue, not hard technical one... (Score:5, Insightful)
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...
Re: (Score:3)
This is just a matter of changing the way the URI is displayed:
NOT ENCRYPTED http:/// [http]
ENCRYPTED, NOT VERIFIED https:/// [https]
ENCRYPTED, VERIFIED https:/// [https]
With a helpful little blurb that explains (with pictures) the differences. I'm sure with some thought and a few user trails you could come up with a UI solution that most people will be able to understand well enough to know that credit card stuff should be green and that pink is better than red.
Re: (Score:3)
I think the green versus not green covers that. IMO, anybody who doesn't have an EV certificate probably doesn't really need a TLS certificate. For everybody else, storing the public key (preferably not a fingerprint—disk space is too cheap to cut corners like that) upon the user's first visit is sufficient security.
Of course, such a scheme would bankrupt the bloated SSL cert industry and their extortion racket, but I would argue that such an outcome would be progress.
Re:Usability issue, not hard technical one... (Score:4, Informative)
Normal people know that there's a difference between HTTP and HTTPS?
Re:Only if I can use self signed certs (Score:5, Insightful)
Yeah, because who cares that removing that warning allows anyone to pretend to be your bank?
Re: (Score:3)
So why not setup your own CA, install the CA into your computer/device and then use that to sign your certs.
Voilà, no more popup warnings.
Re: (Score:2)
The browser would only indicate a site was secure if the certificate was signed by a reputable certificate authority.
How many people do you think check their web browser claims the site is secure before entering their login details?
Removing warnings about self-signed certificates just gives a new way for users to do stupid things without thinking about it.
Re: (Score:2)
That's really the only thing stopping me from putting HTTPS stuff on my server, it's annoying as hell to have to keep clicking through that warning every time I start a new browser session.
Did you know that you can manually trust the certificate and avoid that dialog every time you visit your site?
Re:Only if I can use self signed certs (Score:5, Insightful)
This. If so, it will be a MASSIVE improvement.
A connection with a self-signed cert is, in a very-worst-case and highly unlikely scenario, only as insecure as the plaintext HTTP connections we use every day without batting an eye. Let's start treating them that way.
SSL-only would be a great first step in making life miserable for those NSA peeping toms.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Well just as now, you should make sure the site uses a trusted cert (through a CA or otherwise) before sending sensitive info. You don't send important logins or credit card info over plain HTTP now do you?
Re:Only if I can use self signed certs (Score:4, Informative)
You can check if the certificate is the same one the site produced last time.
Or go through a third party that confirms it is seeing the same certificate you are seeing.
Obviously not foolproof but these both approach the current security of the authority-signing.
Re:Only if I can use self signed certs (Score:4, Insightful)
The problem is that your browser trusted a non-trustworthy CA.
The problem is a lack of trustworth CAs in a world where governments want to spy on everyone.
Re: (Score:2)
Unsigned Certificate + TLS = you have an encrypted connection with someone, and you can't know who unless you independently verify the certificate signature. (e.g. My brother sets up a site with a self-signed certificate, and then calls me on the phone and tells me the certificate signature. When I access his site, I view the certificate and make sure the signature matches.)
Re:Only if I can use self signed certs (Score:4, Insightful)
otherwise this sounds like extortion from CAs
You are so close. Eliminating plain-http would destroy the internet as we know it because the only alternative then is forking cash over to an easily-manipulated corporation for the priviledge of then being able to talk on the internet. It's an attack on it's very soul.
It would kill things like Tor and hidden services. It would oblitherate people being able to run their own servers off their own internet connection. It would irrevocably place free speech on the web at the mercy of corporations and governments.
Re:Only if I can use self signed certs (Score:4, Interesting)
To be fair, no one is telling you to run your server on http 2.0. You can still run a gopher or ftp server, if the outdated technologies appeal to you enough.
(Please don't dog pile me for saying ftp is outdated, I know you're old and cranky, you don't have to alert me)
Re: (Score:3)
To be fair, no one is telling you to run your server on http 2.0.
The same can be said whenever a new version of a protocol comes out. But invariably, people adopt the new one, and eventually nobody wants to support the old one... and so while nobody is "telling you" anything... eventually you just can't do it anymore because all protocols depend on the same thing.. people using them. If nobody's serving content on them, then nobody's supporting the ability to read that content either.
(Please don't dog pile me for saying ftp is outdated, I know you're old and cranky, you don't have to alert me)
I am neither old, nor cranky. I am however an experienced IT professional who's been her
Re:Only if I can use self signed certs (Score:5, Insightful)
Wisdom is knowing that Jurassic Park is fiction, and that we contain wild animals in zoos all the time just fine
Re: (Score:2)
You're a well-known poster? Well excuse me. I didn't know.
But Jurassic Park was the natural thing to reply to, because it seemed intuitively and naturally related to your argument.(And I think an actual dinosaur zoo would be awesome).
Re: (Score:2)
In theory, yes. If tomorrow Chrome, Safari, IE, FireFox, etc all upgraded their browsers to require HTTP 2.0/HTTPS-Only, tons of websites would be faced with the prospect of paying hundreds of dollars for a SSL certificate. These hobby sites with no actual income wouldn't be able to afford it. Presently, to host a website I can pay for a $10 a month shared hosting plan and $15 a year for a domain name. (My registrar is a bit more expensive but I've had a lot of good experience with them so I'm not likel
Re: (Score:2)
You can buy a properly signed SSL cert for as little as $9/year (possibly lower), if that is too much then self signed is always available.
James
Re: (Score:2)
Validating the certificate is the problem. If it can't be validated then SSL is useless, it is open to a man in the middle [wikipedia.org] attack. The trouble with the current SSL system is that even a certifcate signed by a CA is spoofable; an CA can sign a certificate for any domain, so if you can twist arms stronly enough (think: NSA or well funded crooks) then you can still do a MitM attack. So: the first thing that is needed is a robust way of validating certificates -- I don't know how that could be done.
The other pr
Re:Only if I can use self signed certs (Score:4, Informative)
Check if it is the same certificate you saw when you visited the site the last time.
Go through a third party (perhaps one using a signed certificate) and check that you both see the same certificate.
Both of these will defeat a lot of man-in-the-middle attacks.
Re: (Score:3)
Re: (Score:3)
You've fallen into the trap of seeing security as either black or white. Self signed certs are dark gray enough that for you it's black, and thus the same as unencrypted HTTP. And CA verified cert is light gray enough to be white, and thus secure.
The truth is that self signed is much better than unencrypted, and CA verified - while even better - still have enough problems to drive a truck through. Sideways.
Which is why people are talking about DANE, which is even lighter gray than CA validated, but still fa
Betting one beer (Score:3)
Re:Betting one beer (Score:5, Insightful)
You can laugh at the IETF as much as you want, there are lots of things to laugh at. However, there are still a lot of very technical people involved in the IETF, and a large subset of them are finding it unpleasant that the Internet they helped create has become something very different. They are fighting the hard fight right now, and we should all support them when we can.
It is possible that the NSA or other similar dark forces may manage to subvert their intentions once more, but so far it looks like there is still hope for the good guys.
Or I may be hopelessly naive.
https:// available soon! (Score:2)
...or, you know, https everything now for starters, since the processing increase is negligible.
A lot of sites are already on board.
Re: (Score:2)
Processing is negligible, but cost is not. If you are an enterprise-level organization, you should definitely go HTTPS or at least offer that as an option. If you are a hobby site running on a shared server for $10 a month, you aren't going to be able to invest in a $150 SSL certificate.
Re: (Score:2)
Will that be more or less processing than HTTP/2 with https and ssl?
SSL only = no benefit (Score:5, Insightful)
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.
Re:SSL only = no benefit (Score:5, Insightful)
What are your thoughts on RFC 6698 [ietf.org] as a possible solution to the CA problem?
Re:SSL only = no benefit (Score:4, Interesting)
What are your thoughts on RFC 6698 as a possible solution to the CA problem?
I think that it's already been proving that centralizing anything leads to corruption and manipulation. Whether you put it in DNS, or put it in a CA, the result is the same: Centralized control under the auspices of a third party. Any solution that doesn't allow all the power to stay in the hands of the server operator, must be rejected.
How would you avoid MITM? (Score:2)
Re: (Score:3)
Encrypting to the man in the middle (Score:3)
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.
Trusting transitive trust (Score:3)
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 [wikipedia.org].
Re: (Score:2)
So your solution is?
not using anything 'cause the NSA is over you?
Saying that the CA system and the DNS(SEC) infrastructure are the same is retarded.
The CA system is managed by hundred of companies, and you can not possibly know if some company as an unauthorized certificate.
Want to know if someone is giving false information on DNSSEC? "dig domainname + dnssec" should be enough....
The current (DNSSEC) system has problems, but it is not as rotten as not having anything, so it's better than nothing. Plea
Re: (Score:2)
Except at the end of the day you have to trust *something* and
... And nothing. If you do not exchange keys over a secure medium, then it's exploitable. You don't need fancy protocol exploits... you just need to sit between two people and pretend you're the other guy to each. You people seem to be misunderstanding what 'secure medium' means. Everything else is a bandaid. You need a secure medium or it's shit.
Re: (Score:2)
Why is 6698 funny? The author was serious. Now 1149 [ietf.org]? That's funny.
Re: (Score:3, Insightful)
SSL has great key exchange mechanisms. Diffie-Hellman is the most common one, and with large enough groups and large enough keys it works very well. What works less well is the authentication bit, which is what the CAs are doing. But encryption with bad authentication, or even without authentication at all, is not worthless. It prevents passive surveillance, such as the one NSA, GHCQ and their ilk are perpetrating on hundreds of millions of internet users. Yes, you are vulnerable to man-in-the-middle attack
I agree. The idea is broken from the get go (Score:3)
(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 t
Re: (Score:2)
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.
No you don't want that. The browser developers should concern themselves with rendering the content correctly and standards-compliant, and the user-experience/interface. Separation of duties when it comes to money is paramount -- that's why you have outside accountants review your books, not internal ones. Otherwise you have the situation of creating a financial incentive to break or manipulate the system. Even one character, on one line of code, can change something from secure to exploitable. Don't tempt
Agreed (Score:2)
You are right. The two should remain separate, if for no other reason, then it will be easier to deprecate them individually if they screw up.
Re:SSL only = no benefit (Score:5, Interesting)
People think that adding encryption to something makes it more secure. 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.
techincally wrong. The key exchange is secure, the infrastructure managing the key trust is not trustworthy. Please do not mix the two.
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.
Lolwut? it *CAN* be done. Personally I'm working on an alternative of TLS with federated authentication, and no X.509. The base trust will be the DNSSEC infrastructure. Sorry but you got to trust someone. I know it's not perfect, in fact as soon as I'm finished with this project (Fenrir -- will be giving a lightning talk @CCC) I think I'll start working on fixing the mess that DNSSEC is. I already have some ideas. It will take some time, but it is doable.
No matter how you cut it, you need another medium through which to do the initial key exchange.
You keep confusing the key exchange algorithm and the base of the trust for your system... are you doing this on purpose or are you just trolling?
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.
And give each other trust in a hippie fasion... No, you need more than that, and why does it need to be the browser? if you have a way to manage trust, why only at the browser level?
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.
You keep talking about technical stuff and then you keep pointing at political and management problems... get your facts straight. You always make it seem as if the SSL protocol is broken per se. it is not.
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.
Well, I'm working at a solution! NO X.509, trust from DNSSEC chain. That's as trustworthy as you can get. I'll work at a replacement of the DNS system after this project is finished. Keep your ears open for the "Fenrir" project, I'll be presenting it at the European CCC, although it won't be finished by then. come and discuss if you are interested. Otherwise stop spreading useless fear. -- Luca
Re: (Score:2)
I would also add that, in practice, it's the third middle man. The second is the ISP.
You likely have downloaded the browser with the CA list from the net, has it been tampered with? You validate the download with checksum, gotten from the net, has it been tampered with? what about the package manager
Re: (Score:2)
Re: (Score:2)
But physical key exchange doesn't scale. You can't get a billion people that use desktop, laptops, tablets, or smart phones to understand how to do a physical key exchange or why it matters, let alone organize a practical way to get it done.
I don't know what
Re: (Score:2)
While you're right that there are issues with the certificate-based approach, it's not nearly as bad as you describe. There are solutions already implemented that mitigate much of the risk.
One example is certificate pinning. Google already pins all Google-owned sites in Chrome. This is actually how the DigitNotar compromise was discovered; Chrome users got an error when trying to get to a Google site.
Another example is SSH-style change monitoring, alerting users when certificates change unexpectedly. Th
Re: (Score:3)
You might call that a distinction without a difference, but I think it does matter.
Re: (Score:2)
We could start a political movement. Call it the Key Party.
Re: (Score:2)
Good call. If there's one thing republicans, democrats and independents; conservatives, liberals, and moderates can agree on it's that: sex with a complete stranger is the best.
What if, instead of declaring war on Iran, Barack Obama and Hassan Rouhani sat down, smoked a joint, then wife swapped? Throw in Biden and Netanyahu and you've got a gang-bang and a peace accord!
Can't you just picture them high fiving each other as they take turns busting a nut? Maybe they'd even do some double penetration. A
Re: (Score:3)
Wow, this thread just took a turn for the disturbing.
Company Caching Proxies and Filtering? (Score:4, Insightful)
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.
Session cookie copying (Score:2)
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.
Please define what you mean by "consumable content" [gnu.org]. If a user is logged in, the user needs to be on HTTPS so that other users cannot copy the session cookie that identifies him. This danger of copying the session cookie is why Facebook and Twitter have switched to all HTTPS all the time. Even sites that allow viewing everything without logging in often have social recommendation buttons that connect to Facebook, Twitter, Google+, or other services that may have an ongoing session.
Re: (Score:2)
This will require a lot of micromanagement by web developers, but could be possible for large sites. Also set
Re: (Score:2)
Re: (Score:3)
Also how are companies supposed to effectively web filter if everything is HTTPS.
They shouldn't. They should cut off web access for the grunts that don't need it (e.g. telecenter people who are using managed applications) and blow it wide open for those that do (engineers, creative professionals, managers). Hell, the managers are already opting out of the filtering and infecting their networks with porn viruses, so what would this change?
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.
Citation needed. Speaking of too broad a brush; this comment paints with a roller. I've only worked for one company that used WebSense, and that was a
How to qualify for a visa? (Score:2)
Is there any need for HTTP 2? (Score:3, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
Re:Is there any need for HTTP 2? (Score:5, Interesting)
Yes, there is a lot of need for HTTP 2.
HTTP was great when pages were largely just a single block of HTML, but modern pages include many separate resources which are all downloaded over separate connections, and have for a long time, actually. HTTP pipelining helps by reducing the number of TCP connections that have to be established, but they still have to be sequential per connection, and you still need a substantial number of connections to parallelize download. This all gets much worse for HTTPS connections because each connection is more expensive to establish.
HTTP 2 is actually just Google's SPDY protocol (though there may be minor tweaks in standardization, the draft was unmodified SPDY), which fixes these issues by multiplexing many requests in a single TCP connection. The result is a significant performance improvement, especially on mobile networks. HTTP 2 / SPDY adds another powerful tool as well: it allows servers to proactively deliver content that the client hasn't yet requested. It's necessary for the browser to parse the page to learn what other resources are required, and in some cases there may be multiple levels of "get A, discover B is needed, get B, discover C is needed...". With SPDY, servers that know that B, C and D are going to be needed by requesters of A can go ahead and start delivering them without waiting.
The result can be a significant increase in performance. It doesn't benefit sites that pull resources from many different domains, because each of those must be a separate connection, and it tends to provide a lot more value for sites that are already heavily optimized for performance, because those that aren't tend to have lots of non-network bottlenecks that dominate latency. Obviously it will be well-optimized sites that can make use of the server-initiated resource delivery, too.
Actually, though, Google has decided that SPDY isn't fast enough, and has built and deployed yet another protocol, called QUIC, which addresses a major remaining problem of SPDY: it's built on TCP. TCP is awesome, make no mistake, it's amazing how well it adapts to so many different network environments. But it's not perfect, and we've learned a lot about networking in the last 30 years. One specific problem that TCP has is that one lost packet will stall the whole stream until that packet loss is discovered and resent. QUIC is built on top of UDP and implements all of the TCP-analogue congestion management, flow control and reliability itself, and does it with more intelligence than can be implemented in a simple sliding window protocol.
I believe QUIC is already deployed and is available on nearly all Google sites, but I think you have to get a developer version of Chrome to see it in action. Eventually Google will (as they did with SPDY) start working with other browser makers to get QUIC implemented, and with standards bodies to get it formalized as a standard.
Relevant to the topic of the article, neither SPDY nor QUIC even have an unencrypted mode. If the committee decides that they want an unencrypted mode they'll have to modify SPDY to do it. It won't require rethinking any of how the protocol works, because SPDY security all comes from an SSL connection, so it's just a matter of removing the tunnel. QUIC is different; because SSL runs on TCP, QUIC had to do something entirely different. So QUIC has its own encryption protocol baked into it from the ground up.
Re: (Score:3)
There is no reason people can't keep using HTTP and they will, for a very long time.
Anyway it would be pretty stupid to curse the W3C for this, because W3C deals with HTML, not HTTP. The IETF are the ones that work on protocols like HTTP.
Will users care? (Score:2)
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?
Re: (Score:2)
Well, if the browser puts up a big warning message saying "anybody can see this, are you sure?" people might understand.
In the last few months, it's been far easier to explain such things to people, because it's suddenly a real thing and is tangible.
Https with local proxy/filters? (Score:4, Interesting)
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.
Re: (Score:2)
There's no reason you couldn't still use a filtering proxy. What you'll need to do is configure that filtering proxy with its own CA cert which you'll have to add to your browser's trusted CAs. The filtering proxy can terminate the outside SSL connection to the remote site (with its own list of trusted external CAs) and generate and sign its own certificates (with its configured CA cert) for the internal SSL connection to your browser. This is how BurpSuite works, for example.
Hm? (Score:2)
Err...isn't going from opportunistic to mandatory encryption what they're trying to do now? Last I saw, HTTP was seeing a little bit of use already. The addition of a version number to it doesn't change the fact that they're already faced with existing behavior. It seems
We need MITM detection as well (Score:4, Insightful)
If everything is to go SSL, we now need widespread "man-in-the-middle" intercept detection. This requires a few things:
Re: (Score:2)
But if there is a man in the middle, whats to stop them from changing the numbers in the voice?
It would be easy for a computer to change some checksum bits. If I have to manually talk to every customer who visits my eCommerce site to confirm their numbers each page load, I would probably walk out.
The wrong layer for (No)SSL v SSL-Only (Score:3)
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?
Re: (Score:3)
For example who is to say there is no value in HTTP/2 over an IPsec protected link without TLS?
That is precisely the attitude that made IPSEC a bloated pig that's almost impossible for mortal man to configure: 'Who is to say there is no value in an IPSEC connection with no encryption?'
Re: (Score:2)
That is precisely the attitude that made IPSEC a bloated pig that's almost impossible for mortal man to configure: 'Who is to say there is no value in an IPSEC connection with no encryption?'
I'll see your IPSEC and raise you an H323.
...DANE (Score:2)
Perhaps a more explicit self-signed certificate methodology that could be codified in some way into http2.
If your domain registrar supports DNSSEC, you could stash your certificate in a DNS record, as geekboybt mentioned [slashdot.org].
HEAD request (Score:2)
Re: (Score:2)
What I'm worried about is that we just ASSUME it's secure because it's encrypted.
If the encryption is 128bit like the bank stuff or if the NSA/GCHQ get the CAs' Root certs.
If it is, this is nothing but "Security Theatre"
Re: (Score:3)
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).