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?