Certificato autofirmato SSL - Come verificare correttamente sul lato client?

Question

Certificato autofirmato SSL - Come verificare correttamente sul lato client?

#1 da (2 voti)

0

Per la nostra attuale implementazione utilizziamo un certificato di root autofirmato, che viene quindi utilizzato per firmare i certificati SSL per la nostra connessione sicura http.

La mia domanda riguarda la logica di verifica sul client, che sfortunatamente non avrà accesso al certificato di root dell'autorità di certificazione radice attendibile.

È sufficiente memorizzare l'identificazione personale del certificato SSL sul client in un deposito segreto e quindi verificare la conformità nella funzione di callback durante l'handshake https? Considerando che potrebbe essere possibile che qualcuno crei il proprio certificato SSL e utilizzi solo questo valore di identificazione digitale (che ovviamente è disponibile pubblicamente)? Ho sbagliato o è che un certificato x.509 standard non può garantire che i dati non siano stati manomessi?

Non sarebbe più sicuro memorizzare la chiave pubblica del certificato di root e usarlo per controllare l'identificazione personale?

Questo giustifica il sovraccarico aggiuntivo per ogni richiesta iniziale?

http tls certificates certificate-authority x.509

posta HansMusterWhatElse 29.06.2017 - 09:15

fonte

1 risposta

Leggi altre domande sui tag http tls certificates certificate-authority x.509

Considerazioni se dovessi allungare le date di scadenza della sessione a un certo intervallo se il client rimane attivo? È possibile per un'azienda come Apple criptare i dati degli utenti in modo che non possano tracciare le identità? [chiuso]

score 2 · Accepted Answer

My question relates to the verification logic on the client, which unfortunately, won't have access to the root certificate in trusted root certificate authority.

In questo caso non è possibile eseguire la convalida con la CA principale, ma è necessario considerare attendibile ciascun certificato.

... might be possible that someone creates their own SSL certificate and just uses this thumbprint value (which of course is publicly available)?

L'identificazione personale o l'impronta digitale di un certificato o di una chiave pubblica è un hash crittografico sul certificato che contiene la chiave pubblica o la sola chiave pubblica. Poiché la chiave privata segreta deve corrispondere alla chiave pubblica nel certificato e un utente malintenzionato non ha più accesso a questa chiave privata (non sarebbe più privato allora) è praticamente impossibile per un utente malintenzionato creare un certificato con la stessa impronta digitale e avere la chiave privata per questo.

Poiché la proprietà della chiave privata del certificato viene verificata durante l'handshake TLS, ciò significa che è sufficiente controllare il certificato dei server con un'impronta digitale memorizzata, purché questa impronta digitale sia stata creata utilizzando un hash sicuro come SHA-256 e non un insicuro come MD5. Ma naturalmente l'applicazione potrebbe anche memorizzare l'intero certificato atteso o la chiave pubblica e confrontarla.

Does this justify the additional overhead for each initial request?

Non penso che ci sia alcuna differenza evidente tra il confronto dell'impronta digitale o il confronto del certificato completo. Se c'è qualche differenza, allora il confronto tra il certificato completo è probabilmente il più veloce poiché non è necessario creare l'impronta digitale dal certificato per poterlo confrontare.