Domanda:
Cosa rende Let's Encrypt sicuro?
user253751
2015-05-04 12:49:51 UTC
view on stackexchange narkive permalink

Let's Encrypt è un'iniziativa della Electronic Frontier Foundation (EFF), Mozilla, Cisco, Akamai, IdenTrust e dei ricercatori dell'Università del Michigan che mira a fornire automaticamente a ogni proprietario di dominio un certificato che può essere utilizzato per TLS.

Per dimostrare che possiedi un dominio, devi installare un file con contenuti particolari (generati casualmente) in un URL particolare (generato casualmente) su quel dominio. Il server Let's Encrypt lo verificherà accedendo all'URL, prima di firmare il certificato.

Ora, supponiamo di avere qualche attacco che farà risolvere il dominio awesomebank.example al mio server . Supponiamo che io possa anche MITM le connessioni di alcune persone a https: //awesomebank.example/ . TLS ha lo scopo di impedirmi di vedere o alterare le loro comunicazioni al server senza essere rilevato.

Cosa mi impedisce di utilizzare questo attacco al server Let's Encrypt e di ottenere un certificato per awesomebank.example e quindi utilizzarlo per i clienti MITM di AwesomeBank senza essere rilevato (perché ho un certificato valido)? L'esistenza di una CA completamente automatizzata non rende Internet meno sicuro?

"... qualche attacco che farà risolvere il dominio awesomebank.example al mio server". Questo si chiama avvelenamento da DNS. Una volta ottenuto ciò, perché dovresti eseguire MITM. Tutti i dati del cliente stanno arrivando al tuo server. Allora il gioco è finito. Ma non puoi farlo facilmente a meno che tu non convinca il registrar DNS di awesomebank.example a risolverlo sul tuo IP o non sfrutti una vulnerabilità nella loro infrastruttura DNS. Anche questo può essere mitigato tramite il blocco delle modifiche DNS.
Molte CA esistenti sono già automatizzate. Controllano solo se puoi ricevere e-mail ad admin@example.com.
Anche l'avvelenamento DNS (cache) funziona solo se viene utilizzata la cache. Se il resolver è progettato per seguire in modo specifico la catena di delega su ogni ricerca, e forse lo fa anche per tutte le alternative e si assicura che le risposte corrispondano, questo attacco può essere mitigato facilmente con un alto grado di sicurezza. Poiché la firma del certificato è un'operazione a frequenza relativamente bassa, qualcosa del genere non influirebbe in modo significativo su altri sistemi né aumenterebbe in modo significativo il tempo necessario per ottenere un certificato.
Questo è un difetto con l'intera PKI basata su CA. Soluzioni alternative come l'utilizzo di una rete di fiducia invece (come PGP) sarebbero più resistenti a questo tipo di attacco, perché dovresti ingannare più persone facendole fidare della tua identità MITM, invece di una singola CA.
@void_in "Tutti i dati del cliente stanno arrivando al tuo server" sarebbe il caso solo se i client stabilissero effettivamente la connessione TLS al tuo server. Affinché funzioni, è necessario (normalmente) disporre di un certificato valido (firmato da una CA attendibile) per il nome di dominio. E per ottenerlo è necessario ingannare la CA durante il processo di verifica.
L'immagine di Let's Encrypt è presumibilmente buona.Altrimenti questa domanda sarebbe "Is Let's Encrypt affidabile?"o [simile] (https://security.stackexchange.com/questions/127575/is-startssl-com-a-trustworthy-site/127630) ...
[Non più teorico] (https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation)
Subito dopo aver letto l'articolo su Wired https://goo.gl/zAqLKJ, sono atterrato qui @JimmyJames - Che coincidenza, stavo per pubblicare lo stesso commento.
Sei risposte:
StackzOfZtuff
2015-05-04 14:41:51 UTC
view on stackexchange narkive permalink

Stessa sicurezza degli altri certificati DV

Cosa mi impedisce di utilizzare questo attacco al server Let's Encrypt, ottenere un certificato per awesomebank.example e quindi utilizzarlo per i clienti MITM di AwesomeBank senza essere rilevato (perché ho un certificato valido)?

Niente. Se possiedi la rete, allora sei il proprietario della rete. E i certificati di tipo DV (vedi sotto) si basano sulla rete per la prova della proprietà del dominio. Di solito non ci sono controlli fuori banda. (Nessuno chiamerà il tuo telefono, nessuno controllerà il tuo documento d'identità con foto, nessuno ti visiterà nel luogo in cui è registrata l'azienda, ecc.)

Esiste una CA completamente automatizzata rendere Internet meno sicuro?

No. Stesso livello di sicurezza dei certificati di tipo DV.

Esistono (attualmente) tre livelli di garanzia per i certificati x509:

  • DV, convalida del dominio
  • OV , Organization Validation
  • EV, Extended Validation

DV è il più economico. Fondamentalmente significa "Se qualcuno può rispondere a un'e-mail a admin@example.com, quella persona ottiene un certificato per example.com" .

Ci sono controlli aggiuntivi per OV, EV.

Ulteriori informazioni sui tipi di certificati: GlobalSign.com: Quali sono i diversi tipi di certificati SSL? (archiviati qui.) Wikipedia: https://en.wikipedia.org/wiki/Public_key_certificate#Validation_levels E molte altre informazioni di base in queste diapositive qui: RSAConference2017, Session ID: PDAC-W10, Kirk Hall, 100% Encrypted Web - Nuove sfide per TLS

Ulteriori letture

Si noti che il controllo della posta elettronica, sebbene comune, non è l'unico controllo automatico in uso. In particolare, molte CA esistenti danno la possibilità di scegliere esattamente la stessa prova basata sul Web che Lets Encrypt descrive nei loro documenti.
Sì. Non ho mai trovato nient'altro che la versione e-mail in natura.
Lavorando in un'agenzia di sviluppo web, sono stato molto sollevato quando Comodo ha iniziato a offrire la verifica DNS e HTTP, perché significa che non dobbiamo più spiegare il processo al personale non tecnico che ha accesso all'account admin @ e-mail. O, peggio, al personale IT che ha bisogno di creare una simile casella di posta appositamente per lo scopo.
Sebbene DV ed EV siano standard del settore (standardizzati dal CA / Browser Forum), per quanto ne so OV è solo GlobalSign. Ad esempio, sia DigiCert https://www.digicert.com/ssl-certificate.htm che Entrust http://www.entrust.net/ssl-certificates.htm offrono EV e un gruppo delle proprie varianti (ma non OV ).
@MikeOunsworth Sebbene non standardizzato, penso che il concetto ampio di OV come passaggio tra DV ed EV sia abbastanza comune; vedi ad es. [Knowledgebase di Comodo] (https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/312/16/what-is-an-organizationally-validated-certificate).
"* L'esistenza di una CA completamente automatizzata non rende Internet meno sicuro? * No. Stesso livello di sicurezza dei certificati di tipo DV." Sembra che Let's Encrypt sia * più * sicuro dal momento che un attacco MitM non sarebbe facile come con una CA centralizzata?
Steve Jessop
2015-05-04 22:40:51 UTC
view on stackexchange narkive permalink

Sì, il protocollo che descrivi si limita a garantire che "la persona che prende il telefono in awesome bank" quando la chiami, è la stessa persona che ha risposto al telefono in awesome bank quando il server Let's Encrypt l'ha chiamata. Se ho la capacità di intercettare le chiamate alla fantastica banca sia da Let's Encrypt che da te, allora posso ingannarti.

Idealmente ciò che vorresti che TLS ti dicesse è che "la persona che sceglie alza il telefono a awesome bank "quando li chiami è in realtà un dipendente di awesome bank . Ma questo è difficile da automatizzare, poiché i computer non possono semplicemente capire per chi lavora qualcuno, quindi i certificati meglio convalidati costano di più. Let's Encrypt non sta facendo nulla di meno sicuro di quanto fanno già altre CA.

Si spera che Let's Encrypt cercherà di rendere più difficile intercettare le loro chiamate a una banca fantastica, piuttosto che intercettare le tue. Alcuni punti di accesso a Internet sono più facili da usare rispetto ad altri (il wireless non sicuro ha un punteggio basso) e scherzare con più punti di accesso contemporaneamente è più difficile di uno solo (quindi forse Let's Encrypt confermerà che riceve lo stesso file quando lo scarica da molti diversi luoghi del mondo, anche se non ho verificato se lo ritengano necessario). Ad eccezione di organizzazioni come la NSA, gli attacchi MITM in pratica tendono a essere localizzati e temporanei.

Quindi, fornirà una certa misura di sicurezza solo nella misura in cui è più difficile a MITM Let's Encrypt che a MITM te. Supponiamo che sia più facile controllare il tuo accesso a Internet che controllare quello di Let's Encrypt o quello di una fantastica banca, ed è per questo che ti "fidi" di Let's Encrypt come CA.

Naturalmente nessuno di queste sono davvero telefonate, sono connessioni socket in entrata.

Puoi assicurarti che "la persona che risponde al telefono su AwesomeBank" stia effettivamente utilizzando il telefono di AwesomeBank, se DNSSEC è stato utilizzato.
@immibis: bene, puoi essere "sicuro" di avere l'indirizzo IP corretto utilizzando DNSSEC. Il tuo percorso potrebbe ancora essere dirottato. DNNSEC consente anche record CERT affidabili, ma non sono aggiornato su cosa ti vince.
WhiteWinterWolf
2015-05-04 14:02:34 UTC
view on stackexchange narkive permalink

Let's Encrypt è progettato per aiutare contro una serie di attacchi e per spingere la generalizzazione dell'utilizzo di TLS per avere una Internet più sicura e privata a livello globale. Ha lo scopo più precisamente di rimuovere i vincoli tecnici e finanziari che potrebbero impedire ad alcuni webmaster di utilizzare i certificati TLS in modo più ampio.

Tuttavia, come qualsiasi misura di sicurezza, questo non sarà un prodotto miracoloso che risolverà tutti i possibili problemi di titoli e permettendoti di contrassegnare il tuo sito web come "sito web sicuro al 100%!" (anche se alcuni siti web non esitano a utilizzare tali timbri ...). La sicurezza implica la combinazione di diversi livelli, ciascuno progettato per affrontare la propria classe di minacce.

Se si riesce davvero ad assumere la proprietà del nome di dominio, è molto probabile che il fatto che Let'sEncrypt la consegna del certificato automatizzata non avrà un impatto maggiore in questo caso che in un'altra situazione.

Come promemoria, tutto ciò che serve per ottenere un certificato dalla CA classica è possedere un indirizzo amministrativo come "admin @ example. com "e paga dei soldi. Se riesci a ottenere la proprietà del dominio, sei libero di reindirizzare l'email a un tuo server di posta, possedendo così anche l'indirizzo email di tua scelta.

Questa non è una minaccia teorica. Troverai qui un articolo scritto da qualcuno il cui dominio è stato rubato per assumere la proprietà della sua email. In questo preciso caso si trattava di accedere alle email di reimpostazione della password inviate da società terze, tuttavia nella sua posizione l'aggressore avrebbe anche potuto generare nuovi certificati per questo dominio e costruire un sito di phishing che sarà considerato protetto da i browser.

Non "assumere la proprietà del dominio", ma se posso indurre un risolutore DNS a risolvere * temporaneamente * il mio indirizzo (ad esempio con avvelenamento della cache), questo mi dà la capacità non temporanea di impersonare quel dominio.
Non è necessario solo avvelenare la cache del resolver DNS della CA (non importa se Let'sEncrypt risolve l'indirizzo del tuo sito Web o un'altra CA che risolve l'indirizzo del tuo server di posta), ma dovresti anche avvelenare la cache di ciascuno e tutti i visitatori che desideri reindirizzare al tuo sito di phishing quando vanno all'URL `https: // awesomebank.example` (altrimenti avere il certificato sarà inutile se non puoi impersonare il sito web). Potrebbe essere fattibile in una certa misura come parte di un attacco molto mirato, ma rimane chiaramente limitato e non fattibile su larga scala.
Se MITMing un sito web fosse così difficile, allora sicuramente non avremmo bisogno di TLS per impedirlo?
MITM non è l'unica minaccia, esiste anche l'intercettazione e la complessità di tutte dipende direttamente dalla posizione della rete rispetto all'obiettivo. Come suggerisce il nome, devi essere in grado di metterti da qualche parte "nel mezzo" delle comunicazioni tra i tuoi obiettivi. Un utente finale estraneo (al contrario di ISP, agenzie governative, ecc.) Non sarà in una buona posizione per fare un MITM massiccio, quindi dovrà o spostare artificialmente la sua posizione ottenendo l'accesso ad alcune macchine che offrono migliori possibilità MITM, o utilizzare un altro mezzo a seconda di quale è il più redditizio.
Se fossimo preoccupati solo per le intercettazioni, i browser accetterebbero i certificati autofirmati.
I certificati autofirmati @immibis: proteggono solo dagli attacchi MITM passivi. Un utente malintenzionato MITM attivo può creare un certificato autofirmato.
@Brian Anche un utente malintenzionato MiTM attivo interromperà Let's Encrypt.
@Brian Hai detto "MITM non è l'unica minaccia, ci sono anche intercettazioni". Ma se l'intercettazione fosse la minaccia principale, i browser accetterebbero certificati autofirmati, perché l'intercettazione senza MITM è quindi impossibile.
@user54609: Un utente malintenzionato MiTM attivo ha solo una possibilità (per certificato) di compromettere Let's Encrypt e deve farlo compromettendo la connessione a Let's Encrypt (che è firmata da una CA attendibile). Con un certificato autofirmato, * ogni * connessione è vulnerabile agli attacchi MITM attivi.
@immibis: Non è Brian a dirlo, e non ho mai detto che la minaccia principale fosse l'intercettazione. Ho appena detto che il MITM non è l'unico, anche le intercettazioni sono una minaccia. Ecco perché TLS non si limita a garantire l'autenticazione e l'integrità, ma anche la riservatezza. Vai su un wifi pubblico o condiviso, avvia Wireshark e monitora l'attività che coinvolge la porta 80, quindi vedrai rapidamente perché l'intercettazione è un problema e come TLS lo previene efficacemente. Altrimenti potresti voler aprire una nuova domanda poiché discutere i vantaggi di sicurezza e le limitazioni di TLS sembra un po 'fuori portata qui.
IMSoP
2015-05-04 18:48:29 UTC
view on stackexchange narkive permalink

L'utilizzo di un controllo automatico non è esclusivo di questa CA, ma è comune per i certificati entry-level. Come affermato in altre risposte, ci sono 3 livelli di certificato in uso:

  • Doman Validation dimostra solo che avevi il controllo del dominio al momento in cui il certificato è stato emesso. (E da allora il certificato non è stato revocato esplicitamente.)
  • La convalida dell'organizzazione implica un ulteriore controllo della validità del nome dell'azienda elencato nel certificato.
  • La convalida estesa include un audit molto più rigoroso dell'azienda che richiede il certificato.

Per un certificato DV di base (e come primo passo nelle applicazioni OV ed EV), la maggior parte delle CA utilizzerà una qualche forma di dominio "automatizzato Validazione del controllo ". Ad esempio, Comodo offre 3 opzioni:

  1. Un'e-mail deve essere ricevuta da uno di un breve elenco di indirizzi generici nel dominio, come "admin @ ", supponendo che solo il personale autorizzato abbia accesso a queste caselle di posta.
  2. È necessario aggiungere un record CNAME specifico nella zona DNS per il dominio, a dimostrazione che il richiedente ha il controllo DNS.
  3. È necessario aggiungere un URL con contenuto specifico nella radice dell'HTTP del dominio, a dimostrare che il richiedente ha il controllo del server web puntato dal dominio.

Il Il protocollo ACME in fase di sviluppo come parte dello sforzo di Lets Encrypt consiste nell'automatizzare il lato client di questo controllo. La loro Panoramica della tecnologia menziona in realtà sia i controlli basati su DNS che quelli basati su HTTP come esempi che potrebbero essere automatizzati in questo modo.

L'idea è che il software che installi possa determinare automaticamente come affrontare queste sfide in base alla configurazione a cui ha accesso. Se riesce a trovare e scrivere nella radice del documento del dominio da convalidare, la sfida basata su HTTP è molto facile da automatizzare. Il metodo di convalida più tradizionale basato sulla posta elettronica sarebbe più complicato da automatizzare, a causa della complessità della consegna della posta, ma in realtà non differisce per la quantità di prove che fornisce.

J.C.
2015-05-05 11:05:55 UTC
view on stackexchange narkive permalink

La difesa principale contro gli attacchi MITM durante l'emissione è eseguire il controllo di convalida - osservando il server o il suo DNS - da molte posizioni geograficamente disperse. Questo è il numero di CA oggi gestite per i controlli web automatizzati per rilevare falsificazioni e frodi.

Da quello che ho sentito nella stanza IRC, Let's Encrypt farà lo stesso per tutti i controlli di convalida.

Non aiuta se MITM è vicino al tuo server (se è disponibile solo un percorso singolo).
mcfedr
2020-09-03 15:38:01 UTC
view on stackexchange narkive permalink

Ricorda che devi MITM non gli utenti del sito, ma Let Encrypts validation servers per essere in grado di ottenere quel certificato, sarà molto più difficile.

Lets Encrypt ha recentemente parlato di come utilizzare la convalida multi-prospettiva per proteggersi da un attacco di questo tipo: l'idea è che convalideranno la tua proprietà del dominio da diversi punti di Internet, in modo tale da dover MITM più data center in tutto il mondo.

In questo caso, penso che Lets Encrypt sia più sicuro di altri fornitori di certificati che non fanno di tutto per proteggersi. Questo non è niente di unico per Lets Encrypt: se puoi MITM il provider di certificati, puoi usarne uno qualsiasi, potrebbe essere più costoso per te.

Ebbene, alcuni fornitori di certificati tentano di verificare la tua identità nel mondo reale.Non tanto da quando LE ha iniziato a esistere.
Per i certificati EV dovrebbero farlo, ma per i DV che Lets Encrypt ti fornisce, altri fornitori sono simili e tendono anche ad essere automatici, ma in un modo meno strutturato rispetto al protocollo ACME.


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...