Re: Deficiencies in the Web PKI and Mozilla's shepherding thereof, exposed by the WoSign affair

[Tom Ritter]

On 4 October 2016 at 06:12, Eric Rescorla  wrote:
> with the exception of the end-entity
> certificate which MUST be first.

After testing, this part seems to be the component that stops my idea.
I could build paths to arbitrary roots with extra chains contained in
the list... but only if the correct leaf was specified first. (Kind of
surprised by that, I'd have imagined that be a more common
misconfiguration, but I guess not.)

Tested with Chrome/Firefox/IE/Edge on Windows 10. (Seems Edge doesn't
honor the HSTS hard fail mechanism!)

-tom
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Deficiencies in the Web PKI and Mozilla's shepherding thereof, exposed by the WoSign affair

[Eric Rescorla]

On Mon, Oct 3, 2016 at 9:44 PM, Peter Bowen  wrote:

> On Mon, Oct 3, 2016 at 5:24 PM, Jakob Bohm  wrote:
> > On 03/10/2016 20:41, Kyle Hamilton wrote:
> >> WoSign is known to be cross-signed by several independent CAs (as well
> as
> >
> >> 2. There is only One Certificate Path that can be proven in TLS, which
> >> prevents risk management by end-entities.
> >>
> >
> > Are you sure, I thought the standard TLS protocol transmitted a *set*
> > of certificates in which the client could/should search for a chain
> > leading to a client trusted CA.  For example, this is how cross-
> > certificates are often used by servers: Send the cross certificate for
> > the benefit of those clients that don't trust the (newer) root that
> > leads to the server cert.
>
> Kyle is right.  In TLS, you can only send one chain.  The
> specification requires that the server send an ordered sequence of
> certificates.
>
> There is nothing in any TLS version that allows the server to send
> multiple independent certificate chains.  For example I can't send
> these two at the same time:
>
> (server) -> Let's Encrypt Authority X1 -> DST Root CA X3 -> DST RootCA X1
> (server) -> DigiCert Baltimore CA-1 G2 -> Baltimore CyberTrust Root ->
> GTE CyberTrust Global Root
>
> Even if there is only one private key for the server, you can't send
> multiple independent chains
>

TLS versions 1.2 and before explicitly required that you send an ordered
chain
but many servers in fact do not do so and browser clients generally will
compensate
for this. TLS 1.3 (grudgingly) acknowledges this fact and allows it, as
long as there
is only one EE cert:
https://tlswg.github.io/tls13-spec/#certificate

Note: Prior to TLS 1.3, “certificate_list” ordering required each
certificate to certify the one immediately preceding it, however some
implementations allowed some flexibility. Servers sometimes send both a
current and deprecated intermediate for transitional purposes, and others
are simply configured incorrectly, but these cases can nonetheless be
validated properly. For maximum compatibility, all implementations SHOULD
be prepared to handle potentially extraneous certificates and arbitrary
orderings from any TLS version, with the exception of the end-entity
certificate which MUST be first.
-Ekr
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Deficiencies in the Web PKI and Mozilla's shepherding thereof, exposed by the WoSign affair

[Gervase Markham]

Hi Kyle,

On 03/10/16 19:41, Kyle Hamilton wrote:
> WoSign is known to be cross-signed by several independent CAs (as well as 1
> CA which is no longer deemed to be independent).  If it wished to bypass
> any attempt to distrust it, all it would have to do is be cross-signed by
> another CA.  Because we don't have any idea how many cross-signing links
> actually exist to it, it's inappropriate to proceed on the hypothesis that
> all have been found and properly added to a CRL.

CT and crt.sh mean we have a fairly good idea of what cross-signed
exist. You say "all they have to do", but cross-signing another CA is a
rare process, involving both a significant amount of money and a lending
of reputation. If a CA were in the process of being partly or totally
dis-trusted by major root stores, it is unlikely that some other CA
would want to issue such a cross-signing certificate.

> Instead, public keys need to be able to be individually distrusted, no
> matter what identities they're certified with or who they're certified by.
> Once a CA's public key is distrusted, cross-certificates of that key would
> no longer be valid certification paths.

I can't speak for other vendors, but I believe that Mozilla's OneCRL
allows, among other things, distrusting a cert by public key.

> The primary reason why CAs have historically not been fully and
> unilaterally distrusted is because of the damage that would be done to the
> certified end-entities by distrusting the One Certificate Chain that can be
> provided via TLS.  We need a means to provide multiple certificate chains
> simultaneously, with 1/N of those chains needing to pass verification in
> order for the connection to be deemed authentic.

This might be a good enhancement to TLS - the ability to present
multiple certificates and chains. While you are there, please add the
ability to use multiple hash algorithms on a cert :-)

> This protocol would have permitted end entities to have multiple
> certificate chains from multiple providers, so that they wouldn't have had
> to go into crisis mode if one of their providers was distrusted.  

The question would be: how many sites would bother to set this up?
Because if it's your mechanism for mitigating TBTF, then you need it to
be adopted by most sites, otherwise the systemic issues you point out
remain the same.

I actually think that TBTF is not a problem in practice, and with CT
providing verifiable timestamps in certs, it is not going to be a
problem in either theory or practice very soon.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Deficiencies in the Web PKI and Mozilla's shepherding thereof, exposed by the WoSign affair

[Peter Bowen]

On Mon, Oct 3, 2016 at 5:24 PM, Jakob Bohm  wrote:
> On 03/10/2016 20:41, Kyle Hamilton wrote:
>> WoSign is known to be cross-signed by several independent CAs (as well as
>
>> 2. There is only One Certificate Path that can be proven in TLS, which
>> prevents risk management by end-entities.
>>
>
> Are you sure, I thought the standard TLS protocol transmitted a *set*
> of certificates in which the client could/should search for a chain
> leading to a client trusted CA.  For example, this is how cross-
> certificates are often used by servers: Send the cross certificate for
> the benefit of those clients that don't trust the (newer) root that
> leads to the server cert.

Kyle is right.  In TLS, you can only send one chain.  The
specification requires that the server send an ordered sequence of
certificates.

There is nothing in any TLS version that allows the server to send
multiple independent certificate chains.  For example I can't send
these two at the same time:

(server) -> Let's Encrypt Authority X1 -> DST Root CA X3 -> DST RootCA X1
(server) -> DigiCert Baltimore CA-1 G2 -> Baltimore CyberTrust Root ->
GTE CyberTrust Global Root

Even if there is only one private key for the server, you can't send
multiple independent chains

>> The primary reason why CAs have historically not been fully and
>> unilaterally distrusted is because of the damage that would be done to the
>> certified end-entities by distrusting the One Certificate Chain that can
>> be
>> provided via TLS.  We need a means to provide multiple certificate chains
>> simultaneously, with 1/N of those chains needing to pass verification in
>> order for the connection to be deemed authentic.
>
>
> The big limitation here is that most CAs have conditions of
> certification that end entities are not allowed to submit the same
> public key more than once, thus ensuring that each end entity public
> key would be in only one cert from one CA.

Sure. But you could do a threshold scheme where at least N chains have
to be valid. You could even combine this with key pinning to require
that at least N pins are met rather than the current scheme which is
at least 1 pin is valid.

>> This protocol would have permitted end entities to have multiple
>> certificate chains from multiple providers, so that they wouldn't have had
>> to go into crisis mode if one of their providers was distrusted.  It also
>> would have permitted in-protocol stapling of all necessary OCSP responses
>> for validation.  In other words, the One True Certificate issue (which has
>> been known for several years as being the main reason why issuers could
>> not
>> be simply distrusted) has been worked around and worked around and worked
>> around -- most recently with Certificate Transparency -- when the actual
>> reason for the problem was simply "end entities cannot do risk management
>> within the current protocols".

It would seem the obvious tradeoff here is size.  More chains means
larger handshakes.  It does have the advantage of allowing server
operators to "set it and forget it" and still work even if one CA is
distrusted.  It wouldn't even require a change to signatures, it could
just be an extra TLS message, something like "Alternative Server
Certificate".

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Deficiencies in the Web PKI and Mozilla's shepherding thereof, exposed by the WoSign affair

[Tom Ritter]

On 3 October 2016 at 19:24, Jakob Bohm  wrote:
> On 03/10/2016 20:41, Kyle Hamilton wrote:
>> 2. There is only One Certificate Path that can be proven in TLS, which
>> prevents risk management by end-entities.
>>
>
> Are you sure, I thought the standard TLS protocol transmitted a *set*
> of certificates in which the client could/should search for a chain
> leading to a client trusted CA.

I've seen interesting bugs result from client (e.g. browser)
processing of the 'bag of certs' approach - but these bugs are
security vulnerabilities and should be handled correctly. So I don't
see any reason why one could not send multiple chains right now, and
have a client correctly process it.  Shouldn't be too hard to actually
test with Firefox or whatever. Just get a couple chains from different
CAs and start distrusting roots locally...

I guess the main thing I'd wonder about is if a client has a root
marked as untrusted, it may build a chain to that root for the
purposes of *not* trusting it. (As opposed to building a chain to a
completely unknown root.)

Not that I think this is a good idea.

-tom
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy