Non puoi autenticarti come server
Il problema non è che il server "farà storie" non lo farà. Puoi facilmente convincere il server a pensare che tu sia l'utente. L'utente non sta effettuando l'autenticazione con un certificato SSL. Il problema è che non puoi ingannare l'utente o più nello specifico il browser dell'utente. Ricorda che per un attacco MITM l'attaccante deve stabilire connessioni con entrambe le entità (quindi nel mezzo).
Client < --------- > MITM Attacker < ---------- > Server
Con http è banale. Ti siedi nel mezzo e fai finta di essere il server del client e fai finta di essere il client del server. Il problema con https non è il collegamento tra te e server (per quanto riguarda il server sei il cliente). Il problema è nel collegamento tra te e l'utente.
Quando l'utente accede al link il browser si aspetta:
- Che viene restituito un certificato SSL
- Che il certificato SSL ha example.com nel nome host
- Che il certificato SSL è firmato (o indirettamente firmato) da un certificato radice nel suo keystore di root attendibile.
Se blocchi il client dall'ottenere il certificato ssl da example.com, il browser fornirà all'utente un errore (timeout http)
Se invii all'utente un certificato valido (firmato da una CA) per un altro nome host, il browser fornirà all'utente un errore (nome host errato)
Se invii all'utente un certificato per esempio.com che crei e non sia firmato, il browser fornirà all'utente un errore (cert non attendibile).
Se invii all'utente un certificato per esempio.com firmato da un'altra CA, assicurati che il browser fornisca all'utente un errore (certificato non attendibile) perché non si fida del certificato CA.
Striscia SSL (reindirizzamento dell'utente a http)
Come funziona SSL Strip reindirizza l'utente da https a http. L'utente passa al link e intercetta che invia all'utente un reindirizzamento al link e stabilisci ancora una connessione sicura tra te e il server.
Cliente < --- HTTP --- > MITM Attacker < ---- HTTPS --- > Server
Comprendi che stai potenzialmente compromettendo l'utente con altri veri attaccanti. Se l'utente si connette, diciamo alla società wifi, chiunque sul wifi potrebbe rubare informazioni sensibili perché è stato rimosso dallo ssl.
L'utente può tuttavia notare che si trova su http non https ( perché il mio sito web della banca non mostra la barra verde ). Purtroppo non è così comune che la maggior parte degli utenti si accorga ciecamente che sono sicuri, quindi l'HSTS è stato sviluppato per proteggere gli utenti da questo tipo di attacco. Se il browser supporta HSTS, il sito utilizza HSTS e l'utente è già stato sul sito (o HSTS è stato precaricato dal browser) l'utente riceverà un errore / avviso quando si reindirizza a http.
"Infetta" il computer dell'utente con un certificato radice "attendibile" che controlli
L'unico modo per aggirare l'HSTS (specialmente con il preload) è creare un certificato CA per cui si ha la chiave privata e l'installazione quella nel browser / os della vittima. Quindi quando MITM l'utente è possibile creare un certificato per esempio.com, firmarlo con il certificato MITM CA. Il browser convaliderà il certificato example.com che hai creato e controllerà la firma che sarà valida e proviene da un certificato che si fida (nel keystore di root attendibile). Ciò richiederà l'accesso amministrativo sulla macchina dell'utente.
Anche questo non funzionerà se il blocco della chiave è stato utilizzato nel browser per prendere nota del "vero" esempio. cert.