Re: [cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)
Adam Back <adam@cypherspace.org> writes:
a public MitM proxy? Or a corporate LAN.
Private organisation.
That intermediate CA needs publishing, and the CA that issued it.
I was asked not to reveal details and I won't, but in any case I don't know whether it would achieve much. For the case of a public CA doing it, you'd see that CA X is involved, but since it's quite likely that CAs A...W and Y...Z are also at the party, all it'd do is focus people's ire on one entity. Also, if this is being done by a private organisation for DPI to secure their corporate LAN then they're probably quite within their rights to do it. I guess if you're running into this sort of thing for the first time then you'd be out for blood, but if you've been aware of this it going on for more than a decade then it's just business as usual for commercial PKI. I'm completely unfazed by it, it's pretty much what you'd expect.
It breaks a clear expectation of security and privacy the user, even very sophisitcated user, has about privacy of their communications.
Not on a corporate LAN. IANAL but AFAIK your employer's allowed to run that in whatever way they want.
1. private label sub-CA (where the holder has signed an agreement not to issue certs for domains they do not own - I know its policy only, there is no crypto enforced mechanism, but thats the same bar as the main CAs themselves).
For the cases where I've been involved I wasn't aware of there being anything like this in the agreements (actually there probably was something somewhere, I didn't look through all the paperwork). I still have at least some of the documentation stored somewhere (NB: Not under NDA and with the agreement of the parties involved, it was an interesting case study on how these things work), if I ever manage to dig it up I'll see what the conditions were. In any case though it was honour-system security, if you really wanted to do bad things there weren't any controls that I could see to stop you.
3. public provider SSL MitM - if your ISP, wifi hotspot, 3g data prov, is doing this to you, paid or free, thats illegal IMO. Heads should roll up the CA tree.
I think this is where we differ in our outlook. This (and yeah, I'd still like to see the certs for one of these from a public location :-) is business as usual for commercial PKI. Remember the link to the SonicWall docs I posted a few days ago, http://www.sonicwall.com/downloads/SonicOS_Enhanced_5.6_DPI-SSL_Feature_Modu... It's an advertised feature of the hardware (not just from SonicWall, other vendors do it too), d'you think people are going to buy that and then not make use of it? So you just build your defences around the fact that it's broken and then you won't run into problems. Oh, another place where this happens is WAP gateways, where they MITM everything so they can rewrite the content to save bandwidth and make things work on mobile devices. So, is that bad, or good, or both, or neither?
I guess in corporate LANs and that itself employees should be aware of that.
I think employees just need to be aware that a corporate LAN is owned by your employer, and run for their benefit, not yours. If you want to do $non_work_related_whatever, do it from your home system. Peter. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> 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
participants (1)
-
Peter Gutmann