[Translated by Gianluca Consiglio (KYBS2004 course assignment at JYU.FI)]
Herald: Sono emozionato di essere qui, immagino anche voi. Inizieremo con il nostro
primo relatore della giornata. È un ricercatore di sicurezza presso SBA Research, ed è anche
un membro del CCC Vienna. Il talk che sentiremo oggi è "Tutto quello che avresti sempre
voluto sapere sulla Certificate Transparency" e con questo, passo
il palco, per favore date un caloroso benvenuto a Martin Schmiedecker!
*applausi*
Martin: Grazie mille per queste gentili parole e questa bellissima introduzione.
Come appena detto, sono membro del CCC Vienna, sono anche su twitter, quindi se avete un
commento dopo, o volete pingarmi, se trovate un errore nelle diapositive, o
qualunque cosa, pingatemi su twitter.
Quindi, di cosa parla questo talk? Di cosa parleremo?
Certificate Transparency è una novità nell'ecosistema TLS
quindi non molte persone hanno familiarità con la sua esistenza. Quindi presenterò una
panoramica, cos'è CT e cosa fa e guarderemo anche sotto il cofano per vedere cosa
fa effettivamente, come funziona e come puoi giocarci. Quindi una delle cose
che devo dire su di me: sono un grande fan dei meme di Internet. Quindi anche se queste
sono immagini esilaranti. Personalmente trovo immagini esilaranti che metto online. Tieni
a mente che HTTPS è un argomento serio. Che tu faccia net banking, che tu stia
googlando, o qualunque cosa tu faccia online, HTTPS è lì per proteggere la tua privacy e per
proteggere la tua sicurezza. E in alcuni stati, questo è stato dimostrato dalla storia, questo non
è un caso, quindi ci sono dispositivi di introspezione a livello nazionale che aprono
la crittografia TLS e guardano il contenuto. E le persone riceveranno una visita dalla polizia
segreta o altro e busseranno alla loro porta e li arresteranno. Proprio come questa
settimana è successo in Turchia, dove le persone sono state arrestate per aver postato cose su Facebook.
Quindi, anche se ci sono alcune immagini divertenti, tieni presente che questo
è solo un mezzo per un fine per la mia presentazione. Personalmente trovo che HTTPS sia un
argomento molto importante. Spero di poterti convincere anche voi. E CT in particolare è
affascinante. Perché esiste qualcosa come Certificate Transparency? Il nome dice tutto:
se sei un'autorità di certificazione, vuoi rendere pubblici i certificati
che vendi o che emetti. Come per molte buone storie e molti buoni strumenti, tutto è iniziato
con un hack. Nel 2011 c'era questa autorità di certificazione olandese chiamata
DigiNotar, e sono stati compromessi. Sono stati davvero, davvero malamente fregati.
*risate*
Hanno perso tutto. Hanno perso tutti i loro gioielli della corona. E come parte di questo hack,
sono stati emessi 500 e qualcosa certificati fraudolenti.E non solo
certificati, non solo come Let's Encrypt, dove puoi ottenere un certificato gratuito, e
poi usarlo per i tuoi sistemi interni, o per il tuo sito web, o altro. No,
davvero, davvero domini di alto valore e alto valore dei certificati. Come google.com, molto
invasivo per la privacy, se riesci a leggere cosa le persone stanno googlando, o cosa stanno
inviando nelle loro e-mail. windowsupdate.com, che è come la porta
sul retro di una parte del mondo windows. mozilla.com, l'attaccante potrebbe manipolare
il download di Firefox, firmarlo con il certificato e spedirlo tramite un
sito web dall'aspetto sicuro. torproject, e così via. Questo era nel 2011 e questo non era
solo un piccolo incidente, non è stata una piccola CA, ma era una CA regolare con attività regolari.
C'è altro su questo hack: questi certificati sono stati
poi utilizzati per intercettare la comunicazione dei clienti. Persone che navigano sul web, che leggono
la loro email. L'azienda che ha indagato sulla violazione in seguito ha scoperto
che almeno 300.000 indirizzi IP si stavano connettendo a google.com e stavano
vedendo questo certificato fraudolento. Il 99% dei quali provenivano dall'Iran. Quindi era una specie di
attacco di uno stato-nazione contro i clienti basati su ISP o basati su gateway di confine
dove le persone pensavano di navigare in modo sicuro tramite HTTPS, ma in realtà non lo
erano. Questo è un fotogramma meraviglioso dal video. I ragazzi di Fox IT che hanno
indagato su questa violazione hanno usato le richieste OCSP. Ogni volta che ottieni un
certificato, il tuo browser deve in qualche modo capire se questo certificato è ancora
valido. Se è stato revocato, sarebbe bello non usarlo più. E uno degli approcci che
vengono utilizzati è il cosiddetto OCSP, quindi il client chiede all'autorità di
certificazione: "Ehi, è ancora valido?". E questo è stato registrato. Ognuna di queste
richieste è uno dei client che vede questo certificato fraudolento e chiede a
DigiNotar: "Ehi, questo certificato è ancora valido?". E come puoi vedere, la maggior
parte delle connessioni - in realtà è un film, quindi puoi vedere le luci che
lampeggiano e si accendono e si spengono mentre le persone vanno a dormire e si svegliano di nuovo. E la maggior parte delle
persone proveniva dall'Iran. Quindi come ha fatto DigiNotar a essere violato? Sono stati davvero,
davvero, gravemente violati perché avevano vulnerabilità ovunque. Avevano un
sistema in esecuzione che era incomprensibilmente insicuro per un'autorità di certificazione.
La gente pensa che se gestisci un'autorità di certificazione, costruisci le basi per
una comunicazione sicura online. Sei tu quello che protegge la comunicazione su
Internet. E se gestisci un'entità del genere, la gente pensa che tu sappia di sicurezza.
In realtà,
*risate*
in realtà, DigiNotar non lo sapeva. Avevano software non aggiornato, che era aperto a Internet
Potrebbe succedere. Non avevano antivirus sulle macchine che emettevano i
certificati. Non avevano una password sicura per il loro account admin. Quindi
tipo "password" o "admin". In realtà, puoi leggere il rapporto online e le
raccomandazioni di ENISA, l'organismo europeo per la sicurezza, hanno elencato
tutte le cose che sono state trovate e identificate. Inoltre, tutti i server di
emissione dei certificati erano in un unico dominio Windows. Anche una cosa negativa da DigiNotar: hanno mantenuto
segreto l'incidente. Ovviamente, non volevano diffondere su Internet "ehi, siamo stati
violati e abbiamo avuto una brutta sicurezza". Hanno tenuto nascosto questo incidente
per più di 2 mesi.
Dopo 2 mesi, quando è diventato pubblico e quando Internet l'ha scoperto,
che in realtà era successo qualcosa di davvero, davvero brutto, l'hanno scoperto e
DigiNotar è poi fallita. Questo è il triste epilogo della storia. Ma questo non è uno
dei problemi che le autorità di certificazione affrontano. Se gestisci
un'autorità di certificazione, emetti certificati in base all'identità dei tuoi
clienti. Puoi creare CA secondarie, quindi puoi dire Ehi, Martin, sembra un bravo
ragazzo, sembra che sappia di sicurezza, facciamolo diventare una CA e facciamogli
verificare le identità. Probabilmente non è una buona idea, ma questo è il modello di business
di HTTPS e delle autorità di certificazione. Rilasciano certificati e concedono anche
il permesso di rilasciare certificati. E l'intero obiettivo di queste
aziende è entrare nei trust store. Ogni browser, ogni sistema operativo, ogni cosa
che si connette tramite TLS ha qualcosa chiamato trust store, dove memorizza le
entità che hanno il diritto di emettere certificati. E il problema è che queste CA
non vengono rigorosamente controllate. Hanno i loro requisiti che devono soddisfare.
Devono dimostrare di avere una sorta di sicurezza. Ma in seguito, una volta
certificati e una volta nei trust store, non c'è un forte incentivo a controllarli,
perché sono già nei trust store e hanno avuto i loro
controlli e così via. Questo può portare a molti problemi.
Un'altra CA,Trustwave, nel 2011, ha emesso certificati sub-CA. Chiunque abbia un sub-CA
può emettere un certificato TLS per qualsiasi dominio. Lo hanno usato per il traffico
d'introspezione. Quindi vendevano, non so, a un'azienda, che stava
costruendo apparecchi che possono aprire le connessioni di rete per le banche,
aziende o interi ISP. Possono guardare nel traffico dei suoi utenti. Inoltre,
c'era Lenovo SuperFish, idea meravigliosa. SuperFish era un CA locale
man-in-the-middle, e l'obiettivo del SuperFish CA era quello di aprire il traffico
HTTPS, in modo che potessero inserire annunci.
*risate*
Anche se stai usando gmail e hai questa bella interfaccia elegante senza
annunci evidenti, SuperFish avrebbe aperto questa connessione, sarebbe stata
affidata dal browser e avrebbe avuto enormi annunci sovrapposti. Lenovo ha smesso
di collaborare con SuperFish. Questo era preinstallato sui notebook Lenovo.
Avevano un CA locale installato sul sistema in modo da poter ispezionare il
traffico e mostrare annunci agli utenti. Ciò che è ancora più interessante è che
tutti questi CA avevano la stessa chiave e la chiave privata era nella RAM. Quindi chiunque poteva
estrarre la chiave privata del CA, usarla per firmare certificati per qualsiasi cosa e avere un ulteriore livello di iniezione HTTPS, dove
non solo potevi mostrare annunci, ma anche leggere le e-mail o fare quello che vuoi. Molto male.
Non lo stanno più facendo presumibilmente. Poi c'era, in Cina, il CNNIC, che ha emesso un sub-CA per
un'azienda di introspezione. Di nuovo l'azienda voleva vendere apparecchi dove
potevano aprire le connessioni HTTPS e guardare nel traffico degli utenti. E c'è
stato un altro incidente proprio quest'anno: Symantec stava emettendo certificati di "test"
a un'azienda o altro, tra cui google.com, opera.com, cose che
probabilmente non vorresti testare, e sono stati scoperti. E la cosa bella di questo
incidente è: avevano già installato la Trasparenza dei Certificati. E torneremo
su questo incidente tra un minuto. L'introspezione del traffico è una cosa
valida. Se hai una flotta di aerei e sono collegati tramite costose connessioni
satellitari e paghi davvero molto per la larghezza di banda, vorresti bloccare, ad
esempio, Netflix, o qualsiasi cosa che causi molto traffico. Uno degli approcci
che è stato adottato da Gogo, avevano dispositivi di introspezione del traffico nei loro aerei
e hanno emesso certificati non affidabili per ispezionare il traffico. Male per loro:
Adrienne Porter Felt che lavora per Google se ne è accorta e Gogo non lo fa più.
E anche se l'introspezione del traffico sembra una cosa davvero cattiva,
posso pensare a casi d'uso in cui questo è legittimo. Se gestisci un'azienda,
se gestisci una banca e vuoi impedire alle persone di divulgare dati, questo può andare bene.
Ma deve essere trasparente, le persone devono sapere che questo sta accadendo, che stanno
ispezionando tutto. E comunque non impedirà alle persone di portare con sé l'unità USB
dati. Quindi questo è il quadro generale del perché abbiamo bisogno della
Trasparenza dei Certificati. Vorremmo vedere quali certificati sono stati emessi da un
CA specifico. Alcuni problemi minori, non proprio minori, che entrano in gioco sono
che TLS ha i suoi problemi, indipendentemente dal fatto che questi certificati siano
emessi o meno. Uno di questi è che la revoca dei certificati è complicata. Non
è facile come dire "questo certificato non è più valido".
Una volta emesso un certificato, è valido fino alla data indicata nel certificato,
che può essere di tre anni. Succede che, se il primo giorno di utilizzo di questo
certificato, le persone notano, "uh, dovremmo revocarlo", i client che non
ricevono questo aggiornamento potranno utilizzare questo certificato per due o più
anni. Inoltre, un'altra limitazione è che tutti i CA possono emettere certificati per
tutti i siti web. Ognuno di quei 1.800 CA e sub-CA che erano nei trust store nel 2013
possono tutti emettere un certificato per google.com o facebook.com. Questo non è impedito da alcun mezzo, se non da strumenti
sociali e contratti, che stabiliscono che devono verificare la legittimità della richiesta. Questo era
publicato in un paper del 2013. Esistono più di 1.800 CA in grado di firmare
certificati per qualsiasi dominio su dispositivi utente normali. Un altro documento nel 2014 ha scoperto
che un terzo di loro, un terzo di quelle 1.800 autorità di certificazione,
non hanno mai emesso un singolo certificato HTTPS. Questo ti fa chiedere: perché sono allora
nei trust store e così via. Puoi affermare che una certa percentuale di loro
vengono utilizzati per l'emissione di certificati privati all'interno delle reti. Tuttavia, un terzo di loro
non ha mai emesso un certificato HTTPS pubblicamente ottenibile. Poi, naturalmente, ci sono i
problemi di implementazione. TLS ha una lunga storia di difetti di implementazione. Non solo
crittografici, ci sono logjam, freak, poodle, qualunque cosa. Sono un
problema completamente separato. Ma l'implementazione i problemi stanno turbando la sicurezza dei dispositivi
a un ritmo costante. Un esempio famoso è: "goto fail;" da iOS, dove avevano un
parentesi mancante "goto fail" aggiuntiva e la validità del certificato non è stata controllata.
Inoltre, abbiamo molti dispositivi embedded. Una volta accesi, vengono utilizzati per
generare la loro chiave privata e non hanno accesso a una buona entropia. L'entropia su
i dispositivi embedded sono sorprendentemente difficili. Quindi molti di loro generano le stesse chiavi. E
come già detto, abbiamo diversi trust store per browser, per sistema operativo.
Ognuno ha una base di fiducia diversa. Anche, ovviamente, ogni CA cerca di
accedere a tutti i trust store, essere spediti con gli aggiornamenti di sistema per essere
affidabili, e abbiamo una diversità che non è naturale. Potrebbe essere molto più facile se
le persone avessero la stessa base di fiducia su tutti i loro dispositivi. E ci sono molti
problemi di implementazione. SSLv2: tutti pensano che sia morto, ma a quanto pare non lo è.
Sebastian Schinzel farà una splendida presentazione tra due ore sull'DROWN attack.
L'attacco DROWN utilizza SSLv2 debolezze nel trasporto e-mail. Semplicemente
perché è attivato e utilizza il stessa chiave, puoi attaccare la crittografia TLS 1.2 di prim'ordine
perché questo è ancora qui. C'è l'intero shmafoo dei certificati SHA1.
Le autorità di certificazione non dovrebbero più emettere certificati SHA1.
Alcuni lo fanno, alcuni vengono catturati, perché hanno retrodatato i loro
certificati e così via. È un casino. Poi ci sono le cypher suite. Ce ne sono più di
500 cypher suite disponibili per il diverse versioni di TLS. Ogni amministratore
vorrebbe essere il più sicuro possibile ma quale dovrebbe scegliere. Non appena
ci sono soldi in gioco, come Amazon, devono essere compatibili con Internet
Explorer 6 e così via. È davvero un casino. E, naturalmente, email STARTTLS: Email
non ha mai avuto il design per incorporare sicurezza e autenticazione, quindi come sempre,
l'hanno appena aggiunto sopra, e questo è STARTTLS. Il problema con STARTTLS è che
può essere soppresso e le persone torneranno al testo in chiaro se non riescono a raggiungere il
servizio con STARTTLS. Perfect forward segretezza e così via, l'implementazione è un'altra
argomento che può essere un discorso. E lì c'è questo sviluppo problematico che il
CA, vengono acquistati e venduti costantemente. Proprio quest'anno, Symantec
ha acquistato la società BlueCoat. Symantec è una delle CA più grandi. Gestiscono l'intero
- non l'intero, ma gestiscono gran parte delle certificazioni osservabili.
BlueCoat è diventato popolare nella primavera araba, perché hanno trovato proxy BlueCoat che
sono in grado di utilizzare attacchi man-in-the-middle per condurre l'introspezione del traffico,
sono stati utilizzati presso un ISP, penso in Siria o Egitto. Li hanno trovati e hanno
sono stati implementati a livello nazionale. Quindi, se ci pensi che Symantec, una delle più grandi
CA, sta acquistando BlueCoat, una delle più grandi aziende di introspezione del traffico, le cose
possono sembrare davvero sospette o spaventose.
Certo, hanno promesso che non avrebbero mai usato Symantec
*risate*
Questo è lo stato in cui ci troviamo. Va bene, ma non lo è. Ma le persone pensano ancora
che HTTPS sia sicuro. E in realtà ci è voluto un decennio per insegnare alle persone che
devono cercare l'icona del lucchetto. Ma se non capiscono - in realtà non sanno
come appare l'icona del lucchetto. Ma l'intera icona del lucchetto è una farsa se si scava
nei dettagli. Siamo tutti seduti in una stanza piena di fiamme, per così dire. Quindi,
è qui che entra in gioco la trasparenza dei certificati. La trasparenza dei certificati ha
l'obiettivo di identificare le autorità di certificazione fraudolente. In un mondo perfetto, qualsiasi
autorità di certificazione pubblicherebbe tutti i suoi log, pubblicherebbe tutti i
certificati che emette. Quindi, non appena ottengo un certificato per schmiedecker.net,
l'autorità di certificazione - questo fa parte della chiave pubblica/privata, può essere
pubblica - quindi non sarebbe bello se la CA pubblicasse che ha appena emesso un
certificato per schmiedecker.net? Fondamentalmente: sì. Naturalmente, la certificazione
le autorità non vogliono che ciò accada, in particolare se vendono a stati strani o
aziende strane che guadagnano i loro soldi con l'introspezione del traffico e
così via. Quindi il mondo perfetto sarebbe la chiave pubblica di ogni certificato sarebbe
pubblicata. L'autorità di certificazione potrebbe dire "Ehi, ho appena emesso questo
certificato" e tutti potrebbero vederlo, potrebbero verificarlo
e sarebbe, beh, un mondo migliore.
Questo aiuterebbe a rilevare i problemi molto presto. Quindi, se un piccolo olandese
l'autorità di certificazione emettesse un certificato per google.com o
torproject.com, questo sarebbe evidente. Voglio dire, questa è una piccola CA, sarebbero
davvero - dovrebbero essere davvero sorpresi se google.com decidesse di emettere un
certificato per il loro servizio. Questo ridurrebbe la finestra di opportunità per un
attaccante. Inoltre, l'idea è di avere una forma di punizione per le CA che si comportano male. Quindi
al momento, in questo momento, se a l'autorità di certificazione fa casino, e
Google è interessato, impongono che debbano avere passaggi aggiuntivi per essere
reintrodotti nei trust store. Questo è quello che ha fatto Google. Hanno fatto il Power
Ranger muove, e hanno deciso che vogliono rendere Internet più sicuro. Perché Google?
Beh, Google è posizionata in modo univoco in un modo che controllano i client con
i loro browser con il sistema Android, e controllano anche una vasta porzione di
i server. Tutti usano Google, tranne per quelli che usano Bing.
*risate*
Stavo scherzando. Quello che ha fatto Google è, una volta che l'hack di DigiNotar è diventato pubblico, hanno bloccato
i loro certificati. Poiché Chrome ha un ciclo di aggiornamento decente, possono spedire il
certificati che si aspettano di vedere con un aggiornamento del browser. Quindi, non appena
il browser si aggiorna in background, può applicare il certificato specifico che esso
si aspetta di vedere per google.com, youtube.com e qualsiasi altra cosa. Inoltre, ha un
quota di mercato davvero enorme. 50% e più, a seconda di come si conta. Chrome e
Chromium sono piuttosto popolari. E, infine, sono un obiettivo comune. Quindi, se alcuni
il dittatore decide di ispezionare il client e-mail, e-mail utente, di solito prendono di mira
gmail.com, perché hanno una discreta sicurezza, non hanno altri
vulnerabilità o backdoor per consentire l'accesso ai loro contenuti. Il che rende
l'attacco a Gmail un attacco molto drastico. Con le modifiche che Google ha introdotto
in Chrome con il blocco dei certificati, ora possono rilevare questi attacchi.
Ma questo era già nel 2011. Da allora, per esempio, il Tweet di Porter Felt che ti ho mostrato, se Chrome andasse su un
sito web google.com o youtube.com, e avesse un certificato fraudolento, avvertirebbe l'utente
E quello che Google ha fatto allora è stato proporre uno standard, per fare un
RFC, come pubblicare in modo trasparente i log per i certificati che sono stati emessi.
L'idea dell'RFC è che ogni certificato emesso è pubblico. Questo è
implementato in un log pubblico, solo aggiuntivo. Quindi hanno un log, hanno API aperte,
e accettano ogni certificato. Poi, crittograficamente assicurato, il client come
il browser può verificare che questo sia un certificato registrato pubblicamente. E il
l'intero sistema è aperto a tutti. Quindi puoi
andare sul sito, puoi ottenere il codice sorgente,
puoi eseguire il tuo log per RFC 6962.
E tutti sono felici.
Gli obiettivi erano rilevare i CA che si comportano male. Come ho detto,
hanno i loro audit, hanno le loro regolamentazioni di conformità, e così via, ma
non a livello di certificato. Con la trasparenza dei certificati, diventano
udibili dal pubblico, dai browser. Tutti possono interrogare i log e vedere
se questa particolare autorità di certificazione ha emesso un
certificato per google.com.
Va bene! Dopo aver letto l'RFC, ci sono tre entità
che fanno parte della certificazione trasparenza. Ci sono, per uno,
i log, che sono come giganteschi aspirapolvere. Ingeriscono tutti i certificati
che vengono loro inviati, e poi li firmano crittograficamente ed emettono la
garanzia che questo specifico certificato è stato registrato. E questo è stato emesso
e non è stato manomesso, e così via. Poi ci sono i monitor. Essi
identificano i certificati sospetti. Di solito, queste sono le autorità di certificazione
stesse che eseguono quei monitor. E poi ci sono gli auditor. Gli auditor
di solito sono implementati nel browser. E verificano che i certificati emessi
siano effettivamente registrati. Guardando loro in dettaglio: il ruolo del monitor
e l'auditor è in qualche modo intercambiabile, quindi un monitor può essere un
auditor, avanti e indietro. Quello che fa il monitor, preleva tutti i certificati.
Quindi hai questo gigantesco pool di certificati. Sono crittograficamente assicurati che
vedremo presto. E il monitor li preleva tutti. E hanno una qualche forma di
controllo semantico. Possono vedere, c'è stato un certificato per il mio dominio,
è stato creato un sub-CA, che è in grado di emettere certificati per il traffico
introspezione, e così via. Inoltre, cosa possono fare, con questi dati, possono
identificare gli operatori di log che si comportano male. Ho detto, i log, sono solo giganteschi
aspirapolveri, che raccolgono tutti i certificati, e hanno bisogno anche di audit,
ovviamente. Hanno bisogno - hanno una posizione di potere, perché sono
gestendo questo enorme pool di certificati. E bisogna sfidare il log per
identificare il comportamento scorretto. Questo può essere fatto da i monitor, possono anche essere fatti da
gli auditor. Ogni client - in questo momento, è implementato in Chrome. Chrome controlla per
questi certificati di trasparenza blob firmati crittograficamente. E il
browser e tutto, possono verificare anche l'integrità del log. Quindi nel
backend, il log, crea un albero hash. Questo albero hash è firmato. Ci arriveremo
in un secondo. Mi sono perso qui. Quindi entrambi monitor e auditor, interrogano che il
l'entità del log funziona correttamente. Non sarebbe una buona cosa se la Cina potesse andare
a Google e dire loro "Ehi, vorremmo far rimuovere questo certificato". Google
potrebbe quindi conformarsi o non conformarsi ma se rimuovono il certificato questo
sarebbe verificabile e questo sarebbe osservabile al pubblico. Quindi la cosa buona
è che chiunque esegua qualsiasi software, chiunque di voi in questa stanza può eseguire un'entità di log.
Hai bisogno di una sorta di accesso ad alcuni certificati, quindi se sei un
autorità di certificazione, puoi semplicemente eseguire un log pubblico, e tutti possono spingere il loro
certificati al tuo servizio. In questo momento, questo non è il caso. Di solito, i CA eseguono
i monitor e gestiscono i log, ma questo non è per progettazione, chiunque può eseguire
qualsiasi cosa. Uno dei problemi è disponibilità. Quindi anche se posso impostare
un log per i certificati, ho il problema che il mio log deve essere online 24/7. Il mio
L'ISP non è contento se gli chiedo di garantire questo per me, se non pago molto di più
Quindi, come funziona? Attualmente, se si ottiene un certificato, si va al
autorità di certificazione, dici, "ehi, Sono questo meraviglioso dominio, per favore potrei
prendi un certificato?" E poi ottieni il certificato. Cosa succede in più
con la trasparenza della certificazione è che la CA, quando emette il certificato - può
essere qualsiasi CA, può essere Let's Encrypt, può essere Thawte, Symantec, come vuoi -
quello che fanno è inviare il certificato una volta emesso, inviano il
certificato a uno dei log. Il log poi firma la ricezione positiva del
certificato e invia immediatamente qualcosa indietro. Questo blob si chiama
SCT, il timestamp del certificato firmato, e questo può poi essere incluso nel
certificato o con altri metodi. Punto chiave qui è che una volta che il server installa il
certificato, installa anche questo SCT, in modo che i browser possano vederlo e analizzarlo.
Alcune persone potrei averle perse qui. Tuttavia, tutto è più facile in
immagini. In questo momento, attualmente - e queste sono le immagini dal sito web di certificazione
trasparenza, grazie per averle fatte - le mie abilità con le immagini non sono davvero così
buone, quindi non sarei mai stato in grado di fare grafici così belli. Quindi attualmente,
c'è l'autorità di certificazione. Essa rilascia un certificato e il sito web poi
lo installa nella directory corretta. I client lo controllano e la crittografia può
accadere. Il passo aggiuntivo, e questa è la cosa bella, può accadere senza alcun
passo aggiuntivo sul lato server e sul lato client, è solo che il
l'autorità di certificazione deve fare un passo aggiuntivo. Quindi invece di solo
rilasciare il certificato, inviano il certificato ai log, il log
invia immediatamente indietro il cosiddetto SCT, il timestamp del certificato firmato, e questo
viene poi incluso nel certificato, che viene spedito al client. E poi il
client, se lo supporta, può chiedere al server se questo particolare
certificato è incluso o meno. Le cose che tornano dal log sono
firmate, hanno un ID e hanno un timestamp. Queste sono le cose importanti.
Devono essere inclusi in quegli SCT. Inoltre, ciò che sarà interessante in
futuro, è che il certificato può avere più voci di log. Quindi l'SCT è come una
promessa. L'operatore del log promette di includere questo certificato nei suoi log. E
tutti possono controllare in seguito se questo log ha davvero registrato pubblicamente, o se
l'autorità ha omesso di registrarlo. In futuro sarà il caso che molti
SCT possono essere all'interno di un certificato. Se sono un autorità di certificazione posso andare a qualsiasi
operatore di log, inviare loro ogni certificato che ho e poi includere molti, molti SCT.
E l'SCT non è privato. Questo è solo un ID, è un timestamp ed è una
firma. Questo è probabilmente troppo. Ci sono diversi modi per il client di
verificare che questo certificato abbia un SCT. Quindi uno dei metodi, ad esempio, è l'OCSP
stapling. In questo momento, se hai un certificato, invece di andare alla CA,
il server può applicare la richiesta OCSP firmata dalla CA. E all'interno di questo OCSP
stapling può anche essere incluso l'SCT. Come funziona sul lato log?
Tutto ciò che c'è è un albero hash di Merkle. Un albero hash di Merkle è un
meravigliosa struttura dati. Non è niente di nuovo, non è niente di speciale e non è la
blockchain.
*risate*
L'albero hash di Merkle, sembra, è un albero binario. Ogni nodo ha due figli,
e il valore hash di un nodo interno dipende dai due figli. Quindi di solito
è la concatenazione dei valori di i due figli. Viene nuovamente sottoposto a hash, fino a
la radice. Lo rende molto efficiente in termini di spazio perché se voglio verificare l'integrità
di un intero albero, tutto ciò che devo controllare è il valore hash della radice. Poi, ovviamente
,posso ottenere tutti gli hash rilevanti valori, e poi posso ricostruirlo. CT
usa l'albero di Merkle SHA256 e, come ho detto, tutto ciò che si trova sotto un certo nodo è
responsabile del valore hash. Quindi se tu rimuovi un nodo, se aggiungi un nodo o se
sposti un nodo, i valori hash di tutti i nodi superiori vengono modificati. Ognuno di
gli operatori di log, oltre alla promessa di includere ogni
certificato che ricevono, fanno anche una promessa sul massimo ritardo di
fusione. L'SCT, la promessa di includere questa catena di certificati nel log,
può terminare immediatamente perché è una promessa di includerla nel log. E il
massimo ritardo di fusione è il tempo in cui l'operatore di log promette di
includerlo nel grande, grande albero di hash di Merkle. La cosa buona dell'albero
è che, nonostante siamolto efficiente in termini di spazio, calcolo, non ci sia molto sovraccarico di dati e così via,
non è possibile retrodatare gli elementi. Questo era interessante per una delle autorità di
certificazione che ha emesso certificati firmati SHA1,
anche se i browser e tutti hanno concordato che questo non dovrebbe più accadere.
Quindi non è nemmeno possibile rimuovere elementi che sono stati inseriti. Quindi
se Symantec decidesse di rimuovere il certificato google.com, che era un "test",
questo sarebbe notabile, perché se si rimuove una delle foglie, i valori di hash
fino alla radice, cambiano tutti. E non è nemmeno possibile aggiungere elementi. Se
si volesse aggiungere un elemento in modo impercettibile, non è possibile farlo,
perché i valori di hash di tutti i nodi superiori cambierebbero. Quindi come
funzionano i log? Quello che di solito fanno è che ogni ora ricevono i certificati
e ogni ora li includono nel loro albero di hash di Merkle.
Probabilmente già troppi dettagli. Costruiscono un albero separato e poi lo
includono e ricalcolano il valore di hash della radice, che viene poi firmato e
spedito. E la cosa bella dell'albero di Merkle è che ci sono diversi modi per
dimostrare le cose. Una delle cose che si possono dimostrare è se questo operatore di
log è onesto. Se un operatore di log rimuove uno dei certificati, questo diventa
visibile cambiando tutti i nodi rilevanti. Inoltre, è molto efficiente. Anche una
figura dal sito web del progetto. Sul lato sinistro, c'è un albero di Merkle con
alcuni certificati aggiunti, certificati aggiunti. E se un monitor o un revisore
decide di sfidare l'operatore di log, in un secondo momento, se questi certificati
D6 e D7 sono stati aggiunti correttamente, tutto ciò che l'operatore di log deve
inviare sono quei nodi evidenziati. Questa è la radice, questa è la cosa che viene
firmata, ad esempio, ogni ora. Questo è pubblico. I certificati sono pubblici
perché, sono certificati. Se ora qualcuno vuole verificare che non solo questi siano
stati inclusi, questo è molto facile, perché basta calcolare fino in cima,
ma anche verificare che tutti gli altri certificati siano ancora lì, quindi nessuno
dei vecchi certificati è stato rimosso, devono essere trasmessi solo tre valori di
hash. E poi lo sfidante può ricalcolare tutto. Quindi, non appena lo sfidante
conosce quei valori di hash, può concatenare tutto di nuovo insieme e alla
fine, dovrebbe avere lo stesso valore di hash della radice. Un'altra prova che è
possibile è se un certificato specifico è ancora nel log. Quindi non è solo
possibile sfidare la coerenza dell'intero log per quanto riguarda i vecchi dati, ma
anche verificare che un certificato specifico sia ancora nei log, o sia stato
inserito nei log. Ricorda, l'SCT, la cosa che è terminata immediatamente, è solo una
promessa di includerla nei log e, in un secondo momento, chiunque, qualsiasi revisore
può sfidare l'operatore di log se il certificato è davvero nel log. Quindi,
di nuovo, se voglio verificare che un certificato specifico sia nel log, ho il
certificato che vorrei sfidare, quindi ho solo bisogno, in questo esempio, di quei
tre nodi e tutto il resto, il nodo j può essere calcolato perché ho il certificato.
Quindi ho l'hash del certificato. Ho bisogno di questo hash, quindi posso calcolare
questo valore e così via, fino a quando non sono alla radice. Questo è quanto basta
per la parte tecnica. Gli alberi di hash di Merkle sono scomparsi. Uno dei problemi di questi log
è che sono in continua crescita. Potresti aver notato che non abbiamo parlato di
cancellare i certificati, per validi motivi, sono in continua crescita. Ovviamente, niente
è per sempre, quindi quello che fanno gli operatori di log è che ruotano i log. Quindi a un
spunto specifico nel tempo, il log viene congelato, l'albero è quindi statico, e c'è
un'altra entità di log, che viene messa online e utilizzata per includere i nuovi
certificati. Molto recentemente, aviator di Google è stato congelato.
Contiene 46 milioni di certificati.
Piccolo inconveniente del congelamento di un log: finché un certificato in questo
log, in questo albero è ancora valido, questo log deve essere raggiungibile. Non appena tutti
i certificati sono scaduti, può essere scaricato. Ma fino ad allora deve essere
disponibile per le prove.
Uno dei problemi è che in questo momento ci sono solo pochi operatori di log.
In futuro, ce ne dovrebbero essere molti di più. Non centinaia di migliaia di
loro, ma forse centinaia di loro. E loro hanno bisogno di scambiare informazioni. Una forma di
chiacchiericcio di log dovrebbe apparire. Il log gli operatori chiacchierano con i clienti per
verificare che tutti vedano lo stesso stato di alberi di Merkle. E questo è stato
pubblicato in un articolo l'anno scorso. In questo momento, l'idea non è ancora a un livello in cui
hanno bisogno di chiacchierare, cosa che vedremo presto. Questo accade quando crei meme sul
treno. Di solito, sono meme molto brutti. Questo è apparentemente Gossip Girl, non l'ho mai
visto, ma se cerchi gossip e meme, ta-da!
*risate*
Chi gestisce ora i log? Chi sono i entità che stanno eseguendo attivamente i log. Di
certo, Google gestisce la maggior parte di loro. Hanno proposto l'intera cosa, hanno
scritto il codice per eseguire queste cose, e gestiscono i grandi, aperti a tutti
log dei certificati. Tre di loro sono attualmente aperti a tutti. Un altro è per
Certificati di Let's Encrypt, e un altro uno è per certificati non Let's Encrypt.
Ovviamente, Let's Encrypt emette molti certificati., per fortuna. Quindi loro
hanno separato quello, a quanto pare. Se leggi la mailing list, promettono che questi
i log aperti a tutti gratuiti sono separati geograficamente e amministrativamente. Il
sono gestiti da entità diverse, ma loro hanno tutti lo stesso capo, e sarebbe
meglio se ci fossero più log aperti. Symantec ne ha uno, Wosign, CNNIC. Ogni volta
Google rileva che un fraudolento certificato per google.com è stato
emesso, quelle autorità di certificazione sono obbligate a eseguire CT. Che è una buona
cosa, voglio dire, pubblico e tutto. Google ha decine di milioni di
certificati. Hanno davvero un log aperto a tutti, quindi tutti possono spingere
certificati lì dentro. DigiCert, Symantec è una specie di grande, ma tutti gli altri nodi
che sono elencati sul sito web, hanno un centinaio di migliaia di certificati, che
non è poi molto rispetto a 50 milioni o 60 milioni. In questo momento, Google già
impone la trasparenza dei certificati per certificati a convalida estesa, quindi se tu
non solo vedi il testo verde nell'angolo in alto a sinistra angolo del tuo browser, ma anche qualche
nome elegante e grande, grande verde qualunque cosa, questo è un certificato EV. E Google impone
per i certificati EV di avere due SCT. Firefox è in procinto di includerlo, credo.
Inoltre, a quanto pare, la trasparenza dei certificati funziona. Perché, quando Symantec ha emesso questo
certificato per google.com hanno rilasciato un rapporto che afferma di aver trovato 23 "test"
certificati. Symantec ha detto di aver emesso 23 certificati di prova. Ma i log sono
pubblici, chiunque può interrogarli. E in secondi, puoi vedere che Symantec ha emesso
altri 164 certificati per altri domini, e anche 2.500 certificati per
domini non esistenti. Solo per quanto riguarda questo problema. Devo fare in fretta, il tempo è
sta per scadere. Alcuni degli svantaggi di trasparenza dei certificati. Certo:
privacy. Le persone possono apprendere i tuoi interni host, quindi se hai NAS per esempio, e
questo NAS è raggiungibile solo all'interno del tuo LAN, e vuoi sbarazzarti del
Avviso del browser ogni volta che accedi all'interfaccia del tuo NAS, puoi ottenere un
certificato Let's Encrypt, ma poiché non solo il certificato viene pubblicato, ma anche viene
registrato, le persone possono vedere nel file di log pubblico che c'è, per il tuo dominio, un
NAS. Inoltre, le voci di registro devono contenere l'intera catena fino a un certificato root
attendibile, che esclude tutto ciò che è auto-firmato e tutto ciò che è DANE. DANE serve
per verificare i certificati TLS utilizzando DNSsec. E poiché questi due non hanno una root
attendibile, attualmente non funzionano per la trasparenza dei certificati.
Ora, ovviamente, vuoi vedere i dati. Giocherai con questo.
Fondamentalmente, cosa puoi interrogare, tutto è JSON. Quindi, se conosci JSON, puoi
lavorare con la trasparenza dei certificati. L'URL di base è questo. L'URL è qualsiasi log
server, risponde con la root corrente e la sua firma, usando questo URL. Più
interessante, ti dà anche il numero di certificati e il timestamp.
Poi assomiglia a questo. JSON, quindi hai, questo è il log aviator di Google,
che ora è congelato. Ha 46 milioni di certificati, il valore hash di
l'albero di Merkle e la firma. Inoltre, puoi sfidare i registri di certificazione con
prove di coerenza, dove hai due stati del loro albero e il log deve
dimostrare che non ha modificato nulla tra di loro. E, naturalmente, puoi
verificare che un certificato specifico sia nell'albero con il secondo URL. E puoi semplicemente
inserire i certificati lì con una richiesta POST. Quindi lo inserisci, rimandano
l'SCT, se sei l'operatore del log, allora lo includeresti. Qualsiasi sito Web che
al momento non utilizza SCT, tutto ciò che serve è una richiesta POST. Niente di più. Alcune schermate
dagli interni. Questo è per google.com nella visualizzazione degli interni della rete. Cosa
puoi vedere è che il timestamp del certificato firmato, l'SCT, è ricevuto. È valido. E
la conformità è verificata. Quindi questo era per google.com. E tutto ha funzionato.
Ultimo ma non meno importante, solo per menzionarlo, Comodo gestisce un ampio motore di ricerca,
crt.sh. Lì puoi interrogare i log pubblici. Inoltre, Facebook ha recentemente aggiunto un monitor
per i certificati. Quindi, se possiedi un nome di dominio e utilizzi un'entità che - no se
possiedi un dominio, puoi ottenere aggiornamenti se il certificato cambia. Monitorano anche
i log pubblici e non appena, ad esempio, facebook.com utilizza un nuovo
certificato che viene registrato in CT, puoi ricevere una notifica per questo. Questo è quello che
sembra. Ricorda, Facebook può anche inviare e-mail crittografate PGP, quindi niente
trapela a nessuno. Questo screenshot è stato preso in prestito da Scott Helme. Allora, cosa
succede? Solo pochi - Un mese fa, Google ha annunciato che richiederà la trasparenza dei
certificati da ottobre 2017 in poi. Quindi, se gestisci un sito Web protetto da TLS
potresti voler verificare prima di quella data se la tua autorità di certificazione
sta utilizzando la trasparenza dei certificati. Mi aspetterei di avere più
log e più certificati inclusi nei log. In un futuro lontano, fondamentalmente, il
l'idea di trasparenza e questo albero di Merkle è aperto a qualsiasi cosa. Potresti metterci la chiave
mdi gestione delle release dei software, qualsiasi cosa lì. Il team di Google, ha anche
costruito un prototipo per questo, chiamato Trillian, e descritto nel documento
"Verifiable Data Structures".
Prima di arrivare alla fine e alle domande,
*risate*
*applausi*
C'è una distinzione. Certo, tu potresti risolvere questo problema anche con la blockchain.
Ma un albero hash di Merkle è molto più efficiente, molto più elegante. Quando io
ho parlato con un collega sul treno qui, ha detto, certo, puoi semplicemente inserire il
log nella blockchain. Sì, non è la stessa cosa.
Grazie!
*applausi*
Herald: Grazie Martin per questa interessante chiacchierata! Abbiamo ancora
qualche minuto per le domande, quindi se avete una domanda, mettetevi in fila
accanto ai microfoni e ponete la vostra domanda. Ricordate: una domanda ha un punto
interrogativo alla fine. Inoltre, se state uscendo, fatelo silenziosamente e dalla porta
principale, grazie. Penso che ci sia una domanda laggiù:
D: Puoi consigliare alcune librerie o software dove posso effettuare l'handshake TLS
dal lato client, in modo da ottenere l'SCT, tramite estensione TLS, tramite estensione
OCSP, tramite l'SCT del pre-certificato ereditato?
M: Non a memoria. Voglio dire, se fa parte del certificato TLS, qualsiasi cosa andrà bene, OpenSSL,
qualsiasi cosa, è solo un campo. Lo stesso per OCSP, quindi qualsiasi cosa che faccia OCSP lo
includerà, è solo che i client che non conoscono l'estensione semplicemente non -
la ignoreranno. Ma qualsiasi cosa che faccia OCSP o handshake SSL funzionerà.
H: Grazie. Domanda da questo microfono.
D: Ciao, grazie mille per la bella chiacchierata. Sai quanto spazio serve
per memorizzare tutti i log attualmente?
M: Avevo la stessa domanda, ma sfortunatamente no. Quello che memorizzano è
l'albero, e memorizzano l'intera catena, escludendo i certificati radice. Quindi,
probabilmente due, tre, quattro certificati per voce, che è come - penso che si possa comprare
nei normali mercati elettronici un disco rigido in grado di contenere molte di quelle voci.
H: Prossima domanda da quel microfono.
D: Sì, grazie per la chiacchierata. Perché hai bisogno di due SCT per la convalida estesa?
M: Perché una singola entità potrebbe imbrogliare. Quindi è come - anche se puoi rilevarlo,
c'è ancora un lasso di tempo. E se hai due SCT, che sono gestiti
indipendentemente, l'idea è che non è così probabile che i due collaborino
per far sparire un certificato.
D: Grazie!
H: Quel microfono, sì.
D: In realtà sono un po' sorpreso, perché Google ha spinto per rendere il
server HELLO il più piccolo possibile e, naturalmente, questo sta aumentando il server
HELLO con, in questo caso, un SCT, e, naturalmente, stanno anche facendo l'OCSP stapling,
quindi questo lo rende ancora più grande. E questo è come un SHA256, quindi stiamo parlando di 256 bit
lì, più un altro che hai detto che, sai, uno non è sufficiente. In realtà non ho
mai visto che ne ha più di un SCT. Ne hai visti?
M: No.
*risate*
Non ancora.
D: Ho cercato in giro, ma niente.
M: Sì.
D: In realtà sta aumentando le dimensioni. E mi chiedo, dove sta andando.
Stiamo per mangiare i costi di avere tutti questi SCT e OCSP stapling? Siamo
pronti a pagare quel costo?
M: Penso che il costo sia piccolo rispetto al guadagno che ottieni con HTTP2. Quindi se
canalizzi qualcosa in una singola connessione. Penso che non sia più un cattivo costo. Ma
ovviamente, questa è una questione di politica. Richiedere una certa quantità di SCT, per
prevenire CA fraudolente.
D: L'idea è che questo sostituirà qualcosa come l'osservatorio SSL, dove
i browser inviano i certificati che vedono, e poi - hai annuito, quindi presumo di sì. E poi
anche, come funziona per le persone che non possono rendere pubblici i loro certificati?
Per le persone che emettono cose per le reti interne?
M: Se non puoi rendere pubblico il certificato, probabilmente il modo migliore in questo momento
è avere un'autorità di certificazione che non usa CT. In futuro, rende
molto più costoso gestire la propria CA, incorporarla negli archivi fiduciari.
Ma ovviamente, questo è costoso. Devi firmare il certificato e tutto il resto.
D: Ma se, come nell'ottobre 2017, quando Chrome rifiuta tutti i certificati che non hanno
timestamp firmati, cosa faccio?
M: Usa Edge.
*risate*
Sono sicuro che puoi disabilitarlo in qualche modo, ma è *blerg*.
D: E se qualcuno prova SCT con DHT o altri sistemi.
Non blockchain, ovviamente!
È possibile farlo senza autorità centrali?
M: Scusa, ripeti?
D: Il mio inglese è molto cattivo, mi dispiace. Ho detto, è possibile farlo senza
qualche autorità centrale, come Google o tramite SCT, ma
con una tabella hash distribuita, come le tecnologie DHT
M: Sì, sì, certo.
D: E ci sono implementazioni esistenti?
M: Per la cosa centralizzata, sì. Non per la cosa distribuita. Ma penso che sia
solo aggiungere un livello di DHT sopra. Quindi sono sicuro che puoi pensare a un'estensione
del browser che usa il DHT per ottenere SCT. Ma in questo momento è puramente
centralizzato. Ma il codice sorgente è aperto.
D: OK, grazie.
D: Ero solo curioso di come funziona se hai un certificato che viene revocato, nel
contesto dell'albero. Soprattutto se l'albero è congelato. Quindi come funziona?
Come si revoca un certificato con un albero, e poi come funziona se è
già congelato.
M: Ottima domanda! L'obiettivo di CT non è - non riguarda la revoca. Quindi se
il percorso di revoca viene preso regolarmente. Quindi chiedi OCSP. È indipendente dalla
revoca. Dice pubblicamente che questo certificato è stato
rilasciato. Quindi rimuovere un certificato dall' albero, che è stato rimosso - revocato, è
non fa parte della specifica. Questo non è il caso d'uso. È solo la registrazione dei
certificati che sono stati rilasciati.
D: Ma se controlli tutti i registri e vuoi sapere se qualcosa sta, come sta andando
che non dovrebbe andare, non vorresti sapere se il certificato
è stato revocato ad un certo punto?
M: Sì, ma non nei registri. I registri sono solo per dimostrare che la CA ha rilasciato questo
certificato e per dimostrare che il registro ha registrato correttamente. La revoca è
diverso. Di solito, l'OCSP stapling con la CA, ma questo è un canale diverso. Quindi
questo non è per la trasparenza dei certificati.
D: Grazie!
H: È tutto il tempo che abbiamo per le domande e risposte.
Un grande applauso ancora per Martin per un ottimo discorso!
*applausi*
*musica postroll*
[Translated by Gianluca Consiglio (KYBS2004 course assignment at JYU.FI)]