Introductie
Virtuele hosting is de praktijk van het bedienen van meerdere websites op de website dezelfde server. Hoewel het tegenwoordig de norm is, was dit in de begindagen van HTTP (versies voor 1.1) niet mogelijk.
Oorspronkelijk kon een server alleen meerdere websites op dezelfde computer (dwz onder hetzelfde IP-adres) hosten, op voorwaarde dat aan elke website een speciale poort was toegewezen. Dit was geen ideale oplossing omdat browsers standaard poort gebruiken 80 voor HTTP, tenzij de gebruiker een andere specificeert. Als gevolg hiervan kozen de meeste website-eigenaren voor een speciale server om te voorkomen dat gebruikers het juiste poortnummer niet meer onthouden en op een andere website terechtkomen.
Niettemin, naarmate meer gebruikers lid werden van het web en meer netwerkapparaten online verschenen, begon het aantal beschikbare IP-adressen in een alarmerend tempo te dalen. Deze verwachte uitputting, bekend als Uitputting van IPv4-adresbereikheeft de industrie ertoe aangezet verschillende tegenmaatregelen te ontwerpen en uit te voeren, zoals IPv6 (De opvolger van IPv4), die kan ondersteunen meer adressen dan we ooit nodig zullen hebben. Hoewel IPv6 een levensvatbare oplossing is, is deze helaas vrij traag aangenomen. Volgens Google's IPv6-statistieken, op het moment van schrijven is ongeveer 25% van de internetapparaten geïmplementeerd via IPv6.
Virtual hosting werd ook geïmplementeerd als een vroege oplossing van het uitputtingsprobleem, met de introductie van de Host header in HTTP 1.1. Browsers die via HTTP 1.1 communiceerden, konden nu verbinding maken met de poort van een server 80 en neem de domeinnaam op (bijv www.ssl.com) van de website die ze wilden bezoeken in de Host koptekst. Ongeacht het aantal sites dat een server op dezelfde poort host, het kan deze informatie gebruiken om de juiste website te identificeren en de inhoud ervan te retourneren.
HTTPS en virtuele hosting
Talrijke gepubliceerde rapporten over kwetsbaarheden in het netwerk en aanvallen op internetgebruikers hebben de industrie er echter toe aangezet begin weg te gaan van onveilige HTTP naar het veiligere alternatieve HTTPS. De brede acceptatie van HTTPS heeft de algehele gebruikersbeveiliging verbeterd. De aanvullende verbeteringen hebben echter ook de algemene complexiteit van webcommunicatie vergroot.
HTTPS lijkt in principe veel op HTTP, met de uitzondering dat HTTPS-communicatie tussen browsers en servers versleuteld is. In het kort vereist HTTPS dat servers browsers voorzien van een geldig SSL-certificaat dat is uitgegeven door een openbaar vertrouwd certificaat certificaat autoriteit (CA), zoals SSL.com. Een browser kan vervolgens de openbare sleutel in het certificaat gebruiken om een gecodeerd communicatiekanaal met de server tot stand brengen. Verder wordt er een certificaat uitgereikt voor een specifieke domeinnaam, die de browser controleert op een match met het domein dat de gebruiker wilde bezoeken. Het maakt dus niet uit hoeveel websites de server host, browsers verwachten een geldig SSL-certificaat te vinden voor de website die ze hebben aangevraagd.
De oplettende lezer voelt het probleem misschien al aan: de browser heeft het juiste websitecertificaat nodig om het gecodeerde kanaal tot stand te brengen en de Host header, terwijl de server de Host header om het certificaat van de juiste site te vinden. Dit is een klassiek kip-en-ei-probleem.
Het is duidelijk dat virtuele hosting zoals het bedoeld was voor HTTP niet werkt voor HTTPS, omdat de beveiligingsmaatregelen voorkomen dat browsers de Host informatie naar de server. Desalniettemin is virtuele hosting nog steeds een noodzaak, aangezien het IPv4-uitputtingsprobleem nog steeds onopgelost is en de steeds toenemende acceptatie van cloudtechnologieën in de branche (die load-balancing en meerdere fail-over backend-servers vereisen).
Hoe zit het met multi-domein certificaten?
Een voorgestelde oplossing voor dit probleem is het gebruik van meerdere domeinen of SAN-certificaten. Een enkel SAN-certificaat kan honderden verschillende domeinnamen beveiligen, en browsers zullen niet klagen als ze de domeinnaam die ze proberen te bezoeken, vinden in de lijst met domeinen van het SAN-certificaat. Nadat het gecodeerde kanaal is geconfigureerd, kan de browser het Host header naar de server en ga verder zoals in elk ander geval. Dit is een geweldig idee dat gebruikmaakt van een technologie die al aanwezig en beschikbaar is, maar dezelfde mechanismen die de beveiliging van SAN-certificaten garanderen, hebben ook enkele mogelijk ongewenste bijwerkingen geïntroduceerd:
SAN-certificaten zijn een prima hulpmiddel voor het beveiligen van meerdere domeinen die eigendom zijn van dezelfde entiteit (persoon, bedrijf of organisatie), maar ze zijn enigszins onpraktisch om te gebruiken in shared hosting; wanneer een nieuw domein klaar is om te worden toegevoegd aan of verwijderd uit het certificaat, moet een nieuw certificaat met de meest recente lijst met domeinen worden uitgegeven door de CA en opnieuw worden geïmplementeerd op alle domeinen.
Bovendien kunnen SAN-certificaten alleen worden uitgegeven als Organisatie gevalideerd (OV) of uitgebreid gevalideerd (EV) if allen domeinen behoren tot dezelfde organisatie. Deze validatieniveaus verwijzen naar de hoeveelheid en soorten informatie van de potentiële eigenaar van het certificaat, geverifieerd door de CA alvorens ze het certificaat af te geven. Het is aangetoond dat hoe hoger het validatieniveau is, hoe meer vertrouwen gebruikers stellen in de website en het vertrouwen van gebruikers de merkherkenning en conversieratio's kan beïnvloeden.
Ten slotte is het in gedeelde webhostingomgevingen vrij gebruikelijk dat een bedrijf een server deelt met andere bedrijven of organisaties (zelfs met zijn concurrenten). Aangezien de domeinen in SAN-certificaten openbaar worden vermeld, zijn bedrijfseigenaren mogelijk terughoudend om hetzelfde certificaat te delen met externe bedrijven.
Hoewel SAN-certificaten krachtige en veelzijdige tools zijn met talloze toepassingen, hebben deze problemen IETF - het bestuursorgaan voor internetstandaarden - gemotiveerd om te zoeken naar beter passende benaderingen voor het specifieke probleem van virtueel gehoste HTTPS-websites.
Servernaam indicatie voor de redding
De oplossing is geïmplementeerd in de vorm van de Indicatie servernaam (SNI) extensie van de TLS protocol (het deel van HTTPS dat zich bezighoudt met codering).
Met SNI kunnen browsers de domeinnaam specificeren waarmee ze verbinding willen maken tijdens de TLS handdruk (de eerste onderhandeling over het certificaat met de server). Als gevolg hiervan kunnen websites hun eigen SSL-certificaten gebruiken terwijl ze nog steeds worden gehost op een gedeeld IP-adres en poort, omdat HTTPS-servers de SNI-informatie kunnen gebruiken om de juiste certificaatketen te identificeren die nodig is om de verbinding tot stand te brengen.
Daarna, wanneer het gecodeerde communicatiekanaal is geconfigureerd, kan de browser doorgaan met het opnemen van de domeinnaam van de website in de Host koptekst en ga verder zoals normaal. In wezen vervult SNI dezelfde functie als HTTP's Host header tijdens het maken van de gecodeerde verbinding.
Met deze eenvoudige truc konden servers eindelijk meerdere HTTPS-websites op dezelfde poort hosten. Zoals bij de meeste internettechnologieën, heeft SNI echter enkele beperkingen.
SNI-ondersteuning
Hoewel SNI behoorlijk volwassen is sinds het voor het eerst werd opgesteld in 1999, zijn er nog steeds een paar oudere browsers (IE op Windows XP) en besturingssystemen (Android-versies <= 2.3) die dit niet ondersteunen. Raadpleeg voor een uitgebreide lijst met browsers en besturingssystemen die SNI ondersteunen deze tafel.
Hoewel het marktaandeel van browsers die SNI niet ondersteunen (en bijgevolg de gebeurtenissen waarin dit gebeurt) minuscuul is in vergelijking met moderne browsers, zal een browser die SNI niet herkent, terugvallen op het standaard SSL-certificaat en mogelijk een algemene naam komt niet overeen.
Veel bedrijven, zoals Google, implementeren SNI voor de klanten die het ondersteunen en vallen terug op SAN-certificaten voor de zeldzame gevallen die dat niet doen. Uiteraard zal dit probleem naar verwachting afnemen naarmate meer en meer gebruikers en bedrijfseigenaren hun systemen upgraden naar moderne technologieën.
SNI Privacyzorgen
De huidige stabiele versie van TLS (versie 1.2) verzendt het eerste deel van de handshake, en bij uitbreiding SNI-informatie, onversleuteld. Hierdoor kan een netwerkaanvaller de webgeschiedenis van een gebruiker achterhalen, ondanks dat de webcommunicatie zelf volledig is versleuteld.
Verschillende cloudserviceproviders, zoals Amazon of Google, hebben een (vuile) oplossing toegestaan die bekend staat als domein fronting. Domain fronting kan de openbaarmaking van webgeschiedenis voorkomen omdat het SNI-informatie verdoezelt door de hostnaam van de cloudprovider in de TLS onderhandeling en de doelsite in de HTTP-header. Deze methode is echter niet meer haalbaar, aangezien Google en Amazon publiekelijk hebben verklaard dat ze ondersteuning voor domeinfronting uitgeschakeld in hun diensten vanaf april 2018.
Gelukkig is er een meer systemische oplossing voorgesteld als een experimentele diepgang details van de Versleutelde SNI (ESNI) extensie voor de nieuwste TLS versie, 1.3. ESNI versleutelt SNI-informatie en vermindert daarmee alle privacykwesties. Helaas, TLS 1.3 wordt nog niet algemeen geaccepteerd door de industrie TLS 1.3 wordt langzaam het feitelijke netwerkbeveiligingsprotocol. Houd toekomstige artikelen van ons in de gaten over de status van ESNI en privacy van HTTPS en TLS.
Conclusie
Samengevat: met SNI kunt u miljoenen HTTPS-websites op één server hosten. Afhankelijk van uw individuele geval werkt een SAN-certificaat echter mogelijk beter voor u. De privacykwesties over SNI bestaan nog steeds, hoewel er ook een mogelijke oplossing bestaat met ESNI. In elk geval kunt u met een of een combinatie van deze twee methoden eenvoudig virtuele hosting voor al uw websites implementeren met minimale inspanning.
Als u meer vragen heeft over SNI of niet weet hoe u moet kiezen tussen SAN's en SNI, beantwoorden we graag alle vragen van onze klanten over hun PKI behoeften. Stuur ons een e-mail op support@ssl.com en een expert zal je helpen.
