Introduksjon
Virtual Hosting er praksisen med å betjene flere nettsteder på samme server. Selv om det er normen i dag, var dette ikke mulig i de første dagene av HTTP (versjoner før 1.1).
Opprinnelig kunne en server bare være vert for flere nettsteder på samme maskin (dvs. under samme IP-adresse) forutsatt at hvert nettsted ble tildelt en dedikert port. Dette var ikke en ideell løsning fordi nettlesere som standard port 80 for HTTP, med mindre brukeren spesifiserer en annen. Som et resultat valgte de fleste nettstedseiere en dedikert server for å unngå risikoen for at brukerne ikke husker riktig portnummer og havner på et annet nettsted.
Likevel, etter hvert som flere brukere meldte seg på nettet og flere nettverksenheter begynte å vises online, begynte antallet tilgjengelige IP-adresser å avta med en alarmerende hastighet. Denne forventede uttømming, kjent som IPv4 adresseområde utmattelse, har drevet industrien til å designe og implementere ulike mottiltak, som f.eks IPv6 (IPv4s etterfølger), som kan støtte flere adresser enn vi noensinne vil trenge. Selv om IPv6 er en levedyktig løsning, har dessverre implementeringen vært ganske treg. I følge Googles IPv6-statistikk, i skrivende stund er omtrent 25% av Internett-enheter distribuert over IPv6.
Virtuell hosting ble også implementert som en tidlig avbøtning av utmattelsesproblemet, med innføringen av Host topptekst i HTTP 1.1. Nettlesere som kommuniserer via HTTP 1.1, kunne nå koble til serverens port 80 og inkluderer domenenavnet (f.eks www.ssl.com) av nettstedet de ønsket å besøke på Host Overskrift. Uansett hvor mange nettsteder en server er vert på i samme port, kan den bruke denne informasjonen til å identifisere riktig nettsted og returnere innholdet.
HTTPS og Virtual Hosting
Tallrike publiserte rapporter om sårbarheter i nettverket og angrep mot nettbrukere har imidlertid motivert bransjen til begynne å bevege deg bort fra usikker HTTP, til det sikrere alternative HTTPS. Den brede adopsjonen av HTTPS har forbedret den generelle brukersikkerheten. Imidlertid har de ekstra forbedringene økt den generelle kompleksiteten i webkommunikasjon.
I prinsippet er HTTPS ganske lik HTTP, med unntak av at HTTPS-kommunikasjon mellom nettlesere og servere er kryptert. Kort fortalt krever HTTPS at servere gir nettlesere et gyldig SSL-sertifikat utstedt av en offentlig klarert sertifikatautoritet (CA), som f.eks SSL.com. En nettleser kan deretter bruke den offentlige nøkkelen i sertifikatet til etablere en kryptert kommunikasjonskanal med serveren. Videre utstedes et sertifikat for et bestemt domenenavn, som nettleseren sjekker for samsvar med domenet brukeren ønsket å besøke. Så uansett hvor mange nettsteder serveren er vert, forventer nettlesere å finne et gyldig SSL-sertifikat for nettstedet de har bedt om.
Den oppmerksomme leseren kan allerede ane problemet: nettleseren krever riktig nettstedssertifikat for å etablere den krypterte kanalen og sende Host header, mens serveren trenger Host topptekst for å finne riktig nettstedssertifikat. Dette er et klassisk kylling-og-egg-problem.
Det er tydelig at virtuell hosting slik det ble tenkt for HTTP ikke fungerer for HTTPS, fordi sikkerhetskontrollene hindrer nettlesere i å sende Host informasjon over til serveren. Likevel, med IPv4-utmattelsesproblemet fortsatt uløst, og bransjens stadig økende bruk av skyteknologier (som krever belastningsbalansering og flere fail-over backend-servere), er virtuell hosting fortsatt en nødvendighet.
Hva med sertifikater med flere domener?
En foreslått løsning på dette problemet er bruk av multidomener eller SAN-sertifikater. Et enkelt SAN-sertifikat kan sikre hundrevis av forskjellige domenenavn, og nettlesere vil ikke klage hvis de finner domenenavnet de prøver å besøke i SAN-sertifikatets domeneliste. Etter at den krypterte kanalen er konfigurert, kan nettleseren sende Host header til serveren og fortsett som i alle andre tilfeller. Dette er en god idé som bruker en teknologi som allerede er tilgjengelig og tilgjengelig, men de samme mekanismene som sikrer sikkerheten til SAN-sertifikater har også introdusert noen potensielt uønskede bivirkninger:
SAN-sertifikater er et fint verktøy for å sikre flere domener som eies av samme enhet (person, selskap eller organisasjon), men de er noe upraktiske å bruke i delt hosting; hver gang et nytt domene er klar til å bli lagt til eller fjernet fra sertifikatet, må et nytt sertifikat med den nyeste listen over domener utstedes av CA, og omdisponeres på alle domener.
Videre kan SAN-sertifikater bare utstedes som Organization Validated (OV) eller Extended Validated (EV) if alle domener tilhører samme organisasjon. Disse valideringsnivåene refererer til mengde og typer av den potensielle sertifikatinnehaverens informasjon bekreftet av CA før du utsteder sertifikatet. Det er vist at jo høyere valideringsnivå er, desto mer tillit brukerne plasserer seg på nettstedet, og brukertillit kan påvirke merkevaregjenkjenning og konverteringsfrekvens.
Til slutt er det ganske vanlig i delte webhotellmiljøer for et selskap å dele en server med andre virksomheter eller organisasjoner (selv med konkurrentene). Siden domenene i SAN-sertifikater er børsnotert, kan bedriftseiere være motvillige til å dele det samme sertifikatet med tredjepartsselskaper.
Selv om SAN-sertifikater er kraftige og allsidige verktøy med utallige applikasjoner, har disse problemene motivert IETF - det styrende organet for Internett-standarder - til å søke etter bedre tilpassede tilnærminger til det spesifikke problemet med virtuelle HTTPS-nettsteder.
Servernavn Indikasjon til redning
Løsningen ble implementert i form av Servernavnindikasjon (SNI) utvidelse av TLS protokoll (den delen av HTTPS som omhandler kryptering).
SNI gjør det mulig for nettlesere å spesifisere domenenavnet de vil koble seg til i løpet av TLS håndtrykk (den første sertifikatforhandlingen med serveren). Som en konsekvens kan nettsteder bruke sine egne SSL-sertifikater mens de fremdeles er vert for en delt IP-adresse og port, fordi HTTPS-servere kan bruke SNI-informasjonen til å identifisere riktig sertifikatkjede som kreves for å opprette forbindelsen.
Etterpå, når den krypterte kommunikasjonskanalen er konfigurert, kan nettleseren fortsette å inkludere domenenavnet til nettstedet i Host topptekst og fortsett som normalt. I hovedsak utfører SNI den samme funksjonen som HTTP-er Host overskrift under opprettelsen av den krypterte forbindelsen.
Dette enkle trikset tillot endelig servere å være vert for flere HTTPS-nettsteder i samme port. Som med de fleste internettteknologier har SNI imidlertid noen begrensninger.
SNI støtter bekymringer
Selv om SNI er ganske modent siden det ble utarbeidet i 1999, er det fortsatt noen eldre nettlesere (IE på Windows XP) og operativsystemer (Android-versjoner <= 2.3) som ikke støtter det. For en omfattende liste over nettlesere og operativsystemer som støtter SNI, ta en titt på dette bordet.
Selv om markedsandelen til nettlesere som ikke støtter SNI (og i forlengelsen forekomsten av dette skjer) er liten sammenlignet med moderne nettlesere, vil en nettleser ikke gjenkjenne SNI, falle tilbake til standard SSL-sertifikat og potensielt produsere en vanlig feilfeil ved navn.
Mange selskaper, for eksempel Google, implementerer SNI for kundene som støtter det, og faller tilbake til SAN-sertifikater for de sjeldne tilfellene som ikke gjør det. Naturligvis forventes dette problemet å avta etter hvert som flere og flere brukere og bedriftseiere oppgraderer systemene sine til moderne teknologier.
SNI Personvernproblemer
Den nåværende stabile versjonen av TLS (versjon 1.2) overfører den første delen av håndtrykket, og i tillegg SNI-informasjon, ukryptert. Følgelig kan en nettverksangriper oppdage en brukers nettlogg, til tross for at nettkommunikasjonen selv er fullstendig kryptert.
Ulike skytjenesteleverandører, for eksempel Amazon eller Google, har tillatt en (skitten) løsning kjent som domenefrontning. Domain fronting kan forhindre avsløring av nettlogg fordi den tilslører SNI-informasjon ved å bruke skyleverandørens vertsnavn i TLS forhandling og målområdet er i HTTP-overskriften. Denne metoden er imidlertid ikke levedyktig lenger, siden Google og Amazon offentlig har uttalt at de deaktivert støtte for domenefrontering i deres tjenester fra april 2018.
Heldigvis har en mer systemisk løsning blitt foreslått som en eksperimentelt utkast detaljering av Kryptert SNI (ESNI) utvidelse for det nyeste TLS versjon, 1.3. ESNI krypterer SNI-informasjon, og reduserer dermed alle personvernhensyn. Dessverre, TLS 1.3 er ikke allment akseptert av bransjen ennå, selv om TLS 1.3 blir sakte den faktiske nettverkssikkerhetsprotokollen. Hold øye med fremtidige artikler fra oss om statusen til ESNI og personvernet til HTTPS og TLS.
konklusjonen
Oppsummert kan du med SNI være vertskap for millioner av HTTPS-nettsteder på en enkelt server. Avhengig av din individuelle sak, kan et SAN-sertifikat imidlertid fungere bedre for deg. Bekymringene om personvern om SNI eksisterer fortsatt, selv om det også eksisterer en potensiell løsning med ESNI. Uansett, ved å bruke en eller en kombinasjon av disse to metodene, kan du enkelt implementere virtuell hosting for alle nettsteder med minimal innsats.
Hvis du har flere spørsmål om SNI eller ikke vet hvordan du skal velge mellom SAN og SNI, vil vi alltid svare på alle våre kunders spørsmål om deres PKI behov. Bare send oss en e-post kl support@ssl.com og en ekspert vil hjelpe deg.
