[cryptography] if MitM via sub-CA is going on, need a name-and-shame catalog (Re: really sub-CAs for MitM deep packet inspectors?)

Peter Gutmann pgut001 at cs.auckland.ac.nz
Fri Dec 2 07:00:14 EST 2011


Adam Back <adam at 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_Module.pdf? 
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.



More information about the cryptography mailing list