Utilizzo di Diffie-Hellman per verificare il certificato SSL?

Non penso che tu capisca pienamente quello che stai facendo, quindi cerco di spiegare i tuoi passi:

...start by establishing a secure connection between the App and the Web Server using Diffie-Hellman..

Questa sarebbe una connessione DH anonima perché non verifichi l'identità del peer. E non puoi verificare la sua identità perché non hai ancora un'ancora di fiducia. Perché non verifichi l'identità non puoi essere sicuro con chi stai parlando. Ciò significa anche che gli attacchi MITM sono possibili, quindi non dovresti fidarti dei dati che ottieni all'interno di questa connessione.

... to transfer the certificate, so that when the SSL connection is being established, I can verify if the certificate is correct.

Questo significa che si trasferisce un'ancora di fiducia per le connessioni future usando una connessione non sicura che è aperta agli attacchi MITM. Non c'è modo di verificare che il certificato che hai ottenuto sia effettivamente il certificato del peer con cui ti è piaciuto parlare e non il certificato dell'attaccante.

In sintesi: sostituisci "nessuna verifica perché non ci sono ancora trust" con "verifica rispetto all'ancora di fiducia effettivamente non attendibile".

Scrivi:

Since there is no connection to the internet, the SSL Certificate on the Web Server is self signed, and cannot be verified against a CA.

C'è qualche equivoco qui. Riesaminiamo alcuni elementi fondamentali sui certificati:

• I certificati non ottengono o perdono valore a seconda di come li ottieni. Ciò che conta per un certificato è chi lo ha firmato.
• Non hai bisogno di alcuna connessione a Internet. In effetti questo è l'intero punto dei certificati: sono un modo per legare nomi a chiavi pubbliche in un modo che può essere convalidato senza dover parlare con un sistema di terze parti . I certificati sono significa che funzionano per i sistemi offline.
• Un certificato è convalidato per quanto riguarda un "ancoraggio affidabile" a priori conosciuto (ovvero "CA radice"). Un certificato autofirmato è un certificato che si presume essere il proprio CA radice.
• Effettuare uno scambio di chiavi Diffie-Hellman precedente non modifica nulla a nessuno dei precedenti. Nessuna delle firme su tutti questi certificati crea alcun trust; la fiducia è trasferita , ma deve ancora iniziare da qualche parte, cioè le ancore di fiducia. Non puoi evocare la fiducia dal nulla, che si tratti di Diffie-Hellman o di qualsiasi altro algoritmo crittografico.
• Anche se i tuoi sistemi avessero qualche connessione a Internet, nulla sarebbe cambiato.

Nel tuo caso, vuoi che il client (app per iOS) sia in grado di verificare che parli con il server originale (il tuo server Web). Il metodo più semplice consiste nell'utilizzare un certificato autofirmato nel server e nella copia di tale certificato nell'app. Solo per evitare equivoci: il certificato contiene la chiave pubblica ma non la chiave privata; il server avrà sia il certificato che la chiave privata, l'app conoscerà solo il certificato. Con il certificato hardcoded, l'App può assicurarsi che parli con il server giusto in virtù dell'utilizzo della chiave pubblica in quel certificato hardcoded; in altre parole, l'App convalida il certificato inviato dal server confrontandolo, bit per bit, con quello già incluso nelle interi dell'app.

Un metodo un po 'più complesso ma forse più flessibile è quello di eseguire la propria CA. Si crea una CA radice autofirmata e si installa il certificato corrispondente nell'app come un'ancora di attendibilità. Inoltre emetti (cioè firma) con quella CA un certificato per il server. L'App applicherà la normale convalida X.509, ovvero verifica che il certificato inviato dal server sia effettivamente firmato da uno dei suoi ancoraggi di fiducia.

Ciò che vuoi fondamentalmente viola il "Principio Fondamentale della Fiducia" come affermato da Rajput in cui si afferma che "Per stabilire la fiducia tra due parti su un non affidabile è necessario un canale di attendibilità" esterno "(come una terza parte)".

Se il problema è che davvero non ti fidi del certificato, l'aggiunta del certificato nell'archivio fidato non è un'opzione. Una soluzione consiste nell'emettere tutti i certificati utilizzando una singola CA e quindi mantenere il certificato su tutti i dispositivi o installarlo nel momento di "inizializzazione della fiducia". L'inizializzazione della fiducia è sempre il momento più rischioso e dovrebbe essere fatto solo attraverso una delle seguenti opzioni (l'e-mail non è sicura):

1. Porta fisicamente il dispositivo in una zona "attendibile.
2. Tramite una Terza parte di cui entrambi hanno fiducia (cioè consegna il certificato tramite FedEx o consegnalo a mano)

ecc.

Dovresti essere in grado di utilizzare certificati da un'autorità fidata anche senza una connessione Internet. Avrai bisogno di una connessione internet per ottenere il certificato (e tutti i certificati CA intermedi pertinenti), ma una volta acquistato puoi trasferirlo alla intranet e installarlo sul server web.

L'unica fonte potenziale di guai è che il client non sarà in grado di controllare lo stato di revoca del certificato senza una connessione Internet, ma la mia comprensione è che iOS consentirà il collegamento delle connessioni SSL / TLS anche se non può raggiungere il server di revoca (CRL o OCSP).

EDIT: ho pensato a un altro possibile problema: il client deve raggiungere il server utilizzando un nome di dominio appropriato effettivamente registrato nella società: nessun "server.local", "server.private" o indirizzo IP. Si noti che mentre i normali server DNS dell'azienda non sono raggiungibili sulla rete intranet, è generalmente possibile configurare un server DNS privato sulla intranet (potrebbe infatti averne già uno).

È possibile aggiungere il certificato all'elenco dei certificati attendibili del dispositivo; questo sito ha una descrizione di come farlo, ma in pratica puoi inviare per email il certificato a ciascun dispositivo oppure puoi utilizzare Apple Strumenti di gestione iPhone per aggiungerli a molti dispositivi. Sembra che il tuo prodotto riguardi le istruzioni di configurazione (poiché il server deve essere configurato, non possono semplicemente scaricare l'app), quindi puoi aggiungerlo alle istruzioni.

EDIT: Diffie-Hellman, oltre ad essere suscettibile agli attacchi man-in-the-middle, è del tutto inadatto ai tuoi obiettivi. Quello che fa DH è consentire alle parti di negoziare un segreto condiviso su un canale non sicuro senza dover condividere un segreto su un canale sicuro. Nessuna delle due parti può controllare in modo significativo cosa sia quel segreto condiviso; DH è non una tecnica di crittografia, perché richiede ad Alice di essere in grado di inviare a Bob qualcosa a sua scelta, e tutto ciò che fa DH è dare loro sia qualcosa che sanno e che nessun altro fa. Puoi applicare una crittografia simmetrica dopo aver fatto DH (in pratica è ElGamal), ma la DH stessa non può trasferire le informazioni di tua scelta.

Inoltre, DH ha una protezione no contro gli attacchi MitM, e quindi le informazioni trasmesse devono essere rese affidabili in qualche modo (sia che si tratti di unirle nell'app [sebbene tu abbia rifiutato di usare lo stesso cert per tutti, e lo stesso problema si presenta con il riutilizzo delle credenziali DH], o firmandolo [questo è letteralmente come funzionano alcune modalità SSL]). Quindi no, DH non è quello che stai cercando.