Bug 581322 - Enable HTTP Strict Transport Security
Summary: Enable HTTP Strict Transport Security
Status: NEW
Alias: None
Product: ECF
Classification: RT
Component: ecf.filetransfer (show other bugs)
Version: 3.14.26   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.14.24   Edit
Assignee: ecf.core-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-01-11 05:15 EST by Andrew Johnson CLA
Modified: 2023-01-21 19:09 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Johnson CLA 2023-01-11 05:15:33 EST
HTTP Strict Transport Security provides a way for a website to request HTTPS is always used for communications.
https://www.rfc-editor.org/rfc/rfc6797
It is then up to the client to change a user's request from HTTP to HTTPS.

This makes transfers much more secure, as at most one HTTP request would be done to a website, then all subsequent requests would be via HTTPS, even if the user shut down and restarted at a new insecure network location.

Does ECF support this? If not, how could this be done? Where should this be done? 
By the lower level transport? - E.g. Java 11 HTTP Client, but no plans for this. https://bugs.openjdk.org/browse/JDK-8163325
At the provider level - e.g. httpclientjava
At a high level in ECF?
By the caller, e.g. p2. But how would p2 know about a 301 redirect or a Strict-Transport-Security response when it requests a file?

The HSTS status for a website needs to be persisted (possibly for months), but then how does a user clear HSTS for a website if something gets messed up?
Comment 1 Scott Lewis CLA 2023-01-21 19:09:32 EST
(In reply to Andrew Johnson from comment #0)
> HTTP Strict Transport Security provides a way for a website to request HTTPS
> is always used for communications.
> https://www.rfc-editor.org/rfc/rfc6797
> It is then up to the client to change a user's request from HTTP to HTTPS.
> 
> This makes transfers much more secure, as at most one HTTP request would be
> done to a website, then all subsequent requests would be via HTTPS, even if
> the user shut down and restarted at a new insecure network location.
> 
> Does ECF support this? 

Not directly...i.e. not unless it's supported transparently by the underlying provider (e.g. httpclient5 and httpclientjava).

I'm not familiar with this rfc, so I can't even say what it would take to implement...if it requires changes to ECF code (which is a thin wrapper above the specific provider0

If not, how could this be done? Where should this be
> done? 
> By the lower level transport? - E.g. Java 11 HTTP Client, but no plans for
> this. https://bugs.openjdk.org/browse/JDK-8163325
> At the provider level - e.g. httpclientjava
> At a high level in ECF?
> By the caller, e.g. p2. But how would p2 know about a 301 redirect or a
> Strict-Transport-Security response when it requests a file?
> 
> The HSTS status for a website needs to be persisted (possibly for months),
> but then how does a user clear HSTS for a website if something gets messed
> up?

So the short answer is that I don't know the answers to these questions, as I haven't looked at the rfc.