Gestione delle chiavi nei proxy di intercettazione?

Question

Gestione delle chiavi nei proxy di intercettazione?

#1 da (1 voti)

1

Sto leggendo la presentazione Black Hat di Jarmoc su SSL / TLS Interception Proxies and Transitive Trust . Ho alcune domande su alcune pratiche di gestione delle chiavi.

Nel documento, Jarmoc afferma:

To act as the server for the client-side SSL session, an interception proxy must have access to the private key that corresponds to the certificate it’s presenting. Because the server endpoint’s private key is unavailable, the interception proxy must generate a new certificate and key pair to use for this session.

Jarmoc non spiega il ragionamento alla base della sua affermazione "il proxy di intercettazione deve generare un nuovo certificato e una coppia di chiavi da utilizzare per la sessione." E non definisce una "sessione" di per sé .

Domanda : secondo la descrizione di Jarmoc di seguito, è corretto leggere una "sessione" è la connessione point-to-point [crittografata] tra l'utente e il proxy (e viceversa, il proxy e il vero server)?

... interception proxies insert themselves in the flow of traffic and terminate the client’s request. The interception proxy makes a second request on behalf of the client to the server. This behavior causes what was an end-to-end session to instead be two separate, but related, point-to-point sessions. The goal is to allow access to the plain-text session contents while transferring between the two encrypted sessions.

O dovrei leggere la "sessione" per avere il significato end-to-end?

Possono "multiple connessioni da un singolo utente" (flusso da utente a proxy) e "connessioni da più utenti" (flusso da proxy a server) essere multiplexate in una singola sessione?

Domanda : perché un proxy di intercettazione deve generare una coppia di chiavi nuova e un certificato per ogni sessione?

Ecco i casi d'uso che stavo correndo, e non vedo il vantaggio di chiavi e certificati distinti:

due utenti distinti visitano ciascuno example.com .
un singolo utente visita example.com , chiude il browser, quindi visita nuovamente example.com .

Fornire lo stesso certificato e la stessa chiave pubblica per example.com è il modo in cui le cose funzionano senza un proxy di intercettazione. In che modo un certificato e una chiave pubblica distinti per ogni visitatore e visita migliorano il paesaggio?

Ho sperimentato quest'ultimo, e posso dirti che non c'è nulla di "furtivo" nella pratica (specialmente quando la pagina web ha molti link esterni). CertPatrol ha lanciato così tante finestre di avviso che il browser è diventato inutilizzabile.

Domanda : cosa c'è di sbagliato con la certificazione di una singola chiave privata (per esempio, 7 o 30 giorni) e quindi l'emissione di tutti i certificati del server utilizzando la chiave singola?

Generare chiavi al volo è costoso e può portare a un DoS sotto carico. Poiché la pratica può distruggere la disponibilità, non vedo il vantaggio.

Non importa se c'è 1 chiave privata o 10.000 chiavi private. Un compromesso / compromissione chiave dell'ospite al proxy significa l'uscita chiave. Non importa se ce ne sono 1 o 10.000. Ancora una volta, non vedo il vantaggio.

Se qualcosa di più di una relazione 1: 1 non è buona, perché la pratica è utilizzata nei certificati di firma intermedi e nelle CA subordinate?

Domanda : Jarmoc significa che ogni connessione di rete (indirizzo IP sorgente) dovrebbe ricevere la propria chiave privata utilizzata per tutti i certificati? (Qui "sessione" indica l'interazione tra l'utente e il proxy).

Se il proxy sta per riutilizzare le chiavi private per utente, perché non è possibile riutilizzare una chiave privata per tutti gli utenti?

In che modo il proxy gestisce le connessioni NAT, in cui gli utenti sono raggruppati in un unico indirizzo IP diretto?

(Se c'è qualcosa di sbagliato nel riutilizzo, allora i certificati di firma intermedia probabilmente violano qualsiasi regola citata perché la chiave di firma dell'intestatario certifica un numero di certificati di entità finale.)

Domanda : quali sono i detrimenti per il riutilizzo della chiave privata tra le sessioni?

La chiave privata riutilizza gli strumenti come strumenti come HTTPS Everywhere e CertPatrol; e strategie di diversificazione della sicurezza come la chiave pubblica e le prospettive?

La mia preoccupazione qui è un'implementazione ingenua dell'appartenenza di chiavi pubbliche all'interno di un'organizzazione, in cui l'implementazione considera solo la {chiave pubblica} e non la coppia {host, chiave pubblica}. Ma l'implementazione ingenua non può rompersi nella pratica fintanto che la chiave privata del proxy rimane segreta. È difficile dirlo senza un'implementazione concreta.

proxy key-management tls

posta jww 14.02.2014 - 05:51

fonte

1 risposta

Leggi altre domande sui tag proxy key-management tls

Quali tipi di attacchi di hacking si verificano a fianco di un attacco DOS o DDOS? [chiuso] Come usare ESSIV per evitare di vedere ripetizioni?

score 1 · Answer 1

Question: Why must an interception proxy generate a new key pair and certificate for each session?

Spero che non significhi che dovrebbe essere creato un nuovo (e diverso) certificato per ogni utente e sessione. A mio avviso, dice solo che non può semplicemente usare il certificato originale perché non ha accesso alla sua chiave privata. A mio parere è sufficiente creare un nuovo certificato proxy ogni volta che incontra un nuovo certificato server, ad es. stesso certificato proxy per tutti gli utenti e le sessioni che accedono allo stesso host. Questo comportamento è anche descritto nel documento, sebbene criticato. Se generi un nuovo certificato ogni volta che devi assicurarti che è abbastanza simile al precedente, perché il browser si lamenterà se ottiene un certificato diverso per lo stesso host all'interno della stessa sessione del browser (e mantenendo il browser aperto per settimane non è più raro). E, naturalmente, dovresti rilasciare un nuovo certificato proxy se il certificato del server cambia.

Question: according to Jarmoc's description below, is it fair to read a "session" is the [encrypted] point-to-point connection between the user and the proxy (and conversely, the proxy and the real server)? .... Or should I read the "session" has the end-to-end meaning?

Penso che dovrebbe essere interpretato come relazione end-to-end, ad es. la connessione iniziale da client a server tramite proxy avvia una nuova sessione, ma ulteriori connessioni tra queste parti sono solo la continuazione della stessa sessione. Se ogni connessione è considerata una sessione separata con certificati appena creati (diversi dall'ultimo per la stessa connessione client-proxy-server), riceviamo solo i problemi citati con la verifica nel client.

Question: what is wrong with certifying a single private key (for say, 7 or 30 days), and then issuing all server certificates using the single key?

Avere una singola coppia di chiavi per tutti i certificati proxy funzionerà, ma la tua idea di generare una nuova coppia di chiavi potrebbe aver bisogno di un raffinamento per essere sicuro che il certificato non cambi troppo all'interno di una sessione del browser. E, non sono d'accordo con il giornale. A mio parere, la coppia di chiavi per il certificato proxy può essere riutilizzata tanto quanto la coppia di chiavi per la CA proxy verrà riutilizzata. E quest'ultimo deve essere, perché altrimenti dovresti rilasciare una nuova CA proxy per tutto il tempo e inserirla nel browser in modo che i tuoi certificati proxy possano essere verificati. Inoltre, è anche comune riutilizzare la stessa coppia di chiavi quando si estendono i certificati "reali".

Non penso che l'approccio del documento di generazione di una nuova coppia di chiavi per ogni certificato e per ogni sessione possa funzionare. Perché, in questo modo il browser ottiene diversi certificati per lo stesso host all'interno di una singola sessione del browser. Il browser non piace e si lamenterà di ciò. Inoltre, poiché il proxy non è in grado di rilevare la fine e l'inizio delle sessioni del browser, non sa quando utilizzare una nuova coppia di chiavi.

Question: does Jarmoc mean that each network connection (source IP address) should receive its own private key used for all certificates? (Here "session" means the interaction between the user and the proxy).

No, non la penso così. Penso che il punto principale sia che non gli piace che la stessa coppia di chiavi venga riutilizzata troppo. Come ho detto, non sono d'accordo con la carta in questo punto.

Question: what are the detriments to private key re-use across sessions?

Certificate Patrol, Perspectives e altre forme di pinning dei certificati potrebbero comunque reclamare, perché si esegue un attacco uomo nel mezzo e il certificato generato differisce da quello originale. Ma dalla mia esperienza, almeno il blocco dei certificati in Chrome non si lamenta, se hai aggiunto la CA proxy come affidabile. Ma si lamenterà se la CA proxy non viene aggiunta in modo esplicito ma firmata da una CA integrata attendibile.

Il blocco dei certificati, almeno in Chrome, viene eseguito mediante l'impronta digitale della chiave pubblica. Quindi tali tecniche potrebbero fallire se ottengono la stessa chiave pubblica per certificati diversi ma ne dubito. Dovrebbero protestare solo se ottengono una chiave pubblica diversa dal previsto. Quindi dalla mia esperienza (usiamo tali tecniche e riutilizza le chiavi) riutilizzare le chiavi non mostra problemi nei browser.