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

HTTPS è HTTP-entro-SSL. SSL è un protocollo tunnel: funziona su un flusso bidirezionale esistente per i dati e fornisce a 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 siano associati 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 connessione TCP al server (S), quindi il server avvia un handshake SSL, agendo come client SSL (cioè inviando il messaggio ClientHello , invece di aspettare un ClientHello in arrivo). 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 connesso C, ma il client C non sarà sicuro di quale server S sta parlando (un attaccante potrebbe aver intercettato e reindirizzato la comunicazione). A seconda del contesto, questo può o non può essere appropriato.

Tuttavia, ciò si discosta da HTTPS , in cui il client TCP è anche il client SSL e che il client si aspetta che server per mostrare un certificato, che il client convaliderà con la sua CA conosciuta e attendibile e che contiene il nome del server previsto (come estratto dall'URL, vedi sezione 3.1 ). Corrispondentemente, i client esistenti (browser Web) non supportano l'inversione dei ruoli SSL. Se la tua situazione richiede l'utilizzo di browser, devi ovviamente utilizzare solo le funzionalità disponibili nei browser.

SSL supporta alcune suite di crittografia senza certificato. Le suite di cifrari "DH_anon" sono ritenute deboli, perché non implicano alcuna autenticazione (quindi, Man-in- gli attacchi di mezzo-centrale sono possibili). Le suite di crittografia PSK implicano l'autenticazione reciproca di client e server per quanto riguarda un segreto condiviso. Quando il segreto condiviso è di bassa entropia (per esempio, è una password ), SRP cifra le suite sono migliori.

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

Se la conoscenza dell'identità del server non è importante, è possibile fornire al server un certificato autofirmato, insieme alle istruzioni per i client su come abilitare il proprio browser ad accettare il certificato del server senza cratere troppo strong (vedere questa domanda come punto di partenza). Questo verrà mappato a "normale SSL", che ha due vantaggi:

• I browser esistenti lo supportano.
• Quando il server presenta un certificato, per quanto falso, è quindi permesso chiedere, in cambio, un certificato client , ottenendo il tipo di autenticazione che stai cercando. E i browser Web fanno supportano i certificati client per SSL.

Si noti che il certificato autofirmato contiene la chiave pubblica del server. Sebbene questa chiave pubblica non venga convalidata, sarà comunque utilizzata per alimentare lo scambio di chiavi, quindi è necessario utilizzare un tipo di chiave e una lunghezza appropriati (ad esempio, RSA 2048). In alternativa, utilizzare uno dei pacchetti di crittografia "DHE", nel qual caso la chiave pubblica del server viene utilizzata solo per le firme, non per proteggere effettivamente i dati, quindi ( nel caso specifico ), le sue dimensioni e il segreto diventa insignificante.

No. In base alle specifiche di HTTPS , è necessario un certificato poiché è il modo in cui un server si identifica con il cliente. Il certificato non deve essere valido, ovvero il certificato non deve essere emesso e firmato da una CA che il browser considera attendibile per impostazione predefinita.

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

Naturalmente, ci sono sono eccezioni (suite di crittografia anonime, chiavi precondivise, ecc.) ma tutte hanno i loro problemi. Ad esempio, Mozilla non supporta suite di crittografia anonime nei loro prodotti. Chrome ha effettuato di recente lo stesso percorso . Le chiavi pre-condivise presentano problemi di distribuzione regolari che richiedono realmente la convenienza della crittografia a chiave pubblica.

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

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

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

E l'attaccante può semplicemente fingere di essere il cliente intercettando la connessione prima dell'avvio di TLS (in HTTPS vanigliato, questo non funziona siccome la fiducia del falso cert del webserver non può essere stabilita) e presenta il suo cert come il cliente 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 uno.

Devi avere un certificato, ma può essere uno che fai da te.

SSL (che è quello che fornisce HTTPS) richiede un certificato per le comunicazioni sicure perché questo è il fondamento della crittografia e ciò che viene usato per autenticare il fatto che il server è chi dichiara di essere.

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

solo una piccola modifica: mescoli server-certs , necessari per fornire servizi HTTP_ S _ - e certificati client che vengono utilizzati per autenticare un client.

Sebbene chiamato Certs, Client-Cert non ha nulla a che fare con la Crittografia; stanno per autenticare il cliente contro un servizio. I certificati cliente vengono generati utilizzando un tipo di PKI , in cui un'autorità con un ROOT-Cert ius ablke genera e Iscriviti a CLient-Certs.

Apache può eseguire l'autenticazione tramite Client-Certs, così come VPN