Website Technology Issues Forum

In other words, if the user uses the browser as they should, the attack fails.

If you visit a site with a SSL certificate that fails verification (based on root certificates) then IE7 displays a page saying something like "Warning: This server may not be secure and you should not view pages from it" (in IE6 the warning is not a dead-end whole screen, but a Yes/No dialog box -- but IE6 is fortunately dying).

I didn't want to bring up ettercap [ettercap.sourceforge.net], which is completely transparent and doesn't impact your certficate whatsoever. You won't see an invalid cert, nothing, because all ettercap does is sniff and dissect.

FWIW, you can even find software that will crack a WEP key on a wifi, login in and let ettercap do the sniffing.

No FUD there, no certificate warning either.

Here's a nice article from the NYT's about the sniffing software and wifi hotspots [pogue.blogs.nytimes.com]:

Errr... I would never route MY sensitive traffic through a TOR proxy.

That software is again useless in this context. There is no way for a man in the middle to impersonate the remote server, unless he has a valid certificate (or the user ignores the warning screen displayed by the browser). Otherwise, believe me, e-commerce would not exist by now.

I originally stated I didn't want to spell out how to completely pull off a flawless MITM attack but if you must challenge the SSL cert issue again let me explain how it works without the error...

To pull off a true MITM attack without giving away the certificate error, you have to start with an HTTP page, which many people start with such as the bank home page and then login to HTTPS from there.

If the MITM proxy replaces the HTTPS address of the bank with https://www.examplebank.com, such as how I described it above, then you connect to https://www.examplebank.com instead of your bank, no error given.

So if you don't notice the domain name change then you're running via the proxy which has a valid cert.

As a matter of fact, any server that has a valid SSL cert which has been compromised by hackers can be used for this process just like the phishing scams.

Besides, most people wouldn't think twice and would click OK even with the cert warning which is why most MITM attacks don't go to much extreme. If you think people aren't that stupid then try to explain why there are hundreds of thousands of compromised machines from people opening emails from sources they don't know, accepting downloads from rogue sites, etc.. People just aren't that savvy and bypass simple security to get where they want to go, simple as that.

That is not a man-in-the-middle attack as such. That is a user visiting an incorrect URL (the desired SSL connection does not exist so there is nothing to attack). If you bookmark your blog admin page, you can avoid making such a mistake. Besides, you must start with a non-SSL page, which is forbidden if you want to discuss MITM attacks on SSL (https is required).

You're being way to literal because the MITM attack just means that man is just in the middle of your conversation. If you can't sniff the conversation you can simply redirect it through your own proxy which doesn't make it any less of a MITM because someone's server is between you and the intended destination.

The attacks you mentioned, however, are not attacks on SSL connections. The first attack assumes that the user starts browsing a non-SSL URL that takes him to an incorrect URL. This is not an attack on SSL. The desired SSL connection does not exist (with respect to our topic, you have nothing to attack).

The other attacks are not attacks on SSL but exploitation of ignorance of users and their inability to use SSL. This does not mean that SSL cannot protect against MITM attacks (it means that not all people can use SSL).

SSL doesn't stop you from being conned with a MITM using his own (or acquired) server to perpetrate a fraud assuming he redirected you to his server as outlined previously.

SSL, when used correctly, is generally safe. There are some attacks against the random private key generation that is used in each protocol setup, but they are usually defeated by better hardware/software these days.

However, there are many ways to ensure that SSL is not used properly, especially with older browsers that have poor communication with the user.

Again, the fact that some users can't use SSL properly (due to their ignorance) does not mean that SSL cannot prevent MITM attacks. It can, but you need to actually use it (and use it as intended).

Actually, I wasn't because the real fun starts WHEN the connection is initially established on WIFI, not if it already exists.

The potential for SSL mayhem in a compromised wifi situation means you have control over the DNS which allows you to redirect the conversation through a proxy in the first place.

SSL will prevent MITM attacks even on insecure wifi connections (that are fully controlled by an attacker) provided that:

- SSL is used as intended (the user must not ignore warning screens).

- Neither your computer nor the remote server has been compromised.

- The remote server has a certificate issued by a public trustworthy certificate authority.

- The user makes sure he or she visits the correct URL (use bookmarks to access your blog admin page) starting with https://

By the way, I am in no way an expert or even qualified to discuss SSL from this perspective. But, as a new user in this area, I'm clueless! How do "I", the clueless consumer, do all of the above? I just got my laptop too. Help me out here. Don't forget, I've been online since 1995 so I'm not "too" clueless. ;)

Also, what are all these "unsecured networks" appearing in my wireless networks? Should I connect to those? They are free right? Well, that's what I want. A "free" connection. :)

Hmmm, the <title> reads...

The answer has been overwhelmingly NO if you can steer the SSL connection to your server.

You keep assuming MITM is there during an existing conversation but the MITM can be there from the start and direct the data flow to his own server which I've covered a couple of times, which was the initial premise.

As a matter of fact, just so the surfer doesn't know the MITM is even there, the initial request is usually a LOGIN starting from an HTTP page, not an SSL page, which is where the problem starts. The MITM using dnspoof and an SSL proxy can quickly collect your login information and then execute a redirect to the REAL destination so you've just compromised your password without even a change of the URL in the status bar.

Not sure if MSIE or FF alerts when one SSL server redirects to a different SSL server, probably not.

It would appear totally seamless and the MITM could go back at his leisure and login to your bank account and wire transfer all your money offshore.

The problem is that unless the initial request from the visitor is made directly to just examplebank.com it gives the MITM an opportunity to serve up a phish page instead of letting the bank perform it's initial 301 redirect to https://examplebank.com.

So you're safest if you physically type in the https:// yourself and don't let the server do the redirect.

SSL will prevent MITM attacks even on insecure wifi connections (that are fully controlled by an attacker) even if DNS is spoofed or whatever, provided that:

- SSL is used as intended (the user must not ignore warning screens).

- Neither your computer nor the remote server has been compromised.

- The remote server has a certificate issued by a public trustworthy certificate authority.

- The user makes sure he or she visits the correct URL (use bookmarks to access your blog admin page) starting with https://

Yes, I'll agree if you use bookmarks starting with HTTPS and don't click OK on a cert warning you'll probably be safe.

However, the odds of more than a handful of people reading this thread and heading that warning are slim which is why the MITM will still be successful.

At least a few people now might know what to look out for.

Sadly, most ISPs don't provide secure POP or webmail services, except gmail, so most people will compromise their email accounts at a minimum if they check them.