esittely
Virtual Hosting on käytäntö palvella useita verkkosivustoja sama palvelin. Vaikka se on nykyään normi, tämä ei ollut mahdollista HTTP: n alkuaikoina (versiot ennen 1.1).
Alun perin palvelin pystyi isännöimään useita verkkosivustoja samassa koneessa (ts. Samalla IP-osoitteella) edellyttäen, että jokaiselle verkkosivustolle oli osoitettu oma portti. Tämä ei ollut ihanteellinen ratkaisu, koska selaimet ovat oletusportissa 80 HTTP: lle, paitsi jos käyttäjä määrittelee toisen. Tämän seurauksena useimmat verkkosivustojen omistajat valitsivat erillisen palvelimen välttääkseen riskin, että käyttäjät eivät muista oikeaa porttinumeroa ja päätyvät toiselle verkkosivustolle.
Siitä huolimatta, että enemmän käyttäjiä liittyi verkkoon ja lisää verkkolaitteita alkoi näkyä verkossa, käytettävissä olevien IP-osoitteiden määrä alkoi vähentyä hälyttävästi. Tämä odotettu ehtyminen, joka tunnetaan nimellä IPv4-osoitealueen loppu, on saanut teollisuuden suunnittelemaan ja toteuttamaan erilaisia vastatoimenpiteitä, kuten IPv6 (IPv4: n seuraaja), joka voi tukea enemmän osoitteita kuin me koskaan tarvitsemme. Valitettavasti, vaikka IPv6 on toteuttamiskelpoinen ratkaisu, sen käyttöönotto on ollut melko hidasta. Mukaan Googlen IPv6-tilastot, tämän kirjoituksen aikaan vain noin 25% Internet-laitteista on käytössä IPv6: n kautta.
Virtuaalinen isännöinti toteutettiin myös väsymysongelman varhaisena lieventämiseksi käyttöönotettaessa Host otsikko HTTP 1.1: ssä. HTTP 1.1: n kautta kommunikoivat selaimet pystyivät nyt muodostamaan yhteyden palvelimen porttiin 80 ja sisällytä verkkotunnus (esim www.ssl.com) verkkosivustosta, jota he halusivat käydä Host header. Riippumatta siitä, kuinka monta sivua palvelin isännöi samassa portissa, se voisi käyttää näitä tietoja oikean verkkosivuston tunnistamiseen ja sen sisällön palauttamiseen.
HTTPS ja virtuaalimajoitus
Lukuisat julkaistut raportit verkon haavoittuvuuksista ja hyökkäyksistä web-käyttäjiä vastaan ovat kuitenkin motivoineet alaa aloita siirtyminen epävarmasta HTTP: stä turvallisempaan vaihtoehtoiseen HTTPS: ään. Laaja hyväksyminen HTTPS on parantanut käyttäjien yleistä turvallisuutta. Sen lisäparannukset ovat kuitenkin lisänneet verkkoviestinnän yleistä monimutkaisuutta.
Periaatteessa HTTPS on melko samanlainen kuin HTTP, paitsi että selainten ja palvelimien välinen HTTPS-yhteys on salattu. Lyhyesti sanottuna HTTPS vaatii palvelimia toimittamaan selaimille voimassa olevan SSL-varmenteen, jonka on myöntänyt julkisesti luotettava todistuksen myöntäjä (CA), kuten SSL.com. Selain voi sitten käyttää varmenteessa olevaa julkista avainta luoda salattu tietoliikennekanava palvelimen kanssa. Lisäksi tietylle verkkotunnukselle annetaan varmenne, jota selain tarkistaa vastaavuuden verkkotunnuksen kanssa, johon käyttäjä halusi käydä. Niinpä riippumatta siitä, kuinka monta verkkosivustoa palvelin isännöi, selaimet odottavat löytävänsä kelvollisen SSL-varmenteen pyydetylle verkkosivustolle.
Huomaavainen lukija saattaa jo aistia ongelman: selain vaatii oikean verkkosivuston varmenteen salatun kanavan luomiseksi ja Host otsikko, kun taas palvelin tarvitsee Host otsikko oikean sivuston varmenteen löytämiseksi. Tämä on klassinen kana-muna-ongelma.
On ilmeistä, että virtuaalinen isäntä sellaisena kuin se oli suunniteltu HTTP: lle, ei toimi HTTPS: llä, koska suojausohjeet estävät selaimia lähettämästä Host tiedot palvelimelle. Siitä huolimatta, kun IPv4-uupumusongelma on edelleen ratkaisematta ja teollisuuden jatkuvasti lisääntyvä pilviteknologia (joka vaatii kuormituksen tasapainottamista ja useita epäonnistuneita backend-palvelimia), virtuaalinen isännöinti on edelleen välttämätöntä.
Entä multi-domain-sertifikaatit?
Ehdotettu ratkaisu tähän ongelmaan on usean verkkotunnuksen tai SAN-sertifikaatit. Yksi SAN-varmenne voi suojata satoja eri verkkotunnuksia, ja selaimet eivät valittaa, jos he löytävät verkkotunnuksen, jolla yrität käydä, SAN-varmenteen toimialueluettelosta. Kun salattu kanava on määritetty, selain voi lähettää sen Host otsikko palvelimelle ja jatka eteenpäin kuten muissakin tapauksissa. Tämä on hieno idea, joka käyttää jo olemassa olevaa ja saatavilla olevaa tekniikkaa, mutta samat mekanismit, jotka takaavat SAN-varmenteiden turvallisuuden, ovat myös esittäneet muutamia mahdollisesti ei-toivottuja sivuvaikutuksia:
SAN-sertifikaatit ovat hieno työkalu useiden verkkotunnusten turvaamiseksi, jotka ovat sama yhteisö (henkilö, yritys tai organisaatio), mutta niitä on jonkin verran epäkäytännöllistä käyttää jaetussa isännöinnissä; Aina kun uusi verkkotunnus on valmis lisäämään varmenteeseen tai poistamaan siitä, CA: n on annettava uusi varmenne, jossa on viimeisin verkkotunnusluettelo, ja se on siirrettävä uudelleen kaikille verkkotunnuksille.
Lisäksi SAN-varmenteita voidaan myöntää vain Organisaatio validoitu (OV) tai laajennettu validoitu (EV) if kaikki verkkotunnukset kuuluvat samaan organisaatioon. Nämä validointitasot viittaavat varmentajan todentaman mahdollisen varmenteen omistajan tietojen määrä ja tyypit ennen todistuksen myöntämistä. On osoitettu, että mitä korkeampi validointitaso on, sitä enemmän käyttäjiä luottaa verkkosivustoon, ja käyttäjien luottamus voi vaikuttaa tuotemerkin tunnustamiseen ja muuntoprosentteihin.
Lopuksi, jaetussa web-hosting-ympäristössä on melko yleistä, että yritys jakaa palvelimen muiden yritysten tai organisaatioiden kanssa (jopa kilpailijoidensa kanssa). Koska SAN-sertifikaattien verkkotunnukset on listattu julkisesti, yritysten omistajat saattavat olla haluttomia jakamaan samaa varmennetta kolmansien osapuolien kanssa.
Vaikka SAN-varmenteet ovat tehokkaita ja monipuolisia työkaluja, joissa on lukemattomia sovelluksia, nämä asiat ovat motivoineet Internet-standardien hallintoelintä IETF: ää etsimään paremmin sovitettuja lähestymistapoja virtuaalisesti isännöityjen HTTPS-verkkosivustojen erityisongelmaan.
Palvelimen nimen ilmoittaminen pelastamiselle
Ratkaisu toteutettiin Palvelimen nimen ilmaisin (SNI) laajennus TLS protokolla (HTTPS: n osa, joka käsittelee salausta).
SNI antaa selaimille mahdollisuuden määrittää verkkotunnuksen nimi, johon he haluavat muodostaa yhteyden TLS kädenpuristus (alkuperäinen varmenneneuvottelu palvelimen kanssa). Seurauksena on, että verkkosivustot voivat käyttää omia SSL-varmenteitaan samalla, kun ne ovat edelleen jaetussa IP-osoitteessa ja portissa, koska HTTPS-palvelimet voivat käyttää SNI-tietoja tunnistamaan yhteyden muodostamiseen tarvittavan varmenneketjun.
Myöhemmin, kun salattu tietoliikennekanava on määritetty, selain voi jatkaa sisällyttämällä verkkosivuston verkkotunnuksen Host otsikkoa ja jatka normaalisti. Pohjimmiltaan SNI suorittaa saman toiminnon kuin HTTP Host otsikko salatun yhteyden luomisen aikana.
Tämä yksinkertainen temppu antoi vihdoin palvelimille mahdollisuuden isännöidä useita HTTPS-verkkosivustoja samassa portissa. Kuten useimmissa Internet-tekniikoissa, SNI: llä on kuitenkin joitain rajoituksia.
SNI-tukihuoli
Vaikka SNI on melko kypsä siitä lähtien, kun se laadittiin ensimmäisen kerran vuonna 1999, on vielä muutamia vanhoja selaimia (IE Windows XP: ssä) ja käyttöjärjestelmiä (Android-versiot <= 2.3), jotka eivät tue sitä. Katso kattava luettelo SNI: tä tukevista selaimista ja käyttöjärjestelmistä katsomalla tämä taulukko.
Vaikka sellaisten selainten markkinaosuudet, jotka eivät tue SNI: tä (ja laajentaen tämän tapahtumisen esiintymiä), ovat pienet verrattuna nykyaikaisiin selaimiin, jos selain ei tunnista SNI: tä, se palaa takaisin oletus SSL-sertifikaattiin ja tuottaa mahdollisesti yleisnimen epäsovitusvirhe.
Monet yritykset, kuten Google, ottavat käyttöön SNI: n sitä tukeville asiakkaille ja palautuvat SAN-varmenteisiin harvinaisissa tapauksissa, joissa sitä ei ole. Tämän kysymyksen odotetaan luonnollisesti vähenevän, kun yhä useammat käyttäjät ja yritysomistajat päivittävät järjestelmiään nykyaikaiseen tekniikkaan.
SNI: n tietosuojahuolet
Nykyinen vakaa versio TLS (versio 1.2) lähettää kädenpuristuksen alkuosan ja laajennuksella SNI-tiedot salaamattomana. Näin ollen verkkohyökkääjä voi löytää käyttäjän verkkohistorian huolimatta siitä, että verkkoviestintä itse on täysin salattu.
Eri pilvipalvelujen tarjoajat, kuten Amazon tai Google, ovat sallineet (likaisen) kiertotavan, joka tunnetaan nimellä verkkotunnuksen eturintama. Verkkotunnuksen etuosa voi estää verkkohistorian paljastamisen, koska se hämmentää SNI-tietoja käyttämällä pilvipalveluntarjoajan isäntänimeä TLS neuvottelu ja kohdesivusto HTTP-otsikossa. Tämä menetelmä ei kuitenkaan ole enää elinkelpoinen, koska Google ja Amazon ovat julkisesti ilmoittaneet verkkotunnuksen eturintaman tuki poistettu käytöstä heidän palveluksessaan huhtikuusta 2018.
Onneksi järjestelmällisemmäksi ratkaisuksi on ehdotettu kokeellinen luonnos yksityiskohtaisesti Salattu SNI (ESNI) laajennus uusimmalle TLS versio, 1.3. ESNI salaa SNI-tiedot ja vähentää siten kaikkia yksityisyyttä koskevia huolenaiheita. Valitettavasti, TLS 1.3 teollisuus ei ole vielä laajalti omaksunut, vaikka TLS 1.3 on hitaasti tulossa tosiasialliseksi verkon tietoturvaprotokollaksi. Pidä silmällä tulevia artikkeleita meiltä, jotka koskevat ESNI-tilaa ja HTTPS: n ja TLS.
Yhteenveto
Yhteenvetona voidaan todeta, että SNI: n avulla voit isännöidä miljoonia HTTPS-verkkosivustoja yhdellä palvelimella. SAN-sertifikaatti saattaa kuitenkin toimia sinun tapauksestasi paremmin. SNI: n yksityisyyden suojaan liittyvät ongelmat ovat edelleen olemassa, vaikka ESNI: n kanssa on olemassa myös potentiaalinen ratkaisu. Joka tapauksessa käyttämällä yhtä tai näiden kahden menetelmän yhdistelmää, voit helposti toteuttaa virtuaalisen isännöinnin kaikille verkkosivustoillesi pienellä vaivalla.
Jos sinulla on lisää kysymyksiä SNI: stä tai et tiedä miten valita SAN: t ja SNI, vastaamme aina mielellämme kaikkiin asiakkaidemme kysymyksiin heidän PKI tarvitsee. Pudota meille sähköpostia osoitteessa support@ssl.com ja asiantuntija auttaa sinua.
