If you have a user behind this proxy willing to run Netalyzr and send us the results link either direct to netalyzr-help@icsi.berkeley.edu or to you, I'd be very interested in seeing if we can see the BlueCoat proxy in our Netalyzr testing.
Did you encounter much of the "Hey Mr DJ" Payola going on in the industry when you started? Or was the song written about rumors in the industry at the time?
This sort of structure for a web browser has huge potential latency savings.
Web pages consist of lots of pieces, from lots of places, and lots of dependencies. (Open up Firebug, open the HTTP console, and open up the New York Times to see). Latency is the huge limiting factor on page loads, and is why it takes 1.7 seconds for the NY Times to load for me, even though it only transfered 300 kB of data (which is only.12s on my Internet connection).
The Silk-style structure beats the latency bottleneck in two ways.
For NEW content, the Silk proxy is much closer to the content itself. If its just 20ms closer, that will still save 40ms for each dependent fetch from a different site, 20ms for each dependent fetch from an existing site.
And for content that Silk has CACHED, its even faster, shaving basically ALL latency off the fetch.
IT doesn't hurt that the Fire probably has too small a processor and too little memory to run a real browser, but the latency wins make this structure attractive even for real browsers.
The problem is NOT java, the problem is SSL/TLS. Java was just the vector which was used to exploit this, and disabling Java doesn't disable the real problem, especially since Mozilla refuses to support TLS 1.1.
Its also unclear in the press how the Java same origin bypass worked for this test: Was it click to install or a real flaw? As a tool author (Netalyzr [berkeley.edu]), being able to bypass same origin without a signature dialog would be a big deal in improving the quality of our tool.
The root of the problem (pun intended) is NOT that the SSL/TLS certificate hierarchy is a centralized trust, but that there are hundreds of roots of trust, any one of which may be compromised, and all of which are considered equally valid by the browser.
Who outside of the Netherlands even heard about DigiNotar before this happened?
This is why some people like the idea of using DNSSEC for distributing key material: there exists only a single valid path of trust to a single root for a key associated with any given name: its actually more centralized than SSL/TLS, which is what is desired.
It may not be complete, but, F-secure has a list of the ones created, including *.*.com, *.*.org, www.cia.gov, addons.mozilla.org, *.torproject.org, etc...
We detect JUST redirection, we don't discriminate on it. True, we should probably surpress 127.0.0.1 blocking on a few sites, but we also see those sites in particular redirected to malicious sites by rogue DNS resolvers (caused by malcode infections) so we have to check for redirections on theses sites in DNS.
(The malicious resolvers change ad.doubleclick.net so the ads go through a different ad network which earns money for the malcode-authors who change people's DNS settings, and the change to www.google-analytics.com is to create context-sensitive pop-under advertisements on sites)
We don't say its BAD, we say its interesting: we alert on any non-legit reverse data for any site which would normally have a clean reverse. If you did these changes legitimately, it is a false positive, but since we want to detect all DNS-based blocking & modification of the significant name list, we always alert on these changes.
We check these particular names because there is malcode that changes BOTH these sites to malicious servers, and we alert on any change on theses sites.
We don't do GIFs except for ones on the web page, there are test JPG downloads however, which check for caching.
We also fetch a.exe, a.torrent, a.mp3 file, and a "virus" (the benign EICAR test file which AV systems detect as a virus so you can check AV operation safely).
We specifically detect this condition in Netalyzr as well: we fetch three different 404 pages from our server (a blank page, a default apache page, and a custom page) and detect if they are changed in flight.
They do NOT intercept DNS that's not directed to the ISP's resolvers, thus using Google Public DNS allows you to avoid this redirection completely if you are affected.
Make double-sure that your VPN also tunnels the DNS requests, by checking the configuration and/or by using TCPdump. EG, its pretty easy to accidentally set-up firefox through an SSH tunnel in a way where the DNS requests don't pass through the tunnel.
Could you email a Netalyzr execution from One Communications to netalyzr-help@icsi.berkeley.edu, so we can verify this? It could be due to IBBS, which runs DNS for multiple ISPs.
Google did. This is why the ISPs that were proxying Google stopped in the past couple of months: Google's abuse-detection threw up a CAPTCHA on the queries, and then Google posted about it.
Also, you can run Netalyzr to detect this condition.
I am one of the Netalyzr developers involved in this work. I or my colleagues will answer questions in this thread, but I may be offline for a little while so responses may be somewhat delayed at times.
This now sets a precedent that RMS will respond to fiscal pressure, as he's established that the head of FSF will change who he says it to based on who's paying.
Far better for RMS to have refused the trip entirely. Yes, it would have canceled the Israeli university talks anyway, but it would have at least said that he's unwilling to be bullied or change who he talks to.
And for those who say "He could go on a separate time on Israeli money": There is a huge logistical cost in his time and effort involved in traveling halfway across the globe. A trip like this takes two days near dead for travel time & jetlag alone.
This is a cost which RMS, not the Palestinians, is presumably paying. It makes sense, if this cost is incurred, to also give talks at Israeli universities, as this cost is something the Palestinians presumably aren't paying for, he is.
If, instead, the Palestinians are paying for his travel time as well as his ticket, this makes the precedent even worse.
Thanks. If you have the interest, please email netalyzr-help@icsi.berkeley.edu, we may have some new tests soon that we'd like help testing that may detect additional manipulations.
Anyone using Mediacom, please run Netalyzr ( http://netalyzr.icsi.berkeley.edu) and post the results link, this might be able to detect whatever manipulation is ongoing.
Slashdot Mirror
100,000 AT&T activations, out of well over 1M sales!?!?
If so, most people have heeded the advice: Sprint is cheaper, and Verizon you can make phone calls on.
If you have a user behind this proxy willing to run Netalyzr and send us the results link either direct to netalyzr-help@icsi.berkeley.edu or to you, I'd be very interested in seeing if we can see the BlueCoat proxy in our Netalyzr testing.
Did you encounter much of the "Hey Mr DJ" Payola going on in the industry when you started? Or was the song written about rumors in the industry at the time?
Is the situation any different now?
This sort of structure for a web browser has huge potential latency savings.
Web pages consist of lots of pieces, from lots of places, and lots of dependencies. (Open up Firebug, open the HTTP console, and open up the New York Times to see). Latency is the huge limiting factor on page loads, and is why it takes 1.7 seconds for the NY Times to load for me, even though it only transfered 300 kB of data (which is only .12s on my Internet connection).
The Silk-style structure beats the latency bottleneck in two ways.
For NEW content, the Silk proxy is much closer to the content itself. If its just 20ms closer, that will still save 40ms for each dependent fetch from a different site, 20ms for each dependent fetch from an existing site.
And for content that Silk has CACHED, its even faster, shaving basically ALL latency off the fetch.
IT doesn't hurt that the Fire probably has too small a processor and too little memory to run a real browser, but the latency wins make this structure attractive even for real browsers.
The problem is NOT java, the problem is SSL/TLS. Java was just the vector which was used to exploit this, and disabling Java doesn't disable the real problem, especially since Mozilla refuses to support TLS 1.1.
Its also unclear in the press how the Java same origin bypass worked for this test: Was it click to install or a real flaw? As a tool author (Netalyzr [berkeley.edu]), being able to bypass same origin without a signature dialog would be a big deal in improving the quality of our tool.
The root of the problem (pun intended) is NOT that the SSL/TLS certificate hierarchy is a centralized trust, but that there are hundreds of roots of trust, any one of which may be compromised, and all of which are considered equally valid by the browser.
Who outside of the Netherlands even heard about DigiNotar before this happened?
This is why some people like the idea of using DNSSEC for distributing key material: there exists only a single valid path of trust to a single root for a key associated with any given name: its actually more centralized than SSL/TLS, which is what is desired.
It may not be complete, but, F-secure has a list of the ones created, including *.*.com, *.*.org, www.cia.gov, addons.mozilla.org, *.torproject.org, etc...
Verizon does NOT use Paxfire to redirect search requests through proxies.
The full list of ISPs we've observed doing this proxying is Here.
We detect JUST redirection, we don't discriminate on it. True, we should probably surpress 127.0.0.1 blocking on a few sites, but we also see those sites in particular redirected to malicious sites by rogue DNS resolvers (caused by malcode infections) so we have to check for redirections on theses sites in DNS.
(The malicious resolvers change ad.doubleclick.net so the ads go through a different ad network which earns money for the malcode-authors who change people's DNS settings, and the change to www.google-analytics.com is to create context-sensitive pop-under advertisements on sites)
We don't say its BAD, we say its interesting: we alert on any non-legit reverse data for any site which would normally have a clean reverse. If you did these changes legitimately, it is a false positive, but since we want to detect all DNS-based blocking & modification of the significant name list, we always alert on these changes.
We check these particular names because there is malcode that changes BOTH these sites to malicious servers, and we alert on any change on theses sites.
We don't do GIFs except for ones on the web page, there are test JPG downloads however, which check for caching.
We also fetch a .exe, a .torrent, a .mp3 file, and a "virus" (the benign EICAR test file which AV systems detect as a virus so you can check AV operation safely).
Thats unfortunately common. Your ISP probably offers an opt-out. If it doesn't, change your DNS server to something like Google Public DNS.
We specifically detect this condition in Netalyzr as well: we fetch three different 404 pages from our server (a blank page, a default apache page, and a custom page) and detect if they are changed in flight.
They do NOT intercept DNS that's not directed to the ISP's resolvers, thus using Google Public DNS allows you to avoid this redirection completely if you are affected.
Yes. Netalyzr specifically detects this condition amongst its many other tests. We also have a Java Command Line Client.
You can also check by doing a "dig search.yahoo.com". If the authority is "jomax.net", its a Paxfire appliance changing the results.
OpenDNS also does NXDOMAIN wildcarding.
If you want a clean public DNS, Google Public DNS is a better choice.
If you want a DNS that includes considerable filtering of known badness and other controls, at the cost of NXDOMAIN wildcarding, use OpenDNS.
Netalyzr is up for me, connecting from Washington DC starbucks, as are the EFF and New Scientist articles.
Make double-sure that your VPN also tunnels the DNS requests, by checking the configuration and/or by using TCPdump. EG, its pretty easy to accidentally set-up firefox through an SSH tunnel in a way where the DNS requests don't pass through the tunnel.
Could you email a Netalyzr execution from One Communications to netalyzr-help@icsi.berkeley.edu, so we can verify this? It could be due to IBBS, which runs DNS for multiple ISPs.
Google did. This is why the ISPs that were proxying Google stopped in the past couple of months: Google's abuse-detection threw up a CAPTCHA on the queries, and then Google posted about it.
Also, you can run Netalyzr to detect this condition.
I am one of the Netalyzr developers involved in this work. I or my colleagues will answer questions in this thread, but I may be offline for a little while so responses may be somewhat delayed at times.
This now sets a precedent that RMS will respond to fiscal pressure, as he's established that the head of FSF will change who he says it to based on who's paying.
Far better for RMS to have refused the trip entirely. Yes, it would have canceled the Israeli university talks anyway, but it would have at least said that he's unwilling to be bullied or change who he talks to.
And for those who say "He could go on a separate time on Israeli money": There is a huge logistical cost in his time and effort involved in traveling halfway across the globe. A trip like this takes two days near dead for travel time & jetlag alone.
This is a cost which RMS, not the Palestinians, is presumably paying. It makes sense, if this cost is incurred, to also give talks at Israeli universities, as this cost is something the Palestinians presumably aren't paying for, he is.
If, instead, the Palestinians are paying for his travel time as well as his ticket, this makes the precedent even worse.
I'm one of the MANY coauthors of this paper. Myself or others will try to answer questions in this thread.
Thanks. If you have the interest, please email netalyzr-help@icsi.berkeley.edu, we may have some new tests soon that we'd like help testing that may detect additional manipulations.
Anyone using Mediacom, please run Netalyzr ( http://netalyzr.icsi.berkeley.edu) and post the results link, this might be able to detect whatever manipulation is ongoing.
Thanks!