Well first of all if you don't use a real certificate authority, but install a self generated certificate, then using the man in the middle attack, the other pc can install a self generated cert, and you wouldn't know it, since all you would get is a warning. This of course requires dns/arp poisoning to implement.
If you use a real certificate from one of the certificate authorities, the man in the middle can do 1 of 2 things (after they've done the dns/arp poisoning). 1. Steal the certificate from your server and install it on theirs 2. Somehow get access to make changes to the domain registration or to read the domain registration contact emails, and then buy their own certificate. The scenario you've presented where the user goes to 'bad' site and the 'bad' site accesses the 'good' site as a proxy, the 'bad' site administrator can buy the certificate for their domain name, and no warning will be issued. In your example, I would buy a certificate for tra1ning.fugleaf.com and trick the user into going there. Russ > -----Original Message----- > From: Dave Watts [mailto:[EMAIL PROTECTED] > Sent: Monday, October 02, 2006 6:33 PM > To: CF-Talk > Subject: RE: Break it down for n00bs: security problems of non-SSL intrane > t? > > > Internally... you can sniff whatever you want with a man in > > the middle 'attack'. SSL would just encrypt the payload > > making it harder to get at. > > (There are of course ways around that) SSL on an internal > > network would do nothing but slow someone down or add an > > extra step to the sniffing process (an easy step). > > This is far from being a trivial thing to do. When you use SSL > certificates, > the certificate does two things. First, of course, it enables end-to-end > encryption. Second, and equally important here, it verifies that a host is > what it says it is. For example, if you go to > https://training.figleaf.com/, > the installed certificate says "I belong to training.figleaf.com", and if > I > installed it on tra1ning.fugleaf.com, you would get a certificate error > when > you browsed the site, which would tell you that the certificate doesn't > match with the host presenting said certificate. The only effective > "man-in-the-middle" attack you could make here is if you tricked people > into > going to your site instead of the target site, then had your site make SSL > requests to the target site on the original user's behalf, and because of > the certificate verification, this is unlikely to succeed. > > Second, if you are able to connect to a verified host via SSL, SSL traffic > cannot be examined, practically speaking, unless you can examine it at one > endpoint or the other (the client or the server). In between, it is > prohibitively expensive to examine. SSL doesn't just encrypt the traffic, > it > handles key exchange in a relatively secure way. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > > Fig Leaf Software provides the highest caliber vendor-authorized > instruction at our training centers in Washington DC, Atlanta, > Chicago, Baltimore, Northern Virginia, or on-site at your location. > Visit http://training.figleaf.com/ for more information! > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:255101 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
