Why Static Websites Need HTTPS

Re:Why Static Websites Need HTTPS by dragonwriter on Tuesday August 28, 2018 @08:49AM (#17858378)

How is the same origin policy helping when the attacker is impersonating your domain to the target?

[ Parent | on HN ]

Re:Why Static Websites Need HTTPS by austincheney on Tuesday August 28, 2018 @02:52PM (#17861715)

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.

[ Parent | on HN ]

Re:Why Static Websites Need HTTPS by Klathmon on Wednesday August 29, 2018 @09:05AM (#17867884)

DNS cache poisoning happens at a surprising rate. I had Verizon FIOS's DNS serve the wrong IP address for "www.google-analytics.com" before, for over 6 hours. The IP they returned for that hostname was located in Isreal, and was serving up malware in the analytics.js script on any page that included it.

Luckily www.google-analytics.com is HSTS preloaded, and the cert the attacker served wasn't signed, so the request was blocked.

But now imagine that instead of doing that to www.google-analytics.com, they did it to yoursite.com, but you don't have HTTPS enabled, so they are free to send whatever scrips they want to your users, return whatever data they want to their server (which the users's computer thinks is yoursite.com), and can even do a 301 redirect to their own domain after the initial attack to make sure they can keep unsuspecting victims under their control for long after their DNS cache poisoning gets fixed.

[ Parent | on HN ]

Re:Why Static Websites Need HTTPS by icebraining on Tuesday August 28, 2018 @06:54PM (#17863641)

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.

[ Parent | on HN ]

Re:Why Static Websites Need HTTPS by austincheney on Tuesday August 28, 2018 @07:40PM (#17863923)

ARP cache poisoning occurs at the switch not the router. It is an awesome form of attack, but access to the switch and the availability of that compromise are limited in scope. A single switch can only have so many machines connected even with VLANs. It also requires access from within the local LAN.

I really don't think anybody is thinking of ARP poisoning when all these comments here mention public facing MiTM attacks merely because a page is served with HTTP instead of HTTPS. Since ARP is only layer 3 it really doesn't care if the page is sent via HTTPS and works the same either way.

[ Parent | on HN ]

Re:Why Static Websites Need HTTPS by icebraining on Tuesday August 28, 2018 @08:07PM (#17864033)

ARP poisoning is just an example of a very simple and easy attack that can affect anyone that ever uses a public hotspot - on a cafe, university, workplace, etc.

Another possibility - compromising home routers: https://arstechnica.com/information-technology/2018/05/hacke...

Other possible attacks would be to compromise an internal router at an office (affecting everyone up to the CEO), controlling a VPN or Tor exit node, etc.

None of these give you the possibility of creating your own cert, but they do give you enough MITM access to fully compromise an HTTP site.

Since ARP is only layer 3 it really doesn't care if the page is sent via HTTPS and works the same either way.

The attack works in the sense that the traffic starts flowing through the attacker's machine, but the attacker is still prevented from changing anything in the page. That's the whole point of SSL/TLS.

[ Parent | on HN ]