dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
20
share rss forum feed


Matt3
All noise, no signal.
Premium
join:2003-07-20
Jamestown, NC
kudos:12
reply to cdru

Re: Simple solution

said by cdru:

said by Matt3:

This is done at the DNS layer, SSL doesn't matter.

With SSL though, the ISP isn't going to know what the user is searching for to proxy the results. It's also encrypted by google so they can't alter/inject their own results back. And if they redirect all traffic going to https google to their spoofed proxy site that looks like https google, the real certs won't be valid.

They can easily act as a man-in-the-middle SSL proxy and your browser would be none the wiser. You have to go much lower on the OSI model to prevent this type of hijacking, think network or transport layer, not the session or application layer.


cdru
Go Colts
Premium,MVM
join:2003-05-14
Fort Wayne, IN
kudos:7
said by Matt3:

They can easily act as a man-in-the-middle SSL proxy and your browser would be none the wiser. You have to go much lower on the OSI model to prevent this type of hijacking, think network or transport layer, not the session or application layer.

Can you please elaborate? I won't say that you're wrong, but I don't think your right.

Taking google for instance, presuming that google has a properly installed certificate, the certificate is signed by a trusted CA, and you are actually visiting the correct URL (and haven't been redirected to g00g1e.com, I don't see how a MITM attack would be possible. The presentation of any spoofed certificates would not be signed by a CA and/or match up to the host name, all up to date modern browsers would alert you to this immediately.

If this was possible, it would mean the break down of the entire eCommerce infrastructure due to the insecurity of the transactions.


gme

@ada5ab81.net
Google may have a very valid SSL certificate (from VeriSign even), but the way an SSL MiTM attack works is that the SSL proxy intercepts your HTTPS request, breaks it, and then forwards it on to Google (for example).

What the proxy sends to YOU (and your browser) is a completely separate encrypted SSL page, and your little lock still shows, because the SSL proxy is using a certificate that is trusted in your certificate store.

Countries like Saudi Arabia, Iran, and China, can do this because their country-level CAs are in everyone's browser (bring up certmgr.msc if you're on Windows).

Since the root is universally trusted, the root CAs can issue bogus intermediate certs via their own CAs, forging the legitimate certs to your browser.

You mention the breakdown of eCommerce as we know it, and you're absolutely correct.

SSL has been the worst thing to happen to the Internet.

Not because of the technology, but because of the false sense of security it provides.


Steve
I know your IP address
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5

1 recommendation

reply to Matt3
said by Matt3:

They can easily act as a man-in-the-middle SSL proxy and your browser would be none the wiser.

SSL cannot be proxied in this way without setting off alarm bells in the browser due to cert name mismatches.


Matt3
All noise, no signal.
Premium
join:2003-07-20
Jamestown, NC
kudos:12
said by Steve:

said by Matt3:

They can easily act as a man-in-the-middle SSL proxy and your browser would be none the wiser.

SSL cannot be proxied in this way without setting off alarm bells in the browser due to cert name mismatches.

Cert name mismatches are easy to overcome, you simply spoof the name of the URL with a fake cert. It's the chain to the intermediate and/or root certificate that is stored in the browser or local computer's certificate store that I'm not quite sure how they'd work around ... without compromising and delivering an intermediate cert to the browser or OS trust store.

Bruce Schneier has a good summation from April of 2010 of one way to do this, readily built into an appliance. The comments are worth reading as well.

»www.schneier.com/blog/archives/2···d_2.html

quote:
Although current browsers don't ordinarily detect unusual or suspiciously changed certificates, there's no fundamental reason they couldn't (and the Soghoian/Stamm paper proposes a Firefox plugin to do just that). In any case, there's no reliable way for the wiretapper to know in advance whether the target will be alerted by a browser that scrutinizes new certificates.


Matt3
All noise, no signal.
Premium
join:2003-07-20
Jamestown, NC
kudos:12
reply to gme
said by gme :

Google may have a very valid SSL certificate (from VeriSign even), but the way an SSL MiTM attack works is that the SSL proxy intercepts your HTTPS request, breaks it, and then forwards it on to Google (for example).

What the proxy sends to YOU (and your browser) is a completely separate encrypted SSL page, and your little lock still shows, because the SSL proxy is using a certificate that is trusted in your certificate store.

Countries like Saudi Arabia, Iran, and China, can do this because their country-level CAs are in everyone's browser (bring up certmgr.msc if you're on Windows).

Since the root is universally trusted, the root CAs can issue bogus intermediate certs via their own CAs, forging the legitimate certs to your browser.

You mention the breakdown of eCommerce as we know it, and you're absolutely correct.

SSL has been the worst thing to happen to the Internet.

Not because of the technology, but because of the false sense of security it provides.

This is a very good explanation and is inline with what I have read about SSL man-in-the-middle attacks. The crux seems to be that in most modern certificate stores (be it Firefox's internal or the one in Windows) there are simply too many trusted root/intermediate certificates that are valid for 10+ years.

All it takes is one relatively common cert to be exploited and you could build a spying business off it ... while working on the next one to compromise to extend your business another 10 years.


Steve
I know your IP address
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5
reply to Matt3
said by Matt3:

Cert name mismatches are easy to overcome, you simply spoof the name of the URL with a fake cert.

I am familiar with Bruce's piece, and I'm pretty sure you missed a key piece, the part where the cert vendors were induced to issue valid certs for the URLs they wish to intercept.
said by the abstract :

This paper introduces a new attack, the compelled certificate creation attack, in which government agencies compel a certificate authority to issue false SSL certificates that are then used by intelligence agencies to covertly intercept and hijack individuals' secure Web-based communications.

These are "false" certs only in the sense that they're not the ones issued by the real owners, but they will validate the same as the real ones, and there's nothing the clients can do to notice that something is awry.

I really hope that ISPs are not getting bogus certs.

Steve
--
Stephen J. Friedl | Unix Wizard | Microsoft Security MVP | Orange County, California USA | my web site


rchandra
Stargate Universe fan
Premium
join:2000-11-09
14225-2105
reply to Matt3
Even more to the point, validity checking of certs relies on valid DNS results. Without widespread DNSSEC client implementations and validations, and zone signatures, it is likewise MitM vulnerable.