[SSL Observatory] openssl patch: A way to display which root certificate in the browser a SSL certificate is rooted to

[Walter Goulet]

Thanks Peter this is really helpful. The more I think about this, what I
really want to do is answer the question in the opposite form (which SSL
certs are chained to a given CA cert)? So the root_ca_importance.py is
probably the best place for me to start.

As to my original approach, I'm not sure if that's really necessary. You are
right in that openssl verify stops as soon as it finds 1 valid chain, but
looking at the code it shouldn't be too hard to modify it to search through
all entries in CApath. But that approach requires not just patching openssl
but modifying the schema and rebuilding my database. I think I'll try the
easier route first ;)

Thanks again,
Walter

On Thu, Jun 30, 2011 at 11:30 AM, Peter Eckersley <pde at eff.org> wrote:

> On Thu, Jun 30, 2011 at 01:13:28AM -0500, Walter Goulet wrote:
> > Hi,
> >
> > My perusal of the observatory data is that the acerts and vcerts tables
> > include the issuing cert and a flag indicating whether or not the given
> SSL
> > cert is in the mozilla or microsoft trusted root repositories.
>
> No, moz_valid and ms_valid contain the output of openssl verify called with
> their trusted root repositories /and/ any intermediate CA certs that were
> in
> the chain presented by that webserver.  The intermediates are included with
> the -untrusted flag, so OpenSSL checks signatures from roots before using
> them.
>
> The transvalid column contains the output of openssl verify valled with the
> above /plus/ extra intermediate CA certs that look like they were missing
> from
> the chain presented by the webserver.
>
> > But, the
> > issuing cert is usually just an intermediate cert unless a misbehaving
> root
> > CA is directly signing SSL certs. What I really want to know is which
> > particular root cert in the mozilla/microsoft root repositories is
> vouching
> > for a SSL cert.
>
> The answer will often be several, because of cross-certification of
> intermediate CAs (look at the map of CAs PDF).  It's possible to estimate
> which root CAs are at the tops of the chain by Subject/Issuer and AKID/SKID
> matching amongst the set of valid CAs.
>
> Much of this logic is actually implemented in the root_CA_importance.py
> (and
> SubordinateTracking.py) scripts that you can find in questions/ca_graph/.
>  You
> could probably modify root_CA_importance.py to answer your questions.
> Apologies that they aren't neater and better documented, we wrote them in a
> hurry ;).
>
> It is possible that these scripts will slightly overestimate the set of
> root
> CAs ultimately validating a given valid end-entity certificate.  If I make
> some untested assumptions about how openssl implements SKID/AKID matching,
> I
> think this type of overestimation would only happen for CA certs that don't
> have SKID/AKIDs, and where several different CA certs with different keys
> share the same Subject, but some of those keys never signed along this
> path.
>
> >
> > Currently, this doesn't appear to be possible because the openssl verify
> > command at the heart of the observatory scripts doesn't print out which
> root
> > CA in it's CApath directory actually issued the cert. This patch modifies
> > the verify application so that when the 'verbose' flag is passed to the
> > verify command, the issuer of the self-signed certificate at the top of
> the
> > chain is printed. This patch applies to the latest 1.0.0d version of
> > OpenSSL. I feel pretty confident in this patch as I tested it against
> debug
> > printouts that I added to the raw X509_verify_cert function in x509_vfy.c
>
> I suspect OpenSSL builds chains until it finds one that works, and then
> stops.  In that case, this strategy will not tell you about
> cross-certification from multiple roots.
> >
> > To really make this patch useful, additional fields would have to be
> added
> > to the acerts/vcerts tables to store the root issuing cert name and the
> > python scripts would have to be re-run. I'll probably work on that over
> the
> > next few days myself, but if anyone out there with a EC2 account that is
> > more handy with the data/scripts could probably apply this patch and make
> a
> > new snapshot of the data for us all to use.
>
> If for some reason you still want to pursue this route, I'm happy to try to
> answer particular questions about the scripts and schema.
>  #https-everywhere
> on irc.oftc.net would be one place to ask in realtime.
>
> >
> > And I really hope I didn't miss something obvious and this data is
> captured
> > somewhere else that I just plainly missed.
> >
> > Thanks,
> > Walter
> >
> > --- /home/wgoulet/Downloads/openssl-1.0.0d/apps/verify.c    2009-10-31
> > 12:21:47.000000000 -0700
> > +++ verify.c    2011-06-29 22:47:33.127029311 -0700
> > @@ -257,6 +257,7 @@
> >      {
> >      X509 *x=NULL;
> >      int i=0,ret=0;
> > +    char buf[2048];
> >      X509_STORE_CTX *csc;
> >
> >      x = load_cert(bio_err, file, FORMAT_PEM, NULL, e, "certificate
> file");
> > @@ -280,6 +281,11 @@
> >      if (crls)
> >          X509_STORE_CTX_set0_crls(csc, crls);
> >      i=X509_verify_cert(csc);
> > +
>  X509_NAME_oneline(X509_get_issuer_name(csc->current_issuer),buf,2048);
> > +    if(v_verbose)
> > +        {
> > +        fprintf(stdout,"Trusted certificate at top of chain: issuer=
> > %s\n",buf);
> > +        }
> >      X509_STORE_CTX_free(csc);
> >
> >      ret=0;
>
> --
> Peter Eckersley                            pde at eff.org
> Senior Staff Technologist         Tel  +1 415 436 9333 x131
> Electronic Frontier Foundation    Fax  +1 415 436 9993
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/observatory/attachments/20110701/1bd558b9/attachment.html>