Update: Transport Layer Security Cheat Sheet - Consider the use of Extended Validation Certificates

[joneskoo]

What is missing or needs to be updated?

I believe the section about TLS cheat sheet talking about Extended Validation certificates is not aligned with current industry best practices.

EV certificates are today practically entirely hidden from browser users, completely ignored by API users and provide very little advantage.

On the other hand, EV certificates incur significant cost and bureaucracy to issue and renew. As far as I understand, they prevent automating renewal, which can add overhead or at worst risk disruption when certificates expire or get revoked.

https://github.com/OWASP/CheatSheetSeries/blob/957b043c27300912df52634821307a5f14703451/cheatsheets/Transport_Layer_Security_Cheat_Sheet.md?plain=1#L145-L151

Checking top brands I could think of, they all used either domain-validation or organization-validation certificates.

How should this be resolved?

I believe this section could be removed, checking all references pointing to it. Removing it would simplify the cheat sheet.

My reading is that the organization-validation certificates are mostly because the organization operates its own CA, or has made arrangements in the past when EV certificates were still relevant, based on which organizations have OV or DV. In either case, this section talks about EV specifically and not OV. I don't believe there is any reason to consider recommending OV for browser or API uses.

[kwwall]

I personally think the EV section should be left in.

While I agree that EVs are probably not as valued as as they once were (probably because they were greatly over-hyped from the start), I don't think we should imply that they don't have any use / value at by removing the section and thus not mentioning them at all.

I don't see anything outright incorrect in the 3 paragraphs in that section. I do think perhaps was may want to revise the section heading from "Consider the use of Extended Validation Certificates" (which may come across as a recommendation of sorts from OWASP) and tone it down a bit and present it as something more neutral, such as "What about the use of Extended Validation Certificates?".

We might add a sentence there about the additional phishing that they claim to provide. However, OWASP needs to recognize that ultimately choosing EV certs is a risk decision based on cost and perceived value and I don't think OWASP should just yank that section as that's not exactly being neutral either. There are lots of small to medium businesses that wouldn't generally even be aware of EV certs exist as an option if they were not mentioned in this CS.

[joneskoo]

What is the desired outcome of the OWASP cheat sheet and what language best supports that? My understanding is that cheat sheet should guide toward doing the right thing. I don't see removing the paragraph to be taking an opinion against their use; the document should be seen as standalone. By having less, it would give more weight to the remaining recommendations. I would not add text against OV or EV, as they could indeed have valid use cases but are those in scope of OWASP, how?

Are there sources to cite to support recommending anything other than DV today? If the recommendation is based on citable requirements, best practices, maybe it's possible to reword it to be useful? DV doesn't need a mention because if the only thing you can do is good enough, it needs no cheat sheet.

Factually correct is not sufficient for a cheat sheet. I believe there also needs to be a concrete outcome from following the recommendation, and if reader is expected to evaluate or consider it, there should be some information what factors might affect such decision.

The current language clearly takes an opinion: "Chrome and Firefox .. do not believe that EV certificates provide any additional protection" and "there is no security downside". My argument is that there are security downsides: cost, lack of automation, increased overhead. These indirectly may lead to added risk to compromise key material. And the word "believe" implies that it's a belief and browser vendors did not present factual arguments, but no evidence is shown against their "belief". At least these wordings and the title need revising.

[jmanico]

I prefer leaner cheatsheets. EV's certificates are simply not that important anymore, and I vote to have them removed.

[markgamache]

Long time PKI guy here. Only slight appeal to authority. I promise to back claims.

I'd suggest changing the topic and calling the section Certificate Validation types. First off, in the threat model, the server certificate is meant to allow the client to protect itself by authenticating the DNS name of the server. Unless a cert somehow confers better validation to the TLS stack and onto the user or by terminating the handshake automatically, the level of pain to get the certificate has no bearing on client-side security. DV, OV, and EV are all treated exactly the same by browsers and all the major TLS stacks, therefore they don't increase security. There is zero value for the attacker to try and get EV or OV certs. So I am agreeing with @jmanico and @joneskoo .

I further agree with @joneskoo that most come to OWASP for a bit of help parsing the threat models and looking for recommendations, not just data. In fact, there are many vulns that get filed against orgs that can only be traced back to doing something that OWASP says to do or not to do. I will say that many seem to come to OWASP to be told what to do and the docs should accommodate that too.

I'm suggest going as far as pointing out that all the validations are functionally the same and that treating OV and EV as better is security theater. IMO, security professions give ourselves a bad name when we embrace obvious theater. I want to build credibility with developers, not erode it. My point being that just dropping the section may not make it clear that EV is not magic.

@kwwall is right to leave the decision up to the server owner, but I think giving the facts and suggesting the right path with a bit of a nudge is a legitimate use of OWASP's clout.

[joneskoo]

It sounds like everyone here agrees this section needs at minimum updating, thats good.

I checked the rest of the repository and couldn't find references to this so I made PR with just the simplest option of removing this to move things forward. No harm done if it's rejected.

For me, what's important is to have a clear audience where the recommendation is useful and it should be backed by justified reasoning and/or citation. For example, is the target APIs or browsers? Would the user be expected to click through certificate details and in what scenario that's providing meaningful difference from the information not being there?

I'm specifically thinking of https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/ as a case in point why "you can check the legal name of the company behind the certificate" is not that useful, and it's arguably even less useful if seeing that requires you to go to view certificate details. So what's the argument?

Anyone have an alternate version to propose?

[markgamache]

@joneskoo give me a day and I will write up a PR that covers the what and why of the OV vs DV vs EV and lays out what we have said in not overly biased tones.

[kwwall]

@joneskoo give me a day and I will write up a PR that covers the what and why of the OV vs DV vs EV and lays out what we have said in not overly biased tones.

Not overly biased tones is good. You never know when a CA or two might decide to sponsor OWASP. :)

[jmanico]

CA’s are are cheap bastards Kevin. Hit em hard and push them to do better! 😁

[markgamache]

the PR is in. Do I need to harass anyone (nicely) or will they get automated nags?

[kwwall]

@markgamache - The nags are automatic for the most part, but they may be more effective if in your PR you request reviewers.

[joneskoo]

👀

[jmanico]

There is tons of (good) feedback from @joneskoo that I would like to see addressed before approving this PR

[markgamache]

@joneskoo does the system let you close the issue now?