HTTP su TLS
I servizi Web che richiedono l’uso di un canale sicuro possono utilizzare le funzioni di autenticazione e protezione sui dati in transito offerte dal protocollo SSL/TLS.
Generalmente è sufficiente specificare in una pagina HTML come metodo per la richiesta di un URL “https://” piuttosto che HTTP, perché il client avvii il processo di negoziazione SSL/TLS.
La porta TCP riservata per HTTP su SSL/TLS (o HTTPS), è la 443/tcp.
A seconda della soluzione di autenticazione adottata dal server, può comparire o meno all’utente una finestra pop-up che visualizza il certificato server ricevuto durante la negoziazione.
Una volta accettato un certificato, il browser non presenta più la finestra di dialogo in caso di accessi successivi allo stesso server.
Nel caso sia previsto che anche il client si autentichi fornendo un certificato digitale, il browser è responsabile di presentare all’utente una seconda finestra di dialogo attraverso la quale selezionare uno tra i certificati client disponibili, memorizzati sui supporti connessi alla stazione locale (chiavi USB, file system ecc.).
La fondamentale differenza tra una richiesta di servizio HTTP e l’accesso tramite HTTPS è che nessuna informazione presente nella HTTP Request viene trasmessa se non dopo aver completato tutta la fase di handshake SSL/TLS prevista.
Questo approccio rende particolarmente complesso l’uso di Proxy Server HTTPS, in quanto le informazioni relative all’URL richiesto non vengono trasmesse in chiaro sulla rete e non sono pertanto utilizzabili dal Proxy Server per stabilire verso quale server finale rilanciare la richiesta di servizio.
La soluzione adottata per risolvere questa limitazione è stata quella di introdurre un nuovo metodo HTTP, CONNECT, con cui indicare al Proxy almeno l’indirizzo IP (o il FQDN) e la porta servizio del server remoto da contattare.
Se nel browser è quindi impostato l’uso di un Proxy Server, anche per le connessioni HTTPS, il programma confeziona una Request Line in chiaro utilizzando la CONNECT, mettendo così i Proxy in condizione di instradare correttamente tutti i pacchetti della sessione SSL/TLS che verranno successivamente scambiati tra client e server remoto.
Il rilascio di una sessione SSL/TLS può essere preceduto dall’invio di un Alert che permette ai due partecipanti di giungere a una chiusura concordata della sessione cifrata.
In questa maniera è possibile riutilizzare una stessa sessione per più accessi successivi al servizio.
È comunque possibile avviare unilateralmente la chiusura della sessione corrente senza inviare alcun Alert (chiusura incompleta).
In tal caso la sessione precedente non può essere riutilizzata.
Poichè un Web Server conforme alla versione 1.0 del protocollo HTTP invia sempre un segnale al termine di ogni trasmissione dati, la mancata ricezione di un Alert lato client deve essere considerata come un errore (dati incompleti).
A differenza di quanto accade nel caso di trasmissione delle informazioni in chiaro, dove il browser è in grado di visualizzare i dati ricevuti anche se incompleti (consentendo all’utente di comprenderne la natura e forzarne eventuale ritrasmissione), con SSL/TLS generalmente nessun dato parziale viene mostrato sulla finestra del programma client.
