<div dir="ltr">If only X.509 name constraints actually worked.<div><br></div><div>Perhaps if the implementations could get fixed / finished, it would be possible to get the browser vendors to agree to put them in place for select new TLDs.</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 19, 2014 at 2:03 PM, John Denker <span dir="ltr"><<a href="mailto:jsd@av8n.com" target="_blank">jsd@av8n.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

AFAICT, a lot of existing protocols were designed to resist<br>
passive eavesdropping.  In contrast, the idea of large-scale<br>
MITM attacks was sometimes considered tin-foil-hat paranoia.<br>
To this day, standard Ubuntu Firefox trusts 162 different<br>
authorities (including the Hong Kong Post Office) to certify<br>
/anything and everything/.<br>
<br>
In the /usr/share/ca-certificates/mozilla directory, only one<br>
of 163 root certificates has any v3 Name Constraints at all.<br>
Why Ubuntu and Firefox tolerate this is beyond me; I can<br>
understand trusting Microsoft to sign Microsoft-related stuff,<br>
but allowing them to sign /anything and everything/ ?!????!!<br>
<br>
     Actually it's even worse than that, because people like<br>
     Microsoft have been issuing subsidiary certificates with<br>
     unlimited power, so you don't even need to capture a root<br>
     CA;  all you need is one of the subsidiary certs.<br>
<br>
Forsooth, one would think that if these Authorities had any<br>
sense at all, they would voluntarily put constraints on their<br>
own certificates, just to make themselves less of a target.<br>
Issuing an all-powerful cert is like walking through a bad<br>
neighborhood pushing a wheelbarrow full of cash.  If you<br>
carried less cash, you'd be less of a target.<br>
<br>
Forged certs are a documented problem in the wild.  No tin-foil<br>
hat required:<br>
     <a href="https://www.linshunghuang.com/papers/mitm.pdf" target="_blank">https://www.linshunghuang.com/papers/mitm.pdf</a><br>
<br>
SSL "packet inspection" is an article of commerce.  The fact that<br>
this is even remotely possible tells me that SSL fails to provide<br>
the thing I most want it to provide.<br>
  <a href="https://www.google.com/search?q=%22ssl+packet+inspection%22" target="_blank">https://www.google.com/search?q=%22ssl+packet+inspection%22</a><br>
<br>
That crunching noise you hear is the sound of dead canaries<br>
underfoot.  We really need to take action to reduce exposure<br>
on this issue.<br>
_______________________________________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" target="_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Tony Arcieri<br>
</div>