0

As per the RFC6797- [..] "An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport." [..] https://www.rfc-editor.org/rfc/rfc6797#page-18

My question is - if the client is trying to access the host over non-secured HTTP (e.g. TCP port 80) and the server implements HSTS policy the server MUST respond with HSTS policy header over secured transport. Now considering the secured transport as SSL - when does the SSL key exchange and handshake happen, for client to decrypt the server response over secured transport/SSL?

The https://www.ssl2buy.com/wiki/http-strict-transport-security-hsts-better-security-for-applications link nicely explains the HSTS policy implementation but I am unable to put it together how the SSL handshake happens.

Community
  • 1
  • 1
Nilesh
  • 1
  • 1

1 Answers1

1

HSTS has nothing to do with the SSL handshake.

It simply means if the browser is instructed to go to http://www.example.com, then instead act as if they were instructed to go to https://www.example.com.

The SSL negotiation happens afterwards - exactly as if they went to the https version directly.

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • Thanks for your answer. I captured the packets between the client and the HSTS enabled host. I could see the 301 redirect and then the HTTPS communication, the request/response is renegotiated on the secured layer. It's inline with what you mentioned in the answer. – Nilesh Jan 19 '18 at 12:36
  • That’s what should happen for the first time. After that the HSTS policy should be cached and then there should be no redirect but a straight HTTPS call (that’s the point of HSTS to avoid the need for that redirect). Anyway, regardless of that the HTTPS negotiation happens as part of that HTTPS call as I stated. – Barry Pollard Jan 19 '18 at 13:09