8 ms·

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

by 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?
  - marshray 14y ago
    It was meant to be a jab at DNSSEC, so yeah it's probably nonsensical if you try to read it as a real HTTP proposal.
astrodust 14y ago
If TLS could negotiate certificates instead of supporting one and only one, the backbone of any sane "virtual host" system, then https: wouldn't be a big deal. It'd be the default. Now you need a separate IP (expensive) or port (annoying) for each virtual host configured with a different SSL cert. This has to stop, but it will not be easy to fix.
- rwg 14y ago
  RFC 3546, which includes TLS Server Name Indication, has existed since June 2003. The problem preventing deployment is the lack of client support, especially Internet Explorer on Windows XP and Android 2.x [1]. -- 1. http://en.wikipedia.org/wiki/Server_Name_Indication#No_support http://en.wikipedia.org/wiki/Server_Name_Indication#No_suppo...
- deleted 14y ago
  [deleted]
daxelrod 14y ago
> 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. How would they do this without triggering certificate warnings? Or are you simply saying that everyone ignores certificate warnings?
- joshAg 14y ago
  "You're almost done setting up your internet connection! For your security, please add our CA to your computer. This handy-dandy program that you can download from our website or from a usb stick our installer has with him/her will automatically do this for you. At ShitISP we care about your cyber safety. In order to prevent viruses and other Bad Things from infecting your computer and the other computers on our network, you will be unable to do some things on the internet until you install our certificate. Thank you for helping us keep your computer and our network safe!"
marshray 14y ago
> adds extra unneeded overhead by encrypting everything Baloney. :-) Or rather, please cite something in the last 5 years showing that the overhead of the symmetric encryption is a significant cost in HTTPS.
- joshAg 14y ago
  assuming you just want to browse websites and not transfer information that needs to be private, the extra rtt for establishing the ssl connection is the uneeeded overhead. for something like streaming a movie, that won't matter because the ssl connection will be long lived. for something like web browsing, where most websites require a new tcp connection for each GET, ssl is painful. sure, the extra rtt is preferable to javascript injection, but signing the webpage is sufficient to prevent javascript injection and it wouldn't add extra rtt delay (aside from fetching a cert in the trust chain, which https can also suffer from in the exact same way). depending on the algorithms used, on-the-fly signing of dynamic pages might be (read: almost certainly is) more painful than ssl/tls in terms of computation time, but to the user would still be quicker for most cases than the rtt delay added by ssl/tls.
  - marshray 14y ago
    Note that the primary HTML resource for most web pages takes multiple roundtrips to transmit completely. If you sign it only at the end, you've made the browser feel slower. So you'd have to avoid the RTT by accepting, processing, and presenting the data immediately but only later authenticating it retroactively. The bad guy can just drop or delay the legitimate signature. This is inherently error-prone. It gives the developers a big, convenient, and reassuring assumption which the attacker is able to violate. For a complex and evolving endpoint like a web browser, I don't think you'd ever see the end of security bugs. More: https://www.ietf.org/mail-archive/web/tls/current/msg04017.html https://www.ietf.org/mail-archive/web/tls/current/msg04017.h... Furthermore, retroactive authentication still doesn't preclude the encryption: https://www.ietf.org/mail-archive/web/tls/current/msg08722.html https://www.ietf.org/mail-archive/web/tls/current/msg08722.h...
    - 14y ago
richardwhiuk 14y ago
If the ISP can MITM the HTTPS connection (hint: they can't because they can't provide a valid certificate which matches the domain which has been signed by a trusted CA), they can MITM any signing system you may come up with. Google has already provided statistics showing that HTTPS adds a negligible amount of CPU load to servers (and most websites aren't CPU bound anyway).

by joshAg 14y ago

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?
- marshray 14y ago
  It was meant to be a jab at DNSSEC, so yeah it's probably nonsensical if you try to read it as a real HTTP proposal.

astrodust 14y ago

If TLS could negotiate certificates instead of supporting one and only one, the backbone of any sane "virtual host" system, then https: wouldn't be a big deal. It'd be the default. Now you need a separate IP (expensive) or port (annoying) for each virtual host configured with a different SSL cert. This has to stop, but it will not be easy to fix.

rwg 14y ago
RFC 3546, which includes TLS Server Name Indication, has existed since June 2003. The problem preventing deployment is the lack of client support, especially Internet Explorer on Windows XP and Android 2.x [1]. -- 1. http://en.wikipedia.org/wiki/Server_Name_Indication#No_support http://en.wikipedia.org/wiki/Server_Name_Indication#No_suppo...
deleted 14y ago
[deleted]

daxelrod 14y ago

> 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. How would they do this without triggering certificate warnings? Or are you simply saying that everyone ignores certificate warnings?

joshAg 14y ago
"You're almost done setting up your internet connection! For your security, please add our CA to your computer. This handy-dandy program that you can download from our website or from a usb stick our installer has with him/her will automatically do this for you. At ShitISP we care about your cyber safety. In order to prevent viruses and other Bad Things from infecting your computer and the other computers on our network, you will be unable to do some things on the internet until you install our certificate. Thank you for helping us keep your computer and our network safe!"

marshray 14y ago

> adds extra unneeded overhead by encrypting everything Baloney. :-) Or rather, please cite something in the last 5 years showing that the overhead of the symmetric encryption is a significant cost in HTTPS.

joshAg 14y ago
assuming you just want to browse websites and not transfer information that needs to be private, the extra rtt for establishing the ssl connection is the uneeeded overhead. for something like streaming a movie, that won't matter because the ssl connection will be long lived. for something like web browsing, where most websites require a new tcp connection for each GET, ssl is painful. sure, the extra rtt is preferable to javascript injection, but signing the webpage is sufficient to prevent javascript injection and it wouldn't add extra rtt delay (aside from fetching a cert in the trust chain, which https can also suffer from in the exact same way). depending on the algorithms used, on-the-fly signing of dynamic pages might be (read: almost certainly is) more painful than ssl/tls in terms of computation time, but to the user would still be quicker for most cases than the rtt delay added by ssl/tls.
- marshray 14y ago
  Note that the primary HTML resource for most web pages takes multiple roundtrips to transmit completely. If you sign it only at the end, you've made the browser feel slower. So you'd have to avoid the RTT by accepting, processing, and presenting the data immediately but only later authenticating it retroactively. The bad guy can just drop or delay the legitimate signature. This is inherently error-prone. It gives the developers a big, convenient, and reassuring assumption which the attacker is able to violate. For a complex and evolving endpoint like a web browser, I don't think you'd ever see the end of security bugs. More: https://www.ietf.org/mail-archive/web/tls/current/msg04017.html https://www.ietf.org/mail-archive/web/tls/current/msg04017.h... Furthermore, retroactive authentication still doesn't preclude the encryption: https://www.ietf.org/mail-archive/web/tls/current/msg08722.html https://www.ietf.org/mail-archive/web/tls/current/msg08722.h...
  - 14y ago

richardwhiuk 14y ago

If the ISP can MITM the HTTPS connection (hint: they can't because they can't provide a valid certificate which matches the domain which has been signed by a trusted CA), they can MITM any signing system you may come up with. Google has already provided statistics showing that HTTPS adds a negligible amount of CPU load to servers (and most websites aren't CPU bound anyway).