Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Static Websites Need HTTPS

troyhunt.com

Post reply on HN
Print view View original

211–220 of 268 posts

Re: Why Static Websites Need HTTPS

#211

Post by icebraining »

austincheney wrote: post #161
bn-usd-mistake wrote: post #25

Earlier quoted context omitted.

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

CORS allows a site to bypass same origin policy according to a whitelist specified in the corresponding HTTP header. The setup on evil.com is irrelevant. CORS must be instantiated from the server sending the page. https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

No. From your link: "Note that in the CORS architecture, the ACAO header is being set by the external web service (service.example.com), not the original web application server (www.example.com). CORS allows the external web service to authorise the web application to use its services and does not control external services accessed by the web application."

Re: Why Static Websites Need HTTPS

#212

Post by icebraining »

tialaramex wrote: post #87
skuzye wrote: post #3

Earlier quoted context omitted.

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.

There's a corner case where, surprisingly, your parent's point kinda works, SRI: https://developer.mozilla.org/en-US/docs/Web/Security/Subres... If a site exists just to host resources protected with SRI then you can in principle use HTTP, the resource integrity protection will fire and so long as the main page's origin was genuine (e.g. protected with HTTPS) you come out OK... But SRI isn't even implemented at all i…

Right, but you still need HTTPS for the main domain.

Re: Why Static Websites Need HTTPS

#213

Post by tialaramex »

parliament32 wrote: post #201
nofunsir wrote: post #100

Earlier quoted context omitted.

Do we have conclusive evidence yet that LE is not a honey pot? I mean, if I were the NSA...

It's a valid question, with two possible threat models: 1) the honeypot uses your private keys to MITM connections Let's Encrypt doesn't handle your private keys. You generate them yourself, and submit a CRL to LE to get a cert issued. They have no knowledge of your private key. 2) the honeypot issues fake certs Let's Encrypt submits a log of every cert issued, see https://crt.sh/ . To verify, it'd be pretty trivial…

For CT the finished system involves browsers checking that the server can prove its certificates were logged (the ones you get from Let's Encrypt have such proof embedded) and periodically talking to Log Monitors (e.g. owned by your browser vendor) about proofs it has seen.

If somebody has seen a proof that is contradicted by the published log state this means the Logs involved are corrupt. If an otherwise authentic cert is shown without proofs or those proofs are bogus the cert may have been unlogged for nefarious reasons, it shouldn't be accepted and needs reporting

Chrome has the start of this, it checks for the proofs. Firefox is getting roughly the same feature "soon". But the finished system with all bells and whistles is probably a year or five away.

Good news is that even unfinished CT has been very effective.

Re: Why Static Websites Need HTTPS

#214

Post by yobw »

People love to play the games on Roblox because of their quality and creativity. This has been serving the players for more than a decade. You can continue to play games on Roblox platform until you have the Robux cash with you. As you have learned the hacking methods, you might be able to play the games as much as you want. Enjoy Playing!!

http://robuxcodes.ml

Re: Why Static Websites Need HTTPS

#217

Post by gerdesj »

nanoscopic wrote: post #193

I admin a number of different websites. The majority of them are static. I have forced https redirect on some of them. On others I do not. The only benefit of https I perceive in the case of static public content is that ISPs cannot easily monitor which specific pages on my domains are being visited. With plain http they could. I don't particularly care if people get MITM'ed when visiting my static sites. If they did…

I don't particularly care if people get MITM'ed when visiting my static sites.

Re: Why Static Websites Need HTTPS

#218

Post by 3pt14159 »

SahAssar wrote: post #179
3pt14159 wrote: post #125

Earlier quoted context omitted.

It is good, but it is annoying that it came out before we were able to properly lock down domains to cert authorities via DNS. It used to be that a malactor had to buy a new cert when they owned part of your backend if they weren't able to get your private keys. Now they can just use Let's Encrypt.

IIRC Let's Encrypt are more strict in their validation (HTTP, DNS and SNI) than the least onerous authorities before them. The difference is that they are automated and free, but I don't think that I can get any cert I couldn't get before (either for payment or free).

No you are not correct and I've been downloaded by people that don't know the history of DNS Certification Authority Authorization (CAA), which became required in 2017.

Let's Encrypt launched 2016, which meant that unless you were doing HPKP with long pin times and had traffic that already had hit your endpoint, if someone was on your gear (but lacked your private key) they could impersonate you for free and with no messing around with stolen credit cards to CAs.

To verify for Let's Encrypt—contrary to what you recall—all you are required to prove is that you can set a specific value at a path for the domain you are responsible for.

DNS verification is an option; but few use it.

Let's Encrypt has meaningfully reduced the barrier for certificate forgery. Every startup should set CAA headers now, but few do. It's still good that Let's Encrypt exist but it has its drawbacks.

Re: Why Static Websites Need HTTPS

#219

Post by 3pt14159 »

schoen wrote: post #172
3pt14159 wrote: post #125

Earlier quoted context omitted.

It is good, but it is annoying that it came out before we were able to properly lock down domains to cert authorities via DNS. It used to be that a malactor had to buy a new cert when they owned part of your backend if they weren't able to get your private keys. Now they can just use Let's Encrypt.

Can you clarify what restrictions you'd like to see in place? I didn't quite follow this, but if you can describe what you want to see, I might be able to describe a way to do it or request that it be created.

It's fine now, following CAA records is now mandatory, but prior to 2017 we didn't and even now most websites don't use it. CAA should be mandatory in a Let's Encrypted world because it's now trivial to create a HTTPS cert. It no longer requires stolen credit card details.

Re: Why Static Websites Need HTTPS

#220

Post by austincheney »

icebraining wrote: post #207
austincheney wrote: post #148

Earlier quoted context omitted.

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 HTT…

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 domai…

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.

Post reply on HN