Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let’s Encrypt Now Being Abused by Malvertisers

blog.trendmicro.com

Post reply on HN
Print view View original

61–70 of 71 posts

Re: Let’s Encrypt Now Being Abused by Malvertisers

#61

Post by pdkl95 »

roblabla wrote: post #15
Animats wrote: post #7

As a CA, Let's Encrypt should only be issuing certs to second level domains. If they want to issue one to a subdomain below that, there should be a check that the second level domain approves.

What about .co.uk ? Or the various other TLD that are 2-level deep already ? I believe it's impossible to implement this properly.

While I think it is a bad idea to limit which domains can use TLS in an ad hoc style, this issue with stuff like example.co.uk was solved in DNS a long time ago.

One of the main features of DNS is the ability to delegate authority for a zone. You use a NS record on a valid name that where you have authority to indicate that some other server is authoritative for a given subset of your zone.

If you bought example.com, you can create DNS records like

    subdomin.example.com. 172800 IN NS ns1.example.com
to indicate that ns1.example.com is the authority for the entire subdomain.example.com zone. This includes all further nesting of .subdomain.example.com.

Instead of guessing* who is responsible for a zone, you should simply ask the nearest upstream zone authority.

Also, relying on lists is almost always the wrong solution - if your security requires you to successfully enumerate something, you are doing it wrong. ( http://www.ranum.com/security/computer_security/editorials/d... )

Re: Let’s Encrypt Now Being Abused by Malvertisers

#62

Post by pfg »

pdkl95 wrote: post #61
roblabla wrote: post #15

Earlier quoted context omitted.

What about .co.uk ? Or the various other TLD that are 2-level deep already ? I believe it's impossible to implement this properly.

While I think it is a bad idea to limit which domains can use TLS in an ad hoc style, this issue with stuff like example.co.uk was solved in DNS a long time ago. One of the main features of DNS is the ability to delegate authority for a zone. You use a NS record on a valid name that where you have authority to indicate that some other server is authoritative for a given subset of your zone. If you bought example.com,…

What you're saying is true, but in the context of CAs, it's still important to be able to distinguish real public suffixes from regular authority delegations for subdomains. CAs need to be able to filter and block CSRs for wildcard names like *.co.uk or something similar. This also applies to things like cookie scopes in browsers. Currently, the Public Suffix List is your best bet here.

The Dbound WG[1] is working towards a standardized solution that doesn't require enumeration in a centralized list but rather works through DNS records. This should eventually replace the PSL, although I suspect most use cases will still rely on some kind of preload list (similar to HSTS) in addition to that.

[1]: https://tools.ietf.org/wg/dbound/

Re: Let’s Encrypt Now Being Abused by Malvertisers

#63

Post by btown »

simoncion wrote: post #46
Ao7bei3s wrote: post #38

Earlier quoted context omitted.

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 Enc…

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?

Re: Let’s Encrypt Now Being Abused by Malvertisers

#64

Post by ycmbntrthrwaway »

I needed to create valid HTTPS certificate once, as a project to setup MITM proxy and test various applications verification of domain. I just created an account on https://www.startssl.com/ with totally fake identity, found some place to register a free domain and got a certificate at zero cost within a few hours. Maybe Let's Encrypt makes it easier to automate, maybe they need to add a CAPTCHA (what for?), but the possibility of creating valid HTTPS certificates for malicious uses was already there.

Banks and employers should just teach users to look for green icon near the URL, not just a padlock.

Re: Let’s Encrypt Now Being Abused by Malvertisers

#65

Post by solidninja »

jmuguy wrote: post #56
pdkl95 wrote: post #32

> gained the ability to create subdomains under a legitimate domain As lots of people in this thread have already pointed out, that's the security problem. The DNS zone that was delegated to you, then you have a responsibility to keep the "squatters" away. > Traffic to this created subdomain was protected with HTTPS Good. HTTP is obsolete. That doesn't change anything from the perspective of the victim. > an open Dou…

As evidenced by the comments here, the people that count, that is system admins and developers, don't see a problem. Just more FUD from the traditional security players trying to remain relevant.

I finally created a HN account just to say the same thing. The security problem is that of the website itself and its choices of advertisers, not of the CA.

Re: Let’s Encrypt Now Being Abused by Malvertisers

#66

Post by eridius »

Ao7bei3s wrote: post #59
corobo wrote: post #47

Earlier quoted context omitted.

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?

Re: Let’s Encrypt Now Being Abused by Malvertisers

#67

Post by rmhrisk »

tremon wrote: post #58
rmhrisk wrote: post #9

My post responding to this - https://unmitigatedrisk.com/?p=552

Thanks for that response. It is well-written and transparently constructed. That said, you're reading quite a bit more agenda and polemic in TrendMicro's post than I did. Possibly because you've seen this kind of post before :) If you can allow me a bit of proofreading, there are a few typo's in the article: [..] that said it is can be summarized as: -> lose the "is" Maybe the then the issue is -> lose the first "the…

thanks, fixed everything but the quotes.

Re: Let’s Encrypt Now Being Abused by Malvertisers

#68

Post by eridius »

zamalek wrote: post #45
eridius wrote: post #27

Earlier quoted context omitted.

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

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.

Re: Let’s Encrypt Now Being Abused by Malvertisers

#69

Post by Animats »

pfg wrote: post #62
pdkl95 wrote: post #61

Earlier quoted context omitted.

While I think it is a bad idea to limit which domains can use TLS in an ad hoc style, this issue with stuff like example.co.uk was solved in DNS a long time ago. One of the main features of DNS is the ability to delegate authority for a zone. You use a NS record on a valid name that where you have authority to indicate that some other server is authoritative for a given subset of your zone. If you bought example.com,…

What you're saying is true, but in the context of CAs, it's still important to be able to distinguish real public suffixes from regular authority delegations for subdomains. CAs need to be able to filter and block CSRs for wildcard names like *.co.uk or something similar. This also applies to things like cookie scopes in browsers. Currently, the Public Suffix List is your best bet here. The Dbound WG[1] is working to…

There's an authority delegation problem where "example.com" wants to delegate "adblaster.example.com" to some ad service. The owner of "example.com" needs to approve this, but the party named in the certificate is not "example.com", but the AdBlaster service.

On the other hand, since this feature is used almost solely for advertising, there's no reason Let's Encrypt should offer this service for free. Let the ad guys buy those certs from Verisign and verify them with both parties manually.

Re: Let’s Encrypt Now Being Abused by Malvertisers

#70

Post by tracker1 »

zamalek wrote: post #20
aftbit wrote: post #5

>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 f…

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.

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