Intent to Remove: Support for commonName matching in certificates

[Ryan Sleevi]

Primary eng (and PM) emails
rsl...@chromium.org awha...@chromium.org

Link to "Intent to Deprecate" thread

No deprecate thread; it's been deprecated since HTTPS was first introduced (RFC 2818) in 2000.

Summary

Certificates have two ways to express the domain/IP they're bound to - one which is unstructured and ambiguous (commonName), and one which is well-defined (subjectAltName). In the absence of any subjectAltNames, Chrome currently falls back to comparing the domain against the commonName, if present.

This proposal is to remove that fallback path; in effect, requiring a subjectAltName. Ideally, we would do this for all certificates (publicly trusted and privately trusted), but if there are concerns about compat risk, we can restrict it to publicly trusted certificates.

Motivation

Since 1997 (X.509v3's ratification), certificates have had two ways to express a binding to a domain name - either via the commonName attribute within the certificate's subject, or via the explicitly typed (dNSName or iPAddress) of the SubjectAlternativeName Extension.

Since RFC 2818 (published in 2000, first drafted in January 1998), the use of the commonName field has been considered deprecated, because it's ambiguous and untyped - that is, it might contain a human-readable name or it might be a domain name.

The use of the subjectAlternativeName fields leaves it unambiguous whether a certificate is expressing a binding to an IP address or a domain name, and is fully defined in terms of its interaction with Name Constraints. commonName, however, is ambiguous, and because of this, support for the commonName has been a source of security bugs - in both Chrome and the libraries it uses and within the TLS ecosystem at large.

Compatibility Risk

Low. RFC 2818 has deprecated this for nearly two decades, and the Baseline Requirements (which all publicly trusted CAs must abide by) has required the presence of a subjectAltName since 2012.

Mozilla Firefox already requires the subjectAltName for any newly issued publicly trusted certificates since Firefox 48 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1245280 ).

Usage information

From a metrics perspective, less than .002% of publicly trusted certificate validations would require this behaviour (Net.CertCommonNameFallback minus Net.CertCommonNameFallbackPrivateCA).

As 1.57% of privately-trusted CA certificates rely on this behaviour (or 0.1% of all certificate validations), it may be premature to deprecate it for privately-trusted CAs; alternatively, we could remove it with an enterprise policy to allow it for a limited number of releases. Unfortunately, despite being deprecated for nearly 20 years, it's unlikely we'd be able to drive this number down (and improve the security of the ecosystem) without taking further action.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=308330

Entry on the feature dashboard

https://www.chromestatus.com/feature/4981025180483584 (Apologies if I botched this; not sure how to capture "The standard says this is deprecated, and Mozilla supports deprecating")

[Chris Harrelson]

Hi Ryan,

Why not follow Firefox's lead and only remove support for new certificates? It seems that would allow a gradual phasing out of remaining uses, and also unifies behavior across two user agents and thus reduces compatibility differences.

Chris

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Ryan Sleevi]

As the metrics show, the compatibility risk is _extremely_ low.

The "gradual phasing out" began in 2012, when such certificates were forbidden from being issued. Any compatibility issues exist with CAs that have been violating the Baseline Requirements.

From an ecosystem health, both at Google/Chromium and at large, the ecosystem and Chrome end up more secure without any date-based exceptions, and ideally without any CA-based exceptions.

[=JeffH]

Just want to point to RFC6125 [1] in addition to RFC 2818 (referred to
as [HTTP-TLS] in RFC6125), which contains further details wrt
(deprecated) use of Common Name in TLS/SSL certs (aka CN-ID in RFC6125
parlance).

[ for some reasons I still don't quite understand, our shepherding AD
didn't allow RFC6125 to officially "update" RFC2818 and so folks looking
at just the latter are often unaware of the former ]

HTH,

=JeffH

[1] https://tools.ietf.org/html/rfc6125

[Philip Jägenstedt]

For those of us a bit out of the loop, can you explain why making date-based exceptions if a bad idea? Are the dates trivially forged, or is it just hard to explain this behavior to web developers?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Ryan Sleevi]

Both! But especially the former - date-based restrictions don't provide any tangible benefit, because they are in control of the issuer - which, in the case of name-constrained CAs, may and can be the attacker.

Again, the compatability risk here is less than .002%, which itself only exists from CAs not following the Browser-dictated rules that were established in 2012. Any site that breaks was already at risk of breakage due to the CA being potentially suspended for non-compliance. All of the compatibility issues Mozilla encountered were with non-compliant CAs, and those CAs are now at greater risk of removal because of this.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[PhistucK]

Sorry if that were answered already, but, what does removing support mean?

Will the websites stop working altogether if they only have certificates with commonName, or will they just be shown as insecure?

☆PhistucK

[Ryan Sleevi]

The certificate would not be considered valid for the name - so it'd cause an interstitial.

Any reports of interstitials being caused, we'd treat as a CA violation of the Baseline Requirements and put the CA on notice.

[Philip Jägenstedt]

Hmm, so will this directly results in some CAs being put on notice? Do we not have a way of finding those CAs without actually making the change user-facing? If so, do you know anything about which CAs these certs are coming from?

Do you have any idea how ".002% of publicly trusted certificate validations" translates to proportion of pages that will be impossible to load? (Must depend on when and how often validation happens.)

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK]

Nothing is "impossible", it would just be considered as insecure and shown an interstitial.

☆PhistucK

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Ryan Sleevi]

As I feel like you're appying a standard inconsistent with the principles, it would be helpful if you could better articulate your concerns.

We've already put many of the responsible CAs on notice. The certificates are already obligated to be replaced. The compatibility risk is well below the threshold we've established. It's unclear what you think is appropriate beyond that, but perhaps more importantly, it's unclear what your concerns are or what you believe the risks to proceeding are.

Do you believe .002% is too great a risk? Why? Should we update our criteria to reflect this?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

I wanted to know if the CAs in question would be found only by actually making the change, given the phrasing "Any reports of interstitials ... put the CA on notice." But it sounds like you those CAs already have been put in notice, so that's good.

On the risk, I'd like to understand what the .002% number means in terms of proportion of pages views affected, or a qualified guess if there is none. Can one just multiply by the proportion of page views that use HTTPS at all, or is it more complicated?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Ryan Sleevi]

On Mon, Jan 30, 2017 at 10:06 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

I wanted to know if the CAs in question would be found only by actually making the change, given the phrasing "Any reports of interstitials ... put the CA on notice." But it sounds like you those CAs already have been put in notice, so that's good.

On the risk, I'd like to understand what the .002% number means in terms of proportion of pages views affected, or a qualified guess if there is none. Can one just multiply by the proportion of page views that use HTTPS at all, or is it more complicated?

It doesn't directly map, due to connection coalescing of requests (either H/1.1 keep-alives or H/2 pooling). While that would normally sound like "undercounting", it in effect actually overcounts, because we know the majority of page loads are to origins making use of either keep-alive or H2, meaning the stat ends up biasing towards disproportionately representing 'legacy' services because they effectively cause more validations than a coalesced stream.

[David Benjamin]

Due to the net stack's proximity from Blink and architecture, we can't reasonably measure things with page load metrics. Our metrics are all necessarily based on per-connection or per-HTTP-request, not per-page-load. This has been the case with TLS deprecations too; I've made sure to say xyz% of connections or HTTP requests or whatever it is I'm measuring. My experience matches what Ryan says in terms of under- and overcounting.

Risk is further reduced because, unlike most net stack removals which necessarily hit a fatal error, certificate errors we use interstitials which have a click-through. Certificate matters also differ from web content because random web developers cannot mint certificates; they get them from CAs which are required to follow various rules.

David 

[PhistucK]

On Mon, Jan 30, 2017 at 9:09 PM, David Benjamin <davi...@chromium.org> wrote:

certificate errors we use interstitials which have a click-through

​Only in case of a document level navigation (iFrame or top level), though. I do not remember, do resources from previously-unvisited broken HTTPS URL still load as usual?

☆PhistucK

[Ryan Sleevi]

No. 

[PhistucK]

Oh, so that does add some (small and negligible, given the already low percentage) degree of risk

☆PhistucK

[David Benjamin]

The unquoted part of my email was that I was quoting factors which further reduce risk. We do not add prompts on every random thing; on the JS side, we just let the JS code hit an exception, and most net stack errors are fatal. That one of the factors which reduces risk above and beyond the norm has a caveat is hardly a risk add. :-P

[Mike West]

Non-OWNER's LGTM from a security perspective. I agree with David and Ryan that the risk seems quite manageable given the overall number of connections which would fail due to the new behavior, and that the reward of having sane SAN/CN behavior that aligns with the BRs and alleviates Firefox's first-mover pain would be valuable.

-mike 

[Philip Jägenstedt]

Thanks Ryan and David for laying out why the .002% is likely overcounting compared to a hypothetical per-page-view equivalent. That (or .0002%) will still break something, but we don't really have a principled way of making these trade-offs. In the end, there doesn't seem to be any other option apart from living with the quirk forever, so LGTM1 to give it a try. If there is interesting fallout, summarizing it on this thread would be great.

[Jochen Eisinger]

lgtm2 

please ping the enterprise team to watch out for potential breakages

[Chris Harrelson]

LGTM3

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[fatm...@gmail.com]

RFC 2818 states: (Section 3.1, para 4)

"If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead."

By removing support for the CN field, surely Chrome becomes RFC non-compliant (regardless of deprecation) because the RFC states that "Common Name field in the Subject field of the certificate MUST be used" if the CN is not present? How can the MUST be obeyed if the certificate contains only a populated CN field and no populated subjectAltName field if the use of CN is deprecated in Chrome?

In any case, from the perspective of private PKIs, this may be challenging from an operational perspective. For example, the default "WebServer" template in Microsoft ADCS does not use subjectAltName. Whilst this default template can be copied and modified to include the subjectAltName field, reissuance of all these already issued Web Server certificates may be a significant undertaking for those organisations with private PKIs using Chrome if this policy is implemented.

[Ryan Sleevi]

On Wed, Feb 1, 2017 at 1:25 AM, <fatm...@gmail.com> wrote:

RFC 2818 states: (Section 3.1, para 4)

"If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead."

By removing support for the CN field, surely Chrome becomes RFC non-compliant (regardless of deprecation) because the RFC states that "Common Name field in the Subject field of the certificate MUST be used" if the CN is not present? How can the MUST be obeyed if the certificate contains only a populated CN field and no populated subjectAltName field if the use of CN is deprecated in Chrome?

RFC 6125

 

In any case, from the perspective of private PKIs, this may be challenging from an operational perspective. For example, the default "WebServer" template in Microsoft ADCS does not use subjectAltName. Whilst this default template can  be copied and modified to include the subjectAltName field, reissuance of all these already issued Web Server certificates may be a significant undertaking for those organisations with private PKIs using Chrome if this policy is implemented.

It might be; however, Microsoft ADCS is also AD integrated for deployment of those certificates, so it's also arguable that resolving that issue may not be a significant undertaking, because ADCS is highly automated.

In such situations, we rely on our data, enterprise policy controls, and enterprise policy support team, all of which indicate that this concern is unlikely to actually manifest as a significant customer issue. 

[bhu...@gmail.com]

We use our MS CA for other non AD integrated applications, and we actually have the subjectAltName field disabled for any certificates that are only authenticating one domain, user, device, etc. and only have the Common Name field to verify against.

There may be others in this situation as Microsoft actually recommends disabling the SubectAltName field, see this link https://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx

Nathan

[PhistucK]

:S

So who is right? Microsoft sort of says that only using commonName prevents impersonation attacks and this intent says it is sort of the other way around. :(

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

[Adam Langley]

On Thu, Feb 2, 2017 at 9:37 PM, <bhu...@gmail.com> wrote:

We use our MS CA for other non AD integrated applications, and we actually have the subjectAltName field disabled for any certificates that are only authenticating one domain, user, device, etc. and only have the Common Name field to verify against.

There may be others in this situation as Microsoft actually recommends disabling the SubectAltName field, see this link https://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx

The document merely notes that SANs need to be carefully reviewed because they specify who a certificate is being issued for. However, if you only use commonNames then you already have to review those names to the same standard. Like many other extension fields, the SAN is sensitive and MS are right to highlight that, but there's no argument there for continuing to wedge hostnames into CN.

Cheers

AGL

[Eric Lawrence]

https://bugs.chromium.org/p/chromium/issues/detail?id=706398

HTTPS-MitM vendor "Securly" generates self-signed interception certificates that lack SubjectAltNames, leading to blocks in Chrome 58. I've pinged their support team, but do we have any sort of outreach tracker or anything else I should do?

[sasc...@gmail.com]

God...there are days I really believe some browser programmers are so far away from their users and breaks or complicate HTTPS/SSL/TLS stuff in the name "of security" to the worse by for example breaking or hindering SSL scanning / MITM in most ways possible as by enforcing HSTS in the browsers or this unnecessary change to ignore the CN field in favor of SAN even if CN never was declared dead AFAIK.

Same with SSL warnings in a browser in general. Long time ago I liked chrome for it´s simple, logic and intuitive Cert warning approach "red warning page for a certificate issue" with a direct accessible "Proceed" Button shown instead a oversized warning page which has to be expanded everytime to continue to a warned website. This definately is not a security improvement, this is only enforcing people to follow many sequential steps to reach a website instead simply go to a "proceed" button on a red warning page.

Independent of various discussions by some security researchers and/or developers "MITM breaks your security" IS MITM / SSL scanning one of the best ways for companies to protect normal users against their internet usage against every common sense. And I keep that position against all RC4, TLS1.x etc. discussions, which definately have their right to be discussed due security concerns (on a high level). Todays real threats normal users a confronted are malware or sensitive documents slipping through SSL/TLS secured connectios uncontrolled. I personally prefer any "insecure" RC4 cipers for my connection over any "sorry, we do not scan SSL...this breaks the intent of SSL".

Really...real concerns aren´t nation state hackers exploiting broken or compromised cipher suites....todays companies are more hurt by all that crap entering a network via encrypted connections.

And even if HSTS should "improve" security....Yes, I like to MITM services as Google Search and other websites to halfway effectively block advertisments, trackers and data mining companies and all other stuff which concerns me more than those proposed, theoretical "security issues"

Sometimes I also get tempted to think some "enhancements" are not done to improve security, but to keep money flowing by protecting the ability to flood people with advertisements and track every virtual movement with tons of trackers, analytics and user behaviour webservices, which btw. as side effect also namely slows down the whole surfing experience besides the related security concerns...

Also why shouldn´t I trust for internal use more my internal PKI used for MITM in proxies than trusted certification authorities ?

Really....why is no one developing technologies which proactively assists intended MITM, but maybe allows to place an overlay in a browser or a warning sign somewhere in the browser telling the user "this connection is MITM´ed, as the original certificate got replaced", but allows the users to do their work instead making life of admins in the companies difficult by maintaining tons of SSL exclusions and intermittently get hit by new SSL behaviours or issues due "security" changes. In 99% of the MITM cases these are most likely legitimate SSL Proxies used in companies to protect their infrastructure and users, and a small percentage are real attacks maybe used in some public places or "live hacker demos" on some security events....

my very personal 5 cents...

[sasc...@gmail.com]

BTW - small addendum: My previous post wasn´t specifically placed due this concrete or specific thread/announcement - I mixed various contents from the past and my considerations to all those "SSL/TLS" enhancements and general discussions in terms of MITM usage. I generally support the idea to assist MITM instead making it worse to use in a way which still keeps the ability to inform users, that they may get MITM´ed / SSL scanned, but helps especially companies to protect their infrastructure and users against crap passing encrypted connections.