Hot answers tagged

36

Yes, HSTS is still needed, including HSTS preload. The way a browser connects to HTTP/2 is through a URL that looks exactly the same as the URL for HTTP/1, so it doesn't know that it must be HTTP/2 just from looking at the URL. It will try plain cleartext HTTP if it is given a http:// URL. In order for the browser to not try plain HTTP (and not be subject ...


28

Current situation It is true that, as of Oct 2020, Google does not have HSTS on google.com, but only on www.google.com, and performs redirection first to www and then to https://. Even if there was a HSTS header on google.com, the browser would not see it and be able to cache it. Only www.google.com is protected by HSTS. Best practices It is also recommended ...


7

It would be recommendable to have the HSTS header set on every HTTPS response, but this effectively provides the same level of security, because the HSTS policy is cached for the max-age seconds. It's defined that the lack of Strict-Transport-Security header doesn't cause deletion of the policy, but only settings a zero value for the max-age (RFC 6796 6.1.1, ...


7

It doesn't matter what your server does. For all we care it could even be down, and MITM attacks would still be possible. All it matters is what the client does. If your client makes insecure requests or accepts untrusted responses, then a MITM becomes possible. HSTS is used to make sure that your client only uses HTTPS to connect to your server, which means ...


6

Let's back up a bit because you are asking about details on the extreme ends of a technology stack and your question misses the mark and doesn't make sense. Wireshark just captures packets, so you could replace "Wireshark" in your question with "packet captures" TLS encrypts the HTTP payloads, so GET requests would be encrypted packet ...


5

and assuming no systems or components on that network are compromised ...and assuming that nobody who has access to the systems or the networks has any bad intentions and can be trusted with visibility of any data passing through the network....then no, it adds nothing. But those are very big assumptions.


4

The decisions made in RFC 6796, 8.1 are much easier to comprehend, if you imagine what would happen, if a HSTS header from an HTTP response was handled the same way as with HTTPS: The site is HTTP only, and accidentally adds a HSTS header. The browser would now be instructed to upgrade to HTTPS, but the site is not serving the HTTPS version at all, and ...


4

Suppose attacker tricks victim to click on link to your site, browser uses http, attacker in strong network position intercepts and sends malicious content and makes victim believe content came from your site. How would HSTS help? If the victim visited your site before, their browser has an HSTS "flag" for the domain, and clicking the link would make the ...


4

You should absolutely use Strict Transport Security even if you are not serving HTTP. HSTS is about more than requiring HTTPS when HTTP is also served (though that's a good reason by itself as it can rewrite insecure URLs if they were forgotten). It is also used to tell a browser that the content should be over TLS. This can help to defeat SSL-stripping ...


3

Packet capturing happens at the network level. Since the browser has to send out network packets to fetch a site for you, you can always capture the network packets. HSTS has no impact on this process at all. What HSTS does is help the browser decide whether or not it MUST use HTTPS instead of HTTP. If the browser decides to use HTTPS then of course the ...


3

First retrieving arbitrary non-existing resources like /test.xml isn't within normal operation of your site, and therefore the problem doesn't exist anymore after the browser has seen the HSTS header somewhere (or preloaded it), as it causes upgrade to HTTPS on hostname level (and domain level with includeSubDomains). Also, it doesn't make a huge difference ...


3

It does seem strange. Here are two scenarios to illustrate. Scenario One Maybe the browser settings may be such that assets are not loaded, e.g., a mobile device on mobile data, where assets might not be loaded to conserve bandwidth. Then you would be open to all the vulnerabilities that HSTS protects against. Scenario Two (This scenario edited after ...


3

But why would the DNS have to be secure to hold one more bit of information (whether the domain can support https--and ONLY https--or not)? A man-in-the-middle attack could modify the DNS responses to remove the bit saying that a site requires HTTPS. In the worst case, a malicious MiTM attack could make it seem that a website is insecure when it is ...


2

First off, it is apparently more complicated: A bit of testing reveals www.google.com will, apparently, only send the HSTS header if it sees a user agent string that indicates a modern browser. Without a user agent string, e.g. with curl -H https://www.google.com, you will not receive a HSTS header at all. In fact, the google search page will still work via ...


2

Preloading isn't as dangerous as you're making it sound. The only requirement for it to not break your site is that you have TLS working, and if TLS weren't working, then your site is unsafe anyway. The right answer is "just preload".


2

If the site sends the HSTS header in the HTTP response, than that is against the RFC. And the RFC also states, that you "SHOULD" 301 the client to HTTPS and I honestly don't see any reason not to.


1

The issue here is that you aren't providing an HTTPS-only site. An HTTPS-only site would literally not respond on port 80 at all. When someone accesses your site using HTTP, if you send a 301 and then use HSTS, that browser will literally never connect over HTTP again unless you clear the HSTS cache. This is still subject to an attack on the initial ...


1

Although non-normative, the browsers are generally following the well-reasoned User Agent Implementation Advices from RFC 6797, 12 for not letting the user to bypass the errors if there's a known HSTS policy in place. 12.1. No User Recourse Failing secure connection establishment on any warnings or errors (per Section 8.4 ("Errors in Secure Transport ...


1

Question 1: Yes, this is possible. The fact that the site is on the HSTS preload list only tells the browser that it should always connect to the site by https and not http. The HSTS preload list does not contain any information about the certificate itself. Question 2: No, because of the answer to question 1.


1

The HSTS header should be returned for every URI for it to be considered effective. This is because while the header is host wide (optionally including sub-domains), there's nothing to stop a user accessing a resource first which does not return a HSTS header (in your example /contact/nurses), and therefore being allowed to communicate with that URI ...


1

All HTTP(S) headers are just data that the server sends over the wire. It's literally just plain text, usually ASCII/UTF-8. The server can send whatever headers (or body) it is configured for in response to whatever request it receives. Although it is common to configure a server to send certain headers with every response, doing so is neither the only ...


1

HSTS does not contain any kind of fingerprint (that would be HPKP instead). It only says that the site has to be loaded with HTTPS and that the certificate has to be trusted directly, i.e. no bypass of warnings by the user should be allowed. Insofar HSTS does not prevent MITM if the attacker can use a valid certificate which was issued by a CA trusted by the ...


1

You are correct on both your first 2 points. As a protection against attacks such as SSLstrip, the HSTS header prevents an attacker from downgrading a connection from HTTPS to HTTP, as long as the attributes of the header are properly configured. Yes, so the HSTS header tells the browser to only access the web server over a secure connection, thereby ...


1

Essentially if you assume "no systems or components on that network are compromised" your in very deep water already. What if they get compromised? At the end of the day it comes down to your organization evaluating risk and the benefits of implementing the ways to mitigate the risk.


Only top voted, non community-wiki answers of a minimum length are eligible