Servernamnsindikation

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 5 oktober 2020; kontroller kräver 10 redigeringar .

Server Name Indication ( SNI ) är en förlängning av datorprotokollet TLS [1] som tillåter klienter att ange namnet på den värd som de vill ansluta till under handskakningsprocessen. Detta gör att servern kan tillhandahålla flera certifikat på samma IP-adress och TCP-port och tillåter därför flera säkra ( HTTPS- ) webbplatser (eller andra tjänster över TLS) att arbeta på samma IP-adress utan att använda samma certifikat alls. . Detta motsvarar den namnbaserade delade värdfunktionen från HTTP/1.1. Det begärda värdnamnet är inte krypterat [2] , vilket gör att en angripare kan fånga upp det.

Praktisk användning av SNI kräver att de allra flesta användare använder webbläsare som stöder denna funktion. Användare vars webbläsare inte stöder SNI kommer att få ett standardcertifikat (implementeringsberoende, vanligtvis det första i listan) och därmed ett certifikatfel om servern inte är utrustad med ett jokerteckencertifikat och inte innehåller webbplatsnamnet som begärts av klienten .

Sedan hösten 2018 har experiment genomförts för att implementera Encrypted SNI [3] från TLS 1.3-protokollet, som krypterar namnet på den begärda webbplatsen med hjälp av webbplatsens publika nyckel som erhålls från DNS- namnsystemet [4] [5 ] [6] [7] .

Bakgrund till problemet

Under skapandet av en TLS-anslutning begär klienten ett digitalt certifikat från webbservern; efter att servern har skickat certifikatet kontrollerar klienten dess giltighet och jämför namnet som den försökte ansluta till servern med med namnen i certifikatet. Om jämförelsen lyckas görs anslutningen i krypterat läge. Om inga matchningar hittas kan användaren bli varnad för felmatchningen och anslutningen avbryts, eftersom felmatchningen kan indikera ett försök till man-i-mitten-attack . Vissa applikationer tillåter dock att användaren ignorerar varningen för att fortsätta anslutningen, vilket gör det upp till användaren att lita på certifikatet och därmed ansluta till webbplatsen.

Det kan dock vara svårt – eller till och med omöjligt, på grund av avsaknaden av en komplett lista över alla namn – att få ett enda certifikat som täcker alla namn som servern kommer att ansvara för. En server som ansvarar för flera värdnamn kommer förmodligen att behöva presentera olika certifikat för varje värdnamn (eller en liten grupp värdnamn). Sedan 2005 har CAcert experimenterat med olika metoder för att använda TLS på virtuella servrar [8] . De flesta av experimenten är otillfredsställande och opraktiska. Till exempel kan subjectAltName användas för att lagra flera domäner som kontrolleras av samma person [9] i ett enda certifikat. Dessa "enhetliga certifikat" måste utfärdas på nytt varje gång listan över domäner ändras.

Namnbaserad delad hosting låter dig vara värd för flera värdnamn på samma server (vanligtvis en webbserver) på samma IP-adress. För att uppnå detta använder servern värdnamnet som tillhandahålls av klienten som en del av protokollet (för HTTP anges namnet i värdhuvudet ). Men när du använder HTTPS sker TLS-handskakningen innan servern ser några HTTP-rubriker. Därför kan servern inte använda informationen i HTTP-värdhuvudet för att bestämma vilket certifikat som ska representeras, och därför kan endast namn skrivna i samma certifikat serveras på samma IP-adress.

I praktiken innebär detta att en HTTPS-server endast kan betjäna en domän (eller en liten grupp av domäner) per IP-adress för säker och effektiv surfning. Att tilldela en separat IP-adress för varje webbplats ökar kostnaden för hosting, eftersom förfrågningar om IP-adresser måste motiveras med en regional Internet-registrator och IPv4-adresser är redan slut . Som ett resultat kan många webbplatser faktiskt inte använda det säkra protokollet när de använder IPv4. IPv6- adressutrymmet är inte uttömt, så webbplatser som serveras över IPv6 påverkas inte av det här problemet.

ESNI blockering

Sedan augusti 2020 har ESNI- och TLSv1.3-trafik varit blockerad i Kina [10] .

Från oktober 2020 och tidigare i Ryssland började leverantörer också blockera ESNI-trafik, vilket i slutändan gör vanliga och inte förbjudna webbplatser otillgängliga för användare, med tanke på att det inte finns några lagar i kraft för att blockera denna teknik [11] . De första leverantörerna som blockerade ESNI var Rostelecom och sedan dess dotterbolag OOO T2 RTK Holding (varumärke Tele2 Ryssland).

Anteckningar

  1. "Servernamnsindikering 889" . RFC  3546
  2. TLS-servernamnindikation . Pauls tidning . Hämtad 13 november 2015. Arkiverad från originalet 12 augusti 2016.
  3. draft-ietf-tls-esni-07 - Krypterad servernamnsindikation för TLS 1.3
  4. Ghedini, Alessandro . Kryptera det eller förlora det: hur krypterad SNI fungerar  , Cloudflare-bloggen (  24 september 2018). Arkiverad från originalet den 24 september 2018. Hämtad 19 januari 2019. ( [1] Arkiverad 19 januari 2019 på Wayback Machine )
  5. Encrypted SNI Comes to Firefox Nightly  , Mozilla-bloggen (  18 oktober 2018). Arkiverad 24 mars 2020. Hämtad 19 januari 2019. ( [2] Arkiverad 20 januari 2019 på Wayback Machine )
  6. ESNI: A Privacy-Protecting Upgrade to HTTPS . EFF Deep Links Blogg . Hämtad 19 januari 2019. Arkiverad från originalet 18 maj 2019.
  7. ↑ Få inte panik om domänfronting, en SNI-fix hackas ut , The Register  (17 juli 2018). Arkiverad från originalet den 26 augusti 2018. Hämtad 10 oktober 2018.
  8. VhostTaskForce - CAcert Wiki . wiki.cacert.org. Hämtad 19 januari 2019. Arkiverad från originalet 31 december 2018.
  9. Vad är ett SSL-certifikat med flera domäner (UCC)? | SSL-certifikat - GoDaddy Hjälp IN . www.godaddy.com. Datum för åtkomst: 19 januari 2019. Arkiverad från originalet 19 januari 2019.
  10. Catalin Cimpanu. Kina blockerar nu all krypterad HTTPS-trafik som använder TLS 1.3 och ESNI  . ZDNet . Hämtad 29 oktober 2020. Arkiverad från originalet 9 augusti 2020.
  11. Varför blockerar Rostelecom ESNI-trafik? . Habr Q&A - frågor och svar . Hämtad 29 oktober 2020. Arkiverad från originalet 29 januari 2021.