Limitazioni dell'ispezione TLS quando si utilizza Diffie-Hellman

Question

Limitazioni dell'ispezione TLS quando si utilizza Diffie-Hellman

#1 da (3 voti)

0

Sono a conoscenza del fatto che TLS Inspection può essere eseguito in due modi diversi:

1o approccio: utilizzo di un server proxy che negozia TLS con entrambe le estremità.
- In questo scenario, ci sarebbero 2 diversi canali TLS (Client < - > Proxy < - > Server)
- Se le implementazioni TLS non standard sono utilizzate dal client / server o devono essere soddisfatti requisiti specifici nella negoziazione TLS, il Proxy dovrebbe avere caratteristiche specifiche che lo consentano.
2o approccio: utilizzo di un elemento intermedio contenente i segreti necessari per decodificare la negoziazione della chiave condivisa TLS (ad esempio, la chiave privata associata al certificato del server) con la possibilità di crittografare nuovamente (utilizzando il certificato del server) e inoltrare il traffico al server.
- In questo scenario, Client e Server non vedrebbero il server intermedio e sarebbe essenzialmente un canale TLS univoco, anche se l'elemento intermedio può vedere e bloccare il traffico sospetto.
- L'elemento intermedio non avrebbe bisogno di implementare ulteriori funzionalità, in quanto agisce solo ascoltando e inoltrando / bloccando.

Quando una cryptosuite che implementa DH o ECDH viene utilizzata su una comunicazione TLS, è possibile utilizzare il 2 ° approccio? Da quello che so, lo scambio di chiavi in DH rende impossibile per un "intercettatore" capire quale sia il segreto condiviso, poiché le chiavi private RSA sono utilizzate solo come mezzo per autenticare il server.

A seconda della cryptosuite utilizzata, TLS Inspection dovrebbe essere limitato al 1o approccio?

tls diffie-hellman

posta Jausk 19.02.2018 - 10:42

fonte

1 risposta

Leggi altre domande sui tag tls diffie-hellman

Devo scaricare e aprire un allegato di posta elettronica, ma come verificare se è sicuro prima? È possibile annusare gli URL HTTPS? [duplicare]

score 3 · Accepted Answer

Entrambi i tuoi approcci descrivono essenzialmente la stessa cosa: c'è un sistema intermedio che termina TLS e hai essenzialmente due connessioni TLS: una da questo middlebox al client e una dal middlebox al server.

L'unica differenza è che nel secondo scenario la casella centrale ha accesso al certificato e alla chiave privata del server e quindi può impersonare completamente il server senza modifiche al client. Anche se non descrivi più dettagliatamente il primo caso, suppongo che in questo caso i certificati vengano creati dinamicamente dal proxy e firmati da una CA esplicitamente fidata dal cliente. Questo primo caso può essere di solito trovato in un firewall che dovrebbe consentire al client di accedere a molti siti su Internet mentre il secondo caso viene utilizzato per proteggere un server specifico (ad esempio utilizzando un firewall per applicazioni Web).

Poiché in entrambi i casi si hanno due connessioni TLS separate e indipendenti, non c'è nulla di speciale con DH, cioè entrambe le connessioni possono utilizzare lo scambio di chiavi DH.

Ma c'è un terzo scenario in cui un sistema di rilevamento delle intrusioni (IDS) ottiene il traffico scambiato tra client e server e dovrebbe rilevare passivamente attacchi contro questo server, cioè senza essere l'endpoint TLS. In questo caso c'è solo una singola connessione TLS end-to-end tra client e server. E per decodificare il traffico per l'analisi, l'IDS ha tradizionalmente bisogno di accedere al server delle chiavi private, ma funziona solo con lo scambio di chiavi RSA. Per rendere tale analisi passiva possibile con DH, l'IDS dovrebbe avere accesso al segreto principale di ogni nuova connessione, cioè in qualche modo il server deve fornire all'IDS queste informazioni. E questo è molto più complesso del semplice fornire l'IDS con la chiave privata statica del certificato.