次の方法で共有

Internet Explorer – Frequente richiesta delle credenziali con applicazioni SSL

  • [アーティクル]

Uno dei principali motivi per i quali Microsoft Internet Explorer può richiedere l’inserimento delle credenziali quando siamo di fronte ad una connessione HTTPS è relativo ad un abort in fase di handshake.

Vediamo in dettaglio come funzionano i due tipi di handshake SSL.

FULL HANDSHAKE

Durante il full handshake il client e il server si scambiano i relativi certificati per la cifratura dei dati trasmessi via web. Con il full handshake viene creato un ID di sessione relativo al processo di autenticazione appena concluso. L’ID di sessione consente al client e al server di riconoscere come sicura la connessione.

image001_thumb[1]

Terminato l’handshake inizia la trasmissione dei dati crittografati per l’invio sul web.

image002_thumb[2]

Periodicamente, durante la connessione, possono essere inviati dei pacchetti dati di tipo “close notify” con level settato a warning. Questi pacchetti consentono, quando ad esempio il trasferimento dei dati è terminato, la chiusura concordata della connessione, mantenendola comunque valida. In questo caso l’ID di sessione generato nella fase di handshake viene mantenuto nella cache SSL e può essere riutilizzato per le connessioni seguenti.

SHORT HANDSHAKE

Per ristabilire una connessione mantenendo il session ID presente in cache non è più necessario  lo scambio dei certificati; è quindi possibile utilizzare uno short handshake.

image003_thumb[1]

Durante lo short handshake non vi è scambio di certificati, vengono scambiate solo le chiavi per la cifratura dei dati e successivamente viene avviato il trasferimento dei dati.

CONNECTION ABORT

Si ha un abort della connessione, caratterizzato dall’invio di un pacchetto TCP di reset, sostanzialmente quando si naviga su un altro link.

Questa casistica si può verificare ad esempio:

  • Cliccando direttamente su un altro link
  • Richiedendo il reload della pagina ad esempio con F5 (di fatto si naviga sullo stesso link ma la connessione è effettuata come se fosse su una nuova pagina)
  • Attivando qualche javascript che chiede un reload.

L’abort termina il caricamento della pagina e richiede la nuova pagina al server.

In genere questa condizione non causa il purge (cancellazione) della cache e quindi l’ID di sessione rimane valido per le successive connessioni.

image004_thumb[1]

Esiste però un caso particolare che richiede, alla successiva connessione, un full handshake e quindi la rinegoziazione dei certificati.

Per garantire la sicurezza delle informazioni trasmesse il Secure Channel di Windows, che fornisce supporto all’SSL, è stato disegnato in modo da eseguire il purge della cache SSL nel momento in cui si ha un abort durante un handshake.

Come conseguenza di quanto appena descritto la successiva connessione richiederà non più uno short handshake, bensì un full handshake; potrebbe essere quindi necessario specificare le proprie credenziali se l’applicazione lo prevede.

image005_thumb[1]

Per ovviare a questo problema è buona norma bloccare l’”uso” della pagina prima che questa sia stata completamente scaricata.

Uno tra i metodi utilizzabili consiste nel creare un livello trasparente e disabilitarlo al termine del caricamento della pagina. Di seguito riporto un esempio.

<html>
<head>
<SCRIPT TYPE="text/javascript" LANGUAGE="javascript">
          function waitLoading()
           {
            if (document.getElementById)
             document.getElementById('protectloading').style.visibility='visible';
            else //IE4
             document.all.protectloading.style.visibility = 'visible';
           }
       </SCRIPT>
    </head>

<body onLoad="waitLoading();">
      <div id="protectloading" style='position:absolute;
           left:0px; top:0px; background-color:white;
           layer-background-color:white;
           height:100%; width:100%; visibility:hidden;">

        <!—CODICE PAGINA -->

      </div>
    </body>
</html>

Maggiori informazioni:

  • KB 257591 - Description of the Secure Sockets Layer (SSL) Handshake

 

Marco Pulita
Microsoft Enterprise Platform Support