I would like to open this topic in order to express my point of view for CA's role in fighting phishing and malware.
First of all, what is the role of an SSL certificate (trusted or not)? Well, to protect users from "men in the middle" attacks.
Secondly, why do we even have the entire CA trust polices within browsers, if some CA's would not revoke certificates for scam, phishing websites? What is the value for a user to see a trusted certificate or untrusted certificate when the trusted certificate from Let's Encrypt can belong to a malicious website? Why the browsers even validate who issued the certificate at all, if the issuer does not take actions when they realize the malicious behavior of a website?
Think about how hackers are operating. Is all about money right? If they would have to pay 1000 USD for a trusted SSL certificate which they could lose before even performing any successful scam, do you think they would do it? Don't get me wrong, I love the fact that I can run my small personal website with a trusted free of charge SSL certificate from Let's Encrypt, but on the other hand I also think about poor people getting scams every day.
Think also about the new flood of Top Level Domains... I got a scam attempt today. The website IP is from Russia, so trying to get his server down from hosting would probably be unsuccessful. His website Top Level Domain is ".site", I doubt that the registrar would do any actions against the hostname. On the other hand, Let's Encrypt could have revoke their certificate pretty quick, and in this way basically it would invalidate their hostname, so the hackers would have to buy a new hostname.
I know that Let's Encrypt would be bloated with tons of requests like this, most of them legit (for real scam websites) but some of them non-legit (like from competitors or whatever).
In any case, I think is everyone's responsibility to make the internet safer:
CA's to revoke certificates for malicious sites
Hosting companies (clouds) to cut servers where malicious sites are hosted
Registrars to cut hostnames of malicious sites
ISPS to not allow IP spoofing and other TCP/IP & DNS level hacks
Browsers to scan for malware and validate the SSL certificates
Users to be careful where and what they surf on the internet
Every point here is correct except the first one. The point of certificate authorities is to certify that you are actually communicating with who you think you are. If I go to google.com in my browser, the certificate means that I am actually talking with google.com. It means I'm having a private conversation, althought it may be a private conversation with a bad actor.
Browsers, hosting providers and ISPs are far better equipped to deal with malicious users. Charging $1000 for a certificate will only reverse all the work done to encrypt the internet. Would you like to go back to a world where every government and ISP can vacuum up every bit of your online life? Or a compromised router at a coffee shop can steal your session token? I certainly wouldn't.
You may wish to refer to this topic about that
Because, as you said yourself in your first point, the role of a SSL certificate is to prevent MitM attacks. Nothing more, nothing less.
then let me create a top level domain named "allhacks.", hosted somewhere in China or Russia or even North Korea. All the hackers can then register domains under my TLD "allhacks.", host their malicious sites in China/Russia etc., get a Let's Encrypt SSL certificate and you are done. You have a "bulletproof" hacking system for poor people all over the world. You cannot complain to the domain authority, you cannot complain to the hosting company, you can complain to Let's Encrypt but they will say is not their business. Happy hacking!
Oh, wait, you can complain to Microsoft and Google and maybe (just maybe) they will rollout something (like an update) to hardcode block some domains like those.
With the text "allhacks" in the hostname of the URL? You'd be quite stupid to believe that you're in the correct place if you surf to "https://yoursite.allhacks/login.php" without or with a lock visible in your browser...
I don't really see your point.
I suggest you search this forum for posts on this subject. It has been discussed exhaustively. Nothing mentioned in this post or the comments above has not already been discussed at-length before here.
Lol ".allhacks" was an example to make a point. Would it be better to give as an example a TLD like ".safe" or maybe ".secured"?
Right, but this doesn't mean that people like me cannot disagree with Let's Encrypt policy to not take actions in order to make internet safer.
Everyone is free to disagree, but what is the point of simply voicing their disagreement without adding anything new to the conversation?
This is meant as constructive criticism. If you've read through the past discussions on this, and can add something new that is potentially persuasive, great! Let's hear it.
This topic has been discussed at-length and the ISRG/LetsEncrypt staff have laid out definitive policy points and their rationales. They have countered every argument and concept discussed above. ISRG staff rarely interact with posts like these anymore, because it's almost always a waste of their time.
Reiterating previously rejected proposals verbatim, without any new context or insight, is never a productive exercise.
That is a highly subjective opinion from an incredibly narrow viewpoint. The wider discussion on this subject notes that enforcing such a policy as advocated could likely cause debilitating issues for ISRG due to liabilities from civil laws, international laws, and-or CA/B Forum requirements. That could result in one less malware retailer, but millions of websites and billions of end-users without SSL protection.
For anyone who disagrees with ISRG's position on this, I suggest you search this forum to better educate yourself. If you have something new to add, please do so. If you don't have anything new to add, which is almost guaranteed at this point, consider focusing your efforts on something you can effect change on.
How does decrypting the conversation between a murderer and his lawyer make the world safer? If you want a certificate revoked, you either:
- Don't believe the entity using the certificate is whom (domain name) they claim to be
- Don't want the underlying contents to be private
The first bullet is exactly the purpose of revocation in the current CA ecosystem. Keep in mind that when you visit any domain name, there are a large number of communications that occur between here and there. How do you know that the respondent is in fact the server for that domain name? The server sends you a certificate signed by a third party that will vouch for its status and authenticity. You don't trust the server for the domain name here. You trust the CA. Hence, yes, "this is a certificate for that domain name, so go ahead and use it", assuming the server for that domain name has the certificate's private key, which the CA verified with the CSR when the certificate was generated.
Even so, my point remains the same: a (DV) TLS certificate only signifies the secure connection (encryption and authentication on a hostname level) to a certain hostname. Nothing more, nothing less.
The fact many users think the TLS "lock" means something else is not a reason to force Certificate Authorities to pick up a task that is not for them.
Certificate Authorities only offer a single thing: certified proof that the connection to a certain server is authenticated and secured. Even if that server is malicious.
Here's the point that you, and many others, sadly miss: the cert only verifies that you're communicating with the site whose name is on the cert. That's all it means, that's all it's ever meant, and that's almost certainly all it will ever mean. It has never meant, does not mean, and cannot mean, that the operators of that site are good, honorable, trustworthy, or indeed anybody other than Satan himself.
The problem is that decades of ignorant users have been conditioned to see the padlock as signifying that the site is "safe." It's never meant that, and it can't mean that. And the less we pretend it does mean that, the better.
What if I report that zzzbank(dot)ru or whatever is a phishing site, but I'm actually lying? If LE revokes their certificate and they're not actually malicious, then I've just successfully executed a denial of service attack against them.
Let's Encrypt's staff couldn't be expected to know the real web address of every single popular bank or social media site all over the world, and they couldn't just take users' word for it when they get reports - they'd have to spend time investigating every report. This would likely take far more manpower than they have - the organization would have to get much larger. Where are you suggesting the funding for this comes from?
This is why I feel that the onus of taking down phishing sites should be on the domain registrar. Let's Encrypt is a non-profit that gives certificates away for free. Domain registrars are getting paid money for each bogus domain registered by the scammers, so they have the budget to actually investigate claims - or at least they're much more likely to have that budget than Let's Encrypt.
Also, remember that certificate revocation is extremely hit or miss. Most clients don't check OCSP every time they load a site, which means that LE revoking a certificate might not even do anything for most potential victims. On the other hand, the register yanking the DNS records would nuke the site worldwide. (Might take a little bit due to DNS caching, but much more reliable than revoking the cert.)
Deciding that that the CA should be responsible for stopping phishing seems very arbitrary to me. The CA is one of many pieces of Internet infrastructure - why shouldn't it be the registrar's job? Your DNS provider's job? Your browser's job? (Actually, many browsers do block phishing sites.)
I imagine that most people who want CAs to deal with phishing sites are still hanging on to the idea that "https" means a site is trustworthy. That idea is extremely outdated and the web community as a whole is discouraging people from making that assumption - hence why browsers are removing the padlock icons and instead declaring that unencrypted sites are "not secure", rather than calling encrypted ones "secure". HTTPS means that your connection to the server can't be tampered with or eavesdropped on at the network level, nothing more. Calling "phishing" a "man-in-the-middle" attack is misusing that phrase.
It's quite possible that DV certificates shouldn't be shown to users as security indications (in fact I think some of the Chrome developers support that view). However, they have value cryptographically because they represent a confirmatory perspective about the cryptographic identity of a site as seen from outside of your own network. They confirm that the version of example.com that you are connecting to is one that has been seen from elsewhere on the Internet (and publicly logged as such).
Without that, your network operator could intercept and alter your connection, and that could include, for example, any public wifi network that you use. So if you went to an airport or café, the airport or café wifi operator, or someone who had hacked the airport or café wifi router, could monitor all of your passwords and alter the content that you saw on web sites, maybe injecting malware. (They are not the only ones who could do so, but just represent a simple and fairly realistic example.)
The system we have now with DV certificates effectively prevents all of those attacks, which is a great value.
It's true that the DV system is generally only trying to prevent ISPs (including tiny operators like a café wifi, or huge operators like a national mobile carrier) from doing malicious stuff, and is not really doing anything to prevent site operators from doing malicious stuff. And some people think they should especially since there was some perception in the past that paid certificate authorities that did manual offline verifications were interested in policing some malicious behavior on the part of their own customers (partly based on the idea that they felt that that malicious behavior would reflect badly on their brand).
It's really unfortunate that there continues to be any confusion about that (in the sense of any user thinking that Let's Encrypt is warranting anything more than "you appear to be connected to the person we think actually controls this domain name"), but I would maintain that automated DV certification is doing something really worthwhile, just maybe something that ought to be more hidden from most users in order to avoid contributing to such confusion.
This post is very naive.
The purpose and reach of a CA are very clear.
There is certainly no sole purpose for certificates.
[and that example is only one of them]
But word "protect" has been taken out-of-context and would be more precisely written as "prevent".
Certificates can prevent many bad things from happening.
But they are not protection from bad things happening.
If I bought a phone that scrambled my voice over the air waves.
To ensure the security of all my calls...
Would it ensure that I spoke only to good people?
Should I complain to the phone maker when I still get SPAM calls?
Guys, I really appreciate all your answers, but I think you miss a very important thing here. You (we) are all technical persons who know many things about hostnames, SSL certificates and so on. I do not want to claim that CA should alone be responsible for taking down phishing and scam sites by revoking the SSL certificate, but it could really help. In this war, you need to use every single bullet that you have in order to make a difference. I know that Let's Encrypt is a non-profit organization and therefore they do not have enough resources to conduct thorough investigations, but there are cases when the things are pretty obvious without having to deeply analyze the situation. In addition, Let's Encrypt is free of charge, so even if they revoke a certificate by mistake, who could open a law suit against them for offering something free of charge which they later reverted?
I imagine a future world where all browsers would implement a common protocol to blacklist websites like is happening today with mail servers. Unfortunately we, as people, have a great ego and very little empathy for all the victims out there.
This already exists. It's just not the role of the certificate authority.
Google Safe Browsing and Microsoft SmartScreen are great tools, if a website is malicious
but there are cases when the things are pretty obvious
then it can be reported and listed. If someone tries to visit this website there will be a massive red banner that the site is dangerous on every single major web browser.
The ultimate goal of browsers is to totally and completely remove the lock icon and any other "secure" indicators. Encryption is the default, and should be seen as a fundamental part of the internet like TCP and DNS
Anyone can sue for anything, if someone reports my ecommerce site to LE who then promptly revokes it since one employee had an opinion that it's malicious, I could sue for damages (lost business while my certificate was revoked and potential reputation damage). That's not saying I'd win (I'm not a lawyer so I'm not sure), but it would certainly drag LE into court and waste their time and money.
This raises another important question for the people who want CAs to fight this battle - why would ISRG be able to do a better job of this than MS or Google, who have far more resources?
I'm not saying that Let's Encrypt would need to be thorough before revoking any certificates because mistakes could put them in legal jeopardy, I'm saying they'd need to be thorough because it would be the morally right thing to do.