"Web of trust" per i certificati SSL autofirmati?

6

I certificati SSL, in generale, utilizzano un modello di "catena di fiducia": un'autorità di certificazione attendibile (CA) ottiene la prova che un'azienda come Amazon possiede amazon.com e rilascia un certificato SSL.

Tuttavia, i certificati possono essere costosi - e non ha senso spendere quel tipo di denaro, ad esempio, su un sito web personale. Ma sempre più persone sostengono che il traffico web dovrebbe sempre essere criptato perché i computer sono in grado di gestirli e ti protegge su reti pubbliche wifi es starbucks. Quindi puoi usare SSL con un certificato "autofirmato" ma gli utenti riceveranno un messaggio sgradevole dicendo che il certificato non è affidabile poiché è "autofirmato" e non da un'autorità "fidata". Il problema è che ci sono stati numerosi casi in cui le autorità "fidate" hanno commesso errori e consegnato certificati SSL ai "cattivi" per così dire. Ma in realtà, un certificato autofirmato non è significativamente meno sicuro di un certificato firmato da una CA - nel senso che il tuo traffico è crittografato e inviato al server web e decifrato lì. Significa semplicemente che nessuno "fidato" controllato l'identità del server web in questione.

C'è un modo per fare un modello di "web of trust" con certificati SSL simili alle chiavi PGP? Cioè se conosco qualcuno personalmente e so che sono l'amministratore del sito www.example.com e hanno un certificato autofirmato, posso "firmare" il certificato per dire che mi fido di loro. Quindi, quando gli utenti visitano un sito Web autofirmato, diranno che la persona può essere considerata attendibile in base alla loro posizione nella "rete di fiducia".

    
posta Jason 24.07.2014 - 03:11
fonte

3 risposte

8

... But in reality, a self-signed cert is not significantly less secure than a cert signed by a CA - in the sense that your traffic is encrypted and sent to the web server and decrypted there. It just means that no one "trusted" checked the identity of the webserver in question.

Questo solo è una parte molto importante. Se non si verifica, il peer con cui si parla è il peer atteso, piuttosto che potrebbe essere qualcun altro. Per esempio. se Alice vuole parlare con Bob e non controlla, che in realtà sta parlando con Bob, che potrebbe parlare con Mallory sostenendo di essere Bob. Mallory potrebbe quindi trasmettere i messaggi a Bob e la connessione sembrerebbe ancora crittografata, ma sarebbe crittografata da Alice a Mallory e ancora da Mallory a Bob. Mallory avrebbe avuto accesso al testo semplice del messaggio e potrebbe anche modificarlo.

In teoria potresti creare la tua rete di fiducia con certificati autofirmati. Ma, non penso che molti degli attuali utenti di HTTPS capiranno il concetto e le sue implicazioni, ad es. come applicare la fiducia a un'altra parte, come non fidarsi solo di un estraneo, come la fiducia indebolisce più lunga è la catena di fiducia e quanta fiducia hanno bisogno quando si accede a un sito (che potrebbe essere diverso da un sito all'altro).

Il che significa che alla fine si potrebbe ottenere una rete di fiducia che è troppo complessa per la maggior parte delle persone per capire e quindi non si fidano di esso. Oppure potresti ottenere una rete fiduciaria con alcuni giocatori conosciuti e quindi fidati che offrono la possibilità di verificare te e quindi aggiungerti alla rete per un po 'di soldi - che è più o meno quello che hai oggi.

Sebbene a nessuno piaccia davvero un'autorità centrale, avere una cosa del genere semplifica enormemente l'applicazione della fiducia nella vita reale. Cioè la maggior parte delle persone non li mette in una piccola banca a meno che non siano noti per essere sostenuti da una banca più grande o da un'assicurazione ecc.

DANE potrebbe essere un modo migliore per andare. Richiede ancora una rete di fiducia centrale, ma non ne crea una nuova solo per SSL, ma riutilizza quella esistente creata per DNSSec. Questo potrebbe essere più economico e facile da capire - e quindi più affidabile.

    
risposta data 24.07.2014 - 09:35
fonte
3

"Web of Trust" nei formati X.509 sono stati occasionalmente provati. Ad esempio, Thawte l'ha provato ma ha rinunciato.

Per un Web of Trust per "lavorare", hai bisogno di due cose:

  • "Affidare le parti" (nel caso HTTPS, questo significa che i browser Web) devono implementare il protocollo di verifica che controlla le relazioni di WoT.
  • Sufficientemente molti partecipanti devono aderire al sistema. Un WoT fornisce verifiche che valgono quel nome solo attraverso l'accumulo di percorsi. Non è sufficiente che il grafo di WoT sia semplicemente connesso; la forza del WoT si basa sulla capacità di ogni verificatore di trovare molti percorsi tra sé e il certificato che deve essere verificato.

Thawte ha risolto il primo punto ponendosi come intermediario (quindi, dal punto di vista dei browser, era solo una semplice catena di certificati), ma non è riuscito a superare il secondo punto.

Questo è un problema critico e si applica anche a PGP: il sistema è molto difficile da riavviare. Durante la fase di spiegamento, il WoT non fornisce alcun tipo di garanzia decente, quindi c'è poco incentivo per le persone a farne parte. Entrambi i client sono configurati su un'impostazione "trust per impostazione predefinita" in cui si fida di un certificato basato su un singolo percorso; nel qual caso si possono prevedere alcuni attacchi di successo che danneggeranno gravemente la reputazione del sistema, scoraggiando le persone dall'utilizzarlo. Oppure i client hanno una configurazione più rigida e il WoT non sarà utilizzabile fino a quando non vi parteciperà un vasto gruppo di proprietari di server; e non hanno motivo di farlo, soprattutto se ciò significa che i loro certificati autofirmati, nel frattempo, attivano avvertimenti spaventosi.

Si noti che mentre il certificato HTTPS-with-a-self-signed fornisce una protezione efficace contro gli aggressori passivi (i dati vengono effettivamente crittografati), è debole contro attivo aggressori (che tentano di eseguire server falsi, ad esempio per un attacco Man-in-the-Middle ). Succede anche che la maggior parte degli attaccanti che possono diventare passivi può anche attivarsi: per un attaccante economico e solitario, gli scenari di attacco realistici per intercettazioni implicano l'impostazione di un punto di accesso WiFi aperto (ad es. In un ristorante) o qualche Avvelenamento DNS . Entrambi i contesti consentono intrinsecamente anche attacchi attivi, senza lavoro aggiuntivo per l'aggressore.

Pertanto, HTTPS con certificati autofirmati non è, in effetti, molto meglio di un semplice HTTP. È usato molto meglio, nei tempi più antichi, quando il contesto di un attaccante / bersaglio era quello di una postazione di lavoro in qualche università, con gli studenti che cercavano di spiare l'un l'altro: in questi momenti (negli anni '90 gli "attaccanti" erano per lo più passivi e la crittografia li ha sconfitti (quel contesto spiega protocolli di autenticazione come "digest HTTP", che hanno senso, dal punto di vista della sicurezza, solo contro gli attaccanti passivi).

    
risposta data 24.07.2014 - 15:03
fonte
0

Questo mi ricorda gli anelli del web che erano popolari. Se è possibile creare un sistema basato sulla reputazione, è possibile avviare la propria CA.

Il fatto è che anche gli AC oggi non controllano molto. È possibile avere un sito Web dannoso con un certificato firmato da una CA. Quindi, non sembra non plausibile. È possibile creare un sistema CA in base alla reputazione del sito Web. Ad esempio, disporre di un sistema di autorizzazione del certificato a due livelli basato sulla fiducia / reputazione del sito web sarebbe un buon modo. È possibile richiedere un prompt o un'opzione per segnalare il sito durante la fase 1, che sarebbe un periodo di iniziazione. Dopo che il sito Web ha acquisito una reputazione sufficientemente elevata e si è verificato in base a una maggioranza fidata di autorevoli organizzazioni / persone, è possibile firmare il proprio certificato con il secondo livello, indicando che il sito Web ha dimostrato di essere affidabile. Se si richiede ancora l'icona / la finestra del report sulla pagina, in modo visibile, è possibile creare una CA più sicura, decentralizzata, basata sulla reputazione e basata sulla fiducia. È una buona idea. Parteciperei

    
risposta data 24.07.2014 - 09:57
fonte

Leggi altre domande sui tag