There could also be potentially valid cases for paypal in a domain, like “dont-use-paypal.com” or “paypal-is-awful.com” or something similar. Someone may even want one of those domains to have perfectly valid SSL too.
How could a CA tell? What’s to stop me from creating paypal.mysite.com, filling it with blog posts critiquing paypal’s business practices, and then once I get a cert for it, replacing it with a phishing site?
All a CA can do is verify that the person requesting a cert for a given domain name controls the domain. Constantly auditing the ‘worthiness’ of a cert-holder’s domain would be an enormously impractical burden.
The “major CAs” that the article talks about will gladly issue me a certificate for wildcard subdomains. There is nothing new about this problem with Let’s Encrypt. A cert for, say, *.*.mysite.com will let me serve paypal.com.mysite.com.
Indeed, wildcard certificates are only supported for the first level subdomain. See, eg, RFC2818, section 3.1:
Matching is performed using the matching rules specified by
[RFC2459]. If more than one identity of a given type is present in
the certificate (e.g., more than one dNSName name, a match in any one
of the set is considered acceptable.) Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., .a.com matches foo.a.com but
not bar.foo.a.com. f.com matches foo.com but not bar.com.
Of course, you can just buy a certificate for *.com.mysite.com, which lets you do the same thing.
You pose that as if they’re equivalent, but it’s not really the case, is it? Domain registrars have issued invalid certificates used for evil, yes. But is it quite so prevalent as with LE?
The point jcs is trying to make, I believe, is that the domain registrars allowed someone to register the domains in the first place. For DV (domain validation) certificates, it is only verified that you own the machine at the IP address the DNS for that domain points to.
Yes. And LetsEncrypt is willing to do that for every domain and subdomain that you can show you control the DNS for. So if you own blahdz.com, you can get a signed cert for blahdz.com. If your dns server has a subdomain like house.blahdz.com, or vacation.house.blahdz.com, you can get certs for those too. It’s really convenient, and its free!
You can even get one for paypal.com.blahdz.com if you were to put that in your DNS. Register www.paypal.com.signin-country.US.blahdz.com and you can make a really convincing looking fake paypal login screen link, with a little green padlock and everything. Pretty shady!
The article claims that certs for deceptive server names like that have been issued 988 times by Let’s Encrypt. So… maybe we shouldn’t trust Let’s Encrypt? Especially if they aren’t willing to do this one little thing to protect users, Right? Think of the harm LE is causing!
…or you could consider that 988 questionable certs is only 0.003% of the 30 million certs that LE has issued so far.
…and that the author of the article works for a place that sells certs for living, “The SSL Store”.
…and that outfit sells, for $65 a year, the same thing that LE has given 30M of away for free.
So yes, it is absurd. Phishing is certainly shady, but the SSL bussiness is a bit shady too. Its an entrenched cash cow with a vested interest in making sure that users continue pay for the privilege of that little green lock. Otherwise, they would be issuing singing certs, and every domain would already have an SSL certificate.
The problem is not that LetsEncrypt issued those certificates. It’s that we taught people that they should look for the green lock to tell whether a website is legitimate.
I think he means that people think that if the green lock is there, that the website is somehow more “trustworthy”. When in fact, it’s just a measure of connection security. So someone sees the green lock on https://we-steal-from-your-paypal-account.mysite.com and thinks that means it is “trustworthy”. Most people I know have no idea what the green lock means other than “it’s good to look for when I online bank”.
Most modern browsers do attempt to also convey information the owner of the site in the URL bar, where available, and distinguish that from the connection security status. A green lock on its own means just that the connection is secure (but the site could be anything), while a green lock with text next to it, like “? JPMorgan Chase and Co. (US)”, which is what shows for me in Firefox and Chrome when I visit Chase, conveys that the connection is secure and the site has also been authenticated by the CA as owned by “JPMorgan Chase and Co. (US)”. I think many users are likely unaware of how to interpret these distinctions, though.
This is not browser specific. The ownership information is shown for EV certificates(“extended validation”). Let’s Encrypt offers DV certs only, which means all they verify is that the person requesting the cert really owns the domain.
I agree. If anything, I’d say it makes more sense for browsers to take on this role rather than the CAs. Perhaps browsers could warn users if they’re about to send secrets to a site with a domain that contains or is a misspelling of one of Alexa’s top 500 domains.
This certainly isn’t a perfect solution. It might not even be a good one. But I don’t think a CA filtering which domains are allowed is a good solution either.
Definitely interesting coming from seeing the initial presentation at DEFCON crypto and privacy village to this post. I think the argument is that secure in your browser window is secure in a technical definition but isn’t necessarily safe or secure for you the user. Educating the difference between paypal dot com and paypay dot com dot something else isn’t going to work any better than educating folks to drive safer before seatbelts and airbags.
The proper place for the lists and the check is browser-side. You already have the info of what sites a user uses, and trusts, and which ones are new visits, etc. Checking for a commonly used domain inside of an uncommon domain name could void the Secure and expand its meaning beyond just “did this site follow the rules for obtaining a zero cost certificate in order to serve encrypted information to you” which is meaningless to most everyone.
Could you add a browser security feature that blocks new domains with suspicious words in them if they’re recently registered? That does approximately the same thing.
But if it becomes widespread people will just move to domains without those words.
Besides the “this is the browser’s job to display the top-level domain differently” or whatever comments, how difficult would it be for Let’s Encrypt to be given a list of commonly-phished websites and delay issuance (and notify the real paypal so they can take legal action or quash the domain registration)?
It’s a one line perl script to see if a domain name matches a ban list, but who decides what’s in the ban list? (Who decides who decides what’s in the ban list?)
LE already uses the google safe browsing list, so using the inverse of it (the legitimate websites that are imitated by the entries on the safe browsing list) isn’t really superbly controversial.
Creating an audit log of all certificates that have been delayed/quashed due to this procedure (along with the legal entity responsible) seems also completely doable.
Thanks to certificate transparency, that is unnecessary. Paypal can watch the CT log and “take legal action or quash the domain registration” whenever they feel like it :)
“Domain registrars have issued 988 domains with "paypal” in them; all but 4 used for phishing"
There could also be potentially valid cases for paypal in a domain, like “dont-use-paypal.com” or “paypal-is-awful.com” or something similar. Someone may even want one of those domains to have perfectly valid SSL too.
OpenBSD developer uebayasi@ once had problems signing up to some web site which complained that he shall not use a username which contains ‘ebay’.
I was unable to register bannedfromhackernews.com because it had the word hacker.
Yes, but the idea of having trusted CAs is that there should be someone taking a look at these before approving the certificates.
That’s what EV certs are
Also, who’s to say that paypal.mycorp.com is abusive or legitimate?
How could a CA tell? What’s to stop me from creating paypal.mysite.com, filling it with blog posts critiquing paypal’s business practices, and then once I get a cert for it, replacing it with a phishing site?
All a CA can do is verify that the person requesting a cert for a given domain name controls the domain. Constantly auditing the ‘worthiness’ of a cert-holder’s domain would be an enormously impractical burden.
[Comment from banned user removed]
The “major CAs” that the article talks about will gladly issue me a certificate for wildcard subdomains. There is nothing new about this problem with Let’s Encrypt. A cert for, say, *.*.mysite.com will let me serve paypal.com.mysite.com.
The new part would be it’s free and easy the automate. I still think this isn’t letsencrypt’s problem.
I don’t believe you can do double wildcards.
Indeed, wildcard certificates are only supported for the first level subdomain. See, eg, RFC2818, section 3.1:
Of course, you can just buy a certificate for *.com.mysite.com, which lets you do the same thing.
You pose that as if they’re equivalent, but it’s not really the case, is it? Domain registrars have issued invalid certificates used for evil, yes. But is it quite so prevalent as with LE?
The point jcs is trying to make, I believe, is that the domain registrars allowed someone to register the domains in the first place. For DV (domain validation) certificates, it is only verified that you own the machine at the IP address the DNS for that domain points to.
Oh, yes, indeed. I got domain registrars confused w/certificate authorities.
Carry on. ;)
[Comment from banned user removed]
[Comment from banned user removed]
Yes. And LetsEncrypt is willing to do that for every domain and subdomain that you can show you control the DNS for. So if you own blahdz.com, you can get a signed cert for blahdz.com. If your dns server has a subdomain like house.blahdz.com, or vacation.house.blahdz.com, you can get certs for those too. It’s really convenient, and its free!
You can even get one for paypal.com.blahdz.com if you were to put that in your DNS. Register www.paypal.com.signin-country.US.blahdz.com and you can make a really convincing looking fake paypal login screen link, with a little green padlock and everything. Pretty shady!
The article claims that certs for deceptive server names like that have been issued 988 times by Let’s Encrypt. So… maybe we shouldn’t trust Let’s Encrypt? Especially if they aren’t willing to do this one little thing to protect users, Right? Think of the harm LE is causing!
…or you could consider that 988 questionable certs is only 0.003% of the 30 million certs that LE has issued so far.
…and that the author of the article works for a place that sells certs for living, “The SSL Store”.
…and that outfit sells, for $65 a year, the same thing that LE has given 30M of away for free.
So yes, it is absurd. Phishing is certainly shady, but the SSL bussiness is a bit shady too. Its an entrenched cash cow with a vested interest in making sure that users continue pay for the privilege of that little green lock. Otherwise, they would be issuing singing certs, and every domain would already have an SSL certificate.
The problem is not that LetsEncrypt issued those certificates. It’s that we taught people that they should look for the green lock to tell whether a website is legitimate.
Well, it is.
If the green lock is right next to https://we-steal-from-your-paypal-account.mysite.com, then the site really is we-steal-from-your-paypal-account.mysite.com,.
I think he means that people think that if the green lock is there, that the website is somehow more “trustworthy”. When in fact, it’s just a measure of connection security. So someone sees the green lock on https://we-steal-from-your-paypal-account.mysite.com and thinks that means it is “trustworthy”. Most people I know have no idea what the green lock means other than “it’s good to look for when I online bank”.
Most modern browsers do attempt to also convey information the owner of the site in the URL bar, where available, and distinguish that from the connection security status. A green lock on its own means just that the connection is secure (but the site could be anything), while a green lock with text next to it, like “? JPMorgan Chase and Co. (US)”, which is what shows for me in Firefox and Chrome when I visit Chase, conveys that the connection is secure and the site has also been authenticated by the CA as owned by “JPMorgan Chase and Co. (US)”. I think many users are likely unaware of how to interpret these distinctions, though.
This is not browser specific. The ownership information is shown for EV certificates(“extended validation”). Let’s Encrypt offers DV certs only, which means all they verify is that the person requesting the cert really owns the domain.
I agree. If anything, I’d say it makes more sense for browsers to take on this role rather than the CAs. Perhaps browsers could warn users if they’re about to send secrets to a site with a domain that contains or is a misspelling of one of Alexa’s top 500 domains.
This certainly isn’t a perfect solution. It might not even be a good one. But I don’t think a CA filtering which domains are allowed is a good solution either.
I never taught anyone that. I taught them it means that 3rd parties can’t eavesdrop on their conversation with that server.
So what other exceptions will people ask for next?
I for one would like let’s encrypt to issue certs with ‘stsp’ in the domain only to me.
Definitely interesting coming from seeing the initial presentation at DEFCON crypto and privacy village to this post. I think the argument is that secure in your browser window is secure in a technical definition but isn’t necessarily safe or secure for you the user. Educating the difference between paypal dot com and paypay dot com dot something else isn’t going to work any better than educating folks to drive safer before seatbelts and airbags.
The proper place for the lists and the check is browser-side. You already have the info of what sites a user uses, and trusts, and which ones are new visits, etc. Checking for a commonly used domain inside of an uncommon domain name could void the Secure and expand its meaning beyond just “did this site follow the rules for obtaining a zero cost certificate in order to serve encrypted information to you” which is meaningless to most everyone.
Could you add a browser security feature that blocks new domains with suspicious words in them if they’re recently registered? That does approximately the same thing.
But if it becomes widespread people will just move to domains without those words.
Besides the “this is the browser’s job to display the top-level domain differently” or whatever comments, how difficult would it be for Let’s Encrypt to be given a list of commonly-phished websites and delay issuance (and notify the real paypal so they can take legal action or quash the domain registration)?
It’s a one line perl script to see if a domain name matches a ban list, but who decides what’s in the ban list? (Who decides who decides what’s in the ban list?)
LE already uses the google safe browsing list, so using the inverse of it (the legitimate websites that are imitated by the entries on the safe browsing list) isn’t really superbly controversial.
Creating an audit log of all certificates that have been delayed/quashed due to this procedure (along with the legal entity responsible) seems also completely doable.
Thanks to certificate transparency, that is unnecessary. Paypal can watch the CT log and “take legal action or quash the domain registration” whenever they feel like it :)
[Comment removed by author]