6 ms·
HSTS from Top to Bottom
- faeyanpiraat 7y agoDo i remember correctly that Chrome wanted to deprecate HSTS about a year ago? What happened with that?
- recrudesce 7y agoYou're thinking of HPKP https://raymii.org/s/blog/Chrome_68_is_deprecating_HPKP.html https://raymii.org/s/blog/Chrome_68_is_deprecating_HPKP.html
- kadoban 7y agoWhich is a shame really. I understand why they're doing it, it's stressful as hell to configure, since if you do it really wrong you might as well just write off your domain name, but the extra assurance was nice.
- vbezhenar 7y agoIMO browsers should just use TLSA records instead. They already starting to use DoH, so DNS is secure even without DNSSEC.
- xorcist 7y agoIt's less bad, but far from secure seeing it is not end-to-end encrypted.
- vbezhenar 7y agoA simple solution is just to forbid http altogether. No properly encrypted HTTPS connection - no website, sorry (unless you downloaded some kind of firefox developer build). But we're not there yet.
- wielebny 7y agoNot only it is stressful to configure, it can be used to hold your domain at ransom.
- byuu 7y agoStill doesn't solve the first-request problem. When can we start using DNSSEC to help prevent DNS hijacking in the first place?
- shawnz 7y agoThe preload option is supposed to solve the first-request problem
- SahAssar 7y agoIt's not feasible to use preload on a wide scale. Do you think that every secure site should have to be included in the source of your browser to have security?
- Thorrez 7y agoEven without DNS hijacking, a MITM (such as a router) could still intercept your password.
- artursapek 7y agoIsn't DNSSEC supposed to prevent you from connecting to the wrong origin, presumably avoiding an unencrypted connection? A router can't intercept anything on an encrypted connection.
- Thorrez 7y agoDNSSEC ensures a hostname resolves to the right IP address. But when you make a TCP connection to that IP address, a MITM can listen in on (and modify) that TCP connection. Another problem is I believe DNSSEC is only validated by the recursive resolver. So if the end user is using an external recursive resolver (e.g. 8.8.8.8) then the data between the user and the recursive resolver can still be spoofed by a MITM, and also the recursive resolver itself could behave maliciously.
- teddyh 7y ago
- Terretta 7y agoFrom 2016: "95% of HTTPS servers vulnerable to trivial MITM attacks" https://news.netcraft.com/archives/2016/03/17/95-of-https-servers-vulnerable-to-trivial-mitm-attacks.html https://news.netcraft.com/archives/2016/03/17/95-of-https-se... HSTS making progress...
- yoloClin 7y agoThe article mentions preloading but doesn't go into detail. You can apply for Chrome preload via https://hstspreload.org/ https://hstspreload.org/ which I ends up in Chrome source, the list is then replicated to other browsers by their maintaniers. HSTS Preload will prevent initial-access downgrade attacks for clients using versions of browsers with your domain as a HSTS preload. The downside is preload removal is difficult and would take a fair while to propogate. Also another common misconception is disabling port 80 will remediate the issue - if an attacker can intercept and modify traffic they are able to open and redirect the port to a node under their control. https://letsencrypt.org/docs/allow-port-80/ https://letsencrypt.org/docs/allow-port-80/
- trpc 7y agoTroy Hunt is a really loud guy to an annoying level, and I am not even sure how much of a security expert he _really_ is. He's mostly making tons of money out of his bombastic posts