Live data from Hacker News

Dangerous Web Security Features

tunetheweb.com

11–20 of 42 posts

Re: Dangerous Web Security Features

#11
post #9
post #2

Disagree 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)

Netflix can't really be cached anyway because of DRM + rotating keys. You'd need to cache for every device (type/model) and get the big wigs from Hollywood to accept allowing data storage in caches everywhere.

Also, I don't want my employer to know what movies I'm watching. I'd personally opt out (or not use Netflix) if this became an option.

Re: Dangerous Web Security Features

#12

And then we come to the most dangerous item, because you have least control over it: preloading HSTS right into the browser. I can't say specifically why, but there's something about a browser that treats a certain list of sites specially, by default, that just doesn't sit well with me. I've had this feeling ever since I heard about the feature. Not exactly net neutrality, but somewhat reminds me of it.

Sounds similar to web browsers coming with their own CA certificates instead of using system-wide ones, leading to poor integration and inconsistencies. Though a centralized database of rules for websites sounds awkward on its own.

Re: Dangerous Web Security Features

#13
post #9

Earlier quoted context omitted.

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)

Netflix can't really be cached anyway because of DRM + rotating keys. You'd need to cache for every device (type/model) and get the big wigs from Hollywood to accept allowing data storage in caches everywhere. Also, I don't want my employer to know what movies I'm watching. I'd personally opt out (or not use Netflix) if this became an option.

Your employer doesn’t just preload a root cert and use a middlebox to log everything anyway?

Re: Dangerous Web Security Features

#14
post #10
post #6

Can we add minimum password complexity requirements to this list? There is nothing more annoying than having to adjust my already 128-bits of entropy password because the website feels I need a special character. Plus, now hackers have a guide for what the password looks like.

NIST 800-63b actually recommends against character class requirements[1] in favor of minimum length requirement and blacklists of breached passwords and other obvious passwords. Sites that require special characters are not following the current best practice. [1]: https://pages.nist.gov/800-63-3/sp800-63b.html

And who could even be made to care about password quality, when every level of the industry leaks plain text passwords like a rusty tugboat.

It's to the point that I put racial slurs in my passwords, hoping they show up in leak files and databases, in the hopes that it makes it more difficult to host and maintain such leaks.

Re: Dangerous Web Security Features

#15
I 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.)

Re: Dangerous Web Security Features

#16
post #9

Earlier quoted context omitted.

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)

Netflix can't really be cached anyway because of DRM + rotating keys. You'd need to cache for every device (type/model) and get the big wigs from Hollywood to accept allowing data storage in caches everywhere. Also, I don't want my employer to know what movies I'm watching. I'd personally opt out (or not use Netflix) if this became an option.

Well, I think Netflix has cache/edge servers that they deploy to ISPs instead. That said, last I looked at it, the model described (keys through https, enc. chunks through http) was used by BAMTech for example.

Re: Dangerous Web Security Features

#17
> The impact of an incorrect CSP policy, or browser issue could vary from a "Tweet This" button not loading (no big deal), to ads not loading (hurting your income), to stylesheets not loading (basically your whole website is broken).

I really don't like the sentiment that you shouldn't add a security feature because it might be difficult. Any change comes with risk of regression, but CSP isn't even domain-level like the other ones, it only affects the resources it's attached to. It shouldn't be any scarier than making any other change to your site/app.

Replace with 'the impact of replacing your md5-ed passwords with properly hashed ones... basically your whole website is broken'. Of course, that's a reductio ad absurdum in some cases, but if it protects you from XSS it might be a good analogy.

Re: Dangerous Web Security Features

#18
post #12

And then we come to the most dangerous item, because you have least control over it: preloading HSTS right into the browser. I can't say specifically why, but there's something about a browser that treats a certain list of sites specially, by default, that just doesn't sit well with me. I've had this feeling ever since I heard about the feature. Not exactly net neutrality, but somewhat reminds me of it.

Sounds similar to web browsers coming with their own CA certificates instead of using system-wide ones, leading to poor integration and inconsistencies. Though a centralized database of rules for websites sounds awkward on its own.

> Sounds similar to web browsers coming with their own CA certificates instead of using system-wide ones, leading to poor integration and inconsistencies.

Well, the only notable browser which does this is Mozilla's Firefox, and not coincidentally the only root trust store where you can actually see how the sausage is made is Mozilla's. All the other big trust stores (Apple, Microsoft, Google) are black boxes. Presumably they have one or more employees dedicated to this stuff, but since we're not shown their working it might equally be the product of an intern throwing darts at a list.

Right now for example Mozilla is discussing Certinomis, a small CA which doesn't seem to be very good at the technical aspects of their job, issuing certificates for DNS names with spaces in them, typo'ing dates, filling parameters out incorrectly, nothing that screams "evil" but certainly more clumsy than we'd prefer. Are other trust stores thinking about Certinomis? You'll only find out if one of them announces a change.

Re: Dangerous Web Security Features

#19

Earlier quoted context omitted.

Netflix can't really be cached anyway because of DRM + rotating keys. You'd need to cache for every device (type/model) and get the big wigs from Hollywood to accept allowing data storage in caches everywhere. Also, I don't want my employer to know what movies I'm watching. I'd personally opt out (or not use Netflix) if this became an option.

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 be the client, and log everything as you copy it from one to the other. You need a fair amount of horsepower (CPU or specialist ASIC) and somewhere to keep all those logs, neither is cheap.

The $$ solution may have the option to resort to that, but it will lack the horsepower to do it at line rate, (e.g. you may have an appliance on a 100Mbps network that can't do this faster than 5Mbps) or the storage to log at line rate (at 100Mbps that's about 1TB per day) so unless you're being tracked specifically it's probably only doing this:

1. When you makes a new TLS session it stalls you, to see who the far end is, until TLS 1.2 they'll present their certificate in plain text, so the middlebox can read it without needing to actually MITM you. Unless the target is blocked you're allowed through, and probably not logged to save storage.

2. When a session resumption happens, the middlebox has no idea who you're talking to, but it presumes that you must be talking to someone it previously allowed, so, it makes sense to just allow this and not inspect it beyond maybe noting which IP you connected to and when.

There are a lot of ways to screw this up that destroy security, but that's the nature of cheap security appliances, you pay money, you feel better, you probably don't get any actual security.

This all gets even more amusing for TLS 1.3, notice how in bullet point 2 these boxes let through all resumptions? TLS 1.3 deliberately looks exactly like a TLS 1.2 session resumption except with a "Ssh! This is actually TLS 1.3" marker so that a TLS 1.3 server knows what's really going on. For plenty of people TLS 1.3 "just worked" because their "security" appliance doesn't actually deliver any security.

Re: Dangerous Web Security Features

#20

And then we come to the most dangerous item, because you have least control over it: preloading HSTS right into the browser. I can't say specifically why, but there's something about a browser that treats a certain list of sites specially, by default, that just doesn't sit well with me. I've had this feeling ever since I heard about the feature. Not exactly net neutrality, but somewhat reminds me of it.

Really, this solution is because the inverse would be to extreme. We cannot say "https by default" except for this list. So instead we go with a list of https only. Really though, most traffic should move to https.

Moreover, this solves a real problem. We want sites like paypal, facebook, and gmail to really demand HTTPS. There should not be a race to MitM fresh browser installs.

Post reply on HN