Should the CA prevent people from getting certificates for domains containing the names of 'big' websites and corporations? Should browsers make it more obvious that the website has an EV certificate? Maybe also try to detect phishing URLs?
Some approaches to detecting it exist, like this "deceptive domain" score from Netcraft: https://www.netcraft.com/anti-phishing/deceptive-domain-scor... I assume, though, they are just doing some fancy string matching with a few other features (character lookalikes, xlate to punycode, etc). I imagine that both the "false positive" and "false negative" rates are pretty bad.
There's one aspect, connection security, which either you have or you don't have. There's no useful purpose to an icon which is always there and people can then ignore. For practical purposes, browsers should only inform people when their connection is not secure, so people can assume security the rest of the time.
Then there's the other aspect, identity. Is this really PayPal? Honestly, most users will never be able to notice if it's not. Who cares what host is in the address bar, or if it has a valid cert, or if it's plain http? Average users don't scrutinize these things because they don't know what a certificate is, or encryption, or how domains or web pages work. If it looks like Paypal, they assume it is.
EV certificates have always been a scam. I don't think users know they exist, and I don't notice at all when I am on a site that uses one, unless I look really hard and click some buttons and read around. Even when I do (in Firefox, for example), no part of the UI explains to me that this company paid for an expensive process to prove this website is owned by this legal company. It just says "This is Bank of America Corporation (US), verified by xyz". Well, yeah, I would have assumed it was anyway, and I don't know what "verifying" implies. On an identical site without an EV using a phishing domain, it would simply not have this information, and nothing would seem amiss to me at all. So EV does nothing for me as a user.
What is more useful are apps. Apps in an app store do tend to pop up the most authentic result first. You can see this app is Bank of America, and the app was made by Bank of America Corp. Seems legit. If a phishing site popped up a phishing app, and it wasn't made by Bank of America Corp, I might be suspicious enough to double check it before installing it, but maybe not.
If the first time I visit a website the browser displayed some information about the domain, certificate, etc, that would be similar to what the app store does. "This is Bank of America website, owned by Bank of America company, and we legally verified it with X verifier." Or, "This is Bank of America website, it has not been legally verified". Or, "This website is Bank of America, and is registered and geo-located in Lithuania". That would seem odd.
Another failure of browsers: I just visited https://www.bankofamerica.com/, right cliked, clicked View Page Info, and then clicked the Security tab. (Honestly that's way too many clicks, and too hidden) It says "Have I visited this website prior to today? No." Which I don't think is true actually, but anyway, it at least is one hint that maybe I should be suspicious.
I think the browser should provide a button called "Identify" that when you click it, it tries to give you an idea of how much you can trust this page. Show me who owns the domain, the DNS, Geolocation, EV information, the URL, have I been here before, does it match any tracked lists of malware URLs, is it in an IP pool commonly used for cybercrime, etc. Everything I need to get a feeling for if it's trustworthy. And specifically, throw up red flags where something might not be 100% trustworthy. I probably do not care if abcnews.com is not 100% trustworthy, but I do care if Paypal is, so I want a button I can press that will tell me if it isn't.
Ok, so that's a third thing: security, authenticity, and trust. (I would probably rename "authentic" to "real" to be more intuitive)
A "Scan your PC now for viruses!" website that is exactly who they say they are may be authentic, but not trustworthy, as some steal your identity. That is probably already handled by Google Safe Browsing, though.
The blame is misplaced. DV certificates were never meant to protect against phishing. Chrome is just doing it wrong.
In my opinion, there should be no padlock, no visual indicators that a connection is secure for DV certs. The enduser doesn't have to know a website uses HTTPS. The padlock should only show up (along with the company name) when the website uses an EV certificate.
That would imply that there is no security benefit whatsoever provided by a DV certificate. To prove that DV certificates are usually seen as "better than nothing", just consider the difference browsers make in their treatment of self-signed certificates.
I'm also in the position of running a small online business on the side, and such a change would almost certainly require and upgrade to an EV certificate. While we have thought about it (and I have tried to find some data on changes in conversion rates possibly coming from it), I haven't quite been able to convince myself that the costs and hassle are worth it.
The process may be prohibitively expensive in some countries, or for some very small operations.
Maybe it's time to think about improvements to identity-verifying certificates. Either by improvements to the process towards automation, or maybe another certificate class relying on a reputation system for judging trustworthiness.
> That would imply that there is no security benefit whatsoever provided by a DV certificate.
The security benefit is that the connection to the server is authenticated and encrypted. Nobody in between can inspect or mutate the data. This is a huge win over unauthenticated HTTP.
No, but then again the URL bar's color rarely comes up when I do smalltalk. I've also never heard anybody in real life mention the size or color of "order" buttons, but I have pretty reliable data that even among choices that will seem to be completely reasonable, some will convert at 3x the rate of others.
Chrome's long-term plan is to show no visual indicator for (valid) HTTPS, and a non-secure indicator for HTTP[1], so that's essentially what you're describing. IIRC Firefox has similar plans. HTTPS deployment numbers don't quite allow for that yet.
I was about to applaud the author for highlighting that LE isn't a position to do anything about this, but then... the article takes a very strange turn to blame LE anyway.
I advocate quite often for presenting the other side's the best possible arguments, but I guess that I should include a recommendation to actually engage with these as well. In this case, it doesn't amount to much more than "but still..."
Did the requesters of that actually control those domains (hint: they didn't)? If I register the domain superawesomepaypalscam.com then that is my domain name. Since it is my domain name and I can control it, obviously I can get a domain validated SSL certificate for it.
If I don't control example.com, then obviously I should not be able to get a domain validated SSL certificate for it. If I did, I would be able to MITM people trying to visit example.com (which is not my website), and that is bad.
This entire situation is basically working as intended.
If those sites should not be allowed to own the domain names they are using, then the registrars can take the names back.
All the DV certificate means is "you are using an authenticated connection to the server that answers for foo.com".
TLS doesn't have anything to do with the ethics, morality, or legality of the site operators.
It's too bad that we've trained laypeople to think otherwise. But, even a phishing site should be served over HTTPS. Otherwise, the user will be vulnerable not only to the phishing site, but every intermediate server that the connection passes through.
In other news, water is wet. This is exactly working as intended. If I control the website superawesomepaypalscam.com then I should be able to get a DV (domain validated, it's in the name) SSL certificate for it. It doesn't matter what I intend to use the website for.
Ryan Sleevi (Google's representative on the CA/B forum) has tweeted about what the CAs want and why they attack Let's Encrypt: they want the right to censor the internet.
Checking LE's stats page, they've issued over 30M certificates. 15k (hell, even 150k) certs used for nefarious purposes are nothing compared to the public good they're doing.
Also, LE did nothing wrong by issuing these certs (unlike a certain CA that issued bogus certs and will hopefully be kicked out of browsers soon): it's not a CA's role to dictate what a domain is used for.
Well, why not then say this is domain registrar's fault, since somebody clearly did allow registration of paypal.com.tk or something similar.
SSL certificate is for secure communication with some website. Whether the website is a malicious one or not has absolutely nothing to do with security of the communication with said site.
I think the problem here is that people believe sites which are SSL enabled are good, and that problem will be fixed when all the web sites become SSL enabled.
25 comments
[ 3.1 ms ] story [ 30.2 ms ] threadShould the CA prevent people from getting certificates for domains containing the names of 'big' websites and corporations? Should browsers make it more obvious that the website has an EV certificate? Maybe also try to detect phishing URLs?
Personally, I don't see how it makes sense for a domain registrar, CA, web hosting provider, etc, to have to figure this out, but...
- Legitscript, some kind of consortium meant to block internet sales of pharma products named/shamed a domain registrar https://www.legitscript.com/blog/2012/12/internet-bs-domain-...
- Markmonitor, some service sold to big brands to protect their brands, also does some name/shame type reports: http://www.circleid.com/posts/best_worst_phishing_domain_reg...
Some approaches to detecting it exist, like this "deceptive domain" score from Netcraft: https://www.netcraft.com/anti-phishing/deceptive-domain-scor... I assume, though, they are just doing some fancy string matching with a few other features (character lookalikes, xlate to punycode, etc). I imagine that both the "false positive" and "false negative" rates are pretty bad.
Then there's the other aspect, identity. Is this really PayPal? Honestly, most users will never be able to notice if it's not. Who cares what host is in the address bar, or if it has a valid cert, or if it's plain http? Average users don't scrutinize these things because they don't know what a certificate is, or encryption, or how domains or web pages work. If it looks like Paypal, they assume it is.
EV certificates have always been a scam. I don't think users know they exist, and I don't notice at all when I am on a site that uses one, unless I look really hard and click some buttons and read around. Even when I do (in Firefox, for example), no part of the UI explains to me that this company paid for an expensive process to prove this website is owned by this legal company. It just says "This is Bank of America Corporation (US), verified by xyz". Well, yeah, I would have assumed it was anyway, and I don't know what "verifying" implies. On an identical site without an EV using a phishing domain, it would simply not have this information, and nothing would seem amiss to me at all. So EV does nothing for me as a user.
What is more useful are apps. Apps in an app store do tend to pop up the most authentic result first. You can see this app is Bank of America, and the app was made by Bank of America Corp. Seems legit. If a phishing site popped up a phishing app, and it wasn't made by Bank of America Corp, I might be suspicious enough to double check it before installing it, but maybe not.
If the first time I visit a website the browser displayed some information about the domain, certificate, etc, that would be similar to what the app store does. "This is Bank of America website, owned by Bank of America company, and we legally verified it with X verifier." Or, "This is Bank of America website, it has not been legally verified". Or, "This website is Bank of America, and is registered and geo-located in Lithuania". That would seem odd.
Another failure of browsers: I just visited https://www.bankofamerica.com/, right cliked, clicked View Page Info, and then clicked the Security tab. (Honestly that's way too many clicks, and too hidden) It says "Have I visited this website prior to today? No." Which I don't think is true actually, but anyway, it at least is one hint that maybe I should be suspicious.
I think the browser should provide a button called "Identify" that when you click it, it tries to give you an idea of how much you can trust this page. Show me who owns the domain, the DNS, Geolocation, EV information, the URL, have I been here before, does it match any tracked lists of malware URLs, is it in an IP pool commonly used for cybercrime, etc. Everything I need to get a feeling for if it's trustworthy. And specifically, throw up red flags where something might not be 100% trustworthy. I probably do not care if abcnews.com is not 100% trustworthy, but I do care if Paypal is, so I want a button I can press that will tell me if it isn't.
A "Scan your PC now for viruses!" website that is exactly who they say they are may be authentic, but not trustworthy, as some steal your identity. That is probably already handled by Google Safe Browsing, though.
(Not disputing the data.)
In my opinion, there should be no padlock, no visual indicators that a connection is secure for DV certs. The enduser doesn't have to know a website uses HTTPS. The padlock should only show up (along with the company name) when the website uses an EV certificate.
I'm also in the position of running a small online business on the side, and such a change would almost certainly require and upgrade to an EV certificate. While we have thought about it (and I have tried to find some data on changes in conversion rates possibly coming from it), I haven't quite been able to convince myself that the costs and hassle are worth it.
The process may be prohibitively expensive in some countries, or for some very small operations.
Maybe it's time to think about improvements to identity-verifying certificates. Either by improvements to the process towards automation, or maybe another certificate class relying on a reputation system for judging trustworthiness.
The security benefit is that the connection to the server is authenticated and encrypted. Nobody in between can inspect or mutate the data. This is a huge win over unauthenticated HTTP.
Have you ever heard a regular user talk about the URL bar not being green?
[1]: https://www.chromium.org/Home/chromium-security/marking-http...
I advocate quite often for presenting the other side's the best possible arguments, but I guess that I should include a recommendation to actually engage with these as well. In this case, it doesn't amount to much more than "but still..."
Symantec generated certificates for domains Symantec did not control.
If I don't control example.com, then obviously I should not be able to get a domain validated SSL certificate for it. If I did, I would be able to MITM people trying to visit example.com (which is not my website), and that is bad.
This entire situation is basically working as intended.
If those sites should not be allowed to own the domain names they are using, then the registrars can take the names back.
All the DV certificate means is "you are using an authenticated connection to the server that answers for foo.com".
TLS doesn't have anything to do with the ethics, morality, or legality of the site operators.
It's too bad that we've trained laypeople to think otherwise. But, even a phishing site should be served over HTTPS. Otherwise, the user will be vulnerable not only to the phishing site, but every intermediate server that the connection passes through.
https://twitter.com/sleevi_/status/843866627255029760
Also, LE did nothing wrong by issuing these certs (unlike a certain CA that issued bogus certs and will hopefully be kicked out of browsers soon): it's not a CA's role to dictate what a domain is used for.
SSL certificate is for secure communication with some website. Whether the website is a malicious one or not has absolutely nothing to do with security of the communication with said site.
I think the problem here is that people believe sites which are SSL enabled are good, and that problem will be fixed when all the web sites become SSL enabled.