 NetFixerFrom my cold dead handsPremium
join:2004-06-24
The Boro
 ·Comcast Business..
 ·Vonage
 ·Cingular Wireless
·Comcast
| reply to rahvin112
Re: Questions answered in this thread... said by rahvin112:According to the article the issue in this case is that the providers are using deep packet inspection to reroute search results on certain search providers to paid results. The only way to avoid this is encryption and only if they don't MITM (man in the middle) the SSL connection and have free access to your encrypted connections.
This is EXACTLY this issue that created the net-neutrality debate that so many people don't understand. The ISP has free reign over your connection and people don't even realize how badly they could interfere without your knowledge.
That was also my intrepretation of the article, but since nweaver  is supposed to know exactly what is being tested and/or intercepted, perhaps the article is in error?
--
History does not long entrust the care of freedom to the weak or the timid.
-- Dwight D. Eisenhower
The tree of liberty must be refreshed from time to time with the blood of patriots and tyrants.
-- Thomas Jefferson |
|
 cdruGo ColtsPremium,MVM
join:2003-05-14
Fort Wayne, IN
kudos:7 | reply to Matt3
Re: Simple solution 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. |
|
 SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | 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. |
|
|
|
 MxxCon
join:1999-11-19
Brooklyn, NY | reply to rahvin112
Tor is not a solution, it's a workaround. Using Tor you'd bypass your ISPs hijacking, but you have no idea if the exit node you picked has a similar hijacking ISP.
The only way to protect against this kind of hijacking is https or perhaps IP-level authentication that I think IPv6 can provide.
--
Check out my awesome city of MxxTopia »mxxtopia.myminicity.com/ind or »mxxtopia.myminicity.com (the more people visit, the bigger it is) |
|
| reply to NetFixer
Re: Questions answered in this thread... Ah, I see that now. I'm curious, if it's deep packet inspection how does changing DNS server avoid it? Unless the appliance in question only responds to DNS requests that is, but then I don't see how it could alter search results because a DNS request isn't going to include search form submissions unless the providers network is broken. |
|
 Matt3All noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | reply to Steve
Re: Simple solution 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.
|
|
Matt3All 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. |
|
Matt3All noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | reply to zefie
said by zefie:Or maybe Verizon was doing something shady.. because oddly after reading your post I re-enabled this site in the extension, ready to manually except it, but to my surprise, it is not throwing the error anymore. Hmm.
I get random cert errors from this site when I log in from different devices. Seems to be browser based. |
|
Matt3All noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | reply to rahvin112
Re: Questions answered in this thread... said by rahvin112:Ah, I see that now. I'm curious, if it's deep packet inspection how does changing DNS server avoid it? Unless the appliance in question only responds to DNS requests that is, but then I don't see how it could alter search results because a DNS request isn't going to include search form submissions unless the providers network is broken.
As the article mentions, that's where specific "keywords" and URLs come into play.
nweaver , please correct me if I am wrong, but I would think if the Paxfire appliance or software knows you are sending a DNS request to Google, they simply return an IP they own, pointing to a web server they control, read your form submission, then alter the traffic as they see fit ... exactly like OpenDNS currently does for all Google searches? |
|
SteveI know your IP addressConsultant
join:2001-03-10
Yorba Linda, CA
kudos:5 | reply to Matt3
Re: Simple solution 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 |
|
 joakoPremium
join:2000-09-07
/dev/null
kudos:5 | reply to rahvin112
What certain SSL provider?
--
PRescott7-2097 |
|
 dvd536as Mr. Pink as they comePremium
join:2001-04-27
Phoenix, AZ
kudos:4 | HSI should be free Given all the ways providers are making money off our actions!! |
|
4 edits | reply to Matt3
Re: Simple solution If one uses their browser in default setting as intended, a Man in the Middle attack is not transparent and will fail.
Your browser will issue a warning saying the Cert does not match.
All the rest is FUD. |
|
| reply to zefie
said by zefie:Just installed it. Irony is this site fails it. At least for me.
secure.dslreports.com uses an invalid security certificate.
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)
Edit: Oddly only Firefox (v5.0.1, fresh install) is doing it.
Is the plug in compatible with V5? I'm on version 4. |
|
| reply to zefie
I started seeing SSL cert errors with secure.dslreports.com a couple weeks ago. Firefox...er...2!? |
|
KearnstdElf WizardPremium
join:2002-01-22
Mullica Hill, NJ | reply to dvd536
Re: HSI should be free said by dvd536:Given all the ways providers are making money off our actions!!
just think they are snooping data to serve us better targeted ads and then if they truly get their way. they will bill us for the bits consumed by us seeing those ads.
so they will profit off our actions and then profit off the ads generated by our actions and then profit again by the data consumed by those ads.
--
[65 Arcanist]Filan(High Elf) Zone: Broadband Reports |
|
 ctceoPremium
join:2001-04-26
South Bend, IN | reply to kaila
Re: Simple solution ISP's are in the perfect position to use MitM paralelling. You've already given them permission to snoop. You only need a piece of widely used publicly available software to do the trick. |
|
ctceoPremium
join:2001-04-26
South Bend, IN | But then again This is old news to me, at least 6 or 7 years old. I knew it was happening then. Anyone who believed otherwise was simply in their little happy place (the hole they stick their head in when they don't want to believe something is the case). |
|
| reply to Matt3
Re: Questions answered in this thread... Correct: The paxfire appliance sits in front of the DNS resolver. It returns an address in place of NXDOMAINs (the stated function), and also returns the address of their proxy in place of any request for yahoo, bing, or (formerly, sometimes) Google, in order to route the search engine traffic through the proxy. |
|
