Si può intercettare una connessione TLS correttamente implementata?

2

Supponendo una connessione TLS in cui sia il server che il client aderiscono perfettamente agli standard pertinenti.

  1. Un proxy HTTPS trasparente può intercettare la connessione TLS? (Supponendo che il certificato "mock CA" utilizzato dal proxy sia in Trusted Root sul client)

  2. (Forse fuori ambito non ne sei sicuro?) Se non quale (a) server e (b) browser sono i più vicini ad avere una tale implementazione?

Questa domanda è suggerita dalla seguente citazione riguardante il protocollo TLS e il software proxy Squid "Se [la sicurezza TLS] è stata effettivamente utilizzata correttamente, il bumping [ovvero l'intercettazione come descritta in Q1] non è nemmeno possibile. sono un numero crescente di transazioni che lo fanno in modo sempre più vicino a tale uso corretto. "

    
posta o.comp 04.09.2015 - 00:02
fonte

2 risposte

1

Can an transparent HTTPS proxy intercept the TLS connection? (Assuming the "mock CA" certificate used by the proxy is in Trusted Root on the client)

L'intercettazione HTTPS con un proxy (trasparente) è teoricamente possibile se si applicano tutte le seguenti condizioni:

  • La CA degli intercettori è affidabile (come previsto).
  • Nessun blocco del certificato o delle chiavi pubbliche è fatto. I browser sono a conoscenza dell'intercettazione legale SSL, ovvero del blocco del blocco se il certificato è stato firmato da una CA che è stata aggiunta manualmente (e attendibile). Ma applicazioni come Dropbox non sono a conoscenza di tale situazione e falliranno.
  • Non vengono utilizzati certificati client. L'utilizzo di certificati client richiede un vero TLS end-to-end, ovvero non può essere intercettato nemmeno da una CA attendibile. O almeno il certificato client originale non può essere inoltrato al server originale, il che rende quindi fallita l'autenticazione reciproca se il server verifica correttamente il certificato client.

(Possibly out of scope not quite sure?) If not which (a) server and (b) browser are closest to having such an implementation?

L'implementazione del server non è rilevante. L'implementazione del browser è rilevante solo per il comportamento speciale con il pinning descritto sopra. Almeno Firefox e Chrome mostrano questo comportamento speciale.

This question is prompted by the following quote...

Stai prendendo questa citazione senza mostrare la sua fonte e fuori dal contesto. Googling per questo mostra che è solo una citazione da una mail sulla mailing list di squid e non fa parte di qualsiasi documentazione. Inoltre è preceduto dalla frase "Sappi che ssl-bump è un attacco MITM su un protocollo di sicurezza", il che suggerisce che l'autore significhi intercettazione SSL senza consenso da parte dell'applicazione, cioè non accade quando un browser si fida esplicitamente dell'intercettazione CIRCA.

    
risposta data 04.09.2015 - 04:47
fonte
2

Riguardo alla tua prima domanda: la risposta dipende dalla definizione di "trasparente". Per me, l'intercettazione trasparente implicherebbe che nessun certificato o autorità di certificazione debba essere aggiunto manualmente dai client al "trust store" dei loro dispositivi. Finché questa condizione mantiene e il tuo browser controlla correttamente il certificato presentato per la sua validità , un utente malintenzionato non sarà in grado di intercettare la tua connessione, a meno che non riesca a svolgere una delle seguenti operazioni:

  • compromette una delle CA che il tuo dispositivo si fida di
  • in qualche modo ottenere una CA attendibile per firmare un certificato contraffatto per un sito che in realtà non possiede
  • manipola l'archivio fidato sul tuo dispositivo
  • o ottieni una chiave privata del server specifico.

Il motivo per cui questi sono gli unici vettori di attacco (anche in questo caso, se il controllo di validità è implementato correttamente sul lato client) è che il server presenterà un certificato (inclusa la chiave pubblica del server) a sua volta firmato con la chiave privata di CA . Il client controlla se la firma corrisponde alla chiave pubblica che ha memorizzato per la CA corrispondente e, in tal caso, avvia un handshake TLS / SSL con il server. È a un certo punto di questo protocollo di handshake che il client crittografa alcune informazioni specifiche della connessione con la chiave pubblica del server. Chiunque stia intercettando il messaggio dovrà quindi decifrare le informazioni con la chiave privata del server e rispedirle per dimostrare di non essere, in effetti, qualcun altro.

Riguardo alla tua seconda domanda, non so cosa si intenda esattamente nella frase che hai citato. Quello che so è che tutti i browser moderni più diffusi convalidano correttamente i certificati. C'è, tuttavia, un altro meccanismo interessante per quanto riguarda la sicurezza dei certificati che è non adottato da tutti i browser moderni, almeno per quanto ne so. Pinning chiave pubblica è un concetto relativo a trust al primo utilizzo : quando visiti per la prima volta un sito web, "pin" la chiave pubblica che ti è stata mostrata e controlla se è sempre lo stesso nelle successive visite alla pagina. Questo protegge dagli scenari di attacco 1 e 2 delineati sopra: non devi più preoccuparti di emettere certificati falsi se solo una volta hai visto il certificato legittimo. Il blocco della chiave pubblica non può essere eseguito solo per server specifici ma per qualsiasi CA nella catena di fiducia. Per rispondere alla tua domanda, Chrome e Firefox sono in grado di eseguire il blocco della chiave pubblica (e probabilmente ce ne sono altri, ma non ne conosco tutti).

    
risposta data 04.09.2015 - 01:19
fonte

Leggi altre domande sui tag