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

[Martin Blank]

Presumably there will be a collision detection mechanism that nixes the old certificate and alerts you to such changes by e-mail.

Yes, there are ways around it, but that's true of any CA.

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

[omnichad]

And how is that worse than using HTTP?

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

[jbolden]

EFF and Mozilla are included. I think that's a stretch.

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

[Anonymous Coward]

It may be a bit before we have a web-of-trust, so for the time being, we need to get our web-sites encrypted. I'm less concerned about the NSA hacking me as I am my parents getting their passwords sniffed over an open WIFI because a site doesn't have HTTPS.

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

[Anonymous Coward]

Being that one of the sponsors is Cisco, you can pretty much count on there being NSA backdoors with this project.

Re:quick question

[mjwalshe]

or have the tragedy of the commons devalue the ssl certificate

Re:quick question

[nine-times]

Yeah, there was talk a while back of using DNSSEC as a method of authenticating self-signed certificates, which seemed to me to be a promising idea. I'm not sure if any progress was ever made.

Re:quick question

[AaronLS]

"A signed cert by any one of those is equally good for any site, unless you are also checking known signatures..."

What you are describing is what I already described via method #2. If and only if they are able to add their root public key to the user's computer will their fraudulently issued certificates successfully validate. Once it's added, then yes they can issue a fraudulent cert for any domain, and that user's browser will validate it.

"Have you seem the list of CA root certs in a normal browser install these days? Its in the dozens, if not hundreds."

Yes, so if you want to pursue method #1, you only need compromise any one of these CAs. Some CAs are going to have worse security than others, perhaps giving too many employees access to the private key, and some may reside in countries where governments or criminal elements leverage more control over the CA.

Some browsers have been more aggressive in removing CAs that have had issues where they were found to be issuing fraudulent certificates. It's kind of a moving target.

This new organization isn't necessarily immune to any of this. If they aren't secured well and their private key were compromised, then the same issues apply to them.

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

[hawguy]

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?

How can one verify that any "certificate authority" hasn't issued a cert to the NSA?

But if your domain is currently running HTTP because you don't want to pay for an HTTPS certificate, giving the NSA a backdoor to decrypt your website doesn't seem like much of a drawback. Not that matter for most people, if the NSA wants to see your data, if they can't get it from you, they'll get it from your ISP.

Re:quick question

[Shakrai]

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.

It also blocks out obnoxious ISPs that want to mess with your web sessions for whatever reason (usually advertising); from my point of view this matters more to me than the script kiddie with wireshark.

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

[devman]

HTTP STS is supposed to help mitigate Wifi pharming attacks and has already been deployed by a few major sites, the real long term solution for this is DANE though.

Re:quick question

[psyclone]

It's a bummer browsers haven't enabled DANE yet. You can try an experimental addon for firefox. Good news is Postfix supports DANE for email!

Re:quick question

[phantomfive]

What is DANE? I can't find any info on it.

Re:quick question

[devman]

My apologies. The wiki article linked provides a decent primer (it also lists relevant specifications).

DNS-based Authentication of Named Entities

Re:quick question

[thegarbz]

From a theoretical standpoint, encryption without trust is no more secure than plaintext transmission.

From a theoretical standpoint you've used trust and security in the same sentence, whereas they are are two completely independent concepts.

Secure communications means people don't randomly eaves drop.
Trusted communications means the people who read them are the people who are supposed to read them.

Without an encrypted channel you have zero security. Every idiot snooping on the wire can read what you wrote.
With an encrypted channel but no trust, you have some security. You need to directly involve a middle party and accept their security credentials in order for them to read what you wrote. Yes MITM is a thing and it is bad, but that doesn't mean a lack of trust means a lack of security.

You most definitely do even in theory have more security if you use encryption without a way of verifying who the other party is.

Or to use an analogy, you're in a room full of people wearing black hoods. 1 of them is bad, 1 is good, the remainder are innocent.
Using HTTP: "Hello everyone in the room, my CC number is xxxxxx"
Using HTTPS without a CA: "Pssst you there. I don't know who you are but my CC is xxxxxx" (you have a chance of the other person being the correct target, and no one is listening, or you have a chance the other person is bad and you're screwed.
Using HTTPS with a CA: "Psst, who are you, and prove it before I give you my number."

The middle option is definitely less secure than the last, but at the same token more secure than the first. I'm not worried about targeted attacks. I'm quite sure I won't stand up to a targeted attack. But based on what I have seen the vast majority of attacks are not targeted. They are crimes of opportunity. Script kiddies looking for default passwords and running wireshark from a van in the street hoping that a user on an unsecured wifi network will type their CC in plaintext.

Re:quick question

[phantomfive]

Thanks. So it looks like DNS will become the CA, which seems somewhat reasonable.

Re:quick question

[cheater512]

If and only if they are able to add their root public key to the user's computer will their fraudulently issued certificates successfully validate.

Erm what do you mean 'if'? They DO have their own CA's added to all browsers. Lots of governments do.

Re:quick question

[phantomfive]

The middle option is definitely less secure than the last, but at the same token more secure than the first.

From a theoretical standpoint, there is no 'more' or 'less' secure. If you're insecure, you're insecure.

Script kiddies looking for default passwords and running wireshark from a van in the street hoping that a user on an unsecured wifi network will type their CC in plaintext

Well, you don't need an unsecured wifi for a MITM

Re:quick question

[WuphonsReach]

Short answer: no it's not possible to detect that with the current system

The slightly longer answer is either browser pinning of certificates, or better, DANE. With a system like DANE, it's much harder to impersonate large swathes of the domains like you can today.

Re:quick question

[thegarbz]

Well consider yourself always insecure since the NSA can hack into anything.

Oh but you can be secure against somethings but that's no better than being insecure against everything? Do you even read your own pedantry to see if it makes sense?

Maybe I should just remove all my passwords and login as Administrator everywhere since there's no sliding scale in security. So why would I bother?

Re:quick question

[phantomfive]

Do you even read your own pedantry to see if it makes sense?

If you're going to pedantically point out my pedantry, please make sure you can distinguish the difference between practical and theoretical. You've been having trouble thus far, but I know you can do better.

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

[locofungus]

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.

The poor security model was browsers asking for confirmation for self signed certificates.

What browsers should have done is:

self signed certificates or unknown CA - how the "unencrypted web" works today.
No encryption at all - popup "are you sure you want to connect"
Signed certificate - tick (check) mark (instead of padlock) to show that the site is verified.

Now that browers are hiding the "http/https" bit from most people anyway it makes even less sense to treat self signed certificates as less safe/require more warning than a normal http connection.

Re:quick question

[dotancohen]

This was recently asked on Super User (a StackExchange site) but got no good answers:
http://superuser.com/questions...

Re:quick question

[dotancohen]

I would love to see your pruned list. See this SuperUser thread, for which I put a bounty on but never got a good answer:
http://superuser.com/questions...

Re:quick question

[thegarbz]

Oh you assume that theoretical means you should ignore all externalities and focus on only on a variable which confirms what you were already thinking. Interesting. You didn't do science in highschool did you? I hope not. I would not send my kids to the same school if you did.

Re:quick question

[Richard_at_work]

What you are describing is what I already described via method #2. If and only if they are able to add their root public key to the user's computer will their fraudulently issued certificates successfully validate.

Actually I wasn't, because you specifically said in #2 "Somehow maliciously insert their own public key onto your computer". Key there is "maliciously". No need to do that as most governments have legitimately issued root CA certs in most browsers already. Including China...

No need to maliciously insert anything, they are already there waiting to be used.

Re:quick question

[AmiMoJo]

A simple fix is to have the browser warn when a certificate changes. For user friendliness it might only warn when the change is well before the expiry date, or if the certificate provider changes etc. Any browser with millions of users would quickly detect suspicious changes that way.

Re:quick question

[AaronLS]

"Erm what do you mean 'if'? "

If you don't understand what a conditional statement is then you're an idiot. I'm sorry, I started that with "If" so you aren't going to understand that sentence either, so let me rephrase. You're an idiot.

"They DO have their own CA's added to all browsers. Lots of governments do."

I've never seen a major browser delivered with a known government CA. There have been cases where it has appeared that a CA began issuing fraudulent certificates, and it appeared to be under the influence of a government entity. You might claim those are one and the same, but a legitimate independent CA is indistinguishable from a CA that is acting on behalf of a government entity until it starts issuing fraudulent certificates.

Re:quick question

[welsh git]

Well, when I'm accessing my own sites, a self-signed certificate signed by *me* where the chain of trust stops *there* is preferable to a chain involving companies that operate under US jurisdiction ...

Expanding further, using someone elses self-signed site is more secure if there is a way to verify the key,... Yeah, I know... the whole purpose of CA's in the first place, but fatally flawed and past it's sell by date - only kept going by the money-making vested interests

Re:quick question

[welsh git]

No! You seem to be asduming that all self-signed certificates are bogus.

And even if they were, how does downgrading the site to http help?

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

[Zeroko]

I read it as "present self-signed HTTPS connections to the user like plain HTTP is now," rather than "reconnect via HTTP instead."

Re:quick question

[Joce640k]

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

True, but lets get everybody used to using https and get it enabled on all the servers.

Once that's done, THEN we can tackle the problem of who to trust with the certificates.

"The longest journey starts with a single step", etc.

Re: quick question

[LinuxLuver]

With Cisco involved, it would be inevitable. The only way to get this done securely would be locate it outside the United States and Five Eyes defacto police states. But then you risk being Kim Dotcom-ed.

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?

Re:quick question

[david_thornley]

From a theoretical standpoint, there is no 'more' or 'less' secure. If you're insecure, you're insecure.

You're insecure. There is no absolutely secure method of communication. One-time pads are subject to endpoint attacks, and Alice has no direct way of knowing that the public library system is holding Bob's WoW character hostage to coerce him into handing over his files.

If "secure" is to be used in a way that actually conveys some meaning, there are greater and lesser levels.

Re:quick question

[rioki]

So you think the NSA can not get a certificate issued from Verisign for any domain?

Re:quick question

[Demonoid-Penguin]

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?

Good point! Let's not do anything. Inaction is always the best course of action.

How can we work out if baby isn't still dirty? It could be - right? Therefore it's likely (sigh), and if it's likely - we'd better throw out the baby with the bathwater.
/. agressive armchair apathy - the new "insightful"

In other news there are rumours of a CA being broken into - or maybe it was several - or maybe someone with a few thousand just bought a fraudulent certificate. And those who can't/won't stump up a hundred dollars lower the standard
Lucky I'm just making this shit up
How could you possible check? (if only there was some sort of looky-uppy facts com-put-ah....)

How do we know you don't work for the NSA?
Looks like a duck, smells like a duck, got it's arse in the air like a duck....
Must be a weasel!

Re:quick question

[AK Marc]

That's a different question. The question was whether the government is a root CA. Whether they need to be to have control over one is an unrelated question.

Re:quick question

[AK Marc]

The complex fix is to delete all root certs, and allow sites on a per-site bases. This isn't used because, in practice, it's less secure than accepting the compromised CA's certs.

Re:quick question

[phantomfive]

I did. I went to the same school your kids are going to.

Re:quick question

[cheater512]

Err so your eyes have been closed? Or you are saying crap on the internet without actually looking at all?

Mozilla's CA list: https://www.mozilla.org/en-US/...

Quick search shows:
Spain
Turkey
Taiwan
Hong Kong
Japan
Netherlands
France

Re:quick question

[userw014]

It's the organizations that put strong controls over their staff use of desktop computers that do this when they generate an image. Those organizations that value micromanaging what their staff can do more than getting work done used to (and may still) block much of the internet, etc. and in that context of tightening everything down so much that the threads get stripped, managing the CA root list makes sense.

Re:quick question

[userw014]

It makes sense when you understand the trust model, but that takes some explaining and isn't as simple to "civilians" as "check to make sure that the site begins with 'https://' or look for the 'key' icon provided by your browser." (Asking them to verify the host/site part of the URL is the advanced part of the explanation.)

It's rather like teaching people how to cook by telling them "be careful of hot burners, pots, and pans", but that is what we in IT have been doing to "civilians".

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

[jbolden]

It isn't the encryption they would care about its you being comfortable consuming video privately. In particular people want privacy about their porn choices.

Re:CAcert

[fustakrakich]

They only want you to believe you have privacy. But whether you do or you don't won't make any difference in their market. Their market is the people who sell you your internet, and those people usually have monopolies in each respective region. This is a sham to pacify people over the NSA crap. I'm a little disappointed to see the EFF involved. Now I have to pay a bit more attention to their intentions, for instance, where are they going to compromise our interests when dealing with the big names?

Re:CAcert

[dargaud]

I used StartSSL a couple years ago when the first versions of HTTPS-Everywhere came out. Great. It worked. But then after a year you had to do the whole procedure again. Which I of course forgot to do. And since HTTPS-Everywhere doesn't revert to HTTP is the certificate lapses, all my visitors got was a 404 (or the https equivalent). Not really optimum. If this new scheme wants to take off, they need a way to renew automatically. Provide us with a shell script we can put in cron once a year and forget about it. Or something like that.

Re:CAcert

[jbolden]

They only want you to believe you have privacy. But whether you do or you don't won't make any difference in their market

True but you can't have at the same time:

1) A widespread belief there is privacy
2) The government violating that privacy through monitoring and frequently acting on the information

I'm a little disappointed to see the EFF involved. Now I have to pay a bit more attention to their intentions, for instance, where are they going to compromise our interests when dealing with the big names?

Or maybe the EFF was brought in so that a trustworthy system would be seen as trustworthy. They actually do intend to do the right thing.

Re:CAcert

[danbob999]

then why aren't they working with current CA to implement their protocol?

Re:CAcert

[fustakrakich]

They actually do intend to do the right thing.

They can't. There's too much secrecy in the system. If the companies want them there, it is strictly a facade of 'legitimacy' for the community to see. It is purely a ceremonial thing. May as well invite the Queen of England. I like the EFF a lot, but they're getting fished in. Whether or not they want to be used like this, I do not know. As I said before, this whole 'certificate' thing is only lipstick on the pig. Certificates look like tracking cookies to me. IP spoofing with proxy servers or whatever will give you more security and privacy. I sure as hell won't get that from any central authority.

1) A widespread belief there is privacy
2) The government violating that privacy through monitoring and frequently acting on the information

Yes, we are living with that contradiction right now. The elections confirm it. And we have to determine how to overcome it.

Re:CAcert

[jbolden]

There's too much secrecy in the system.

What secrecy that the EFF wouldn't see. A certification agency doesn't need secrecy. In theory the EFF could be the one to generate the private key and run that on a server they control. That might be an excellent way to build trust, that it runs on EFF hardware.

Yes, we are living with that contradiction right now. The elections confirm it.

How does the election confirm that we have: A widespread belief there is privacy and at the same time he government violating that privacy through monitoring and frequently acting on the information? I'm not following at all.

Re:CAcert

[petermgreen]

Most CAs are in the buisness of selling certs, startssl give some away for free but they clearly hope to upsell you to their paid offerings.

To get SSL everywhere it has to be trivial to get a cert, since we still lack a good micropayment system trivial basically means free. The existing CAs are not likely to help much with something that will disrupt their gravy train.

Re:CAcert

[danbob999]

We only need one CA, not many. And CAcert is non-profit / community based. Therefore I don't see what could be disrupted.

Re:Worth a shot

[HatofPig]

Yes, please. So many internet-based business models are built entirely on technical abstractions. So their is an interest in maintaining those structures as it, holding back progress. Social networks are one example. SSL certs are another. I'd rather used self-signed certs for my own stuff, but this is the closest thing that won't scare people away. We need progress, and if that means the obsolescence of some business models, so be it.

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!

[jdunn14]

I'm with you on your points, but can you cite when Phil Zimmerman was arrested? He was investigated back in the 90s and it was dropped without an indictment in 96 according to wikipedia.

No thanks...

[snarfies]

Its based out of the US and A.

As such, I have to assume it is pre-backdoored.

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.

Re:No thanks...

[fustakrakich]

A what?

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)?

Re:No thanks...

[danbob999]

There might not be one however I would trust many of them before the US. The top of the chart would be those of Scandinavia.

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:No thanks...

[toonces33]

They have computers there? Who knew!

Re:No thanks...

[lillgud]

Exactly what do you mean is backdoored?
This is a protocol for signing a certificate and anyone can view their proposal: https://github.com/letsencrypt...

Re:No thanks...

[Just Some Guy]

Given the parties involved, I don't. Mozilla Foundation and EFF are two groups I implicitly trust. That doesn't mean their proposal will be perfect, of course, but to me it means that their motives are good and that smart people are trying to do the right thing.

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:No thanks...

[Culture20]

Its based out of the US and A. As such, I have to assume it is pre-backdoored.

NSA has claimed the right of Prima Podex?

Re:No thanks...

[phantomfive]

Where do you think there's an honest government?

In the country made of honest people.

Re:No thanks...

[S.O.B.]

They have a TRS-80 in Pyongyang.

Re:No thanks...

[devman]

IMO, DANE is the best alternative. It requires trusting DNSSEC, but if combined with key pinning it could be much more effective than the security model in place today.

Re:No thanks...

[david_thornley]

If the NSA is after your communications, they'll get them. I don't worry about keeping secrets from them, because I have enough things to worry about that I can do something about. I am interested in countering lesser threats.

The NSA has to be dealt with politically, which isn't working real well right now.

Re:No thanks...

[JustNiz]

...because "clean politician" is an oxymoron. the politicians avoid pushing restrictions on the NSA in case the NSA leaks the dirt on them. ...so there really is nobody powerful enough to limit the NSA, even the government.

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!

Re:Fantastic.

[grim4593]

StartSSL offers free SSL certificates: https://www.startssl.com/

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

[Em Adespoton]

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.

Good question regarding root certs.

As for Iceland being far away from 5-eyes:
http://www.submarinecablemap.c...
Look at where the Iceland trunks go to -- hint: Canada and England are part of 5-Eyes
That, and the country closest to Iceland is....

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:Replace Cisco, and Akamai and then maybe..

[Burz]

"Lawful intercept" has entered the business models of Verisign and CISCO. I would not trust CISCO... http://www.forbes.com/2010/02/...

Not even an inch... http://arstechnica.com/tech-po...

Proper security on a network is properly done at the endpoints. Its doesn't belong anywhere else.

What is Mozilla thinking?? They could help fund Convergence.io. They could implement clever ways to get it to ride on existing social networks. They could look at network privacy layers that use public keys as addresses. There are options for improving privacy that don't involve elevating the PKi clusterf*ck any further.

Re:This is a huge first step!

[geekmux]

They put the inventor of PGP in jail - Phil zimmerman. Reason: simple transport encryption - even without trust - makes Fedzilla and its police state angry.

This would force the Fedzilla police state to obtain end-point warrants rather than be able to sniff the firehose.

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

This is an imperative first step.

I'm just curious here...what exactly makes you assume the government would have to prove a damn thing, even if what they are doing is illegal by our own Constitution?

Not sure what is feeding your delusions, but one thing is for certain. The government needing authority or approval to do anything to you legally or otherwise is complete bullshit.

And this "imperative" step means jack shit if the NSA has already been issued a cert.

Now prove they haven't, and you can have your first step back.

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.

Re:This is a huge first step!

[blue9steel]

True, but if you can raise the cost you cut the occurrence rate. There is no law preventing them from having police officers tail every citizen, they don't because it would be prohibitively expensive.

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.

Already done - startssl.com

[Anonymous Coward]

startssl.com already offers a free domain certificate. The only catch is if you need to revoke it costs $25 to do the revoke.

Now let me have my own CA for my personal domain example.com so I can sign as I want would be nice.

Re:This is a huge first step!

[Zeio]

I expect a lot of agents to come in and stump against transport encryption. I question why on earth you wouldnt want to make it harder to sniff. Even if there is a man in the middle possibility, they need a copy of every cert. Lugging around millions of certs and trying to apply them to every flow to see if you can get into that flow sounds a lot harder than not encrypting.

Shared hosting...

[The_Systech]

I see nothing in here about how they plan to address shared web hosting. To me that's always been more of an issue than the cost of the certificate.... Current implementations of SSL requires one certificate to be bound per IP address, and there is no "hostname" request from the browser like there is with HTTP. When I can pick up a certificate for less than $20 per year, the cost of the certificate is not going to hold me back... The fact that I can't install the certificate on my "Shared hosting" website, would however.

Re:Shared hosting...

[BradleyUffner]

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

Re:Shared hosting...

[omnichad]

A static IP for your shared host is usually cheaper than SSL. However, they're not going to let you use your free SSL and will charge you for their own SSL anyway, because they have the control.

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:Shared hosting...

[XanC]

If you can live with Android 2.x and IE on Windows XP being unable to connect, then there is a "hostname" equivalent request, and you can host multiple SSL sites on a single IP.

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

Re:Shared hosting...

[squiggleslash]

There are still quite a few mobile devices that don't. Still, time should fix that, one hopes...

Re:Shared hosting...

[Peter Eckersley]

We'll try to give site operators a configurable choice of multiple solutions -- certificates with multiple Subject Alternative Names (SANs); per-site certificates deployed using Server Name Indication (SNI); IPv4 addresses per site if you have enough; or IPv6 addresses per site.

All of these solutions have different problems and limitations:

• If mutliple-SAN certs get too large, they cause performance problems, and some clients may not be able to handle them
• SNI isn't supported by Safari and older IE on Windows XP, or more alarmingly by Android below 4.x
• IPv4 addresses are scarce and costly
• Many clients still can't route IPv6

  Sophisticated hosting platforms may want to use all of these methods in combination.

Re:Shared hosting...

[fnj]

A static IP for your shared host is usually cheaper than SSL. However, they're not going to let you use your free SSL and will charge you for their own SSL anyway, because they have the control.

Who is "they". The VPS I rent is shared (by me) to various parties - shared hosting. It's my VPS. I control its certificate. There is no "they".

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?

[NoKaOi]

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

So, the straw man you're referring to is the idea that if the NSA can break it, then it's useless?

Re:strawman?

[JustNiz]

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

Re:strawman?

[thegarbz]

Why should I care? The NSA is tracking my move. That's a given. However in terms of my own personal life should I be more afraid of the NSA reading my credit card number and emptying my account (they have this info already), or should I be afraid of some 15 year old script kiddy doing it?

Security has a lot of granularity between everyone can read anything I say, and uber security not even the NSA can hack.

Re:strawman?

[JustNiz]

I guess my real point is: assuming the NSA can already do it, how long will it be before the 15 yr old skript kiddy can download a tool from somewhere that does it too?

Re:Only half of the problem

[PRMan]

Referrer leakage is exactly why it matters.

Re:This is a huge first step!

[DarkOx]

Agreed,

I don't see this as much of a solution. The Grandparent is right transport encryption is a requirement but I am not sure its first step. encryption and authentication are part and parcel. One really isn't useful without the other and might be more dangerous alone than nothing.

At least with HTTP I *know* there exists the possibility what I am receiving isn't coming from who I thought it was from, may have been undetectably altered, and others know I am viewing it. Just as anything i send, might be altered or not go where i expect it to.

The big problem today is all those shitty domain validated certs, are cheap ticket to every spammer, fraudster in the world to appear legit.. Not to mention if I can find some stored-reflected-xss or even just content injection via iframe, or img tag on a legit site say "example.com, I register a name like uberCDN.com and host the sourced content at example.com.uberCDN.com and the typical victim user will have virtually no chance to detect anything is up..

Honestly we need to solve the trust problem as step 0, than we need encryption and integrity + authentication as step 1.

Identity?

[cant_get_a_good_nick]

I thought part of the reason for the cost of certs was the identity portion of the server. It's not just encryption, it's making sure that Citibank is Citibank not Bob DeHacker. I didn't see much talking about this, just about encryption.

At some point, somebody needs to pay for identity verification. Maybe a group of companies does it for free for a Better Net, but there will be a cost someplace.

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.

More technical issues than just CAs

[Hydrian]

There are more technical issues than just having a trusted CA in order to do HTTPS everywhere. The big issue is the legacy one certificate per IP:Port limitation. I know that is being resolved with SNI. Unfortunately that is going to take a while because both HTTP server _and_ clients need to updated to support this. Many of the current versions of the HTTP servers already support this. I've seen lots of mobile app HTTP clients that do not. Also what about some of the aging web servers/clients where the vendor has no plans up fix / upgrade them?

Sure but...

[fahrbot-bot]

...do we really need to encrypt the entire web? (It's like TV stations boasting that they broadcast the News in high-def. Seriously, it's the News.) Do I (should we) care if the traffic to/from many (most?) sites is encrypted? No.

What I'd rather have is sites not requiring a fuck-ton of Javascript, usually from other sites, to display anything or to work / navigate in even the simplest fashion. Content sites that use Javascript to display article text is particularly annoying.

Just my $.02.

Re:Sure but...

[Strider-]

Exactly. I work in an environment with very limited bandwidth (1.8Mbps private satellite link servicing ~80 people). SSL by default is the bane of my existence. Right now, I've got Cisco WAAS deployed, and it adds about another 30% of effective capacity to my link, and often more. If everything goes encrypted by default, then I lose all of that. I get no caching gain, no compression gain, nothing, unless I MITM the link, which is evil and causes no end of support headaches.

Encrypt what needs to be encrypted (Authentication mechanisms, financial transactions, etc...) and leave the rest. There's no reason to encrypt cute cat pictures or grandma's chocolate chip cookie recipe.

Won't existing CAs complain?

[swb]

Sure, they do business selling code-signing certs, wildcard and SAN certs but I have to believe that a not insignificant part of their business is selling boring, single-name certs for web servers.

If you can suddenly get SSL certs for your web server for free and have them work like a paid certificate (wide-spread browser and device support) won't a lot of people do just this?

Or will it be some kind of "we need support" thing where people keep buying them because of corporate policy and the "only" users will be hobbyists and tinkerers who had previously used self-signed certs or none at all?

Re:Won't existing CAs complain?

[petermgreen]

Some people will stick with the established CAs for better compatibility with older browsers or for the green extended validation bar. It's also not clear whether this service will support stuff like wildcard certs (heck it's not even clear right now how they are planning to validate certificate requests).

but yeah if this takes off it's going to be a tough time to be a CA.

Re:Won't existing CAs complain?

[petermgreen]

NM read in more detail, it seems they will be validating based on the ability to put a file on an unsecured webserver (which will make life a whole lot easier for a man in the middle close to the server).

Re:Won't existing CAs complain?

[denis-The-menace]

Yes they will. Just like cable companies, they will get the best laws that money can buy.

I predict in 10 years: money is privacy
No money == no Certs == No privacy

After all, money is speech (Thanks, you corrupt USSC!)
No money == STFU

Re:Won't existing CAs complain?

[swb]

Yes they will. Just like cable companies, they will get the best laws that money can buy.

When I posted my original comment I didn't think of this, but it's not hard to CAs to start claiming they provide a beneficial security service by validating certificate buyers, helping to keep bad guys from running encrypted web sites to sell drugs, defile white women and support terrorism.

Maybe they will agree to some kind of "national security compromise" that enables regulation of CAs and their continued monopoly status, of course in exchange for giving the NSA backdoor access.

Re:Won't existing CAs complain?

[thogard]

When your in the business of selling random numbers, don't be surprised when someone undercuts you.

Re:GoDaddy

[Em Adespoton]

However,, a more reputable company like SquareSpace might be convinced to do something like that. From what I've seen, GoDaddy seems to have stopped trying to do things for the public good almost a decade ago.

Re:Do we still need shared web hosting?

[omnichad]

For a certain level of technical competence, I suppose that makes sense. But there's a big RAM hit to have a CPanel instance for each customer, so the beginners would save a lot of resources to be on the same server instance.

Fix the problem properly

[DrXym]

Let sites create their own keys and sign them (or not) by anyone they feel like. This could include CAs but equally it could include other sites they do business with to build a web of trust. And the browser should use SSL observatory to compare and cache these keys and present a simple checklist of what protection the site has against attack, its level of trust etc.

The existing model is broken by the fact that CAs are not always trustworthy, the certs they issue to most sites are worthless as tokens of trust and the whole mechanism is a tax on security. It needs all browser makers to knock heads and make CAs for security an optional thing. Yes some sites like banks or whatever might want to pay some CA to audit their security procedures for storing a cert. For most sites it's complete overkill.

So many comments worried about NSA...

[Rashkae]

So I'm just going to send everythign in plain text instead. That'll show em.

If you need true secure communications, in as much as any such might be possible, there are other solutions for that, which don't involve any kind of central authority. (As soon as you have a central authority, you have the weakest link of attack for a larger target.)
This is encryption for everyone else, so passwords aren't being sent in the clear willy nilly by everyone who connects to their favorite sites from public wifi spots, (as an example of a real potential problem with today's security practices.)

That being said, I think they are wrong about this being the missing piece... if it were that easy to use https everyone would at least be using self signed certs by now. The standard has to be updated to reflect the reality of shared IP virtual domains. And why no TLS for http traffic yet? Even if there is no authorative signing, the web browser could then at least warn you if the cert of the a kown server suddenly changes, indicate potential MIM.

Re:So many comments worried about NSA...

[Rashkae]

Replying to my own comment, reading some of the other comments that were posted since mine, I see have some reading up to do on this new fandangled SNI thing.. That's one problem barrier down :)

Obviously the NSA should do this

[nedlohs]

They are the encryption experts after all, who better to trust for your SSL certificate needs?

So how much power will this use?

[Maury Markowitz]

Any estimates on how much power will be needed to run the crypto so a bunch of static web sites can put an S in the URL?

Re:So how much power will this use?

[kingbyu]

Indeed, there is a lot of traffic on the web that has no need to be private. This slashdot page for example. But encrypting communications takes extra CPU cycles, and extra CPU cycles take extra energy, and will require more servers. Sure there is a lot of web traffic which should be encrypted, but the rest of it shouldn't be, for the sake of the environment and for the sake of that battery powered device in my pocket.

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.

Re:So how much power will this use?

[cbhacking]

Actually, there's a pretty damn good reason why Slashdot *should* be private:

You (and I) are logged into this site. That means a unique identifier tied to our Slashdot accounts is sent to the server (in a cookie) with every request we make. This lets Slashdot know who we are, primarily for when we post a comment. The problem is, this unique identifier is sent in plain text; anybody on the same network as you or anywhere in the network between you and Slashdot's servers can see it.

Now, I don't know about you, but it's not *that* hard to get from my Slashdot identity to my real name. I assume everything I post here can be traced back to me. I'm OK with that; if I wanted to post something privately (and for some reason didn't want to post AC) I'd create and use a throwaway account, possibly via TOR + an additional proxy redirect at an Internet café or something (Slashdot blocks known TOR exit nodes, if I recall correctly). However, just because I'm OK with the posts I make being traceable to me does *not* mean I'm OK with just anybody who wants to posting in my name.

Right now, if you and I were on the same local network (wireless or wired), I could use techniques such as ARP spoofing or DNS poisoning to intercept every HTTP request you send to Slashdot, an every response it sends you. I could extract your authentication cookie and use it to make requests that Slashdot would think come from you and would post under your username. I could even have an excellent chance to steal your password; all I would have to do is modify Slashdot's responses to make it look like you aren't signed in. Then, when you go to the login page (which normally sends your password via HTTPS, but is itself served over HTTP), I use a technique called SSL Stripping to modify the login form so that it submits your password over plain-text HTTP (I could then submit that password to Slashdot over HTTPS, as it expects). Now I have your username and password, I can modify your account, I can post as you, and odds are you don't even know you were compromised.

None of that even requires any special skill, not even basic coding. The tools to do it all are pre-built and available for free download.

Re:So how much power will this use?

[kingbyu]

OK, I'll give you that: in order to be a logged in user or to post comments, the connection should be encrypted. But there is no reason I should need SSL just to view the page. One could argue that on an unsecured connection, I could be shown content that didn't really come from the slashdot servers. But I don't trust anything I get from slashdot anyway.

Re:"Proper" certificates to the wrong people?

[amaurea]

I think they might do something like this: You run a program on your server. That program establishes an encrypted connection to the Let's Encrypt server (using normal SSL). The Let's Encrypt server sends a secret message over the encrypted channel. The program on your server sets up a web page with that secret on it and sends the URL back to over the encrypted connection. The Let's Encrypt server then accesses the given URL normally, and checks whether it contains the correct secret. If so, it issues a certificate for the host name contained in that URL, since you have proved that you were in control of that server.

This is immune to man-in-the-middle attacks on your side, but it would still be vulnerable to somebody who can intercept all of the traffic to the Let's Encrypt server. But perhaps they're doing something cleverer than what I describe here. (If you had multiple Let's Encrypt servers spread across the internet, then you could have multiple ones participate in the handshake. That would mean that somebody would have to intercept the traffic of all those servers in order to fool them.)

Why do this (free, easy SSL certificates)?

[userw014]

Why do this?
So that:

• (1) App developers get used to designing and testing with https/SSL instead of gluing it in at the last minute AND GETTING IT WRONG
• (2) to encourage encryption and privacy, and to make the use of https/SSL less likely to distinguish between valuable communication and noise

Why not do this?
Because it:

• (A) makes the value of the https signifier on a URL / browser bar nearly worthless
• (B) will encourage App developers to send even more information to poorly secured servers
• (C) prevent researchers from determining what privacy-violating information an App is sending

What might happen because of this?
It will:

• (i) break the already weak link between certificates and the organizations they represent.
• (ii) kill the business model of the certificate authorities
• (iii) result in another somewhat meaningless revision of the "verified" certificate

Overall, it might work out well - but I doubt that App developers are going to bother so the major good reason will be ignored. App developers will STILL get it wrong, and even if they do set up https, that'll just encourage them to pass even more sensitive information to poorly secured APIs.

Re:Why do this (free, easy SSL certificates)?

[cbhacking]

A) WTF do you mean, "nearly worthless"? It'll mean what it does today: the connection is secured using SSL/TLS. Nothing more and nothing less. HTTPS isn't some special indication that a site is Serious Business or something. It just means that an eavesdropper can't listen in on the connection or intercept the traffic. If you *REALLY* think there's value in that distinction, though, Extended Validation certs (green URL bar) will still exist to take money from people like you.
B) Vaguely possible, but not something I'm really worried about. If their server is so insecure that the data they send is easily exposed, then they probably wouldn't have cared about what data they were or were not sending in the first place. Besides, that's *still* better than having *all* the data (including authentication data) be sent in plain text!
C) Bullshit. There are many ways around that. The easy (obvious, to anybody who knows anything about the subject) one is to fake up your own CA, install its certificate, and use a proxy server that serves up faked certs signed by your faked up CA. Burp Suite and Fiddler (two common web proxy tools, the first of which is explicitly intended for web security testing) already support doing this and have supported it for years.

i) How do you think it'll do that? The technique these people are using to authenticate domain ownership is better than what some existing "trusted" CAs use...
ii) Cry me a fucking river. The world will not miss them.
iii) See previous points, including the ones that express "WTF are you talking about?".

Authority: I've been in the information security and penetration testing profession, including lots of tests of web apps, web services, and mobile apps, since 2006.

Re:Why do this (free, easy SSL certificates)?

[userw014]

• (A) Nearly worthless because a lot of the advice given out to "civilians" is that "https" can be trusted, "look for the lock", etc. More subtle advice (like check the URL, don't mistake "1" for "l" or "0" for "O", etc) are advanced techniques (at least for too many civilians.) Charging for SSL certificates - and the turnaround time it takes to issue them, install them, etc. meant that a certain class of quick-and-fast scams weren't practical. Cheap, fast, easy to install SSL certificates make this easier, thereby making the "https" indicator less valuable. (In short, use of "https" to "trust" a site is a gross mistake - but a mistake IT people have been advising civilians to do.)
• (C) I'm not a security researcher, I know a little about running a CA. A faked up CA isn't going to help someone trying to figure out what an App is trying to send over a SSL session, unless they're somehow able to replace the certificate and key in the App. Of course, a web app isn't going to have a certificate and key - but a smartphone/tablet app might.
• (i) On this, I think you're arguing that the CA system is even more broken than I am. I won't protest that.
• (ii) I'm not going to cry - but if there's enough money involved, Congress will do something stupid.
• (iii) I'm talking about "Extended Validation" certificates - which were an enhancement (via. another X.509 attribute) that suggested that the issuing CA did some due diligence (other than verifying that a credit card accepted a charge.) Whether the CA actually followed the guidelines is another matter. Is there a way for an outsider to audit this 'Extended Validation' for a particular Certificate? Without that, "Extended Validation" is just a way for CAs to charge more money.

Apps

Re:This is a huge first step!

[phantomfive]

It's always good to be technically correct!

Re:Only half of the problem

[daniel23]

Slashdot doesn't support utf, it doesn't support ipv6. To config https would be inconsistent then.

Re: Worth a shot

[corychristison]

I own a web hosting business. I resell certificates. I keep my prices pretty low ($10CAD for Comodo PositiveSSL, $12CAD for RapidSSL). I do this to try to push the notion that you need to encrypt everything. I'm currently planning to start giving them away with hosting packages, when paid annually.

With that said, I really don't care if technology carries us another direction and I lose those sales. I don't really make much on them anyway ($4-5 per cert).

I really like the idea of DNSSEC and DANE. From my understanding, about the only way around it would be to breach the registries.

Re:This is a huge first step!

[TheGratefulNet]

I'm with you; I have given up believing that our government is good and is trying to do the Right Thing(tm).

they are now more concerned with covering their asses and collecting all info they can 'just in case' they need it. more CYA, really.

parallel reconstruction is a horrible thing, but they use it and so they don't care about laws anymore.

what this has done is make us, the citizens, ALSO not care about the laws. I dont' think they realized this would be the effect, but I see it, in modern attitudes. especially in the young. they don't believe our government is good or trustable anymore and that our laws are corporate self-interest based.

what goes around, comes around. and that's what bothers me the most. the 'arms race' between the gov and the citizens is growing and not de-escalating.

each generation has said 'the world is going to hell in a handbasket' but this time, they really are right.

sadly, I don't see a reversal. ;(

What about SSL proxy appliances

[Richard_J_N]

What do we do to defeat SSL proxying, where there is an "official" MITM? For example, a Bob uses a web browser on his work computer, which trusts an SSL proxy appliance, because Eve (sysadmin) installed that cert into all browsers on the office machines. Alice (as the server-operator) wants to protect Bob (who doesn't know any better) from this. Key fingerprinting would allow Bob to discover this, but how can Alice verify this?

How will they get other browsers to support this?

[jonwil]

Being backed by Mozilla, Firefox will obviously support it, as will SeaMonkey and Thunderbird (since they use the same set of certs as Firefox from the same NSS tree). But how will they get the other big browser vendors to support it? In particular Microsoft (you can bet VeriSign will be using its very close relationship with Microsoft to lobby hard for MS not to support this in IE)

The informative URL

[manu0601]

Here is the informative URL, which explains how validation and automation is handled: https://letsencrypt.org/howitworks/technology/

Schneier says

[Pascal Sartoretti]

I didn't know what to exactly think about this, then I saw what Bruce Schneier says about it:

This is an absolutely fantastic idea.

Good enough for me.

Naive much?!

[meimeiriver]

Did anyone ever consider that this project is already in the NSA's pockets? Or, if not, that coercing this new authority (under terrorists laws, and NDA) will only make it 10x easier for the NSA to break into any communication, just busting the balls of a conveniently single cert authority?! Sigh. Anyone in support of this proposal either works for the NSA, or is a blithering idiot deserving of daily monitoring.

Re:This is a huge first step!

[Zeio]

By the way, the EFF is backing this encryption effort. Good to see moderation quality here is right inline with the oligarchical collectivist snowden-chasing "Google NSA AOL Time Warner Taco Bell US Government"