Come è possibile che le persone che osservano una connessione HTTPS stabilita non sappiano come decrittografarla?

È la magia di crittografia a chiave pubblica . La matematica è coinvolta.

Lo schema di scambio di chiavi asimmetrico che è più facile da capire è la crittografia asimmetrica con RSA. Ecco una descrizione semplificata:

Sia n un numero intero (ad esempio 300 cifre); n viene scelto in modo tale che sia un prodotto di due numeri primi di dimensioni simili (chiamiamoli p e q ). Quindi calcoleremo le cose "modulo n ": questo significa che ogni volta che aggiungiamo o moltiplichiamo insieme due numeri interi, dividiamo il risultato per n e manteniamo il resto (che è tra 0 e n-1 , necessariamente).

Dato x , calcolare x ³ modulo n è facile: moltiplica x con x e poi di nuovo con x , e poi dividi per n e tieni il resto. Tutti possono farlo. D'altra parte, dato x ³ modulo n , il recupero di x sembra eccessivamente difficile (i metodi più noti sono troppo costoso per la tecnologia esistente) - a meno che tu sappia p e q , nel qual caso diventa di nuovo facile. Ma anche il calcolo di p e q di n sembra difficile (è il problema noto come integer factorization ).

Quindi ecco cosa fanno il server e il client:

• Il server ha un n e conosce i corrispondenti p e q (li ha generati). Il server invia n al client.
• Il client sceglie un x casuale e calcola x ³ modulo n .
• Il client invia x ³ modulo n al server.
• Il server usa la sua conoscenza di p e q per recuperare x .

A quel punto, sia client che server sanno x . Ma un intercettatore ha visto solo n e x ³ modulo n ; non può ricalcolare p , q e / o x da quelle informazioni. Quindi x è un segreto condiviso tra il client e il server. Dopodiché è una crittografia simmetrica abbastanza semplice, usando x come chiave.

Il certificato è una nave per la chiave pubblica del server ( n ). È usato per bloccare gli attaccanti attivi che vorrebbero impersonare il server: un tale attaccante intercetta la comunicazione e invia il suo valore n invece del n del server. Il certificato è firmato da un'autorità di certificazione, in modo che il cliente possa sapere che un determinato n è davvero il vero n dal server con cui vuole parlare. Le firme digitali utilizzano anche la crittografia asimmetrica, anche se in modo distinto (ad esempio, esiste anche una variante di RSA per le firme digitali).

Ecco una versione davvero semplificata:

1. Quando un client e un server negoziano HTTPS, il server invia il suo chiave pubblica per il client.
2. Il client crittografa la chiave di crittografia della sessione che desidera utilizzare utilizzando chiave pubblica del server e invia i dati crittografati al server.
3. Il server decodifica la chiave di crittografia della sessione utilizzando la sua chiave privata e inizia a usarla.
4. La sessione è protetta ora, poiché solo il client e il server possono conoscere la chiave di crittografia della sessione. Non è mai stato trasmesso in chiaro, o in alcun modo un utente malintenzionato può decrittografarlo, quindi solo loro lo sanno.

Voilà , chiunque può vedere la chiave pubblica, ma questo non gli consente di decifrare il pacchetto "hey-let's-encrypt-using-this-from-now-on" che è criptato con quella chiave pubblica. Solo il server può decrittografarlo, perché solo il server ha quella chiave privata. Gli aggressori potrebbero tentare di forgiare la risposta contenente una chiave crittografata, ma se il server imposta la sessione con quella, il vero client non la pronuncia perché non è la chiave impostata dal vero client.

È tutta la magia della crittografia a chiave asimmetrica. Roba affascinante.

P.S. "veramente semplificato" significa "dettagli storti per rendere più facile la comprensione". Wikipedia "Transport Layer Security" offre una risposta più corretta nei dettagli tecnici, ma io miravo a "facile da inghiottire".

Le altre risposte sono buone, ma qui c'è un'analogia fisica che potrebbe essere più facile da comprendere:

Immagina una cassetta di sicurezza, del tipo con un lembo di metallo su cui mettere un lucchetto per fissarlo. Immagina che il punto in cui collochi il lucchetto sia abbastanza grande da contenere due lucchetti. Per scambiare in modo sicuro inviare qualcosa a un'altra parte senza condividere i tasti del lucchetto, dovresti

1. inserisci la "Cosa" nella casella e bloccala con il lucchetto.
2. invia la casella bloccata all'altra parte.
3. mettono anche il loro lucchetto sul ciclo (in modo che ci siano due blocchi su di esso) e restituiscono la casella a doppio blocco
4. Togli il lucchetto e restituisci la casella ora isolata a loro
5. rimuovono il proprio lucchetto e aprono la scatola.

Con la crittografia i blocchi e le chiavi sono matematici, ma il concetto generale è vagamente come questo.

Molte delle risposte già fornite si affacciano sulla capacità di intercettazione dell'ISP o dell'NSA. Dai un'occhiata a Room 641A nel datacenter AT & T. Ci sono circa 10-20 strutture del genere che sono state installate negli Stati Uniti. Dai anche un'occhiata a One Wilshire edificio in cui le connessioni di 260 ISP convergono in un unico edificio. Quella posizione è una posizione privilegiata per una struttura di intercettazione.

Il fatto è un ISP (o l'apparecchiatura installata dalla NSA nell'ISP) può intercettare e MITM attaccare una connessione SSL e possono farlo abbastanza facilmente.

• Il tuo browser o sistema operativo ha oltre 500 trusted certificati installati in esso. Ciò significa che ti fidi implicitamente di qualsiasi sito web il cui certificato sia stato firmato da questo certificato.
• La NSA tramite l'ordine giudiziario FISA segreto può obbligare qualsiasi autorità di certificazione che opera negli Stati Uniti a fornire loro il certificato di origine. L'ordine del tribunale include una clausola speciale di non divulgazione che costringe la CA a tenere la bocca chiusa sotto pena di carcere se ne parla. Potrebbero anche non aver bisogno di farlo, hanno solo bisogno di convincere i produttori di browser ad accettare un one certificato di proprietà NSA come affidabile nel browser.
• Mentre il tuo traffico passa attraverso l'ISP, scambia la vera chiave pubblica del sito web con la chiave pubblica della NSA firmata dall'autorità di certificazione compromessa, eseguendo così l'attacco MITM.
• Il browser Web accetta questo certificato falso come attendibile e comunica la chiave di crittografia simmetrica per lo scambio all'NSA / ISP che ne conserva una copia e passa la stessa chiave sul sito Web.
• La tua sessione con il sito web viene decodificata in tempo reale con la chiave simmetrica compromessa.
• I dati decrittografati vengono inviati tramite la linea in fibra ottica al quartier generale e data center NSA nel seminterrato di Fort Meade. Questo esegue la scansione dei dati per centinaia o migliaia di parole chiave che potrebbero indicare vari tipi di minacce. Qualsiasi parola chiave viene contrassegnata in rosso per consentire a un analista di visualizzare e assegnare la priorità a eventuali ulteriori azioni. I dati finali vengono inviati a una delle strutture di archiviazione dati dell'NSA negli Stati Uniti. La nuova funzione di archiviazione è il centro dati dello Utah che è probabilmente già online poiché era in programma per essere online alla fine del mese scorso .

Ecco un diagramma di nsawatch.org:

In parole semplici: ci sono due diverse crittografie in atto:

• Innanzitutto c'è la crittografia della chiave pubblica / privata . Il client utilizza la chiave pubblica del server (inclusa nel certificato) per crittografare alcune informazioni che solo il server può decodificare utilizzando la sua chiave privata.

• In base a queste informazioni, viene derivata una chiave di sessione , che è nota solo al server e al client. Questa chiave di sessione viene utilizzata per crittografare tali dati.

Questo è un sommario molto approssimativo.

C'è molto di più in atto per prevenire vari tipi di attacco:

• Ad esempio, il client prova a convalidare il certificato del server per assicurarsi che non stia parlando con un uomo nel mezzo.
• Esistono diversi algoritmi e chiavi di lunghezza per le chiavi di sessione che devono essere negoziate
• I numeri casuali che vengono utilizzati solo una volta vengono utilizzati per impedire replay attack .
• Il protocollo di scambio chiavi Diffie-Hellman può essere utilizzato per generare una chiave di sessione che non può essere ricostruito da qualcuno che ha registrato la trasmissione di dati crittografati e ottiene l'accesso alla chiave privata del server in un secondo momento ( Segreto perfetto in avanti ).
• ...

Penso che le sei risposte siano già arrivate, gowenfawr lo spiega meglio. Per prima cosa leggi questo è semplicemente un addendum.

Su Diffie-Hellman

Diverse risposte menzionano gli scambi Diffie-Helman. Questi sono implementati in una minoranza di scambi. Uno scambio DH è firmato dalla chiave del server per prevenire un attacco MITM . Poiché la chiave non è crittografata su una chiave pubblica, non può essere ripristinata utilizzando una chiave privata acquisita contro il traffico acquisito di uno scambio di chiavi. Questa è l'idea di Perfect Foward Secrecy . OpenSSL offre scambi di chiavi "normali" e DH a seconda della configurazione.

Sulle catene MITM / Signature

Sia gli scambi a chiave pubblica che quelli DH impediscono a qualcuno di osservare la connessione e derivare la chiave. Questo è basato su un sacco di problemi di matematica che puoi cercare / guardare la risposta di Thomas per capire. Il problema con entrambi è l'attacco MITM. Per la crittografia a chiave pubblica, ciò viene risolto conoscendo la chiave pubblica in anticipo (anche se lo scambio viene osservato) o tramite una catena di certificati. Esempi: Mi fido di Alice, e Alice ha firmato la chiave di Bob che certifica che è davvero sua. Conosciuto anche come Google è certificato da ... err, Google. Sembra che siano in Firefox come loro CA. Quindi, random_bank's_ssl è firmato da Verisign, e il mio browser si fida di Verisign per emettere solo certificati legittimi.

Esistono problemi con questo modello quando ti imbatti in elementi come un'autorità di certificazione compromessa . In tal caso, diventa possibile un attacco MITM.

SSL si basa sulla crittografia a chiave pubblica. Un server che partecipa a SSL ha una coppia di chiavi , che ha componenti pubblici e privati.

Immagina di avere un lockbox speciale con due chiavi: una chiave può bloccare la casella e un'altra sbloccare la casella. Se il tuo amico desidera inviarti un messaggio segreto, ha solo bisogno della chiave di blocco e puoi mantenere il tasto di sblocco privato .

In effetti, puoi dare liberamente il tuo blocco a tutti. Decidi di lasciare fuori le copie dei tuoi lockbox speciali e i tasti di blocco sul portico in modo che chiunque possa avere una copia. Presto, tutti in tutta la tua città potranno inviarti messaggi segreti per posta. Hai reso la tua chiave di blocco pubblica .

Se il tuo amico Alice vuole mandarti un messaggio segreto, inserisce il suo messaggio in un lockbox e lo blocca con una copia della chiave pubblica di blocco. Il postmaster della tua città è molto sospettoso nei tuoi confronti e Alice, ma - anche se anche lui ha accesso alla tua chiave pubblica - non può aprire il lockbox. Solo tu, l'unico proprietario della chiave di sblocco privata, puoi aprire la casella bloccata da Alice.

Quindi, il tuo ISP (qui, il postmaster) ha accesso alla tua chiave pubblica , ma questo non li aiuta a decodificare i messaggi cifrati con la tua chiave pubblica. La tua chiave pubblica viene crittografata e solo la tua chiave privata viene decrittografata. Pertanto, la tua chiave privata non lascia mai il tuo possesso, quindi non può accedervi tranne te e quindi nessuno può intercettare i tuoi messaggi.

C'è un po 'più di protezione che ti offre SSL (ad esempio, supponiamo che il postmaster getti via la scatola di Alice e ti invii un nuovo messaggio fingendo di essere Alice), ma questo dovrebbe chiarire perché il tuo ISP non può semplicemente decifrare i tuoi messaggi.

Guarda Diffie Hellman: link

Per motivi di prestazioni, la connessione è crittografata con chiave simmetrica. Ma la chiave simmetrica viene generata durante la creazione della connessione e mai scambiata in chiaro, ma utilizzando la crittografia asimmetrica.

La crittografia asimmetrica è una tecnica di cui sono necessarie due chiavi: una pubblica e una privata. Ciò che viene criptato con la chiave pubblica deve essere decodificato con la chiave privata e viceversa. Quindi entrambi i computer possono scambiarsi dati in base alle altre chiavi pubbliche. Ma solo il proprietario della chiave privata corrispondente può decodificarlo. La chiave privata non viene mai scambiata, quindi, anche se hai annusato tutto, non puoi decodificare nulla. Queste tecniche sono espansive, quindi vengono utilizzate per scambiare la chiave per la chiave di crittografia simmetrica e non per i dati stessi.

Transport Layer Security (che è ciò che viene chiamato Secure Sockets Layer) comporta metodi di scambio sicuro di chiavi crittografiche su un canale di comunicazioni non sicuro (come Internet).

Sì, questo significa che l'ISP può vedere le informazioni sullo scambio di chiavi mentre passa avanti e indietro, e tuttavia ha ancora informazioni insufficienti per leggere il flusso di messaggi una volta stabilita una connessione sicura.

Un concetto molto strano, ed è un bel po 'di lavoro. L'esempio più comune di questo è chiamato Diffie-Hellman Key Exchange , ed è stato inventato solo nel 1970.

L'articolo di Wikipedia ha tutti i deliziosi dettagli matematici, ma trovo l'immagine qui sotto (da Wikimedia) che illustra perfettamente il concetto. Guardalo, pensaci, provalo anche tu stesso e scoprirai che non c'è modo per un avversario di ricavare la chiave privata dalle informazioni pubblicamente visualizzabili.

Se metto il mio cappello nero (non questo cappello nero ... in realtà anche quel cappello funziona):

Un ISP può semplicemente eseguire un attacco man-in-the-middle su uno qualsiasi dei download HTTP di applicazioni o delle relative patch e quindi aggiornare direttamente la catena di attendibilità del browser o aggiornarla indirettamente con un trojan autodistruggente.

Microsoft richiede solo che i driver siano firmati dal codice; le firme digitali per le applicazioni e i dati eseguibili equivalenti a un'applicazione non vengono applicate per impostazione predefinita *. La maggior parte dei sistemi operativi consumer non è migliore se semplicemente perché la codifica obbligatoria dell'applicazione (e la verifica dell'identità) costerebbe quanto basta per ridurre drasticamente le dimensioni del loro ecologia del software .

_{* Faccio un punto di non collegamento a Microsoft Answers a meno che non sia necessario. Le loro scimmie addestrate usano ovviamente macchine da scrivere rotte.}

La cosa fondamentale è la crittografia asimmetrica o a chiave pubblica. Significa che hai due chiavi, pubbliche e private, e una funzione matematica facile da calcolare in una direzione, ma molto, molto difficile da calcolare con l'altra.

Quindi, quando i server inviano la sua chiave pubblica, possiamo usare la chiave pubblica per crittografare facilmente le nostre cose, ma solo con l'altra chiave della coppia, la chiave privata in questo caso, puoi facilmente decrittografarla.

La EcoParty Conference ha annunciato uno strumento chiamato BEAST che decifra il traffico SSL3 / TLS1.0 e diminuisce, presumibilmente osservandolo.

Ecco un link alle notizie segnala

Sono certo che nei prossimi giorni sentiremo di più su questo, su soluzioni alternative e limitazioni.

Questa sezione di seguito verrà aggiornata man mano che vengono scoperte ulteriori informazioni

Questo hack presuppone che l'hacker possa in qualche modo vedere il tuo traffico di rete; sebbene spyware o attraverso un'acquisizione di rete. Le macchine con scarsa amministrazione e gli utenti Wifi sono i più probabili soliti sospetti ... anche se non sono limitati a tale caso d'uso.

Ci sono segnalazioni che possiamo mitigare questo rischio modificando l'elenco di cifrature SSL * / TLS 1.0 su RC4 e non supportando le combinazioni precedenti. Un'altra soluzione è quella di aumentare la lunghezza del token di autenticazione, che rallenterebbe l'attacco. Qui puoi modificare la configurazione dei cookie di autenticazione dell'appartenenza a Siteminder e ASP.net.

Solo così sai che questa vulnerabilità è esposta dalle stesse persone che hanno annunciato "Padding Attack on ASP.NET" l'anno scorso. Quel vecchio problema mette a rischio tutti i server Web IIS semplicemente accedendo, il che sembra essere più grave di questo attacco.

Do share any links you find that mention or confirm these vulnerable scenarios, or mitigations here. As it stands now, some of this is speculation and not vetted by Cryptology experts.

No, non terrebbero la chiave poiché la connessione che stai facendo è tra te e il sito di destinazione (ad es. Amazon), quindi l'ISP non avrebbe alcuna conoscenza della chiave.

La domanda più generale su come funziona SSL / TLS è la risposta qui .

Ci sono molte grandi risposte qui, specialmente quelle che parlano dei problemi oltre l'esecuzione di DH o ECDH (ad esempio, corruzione / installazione di cert client / cert hijacking, eccetera.)

Se stai ignorando la macchina locale e semplicemente ti preoccupi per il MITM, hai bisogno del pin DH / ECDH e SSL. Il pinning SSL sta diventando più comune, ma non è ancora oggi ubiquitario. Ciò significa che il tuo ISP può semplicemente fingere di essere il tuo server fintanto che ha un SSL valido nella tua catena di fiducia. Il pinning SSL garantisce che il certificato SSL utilizzato dal server a cui sei connesso sia il certificato del server che stai cercando di raggiungere.

Ancora una volta, se stai cercando di essere al sicuro dal governo o dagli hacker, questo non è abbastanza. Se stai cercando di impedire al tuo ISP di esaminare i tuoi dati, probabilmente è sufficiente.