Hacker News new | ask | show | jobs
by ohiovr 3038 days ago
Whats the deal with letsencrypt? If anyone can get a certificate for the domains I own, it can't stop man in the middle attacks. How is this any better than a self signed cert which throws a hissy fit when you visit? Thats a browser issue to me not an inherant technical advantage. Anyone can get a cert from it including criminals. Google sometimes makes the news when they revoke a cert authority because of criminal activity (I think). How often do people check under those locks to see what it is? Google.com at a wifi hotspot could be something completely different and you'd not know. I'm sure I'll look like a fool when someone explains it to me.
4 comments

Let's Encrypt just like every other certificate authority validates that you own the domain before giving you a cert. They do that by sending a request to the domain from their servers (via looking up the nameservers via domain registries) and validating the response matches a unique message generated.

You could impersonate google.com on wifi, but you couldn't get a valid cert for google.com because you don't own the nameservers or any of the servers that google.com points to.

Thank you! So I'm using a cable modem with a dynamic IP. All someone needs are access to the updater program and credentials to impersonate my domain. So certs are fine and all, as long as those little numbers at the name server never change. I'm a just a hobbyist. Just asking questions, don't mean to offend anyone...
Thats your problem
> If anyone can get a certificate for the domains I own, it can't stop man in the middle attacks.

You're right, if that were the case, it would be terrible!

Luckily, it's not: to get a certificate for your domain, I need to either control your domain, or control the computer that the domain points at. In either case, you have much bigger problems than certificate issuance.

Lets Encrypt only verifies that the entity requesting the cert basically has control of the domain.

I would agree that the biggest issue with TLS is the certificate authorities. All the trust lies in them. If they issue a bad certificate for google, microsoft, usbank ect... It can cause problems. This is part of the reason HTTP key pinning exists. Further, CAs have issued bad certs. It's happened and will happen again.

However, there are a lot websites that in theory do not need TLS. However, the browsers are preventing HTTP only sites from using newer features. For instance HTTP 2.0 does not require TLS, but none of the browsers support plain text HTTP 2.0. (So the browsers are ignoring the standard)

So why do the browsers push so hard for TLS. As this article mentions MITM. Considering how complicated the web standards for CSS, JS, and HTML are these days. There is a potential attack vector. So in theory an attacker could insert content on the page your viewing that uses a zero day exploit. However, I think people are forgetting it's probably easier to get people to just visit a website with the exploit via some click baity title.

The next reason is that it prevents people from snooping on other people. However, a website that displays the time for instance is not really that big of issue. However, there is content people view that they would not like someone else knowing. Although, the DNS system can give that away if the website is topical in nature. However, I would not call this insecure as the browsers do. Really it should be noted that the content your viewing may be observed. However, that is not a security issue unless the site is serving private information. At that point the server operator is screwing up.

Really, if the user can't verify (does not know how) and does not verify the certificate it's not secure. It's more likely to be secure. Even if the user verifies the certificate if the server or user's computer is compromised the encryption is good as non-existent. If your worried about the user loading any scripts with any possible exploits Java-script probably should be removed the web standards. As I mentioned it's not hard to get users to view a site with some payload taking advantage of an exploit.

Part of the problem is that we have everyday people using the web more and more these days. They don't know necessarily know when they should be worried about security. However, what is annoying me more for instance with HTTP 2.0. I can't go into Firefox's about:config and enable plain text HTTP 2.0. I can agree with sane defaults, but really I should be able to change those.

> For instance HTTP 2.0 does not require TLS, but none of the browsers support plain text HTTP 2.0. (So the browsers are ignoring the standard)

H2 requires TLS for practical reasons; without it, poorly-written transparent proxies mangle this protocol that they don't understand. Requiring SSL was the solution to this otherwise intractable problem during the initial SPDY work, and became a hard requirement for SPDY. But due to pressure from certain groups during the IETF standardization process (who didn't want the web to "go dark"), this requirement from SPDY was dropped in the official HTTP2 spec.

But dropping the requirement from the spec doesn't solve the problem that put it there in the first place. You still can't reliably use any protocol newer than HTTP/1.1 unencrypted with many ISPs. It's been demonstrated to fail in ways that are difficult to debug and which would otherwise make HTTP2 seem unreliable. So no consumer-facing implementation will let you try.

Technically any CA can sign certificates from bad actors, letsencrypt is notable because they verify you own the domain automatically, and they do so for free.. I know of no issues in the ACME protocol.

That said, any CA can sign anything and your browser will trust it in most* cases.

* - Not under certificate pinning or CA pinning though.

Consider the scenario where I own a domain example.com for a year. Just a day before its expiry or just a day before I sell the domain to someone else, I obtain a certificate for it from letsencrypt via ACME protocol.

A week or month from now, the new owner of the domain sets up a HTTPs website. With the old certificate I have, I can now launch an MITM attack on the new owner for about 2-3 months!

You can perform exactly the same attack with a 1-year certificate from any other CA.
The answer to this is ultimately ratcheting down cert validity duration. As more people automate renewals we can get to the point where certs are valid for maybe days at a time.