1

During an HTTPS connection between a browser and server -- Is the very first packet from the browser encrypted? My guess is that the answer is "NO" because encryption should only begin after the client and server have negotiated encryption parameters.

Now, if my answer of "NO" is correct, how come the SSLStrip attack fails to work when the user explicitly types HTTPS in the address bar? Since the first packet is unencrypted regardless of whether the attacker types https:// or http://, the attacker should still be able to hijack the connection and fool both the sender and attacker in the same way for both cases. This would mean SSLStrip should work in either case.

Improve this question

1 Answer 1

Reset to default
5

SSLstrip works by replacing HTTPS links in web pages returned by the server with HTTP links. This happens during a standard HTTP request, response exchange.

While the initial HTTPS call isn't encrypted, it is part of the TLS handshake and is definitely not standard HTTP requests. The TLS handshake can only result in a TLS connection or a connection failure. There's no way for it to magically become standard HTTP.

So there's no way for SSLstrip to downgrade an HTTPS request.

Improve this answer
10
  • I have edited my question a little to make it clearer (see above). I thought typing https:// foils the attack because the attacker cannot read anything (because its encrypted)
    – Minaj
    Jun 2, 2016 at 2:54
  • @Minaj - the question has not been edited. Are you sure you saved it?
    – Neil Smithline
    Jun 2, 2016 at 2:56
  • @Minaj - And typing https foils the attack because SSLstrip works on HTML pages being returned in an HTTP response. Typing https doesn't have an HTTP response (prior to the completion of the SSL handshake) so SSLstrip has no opportunity to work
    – Neil Smithline
    Jun 2, 2016 at 3:04
  • You are right to note that prior to the completion of the SSL handshake, there are no HTML pages exchanged. But if the attacker decided to capture all the SSL handshake packets as well, he will eventually access the HTML traffic because he will witness the entire key negotiaton process and use those keys to do a man-in-the-middle. I wonder why SSLStrip never covers this scenario. My understanding is that the handshake packets are unencrypted, and thus can be read and modified by the man-in-the-middle. From your response I understand that SSLStrip does not do this. It appears doable to me
    – Minaj
    Jun 2, 2016 at 3:40
  • 1
    @Minaj Neil answered your question well. I think you fundamentally misunderstand how a HTTPS session is establiahed.
    – Luke Park
    Jun 2, 2016 at 6:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .