Apache: convalida la catena di fiducia SSL per prevenire gli attacchi MITM?

11

Mi sono appena reso conto che gli attacchi man-in-the-middle SSL sono molto più comuni di quanto pensassi, specialmente negli ambienti aziendali. Ho sentito parlare di me stesso e ho visto diverse aziende che dispongono di un server proxy SSL trasparente. Tutti i client sono configurati per fidarsi del certificato di questo proxy. Ciò significa fondamentalmente che il datore di lavoro in teoria può intercettare anche il traffico crittografato SSL senza che vengano visualizzati avvisi nel browser. Come accennato in precedenza, i client arrivano con il certificato di fiducia. Questo può essere rivelato solo convalidando manualmente il certificato che viene utilizzato.

Per me, sembra che il datore di lavoro utilizzi la sua posizione superiore per spiare il traffico SSL del dipendente. Per me, questo rende l'intero concetto di SSL inaffidabile. Io stesso ho testato con successo una configurazione simile usando mitmproxy e sono stato in grado di leggere la comunicazione tra il client e il mio server bancario elettronico. Questa è un'informazione che non dovrebbe essere rivelata a nessuno.

Pertanto, la mia domanda è piuttosto semplice: come posso convalidare la catena di fiducia sul lato server? Voglio assicurarmi che il client usi il certificato del mio server e solo una catena di fiducia. Mi chiedo se ciò può essere ottenuto con la configurazione SSL di Apache? Ciò sarebbe conveniente in quanto potrebbe essere facilmente applicato a molte applicazioni. Se ciò non è possibile, qualcuno conosce un modo per farlo in PHP? O hai altri suggerimenti?

— aileron79
fonte

1

Va bene se il datore di lavoro vede il traffico dei dipendenti. Stai utilizzando le risorse del datore di lavoro (pc, connessioni di rete, ecc.), Queste non sono tue. E se temi che emplyer possa vedere i dati che trasmetti al tuo conto bancario, fallo a casa, non al lavoro. E i tentativi di violare la politica di sicurezza aziendale possono essere oggetto di un tribunale contro di voi.

— Crypt32

2

In molte aziende europee l'uso privato delle apparecchiature per ufficio è regolato nel contratto di lavoro. Nella compagnia in cui lavoro posso navigare in privato, questo non è un problema. Ci sono eccezioni come il porno, la condivisione di file, ecc. Allo stesso tempo ci sono leggi che vietano alle aziende di spiare i propri dipendenti. Pertanto, per me - e molti altri - NON va bene quando i datori di lavoro intercettano il traffico dei dipendenti in quanto ciò è chiaramente vietato mentre la navigazione privata è tollerata in molte aziende.

— Aileron79,

2

La maggior parte delle (secondo la mia esperienza) le workstation di proprietà del governo degli Stati Uniti includono questi due avvisi ad ogni accesso: "Le comunicazioni che utilizzano o i dati memorizzati su questo IS non sono private, sono soggette a monitoraggio, intercettazione e ricerca di routine e possono essere divulgate o utilizzate per qualsiasi scopo autorizzato USG. Questo IS include misure di sicurezza (ad es., autenticazione e controlli di accesso) per proteggere gli interessi USG, non per il tuo vantaggio personale o la tua privacy. " L'uso di questi sistemi è spesso coperto da un accordo firmato che stipula lo stesso. Il dettaglio chiave è che il proprietario del sistema si sta proteggendo da te.

— Randall,

Questa è una delle molte differenze tra Stati Uniti ed Europa. I termini @Randall citati sopra sono illegali nella maggior parte dei paesi europei.

— Aileron79,

I termini che ho citato sono incompleti, altri termini elencano attività che non devono essere monitorate esplicitamente. Non riesco a trovare alcun riferimento che indichi che i datori di lavoro europei non possono rendere tali precondizioni una condizione per l'utilizzo dei loro computer (lavoro per un'azienda che opera in Europa, istituendo tali processi di monitoraggio, anche se lavoro per una divisione che non fa affari in Europa), ma può trovare riferimenti che suggeriscono che tali termini non sono illegali purché siano espliciti e trasparenti.

— Randall,

9

Penso che questa domanda sarebbe più appropriata per security.stackexchange.com in cui l'argomento del MITM è discusso in molte domande. Ma in ogni caso:

La convalida del certificato del server viene eseguita solo sul client e non può essere spostata in qualche modo sul server poiché il punto di convalida del certificato sul client è che i client devono assicurarsi che stia parlando con il server corretto e non possono fidarsi del server (non attendibile) per prendere questa decisione per il client.

In caso di intercettazione SSL il client TLS dal punto di vista del server è il firewall / AV intercettante SSL. Pertanto, il problema sul lato server è rilevare se sta parlando con il client previsto (il browser) o meno (il firewall / AV). Il modo più sicuro per farlo è utilizzare i certificati client per autenticare il client - e in effetti l'intercettazione SSL non funzionerà se si utilizza l'autenticazione client, ovvero l'handshake TLS fallirà poiché il MITM non è in grado di fornire il certificato client previsto.

Solo, i certificati client sono usati raramente. Inoltre, una stretta di mano TLS non riuscita non significherebbe che il client può comunicare con il server senza intercettazione SSL ma che il client non può affatto comunicare con il server. Un modo alternativo sarebbe quello di utilizzare alcune euristiche per rilevare il tipo di client TLS basato sull'impronta digitale dell'handshake TLS, ovvero il tipo e l'ordine delle cifre, l'uso di estensioni specifiche ... Mentre un proxy intercettante SSL potrebbe in teoria emulare l'originale ClientHello perfettamente, la maggior parte no. Vedere anche Rileva man-in-the-middle sul lato server per HTTPS o l' euristica dell'implementazione TLS della sezione III in Impatto sulla sicurezza dell'intercettazione HTTPS .

— Steffen Ullrich
fonte

14

Per me, sembra che il datore di lavoro utilizzi la sua posizione superiore per spiare il traffico SSL del dipendente. Per me, questo rende l'intero concetto di SSL inaffidabile

Il problema non è nel concetto di SSL né nell'implementazione tecnica, ma piuttosto che qualcun altro ha il pieno controllo su un end-point della connessione, ovvero la workstation.
Questa è la radice dell'effettivo rischio per la sicurezza ...

Dal punto di vista della sicurezza, è la tua workstation a essere compromessa a spezzare la catena di fiducia che, in circostanze normali, impedisce a un MITM di avere successo.

Come posso convalidare la catena di fiducia sul lato server?

Non puoi. Questo è fatto lato client.

A seconda del caso d'uso, ciò che è possibile fare è Pinning della chiave pubblica HTTP RFC 7469 in cui è stata inviata un'intestazione aggiuntiva al client con un elenco (hash) dei certificati SSL effettivi o delle CA utilizzate.

— HBruijn
fonte

4

HPKP non aiuterà poiché verrà ignorato dai browser se il certificato è firmato da un'autorità di certificazione esplicitamente aggiunta. Questo viene fatto specificamente per consentire l'intercettazione SSL da parte di una parte fidata, ovvero un firewall aziendale o un AV desktop locale (molti lo fanno su intercettazione SSL).

— Steffen Ullrich,

2

Sei assolutamente corretto lì: §2.6 dall'RFC: "È accettabile consentire la disabilitazione della convalida dei pin per alcuni host in base alla politica locale. Ad esempio, un UA può disabilitare la convalida dei pin per gli host bloccati la cui catena di certificati convalidata termina all'indirizzo un ancoraggio di fiducia definito dall'utente, piuttosto che un ancoraggio di fiducia incorporato in UA (o piattaforma sottostante). "

— HBruijn,

3

Questo è il modo sbagliato. Non il server controlla la catena di fiducia. È il cliente. Quindi il motivo per cui la società usa questo modo è quello di proteggere l'ambiente aziendale e controllare cosa sta facendo il dipendente nel suo orario di lavoro.

— beli3ver
fonte

Bene, sì, sono consapevole che questo probabilmente non può essere prevenuto solo sul lato server. Tuttavia, alcuni JS sul lato client potrebbero anche essere ingannati. A proposito, lo spionaggio dei dipendenti è illegale nella maggior parte dei paesi europei. Come gestore di un sito web voglio evitare che i miei clienti vengano ingannati, quindi mi chiedo se esiste un modo per convalidare la catena di fiducia in modo sicuro.

— Alileron79,

Forse non è permesso. Ma la maggior parte delle aziende non spiano i dipendenti, che vogliono solo proteggere la propria rete aziendale e la maggior parte dei webfilter o scanner deve interrompere la connessione SSL per verificarlo. Quindi questo è un uomo legale nel mezzo dell'attacco

— beli3ver

Capisco il tuo punto. Tuttavia, questa domanda riguarda come posso garantire che una connessione HTTPS sia crittografata end-to-end. L'impostazione che ho descritto sopra è molto comune negli ambienti aziendali, ma lo stesso tipo di attacco potrebbe essere utilizzato dai ragazzi gelosi per spiare le loro amiche o dai proprietari che intercettano il traffico degli inquilini. Queste persone devono ancora essere ingannate nell'installazione di un certificato, ma questa è la parte facile. Tuttavia, questo è illegale - e mi chiedo ancora se esiste un modo per garantire che una connessione HTTPS sia davvero crittografata e2e.

— Aileron79,

3

Non e possibile. Quando il certificato radice è stato modificato sul client, non è possibile verificarlo. Il server non effettua il controllo, il client effettua il controllo.

— beli3ver

3

Si POTREBBE (tipo di), ma la vera domanda è se si DOVREBBE .

Ma attenzione, non è affatto semplice come cambiare una bandiera in apache.conf.

Inoltre, poiché l '"attaccante" (ad esempio il datore di lavoro) controlla il computer client, possono sempre ostacolare i tuoi tentativi se sono propensi a investire abbastanza sforzo (il lato positivo, a meno che tu non sia un pesce molto grosso, molto probabilmente non lo sono incline, quindi raggiungerai il tuo obiettivo che i tuoi utenti non saranno in grado di connettersi a te a meno che non sia sicuro))

potresti reimplementare TLS in javascript e fare il tuo controllo lì se il certificato a cui è collegato il client è il certificato del tuo sito web.
se sei fortunato , l'utente potrebbe utilizzare un browser in cui Javascript lato client può ottenere informazioni sul certificato remoto utilizzato (e quindi verificarlo facilmente rispetto al valore hardcoded del certificato del tuo server).
potresti usare JavaScript per eseguire la tua crittografia personalizzata . Quindi, anche se il malvagio TLS MiTM dell'azienda riuscisse, non gli avrebbe comunque consentito l'accesso ai tuoi dati. Naturalmente, se sono sufficientemente interessati (e poiché controllano il client), possono semplicemente sostituire al volo il tuo javascript sicuro con il proprio che registra (o modifica) tutte le informazioni in transito.

Inoltre, poiché le aziende che utilizzano proxy TLS MiTM di solito controllano completamente anche il computer client, possono facilmente installare lo schermo e il keylogger per registrare semplicemente video di tutto ciò che l'utente vede e registrare tutte le battiture (e i movimenti del mouse) che l'utente digita. Come puoi vedere, quando un utente malintenzionato È il client, non esiste un modo assolutamente sicuro per ingannarlo. È davvero solo una domanda di quanto si preoccuperanno ... E alcune delle soluzioni sopra potrebbero essere abbastanza buone per te.

— Matija Nalis
fonte

" potresti reimplementare TLS in javascript " Come? Dove?

— curiousguy,

@curiousguy che il testo qouted è un link - fai clic su di esso e ti porterà a un'altra domanda e risposta, e infine al progetto digitalbazaar / Forge

— Matija Nalis,

Quindi, quando è utilizzabile? Per quale scopo?

— curiousguy,

@curiousguy tra molte altre cose, specialmente per gli scopi posti in questa domanda Serverfault. Quando hai il tuo JS TLS in esecuzione sul client, quel client JS saprà esattamente a quale server TLS è stato connesso il client (ed è la sua chiave pubblica). Quindi puoi confrontare quella chiave pubblica con la chiave pubblica del server autorizzato (anch'essa codificata nel tuo JS) e se saprai se sono uguali. Se non sono uguali, la tua connessione è stata dirottata da MiTM.

— Matija Nalis,