Sissejuhatus
Virtuaalne hostimine on tava veebisaitide teenindamiseks sama server. Ehkki see on tänapäeval norm, ei olnud see HTTP algusaegadel (versioonid enne 1.1) võimalik.
Algselt võis server hostida samas arvutis (st sama IP-aadressi all) ainult mitut veebisaiti, tingimusel et igale veebisaidile oli määratud spetsiaalne port. See ei olnud ideaalne lahendus, kuna brauserid vaikimisi pordi 80 HTTP jaoks, kui kasutaja ei määra muud. Selle tulemusel valisid enamik veebisaitide omanikke spetsiaalse serveri, et vältida ohtu, et kasutajad ei jäta õiget pordinumbrit meelde ja satuvad teisele veebisaidile.
Sellegipoolest, kuna veebiga ühines rohkem kasutajaid ja võrgus hakkas ilmuma üha enam võrguseadmeid, hakkas saadaolevate IP-aadresside arv murettekitava kiirusega vähenema. See eeldatav ammendumine, mida nimetatakse IPv4 aadressivahemiku ammendumine, on ajendanud tööstust kavandama ja rakendama mitmesuguseid vastumeetmeid, näiteks IPv6 (IPv4 järeltulija), mida saab toetada rohkem aadresse, kui me kunagi vajame. Kahjuks, ehkki IPv6 on elujõuline lahendus, on selle kasutuselevõtt olnud üsna aeglane. Vastavalt Google'i IPv6 statistika, on selle kirjutamise ajal vaid umbes 25% Interneti-seadmetest ühendatud IPv6-ga.
Virtuaalset hostimist rakendati ka ammendumise probleemi varase leevendamiseks koos veebisaidi kasutuselevõtuga Host päis HTTP 1.1-s. HTTP 1.1 kaudu suhtlevad brauserid said nüüd ühenduse luua serveri pordiga 80 ja lisage domeeninimi (nt www.ssl.com) veebisaidil, mida nad tahtsid külastada Host päis. Sõltumata sellest, kui palju saite server samas sadamas hostis, võiks ta seda teavet kasutada õige veebisaidi tuvastamiseks ja selle sisu tagastamiseks.
HTTPS ja virtuaalne hostimine
Arvukad avaldatud aruanded võrgu haavatavuste ja veebikasutajate vastu suunatud rünnakute kohta on aga tööstust motiveerinud hakake eemalduma ebakindlast HTTP-st selle turvalisema alternatiivse HTTPS-i juurde. - HTTPS on parandanud kasutajate üldist turvalisust. Kuid selle täiendavad täiustused on suurendanud ka veebisuhtluse üldist keerukust.
Põhimõtteliselt on HTTPS üsna sarnane HTTP-ga, välja arvatud see, et brauserite ja serverite vaheline HTTPS-side on krüptitud. Lühidalt öeldes nõuab HTTPS, et serverid esitaksid brauseritele kehtiva SSL-sertifikaadi, mille on välja andnud avalikult usaldusväärne sertifikaadiasutus (CA), näiteks SSL.com. Seejärel saab brauser kasutada sertifikaadis sisalduvat avalikku võtit looge serveriga krüptitud sidekanal. Lisaks väljastatakse sertifikaat kindlale domeeninimele, mida brauser kontrollib, kas see on vastavuses domeeniga, mida kasutaja soovis külastada. Seega, hoolimata sellest, kui palju veebisaite server majutab, loodavad brauserid leida soovitud veebisaidile kehtiva SSL-sertifikaadi.
Tähelepanelik lugeja võib probleemi juba aimata: brauser nõuab krüpteeritud kanali loomiseks ja Host päises, samas kui server vajab Host päis õige saidi sertifikaadi leidmiseks. See on klassikaline kana-muna probleem.
On ilmne, et virtuaalne hostimine, nagu see HTTP jaoks välja töötati, HTTPS-i puhul ei tööta, kuna turbekontrollid takistavad brauseritel saata Host teave serverisse. Sellest hoolimata, kuna IPv4 ammendumisprobleem on endiselt lahendamata ja tööstusharu üha suurenev pilvetehnoloogia (mis nõuab koormuse tasakaalustamist ja mitut ebaõnnestunud taustaprogrammi) kasutuselevõtt, on virtuaalne hostimine endiselt hädavajalik.
Kuidas on lood mitme domeeni sertifikaatidega?
Selle probleemi kavandatud lahendus on mitme domeeni või SAN-sertifikaadid. Ühe SAN-sertifikaadiga saab kaitsta sadu erinevaid domeeninimesid ja brauserid ei kurda, kui nad leiavad SAN-i sertifikaadi domeeniloendist domeeninime, mida proovite külastada. Pärast krüptitud kanali konfigureerimist saab brauser selle saata Host päise serverisse ja jätkake nagu igal teisel juhul. See on suurepärane idee, mis kasutab juba olemasolevat ja saadaolevat tehnoloogiat, kuid samad mehhanismid, mis tagavad SAN-sertifikaatide turvalisuse, on toonud kaasa ka mõned potentsiaalselt soovimatud kõrvaltoimed:
SAN-sertifikaadid on hea vahend mitme sama domeeni (isiku, ettevõtte või organisatsiooni) omanduses olevate domeenide turvamiseks, kuid neid on jagatud hostimises mõnevõrra ebapraktiline kasutada; alati, kui uus domeen on sertifikaadile lisamiseks või sealt eemaldamiseks valmis, peab CA välja andma uue sertifikaadi koos uusima domeenide loendiga ja kõikides domeenides uuesti kasutusele võtma.
Lisaks saab SAN-sertifikaate välja anda ainult kui Organisatsiooni valideeritud (OV) või laiendatud valideeritud (EV) if kõik domeenid kuuluvad samasse organisatsiooni. Need valideerimistasemed viitavad CA poolt kontrollitud võimaliku sertifikaadi omaniku teabe kogus ja tüübid enne neile sertifikaadi väljaandmist. On tõestatud, et mida kõrgem on valideerimise tase, seda rohkem usaldavad kasutajad veebisaiti ja kasutajate usaldus võib mõjutada kaubamärgi tuntust ja konversioonimäärasid.
Ja lõpuks on jagatud veebimajutuskeskkondades üsna tavaline, et ettevõte jagab serverit teiste ettevõtete või organisatsioonidega (isegi konkurentidega). Kuna SAN-sertifikaatide domeenid on avalikult loendis, võivad ettevõtete omanikud olla vastumeelsed jagama sama sertifikaati kolmandate osapoolte ettevõtetega.
Kuigi SAN-sertifikaadid on võimsad ja mitmekülgsed tööriistad, millel on lugematu arv rakendusi, on need probleemid motiveerinud Interneti-standardite juhtorganit IETF-i otsima paremini sobivaid lähenemisviise virtuaalselt hostitud HTTPS-veebisaitide konkreetsele probleemile.
Serveri nime tähis päästmiseks
Lahendus rakendati programmi kujul Serveri nime tähis (SNI) laiendamine TLS protokoll (HTTPS see osa, mis tegeleb krüptimisega).
SNI võimaldab brauseritel täpsustada domeeninime, millega nad tahavad ühenduse ajal luua TLS käepigistus (esimene sertifikaadi läbirääkimine serveriga). Selle tulemusena saavad veebisaidid kasutada oma SSL-sertifikaate, kui nad on endiselt hostitud jagatud IP-aadressil ja pordil, kuna HTTPS-serverid saavad SNI-teavet kasutada ühenduse loomiseks vajaliku sobiva sertifikaatide ahela tuvastamiseks.
Pärast krüptitud sidekanali konfigureerimist saab brauser lisada veebisaidi domeeninime Host päises ja jätkake nagu tavaliselt. Sisuliselt täidab SNI sama funktsiooni nagu HTTP Host päis krüptitud ühenduse loomise ajal.
See lihtne trikk võimaldas serveritel lõpuks hostida mitut HTTPS-i veebisaiti samas pordis. Kuid nagu enamiku Interneti-tehnoloogiate puhul, on ka SNI-l mõned piirangud.
SNI tugimured
Kuigi SNI on alates selle esmakordsest koostamisest 1999. aastal üsna küps, on endiselt olemas mõned pärandibrauserid (IE Windows XP-l) ja operatsioonisüsteemid (Androidi versioonid <= 2.3), mis seda ei toeta. SNI-d toetavate brauserite ja operatsioonisüsteemide täieliku loendi saamiseks vaadake palun see tabel.
Kuigi SNI-d mitte toetavate brauserite turuosa (ja laiemalt selle juhtumi esinemine) on tänapäevaste brauseritega võrreldes tühine, kui brauser SNI-d ei tunne, langeb see tagasi SSL-i vaikesertifikaadi juurde ja võib potentsiaalselt luua üldnime mittevastavuse viga.
Paljud ettevõtted, näiteks Google, rakendavad SNI-d seda toetavate klientide jaoks ja jäävad haruldaste juhtumite korral tagasi SAN-sertifikaatide juurde. Loomulikult eeldatakse, et see probleem väheneb, kui üha enam kasutajaid ja ettevõtete omanikke täiustavad oma süsteeme kaasaegsete tehnoloogiatega.
SNI privaatsusprobleemid
Programmi praegune stabiilne versioon TLS (versioon 1.2) edastab käepigistuse algosa ja laiendusega SNI teabe krüptimata. Järelikult võib võrguründaja avastada kasutaja veebiajaloo, hoolimata sellest, et veebikommunikatsioon ise on täielikult krüptitud.
Mitmed pilveteenuse pakkujad, näiteks Amazon või Google, on lubanud (määrdunud) ümbersõidu nimega domeenide esikülg. Domeeni esiplaan võib takistada veebiajaloo avalikustamist, kuna see hägustab SNI-teavet, kasutades pilvepakkuja hostinime TLS läbirääkimised ja HTTP-päises olevad sihtsaidid. Kuid see meetod ei ole enam elujõuline, kuna Google ja Amazon on avalikult teatanud, et nad seda teevad domeenide fronteerimise puudega tugi nende teenistuses alates 2018. aasta aprillist.
Õnneks on pakutud süsteemilisemat lahendust eksperimentaalne mustand üksikasjalikult Krüpteeritud SNI (ESNI) pikendus uusimale TLS versioon, 1.3. ESNI krüpteerib SNI teabe, leevendades sellega kõiki privaatsusega seotud probleeme. Kahjuks TLS 1.3 ei ole tööstus veel laialdaselt kasutusele võetud, kuigi TLS 1.3 on aeglaselt muutumas de facto võrguturbeprotokolliks. Hoidke silma peal meie tulevastel artiklitel, mis käsitlevad ESNI staatust ning HTTPS-i ja TLS.
Järeldus
Kokkuvõtteks võib öelda, et SNI-ga saate hostida ühes serveris miljoneid HTTPS-i veebisaite. Sõltuvalt teie konkreetsest juhtumist võib SAN-sertifikaat teie jaoks siiski paremini töötada. SNI-dega seotud eraelu puutumatuse probleemid on endiselt olemas, kuigi ka ESNI-ga on olemas potentsiaalne lahendus. Igal juhul, kasutades ühte neist kahest meetodist või nende kombinatsiooni, saate minimaalse vaevaga hõlpsalt rakendada kõigi oma veebisaitide virtuaalset hostimist.
Kui teil on SNI kohta veel küsimusi või kui te ei tea, kuidas valida SAN-ide ja SNI-de vahel, vastame alati hea meelega kõigile klientide küsimustele nende kohta PKI vajadustele. Kirjutage meile lihtsalt aadressil support@ssl.com ja ekspert aitab teid.
