No , per poter eseguire che l'utente malintenzionato debba avere la chiave privata associata al certificato del sito Web (chiave privata utilizzata per generare la chiave pubblica nel certificato). Il client invierà una sfida al sito web durante l'handshake SSL e se non torna firmato con la chiave privata del sito web sa che non sta parlando al sito Web in cui sta cercando di parlare a.
L'attaccante non può generare una coppia di chiavi diversa perché il client ha un certificato CA (nel browser o come parte del sistema operativo) che canta il certificato del sito web. Il certificato firmato dalla CA collega il dominio del sito web a una chiave pubblica e solo la chiave privata di quel dominio specifico (ovvero quella chiave pubblica ) sarebbe in grado di firmare correttamente il testo della sfida.
D'altro canto, se l'attaccante può ottenere la chiave privata del sito Web (per ottenere il quale probabilmente dovrà copiarlo dai server del sito Web), sarà in grado di eseguire HTTPS al client.
Tuttavia, questo non è più un attacco SSLstrip, questo sarebbe un semplice certificato compromesso. E, se il sito Web scopre il compromesso, probabilmente aggiungerà il suo certificato a un database di certificati compromessi. Ad esempio il database OSCP che vari browser controlleranno (ovviamente l'attacco potrebbe essere ale per falsificare la richiesta OSCP).
Un'altra opzione è ingannare il cliente (grazie @ crovers ). Se e l'utente malintenzionato può consentire al client di accettare un nuovo certificato CA radice, può firmare il dominio con la propria CA e fornirlo come certificato anziché come quello reale.
Anche in questo caso non è SSLstrip, si tratta di una forma di phishing dell'utente per l'installazione di certificati CA falsi.