Il certificato del lato client rubato è un problema valido per la comunicazione SSL? Come costruire un sistema di revoca automatico?

Question

Il certificato del lato client rubato è un problema valido per la comunicazione SSL? Come costruire un sistema di revoca automatico?

#1 da (1 voti)

0

Nel contesto della comunicazione da server a server, eseguiamo TLS / SSL con autenticazione del certificato client. Quindi la comunicazione ha il seguente aspetto:

service_a on Host_A (as the SSL client) --> service_b on Host_B (as the SSL server)

Abbiamo la nostra infrastruttura PKI e la CA organizzativa per rilasciare i certificati per service_a e service_b.

Supponiamo che Host_A sia stato compromesso (quindi è la chiave privata e il certificato di service_a è stato rubato dall'attaccante). Questo aggressore installa tranquillamente un altro EC2 VM Host_C ed esegue (malevolmente modificato) service_a su Host_C (nota: la chiave privata di Host_A è disponibile anche qui su Host_C)

In che modo service_b (insieme alla nostra infrastruttura PKI e CA) protegge o risponde automaticamente a questo scenario? C'è un modo per progettare un sistema del genere?

public-key-infrastructure key-management tls certificate-authority certificate-revocation

posta chen 28.07.2016 - 20:10

fonte

1 risposta

Leggi altre domande sui tag public-key-infrastructure key-management tls certificate-authority certificate-revocation

In che modo l'entropia "agitazione" viene raggiunta nel Microsoft TPM? È necessario pulire l'intestazione LUKS?

score 1 · Answer 1

Ci sono molti modi per rilevare questo scenario.

1: È possibile rilevare il doppio login poiché Host_A e Host_C verrebbero registrati allo stesso tempo, a meno che l'autore dell'attacco non impedisca in qualche modo a Host_A di accedere a Host_B.

2: è possibile utilizzare l'IP dell'host per rilevare se l'IP del client cambia improvvisamente. Suppongo che tu voglia avere un client API che comunica con un endpoint API su Host_B, e quindi l'IP del client dovrebbe essere statico.

3: Puoi "impronte digitali" al client API e, se il client API si comporta in modo diverso (un altro utente o sta inviando intestazioni diverse), è considerato un compromesso.

Potrebbe esserci un altro segno di manomissione, in cui è possibile rilevare qualcosa che non è normale. Supponiamo che il tuo client API originale abbia un tempo prefissato per eseguire operazioni specifiche. È quindi possibile cronometrare queste azioni e se il client API esegue l'azione più rapidamente o più lentamente, può essere un segno di attacco.

Ora all'azione. Per facilitare una revoca più rapida, suggerirei, oltre alla revoca tramite CRL. Come il tuo server può sapere quale certificato viene rubato, puoi invece configurare il tuo servizio API per non accettare accessi con quel certificato SSL, in effetti un "revoca soft". Ciò significa che il certificato viene bloccato immediatamente, invece di dover attendere che il server SSL rileggi e analizzi un CRL nel sistema SSL.