Introduzione
Hosting virtuale è la pratica di servire più siti Web su stesso server. Sebbene sia la norma al giorno d'oggi, questo non era possibile nei primi giorni di HTTP (versioni precedenti alla 1.1).
Inizialmente, un server poteva ospitare più siti Web sulla stessa macchina (ovvero con lo stesso indirizzo IP) a condizione che a ciascun sito Web fosse assegnata una porta dedicata. Questa non era una soluzione ideale perché il browser porta alla porta di default 80 per HTTP, a meno che l'utente non ne specifichi uno diverso. Di conseguenza, la maggior parte dei proprietari di siti Web ha optato per un server dedicato per evitare il rischio che gli utenti non ricordassero il numero di porta corretto e finissero su un altro sito Web.
Tuttavia, quando più utenti si sono uniti al Web e più dispositivi di rete hanno iniziato ad apparire online, il numero di indirizzi IP disponibili ha iniziato a diminuire a un ritmo allarmante. Questo esaurimento anticipato, noto come Esaurimento dell'intervallo di indirizzi IPv4, ha spinto l'industria a progettare e attuare varie contromisure, come ad esempio IPv6 (Successore di IPv4), che può supportare più indirizzi di quanti avremo mai bisogno. Sfortunatamente, sebbene IPv6 sia una soluzione praticabile, la sua adozione è stata piuttosto lenta. Secondo Statistiche IPv6 di Google, al momento della stesura di questo documento, circa il 25% dei dispositivi Internet è distribuito su IPv6.
L'hosting virtuale è stato anche implementato come una soluzione precoce al problema dell'esaurimento, con l'introduzione di Host intestazione in HTTP 1.1. I browser che comunicavano tramite HTTP 1.1 erano ora in grado di connettersi alla porta di un server 80 e includere il nome di dominio (ad es www.ssl.com) del sito Web che desideravano visitare nel Host intestazione. Indipendentemente dal numero di siti ospitati da un server sulla stessa porta, potrebbe utilizzare queste informazioni per identificare il sito Web corretto e restituirne il contenuto.
HTTPS e hosting virtuale
Numerosi rapporti pubblicati sulle vulnerabilità della rete e gli attacchi contro gli utenti Web, tuttavia, hanno motivato l'industria a inizia ad allontanarti da HTTP non sicuro, verso il suo HTTPS alternativo più sicuro. L'ampia adozione di HTTPS ha migliorato la sicurezza generale dell'utente. Tuttavia, i suoi miglioramenti aggiuntivi hanno anche aumentato la complessità generale delle comunicazioni web.
In linea di principio, HTTPS è abbastanza simile a HTTP, con l'eccezione che le comunicazioni HTTPS tra browser e server sono crittografate. In breve, HTTPS richiede ai server di fornire ai browser un certificato SSL valido emesso da un pubblico attendibile autorità di certificazione (CA), ad esempio SSL.com. Un browser può quindi utilizzare la chiave pubblica contenuta nel certificato per stabilire un canale di comunicazione crittografato con il server. Inoltre, viene emesso un certificato per un nome di dominio specifico, che il browser verifica per una corrispondenza con il dominio che l'utente desiderava visitare. Pertanto, indipendentemente dal numero di siti Web ospitati dal server, i browser si aspettano di trovare un certificato SSL valido per il sito Web richiesto.
Il lettore attento potrebbe già percepire il problema: il browser richiede il certificato del sito web corretto per stabilire il canale crittografato e inviare il Host intestazione, mentre il server ha bisogno del Host intestazione per individuare il certificato del sito corretto. Questo è un classico problema di pollo e uova.
È evidente che l'hosting virtuale così com'è stato concepito per HTTP non funziona per HTTPS, poiché i controlli di sicurezza impediscono ai browser di inviare il Host informazioni al server. Tuttavia, con il problema dell'esaurimento di IPv4 ancora irrisolto e l'adozione sempre crescente da parte del settore di tecnologie cloud (che richiedono il bilanciamento del carico e più server backend fail-over), l'hosting virtuale è ancora una necessità.
Che dire dei certificati multi-dominio?
Una soluzione proposta a questo problema è l'uso di più domini o Certificati SAN. Un singolo certificato SAN può proteggere centinaia di nomi di dominio diversi e i browser non si lamenteranno se trovano il nome di dominio che stanno cercando di visitare nell'elenco dei domini del certificato SAN. Dopo aver configurato il canale crittografato, il browser può inviare il file Host intestazione al server e continuare come in ogni altro caso. Questa è un'ottima idea che utilizza una tecnologia già presente e disponibile, ma gli stessi meccanismi che garantiscono la sicurezza dei certificati SAN hanno introdotto anche alcuni effetti collaterali potenzialmente indesiderati:
I certificati SAN sono un ottimo strumento per proteggere più domini di proprietà della stessa entità (persona, società o organizzazione), ma sono in qualche modo poco pratici da utilizzare nell'hosting condiviso; ogni volta che un nuovo dominio è pronto per essere aggiunto o rimosso dal certificato, la CA deve emettere un nuovo certificato con l'ultimo elenco di domini e ridistribuire su tutti i domini.
Inoltre, i certificati SAN possono essere emessi solo come Organizzazione convalidata (OV) o estesa convalidata (EV) if contro tutti i i domini appartengono alla stessa organizzazione. Questi livelli di validazione si riferiscono a quantità e tipi di informazioni del potenziale proprietario del certificato verificate dalla CA prima di rilasciare loro il certificato. È stato dimostrato che maggiore è il livello di convalida, maggiore è la fiducia degli utenti nel sito Web e la fiducia degli utenti può influire sul riconoscimento del marchio e sui tassi di conversione.
Infine, è abbastanza comune negli ambienti di web hosting condiviso per un'azienda condividere un server con altre aziende o organizzazioni (anche con i suoi concorrenti). Poiché i domini nei certificati SAN sono elencati pubblicamente, i proprietari delle aziende potrebbero essere riluttanti a condividere lo stesso certificato con società terze.
Sebbene i certificati SAN siano strumenti potenti e versatili con innumerevoli applicazioni, questi problemi hanno motivato IETF - l'ente governativo per gli standard Internet - a cercare approcci più adatti al problema specifico dei siti Web HTTPS ospitati virtualmente.
Nome server Indicazione al salvataggio
La soluzione è stata implementata sotto forma di Indicazione nome server (SNI) estensione del TLS protocollo (la parte di HTTPS che si occupa della crittografia).
SNI consente ai browser di specificare il nome di dominio a cui desiderano connettersi durante il TLS stretta di mano (la negoziazione iniziale del certificato con il server). Di conseguenza, i siti Web possono utilizzare i propri certificati SSL mentre sono ancora ospitati su un indirizzo IP e una porta condivisi, poiché i server HTTPS possono utilizzare le informazioni SNI per identificare la catena di certificati appropriata richiesta per stabilire la connessione.
Successivamente, quando il canale di comunicazione crittografato è stato configurato, il browser può procedere con l'inclusione del nome di dominio del sito Web in Host intestazione e continuare come farebbe normalmente. In sostanza, SNI svolge la stessa funzione di HTTP Host intestazione durante la creazione della connessione crittografata.
Questo semplice trucco ha finalmente permesso ai server di ospitare più siti Web HTTPS sulla stessa porta. Tuttavia, come con la maggior parte delle tecnologie Internet, SNI presenta alcune limitazioni.
Preoccupazioni del supporto SNI
Sebbene SNI sia abbastanza maturo da quando è stato redatto per la prima volta nel 1999, ci sono ancora alcuni browser legacy (IE su Windows XP) e sistemi operativi (versioni Android <= 2.3) che non lo supportano. Per un elenco completo di browser e sistemi operativi che supportano SNI, dai un'occhiata a questo tavolo.
Sebbene le quote di mercato dei browser che non supportano SNI (e per estensione le occorrenze di ciò che accade) siano minuscole rispetto ai browser moderni, se un browser non riconosce SNI tornerà al certificato SSL predefinito e potenzialmente produrrà un errore di mancata corrispondenza del nome comune.
Molte aziende, come Google, implementano SNI per i client che lo supportano e ricorrono ai certificati SAN per i rari casi che non lo fanno. Naturalmente, questo problema dovrebbe diminuire man mano che sempre più utenti e proprietari di aziende aggiornano i loro sistemi alle moderne tecnologie.
Preoccupazioni sulla privacy SNI
L'attuale versione stabile di TLS (versione 1.2) trasmette la parte iniziale dell'handshake e, per estensione, le informazioni SNI, non crittografate. Di conseguenza, un utente malintenzionato di rete può scoprire la cronologia Web di un utente, nonostante le stesse comunicazioni Web siano completamente crittografate.
Vari fornitori di servizi cloud, come Amazon o Google, hanno consentito una soluzione (sporca) nota come fronting del dominio. Il fronting del dominio può impedire la divulgazione della cronologia web perché offusca le informazioni SNI utilizzando il nome host del provider cloud nel TLS negoziazione e il sito di destinazione è nell'intestazione HTTP. Tuttavia, questo metodo non è più praticabile, poiché Google e Amazon hanno dichiarato pubblicamente che lo hanno fatto supporto disabilitato per il fronting del dominio nei loro servizi dall'aprile 2018.
Fortunatamente, è stata proposta una soluzione più sistemica come file bozza sperimentale dettagliare il SNI crittografato (ESNI) estensione per il più recente TLS versione, 1.3. ESNI crittografa le informazioni SNI, mitigando così tutti i problemi di privacy. Sfortunatamente, TLS 1.3 non è ancora ampiamente adottato dall'industria, anche se TLS 1.3 sta lentamente diventando il protocollo di sicurezza della rete di fatto. Tieni d'occhio i nostri articoli futuri sullo stato di ESNI e sulla privacy di HTTPS e TLS.
Conclusione
In sintesi, con SNI è possibile ospitare milioni di siti Web HTTPS su un singolo server. Tuttavia, a seconda del singolo caso, un certificato SAN potrebbe funzionare meglio per te. Le preoccupazioni sulla privacy relative a SNI esistono ancora, sebbene esista anche una potenziale soluzione con ESNI. In ogni caso, utilizzando uno o una combinazione di questi due metodi, è possibile implementare facilmente l'hosting virtuale per tutti i siti Web con il minimo sforzo.
Se hai altre domande su SNI o non sai come scegliere tra SAN e SNI, siamo sempre felici di rispondere a tutte le domande dei nostri clienti sui loro PKI esigenze. Mandaci una email a support@ssl.com e un esperto ti aiuterà.
