Blog

Témata:

11. 5. 2026

Bezpečnost Kryptografie

SNI, ESNI/ECH a SSL inspekce

Základní nástroje pro analýzu komunikace a spojení vycházejí z technologií SSL inspekce a fingerprintů komunikačních partnerů. Příchod ECH ale znamená evoluci v ochraně soukromí uživatelů, včetně dopadů na tyto nástroje. Jak tomu ale rozumět?

SNI jako současná technologie

V současnosti se stále ještě používá SNI (Server Name Indication), která v rámci ClientHello sděluje cílový hostname. To přináší obrovskou výhodu, protože díky SNI každý server nemusí mít samostatnou IP adresu. A virtualizace tak obrovským způsobem šetří nejenom IP adresy, ale i náklady.

Jak funguje? V rámci ClientHello se posílá identifikace cílového serveru. Na základě uvedené informace cílový server dokáže zvolit odpovídající virtuální server a poskytnout relevantní klíčový materiál (certifikát). Tedy na jedné IP adrese mohou být desítky až stovky virtuálních serverů. Zároveň tato položka dovoluje různým serverům zajišťujícím SSL inspekci odpovídajícím způsobem ověřit, zda je adresa dotazovaného serveru akceptována organizační politikou nebo ne.

Proč je inspekce tak důležitá

Inspekce komunikace je dnes na hraničních bodech sítě jednou z nejsilnějších zbraní proti různé počítačové havěti, podvodům a dalším typům útoků, ohrožující provoz organizace. Správce za tuto síť má zodpovědnost. Bohužel, pokud nemáte nad sítí kontrolu, její údržba a řízení je téměř nemožné. Podobným způsobem fungují i kontrolní mechanismy antivirových produktů, internet providerů nebo na hranicích některých státních celků. I zde ale musí být určitý důvod pro analýzu. Tím může být ochrana počítače, ochrana sítě nebo ochrana národních zájmů. Mezi národní zájmy patří i potírání kriminality, proto v rozvinuté společnosti není možné jen tak někoho kontrolovat. V případě bezpečnostních složek pro to musí být odpovídající oprávnění, např. soudní příkaz. To ale záleží na konkrétní jurisdikci.

Příchod ESNI / ECH a rozdíly mezi nimi

ESNI (Encrypted SNI) nebo ještě lépe ECH (Encrypted Hello) přinášejí ochranu přenášených informací, každá technologie jiným způsobem. ESNI se považuje za překonané a v současnosti se objevuje podpora hlavně pro ECH. Jaké jsou ale mezi nimi rozdíly?

ESNI zajišťovalo pomocí šifrování pouze ochranu SNI jako jediného parametru. Zůstával zde viditelný seznam ciphersuites, různá rozšíření včetně ALPN a dovolil tak vytvářet fingerprinting TLS. To sice může být užitečné ve spolupráci s IDS/IPS systémy, jako ochranný mechanismus proti některým typům útoků. ESNI ale neřeší únik těchto metadat a jejich zneužitelnost. ECH naproti tomu řeší kompletní ochranu Client Hello. Ten je celý šifrován, v nešifrované části je jenom generický SNI, který slouží jako fallback a obsahuje minimální metadata. V šifrované části jsou veškeré ostatní informace, včetně dat používaných pro fingerprinting jako jsou ciphersuites a rozšíření typu ALPN. V takovém případě je tedy téměř nemožné tento metadata použít, případně je využít na ochranu síťové infrastruktury.

Použití ECH má své výhody a nevýhody, které záleží na architektuře použití. Mezi jedny z vlasností dvojího významu patří již zmiňované omezení schopnosti detekovat klientský stroj podle jeho metadat. To je možné použít pro identifikaci klientů, ale například také pro ochranu před botnety nebo dalšími metodami útočníků. Dalším problémem je omezení schopností inspekce TLS, který je jedním z potřebných nástrojů pro kontrolu provozu a dohledem nad přenosy v síti. Na jednu stranu tak tato technologie zvyšuje ochranu soukromí, na druhou omezuje schopnosti správců chránit data a práci uživatelů. To má zásadní dopady na řízení bezpečnosti.

V případě nasazení ECH tak zbývá pouze několik metod. Jednak hodnocení důvěryhodnosti IP adres, které ale zcela selhává v případě CDN (Content Distributed Network), cloudového prostředí nebo dynamické adresace. Dále je možné použít vyhodnocování a relace k DNS dotazům, tedy behaviorální analýza. Mimo ECH je tu ale problém s metodami ochrany DNS dotazů, jako je DoH (DNS over HTTPS), DoS (DNS over SSL) nebo DoQ (DNS over QUIC). V případě jejich dostupnosti nemá správce šanci řídit síť. Použití SSL inspekce bude díky ECH omezeno, současné systémy budou potřebovat upgrade aby se s novou architekturou vypořádaly. Rozlišení běžného provozu díky chráněnému obsahu Client Hello (včetně fallback SNI) tak bude výpočetně náročnější. Poslední možností je sledování provozu, tedy dostupných dat o počtu paketů, jejich velikosti, časech komunikace. Tedy analýza metadat a chování, která má ale velké množství omezení a výsledky nebudou zcela přesné.

Jako nejrozumnější metoda se mi tak jeví forma SSL inspekce, spojená s paděláním ECH záznamu v DNS. V takovém okamžiku se klient připojí na inspekční server, který se na základě dotazu klient připojí ke zdrojovému serveru. Alternativou je možnost zcela ECH v organizacích zakázat s tím, že inspekční server povolí ECH až od inspekčního serveru. Spoléhat na fallback stránek hostovaných v cloudu je problematické. SNI záznam jde standardně na hlavní doménu, protože fallback spoléhá pouze na oznamované informace. To je ale pro správu a řízení sítě zcela nedostatečné.

Jak pracuje ESNI

Starší varianta ochrany, ESNI, využívá vygenerované klíče uložené v DNS pro úvodní inicializaci protokolu. Pro ukládání se používatl textový záznam _esni v rámci domény:

_esni.domain.tld TXT "BASE64_ENCODED_ESNI_CONFIG"

kde vlastní ESNI config v binární formě obsahuje následující strukturu dat:

struct { uint16 version; uint8 checksum[4]; KeyShareEntry { uint16 group; // např. X25519 opaque public_key }; CipherSuite cipher_suites[]; uint64 not_before; uint64 not_after; uint16 extensions; } ESNIKeys;

Na základě získaných klíčů se vytváří kryptogram, využívající domluvu na klíčích pomocí ECDH. Jeho tvorba postupuje následujícím způsobem. Vytvoří se ESNI extension, obsahující informace o klíčovém materiálu, který bude poskytnut na server.

ESNIExtension = { cipher_suite; key_share (client ephemeral publickey); record_digest; encrypted_sni (ciphertext); }

Dále se spočítá sdílený klíč a odvodí se jednotlivá tajemství tak, aby bylo možné šifrovat data. Některá z těchto tajemství se propisují do ESNI extenstion:

shared_secret = ECDH(ephemereal secret_key_klient, publickey_server) secret = HKDF-Extract(0, shared_secret) key = HKDF-Expand(secret, "esni key") nonce = HKDF-Expand(secret, "esni nonce") ciphertext = AEAD_Encrypt(key, nonce, SNI, associated_data)

Nakonec je možné zaslat informace o klíčovém materiálu na server. Ten na základě uvedených infromací může dešifrovat data a získat z ESNI odpovídající SNI:

ESNI payload = ephemeral_publickey_client || ciphertext

Proč bylo ESNI v krátké době nahrazeno ECH

Návrhy ESNI se objevily už v roce 2018 a bylo poprvé nasazeno okolo roku 2020, nikdy se ale nedostalo do stadia RFC. Důvodem pro vznik ESNI bylo nešifrované SNI, umožňující cenzuru a sledování. Tedy temná strana řízení provozu sítě. Bohužel se při pokusech ukázala nedostačnost návrhu, tedy příliš úzká ochrana. Od roku 2020 tedy docházel ke změnám v návrhu až do dnešní, podoby ECH. Od roku 2023 byly postupně standardizovány RFC 9320, RFC 9337 a RFC 9361, které popisují jak má ECH problém s ochranou před sledováním řešit.

Jak pracuje ECH

U ECH je situace od ESNI lehce odlišná. Tato technologie opustila využívání TXT záznamů, důvodem byly problémy s rozšiřitelností a verzováním. Proto se pro konfiguraci používají záznamy typu HTTPS (RR type 65) a SVCB (Service Binding). Příkladem takového záznamu může být napříkad:

domain.tld. HTTPS 1 . alpn="h2,h3" ech="BASE64_ENCODED_ECH_CONFIG"

V tomto záznamu je důležitá položka ech="BASE64". Ta obsahuje konfiguraci, která má strukturu:

ECHConfig = { version public_name max_name_length key_config { kem_id public_key cipher_suites config_id } }

Na začátku je nutné, aby server vygeneroval svůj privátní a veřejný klíč. Veřejný klíč /je uložen v DNS záznamu, privátní klíč neopouští server. Klient při inicializaci spojení vygeneruje svůj pár klíčů, kde veřejný poskytuje serveru a privátní si ponechává. Díky využití ECDH se tak mohou obě strany domluvit na sdíleném tajemství.

shared_secret = ECDH(ephemereal secret_key_klient, publickey_server) key = HKDF-Expand(secret, "ech key") nonce = HKDF-Expand(secret, "ech nonce") associated_data = outer ClientHello, config_id, encapsulated_key ciphertext = AEAD_Encrypt(key, nonce, ClientHelloInner, associated_data)

Následně se vytvoří hlavička spojení, kde je šifrované ECH následující formě. Případný útočník by tak neměl mít možnost vidět žádná relevantní data. Otázkou je, jaká adresa bude použita pro fallback (SNI) a zda nebude prováděna korelace DNS dotazů se spojením.

ECHCiphertext = (ephemereal public_key_klient, ciphertext )

Pokud je nainstalované OpenSSL 4.0, je možné použít přibližně následující postup. Ten počítá s použitím následující ciphersuite.

KEM : X25519 = 0x0020 KDF : HKDF-SHA256 = 0x0001 AEAD: AES-256-GCM = 0x0002

Postup:
mkdir -p /home/git cd /home/git git --clone https://github.com/defo-project/ech-dev-utils mkdir -p /home/git/ech openssl ech -public_name domain.tld -suite x25519,hkdf-sha256,aes256gcm -out /home/git/ech/domain.tld.pem.ech /home/git/ech-dev-utils/scripts/pem2rr.sh /home/git/ech/domain.tld.pem.ech

kde výstupem je řetězec BASE64_CONFIG. Ten je nutné následně zpracovat do formátu, použitelného do HTTSP záznamu.

ech-enabled-portal.domain.tld. 3600 IN HTTPS 1 . alpn="h2,h3" ech="BASE64_CONFIG"

Mimo uvedeného záznamu je nutné mít záznam odkazující se na IP adresu jak pro doménu nebo nějaký defaultní web server, tak pro ech-enabled-portal. V případě připojení na portál tak dojde k poskytnutí SNI odkazujícího se přímo na default server domény, přestože klient bude používat server odlišný.

Ostatní nastavení už závisí pouze na konfiguracích web serverů. Otázkou zde bude, jak řešit případné řízení přístupů v síti. Pro většinu systémů taková konfigurace postrádá smysl. Příkladem je zpravodajství a podobné weby. Na druhou situaci si dokáži představit weby, kde uvedené skrývání informací může mít význam.

ECH je dobrý sluha, ale špatný pán. Příliš benevolentní řízení nejenom že dokáže pustit do sítě návštěvy, o kterých nevíte. Ale bude možné skrze něj stejným způsobem exfiltrovat data. Proto bude nutné zvážit, kdy bude takové použití akceptovatelné a kdy bude nutné jej zakázat.

Reference:

Draft Encrypted Server Name Indication for TLS 1.3
Zdroj: https://ietf.org/
Good-bye ESNI, hello ECH!
Zdroj: https://blog.cloudflare.com/
RFC 9849 TLS Encrypted Client Hello
Zdroj: https://www.rfc-editor.org/
OpenSSL 4.0 Documentation
Zdroj: https://docs.openssl.org/
Quick set up guide for Encrypted Client Hello (ECH)
Zdroj: https://guardianproject.info/
GIT defo-project/ech-dev-utils
Zdroj: https://github.com/

Autor článku:

Jan Dušátko

Jan Dušátko se počítačům a počítačové bezpečnosti věnuje již skoro čtvrt století. V oblasti kryptografie spolupracoval s předními odborníky např. s Vlastimilem Klímou, či Tomášem Rosou. V tuto chvíli pracuje jako bezpečnostní konzultant, jeho hlavní náplní jsou témata související s kryptografií, bezpečností, e-mailovou komunikací a linuxovými systémy.

1. Úvodní ustanovení

1.1. Tyto všeobecné obchodní podmínky jsou, není-li ve smlouvě písemně dohodnuto jinak, nedílnou součástí všech smluv týkajících školení, pořádaných nebo poskytovaných školitelem, Jan Dušátko, IČ 434 797 66, DIČ 7208253041, se sídlem Pod Harfou 938/58, Praha 9, zapsané u Úřadu městské části Praha 9 (dále jen „školitel“).
1.2. Smluvními stranami ve všeobecných obchodních podmínkách jsou míněni školitel a objednatel, kdy objednatel může být zároveň zprostředkovatelem smluvního vztahu.
1.3. Záležitosti, které nejsou upravené těmito obchodními podmínkami, se řeší podle Občanského zákoníků, tj. zákon č. 89/2012 Sb.

2. Vznik smlouvy přihlášením ke kurzu

2.1. Přihláškou se rozumí jednostranný úkon objednatele adresovaný školiteli prostřednictvím datové schránky s identifikací euxesuf, e-mailu na adresu register@cryptosession.cz nebo register@cryptosession.info, internetových stránek cryptosession.cz, cryptosession.info nebo kontaktním telefonem +420 602 427 840.
2.2. Odesláním přihlášky objednatel souhlasí s těmito všeobecnými podmínkami a prohlašuje, že se s nimi seznámil.
2.3. Přihláška se považuje za přijatou momentem potvrzení (stadnardně do 2 pracovních dní) školitelem nebo zprostředkovatelem. Toto potvrzení je zasláno do datové schránky nebo na kontaktní e-mail.
2.4. Standardní doba pro přihlášení je nejpozději 14 pracovních dní před konáním vzdělávací akce, pokud není uvedeno jinak. V případě fyzické nepodnikající osoby musí být objednávka alespoň 28 pracovních dní před konáním vzdělávací akce.
2.5. Na jednu přihláškou lze přihlásit i více než jednoho účastníka.
2.6. Pokud je více než 10 účastníků od jednoho objednatele, je možné se domluvit na školení v místě sídla zprostředkovatele nebo objednatele.
2.7. Přihlášky jsou přijímány a zpracovávány v pořadí, v jakém došly poskytovateli. Poskytovatel neprodleně informuje objednatele o všech skutečnostech. Těmi se míní naplnění kapacity, příliš nízký počet účastníků, nebo jiný závažný důvod, jako je nemoc lektora nebo zásah vyšší moci. Objednateli bude v tomto případě nabídnut nový termín, případně účast na jiné vzdělávací akci. V případě, že objednatel nebude s přesunutím či účastí na jiné nabídnuté vzdělávací akci souhlasit, poskytovatel mu vrátí účastnický poplatek. Nedostatečný účastníků je oznámen objednateli alespoň 14 dní před začátkem plánovaného termínu.
2.8. Smlouva mezi poskytovatelem a objednatelem vzniká odesláním potvrzení poskytovatelem objednateli.
2.9. Smlouvu lze změnit nebo zrušit pouze za splnění zákonných předpokladů a pouze písemně.

3. Zánik smlouvy zrušením přihlášky

3.1. Přihláška může být objednatelem zrušena pomocí e-mailu, nebo pomocí datové schránky.
3.2. Zákazník má právo stornovat svoji přihlášku na kurz 14 dní před konáním kurzu bez jakýchkoliv poplatků. Pokud se jedná o kratší dobu, dochází k následné změně. V intervalu 7-13 dní je účtován administrativní poplatek 10%, storno účasti v kratším intervalu než 7 dní pak poplatek 25%. V případě storna přihlášky nebo objednávky ze strany zákazníka je nabízena možnost účasti zákazníka v náhradním termínu bez dalšího poplatku. Právo na zrušení přihlášky zaniká realizací objednaného školení.
3.3. Při zrušení přihlášky školitelem náleží objednateli plná náhrada za neuskutečněnou akci.
3.4. Objednatel má právo žádat náhradní termín nebo náhradní školení. V takovém případě bude objednatel informován o všech otevřených kurzech. Náhradní termín si nelze vymáhat ani vynucovat, závisí na aktuální dostupnosti kurzu. Pokud má náhradní školení nižší cenu, objednatel doplatí rozdíl. Pokud má náhradní školení nižší cenu, školitel vrátí rozdíl cen školení objednateli.

4. Cena a platební podmínky

4.1. Odesláním přihlášky objednatel akceptuje smluvní cenu (dále jen účastnický poplatek) uvedenou u daného kurzu.
4.2. V případě více účastníků přihlášených jednou přihláškou je možná sleva.
4.3. Účastnický poplatek musí být uhrazen na bankovní účet společnosti vedený u Komerční banky č. 78-7768770207/0100. Při platbě je nutné uvést variabilní symbol, který je uveden na faktuře, odeslané objednateli školitelem.
4.4. Účastnický poplatek zahrnuje náklady poskytovatele včetně školicích materiálů. Poskytovatel je plátce DPH.
4.5. Účastnický poplatek je objednatel povinen uhradit do 14 pracovních dní od přijetí faktury, pokud nebylo samostatnou smlouvou uvedeno jinak.
4.6. Pokud se přihlášená osoba neúčastní školení a nedošlo k jiné domluvě, je její neúčast považována za storno příhlášku v intervalu kratším než 7 dní, tj. školiteli náleží odměna ve výši 25% z ceny kurzu. Přeplatek je vrácen do 14 dní na platební účet odesílatele, ze kterého byly prostředky odeslány. Platba na jiné číslo účtu není možná.
4.7. Nejdéle do 5 pracovních dní od začátku školení bude školitelem vystavena faktura, která bude dle dohody odeslána e-mailem nebo datovou schránkou.

5. Podmínky školení

5.1. Školitel je povinnen informovat objednatele 14 dní dopředu o místě a času školení, včetně termínu zahájení a ukončení denního programu.
5.2. Pokud objednatel není studentem kurzu, je povinnen zajistit distribuci těchto informací koncovým účastníkům. Za nesplnění těchto podmínek školitel nenese odpovědnost.
5.2. Standardně školení probíhá v čase od 9:00 do 17:00 na předem určeném místě.
5.3. Školitel může být dle aktuálních podmínek k dispozici od 8:00 do 9:00 a následně od 17:00 do 18:00 pro dotazy účastníků.
5.4. Na konci školení je koncovým uživatelům předán certifikát o absolovování.
5.5. Na konci školení koncoví uživatelé vyhodnocují přístup lektora a mají se vyjádřit k ohodnocení jeho prezentace, způsobu přednesení a ohodnotit významn poskytnutých informací.

6. Reklamace

6.1. Pokud je účastník hrubě nespokojen s průběhem kurzu, je školitel o této informaci vyrozuměn.
6.2. Důvody nespokojenosti jsou ten samý den zapsány do protokolu ve dvou kopiích. Jedna je předána objednateli a jednu má školitel.
6.3. Vyjádření k reklamaci bude podáno e-mailem do dvou týdnů. Následně do jednoho týdne bude domluven způsob řešení.
6.4. Nespokojenost zákazníka může být důvodem k rozvázání další spolupráce, nebo finanční kompenzaci až do výše ceny školení po odečtení nákladů.

7. Autorská práva k poskytnutým materiálům

7.1. Školicí materiály poskytnuté školitelem v rámci konání školení splňují znaky autorského díla dle zákona č. 121/2000 Sb.
7.2. Žádný ze školicích materiálů ani jeho část nesmí být bez předchozího písemného souhlasu školitele jakýmkoli způsobem dále zpracovávána, rozmnožována, rozšiřována nebo využívána k dalším prezentacím nebo školením.

8. Zodpovědnost

8.1. Školitel nepřebírá odpovědnost za nedostatky ve službách kterékoliv třetí strany, kterou využívá při školeních.
8.2. Školitel nepřebírá odpovědnost za zranění, škody a ztráty, vzniklé účastníkům vzdělávacích akcí, nebo které byly účastníky způsobeny. Takové náklady, způsobené uvedenými okolnostmi, ponese výhradně účastník vzdělávací akce.

9. Platnost podmínek

9.1 Tyto všeobecné obchodní podmínky jsou platné a účinné od 1. října 2024.