The London Protocol: Reducing Phishing on Identity Websites
The CAs are pitching the London Protocol to improve Organization and Extended Validation SSL certificates– but will the browsers go for it?
The London Protocol is an excellent example of why the SSL industry is so unique. Rarely do five of the top companies in an industry come together in an attempt to fix problems with the products they sell. But that’s what’s essentially happening here: Comodo, Entrust, GlobalSign, GoDaddy and Trustwave, through the CA Security Council, have joined together in support of the London Protocol — a formal plan to improve identity certificates (OV and EV SSL).
The initiative was given its name as a result of the venue it was first proposed — at the London Face to Face meeting of the Certificate Authority/Browser Forum (CAB Forum) at the beginning of July.
As the VP of Strategy at Entrust, Chris Bailey writes:
The genesis of our action stemmed from a report from HashedOut noting that “between January 1st, 2016 and March 6th, 2017, the Let’s Encrypt certificate authority issued a total of 15,270 SSL certificates containing the word ‘PayPal.'” These Let’s Encrypt certificates were issued to bad actors who used the name “PayPal” in their domains to trick online users into sending their personal data — in other words, to commit identity theft. The certificates issued by Let’s Encrypt are solely domain-validated certificates, which means that they can be issued to anonymous websites because issuance is 100% automated.
First of all, we would like to thank Chris (and everyone else) for reading. Now let’s talk about how we got here and where this may lead.
What’s behind the London Protocol?
Much though we would love to take credit for helping to get this off the ground, there is a lot more going on than just some bad PayPal certificates. Right now the continued existence of Extended Validation SSL certificate in particular is at stake. Part of this stems from a pair of incidents that occurred over the past year or so where enterprising security researchers were able to create fictional companies that were then used to sow confusion in one case and create an EV name collision with the other.
In one example, Ian Carroll created a company called Stripe in Kentucky, then received an Extended Validation certificate that was indistinguishable from the Stripe payment company’s. In the other example James Burton created a company called “Identity Verified” and received an EV certificate that had the potential to mislead users. No actual harm was done with either certificate, and if anything both examples show the lengths a phisher would have to go through to get an EV certificate, which considering the average phishing site is left up for around 15 hours, seems unlikely.
Burton then gave himself a big old pat on the back in the Mozilla.Dev.Security forum:
EV is on borrowed time and deprecating EV is the most logical viable solution right now and brings us one step forward in vanishing the old broken web security frameworks of the past. Now that both me and Ian have demonstrated the fundamental issues with EV and the way its displayed in the UI, it’s only time until the REAL phishing starts with EV.
Try to ignore the pomposity of the statement and focus on the substance. The first part about deprecating EV is something that several influential people in this industry have already seized on. Google already doesn’t display EV on Chrome mobile and has experimented with removing EV’s unique indicator in Chrome desktop – often referred to as the green address bar – and currently has a flag that removes all EV treatment. Apple may be about to do something similar in future versions of both its mobile and desktop browser, Safari.
The threat is real.
The second part is bogus. James Burton did not open some floodgate and now there has been a rash of EV phishing. Quite the opposite, actually. In a recent study that looked at one month’s worth of phishing activity, just .05% (three total) of the HTTPS phishing sites used an EV certificate. That would be an indication that talk of EV phishing is greatly exaggerated.
What is the London Protocol?
The London Protocol is a proposal by the CAs to implement improvements to both Organization Validation and Extended Validation SSL certificates. It calls for unprecedented collaboration between the CAs that have signed on as they share data and work to make OV and EV safer.
It’s objective is to:
“…improve identity assurance and minimize the possibility of phishing activity on websites encrypted by OV (organization validated) and EV (extended validation) certificates (together referred to as “Identity Websites”). The London Protocol reinforces the distinction between Identity Websites making them even more secure for users than websites encrypted by DV (domain validated) certificates. That security feature can then be utilized by others for their own security purposes, including informing users as to the type of website they are visiting and use by antiphishing engines and browser filters in their security algorithms.
The CAs that have signed on have agreed to take the following steps:
- Monitor phishing reports for websites to whom they have sold an OV or EV SSL certificate
- Notify said websites that phishing content was found and offer instructions for remediation
- Contribute to a common database to help reduce future phishing efforts
The Protocol is currently planned to play out in four phases, starting in June and ending in March of 2019.
Phase | Time Period | Description |
1 | June-August 2018 | Official announcement of Protocol and participants, CAs will further develop Protocol Details and research feasibility of implementation |
2 | September- November 2018 | Participating CAs will apply the Protocol’s concepts to their own customers and share feedback with other CAs |
3 | December 2018- February 2019 | Participating CAs will update Protocol policies and approve plans for uniform policies to be applied by all CAs |
4 | March 2019 | Participating CAs will forward their report and recommendations to the CAB Forum for possible changes to baseline requirements |
Will the London Protocol work?
It’s tough to say at this point. Frankly, it all depends on the whims of a handful of people– some of whom have shown a tremendous unwillingness to even have this discussion, it is anathema to them.
And the London Protocol is not without its critics. Last month DigiCert, which owns its own eponymous CA, as well as Symantec, GeoTrust, Thawte and RapidSSL, formally announced it was withdrawing from the CA Security, citing a different vision for how to fix identity certificates.
From our perspective, this is a nice step – a worthwhile endeavor – but it is treating a symptom, not the root cause of the problem. We can see why DigiCert feels this initiative is missing the point.
Identity certificates, Extended Validation in particular, need legitimate improvements that go beyond an after-market phish monitoring service. There are tweaks to be made to validation and discussions about what to display in instances where a collision has occured.
Those are the conversations that need to be had, and quickly if the advance versions of Google and Apple’s browsers are any indication.
We support the London Protocol, anything that can be done to make websites with identity certificates safer should be done, without question. But the London Protocol needs to be part of a larger plan to fix identity certificates, specifically EV, in general. This can’t be the whole plan itself.
And none of it means anything without buy-in from the browser community.
Still, it’s a damn good start. Hopefully the spirit of collaboration on display by the participating CAs leads to even bigger and better things.
5 Ways to Determine if a Website is Fake, Fraudulent, or a Scam – 2018
in Hashing Out Cyber SecurityHow to Fix ‘ERR_SSL_PROTOCOL_ERROR’ on Google Chrome
in Everything EncryptionRe-Hashed: How to Fix SSL Connection Errors on Android Phones
in Everything EncryptionCloud Security: 5 Serious Emerging Cloud Computing Threats to Avoid
in ssl certificatesThis is what happens when your SSL certificate expires
in Everything EncryptionRe-Hashed: Troubleshoot Firefox’s “Performing TLS Handshake” Message
in Hashing Out Cyber SecurityReport it Right: AMCA got hacked – Not Quest and LabCorp
in Hashing Out Cyber SecurityRe-Hashed: How to clear HSTS settings in Chrome and Firefox
in Everything EncryptionRe-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithms
in Everything EncryptionThe Difference Between Root Certificates and Intermediate Certificates
in Everything EncryptionThe difference between Encryption, Hashing and Salting
in Everything EncryptionRe-Hashed: How To Disable Firefox Insecure Password Warnings
in Hashing Out Cyber SecurityCipher Suites: Ciphers, Algorithms and Negotiating Security Settings
in Everything EncryptionThe Ultimate Hacker Movies List for December 2020
in Hashing Out Cyber Security Monthly DigestAnatomy of a Scam: Work from home for Amazon
in Hashing Out Cyber SecurityThe Top 9 Cyber Security Threats That Will Ruin Your Day
in Hashing Out Cyber SecurityHow strong is 256-bit Encryption?
in Everything EncryptionRe-Hashed: How to Trust Manually Installed Root Certificates in iOS 10.3
in Everything EncryptionHow to View SSL Certificate Details in Chrome 56
in Industry LowdownPayPal Phishing Certificates Far More Prevalent Than Previously Thought
in Industry Lowdown