SNI: Virtuel hosting til HTTPS

Introduktion

Virtual Hosting er praksis med at betjene flere websteder på samme server. Selvom det er normen i dag, var dette ikke muligt i de tidlige dage af HTTP (versioner før 1.1).

Bemærk: Selv om dette ikke er teknisk korrekt, angiver "samme server" i forbindelse med denne artikel, at alle domænenavne peger på det samme IP-adresse og portnummer.

Oprindeligt kunne en server kun være vært for flere websteder på den samme maskine (dvs. under den samme IP-adresse), forudsat at hvert websted blev tildelt en dedikeret port. Dette var ikke en ideel løsning, fordi browsere standard til port 80 for HTTP, medmindre brugeren specificerer en anden. Som et resultat valgte de fleste webstedsejere en dedikeret server for at undgå risikoen for, at brugere ikke husker det rigtige portnummer og ender på et andet websted.

Hosting af flere sider på flere havne

Ikke desto mindre, da flere brugere kom med på nettet og flere netværksenheder begyndte at vises online, begyndte antallet af tilgængelige IP-adresser at falde med en alarmerende hastighed. Denne forventede udtømning, kendt som IPv4-adresseområde udmattelse, har drevet industrien til at designe og implementere forskellige modforanstaltninger, f.eks IPv6 (IPv4s efterfølger), som kan understøtte flere adresser, end vi nogensinde har brug for. Selvom IPv6 er en bæredygtig løsning, har det desværre været ret langsomt. Ifølge Googles IPv6-statistik, på dette tidspunkt skrives næsten 25% af internetenhederne over IPv6.

Virtuel hosting blev også implementeret som en hurtig afhjælpning af udmattelsesproblemet med introduktionen af Host header i HTTP 1.1. Browsere, der kommunikerer via HTTP 1.1, kunne nu oprette forbindelse til en servers port 80 og inkluderer domænenavnet (f.eks www.ssl.com) af det websted, de ønskede at besøge på Host header. Uanset hvor mange steder en server er vært på den samme port, kunne den bruge disse oplysninger til at identificere det rigtige websted og returnere sit indhold.

Hosting af flere sider på en enkelt port - virtuel hosting

HTTPS og Virtual Hosting

Adskillige offentliggjorte rapporter om netværkssårbarheder og angreb mod webbrugere har imidlertid motiveret branchen til begynder at bevæge sig væk fra usikker HTTP til dets mere sikre alternative HTTPS. Den brede vedtagelse af HTTPS har forbedret den samlede brugersikkerhed. Imidlertid har dens yderligere forbedringer også øget den generelle kompleksitet af webkommunikation.

I princippet er HTTPS meget lig HTTP, med undtagelse af at HTTPS-kommunikation mellem browsere og servere er krypteret. Kort fortalt kræver HTTPS, at servere giver browsere et gyldigt SSL-certifikat udstedt af en offentligt betroet certifikat myndighed (CA), som f.eks SSL.com. En browser kan derefter bruge den offentlige nøgle, der er indeholdt i certifikatet til etablere en krypteret kommunikationskanal med serveren. Derudover udstedes et certifikat for et specifikt domænenavn, som browseren kontrollerer for at matche det domæne, som brugeren ønskede at besøge. Uanset hvor mange websteder serveren er vært, forventer browsere derfor at finde et gyldigt SSL-certifikat til det websted, de har anmodet om.

Den opmærksomme læser kan allerede mærke problemet: browseren kræver det korrekte websides certifikat for at etablere den krypterede kanal og sende Host header, mens serveren har brug for Host header for at finde det korrekte websteds certifikat. Dette er et klassisk kylling-og-æg-problem.

Bemærk: Selvom udtrykket virtuel hosting oprindeligt blev opfundet til HTTP-websteder, det blev også overført til HTTPS. Det henviser til den samme praksis med at være vært for flere websteder på en enkelt server, uanset den faktiske implementeringsmetode.

Det er åbenlyst, at virtuel hosting, som det blev udtænkt for HTTP, ikke fungerer for HTTPS, fordi sikkerhedskontrollerne forhindrer browsere i at sende Host information over til serveren. Ikke desto mindre, med IPv4-udmattelsesproblemet stadig uafklaret, og branchens stadigt stigende anvendelse af skyteknologier (der kræver belastningsbalancering og flere fail-over backend-servere), er virtuel hosting stadig en nødvendighed.

Hvad med certifikater med flere domæner?

En foreslået løsning på dette problem er brugen af ​​multi-domæne eller SAN-certifikater. Et enkelt SAN-certifikat kan sikre hundredvis af forskellige domænenavne, og browsere klager ikke, hvis de finder det domænenavn, de prøver at besøge, på SAN-certifikatets domæneliste. Når den krypterede kanal er konfigureret, kan browseren sende Host header til serveren og fortsæt som i alle andre tilfælde. Dette er en god idé, der bruger en teknologi, der allerede er til stede og tilgængelig, men de samme mekanismer, der sikrer sikkerheden af ​​SAN-certifikater, har også introduceret et par potentielt uønskede bivirkninger:

SAN-certifikater er et fint værktøj til at sikre flere domæner, der ejes af den samme enhed (person, firma eller organisation), men de er noget upraktiske at bruge i delt hosting; hver gang et nyt domæne er klar til at føjes til eller fjernes fra certifikatet, skal et nyt certifikat med den seneste liste over domæner udstedes af CA og omdisponeres på alle domæner.

Derudover kan SAN-certifikater kun udstedes som Organisation valideret (OV) eller forlænget valideret (EV) if alle domæner hører til den samme organisation. Disse valideringsniveauer henviser til beløb og typer af den potentielle certifikatsejeres oplysninger, der er verificeret af CA før du udsteder certifikatet. Det er vist, at jo højere valideringsniveauet er, jo mere tillid brugerne placerer sig på webstedet, og brugertillid kan påvirke brand-anerkendelses- og konverteringsfrekvenser.

Endelig er det ret almindeligt i delte webhostingsmiljøer for en virksomhed at dele en server med andre virksomheder eller organisationer (selv med sine konkurrenter). Da domænerne i SAN-certifikater er offentligt noterede, kan virksomhedsejere være tilbageholdende med at dele det samme certifikat med tredjepartsfirmaer.

Selvom SAN-certifikater er kraftfulde og alsidige værktøjer med utallige applikationer, har disse problemer motiveret IETF - det styrende organ for internetstandarder - til at søge efter bedre tilpassede tilgange til det specifikke problem med virtuelt hostede HTTPS-websteder.

Servernavn Angivelse til redning

Løsningen blev implementeret i form af Angivelse af servernavn (SNI) udvidelse af TLS protokol (den del af HTTPS, der beskæftiger sig med kryptering).

SNI gør det muligt for browsere at specificere det domænenavn, de vil oprette forbindelse til i løbet af TLS håndtryk (den første certifikatforhandling med serveren). Som en konsekvens kan websteder bruge deres egne SSL-certifikater, mens de stadig er vært på en delt IP-adresse og -port, fordi HTTPS-servere kan bruge SNI-informationen til at identificere den relevante certifikatkæde, der kræves for at etablere forbindelsen.

Bagefter, når den krypterede kommunikationskanal er konfigureret, kan browseren fortsætte med at inkludere domænenavnet på webstedet i Host header og fortsæt som normalt. I det væsentlige udfører SNI den samme funktion som HTTP'er Host header under oprettelsen af ​​den krypterede forbindelse.

Virtuel hosting af HTTPS-websteder med SNI

Dette enkle trick tillod endelig servere at være vært for flere HTTPS-websteder på den samme port. Som med de fleste internetteknologier har SNI dog nogle begrænsninger.

SNI Support bekymringer

Selvom SNI er ret modent, siden det blev oprettet i 1999, er der stadig et par ældre browsere (IE på Windows XP) og operativsystemer (Android-versioner <= 2.3), der ikke understøtter det. For en omfattende liste over browsere og operativsystemer, der understøtter SNI, skal du tage et kig på denne tabel.

Selvom markedsandele for browsere, der ikke understøtter SNI (og i forlængelse heraf forekomsterne af dette sker), er mindre i forhold til moderne browsere, hvis en browser ikke genkender SNI, falder den tilbage til standard SSL-certifikatet og potentielt producerer en almindelig fejlfejl i navnet.

Mange virksomheder, såsom Google, implementerer SNI for de klienter, der understøtter det, og falder tilbage til SAN-certifikater for de sjældne tilfælde, der ikke gør det. Naturligvis forventes dette problem at blive mindre, når flere og flere brugere og virksomhedsejere opgraderer deres systemer til moderne teknologier.

SNI-beskyttelse af personlige oplysninger

Den aktuelle stabile version af TLS (version 1.2) transmitterer den indledende del af håndtrykket, og ved udvidelse SNI-information, ukrypteret. Derfor kan en netværksangriber opdage en brugers webhistorik på trods af, at webkommunikationen selv er fuldt krypteret.

Forskellige cloud-tjenesteudbydere, såsom Amazon eller Google, har tilladt en (beskidt) løsning, kendt som domæne fronting. Domain fronting kan forhindre afsløring af webhistorik, fordi det tilslører SNI-oplysninger ved hjælp af skyudbyderens værtsnavn i TLS forhandling og målwebstedet i HTTP-overskriften. Denne metode er imidlertid ikke levedygtig længere, da Google og Amazon offentligt har udtalt, at de deaktiveret support til domænefrontering i deres tjenester fra april 2018.

Heldigvis er en mere systemisk løsning blevet foreslået som en eksperimentelt udkast detailing the Krypteret SNI (ESNI) udvidelse til den nyeste TLS version, 1.3. ESNI krypterer SNI-oplysninger og reducerer således alle hensyn til privatlivets fred. Uheldigvis, TLS 1.3 er ikke bredt vedtaget af branchen endnu, selvom TLS 1.3 bliver langsomt de facto netværkssikkerhedsprotokol. Hold øje med fremtidige artikler fra os om status for ESNI og privatlivets fred for HTTPS og TLS.

Konklusion

I sammendraget kan du med SNI være vært for millioner af HTTPS-websteder på en enkelt server. Afhængigt af din individuelle sag, fungerer et SAN-certifikat muligvis bedre for dig. Bekymringer om beskyttelse af personlige oplysninger om SNI eksisterer stadig, selvom der også findes en potentiel løsning med ESNI. Under alle omstændigheder ved hjælp af en eller en kombination af disse to metoder kan du let implementere virtuel hosting til alle dine websteder med minimal indsats.


Hvis du har flere spørgsmål om SNI eller ikke ved, hvordan du vælger mellem SAN'er og SNI, er vi altid glade for at besvare alle vores kunders spørgsmål om deres PKI har brug for. Bare send os en e-mail kl support@ssl.com og en ekspert vil hjælpe dig.

Abonner på SSL.coms nyhedsbrev

Gå ikke glip af nye artikler og opdateringer fra SSL.com

Hold dig informeret og sikker

SSL.com er en global leder inden for cybersikkerhed, PKI og digitale certifikater. Tilmeld dig for at modtage de seneste industrinyheder, tips og produktmeddelelser fra SSL.com.

Vi vil meget gerne have din feedback

Tag vores undersøgelse og fortæl os dine tanker om dit seneste køb.