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.

Comments

quick question

[Anonymous Coward]

how can one verify that this future "certificate authority that issues free certificates to any website" hasn't issued a cert to the NSA for your domain? is it possible?

Re:quick question

[Peter Eckersley]

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.

Re:quick question

[tignet]

How can one verify that a different CA doesn't issue a certificate for your domain name to the NSA? It's happened before (including sub CAs getting compromised so new certificates could be created at will).

In order for traditional PKI to work, there needs to be a point of trust -- the certificate authorities. That also means trusting anyone that controls the certificate authorities (who may have the power of secret laws, subpoenas, and gag orders). If you don't trust the authorities, then you cannot trust PKI.

There can be public/private encryption without a centralized authority (SSH keys, PGP, etc). However, then it's up to each person to individually verify the authenticity of every other key. The certificate authority performs that role, so long as you're willing to trust them.

Re:quick question

[ememisya]

I don't believe any "burried deep within your cables" type organization would require this sort of access. It's a lot easier to exploit some kind of a firmware vulnerability and download the private key to the CA, or simply VNC into the target user's machine to see the requested data before it was encrypted. This is to keep out private hackers, organized hackers, wealthy hackers etc. The government will always have access to your data, well since they tend to have tanks the persuation tends to be unmatchable. The turn of the tide for our century is to see if the governments who do have such access will show equal attention to everyone rather than be in favor of economics, lets be honest having access to all of someone's data immediately tends to reduce respect to that person, objectifying them. This is the culture which is really the root of all the privacy issues. I think ultimately we need to rebrand the NSA err I mean shut down the NSA. Because truly, nobody is watching your computer... O_O ... That's the point, when you KNOW someone is watching, it screws up the whole experience.

When something's strange, in your computer, who you gonna call? Momentarily the answer is, "Tough luck" We've been talking about a "government layer" within the network stack (jokingly at first) for decades. As it is however, the world has a major respect issue between authority and economically disadvantaged. It's really a very complex issue. But I'd say the only good way out is read-only access, which doesn't exist, by highly trained (and hopefully paid) employees who just don't exist.

If you're asking, isn't that the case today anyways? The answer is no, there are 0 checks and balances, apparently. In that, a family was raided (agents boxed in their cars), and interrogated because they Googled, "pressure cooker". Heads of such agencies lied to the Congress, in public, and nobody cared. There is this feeling that there are no consequences to invading people's privacy, whereas it should be jail time for the officials. You see? That's the issue with respect, the person who is watching isn't intimidated at all into peering over a person's private life.

Re:quick question

[phantomfive]

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.

Re:quick question

[mlts]

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.

Re:quick question

[Anonymous Coward]

This is a New Sertificate Authority, not the NSA.

Re:quick question

[Richard_at_work]

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

Re:quick question

[userw014]

...

What might have been better is early on, have Web browsers accept self-signed SSL certs, and show some grey icon for that....

Web Browsers DID used to accept self-signed certificates (and certificates signed without a known CA - or cert-chain.) People just clicked through and accepted them willy-nilly. That was a poor security model. Although the existing security model of having a swamp of independent Root Certificate Authorities (per browser) is not too great either, but at some point you have to establish whom to trust - and for most of us, it's the browser vendor. (Some of us prune the Certificate Authority list and distribute the new list with software imaging technologies....)

Re:quick question

[diamondmagic]

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

Re:quick question

[Shakrai]

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

CAcert

[danbob999]

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:CAcert

[ememisya]

It really has much to do with the people involved in the security groups for the popular browsers. I have a feeling EFF, Cisco, Mozilla and Akamai are big enough names to push this through to production.

Re:CAcert

[Martin Blank]

A lack of sufficient auditing capability is what has kept CACert out of most browser CA bundles.

StartSSL.com provides free entry-level certificates with some level of verification, enough at least to satisfy the major browsers.

Re:CAcert

[Fnord666]

A lack of sufficient auditing capability is what has kept CACert out of most browser CA bundles.

Which is laughable considering some of the other CAs that are included.

Re:CAcert

[fustakrakich]

Depending on 'big names' can reduce the trust factor to near zero, and rightfully so. How do 'big names' benefit from our privacy? Where is the incentive to secure it? This is a monolithic industry. Supply and demand are silly illusions. 'Big names' are subject to big laws from big people and the whims of big money, obviously, that's what made their names so big. And now we expect them to bite the hand? I don't think so...

Re:CAcert

[jbolden]

How do 'big names' benefit from our privacy?

Akamai wants you consuming lots and lots of video. Cisco wants you chewing up bandwidth like crazy. They benefit. But yes if push comes to shove between you and Homeland Security, you lose.

Re:This is a huge first step!

[MrKevvy]

re: "They put the inventor of PGP in jail - Phil zimmerman."

Uh, no. He wasn't even charged, just investigated.

Re:This is a huge first step!

[gstoddart]

Also, even if these are back doored by the NSA, the government would have to prove how they got the information without a warrant.

Horseshit.

Some things they just keep secret.

Other things, they commit perjury and perform parallel construction to hide how they got it in the first place.

In other words, they don't need no steenking warrants, they don't need to care about the law, and will do anything they see fit.

They can take care of the pretense of following the law much later.

I'm long past believing they give a damn about needing to prove they obtained stuff legally.

Fantastic.

[KermodeBear]

This is a fantastic effort that will help people such as myself. I run sites across a dozen or so hosts, but they don't generate income and I really don't want to drop all that money into certificates. If I can get free certificates from a good CA then I'll gladly bump all my sites over to HTTPS.

Thank you!

Replace Cisco, and Akamai and then maybe..

[denis-The-menace]

Replace Cisco, and Akamai and then maybe I'll be convinced it's better than the current situation. But it's still oxymoronic service: A central authority that *REQUIRES* trust for people who don't trust anybody.

And what do you do for countries with draconian Cert laws like England? (They want a copy of your root cert)

The resulting entity would have to be incorporated in Iceland or something. FAR away from 5-eye's dragnets.

Re:Replace Cisco, and Akamai and then maybe..

[dnavid]

Replace Cisco, and Akamai and then maybe I'll be convinced it's better than the current situation. But it's still oxymoronic service: A central authority that *REQUIRES* trust for people who don't trust anybody.

First, if you don't trust Cisco and Akamai to that extent, how do you intend to avoid transporting any of your data on networks that use any of their hardware or software?

Second, I think a lot of people really have no idea how SSL/TLS actually work. There's two forms of trust involved with SSL certificate authorities. The first involves the server operators. Server ops have to trust that CAs behave reasonably when it comes to protecting the process of acquiring certs in a domain name. But that trust has nothing to do with actually using the service. Whether you use a CA or not, you have to trust that *all* trusted CAs behave accordingly. If Let's Encrypt, or Godaddy, or Network Solutions, is compromised or acts maliciously they can generate domain certs that masquerade as you whether you use them or not. As a web server operator if you don't trust Let's Encrypt, not using their service does nothing to improve the situation, because they can issue certs on your behalf whether you use them or not - so can Mozilla, so can Microsoft, so can Godaddy.

The real trust is actually on the end user side: they, or rather their browsers, trust CAs based on which signing certs they have in their repositories. Its really end users that have to decide if they trust a server and server identity or not, and the SSL cert system is designed to assist them, not server operators, to make a reasonable decision. If you, as an end user decide not to trust Let's Encrypt, you can revoke their cert from your browser. Then your browser will no longer trust Let's Encrypt certs and generate browser warnings when communicating with any site using them, and you as the end user can then decide what to do next, including deciding not to connect to them.

Seeing as how the point of the service is to improve the adoption of TLS for sites that don't currently use it, refusing to trust a Let's Encrypt protected website that was going pure cleartext last week seems totally nonsensical to me, unless you also don't trust HTTP sites as well and refuse to connect to anything that doesn't support HTTPS.

Lastly, if you literally don't trust anybody, I don't know how you could even use the internet in any form in the first place. You have to place a certain level of trust in the equipment manufacturers, the software writers, the transport networks. If all of them acted maliciously, you can't trust anything you send or do.

I don't necessarily trust the Let's Encrypt people enough to believe they will operate the system perfectly, and I don't believe they are absolutely immune from compromise. But I do think the motives of people adding encryption to things currently not encrypted at all is likely to be reasonable, because no malicious actor would be trying to make it easier to encrypt sites that have lagged and would otherwise continue to lag behind adopting any protection at all. Even if they are capable of compromising the system, that is quixotic at best. Even in the best case scenario they would be making things a lot harder for themselves, and in the long run getting people accustomed to using encryption with a system like this can only accelerate the adoption of even stronger encryption down the road.

Re:No thanks...

[digsbo]

Where do you think there's an honest government?

Re:No thanks...

[Himmy32]

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.

strawman?

[JustNiz]

Why should we believe that HTTPS (or i suppose more accurately TLS / SSL) hasn't already been compromised (i.e. by the NSA)?

Re:Shared hosting...

[BradleyUffner]

SNI solved this problem
http://en.wikipedia.org/wiki/S...

Re:No thanks...

[Kjella]

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.