6 ms·

Using HSTS on a website will generally prevent your browser from allowing you to continue, which is fair: the website owner has explicitly indicated the website

Using HSTS on a website will generally prevent your browser from allowing you to continue, which is fair: the website owner has explicitly indicated the website should only ever be used over a encrypted connection, and that is not the case..

paulddraper 10y ago
I understand who owns the website. Who owns my browser?
- AtheistOfFail 10y ago
  The manufacturer.
- snug 10y ago
  To be RFC compliant, it MUST NOT allow the user to ignore the errors. 12.1. No User Recourse Failing secure connection establishment on any warnings or errors (per Section 8.4 ("Errors in Secure Transport Establishment")) should be done with "no user recourse". This means that the user should not be presented with a dialog giving her the option to proceed. Rather, it should be treated similarly to a server error where there is nothing further the user can do with respect to interacting with the target web application, other than wait and retry. Essentially, "any warnings or errors" means anything that would cause the UA implementation to announce to the user that something is not entirely correct with the connection establishment. Not doing this, i.e., allowing user recourse such as "clicking through warning/error dialogs", is a recipe for a man-in-the-middle attack. If a web application issues an HSTS Policy, then it is implicitly opting into the "no user recourse" approach, whereby all certificate errors or warnings cause a connection termination, with no chance to "fool" users into making the wrong decision and compromising themselves. https://tools.ietf.org/html/rfc6797#section-12.1 https://tools.ietf.org/html/rfc6797#section-12.1
  - paulddraper 10y ago
    Well I suppose curl/wget will never be RFC compliant user agents (curl -k, wget --no-check-certificate). But somehow I think they'll still be used...
    - aaronmdjones 10y ago
      wget writes a ~/.wget-hsts file with the HSTS information for any URI you have accessed that served an HSTS header. Making it ignore --no-check-certificate if the file has an entry for the hostname you are visiting should be trivial, if it hasn't been done already.
      - paulddraper 10y ago
        Exactly.
  - deleted 10y ago
    [deleted]
- click170 10y ago
  You can configure most major browsers to forget HSTS entries they already know about, so to the question of who owns your browser wrt honoring HSTS, I'd say it's the user. http://classically.me/blogs/how-clear-hsts-settings-major-browsers http://classically.me/blogs/how-clear-hsts-settings-major-br... Though now I'm curious if Chrome can be configured to forget HSTS for Google sites.
  - snug 10y ago
    I'm not 100% certain, but is that to just delete the HSTS Header that is saved into the browser?

paulddraper 10y ago

I understand who owns the website. Who owns my browser?

AtheistOfFail 10y ago
The manufacturer.
snug 10y ago
To be RFC compliant, it MUST NOT allow the user to ignore the errors. 12.1. No User Recourse Failing secure connection establishment on any warnings or errors (per Section 8.4 ("Errors in Secure Transport Establishment")) should be done with "no user recourse". This means that the user should not be presented with a dialog giving her the option to proceed. Rather, it should be treated similarly to a server error where there is nothing further the user can do with respect to interacting with the target web application, other than wait and retry. Essentially, "any warnings or errors" means anything that would cause the UA implementation to announce to the user that something is not entirely correct with the connection establishment. Not doing this, i.e., allowing user recourse such as "clicking through warning/error dialogs", is a recipe for a man-in-the-middle attack. If a web application issues an HSTS Policy, then it is implicitly opting into the "no user recourse" approach, whereby all certificate errors or warnings cause a connection termination, with no chance to "fool" users into making the wrong decision and compromising themselves. https://tools.ietf.org/html/rfc6797#section-12.1 https://tools.ietf.org/html/rfc6797#section-12.1
- paulddraper 10y ago
  Well I suppose curl/wget will never be RFC compliant user agents (curl -k, wget --no-check-certificate). But somehow I think they'll still be used...
  - aaronmdjones 10y ago
    wget writes a ~/.wget-hsts file with the HSTS information for any URI you have accessed that served an HSTS header. Making it ignore --no-check-certificate if the file has an entry for the hostname you are visiting should be trivial, if it hasn't been done already.
    - paulddraper 10y ago
      Exactly.
- deleted 10y ago
  [deleted]
click170 10y ago
You can configure most major browsers to forget HSTS entries they already know about, so to the question of who owns your browser wrt honoring HSTS, I'd say it's the user. http://classically.me/blogs/how-clear-hsts-settings-major-browsers http://classically.me/blogs/how-clear-hsts-settings-major-br... Though now I'm curious if Chrome can be configured to forget HSTS for Google sites.
- snug 10y ago
  I'm not 100% certain, but is that to just delete the HSTS Header that is saved into the browser?