it-swarm.dev

Il server HTTPS può essere configurato senza un certificato server?

Ho notato che, è possibile impostare una connessione HTTPS con il server configurato per utilizzare un certificato e, quando è richiesta ulteriore sicurezza, il server può chiedere al client di fornire un certificato client, convalidarlo e impostare una connessione.

Sembra che, se chiediamo a tutti i clienti di fornire i loro certificati, che contengono chiavi pubbliche e firme corrispondenti, dovrebbe essere possibile stabilire anche la connessione sicura. Il server convalida semplicemente le firme, quindi crittografa i dati inviati mediante la chiave pubblica del client. Se la conoscenza dell'identità dei client è più importante di quella del server, qui il certificato del server non è di alcuna utilità.

Quindi è supportato nel protocollo HTTPS, che il server non fornisce certificati ma richiede certificati client e quindi stabilisce una connessione HTTPS?

34

HTTPS è HTTP-entro-SSL. [~ # ~] ssl [~ # ~] è un protocollo tunnel: funziona su un flusso bidirezionale esistente per i dati e fornisce un flusso bidirezionale per i dati. Le due parti coinvolte in SSL sono il client e il server , che sono due ruoli all'interno del protocollo SSL; non è necessario che questi ruoli si associno alle nozioni di "client" e "server" del protocollo di trasporto sottostante.

Ad esempio, è possibile immaginare una configurazione in cui il sistema client (C) avvia una TCP connessione al server (S), quindi il server avvia una stretta di mano SSL, fungendo da Client SSL (ovvero invio del messaggio ClientHello, invece di attendere un ClientHello in entrata). Questo inverte i ruoli di entrambe le macchine e anche le garanzie di sicurezza: la macchina S avrà una buona idea dell'identità del client C collegato, ma il client C non sarà sicuro di quale server S sta parlando (un utente malintenzionato potrebbe aver intercettato e reindirizzato la comunicazione) A seconda del contesto, ciò può essere o non essere appropriato.

Tuttavia, questo parte da [~ # ~] https [~ # ~] , in cui il client TCP è anche il client SSL, e quel client si aspetta che il server mostri un certificato, che il client convaliderà rispetto alla sua CA nota e attendibile e che contiene il nome del server previsto (come estratto dall'URL, vedere sezione 3.1 ). Di conseguenza, i client esistenti (browser Web) non supportano l'inversione dei ruoli SSL. Se la situazione richiede l'utilizzo dei browser, è necessario, di ovviamente, usa solo le funzionalità disponibili nei browser.


SSL supporta alcune suite di crittografia senza certificato. Le suite di cifratura "DH_anon" sono considerate deboli, perché non implicano alcuna autenticazione (quindi, sono possibili attacchi Man-in-the-Middle ). Le suite di cifratura [~ # ~] psk [~ # ~] implicano l'autenticazione reciproca di client e server per quanto riguarda un segreto condiviso. Quando il segreto condiviso è di bassa entropia (diciamo, è una password ), [~ # ~] srp [~ # ~] suite di crittografia sono migliori.

Anche in questo caso, queste suite di crittografia non sono (ancora) disponibili nei browser tradizionali (anche se alcune persone ci stanno lavorando ). Richiedono un segreto condiviso (chiave o password), una condizione che può essere o meno facile da raggiungere nel proprio contesto specifico.


Se la conoscenza dell'identità del server non è importante, è possibile assegnare al server un certificato autofirmato, insieme alle istruzioni per i clienti su come fare in modo che il proprio browser accetti il ​​certificato del server senza rilasciare troppo forte (vedere questo domanda come punto di partenza). Questo verrà mappato su "normale SSL", che presenta due vantaggi:

  • I browser esistenti lo supportano.
  • Quando il server presenta un certificato, per quanto fasullo, può quindi chiedere, in cambio, un certificato client , ottenendo il tipo di autenticazione stanno cercando. E i browser Web supportano i certificati client per SSL.

Si noti che il certificato autofirmato contiene la chiave pubblica del server. Sebbene questa chiave pubblica non verrà convalidata, verrà comunque utilizzata per alimentare lo scambio di chiavi, quindi è necessario utilizzare un tipo e una lunghezza della chiave appropriati (ad esempio RSA 2048). In alternativa, utilizzare una delle suite di crittografia "DHE", nel qual caso la chiave pubblica del server viene utilizzata solo per le firme, per non proteggere effettivamente i dati, quindi ( nel caso specifico ), le sue dimensioni e la sua segretezza diventano irrilevanti.

48
Thomas Pornin

No. Secondo specifiche di HTTPS , è necessario un certificato poiché è il modo in cui un server si identifica al client. Non è necessario che il certificato sia valido, vale a dire che non deve essere emesso e firmato da un'autorità di certificazione che il browser considera attendibile per impostazione predefinita.

HTTPS (HTTP over TLS) è nato dall'idea che dobbiamo assicurarci di essere effettivamente connessi allo stesso server Web a cui stiamo cercando di connetterci. In effetti, vedrai che molti software per server web non hanno nemmeno il supporto per l'autenticazione HTTPS a due vie.

Ovviamente, ci sono eccezioni are (suite di cifratura anonime, chiavi precondivise, ecc.) Ma tutte presentano problemi propri. Ad esempio, Mozilla non supporta le suite di crittografia anonime nei loro prodotti. Chrome ha recentemente seguito lo stesso percorso pure. Le chiavi precondivise presentano problemi di distribuzione regolari che sfruttano davvero la crittografia a chiave pubblica.

La linea di fondo è: è necessario un certificato del server per HTTPS.

15
Adi

No. Nel momento in cui inizi lo scambio TLS devi fornire la tua chiave pubblica.

Inoltre, questo non funzionerebbe mai. Non ci sono praticamente attacchi MITM che sono solo "passivo" , un attaccante può modificare i dati fintanto che è in grado di annusarlo.

E l'aggressore può semplicemente fingere di essere il client intercettando la connessione prima dell'inizio di TLS (in Vanilla HTTPS, ciò non funziona poiché non è possibile stabilire la fiducia del falso certificato del server web) e presentare il proprio certificato come client cert .

Inoltre, RSA richiede due chiavi. È necessario crittografare il testo con la chiave privata e la chiave pubblica del client. Una chiave pubblica viene di pari passo con un certificato, quindi ne avrai bisogno.

5
Manishearth

Devi avere un certificato, ma può essere quello che fai tu stesso.

SSL (che è ciò che HTTPS fornisce) richiede un certificato per la comunicazione sicura perché è il fondamento della crittografia e ciò che viene utilizzato per autenticare che il server è chi dichiarano di essere.

Se fai un certificato da solo, i tuoi utenti non avranno alcun motivo per fidarsi del certificato a meno che non sappiano che è già accurato (poiché non ha alcuna verifica indipendente della tua identità) ma fornirà la crittografia bene e confermerà a qualcuno che si connette per la seconda volta che si sta connettendo allo stesso server di prima.

4
AJ Henderson

solo una breve modifica: mescoli server-certs , che sono necessari per fornire HTTP _ [~ # ~] s [~ # ~] _ - servizi e client-certs utilizzati per autenticare un client.

Sebbene chiamato Certs, Client-Cert non ha nulla a che fare con la crittografia; stanno per autenticare il client rispetto a un servizio. I Client-Certs vengono generati usando una sorta di PKI , dove un'autorità con un ROOT-Cert ius è in grado di generare e firmare CLient-Certs.

Apache può eseguire l'autenticazione tramite Client-Certs e VPN