SNI: Virtual Hosting för HTTPS

Beskrivning

Virtuellt Hosting är praxis att betjäna flera webbplatser på samma server. Även om det är normen nuförtiden var detta inte möjligt under de första dagarna av HTTP (versioner före 1.1).

Notera: Även om detta inte är tekniskt korrekt, betyder "samma server" i den här artikeln att alla domännamn pekar på samma IP-adress och portnummer.

Ursprungligen kunde en server endast vara värd för flera webbplatser på samma maskin (dvs. under samma IP-adress) förutsatt att varje webbplats tilldelades en dedicerad port. Detta var ingen idealisk lösning eftersom webbläsare som standard är port 80 för HTTP, såvida inte användaren anger en annan. Som ett resultat valde de flesta webbplatsägare en dedikerad server för att undvika risken för att användare inte kommer ihåg rätt portnummer och hamnar på en annan webbplats.

Värd för flera webbplatser på flera portar

Icke desto mindre, när fler användare anslöt sig till webben och fler nätverksenheter började dyka upp online, började antalet tillgängliga IP-adresser minska i en oroväckande takt. Denna förväntade utarmning, känd som IPv4-adressområde utmattning, har drivit branschen att utforma och genomföra olika motåtgärder, t.ex. IPv6 (IPv4s efterträdare), som kan stödja fler adresser än vi någonsin kommer att behöva. Tyvärr, även om IPv6 är en livskraftig lösning, har antagandet varit ganska långsamt. Enligt Googles IPv6-statistik, vid tidpunkten för detta skrivande är cirka 25% av Internet-enheter distribuerade via IPv6.

Virtuell värd implementerades också som en tidig begränsning av utmattningsproblemet, med införandet av Host rubrik i HTTP 1.1. Webbläsare som kommunicerar via HTTP 1.1 kunde nu ansluta till en serverport 80 och inkludera domännamnet (t.ex. www.ssl.com) på webbplatsen de ville besöka på Host rubrik. Oavsett hur många webbplatser en server är värd i samma port kan den använda denna information för att identifiera rätt webbplats och returnera dess innehåll.

Hosting flera webbplatser på en enda port - virtuell hosting

HTTPS och Virtual Hosting

Många publicerade rapporter om nätverkssårbarheter och attacker mot webbanvändare har dock motiverat branschen till börja flytta bort från osäker HTTP till dess säkrare alternativ HTTPS. Den breda antagandet av HTTPS har förbättrat den totala användarsäkerheten. Men dess ytterligare förbättringar har också ökat den allmänna komplexiteten i webbkommunikation.

I princip liknar HTTPS ganska HTTP, med undantag för att HTTPS-kommunikation mellan webbläsare och servrar är krypterad. Kortfattat kräver HTTPS att servrar förser webbläsare med ett giltigt SSL-certifikat utfärdat av en offentligt betrodd certifikatmyndighet (CA), t.ex. SSL.com. En webbläsare kan sedan använda den offentliga nyckeln i certifikatet till upprätta en krypterad kommunikationskanal med servern. Dessutom utfärdas ett certifikat för ett specifikt domännamn, vilket webbläsaren söker efter för att matcha den domän som användaren ville besöka. Oavsett hur många webbplatser servern är, förväntar sig webbläsare att hitta ett giltigt SSL-certifikat för den webbplats de har begärt.

Den uppmärksamma läsaren kanske redan känner av problemet: webbläsaren kräver rätt webbplatscertifikat för att upprätta den krypterade kanalen och skicka Host sidhuvud, medan servern behöver Host rubrik för att hitta rätt webbplatscertifikat. Detta är ett klassiskt kyckling-och-äggproblem.

Notera: Även om termen virtuell värd ursprungligen myntades för HTTP-webbplatser, det överfördes också till HTTPS. Det hänvisar till samma praxis att värd för flera webbplatser på en enda server, oavsett den faktiska implementeringsmetoden.

Det är uppenbart att virtuell värd som den var tänkt för HTTP inte fungerar för HTTPS, eftersom säkerhetskontrollerna hindrar webbläsare från att skicka Host information över till servern. Icke desto mindre, med IPv4-utmattningsproblemet fortfarande olöst, och branschens ständigt ökande antagande av molnteknologier (som kräver belastningsbalansering och flera fail-over backend-servrar), är virtuell hosting fortfarande en nödvändighet.

Vad sägs om certifikat med flera domäner?

En föreslagen lösning på detta problem är användningen av flera domäner eller SAN-certifikat. Ett enda SAN-certifikat kan säkra hundratals olika domännamn, och webbläsare klagar inte om de hittar domännamnet de försöker besöka i SAN-certifikatets domänlista. När den krypterade kanalen har konfigurerats kan webbläsaren skicka Host header till servern och fortsätt som i alla andra fall. Detta är en bra idé som använder en redan tillgänglig och tillgänglig teknik, men samma mekanismer som säkerställer säkerheten för SAN-certifikat har också infört några potentiellt oönskade biverkningar:

SAN-certifikat är ett bra verktyg för att säkra flera domäner som ägs av samma enhet (person, företag eller organisation), men de är något opraktiska att använda i delad hosting; varje gång en ny domän är redo att läggas till eller tas bort från certifikatet, måste ett nytt certifikat med den senaste listan med domäner utfärdas av CA och omdisponeras på alla domäner.

Dessutom kan SAN-certifikat endast utfärdas som Organisation Validated (OV) eller Extended Validated (EV) if alla domäner tillhör samma organisation. Dessa valideringsnivåer avser belopp och typer av den potentiella certifikatägarens information verifierad av CA innan du utfärdar certifikatet. Det har visats att ju högre valideringsnivån är, desto mer förtroende lägger användarna på webbplatsen och användarnas förtroende kan påverka varumärkesigenkänningen och konverteringsgraden.

Slutligen är det ganska vanligt i delade webbhotellmiljöer för ett företag att dela en server med andra företag eller organisationer (även med sina konkurrenter). Eftersom domänerna i SAN-certifikat är offentligt listade, kan företagare vara ovilliga att dela samma certifikat med tredjepartsföretag.

Även om SAN-certifikat är kraftfulla och mångsidiga verktyg med otaliga applikationer, har dessa frågor motiverat IETF - det styrande organet för Internetstandarder - att söka efter bättre anpassade tillvägagångssätt för det specifika problemet med virtuella HTTPS-webbplatser.

Servernamnindikation för räddningen

Lösningen implementerades i form av Servernamnindikering (SNI) förlängning av TLS protokoll (den del av HTTPS som hanterar kryptering).

SNI gör det möjligt för webbläsare att specificera domännamnet de vill ansluta till under TLS handskakning (den första certifikatförhandlingen med servern). Som en konsekvens kan webbplatser använda sina egna SSL-certifikat medan de fortfarande är värd för en delad IP-adress och port, eftersom HTTPS-servrar kan använda SNI-informationen för att identifiera lämplig certifikatkedja som krävs för att upprätta anslutningen.

Efteråt, när den krypterade kommunikationskanalen har konfigurerats, kan webbläsaren fortsätta att inkludera webbplatsens domännamn i Host rubrik och fortsätt som vanligt. I huvudsak utför SNI samma funktion som HTTP: er Host rubrik under skapandet av den krypterade anslutningen.

Virtuell värd för HTTPS-webbplatser med SNI

Detta enkla trick tillät äntligen servrar att vara värd för flera HTTPS-webbplatser i samma port. Men som med de flesta internettekniker har SNI vissa begränsningar.

SNI Support bekymmer

Även om SNI är ganska moget sedan det först utarbetades 1999, finns det fortfarande några äldre webbläsare (IE på Windows XP) och operativsystem (Android-versioner <= 2.3) som inte stöder det. För en omfattande lista över webbläsare och operativsystem som stöder SNI, ta en titt på det här bordet.

Även om marknadsandelarna för webbläsare som inte stöder SNI (och i förlängningen förekomsten av detta händer) är små jämfört med moderna webbläsare, om en webbläsare inte känner igen SNI kommer den att falla tillbaka till standard SSL-certifikatet och potentiellt producera en vanligt namnfel.

Många företag, till exempel Google, implementerar SNI för de kunder som stöder det och faller tillbaka till SAN-certifikat för de sällsynta fall som inte gör det. Naturligtvis förväntas denna fråga minska när fler och fler användare och företagare uppgraderar sina system till modern teknik.

SNI Sekretessproblem

Den nuvarande stabila versionen av TLS (version 1.2) överför den första delen av handskakningen, och i tillägg SNI-information, okrypterad. Följaktligen kan en nätverksangripare upptäcka en användares webbhistorik trots att webbkommunikationen i sig är helt krypterad.

Olika leverantörer av molntjänster, som Amazon eller Google, har tillåtit en (smutsig) lösning känd som domänfronting. Domain fronting kan förhindra avslöjande av webbhistorik eftersom det fördunklar SNI-information genom att använda molnleverantörens värdnamn i TLS förhandlingar och målwebbplatserna i HTTP-rubriken. Denna metod är dock inte livskraftig längre, eftersom Google och Amazon offentligt har sagt att de inaktiverat stöd för domänfrontering i deras tjänster från april 2018.

Lyckligtvis har en mer systemisk lösning föreslagits som en experimentellt utkast specificerar Krypterat SNI (ESNI) förlängning för den senaste TLS version, 1.3. ESNI krypterar SNI-information och på så sätt minskar alla problem med sekretess. Tyvärr, TLS 1.3 är inte allmänt antagen av branschen ännu, även om TLS 1.3 blir långsamt det de facto nätverkssäkerhetsprotokollet. Håll utkik efter framtida artiklar från oss om statusen till ESNI och integriteten för HTTPS och TLS.

Slutsats

Sammanfattningsvis kan du med SNI vara värd för miljoner HTTPS-webbplatser på en enda server. Beroende på ditt enskilda fall kan ett SAN-certifikat dock fungera bättre för dig. Integritetsproblemen för SNI finns fortfarande, men det finns också en potentiell lösning med ESNI. Hur som helst, med hjälp av en eller en kombination av dessa två metoder, kan du enkelt implementera virtuell värd för alla dina webbplatser med minimal ansträngning.


Om du har fler frågor om SNI eller inte vet hur du väljer mellan SAN och SNI, svarar vi alltid gärna på alla våra kunders frågor om deras PKI behov. Släpp oss bara ett e-postmeddelande kl support@ssl.com och en expert hjälper dig.

Prenumerera på SSL.coms nyhetsbrev

Missa inte nya artiklar och uppdateringar från SSL.com

Håll dig informerad och säker

SSL.com är en global ledare inom cybersäkerhet, PKI och digitala certifikat. Registrera dig för att få de senaste branschnyheterna, tipsen och produktmeddelanden från SSL.com.

Vi vill gärna ha din feedback

Följ vår undersökning och låt oss veta vad du tycker om ditt senaste köp.