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
participants (2)
-
Eric Murray -
jbass＠dmsd.com