A kiszolgálónév-jelzés ( SNI ) a TLS [1] számítógépes protokoll kiterjesztése, amely lehetővé teszi az ügyfelek számára , hogy jelezzék annak a gazdagépnek a nevét , amelyhez csatlakozni kívánnak a kézfogási folyamat során. Ez lehetővé teszi a szerver számára, hogy több tanúsítványt biztosítson ugyanazon az IP-címen és TCP-porton, és ezáltal több biztonságos ( HTTS- ) webhely (vagy egyéb TLS-en keresztüli szolgáltatás ) működjön ugyanazon az IP-címen anélkül, hogy ugyanazt a tanúsítványt egyáltalán használná. . Ez megegyezik a HTTP/1.1 névalapú megosztott tárhely szolgáltatásával. A kért gazdagépnév nincs titkosítva [2] , így a támadó elkaphatja azt.
Az SNI gyakorlati használatához a felhasználók túlnyomó többségének olyan böngészőket kell használnia , amelyek támogatják ezt a funkciót. Azok a felhasználók, akiknek a böngészője nem támogatja az SNI-t, alapértelmezett tanúsítványt kap (megvalósítástól függő, általában a listában az elsőt), és ebből eredően tanúsítványhibát, ha a szerver nincs felszerelve helyettesítő karakter tanúsítvánnyal , és nem tartalmazza az ügyfél által kért webhelynevet. .
2018 ősze óta kísérletek folynak az Encrypted SNI [3] TLS 1.3 protokollból való megvalósítására, amely a DNS névrendszerből nyert webhely nyilvános kulcsával titkosítja a kért oldal nevét [4] [5 ] [6] [7] .
A TLS kapcsolat létrehozása során a kliens digitális tanúsítványt kér a webszervertől; miután a szerver elküldte a tanúsítványt, a kliens ellenőrzi annak érvényességét, és összehasonlítja azt a nevet, amellyel a szerverhez próbált csatlakozni a tanúsítványban szereplő nevekkel. Ha az összehasonlítás sikeres, a kapcsolat titkosított módban jön létre. Ha nem található egyezés, a felhasználó figyelmeztetést kaphat az eltérésre, és a kapcsolat megszakad, mivel az eltérés egy ember a középső támadásra tett kísérletet jelezhet . Egyes alkalmazások azonban lehetővé teszik a felhasználó számára, hogy figyelmen kívül hagyja a figyelmeztetést a kapcsolat folytatására, így a felhasználóra bízza a tanúsítványt, és így csatlakozik a webhelyhez.
Mindazonáltal nehéz lehet – vagy akár lehetetlen az összes név előre elkészített teljes listája hiánya miatt – egyetlen tanúsítvány beszerzése, amely lefedi az összes nevet, amelyért a szerver felelős lesz. A több gazdagépnévért felelős kiszolgálónak valószínűleg minden gazdagépnévhez (vagy gazdagépnevek egy kis csoportjához) különböző tanúsítványokat kell bemutatnia. A CAcert 2005 óta kísérletezik a TLS virtuális szervereken való használatának különféle módszereivel [8] . A legtöbb kísérlet nem kielégítő és nem praktikus. Például a subjectAltName használható több, ugyanazon személy által vezérelt tartomány [9] egyetlen tanúsítványban való tárolására. Ezeket az „egységes tanúsítványokat” minden alkalommal újra ki kell adni, amikor a tartományok listája módosul.
A névalapú megosztott tárhely lehetővé teszi több gazdagépnév tárolását ugyanazon a szerveren (általában webszerveren) ugyanazon az IP-címen. Ennek eléréséhez a szerver az ügyfél által a protokoll részeként megadott gazdagépnevet használja (HTTP esetén a név a Host fejlécben van megadva ). HTTPS használatakor azonban a TLS-kézfogás még azelőtt megtörténik, hogy a szerver HTTP-fejléceket látna. Ezért a szerver nem tudja felhasználni a HTTP gazdagép fejlécében található információkat annak eldöntésére, hogy melyik tanúsítványt képviselje, és így csak az azonos tanúsítványba írt nevek szolgálhatnak ki ugyanazon az IP-címen.
Ez a gyakorlatban azt jelenti, hogy egy HTTPS-szerver IP-címenként csak egy tartományt (vagy tartományok egy kis csoportját) tud kiszolgálni a biztonságos és hatékony böngészés érdekében. Az egyes webhelyekhez külön IP-cím hozzárendelése növeli a tárhely költségeit, mivel az IP-címek kérését egy regionális internetes regisztrátorral kell megindokolni , és az IPv4-címek már kimerültek . Ennek eredményeként sok webhely nem tudja használni a biztonságos protokollt az IPv4 használatakor. Az IPv6 - címtér nem merült ki, így az IPv6-on keresztül kiszolgált webhelyeket nem érinti ez a probléma.
2020 augusztusa óta az ESNI és a TLSv1.3 forgalma blokkolva van Kínában [10] .
2020 októberétől és korábban Oroszországban is megkezdték a szolgáltatók az ESNI forgalom blokkolását, ami végső soron elérhetetlenné teszi a rendszeres és nem tiltott webhelyeket a felhasználók számára, tekintettel arra, hogy nincsenek hatályos törvények a technológia blokkolására [11] . Az ESNI-t először blokkoló szolgáltatók a Rostelecom, majd leányvállalata, az OOO T2 RTK Holding (Tele2 Russia védjegy) voltak.