Slashdot Mirror
Launching 2015: a New Certificate Authority To Encrypt the Entire Web
Peter Eckersley writes: Today EFF, Mozilla, Cisco, and Akamai announced a forthcoming project called Let's Encrypt. Let's Encrypt will be a certificate authority that issues free certificates to any website, using automated protocols (demo video here). Launching in summer 2015, we believe this will be the missing piece that deprecates the woefully insecure HTTP protocol in favor of HTTPS.
We already have a free certificate autority: CAcert. The problem is that their root certificate is not included by default in major web browsers. Why would that be any different? I guess since Mozilla is involved Firefox will get it. But why don't just they allow CAcert? And what about Google and Microsoft?
re: "They put the inventor of PGP in jail - Phil zimmerman."
Uh, no. He wasn't even charged, just investigated.
-- Insert witty one-liner here. --
He did get put in jail, though, on other occasions. Apparently for protesting in a disruptive manner at a nuclear test site.
So technically they were right up until the part where they identified the reason for his arrest.
Actually the US Department of Defense and dozens of other governments have their own CAs with which they could issue a certificate for your domain, if they wished to. Here's a map we made of them using our SSL Observatory datasets.
Nonetheless we should be able to use publication mechanisms such as Certificate Transparency to ensure that any compromise or compulsion of the Let's Encrypt CA could be quickly detected.
Fixing copyright
This is supposed to be an alternative to just using plain HTTP. If you are already paying for a cert from a CA you trust, then this doesn't target you. Even if a couple parties have the key, it's still protects you from all of the others that don't. The whole point is that it's better than nothing. I have a personal website that doesn't do too much and I'd put https on it if I didnt have to pay for a key.
You can't. That gets at the root of the primary problem, and why web traffic isn't encrypted already.
There are two issues, encryption and trust. When you connect to Google.com, how do you know that you've really connected to Google.com? Right now, because Verisign (or somebody) has vouched that the certificate comes from Google.com (ip address by itself isn't enough). Without that vouching, there are all kinds of MITM/redirection attacks that can happen.
From a theoretical standpoint, encryption without trust is no more secure than plaintext transmission. However, from a practical standpoint, encryption blocks out a lot of script kiddies who sit on a wireless network with wireshark (incidentally, there is no way to verify that a WiFi SSID corresponds to a given base station, so if you're on WiFi you are almost always vulnerable to MITM attacks). The EFF, Mozilla, Cisco, and Akami are trying to raise the bar on the difficulty of the practical attacks.
So we're moderately reducing the ease of the theoretical attack, but the big problem is still there, "is this website trusted, or just encrypted?" Traditionally no browser has had a way to distinguish, but it looks like Mozilla is going to, so that's a good thing.
We still have the problem of trust though. It's probably the toughest problem in all of the fields of security and encryption.
"First they came for the slanderers and i said nothing."
HTTPS requires active MITM attacks to eavesdrop. If one looks at the trail afterwards, there isn't any real way to glean the session key the two machines created... to get that key, Charlie has to actively step between Alice and Bob and capture their pieces, while pretending to be the other person. If both use some signature mechanism, Charlie is SOL.
What might have been better is early on, have Web browsers accept self-signed SSL certs, and show some grey icon for that. Certs validated and signed by a CA, a blue icon. EV certs, green. Couple that with a mechanism that detects an unexpected certificate change, and this could provide a decent level of protection, while making it obvious to the user that if they are concerned about security, do transactions with the green or blue color present.
Have you seem the list of CA root certs in a normal browser install these days? Its in the dozens, if not hundreds. A signed cert by any one of those is equally good for any site, unless you are also checking known signatures...
That almost doesn't matter... you create the private key and make a certificate request containing only the public key that they sign, but you're the only one with the private key for that particular certificate with that particular fingerprint. Sure, they or indeed any other CA your users' browsers trust could sign a different certificate and run a MITM, but if they did this in general it would be trivial to discover. Just scribble down your certificate fingerprint and browse it from your family / friends / work / internet cafe / proxy / VPN / open wifi Internet connection and look at the certificate details or just ask some random tin foil hatters to verify it.
It of course doesn't guarantee the government won't do anything nasty if a particular "person of interest" decides to browse your website, but you've at least upgraded it from postcards to an envelope that with a little bit of effort can be steamed open and resealed. Today if they have a bulk logger installed at key internet junctions, which you can be almost certain they do then they can just dump it all to tape, every HTTP call to every website passing through and analyze it later.
Even with the weakest of certificates they must decide whether to intercept it per site, per user and risk their tampering being discovered and it all must be done live. They can't just dump it to tape and decide weeks and months later that they want to go back and look at all that traffic, like postcards passing by a video camera. It would effectively kill bulk traffic data collection and by encrypting URLs also a lot of useful metadata, they'd just see server-to-server connections.
Live today, because you never know what tomorrow brings
according to google, essentially NO extra cpu (in real terms) is needed anymore.
citation:
https://www.imperialviolet.org...
quote:
If there's one point that we want to communicate to the world, it's that SSL/TLS is not computationally expensive any more. Ten years ago it might have been true, but it's just not the case any more. You too can afford to enable HTTPS for your users.
--
"It is now safe to switch off your computer."
It's called DANE, or DNS-based Authentication of Named Entities and described in RFC 6698. The DNS record is TLSA, it associates a TLS certificate to a domain name.
Unfortunately a major browser vendor has yet to implement it. How about supporting the feature requests to implement it? https://bugzilla.mozilla.org/s...
Wonder what the public key field is for?
If you're engaged in activities that would place you on the radar of a major nation-state's intelligence apparatus you shouldn't trust anyone. The only truly secure way to use encryption is to exchange keys (or better yet, one time pads) in person with those that you wish to communicate with. The web of trust/certificate authority model was never intended to provide protection in life or death scenarios, rather it was intended to protect day to day web browsing and e-commerce. By definition it requires that you trust people you've never met and will never meet. This is sufficient when the threat vector is nosy network administrators and script kiddies sniffing hotspot packets at Starbucks.
The whole discussion here is laughable; there's probably a 10 to 1 ratio of people questioning this development vs. those welcoming it. I'm guessing that not a single one of the people in the former category is interesting enough to be on NSA's radar. Many of these same people were commenting in the stories about supercookies and condemning AT&T and Verizon for that behavior. Here's your solution to such shenanigans people....
I want peace on earth and goodwill toward man.
We are the United States Government! We don't do that sort of thing.