Hacker News Reader

Comment by aftbit | Hacker News Reader

>Let’s Encrypt only checks domains that it issues against the Google safe browsing API; in addition, they have stated that they do not believe CAs should act as a content filter. Security on the infrastructure is only possible when all critical players – browsers, CAs, and anti-virus companies – play an active role in weeding out bad actors.

I agree strongly with Let's Encrypt's view. They should not be responsible for policing the behaviour of their certificate users. They should just ensure that they only issue certificates for validated CNs.

View on HN

In fact it's not more of an abuse of let's encrypt than it is an abuse of the linux, apache and openssl used to host these malicious websites. All of which are doing their job. The domain owner is the one not doing his.

Exactly, their statement has been made in October already: https://letsencrypt.org/2015/10/29/phishing-and-malware.html

That statement did not contain anything on other kinds of reports. They do have an email address for reporting certificate abuse. So far, I have not been able to find any public statements on how they will handle that.

>> in addition, they have stated that they do not believe CAs should act as a content filter.

Isn't that what they exactly do when they check the safe browsing API?

There is a way to avoid this issue: Let's Encrypt should disallow subdomain registrations unless a TXT record is present for the parent domain. For example, if I wanted to get a certificate for bar.foo.example.com there would need to be a Let's Encrypt TXT record for foo.example.com.

Although it's not their responsibility, they can take steps to mitigate it.

Why is this something they should do? If I have complete control over a subdomain bar.foo.example.com, why do I need cooperation from the parent foo.example.com in order to set up something basic like an SSL certificate?

Because A records don't mean complete control over domains.

There is a difference between "I can serve content under this domain (currently)" and "I control this domain (and can decide where it points)".

DNS domain validation is the right way to do domain validation. But it's slightly harder for users, which is why HTTP(s)- or E-Mail-based validation is being done more often.

> There is a difference between "I can serve content under this domain (currently)" and "I control this domain (and can decide where it points)".

Agreed. However, I have a hard time believing that it's a net win to make it impossible for people who are permitted to control the machines that a DNS record points to, but are not permitted to alter that DNS record and/or anything under it [0] to get a cert from Let's Encypt.

[0] Or are -perhaps- using a DNS hosting provider that doesn't let you add TXT or CNAME records. (I've used such a sorry provider in the past. :/ )

But consider an attacker who pivots onto your entire infrastructure to serve any content they desire. Presumably your DNS provider passwords are stored in a password manager outside of that infrastructure. The attacker would still need to use social engineering to trick the CTO into revealing those passwords. It seems that would have prevented the abuse in the OP, right?

> But consider an attacker who pivots onto your entire infrastructure to serve any content they desire.

I mean, if we're talking about a situation where an attacker controls your webserver, then that's pretty much game over, right? They can read and write to everything your server can, including SSL private keys, SQL databases, etc., etc., etc...

> Presumably your DNS provider passwords are stored in a password manager outside of that infrastructure. ... It seems that would have prevented the abuse in the OP, right?

Doing DNS-record-alteration-only verification would have prevented the scenario described in TFA, yeah. But, there are a couple of things to consider:

* DV certs provide nothing more than HTTPS, without the scary "THE BROWSER DOESN'T RECOGNIZE THIS CERT ISSUER!!11" dialog. They don't provide the additional UI cues that EV certs do. So, their phishing utility is rather limited.

* Society as a whole benefits far more from thwarting passive dragnet surveillance than it does from putting roadblocks in the way of occasional unauthorized and unwanted issuance of a DV cert to someone who has improperly (effectively) gained control of someone else's web server or DNS zone.

* TFA is primarily a scare-piece from a traditional CA <strike>that's likely sad that their revenue stream from DV issuance is going to vanish.</strike>

Ugh. I actually got off my ass and did some research... it seems that Trend Micro doesn't issue DV certs. [0] Mea culpa.

[0] http://esupport.trendmicro.com/solution/en-US/1097653.aspx

I can serve using HTTP on this domain should be enough to prove you can also serve HTTPS on this domain though.

It's on the domain owner to avoid giving away control of their (sub)domain to a malicious party. Exactly the same as with regular HTTP and anything else that uses DNS.

It's not about proving that you can serve HTTPS, it's about proving that you can legitimately serve HTTPS.

I'd find HTTP(S)-based validation ok if CAs wouldn't issue certificates with an expiration time past the expiration time of the DNS records.

Of course that would be fairly impractical. But then DNS-based validation exists and doesn't have these problems.

What is the difference between serving HTTPS and "legitimately" serving HTTPS? Or to put it another way, what qualifies as "illegitimate" HTTPS?

Because this happened:

> Website owners should ensure that they secure their own website control panels, to ensure that new subdomains beyond their control are not created without their knowledge.

You're a bank and haven't secured your DNS control panel correctly. Someone comes along, and using your vulnerable DNS, registers logon.bank.com (instead of login.bank.com). Now it is the bank's fault to begin with, but end-users are going to see that green padlock and will get pwned. You can point fingers all you want at the bank but that situation could (and should) have been avoided.

Let's Encrypt could be seen as a "vulnerability amplifier." With the previous PKI, even if you gained authority over logon.bank.com you wouldn't be able to get that green padlock in the title bar. There is a very good chance that someone at the CA would have made a phone call to someone at bank.com. With the current Let's Encrypt approach this scenario becomes plausible because no check is made with the parent domain to find out exactly how paranoid it is about subdomains.

Nobody is blaming Let's Encrypt, but they can help.

It's completely unclear whether what you're saying is factually correct. If the attacker controls the bank's DNS, which seems likely given that they're able to create an A record for a subdomain, they can likely also add TXT records for bank.com, which is what traditional CAs often use to verify ownership. They could probably also modify MX records to redirect confirmation emails to a server under their control.

Other CAs don't have a magic solution that automatically detects malicious domains. Issuance of DV certs is completely automated at any major CA. There is no manual review unless the domain is on some kind of grey- or blacklist, and I highly doubt that they have a list of every domain used by a bank. There have been numerous counts of unauthorized certificates being issued by almost all CAs, what makes you think they're somehow that much more smarter than Let's Encrypt on this topic?

The green padlocks are only for EV certs. Let's Encrypt doesn't do EV certs (nobody automatically issues those). There's a reason why browsers visually distinguish between EV certs and DV certs, and it's because DV certs don't indicate anything at all beyond the fact that the cert owner is able to serve HTTPS at a given domain.

Or perhaps do it the other way around? Make a Let's Encrypt subdomain-blacklisting TXT record with which the parent domain could indicate that they don't want subdomain owners to be able to create their own SSL certificates. (Useful in the case of hosted web services, for example, where the parent already owns a wildcard certificate so there's no reason for the subdomain to create one)

This is already possible using CAA DNS records, which can be used to define which CAs should be permitted to issue certificates for a domain.

That's great. But according to https://tools.ietf.org/html/rfc6844, this is quite recent, and not standardized yet.

Do you have any information on which CA's already support this, or whether Let's Encrypt (intends to) support this?

I'm still hoping for DANE to gain traction, though. Not necessarily as a replacement for CA's; there is value in thorough, third-party validation of certificates, but not within the current ecosystem.

Yes, Let's Encrypt does support CAA. Not sure about other CAs.

In this case someone got a legitimate subdomain A record in DNS... your solution would not add much to the situation.

Encrypting everything has consequences.

I recently had an IoT pairing issue between two devices. A normal human will not run wireshark to troubleshoot a pairing failure between two devices. I did. I was rewarded with a shitty protocol that could not be evaluated for errors and a moderated support forum that encouraged me to reboot my router.

Taken to its extreme conclusion- there are important networking problems that are amplified if we encrypt all the packets.

Sometimes, I feel like the EFF is composed of idealistic teenagers with limited understanding of how the world outside of their first hop works. I generally support them, but it is always at arms length.

And buckling up your seat belt has consquences. You cannot danse the way you used to on your seat and 1 time out 1000, it actually makes the accident more violent.

Still, you should use the seat belt. All the time.

That's what MITM proxies are for... but I do agree that devices with encrypted traffic, without any means of its owner inspecting it, can be a significant threat.

Of course, not encrypting and authenticating between the devices lets any other compromised device on your network interpose itself in that pairing and do whatever it likes with your IoT devices.

Reply on news.ycombinator.com