[Full disclosure I work at Google, I do not speak for the Chrome team, and more generically am not speaking for my employer in this or any of my posts here]
Recently Melih did a blog post on the topic of browser trust indicators. In this post he makes the argument that DV certificates should not receive any positive indicator in the browser user interface.
I agree with him, just not for the same reasons. Positive trust indicators largely do not work and usability studies prove that is true. Browsers introduced the “lock” user interface indicator as part of a set of incentives and initiatives intending to encourage site operators to adopt SSL.
What is important is that these efforts to encrypt the web are actually working, over half the web is now encrypted and more importantly the adoption rate is demonstrating hockey stick growth.
As a result, in 2014 Chrome started down the path of deprecating positive trust indicators all together. In-fact today Chrome already marks HTTP pages as “Not secure” if they have password or credit card fields.
The eventual goal being able to mark all HTTP pages as insecure but for this to happen SSL adoption needs to be much higher, I suspect browsers will want to see adoption in the 90% to 95% range before they are willing to make this change.
This is relevant in this case because if all pages are encrypted what value does a positive trust indicator have? None. This means that when all HTTP pages get marked “Not secure” we will probably see the lock icon disappear.
So, as I said, I agree with Mehli, the “Secure” indicator should go away but so should the lock, the question is not if, but when.
But what does that mean for EV trust indicators? I am a member of a small group, a group that thinks that EV certificates can provide value. With that said today EV certificates have some major shortcomings wich significantly limit their value, some of which include:
- It is not possible to get an EV wildcard certificate,
- CAs, largely, have ignored automation for EV certificates,
- Due to the lack of automation EV certificates are long lived and their keys more susceptible to theft as a result,
- The vetting processes used in the issuance of EV certificates are largely manual making them expensive and impractical to use in many cases,
- CAs market them as an antiphishing tool when there are no credible studies that support that,
- The business name in the certificate is based on the legal name of the entity, not the name they do business under (DBA),
- The business address details in the certificate are based on where business is registered (e.g. Delaware),
- There is no contact information in the certificate, short of the taxation address, that a user can use to reach someone in case of an issue.
Addressing these issues have either been actively been resisted by CAs, for example, DigiCert has tried to get EV wildcard certificates to be a thing in the CA/Browser Forum a number of times but CAs have voted against it every time, or simply ignored.
There are some people who are working towards addressing these gaps, for example, the folks over at CertSimple but without CAs taking a leading role in redefining the EV certificate the whole body of issues can nott be resolved. Importantly until that happens you won’t see browsers even considering updates to the EV UI.
Given this reality, browsers have slowly been minimizing the details shown in EV certificates since they can give users the wrong impression and have limited value given the contents of the certificate.
It is my belief that unless the CAs work together to address the above systematic issues in EV certificates that minimization will continue and when the web is “encrypted” it won’t just be DV that loses its positive trust indicator, it will be EV also.
Frankly, I like to know who I am paying, legal name and all. Don’t most countries require this for all shops?
That’s the value to me (and most companies, I think). Would you say that can remain, with all other issues solved?
Legal name is valuable but often it seems totally unrelated to the entity I am interacting with, keep legal identity but put something more relevant in there also.
Pingback: Entrust Datacard SSL Review July 2017 by Bruce Morton
I agree with Ryan 100%!
EV must be made more relevant.
Pingback: Problem vs Solution Value mapping
Ryan – interesting post that I only just read. I want to offer a few comments and correction as to EV certificates.
You listed “major shortcomings” for EV certs which you think limit their value. Here are my responses in [brackets]:
• It is not possible to get an EV wildcard certificate, [Kirk: Yes, this is intentional. If we issue wildcard certs such as *.evil.com for Evil, Inc., it can then be used to give the positive EV UI for something really bad like “login.paypal.com.evil.com”, which we don’t want (and which many CAs would block during the issuance process).]
• CAs, largely, have ignored automation for EV certificates [Kirk: Not true. Parts of the EV validation process must be manual, like the final cross-check and correlation of all data points in the vetting file to look for errors caused by automation, but the rest of the process can be and is automated, including corporate lookups, validation of domains, and EV cert issuance at the customer’s request. Revalidation of the organization itself only happens once a year, after which the customer can obtain EV certs automatically from many CAs, the same as for DV and OV certs.]
• Due to the lack of automation EV certificates are long lived and their keys more susceptible to theft as a result [Kirk: We have not seen any theft of keys for EV certificates over many years – I don’t think the data supports this claim as a significant problem for EV certs.]
• The vetting processes used in the issuance of EV certificates are largely manual making them expensive and impractical to use in many cases [Kirk: see comments above. There can be a negative aspect to automating everything end-to-end – that’s why you now have thousands of DV phishing certs.]
• CAs market them as an antiphishing tool when there are no credible studies that support that [Kirk: Our ongoing research and data, soon to be released, shows no phishing from EV sites. They are much safer for users.]
• The business name in the certificate is based on the legal name of the entity, not the name they do business under (DBA) [Kirk: That’s not correct – while the CA must first establish the actual legal name of the customer, the CA can then insert a confirmed DBA as the first part of the EV cert’s O field if the customer requests – so the EV cert can display as “Google [Alphabet, Inc.] [US]” for example if requested by Alphabet, Inc. as a customer – but both elements must be confirmed. See EV Guideline 9.2.1.and 11.3. Be aware that two companies such as Delta Airlines and Delta Faucets may each have the right to use the dba “Delta, so it’s important for disambiguation in an EV cert to show the real name of the organization along with the DBA.]
• The business address details in the certificate are based on where business is registered (e.g. Delaware) [Kirk: That’s not correct, the business address details in an EV cert are typically based on a confirmed place of operations for the customer. Look at the EV cert for bankofamerica.com – it lists the following business address: 135 S La Salle Street, Chicago, IL 60603, but then indicates the Bank is a Delaware corporation and provides its unique Delaware registration number. For EV certs the CA both confirms the requested business operation address of the customer, and also collects the information on the state of incorporation, but both pieces of information are included in the EV cert. See EV Guideline 9.2.5 and 9.2.7, and look inside existing EV certificates.]
• There is no contact information in the certificate, short of the taxation address, that a user can use to reach someone in case of an issue. [Kirk: Incorrect – By “the taxation address”, do you mean jurisdiction of incorporation? We don’t look up taxation address information for EV certificates and so that’s not displayed, but instead an EV certificate includes both a confirmed business operation location and the jurisdiction of incorporation, which should help users contact the company if desired.]
Addressing these issues have either been actively been resisted by CAs, for example, DigiCert has tried to get EV wildcard certificates to be a thing in the CA/Browser Forum a number of times but CAs have voted against it every time, or simply ignored. [Kirk: That’s not correct. Only actual corporations or other legal bodies can get an EV certificate because of the rigorous vetting required, including confirmation that the organization is legally registered in some jurisdiction. The CA/Browser Forum is just a name, not an organization, and simple names not tied to any legal existence do not qualify for an EV Guideline. If the Forum ever decides to incorporate, it can then easily get an EV certificate.]
There are some people who are working towards addressing these gaps, for example, the folks over at CertSimple but without CAs taking a leading role in redefining the EV certificate the whole body of issues can nott be resolved. Importantly until that happens you won’t see browsers even considering updates to the EV UI. [Kirk: CAs and browsers together have been working hard on writing and updating the EV Guidelines for over ten years, and they represent the highest and most secure standard for identifying a website and its domains today – and have virtually no phishing or malware. What more are you asking for?]
Given this reality, browsers have slowly been minimizing the details shown in EV certificates since they can give users the wrong impression and have limited value given the contents of the certificate. [Kirk: Take a look at my responses above – does that change your mind at all?]
It is my belief that unless the CAs work together to address the above systematic issues in EV certificates that minimization will continue and when the web is “encrypted” it won’t just be DV that loses its positive trust indicator, it will be EV also. [Kirk: That’s an unfortunate mistake – emerging data shows EV websites are extremely safe from phishing and malware, and users are safer there as well. EV websites are also the only real way to know if you are at the real login page for your bank or credit card company, or a fake DV phishing page that is imitating your bank or credit card company – if you eliminate the EV UI, users will literally have no way to tell the difference. Don’t do it!]
Kirk,
See my responses to your comments:
EV wildcard certificate, [Kirk: Yes, this is intentional. If we issue wildcard certs such as *.evil.com for Evil, Inc., it can then be used to give the positive EV UI for something really bad like “login.paypal.com.evil.com”, which we don’t want (and which many CAs would block during the issuance process).]
What you seem not to understand is that this restriction provides no value. Today nearly all websites are made up of resources from multiple host names, in the cases EV is used it is only used for a handful of resources. Typically the index.html (as an example) but not child resources.
These child resources have the ability to modify every bit of the web page even though the EV badge is shown and they do not have to be over DV. In-fact they are almost never over EV, so much so last time I ran a scan of the internet looking at this almost none of the existing EV sites would hosted these dependencies on sites with EV certs.
In short, if browsers only showed the EV badge when 100% of the content on a site was served with EV certificates you would not see the badge.
Your argument about the “evil” of wildcard certificates would only be material if browsers adopted this behavior and I am sure you wouldn’t want to see that either.
I am not a fan of wildcard certificates (http://unmitigatedrisk.com/?p=127) but the reality is they are needed because of SNI and how long it takes to enroll for a certificate.
In short, not allowing EV wildcards does nothing to help the user and limits its applicability.
CAs, largely, have ignored automation for EV certificates [Kirk: Not true. Parts of the EV validation process must be manual, like the final cross-check and correlation of all data points in the vetting file to look for errors caused by automation, but the rest of the process can be and is automated, including corporate lookups, validation of domains, and EV cert issuance at the customer’s request. Revalidation of the organization itself only happens once a year, after which the customer can obtain EV certs automatically from many CAs, the same as for DV and OV certs.]
You are correct that the EV requirements do require there be a human intervention but it does not require the collection and pre-validation of the evidence to be manual. The fact is it is largley manually today and this creates a negative purchase experience for users and unnecessarily delays how long it takes to get a certificate.
Having looked into this extensively the I can say the the majority of CAs take around of 4 hours to process the an EV order that was provided with all the correct information and the most efficient take around 40 minutes. That said, the lack of automation and pre-validation introduces failure rates that skew these numbers higher. With automation as CertSimple has shown this process can be cut significantly.
Beyond that, not a single CA I am aware of offers enrollment for EV over ACME or an ACME like protocol, I have not checked in about six months but it was true six months ago. The lack of support for lifecycle management via systems like this has hurt EVs adoption and will continue to do so.
Due to the lack of automation EV certificates are long lived and their keys more susceptible to theft as a result [Kirk: We have not seen any theft of keys for EV certificates over many years – I don’t think the data supports this claim as a significant problem for EV certs.]
Show me this data. The fact is that a long lived keys are more valuable to an attacker, no one can rationally argue differently. Think of it this way If I steal a key and can use it to impersonate or decrypt a site’s traffic for three years that is valuable if I can use it for 90 days it is less valuable.
For more on this see: http://unmitigatedrisk.com/?p=584
The vetting processes used in the issuance of EV certificates are largely manual making them expensive and impractical to use in many cases [Kirk: see comments above. There can be a negative aspect to automating everything end-to-end – that’s why you now have thousands of DV phishing certs.]
Computers are great at repetitive detail oriented tasks, people are not, every study on this topic ever has shown that. Just because you automate the repetitive detail oriented part does not mean you remove the human from the process.
CAs market them as an anti-phishing tool when there are no credible studies that support that [Kirk: Our ongoing research and data, soon to be released, shows no phishing from EV sites. They are much safer for users.]
Well I can’t say anything about non-published data but there have been several reports that show the exact opposite of what you suggest, for example:
https://news.netcraft.com/archives/2011/12/30/phishing-sites-using-extended-validation-ssl.html
The business name in the certificate is based on the legal name of the entity, not the name they do business under (DBA) [Kirk: That’s not correct – while the CA must first establish the actual legal name of the customer, the CA can then insert a confirmed DBA as the first part of the EV cert’s O field if the customer requests – so the EV cert can display as “Google [Alphabet, Inc.] [US]” for example if requested by Alphabet, Inc. as a customer – but both elements must be confirmed. See EV Guideline 9.2.1.and 11.3. Be aware that two companies such as Delta Airlines and Delta Faucets may each have the right to use the dba “Delta, so it’s important for disambiguation in an EV cert to show the real name of the organization along with the DBA.]
You are correct that it is technically possible for a requestor to get the DBA included, the issue is that it is not done by default and is not required. When looking at EV certs in outside the largest sites you find the name very often is not related to the website in question from the users perspective. Displaying a name that to the user is totally unrelated to the site in question (from the users perspective) devalues EV.
The business address details in the certificate are based on where business is registered (e.g. Delaware) [Kirk: That’s not correct, the business address details in an EV cert are typically based on a confirmed place of operations for the customer. Look at the EV cert for bankofamerica.com – it lists the following business address: 135 S La Salle Street, Chicago, IL 60603, but then indicates the Bank is a Delaware corporation and provides its unique Delaware registration number. For EV certs the CA both confirms the requested business operation address of the customer, and also collects the information on the state of incorporation, but both pieces of information are included in the EV cert. See EV Guideline 9.2.5 and 9.2.7, and look inside existing EV certificates.]
You are correct it is technically possible for a requestor to get a real business address included. The issue is that it’s not done by default and not required. A brief search in CenSys will show you that these taxation addresses are extremely common.
More importantly, though there is no requirement that the address be useful for reaching the business, it serves only to uniquely identify the business. For the address to provide value it needs to be a means of contact that the user can actually use.
There is no contact information in the certificate, short of the taxation address, that a user can use to reach someone in case of an issue. [Kirk: Incorrect – By “the taxation address”, do you mean jurisdiction of incorporation? We don’t look up taxation address information for EV certificates and so that’s not displayed, but instead an EV certificate includes both a confirmed business operation location and the jurisdiction of incorporation, which should help users contact the company if desired.]
Yes, that is what I meant, the address in which they were incorporated. Try mailing a letter to 10 addresses listed in EV certificates and see if you get a response. Hint, you won’t except in rare exceptions.
Addressing these issues have either been actively been resisted by CAs [Kirk: CAs and browsers together have been working hard on writing and updating the EV Guidelines for over ten years, and they represent the highest and most secure standard for identifying a website and its domains today – and have virtually no phishing or malware. What more are you asking for?]
I am concretely asking for the issues I have called out above to be addressed. Each of these has come up in the CAB Forum numerous times over the last 10 years and numerous times CAs have resisted addressing them.
While I am not speaking for any UA, I can confidently say the reason the EV details have been minimized year over year is that issues like the above have been ignored by the CA ecosystem.
As for your claims of EV certificates having some magical power to prevent phishing and malware, this is not backed up by data and in fact, is contradicted by data.
Ryan, I some of your responses to my comments are not completely correct or are unfair, but there’s no need to argue any more about that.
What I’d really like to know is, do you have any concrete proposals for changing the EV Guidelines to address your concerns? If yes, can you share your specific proposals for change? The Forum will promptly get to work on them – after all, you are a participant in Forum activites and can introduce proposals at will. If you have no concrete proposals but just dislike EV certificates no matter what, it’s hard to respond in any meaningful way.
I would note that Google has strongly hinted for years that it intends to drop the EV UI indicator in Chrome, so your opinions above are consistent with this policy. It will be a pity if all websites – DV, OV, and EV – are treated as equivalent from a security standpoint and users are not able to tell the difference, as this will only exacerbate the fake DV login page problem (affecting PayPal, banks, credit card companies, etc.) that we are facing today.
Kirk,
If I have been unfair or stated anything incorrect I would like to update the text accordingly so please let me know.
As for what changes I think are needed for EV to survive, I thought I was pretty explicit above but I can try once more in shorter form:
1) Allow for wildcard certificates,
2) Require and verify that the business name details be contextually relevant to the site,
3) Require and verify the contact information in the certificate be used for the user to reach the site operator and get a response,
4) Require that an online contact mechanism such as email or a phone number be validated and included in the certificate so the user can reach the site operator and get a response,
5) CAs need to stop falsely representing the value proposition of EV being an effective mitigator of phishing and malware or provide a real study to contradict all of the other studies that show otherwise,
6) CAs need to automate the pre-validation and as much of the actual validation as possible getting vetting times down significantly and improve the user experience of acquiring the certificates,
7) CAs need to support and encourage automatic lifecycle management of EV certificates with ACME or an alternate open protocol,
8) CAs need to encourage shorter lived server keys by changing defaults to short lived keys even if users can request longer periods.
As for me being the one to work to save EV, I have enough on my plate 🙂
First of all, I am glad that we are communicating. its all very positive.
let me add my 2 cents.
Here are the areas I agree/disagree with and why.
1)Agree..we just have to work to find a way..maybe we start with very limited use cases and work from there
2)Agree..(the context within which Ryan is proposing “relevance” is something i agree with in general)
3)Agree..end users need this information…and EV could be a way to convey it..or OV..or DV…(CAs can get the information and put it in a cert..the question is how will browser display it…the bigger question is about browser display and not how CAs can validate and encapsulate data in a certificate. I explained the needs in more detail in my blog https://www.melih.com/2017/09/03/problem-vs-solution-value-mapping/ .
4)Agree..similar to 3..
5)Disagree: Phishing is a problem of inability to identify where you are. EV has the capability to tell you where you are, therefore it can be used as phishing protection. Its all about how the browser display the identity information encapsulated in the certificate.
6)Neutral: this is a market condition….the more efficient you make the process..the more cost effective your product becomes….free market will take care of this…don’t need to regulate it.
7)Disagree: There simply is no need as all our respective customers who use EV use our own cert management protocol. There simply is no usecase. This is a doing something for the sake of doing something.
8)Disagree: We ping ponged this argument in great detail https://www.melih.com/2017/05/06/short-lived-certificates-cannot-solve-the-un-aware-victim-problem-4/ .. Short lived keys are a fallacy…When we make available the DNS based Revocation platform, there will be no need for short lived keys.
I answered all this while I was eating what was on my plate 😉
I really think its healthy to have open discussions and encourage both Kirk and Ryan whose opinions I value. Lets keep the discussion going and “agree on the problem definition”.
Pingback: Problem vs Solution Value mapping - Melih Abdulhayoğlu
Pingback: Reality vs Fantasy – The DV vs EV argument | UNMITIGATED RISK