1

It is my understanding that requests from a client browser to a webserver will initially follow the specified protocol e.g, HTTPS, and default to HTTP if not specified (Firefox Tested). On the server side it is desired to enforce a strict type HTTPS for all connections for the privacy of request headers and as a result HTTPS redirections are used. The problem is that any initial request where the client does not explicitly request HTTPS will be sent unencrypted. For example, client instructs browser with the below URL command.

google.com/search?q=unencrypted-get

google.com will redirect the client browser to use HTTPS but the initial HTTP request and GET parameters were already sent unencrypted possibly compromising the privacy of the client. Obviously there is nothing full-proof that can be done by the server to mitigate this vulnerability but:

  1. Could this misuse compromise the subsequent TLS security possibly through a known-plaintext
    attack (KPA)?
  2. Are there any less obvious measures that can be done to mitigate this possibly through some DNS protocol solution?
  3. Would it be sensible for a future client standard to always initially attempt with HTTPS as the default?
user237462
  • 11
  • 1
  • (1) no (2) [HSTS preload](https://www.chromium.org/hsts) (3) maybe, but if when S fails you fallback to plain it's still just as insecure because attacker can force the fallback, and if you fail hard in situations where other browsers (seem to) work, you won't have any users. See https://security.stackexchange.com/questions/81801/why-do-browsers-default-to-http-and-not-https- and prior https://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol and https://security.stackexchange.com/questions/44849/security-of-an-initial-redirection-from-http-example-com-to-https- – dave_thompson_085 Jun 29 '20 at 03:00

2 Answers2

1

google.com will redirect the client browser to use HTTPS but the initial HTTP request and GET parameters were already sent unencrypted possibly compromising the privacy of the client.

Correct. Except for HSTS preload.

Could this misuse compromise the subsequent TLS security possibly through a known-plaintext attack (KPA)?

Not exactly. If this event is exploitable, the desired outcome for the attacker is instead to influence the redirection towards something that they control so that they can "impersonate" the TLS endpoint. It would be much more difficult to use this to influence the subsequent TLS connection to the real server (closer to impossible actually).

Are there any less obvious measures that can be done to mitigate this possibly through some DNS protocol solution?

Not really. HSTS preload ensures that a browser will refuse to connect to an HTTP domain in the preload list, so there isn't an initial plaintext request.

Would it be sensible for a future client standard to always initially attempt with HTTPS as the default?

Yes, in my mind this would be a sensible default. There's always implications to guessing though.

Pedro
  • 3,931
  • 12
  • 25
0

I don't see what is the vulnerability here? Even if an attacker in the middle knows the request that you made, all HTTPS sessions have their own session keys. They won't be able to intercept the response mid flight and parse it.

This famous question on the forum may help you understand the answer to question 1.

As for question 3, it is quite common for clients to use HTTPS by default when talking to the server.

Limit
  • 3,236
  • 1
  • 16
  • 35