7 ms·

HTTPS everywhere would solve this, and the Comcast Javascript injection - I wonder how many more people will deploy things like this before that happens?

revelation 14y ago
You shouldn't have to encrypt your data to stop your ISP from actively 1) scanning and 2) corrupting it. What is the FCC good for?
- HarryHirsch 14y ago
  Indeed. What's with the Internet being a set of tubes?
  - marshray 14y ago
    And tubes based on the honor system at that.
- ams6110 14y ago
  If you don't encrypt your data and verify the sites to which you connect (both of which https does) then anybody between you and them can intercept and alter the transmission. I agree you shouldn't have to do it, but you need to worry about more than just your ISP. Just assume any unsecured internet connection is actively hostile, and you'll be better off.
- betterunix 14y ago
  It is not just about your ISP, it is about all the ISPs between you and the website.
  - Xorlev 14y ago
    Transit and peering providers aren't going to do that. Certainly not tier 1 networks. 1) They can't get away with it 2) That'd slow everything to a crawl, inspecting traffic is expensive at the scales most large providers operate at.
- mikeash 14y ago
  You shouldn't have to, I agree, but apparently you do have to. "Should" counts for nothing.
dmiladinov 14y ago
We hope ads/no-ads arms race would end there. But I could easily see some unscrupulous/greedy ISPs then resorting to setting up SSL proxies to MITM your ostensibly secure traffic, as some private organizations (schools, corporations) already do.
- koenigdavidmj 14y ago
  That's a good way to get yourself the CA death penalty.
  - derleth 14y ago
    So? If Comcast does it, what are they going to do?
    - marshray 14y ago
      A few financial institutions holding large quantities of Comcast's paper (and their executives' IRAs) pick up the phone and explain how they feel about having their secure websites' identity impersonated.
- omellet 14y ago
  They'd have to have their certs installed on your computer, or be an existing CA. Schools and corps (including the one I work for) can do this because they have admin control over destination machines.
  - dmiladinov 14y ago
    You're absolutely right, I didn't mean to imply what schools & corps currently do was shady in any way (as long as you're aware that they're doing it).
jcr 14y ago
Actually, the "HTTPS Everywhere" plugin [1] for firefox and chrome is an incomplete solution. The reason is simple; not all sites support HTTPS, so the plain HTTP-only sites are still vulnerable. Injecting a script into insecure HTTP is just one of many abuses possible by ISP's. Replacing images on the fly is another. Recompressing (degrading) images/video is another. Messing with DNS responses is another, and so on... A far better working solution is to use a VPN service since when it's configured correctly, it will encrypt all traffic passing through your ISP. Of course, this is really just moving the trust problem, rather than solving it, but at least using a VPN service makes it your decision who to trust. I use Tunnelr.com [2] since by reputation, similar interests, and years of traded emails, I know the people who run it. [1] https://www.eff.org/https-everywhere https://www.eff.org/https-everywhere [2] http://tunnelr.com http://tunnelr.com
- ams6110 14y ago
  tunnelr.com... "Powered by OpenBSD"... I like it already.
- richardwhiuk 14y ago
  I meant actually demanding that content providers deploy HTTPS everywhere instead.
  - jcr 14y ago
    Sorry about that. It seems my reading comprehension skills are still flawed. ;)
- kibibu 14y ago
  And here's your annual reminder of the upside-down-ternet http://www.ex-parrot.com/pete/upside-down-ternet.html http://www.ex-parrot.com/pete/upside-down-ternet.html
cramerica 14y ago
It would solve it for many sites, but there are plenty that don't have full https support (and some that have none at all)
joshAg 14y ago
https is the wrong solution. that is for preventing others from seeing what you're sending/receiving, not verifying the integrity of what is sent/received. well, it does do that too, but it adds extra unneeded overhead by encrypting everything. Besides, the ISP can easily man-in-the-middle any connection you make and then inject their ads into the webpage, even if you use https. The correct solution is signing the webpage (but not necessarily encrypting it). More technically, that means the server/website would hash the source of the webpage, and then send the webpage, the signed hash, and if needed, the cert it used to sign the hash. Upon receiving both the webpage and the signed hash, the browser would then check to make sure that the signature can be trusted (using a chain of trust the same way we do with certs for https pages already), hash the webpage source it received, and then verify that that hash matches the signed hash it received from the website. It doesn't matter if any of that is sent in plaintext, because there is no sensitive information, and as long as the hashing algorithm used is strong (ie sha2 family, not md5), then the isp can do fuck all to inject javascript.
- dchest 14y ago
  Ha-ha, and let's call this HTTPSEC http://cr.yp.to/talks/2013.02.07/slides.pdf http://cr.yp.to/talks/2013.02.07/slides.pdf ! (Spoiler: HTTPSEC is not a real thing, it's what we'd had if people who invented DNSSEC, or people like the parent commenter, designed something like TLS).
  - joshAg 14y ago
    wow, that is an annoying slide deck. a lot of the issues seemed to be dns-specific that don't exist with http (slide 110: "Attacker forges many UDP request packets from victim’s IP address to many HTTPSEC servers.", also exist for https (slide 106: "Each HTTPSEC key/signature is another file to retrieve. Often your browser needs a chain of keys from several servers. Could be a serious slowdown."), or were self contradictory (slide 13 says httpsec "allow[s] for verification of the origin, authenticity, and integrity of data' obtained through http", but slide 123 says "The data signed by HTTPSEC doesn’t actually include the web pages that the browser shows to the user". I think the HTTPSEC you are referencing is partly a straw man, because that httpsec does the opposite of what I proposed, which was signing the webpage itself, not the redirect info. I do have some questions about issues brought up in the slides: is the delay/cost of signing versus encrypting data really so huge that it's infeasible to sign dynamic pages? also, why does each non-existent http page need it's own 404? Wouldn't a static 404 response be just fine?

revelation 14y ago

You shouldn't have to encrypt your data to stop your ISP from actively 1) scanning and 2) corrupting it. What is the FCC good for?

HarryHirsch 14y ago
Indeed. What's with the Internet being a set of tubes?
- marshray 14y ago
  And tubes based on the honor system at that.
ams6110 14y ago
If you don't encrypt your data and verify the sites to which you connect (both of which https does) then anybody between you and them can intercept and alter the transmission. I agree you shouldn't have to do it, but you need to worry about more than just your ISP. Just assume any unsecured internet connection is actively hostile, and you'll be better off.
betterunix 14y ago
It is not just about your ISP, it is about all the ISPs between you and the website.
- Xorlev 14y ago
  Transit and peering providers aren't going to do that. Certainly not tier 1 networks. 1) They can't get away with it 2) That'd slow everything to a crawl, inspecting traffic is expensive at the scales most large providers operate at.
mikeash 14y ago
You shouldn't have to, I agree, but apparently you do have to. "Should" counts for nothing.

dmiladinov 14y ago

We hope ads/no-ads arms race would end there. But I could easily see some unscrupulous/greedy ISPs then resorting to setting up SSL proxies to MITM your ostensibly secure traffic, as some private organizations (schools, corporations) already do.

koenigdavidmj 14y ago
That's a good way to get yourself the CA death penalty.
- derleth 14y ago
  So? If Comcast does it, what are they going to do?
  - marshray 14y ago
    A few financial institutions holding large quantities of Comcast's paper (and their executives' IRAs) pick up the phone and explain how they feel about having their secure websites' identity impersonated.
omellet 14y ago
They'd have to have their certs installed on your computer, or be an existing CA. Schools and corps (including the one I work for) can do this because they have admin control over destination machines.
- dmiladinov 14y ago
  You're absolutely right, I didn't mean to imply what schools & corps currently do was shady in any way (as long as you're aware that they're doing it).

jcr 14y ago

Actually, the "HTTPS Everywhere" plugin [1] for firefox and chrome is an incomplete solution. The reason is simple; not all sites support HTTPS, so the plain HTTP-only sites are still vulnerable. Injecting a script into insecure HTTP is just one of many abuses possible by ISP's. Replacing images on the fly is another. Recompressing (degrading) images/video is another. Messing with DNS responses is another, and so on... A far better working solution is to use a VPN service since when it's configured correctly, it will encrypt all traffic passing through your ISP. Of course, this is really just moving the trust problem, rather than solving it, but at least using a VPN service makes it your decision who to trust. I use Tunnelr.com [2] since by reputation, similar interests, and years of traded emails, I know the people who run it. [1] https://www.eff.org/https-everywhere https://www.eff.org/https-everywhere [2] http://tunnelr.com http://tunnelr.com

ams6110 14y ago
tunnelr.com... "Powered by OpenBSD"... I like it already.
richardwhiuk 14y ago
I meant actually demanding that content providers deploy HTTPS everywhere instead.
- jcr 14y ago
  Sorry about that. It seems my reading comprehension skills are still flawed. ;)
kibibu 14y ago
And here's your annual reminder of the upside-down-ternet http://www.ex-parrot.com/pete/upside-down-ternet.html http://www.ex-parrot.com/pete/upside-down-ternet.html

cramerica 14y ago

It would solve it for many sites, but there are plenty that don't have full https support (and some that have none at all)

joshAg 14y ago

https is the wrong solution. that is for preventing others from seeing what you're sending/receiving, not verifying the integrity of what is sent/received. well, it does do that too, but it adds extra unneeded overhead by encrypting everything. Besides, the ISP can easily man-in-the-middle any connection you make and then inject their ads into the webpage, even if you use https. The correct solution is signing the webpage (but not necessarily encrypting it). More technically, that means the server/website would hash the source of the webpage, and then send the webpage, the signed hash, and if needed, the cert it used to sign the hash. Upon receiving both the webpage and the signed hash, the browser would then check to make sure that the signature can be trusted (using a chain of trust the same way we do with certs for https pages already), hash the webpage source it received, and then verify that that hash matches the signed hash it received from the website. It doesn't matter if any of that is sent in plaintext, because there is no sensitive information, and as long as the hashing algorithm used is strong (ie sha2 family, not md5), then the isp can do fuck all to inject javascript.

dchest 14y ago
Ha-ha, and let's call this HTTPSEC http://cr.yp.to/talks/2013.02.07/slides.pdf http://cr.yp.to/talks/2013.02.07/slides.pdf ! (Spoiler: HTTPSEC is not a real thing, it's what we'd had if people who invented DNSSEC, or people like the parent commenter, designed something like TLS).
- joshAg 14y ago
  wow, that is an annoying slide deck. a lot of the issues seemed to be dns-specific that don't exist with http (slide 110: "Attacker forges many UDP request packets from victim’s IP address to many HTTPSEC servers.", also exist for https (slide 106: "Each HTTPSEC key/signature is another file to retrieve. Often your browser needs a chain of keys from several servers. Could be a serious slowdown."), or were self contradictory (slide 13 says httpsec "allow[s] for verification of the origin, authenticity, and integrity of data' obtained through http", but slide 123 says "The data signed by HTTPSEC doesn’t actually include the web pages that the browser shows to the user". I think the HTTPSEC you are referencing is partly a straw man, because that httpsec does the opposite of what I proposed, which was signing the webpage itself, not the redirect info. I do have some questions about issues brought up in the slides: is the delay/cost of signing versus encrypting data really so huge that it's infeasible to sign dynamic pages? also, why does each non-existent http page need it's own 404? Wouldn't a static 404 response be just fine?