full-disclosure - SSL Filtering

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

From: full-disclosure at ifokr.org (Brian Hatch)
Subject: SSL Filtering

> >Is there a way to detect if this MITM is being performed?
> 
> The one method I'm familiar with for how to accomplish this with SSL 
> involves installing keys for a company CA in the users' browsers.  (The 
> SSL MITM box resigns the keys, and as long as the key is trusted by the 
> user, no dire error messages occur.) If you were paying attention, you 
> could check that the signing CA had changed.

Acording to the PDF, yes, this is what happens.  Client browsers
must have the MITM's cert listed as a trusted CA, and at that
point the MITM box can create keys on the fly, sign with it's
cert, and you'd never know what hit you.

So, the only way to determine you were being MITM'd by this is
by checking the certificate that was used.  (Clicking the lock
icon, etc.)

If you go to a bunch of different unrelated sites and they're all
signed by the same cert, you probably know the culprit and can
remove that cert from your trusted CA list if you wanted.  Then
you'd get cert warnings all the time though.

You could get around their inspection by running things like
HTTPTunnel with SSL inside it.  You could do this HTTPTunnel
over SSL inside a MITM'd SSL too.  However regardless how
you do it, with the MITM they should be smart enough to
catch the HTTPTunnel-style traffic.

--
Brian Hatch                  I have no cognitive
   Systems and                powers.  It's amazing
   Security Engineer          that I'm respirating.
http://www.ifokr.org/bri/     --bree

Every message PGP signed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20031017/63160e2d/attachment.bin