Dettagli di progettazione di crittografia TOR in profondità

3

Attualmente sto lottando con la comprensione dei dettagli di una connessione in tor, principalmente perché cerco di capire PCTCP . In questo documento gli autori sostengono che le modifiche sono locali al router di cipolla che utilizza PCTCP e che IPSec sostituisce completamente TLS nel senso degli obiettivi di sicurezza, integrità, riservatezza e autenticità.

Bene. Ho capito il principio base del routing della cipolla, ho capito Tor (credo) e ho capito l'intenzione in PCTCP, ma quando si sostituisce TLS con IPSec, imho le modifiche possono non essere locali al router cipolle usando PCTCP a meno che non abbia una comprensione errata dell'architettura di sicurezza TOR.

Tor usa il routing della cipolla, il che significa che il proxy della cipolla (OP) ha negoziato tre chiavi simmetriche (K1-3) con ciascuno dei router di cipolla (OR1-3) sul circuito con lo scambio di chiavi Diffie-Hellman. Queste sono le chiavi per le "bucce di cipolla" che sono avvolte dai dati che scorrono lungo il circuito dai proxy della cipolla. (Non vedo alcuna possibilità di introdurre IPSec qui)

Ma questa è l'unica crittografia in TOR o anche le connessioni tra i router di cipolla sono crittografate? (TLS, sarebbe sostituibile da IPSec) Se sì, perché è necessario?

Inoltre PCTCP afferma che per evitare che un avversario contenga le connessioni IPSec sarà introdotto. Ma il modello di filo definito in TOR presuppone che un avversario possa eseguire il proprio router di cipolla, con il quale poteva contare la connessione anche con IPSec abilitato.

Sarebbe bello se qualcuno potesse spiegare la progettazione della connessione nel suo complesso, compresi tutti i luoghi in cui vengono utilizzati i meccanismi di sicurezza. Immagino che la bella illustrazione citata in ogni secondo thread nel web non è tutto ciò di cui è fatto.

    
posta ManuelSchneid3r 17.01.2015 - 17:23
fonte

1 risposta

3

Connessioni TCP di TOR

Il documento PCTCP afferma che TOR utilizza una singola connessione TCP con dati multiplex da diversi utenti. Il buffer di output singolo richiede quindi uno scheduler per crittografare / decrittografare i dati di ciascun utente e assicurarsi che tutto il processo di ciascun flusso di dati sia corretto. Ciò può portare alla perdita di dati in un pacchetto, che causa la ritrasmissione di quel pacchetto e causa latenza generale in TOR.

PCTCP sta cambiando il modo in cui vengono eseguite le connessioni. Stanno proponendo che piuttosto che il multiplexing degli utenti insieme in una singola sessione TCP, ogni utente otterrebbe la propria connessione TCP dedicata tra Onion Routers (OR). TOR ha il proprio protocollo per stabilire le chiavi tra le OR. Questa operazione può ancora essere eseguita come al solito, ma ora con una connessione TCP dedicata. L'obiettivo qui è tentare di ridurre la corruzione dei dati e la successiva ritrasmissione di pacchetti.

Comunicazioni protocollo TOR

TOR utilizza TLS tra OR per proteggere la comunicazione del protocollo TOR. Una volta che i messaggi sono stati completati e le chiavi sono state stabilite, i dati crittografati passano attraverso la connessione TCP multiplexata.

PCTCP non cambia il modo in cui vengono scambiate le chiavi, ma genera solo una nuova sessione TCP per ogni nuovo utente. Potrebbe utilizzare le sessioni TLS per queste connessioni TCP, se lo volessero. Il difetto nella loro progettazione è che un avversario può testimoniare il numero di connessioni TCP e l'analisi del traffico su un nodo PCTCP può essere eseguita. Per contrastare questo PCTCP, tutte le comunicazioni tra OR in un tunnel IPSec vengono completate. Essenzialmente spostando il multiplexing dei dati a livello di trasporto a livello IP. Poiché IPSec viene eseguito sul livello IP, l'origine e la destinazione non si preoccupano dei dati TCP. I pacchetti verranno decrittografati / crittografati e le singole connessioni TCP verranno elaborate normalmente dal daemon TOR. Il documento PCTCP afferma che ciò rende l'uso di TLS tra OR ridondante. Che fa Ora si sta eseguendo il tunneling all'interno di un tunnel.

Ricorda che questo è solo tra le OR. I dati tra l'OP e il nodo di ingresso continueranno a utilizzare una connessione TLS per proteggere le sue comunicazioni. È comunque possibile ottenere prestazioni significative dal momento che la maggior parte dei dati abbandonati e delle ritrasmissioni sono dovuti all'inefficienza delle OR.

Questo è il modo in cui possono affermare che le modifiche devono avvenire solo sulle RU. L'OP usa il suo stesso metodo di comunicazione con il nodo di entrata. Gli OR devono abilitare IPSec e utilizzare PCTCP per stabilire connessioni TCP dedicate per utente. IPSec è ora abilitato di default in tutte le distribuzioni Linux. Finché l'OR è configurato correttamente, è possibile stabilire questo tunnel.

In realtà non indicano come gestiscono una connessione se il tunnel IPSec viene rifiutato. Direi che il loro client PCTCP tornerebbe di default a una connessione TLS. Inoltre, sfuggono al fatto che anche un singolo nodo aggiornato a PCTCP in un circuito migliorerà le prestazioni. Ma mi sembra che per far funzionare IPSec occorra almeno due OR adiacenti configurati con PCTCP. Nei loro esperimenti ne hanno sempre almeno due.

Penso di aver risposto a ciascuna delle tue domande.

    
risposta data 19.01.2015 - 14:49
fonte

Leggi altre domande sui tag