Possiamo avere https senza certificati?

5

Mi scuso in anticipo se sono fondamentalmente incompreso qualcosa, ma è possibile avere protocolli di comunicazione crittografati (https, suppongo) senza ricorrere a un sistema di certificazione?

Queste domande riguardano l'iniziativa EFF / Mozilla per "cifrare ovunque!" Comprendo che i certificati verificano / identità / ma è possibile e / o ragionevole costruire un https protocal witbout usando identità verificate? L'esempio più ovvio è comunicare con siti certificati autofirmati, ma ci sono altre situazioni in cui potresti valutare la crittografia della comunicazione più che l'identità di chi stai comunicando?

    
posta sharedphysics 20.11.2014 - 06:01
fonte

5 risposte

6

puoi avere SSL / TLS senza certificati. Questo è supportato nello standard TLS : le suite di crittografia "DH_anon" non implicano alcun certificato di sorta. Ma bisogna ricordare che tale TLS non autenticato è intrinsecamente debole contro gli aggressori attivi, dal momento che non possono impedire la rappresentazione del client o del server (o entrambi allo stesso tempo, che è chiamato a Attacco man-in-the-middle ).

La maggior parte dei browser Web disattiva le suite di crittografia DH_anon a causa della vulnerabilità intrinseca a MitM. Puoi avere lo stesso effetto concettuale con un certificato SSL autofirmato, che puoi produrre da solo senza parlare con nessuna CA. Naturalmente, gli stessi browser Web mostreranno gli "avvisi spaventosi", praticamente per lo stesso motivo.

Dal punto di vista del FEP, il cui nemico è l'NSA, le suite di crittografia DH_anon generalizzate avrebbero senso, dal momento che le Evil Spy Agencies ™ preferiscono l'intercettazione passiva (poiché non lascia tracce incriminanti). L'intercettazione passiva è sconfitta da DH_anon. Tuttavia, per la maggior parte delle altre persone, la più grande minaccia non è l'intrusività governativa, ma i banali truffatori che cercano di separarti dai tuoi soldi, e questi non esitano a eseguire attacchi MitM completi, ad es. con falsi punti di accesso WiFi.

L'iniziativa Let's Encrypt mira a rendere l'emissione di certificati gratuita (come in "senza soldi") e automatizzata, pur mantenendo un po 'di impegno a "verificare" che chiunque ottiene il certificato abbia un certo grado di controllo sul dominio designato. Dal suo aspetto (merita un'ispezione più ravvicinata), questo sistema si basa sul DNS e implica che qualsiasi attacco DNS (ad esempio DNS spoofing ) potrebbe essere sfruttato per emettere certificati canaglia, in modo completamente automatico, quindi questa iniziativa sarebbe un indebolimento dell'attuale modello di certificato. D'altra parte, se convince più persone a usare SSL, contribuisce a un "mondo più sicuro", almeno dal punto di vista NSA-is-the-Devil, dove ciò che conta è sconfiggere gli intercettatori passivi.

In ogni caso, senza il supporto di Microsoft e Google (ad esempio l'inclusione della CA di Let's Encrypt in IE e Chrome), non c'è modo che l'iniziativa si trasformi davvero in HTTPS generalizzato. Non molte persone attiverebbero SSL sul loro sito Web se ciò significa che il 70% degli utenti verrà insultato e spaventato dai loro browser. Se Microsoft e Google non salgono sul carro (e non credo che lo faranno), allora il sistema Let's Encrypt rimarrà un gesto politico, ma non sarà diffuso (e alla fine Mozilla lo abbandonerà se qualcuno si disturba montare un attacco automatico basato sul DNS).

C'è un'altra modalità senza certificato completamente diversa per SSL; si chiama SRP . Quello è sicuro, ma diverso dalla normale navigazione Web. SRP garantisce l'autenticazione reciproca client / server per quanto riguarda un segreto condiviso, e lo fa in un modo che protegge il segreto condiviso contro la forza bruta offline - in modo che possa tollerare l'uso di un segreto condiviso a bassa entropia, cioè un la password . TLS-SRP ha molto senso per l'accesso a risorse di rete protette da password e non comporta alcun certificato; eppure, è sicuro contro MitM e l'intercettazione.

Sfortunatamente, i browser Web attualmente non supportano SRP.

    
risposta data 20.11.2014 - 14:40
fonte
4

SSL / TLS (il protocollo sottostante per HTTPS) offre due funzionalità:

  • Crittografia, in modo che nessuno possa ascoltare passivamente i dati. La crittografia viene eseguita utilizzando una chiave che è in qualche modo condivisa tra i peer.
  • Identificazione, così puoi essere sicuro con chi stai parlando. Questo di solito è fatto con i certificati.

Anche se potresti avere la crittografia senza identificazione, la tua connessione sarebbe aperta agli attacchi attivi, dove invece del peer atteso parli con un'altra parte, come un uomo nel mezzo che poi può decodificare e manipolare i dati e inoltrare i dati a il peer originale dopo la nuova crittografia.

Senza identificazione non significa solo senza certificati ma anche quando ci si fida di qualsiasi certificato che si ottiene, in genere certificati autofirmati.

Pertanto, mentre TLS stesso può eseguire la crittografia senza certificati, HTTPS richiede certificati poiché questo è l'unico modo per un'identificazione corretta in questo caso d'uso.

    
risposta data 20.11.2014 - 06:50
fonte
0

No, non puoi avere HTTPS senza utilizzare il certificato SSL / la chiave pubblica.

Con il certificato SSL il server si identifica con il client.

Se possiedi un certificato autofirmato, avrai HTTPS, ma il certificato autofirmato non è considerato affidabile dai browser moderni.

    
risposta data 20.11.2014 - 06:18
fonte
0

I dati sulla connessione https sono crittografati usando una chiave privata, che è nota sia al mittente che al ricevente. Il mittente crittografa i dati utilizzando la chiave privata e il destinatario utilizza la stessa chiave per decrittografare i dati.

La stessa chiave non viene riutilizzata per impedire gli attacchi di replay. Pertanto, una chiave univoca deve essere utilizzata in ogni sessione.

Ora, la domanda è chi genera la chiave univoca e come condividiamo questa chiave univoca in ogni sessione. Questo è un problema, giusto? Questa chiave privata univoca è condivisa utilizzando un'infrastruttura a chiave pubblica e il certificato è parte integrante di esso. Generalmente, la richiesta viene avviata dal client (in questo caso il browser). Il certificato include le informazioni sulla chiave pubblica del server che viene utilizzata per crittografare una chiave privata casuale generata dal client. Questi dati possono essere decifrati solo dalla chiave privata del server, che è nota solo al server. Una volta stabilita la chiave privata tra il client e il server, possono iniziare a comunicare in modo sicuro, che è essenzialmente l'https.

    
risposta data 20.11.2014 - 06:23
fonte
0

Per quanto riguarda le alternative alla crittografia basata su certificato (asimmetrico) per i protocolli di comunicazione, la crittografia simmetrica è una possibilità come una chiave condivisa conosciuta da entrambe le parti.

Considerando le alternative a SSL e in particolare ai certificati, prendi in considerazione la possibilità di crittografare i dati prima che siano posizionati sul filo. Ciò consentirebbe di utilizzare un numero qualsiasi di protocolli come trasporto, assicurando che i dati non possano essere visualizzati. Una decrittazione corretta significherebbe quindi che i dati sono arrivati con successo a destinazione e non sono stati manomessi.

Tecnicamente non puoi avere https senza SSL a causa dello schema URI. Questo articolo di wikipedia fa un ottimo lavoro spiegando questo e include collegamenti agli articoli RFC se stai cercando qualcosa di più tecnico. In breve, la specifica afferma che lo schema https corrisponde a SSL / TLS. Tieni presente che questo esclude scenari in cui uno rinuncia alle specifiche RFC a favore della propria soluzione (esempio: lancia il tuo propria crittografia ) in cui crei le tue specifiche per https. Chiunque consumi quel servizio dovrebbe quindi comprendere le specifiche personalizzate.

    
risposta data 20.11.2014 - 07:00
fonte

Leggi altre domande sui tag