Everything you always wanted to know about Certificate Transparency (33c3)

[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)]