----- Forwarded message from Bryce Lynch <bryce@zerostate.is> ----- Date: Thu, 22 Aug 2013 12:00:52 -0400 From: Bryce Lynch <bryce@zerostate.is> To: doctrinezero@zerostate.is Subject: Re: [Doctrinezero] HTTPS Organization: Zero State User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 Reply-To: doctrinezero@zerostate.is -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/21/2013 10:37 AM, Dirk Bruere wrote:
Do the certification authorities hold a key that can break the encryption of sites that use it?
It's more complicated than that. Most of the time, whenever someone buys an SSL certificate pair signed by a CA, they have the CA generate the certificate pair for them (because OpenSSL's command line is pants, usually), sign it for them, and then send them the whole mess. The CA archives copies of the public and private certs after signing. We've seen several times in the past where CAs have given untrusted third parties copies of those signed certs. Ouch. There is a subtle flaw in the CA ecosystem: So long as a cert is signed by a CA that the client trusts, it doesn't matter /who/ the signer was. So, example.com could buy an SSL certificate from Thawte, and Eve could buy an SSL cert from Comodo for example.com. Eve could then use her cert for example.com to run a man-in-the-middle attack against users of example.com, and their browsers would never notice because both Thawte and Comodo are trusted. The SSL protocol has no provision for noticing if and when the trust chain changes in mid-flight. Double ouch. We've seen this one happen in the field several times. This is how ComodoHacker wrecked so much havoc a few years ago. There is another flaw in SSL: Wildcards. It is not uncommon for companies to buy SSL certs valid for *.example.com, so that they have only one cert covering all of their SSL enabled resources. What isn't obvious is that it's possible to generate a valid cert for *.com. Or *.org. Or *. Those certs are valid for *.com, or *.org, or * (any SSL enabled resource on the global Net) until they expire. A few of the big CAs sell these for whoever can pony up for them (they're very expensive) because they can be loaded into DPI/DCI hardware which basically carries out MITM attacks for detecting data exfiltration. That they are also used for surveillance comes with the territory. At least one CA that was pwned in the past five years had a number of wildcard certs generated by the attacker for * which are good until 1 January 2038. Uh-oh. Third parties have been trying to find ways to fix this - certificate pinning, TOFU/POP, Webs of Trust for SSL, Convergence, manually untrusting every CA in your browser - but none of them have caught on. - -- The Doctor [412/724/301/703] [ZS] PGP: 0xF1F922F2 / CABE 73FB 2D68 D1EF 3956 A468 7B1F DFE8 F1F9 22F2 WWW: https://drwho.virtadpt.net/ The future belongs to the brave. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSFjWzAAoJEHsf3+jx+SLyYGUH/3ekahHofFHoxwcIAXikcxY6 SEgYQdN2MQyyX4JHfC+T56d0spWyBykd87NV53+qqxLkRpK90OHAgcciKTctyFw7 Vw4VUGIJlie+IXItZTD203mWLjfHlNubJFCTCFeujVs/Sl9WBCXOi3I2mN9RP20j G3EPYvR7NWUk8Y0O66ZUwh5Wnblj1PtbpCqU6vbByK1DWTIOopI1UC++aU7wYw4F 9IyfoXRe7JJIjexxq03XRsOc2GeaYkuy6LpwG+LDO3HrTv7Us7Y5plF/ybUnuQWL pccOHBcUgnvaCcD+8S8/6x0do8qVQNNVu74C88SCDR0R6vrNT0k2Ws1wfG8ix8s= =oa/z -----END PGP SIGNATURE----- _______________________________________________ Doctrinezero mailing list Doctrinezero@zerostate.is Unsubscribe: https://lists.zerostate.is/mailman/listinfo/doctrinezero ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
Are you sure about that? (*.com and *. being valid). I thought the MITM boxes were loaded with a sub-CA cert - a cert with a bit set authorizing it to generate certs for sites, some of the smaller CAs are not directly in the trusted browser databases, and have bought sub-CA certs from CAs that are. Then what actually happens in the MITM box is to load a fake cert for a domain (issued by its sub-CA cert), or to generate fake certs on the fly for any targetted domains (or all domains) again issued by its sub-CA cert. So I thought the CA that got warned by mozilla had issued a sub-CA cert for MITM purposes. (I really dont think a browser vendor would accept *.com nor especially *. as a valid site cert wildcard. It does get fiddly because you also want *.co.uk etc to be invalid but they have some built in tables of such things to differentiate a TLD from a domain). Adam On Thu, Aug 22, 2013 at 06:09:28PM +0200, Eugen Leitl wrote:
----- Forwarded message from Bryce Lynch <bryce@zerostate.is> -----
Date: Thu, 22 Aug 2013 12:00:52 -0400 From: Bryce Lynch <bryce@zerostate.is> To: doctrinezero@zerostate.is Subject: Re: [Doctrinezero] HTTPS Organization: Zero State User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 Reply-To: doctrinezero@zerostate.is
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/21/2013 10:37 AM, Dirk Bruere wrote:
Do the certification authorities hold a key that can break the encryption of sites that use it?
It's more complicated than that.
Most of the time, whenever someone buys an SSL certificate pair signed by a CA, they have the CA generate the certificate pair for them (because OpenSSL's command line is pants, usually), sign it for them, and then send them the whole mess. The CA archives copies of the public and private certs after signing. We've seen several times in the past where CAs have given untrusted third parties copies of those signed certs. Ouch.
There is a subtle flaw in the CA ecosystem: So long as a cert is signed by a CA that the client trusts, it doesn't matter /who/ the signer was. So, example.com could buy an SSL certificate from Thawte, and Eve could buy an SSL cert from Comodo for example.com. Eve could then use her cert for example.com to run a man-in-the-middle attack against users of example.com, and their browsers would never notice because both Thawte and Comodo are trusted. The SSL protocol has no provision for noticing if and when the trust chain changes in mid-flight. Double ouch. We've seen this one happen in the field several times. This is how ComodoHacker wrecked so much havoc a few years ago.
There is another flaw in SSL: Wildcards. It is not uncommon for companies to buy SSL certs valid for *.example.com, so that they have only one cert covering all of their SSL enabled resources. What isn't obvious is that it's possible to generate a valid cert for *.com. Or *.org. Or *. Those certs are valid for *.com, or *.org, or * (any SSL enabled resource on the global Net) until they expire. A few of the big CAs sell these for whoever can pony up for them (they're very expensive) because they can be loaded into DPI/DCI hardware which basically carries out MITM attacks for detecting data exfiltration. That they are also used for surveillance comes with the territory. At least one CA that was pwned in the past five years had a number of wildcard certs generated by the attacker for * which are good until 1 January 2038. Uh-oh.
Third parties have been trying to find ways to fix this - certificate pinning, TOFU/POP, Webs of Trust for SSL, Convergence, manually untrusting every CA in your browser - but none of them have caught on.
- -- The Doctor [412/724/301/703] [ZS]
PGP: 0xF1F922F2 / CABE 73FB 2D68 D1EF 3956 A468 7B1F DFE8 F1F9 22F2 WWW: https://drwho.virtadpt.net/
The future belongs to the brave.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSFjWzAAoJEHsf3+jx+SLyYGUH/3ekahHofFHoxwcIAXikcxY6 SEgYQdN2MQyyX4JHfC+T56d0spWyBykd87NV53+qqxLkRpK90OHAgcciKTctyFw7 Vw4VUGIJlie+IXItZTD203mWLjfHlNubJFCTCFeujVs/Sl9WBCXOi3I2mN9RP20j G3EPYvR7NWUk8Y0O66ZUwh5Wnblj1PtbpCqU6vbByK1DWTIOopI1UC++aU7wYw4F 9IyfoXRe7JJIjexxq03XRsOc2GeaYkuy6LpwG+LDO3HrTv7Us7Y5plF/ybUnuQWL pccOHBcUgnvaCcD+8S8/6x0do8qVQNNVu74C88SCDR0R6vrNT0k2Ws1wfG8ix8s= =oa/z -----END PGP SIGNATURE----- _______________________________________________ Doctrinezero mailing list Doctrinezero@zerostate.is Unsubscribe: https://lists.zerostate.is/mailman/listinfo/doctrinezero
----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5
On 08/22/2013 05:25 PM, Adam Back wrote:
(I really dont think a browser vendor would accept *.com nor especially *. as a valid site cert wildcard. It does get fiddly because you also want *.co.uk etc to be invalid but they have some built in tables of such things to differentiate a TLD from a domain).
About three years ago I looked at that code on WebOS (Palm smart phones). The code came from Webkit which is what Google's and Apple's browsers were based on. It did not accept *.com, certainly not *., and had some complex logic to decide what to accept. I doubt that Mozilla accepts *.com or *. as well. Few modern CAs issue certs with wildcards in the CN. Instead they use the SubjectAlternateName extension which can have multiple entries, reducing or eliminating the need for wildcards. Eric
participants (3)
-
Adam Back -
Eric Murray -
Eugen Leitl