I've only seen examples of this type of MITM attack stripping SSL completely and this isn't ideal as most devices warn their users when the connection is not secured.

So is it possible to create the following system:

Website <(HTTPS)> Attacker <(HTTPS)> Victim

Where the attacker gets one set of credentials from the website and is therefore able to decrypt the connection and creates another set of credentials which are passed on to the victim.

That way the attacker can decrypt/modify the packets as they come, encrypt them again with the credentials s/he passed created for the target and the connection looks legitimate.

1 Answer 1


No, to be able to perform that the attacker must have the private key associated with the certificate of the website (private key used to generate the public key in the certificate). The client will send a challenge to the website during the SSL handshake and if it does not come back signed with the private key of the website it knows it is not talking to the website in it is trying to talk to.

The attacker cannot generate a different key-pair because the client has a CA certificate (in the browser or as part of the OS) that sings the website's certificate. The certificate signed by the CA relates the domain of the website to a public key and only the private key of that specific domain (i.e. that public key) would be able to sign the challenge text correctly.

On the other hand, if the attacker can get hold of the private key of the website (to achieve which he would likely need to copy it from the website's servers) then he would be able to perform HTTPS to the client.

Yet, this is not an SSLstrip attack anymore, this would be a plain compromised certificate. And, if the website discovers the compromise, will likely add its certificate to a database of compromised certificates. For example the OSCP database which several browsers will check (of course the attack may be ale to spoof the OSCP request).

Another option is to fool the client (thanks @crovers). If and attacker can make the client to accept a new root CA certificate, he can sign the domain with his own CA and provide that as a certificate instead of the real one.

This again is not SSLstrip, this is a form of phishing the user into installing bogus CA certificates.

  • 2
    If you can get your root cert into the client's trusted CA list, mind, all bets are off. That's how https MITM proxies (like ZAP) work - the proxy re-signs all requests with a cert for the site made with its own root cert. That only works if the browser trusts that root cert - that's why root certs are such a big deal.
    – crovers
    Commented Sep 16, 2016 at 18:52

You must log in to answer this question.

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