Server Name Indication ( SNI ) er en udvidelse af TLS [1] -computerprotokollen, der gør det muligt for klienter at angive navnet på den vært , de ønsker at oprette forbindelse til under handshake-processen. Dette gør det muligt for serveren at levere flere certifikater på den samme IP-adresse og TCP-port og tillader derfor flere sikre ( HTTPS- ) websteder (eller andre tjenester over TLS) at operere på den samme IP-adresse uden overhovedet at bruge det samme certifikat. . Dette svarer til den navnebaserede delte hosting-funktion fra HTTP/1.1. Det anmodede værtsnavn er ikke krypteret [2], som gør det muligt for en angriber at opsnappe det.
Praktisk brug af SNI kræver, at langt de fleste brugere bruger browsere , der understøtter denne funktion. Brugere, hvis browsere ikke understøtter SNI, vil modtage et standardcertifikat (implementeringsafhængigt, normalt det første på listen) og dermed en certifikatfejl, hvis serveren ikke er udstyret med et wildcard-certifikat og ikke indeholder det webstedsnavn, som klienten anmoder om. .
Siden efteråret 2018 er der blevet udført eksperimenter med at implementere Encrypted SNI [3] fra TLS 1.3-protokollen, som krypterer navnet på det anmodede websted ved hjælp af webstedets offentlige nøgle hentet fra DNS -navnesystemet [4] [5 ] [6] [7] .
Under oprettelsen af en TLS-forbindelse anmoder klienten om et digitalt certifikat fra webserveren; efter at serveren har sendt certifikatet, kontrollerer klienten dets gyldighed og sammenligner det navn, som den forsøgte at oprette forbindelse til serveren med, med navnene i certifikatet. Hvis sammenligningen lykkes, oprettes forbindelsen i krypteret tilstand. Hvis der ikke findes nogen matches, kan brugeren blive advaret om uoverensstemmelsen, og forbindelsen afbrydes, da uoverensstemmelsen kan indikere et forsøg på man-in-the-middle-angreb . Nogle applikationer giver dog brugeren mulighed for at ignorere advarslen om at fortsætte forbindelsen, hvilket overlader det til brugeren at stole på certifikatet og dermed oprette forbindelse til webstedet.
Det kan dog være svært – eller endda umuligt, på grund af manglen på en komplet liste over alle navne på forhånd – at få et enkelt certifikat, der dækker alle de navne, som serveren vil være ansvarlig for. En server, der er ansvarlig for flere værtsnavne, skal sandsynligvis præsentere forskellige certifikater for hvert værtsnavn (eller en lille gruppe værtsnavne). Siden 2005 har CAcert eksperimenteret med forskellige metoder til at bruge TLS på virtuelle servere [8] . De fleste af eksperimenterne er utilfredsstillende og upraktiske. SubjectAltName kan f.eks. bruges til at gemme flere domæner kontrolleret af den samme person [9] i et enkelt certifikat. Disse "ensartede certifikater" skal genudstedes, hver gang listen over domæner ændres.
Navnebaseret delt hosting giver dig mulighed for at hoste flere værtsnavne på den samme server (normalt en webserver) på den samme IP-adresse. For at opnå dette bruger serveren det værtsnavn, som klienten har leveret som en del af protokollen (for HTTP angives navnet i Host-headeren ). Men når du bruger HTTPS, sker TLS-håndtrykket, før serveren ser nogen HTTP-headere. Derfor kan serveren ikke bruge informationen i HTTP-værtsheaderen til at beslutte, hvilket certifikat der skal repræsenteres, og derfor kan kun navne skrevet i det samme certifikat serveres på den samme IP-adresse.
I praksis betyder det, at en HTTPS-server kun kan betjene et domæne (eller en lille gruppe domæner) pr. IP-adresse for sikker og effektiv browsing. Tildeling af en separat IP-adresse til hvert websted øger omkostningerne ved hosting, da anmodninger om IP-adresser skal begrundes med en regional internetregistrator , og IPv4-adresser er allerede opbrugt . Som et resultat kan mange websteder faktisk ikke bruge den sikre protokol, når de bruger IPv4. IPv6 -adresserummet er ikke opbrugt, så websteder, der serveres over IPv6, påvirkes ikke af dette problem.
Siden august 2020 har ESNI- og TLSv1.3-trafik været blokeret i Kina [10] .
Fra oktober 2020 og tidligere i Rusland begyndte udbydere også at blokere ESNI-trafik, hvilket i sidste ende gør almindelige og ikke forbudte websteder utilgængelige for brugere, da der ikke er nogen gældende love til at blokere denne teknologi [11] . De første udbydere, der blokerede ESNI, var Rostelecom og derefter dets datterselskab OOO T2 RTK Holding (varemærke Tele2 Rusland).