Domanda:
Cos'è il blocco del certificato?
Avery Chan
2013-01-31 05:27:08 UTC
view on stackexchange narkive permalink

Conosco superficialmente SSL e cosa fanno i certificati. Recentemente ho visto alcune discussioni sul blocco dei certificati ma non c'era una definizione. Una ricerca DDG non ha rivelato nulla di utile. Che cos'è il blocco del certificato?

C'è una descrizione ragionevolmente succinta di [certificate pinning] (https://en.wikipedia.org/wiki/Certificate_pinning#Certificate_pinning) in Wikipedia. Per una descrizione più dettagliata, vedere la specifica [Public Key Pinning Extension for HTTP] del gruppo di lavoro IETF Web Security (websec) (http://tools.ietf.org/html/draft-ietf-websec-key-pinning) (attualmente una Internet Draft ma probabilmente presto diventerà un RFC).
FYI: questa domanda è collegata da http://www.theregister.co.uk/2015/03/24/google_ssl_cnnic/
Sono un coautore della RFC per il pinning della chiave pubblica basata su HTTP.Le risposte qui sono imprecise in qualche modo (ad esempio, PKP è separato da STS).Controlla il mio post sul blog sull'argomento, https://noncombatant.org/2015/05/01/about-http-public-key-pinning/, o leggi la RFC stessa, https://tools.ietf.org/html / rfc7469.
Sei risposte:
tylerl
2013-01-31 07:23:32 UTC
view on stackexchange narkive permalink

In genere i certificati vengono convalidati controllando la gerarchia delle firme; MyCert è firmato da IntermediateCert che è firmato da RootCert e RootCert è elencato nell'archivio "certificati di cui fidarsi" del mio computer.

Il blocco del certificato era il punto in cui si ignora l'intera cosa e si dice di fidarsi di solo questo certificato o forse di fidarsi solo dei certificati firmati da questo certificato , ignorando tutte le altre CA radice che altrimenti potrebbero essere ancore di fiducia. Spesso era noto anche come Key Pinning, poiché in realtà era l'hash della chiave pubblica che veniva salvato.

Ma in pratica, Key Pinning si è rivelato causare più problemi di quanti ne risolva. Spesso veniva configurato in modo errato dai proprietari del sito e, in caso di compromissione del sito, gli aggressori potevano bloccare in modo intenzionale un certificato che il proprietario del sito non controllava. Key Pinning è stato ritirato nel 2017 ed è stato completamente rimosso da Chrome e Firefox nel novembre 2019. Inizialmente non è mai stato supportato da IE e Safari.

La sostituzione consigliata è utilizzare Expect -CT per indicare ai browser di richiedere che il certificato venga visualizzato nei log di Certificate Transparency.

Buona risposta, ma dipende anche dal browser; Il browser Chrome di Google blocca i certificati per i siti di Google, quindi nel tuo esempio, un browser Chrome si fida solo di certificati specifici di google.com noti per essere quelli corretti (o quelli firmati dalla Google Internet Authority).
@KeithS il principio è indipendente dal browser. Google blocca i certificati che conosce utilizzando un meccanismo leggermente diverso (hash della chiave pubblica anziché hash del certificato), ma è ancora abbastanza vicino che chiamarlo "pinning" è ancora corretto.
Allora come si fa? Attivazione del certificato, intendo
@user93353 i dettagli del certificato vengono archiviati lato client e confrontati con quelli inviati in rete.
Dettagli più completi su come è fatto (o come potrebbe essere fatto quando le bozze di proposta sono standardizzate): https: //www.owasp.org/index.php/Certificate_and_Public_Key_Pinninghttps: //tools.ietf.org/html/draft-ietf- websec-key-pinninghttp: //tack.io/index.htmlhttps: //www.imperialviolet.org/2011/05/04/pinning.html
"** Hongkong Post Office **" dovrebbe farti pensare
Quello che ancora non capisco sul blocco dei certificati è: perché riesco ancora ad accedere alle app Google tramite un MITM aziendale? So di avere il certificato di root per la mia azienda installato sul mio PC, ma Google non dovrebbe generare un errore quando i suoi siti sono firmati da un certificato (il certificato della mia azienda) che non corrisponde a uno dei certificati bloccati? Forse sto fraintendendo come funziona il pinning.
@JoshvonSchaumburg Quando il certificato incriminato è installato localmente (non concatenato a un certificato dell'archivio principale), Chrome non esegue i controlli di blocco. Questo è intenzionale. L'idea è che se sei il proprietario della macchina locale, la tua decisione dovrebbe essere definitiva e Chrome non dovrebbe cercare di aggirare le tue azioni. Penso che ci siano state alcune chiacchiere in passato sul fornire qualche indicazione visiva che il certificato è attendibile a livello locale piuttosto che a livello globale, finora non è stato implementato nulla.
Il tuo post confonde HSTS per HPKP.HSTS garantisce solo l'utilizzo di HTTPS;il blocco del certificato è compito di [HPKP] (https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning).
@user2428118 No. Il modo in cui accedi alla configurazione di hpkp (almeno quando è stato scritto) era un'opzione nella configurazione di hsts.
@tylerl: ehhh ... no?HPKP utilizza l'intestazione Public-Key-Pins, mentre HSTS utilizza l'intestazione Strict-Transport-Security.Sono totalmente estranei.
@tylerl basato su [il tuo commento] (https://security.stackexchange.com/questions/29988/what-is-certificate-pinning/84425#comment146160_29990) stai dicendo se un'app iOS implementa il pinning del certificato anche in questo caso la sua retele richieste sarebbero state rivelate a qualcosa come Charles Proxy, perché "se sei il proprietario della macchina locale, la tua decisione dovrebbe essere definitiva".In tal caso, le chiavi API non sarebbero facilmente phishing dalle chiamate di rete?
Il mio post faceva riferimento all'intestazione HSTS piuttosto che a HPKP perché al momento l'intestazione HPKP non era ancora stata definita e Chrome ha sovraccaricato l'intestazione HSTS per bloccare le chiavi.Non è quello che fanno oggi;infatti, oggi nessuno usa assolutamente il pinning dei tasti poiché la funzione è stata rimossa.
fuero
2013-01-31 06:20:53 UTC
view on stackexchange narkive permalink

È ambiguo, ma si riferisce a soluzioni per un problema nella verifica della catena di certificati SSL. In sostanza, la fiducia in SSL si riduce ai certificati di root, i certificati in cui il tuo sistema si fida per essere autentici. Questi vengono forniti con il tuo sistema operativo o con il tuo browser. Se uno di questi è compromesso, tutti i certificati firmati da questo e quelli firmati in modo transitorio devono essere considerati compromessi.

  • TACK o Pubblico Key Pinning Extension (chiamata cert pinning da chrome, apparentemente) consente all'amministratore di un server di "appuntare" la firma della chiave pubblica di un'autorità di certificazione (CA) a un certificato, che viene verificato dal client (fornito tramite estensione SSL). Se la chiave del certificato CA è diversa al momento del recupero della catena di certificati, è probabile che il certificato CA venga compromesso. Sorgente

  • Anche il blocco del certificato può fare riferimento per importare il certificato di un host nel tuo truststore, piuttosto che fidarsi dei certificati CA. Ciò riduce il rischio che un certificato CA venga compromesso ma ti obbliga ad aggiornare i certificati se scadono manualmente. Sorgente

Tom Leek
2013-01-31 20:34:18 UTC
view on stackexchange narkive permalink

I certificati server SSL provengono dal mondo X.509. Il client verifica la validità del certificato del server convalidando molte firme crittografiche dalle Autorità di certificazione . La bellezza dello schema è che è senza stato : un dato server potrebbe cambiare il suo certificato ogni cinque minuti e continuerebbe a funzionare con i client.

È stato affermato che mentre supportare certificati a rotazione rapida è fantastico ma inutile, perché in pratica un dato server cambia il suo certificato una volta anno ; infatti, un cambio anticipato del certificato è indicativo di alcune attività sospette in corso. Il blocco del certificato è un modo per un server di affermare che ciò non dovrebbe accadere in condizioni normali e che il client dovrebbe sollevare un sopracciglio metaforico in caso di cambio di certificato imprevisto. Questa è un'estensione del protocollo, suggerita ma non ancora ampiamente supportata. In realtà sembra che ci siano diverse proposte concorrenti relativamente simili.

Vedi anche Convergence, ancora un'altra estensione di protocollo che può essere considerata come "blocco del certificato da parte di terze parti fidate". La convergenza e le proposte di blocco dei certificati ruotano tutte attorno alla stessa idea di base, che è di avere uno stato nel client (o almeno da qualche parte) e attivare avvisi di sicurezza quando i certificati cambiano troppo spesso o troppo presto . Se una qualsiasi di queste proposte raggiungerà mai un'ampia accettazione (cioè sarà implementata in modo compatibile da IE, Firefox, Chrome e Safari, e saranno utilizzati dalla maggior parte degli amministratori di sistema del server SSL) è indovinato.

Direi che Convergence (o Perspectives) non sono estensioni di protocollo ma un canale laterale per verificare che l'host stia utilizzando lo stesso certificato se visualizzato da diverse località in tutto il mondo e che questa situazione è in corso da un po '. La differenza principale rispetto ad altre misure è che l'host non può influire su questa verifica, a differenza di altri metodi di blocco dei certificati.
So che questa non è la risposta selezionata, ma per me questa era la spiegazione che potevo capire.Grazie Tom.
Seconding Sizons, spiegazione espressiva e concisa di Tom.Ecco [Documenti MDN per l'implementazione del blocco che sembra essere lo standard oggi (HPKP)] (https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning).
Aniket Thakur
2015-03-23 23:02:26 UTC
view on stackexchange narkive permalink

In genere ciò che accade in una connessione HTTPS è che il client richiede il certificato SSL dal server conforme a SSL con cui sta comunicando tramite https. Il server fornirà un certificato dal suo archivio chiavi. Dopo che il client riceve questo certificato, convalida le sue credenziali a seconda che

  • hostname sia uguale a quello richiesto
  • ha una catena di fiducia verificabile per tornare a un certificato (radice) attendibile [da client trust store]

Ora se le connessioni sono proxy e puoi fare in modo che il dispositivo si fidi del tuo certificato CA radice (canaglia), puoi intercettare le connessioni sicure. Questo è essenzialmente un attacco man-in-the-middle. Ora ecco cosa succede nel pinning SSL che potenzialmente aggiunge un ulteriore livello di sicurezza dagli attacchi man-in-the-middle.

L'app raggrupperà i certificati del server noto con se stessa. Quando l'app tenta di stabilire una connessione sicura con il server, convalida il certificato ricevuto dal server con quelli con cui è stato fornito in bundle. Quindi, anche se il sistema operativo convalida la catena di certificati ricevuti rispetto a una CA radice (potenzialmente non autorizzata), l'app rifiuterà la connessione visualizzando l'errore di rete.

Nota: ho provato a rispondere a questa domanda dal punto di vista del blocco SSL nelle app Android. Il pinning SSL è facilmente possibile in tali app perché l'app conosce già il server (nome host) a cui si connetterà. Lo stesso potrebbe essere difficile da implementare nei browser. Penso che il browser Chrome lo implementa già.

Ho anche scritto un codice di esempio che mostra il blocco dei certificati in Android. Puoi trovarlo su github. Puoi anche trovare la stessa app su playstore.

Ulteriori informazioni:

FWIW c'è un problema con il pinning del certificato: 1. Rende difficile il debug.Perché non puoi collegarlo a Charles, a meno che non lo disabiliti durante il debug 2. I tuoi certificati alla fine scadranno.
Lucas
2016-09-22 01:19:49 UTC
view on stackexchange narkive permalink

Il pinning del certificato consente di aggirare le catene di autorità di certificazione standard per mitigare il rischio che un certificato valido venga rilasciato a un criminale.

Motivazione per una nuova soluzione ...

SSL / I certificati TLS sono firmati da altri certificati. I browser normalmente riconoscono un certificato come valido quando in un punto di questa catena di firme viene trovata un'entità attendibile. Le firme delle entità attendibili si trovano nell'installazione di base del sistema operativo e dei browser. È un elenco incorporato di circa 100 entità.

Se una delle autorità di certificazione attendibili è compromessa o se l'autorità di certificazione è vittima di una frode, può rilasciare un certificato valido a un criminale. Il criminale avrà un certificato SSL / TLS perfetto a tuo nome. Il criminale sarà in grado di effettuare attacchi credibili e riusciti "uomo nel mezzo". L'utente vedrà informazioni sul certificato valido sul tuo sito web.

Inoltre, non è difficile convincere l'utente a installare una nuova autorità di certificazione affidabile. Ad esempio, in Brasile, l'autorità di certificazione ufficiale non è riconosciuta dai principali browser e tutti devono installare un'autorità di certificazione aggiuntiva. I browser sono diventati molto bravi in ​​questo: fai clic su un link e rispondi sì. Per raggiungere questo livello di usabilità credo che questo sia un compito comune in tutto il mondo.

Le autorità di certificazione non possono essere completamente attendibili. Il processo per ottenere un certificato non è affatto sicuro. Ne ho già acquistato uno in un'azienda e ho pagato poco. Ovviamente è meglio di niente. Ma ha bisogno di miglioramenti.

Che cos'è il blocco?

Al primo accesso al sito Web secure.example.com, il sito Web invia un messaggio nascosto al browser client che traduce vagamente come:

"nei prossimi N giorni il sito secure.example.com utilizzerà il certificato CECECECE. In quel periodo non accettare un altro certificato, anche se l'autorità di certificazione afferma che è valido per questo sito. Se succede avvisami su http://100.200.100.200/callbacks/warn_pinning.php ".

Il blocco risolve il problema?

Non risolve la debolezza del processo di firma del certificato delle autorità di certificazione. Ma minimizza la finestra di opportunità di un criminale per cavarsela con un uomo nel mezzo dell'attacco. L'attacco funzionerà solo se l'utente ottiene il primo accesso al sito web.

È simile alla sicurezza SSH. Al primo accesso viene salvata la firma della chiave del server. Se in futuro l'accesso l'identificazione non corrisponde, il sistema genera un avviso. L'avvertimento è preso sul serio perché accade solo quando si apportano modifiche reali.

La cosa migliore per una grande azienda è ricevere una notifica tramite i reclami dei clienti che qualcuno ha rilasciato un vero certificato TLS / SSL a loro nome a un criminale. A quanto mi risulta, il meccanismo di blocco è stato proposto da Google

Blocco a livello di applicazione

Il blocco può essere effettuato anche al di fuori del browser, compilando l'impronta digitale del certificato reale in un'app.

Suppongo che nel caso di avvelenamento DNS e simili in cui l'IP per il nome di dominio viene modificato da un utente malintenzionato, anche il pinning del certificato potrebbe aiutare (supponendo che tu abbia visitato il sito in precedenza).
Buona domanda.Sulle connessioni crittografate lo farà.Ma non so se bloccare un sito impedirà il funzionamento delle connessioni non crittografate.In caso contrario, l'aggressore sarà comunque in grado di effettuare un attacco credibile utilizzando connessioni non crittografate.In caso contrario è solo questione di tempo.Non ha alcun senso consentire connessioni non crittografate per un sito bloccato.
Joseph
2013-04-28 16:56:37 UTC
view on stackexchange narkive permalink

Penso che sia solo un'implementazione HSTS per conservare i certificati SSL dei client browser quando viene effettuato un attacco sslstrip MITM contro l'utente web

Il blocco del certificato è diverso. Al momento HSTS non fornisce alcun modo per bloccare un singolo certificato; invece, HSTS è un valore booleano che consente a un sito di dire "SSL only please" (ma non consente al sito di limitarsi a un singolo certificato). Il blocco del certificato è un'estensione / meccanismo diverso.


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...