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

On Sat, Dec 03, 2011 at 01:00:14AM +1300, Peter Gutmann wrote:
> I was asked not to reveal details and I won't, 

Of course, I would do the same if so asked.  But there are lots of people on
the list who have not obtained information indirectly, with confidentiality
assurances offered, and for them remailers exist.

> 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, ...

personally I'd like to know who is doing this and at what scale.

> 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.

I do not think its what you'd expect.  A CA should issue certificates only
to the holders of certificates.  It should NOT issue sub-CA certifactes to
third parties who will then issue certs to domains they dont own.  Not even
on the fly inside a "packet inspection" box.

If someone wants to inspect packets on a corporate lan they can issue their
own self-signed cert, and install that in their users browsers in their OS
install image.

Then if I go on their LAN with my own equipment, I'll get a warning.

I think its unacceptable to have CAs issuing such certs.

>> 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.

No.  Also IANAL but there were several cases where employees did have an
expectation of privacy upheld even in the US.  Certainly you cant do that in
the EU legally either.

>> 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.  

I dont view this as business as usual.  If I am on a public hotspot, 3g or
my own DSL/cable I do ABSOLUTELY NOT expect the ISP to be getting inside my
SSL connection to my bank, my gmail account etc.  Whether I paid or not.  
For any reason at all (not to do advert analysis, not to do anti-virus, not
to re-write pages etc).  I use airport/hotel wifi a lot and I've never seen
it and I am suspicious enough to use cert patrol etc.

> 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.

Well yes I know the hardware exists.  I even helped design and implement a
software-only MitM at ZKS.  Before you get alarmed the cert it created was
known only to the user, generated on the machine, and its purpose was to
protect the user via a cookie manager protecting their privacy.

If you read the sonic wall stuff its fairly clear the model that they talk
about at least is that you do not have a sub-CA key.  You generate a
self-signed CA key, and install it in your corporate LAN browsers trusted CA
dbs.  Clearly it would also work with such a cert.

Similarly their doco about server SSL shows they dont expect you to have a
proper sub-CA key.  (scenario where the web server for public access is
behind the sonicwall) you are expected to import your server SSL certs
mapped per IP address into the box.  (Otherwise the public would see
self-signed MitM notices when they browse the site.  Or the sub-CA cert.

> 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?

Well people were complaining about the "WAP gap" a long time ago.  I thought
this was more about the phones at the time being not CPU powerful enough to
terminate SSL.  The idea that a gap exists somewhere where your traffic is
decrypted was viewed as a significant security limitation people were
pleased to see go a way with phones fast enough to terminate their own SSL.

That is bad.  Are you saying there is anyone doing SSL mitm for stream
compression reasons?  Who?

Adam
_______________________________________________
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