<div dir="ltr">Bonsoir,<br><div class="gmail_extra"><br><div class="gmail_quote">2016-05-31 19:25 GMT+02:00 Phillip Hallam-Baker <span dir="ltr"><<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, May 31, 2016 at 12:54 PM, Erwann ABALEA <span dir="ltr"><<a href="mailto:erwann@abalea.com" target="_blank">erwann@abalea.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Bonjour,<br><div class="gmail_extra"><br><div class="gmail_quote"><span>2016-05-31 16:34 GMT+02:00 Phillip Hallam-Baker <span dir="ltr"><<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Sun, May 29, 2016 at 8:55 AM, Stephen Farrell <span dir="ltr"><<a href="mailto:stephen.farrell@cs.tcd.ie" target="_blank">stephen.farrell@cs.tcd.ie</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><br>
<br>
On 29/05/16 02:35, Henry Baker wrote:<br>
> FYI --<br>
><br>
> <a href="http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/" rel="noreferrer" target="_blank">http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/</a><br>
><br>
> A Controversial Surveillance Firm Was Granted a Powerful Encryption Certificate<br>
> Written by Joseph Cox, Contributor<br>
<br>
</span>Yeah, two things strike me:<br>
<br>
1 - yay for certificate transparency - CAs behaving oddly being spotted<br>
and outed is good<br>
<br>
2 - what kind of "testing" would require symantec to issue a CA<br>
cert with path-len 0 and for symanetec to hold the private key? I<br>
can't figure anything that makes sense unless symantec were thinking<br>
of actively helping blue coat spoof web sites better, maybe at<br>
run-time, or on a case-by-case basis - or am I missing something?<br>
<br>
Cheers,<br>
S.</blockquote><div><br></div></span><div>For the benefit of us who can't remember, what is the effect of path-len 0?</div></div></div></div></blockquote><div><br></div></span><div>A CA certificate containing a BasicConstraints with pathLenConstraint=0 means that this CA certificate can only be used to verify an end-entity certificate, or a CA certificate that doesn't issue any certificate, but not a CA certificate that itself would issue another certificate (either CA or end-entity).</div><div><br></div><div>To simplify:</div><div> CA(BC:pathLenConstraint=0) -> end-entity : OK</div><div> CA(BC:pathLenConstraint=0) -> CA(anything) : OK</div><div> CA(BC:pathLenConstraint=0) -> CA(anything) -> any certificate : NOT OK</div></div></div></div></blockquote><div><br></div></div></div><div>One of the things I learned from experimental physics was that you should always ask the question even if you think you know the answer.</div><div><br></div><div>I deliberately asked what the *effect* was, not what the specification says. The questions are not the same.</div><div><br></div><div>What I had forgotten is:</div><span class=""><div><br></div><div> CA(BC:pathLenConstraint=0) -> CA(anything) : OK<br></div><div><br></div></span><div>Which is kinda screwed up. I am still not seeing how to turn this into an exploit if Symantec hold the private key.</div></div></div></div></blockquote><div><br></div><div>The normative path validation algorithm takes as input a prospective certification path, and this certification path can end with a CA certificate. Which can be seen as useless, but may raise some specific implementation quirks. This CA certificate could be an X.509v1 cert, raising other potential quirks.</div><div><br></div><div>Another behavior dictated by the norm is this:</div><div> CA(BC:pathLenConstraint=0) -> self-issued CA(anything) -> end-entity : OK</div><div>That is, they could issue another CA certificate named the same (C=US, O/OU..., CN=Blue Coat Public Services Intermediate CA) for which they have the private key, and then issue end-entity certificates. It works because the pathLength is decremented for each non self-issued CA certificate. I haven't tested implementations on this point.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>As in, what is the effect on systems out there in the wild as opposed to what does the spec say. Is there a difference and if so for what systems?<br></div><div><br></div><div>Does 0 = infinity? Probably not in the spec but what about elsewhere?</div></div></div></div></blockquote><div><br></div></span><div>0 is not infinity. Infinity is expressed as the absence of the pathLenConstraint field.</div></div></div></div></blockquote><div><br></div></span><div>OK so that possibility out.</div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Some not so old versions of GnuTLS didn't correctly verify the pathLenConstraint, at least. I think it was corrected in 2014.</div><div>OpenSSL, NSS, MSCAPI, and Opera are OK. Don't know about PolarSSL/mbedTLS or other smaller TLS stacks.</div></div></div></div></blockquote><div><br></div></span><div>Does any browser use GnuTLS though? I don't think we need to panic if the code is being used for STARTTLS in SMTP or the like as those aren't typically tied to a root of trust in any case.<br clear="all"></div></div></div></div></blockquote><div><br></div><div>Browser, maybe none. But some Linux distributions compile and link some software with GnuTLS (I've seen some OpenLDAP in Debian/Ubuntu, for example). Some cli tools such as curl/wget, or proxies can be compiled with GnuTLS.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
</div>
</div></div></div></blockquote></div></div></div>