Trasparenza certificato: registra un pre-certificato legittimo e rilascia un certificato canaglia

Question

Trasparenza certificato: registra un pre-certificato legittimo e rilascia un certificato canaglia

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

5

Sto cercando di capire come la trasparenza dei certificati risolva il problema con le autorità di certificazione disoneste che incorporano un SCT nei loro certificati. Comprendo che il registro è solo per l'aggiunta e il server può "dimostrare" che il certificato è stato effettivamente registrato.

Supponiamo che io sia una CA canaglia e voglio emettere un certificato ma anche registrarlo su un paio di registri. Creo un certificato per un nome di dominio di cui nessuno se ne preoccupa (diciamo foobar.com ), e invia il pre-certificato ai log. Posso quindi recuperare l'SCT. Posso quindi rimuovere l'estensione veleno e aggiungere un altro nome di dominio (ad esempio paypal.com ) al campo SAN, quindi emettere il certificato.

C'è qualche meccanismo che mi impedisce di farlo? Chiunque effettui la scansione dei log di CT non vedrà che ho emesso un certificato per paypal.com , ma i browser dovrebbero fidarsi del certificato e crederanno anche che ho inviato il certificato al log.

L'obiettivo principale della CT è impedire alle CA di rilasciare certificati per ciò che non dovrebbe. Sono sicuro che ci sono dei requisiti di base che impediscono questo e la CA verrà rimossa dalle radici attendibili se vengono catturate in questo modo. Ma esiste un modo crittograficamente sicuro per impedirlo?

public-key-infrastructure tls certificate-authority certificate-revocation x.509

posta Ayesh K 31.07.2017 - 01:41

fonte

2 risposte

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

Qual è lo scopo di un'istruzione di transizione PGP? Quali sono alcune opzioni per una piccola azienda su un budget per mantenere un programma di bug bug? [chiuso]

score 2 · Answer 1

Indovinare: non funzionerebbe. Stessa cosa quando alcune CA hanno provato a utilizzare uno schema di redazione non standard. - Che è solo una variante specifica di inviare un certificato mentre in realtà ne emetti un altro. Questo è stato regolato dai browser che in realtà si preoccupano di controllare. - > Il mio sito ha abilitato la trasparenza del certificato ma Chrome mostra ancora NET :: ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

- L'applicazione CT è fino al browser. E AFAIK richiesto solo da Chrome per i certificati Symantec. Ma il requisito CT-tutto è all'orizzonte per Chrome per ottobre 2017. Vedi: link

Modifica 1: a cosa serve CT?

Hai scritto:

The very objective of CT is to prevent CAs from issuing certificates for what it should not.

Non lo è. L'obiettivo non è la prevenzione, ma la responsabilità. Una CA può emettere un certificato per qualsiasi dominio in qualsiasi momento. Questa parte NON è stata modificata da CT.

Ciò che cambia il gioco è che quando viene emesso un certificato canaglia può accadere una delle due cose:

Se la CA non si sottomette affatto a CT o non presenta un nome host diverso (non appena i browser lo applicano effettivamente), il browser rifiuterà il certificato. E il certificato canaglia sarà inutile.
Se la CA invia a CT il nome host corretto, allora il certificato sarà pubblico. E un proprietario di dominio che si preoccupa può inserire un processo di controllo automatico per tutti i suoi nomi di dominio nei registri CT. ( Facebook offre un tale servizio gratuitamente .)

Nelle loro stesse parole:

Certificate Transparency makes it possible to detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority. It also makes it possible to identify certificate authorities that have gone rogue and are maliciously issuing certificates.

score 1 · Answer 2

Sì, è possibile prendere lo scenario che hai descritto.

Ciò è reso possibile perché l'intera catena di certificati è memorizzata nel registro. Le domande quindi sono "quale parte ha la responsabilità di fare questo?" e "come fanno?"

Mi sembra che la responsabilità principale sia nei confronti del cliente, in quanto Relying Party (la mia interpretazione, non dichiarata nello standard), per controllare correttamente prima di fare affidamento su qualsiasi cosa.

La mia ricostruzione (interpretazione?) di come accade - basato sul documento RFC 6962 :

I certificati (precertificato e quello attuale) vengono registrati e rilasciati come descritto.
Durante l'handshake TLS, Client include un'estensione ClientHello "signed_certificate_timestamp" con extension_data come vuoto.
Il server restituisce SCT (multipli, da più provider di log, se applicabile) in extension_data con il tipo "signed_certificate_timestamp".
Il client recupera la catena sicura da un / il registro ed esegue 4 controlli in qualsiasi ordine.
(3a) Le firme cert corrispondono tra il cert fornito dal server e il cert fornito dal registro?
(3b) I cert SCT corrispondono? (il recupero sembra essere da LogID, quindi immagino che questo controllo sia richiesto)
(3c) Verifica l'integrità della cert? Questa è già una parte dei controlli che sono già in voga.
(3d) Il nome del server corrisponde a una delle voci SNI / SN nel certificato? Anche questo fa già parte dei controlli attualmente in voga.

Mi aspetto che se i client fanno 3a & 3b, la frode verrà catturata. Il ruolo di CT Logs e SCT si interrompe rendendo disponibili le informazioni per i clienti (compresi i proprietari di certificati e gli auditor CT) in modo che tali frodi possano essere rilevate dai minori.

Se un proprietario certificato non è complice nello scenario che hai descritto, il problema verrebbe rilevato non appena il certificato viene consegnato al proprietario e il proprietario invia il certificato al registro CT. Ci sarebbe un disallineamento della firma sul certificato.

Anche se il proprietario del certificato è complice, quando un browser conforme (client) effettua questo controllo, verrà catturato in 3a o 3b, a seconda di come i dati sono stati modificati sul certificato.