Con SSL / TLS, è pre-condivisione di un certificato fondamentale per evitare un MITM attivo iniziale?

Question

Con SSL / TLS, è pre-condivisione di un certificato fondamentale per evitare un MITM attivo iniziale?

#1 da (1 voti)

1

Per prima cosa, ho alcune domande concettuali e poi alcune domande più specifiche sull'implementazione di HTTPS.

In un sistema estremamente semplice con solo 2 host (A e B) che parlano su una LAN ma un MITM attivo sulla LAN (Z), che è attivo fin dall'inizio e in grado di intercettare e modificare completamente le prime connessioni tra i 2 host A e B, è vero che fondamentalmente, alcuni dati devono essere condivisi fuori banda per evitare questo scenario di attacco, corretto?

In altre parole: non esiste alcun algoritmo, protocollo o trucco matematico esistente che permetta all'host A di connettersi a B per la prima volta in assoluto, avendo assolutamente nessuna conoscenza precedente di B, e in qualche modo asserire che B non è un MITM, giusto? So che questa domanda potrebbe sembrare ovvia, perché sinceramente se A non ha conoscenza di B di sorta, allora non c'è davvero nulla che distingua B da Z ad A, ma ho bisogno di sentirlo dagli esperti.
Questo è esattamente il modo in cui funziona PKI su Internet, giusto? Poiché il certificato di un server è firmato dalla chiave privata di una CA, ma il certificato pubblico della CA è stato effettivamente condiviso in anticipo e in modo fuori banda (al momento dell'acquisto del computer o del disco del sistema operativo, era già presente nel browser software).
È anche vero che un certificato di CA rilasciato in confronto a un certificato autofirmato fornisce solo un vantaggio logistico sotto forma di scalabilità? (in confronto a un mondo ipotetico in cui tutte le parti hanno condiviso certs in modo sicuro, fuori banda) In altre parole, ogni sito su Internet ha tentato di utilizzare certificati autofirmati, quindi tecnicamente potrebbe essere ancora sicuro se per esempio amazon.com e io abbiamo comunicato fuori banda e amazon ha condiviso il suo certificato (in modo da poter stabilire che il certificato fornito era effettivamente di Amazon), così ho potuto convalidare le connessioni future, giusto? Ma il problema sarebbe quello di dover eseguire questo passo fuori banda per ogni sito web là fuori.

Ora su un problema di implementazione correlato.

Immaginate un ipotetico sistema di computer autonomo con circa 100 host su una LAN privata. 1 host è il "master" e viene inizialmente installato manualmente (da un disco, un'unità o un altro supporto fisico attendibile). Ma i restanti 99 host sono installati sulla LAN (https). Se i rimanenti 99 host hanno nessuna memoria persistente e si installano direttamente nella RAM e iniziano ad essere eseguiti, allora deve essere impossibile progettare un tale sistema per evitare la possibilità iniziale del MITM descritta sopra, giusto? Soprattutto considerando che ognuno dei 99 host esegue una completa reinstallazione, e essenzialmente connette per la prima volta ad ogni riavvio. Perché non vi è alcun luogo o mezzo per memorizzare alcun tipo di certificato precondiviso o dati di convalida in modo che i 99 client possano verificare digitalmente un certificato SSL presentato dal server "master". E se non esiste un metodo di comunicazione fuori banda, allora devono ricorrere esclusivamente all'accettazione iniziale del certificato sulla stessa connessione (creando la possibilità del MITM). Inoltre, i 99 host sono automatizzati, quindi non vi è alcuna possibilità per un utente di intervenire e di convalidare un'impronta digitale, come con ciò che fa SSH. Ma in realtà sarebbe solo un'altra forma di comunicazione fuori banda.

openssl public-key-infrastructure tls man-in-the-middle

posta krb686 24.11.2016 - 05:56

fonte

1 risposta

Leggi altre domande sui tag openssl public-key-infrastructure tls man-in-the-middle

Utilizzo ASP.Net del file Machine.config TLS handshake proof of private key posession [chiuso]

score 1 · Answer 1

Per i punti 1..3:
Sì, è così che funziona. È necessaria una certa fiducia iniziale, sotto forma di CA attendibile che può essere utilizzata per ricavare la fiducia in certificati foglia o come certificati foglia condivisa direttamente affidabili.

Per quanto riguarda il problema dell'implementazione:
Presumo che il tuo disco meno client abbia lo stesso tipo di supporto di sola lettura da cui avviano perché altrimenti il tuo problema di attendibilità inizia prima, ovvero come si assicurano che avviano il sistema operativo corretto quando avvio da una rete. Quindi, supponendo che il sistema operativo da loro avviato sia in realtà quello corretto ma che non hanno alcuna conoscenza di chi possono fidarsi, devono fare affidamento su "TOFU", ossia Trust On First Use.

Ovviamente si potrebbe provare a mettere almeno alcune informazioni di fiducia iniziali nei sistemi perché anche un trust debole potrebbe essere migliore della mancanza di fiducia. Ad esempio, ciascuno di questi sistemi potrebbe essere dotato di un certificato diverso installato dalla manifattura, il tutto firmato dal produttore CA. In questo modo si potrebbe assicurare al primo collegamento che il dispositivo peer è almeno dalla produzione e quindi rendere gli attacchi più difficili. Ovviamente questo non è infallibile poiché l'utente malintenzionato potrebbe estrarre il certificato e la chiave del dispositivo da un dispositivo esistente o modificare tale dispositivo affinché funzioni come MITM, ma in questo modo i costi iniziali dell'attacco sarebbero più elevati.

BTW, questo non è un problema limitato a TLS o anche ai computer, ma è una semplice domanda su quali informazioni sono necessarie per fidarsi di qualcuno. E se non hai nessuna informazione, non hai modo di decidere se il peer di comunicazione è affidabile o meno. Questo è il motivo per cui nella vita reale hai varie forme di identificazione centralizzata, vale a dire passaporti, patente di guida o simili che ti forniscono un modo per ottenere fiducia perché in qualche modo ti fidi degli emittenti di queste carte d'identità.