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

[lillgud]

Irrelevant.
The "certificate authority that issues free certificates to any website" can actually be one or many of the CAs that is popular today. This is just a new protocol for the way to get a certificate signed by one of these CAs. So if some CA issues as a cert to the NSA for your domain right now there is nothing here that prevents that CA for doing it when using this new protocol.

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

[Anonymous Coward]

The fundamental problem is the whole concept of a "Web of Trust." How or why should I trust that a collision detection mechanism is in place, functioning properly, and has not been manually overridden? We've come full-circle to "I just have to blindly trust."

Re:quick question

[robmv]

Public Key pinning is a small first step in the right direction, I think the problem is the first connection with the site, hopefuly something with DNSSEC could be added to help more

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

Re:quick question

[Bert64]

#1 does not require compromising the CA... Any CA is beholden to the government of the country in which it operates, and would be required to hand over the private key if ordered to do so. And the more people who have the private key, the greater chances of it leaking.

Re:quick question

[mike10027]

... 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 has Charlie done with Eve?

Re:quick question

[david_thornley]

Currently, a browser will happily accept an unencrypted connection or an encrypted one with a certificate tracing back to (in this Firefox browser) a certificate from of of 92 authorities (some of which have multiple certificates), some of which aren't in English and most of which I've never heard of. With that many authorities, it seems like a reasonable bet that at least one is compromised and doesn't know it. The browser will have conniptions and claim loudly that the sky is falling if it encounters a self-signed certificate.

Granted, a self-signed certificate does nothing for authentication, unlike that certificate signed by the people who hacked into one of those Turkish authorities, but it seriously reduces the attack surface compared to straight HTTP (which also doesn't provide authentication).

Does this make any sense to anybody?

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

[akpoff]

Cisco's involvement makes sense. They're pushing hard into "Internet of Things". They won't want the bad publicity or financial risk of delivering unsecured configuration UIs. Sure, they could install self-signed certificates but browser warnings about self-signed certs will generate support calls. If they can get the root cert into the other browsers (and as one poster above noted, it seems likely with this line-up), free certificates for the asking solves the problem.

Akamai, not sure what they get out of it. Perhaps just improved end-to-end security.

For the EFF, it's pretty obvious. They're pushing https everywhere. Working with heavyweights like Cisco and Akamai furthers that goal. Having the EFF involved will at least ensure the new CA is looked at by geeks and privacy folks.

I have no complaints. At least not until the details are fully known. Hopefully no complaints then either.

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:This is a huge first step!

[i kan reed]

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.

What about the browsers?

[Anonymous Coward]

Have Apple, Microsoft, Google and Opera all pledged to add certificates for Let's Encrypt - and not just for future browser releases? Otherwise, we lose all of our IE12, Safari, Mobile Safari, Android, Chrome, and Opera users with these certificates.

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.

Re:No thanks...

[JustNiz]

This.

I think this is the REAL question. As is: why should we believe that https isn't also already compromised (i.e. by the NSA)?

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:strawman?

[JustNiz]

Not useless, but also not what it says on the tin.

Re:Shared hosting...

[BradleyUffner]

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

Re:No thanks...

[toonces33]

The transport itself - most likely not. They wouldn't be spending all kinds of time and effort to break into certificate authorities so that they can generate their own "trusted" certificates for whatever websites that they wish.

The notion that there are "trusted" root certificates is where the problem lies. But I have not seen anyone come up with a workable alternative.

Re:Identity?

[omnichad]

The amount of identity verification required is very small. StartSSL is fully compliant and included in browsers by default, but it's very simple and takes only a few minutes online.

Bob DeHacker isn't going to be able to get an accepted cert for a MITM attack for a major company. Really, these days, the only thing that lights up the address bar green is EV-SSL. Your standard HTTPS site just puts in a tiny padlock in the address bar. And nobody's going to buy a certificate for a MITM attack on a site that's not big enough to be buying an EV-SSL certificate.

Re:Shared hosting...

[heypete]

SNI is now supported by all the major players (IE was the last hold out) but... I'm pretty sure the current free cert providers don't support it.

SNI requres support from (a) the browser, and is near-universally supported by all browsers these days and (b) the web server, with many hosts supporting it already. If not, they should.

The certificate authority is not involved with SNI at all.

Re:Shared hosting...

[VGPowerlord]

More to the point:

All modern browsers except IE on XP or lower support it.

All modern web servers support it. For reference, this is all versions of nginx; Apache 2.2.12+; and IIS8+. Assuming nginx and Apache are compiled against a version of openssl released after 2006 and didn't explicitly disable SNI.

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.

Re:So how much power will this use?

[TheGratefulNet]

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.