A New Free CA

Announcing Let’s Encrypt, a new free certificate authority. This is a joint project of EFF, Mozilla, Cisco, Akamai, and the University of Michigan.

This is an absolutely fantastic idea.

The anchor for any TLS-protected communication is a public-key certificate which demonstrates that the server you’re actually talking to is the server you intended to talk to. For many server operators, getting even a basic server certificate is just too much of a hassle. The application process can be confusing. It usually costs money. It’s tricky to install correctly. It’s a pain to update.

Let’s Encrypt is a new free certificate authority, built on a foundation of cooperation and openness, that lets everyone be up and running with basic server certificates for their domains through a simple one-click process.

[…]

The key principles behind Let’s Encrypt are:

  • Free: Anyone who owns a domain can get a certificate validated for that domain at zero cost.
  • Automatic: The entire enrollment process for certificates occurs painlessly during the server’s native installation or configuration process, while renewal occurs automatically in the background.
  • Secure: Let’s Encrypt will serve as a platform for implementing modern security techniques and best practices.
  • Transparent: All records of certificate issuance and revocation will be available to anyone who wishes to inspect them.
  • Open: The automated issuance and renewal protocol will be an open standard and as much of the software as possible will be open source.
  • Cooperative: Much like the underlying Internet protocols themselves, Let’s Encrypt is a joint effort to benefit the entire community, beyond the control of any one organization.

Slashdot thread. Hacker News thread.

EDITED TO ADD (11/19): Good post. And EFF’s blog post.

Tags: , , , ,

Posted on November 18, 2014 at 12:38 PM • 84 Comments

Comments

dale • November 18, 2014 12:51 PM

Based in the USA (not just the USA but California!), which means they are just as vulnerable to subpoenas and TLA coercion as the commercial CAs. Pointless.

anonymous coward • November 18, 2014 12:52 PM

This is a joint project of EFF, Mozilla, Cisco, Akamai,
and the University of Michigan.

Everyone involved is located in the US. Awesome. My trust level just went through the roof.

L • November 18, 2014 12:55 PM

It is fantastic, but what happened to CACERT?

If this can get included into chrome, firefox, ie, why can’t also CACERT and the free startcom be included too?

I’m not trying to be polemic, I don’t see many details, so I don’t see a difference…

Is it just because “this is ours, so it’s better”?

They really need a FAQ with “Why this is different from CACERT”.

Rob • November 18, 2014 1:01 PM

dale is right. This is one secret, non-disclosure letter away from an even worse situation. Users who think they are secure because “encryption” when really the C.A. has been subverted. At least this will cut out the non-governmental snoops?

Karsten • November 18, 2014 1:02 PM

If this will work, it could eventually kill the business-model of commercial CAs which is probably a good thing. I look forward to test it when some of my certs need renewel end of next year.

More of the same • November 18, 2014 1:03 PM

The centralized control of certificates amounts to one big honey pot. I am sorry but this project solves nothing. What we need is a way of attaching levels of trust to self-signed certificates in a decentralized manner.

Five years ago we were more or less willing to give organizations like CAs the benefit of the doubt, assuming that traffic was not being re-routed, that keys were not being leaked and that we were not being MIM-ed. Today, I’m not so sure.

bcs • November 18, 2014 1:27 PM

Looks to me like running a DNS spoof for any domain that hasn’t yet registered with them (i.e. any site that already has a cert with a different CA) would be enough to get a signed cert for any such domain.

Tom • November 18, 2014 1:40 PM

What ? No!
Nothing to stop the NSA demanding they use a private key of the NSA choosing, for instance.

StartSSL has free SSL certificates covered anyway.

Jarrod Frates • November 18, 2014 1:40 PM

Those who are dismissing this because of the CA model in use are missing the point. This isn’t meant to solve every issue of the current certificate architecture. It’s intended to make it easier for server admins, many of whom do not have a good grasp of configuring SSL/TLS, to go HTTPS by default. Especially if combined with PFS, that makes intercepting traffic on the wire useless without the private keys.

Yes, there are ways of getting the private keys, such as through NSLs. But this minimizes casual interception and adds hurdles even to state-level actors. It also creates a new field of competition, especially given that it’s open source; competing services will show up based out of many other countries such as Russia, Switzerland, the UK, Iceland, and many others. Hopefully, it will also assist with best-practice server configuration, such as disabling SSL and weak cipher suites, enabling TLS and stronger cipher suites, and enabling PFS.

Cynicism can be healthy when it makes you question motives or outcomes. Blind cynicism that causes dismissal of a partial fix because it’s not a panacea is not helpful.

Ortant • November 18, 2014 1:46 PM

@Jarrod Frates
Point taken, but if you cannot configure SSL/TLS, should you be running a server in the first place?

For small-scale garage-style web projects, you already have solutions like YUNOHOST (a point-and-click server set-up with self-signed certificates). In my view, these are much more useful than perpetuating an old, inefficient and insecure model under the pretense of offering something new and valuable. As many have already pointed out, if the issue is free (but insecure) certificates, we’ve got our fair share of those, thanks (and based outside the USA too, which is a bonus as far as most people are concerned).

EvilKiru • November 18, 2014 2:02 PM

@Ortant: “if you cannot configure SSL/TLS, should you be running a server in the first place?”

Yes. Only the web services provider should need to know anything about how to configure SSL/TLS. There is absolutely no reason for a web site operator to have any technical knowledge about SSL/TLS. The only skill required of a web site operator should be the ability to check a box that says “Make my web site work with SSL/TLS”.

Ortant • November 18, 2014 2:06 PM

@EvilKiru: That may be the case for a webmaster (i.e. the person who chooses the background color and replies to customer e-mails), but if you are the person who’s actually running the system that’s hosting a public-facing website (i.e., the sysadmin) and you struggle to configure SSL in your box, I’d dare say you’re in for a bumpy ride as soon as the web goes live. SSL will probably be the last of your worries…

FuraxFox • November 18, 2014 2:09 PM

I concur with Jarrod Frates. The point of such initiative is not to solve all problems at once.

Also, on of their main bulletpoints is “Transparency”.

For me it implies we can expect this CA to adhere to certificate transparency (basically a mix of notaries and signed certificate logs). This would make the stealth signature of illegitimate certificates much more difficult.

Anyway, it does not matters if one CA is not trusty since your web browser is happy to accept certificates signed by any of the world CAs. And last time I checked they all were legal entities under some state law (and influence).

May be one day, with something like DANE+DNSEC you will be able to control who is signing your certificates, but for now “Let’s Encrypt” is as good as we can get in a short time.

iedi • November 18, 2014 2:18 PM

The way I see it, this is a bit like sprinkling sugar from a helicopter over a flood area ’cause at least the water will taste sweeter — utterly pointless. The problem is that the CA model is fundamentally flawed and vulnerable. We don’t need to perpetuate the status quo, we need to move away from the centralized, flawed structure that is wide open to abuse. This is a step in the wrong direction.

Grauhut • November 18, 2014 2:33 PM

@ortant “Point taken, but if you cannot configure SSL/TLS, should you be running a server in the first place?”

Point taken, would you tell us your recipe for giving a fixed ip v4 address to every domain now residing on single ip mass hosting servers? Where will we get them?

Dont tell me ipv6. The only workable way i see is single points of surveillance like Cloudflare.

Ortant • November 18, 2014 2:46 PM

@Grauhut: to completely solve the problem you are suggesting would involve transforming the hierarchical structure of the internet. This would not necessarily be a bad thing in many respects, but a tad ambitious maybe… I’d be satisfied with dealing with the SSL signing problem for the time being.

On a more serious note, mesh networks are worth looking into!

Friday • November 18, 2014 2:52 PM

…and one of the founding members is Cisco?

A company that guaranteed is in cahoots with NSA.

What is this, a honeytrap of sorts?

Noah • November 18, 2014 3:04 PM

I love how all the tin-foil-hatters in the comments are exposing their lack of knowledge to how SSL works… The CA’s don’t generate the certificates, they sign them. Thus they don’t control the private key.

Anura • November 18, 2014 3:07 PM

@Grauhut

SNI is supported by IE7+, Chrome 6+, Firefox 2.0+, IIS8+, and Apache 2.2.15+ – one IPv4 address can serve an unlimited number of websites now.

10-05-10 • November 18, 2014 3:09 PM

@Noah: I don’t think any post here has suggested that the CA’s create the certificate or control the private key. The point we are all making is that, sadly, they don’t even need to. Have you heard of Blue Coat? Does DigiNotar ring a bell?

Jarrod Frates • November 18, 2014 3:17 PM

@Noah: If an entity (such as the NSA) can access the private keys of the CA, it can then sign any certificate that it likes and use it in a MitM attack. That’s what makes it so dangerous.

But the goal here is to make listening more difficult, not impossible. Like I said, it’s one more hurdle that everyone, even state actors, has to go through.

kryptonite • November 18, 2014 3:28 PM

@Jarrod Frates: Exactly. And because it is a centralized system with so much at stake, when it comes to the NSA it’s not “if” they obtain access to the private keys, but “when.”

FuraxFox • November 18, 2014 3:40 PM

@kriptonite you might want to have a look to http://www.certificate-transparency.org/ (there is also a pretty good article in last October CACM, but it is behind a paywall: http://cacm.acm.org/magazines/2014/10/178780-certificate-transparency/fulltext).

You can’t prevent government forcing CA to sign illegitimate certificates, but, with proper infrastructure, you can detect it.

But in the end, you have to trust the your web browser, your operating system and the hardware.

This initiative wont prevent targeted spying by state. But it can make mass surveillance much more costly, which could really change the situation.

EvilKiru • November 18, 2014 3:43 PM

@10-05-10: In that case, I’ll make the suggestion, based on my interaction with Symantec, that Symantec creates the certificate and controls the private key for the vast majority of the certificates they issue, because that’s their default business model for certificates.

Apples • November 18, 2014 3:44 PM

To the naysayers: If nothing else is achieved then at least this may raise the profile of security in the minds of many web site owners who are signed up on virtual hosts and who don’t actually know the mechanics of site administration. Anything that makes encryption more easily available to those people is a start. And as others have noted more more initiatives will probably follow. We cannot magically replace all internet engineering in one step but we can incrementally improve. And this could be a very valuable educational outreach if nothing else.

Andy • November 18, 2014 3:44 PM

Nothing to stop the NSA demanding they use a private key of the NSA choosing, for instance.

A number of commenters don’t seem to understand how PKI works. The CA never sees your private key. You generate a key pair, keep the private key on your own server and send the public key in a CSR to the CA to be signed. A bad actor may find a way to impersonate you, but they can’t possibly compromise your private key from the CA, only by hacking your server.

Aunt Tilda • November 18, 2014 3:48 PM

I agree with those who think that this is a move in the wrong direction and I’m surprised Bruce thinks it’s a good thing. Bruce, didn’t you say we’ve got to make surveillance hard and expensive again? How are we going to achieve this by bringing together the certificates of half the world’s websites under a system which we know is inefficient and vulnerable, hosted in a nation that has seen some of the worst abuses against internet privacy of any western democracy? Basically, if we’re the gazelles and the NSA is the lion, what do we want to do — huddle in the same place (one massive CA for everyone), or run in different directions (millions of independent self signed certificates)?

Ned Ryerson • November 18, 2014 5:37 PM

If this is just an automated signing mechanism, it’s actually worse from a security perspective than a self-signed certificate would be, because it’s pretending to be more secure when it isn’t. The practical consequence will be that certificates signed by this authority will have to be treated the same as self-signed certificates.

James Ward • November 18, 2014 5:45 PM

@Aunt Tilda “How are we going to achieve this by bringing together the certificates of half the world’s websites under a system which we know is inefficient and vulnerable, hosted in a nation that has seen some of the worst abuses against internet privacy of any western democracy?”

This is super hyperbolic. Half the world’s websites are going to be using this CA? Unlikely. More realistically most people will keep using paid CAs for a long time to come and some fraction of a single percent of the world’s websites will use this free CA.

Here is the logic that people seem to be missing: CAs can already be compromised. If the NSA decides to target you in a way that they’re willing to MITM your certificate you’re already cooked goose. If they want you that bad they’re going to get you. This isn’t about preventing that kind of security compromise. This is about increasing the cost of bulk untargeted collection. A free CA makes it more expensive to run the types of programs the NSA wants to run in which they collect literally all communications transacted on the Internet

The real truth to this idea is that building a free CA doesn’t mean that you personally cannot design and implement an alternative to the CA model. It doesn’t mean that all work must be stopped on all other security ideas and that this is the perfect solution. It just means that people who want an SSL that doesn’t cause a browser to flash sirens at you can finally get one without paying 50 dollars a year.

Having a free CA is objectively an improvement over not having a free CA and so therefore this is only good news. It is not the holy grail of Internet security but it also does not claim to be.

James Ward • November 18, 2014 5:54 PM

@Ned Ryerson “If this is just an automated signing mechanism, it’s actually worse from a security perspective than a self-signed certificate would be, because it’s pretending to be more secure when it isn’t. The practical consequence will be that certificates signed by this authority will have to be treated the same as self-signed certificates.”

We have not seen (AFAIK) the vetting methods that will be employed by this free CA. Being backed by the EFF I imagine that they have been thought about at great length. Based on the automation points raised I believe that this project will provide a set of softwares which are installed on a server and allow automatic SSL installations. If such software is provided it should be able to handle verification in some way which is superior to self signed certificates and in fact superior to many CAs which in my experience care more about your 50 dollars than about verifying your identify.

Regarding the point that these certs should be treated the same as self-signed certificates; the way we handle self-signed certs today is a total joke and is leading directly to the need for a free CA. Modern browers act as though they are WORSE than clear-text connections. Want to send a password over cleartext? Not a problem! Want to send it via a self-signed? WHOA! Google Chrome is going to pop up a giant red page and make you click through 10 dialogues. There is no reason that Apache/Nginx/IIS/whatever shouldn’t be making self-signed certs on the fly for all connections that would otherwise be cleartext and frankly I view this new CA as a step in that direction.

Anura • November 18, 2014 6:32 PM

Most systems for ordering SSL certificates today are already fully automated. They send an email to the registrant email on the domain, or alternatively an email address like admin@example.com with a link to verify your email. Is it a secure way to verify identity? No, but it’s cheap.

As for whether this is a step back, I don’t think it is. Any real solutions are going to take years or even decades to implement, and this is something that actually works today. Sure the whole CA system sucks, but it’s still better than plaintext.

Adrian Cohea • November 18, 2014 7:08 PM

Good lord, folks, this conversation is cringe-worthy. First, a few of you seem not to know what the hell a certificate even is. You generate a private key, and that’s completely separate from your CSR (which only contains the public key). Your certificate is your public key signed by the CA (plus maybe a chain certificate file if the CA needs a path to root trust). Unless the NSA can solve the discrete logarithm problem over the elliptic curve you’re using, they can’t extract the private key from your certificate, and neither can your CA. Not even a national security letter can get the private key.

The second thing I find truly cringe-worthy about this conversation is how everything economically wrong with the CA PKI is somehow technically wrong also. The PKI sucks, yes. But it sucks because you have to pay CAs for signatures, and the fact that they are conveniently root trusted in everyone’s browsers.

What’s the alternative to CAs? Turn everybody’s browser certificate store into the GPG trust model? How’s GPG adoption by the way? I hear all the cool kids are using it. Oh wait, they aren’t. (Don’t flame me here, I’m an avid GnuPG 2.1 user.) My point is, I don’t see a path to “decentralized trust” that doesn’t essentially reduce to the GPG trust model, and let’s face it, lots of GPG users don’t make it to a single keysigning party in their life. So how do we think this is going to work for internet server trust?

Thoth • November 18, 2014 7:29 PM

Most CA systems get pwned easily becauae they use The Default Config file or a weakly config. Their assurance is as good as none. HP app servers, RAID hard disk maybe SAN storage, some HSMs, couple of Junipers and Ciscos …. Talk about a HSA favourite setup. Easy game to GG.

I might sit down and write a list of basic compliance to give a hand if there is support from you guys. Clive Robinson and Nick P inputs would be highly valuable here.

Anura • November 18, 2014 8:06 PM

@Adrian Cohea

he problem with the CA model is that the CAs are authorities on certificates, not authorities on what they are issuing the certificates for. When you go to a domain, you want to make sure that the machine you are accessing is allowed to use that domain; so where do you need to go to verify? Someone who is an authority over that domain.

The real alternative to CAs is to store public keys in DNS and secure it with DNSSEC.

Dave • November 18, 2014 8:15 PM

They really need a FAQ with “Why this is different from CACERT”.

That was my first reaction as well. The only difference seems to be “this one is controlled/owned/whatever by Mozilla, while CACert isn’t”.

David Henderson • November 18, 2014 8:37 PM

There is already a web of trust built into PGP; it was designed to be built up through personal contacts.

Some operating systems have sha-1 hashes for packages signed by specific PGP keys.
E.g. https://packages.debian.org/search?keywords=debian-archive-keyring

Why do we need a small set of central CA signers? Can’t browsers be taught to pick up on the web-of-trust of the pgp keys signing certificates?

How did the model of trusting central certificate authorities ever get started given the original robust fault-tolerant design requirements for ARPAnet?

I would like to be able to downgrade my trust in certain authorities. Dont have a chance to with the current system.

Mark • November 18, 2014 8:55 PM

“How does this differ from CAcert?”

This has Mozilla’s backing, so the root certificate will be included by default in a third of the world’s web browsers. This has Cisco and Akamai backing it, which provides plenty of leverage for including the certificate in the other two-thirds.

In comparison, CAcert’s root certificate is included in a single, obscure browser and a few of the less common *nix distros.

Anura • November 19, 2014 12:05 AM

“How does this differ from CAcert?”

They list an existing CA as a partner, and if that’s the case then they may be acting as an intermediate certificate authority, and therefore would not require a new root certificate be installed on the client machines. I’m not sure this is the case, but I suspect it is, and if so it means it would just work unless a certificate higher up in the chain gets revoked.

David Dyer-Bennet • November 19, 2014 1:02 AM

Unless things have changed since I last had to deal with this, you can’t use HTTPS on a virtual-by-name site. So to use this I’d have to pay for a private IP address, and there’s a shortage of those so making drastic changes to demand for them either won’t work or will raise the price (IPv6 not connecting desktops to servers usefully yet). And that would only cover one of my domain names.

Sorry, I don’t see what this accomplishes.

Adam • November 19, 2014 3:37 AM

I don’t think this addresses the basic problem with http / https. Http is completely insecure, and ideally all web server software should be configured out of the box to disable or deprecate it. Yet Https is built on the basis of a broken model – that only a cert signed by a CA is “trustworthy” enough for a browser to make some scary popups go away. Even if keys are free and handed out like candy they still require an effort to obtain, renew and the CA is basically an 3rd wheel in the process.

Why can’t I generate my own cert (set to expire in 10 years) and tell the browser (e.g. through a header) to just trust it implicitly instead of throwing up scary warnings? At the very least my users get crypto and it means I as the site owner don’t have to pay a tax (either in time, effort or money) obtaining the meaningless blessing of some CA.

An unsigned / self signed cert doesn’t protect against man-in-the-middle but I don’t see that some key handed out by a CA does either – CAs have been compromised before. Even the threat of mitm could mitigated to some extent if browsers fingerprinted the cert, cached it and also and did a submission/comparison to a central repository to see if it matched what other users saw. Someone who did a mitm attack with a different cert would be flagged by what the browser had previously cached or during the check to the repository.

One step further would be to let me sign other people’s certs like PGP. If I were browsing Amazon’s website, a signature from Google, Apple, B&N etc would be far more meaningful to people than one from Verisign.

65535 • November 19, 2014 4:31 AM

Bruce [and company] is making an effort to solve a problem. Good for him. Just reading this post and the comments is an education in and of itself.

‘The CA’s don’t generate the certificates, they sign them. Thus they don’t control the private key.’ – Noah

[and]

‘…few of you seem not to know what the hell a certificate even is. You generate a private key, and that’s completely separate from your CSR (which only contains the public key). Your certificate is your public key signed by the CA (plus maybe a chain certificate file if the CA needs a path to root trust)…’ -Adrian Cohea

Good points. That is the way the PKI is “supposed” to work – but not always in practice! PGP and GPG it may work – but with other CA’s who force you to use their Certificates – it may not work exactly that way [Cough… Godaddy and so on].

“@Noah: I don’t think any post here has suggested that the CA’s create the certificate or control the private key. The point we are all making is that, sadly, they don’t even need to. Have you heard of Blue Coat?..” -10-05-10

That is SSL/TLS stripping [through various tricks – some legal and some not so legal]. That is a real problem.

“You can’t prevent government forcing CA to sign illegitimate certificates, but, with proper infrastructure, you can detect it… But in the end, you have to trust the your web browser, your operating system and the hardware.” –FuraxFox

I agree. That is very dishonest. Hopefully ‘Let’s Encrypt’ CA will not fall into that trap.

“@10-05-10: In that case, I’ll make the suggestion, based on my interaction with Symantec, that Symantec creates the certificate and controls the private key for the vast majority of the certificates they issue, because that’s their default business model for certificates.” -EvilKiru

Yes, we are back to the real issue of who actually makes the private keys [and possibly keeps a copy of your private keys or escrows them] before the Certificate Signing Request [CSR] is sent and signed by the Certificate Authority [CA] for their $50 – $200 “stamp of authenticity” – so Google, Firefox, and Chrome don’t start red-flag screens on your browser.

“Most systems for ordering SSL certificates today are already fully automated. They send an email to the registrant email on the domain, or alternatively an email address like admin@example.com with a link to verify your email. Is it a secure way to verify identity? No, but it’s cheap. As for whether this is a step back, I don’t think it is. Any real solutions are going to take years or even decades to implement.. Sure the whole CA system sucks, but it’s still better than plaintext.” – Anura

I concur.

Plaintext or HTTP is easily Man-in-the-middled or scammed in some other fashion. It is unsafe. Plaintext is toast in the long run. At least HTTPS makes the NSA try harder at circumventing the current laws – which will out-them eventually.

“Unless things have changed since I last had to deal with this, you can’t use HTTPS on a virtual-by-name site. So to use this I’d have to pay for a private IP address’ – David Dyer Bennet

That is one of the reasons that the majority of websites are plaintext [HTTP].

“Most clients software support it now, except unfortunately a few mobile browsers and Internet Explorer 6.” -FuraxFox

But, check big sites like Wired and Ars Technica – they are still plaintext. That is in addition to their mobile customers who cannot take advantage of SSL/TLS.

“@Ned Ryerson “If this is just an automated signing mechanism, it’s actually worse from a security perspective than a self-signed certificate would be, because it’s pretending to be more secure when it isn’t. The practical consequence will be that certificates signed by this authority will have to be treated the same as self-signed certificates.”

‘We have not seen (AFAIK) the vetting methods that will be employed by this free CA. Being backed by the EFF I imagine that they have been thought about at great length. Based on the automation points raised I believe that this project will provide a set of softwares which are installed on a server and allow automatic SSL installations. If such software is provided it should be able to handle verification in some way which is superior to self signed certificates and in fact superior to many CAs which in my experience care more about your 50 dollars than about verifying your identify.’ – James Ward

That is a good point.

“Based in the USA and with NSA-Cisco involved? No chance…” –keiner

That is understandable.

But, the concern about being an American company under the jurisdiction of the FBI, FISC and eventually the NSA is valid. I hope that ‘Let’s Encrypt’ doesn’t fall victim to the NASKEY trick where the NSA plants it’s public key in the CA’s code to spy on the construction of all certificates issued by said CA [or similar trick].

https://en.wikipedia.org/wiki/NSAKEY

“Anything that makes encryption more easily available to those people is a start. And as others have noted more… initiatives will probably follow. We cannot magically replace all internet engineering in one step but we can incrementally improve. And this could be a very valuable educational outreach if nothing else. –Apples

I agree. As it stands, most http is not only pwn’d by the NSA but other hackers. Any broad and cheap encryption is better than plain text. As you say “…a valuable educational outreach if nothing else.” Encryption is hard to get right and making it easier is better than not.

Ned Ryerson • November 19, 2014 7:34 AM

@Adam: Even the threat of mitm could mitigated to some extent if browsers fingerprinted the cert, cached it and also and did a submission/comparison to a central repository to see if it matched what other users saw. Someone who did a mitm attack with a different cert would be flagged by what the browser had previously cached or during the check to the repository.

This will not work. Firstly, the same NSA that can force CAs to install compromised signing keys can also force an central repository to install compromised “root evidence” that would make the NSA’s forged keys look more legitimate than the actual legitimate one. Secondly, this would allow any script kiddie in a Guy Fawkes mask the ability to DDOS a site they didn’t like, without having to attack the site itself and leave evidence there. All it would take was the submission of lots of automatically-generated bogus “evidence” that rendered certificate comparisons incoherent. Besides, how do you even know you’re talking to the real trusted central repository in the first place? Think carefully about this…

65535 • November 19, 2014 8:31 AM

I can think of at least two groups of individuals who would be extremely critical of Let’s Encrypt’s free certificate offering:

  1. The NSA and all of its tentacles.
  2. The current for profit Certificate Authorities [or their holding companies] who stand to lose a sizable about of money.

Getting this Certificate Authority off of the ground will be difficult.

FuraxFox • November 19, 2014 10:36 AM

I believe most comments are missing the point of this initiative.

HTTPS in a web browser cannot protect you from a targeted attack from US government (or any technology conscious gov): they can try to strip SSL, they can go to the server, to the service provider(legally or not), use backdoors in client or server operating system, plant malware server or client side they can have backdoors or 0days in your firmwares and in the end, they can plant cameras in your living room … Securing an individual against targeted surveillance is extremely difficult and possibly impossible for a large enough population.

But, generalizing the use of TLS force them to use those, relatively costly, attacks, and choose targets. It defeats the mass collection of traffic for future analysis.
The current situation is that mass attackers do not need to be subtle: most traffic is clear-text and can be mined for information.

To get there we need a few steps:

  • make using TLS the default for a web site operator (easy and cheap certificate delivery is a requirement for that).
  • ensure proper cryptographic suites are chosen by most sites
    (the generalization of TLS1.2 support and the killing of CBC and RC4 would be nice)
  • generalize the use of PFS (preferably ECDH with reliable curves)
  • have a transparency mechanism for certificates that would allow to detect improper certificates (through DNS[SEC] or notaries)

“Let’s encrypt” seems to be a step in the right direction for step 1 at least.

I’m surprised of people talking about private keys getting in the hands of CAs.
The only case I have encountered of are for corporate encryption certificates and smart-cards (and with those in most cases private keys are not supposed to be extracted).

The normal process is to generate your own key-pair, send a request (CSR) to the authority (Registration Authority to be pedantic). Prove your identity (a weak point, generally automatized) and the authority signs your CSR to generate the certificate.

If you do so, most attacks through the authority consist of signing new certificates for your identity for third parties (i.e getting certificates in someone else’s name). Most of the time it is automatized by giving the attacker a sub-CA signed by a legitimate CA to make his own certificate printing machine.

Czerno • November 19, 2014 11:17 AM

Of CAs and private keys :

…as discussed by a few contributors. I think
there is some confusion, what’s been questionned is not that CAs have (a copy of) the private keys of customers, they don’t, in general.

The concern was about the CAs’ OWN private (signing) keys, which the powers-that-be can
grasp either by asking (with or without a legal warrant or security letter or rubber-hose persuasion…) or, perhaps, using some exploits for stealing them unbeknownst.

gurl • November 19, 2014 11:30 AM

This is a great idea, and I plan on using it with all of my self-signed S/MIME certificates and server CA. And the critics are wrongheaded and clearly misunderstand PKI.

This provides a real improvement on my own current model, which is to create my own certs, then ask people to manually trust them based on TOFU.

The proposed model involves a CA that’s already installed in nearly everyone’s keychain. There is no downside risk to sending a public certificate, which is PUBLIC, to the Let’s Encrypt project.

NobodySpecial • November 19, 2014 12:27 PM

“The anchor for any TLS-protected communication is a public-key certificate which demonstrates that the server you’re actually talking to is the server you intended to talk to. ”

Exactly – the server you THOUGHT you were talking to.
But by handing out certificates with no proof of ID, credit card business license etc it generates scams. So I run off and register microsft.com or BankOAmerica.com and this will give me a little green padlock to PROVE that the site is genuine !

This is like a security system which, when you are emailed by a “Nigerian Prince” scammer, proves that it is really that scammer who is calling you not a fake one – it does nothing to prove it is really a Nigerian prince.

Anura • November 19, 2014 12:39 PM

@NobodySpecial

The problem of similar domain names probably isn’t solvable. There’s nothing to stop me from starting a company that makes check printing software called “MICR Software” using stolen identity and then using “micrsoft.com” to fool people into thinking they are at microsoft.com (except legal action after-the-fact by microsoft).

The best we can hope for is to verify that the private key is for the domain you are visiting and that the server you are communicating with knows the private key.

NobodySpecial • November 19, 2014 2:55 PM

@Anura- true, but when you could only get a cert from a real “trusted authority” you could trust that they would be a bit suspicious of somebody registering bankoamerica.com and require a credit card and a copy of some state/federal corporate registration.

But a major bank allowed a postal employee to open an account as “Internal Revenue ServiceS” and deposit a bunch of stolen checks so you can’t rely on common sense !

Anura • November 19, 2014 3:08 PM

@NobodySpecial

See my above post about the rigourous cough checks they go through. That’s actually one of the more rigorous systems I’ve seen. I used to work for a reseller about 5 or 6 years back, and all we did was submit orders to their system, and the usual ETA from sending the CSR to receiving the signed certificate was from two to five minutes. Now, what kind of checks do you think they did? As far as I can tell, they just made sure the information on the CSR matched the domain registration (they would require email verification sometimes when they used proxy registration).

Anura • November 19, 2014 3:20 PM

I should note that for a much higher price, you can get an EV SSL certificate, in which CAs do what they were supposed to be doing in the first place and actually verifying they are who they say they are. There is still a problem in that they don’t have authority over the domains, so if a domaain changes hands the certificate still remains valid. We really need two pieces; one that uses the domain name system to provide assurance that they hold a valid private key for the domain, and the EV SSL Certificate which verifies that the company itself has been verified to be legit.

Pat • November 19, 2014 3:58 PM

But by handing out certificates with no proof of ID, credit card business license etc it generates scams. So I run off and register microsft.com or BankOAmerica.com and this will give me a little green padlock to PROVE that the site is genuine !

Clearly the existing methods are preventing scams excellently.

Former Subscriber • November 19, 2014 4:15 PM

Bruce,

I always respected you as a security guru. You dropped down a notch the other day, when your mailer for Crypto-gram sent me a confirmation message with my PASSWORD in plain text in the email.

See any issue with that?

You sent me this:

On your membership page, you can change various delivery options such as your email address and whether you get digests or not. As a reminder, your membership password is

hunter2

If you have any questions or problems, you can contact the list owner at

crypto-gram-owner@schneier.com

Come on, dude, you should know better! You shouldn’t even be storing my password without one-way encrypting it.

NobodySpecial • November 19, 2014 4:30 PM

@hunter2 – he did encrypt it, Bruce can reverse an MD5 in his head!

Allowing weak security on sites like this actually makes sense, forcing users to meet security requirements on throw-away accounts tends to make them re-use important passwords

Wael • November 19, 2014 5:15 PM

@Former Subscriber,

I like your password! Reminds me of The Cuckoo’s egg where the vilan (hacker) chose a codename of “Hunter” 🙂

Why did you choose such a weak password anyways? 🙂

Mike Amling • November 19, 2014 7:08 PM

I agree that making it easier to move existing HTTP traffic to HTTPS is a good idea. But I can hardly believe that the process of keeping the generated private key private yet available for use in securing every incoming connection is a ‘one-click’ process.

BJ • November 19, 2014 7:37 PM

I find it striking that commenters on this post disagree with Bruce about the benefit of this offering.

He literally wrote the book on Applied Crypto!

David Henderson • November 19, 2014 7:43 PM

openssh implements another form of certificate – a signed key.

An ssh trusted keypair on a system is used to authorize Alice’s logins on that system. Alice sends her public key to the sysadmin of the system. The sysadmin verifies Alice’s identity, perhaps from a personal contact. Alice’s signed key is returned to Alice.

To logon to the system, Alice configures ssh to present her signed public key. The system verifies the signature, and bingo, the connection is authorized. The ssh utility can also detect and report man-in-the-middle attacks.

Whats neat and relevant to this thread is that ssh can tunnel a http: link. This replaces a somewhat questionable ssl link with a very private encrypted ssh tunnel with ultra secure protocols fixed in advance.

For a really secure connection, I think I’d rather be using a ssh tunnel than ssl. Note that is not anonymous, its just very private.

A howto also describes doing DNS lookups through the same tunnel, showing details of configuring Firefox. No info leaks out…
https://calomel.org/firefox_ssh_proxy.html

Buck • November 19, 2014 9:03 PM

I can’t decide whether this is great news or worse… Certainly, free market forces will continue to play their course; countries ’round the world will be forced to provide their own no-cost-cert-authorities… Small step for national security..? Massive deconstruction of a large bubble market in ‘trust’ brokerage..!

65535 • November 19, 2014 10:27 PM

“The concern was about the CAs’ OWN private (signing) keys, which the powers-that-be can grasp either by asking (with or without a legal warrant or security letter or rubber-hose persuasion…) or, perhaps, using some exploits for stealing them unbeknownst.” –Czerno

That very “exploit” problem was one of theories of the embedded _NASKEY and an unknown third key discovered in MS 2000 Server editions [and NT4 editions with Service Pack 5 – which most people assumed was a normal service pack].

‘”Let’s encrypt” seems to be a step in the right direction for step 1 at least.’ –FuraxFox

I agree. Any improvement of the current situation is better than none. And, a free improvement is appreciated [although some have their doubts about “Free” stuff and are not forced to use it].

Thoth • November 20, 2014 1:10 AM

Stakeholders influence a ptoject. Laws and invisible hands as well. It is the driver. Robust security designs are like the vehicle. The fnds and resources are lie the fuel. Thre are many ways to spoil that journey.

SSH is a huge complex beast that can go wrong easily. I was doing QA for an SSH monitoring system and I can say easily SSH is an outdated design. Read the MinimaLT papr for a better sec comms protocol.

Tom Bortels • November 20, 2014 1:42 AM

The proliferation of CAs, many of whom have been subverted in the past, and are likely to be subverted in the future, makes the concept that a CA is vouching for identity pretty laughable to begin with. This does very little to change that, and that’s probably not totally a bad thing – If your locks are poor, best that it’s a well-known fact, so people don’t depend heavily on them.

What this could do instead is help to make SSL more ubiquitous – and that’s nothing but good, not for the pretend-assurance of a CA vouching for identity, but for the encryption – A fairly large number of fairly easy to perpetrate attacks are nicely foiled by simple encryption. It doesn’t make you invulnerable to sniffing – but nothing will.

And it should help to break the silly, silly business of a CA vouching for identity, which has always been ineffective, at best, and deceptive at worst (I can’t tell you how many sites I used to see behind a good https link, that then dumped credit card information in plaintext to disk back in the day). By making SSL free (or rather a technical debt rather than a financial one), we’re making a big step in the right direction.

mark • November 20, 2014 11:59 AM

Bruce,

What bothers me about a free CA is that it becomes a cost-free source of CAs for distributors of malware. My first thought it a hijacked website, and of course it’s ok to go to the false one, because it has a valid CA. At least with the for-pay ones, there’s a brake on how many false flag domains the nasties can set up per day….

   mark

Nicolas George • November 20, 2014 12:27 PM

Like several other comments already here, I wonder that people rejoice in this instead of denouncing the flaws of certification authorities, but my main argument was not stated, so here is my piece:

Certification authorities are used to give trust to the client, but they are chosen by the server. The basic design is completely flawed.

Carlos • November 21, 2014 7:38 AM

Geeez!

The way so many people here are opposing this idea is, frankly, a bit surprising.

But yes, let’s not even begin to address the problem of mass surveillance by various governments because this doesn’t address this or that other problem.

Also, as someone said before, today lots of sites don’t use any form of encryption because browsers actually make self-signed certificates seem more dangerous than plaintext sites. Let’s not address this problem either!

Because, you know, reasons.

Yes, maybe the NSA can crack SSL/TLS, but can they still do it if the majority of the web traffic uses it?

And that is why this is called “Let’s Encrypt”, not, “Let’s fix the web”.

species5618 • November 21, 2014 10:54 AM

I am not convinced society is ready for this level of “free” security

The general public have spent ages learning to trust the GREEN address bar or lock symbol on internet browsers

so would trust a “authentic” looking ecommerce site, enabling criminals to collect MORE data than before,

I step in the right direction, but needs more work

Wael • November 21, 2014 11:06 AM

@species5618,

I find it very “interesting” that out of all possible names, you picked this at the same time I talked about “species”. And we both posted at the same time! Did you by any chance lookup the meaning of the word “Gerontic”, then that infeluenced your choice of handles? I refuse to believe this is a coincidence!

The general public have spent ages learning to trust the GREEN address bar or lock symbol on internet browsers

Trust has been dwindling for sometime now. We are ready 🙂

@Nick P,
Still interesting, eh?

Nick P • November 21, 2014 12:38 PM

@ Wael

Only interesting if that was his first use of ‘species’ and he chose it as you were thinking on it. Even then, it gets negated by probability because there’s only so many words that get used a lot, a ton of people, tons of thoughts/writing. Means there should be lots of associations that happen purely by chance. So, words and numbers popping up with no context I’m more inclined to call a coincidence.

I’d have raised an eyebrow if you were writing a short story with an online character named species5618, checked the blog, and bam there it was in the comment feed. I’m sure you’d have raised one too.

Wael • November 21, 2014 1:53 PM

@Nick P,

Short term memory is failing. Must be the mercury contaminated fish I had the other day. November 21, 2014 10:54 AM is the correct time.

bobup • November 21, 2014 7:32 PM

DNS encryption is also a good idea, and using SSH tunnels via VPN through a variety of different servers in different countries. Yeah it’s a pain, but let’s make their data retention plans a real pain. Also run fake search pushers that push lists of random words to search engines. Sift that you snooping dongass, want data, well here is a huge crap load.

muchiosgarndiass • November 21, 2014 7:40 PM

Push loads of fake data with your data, via SSH tunnel and VPN to different servers in different countries all the time. Want data, well here’s lot’s of fake random searches automatically generated and you have to collect it from many different countries. If everyone pushes loads of extra crap then it will start filling their petabytes of storage pretty darn quickly and those racks will be smoking trying to hit all those DPI profiling and keyword sniffers.

Oh great, the internet is now fundamentally broken, oops what a great idea spying on all the good people was. 🙁

MrPKI • November 25, 2014 12:10 AM

This initiative is being called “Let’s Encrypt” NOT “Let’s Authenticate”. Keep in mind that there are 2 parts to TLS/SSL, the encryption part and the authentication part. I expect that this group (EFF, etc.) is attempting to solve the encryption part first by providing what is essentially a “low trust” free CA service. Once we get ALL web traffic encrypted where HTTPS is the default, then we can start to focus on getting the server authentication part right. One step at a time here folks.

Justin • November 25, 2014 1:01 AM

@ MrPKI

It’s all well and good to encrypt web traffic, but without effective authentication—and x.509 PKI is hopelessly broken—it’s almost worthless to do so because a MITM attacker can simply present a fake certificate to the client, and in turn connect to the real server, and nobody would be the wiser. And there are certain SSL firewalling appliances that have been issued valid certificates to do just that.

Either a more sophisticated decentralized model of trust is needed, or a more formal centralized one tied to DNS, not the current mess we have where hundreds of root and intermediate CAs (in the control of various organizations with differing policies, motives, and goals) are totally trusted for all domains. And then there is the question of how to ensure continued access to TLS-protected communications by intelligence and law enforcement agencies, something of a practical and political necessity which is trivial in the present model.

But that’s really a separate issue. The PKI is what it is now, and it does no harm to make it more convenient and free to use. Just recognize that it doesn’t provide more than a token level of security.

some_seriousness_please • January 25, 2015 3:54 PM

haha 🙂 Minute Cisco but especially Akamai are in on it…. = epic fail. Moving on.

Jarth • February 19, 2015 4:54 AM

Dear World

Privacy is as old as humanity, it is closely related to intimacy as well.

As such encryption is a great tool to maintain privacy.

But it’s also driving quite a bit of people up or against the wall. Hence the focus is much more on the conflict at hand than on a solutions of some sort.

Since I’m naïve and a bit bored. Here goes my take on the debate.

What about offering an authenticated (as in AEAD(Though AE should stand for Authenticated Encapsulation)) MPLS like technology for individual use, offering warranted ‘isolated channels’ for communications. Considering only confidential data ( not everything in-flight) would be encrypted, which in turn could be regulated to some extent. If need be the context of encrypted communications could be deduced and site conforming to such compliance would facilitate rather than limit any necessary surveillance.

The relation between citizen and governments are being hyper rationalized, which is a proven recipe for suffering. Such leads to thinking of human beings in a population as more like a flock which needs grooming, feeding, territory, maneuvering space and occasional culling.

I hope we can move beyond that primal level of interrelationships and consider our species as conscious beings. Beings who are interdependent and are often open to such an approach of collaboration.

“Yes we Can, Yes we Scan, Yes we Validate, Yes we Trust” so to speak.

In addition there might be need for a way for a citizen to be sent a notification his or her communications and/or data has been noticed, monitored, absorbed for review.

It will have some desirable and less desirable effects.

But in the end a positive effect may, or even will be, noticeable. Awareness will grow and the need for surveillance as well as it’s implementation will be out of the shadows and as such open to some form of public scrutiny, while maintaining function and purpose.

Jeff • July 4, 2019 9:16 AM

Curious to know if you have reviewed EJBCA, Dogtag CA or Simple Authority as a small business CA? I agree with this article that a free and open CA is a great idea. It’s also possible to simply dig in, use OpenSSL, write C or Java and implement one’s own CA. As well as use the Bouncycastle API. While people who are interested in PKI should read your book and others on PKI, it would be interesting if you did an article on some of the security issues around running a CA privately.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.