MITM attacks, the day after ...

I suppose C2 got as many "do you know how hard it is" complaints as
I have, or more. But dispite that, several people broke keys.

There seem at this point to be two messenger or man in the middle attacks
on SSL that have enough merit to explore further.

#1  Attack client binaries to suppress certificate validation, and accept
ones forged by the filter/MITM. The binary attack could occur during down
load from NetScape (a good ISP level attack) or after the fact with a virus.
The client binary would be normally functioning with servers other than the
attacking MITM filter.

#2  Present client with the filters valid certificate and hope that in the
rare case the user looks, that they will not question it, or even know what
a valid one from the real server is.

Since detection is possible in both of these, attack only a few percent of the
traffic until the heat is on, then lay dormant or move to a different site.

Suggested to me this morning was taking a harder look proxy servers.

John

> There seem at this point to be two messenger or man in the middle attacks
> on SSL that have enough merit to explore further.
> 
> #1  Attack client binaries to suppress certificate validation, and accept
> ones forged by the filter/MITM. The binary attack could occur during down
> load from NetScape (a good ISP level attack) or after the fact with a virus.
> The client binary would be normally functioning with servers other than the
> attacking MITM filter.

That's not an attack on SSL.   It's an attack on an application.
It's no different, conceptually, than attacking sendmail or MS Word.

The point to attacking SSL is to be able to decode a message from any
browser, without having to do anything extraordinary to the victim's host.
No cryptosystem is proof against an attacker who can see and
control everything you do on the client side (i.e. has root in UNIX
parlance).

So, while your idea #1 might be interesting or fun to do as far as computer
security goes, it's not an attack on SSL. 

> #2  Present client with the filters valid certificate and hope that in the
> rare case the user looks, that they will not question it, or even know what
> a valid one from the real server is.

That points out the flaw in Netscape's authentication model that
others have already pointed out on this list.  Admittedly, like Don
Stephenson just posted, there's not really a good way to distribute
and authenticate certificates until there's a ubiquitous global
CA chain.



-- 
Eric Murray  ericm@lne.com  ericm@motorcycle.com  http://www.lne.com/ericm
PGP keyid:E03F65E5 fingerprint:50 B0 A2 4C 7D 86 FC 03  92 E8 AC E6 7E 27 29 AF