Bevezetés
Virtuális tárhely az a gyakorlat, hogy több webhelyet szolgálnak fel a ugyanaz a szerver. Bár manapság ez a norma, ez a HTTP korai napjaiban (1.1-nél korábbi verziók) nem volt lehetséges.
Eredetileg a szerver csak több webhelyet fogadhatott ugyanazon a gépen (azaz ugyanazon az IP-címen), feltéve, hogy minden webhelyhez hozzárendelt port van rendelve. Ez nem volt ideális megoldás, mert a böngészők alapértelmezés szerint portolnak 80 HTTP esetén, kivéve, ha a felhasználó másikat ad meg. Ennek eredményeként a legtöbb webhelytulajdonos egy dedikált szervert választott, hogy elkerülje annak kockázatát, hogy a felhasználók nem emlékeznek a helyes portszámra, és más webhelyre kerülnek.
Ennek ellenére, mivel egyre több felhasználó csatlakozott az internethez, és egyre több hálózati eszköz kezdte megjelenni az interneten, a rendelkezésre álló IP-címek száma aggasztó ütemben kezdett csökkenni. Ez a várható kimerülés, az úgynevezett Az IPv4 címtartomány kimerülése, arra késztette az iparágot, hogy megfogalmazzon és hajtson végre különféle ellenintézkedéseket, például IPv6 (IPv4 utódja), amely támogatni tudja több cím, mint amire valaha is szükségünk lenne. Sajnos, bár az IPv6 életképes megoldás, az elfogadása meglehetősen lassú. Alapján A Google IPv6-statisztikái, e cikk írásakor az internetes eszközöknek csak körülbelül 25% -át telepítették az IPv6-on.
A virtuális tárhelyet a kimerültség problémájának korai enyhítéseként is bevezették, a Host fejléc a HTTP 1.1-ben. A HTTP 1.1 kapcsolaton keresztül kommunikáló böngészők most már csatlakozhattak a szerver portjához 80 és tartalmazza a domain nevet (pl www.ssl.com) a weboldalon, amelyet meg akartak látogatni Host fejléc. Függetlenül attól, hogy hány webhelyet tárol egy kiszolgáló ugyanazon a porton, felhasználhatja ezeket az információkat a helyes webhely azonosítására és annak tartalmának visszaadására.
HTTPS és virtuális tárhely
Számos közzétett jelentés a hálózati sebezhetőségekről és a webfelhasználók elleni támadásokról azonban motiválta az ipart kezdje el távolodni a nem biztonságos HTTP-től a biztonságosabb alternatív HTTPS-hez. A HTTPS javította a felhasználók általános biztonságát. További fejlesztései azonban a webkommunikáció általános komplexitását is megnövelték.
Elvileg a HTTPS meglehetősen hasonlít a HTTP-hez, azzal a különbséggel, hogy a böngészők és a szerverek közötti HTTPS-kommunikáció titkosított. Röviden: a HTTPS előírja, hogy a kiszolgálóknak böngészőknek biztosítaniuk kell egy nyilvánosan megbízható által kiadott érvényes SSL-tanúsítványt tanúsító hatóság (CA), például SSL.com. Ezután egy böngésző felhasználhatja a tanúsítványban szereplő nyilvános kulcsot hozzon létre egy titkosított kommunikációs csatornát a szerverrel. Továbbá tanúsítványt adnak ki egy adott domainnévre, amelyet a böngésző ellenőriz, hogy egyezik-e a felhasználó által meglátogatni kívánt domainnel. Így, függetlenül attól, hogy a szerver hány weboldalt üzemeltet, a böngészők azt várják, hogy találnak érvényes SSL tanúsítványt a kért webhelyhez.
A figyelmes olvasó már érzékelheti a problémát: a böngészőnek a megfelelő webhely tanúsítványára van szüksége a titkosított csatorna létrehozásához és a Host fejléc, míg a szervernek szüksége van a Host fejléc a megfelelő webhely tanúsítványának megkereséséhez. Ez egy klasszikus csirke-tojás probléma.
Nyilvánvaló, hogy a virtuális tárhely, ahogyan azt a HTTP-re tervezték, nem működik a HTTPS-nél, mivel a biztonsági ellenőrzések megakadályozzák, hogy a böngészők küldjék a Host információkat továbbítani a szerverre. Mindazonáltal, mivel az IPv4 kimerülési problémája még mindig megoldatlan, és az ipar egyre növekvő mértékben alkalmazza a felhőtechnológiákat (amelyek terhelés-kiegyenlítő és többszörös hibát okozó háttérszervereket igényelnek), a virtuális tárhely továbbra is szükségszerű.
Mi a helyzet a több domain tanúsítvánnyal?
A probléma javasolt megoldása a több domain vagy SAN tanúsítványok. Egyetlen SAN-tanúsítvánnyal több száz különböző domainnév védhető, és a böngészők nem panaszkodnak, ha a SAN-tanúsítvány domainlistáján találják meg azt a domainnevet, amelyet megpróbálnak meglátogatni. A titkosított csatorna konfigurálása után a böngésző elküldheti a csatornát Host fejlécet a szerverre, és folytassa tovább, mint minden más esetben. Ez egy nagyszerű ötlet, amely a már meglévő és elérhető technológiát használja, de ugyanazok a mechanizmusok, amelyek biztosítják a SAN tanúsítványok biztonságát, néhány potenciálisan nemkívánatos mellékhatást is bevezettek:
A SAN tanúsítványok kiváló eszköz az ugyanazon entitás (személy, vállalat vagy szervezet) tulajdonában lévő több domain biztosításához, ám ezek gyakorlatilag nem praktikusak a megosztott tárhelyen történő felhasználás során; minden alkalommal, amikor egy új domain készen áll a hozzáadásra vagy a tanúsítványtól való eltávolításra, a hitelesítésszolgáltatónak ki kell állítania egy új tanúsítványt a legfrissebb domain-listával, és az összes domainbe kell telepítenie.
Ezenkívül a SAN tanúsítványokat csak formában lehet kiállítani Szervezet validált (OV) vagy kiterjesztett érvényesítés (EV) if minden a domainek ugyanabba a szervezetbe tartoznak. Ezek az érvényesítési szintek a a tanúsítvány leendő tulajdonosának a CA által ellenőrzött adatainak összege és típusai mielőtt kiadná nekik a tanúsítványt. Kimutatták, hogy minél magasabb az érvényesítési szint, annál nagyobb a bizalom a felhasználók számára a webhelyen, és a felhasználói bizalom befolyásolhatja a márka elismerését és az átváltási arányokat.
Végül, a megosztott web hosting környezetben nagyon gyakori, hogy egy vállalat megoszt egy szervert más vállalkozásokkal vagy szervezetekkel (még a versenytársakkal is). Mivel a SAN tanúsítványokban szereplő domainek nyilvánosan szerepelnek, az üzleti tulajdonosok vonakodhatnak ugyanazt a tanúsítványt megosztani harmadik féltől származó társaságokkal.
Bár a SAN tanúsítványok hatékony és sokoldalú eszközök, számtalan alkalmazással, ezek a kérdések arra késztették az IETF-et - az internetes szabványok irányító testületét -, hogy jobban illeszkedő megközelítéseket keressen a virtuálisan tárolt HTTPS-webhelyek sajátos problémájára.
Szervernév jelzése a mentéshez
A megoldást a következő formában valósították meg: Szervernév jelzése (SNI) kiterjesztése TLS protokoll (a HTTPS titkosítással foglalkozó része).
Az SNI lehetővé teszi a böngészők számára, hogy meghatározzák azt a domain nevet, amelyhez csatlakozni akarnak az alatt TLS kézfogás (a szerverrel folytatott kezdeti tanúsítvány-egyeztetés). Ennek eredményeként a webhelyek használhatják saját SSL-tanúsítványaikat, miközben még mindig megosztott IP-címen és porton vannak tárolva, mert a HTTPS-kiszolgálók felhasználhatják az SNI-információkat a kapcsolat létrehozásához szükséges megfelelő tanúsítványlánc azonosítására.
Ezután a titkosított kommunikációs csatorna konfigurálása után a böngésző folytathatja a webhely domain nevének felvételét a Host fejlécet, és folytassa a szokásos módon. Lényegében az SNI ugyanazt a funkciót látja el, mint a HTTP Host fejléc a titkosított kapcsolat létrehozásakor.
Ez az egyszerű trükk végül lehetővé tette a szerverek számára, hogy több HTTPS-webhelyet is tároljanak ugyanazon a porton. Az SNI-hez azonban hasonlóan, mint a legtöbb internetes technológiához, vannak bizonyos korlátai.
SNI támogatási aggályok
Bár az SNI meglehetősen kiforrott, amióta 1999-ben elkészítették, még mindig van néhány régi böngésző (IE Windows XP-n) és operációs rendszer (Android-verzió <= 2.3), amelyek nem támogatják. Az SNI-t támogató böngészők és operációs rendszerek átfogó listáját megtekintheti ezt a táblázatot.
Bár azoknak a böngészőknek a piaci részesedése, amelyek nem támogatják az SNI-t (és ennek kiterjesztésével ennek előfordulása), csekély, összehasonlítva a modern böngészőkkel, ha egy böngésző nem ismeri fel az SNI-t, akkor visszaáll az alapértelmezett SSL-tanúsítványra, és potenciálisan köznév eltérés hiba.
Sok vállalat, például a Google, az SNI-t az ügyfelek számára támogatja, amely támogatja, és visszatér a SAN tanúsítványokhoz azon ritka esetekben, amelyek nem támogatják. Természetesen ez a kérdés várhatóan csökkenni fog, mivel egyre több felhasználó és üzleti tulajdonos korszerűsíti rendszereit a modern technológiákra.
SNI adatvédelmi aggályok
A .a jelenlegi stabil verziója TLS (1.2-es verzió) titkosítatlanul továbbítja a kézfogás kezdeti részét és kiterjesztésével az SNI-információkat. Következésképpen egy hálózati támadó felfedezheti a felhasználó internetes előzményeit, annak ellenére, hogy a webkommunikáció teljesen titkosított.
Különböző felhőalapú szolgáltatók, például az Amazon vagy a Google engedélyeztek egy (piszkos) megoldást, melynek neve domain fronting. A tartománykezelés megakadályozhatja az internetes előzmények nyilvánosságra hozatalát, mert az felhőszolgáltató hosztnevének használatával elfedi az SNI-információkat. TLS egyeztetés és a célhelyek szerepelnek a HTTP fejlécben. Ez a módszer azonban már nem életképes, mivel a Google és az Amazon nyilvánosan kijelentette, hogy igen a domain frontozásának letiltott támogatása szolgálatainál 2018. áprilisától.
Szerencsére szisztémásabb megoldást javasoltak kísérleti vázlat részletezve a Titkosított SNI (ESNI) kiterjesztés a legújabbra TLS verzió, 1.3. Az ESNI az SNI-információkat titkosítja, enyhítve ezzel az összes adatvédelmi aggályt. Sajnálatos módon, TLS Az 1.3-at az ipar még nem alkalmazta széles körben, annak ellenére sem TLS Az 1.3 lassan tényleges hálózati biztonsági protokollmá válik. Figyelemmel kíséri a tőlünk jövőben megjelenő cikkeket, amelyek az ESNI státusáról és a HTTPS és TLS.
Következtetés
Összefoglalva: az SNI-vel több HTTPS webhelyet tárolhat egyetlen kiszolgálón. Az Ön esetétől függően azonban a SAN tanúsítvány jobban működhet az Ön számára. Az SNI-vel kapcsolatos adatvédelmi aggályok továbbra is fennállnak, bár létezik potenciális megoldás az ESNI-vel is. Mindenesetre, a két módszer egyikének vagy ezek kombinációjának használatával, minimális erőfeszítéssel könnyedén végrehajthatja a webhelyek virtuális tárhelyét.
Ha további kérdése van az SNI-vel kapcsolatban, vagy nem tudja, hogyan válasszon a SAN-ok és az SNI között, mindig örömmel válaszolunk ügyfeleink minden kérdésére, PKI igények. Csak küldjön nekünk egy e-mailt a support@ssl.com és egy szakértő segít.
