Talk:HTTP Strict Transport Security

This is the talk page for discussing improvements to the HTTP Strict Transport Security article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computing: Networking / Security Low‑importance

This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles

Low

This article has been rated as Low-importance on the project's importance scale.

This article is supported by Networking task force (assessed as Low-importance).

This article is supported by WikiProject Computer Security (assessed as Mid-importance).

Things you can help WikiProject Computer Security with:

Article alerts will be generated shortly by AAlertBot. Please allow some days for processing. More information...

Review importance and quality of existing articles
Identify categories related to Computer Security
Tag related articles
Identify articles for creation (see also: Article requests)
Identify articles for improvement
Create the Project Navigation Box including lists of adopted articles, requested articles, reviewed articles, etc.
Find editors who have shown interest in this subject and ask them to take a look here.

Cryptography Low‑importance

	This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography articles
Low	This article has been rated as Low-importance on the importance scale.

Internet Mid‑importance

	Internet portal This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet articles
Mid	This article has been rated as Mid-importance on the project's importance scale.

What is the exact response header?

The "Overview" section thoroughly describes how a user agent should behave, but says nothing about how the server should behave. A few sentences giving, e.g., the exact header syntax, should make the section complete and not much longer. --66.30.251.99 (talk) 10:47, 29 June 2010 (UTC)[reply]

I agree. -- Kistano (talk) 23:19, 5 September 2010 (UTC)[reply]

Please, check the code

It seems like either the second -if- statement is redundant or -else if- should be replaced with simple -if- 194.105.145.69 (talk) 07:33, 17 November 2010 (UTC)[reply]

The second -if- statement is meant to redirect users not using HTTPS already, however, in many of the snippets there is no check for this. Code needs work. --praseodym (talk) 16:53, 26 February 2011 (UTC)[reply]

That better be without AND at all. Skeleton is to be nested IFs: IF [ STS-a-must] THEN [ if { SSL-is-used } then {add-STS-header} else { redirect-to-SSL } ] ELSE [ ...non-STS path... ]

However, the code is just broken

In CFML, JSP, VB.NET example - there is no support for SSL-is-used check at all ! That results in else-if branch been always dead code. It better be removed then... Or maybe help requested on artices about JSP, VB.NET, CFML. Note - in above discussion about nested IFs - this mistake been very obvious and just could not slip in ;-) 79.111.223.5 (talk) 22:50, 14 May 2011 (UTC)[reply]

in addition to above, classic ASP does not support request.url (.Net does). 173.9.157.225 (talk) 00:07, 7 September 2011 (UTC)[reply]

FWIW, it's good practice to put an "exit;" after a "header('location: ...');" in PHP - if output buffering is off and any part of the body of the request (e.g. whitespace) has accidentally been sent to the client, I think PHP just gives a warning when you try to redirect via the location header...and then keeps executing code. So your stuff would just go out over http:// in that case. — Preceding unsigned comment added by 74.79.145.8 (talk) 14:26, 10 September 2011 (UTC)[reply]

Why so many code examples?

The plethora of programming languages distracts from the content of the article IMO. Also the redirect instruction doesn't fall within the scope of HSTS IMO. Ben Atkin (talk) —Preceding undated comment added 17:38, 10 July 2011 (UTC).[reply]

I think its relevantMayhaymate (talk) 19:20, 3 May 2012 (UTC)[reply]

Applicability

I expanded the applicability section with some information about how this prevents SSL-stripping, and how it should really (or also) be in the DNS records. Please comment/edit rather than just deleting it all! 155.198.65.73 (talk) 17:36, 22 March 2011 (UTC)[reply]

I assume WP:CATALOG #4, #5 is about this list. We should not to list a website ONLY BECAUSE it has . We can list very famous web-services, such as Gmail, Facebook, Twitter - and the good indication of such is an long-lived article about this service: GMail, Facebook, Twitter. `A5b (talk) 18:27, 22 June 2011 (UTC)[reply]

"Of course, the HSTS header can be stripped by the attacker if this is the user's first visit."

The HSTS header can only be sent over SSL. It may be worth mentioning that the attacker could perform a stripping attack to prevent the header from being sent, but I think the sentence should be removed in its current form.--79.66.208.193 (talk) 15:23, 30 August 2011 (UTC)[reply]

Agreed. The current wording is self-contradictory. A more correct description of the attack would be to use an SSL stripping to prevent the header from being communicated to the client. Kasperd (talk) 21:23, 25 September 2011 (UTC)[reply]

Use of DNSSEC

The article mention of the possibility of using DNSSEC, but it above tell how far the work is on standardizing the use of DNSSEC for this. Kasperd (talk) 21:23, 25 September 2011 (UTC)[reply]

Use of HSTS without forcing all clients to use HTTP should be added

It is possible to deploy HSTS so that a website can be accessed with and without HTTP if wanted and I think this should be added to the article.

I.e. That HSTS is forced only to clients already accessing the site with HTTP with forcing clients that access the site with HTTP to use HTTP. This isnt currently clear and the article gives the impression that using HSTS forces everyone using a website to use HTTP. Mayhaymate (talk) 11:36, 10 June 2012 (UTC)[reply]

Browser Support and Implementation

Great article but some rather glaring omissions. The browser list doesn't mention IE and the implementation list doesn't mention IIS. There seem to be some other far less prevalent products listed. I wish I could help, but I'm sure someone out there could assist in providing this information for us Microsoft users. — Preceding unsigned comment added by 70.42.29.6 (talk) 13:07, 15 March 2013 (UTC)[reply]

Wget might not qualify as a browser, but version 1.17 and later implement HSTS support. — Preceding unsigned comment added by 107.1.244.230 (talk) 18:15, 12 May 2017 (UTC)[reply]

preload directive?

The RFC does not mention a preload directive or did I miss something? — Preceding unsigned comment added by 77.56.96.22 (talk) 10:12, 12 March 2015 (UTC)[reply]

Deployment Best Practices

The second bullet point is a little unclear:

I assume it should say something like "In addition to HSTS deployment, pages served by https://www.example.com should trigger a browser request to https://example.com ..." then I guess it might go on to suggest loading an empty javascript file or hidden image?
A source should be cited. (I have since found it under External Links but am not sure how to cite it: The State of HSTS Deployment: A Survey and Common Pitfalls) I have not found evidence of major sites implementing this (including icloud.com referenced in the source) so maybe it is outdated somehow or not necessary once a domain is in the preload list.

Jimwrightbe (talk) 15:23, 5 January 2017 (UTC)[reply]

In which way is HTTP insecure?

The article should not claim or suggest that HTTP is inherently insecure just because it is not encrypted. In case HTTP is inherently insecure, the article needs to explain how and why when suggesting that it is.

It is generally a very bad to give the impression that something which is encrypted is magically secure while something that is not encrypted is magically "insecure". No information and no data is secure, and no encryption is ultimately able to prevent that. — Preceding unsigned comment added by 93.244.198.209 (talk) 14:09, 2 February 2020 (UTC)[reply]