[cryptography] how many MITM-enabling sub-roots chain up to public-facing CAs ?

Ralph Holz holz at net.in.tum.de
Tue Feb 14 15:35:45 EST 2012


> In both cases, Crossbear will detect a MITM device, yes?  But in one
> case, the device is authorized to sign for the entities it's signing
> certificates for, and in the other, it's not.
> This does not in any way diminish the usefulness of Crossbear as a tool
> for detecting MITM devices.  But what's interesting about what happens
> in these two cases is that it's _whether the user is being deceived_
> that differs.  Crossbear can't know that -- the user has to supply the
> knowledge of whether there is, in fact, an authorized MITM in place.

Ah, I see where you're going with this.

Crossbear signals its findings to the client browser, via a separate SSL
connection (the CB server cert is hard-coded into the Crossbear client).
The assessment comes complete with a view of what others are seeing,
including a view we obtain by asking Convergence. The suspicious chain
is sent to our database for human analysis.

As Crossbear's assessment is not something everyday users will
understand, we ourselves view Crossbear as the tool that, e.g., a
travelling security afficionado/hacker/interested person might want to
use, but not your average guy. Our goal is to find out how many Mitm
actually happen, and how, and where. That's why Crossbear has this
second component, the hunting tasks.

BTW: Crossbear's assessment still leaves some potential for false
positives: there are plenty of server farms out there that use more than
one (valid) chain. If a new but valid one pops up, no system can know it
at first. That's where all these notary-based systems get in trouble
when they cache (and they have to, at least on the global scale, like

> And that is precisely what is wrong with what Trustwave did: they tried
> to make it look like there was no MITM in place instead of an unauthorized
> one, where in this case "authorized" means "the administrator of the client
> node positively agreed to have that node's traffic MITMed".

Yes, fully agreed. But I still think pulling their root would have given
the wrong incentive to CAs.


Ralph Holz
Network Architectures and Services
Technische Universität München
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20120214/5b9bde2a/attachment.asc>

More information about the cryptography mailing list