An interesting thing happened at a meet-up at Square last year. Someone from google's security team came out and demonstrated what google does to notify a user that a page has been compromised or is a known malicious attack site.

During the presentation she was chatting about how people don't really pay attention to the certificate problems a site has, and how they were trying to change that through alerts/notifications.

After which someone asked that if google cared so much about security why didn't they just become a CA and sign certs for everyone. She didn't answer the question, so I'm not sure if that means they don't want to, or they are planning to.

What privacy concerns should we have if someone like goog were to sign the certs? What happens if a CA is compromised?

If I'm running a single web app on a single Ubuntu server using Apache then I'm set! If I'm running multiple web apps across multiple servers using a load balancer, nginx on FreeBSD then...

All the same I'm really looking forward to this coming out, it can be nothing but good that all of these companies are backing this new solution and I'm sure it'll expand and handle these issues as long as a good team is behind it.

This is huge if it takes off. The CA PKI will no longer be a scam anymore!!

I'd trust the EFF/Mozilla over a random for profit "security corporation" like VeriSign any day of the week and twice on Sunday to be good stewards of the infrastructure.

However, it doesn't do anything about the very serious problems with the CA system, which is fundamentally unsound because it requires trust and end users do not meaningfully have the authority to revoke that trust. And there's a bigger problem: if EFF's CA becomes the standard CA, there is now another single point of failure for a huge portion of the web. While I personally have a strong faith in the EFF, in the long term I shouldn't have to.

The certificate authorities are quite in love that the self-signed certificate errors are turning redder, bolder, and bigger. A self signed certificate warning means "Warning! The admin on the site you're connecting to wants this conversation to be private but it hasn't been proven that he has 200 bucks for us to say he's cool".

But so what if he's cool? Yeah I like my banking website to be "cool" but for 200 bucks I can be just as "cool". A few years back the browsers started putting extra bling on the URL bar if the coolness factor was high enough - if a bank pays 10,000 bucks for a really cool verification, they get a giant green pulsating URL badge. And they should, that means someone had to fax over vials of blood with the governor's seal that it's a legitimate institute in that state or province. But my little 200 dollar, not pulsating but still green certificate means "yeah digitalsushi definitely had 200 bucks and a fax machine, or at least was [email protected] for damned sure".

And that is good enough for users. No errors? It's legit.

What's the difference between me coughing up 200 bucks to make that URL bar green, and then bright red with klaxons cause I didn't cough up the 200 bucks to be sure I am the owner of a personal domain? Like I said, a racket. The certificate authorities love causing a panic. But don't tell me users are any safer just 'cause I had 200 bucks. They're not.

The cert is just for warm and fuzzies. The encryption is to keep snoops out. If I made a browser, I would have 200 dollar "hostmaster" verification be some orange, cautious URL bar - "this person has a site that we have verified to the laziest extent possible without getting sued for not even doing anything at all". But then I probably wouldn't be getting any tips in my jar from the CAs at the end of the day.

1. I really hope this is hosted in a non-FVEY territory.

2. Why can't we set a date (say, 5 years?) when all browsers default to https, or some other encrypted protocol, and force you to type "http://" to access old, unencrypted servers?

There's a scenario (simplified for illustration, but entirely possible) that's normally not a huge risk because there are many CAs, and they are private, for-profit companies that have an economic incentive to protect you and your certificate's ability to assure end users that a conversation's privacy won't be compromised.

1) browser requests site via SSL

2) MITM says, "let's chat - here's my cert"

3) browser asks, "is this cert legit for this domain?"

4) MITM says, "yes, CA gave us this, because of FISA, to give to you as proof"

5) browser says, "ok, let's chat"

I'm not trying to spread FUD, but if you're NSA and you've been asking CAs for their master keys for years, doesn't a single CA sound great (free and easy == market consolidation), and doesn't EFF seem like the perfect vector for a Trojan horse like this, given its popularity and trust among hacker types gained in recent years?

While we're at it, let's get a non-profit domain registrar going.

>Put a CA-provided challenge at a specific place on the web server

or

> Put a CA-provided challenge at a DNS location corresponding to the target domain.

Since the server will presumably be plaintext at that point and DNS is UDP, couldn't an attacker like NSA just mitm the proof-of-site-ownership functionality of lets-encrypt to capture ownership at TOFU and then silently re-use it, e.g. via Akamai's infrastructure?

[0] https://github.com/letsencrypt/acme-spec/blob/master/draft-b...

"A recovery token is a fallback authentication mechanism. In the event that a client loses all other state, including authorized key pairs and key pairs bound to certificates, the client can use the recovery token to prove that it was previously authorized for the identifier in question.

This mechanism is necessary because once an ACME server has issued an Authorization Key for a given identifier, that identifier enters a higher-security state, at least with respect the ACME server. That state exists to protect against attacks such as DNS hijacking and router compromise which tend to inherently defeat all forms of Domain Validation. So once a domain has begun using ACME, new DV-only authorization will not be performed without proof of continuity via possession of an Authorized Private Key or potentially a Subject Private Key for that domain."

Does that mean, if for instance, someone used an ACME server to issue a certificate for that domain in the past, but then the domain registration expired, and someone else legitimately bought the domain later, they would be unable to use that ACME server for issuing an SSL certificate?

[0] https://github.com/letsencrypt/acme-spec/blob/master/draft-b...

This new SSL scheme is mostly security theater. There's no particular reason to encrypt traffic to most web pages. Anyone with access to the connection can tell what site you're talking to. If it's public static content, what is SSL protecting? Unless there's a login mechanism and non-public pages, SSL isn't protecting much.

The downside of SSL everywhere is weak SSL everywhere. Cloudflare sells security theater encryption now. All their offerings involve Cloudflare acting as a man-in-the-middle, with everything decrypted at Cloudflare. (Cloudflare's CEO is fighting interception demands in court and in the press, which indicates they get such requests. Cloudflare is honest about what they're doing; the certificates they use say "Cloudflare, Inc.", so they identify themselves as a man-in-the-middle. They're not bad guys.)

If you try to encrypt everything, the high-volume cacheable stuff that doesn't need security but does need a big content delivery network (think Flickr) has to be encrypted. So the content-delivery network needs to impersonate the end site and becomes a point of attack. There are known attacks on CDNs; anybody using multi-domain SSL certs with unrelated domains (36,000 Cloudflare sites alone) is vulnerable if any site on the cert can be broken into. If the site's logins go through the same mechanism, security is weaker than if only the important pages were encrypted.

You're better off having a small secure site like "secure.example.com" for checkout and payment, preferably with an Extended Validation SSL certificate, a unique IP address, and a dedicated server. There's no reason to encrypt your public product catalog pages. Leave them on "example.com" unencrypted.

What's Cisco's role in this? I'm quite worried about that. It has been reported multiple times that Cisco's routers have NSA backdoors in them, from multiple angles (from TAO intercepting the routers to law enforcement having access to "legal intercept" in them).

So I hope they are not securing their certificates with Cisco's routers...

I do a lot of custom stuff and want to run my own server. I can set up and run the server in maybe 50-100 lines of code, and it works great.

I know, I should conform and use Apache/nginx/OpenSSL like everyone else. Because they're so much more secure, right? By using professional code like the aforementioned, you won't get exposed to exploits like Heartbleed, Shellshock, etc.

But me, being the stubborn one I am, I want to just code up a site. I can open up a socket, parse a few text lines, and voila. Web server. Now I want to add TLS and what are my options?

OpenSSL, crazy API, issues like Heartbleed.

libtls from LibreSSL, amazing API, not packaged for anything but OpenBSD yet. Little to no real world testing.

Mozilla NSS or GnuTLS, awful APIs, everyone seems to recommend against them.

Obscure software I've never heard of: PolarSSL, MatrixSSL. May be good, but I'm uneasy with it since I don't know anything about them. And I have to hope they play nicely with all my environments (Clang on OS X, Visual C++ on Windows, GCC on Linux and BSD) and package managers.

Write my own. Hahah. Hahahahahahahahah. Yeah. All I have to do is implement AES, Camellia, DES, RC4, RC5, Triple DES, XTEA, Blowfish, MD5, MD2, MD4, SHA-1, SHA-2, RSA, Diffie-Hellman key exchange, Elliptic curve cryptography (ECC), Elliptic curve Diffie–Hellman (ECDH), Elliptic Curve DSA (ECDSA); and all with absolutely no errors (and this is critical!), and I'm good to go!

I'm not saying encryption should be a breeze, but come on. I want this in <socket.h> and available anywhere. I want to be able to ask for socket(AF_INET, SOCK_STREAMTLS, 0), call setsockcert(certdata, certsize) and be ready to go.

Everything we do in computer science is always about raising the bar in terms of complexity. Writing software requires larger and larger teams, and increasingly there's the attitude that "you can't possibly do that yourself, so don't even try." It's in writing operating systems, writing device drivers, writing web browsers, writing crypto software, etc.

I didn't get into programming to glue other people's code together. I want to learn how things work and write them myself. For once in this world, I'd love it if we could work on reducing complexity instead of adding to it.

There have been previous attempts, e.g. http://www.cacert.org/

AFAIK they failed in the politics front (getting accepted in mainstream browsers). Sounds like EFF might have better leverage.

There aren't a whole lot of privacy concerns with CA's as long as you use OCSP stapling, so users browsers aren't hitting up the CA each time they visit a website (Chrome never does this but other browsers can do).

Re: CA compromise. One reason running a CA costs money is that the root store policies imposed by the CA/Browser Forum require (I think!) the usage of a hardware security module which holds the signing keys. This means a compromised CA could issue a bunch of certs for as long as the compromise is active, but in theory it should be hard or impossible to steal the key. Once the hackers are booted out of the CA's network, it goes back to being secure. Of course quite some damage can be done during this time, and that's what things like Certificate Transparency are meant to mediate - they let everyone see what CAs are doing.

NB: This is a bit unfair, because the existing for-money CAs haven't always stopped someone from registering microsoft.com.

But it's not like MITM attacks are not real. CAs don't realistically do a thing about them, but it is true that you can't trust that your connection is private based on TLS alone. (unless you're doing certificate pinning or you have some other solution).

That being said: Identity verification is important as the encryption is worthless if you can be trivially man-in-the-middled. All encryption assures is that two end points can only read communications between one another, it makes no assurances that the two end points are who they claim to be.

So verification is a legitimate requirement and it does have a legitimate cost. The problem is the LOWEST barriers to entry are set too high, this has become a particular problem when insecure WiFi is so common and even "basic" web-sites really need HTTPS (e.g. this one).

Domain validation is done through a challenge (issued by a CA) to sign arbitrary data and put on a URL (covered by the domain) the CA can then query. This seems pretty solid. Better then email.

I think it's about time for a free CA that is recognized by all clients, but you still need to establish a trust chain to exchange a CSR for a signed certificate. This service needs to be server agnostic. The barrier to adoption isn't configuration, and HTTPS isn't the only thing that uses certificates.

- Obtain a browser-trusted certificate and set it up on your web serve

IdenTrust is listed as a sponsor and is the CA for the letsencrypt.org certificate so I'm guessing they're doing some sort of partnership.

First, TLS has three principles that, if you lose one, it becomes essentially uselsss:

1) Authentication - you're talking to the right server

2) Encryption - nobody saw what was sent

3) Verification - nothing was modified in transit

Without authentication, you essentially are not protected against anything. Any router, any government can generate a cert for any server or hostname.

Perhaps you don't think EV certs have a purpose - personally, I think they're helpful to ensure that even if someone hijacks a domain they cannot issue an EV cert. Luckily, the cost of certificates is going down over time (usually you can get the certs you mentioned at $10/$150). That's what my startup (https://certly.io) is trying to help people get, cheap and trusted certificates (sorry for the promotion here)

no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on".

Treating this as a grave error IMHO is right because by accepting the connection over SSL, you state that the conversation between the user agent and the server is meant to be private.

Unfortunately, there is no way to guarantee that to be true if the identity of the server certificate can't somehow be tied to the identity of the server.

So when you accept the connection unencrypted, you tell the user agent "hey - everything is ok here - I don't care about this conversation to be private", so no error message is shown.

But the moment you accept the connection over ssl, the user agent assumes the connection to be intended to be private and failure to assert identity becomes a terminal issue.

This doesn't mean that the CA way of doing things is the right way - far from it. It's just the best that we currently have.

The solution is absolutely not to have browsers accept self-signed certificates though. The solution is something nobody hasn't quite come up with.

How does having _fewer_ CAs make anything easier? Why is the EFF a better route than any of the various other companies that have gotten themselves in the CA program? And given that all the CAs are equivalently trusted at a technical level, why does the human trust afforded the EFF affect whether it's a better target?

http://www.certificate-transparency.org/

There's also HPKP, TACK, and DANE, plus the prospect of having more distributed cert scans producing databases of all the publicly visible certs that people are encountering on the web.

Browsers will be able to check any cert signed by the Let's Encrypt CA against the published list. If there's a discrepancy, that will be immediately detectable.

Let's Encrypt is only planning to issue DV certificates, since that is the only type that can be issued in a fully automated way. Many organizations will want something other than DV, and they'll have to get such certs from other CAs.

Also, our software and protocols are open so that other CAs can make use of them.

What you're talking about is being introduced alongside DNSSEC, and it's called DANE.

https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

We'll be doing quite a bit of work based on user feedback between now and when we go live. We're well aware that we need to cater to a variety of types of users.

And pretty much every major government directly or indirectly controls one or multiple CAs that are in the standard set.

Now, if there was a project in Iceland or Seychelles that was doing something similar, I would be much more apt to participate.

domain squatters are already an issue. imaging if you could register domains for free. I think having to pay $10 for a year is pretty fair. That's one reason I don't mind paying ~$70 for .io domain. it keeps most squatters away.

While probably not officially scriptable, free certificates have been available since a long time ago: https://www.startssl.com/?app=1

Also, no free wildcard certs. Which I really want.

> What happens if a CA is compromised?

Looking at past compromises, if they have been very irresponsible they are delisted from the browsers' list of trusted roots (see diginotar). If they have not been extremely irresponsible, then they seem to be able to continue to function (see Comodo).

https://en.wikipedia.org/wiki/DigiNotar#Refusal_to_publish_r... https://blogs.comodo.com/uncategorized/the-recent-ra-comprom...

(1) You can do the attack you describe today with existing CAs that are issuing DV certs because posting a file on the web server is an existing DV validation method that's in routine use.

(2) There is another validation method we've developed called dvsni which is stronger in some respects (but yes, it still trusts DNS).

(3) We're expecting to do multipath testing of the proof of site ownership to make MITM attacks harder. (But as with much existing DV in general, someone who can completely compromise DNS can cause misissuance.)

(4) If the community finds solutions that make any step of this process stronger, Let's Encrypt will presumably adopt them.

What's especially baffling about self-signed certificate advocacy is the implied threat model. Low- and mid-level network attackers and crime syndicates can't compromise a CA. Every nation state can, of course (so long as the site in question isn't public-key-pinned). But nation states are also uniquely capable of MITMing connections!