Server Name In­di­ca­tion (SNI): che cosa si nasconde dietro questo standard?

La sicurezza gioca un ruolo molto im­por­tan­te su Internet. Perciò gli standard, i cer­ti­fi­ca­ti e i pro­to­col­li cercano di pro­teg­ge­re sia l’utente che il server da pe­ri­co­lo­si attacchi. Uno di questi pro­to­col­li si chiama Transport Layer Security (TLS). Poiché però questo pro­to­col­lo porta con sé parecchi problemi, è stato ampliato con il Server Name In­di­ca­tion (SNI).

Prima di poter com­pren­de­re perché l’SNI è stato svi­lup­pa­to, occorre com­pren­de­re come funziona il TLS. Il suc­ces­so­re di Secure Sockets Layer (SSL) è un co­sid­det­to handshake TLS. Nel processo, client e server, nella maggior parte dei casi il browser e il sito web, scambiano in­for­ma­zio­ni prima ancora che inizi il tra­sfe­ri­men­to vero e proprio dei dati. In questa stretta di mano virtuale il server si iden­ti­fi­ca di fronte al client e invia anche il relativo cer­ti­fi­ca­to di sicurezza. Solo quando il client li ha ve­ri­fi­ca­ti, inizia la co­mu­ni­ca­zio­ne e lo scambio di dati. Se la verifica ha esito negativo, non vengono scambiati ulteriori dati.

Ma cosa succede se diversi siti web sono in ese­cu­zio­ne at­tra­ver­so un indirizzo IP, come per esempio con il virtual hosting? Dato che l’IPv6 non si è ancora affermato come standard, gli indirizzi IP risultano ancora molto limitati e non tutti i domini possono pre­ten­de­re di avere un indirizzo IP tutto per sé. Ma quindi a chi indirizza il client il proprio “Hello” (il primo passo di un handshake TLS)? Ci sono molte pro­ba­bi­li­tà che risponda il sito sbagliato, che non invii il cer­ti­fi­ca­to corretto con il giusto nome dell’host, e che quindi non venga stabilita la con­nes­sio­ne. Per cui è im­por­tan­te che il client comunichi al server a quale dominio (host) sta cercando di con­net­ter­si. Proprio per questo è stato in­tro­dot­to il Server Name In­di­ca­tion.

Quando in una con­nes­sio­ne non protetta più siti web uti­liz­za­no uno stesso indirizzo IP, non ci sono problemi di sorta. Nell’HTTP è previsto che il nome dell’host sia indicato nell’header nel momento in cui si accede ad un sito. Con il TLS deve però avvenire l’handshake prima che il browser possa inviare questi dati. Il Server Name In­di­ca­tion fa in modo che il nome dell’host sia co­mu­ni­ca­to prima dello scambio di cer­ti­fi­ca­ti tra server e client.

L’SNI è un’esten­sio­ne di TLS. Il pro­to­col­lo criptato è parte dello stack di pro­to­col­lo TCP/IP. Come tale, il TLS amplia il Tra­smis­sion Control Protocol (TCP) con una cifratura. Con questo passo ag­giun­ti­vo HTTP diventa così HTTPS. Ampliando il TLS con il Server Name In­di­ca­tion, il pro­to­col­lo di sicurezza mette a di­spo­si­zio­ne con l’handshake un ulteriore campo: sotto il campo Clien­tHel­loEx­ten­sion si trova quello opzionale Ser­ver­Na­me. In questo campo il client (e di questo si fa carico au­to­ma­ti­ca­men­te il browser) inserisce il nome dell’host con il quale vorrebbe col­le­gar­si. In questo modo è as­si­cu­ra­to che risponda l’host corretto.

Gli utenti non si accorgono del fun­zio­na­men­to dell’SNI, dato che nella maggior parte dei casi non devono nemmeno in­stal­la­re o con­fi­gu­ra­re nulla. È suf­fi­cien­te disporre di un sistema operativo recente e di un browser moderno: infatti Firefox, Chrome, Edge, Opera e Safari sup­por­ta­no questa esten­sio­ne di default.

Soltanto gli utenti che uti­liz­za­no ancora Windows XP (o versioni ancora più datate di Windows) con Internet Explorer non hanno a di­spo­si­zio­ne il Server Name In­di­ca­tion. Nel caso dell’utilizzo di un sistema operativo che non supporta più gli ag­gior­na­men­ti, si ha comunque la pos­si­bi­li­tà di in­stal­la­re un altro browser che supporta l’SNI. Anche la maggior parte dei browser per di­spo­si­ti­vi mobili utilizza l’SNI.

Il Server Name In­di­ca­tion non ha soltanto vantaggi: in­nan­zi­tut­to non è sup­por­ta­to da tutti i browser, anche se questo riguarda un numero molto limitato di utenti. Non si tratta però di un modello perfetto, ma di una soluzione di tran­si­zio­ne, come si riconosce dal fatto che sono trasmesse in­for­ma­zio­ni non criptate. Anche se si tratta soltanto del nome dell’host, uti­liz­zan­do una cifratura accurata è difficile che queste in­for­ma­zio­ni finiscano in mano a terzi. Insomma sarebbe si­cu­ra­men­te più sicuro se ogni sito web avesse il proprio indirizzo IP specifico, senza quindi dover in­stal­la­re nessun SNI.

Poiché purtroppo questo non si può cambiare a causa della quantità ridotta di indirizzi IP (almeno fino a quando l’IPv6 non verrà in­tro­dot­to a livello globale), occorre trovare altre soluzioni, una delle quali è appunto offerta dall’SNI. Un’al­ter­na­ti­va sarebbe il cer­ti­fi­ca­to Subject Al­ter­na­ti­ve Name (SAN): con questi cer­ti­fi­ca­ti si possono re­gi­stra­re più domini o nomi host, il che significa che al server non importa con quale dominio il client voglia con­net­ter­si, poiché il cer­ti­fi­ca­to è valido per tutti i domini sul server. Lo svan­tag­gio di questi cer­ti­fi­ca­ti è che sono re­la­ti­va­men­te costosi, perciò molti gestori di siti web sono com­pren­si­bil­men­te poco disposti ad im­ple­men­tar­li. Se l’al­ter­na­ti­va è quella di ri­nun­cia­re ad avere una pagina crit­to­gra­fa­ta, di sicuro l’SNI rap­pre­sen­ta una buona soluzione in­ter­me­dia.