{"id":570,"date":"2017-04-01T16:24:34","date_gmt":"2017-04-02T00:24:34","guid":{"rendered":"http:\/\/unmitigatedrisk.com\/?p=570"},"modified":"2017-04-09T20:22:44","modified_gmt":"2017-04-10T04:22:44","slug":"cas-and-ssl-and-phishing-oh-my","status":"publish","type":"post","link":"https:\/\/unmitigatedrisk.com\/?p=570","title":{"rendered":"CAs and SSL and Phishing Oh My!"},"content":{"rendered":"

\"\"<\/a><\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

NOTE: <\/i><\/b>This post reflects my personal beliefs and is not necessarily those of my employer Google, or Let\u2019s Encrypt where I am a member of their Technical Advisory Board.<\/span><\/i><\/p>\n

Introduction<\/span><\/h1>\n

Recently Vincent <\/span>from The SSL Store published a blog post<\/a> <\/span>calling out Let\u2019s Encrypt for issuing certificates to domains that contain the world PayPal.<\/span><\/p>\n

The TL;DR for his post is he believes that Let\u2019s Encrypt is enabling phishers by issuing them SSL certificates that contain the word \u201cPayPal\u201d and then refusing to revoke them when arbitrary third-parties ask them to.<\/span><\/p>\n

As a result of his post, several news sources have decided to write articles about how\u00a0“Let\u2019s Encrypt” is acting as an enabler of these Phishers [1<\/a>] [2<\/a>]<\/span>.<\/span><\/p>\n

Unfortunately, Vincent\u2019s post and the associated articles don\u2019t cover this in the most complete and balanced way so over my morning coffee today I decided to write this post to discuss the other side of the argument.<\/span><\/p>\n

If this is a topic that interests you please also check out the Let\u2019s Encrypt blog post where they talk about why they have taken this position<\/a><\/span>.<\/span><\/p>\n

Exploration<\/span><\/h1>\n

Let\u2019s explore the opportunities CAs have to check for phishing, the tools they have available to them, the effectiveness of those tools, the consequences of this approach, how complete a solution based on the tools available to them would be and what the resulting experience would be for users.<\/span><\/p>\n

Opportunities<\/span><\/h2>\n

The WebPKI\u2019s CAs role, historically, has been that of a Passport office, you present proof you control a domain, and possibly that you are an authorized member of an organization and you get a digital certificate that attests to that.<\/span><\/p>\n

This certificate could be valid for up to 1095 days. Once the certificate is issued the CA, largely speaking, has no natural opportunity to verify this information again. It is worth noting that this month the CABForum voted to shorten this period to 825 days<\/a><\/span>.<\/span><\/p>\n

Tools<\/span><\/h2>\n

In the event a CA determines it made a mistake in the issuance of a certificate or has been notified by the subscriber they would like to see a certificate marked invalid, the tool they have available to them is called “revocation”.<\/span><\/p>\n

The two types of revocation that are under the control of a Certificate Authority are called Certificate Revocation Lists and OCSP responses. The first is a like a phonebook of all known \u201crevoked\u201d certificates while the last is more like a lookup that it enables User Agents to ask the status of a particular set of certificates.<\/span><\/p>\n

Effectiveness<\/span><\/h2>\n

Earlier we discussed the lifetime of certificates, this is important to understand because the large majority of phishing sites do not start out as Phishing sites<\/a>, as such issuance time checks seldom net positive results.<\/span><\/p>\n

After issuance, this leaves you with periodic checks of the site, \u00a0third-party reports of phishing and relying on revocation checking as an enforcement mechanism. This is a recipie for failure, there are a few reasons for this, but one of the more significant is the general ineffectiveness\u00a0of revocation checking.<\/span><\/p>\n

Revocation checking is the most taxing thing a CA does. This is because the revocation mechanisms available to them will result in every relying party contacting them to download\u00a0a OCSP response or CRL covering that certificate.<\/span><\/p>\n

As a result, OCSP has a tendency to be both slow and unreliable. This forced browsers to implement this check as a \u201csoft fail\u201d, in other words, if the connection times out or fails for some reason they assume the certificate as good. <\/span><\/p>\n

To give that some context about 8% of all revocation checks done by Firefox fail <\/a><\/span>and the median response time is over 200ms<\/a><\/span>. <\/span><\/p>\n

As a result of this in 2012 Chrome, which is used by about 50% of all users<\/a><\/span>, more-or-less disabled revocation checking except for exceptional circumstances<\/a><\/span>.<\/span><\/p>\n

What this means is that revocation checking, even for its intended purpose, is far from an effective tool. Expanding its use to include protecting users from phishers would not improve its effectiveness and arguably it would (due to the infrastructure implications) make it even less reliable.<\/span><\/p>\n

It is also important to note that every wildcard certificate can be used for a hostname containing “<\/span>PayPal\u201d without the CA ever being made aware, a good example is <\/span>https:\/\/paypal.github.io\/<\/span><\/a> which is protected by a wildcard certificate issued to Github. <\/span><\/p>\n

Consequences<\/span><\/h2>\n

To understand the consequences of expanding the CAs role include protecting us from phishing we first need to understand what a certificate represents, or more importantly what it does not represent. It does not represent the content, it represents the host that is serving content and it is the content that “phishes”.<\/span><\/p>\n

Today, in the age of cloud services, there is a good chance the host that is serving the content is a service operated by WordPress, or maybe Amazon\u2019s S3. These services allow users to sign up and post arbitrary content for free or very little money. <\/span><\/p>\n

If we decide that revocation checking is the right tool to get phishing content off the web we would be saying a CA should revoke WordPress\u2019s certificate if one of it\u2019s users posted something someone reported as phishing content. That would, for the situations where revocation checking takes place and happens to work, take WordPress off the Internet. Is that what we want to happen?<\/span><\/p>\n

If so, who is it we are asking to perform this task? There are well over 400 CAs in the Microsoft Root Program<\/a> <\/span>do we believe these are the right organizations to be policing the internet for the appropriateness of content?<\/span><\/p>\n

If so what criteria should they use to do so and what do we do if they abuse this censorship role?<\/span><\/p>\n

Completeness<\/span><\/h2>\n

It is easy to say that a CA should not issue a certificate if it contains the word \u201cPayPal\u201d. I could even see an argument that those that would be hurt by such a rule, for example, <\/span>http:\/\/www.PayPalSucks.com<\/span><\/a>\u00a0and (a theoretical) PayPalantir.com are an acceptable loss.<\/span><\/p>\n

This would, however not catch homoglyphs like when a Cyrillic \u201ca\u201d is used instead of the latin \u201ca\u201d which would very likley require a manual review of the name and content to determine the\u00a0intent of the domain owner which is near impossible to do with any level of accuracy or fairness.<\/span><\/p>\n

Even with that, what about ING, as one of the world’s largest banks, they too are commonly phished, should a CA be able to issue a certificate to <\/span>https:\/\/www.fishing.com<\/span><\/a>. And if they do and the issuing CA receives a complaint that it is Phishing ING what should they do?<\/span><\/p>\n

And what about global markets and languages? In Romania there is a company called Amazon<\/a> <\/span>that is a cleaning company, should anyone be able to request their website be revoked because it contains the word Amazon?<\/span><\/p>\n

If we promote the CA to content police, how do we do so in a complete way?<\/span><\/p>\n

User Experience<\/span><\/h2>\n

With CAs acting as the content police, what would a user see when they encounter a revoked site? While it varies browser to browser the experience is almost always a blocking \u201cinterstitial\u201d, for example:<\/span><\/p>\n\n\n\n
\u00a0\"chrome<\/a><\/td>\n\"firefox<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n


\nIf you look closely you will see these\u00a0are not screens that you can bypass, revoked sites are effectively removed from the internet.<\/span><\/p>\n

This is in contrast to <\/span>Safe Browsing<\/span><\/a> and <\/span>Smartscreen<\/span><\/a> which were designed for this particular problem set and therefore provide the user a chance to visit the site after a contextually relevant warning:<\/span><\/p>\n\n\n\n
\u00a0\"SafeBrowsing\"<\/a><\/td>\n\"smartscreen\"<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Conclusion<\/span><\/h1>\n

I hope you see from the above that relying on Certificate Authorities as content police as a means to protect users from phishers a bad idea, at a minimum, it would be:<\/span><\/p>\n