Può un pacchetto di risposta del server decifra MITM HTTPS?

Ci sono due problemi separati menzionati in questa domanda: autenticazione e crittografia di sessione.

Per quanto riguarda l'intercettazione della risposta iniziale, si tratta di un problema di crittografia della sessione. Ogni sessione tra il client e il server è protetta utilizzando una chiave diversa. L'algoritmo di scambio delle chiavi (a seconda di quale viene utilizzato) garantisce che solo una delle parti riceva le chiavi utilizzate per proteggere la trasmissione.

I dettagli tecnici sono già stati spiegati nelle risposte a Come funziona SSL / TLS? , ma in breve vengono utilizzate coppie di chiavi effimere. Sono separati dalla chiave pubblica inviata dal server nel certificato.

La chiave pubblica del server (inclusa nel certificato) viene invece utilizzata per l'autenticazione (nella crittografia a chiave pubblica quando si crittografa i dati con una chiave privata che si sta effettivamente firmando non crittografando, chiunque può decrittografarla con il chiave pubblica pubblicamente nota.

Per l'autenticazione del client è anche possibile utilizzare un'autenticazione basata su chiave, ma questo scenario è molto meno comune. Solitamente si autentica usando la password o qualche altro metodo su un canale sicuro già stabilito. In questo scenario non c'è bisogno o modo di "fingere di essere il client previsto " perché al momento di iniziare la connessione non c'è ancora nessuna idea del client previsto .

Come ha scritto @techraf, ci sono due cose fornite da TLS: autenticazione e crittografia.

Basically wondering if you can pretend to be the client, instead of most MITM where the attacker pretends to be the server.

Tenendolo a mente, concentriamoci sull'autenticazione.

La tipica comunicazione HTTPS su Internet viene utilizzata per assicurare ai client che il server è quello che afferma di essere, ad es. e-banca. Tuttavia, nel tipico scenario Internet, un server non autentica i client tramite HTTPS. In questo esempio di banca elettronica, devi fornire le credenziali in modo che la banca sappia chi sei (non il tuo certificato).

Sul livello di crittografia: dopo l'iniziale handshake TLS, una chiave simmetrica specifica della sessione viene negoziata tra il client e il server e è la chiave simmetrica che viene quindi utilizzata per crittografare tutto il traffico sulla connessione HTTP in entrambi indicazioni .

EDIT: quando ci si trova nel mezzo del canale di comunicazione e si interrompe la connessione TLS, è possibile impersonare entrambi i lati della comunicazione: un client e un server. Qual è uno scenario tipico di MItM, ma proprio come hai scritto tu: solitamente vogliamo ingannare i client, non i server.

Una risorsa utile su questo è I primi pochi millisecondi di una connessione HTTPS .

La crittografia a chiave pubblica viene utilizzata per autenticare il server sul client. Cioè, il client non può quindi essere ingannato a connettersi a un MITM che finge di essere bank.example.com perché solo il% reale di% co_de avrà la chiave privata.

Una volta stabilito questo, vengono stabilite una coppia di chiavi simmetriche. Uno per il traffico da client a server e un altro per il traffico da server a client.

Un MITM non può decodificare il server sul traffico del cliente perché non ha conoscenza della chiave privata concordata.

Una panoramica molto semplicistica è:

• Il client genera un ClientHello.random e lo invia al server durante l'iniziale handshake.
• Il server genera un ServerHello.random e lo invia al client durante l'iniziale handshake.
• Il client genera un "pre-master secret" da 48 byte e lo invia al server crittografato dalla chiave pubblica del server.
• Un master secret viene calcolato utilizzando la formula bank.example.com
• PRF è una miscela di MD5 e SHA-1.
• Un blocco chiave viene calcolato utilizzando master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)
• Il keyblock è suddiviso in sezioni per fornire chiavi asimmetriche separate per il traffico in ogni direzione (insieme ad alcuni IV e MAC che puoi ignorare per rispondere alla tua domanda).