3 ms·

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

by ve55 8y ago

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 many would break), but I view things like "If you've a sub-site that you never got round to securing (e.g. http://blog.example.com http://blog.example.com), then you've just forced yourself to upgrade with this policy." as a positive, not a negative (hence the word 'upgrade').

Boulth 8y ago
HPKP as people know it is being withdrawn from browsers so there is no need to discuss it further. Source: https://chromestatus.com/feature/5903385005916160 https://chromestatus.com/feature/5903385005916160
ficklepickle 8y ago
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:// https://. Including the page with polling location information. So any malicious actor in a privileged position, like a public WiFi network operator, could have effectively prevented people from getting accurate poll location information, effectively DoSing prospective voters. I tried to bring this to their attention, but I got a response telling me their IT guy says it's not a problem because no user data is submitted on those pages. Never mind that it was probably more work to selectively enable TLS per URL and leaves important content vulnerable to manipulation. Incredible! It's like the old "all of our download links use HTTPS", but the downloads page is served unencrypted. Frustrating.
- sildur 8y ago
  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.
  - DenseComet 8y ago
    Elliptical curve based keys are now supported by all major browsers and require much less processing power and overhead compared to traditional RSA keys.
- lisper 8y ago
  > 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/ http://flownet.com/ron/ Why should I use TLS for that?
  - mlazowik 8y ago
    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-bsnl-india-is-injecting-ads-using-phozeca-which-spoils-websites-and-mak https://security.stackexchange.com/questions/157828/my-isp-b... https://thenextweb.com/insights/2017/12/11/comcast-continues-to-inject-its-own-code-into-websites-you-visit/ https://thenextweb.com/insights/2017/12/11/comcast-continues...
nijave 8y ago
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)
- jeroenhd 8y ago
  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.
  - ianlevesque 8y ago
    Your employer doesn’t just preload a root cert and use a middlebox to log everything anyway?
    - tialaramex 8y ago
      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.

by ve55 8y ago

Boulth 8y ago

HPKP as people know it is being withdrawn from browsers so there is no need to discuss it further. Source: https://chromestatus.com/feature/5903385005916160 https://chromestatus.com/feature/5903385005916160

ficklepickle 8y ago

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:// https://. Including the page with polling location information. So any malicious actor in a privileged position, like a public WiFi network operator, could have effectively prevented people from getting accurate poll location information, effectively DoSing prospective voters. I tried to bring this to their attention, but I got a response telling me their IT guy says it's not a problem because no user data is submitted on those pages. Never mind that it was probably more work to selectively enable TLS per URL and leaves important content vulnerable to manipulation. Incredible! It's like the old "all of our download links use HTTPS", but the downloads page is served unencrypted. Frustrating.

sildur 8y ago
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.
- DenseComet 8y ago
  Elliptical curve based keys are now supported by all major browsers and require much less processing power and overhead compared to traditional RSA keys.
lisper 8y ago
> 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/ http://flownet.com/ron/ Why should I use TLS for that?
- mlazowik 8y ago
  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-bsnl-india-is-injecting-ads-using-phozeca-which-spoils-websites-and-mak https://security.stackexchange.com/questions/157828/my-isp-b... https://thenextweb.com/insights/2017/12/11/comcast-continues-to-inject-its-own-code-into-websites-you-visit/ https://thenextweb.com/insights/2017/12/11/comcast-continues...

nijave 8y ago

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)

jeroenhd 8y ago
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.
- ianlevesque 8y ago
  Your employer doesn’t just preload a root cert and use a middlebox to log everything anyway?
  - tialaramex 8y ago
    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.