[umaguma]

Is the lure of letsencrypt that

1 it's accepted without warning in browsers or

2 it lets users ignore learning how to use the openssl binary (or writing their own tools with libssl, polarssl, etc.) to generate ca and site keys, certs, csr's, crl's, etc., or

3 both?

Here, the author appears to benefit mainly from 1.

Assuming letsencrypt does not do any sort of commercial CA-type "verification" then why do they need to be a CA? Why does one need an account?

Answer: browsers clinging to CA system.

Why not just get browsers to drop the warnings for self-signed certs?

The goal here, I thought, is to facilitate encrypted traffic, not to give a false sense of "authentication", correct?

Encryption and authentication are two different things.

Every user should understand that.

[teraflop]

Telling the browser to accept all self-signed certificates is a bad idea, because it's no more difficult for an attacker to create one of those than the legitimate domain owner. Let's Encrypt has at least two huge immediate benefits:

1) It does challenge-response domain validation from an external server. It's not enough for an attacker to intercept and modify traffic between the client and server -- they also have to control the route between the server and LE. This isn't an infallible check but it dramatically raises the difficulty of an attack, especially if the check is done from multiple independent locations.

2) LE supports Certificate Transparency, which means they verifiably log all certificates that they issue to multiple third-party observatories. Even if an attacker can bypass domain validation, they can't actually get a certificate without immediately making it obvious that they've done so, giving the server operator the chance to revoke the certificate and investigate (if they're paying attention).

[umaguma]

It sounds like domain registrars are being used to supplant the role of CA's?

This reminds me of the situation with email where if a user has not purchased a domain name, then it is nearly impossible for the user to send or recieve email without a third party "email provider".

Will encryption become the same? If at least one endpoint has not signed up with some third party (e.g., letsencrypt) _and_ purchased a domain name, then it becomes nearly impossible for two endpoints to encrypt traffic between them?

Will we ever again allow users to be fully empowered, _without the involvement of third party endpoints_ (CA's, domain regstrars, etc.), to send email, encrypt traffic, and all the other basic things one can do with a computer and an internet connection? Is it unfathomable that two parties connected to the internet might actually know and/or trust each other already, without involvement of a third party interloper?

Those are meant to be yes or no questions, or perhaps a rhetorical ones. No need to provide rationale. :)

[Vendan]

almost anyone can set up trivial end to end encryption using any number of methods without relying on outside agencies. SSH, VPN, PGP, the list goes on. The issue is getting a HTTPS cert trusted by the general public, which is a much harder problem. Before letsencrypt, you had to pay a CA to issue you a cert. For a DV cert, they verified that you had permission to get a cert through a small number of ways. Most involved just getting an email through the whois entry for your domain, or setting a specific entry in DNS. Those aren't any more "secure" then letsencrypt's methods. If anything, a letsencrypt cert is arguably MORE secure, as it only lasts 3 months, so the domain needs to be rechecked more often.

[ketralnis]

You can encrypt between end points using self signed certs or your own CA just fine, but without the CA system you'll need some other way to prove that the signer is who you think they are. This could be a phone call or whatever other method you like

[umaguma]

Yes! You got it!

[nly]

Where can I run queries against these verifiable logs for my domain?

[clinta]

https://crt.sh/?Identity=%25&iCAID=7395

[nly]

The allure over other DV CAs is that it's gratis, and, soon, that it'll be deployable at the push of a button.

DANE-TA or DANE-EE still would have been better than any and all of this DV public CA nonsense. A DV cert from a public CA proves that someone on the other end of the connection momentarily controlled either the DNS records for your domain, or your web server, at some point in the near past. That's it.

DV is an extremely weak proof of identity, and provides no authentication at all (as in, proof that the issue was actually authorised by the domain owner).

[Jasper_]

Doesn't LetsEncrypt require that you have DNSSEC enabled on your domain, as a first step? DV is a valid proof of identity, assuming DNSSEC, right?

[nly]

No, DNSSEC isn't required. LetsEncrypt supports a bunch of DV methods right now[0], but the bottom line is that if someone can control either your DNS server or your web server (any web server on an IP at which your domain points) then they can always get a certificate for your domain. This applies to all DV cert issuance from most CAs afaik.

Full DNSSEC verification by the issuing CA (LetsEncrypt) still wouldn't mitigate attacks against the "Simple HTTP" method.

[0]https://letsencrypt.github.io/acme-spec/#rfc.section.7

[lukas2511]

Well, there are two major reasons why I think letsencrypt is great right now.

One thing is that it just works, it's a trusted CA and there is no bullshit "please install this cert" stuff.

The other thing is the automatisation. There were some CAs with free certificates before, but you had to manually click around in a webinterface, manually put a file on a webserver or copy an ID from an email, or whatever to verify that you are the owner of the domain. This process often took from around 30 minutes to several hours, while the acme-protocol is designed to handle validation in seconds, and it actually works. You can start a new project, send of the signing command, and in seconds you'll have a certificate.

[Jasper_]

TLS is a system designed to support both authentication and encryption. Losing authentication is actually a pretty big deal, so of course browsers won't do it.

Encryption without authentication isn't really a good idea, because you can trivially MITM someone, serve them your certificate for google.com, open up a connection to google.com yourself, and it's now effectively as good as plain-text.

The security community was really upset with SuperFish and the recent Dell eRoot for the same reason -- you effectively lost accurate authentication, making it pretty easy to degrade someone's connection to plain-text.

[umaguma]

"... because you can trivially MITM someone..."

This assumes the user is relying on certificates for authentication. Certificates that are likely tied to domain names.

What if the user authenticates by another means? SSH keys, real life meeting and exchange of keys, keys printed on paper and sent in the postal mail, etc. No domain name involved.

There are other ways to authenticate an endpoints besides domain names and certificates.

It's possible to have encryption without authentication.

It's also possible to have each of encryption and authentication handled by a different program. What we have now are programs that try to do both, and may do a very bad job of one at the expense of the other. These programs provide a false sense of "security".

The fundamental question: Are domain names easier to MITM than IP addresses?

[Vendan]

It authenticates the same thing most ssl certs do. That you have control over the domain. Self-signed certs don't do that, so a letsencrypt cert is actually more secure then a self-signed cert.