On 11/30/11, Rose, Greg <g...@qualcomm.com> wrote: > > On 2011 Nov 30, at 16:44 , Adam Back wrote: > >> Are there really any CAs which issue sub-CA for "deep packet inspection" >> aka >> doing MitM and issue certs on the fly for everything going through them: >> gmail, hotmail, online banking etc. > > Yes, there are. I encountered one in a hotel at Charles de Gaulle airport a > few weeks ago.
How did you know there was a MITM if it gave out a valid cert? Thanks, Lee > > Greg. > >> >> I saw Ondrej Mikle also mentions this concept in his referenced link from >> recent post: >> >> https://mail1.eff.org/pipermail/observatory/2011-November/000484.html >> >>> - SSL inspection/MitM boxes sometimes show up before being configured >>> (Blue Coat, SonicWall, Watchguard Fireware) >> >> How do they know you're going to put the cert in a blue coat box and >> inflict >> that only to your employees vs steal banking passwords and money of users >> in >> an airport? >> >> Do blue coat and other MitM proxies mentioned on this list recently >> actually >> support on the fly cert generation and putting a CA cert in there? >> >> I was presuming that to do so they user would have to self-sign a CA cert >> and "upgrade" their browsers on their corporate installs by adding their >> self-signed MitM cert to the trusted CA set in their standard >> image/install >> set. (Which is obnoxious but fair enough). >> >> But for a CA to intentionally issue an unrestricted sub-CA cert for >> installing in MitM boxes - that sounds outright lethal. How much do you >> trust the box security, the operators of the box. Do they sell such >> sub-CAs >> to Iran, Syria via shady intermediaries? >> >> What do these sub-CA certs cost? What do I have to say or sign to get >> one? Will they sell it to me to monitor my kids? Employees of a small >> startup? >> >> Adam >> >> On Wed, Nov 30, 2011 at 01:30:40PM -0600, Marsh Ray wrote: >>> On 11/30/2011 12:01 PM, Ben Laurie wrote: >>>> On Wed, Nov 30, 2011 at 5:16 PM, Marsh Ray<ma...@extendedsubset.com> >>>> wrote: >>>>> >>>>> Perhaps you define this category of "publicly visible certs" as "certs >>>>> which display without warnings on default-configured browsers when >>>>> presented by the correct site". >>>>> ... >>>>> On the other hand, one could interpret this category of "publicly >>>>> visible certs" as "certs visible to the public", i.e., "certs served by >>>>> legitimate servers on routable IPs located via public DNS". But this >>>>> interpretation would be much weaker (and I don't think that's what you >>>>> mean). >>>> >>>> Although I rather like your first definition, this one seems closer to >>>> the truth: it may be that some sites which currently validate >>>> correctly in default-configured browsers would choose not to in our >>>> system. >>> >>> The certs I am worried about though are the certs that were issued in >>> secret (e.g. Comodo and friends) and are never "publicly visible" until >>> they are used in an attack. >>> >>> If the attack is sufficiently targeted, it may be the case that no one >>> other than the victim ever sees the cert at all. In the event of a mass >>> MitM attack (e.g. *.ir), the attacker would likely have free use of his >>> previously-hidden cert for at least as long as the combined reporting, >>> reaction, and revocation latency. >>> >>> It's not clear how this proposal is actually an improvement on the >>> current system in this regard. >>> >>> On the other hand, if you *did* engage the CAs and get their buy-in, they >>> could pledge to update the log promptly with every cert they issued. >>> Specific CA certs could be configured with this flag in the browser's >>> trusted store. This would allow a missing audit proof to be treated as a >>> hard stop and would seem to be a more meaningful distinction among CAs >>> than the current EV scheme. (The few CAs I've spoken were really grasping >>> for ways with which the 'better' CAs could distinguish themselves in the >>> industry.) >>> >>> Additionally, such a flag could be added to HSTS. Rather than pinning to >>> a specific CA ("I will only use this one CA ever"), a site could pin >>> itself to the use of a CA that promised to participate in the auditing. >>> This would reduce some of the DoS potential inherent in CA pinning yet >>> still allow browsers to catch that critical transition from "provably >>> logged cert" to "non-logged cert". >>> >>>>> But the proposal does nothing _directly_ to prevent a CA from issuing a >>>>> cert, right? And since browsers aren't logging the certs as they find >>>>> them, this doesn't inform the owner of the domain either. >>>>> >>>>> Instead it seems to be a hoped-for effect of "default-configured >>>>> browsers will raise hell if they are presented with a non-logged cert >>>>> and CAs will feel compelled to go along with the audit logging". >>>> >>>> CAs do not have to go along with anything, the log will accept a cert >>>> from anyone - which obviously includes the owner of the cert. >>> >>> There would need to be a way for end-users to report new certs via their >>> browser, much like they report browser crashes today. Wouldn't some users >>> want it? I think it would be good to involve the users in this process as >>> much as is practical. >>> >>>>> they'll have to put the certs they >>>>> issue in the logs too, right? >>>> >>>> Someone will, yes. >>>> >>>>> Wouldn't they have to put the certs they sign in the public log? They >>>>> don't have to do this today. >>>> >>>> No, but their certs are already publicly visible today. >>> >>> I don't believe this is the case. It's one of the big problems with the >>> system we have today. >>> >>> Consider a sub-CA which is issed for the purpose of a company's >>> deep-inspecting firewall (e.g., a BlueCoat). The device will use the >>> sub-CA to issue new certs on-the-fly for each new website that the >>> internal network clients browse to. The rest of the world (hopefully) >>> never sees those certs. >>> >>> Yet this log of the certs that it has generated is highly confidential. >>> It contains info about the browsing history of the entire company, e.g., >>> parts suppliers, financial institutions, use your imagination. >>> >>> The current crop of "trusted" CAs refuse to give the names or even the >>> count of the sub-CAs they've sold. They only require that the party to >>> which they sell them agree in a contract to use them accordingly. >>> >>> I'm all for saying that these sub-CAs need to be put on the boat to the >>> island of lost toys like the toxic plastic that they are. But I wouldn't >>> expect the parties that currently enjoy this privilege to go quietly. :-) >>> >>> - Marsh >>> _______________________________________________ >>> cryptography mailing list >>> cryptography@randombit.net >>> http://lists.randombit.net/mailman/listinfo/cryptography >> _______________________________________________ >> cryptography mailing list >> cryptography@randombit.net >> http://lists.randombit.net/mailman/listinfo/cryptography > > _______________________________________________ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
