Client che richiede la nostra chiave privata SSL per configurare il Load Balancer che raggiunge il nostro server. Ha senso?

Question

Client che richiede la nostra chiave privata SSL per configurare il Load Balancer che raggiunge il nostro server. Ha senso?

#1 da (5 voti)

5

Sto affrontando una situazione insolita, spero che tu possa chiarire questo per me.

Gestiamo alcune applicazioni accessibili tramite le richieste HTTPS sulla porta 443 del nostro server X.

Abbiamo un nuovo client che dovrebbe anche raggiungerci attraverso la nostra porta 443 sul server X. Tuttavia il client utilizzerà una specie di Load Balancer (proxy + snat in base a loro) per farlo.

Per consentire a Load Balancer di connetterci, il client richiede la nostra coppia di certificati pubblici + chiave privata , altrimenti Load Balancer reimposta le connessioni con noi a causa di una mancata corrispondenza delle coppie di chiavi.

Questo è completamente assurdo per me, dal momento che il privato dovrebbe essere semplicemente privato, non posso condividerlo. È contro ogni politica di sicurezza che conosco.

La parte curiosa è che hanno fornito una documentazione che sembra indicare esattamente questo. Questo è il link:

link

Sembra che utilizzino una tecnologia chiamata Big IP e richiede la chiave privata in base a questa dichiarazione sul link precedente:

Azioni consigliate È possibile correggere questo errore configurando i profili SSL interessati con la coppia di chiavi del certificato presentata dal server di destinazione . Per fare ciò, eseguire le seguenti procedure ...

Qualcuno ha affrontato una situazione simile a questa?

Anche la loro tecnologia lo richiede davvero, non sono a conoscenza di alcuna 'API' fornita da HTTPS che gestisca il traffico precedentemente cifrato da un Load Balancer, quindi sono piuttosto confuso.

Ogni tipo di chiarimento è utile. Grazie a tutti.

apache openssl tls ssl-interception

posta vinicius.olifer 21.07.2017 - 15:57

fonte

1 risposta

Leggi altre domande sui tag apache openssl tls ssl-interception

MITM durante il cambio di chiave / impronta digitale legittima Come proteggere l'API REST dalla scansione durante la pubblicazione di contenuti pubblici?

score 5 · Accepted Answer

Sembra che stiano utilizzando la funzionalità Proxy SSL di F5s, il che significa che l'appliance F5 non è il client dell'applicazione (non stanno terminando nell'appliance, ma stanno passando), ma offre loro la possibilità di decodificare il dispositivo. il traffico per determinare se può essere memorizzato nella cache e riutilizzato per migliorare le prestazioni. E.G., se possono memorizzare alcune cose al loro margine, possono restituirli ai propri utenti senza dover effettuare ulteriori round trip completi ai server di origine. Se non riescono a decodificare il traffico, non possono memorizzarlo nella cache.

Questo, come sai chiaramente, ha implicazioni sulla sicurezza. Se insistono su questa architettura, e i dati e il rischio sono solo loro e loro, allora hai bisogno di un certificato specifico per la loro applicazione che sia non condiviso per proteggere i dati di uno dei tuoi altri clienti. È quindi possibile installare il certificato sui server applicazioni che si ospitano per loro e possono installarlo sul proprio F5, e fintanto che non è possibile che il certificato venga usato accidentalmente per gli altri clienti, non vi è quindi alcun rischio per tu.

SE , tuttavia, l'applicazione è non progettata per consentire che vengano separati in questo modo e il certificato non può essere isolato solo per il loro uso, quindi a mio parere, devi rifiutare. Non è possibile fornire loro una chiave che consenta loro di accedere potenzialmente ad altri dati dei clienti in qualsiasi circostanza.