Imagine the following:

Client C wants to communicate with server S. The evil attacker A is the Man-In-The-Middle.

C sends a request to S, A intercepts it. A creates a self-signed certificate with the domain-name of S and sends the certificate to C, while spoofing the Source-IP to the IP of S.

C and A perform the handshake (C thinks that A is S), A can decrypt requests made form A and forwards them to S (via HTTP or HTTPS). S's responds are treated the other way round.

C sees the warning that the certificate is self signed, but who cares, really?

Since the connection between C and A is via SSL, HSTS should not be a problem.

Is this possible? Or am I missing anything?

  • 1
    C sees the warning that the certificate is self signed, but who cares, really? This is a big assumption. Most of the time, one should care!
    – ρss
    Jun 10, 2015 at 11:49

2 Answers 2


Once C's browser has established that S is a known HSTS host (either via its preload list or by having previously received a valid Strict-Transport-Security header), self-signed certificates and similar security problems produce errors that the user can't simply click through.


So the answer to your question "who cares, really?" is "the browser".

Of course, this attack could succeed if C hasn't yet established that S uses HSTS - that is, if this is C's first attempt to connect to S, and S isn't in the browser's preload list.


"No user recourse"

RFC 6797, section 12.1 states that the user SHOULD not be presented with a "click here to ignore and proceed" dialog.

Now this is a "SHOULD" clause and not a "MUST" clause. In RFC speak this means you are free to ignore it. But urged not to.

So if your browser honors the RFC's recommendation, then you won't be able to ignore it.

And if your browser allows you to ignore the failure, then you can go ahead and be sniffable.

You must log in to answer this question.

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