Utilizzo di HTTPS in Java senza crittografia

Question

Stiamo cercando una soluzione che ci consenta di utilizzare HTTPS senza crittografia. Perché? Ecco la storia:

Il nostro prodotto (installato presso i clienti) si connette ai nostri server per recuperare aggiornamenti, pubblicare informazioni, ecc. Vogliamo che il prodotto verifichi che sia collegato al server (e non a un impostore) prima di postare dati. Dobbiamo anche assicurarci che non ci siano attacchi man-in-the-middle (cioè, il contenuto dovrebbe essere firmato, ecc.). Tuttavia, i nostri clienti richiedono che possano annusare il traffico (Wireshark, tcpdump, ecc.) E visualizzare l'intero contenuto della transazione. Questo è per motivi di conformità e sicurezza.

Il nostro prodotto è scritto in Java, a proposito.

Qualche idea?

UPDATE: Si prega di scusarmi se non sto usando la forma corretta per rispondere alle risposte, io sono abbastanza nuovo in questo sito.

Prima di tutto, grazie per le risposte rapide!

La nostra ragione per indagare sulla possibilità di HTTPS è perché non vogliamo inventare un nuovo protocollo qui. Non è solo la quantità di lavoro, ma anche il fatto che inventare il proprio protocollo di sicurezza (anche se solo per la firma) è generalmente considerato una cattiva pratica. Stiamo cercando di ottenere i vantaggi di HTTPS nell'autenticazione del server (che è importante, questo server serve anche codice eseguibile che può essere abbastanza grande - non vogliamo che qualcuno serva malware o DoSing ai nostri clienti con grandi dati che solo dopo aver ricevuto l'intero il sistema scoprirà che è brutto) e non garantisce che il MITM non si verifichi (la firma dei messaggi stessi). Non ci importa se qualcuno si becca nel traffico perché non contiene mai qualcosa di considerato confidenziale. Inoltre, non deve necessariamente essere facile leggere i contenuti in Wireshark, solo possibile in modo che i revisori possano farlo.

@Nate Zaugg - no, questo non è uno scherzo. In realtà è sorprendente che oggi i fornitori utilizzino HTTPS con crittografia e non ottengano un sacco di reazioni da parte dei clienti con rigidi problemi di conformità.

@erickson - La prima soluzione con i semi di codice NULL sembra interessante, esamineremo il problema. La seconda soluzione richiederà un set di chiavi per ogni cliente, non qualcosa che vorremmo gestire.

Codificatore @ZZ: intendi che con i codici null non sarà possibile visualizzare i contenuti in Wireshark?

Answer 1

Esistono "ciphersuites" SSL senza crittografia e tutte le versioni del provider Sun JSSE supportano SSL_RSA_WITH_NULL_SHA. Tuttavia, tutti i dati dell'applicazione sono ancora racchiusi in record SSL (per trasportare il MAC che fornisce protezione dell'integrità, ecc.), Così come lo guardi in Wireshark, vedrai queste strutture.

In alternativa, se non si utilizza Diffie-Hellman effimero (una delle cifrature DHE_XXX), è possibile fornire a Wireshark la chiave privata del server e decodificare una sessione SSL. Anche se questo è un lavoro extra, non impone alcun requisito inusuale sul server o sul client per supportare le cipherutee non crittografate usate raramente.

Answer 2

Se è necessaria solo la firma, perché non è sufficiente firmare ogni risposta con una chiave privata (inserendo la firma in un'intestazione) e verificarla con una chiave pubblica sul client, ma non utilizzare affatto HTTPS? Finché la tua chiave privata rimane segreta e tu scegli un algoritmo di firma appropriato, questo dovrebbe impedire di manomettere il corpo della risposta ma senza mantenere quel corpo segreto.

Answer 3

Si può provare a utilizzare i codici NULL (1 e 2) ma la maggior parte dei server è configurata per non accettare i cifrari deboli. Naturalmente, questi 2 codici sono i più deboli.

Anche il payload sarà in chiaro, è ancora avvolto nel frame SSL, quindi la decifratura dei pacchetti più comune non funziona.

Answer 4

Concordo con @Jon Skeet: non dovresti provare a utilizzare un HTTPS danneggiato, ma devi semplicemente firmare le tue risposte. È possibile consultare alcuni documenti per Amazon's S3 per un buon esempio di un modello di sicurezza robusto, robusto e tuttavia abbastanza semplice.

In breve, l'idea di base è avere una sorta di chiave segreta, aggiungerla e un timestamp al messaggio e cancellarlo. Invia hash e data (ma non il segreto, ovviamente) insieme al tuo messaggio al server. Il tuo server controlla quindi che la data sia abbastanza vicina da fidarsi (diciamo 15 minuti) e che la richiesta, la data e la chiave segreta che ha in archivio siano sbiadite. Se ottiene lo stesso hash, una risorsa attendibile genera la richiesta e il server può procedere in modo sicuro.

Ovviamente, questo non è sicuro dallo sniffing man-in-the-middle (che sembra essere ok) ma impedirà a un MITM di cambiare o creare richieste fasulle.

Answer 5

bene, non dovrebbe comunque ciascun client avere una chiave distinta? altrimenti come fa il tuo server a sapere chi sta postando? il server non si cura di nessun uomo nel mezzo?

se ogni client ha una chiave, come una semplice password, che il server sa, la chiave può essere utilizzata come salt con una funzione hash per firmare richieste/risposte.

Answer 6

Esistono alternative che consentono di decrittare il traffico in modo che possa essere letto. Il netronoma è solo un esempio. Per ulteriori dettagli, vedere http://werebuild.telecomix.org/w/images/2/25/Netwitness-SSL-Decryption.pdf