508355 - Basic Constraints Tracking Bug

Status: RESOLVED INVALID

(NSS :: Libraries, defect)

Description

[chris hofmann]

The first section of Moxie's video at
https://media.blackhat.com/bh-usa-09/video/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-VIDEO.mov  talks about the need for cert chain limits, chain limit enforcement in the client and makes several hints that bugs might be still be lurking there.   This is to follow up on the claim "you'd be surprised at who still doesn't do basic constraint checking"  and to make sure we are doing all that we can both on the CA and client side to cut off chaining attacks.

questions listed here might be individual bugs to spin off.

some quick notes from an IRC conversation to get the discussion rolling.

dveditz> so I guess we could take two approaches (or both) -- a) arbitrarily impose a non-specified limit, b) force all new/renewed roots to include a chain limit contraint

dveditz> I'm not sure either is very useful in practice -- for moxie's attack you only need to add 1 to the chain length. If our limit is such that adding 1 breaks then probably we're breaking lots of existing certs

<chofmann>	sounds like b) force all new/renewed roots to include a chain limit contraint is what we need first.
	
<dveditz>	b) is obviously not a short-term fix.   

Are there other effective strategies that we could use against these chaining attacks?

-----------------------------


Some specific questions around constraint checking in Firefox and other clients:

<dveditz>	Nelson assures me that we do, but since _zero/so few_ roots use it it may not be well-tested

<dveditz>	It's possible CA's add the constraint only to signing-certs they issue to corporations (e.g. chain limit = 1 so that corp can issue internal certs but not set up their own CA)

Is this the case?  
Do we need CAs to start adding the chain limit as a defense for this problem?
What are some test cases that we could add to get better coverage?

security-sensitive for now until we get a better handle, and headstart, on what problems might be lurking if any.

are the CA reps we should add to the discussion?

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

This bug annoys me, because there is no bug in NSS.  This is invalid.
NSS has correctly honored basic constraints for over 12 years.  
Way back when it was shown that MS Windows/IE ignored them completely,
and that anyone with an EE (Non-CA) cert could nonetheless use it like a
CA cert and issue subordinate certs that would be honored by IE, the NSS 
team was shocked that anyone could get it so wrong.
We had gotten it right for years by then.

It is very rare for a root to constrain itself with a path length.
The typical use of path length constraints is to constrain corporate CAs
that are subordinate to commercial CAs, as Dan suggests in the previous
comment.  

Most CAs put as few constraints as they they can into CA certs. 
This is done to avoid reissuance in the event that some unforseen use 
arises later.  If you want to try to get CAs to start constraining 
subordinate CA certs, you should start to champion that as a best practice 
in the CAB Forum.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

IMO, a much bigger issue is lack of NAME constraints in CA certs.  

CA certs can be constrained regarding the domain names they can place into certs they issue.  If this worked, it would be very useful to prevent 
corproate CAs from issuing certs for domains they do not control. But today, this does not work because CAs and browsers continue to allow DNS names to be used in non-standard places in certificates, places to which Name constraints 
do not apply.

Name constraints only apply to DNS names in the standard place in certs, NOT to DNS names in Subject Common Names.  

The practice of putting DNS names in Subject Name CNs has never been a standard.
Certs have a standard place for DNS names, called the Subject Alternative Names (SAN) extension.  NSS, Windows and Opera have honored DNS names in SAN extension for years now.  But today, most CAs still put DNS names in Subject Name CommonName attributes, and all browsers still honor them. 

If you want name constraints to start to work as they were intended, you have
to agree to stop honoring DNS names in Subject Common Names.  You probably 
must also get the other browsers to agree, too.  As long as DNS names 
in Subject Common Names are honored, Name Constraints will remain useless.

Comment 3

[chris hofmann]

Nelson,

Thanks for your comments and to help map out a plan for what areas need work.  

I struggled for a long time trying to figure out a good product and component for this bug, but we don't have anything that covers the broad set of interfaces that come into play for implementation of PKI across browsers, the CAs, and deployment.   That's really moxie's attack vector in this area.  As dan points out "...It's possible CA's add the constraint only to signing-certs they issue to corporations (e.g. chain limit = 1 so that corp can issue internal
certs but not set up their own CA)"  --  basically moxie seems to be exploiting this fact, and the result is *any* user can set up their own CA using his technique.

johnath, Nelson's suggestion of adding this to the agenda of CAB forum sounds like a good one.

Adding a few representatives from CAs that I saw commenting in https://bugzilla.mozilla.org/show_bug.cgi?id=477244 to get there perspective on how we can make ground on this issue.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

> the result is *any* user can set up their own CA using his technique.

I don't think that's true, Chris, for a whole variety of reasons.  
But just in case I'm reading something different than you are, please 
point me to exactly what you've read that leads you to that conclusion.

Comment 5

[chris hofmann]

Slides 10-12 and/or the in the video at http://blackhat.com/html/bh-usa-09/bh-usa-09-archives.html#Marlinspike are where the claims are made.

http://www.thoughtcrime.org/software/sslsniff/ has also been updated in the last couple of days.

These are the claims to be investigated; then discounted if not true, or studied and fixed if they are exploitable or could be...

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

The video component of the 2GB .mov file cited in comment 0 is just Moxie's 
black hat slides, which are available in a MUCH smaller (1.7 MB) format as
http://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf

In Moxie's presentation, he reviewed his long history of finding problems
with PKI.  He cited some problems that existed VERY long ago.  In his first
~20 slides, he talks about an old vulnerability in IE that allowed any user
with a legitimate non-CA cert (a so-called "End Entity" or "EE" cert) to 
use it as a CA cert and issue subordinate certs that IE would honor.  That 
has NEVER been a problem in ANY version of NSS or any product that uses NSS 
for cert validation.  IMO, Mozilla should not be trying to devise measures 
to protect against attacks to which it is not and never has been vulnerable. 

So, let's look at other ways that a user might get a CA cert, ways that 
do not depend on browsers ignoring basic constraints extensions, and see
if basic constraint path lengths are an effective counter measure to them.

1. Getting a CA to issue a non-CA cert whose signature is identical to the
signature on a CA cert that the attacker has devised.  This is the attack
that Kaminsky's team revealed in December in Berlin, and it depends on 
the browser honoring signatures made with weak hash algorithms such as MD2, 
which has been disabled in FF 3.5, and MD5, which NSS is prepared to disable
(simple API call) but which Firefox has not (yet) chosen to disable.  

2. Tricking a CA that is intended to ony issue non-CA ("EE") certs into issuing a CA cert.  I have not read any disclosure of techniques that trick a CA into issuing a CA cert.  If such a technique existed, it would mean 
that the CA was issuing certs where it was not in control of the contents 
of the basicConstraints extensions in the certs it issues, so solutions 
that involve controlling the content of the basicConstraints extension in 
the bogus issued cert won't work.  

3. Collusion, getting a CA to cooperatively issue a subordinate CA cert 
that it ought not to issue.  

In both cases 2 and 3, the only way that a path length constraint would help would be if it was imposed on and present in the cert for the CA 
that was tricked into issuing (or colluded to issue) the bogus CA cert.  

In summary: imposing path length constraints on low-level CAs, to keep 
them honest and to prevent them from issuing subordinate CA certs that 
they ought not to issue, is a good idea that CAs can do themselves today.

Imposing path length constraints on higher level CAs is less effective 
because of legitimately varying path lengths (depth of subordinate CAs) 
that may exist in subordinates of the same high level CA.

Comment 7

[chris hofmann]

just a note:  the .mov file also contains audio from the talk where a few extra commments are noted during the presentation in addition the the content of the slides.

I wonder if there is any way to get information on how many low level CAs are using path length constraints, and how many/who might be not be using them.  That might allow us to get a better handle on how big the problem might be, and/or how hard it might be to solve.

If I understand the issues correctly I guess *size* of the problem (in terms of number of CAs or number of certs issued) doesn't matter.  If only one low level CA provides certs without the path length constraints to the to a single person that develops exploits using this technique then users can still be at risk. Is that right?

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

If Mozilla was vulnerable to this, then I agree, the number of CAs is not significant.  But since NSS always pays attention to BasicConstraints ...

Comment 9

[Rob Stradling]

In reply to comment #6:
> 2. Tricking a CA that is intended to ony issue non-CA ("EE") certs into
> issuing a CA cert.  I have not read any disclosure of techniques that trick a
> CA into issuing a CA cert.  If such a technique existed, it would mean
> that the CA was issuing certs where it was not in control of the contents
> of the basicConstraints extensions in the certs it issues...

I would consider any CA who does not retain full "control of the contents of the basicConstraints extensions in the certs it issues" to be incompetent.  I sincerely hope that no CAs fall into this category.

> In summary: imposing path length constraints on low-level CAs, to keep them
> honest and to prevent them from issuing subordinate CA certs that they ought
> not to issue, is a good idea that CAs can do themselves today.

I fully agree.  Comodo have always imposed path length constraints on "low-level" CAs.  If other CAs have not been doing this, I would very much like to know why.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

If this was a valid bug, it would be a bug in NSS libraries. 
But IMO, it's not.

Comment 11

[chris hofmann]

in reflection this bug was 

1) about making sure we are doing all that we can do in the client to protect against chain limit attacks, and that we are confident in the current state of that code.  (nelson has made an excellent case for resolving this part)

*and*

2) protecting against a rouge and/or incompetent CA entering the system, then unknowingly or knowingly participating as a vector in an attack, and bring down the entire trust system shared by the Browser, CAs, Websites, and Users.

Its still not clear to me that we have auditing and assurance systems in place for the later, or at least would attempt to identify or solve possible problems in the system,  but maybe this bug is not the place to try and figure that out. 

Rob's comment 9 helps build some confidence in what Comodo is doing as a CA provider, but leaves questions open about what other CAs that are included in Firefox might be doing.  Those seem like questions worth exploring with CAs even at a general level.  Nothing in our guidelines indicates the need for continued auditing and assessment once the cert is included.

Its a difficult problem and its hard to figure out who might take the lead on solutions.  From the list above users seem unlikely to understand the problem or take the lead.  Websites too; big e-commerce are at risk in this but little leverage to make something happen.  CAs might be able to collectively solve the problem through setting up disclosure and auditing mechanism that would allow the kind of detection and removal of problems from the system that might be possible.  But it seems like that might be unlikely to happen on its own.  That leaves browsers.  What should we do to try and influence this area?  What can we do protect against the introduction of rouge/incompetent CAs?

Nelson's right.  This bug is probably not Component|CA Certificates.  Its probably not NSS Libraries now either.  I'm not sure I know the right component for it.  I hope that if there is the possibility of continued work in this area we won't hold it up just because we don't have a bugzilla component for it.

Moxie's also right.  Some of the worst security bugs can be found when one participant in the API or system doesn't know exactly what the intent or actions are on the other side of the API or system.

Comment 12

[chris hofmann]

In a shorter summary here is the bug that I think we have now.  To quote Rob:

> I would consider any CA who does not retain full "control of the contents of
> the basicConstraints extensions in the certs it issues" to be incompetent.  I
> sincerely hope that no CAs fall into this category.
> 

this bug is about replacing that *hope* with action.  what could we do to encourage and/or require more continuing assurance, disclosure, auditing, and visibility into who is getting certs, for what domains, and what the contents of the certs are?

> 
> I fully agree.  Comodo have always imposed path length constraints on
> "low-level" CAs.  If other CAs have not been doing this, I would very much
> like to know why.

right, if there are problems out there it's in the best interest of all 4 groups listed above to know about them and take action.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

OK, Mozilla Foundation has a policy governing its acceptance criteria for 
CAs whose certs are in Mozilla's trusted root CA list.  MoFo has a group
that administers (and occasionally revises) that policy.  

Mozilla has a newsgroup in which discussions about the policy itself, its 
efficacy, proposed changes, etc. should take place.  That is 
   news://news.mozilla.org:119/mozilla.dev.security.policy

Any and all issues with specific CAs who either 
a) want to be added to the list or 
b) are in the list, but maybe should not be, 
should be handled through bugzilla bugs filed against 
product: mozilla.org
component: CA Certificates

When Mozilla's cert policy group makes changes to the official list, 
then bugs get filed against NSS to change its list to match mozilla's list.
That's what product NSS component CA Certificates is for.  

If this bug is about a specific CA, then perhaps it should be reopened and
changed to product mozilla.org.  If it is about policy, or about the 
establishment of a mozilla policing agency to monitor CAs, that discussion
should happen in mozilla.dev.security.policy, IMO.