From ondrej.mikle@nic.cz Fri Jul 6 02:38:02 2018 From: Ondrej Mikle To: cypherpunks-legacy@lists.cpunks.org Subject: Re: [cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs) Date: Fri, 06 Jul 2018 02:38:02 +0000 Message-ID: <172289092471.3849117.17268319715645949318.generated@mail.pglaf.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6363554794441408108==" --===============6363554794441408108== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This thread is amazing. I've known just a fractions/hints of the practices described here. Few comments/questions inline/below. On 12/04/11 07:37, Lucky Green wrote: > Concur. The standard sub-CA contracts contain a right to audit the > number of certs issued, like any enterprise-wide software license > agreement does include a right to audit used seats. Not once in over 30 > years have I seen such an audit performed. There is no reason to audit: > when you buy a sub-CA, the public CA's rep will work out a contract that > gives you the right to use as many certs and more as you conceivably > could use given the application to which you plan to put the sub-CAs. > Keeping count of actual certs issued would only add cost to both the > sub-CA customer and the root CA provider. There is simply no business > case for auditing the number of certs issued. On 12/02/11 11:02, Peter Gutmann wrote: > It's not just a claim, I've seen them too. For example I have a cert issued > for google.com from such a MITM proxy. I was asked by the contributor not = to > reveal any details on it because it contains the name and other info on the > intermediate CA that issued it, but it's a cert for google.com used for deep > packet inspection on a MITM proxy. I also have a bunch of certs from priva= te- > label CAs that chain directly up to big-name public CAs, there's no technic= al > measure I can see in them anywhere that would prevent them from issuing cer= ts > under any name. How do MitM boxes react when they MitM connection to a server with self-signed cert (or cert issued by an obsure CA not trusted by MitM box)? Do the boxes s= end to client also an auto-generated self-signed cert that generates warning or "re-sign" it so that client sees valid chain? MitM-re-signing an unverifiable chain of server to a chain that's trusted at = the MitM-ed client would be hilarious, allowing to MitM a MitM box (though this would be an easily avoidable mistake to make). Given the state of security/auditing of "private sub-CAs" as described, was there ever a report of a breach (e.g. stolen key, fraudulently issued certs)? While chasing data from my scans around, I checked history of few CAs. Most oddly hilarious "trusted" CA is probably SAIC (Science Applications International Corporation). Reason: SAIC led the development of Trailblazer Project for NSA (in my book this tops much-too-obvious CAs of other TLA agenc= ies). Also, Network Solutions, L.L.C (also a CA) was owned by SAIC at some time. Later, Network Solutions did not acquire exactly "good guy" reputation. Don't get me wrong: I'm not claiming either of the mentioned CAs did anything egregious subverting CA-trust placed in them. I have no intention to single t= hem out as "shady", additional search would turn up many more CAs. Hypothetical question: assume enough people get educated how to spot the MitM box at work/airport/hotel. Let's say few of them post the MitM chains publicly which point to a big issuing CA. It was said (by Peter I think) that nothing would likely happen to big issuing CAs (too-big-to-fail). Would the MitM-ing sub-CAs take the fall? (lose license and invested funds) Ondrej _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- --=20 Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE --===============6363554794441408108==--