Indikace názvu serveru

Aktuální verze stránky ještě nebyla zkontrolována zkušenými přispěvateli a může se výrazně lišit od verze recenzované 5. října 2020; kontroly vyžadují 10 úprav .

Server Name Indication ( SNI ) je rozšířením počítačového protokolu TLS [1] , které umožňuje klientům uvést jméno hostitele , ke kterému se chtějí připojit během procesu handshake. To umožňuje serveru poskytovat více certifikátů na stejné IP adrese a TCP portu, a proto umožňuje více zabezpečeným ( HTTPS- ) webům (nebo jiným službám přes TLS) pracovat na stejné IP adrese bez použití stejného certifikátu. . To je ekvivalentní funkci sdíleného hostování na základě názvu z HTTP/1.1. Požadovaný název hostitele není zašifrován [2] , což umožňuje útočníkovi jej zachytit.

Praktické použití SNI vyžaduje, aby drtivá většina uživatelů používala prohlížeče , které tuto funkci podporují. Uživatelé, jejichž prohlížeče nepodporují SNI, obdrží výchozí certifikát (závislý na implementaci, obvykle první v seznamu), a tedy chyba certifikátu, pokud server není vybaven zástupným certifikátem a neobsahuje název webu požadovaný klientem. .

Od podzimu 2018 probíhají experimenty s implementací Encrypted SNI [3] z protokolu TLS 1.3, který zašifruje název požadovaného webu pomocí veřejného klíče webu získaného ze systému jmen DNS [4] [5 ] [6] [7] .

Pozadí problému

Během vytváření připojení TLS klient požaduje digitální certifikát z webového serveru; po odeslání certifikátu serverem klient zkontroluje jeho platnost a porovná jméno, se kterým se pokusil připojit k serveru, se jmény obsaženými v certifikátu. Pokud je porovnání úspěšné, spojení se uskuteční v šifrovaném režimu. Pokud nebudou nalezeny žádné shody, může být uživatel varován o neshodě a připojení je přerušeno, protože neshoda může znamenat pokus o útok typu man-in-the-middle . Některé aplikace však umožňují uživateli ignorovat varování, aby pokračoval v připojení, a ponechávají na uživateli, zda certifikátu důvěřuje a tím se připojí k webu.

Může však být obtížné – nebo dokonce nemožné, kvůli nedostatku předem připraveného úplného seznamu všech jmen – získat jediný certifikát, který pokrývá všechna jména, za která bude server zodpovědný. Server odpovědný za více názvů hostitelů bude pravděpodobně muset předložit různé certifikáty pro každý název hostitele (nebo malou skupinu názvů hostitelů). Od roku 2005 CAcert experimentuje s různými metodami využití TLS na virtuálních serverech [8] . Většina experimentů je neuspokojivá a nepraktická. SubjectAltName lze například použít k uložení více domén řízených stejnou osobou [9] do jednoho certifikátu. Tyto „jednotné certifikáty“ je nutné znovu vydat pokaždé, když se změní seznam domén.

Sdílený hosting na základě názvu vám umožňuje hostovat více názvů hostitelů na stejném serveru (obvykle webovém serveru) na stejné IP adrese. K dosažení tohoto cíle server používá název hostitele zadaný klientem jako součást protokolu (pro HTTP je název uveden v hlavičce hostitele ). Při použití HTTPS však k navázání spojení TLS dojde dříve, než server uvidí jakékoli záhlaví HTTP. Server proto nemůže použít informace v hlavičce hostitele HTTP k rozhodnutí, který certifikát bude reprezentovat, a proto lze na stejné IP adrese obsluhovat pouze jména zapsaná ve stejném certifikátu.

V praxi to znamená, že HTTPS server může obsluhovat pouze jednu doménu (nebo malou skupinu domén) na IP adresu pro bezpečné a efektivní procházení. Přidělení samostatné IP adresy pro každou stránku zvyšuje náklady na hosting, protože žádosti o IP adresy musí být odůvodněny u regionálního internetového registrátora a adresy IPv4 jsou již vyčerpány . V důsledku toho mnoho webových stránek nemůže ve skutečnosti používat zabezpečený protokol při používání IPv4. Adresní prostor IPv6 není vyčerpán, takže webů obsluhovaných přes IPv6 se tento problém netýká.

Blokování ESNI

Od srpna 2020 je v Číně blokován provoz ESNI a TLSv1.3 [10] .

Od října 2020 a dříve v Rusku začali poskytovatelé také blokovat provoz ESNI, což v konečném důsledku znepřístupňuje uživatelům běžné a nezakázané stránky, protože neexistují žádné platné zákony, které by tuto technologii blokovaly [11] . Prvními poskytovateli blokujícími ESNI byl Rostelecom a poté jeho dceřiná společnost OOO T2 RTK Holding (ochranná známka Tele2 Russia).

Poznámky

  1. "Indikace názvu serveru 889" . RFC  3546
  2. Indikace názvu serveru TLS . Pavlův deník . Získáno 13. listopadu 2015. Archivováno z originálu 12. srpna 2016.
  3. draft-ietf-tls-esni-07 – Označení názvu šifrovaného serveru pro TLS 1.3
  4. Ghedini, Alessandro . Zašifrujte nebo ztratíte: jak funguje šifrované SNI  , blog Cloudflare (  24. září 2018). Archivováno z originálu 24. září 2018. Staženo 19. ledna 2019. ( [1] Archivováno 19. ledna 2019 na Wayback Machine )
  5. Encrypted SNI přichází na Firefox Nightly  , blog Mozilla (  18. října 2018). Archivováno 24. března 2020. Staženo 19. ledna 2019. ( [2] Archivováno 20. ledna 2019 na Wayback Machine )
  6. ESNI: Upgrade na ochranu soukromí na HTTPS . Blog EFF Deep Links . Staženo 19. ledna 2019. Archivováno z originálu 18. května 2019.
  7. Nepropadejte panice ohledně frontingu domény, oprava SNI se dostává hackery , The Register  (17. července 2018). Archivováno z originálu 26. srpna 2018. Staženo 10. října 2018.
  8. VhostTaskForce - CAcert Wiki . wiki.cacert.org. Staženo 19. ledna 2019. Archivováno z originálu 31. prosince 2018.
  9. Co je certifikát SSL pro více domén (UCC)? | Certifikáty SSL - Nápověda GoDaddy IN . www.godaddy.com. Datum přístupu: 19. ledna 2019. Archivováno z originálu 19. ledna 2019.
  10. Catalin Cimpanu. Čína nyní blokuje veškerý šifrovaný provoz HTTPS, který používá TLS 1.3 a ESNI  . ZDNet . Získáno 29. října 2020. Archivováno z originálu dne 9. srpna 2020.
  11. Proč Rostelecom blokuje provoz ESNI? . Habr Otázky a odpovědi - otázky a odpovědi . Získáno 29. října 2020. Archivováno z originálu dne 29. ledna 2021.