comunicazione HTTP sicura per componenti di prodotti commerciali

Diciamo che voglio spedire un prodotto commerciale che ha due componenti, scritte in Java, che comunicano tra loro su una rete locale utilizzando un’API RESTful. Potrebbe essere un gestore di musica, un database di contatti, un libro di cucina — ciò che è importante è che questo è uno scenario ragionevole ed estremamente probabile.

Si noti che sto parlando di due componenti che parlano tra loro su una rete locale, non sulla comunicazione al mio server.

Quindi, come posso rendere sicura la comunicazione?

So se vado a configurare un server HTTP per il mondo che posso (anche a buon mercato) acquistare un certificato SSL. L’ho fatto. Ma non posso dire all’utente di andare a comprare un certificato — non avranno idea di cosa sto parlando, e non riuscirei mai a capire come installarlo.

Quindi cosa faccio? Spedisci a tutti il ​​mio certificato autofirmato e fai una cosa molto brutta come disabilitare la convalida dei certificati in Java ? Orribile, lo so. Ma almeno le informazioni non andranno oltre la linea in testo normale.

Qualcuno ha delle soluzioni migliori?

Aggiornato il 20 settembre 15 per chiarire i punti sollevati nei commenti

Per capire come ciò può essere fatto, esaminiamo un ansible scenario di distribuzione di tale applicazione. Supponiamo che l’applicazione in questione comprenda due componenti: la parte client e la parte server, pensata per essere installata su diversi computer su una rete locale. Vogliamo che la nostra parte server accetti solo connessioni sicure, quindi la rete locale è considerata ostile.

  1. Installa la parte server. Al momento dell’installazione, crea un certificato autofirmato utilizzando il nome host di un computer di destinazione. Se non esiste alcun record DNS per il computer (come myserver.mycorp.com ), usa il suo indirizzo IP – deve essere statico poiché è necessario puntare la parte client su di esso. Puoi utilizzare l’ API di Bouncy Castle per creare un certificato nel codice.

  2. Installa la parte client su un altro computer e copia il certificato generato nella cartella di installazione. Fare questo manualmente sta effettivamente stabilendo la fiducia tra il server e il client. Provare a farlo automaticamente tramite una connessione non criptata su una rete nemica potrebbe vanificare lo scopo.

  3. Dal momento che si sta proteggendo strettamente la comunicazione tra le proprie parti dell’applicazione, si ha il pieno controllo di quali sono i certificati che l’applicazione in questione si fida. Sul client, creare un keystore e aggiungere ad esso il certificato generato:

    FileInputStream fis = new FileInputStream(yourCertificateFile); CertificateFactory cf = CertificateFactory.getInstance("X.509"); X509Certificate c = (X509Certificate)cf.generateCertificate(fis); KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType()); ks.load(null, aRandomKeystorePasswordCharArray); ks.setCertificateEntry(aUniqueNameForYourCertificate, c); FileOutputStream fos = new FileOutputStream(aRandomKeystoreFileName); ks.store(fos, aRandomKeystorePasswordCharArray); fos.close(); 

    Dì alla JVM che la tua applicazione si affiderà solo ai certificati dal proprio keystore.

     // replace backslashes '\' with slashes '/' in aRandomKeystoreFileName on Windows System.setProperty("javax.net.ssl.trustStore", aRandomKeystoreFileName); System.setProperty("javax.net.ssl.trustStorePassword", aRandomKeystorePassword); 

Cerca OAuth 2.0 per proteggere i tuoi servizi e dovresti fornire solo token ai tuoi clienti anziché SSL a due vie. Facebook, Google, ecc. Lo usa.

https://en.wikipedia.org/wiki/OAuth

La risposta collegata presenta un’altra soluzione: invece di disabilitare la convalida del certificato per i certificati autofirmati, ‘Esporta il certificato (…) e importalo nel truststore JVM’.

Quindi, solo per la prima volta quando viene trovato un certificato sconosciuto, chiedere conferma all’utente.

Dai un’occhiata al confronto tra Facebook Connect, OAuth e OpenID su TheNextWeb

OpenID : OpenID funge da terza parte in grado di verificare chi sei

OAuth : un modo più sicuro e più sicuro per le persone di darti l’accesso

Facebook Connect : con Facebook Connect, ciò che vediamo sono elementi sia di OpenID che di OAuth. Facebook Connect può verificare chi sei chi dici di essere e può quindi fornire l’accesso ai tuoi dati una volta che hai dato il permesso di farlo.

Sommario:

OpenID e OAuth pensano di avere una risposta giusta collettiva, ma Facebook pensa chiaramente di avere il suo. Dobbiamo vedere come si evolverà in futuro.