Qual è la migliore pratica per MitMing del traffico https per distinguere i certificati autofirmati?

0

La mia organizzazione è preoccupata per virus e attacchi che entrano nella nostra rete.

Poiché il traffico http è stato dichiarato non gradito da alcuni produttori di browser e da altre parti, diventa sempre più difficile eseguire tale funzione.

Poiché molti siti al giorno d'oggi bloccano l'accesso http:// (invece semplicemente reindirizzando alla loro versione https:// ), siamo costretti a fare MitM per continuare efficacemente le nostre scansioni.

Il che significa che dobbiamo eseguire l'autenticazione del certificato su base centrale, poiché sarà il nostro proxy che eseguirà il TLS sul lato client.

Non desiderando bloccare i certificati autofirmati di terze parti, in tale configurazione di MitM, c'è qualcosa che possiamo fare per garantire che i nostri utenti possano distinguere tra siti Web downstream con certificati autofirmati e basati su CA ? Ad esempio, se il nostro upstream stesso fa un MitM sul nostro traffico, c'è un modo per far sapere al nostro utente, senza bloccare la connessione (ad esempio, lasciarli decidere)?

    
posta cnst 12.12.2015 - 07:15
fonte

1 risposta

1

Non penso che sia una buona idea lasciare che gli utenti decidano quali certificati sono belli e quali no o per accettare certificati autofirmati o non validi in generale. Almeno non credo che molti utenti capiscano i problemi sottostanti e sarebbero in grado di prendere la decisione giusta. Ma forse tutti i tuoi utenti hanno una comprensione più profonda dell'argomento e dei problemi coinvolti quando prendono una decisione sbagliata, quindi ecco un modo per trasferire almeno parte di queste informazioni all'utente:

  • Per le corrette connessioni TLS che hanno un certificato valido, il nuovo certificato generato sul dispositivo di intercettazione SSL sarà firmato dalla CA proxy del dispositivo. In questo modo non si verificano avvisi nel browser finché la CA proxy viene importata come attendibile.
  • Le connessioni TLS con un certificato non valido (scaduto, soggetto sbagliato, autofirmato ...) non saranno firmate dalla CA proxy ma verrà creato un certificato autofirmato che conterrà la maggior parte delle informazioni originali (soggetto , scadenza...). Ciò provocherà un avviso all'interno del browser perché non è firmato da una CA attendibile e l'utente può esaminare i dettagli del certificato e decidere di accettarlo comunque.

In questo modo solo i certificati validi vengono accettati silenziosamente dal browser e tutti gli altri richiedono l'intervento manuale dell'utente. Si noti che sono abbastanza sicuro che non tutti i dispositivi di intercettazione SSL gestiranno certificati non validi nel modo in cui ho descritto, quindi è necessario verificare i dettagli con il prodotto specifico o l'implementazione che si ha in mente. Inoltre, non tutte le informazioni sui motivi per cui un certificato non è valido vengono trasferite in questo modo. Soprattutto non è possibile distinguere tra certificati e certificati originariamente autofirmati con una catena di trust altrimenti interrotta (come certificati di catena mancanti o CA radice non attendibile) in questo modo e non si ha modo di esaminare l'emittente originale del certificato.

Ma ancora una volta, non raccomando di fidarsi completamente degli utenti per decidere quali sono i certificati buoni e cattivi, quindi questa pratica dovrebbe essere limitata a pochi siti sbagliati. Dalla mia esperienza, i soli certificati autofirmati validi sono per i dispositivi locali (router, ecc.) E quindi di solito non dovrebbero essere influenzati dall'intercettazione SSL. I siti pubblici su Internet dovrebbero invece utilizzare le CA pubbliche e quasi tutti lo fanno. Se non lo fanno o lo fanno male, questi siti dovrebbero essere meglio bloccati. Dalla mia esperienza, i siti comuni su Internet non causeranno alcun problema perché ciò potrebbe causare problemi anche ai browser e perderebbero i visitatori in questo modo.

    
risposta data 12.12.2015 - 08:08
fonte

Leggi altre domande sui tag