Just wanted to drop in and express support for not doing any phishing/malware checks. I agree with your position that CAs should not be gatekeepers when issuing DV certs.
Every certificate issuance will pass through Google and Google will be the gatekeepers of who gets a certificate.
Can’t say I’m thrilled.
@RAMJAC has a good point, leaving that authority to Google has to be considerate, but if Let’s Encrypt can counter balance that with a “supreme” authority on the validation it can be right.
Still I think you are out of your role doing that phishing/malware check, browsers should advert users that the HTTPS site they are browsing are maybe not so friendly, IMO this is not your responsibility to do that job.
I would like to know if there is also any alternative to google’s service. If so, Let’s Encrypt could use it also. Perhaps using a DNS blacklist https://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists ?
I searched and found several sites that have SSL certificates from official issuers (Comodo, etc) that are blocked by google’s safe browser service for providing malware and/or phishing scams.
Example: https ://kar.cr [link edited by moderator to not be clickable per other users’ suggestion - please bear in mind that this is a malicious domain when navigating to it]
So, do you think that the certificate issuer should be held accountable for the site actions/content?
If I am scammed by a site that has a ‘valid SSL’, should I sue the certificate issuer because I believed that the site was honest and real?
IMO this is marketing BS that the certificate issuers use to justify the high cost of the certificates.
I have a question regarding Let’s Encrypts plan. Will you solely be relying on Google’s API or will there be an additional blacklist of any kind? For instance, everyday new derivative domains of “paypal” are registered with the intent of using them for phishing. Google cant keep up with every single one of them, and if someone wanted to they could immediately register the domain and then request the certificate before they could be flagged
Will Let’s Encrypt have any additional measures for extremely popular phishing targets such as Paypal?
The pro-content policing argument does have one good point. While a “green lock” does not indicate safety or legitimacy, there is tons of advice out there (from websites, commercial CAs, news programs, etc) that have incorrectly stated that the lock means just that.
So there is a real risk of users misunderstanding the meaning of the symbol. Inexperienced users may visit “Paypall.com” and check for a lock as assurance that they are on the real Paypal. However I think the CA industry uses this argument as a crutch; there is no evidence to support this is a common occurrence.
Most commercial CAs do have content policing measures. Its usually a combination of a black listed term list + revocation information + 3rd party databases like Google’s Safe Browsing database.
Some CAs are more strict, like Symantec, who recently banned an entire TLD because they identified it as being a popular TLD for phishing/malware. This is a perfect example of CAs overstepping their boundaries, and an illustration of why aggressive content policing is inappropriate.
Let’s Encrypt’s position is a good one. The CA/B Forum Baseline Requirements do suggest that CAs use some sort of system to identify “high-risk” domains. So there is an implication, with the current wording of the BRs, that the CA does have SOME responsibility on this front. One of the suggestions they make is to check with the Google Safe Browsing database. There is no evidence that Google uses this list to unfairly punish domains, so claims that this makes Google “gatekeepers of who gets a certificate” are unfounded and purely hypothetical.
We should remember that historically, all certificates had identity validation (OV was the first kind of Certificate). Some CAs carry this history with them and have a different interpretation about what a certificate represents and means. Let’s Encrypt’s move is partially political. They dont want to immediately end the practice of content policing, and their blog post says as much. Some of you may be unhappy with this in the short term, but I think it will yield more benefits in the long term.
On a philosophical and moral level, mistakes (innocent or otherwise)
will mean censorship, since CAs would be gatekeepers for online speech
and presence. This is probably not a good role for CAs.
So to solve the problem of not trusting CAs, we trust…Google?
I must not have actually woken up today because things like this only exist in nightmares.
The CA system is not successful if we put absolute trust in the CAs.
This issue is complex, but I can respect Let’s Encrypt for being conservative early on about which domains they issue certificates for. Of course the solution isn’t perfect – PKI isn’t perfect either – but it’s a respectable measure to prevent issuing certificates for sites that are probably malicious. If they issued certificates without any integrity check, Let’s Encrypt would lose credibility.
Using Google’s API is, in one sense, a way to balance power and trust. Google Chrome trusts Let’s Encrypt to issue reliable certificates, and Let’s Encrypt trusts Google to maintain an accurate domain blacklist. Google is known for keeping CAs accountable using stern measures, and having a CA use their blacklist is one way of keeping Google accountable. Not to mention the millions of Chrome users. CAs only work by the grace of operating systems and browsers.
This validation check is a far cry from being censorship. Not having an SSL cert from one non-profit organization because your domain was blacklisted by a separate entity does not in any way stop you from publishing your thoughts and ideas.
Validating the integrity of domain names is one job of CAs – not unique to Let’s Encrypt.
The “green lock” and even “lock” icons are at the browsers’ discretion… tomorrow Chrome could change this icon to a smiley face if they wanted, right?
As TLS becomes as pervasive as I think we all anticipate, the UX metaphor for it should probably change quite a bit. Perhaps it would be inverted and browsers would only show a message if you’re not encrypted.
Regardless, I think the future is going to look quite a bit different than the present, and looking forward, we should not be so hung up on the “lock” metaphor.
Google has already stated that their goal is to invert the icons so that TLS connections do not have an indicator, and HTTP connections have a negative indicator, just as you have suggested.
However that is the future.
not really, Chrome 46 has started doing this http://arstechnica.com/information-technology/2015/10/chrome-finally-kills-off-the-http-https-mixed-content-warning/
I’m not thrilled about it.
How long will it be before we see politicians use this because they want to label something as sedition, inciting terrorism or target the marijuana industry in states where it is legal?
And yes I know, they have already tried with some success with domain names.
While what you suggest (Marijuana industry) may be protected by some states’ laws, it should be noted that nearly all, if not all these websites, have no mechanism in place to prevent out of state access, and is in violation of Federal law and international treaties. In addition, DV certificates have no way of saying that they are only valid in X state or jurisdiction. Said certificate would even likely validate in Iran, where drug use can carry a death sentence!
With that said, hopefully having Shopify as a sponsor won’t weaken the anti-abuse provisions of the Let’s Encrypt service. I say that because they have refused after several contacts with their abuse team to shut down an illegal store.
As it is stated in the blog post it is not the job of a CA to decide between good and evil. Sad to see you have decided to try to do this anyway. The lock symbol sure is misleading because people were told wrong facts about what is proves and what not but this is the job of the browser vendors to finally create a better UI for this.
At least for the time being, Let’s Encrypt is going to check with the Google Safe Browsing API before issuing certificates, and refuse to issue to sites that are flagged as phishing or malware sites. Google’s API is the best source of phishing and malware status information that we have access to, and attempting to do more than query this API before issuance would almost certainly be wasteful and ineffective.
And what if Google is wrong? Do you fully rely on an arbitrary decision made by some company perhaps for reasons nobody even knows? Do you provide a way to appeal to this if google refuses to remove one from the list? If yes: by what criteria?
Sure i don’t expect this to be a big problem in practice for now but it’s surely nothing to be comfortable with in general.
Will Let’s Encrypt have any additional measures for extremely popular phishing targets such as Paypal?
What if i register e.g. paypall.com not to do phishing but to e.g. put some satirical content on it criticising the company? Would be some form of censorship. Sure letsencrypt has any legal right to say “fuck it, you ain’t get nothing” but is this what the project wants to do? It would be a huge effort verify that a domain is likely not intendend to be used as a phishing domain if it matches such a fuzzy filter.
Doing such things may probably be useful, but elsewhere e.g. in the browser or mail client issuing an appropriate warning but do not block it because it looks a bit evil.
Google cant keep up with every single one of them, and if someone wanted to they could immediately register the domain and then request the certificate before they could be flagged
So you think letsencrypt is able to pull some magical measures out of thin air which outperform Google in this regard?
I do not agree a CA is responsive for fighting phishing or malware. DV certificates should be issued to do what it is supposed to do: Domain Validation.
The Google API process do not add more value. A bad guy can simply create a blank site, acquire a cert, then do bad things.
If Let’s Encrypt worries people could be confused by the browser icon, it is an education issue. It is not the role of a CA to do/say anything about a site’s content.
Really interesting how that nobody (not in the article or the comments) mentioned the other kind of certificates: Extended Validation certificates (EV) aka green bar with an organisation name in the URL.
I would think that CAs issuing those certificates would not issue those certificates for domains with very similar names.
It’s getting close to 10 years now, we’ve had these EV-certificates, don’t most people know by now not to look for the lock-icon, but for the green bar for banks, Paypal and the like ?
Totally agree that sooner or later the browser UIs are going to change/flip for HTTP and HTTPS (with DV-certs).
I will not discuss about CA’s role in fighting phising but if letsencrypt want it can setup a keyword blacklist.
For example, StartCom checks if domain/subdomain contains words like paypal/hotmail/etc and reviews them manually.
This list should not produce false positives, it should only include obvious phising words.
Also, as the list of certs will be public, anyone could audit it.
They’re also reviewing other things manually, maybe because I chose a different prefix than
www. as the single allowed one.
My first impulse is to say that LE should not perform any checks related to hosted content, particularly if there is no human appeals process available when a certificate request is denied. In particular, I don’t know what is gained by refusing to issue certificates for sites that would already cause prominent warnings when visited by browsers that use the Save Browsing API and the blog post we’re all responding to really does not articulate a good case for this either.
But if LE decides it must perform checks based on blacklists maintained by third parties, it should only select third-party blacklists that are narrow in scope and which have an effective appeals process. (I do not have enough knowledge of Google’s phishing/malware lists to say whether it has these two properties or not)
LE should fully and accurately disclose what those checks are.
LE should ensure that when a particular certificate request is denied, the administrator of the denied site receives enough information to lodge an appeal with the maintainer of the third-party blacklist. (this is simple enough if LE is only using a single blacklist, but if it eventually uses several blacklists it’ll be important to inform the site administrator which blacklist test(s) are failing. This could be outside the ACME protocol itself, such as a page on the LE website where an administrator can enter a domain and see what the blacklist results are)
Google’s Safe Browsing FAQ lists three types of sites which receive advisories: Phishing, Malware, and Unwanted Software. Two of the three types provide an appeals/delisting process, but “Unwanted Software” does not. However, it may be that LE’s proposed use of the Safe Browsing API is only looking at the first two types.