TLS e client Java

Question

TLS e client Java

#1 da (1 voti)
#2 da (1 voti)

1

Lavoro con un client e un server Java che la nostra startup ha recentemente acquisito con un accesso molto limitato agli sviluppatori che lo hanno creato. C'è una documentazione molto limitata. Sembra che il client Java utilizzato per connettersi al proprio server con TLS, c'è una regola del server Nginx per l'endpoint giusto e un certificato e una chiave privata ad esso associati. Tuttavia, lo sviluppatore afferma di non aver bisogno di avere una chiave pubblica presente sul computer che esegue il client Java.

Finora ho appreso che Java memorizza questi certificati attendibili nel file jre/lib/security/cacerts . Dopo aver installato un certificato autofirmato, ho potuto rendere il client Java connesso al server con crittografia.

Ora la domanda è: in che modo il certificato diventa disponibile per Java? Deve essere installato ogni volta manualmente in cacerts ? O diventerà disponibile in Java dopo aver ottenuto un certificato legale da parte di alcune autorità come Thawte? Per "diventare disponibili" intendo, la lib di HTTP di Java andrà a trovare quel certificato con l'autorizzazione della chiave pubblica? (Non ho familiarità con il modo in cui la verifica CERT funziona con i client senza browser.)

Mi è stato detto dal dev del client e server Java che la chiave pubblica viene scaricata dal server stesso durante la connessione, il che per me non ha senso e tipo di sconfitte lo scopo della sicurezza - se sia la chiave pubblica che la chiave privata proviene dalla stessa fonte, come possiamo fidarci?

Sto imparando molte cose mentre vado (è una startup) e conosco solo la crittografia pubblica in teoria dall'università, ma in pratica sembra un po 'diversa. :) Grazie.

public-key-infrastructure tls

posta Serge Poele 10.11.2016 - 00:44

fonte

2 risposte

1

Una volta ottenuto un certificato "legittimo", java si fiderà di tale certificato in modo nativo. Java viene fornito con un elenco di CA standard (proprio come fa il browser) e sarà in grado di collegarlo insieme.

Ci sono molte cose che possono andare storte - se non funziona, devi assicurarti:

Il server è configurato correttamente (invia il certificato e certificati intermedi che si associano alla CA)
La CA si trova nel Java Store (cacerts)
Il client è codificato per utilizzare l'archivio predefinito di Java - facendo leva su java La classe URL di solito è il modo più semplice per farlo

risposta data 12.11.2016 - 02:42

fonte

Leggi altre domande sui tag public-key-infrastructure tls

Sta usando il metodo appropriato VPN nel mio caso? Come eseguire la crittografia dopo Diffie Hellman Key Exchange

score 1 · Accepted Answer

Un certificato attendibile è firmato ( per favore leggi tutta la risposta nel link ) da un certificato intermedio che è a sua volta firmato da un certificato di origine. Potrebbero esserci più di un intermedio nella catena, uno dopo l'altro. Il certificato radice è distribuito da Oracle (e probabilmente anche da Microsoft e Apple negli aggiornamenti del sistema operativo e dalle distribuzioni Linux nel pacchetto di certificati basato sul programma radice di Mozilla).

Durante l'handshake TLS, il server TLS invia il certificato foglia e tutti gli intermedi al client TLS. Il client TLS verifica tutte le firme digitali (l'handshake è firmato dalla chiave nel certificato foglia, che è firmato dalla chiave per l'intermedio, ecc.) Fino al certificato di root che è considerato implicitamente attendibile, non a causa della crittografia ma perché qualcuno ha messo il file del certificato radice nella directory giusta.

Non esiste una directory di certificati o chiavi pubbliche per i domini, il server ti consegna un certificato. C'è un progetto chiamato Certificate Transparency avviato da google per ottenere un registro pubblico di tutti i certificati pubblicamente affidabili per tutti i server accessibili pubblicamente, ma non è pensato per essere utilizzato per stabilire connessioni TLS, anche se una prova che il certificato è stato registrato è richiesta dai browser per certificati EV e certificati emessi da CA di proprietà di Symantec e nel 2017 Google prevede di richiedere la prova di registrazione per tutti i certificati.

La CA non ha bisogno di essere contattata per verificare il certificato.

Se si desidera verificare che il certificato non sia stato revocato, il client TLS deve contattare il CRL della CA o ottenere una risposta OCSP con punti metallici dal server TLS. I certificati possono essere impostati (alla creazione) per dire "non fidarsi di questo certificato senza controllare la revoca", questo è chiamato "OCSP Must Staple". Non so se il tuo cliente cerca persino di verificare la revoca - molti non lo fanno.

I certificati non attendibili possono essere identici a quelli attendibili, ma firmati da una CA la cui root non è considerata attendibile dal client. Molte organizzazioni eseguono la propria CA interna, che è considerata affidabile da tutti i loro clienti (IT aggiunge la radice CA a tutti i computer) e questa CA viene utilizzata per emettere certificati per i propri server interni. La CA potrebbe anche emettere certificati SSH e VPN. Per un client TLS che non ha familiarità con la CA interna, un certificato emesso da uno non sarebbe attendibile.

I certificati non attendibili possono anche essere autofirmati. Per convalidare tale certificato, il client deve avere, prima di effettuare una connessione, una copia del certificato stesso, non di una radice, che ha acquisito "fuori banda" (cioè lo ha copiato da uno sviluppatore). Consiglierei di passarlo (il certificato autofirmato con hardcoded) all'API facendo la connessione di rete invece di renderlo un certificato di root attendibile per il computer su cui è installato il software client.