-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a FAQ answer about why HSTS is needed even when port 80 is off #248
Conversation
Is it worth mentioning the additional benefit that (for browsers which support HSTS), this will keep |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made a small suggestion, but this is good addition 👍
pages/guide.md
Outdated
@@ -100,6 +101,16 @@ Note that while connections to port 80 are insecure, even for redirects, the use | |||
|
|||
HSTS mitigates the security impact of connections over port 80, while allowing agencies the flexibility to continue redirecting legacy clients or clients which have not yet received an HSTS policy for the target domain. | |||
|
|||
### If I turn off plain HTTP on my server entirely, do I still need HSTS? | |||
|
|||
**Yes.** Turning off HTTP support is not sufficient to prevent attacks that downgrade web browsers to plain HTTP. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider something that addresses the case when a device only supports HTTPS (i.e., there's nothing to "turn off"):
"Turning off HTTP support (or only supporting HTTPS) is not sufficient...
When this lands, I'm likely to link to this answer in the BOD 18-01 FAQ item related to this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@h-m-f-t Good point. I just added a commit which rephrases this to disabled
instead of turned off
.
@alex That's a good point, though I think I'd like to see it made elsewhere (the HSTS page?) rather than here - for this FAQ answer, I don't want to distract from the core argument (as agencies and vendors do sometimes actively contest it). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nicely done.
|
||
During an attack, it doesn't matter whether the "real" server has disabled HTTP. If the client can be coaxed into initiating a plain HTTP connection -- such as when a user clicks an `http://` link, or types a URL into their browser manually -- then a local attacker can respond to that connection attempt from their own server and establish their own connection. | ||
|
||
HSTS specifically instructs web browsers to never initiate plain HTTP connections. If a user clicks an `http://` or types in an `http://` URL, HSTS causes the browser to first rewrite the URL to use `https://` before initiating the connection. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@konklone -- Should this read: "If a user clicks an http://
link or ..." ?
Great summary of the pertinent considerations from the client perspective and related local attack vectors! These are often overlooked when thinking about the relevant server configurations, hence the F of this AQ 😄 |
In response to some inquiries from agencies, this clarifies that HSTS is needed even when HTTP (typically port 80) is disabled, to prevent downgrade attacks.