-
-
Notifications
You must be signed in to change notification settings - Fork 629
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
Proposal: the application must belong/covered to the HSTS preload list (probably level 3) #1941
Comments
This is quite high effort for a relatively small benefit (basically the first website load per browser) Not sure I would want to mandate it. |
Just in case - it is valid only for one application context. HSTS preload covers a larger scope than just one application, it's more a company or organization-level guarantee, that everything goes over HTTPS. |
HSTS preload is specific to one registerable domain. It must be deployed on a domain-by-domain basis.
It is not organization wide when an organization manages multiple domains.
|
Oh well. My point is, that the company or organization can manage larger risks at once by adding an entire domain to the HSTS preload list. In my opinion, banks, governments, etc should have it set. Is it worth a requirement - I think a level 3 requirement would be reasonable, but I'm ok with a recommendation row as well.
It may also include TLD. |
I'm leaning towards a recommendation. Aside from anything else there is also the "bricking" risk if it is done unwisely. |
Opened #1952 |
I was thinking more about it and I'm leaning towards level 3 requirement, I think recommendation is not enough. From @tghosth
What I did not point out clearly, is that without HSTS preload it is possible to serve any HTTP service from the Same-Site scope with the critical application. This is a way more important vector to eliminate compared to the first HTTP request to the application. Let's say there is an application served from Does it change your mind, @tghosth ? |
This is very good information and new to me. Thank you Elar. I am with you on this.
|
@elarlang if I understand correctly, the main problem here is that the domain does not have HSTS with sub-domains set at https://bank.tld If it did have that (and the user was guaranteed to get there on first load), then your scenario would only work if the user had never been to https://bank.tld before. Is that correct? See for example that when you browse to https://www.stripe.com, the very first thing it does is redirect you to https://stripe.com which has an HSTS header |
The boolean answer is true, but it requires some context. For this "guaranteed redirect scenario" through the main domain, the But if you do so, then any given arguments against The main topic here is that it is easy to understand and implement if it is But @tghosth - just in case, you asked a question, but what was your point and message behind that? I was thinking about it more and actually, there is a good question, is it in the scope for the application, which is served from |
So this complexity makes me feel even more uncomfortable about mandating HSTS at the root tld level. The number of moving parts to implement HSTS and preload at the |
I agree, that effort can be huge for some legacy systems, when you have "mess in the house". At the same time, for new organisations and application, it must be cornerstone for building things. The price is clear - control over Same-Site scope. Then no-one can use trusted domain for phisnig (yes, it does not stop phising), no cookie manipulation for apps, no cookie leakage for apps (in case those are misconfigured with Also note, that we give similar direction with other requirement:
Me and you can theorize here further, but I think we need some additional views. Probably it's worth asking in social media, why big companies use or don't use the |
OK so I think these are our possible suggestions:
If I understand correctly, you support 2) and I am most incline to support a combination of 1) and 4). Do you agree with my interpretation? If so, I will try and get wider feedback. |
I think we have only 2 options - 1 and 2. Option 3 is something that I could call the "development stage" for implementing HSTS preload. The entire redirection thingy seems risky, but - technically, (I have not tested it) - is there a navigation request required to have the HSTS statement set to the browser, or for example, loading an image is enough? E. g. if from
Option 4 is not supported by HSTS preload list. If you try to check the subdomain (which is not
Note: "...with the subdomains attribute" - using the
So, in my opinion - our options are simple - should we only recommend it or can we require it? For the perspective - most likely the new ASVS version will be valid for "non-braking-changes" for many years, this is something to keep in mind. |
From my point of view, the question should be: Are there any valid reasons not to have HSTS preload as a requirement? Context: level 3 requirement for applications with critical business value and/or highly sensitive data. |
Ok so the basic question is, should HSTS preload at the top level domain be a L3 requirement or a recommendation? Curious to see what @jmanico @ryarmst @Sjord @ImanSharaf @EnigmaRosa @csfreak92 @meghanjacquot have to say |
My mindset for requirements that may be difficult or complicated for legacy systems. Legacy systems are built in their time and are expected to be not compatible by default with new requirements. It is the same way everywhere - take for example requirements for new cars, requirements for building new houses, etc. There are reasons for having new requirements. If those new requirements are reasonable to require for new systems that are built today and from scratch, we should have those requirements in. We don't need to legalize old and insecure systems to be compatible with new standards. |
Ok so the basic question is, should HSTS preload at the top level domain be a L3 requirement or a recommendation?
I think it should be a level 3 requirement.
Like other level 3 requirements it will be challenging to implement for some legacy systems. This should not stop us from setting a requirement of any kind. Many level 3’s are hard to implement for even new applications.
|
See https://hstspreload.org/ :
This might be a good reason for not mandating this. |
I watch a bit differently - it says clearly, do not include it by default. It is recommendation about the process, how to implement HSTS preload into your infrastructure. It does not say "don't use it". @randomstuff - The main question for me is from (#1941 (comment)): is there any good reason to say, that why you should not use it when you start building your company or organization from a blank page e.g. you don't have any legacy to carry? What is your opinion on this? |
There is a tradeoff here where requiring HSTS preload can lead to worse security. For example, bank.tld has a customer portal on my.bank.tld and a legacy application on legacy.bank.tld. They cannot put HSTS preload on bank.tld, as that would break their legacy application. However, ASVS L3 says that their company portal should have HSTS preload. The "solution" is to move it to another domain, mybankonline.tld, and enable HSTS preload there. However, this is exactly what a phishing attack looks like: a similar but different domain, which makes it impossible to verify if the customer portal is actually owned by bank.tld. So this would give the wrong signal to customers, that not only bank.tld is trustworthy, but other domains that look similar as well. This is not uncommon in the real world, for example with microsoftonline.com being an actual Microsoft domain. But I think this is not desirable from a security perspective. |
HSTS - and HSTS in general (since includeSubdomains is really needed for privacy) is only useable when the entire domain supports HTTPS.
Also, why would a *bank* website have a legacy subdomain that is HTTP? That’s pretty rare these days.
Would you be happier if the requirement was more specific about first moving the entire site to HTTPS?
Something like “ …the application must be covered by HSTS preload and be 100% HTTPS “ as a level 3 requirements?
|
An alternative way to use HTTPS immediately (including the first request) is to use a HTTPS RR DNS record. This is pretty new, but seems to be supported by Chrome and Firefox. This is specific to domains instead of sites, solving the tradeoff I mentioned earlier. I feel like this scales better and is more flexible, since site administrators can configure this themselves instead of requesting a change in the preload database. Of course, DNSSEC is required for optimal security. |
What if we suggest HSTS preload or HTTPS RR DNS?
|
Hi @Sjord, as I understand, then domain based solution does not solve the "control your same-site scope" effect. Correct? (See my comment here: #1941 (comment)) I don't want to have too much impact from "Let's do the legacy legal" behavior and I have the question to you: Is there any good reason to say, that why you should not use HSTS preload when you start building your company or organization from a blank page e.g. you don't have any legacy to carry? What is your opinion on this? |
I agree with Elar‘s perspective here, for what it’s worth. 🙏
|
Yeah it does seem like HTTPS RR doesn't solve the problem that elar mentions in his comment: #1941 (comment) Is that correct @Sjord? |
The topic is discussed before - #966, but as there is offtopic noise, I open a new issue.
Problem to solve: if the browser makes the first HTTP request to the application domain, it must be forced over HTTPS connection. That can be achieved by registering the main domain (if not covered by TLD) to the HSTS preload list.
Note, that just adding the
preload
directive into theStrict-Transport-Security
HTTP response header does not have any effect. Although related, it also means, that the requirement does not fit the section "V50.2 Browser Security Mechanism Headers". As it is browser related, it should belong to the paragraph "V50 Web Frontend Security".Now the challenge is how to write it as a requirement. We can not ask the application hostname to be in the preload list. It can be covered by the main domain or by the TLD (
.dev
)The text was updated successfully, but these errors were encountered: