In che modo Certificate Transparance rileva i log falsi o biforcati?

5

Sto cercando di capire Trasparenza certificato .

Diciamo che voglio curiosare sulla posta di qualcuno. Quindi vado a hackerare o corrompere una CA, gli faccio rilasciare un certificato per google.com , e poi lo presento quando collego gli utenti a Gmail con MitM. Questa è la situazione che CT sta cercando di rilevare e consentire a Google di scoprire il falso certificato.

Con la trasparenza del certificato, il browser degli utenti richiede di allegare un timestamp del certificato firmato (SCT) che dimostra che il certificato è stato aggiunto a un registro.

  • In primo luogo, cosa mi impedisce di impostare il mio registro, creare il codice SCT e non dirlo mai a Google o a nessun altro?
  • Il browser può dire se un log è legittimo?
  • Il browser o il suo componente Auditor invia SCT ai monitor?

In alternativa potrei hackerare / corrompere un operatore di log per emettere un SCT con gli hash dell'albero di cui sopra tutti i certificati precedenti. Quindi, quando Google e altri interrogano il log per la sua catena di certificati, potrebbe fingere che il SCT non valido non sia mai esistito. Questo sarebbe un fork nel registro. Ancora una volta Google potrebbe solo scoprire se il browser (Auditor) invia SCT a Google o ad altri monitor.

Il sito web CT menziona che "i revisori e i controllori scambiano informazioni sui registri attraverso un protocollo di gossip" , ma non entra mai nei dettagli su come o quando.

  • In particolare, in che modo il browser (Auditor) sa a quali Monitor parlare?
posta Tor Klingberg 29.10.2015 - 12:45
fonte

2 risposte

2

First, what stops me from setting up my own log, make the SCT, and never tell Google or anyone else about it?

Niente.

Can the browser tell if a log is legitimate?

È lasciato non specificato nella RFC :

TLS clients [...] should validate the SCT by [...] using the corresponding log's public key. Note that this document does not describe how clients obtain the logs' public keys.

(Nota: questa frase era rimossa dalla sezione 5.3 la nuova RFC attualmente in fase di sviluppo. Non so se l'hanno sostituita con qualcosa di più specifico)

Ma Chrome, ad esempio, solo per impostazione predefinita si fida di una manciata di log codificati :

By default, Chrome will check SCTs coming from a list of predefined CT logs recognized by Chrome.

.

Does the browser or its Auditor component send the SCT to Monitors?
[...] Specifically, how does the browser (Auditor) know which Monitors to talk to?

Dipende. Come per la bozza RFC di Gossip questo sarebbe il Trusted Rapporto di revisione tipo di pettegolezzo. (Il che è uno dei 3 tipi di pettegolezzi proposti e tutti questi meccanismi possono essere usati in parallelo.)

E la bozza RFC continua dicendo :

The Trusted Auditor Relationship is expected to be the rarest gossip mechanism, as an HTTPS Client is providing an unadulterated report of its browsing history to a third party. While there are valid and common reasons for doing so, there is no appropriate way to enter into this relationship without retrieving informed consent from the user.

Quindi penso che sarà configurato manualmente o configurato per provenire da una parte fidata (il produttore del browser credo).

Aggiornamento 2018-01-26Fri .: @__ agwa-Blog.

C'è un post sul blog recente su questo argomento:

  • Andrew Ayer, 2018-01-10, In che modo verranno certificati i registri di trasparenza dei certificati in pratica? (archiviato qui .)

    È una lettura tecnica approfondita. Il TLDR è questo ultimo paragrafo qui:

    All of this is a ways off. CTv2 is still not standardized. Chrome still doesn't do any SCT auditing, and consequentially its CT policy requires at least one SCT to be from a Google-operated log, since Google obviously trusts its own logs not to break its promises. Fortunately, even without widespread log auditing, Certificate Transparency has been a huge success, cleaning up the certificate authority ecosystem and making everyone more secure. Nevertheless, I think it would be a shame if Certificate Transparency's auditability were never fully realized, and I hope we'll be able to find a way to make it work.

risposta data 29.10.2015 - 17:47
fonte
1
  • First, what stops me from setting up my own log, make the SCT, and never tell Google or anyone else about it?

Guardando la documentazione sembra che questo sia un requisito per risolverlo:

Dalla pagina fai riferimento: "Ogni registro dei certificati deve pubblicizzare pubblicamente il proprio URL e la sua chiave pubblica (tra le altre cose) Chiunque può interagire con un log tramite i messaggi HTTPS GET e POST."

I monitor stanno acquisendo lo stato di questi registri e si assicurano che siano coerenti con la loro cronologia. Presumibilmente, se l'auditor non è a conoscenza del log, lo collegherà immediatamente al browser [Altro sotto].

  • Can the browser tell if a log is legitimate?
  • Does the browser or its Auditor component send the SCT to Monitors?

Ancora una volta, dalla pagina fai riferimento: "La maggior parte degli auditor sarà probabilmente incorporata nei browser. In questa configurazione, un browser invia periodicamente un batch di SCT al componente di controllo integrato e chiede se gli SCT (e i certificati corrispondenti) sono stati aggiunto legittimamente a un log. L'auditor può quindi contattare in modo asincrono i log ed eseguire la verifica. "

Se si tenta di creare il proprio registro o di corromperlo, i monitor potrebbero rilevarlo. Sono un po 'incerto sul termine "periodicamente" sopra. Non sono sicuro di aver capito il dosaggio o gli SCT. Ciò significherebbe che i browser presumerebbero che gli SCT fossero buoni fino a quando non fossero stati informati diversamente? Mi sembra un buco. Penso che vorresti verificare immediatamente qualsiasi nuovo certificato quando è stato presentato.

    
risposta data 29.10.2015 - 16:45
fonte