Discussion:
Intent to Remove: Support for commonName matching in certificates
(too old to reply)
Ryan Sleevi
2017-01-28 00:44:57 UTC
Permalink
*Primary eng (and PM) emails*
***@chromium.org ***@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")
--
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.
Chris Harrelson
2017-01-28 19:06:14 UTC
Permalink
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
Post by Ryan Sleevi
*Primary eng (and PM) emails*
*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")
--
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
--
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
2017-01-28 22:24:45 UTC
Permalink
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.
Post by 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
Post by Ryan Sleevi
*Primary eng (and PM) emails*
*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")
--
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
--
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.
Philip Jägenstedt
2017-01-29 10:09:40 UTC
Permalink
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?
Post by 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.
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
*Primary eng (and PM) emails*
*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")
--
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
--
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
2017-01-29 19:42:40 UTC
Permalink
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.
Post by 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?
Post by 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.
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
*Primary eng (and PM) emails*
*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")
--
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
--
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
2017-01-29 20:59:35 UTC
Permalink
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*
Post by 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.
Post by 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?
Post by 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.
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
*Primary eng (and PM) emails*
*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")
--
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
--
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
--
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
2017-01-29 22:48:11 UTC
Permalink
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.
Post by 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*
Post by 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.
Post by 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?
Post by 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.
On Sat, Jan 28, 2017 at 11:06 AM, 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
*Primary eng (and PM) emails*
*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")
--
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
--
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
--
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.
Philip Jägenstedt
2017-01-30 08:30:01 UTC
Permalink
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.)
Post by 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.
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*
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.
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?
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.
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
*Primary eng (and PM) emails*
*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")
--
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
--
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
--
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
2017-01-30 09:00:55 UTC
Permalink
Nothing is "impossible", it would just be considered as insecure and shown
an interstitial.


☆*PhistucK*
Post by 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.)
Post by 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.
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*
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.
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?
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.
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
*Primary eng (and PM) emails*
*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")
--
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
--
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
--
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
2017-01-30 17:29:31 UTC
Permalink
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?
Post by 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.)
Post by 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.
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*
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.
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?
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.
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
*Primary eng (and PM) emails*
*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")
--
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
--
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
--
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.
Philip Jägenstedt
2017-01-30 18:06:06 UTC
Permalink
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?
Post by 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?
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.)
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.
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*
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.
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?
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.
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
*Primary eng (and PM) emails*
*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")
--
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
--
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
--
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
2017-01-30 18:15:17 UTC
Permalink
Post by 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?
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.
--
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.
David Benjamin
2017-01-30 19:09:12 UTC
Permalink
On Mon, Jan 30, 2017 at 1:16 PM Ryan Sleevi <***@chromium.org> wrote:

On Mon, Jan 30, 2017 at 10:06 AM, Philip JÀgenstedt <***@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.


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
--
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
2017-01-30 21:08:32 UTC
Permalink
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*
--
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
2017-01-30 21:14:41 UTC
Permalink
Post by PhistucK
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?
No.
--
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
2017-01-30 21:26:49 UTC
Permalink
Oh, so that does add some (small and negligible, given the already low
percentage) degree of risk


☆*PhistucK*
Post by PhistucK
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?
No.
--
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.
David Benjamin
2017-01-30 21:30:51 UTC
Permalink
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


On Mon, Jan 30, 2017 at 4:27 PM PhistucK <***@gmail.com> wrote:

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


☆*PhistucK*

On Mon, Jan 30, 2017 at 11:14 PM, Ryan Sleevi <***@chromium.org> wrote:


On Mon, Jan 30, 2017 at 1:08 PM, PhistucK <***@gmail.com> wrote:


On Mon, Jan 30, 2017 at 9:09 PM, David Benjamin <***@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?


No.
--
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.
'Mike West' via blink-dev
2017-01-30 21:39:15 UTC
Permalink
Post by Ryan Sleevi
Post by 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?
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.
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
--
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.
Philip Jägenstedt
2017-01-31 05:46:41 UTC
Permalink
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.
Post by 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?
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.
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
--
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.
Jochen Eisinger
2017-01-31 05:53:34 UTC
Permalink
lgtm2

please ping the enterprise team to watch out for potential breakages
Post by 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.
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.
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
--
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.
Chris Harrelson
2017-01-31 20:40:16 UTC
Permalink
LGTM3
Post by Jochen Eisinger
lgtm2
please ping the enterprise team to watch out for potential breakages
Post by 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.
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.
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
--
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
--
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.
=JeffH
2017-01-29 01:54:49 UTC
Permalink
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
--
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.
f***@gmail.com
2017-02-01 09:25:25 UTC
Permalink
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.
--
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
2017-02-01 18:59:28 UTC
Permalink
Post by f***@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?
RFC 6125
Post by f***@gmail.com
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.
--
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.
b***@gmail.com
2017-02-03 05:37:42 UTC
Permalink
Post by Ryan Sleevi
Primary eng (and PM) emails
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")
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
--
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
2017-02-03 07:03:27 UTC
Permalink
: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*
Post by Ryan Sleevi
Post by Ryan Sleevi
Primary eng (and PM) emails
Link to "Intent to Deprecate" thread
No deprecate thread; it's been deprecated since HTTPS was first
introduced (RFC 2818) in 2000.
Post by Ryan Sleevi
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.
Post by Ryan Sleevi
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.
Post by Ryan Sleevi
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.
Post by Ryan Sleevi
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.
Post by Ryan Sleevi
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.
Post by Ryan Sleevi
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.
Post by Ryan Sleevi
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 ).
Post by Ryan Sleevi
Usage information
From a metrics perspective, less than .002% of publicly trusted
certificate validations would require this behaviour
(Net.CertCommonNameFallback minus Net.CertCommonNameFallbackPrivateCA).
Post by Ryan Sleevi
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.
Post by Ryan Sleevi
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")
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
--
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
--
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.
p***@gmail.com
2017-09-26 17:47:26 UTC
Permalink
If anybody can outline an attack against either a valid common name when a SAN is present or attack when it is not present i'd be interested.
: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
Post by Ryan Sleevi
Primary eng (and PM) emails
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")
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
--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e9f71def-769c-4393-9ca5-0edff0314c3f%40chromium.org.
Ryan Sleevi
2017-09-27 00:50:01 UTC
Permalink
https://nameconstraints.bettertls.com/
Post by p***@gmail.com
If anybody can outline an attack against either a valid common name when a
SAN is present or attack when it is not present i'd be interested.
Post by 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. :(
Post by PhistucK
☆PhistucK
Post by Ryan Sleevi
Primary eng (and PM) emails
Link to "Intent to Deprecate" thread
No deprecate thread; it's been deprecated since HTTPS was first
introduced (RFC 2818) in 2000.
Post by PhistucK
Post by Ryan Sleevi
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.
Post by PhistucK
Post by Ryan Sleevi
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.
Post by PhistucK
Post by Ryan Sleevi
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.
Post by PhistucK
Post by Ryan Sleevi
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.
Post by PhistucK
Post by Ryan Sleevi
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.
Post by PhistucK
Post by Ryan Sleevi
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.
Post by PhistucK
Post by Ryan Sleevi
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 ).
Post by PhistucK
Post by Ryan Sleevi
Usage information
From a metrics perspective, less than .002% of publicly trusted
certificate validations would require this behaviour
(Net.CertCommonNameFallback minus Net.CertCommonNameFallbackPrivateCA).
Post by PhistucK
Post by Ryan Sleevi
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.
Post by PhistucK
Post by Ryan Sleevi
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")
Post by PhistucK
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.
Post by PhistucK
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
Post by PhistucK
Nathan
--
You received this message because you are subscribed to the Google
Groups "Security-dev" group.
Post by PhistucK
To unsubscribe from this group and stop receiving emails from it, send
--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvaWvb4KJm7%3DEmHV_FtQhvPo%2BDEf2O%3DRLaFc-ri2N5ErNJPww%40mail.gmail.com.
Adam Langley
2017-02-03 16:05:33 UTC
Permalink
Post by b***@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
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
--
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.
i***@gmail.com
2017-05-18 17:48:11 UTC
Permalink
Post by b***@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
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
Microsoft says just above that "the use of user-defined SANs can increase the risk of impersonation attacks".

As a sysadmin in an IT department where we use AD CS for internal applications and sites, this is a major pain. The certificates, while issued by AD CS, are for various other platforms that don't integrate with AD.

It will be easier for me to tell our users to use another browser rather than make all these application changes.

IT departments are staffed with minimal personnel, and issues like this will be deferred/deflected/etc. as much as possible.
--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/da02eabc-0cb3-45c7-a4db-9aa63af3423d%40chromium.org.
'Eric Lawrence' via blink-dev
2017-03-29 15:55:31 UTC
Permalink
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?
Post by Ryan Sleevi
Primary eng (and PM) emails
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")
--
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.
s***@gmail.com
2017-04-26 13:58:10 UTC
Permalink
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...
--
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.
s***@gmail.com
2017-04-26 14:17:20 UTC
Permalink
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.
--
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.
m***@gmail.com
2017-04-26 14:18:46 UTC
Permalink
It turns out that CentOS 6 and CentOS 7 ship with OpenSSL configured to generate certificates with only CN, no SAN.

Mozilla's reference guide to server side TLS configuration talks a lot about algorithms, but doesn't even mention subjectAltName:
https://wiki.mozilla.org/Security/Server_Side_TLS

The official OpenSSL site seems to have nothing relevant in the documentation:
https://www.google.com/search?sitesearch=www.openssl.org&q=subjectAltName

Microsoft presents it as an extension which can *damage* security and "increase the risk of impersonation attack":
https://technet.microsoft.com/en-us/library/ff625722%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396

Given the above and the fact that I'd never seen a single set of instructions for SSL even mention SAN before all our certificates stopped working, I'm betting there are a lot of angry people out there.

Next time, please:
- Evaluate how many people are likely to be affected
- Make prominent public announcements, not on a developer mailing list
- Provide instructions for fixing the problem
- Deprecate, rather than proceeding straight to the "throw up an error page" approach

It should have been handled more like the SHA1 or TLS 1.0 deprecation transitions.


mathew
--
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
2017-04-26 14:50:45 UTC
Permalink
Post by m***@gmail.com
It turns out that CentOS 6 and CentOS 7 ship with OpenSSL configured to
generate certificates with only CN, no SAN.
OpenSSL is not a tool to be used to generate certificates that are expected
to 'just work'. For example, an out of the box OpenSSL on these platforms
also uses an invalid string encoding. It is meant to provide a tool and
framework for folks to configure appropriately.
Post by m***@gmail.com
Mozilla's reference guide to server side TLS configuration talks a lot
https://wiki.mozilla.org/Security/Server_Side_TLS
That's because it's not something server operators need to be aware of,
because it's been required of CAs since 2012.
Post by m***@gmail.com
https://www.google.com/search?sitesearch=www.openssl.org&q=subjectAltName
The difficulty of documentation in OpenSSL is unsurprising, especially as
they've significantly reorgnized the site and removed a lot of their
excellent documentation.

For what it's worth, the page is
https://www.openssl.org/docs/manmaster/man5/x509v3_config.html , which is
the official manual page for generating X.509 certificates.
Post by m***@gmail.com
Microsoft presents it as an extension which can *damage* security and
https://technet.microsoft.com/en-us/library/ff625722%28v=ws.
10%29.aspx?f=255&MSPPError=-2147217396
To be clear, Microsoft's aptly stating that, on older versions of Windows,
it's a security risk to allow clients to automatically enroll (thereby
control) the values for the subjectAlternativeName, because the autoenroll
system does not validate these names are accurate (unlike what they do for
directory names). Subsequent versions of Windows do allow auto-enrollment
of SANs, provided they match the FQDN of the enrolling machine. For
non-machine enrollment (e.g. end-user), it's also correct that having them
generate arbitrary SANs is dangerous - much like allowing the attacker to
say "I am google.com". For those cases, they rightfully recommend that you
require manual review.

I'm afraid you've misread this documentation, but I can understand that if
you're looking to support the view the SAN isn't required, this would seem
appealing.
Post by m***@gmail.com
Given the above and the fact that I'd never seen a single set of
instructions for SSL even mention SAN before all our certificates stopped
working, I'm betting there are a lot of angry people out there.
- Evaluate how many people are likely to be affected
We did. As you can see on the original announcement, the number of
validations affected represent an incredibly small fraction of both users
and site operators. It also is exclusively limited to those managing their
own PKIs that have not followed the industry standards - as noted, it's
been deprecated since HTTPS itself was introduced.
Post by m***@gmail.com
- Make prominent public announcements, not on a developer mailing list
This was tracked on chromestatus.com. It also went out with our Enterprise
release notes regularly in advance. There's also the opportunity to run Dev
and Beta versions within your organization, to help surface any concerns
you might have well before it's launched.
Post by m***@gmail.com
- Provide instructions for fixing the problem
As noted, EnableCommonNameFallbackForLocalAnchors is an enterprise policy
to work around this. However, in doing so, you introduce security risks to
your organization, and should do so sparingly.
Post by m***@gmail.com
- Deprecate, rather than proceeding straight to the "throw up an error page" approach
What do you believe this means? Particularly, what do you believe this
should mean for situations where there is an active security bug?
Post by m***@gmail.com
It should have been handled more like the SHA1 or TLS 1.0 deprecation transitions.
Thank you for your feedback. Certainly, I wish we would have phased these
out much sooner - as noted on the bug, it was something I've been tracking
since 2013 to measure the impact of such a phase out, to make sure we had
accurate numbers.

As always, you can help make sure your concerns are surfaced by running
earlier versions (Dev, Beta, or Canary), and as an enterprise, opting in to
anonymous usage stats to help ensure the impact to your organization is
measured. While we always strive to provide ample notice to the ecosystem,
it's also worth noting we're not the only one to have deprecated this, and
that there are indeed active security issues that arise from continuing to
support this. In balacing the risk versus compatibility, the risk (to all
Internet users) was much, much greater than the compatibility impact to the
limited number of Enterprises, for whom mitigation options were and are
provided, and for which communications went out. For enterprise-focused
customers, https://enterprise.google.com/chrome/chrome-browser/ can be a
one-stop portal for signing up to updates and even support agreements to
help measure, evangelize, and minimize any impact to Enterprise-specific
use cases.
--
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.
Eran Messeri
2017-04-26 14:16:02 UTC
Permalink
Post by s***@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.
It was declared deprecated 17 years ago:
https://tools.ietf.org/html/rfc2818#section-3.1
Post by s***@gmail.com
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...
--
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
2017-04-26 14:59:39 UTC
Permalink
Post by s***@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
If you're having issues, it's not related to Chrome policies.
https://dev.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters-
documents our policies here that apply to both HSTS and HPKP, but errors
are not fatal if you're using a properly configured scanning software
legitimately installed on a device operated and owned by the Enterprise
organization. As long as its your device, and is properly observing the
protocol specifications, we aim to minimize impact.
Post by s***@gmail.com
or this unnecessary change to ignore the CN field in favor of SAN even if
CN never was declared dead AFAIK.
It was declared dead in RFC 2818. Support for commonName allows for
bypassing restrictions on certificates in such a way that it's possible to
issue a legitimate certificate for any valid domain undetectably, and
without consequence, because it's fully conforming to all the valid
specifications.

As I'm sure you can understand, allowing arbitrary parties to Internet-wide
intercept communication is something we treat as a Very Serious security
issue.
Post by s***@gmail.com
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.
Thank you for your feedback. Have you had the opportunity to review the
peer-reviewed scientific research that explains these changes, and the
process and methodology for making them? It might help explain how this is,
from a quantifiable measured perspective, an improvement overall, even if
individual opinions may vary.

You can find just a sampling of these efforts at:
https://research.google.com/pubs/pub41323.html
https://research.google.com/pubs/pub41927.html
https://research.google.com/pubs/pub43265.html
https://research.google.com/pubs/pub45374.html
https://research.google.com/pubs/pub45366.html


I've refrained from addressing most of your other points, as I think you
acknowledge many of them are opinions, and as such, we can reasonably
disagree. We see a variety of threats against users, both from inside the
organization and from outside, and do our best to provide a browser that
can provide security for all users. While understandably, this may
occasionally conflict with an individual organizations good, it's a
collective health problem in which sometimes the needs to provide a
consistent, baseline assurance of security outweighs those of individual
organizations who may have the necessary technical skill and sufficiency to
operate things in a way that's reasonable for their threat model. That
said, I think most of those actively practicing in the field would know the
limits of our knowledge and ability, and suggest that this is not
realistically possible, but that's simply the result of knowing our
limitations, the threats, and the perfect skills required to even get
remotely close to that level.
--
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
2017-04-26 16:30:39 UTC
Permalink
It also went out with our Enterprise release notes regularly in advance.
Where can I find those "Enterprise release notes"?
I searched for chrome release notes "commonName"
<https://www.google.co.il/search?q=chrome+release+notes+"commonName"> and
nothing came up.


☆*PhistucK*
Post by s***@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
If you're having issues, it's not related to Chrome policies.
https://dev.chromium.org/Home/chromium-security/
security-faq#TOC-How-does-key-pinning-interact-with-local-
proxies-and-filters- documents our policies here that apply to both HSTS
and HPKP, but errors are not fatal if you're using a properly configured
scanning software legitimately installed on a device operated and owned by
the Enterprise organization. As long as its your device, and is properly
observing the protocol specifications, we aim to minimize impact.
Post by s***@gmail.com
or this unnecessary change to ignore the CN field in favor of SAN even if
CN never was declared dead AFAIK.
It was declared dead in RFC 2818. Support for commonName allows for
bypassing restrictions on certificates in such a way that it's possible to
issue a legitimate certificate for any valid domain undetectably, and
without consequence, because it's fully conforming to all the valid
specifications.
As I'm sure you can understand, allowing arbitrary parties to
Internet-wide intercept communication is something we treat as a Very
Serious security issue.
Post by s***@gmail.com
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.
Thank you for your feedback. Have you had the opportunity to review the
peer-reviewed scientific research that explains these changes, and the
process and methodology for making them? It might help explain how this is,
from a quantifiable measured perspective, an improvement overall, even if
individual opinions may vary.
https://research.google.com/pubs/pub41323.html
https://research.google.com/pubs/pub41927.html
https://research.google.com/pubs/pub43265.html
https://research.google.com/pubs/pub45374.html
https://research.google.com/pubs/pub45366.html
I've refrained from addressing most of your other points, as I think you
acknowledge many of them are opinions, and as such, we can reasonably
disagree. We see a variety of threats against users, both from inside the
organization and from outside, and do our best to provide a browser that
can provide security for all users. While understandably, this may
occasionally conflict with an individual organizations good, it's a
collective health problem in which sometimes the needs to provide a
consistent, baseline assurance of security outweighs those of individual
organizations who may have the necessary technical skill and sufficiency to
operate things in a way that's reasonable for their threat model. That
said, I think most of those actively practicing in the field would know the
limits of our knowledge and ability, and suggest that this is not
realistically possible, but that's simply the result of knowing our
limitations, the threats, and the perfect skills required to even get
remotely close to that level.
--
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
--
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
2017-04-26 16:39:26 UTC
Permalink
Sign up at the site I mentioned.
--
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
2017-04-26 16:42:53 UTC
Permalink
And it was also captured in
https://developers.google.com/web/updates/2017/03/chrome-58-deprecations
but it looks like there's a JS error on the page at the moment. I let folks
know.
Post by Ryan Sleevi
Sign up at the site I mentioned.
--
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
2017-04-26 16:43:33 UTC
Permalink
:( Why is there no page, blog or similar for that as well? In order to keep
track of the readers and be able to contact them in critical change cases?


☆*PhistucK*
Post by Ryan Sleevi
Sign up at the site I mentioned.
--
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
2017-04-26 16:45:32 UTC
Permalink
There is
https://developers.google.com/web/updates/2017/03/chrome-58-deprecations .
The Enterprise notes focus on drawing specific attention to
Enterprise-oriented concerns, which I'm sure you can understand aren't
useful in a broadly reaching communication. But there was the
broad-reaching comms at the Developer site. It just didn't show in the Beta
notes.
Post by PhistucK
:( Why is there no page, blog or similar for that as well? In order to
keep track of the readers and be able to contact them in critical change
cases?
☆*PhistucK*
Post by Ryan Sleevi
Sign up at the site I mentioned.
--
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
2017-04-26 17:00:16 UTC
Permalink
I do not mind about it not being broad reaching, but a place that keeps all
of the release notes of the past releases makes perfect sense to me. For
example, say I signed up after the Chrome 58 Enterprise release notes came
out (but before it was released to stable), I am going to miss them forever
and will be surprised by the breaking changes.
This is actionable. I can delay the installation of Chrome 58 for a short
while until I get the breaking changes sorted in the intranet.

It is 2017, not 1997. Archives are very common nowadays.


☆*PhistucK*
There is https://developers.google.com/web/updates/2017/03/chrome-
58-deprecations . The Enterprise notes focus on drawing specific
attention to Enterprise-oriented concerns, which I'm sure you can
understand aren't useful in a broadly reaching communication. But there was
the broad-reaching comms at the Developer site. It just didn't show in the
Beta notes.
Post by PhistucK
:( Why is there no page, blog or similar for that as well? In order to
keep track of the readers and be able to contact them in critical change
cases?
☆*PhistucK*
Post by Ryan Sleevi
Sign up at the site I mentioned.
--
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.
'Eric Lawrence' via blink-dev
2017-04-26 17:43:55 UTC
Permalink
Post by PhistucK
Archives are very common nowadays.
Am I missing something?

https://developers.google.com/web/updates/2017/03/chrome-58-deprecations
https://developers.google.com/web/updates/2017/02/chrome-57-deprecations
https://developers.google.com/web/updates/2016/#api_deprecations_and_removals_in_chrome_56
https://developers.google.com/web/updates/2016/#api_deprecations_and_removals_in_chrome_55
https://developers.google.com/web/updates/2016/#api_deprecations_and_removals_in_chrome_54
https://developers.google.com/web/updates/2016/#api_deprecations_and_removals_in_chrome_53
https://developers.google.com/web/updates/2016/#api_deprecations_and_removals_in_chrome_52
...

-Eric
Post by PhistucK
I do not mind about it not being broad reaching, but a place that keeps
all of the release notes of the past releases makes perfect sense to me.
For example, say I signed up after the Chrome 58 Enterprise release notes
came out (but before it was released to stable), I am going to miss them
forever and will be surprised by the breaking changes.
This is actionable. I can delay the installation of Chrome 58 for a short
while until I get the breaking changes sorted in the intranet.
It is 2017, not 1997. Archives are very common nowadays.
☆*PhistucK*
There is https://developers.google.com/web/updates/2017/03/chrome-
58-deprecations . The Enterprise notes focus on drawing specific
attention to Enterprise-oriented concerns, which I'm sure you can
understand aren't useful in a broadly reaching communication. But there was
the broad-reaching comms at the Developer site. It just didn't show in the
Beta notes.
Post by PhistucK
:( Why is there no page, blog or similar for that as well? In order to
keep track of the readers and be able to contact them in critical change
cases?
☆*PhistucK*
Post by Ryan Sleevi
Sign up at the site I mentioned.
--
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
2017-04-26 17:45:25 UTC
Permalink
Yes, I mean the Chrome for Enterprise release notes, not the broad-reaching
developer-oriented ones.


☆*PhistucK*
Post by 'Eric Lawrence' via blink-dev
Post by PhistucK
Archives are very common nowadays.
Am I missing something?
https://developers.google.com/web/updates/2017/03/chrome-58-deprecations
https://developers.google.com/web/updates/2017/02/chrome-57-deprecations
https://developers.google.com/web/updates/2016/#api_
deprecations_and_removals_in_chrome_56
https://developers.google.com/web/updates/2016/#api_
deprecations_and_removals_in_chrome_55
https://developers.google.com/web/updates/2016/#api_
deprecations_and_removals_in_chrome_54
https://developers.google.com/web/updates/2016/#api_
deprecations_and_removals_in_chrome_53
https://developers.google.com/web/updates/2016/#api_
deprecations_and_removals_in_chrome_52
...
-Eric
Post by PhistucK
I do not mind about it not being broad reaching, but a place that keeps
all of the release notes of the past releases makes perfect sense to me.
For example, say I signed up after the Chrome 58 Enterprise release notes
came out (but before it was released to stable), I am going to miss them
forever and will be surprised by the breaking changes.
This is actionable. I can delay the installation of Chrome 58 for a short
while until I get the breaking changes sorted in the intranet.
It is 2017, not 1997. Archives are very common nowadays.
☆*PhistucK*
There is https://developers.google.com/web/updates/2017/03/chrome-
58-deprecations . The Enterprise notes focus on drawing specific
attention to Enterprise-oriented concerns, which I'm sure you can
understand aren't useful in a broadly reaching communication. But there was
the broad-reaching comms at the Developer site. It just didn't show in the
Beta notes.
Post by PhistucK
:( Why is there no page, blog or similar for that as well? In order to
keep track of the readers and be able to contact them in critical change
cases?
☆*PhistucK*
Post by Ryan Sleevi
Sign up at the site I mentioned.
--
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.
f***@gmail.com
2017-04-26 17:54:41 UTC
Permalink
So are you going to patch OpenSSL to make it easier to generate CSRs with SANs then because this is insane and requres zsh? Ask any random sysadmin how to generate SAN CSRs and they'll be googling for an hour.

openssl req -new -newkey rsa:4096 -nodes -sha256 -out ${domain}.csr -keyout ${domain}.key -subj "/C=US/ST=MyState/L=MyCity/O=${company}/CN=${domain}/emailAddress=***@example.com" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:${domain},DNS:www.${domain}"))
--
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
2017-04-26 17:57:17 UTC
Permalink
Post by f***@gmail.com
So are you going to patch OpenSSL to make it easier to generate CSRs with
SANs then because this is insane and requres zsh? Ask any random sysadmin
how to generate SAN CSRs and they'll be googling for an hour.
openssl req -new -newkey rsa:4096 -nodes -sha256 -out ${domain}.csr
-keyout ${domain}.key -subj "/C=US/ST=MyState/L=MyCity/O=$
-config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:${
domain},DNS:www.${domain}"))
Hopefully it won't be an hour.

http://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl/27931596#27931596
is one of the top results (linked to the #1 result, but I'm sure linking
here will help).
--
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.
f***@gmail.com
2017-04-26 18:04:35 UTC
Permalink
Post by f***@gmail.com
So are you going to patch OpenSSL to make it easier to generate CSRs with SANs then because this is insane and requres zsh? Ask any random sysadmin how to generate SAN CSRs and they'll be googling for an hour.
nfig <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:${domain},DNS:www.${domain}"))
Post by f***@gmail.com
Hopefully it won't be an hour.
http://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl/27931596#27931596 is one of the top results (linked to the #1 result, but I'm sure linking here will help). 
That solution requires editing a config file for each CSR you do. That's absolutely unacceptable.
--
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.
Alex Gaynor
2017-04-26 18:07:56 UTC
Permalink
If you're in a position where you need to create a large number of CSRs,
you may want to automate it with something that gives you slightly more
control and a more expressive API, to toot my own horn:
https://cryptography.io/en/latest/x509/tutorial/

Alex
Post by f***@gmail.com
Post by f***@gmail.com
So are you going to patch OpenSSL to make it easier to generate CSRs
with SANs then because this is insane and requres zsh? Ask any random
sysadmin how to generate SAN CSRs and they'll be googling for an hour.
Post by f***@gmail.com
openssl req -new -newkey rsa:4096 -nodes -sha256 -out ${domain}.csr
-keyout ${domain}.key -subj "/C=US/ST=MyState/L=MyCity/O=$
nfig <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:${
domain},DNS:www.${domain}"))
Post by f***@gmail.com
Hopefully it won't be an hour.
http://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-
certificate-with-openssl/27931596#27931596 is one of the top results
(linked to the #1 result, but I'm sure linking here will help).
That solution requires editing a config file for each CSR you do. That's
absolutely unacceptable.
--
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
--
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6
--
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
2017-04-26 18:29:31 UTC
Permalink
For sure. OpenSSL's config file syntax also fully supports automation of
this (whether through the 'req', 'x509', or 'ca' commands). I would hope
this discussion doesn't involve too much OpenSSL support, other than
highlighting that the OpenSSL manpages have covered ways to simplify this
for over a decade. I can understand that when something 'just works',
reading the manual isn't often a priority, but inevitably, software marches
on as the ecosystem responds to security threats. Luckily, OpenSSL had the
foresight even back then to include all the tools necessary.

A brief amount of help - although probably the last I can give to
OpenSSL-specific help - the .cnf file supports the syntax
${ENV::variable_name} as a way of doing substitutions. The Chrome Team's
build tools use this, for example, to generate a variety of test
certificates.

[exts]
subjectAltName=@SAN

[SAN]
DNS.1=${ENV::domain}
DNS.2=www.${ENV::domain}

Would allow you to use your existing ${domain} environment variable.

You can see this example in a file like
https://chromium.googlesource.com/chromium/src/+/52939ed422f481e2970edfa57a8bf24ca3dbacb8/net/data/ssl/scripts/ca.cnf

Note that, for using OpenSSL as a CA, it's generally poor form to rely on
/etc/ssl/openssl.cnf. You should think of that as an example 'skeleton'
file, and configure appropriate for each individual CA you're running using
OpenSSL.

I realize that OpenSSL may not be the best documented example, but this
hopefully helps you find better tools to support your needs, gives you a
path to read more about the support your chosen tool already has, and gives
you alternatives if you wish to simplify your management. "Running" a CA is
hard stuff, and running with OpenSSL is likely going to be a continued
source of pain "out of the box". Best of luck!
Post by Alex Gaynor
If you're in a position where you need to create a large number of CSRs,
you may want to automate it with something that gives you slightly more
https://cryptography.io/en/latest/x509/tutorial/
Alex
Post by f***@gmail.com
Post by f***@gmail.com
So are you going to patch OpenSSL to make it easier to generate CSRs
with SANs then because this is insane and requres zsh? Ask any random
sysadmin how to generate SAN CSRs and they'll be googling for an hour.
Post by f***@gmail.com
openssl req -new -newkey rsa:4096 -nodes -sha256 -out ${domain}.csr
-keyout ${domain}.key -subj "/C=US/ST=MyState/L=MyCity/O=$
nfig <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:${d
omain},DNS:www.${domain}"))
Post by f***@gmail.com
Hopefully it won't be an hour.
http://stackoverflow.com/questions/10175812/how-to-create-a-
self-signed-certificate-with-openssl/27931596#27931596 is one of the top
results (linked to the #1 result, but I'm sure linking here will help).
That solution requires editing a config file for each CSR you do. That's
absolutely unacceptable.
--
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
--
"I disapprove of what you say, but I will defend to the death your right
to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6
--
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.
f***@gmail.com
2017-04-27 14:16:32 UTC
Permalink
I have recently been informed this breaks Common Criteria FIA_X509 SFRs which requires that CN matching works on certificates without SAN. This would make Chrome no longer compliant for the federal government. More investigation will be needed as I am still looking for the specific language that defines this requirement.
--
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.
Hanno Böck
2017-04-27 14:29:56 UTC
Permalink
Hi,

On Thu, 27 Apr 2017 07:16:32 -0700 (PDT)
Post by f***@gmail.com
I have recently been informed this breaks Common Criteria FIA_X509
SFRs which requires that CN matching works on certificates without
SAN. This would make Chrome no longer compliant for the federal
government. More investigation will be needed as I am still looking
for the specific language that defines this requirement.
I tried to googl for those criteria, but didn't find them, can you
point to a source? Or are they nonpublic?

Is there any justification for that requirement? Or is it more an
example of gov certifications doing pointless things without a reason?
--
Hanno Böck
https://hboeck.de/

mail/jabber: ***@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
--
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.
Mark Felder
2017-04-27 14:35:53 UTC
Permalink
I was informed by an acquaintance who works with this compliance. I
think the details are somewhere on this site, but there are a lot of
PDFs to hunt through.

http://www.commoncriteriaportal.org/cc/
Post by Hanno Böck
Hi,
On Thu, 27 Apr 2017 07:16:32 -0700 (PDT)
Post by f***@gmail.com
I have recently been informed this breaks Common Criteria FIA_X509
SFRs which requires that CN matching works on certificates without
SAN. This would make Chrome no longer compliant for the federal
government. More investigation will be needed as I am still looking
for the specific language that defines this requirement.
I tried to googl for those criteria, but didn't find them, can you
point to a source? Or are they nonpublic?
Is there any justification for that requirement? Or is it more an
example of gov certifications doing pointless things without a reason?
--
Hanno Böck
https://hboeck.de/
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
--
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
2017-04-27 14:37:13 UTC
Permalink
Post by Hanno Böck
Hi,
On Thu, 27 Apr 2017 07:16:32 -0700 (PDT)
Post by f***@gmail.com
I have recently been informed this breaks Common Criteria FIA_X509
SFRs which requires that CN matching works on certificates without
SAN. This would make Chrome no longer compliant for the federal
government. More investigation will be needed as I am still looking
for the specific language that defines this requirement.
I tried to googl for those criteria, but didn't find them, can you
point to a source? Or are they nonpublic?
Is there any justification for that requirement? Or is it more an
example of gov certifications doing pointless things without a reason?
The current criteria is https://www.niap-ccevs.org/pp/pp_md_v2.0.pdf
FCS_TLSC_EXT.2.2

This does not conflict with this change, but in fact supports it:

FCS_TLSC_EXT.2.2

The TSF shall verify that the presented identifier matches the
reference identifier according to RFC 6125.
Application Note: The rules for verification of identify are described in
Section 6 of RFC
6125. The reference identifier is established by the user (e.g. entering a
URL into a web
browser or clicking a link), by configuration (e.g. configuring the name of
a mail server or
authentication server), or by an application (e.g. a parameter of an API)
depending on the
application service. Based on a singular reference identifier’s source
domain and application
service type (e.g. HTTP, SIP, LDAP), the client establishes all reference
identifiers which are
acceptable, such as a Common Name for the Subject Name field of the
certificate and a
(case-insensitive) DNS name, URI name, and Service Name for the Subject
Alternative
Name field. The client then compares this list of all acceptable reference
identifiers to the
presented identifiers in the TLS server’s certificate.
The preferred method for verification is the Subject Alternative Name using
DNS names,
URI names, or Service Names. Verification using the Common Name is required
for the
purposes of backwards compatibility. Additionally, support for use of IP
addresses in the
Subject Name or Subject Alternative name is discouraged as against best
practices but may
be implemented. Finally, the client should avoid constructing reference
identifiers using
wildcards. However, if the presented identifiers include wildcards, the
client must follow the
best practices regarding matching; these best practices are captured in the
assurance activity.
--
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.
Mark Felder
2017-04-27 14:49:52 UTC
Permalink
Ok, so this policy demands that verification has to happen, period. It
would not be in compliance to use software that doesn't actually
verify the name on the certificate matches. This is good.
Verification using the Common Name is required for the purposes of backwards compatibility.
I interpret this as requiring that Common Name has to work, but they
prefer SAN. Chrome isn't removing the ability to match names via
CommonName which would create a vulnerability, but are denying
validation of certificates that use CommonName (unless extra setting
for local trust anchors). Is this still within compliance if they are
explicitly requiring the backwards compatibility? I wonder what an
auditor would say because I can see it both ways.
Post by Hanno Böck
Hi,
On Thu, 27 Apr 2017 07:16:32 -0700 (PDT)
Post by f***@gmail.com
I have recently been informed this breaks Common Criteria FIA_X509
SFRs which requires that CN matching works on certificates without
SAN. This would make Chrome no longer compliant for the federal
government. More investigation will be needed as I am still looking
for the specific language that defines this requirement.
I tried to googl for those criteria, but didn't find them, can you
point to a source? Or are they nonpublic?
Is there any justification for that requirement? Or is it more an
example of gov certifications doing pointless things without a reason?
The current criteria is https://www.niap-ccevs.org/pp/pp_md_v2.0.pdf
FCS_TLSC_EXT.2.2
FCS_TLSC_EXT.2.2
The TSF shall verify that the presented identifier matches the
reference identifier according to RFC 6125.
Application Note: The rules for verification of identify are described in
Section 6 of RFC
6125. The reference identifier is established by the user (e.g. entering a
URL into a web
browser or clicking a link), by configuration (e.g. configuring the name of
a mail server or
authentication server), or by an application (e.g. a parameter of an API)
depending on the
application service. Based on a singular reference identifier’s source
domain and application
service type (e.g. HTTP, SIP, LDAP), the client establishes all reference
identifiers which are
acceptable, such as a Common Name for the Subject Name field of the
certificate and a
(case-insensitive) DNS name, URI name, and Service Name for the Subject
Alternative
Name field. The client then compares this list of all acceptable reference
identifiers to the
presented identifiers in the TLS server’s certificate.
The preferred method for verification is the Subject Alternative Name using
DNS names,
URI names, or Service Names. Verification using the Common Name is required
for the
purposes of backwards compatibility. Additionally, support for use of IP
addresses in the
Subject Name or Subject Alternative name is discouraged as against best
practices but may
be implemented. Finally, the client should avoid constructing reference
identifiers using
wildcards. However, if the presented identifiers include wildcards, the
client must follow the
best practices regarding matching; these best practices are captured in the
assurance activity.
--
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
2017-04-27 14:55:05 UTC
Permalink
Post by Mark Felder
Ok, so this policy demands that verification has to happen, period. It
would not be in compliance to use software that doesn't actually
verify the name on the certificate matches. This is good.
Verification using the Common Name is required for the purposes of
backwards compatibility.
I interpret this as requiring that Common Name has to work, but they
prefer SAN. Chrome isn't removing the ability to match names via
CommonName which would create a vulnerability, but are denying
validation of certificates that use CommonName (unless extra setting
for local trust anchors). Is this still within compliance if they are
explicitly requiring the backwards compatibility? I wonder what an
auditor would say because I can see it both ways.
Chrome is not audited to that Common Criteria Profile. However, Chrome will
work with servers that need to support clients that are audited to that
profile.

To be clear, by supporting Common Name as specified by that profile, it
will allow bypassing the use of nameConstraints in a way that a
nameConstrained sub-CA will be able to have unconstrained issuance. This
is, among other reasons, why Common Name has been deprecated since RFC 2818.

As the profiles are routinely updated to respond to emergent security
threats, I'm sure that clearer documentation of these risks, such as those
provided by https://nameconstraints.bettertls.com , can better inform.
--
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.
j***@gmail.com
2017-05-04 19:41:08 UTC
Permalink
Post by Mark Felder
Ok, so this policy demands that verification has to happen, period. It
would not be in compliance to use software that doesn't actually
verify the name on the certificate matches. This is good.
Verification using the Common Name is required for the purposes of backwards compatibility.
I interpret this as requiring that Common Name has to work, but they
prefer SAN. Chrome isn't removing the ability to match names via
CommonName which would create a vulnerability, but are denying
validation of certificates that use CommonName (unless extra setting
for local trust anchors). Is this still within compliance if they are
explicitly requiring the backwards compatibility? I wonder what an
auditor would say because I can see it both ways.
Chrome is not audited to that Common Criteria Profile. However, Chrome will work with servers that need to support clients that are audited to that profile.
To be clear, by supporting Common Name as specified by that profile, it will allow bypassing the use of nameConstraints in a way that a nameConstrained sub-CA will be able to have unconstrained issuance. This is, among other reasons, why Common Name has been deprecated since RFC 2818.
As the profiles are routinely updated to respond to emergent security threats, I'm sure that clearer documentation of these risks, such as those provided by https://nameconstraints.bettertls.com , can better inform.
Ryan, & Mark,

I believe you will find that any auditor will find that Chrome is no longer compliant for use in the Federal Government. Basically, the CCP says what RFC2818 says says but deprecates:
A cert if valid if it matches the cert name or a name in a SAN.
IF (and only if) the SAN is blank, then the cert CN MUST be checked for a match.

RFC2818 says that the IFF portion is deprecated, but it still MUST be done. CCP does not mention the deprecation at all. Thus, the fact that Chrome 58+ no longer considers a cert valid in the case that there is not a match in the name and the SAN is blank. It does NOT follow the "If SAN is blank, you MUST consider the CN". Thus, it is no longer CCP compliant.

Just a strict reading of RFC2818 and CCP. Not judging any of the security merits of doing / not doing CN checking.
--
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
2017-05-04 20:06:36 UTC
Permalink
Ryan already stated -
Post by Ryan Sleevi
Chrome is not audited to that Common Criteria Profile
So this is apparently not a goal of Chrome at the moment anyway. If it were
compliant in the past, it was apparently coincidental.


☆*PhistucK*
Post by Ryan Sleevi
Post by Mark Felder
Ok, so this policy demands that verification has to happen, period. It
would not be in compliance to use software that doesn't actually
verify the name on the certificate matches. This is good.
Verification using the Common Name is required for the purposes of
backwards compatibility.
Post by Mark Felder
I interpret this as requiring that Common Name has to work, but they
prefer SAN. Chrome isn't removing the ability to match names via
CommonName which would create a vulnerability, but are denying
validation of certificates that use CommonName (unless extra setting
for local trust anchors). Is this still within compliance if they are
explicitly requiring the backwards compatibility? I wonder what an
auditor would say because I can see it both ways.
Chrome is not audited to that Common Criteria Profile. However, Chrome
will work with servers that need to support clients that are audited to
that profile.
Post by Mark Felder
To be clear, by supporting Common Name as specified by that profile, it
will allow bypassing the use of nameConstraints in a way that a
nameConstrained sub-CA will be able to have unconstrained issuance. This
is, among other reasons, why Common Name has been deprecated since RFC 2818.
Post by Mark Felder
As the profiles are routinely updated to respond to emergent security
threats, I'm sure that clearer documentation of these risks, such as those
provided by https://nameconstraints.bettertls.com , can better inform.
Ryan, & Mark,
I believe you will find that any auditor will find that Chrome is no
longer compliant for use in the Federal Government. Basically, the CCP
A cert if valid if it matches the cert name or a name in a SAN.
IF (and only if) the SAN is blank, then the cert CN MUST be checked for a match.
RFC2818 says that the IFF portion is deprecated, but it still MUST be
done. CCP does not mention the deprecation at all. Thus, the fact that
Chrome 58+ no longer considers a cert valid in the case that there is not a
match in the name and the SAN is blank. It does NOT follow the "If SAN is
blank, you MUST consider the CN". Thus, it is no longer CCP compliant.
Just a strict reading of RFC2818 and CCP. Not judging any of the security
merits of doing / not doing CN checking.
--
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
--
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.
Loading...