Let’s Encrypt Now Being Abused by Malvertisers(blog.trendmicro.com)
blog.trendmicro.com
Let’s Encrypt Now Being Abused by Malvertisers
http://blog.trendmicro.com/trendlabs-security-intelligence/lets-encrypt-now-being-abused-by-malvertisers/
70 comments
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.
>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.
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.
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.
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?
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.
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)".
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. :/ )
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 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 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.
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.
> 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?
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.
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.
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.
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.
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.
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.
Title should read "Let’s Encrypt Now Being Used by Malvertisers"
If someone gains access to a subdomain and is able to place files there, THAT is the problem, not being able to request a certificate for it.
To quote both Ford and Raymond Chen: "It rather involved being on the other side of this airtight hatchway"
If someone gains access to a subdomain and is able to place files there, THAT is the problem, not being able to request a certificate for it.
To quote both Ford and Raymond Chen: "It rather involved being on the other side of this airtight hatchway"
As a certificate authority ourselves
That says it all, really. This isn't the first time other CAs have attempted to stop LE:
https://news.ycombinator.com/item?id=10685458
That says it all, really. This isn't the first time other CAs have attempted to stop LE:
https://news.ycombinator.com/item?id=10685458
IMO the problem is more "attackers who have gained the ability to create subdomains under a legitimate domain" (not explained how) than Let's Encrypt.
There are sites that do this as part of their core ui, such as deviantart.
Yes, although the subdomains still point to deviantart's servers. The difference here is that ad.example.com ends up pointing to the attacker's server.
Because LetsEncrypt needs a very specific response to be served from a specific endpoint, you need this kind of total control to validate a domain and get a certificate issued.
Because LetsEncrypt needs a very specific response to be served from a specific endpoint, you need this kind of total control to validate a domain and get a certificate issued.
https://letsencrypt.org/howitworks/technology/#domain-valida...
There's a bit more to it than "allowing subdomain creation". You will need control over the DNS records, or ability arbitrarily change the page (essentially).
There's a bit more to it than "allowing subdomain creation". You will need control over the DNS records, or ability arbitrarily change the page (essentially).
I don't understand. How is it being "abused"? If the attacker has actual DNS access to create ad.{legitimate domain}.com, then Let's Encrypt is working as intended. So what if they're hosting malware—that's {legitimate domain}.com's problem.
Let's Encrypt has absolutely nothing to do with content behavior safety, only domain validation and encryption to keep data away from prying eyes.
This title is no different from "Chairs Now Being Abused by Criminals". It's nonsensical and completely unrelated. Do you care that criminals have started using chairs to sit down (gasp)? I don't think this even belongs on Hacker News.
Let's Encrypt has absolutely nothing to do with content behavior safety, only domain validation and encryption to keep data away from prying eyes.
This title is no different from "Chairs Now Being Abused by Criminals". It's nonsensical and completely unrelated. Do you care that criminals have started using chairs to sit down (gasp)? I don't think this even belongs on Hacker News.
In their attempt at shaming Let's Encrypt, only Trend Micro has been shamed.
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"
It had nothing to do with SSL, the attacker had full control of a subdomain and the attack would have still worked without it. -> The final "it" should presumably refer to SSL, but in this construct it refers to "control".
I say “could” because in that not everyone is aware of -> lose "in that" ?
Until all CAs are required to log all of the SSL certificates they issue into CT Logs and add are required to CAA -> Not sure of your intent here. "And CAA records are required before requesting certs"?
Also, your quotes from the original article render for me (in firefox) as single-line textboxes with scrollbars. Maybe you can change it to force automatic wrapping?
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"
It had nothing to do with SSL, the attacker had full control of a subdomain and the attack would have still worked without it. -> The final "it" should presumably refer to SSL, but in this construct it refers to "control".
I say “could” because in that not everyone is aware of -> lose "in that" ?
Until all CAs are required to log all of the SSL certificates they issue into CT Logs and add are required to CAA -> Not sure of your intent here. "And CAA records are required before requesting certs"?
Also, your quotes from the original article render for me (in firefox) as single-line textboxes with scrollbars. Maybe you can change it to force automatic wrapping?
thanks, fixed everything but the quotes.
This is not an issue, just FUD from Trend Micro.
I'm unclear about what the problem is.
So the traffic is encrypted. How does that make anything worse?
It seems pretty irrelevant to me if it's encrypted or not.
So the traffic is encrypted. How does that make anything worse?
It seems pretty irrelevant to me if it's encrypted or not.
Indeed, trendmicro doesnt say anything about that. Let's Encrypt says "The concern most commonly expressed is that having valid HTTPS certificates helps these sites look more legitimate, making people more likely to trust them."
I agree with Let's Encrypt position, they are not to blame here.
https://letsencrypt.org/2015/10/29/phishing-and-malware.html
https://letsencrypt.org/2015/10/29/phishing-and-malware.html
Exactly. This false notion of security was perpetuated by CAs for marketing purposes. It's their fault if users now mistakenly think HTTPS == trustworthy.
They basically sold certs as something they're not and now complain that people may realize they don't actually serve that purpose now that they're made widely available without the false pretences.
They basically sold certs as something they're not and now complain that people may realize they don't actually serve that purpose now that they're made widely available without the false pretences.
Not 100% sure, but if the malicious ad is put on an HTTPS page, it would not be possible to load additional scripts and data from an un-encrypted (HTTP) location as opposed to another valid HTTPS location. Having your malware on an HTTPS site goes around the browser's mixed content restrictions.
You could just as easily register a separate domain and use HTTPS on that if your goal is to inject scripts in the background. The "problem" being reported here is that the user may think the site is not going to send them malware because it has a green padlock in the address bar
Maybe because it can't be automatically detected by some layer 7 firewall filters/web proxies.
Although some seem a bit squeamish about it, any good firewall/filtering solution should do SSL MITM --- especially now that encrypted connections are becoming the norm.
Given that Trend Micro themselves provide AV software that does this, it's particularly ironic since it's already no problem for them to decrypt and scan encrypted traffic. It's likely just their CA division that dislikes Let's Encrypt.
Given that Trend Micro themselves provide AV software that does this, it's particularly ironic since it's already no problem for them to decrypt and scan encrypted traffic. It's likely just their CA division that dislikes Let's Encrypt.
Here is a more complete explanation of Let's Encrypt's views on the subject.
https://letsencrypt.org/2015/10/29/phishing-and-malware.html
https://letsencrypt.org/2015/10/29/phishing-and-malware.html
There were already free automatically-validated CAs before Let's Encrypt.
> As a certificate authority ourselves
This pretty much invalidates the entire argument. TLS is not about making things look more legitimate. If anything, CLAs are to blame for marketing TLS as something it's not.
Let's Encrypt is doing the right thing here, Trendmicro is part of the problem.
This pretty much invalidates the entire argument. TLS is not about making things look more legitimate. If anything, CLAs are to blame for marketing TLS as something it's not.
Let's Encrypt is doing the right thing here, Trendmicro is part of the problem.
I havent used Lets Encrypt, but other CAs would validate the owner of the TLD by sending an email to hostmaster. You wouldnt be able to have certificates issued on a subdomain unless you are verified as owner of the TLD. Is this not the case here, and if not, why not?
This is one of many verification mechanisms other CAs offer. A lot of them also offer verification via DNS TXT record, or by placing a file under a certain path and verifying it's being served via HTTP. Let's Encrypt is definitely not the first to offer any of those, and they are in line with the CA/B Baseline Requirements under which CAs operate.
DNS TXT records I can also agree with, as its as secure as email in the respect that it uses the same potential vector for spoofing.
File verification (which I haven't seen as an option with the multiple CAs I have used) is an alternate vector. It may be in line with the CA/B Baseline Requirements, but by removing this they would likely eliminate this threat.
This is a serious problem
p.s. I note that this "content change" verification mechanism is mentioned as point 6 under 3.2.2.4 of the Baseline requirements. It is entirely feasible that when these documents were written this particular issue wasn't considered. How would one go about repealing this particular point, and thus forcing CAs to comply.
File verification (which I haven't seen as an option with the multiple CAs I have used) is an alternate vector. It may be in line with the CA/B Baseline Requirements, but by removing this they would likely eliminate this threat.
This is a serious problem
p.s. I note that this "content change" verification mechanism is mentioned as point 6 under 3.2.2.4 of the Baseline requirements. It is entirely feasible that when these documents were written this particular issue wasn't considered. How would one go about repealing this particular point, and thus forcing CAs to comply.
WoSign is one of the other CAs offering this option.
It is unclear to me how TXT verification would have prevent this. The article indicates that the attackers created the subdomain and pointed it at a server they controlled; this means DNS was compromised and creating a TXT record wouldn't have been a problem.
Domain owners which are worried about Let's Encrypt can opt to create a CAA DNS record that limits CAs allowed to issue certificates to ones they trust.
CA/B BR can be found here[1].
[1]: https://cabforum.org/wp-content/uploads/Baseline_Requirement...
It is unclear to me how TXT verification would have prevent this. The article indicates that the attackers created the subdomain and pointed it at a server they controlled; this means DNS was compromised and creating a TXT record wouldn't have been a problem.
Domain owners which are worried about Let's Encrypt can opt to create a CAA DNS record that limits CAs allowed to issue certificates to ones they trust.
CA/B BR can be found here[1].
[1]: https://cabforum.org/wp-content/uploads/Baseline_Requirement...
I simply see it as an additional (and unnecessary) attack vector.
If you are unable to hijack the DNS servers or poison/spoof the cache used by the CA, then you have the luxury of a whole new (and often WAY more insecure) attack surface. Then you have a cert for that domain which can be used for other, more targeted purposes.
EDIT: IGNORE BELOW, I WAS ASSUMING THAT LETS ENCRYPT LETS YOU VALIDATE SUBDOMAINS FROM THE TLD, BUT THIS DOEST SEEM TO BE THE CASE FROM THE DOCS.
e.g.
1) Wifi access point uses https://login.wifiprovider.com to authenticate users. This is clamped down as tight as possible. Theres no way i'm getting in to that beastie.
2) Their brochure site located at http://www.wifiprovider.com. It was made by some ad agency and probably allows you to log in with test/test or uses some crappy custom CMS that allows SQL injections or even allows you to log in with a "wildcard" password... (this is INSANELY common). Its just a brochure site, and its not linked to the super-secure login systems in any way.
3) By breaking into this crappy brochure site, I can get a cert from a valid CA for the subdomain https://login.wifiprovider.com that allows me to sit at an access point, spoofing DNS and capturing valid login details.
That doesn't seem right to me.
If you are unable to hijack the DNS servers or poison/spoof the cache used by the CA, then you have the luxury of a whole new (and often WAY more insecure) attack surface. Then you have a cert for that domain which can be used for other, more targeted purposes.
EDIT: IGNORE BELOW, I WAS ASSUMING THAT LETS ENCRYPT LETS YOU VALIDATE SUBDOMAINS FROM THE TLD, BUT THIS DOEST SEEM TO BE THE CASE FROM THE DOCS.
e.g.
1) Wifi access point uses https://login.wifiprovider.com to authenticate users. This is clamped down as tight as possible. Theres no way i'm getting in to that beastie.
2) Their brochure site located at http://www.wifiprovider.com. It was made by some ad agency and probably allows you to log in with test/test or uses some crappy custom CMS that allows SQL injections or even allows you to log in with a "wildcard" password... (this is INSANELY common). Its just a brochure site, and its not linked to the super-secure login systems in any way.
3) By breaking into this crappy brochure site, I can get a cert from a valid CA for the subdomain https://login.wifiprovider.com that allows me to sit at an access point, spoofing DNS and capturing valid login details.
That doesn't seem right to me.
No, with Let's Encrypt you would have to have full control over contents of login.wifiprovider.com to get a certificate for that domain. Specifically, you'd have to be able to serve a token at
http://login.wifiprovider.com/.well-known/acme-challenge/random
Thanks. I was assuming it would work the same as other CAs in that respect.
I'm still not sure about this mechanism of verification, but good to know that my example scenario cant exist.
I'm still not sure about this mechanism of verification, but good to know that my example scenario cant exist.
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.
Banks and employers should just teach users to look for green icon near the URL, not just a padlock.
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 <somedomain>.co.uk ? Or the various other TLD that are 2-level deep already ? I believe it's impossible to implement this properly.
There's a huge suffix list that browsers use to control things like cookie scope:
https://en.wikipedia.org/wiki/Public_Suffix_List
https://publicsuffix.org/
Probably includes https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom...
https://en.wikipedia.org/wiki/Public_Suffix_List
https://publicsuffix.org/
Probably includes https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom...
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
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... )
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
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... )
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/
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/
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.
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.
[deleted]
In other news, guns are used to kill people.
There are peolpe that are really suprised? This was expected.
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 DoubleClick redirect
Which is yet another example of how irresponsible advertisers are creating huge attack surfaces.
From the blog they link to:
It sounds like doubleclick is sending out the harmful redirect. Maybe they should verify URLs instead of blindly believing the query params?
LOL
> These DV certificates can help the hacker gain legitimacy with the public.
How? "The public" probably doesn't even know what a DV certificate is.
It doesn't look like Let's Encrypt is even involved in any of the actual problems that enable this attack.
> As a certificate authority ourselves
... I guess that explains this hit piece ... /sigh/