Verificare che una seconda connessione TLS provenga dallo stesso client

Question

Verificare che una seconda connessione TLS provenga dallo stesso client

#1 da (5 voti)
#2 da (3 voti)

3

Vorrei implementare una specie di schema TOFU (trust-on-first-use) con TLS:

Un client crea una chiave e un certificato autofirmato.
Il client si connette al server con questo certificato.
Il server accetta la connessione e memorizza qualcosa sul client
Supponendo che questa prima connessione non fosse MITM, voglio essere in grado di verificare che la prossima connessione provenga dallo stesso client.

È possibile? E se sì, che cos'è quel qualcosa che devo memorizzare dalla prima connessione per poter verificare la seconda connessione?

In pratica sto usando la libreria TLS di Golang quindi penso che questo sia l'informazione che ho sul certificato di connessione.

public-key-infrastructure tls x.509

posta AndreKR 06.03.2017 - 14:25

fonte

2 risposte

5

Invece di progettare il tuo schema per questo, puoi cercare in JWT usando x509: link .

Oauth ha anche questo tipo di opzione (credo), ma non riesco a trovare una documentazione decente.

Penso che ci siano alcuni aspetti della soluzione che sembrano problematici al momento - in particolare, piuttosto che memorizzare qualcosa sul server per client, usando x509 significa che devi solo convalidare il certificato presentato dal cliente correttamente, piuttosto che doverlo fare controlli più complessi.

Non è necessario (AFAIK) che i certificati che invii ai tuoi clienti siano validi al di fuori del tuo ambiente (ad esempio puoi usare la tua CA per questo), in modo che tu possa avere il tuo flusso come:

richiede un certificato basato su un CSR che genera (simile a Oauth)
se la richiesta del cliente è autenticata correttamente, la CSR viene elaborata in un certificato valido per le tue esigenze
il client quindi memorizza questo certificato e lo presenta quando necessario
il server convalida che il certificato è valido ed estrae la sua chiave pubblica per i propri bisogni (se presenti).

Quindi, sì, ciò che proponi potrebbe essere possibile, ma sembrano esserci alcuni schemi consolidati che forniscono già un approccio simile e che potrebbe essere utile esaminare.

risposta data 06.03.2017 - 14:59

fonte

Leggi altre domande sui tag public-key-infrastructure tls x.509

Ottenendo circa 6-7 email di spam ogni minuto Fattore di resistenza chiave SSH oltre alla lunghezza della chiave (ad esempio ed25519 vs rsa-4096)

score 3 · Accepted Answer

Poiché si utilizza TLS con i certificati client e si desidera rilevare se lo stesso client con lo stesso certificato si connette di nuovo, è possibile archiviare semplicemente il certificato client o il pubkey contenuto nel certificato o un'impronta (hash) di questi. Poiché in base alla tua descrizione la chiave e quindi il certificato sono generati dal cliente e sono unici per il cliente, qualsiasi caratteristica menzionata dovrebbe identificare in modo univoco il client. E poiché solo il proprietario della chiave privata (ovvero il client) può utilizzare il certificato di corrispondenza per l'autenticazione con il server, è anche impossibile che solo la conoscenza dell'impronta digitale o del certificato consenta a un utente malintenzionato di impersonare il client.