VPN vulnerabili a MiTM perché ogni certificato va

Question

VPN vulnerabili a MiTM perché ogni certificato va

#1 da (8 voti)
#2 da (3 voti)

7

Oggi ho parlato con un sysadmin in un business center che intendeva fondamentalmente eseguire un MiTM (come lo chiamava) su ogni connessione nella sua rete perché le persone nel suo edificio utilizzavano VPN e connessioni https per lo streaming di video, download torrent ecc. Questi servizi utilizzano tutta la larghezza di banda, ma poiché sono connessioni crittografate, il suo servizio di bilanciamento del carico non funziona.

La società di sicurezza da lui assunta lo ha convinto che è possibile configurare un server proxy con il proprio certificato valido e firmato (ovviamente per il server proxy) che duplicherebbe tutti i browser e le connessioni VPN per accettare il proxy come endpoint. Ciò gli consentirebbe di decrittografare tutto il traffico, verificarne il contenuto e ridurlo se necessario, crittografarlo nuovamente e inviarlo come previsto senza che nessuno ne sia il più saggio.

Sulla parte https sono riuscito a spiegarlo / convincerlo che qualsiasi implementazione https decente è intesa specificamente per evitare gli attacchi MiTM perché i certificati sono collegati a un dominio oa un'azienda specifici. In nessun modo il suo proxy può ingannare un browser per pensare che si stia connettendo al sito web mentre in realtà si connette al server proxy.

Tuttavia, per quanto riguarda le VPN, è irremovibile (o, meglio ancora, la società di sicurezza che ha ingaggiato per la sua rete) che molti servizi o protocolli VPN accetteranno qualsiasi certificato firmato da una CA per creare una connessione sicura. Indipendentemente dal fatto che il certificato sia effettivamente attribuito al server a cui ci si sta collegando non è selezionato.

Questo mi sembra altamente improbabile e contrariamente a tutto ciò che so di connessioni sicure, ma prima di riprendere questa discussione voglio assicurarmi che non manchi una vulnerabilità poco conosciuta nei protocolli VPN di software che pochissime persone conoscono .

La mia domanda: è vero che alcuni protocolli VPN o software VPN controllano solo la validità di un certificato controllando se è firmato da una CA e non verificherà affatto se il certificato è effettivamente attribuito al server ci si sta connettendo?

- piccola modifica - Per specificare perché questo dovrebbe essere possibile: secondo l'impresa di sicurezza alcuni software VPN accetteranno qualsiasi certificato valido e non controllerà se il certificato è effettivamente collegato al server: qualsiasi certificato valido è accettato.

vpn tls certificates

posta user3244085 15.03.2014 - 20:22

fonte

2 risposte

3

Potresti voler leggere questo pezzo sul sito Gibson Research Corporation : The "S "Aggiunto alla fine di" HTTP "significa SICURO. (O almeno doveva).

The presence of the unbroken key or the lock icon on the web browser once meant that the connection between the user and the remote web server was authenticated, secured, encrypted . . . and not susceptible to any form of eavesdropping by any third party. Unfortunately, that is no longer always true.

E

How is this elegant system [cfr. CA-system] subverted?

Any corporation, educational institution, or other Internet connectivity provider who wishes to monitor every Internet action of its employees, students or users — every private user ID & password of every social networking or banking site they visit, their medical records, all “secure” eMail . . . EVERYTHING — simply arranges to add one additional “Pseudo Certificate Authority” to their users' browsers or computers. It's that simple.

risposta data 16.03.2014 - 01:01

fonte

Leggi altre domande sui tag vpn tls certificates

Come rilevare se si sta tentando di crackare la chiave della mia rete? Fiducia delle chiavi GPG dopo una parte della firma

score 8 · Accepted Answer

Risposta breve:

No, non può essere fatto. Ciò è dovuto al fatto che un'autorità di certificazione affidabile non emetterà un certificato per un dominio che il tuo sysadmin non controlla.

Risposta lunga:

Può essere eseguito in alcuni scenari.

Ad esempio - se stai usando OpenVPN per creare una connessione TLS ad un concentratore VPN in un'altra parte del mondo chiamato ... say ... awesomevpn.sx, uno dei primi passi nel l'handshake TLS è la convalida del certificato del server. Il tuo sysadmin potrebbe tentare di connettere questa connessione a MITM, ma non sarebbe in grado di presentare un certificato per awesomevpn.sx perché nessuna CA lo invierà a lui , il che farebbe fallire la connessione.

Tuttavia, considera uno scenario in cui un'azienda ha incaricato un fornitore di installare dispositivi di ispezione dei pacchetti. Per eseguire attacchi MITM su connessioni sicure, i fornitori costringeranno l'installazione dei propri certificati "root" sulle macchine client . In questo modo, possono utilizzare la propria CA per firmare i certificati per qualsiasi dominio. Questo può essere fatto al volo dagli apparecchi di ispezione. Quando questi certificati vengono presentati al client durante la sequenza MITM, verranno accettati, consentendo il completamento della connessione e i pacchetti da ispezionare in chiaro.

Sembra una debolezza del sistema CA, ma ricorda che in un ambiente aziendale, non hai il controllo fisico sulle macchine di proprietà dell'azienda. Senza controllo fisico, è game over in termini di sicurezza.

Quindi la spiegazione che ti è stata data manca un punto chiave: non hanno menzionato il requisito di installare i propri certificati di root sui computer client. Non ha nulla a che fare con una debolezza nei client VPN, o con i vari protocolli usati per le connessioni sicure.