This article is probably much more harmful than the security features it describes as dangerous...
Dangerous Web Security Features
21–30 of 42 posts
Re: Dangerous Web Security Features
#22Disagree with HSTS being 'dangerous' in 2019. There are not really any good excuses left to have any parts of your website (new/different subdomains included) unable to use https. On the other hand, HPKP is a lot easier to mess up and is more situational, but HSTS should be standard by now. The author's recommendations are still good (If everyone tried to set up strict HPKP+CSP on their websites, I can imagine how ma…
Caching. If Netflix wants to let company or University x cache their shows, they can just distribute over http encrypted blocks of content. Same with package distribution (although these are usually verified via signing)
SXG would allow that without breaking security: https://wicg.github.io/webpackage/draft-yasskin-http-origin-...
And Netflix and similar already handle caching in a much better way: they effectively hand CDN nodes to ISPs, and then direct requests specifically to the right CDN.
Re: Dangerous Web Security Features
#23Earlier quoted context omitted.
Your employer doesn’t just preload a root cert and use a middlebox to log everything anyway?
Actually doing this costs $$$ (and is probably less useful than many people think it will be) Most employers are always looking for opportunities to cut costs, and so the $$ product that is superficially similar gets chosen not the $$$ product that will "log everything". The $$$ solution is to literally MITM every TLS session. Build two session, one in which you pretend to be the server, one in which you pretend to b…
My employer MITMs all content using the first approach. I don't think they have the storage to log all content, certainly not all downloads, but they do scan it for DLP, e.g., uploading stuff that looks like source code. It seems genuinely useful for things like preventing accidental pushes to GitHub (which is a thing I've seen happen multiple times).
Also, my employer provides a guest wifi for personal devices that doesn't do MITMing at all, and if for some reason I were watching Netflix at work, I'd presumably watch it on a personal device anyway. (Even if I was projecting to a conference room at work, I'd still plug in a personal device to the projector.)
Re: Dangerous Web Security Features
#24I still very strongly oppose HSTS's "No user recourse" policy, and don't deploy it on my sites purely for that reason. I get the reasoning, but it's still unethical to the user. (as an aside, hsts applies to all ports with no option to disable this, something to keep in mind.)
How is it unethical to protect your users from MITM attacks?
Why would any end user need “recourse” to connect to your server incorrectly?
If you’re no longer serving content over HTTP anyway, what opportunity is lost?
Re: Dangerous Web Security Features
#25Disagree with HSTS being 'dangerous' in 2019. There are not really any good excuses left to have any parts of your website (new/different subdomains included) unable to use https. On the other hand, HPKP is a lot easier to mess up and is more situational, but HSTS should be standard by now. The author's recommendations are still good (If everyone tried to set up strict HPKP+CSP on their websites, I can imagine how ma…
I definitely agree there's no excuse not to use TLS anymore. I recently ran into this on a city of Vancouver website for voting information. While any page that had a form used HTTPS, all other pages forced the user to use HTTP. Like, for those pages, it redirected to unencrypted even if you typed in https:// . Including the page with polling location information. So any malicious actor in a privileged position, like…
Maybe all they can afford is a really old or weak server machine, and are afraid of the extra computational power that enabling https on all pages would incur.
Re: Dangerous Web Security Features
#26I still very strongly oppose HSTS's "No user recourse" policy, and don't deploy it on my sites purely for that reason. I get the reasoning, but it's still unethical to the user. (as an aside, hsts applies to all ports with no option to disable this, something to keep in mind.)
How is it unethical to protect your users from MITM attacks? Why would any end user need “recourse” to connect to your server incorrectly? If you’re no longer serving content over HTTP anyway, what opportunity is lost?
I'm not an end user, and I should have the ability to bypass expired/invalid cert errors on both my own sites, as well any other site out of curiosity. Sure, lock it behind a flag or other hidden setting, that even covers enterprise clients because they already disable setting those on their domain computers, but it should be possible nonetheless to bypass the error.
Re: Dangerous Web Security Features
#27Disagree with HSTS being 'dangerous' in 2019. There are not really any good excuses left to have any parts of your website (new/different subdomains included) unable to use https. On the other hand, HPKP is a lot easier to mess up and is more situational, but HSTS should be standard by now. The author's recommendations are still good (If everyone tried to set up strict HPKP+CSP on their websites, I can imagine how ma…
I definitely agree there's no excuse not to use TLS anymore. I recently ran into this on a city of Vancouver website for voting information. While any page that had a form used HTTPS, all other pages forced the user to use HTTP. Like, for those pages, it redirected to unencrypted even if you typed in https:// . Including the page with polling location information. So any malicious actor in a privileged position, like…
> there's no excuse not to use TLS anymore
I have a personal site that consists entirely of low-value static assets:
Why should I use TLS for that?
Re: Dangerous Web Security Features
#28Earlier quoted context omitted.
I definitely agree there's no excuse not to use TLS anymore. I recently ran into this on a city of Vancouver website for voting information. While any page that had a form used HTTPS, all other pages forced the user to use HTTP. Like, for those pages, it redirected to unencrypted even if you typed in https:// . Including the page with polling location information. So any malicious actor in a privileged position, like…
> there's no excuse not to use TLS anymore I have a personal site that consists entirely of low-value static assets: http://flownet.com/ron/ Why should I use TLS for that?
Anyone on the path between your server and clients can change the content however they want. Inject ads, mining scripts, redirect
to a phishing website, try to push a virus to your client etc.
There are even ISPs that do that: https://security.stackexchange.com/questions/157828/my-isp-b...
https://thenextweb.com/insights/2017/12/11/comcast-continues...
Re: Dangerous Web Security Features
#29I still very strongly oppose HSTS's "No user recourse" policy, and don't deploy it on my sites purely for that reason. I get the reasoning, but it's still unethical to the user. (as an aside, hsts applies to all ports with no option to disable this, something to keep in mind.)
I agree with you. That is also why I hate HSTS and will not use it. The user must be given permission to override (for any reason they want to, including one you don't know) anything, and must have enough ropes to hang yourself and also a few more just in case.
HSTS is terrible, even if you support HTTPS (which you probably should).
Re: Dangerous Web Security Features
#30As others have pointed out, this post is from 2015 and a lot has changed since then. I've added an updated section at the end, to clarify my thoughts since then (mostly unchanged to be honest, except for CSP): https://www.tunetheweb.com/blog/dangerous-web-security-featu...