Se l'attacco Man-in-the-Middle ha esito positivo, allora per definizione , l'attaccante vede tutto: il successo è che l'attaccante impersona sia il client che il server, quindi il client parla con l'attaccante, il server parla con l'attaccante, l'attaccante decifra da un lato e reencrypt su l'altro. Con un MitM riuscito, l'utente malintenzionato può visualizzare i collegamenti, i contenuti della pagina, le password ...
Ma, naturalmente, SSL è stato progettato per sconfiggere gli attacchi MitM. La protezione principale è il certificato del server. Per avere successo con MitM, l'utente malintenzionato deve creare un certificato falso con il nome del server, ma contenente una chiave pubblica controllata dall'utente malintenzionato. L'intero punto della CA radice affidabile e della convalida del certificato è tale che il client non venga ingannato da un falso certificato del server.
(Se gli utenti umani vedono l'avviso spaventoso dal proprio browser "questo server utilizza un certificato non attendibile" e fa ancora clic sul pulsante "Non mi interessa, connetti comunque!", il MitM ha esito positivo. SSL si basa sull'idea che l'utente umano non fa nulla di stupido come non tener conto di questo tipo di avvertimento.)
Modifica: per quanto può essere dedotto dallo sniffing passivo, quindi questo non include l'URL richiesto per sé ; tuttavia, alcune cose possono essere dedotte:
Il nome del server previsto (la parte "nome host" dell'URL) sarà noto all'attaccante. I browser moderni lo mostrano in chiaro come parte dell'estensione Nome server . Il nome appare anche nel certificato del server, che viene inviato anche come testo in chiaro.
La crittografia nasconde i dati contenuti , ma non i dati lunghezza . L'utente malintenzionato può quindi dedurre la lunghezza dell'URL, soprattutto se riesce a osservare diverse richieste crittografate.
Poiché le lunghezze perdono, l'attaccante può vedere più o meno quanti elementi vengono scaricati dal client e le loro lunghezze, ad es. immagini collegate. A seconda della struttura del sito e se l'autore dell'attacco può anche esplorare lo stesso sito (ad esempio, un altro utente), quindi può capire con estrema precisione ciò che l'utente di destinazione sta effettivamente navigando.
No perché un tunnel crittografato viene configurato prima che qualsiasi messaggio (incluse le richieste GET / POST) venga inviato attraverso il collegamento.
Leggi altre domande sui tag tls