Capisco come sia in grado di creare una connessione sicura tramite l'handshake, ma come è in grado di avviare una connessione sicura senza prima inviare una richiesta non crittografata, rivelando così il sito web di destinazione (ma non i dati inviati o ricevuti da / alla destinazione ...) ad un potenziale attaccante "uomo nel mezzo" ...? o non lo nasconde?
Non confondere la sicurezza con la privacy.
Il compito di SSL / TLS è la sicurezza, non la privacy. Ciò significa che i dati stessi sono crittografati, ma i metadati come IP di origine e di destinazione, il nome host (con SNI utilizzato da tutti i browser moderni), le dimensioni del payload e il tempo ecc. Non lo sono. E tutti questi possono essere utilizzati per creare un profilo di navigazione di te che include i siti che visiti e talvolta anche le pagine che visiti sul sito (in base alla tempistica e alle dimensioni del payload). Ma SSL / TLS si assicura che il contenuto non pubblico (come i cookie, i dati dei moduli, ecc.) Sia protetto dallo sniffing e dalla manipolazione.
Se vuoi una migliore privacy devi combinare SSL / TLS con qualcosa come Tor, ma anche questo non può garantire la privacy completa.
SSL / TLS non nasconde l'origine e gli indirizzi IP di destinazione. È impossibile (almeno con una soluzione puramente ssl / tls), perché gli indirizzi src / dst devono essere validi per una connessione tcp funzionante.
Il nome del sito web collegato, è nascosto per impostazione predefinita - o, almeno, è rimasto fino agli ultimi anni.
Da allora, esiste un'estensione del TLS denominata " Indicazione del nome del server ", che fornisce il nome del sito collegato non crittografato , ancora nella fase di handshake.
Il sito man-in-the-middle è una cosa diversa. Con mitm, un utente malintenzionato può eseguire la destinazione per il client e riprodurre il client per il server, utilizzando chiavi diverse e diverse sessioni ssl / ttls. Ma non ha nulla a che fare con la decrittazione ssl.
Come l'altro ha affermato, la connessione iniziale non è protetta e contiene almeno l'indirizzo IP (anche se sempre più il nome del server, grazie a SNI). Il server di destinazione risponde con un certificato di chiave pubblica e negozia la sessione SSL / TLS.
La chiave per evitare gli attacchi man in the middle è il certificato e il fatto che sia stato approvato da un'autorità di certificazione che il tuo browser ha fiducia.
Supponiamo che tu abbia un hacker che intercetta le comunicazioni tra un client e un server. Il cliente ha chiesto una connessione sicura al collegamento del sito web (ad esempio). L'hacker può inviare la richiesta al sito Web reale e ritrasmettere le risposte. L'hacker sarà anche in grado di leggere la prima risposta da server a client poiché è un testo normale. Tuttavia non può leggere il messaggio successivo dal client al server poiché è crittografato con la chiave pubblica del sito Web e quindi può essere decifrato solo con la chiave privata (che l'hacker non ha). Poiché questi messaggi successivi vengono utilizzati per negoziare la chiave da utilizzare per la connessione SSL / TLS effettiva, l'hacker è fondamentalmente bloccato dopo quel primo messaggio.
In alternativa, invece di agire come un relè diretto, l'hacker può fornire un falso cert (a cui conosce la chiave privata) per la connessione client-hacker e quindi può impostare la propria connessione e passaggio del server hacker messaggi tra i due. Tuttavia in questo scenario, a meno che non siano riusciti a compromettere uno dei principali emittenti di certificati che il browser client accetta automaticamente, ci sarebbe un grande lucchetto rosso che dice che il certificato che l'hacker ha restituito al client è 1) non reale o 2 ) non per questo sito Web.
La maggior parte degli attacchi MITM dipende dal mantenere la connessione su standard http. Ad esempio, vai su www.mybank.com (quindi il browser prova http: // come impostazione predefinita in quanto non hai specificato un protocollo). Normalmente la banca ti reindirizza a link ma invece l'hacker intercetta tale reindirizzamento e ti mantiene su http per la connessione client-hacker ma imposta un corretta connessione https da hacker a server. In questo scenario, l'hacker spera che gli utenti non si accorgano che non esiste un lucchetto verde e che non sono passati a https. Gli hacker sono piuttosto sfortunati se l'utente passa direttamente a https.