In SSL se l'handshake non ha successo, finisce sempre con un avviso di handshake?
Oppure ci sono altri modi per completare la connessione SSL (accettabile per standard).
Lo sto chiedendo, perché in un server HTTPS configurato per richiedere l'autenticazione del client, se il client non invia un certificato, vedo (tramite i pacchetti di rete) un messaggio TLS completato da server a client; Mi aspettavo un avviso.
Una connessione SSL / TLS deve sempre terminare con un messaggio di avviso di qualche tipo: una connessione interrotta (ad esempio, il socket TCP sottostante è chiuso) senza un avviso si dice che sia terminato in modo errato. Il messaggio di avviso per un termine normale è close_notify .
L'handshake è solo una parte della connessione; una stretta di mano si verifica all'inizio e le successive strette di mano possono essere riprodotte sulla stessa connessione. L'handshake di solito è dove si verificano degli errori, attivando i messaggi di avviso, ma un messaggio di avviso fatale non termina solo l'handshake: chiude l'intera connessione.
Nel caso di un server che richiede l'autenticazione del client, il client può rispondere inviando un certificato e calcolando una firma; tuttavia, questo è opzionale. Il cliente è autorizzato a non onorare la richiesta. Il server sceglie quindi cosa fare. Il server può rifiutare il client immediatamente, attraverso un messaggio di avviso che chiude la connessione. Il server può anche decidere di continuare e gestire la mancanza di autenticazione del client a un altro livello. Un server che invia un messaggio Finished sceglie certamente di continuare; eventualmente, il server può decidere di segnalare l'errore come dati applicativi all'interno del tunnel (ad esempio, per un server HTTPS, inviare un messaggio di errore HTTP una volta che l'handshake è terminato).
Vedi RFC 2246 , sezione 7.4.6 per i dettagli:
This is the first message the client can send after receiving a
server hello done message. This message is only sent if the
server requests a certificate. If no suitable certificate is
available, the client should send a certificate message
containing no certificates. If client authentication is required
by the server for the handshake to continue, it may respond with
a fatal handshake failure alert.
→ enfasi su "può".
La sezione sui certificati client nella specifica TLS 1.0 (RFC 2246) dice questo:
If no suitable certificate is available, the client should send a certificate message containing no certificates. If client authentication is required by the server for the handshake to continue, it may respond with a fatal handshake failure alert.
Il fatto che possa rispondere con un avviso fatale non significa che debba farlo.
Hai taggato la tua domanda con IIS, ma qui c'è un po 'di background su altri server.
In Apache Httpd, ci sono tre impostazioni per richiedere un certificato client : none , optional e required (e optional_no_ca se si desidera disabilitare la verifica del certificato lì).
Quando il server è configurato con optional , quando il client non presenta un certificato, l'handshake continuerà comunque. Quando il server è configurato con required , se non è presente alcun certificato client, si verificherà un avviso di errore irreversibile. Java SSLEngine implementa questi impostazioni con setWantClientAuth e setNeedClientAuth .
Si noti che procedere con l'handshake non significa che il server concederà l'accesso alla risorsa o autorizzerà l'esecuzione della richiesta.
Il grosso lato negativo del comportamento di avviso di guasto fatale è che chiude bruscamente la connessione. Nella migliore delle ipotesi, apparirà come un messaggio di "connessione chiusa - errore di handshake" (o qualcosa di simile) nel browser. Nessuno scambio HTTP avrà avuto luogo, quindi non è possibile inviare un codice di stato HTTP e / o una pagina web di accompagnamento per descrivere il problema.
Da un punto di vista dell'usabilità, questo può essere molto confuso, specialmente per gli utenti che non hanno necessariamente familiarità con i certificati client (spesso c'è una certa curva di apprendimento semplicemente per gestire i certificati). Per questo motivo, molti server richiedono solo l'autenticazione del certificato client opzionale, in modo da poter inviare una spiegazione se l'autorizzazione è negata.
Devo ammettere che non sono del tutto familiare con le impostazioni in IIS, ma la documentazione sembra suggerire che ci sono anche tre opzioni:
Select Ignore if you do not want to accept a client certificate even if a client presents one.
Select Accept to accept client certificates.
Select Require to require client certificates. To use Require Client Certificates, you must enable Require SSL.
Un altro documento suggerisce che esiste un codice di stato HTTP e un messaggio di errore per non aver fornito un certificato richiesto: " 403.7 Proibito: richiesto il certificato del cliente ". Il fatto che esista un codice di stato HTTP per questo caso implica che non è un caso che causa un errore di handshake (altrimenti la connessione non verrebbe stabilita per inviare messaggi HTTP). Ciò implica che la modalità "require" di IIS si comporta come la modalità "facoltativa" di Apache Httpd per quanto riguarda l'handshake TLS, ovvero non presentare un certificato client non causa un avviso fatale (l'autorizzazione in seguito è diversa importa, ovviamente).
Non sono sicuro di cosa siano "ignore" e "accetta", quindi. In SSL / TLS, solo il server può richiedere un certificato, inviando un messaggio CertificateRequest . Se il server non invia questo messaggio, il client semplicemente non invierà mai il suo certificato, ancora una volta, da RFC 2246:
7.4.6. Client certificate
When this message will be sent: This is the first message the client can send after receiving a server hello done message. This message is only sent if the server requests a certificate.
La mia ipotesi è che significano "ignorare" / "accettare" in termini di mappatura dell'account o autorizzazione, più avanti sulla linea.
Modifica.
Per quanto mi ricordo, per impostazione predefinita, IIS negozia sempre i certificati client usando rinegoziazione : una prima stretta di mano ha esito positivo, senza alcuna richiesta di certificato client, ma poi, una seconda stretta di mano è innescato. Ciò significa che non si sarà in grado di vedere lo scambio di certificati client osservando i pacchetti, poiché questa seconda stretta di mano verrà eseguita all'interno della sessione crittografata (in alcuni casi è possibile vederlo con Wireshark, è configurato con il server chiave privata e supporta la suite di crittografia).
È possibile configurare la negoziazione del certificato client da eseguire nell'handshake iniziale utilizzando l'opzione clientcertnegotiation=enable di netsh (che si riferisce all'handshake iniziale).
Prenderò un esempio da OpenSSL, che è usato da Apache.
C'è un flag di modalità, chiamato SSL_VERIFY_PEER che, quando impostato sul server, richiederà un certificato client nell'handshake. Il cliente è libero di inviarlo o meno.
Quindi il comportamento del server dipende da un altro flag:
SSL_VERIFY_FAIL_IF_NO_PEER_CERT
Che è spiegato come segue
Server mode: if the client did not return a certificate, the TLS/SSL handshake is immediately terminated with a ''handshake failure'' alert. This flag must be used together with SSL_VERIFY_PEER.
Se questo flag non è impostato, non viene creato alcun avviso e l'handshake continua normalmente e il server deve verificare il certificato in seguito e chiudere la connessione se necessario.
EDIT: ulteriori informazioni su opzioni di configurazione simili in IIS 7.0:
Sembra che ci sia un attributo sslFlags che può essere uno dei seguenti
Immagino che il comportamento che si nota avvenga perché SslNegotiateCert è configurato al posto di SslRequireCert.
Leggi altre domande sui tag cryptography iis tls