[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]

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.
_______________________________________________
cryptography mailing list
cryptography at 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