crypto.subtle.digest() (W3C Web Crypto API) a vlastní JS implementaci MD5. Soubory ≥ 500 MB: streamovaný výpočet v blocích po 64 MB přes knihovnu hash-wasm – integrována přímo v tomto souboru, bez externích požadavků.
crypto.getRandomValues() (CSPRNG). Pravděpodobnost kolize při generování 1 miliardy UUID je ~9.4×10⁻²⁰ (birthday approximation). Definován v RFC 9562 (dříve RFC 4122).
1.3.6.1.4.1.{číslo}. Registrace je bezplatná a řídí se politikou „First Come First Served“ dle RFC 9371.
Čistě statická demo stránka. Umí capability check browseru, testovací registraci a vyčtení základních údajů z credentialu včetně AAGUID. Mapování AAGUID na vendor/model využívá pouze lokální data (bez MDS dotazů a ověření).
Funguje v HTTPS nebo na localhost. Přes file:// bude WebAuthn ve většině browserů blokovaný.
Zatím bez výsledků.
Načítám dostupná data…
Generuje výchozí návrh konfigurace passkey profilů v authentication method policy (max. 3 sloty) na základě zadaných požadavků. Upozorňuje na kombinace vstupů, které vedou ke konfliktu nebo k uzamčení uživatelů.
Nástroj se nepřipojuje k Entra ID ani k žádnému API a nezná stav vašeho tenantu. Výstup je doporučení k posouzení, ne auditovaná konfigurace; před nasazením ověřte proti aktuální dokumentaci Microsoftu a vlastnímu prostředí.
Návrh je psaný jako na zelené louce, ale tenant na ní typicky nestojí. Po opt-inu na passkey profily se do Default profilu přenesla původní globální nastavení Passkey (FIDO2), takže Profil 1 níže je zpravidla editace existujícího profilu, ne založení nového – a opt-in je podle MS nevratný. Pokud tenant na profily zatím nepřešel a nevynucuje attestation, jsou synced passkeys už dnes povolené bez zásahu administrátora. Stav si ověřte dřív, než podle návrhu začnete konfigurovat.
Attestation je v profilu přepínač se dvěma stavy, ale stojí za ním celý ověřovací řetězec. Se zapnutým Enforce attestation musí autentizátor při registraci vrátit attestation statement ve formátu packed a k němu úplný certifikační řetězec, který se dá navázat na attestation root certifikáty vytažené z FIDO Alliance Metadata Service (MDS). Entra tedy neověřuje proti vlastnímu ručně udržovanému seznamu modelů, ale proti metadatům z MDS – a zveřejnit tam své root certifikáty je odpovědnost výrobce. Když to neudělá, ověření selže, i když je klíč jinak v pořádku.
Platný řetězec sám o sobě nestačí. Metadata v MDS musí pro daný AAGUID navíc deklarovat FIDO2 certifikaci (stačí libovolná úroveň, i L1), FIDO 2.0 nebo vyšší, user verification nebo client PIN (Entra vyžaduje ověření uživatele biometrikou nebo PINem u každého pokusu), resident keys (discoverable credentials, kvůli přihlášení bez zadání uživatelského jména) a rozšíření hmac-secret nebo PRF (kvůli odemykání Windows offline). Klíč, který v MDS je, ale některou z těchto položek nedeklaruje, atestací neprojde.
Časování je vlastní zdroj překvapení: Microsoft ingestuje MDS jednou měsíčně, takže od okamžiku, kdy se model objeví v MDS, může trvat až čtyři týdny, než ho Entra začne uznávat. Čerstvě vydaný klíč proto v prostředí s Enforce attestation nemusí jít zaregistrovat, přestože je certifikovaný. Tabulka FIDO2 security keys eligible for attestation na stránce MS (aktuálně sestavená z MDS verze 275) je odvozený výstup tohoto procesu, ne autoritativní whitelist – model, který v ní chybí, je spíš „zatím ne“ než „nikdy“. Pro nákup hardwaru je to praktické vodítko: pořizovat model, který se v tabulce ještě neobjevil, znamená počítat s čekáním.
Opačný stav není „slabší ověření“, ale žádné: s Attestation = Disabled
přijme Entra i statement typu none, tpm, packed (AttCA)
nebo vlastní formát do 32 znaků. Odtud plyne to, co návrh říká na jiných místech – bez
attestation nelze o passkey zaručit žádnou vlastnost, protože AAGUID i typ klíče jsou v takovém
případě jen tvrzením autentizátoru o sobě samém.
Zdroj: Microsoft Entra ID attestation for passkey (FIDO2) vendors – stránka je psaná pro výrobce klíčů, ale požadavky na ní jsou přesně to, co Entra při registraci kontroluje.
Passkey profil a Conditional Access nejsou dvě verze téhož. Profil je provisioning gate: rozhoduje, co si uživatel smí zaregistrovat, a přes key restriction a Passkey types i to, čím se smí přihlásit. Custom authentication strength je authorization gate: řeší jen přihlášení a jen na zdroje, které politika cílí. Praktický důsledek je, že CA nezabrání registraci neschváleného klíče – uživatel ho zaregistruje, všude jinde s ním projde a naráz na něj narazí až ve chvíli, kdy potřebuje chráněnou aplikaci. Chybu tedy neodhalí registrace, ale provoz.
Druhý důsledek je pro AAGUID seznam. Ověřitelný je jen díky tomu, že profil, pod kterým klíč vznikl, vynucoval attestation – CA sama původ klíče ověřit neumí. Záruka proto stojí a padá s cílením profilů, ne se samotnou CA politikou, a platí jen o klíčích zaregistrovaných pod tímto návrhem: attestation je registrační kontrola, takže dříve zaregistrovaný klíč si svůj nezaručený AAGUID ponechá.
Hosté jsou mimo dosah obou vrstev. Passkey profil řídí registraci ve vašem tenantu, ale host se autentizuje v domovském tenantu a jeho credential podléhá jejich profilu. CA na hosta platí, jenže phishing-resistant metody (FIDO2, Windows Hello for Business, certificate-based auth) smějí podle MS splnit sílu ověření pouze v domovském tenantu; ve vašem je host odkázaný na SMS, hovor, Authenticator push nebo OATH software token. Rozhodují tedy dvě osy najednou:
| Grant | MFA trust vypnutý | MFA trust zapnutý |
|---|---|---|
| Require MFA | Host projde slabou metodou u vás. FIDO2 klíč z domovského tenantu použít nemůže. | Host projde tvrzením z domovského tenantu, i slabou metodou. |
| Phishing-resistant MFA | Neprojde nikdo – žádná metoda použitelná ve vašem tenantu tuto sílu nesplní. | Projde jen FIDO2 / WHfB / CBA z domovského tenantu, jehož kvalitu neřídíte. |
U hosta tedy nelze mít současně kontrolu nad credentialem a phishing-resistant ověření. Pozor na jeden konkrétní důsledek pro politiku výše: pokud některou z vybraných rolí drží guest účet a MFA trust je vypnutý, politika ho nezpřísní, ale zablokuje – a protože nemá exclude jako break-glass účty, pozná se to až prvním přihlášením dodavatelského správce. Doporučení je proto řešit to o patro výš: privilegovanou roli nedržet na guest identitě a pro externí správce zakládat dedikovaný cloud-only účet ve vašem tenantu, kde platí obě vrstvy. MS tento argument uvádí pro účty synchronizované z on-premises; na hosty ho nevztahuje, ale mechanismus je stejný.
Zbývá cílení. Návrh výše cílí Privileged profil na skupinu, zatímco CA politika používá Directory roles – a to nejsou tytéž lidé. Directory roles pokrývají jen vestavěné role a podle MS uživatele aktivně přiřazené, takže custom role, přiřazení omezená administrative unitem a držitelé eligible přiřazení v PIM před aktivací zůstávají mimo rozsah CA, přestože do profilu spadají. Nejjednodušší náprava je cílit obě vrstvy na tutéž spravovanou (ideálně role-assignable) skupinu.
Kdy tedy omezení do CA přesunout má smysl: CA umí report-only a nativní exclude, což passkey profil neumí ani jedno, a neplýtvá jedním ze tří slotů. Přesun je proto legitimní ústup tam, kde limit tří profilů jinak nevychází – za podmínky, že baseline profil vynucuje attestation, že CA cílí na skupinu, a že registrace nové metody u privilegovaných účtů má alert v audit logu. Náhradou profilového omezení ale přesun není: prevenci vymění za detekci.
Logika plánovače vychází z níže uvedené dokumentace Microsoftu. Chování Entra ID se mění – před nasazením ověřte proti aktuální verzi těchto stránek.
1970-01-01 00:00:00 UTC. Rozlišení se liší podle zdroje: sekundy (JWT exp/iat, syslog), milisekundy (JavaScript, Java), mikro/nanosekundy (Prometheus, Go, databázové logy).pwdLastSet, lastLogonTimestamp, accountExpires.Number.MAX_SAFE_INTEGER, proto se počítá v BigInt – zaokrouhlení na běžném čísle by ustřelilo o stovky sekund.0 a 9223372036854775807 v accountExpires neznamenají datum, ale „nikdy nevyprší“.Z, +02:00) – bez něj ho prohlížeč čte v lokální zóně.W52/W53 předchozího roku.10.0.0.0/24, 10.0.0.5-10.0.3.200, samotnou adresu i zápis s maskou 10.0.0.0 255.255.252.0. Komentáře za #, ; nebo // a koncové čárky se ignorují.
10.0.0.5–10.0.0.10 potřebuje čtyři (/32, /31, /31, /32).10.0.0.0/24 + 10.0.1.0/24 + 10.0.2.0–10.0.3.255 je dohromady jediné 10.0.0.0/22. To je hlavní důvod, proč tento nástroj existuje – zkrácení seznamu pravidel na firewallu.0.0.0.0/0, 2³² adres) se do 32bitového intu nevejde a bitový výpočet by přetekl.localStorage a zavřením záložky zmizí.
Nástroj neověřuje podpis: obsah přečte, ale netvrdí, že je pravý.
jwks_uri v /.well-known/openid-configuration a vybírá se podle kid z hlavičky. To je síťové volání, a tento toolkit je záměrně offline.iss → aud → exp/nbf → nonce. Cokoli přečtené z payloadu před ověřením podpisu je tvrzení útočníka, ne fakt.alg z hlavičky – algoritmus musí být daný konfigurací ověřovatele. Právě na tom stojí útoky alg:none a záměna RS256 za HS256 (RFC 8725).exp – vložit ho do ticketu, chatu nebo online dekodéru znamená předat ho dál. Tady zůstává v prohlížeči, ale reflex „vložím to do JWT dekodéru“ stojí za promyšlení pokaždé.Zdůvodnění, která nejsou potřeba k použití nástroje, jsou složená do rozbalovacích bloků. Ctrl+F je najde i sbalené v Chrome, Edge, Firefoxu 139+ a Safari 26.2+; ve starším prohlížeči je nejdřív rozbalte – .
Než se pustíte do názvů cipher suit: TLS řeší tři věci najednou a pro každou z nich se použije jiný algoritmus. Právě proto má cipher suite tak dlouhé jméno – je to zápis všech těch voleb v jednom řetězci.
| Co TLS zajišťuje | Na jakou otázku odpovídá |
|---|---|
| Důvěrnost | Přečte někdo po cestě, co si se serverem posíláme? Řeší šifrování provozu. |
| Integrita | Mohl někdo po cestě data nepozorovaně změnit? Řeší kontrolní součet, který nejde zfalšovat. |
| Autenticita | Mluvím opravdu se serverem, na který jsem se chtěl připojit? Řeší certifikát a podpis. |
Všechno se domlouvá na začátku spojení, při tzv. handshake. Proběhne jednou, pak už se jen šifruje domluvenými klíči. Tyto čtyři kroky jsou kostra, do které zapadá zbytek stránky:
| Krok | Co se v něm stane | Detail |
|---|---|---|
| 1 · Domluva verze | Klient řekne, které verze TLS a které cipher suity umí; server z nich vybere. Stará verze = stará (a často rozbitá) kryptografie, proto se řeší jako první. | |
| 2 · Výměna klíče | Obě strany se dohodnou na společném tajemství, ze kterého vznikne session klíč – aniž by ho kdokoli po cestě odposlechl. | |
| 3 · Ověření identity | Server pošle certifikát a podepíše jím data z handshake. Tím dokáže, že k certifikátu opravdu vlastní privátní klíč. | |
| 4 · Šifrovaný provoz | Teprve teď tečou data – symetricky zašifrovaná session klíčem, s kontrolou integrity u každé zprávy. |
Pokud vás zajímá jen výsledek a ne proč: toto je stejná rozhodovací tabulka jako v sekci 9, jen nahoře.
| Scénář | Doporučení |
|---|
Co ta jména profilů znamenají, rozebírá ; konfiguraci pro Windows, nginx, Apache i OpenSSL vygeneruje .
Referenční bod pro zbytek stránky – nemusíte si nic pamatovat dopředu, jen se sem vracejte. Zkratky použité v textu mají navíc bublinu po najetí myší.
Tento řetězec je zápis výsledku kroků 2–4 handshake do jednoho identifikátoru – co si klient se
serverem domluvili. Řetězec TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
popisuje čtyři nezávislé volby najednou:
| Segment | Význam |
|---|---|
| ECDHE | Key exchange – jak se domluví session klíč (krok 2, viz sekce 3). |
| RSA | Autentizace – jaký klíč/podpis dokazuje identitu serveru (krok 3, sekce 4). |
| AES_128_GCM | Bulk cipher a mód – čím a jak se šifruje samotný provoz (krok 4, sekce 5). |
| SHA256 | Hash pro PRF/HMAC – odvození klíčů, u CBC suit i integrita (sekce 6). |
TLS 1.3 zredukoval jméno na TLS_AES_128_GCM_SHA256 – jen bulk
cipher + hash. Key exchange (vždy efemérní – ECDHE/X25519) a autentizace (podpisový algoritmus certifikátu)
se vyjednávají samostatně přes rozšíření key_share a
signature_algorithms, protože v TLS 1.3 je autentizace oddělená od
volby šifry – RSA key transport (bez PFS) byl úplně odstraněn, takže už není co jménem rozlišovat.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, OpenSSL (openssl ciphers -v,
Apache/nginx configy) tvar ECDHE-RSA-AES128-GCM-SHA256 – stejná
suita, jiná konvence zápisu. Parser v sekci 10 přijímá oba tvary.
První, na čem se klient se serverem musí shodnout, je verze protokolu. Rozhoduje o všem dalším: starší verze nabízejí slabší algoritmy a mají známé útoky na samotný handshake, takže žádná volba cipher suity je nezachrání.
| Verze | Stav | Poznámka | Kde to funguje (orientačně) |
|---|---|---|---|
| SSL 2.0 / 3.0 | mrtvé | Prolomené (DROWN, POODLE). Moderní OS je už nepodporují vůbec. | Nikde, kde je co ztratit – prohlížeče, mobilní OS i knihovny to odmítají. |
| TLS 1.0 / 1.1 | deprecated | Formálně vyřazeno v RFC 8996 (2021). Prohlížeče a hlavní certifikační autority je dál nepodporují. | Windows XP SP3 / IE8, Android 4.0–4.3, staré appliance a průmyslová zařízení bez update. |
| TLS 1.2 | minimum | RFC 5246, dnešní praktické minimum – musí být správně nakonfigurované (jen ECDHE/DHE + AEAD suity, viz sekce 7). | Prakticky vše od ~2013: Windows 7+ (na 7/8 nutno zapnout), Android 4.4+, Java 8, OpenSSL 1.0.1+, všechny dnešní prohlížeče. |
| TLS 1.3 | cíl | RFC 8446 – zjednodušený 1-RTT handshake, odstraněný statický RSA i CBC, jen AEAD suity. Volitelné 0-RTT (early data) má replay riziko – použít jen pro idempotentní požadavky. | Windows 11 / Server 2022+, OpenSSL 1.1.1+, Chrome 70+, Firefox 63+, Safari 12.1+, Android 10+, Java 11+. |
Jak se dvě strany přes odposlouchávanou linku domluví na společném tajném klíči? A co se stane s dřív zachyceným provozem, když někdo ten klíč později získá?
Perfect Forward Secrecy (PFS): i když někdo později získá dlouhodobý privátní klíč serveru (kompromitace, soudní příkaz, chyba), nedokáže dešifrovat dřív zachycený provoz – protože session klíč nebyl z dlouhodobého klíče odvozen, ale vygenerován efemérně (jednorázově, jen pro dané spojení) a po skončení spojení zahozen.
| Key exchange | PFS | Poznámka |
|---|---|---|
| ECDHE | ano | Efemérní Diffie-Hellman na eliptické křivce (X25519, P-256/P-384) – dnešní standard. |
| DHE | ano | Efemérní Diffie-Hellman nad konečným polem – stejná záruka, výpočetně dražší; fallback pro klienty bez podpory křivek. |
| RSA (statický) | ne | Klient zašifruje session klíč přímo veřejným klíčem certifikátu – žádná efemérní výměna. V TLS 1.3 odstraněno úplně. |
Jak server dokáže, že je to opravdu on, a ne někdo, kdo se za něj vydává? Podepíše data z handshake privátním klíčem, ke kterému má certifikát – a klient podpis ověří veřejným klíčem z certifikátu. Podpisový algoritmus je ta druhá zkratka v názvu suity.
| Algoritmus | Popis |
|---|---|
| RSA | Server dokazuje vlastnictví privátního klíče RSA certifikátu podpisem handshake dat. Nejrozšířenější, ale delší klíče/podpisy než ECDSA při srovnatelné síle. |
| ECDSA | Podpis na eliptické křivce – kratší klíče a rychlejší operace než RSA. Vyžaduje ECDSA certifikát (ne každá CA/PKI ho běžně vydává). |
| EdDSA (Ed25519/Ed448) | Moderní podpisové schéma z RFC 8032 – v TLS 1.3 přes signature_algorithms. Rychlé, odolné vůči řadě implementačních chyb (deterministické podpisy), zatím méně rozšířené CA podpory. |
Klíč je domluvený, identita ověřená – čím se tedy šifrují samotná data? Symetrickou šifrou, a hlavně: v jakém módu, protože ten rozhoduje, jestli se spolu se šifrováním řeší i integrita.
AEAD (Authenticated Encryption with Associated Data) šifruje a autentizuje v jednom kroku – dnešní standard. Starší CBC mód dělá šifrování a integritu (HMAC) odděleně (MAC-then-Encrypt), což historicky vedlo k padding-oracle útokům (Lucky13, POODLE, BEAST u TLS 1.0) a je i bez konkrétní zranitelnosti komplikovanější implementovat bezpečně.
| Šifra / mód | AEAD | Poznámka |
|---|---|---|
| AES-GCM | ano | Standard pro AES v TLS. Nejrychlejší na CPU s AES-NI (většina serverů/desktopů od ~2011). |
| ChaCha20-Poly1305 | ano | Proudová šifra + Poly1305 AEAD. Rychlejší než AES bez hardwarové akcelerace (mobily, IoT, starší CPU) – proto ji preferují mobilní klienti. |
| AES-CBC | ne | Funkční, ale bez AEAD záruk – v TLS 1.2 zmírněno (record splitting, konstantní čas), v TLS 1.3 úplně odstraněno. |
| RC4 / DES / 3DES | – | Prolomené nebo zranitelné (RC4 bias, DES hrubá síla, 3DES Sweet32 na 64bit bloku) – vyřadit bez výjimky. |
Hash není samostatný krok handshake – je to nástroj, který se používá ve všech. V názvu cipher suite hraje hash dvojí roli: u AEAD suit (GCM, ChaCha20-Poly1305) jde jen o PRF/HKDF hash pro odvození klíčů; u starších CBC suit navíc o HMAC pro integritu zprávy. To je jiná role než hash v podpisu certifikátu – tam je SHA-1 dnes zakázaný (kolize), zatímco jako HMAC uvnitř CBC suity zůstává SHA-1 prakticky bezpečný. MD5 nepoužívat v žádné roli. Baseline dnes: SHA-256/384 (nikdy samotné jako podpis, vždy jako PRF/HMAC součást cipher suite).
Orientační přehled, ne přepis originálu – vždy ověřte aktuální verzi u zdroje, doporučení se v čase posouvají (naposledy výrazně kvůli PQC hybridům, sekce 8).
| Zdroj | Profil | Jádro doporučení |
|---|---|---|
| Mozilla SSL Config | Modern | Jen TLS 1.3, jen AEAD (3 suity), žádný TLS 1.2 fallback – pro klienty, u kterých je jistá podpora TLS 1.3. |
| Mozilla SSL Config | Intermediate | TLS 1.2 + 1.3, jen ECDHE/DHE + AEAD, žádné CBC/3DES/RC4 – obecně doporučený default pro veřejné služby. |
| Mozilla SSL Config | Old | Povoluje TLS 1.0+ a CBC kvůli starým klientům – jen pro nutnou zpětnou kompatibilitu, ne jako výchozí volba. |
| NIST SP 800-52r2 | – | TLS 1.2 povinné minimum pro federální systémy, TLS 1.3 doporučeno; jen AEAD suity s (EC)DHE. |
| BSI TR-02102-2 | – | Německé BSI – obdobně TLS 1.2/1.3, AEAD-only, konkrétní seznam povolených křivek a délek klíčů. |
| NSA CNSA 2.0 | – | Cílí na PQC algoritmy (sekce 8) s mandátem přechodu do 2030–2033 pro systémy národní bezpečnosti. |
„Harvest now, decrypt later“: útočník zachytává šifrovaný provoz už dnes a čeká, až kvantový počítač zvládne prolomit klasický key exchange (RSA, ECDHE). Riziko se týká dat, která musí zůstat důvěrná roky (zdravotní záznamy, státní tajemství, dlouhodobé smlouvy) – ne krátkodobých relací.
| NIST standard | Účel | Poznámka |
|---|---|---|
| ML-KEM (FIPS 203, dříve Kyber) | Key exchange | Řeší se první – TLS už dnes běžně nasazuje hybridní key exchange (klasický ECDHE + ML-KEM současně), takže spojení je bezpečné, i kdyby jeden z algoritmů později padl. |
| ML-DSA (FIPS 204, dříve Dilithium) | Podpisy | Nahrazuje RSA/ECDSA v certifikátech – nasazení v PKI je pomalejší (řetězce důvěry, revokace, délky podpisů). |
| SLH-DSA (FIPS 205, dříve SPHINCS+) | Podpisy (stateless hash-based) | Konzervativnější, hash-based alternativa k ML-DSA – větší podpisy, ale méně nových matematických předpokladů. |
Hybridní key exchange X25519MLKEM768 je už dnes výchozí v Chrome a
podporovaný v OpenSSH – je to key exchange, ne cipher suite, takže se do generátoru v sekci 12
(SCHANNEL cipher suite pořadí) nepromítá; jde o samostatnou vrstvu konfigurace TLS stacku.
Orientační timeline: NSA CNSA 2.0 žádá přechod na PQC algoritmy do 2030–2033 pro systémy národní
bezpečnosti, NIST obdobně doporučuje útlum klasických algoritmů do roku 2030/2035.
EccCurves, GPO Configure ECC Curve Order,
Enable-TlsEccCurve) teď nese i ne-eliptické skupiny podle
IANA TLS Supported Groups registru
– nevznikl žádný nový nástroj ani klíč v registru.
| Supported Group (Schannel) | Co to je | Protokol | Výchozí zapnuto | FIPS (legacy) | Dostupnost |
|---|
Enable-TlsEccCurve
– žádný nový cmdlet nepřibyl. Nejsou to alternativy, ze kterých se vybírá jedna:
EccCurves je úplný seznam, takže skupina, která v něm není,
se nepoužije, a klient, který umí jen tu chybějící, se tiše vrátí ke klasické výměně klíče. Vypsat
všechny tři na serveru nic nestojí – skupina se uplatní jen tehdy, když ji klient nabídne. Zadarmo
naopak není samotný hybridní handshake, jakmile se použije: výměna klíče má u ML-KEM-768
zhruba 1200 B, u secp384r1_mlkem1024 skoro 1700 B a ten je
i výrazně náročnější na CPU (kvůli P-384). Na straně klienta pak větší ClientHello nemusí padnout do
jednoho TCP segmentu – OpenSSL to má v dokumentaci jako známý případ, kdy handshake přeruší chybně implementovaný
firewall. Rozdíl mezi nimi je v parametru ML-KEM: secp384r1_mlkem1024 je
jediná s ML-KEM-1024, zbylé dvě používají ML-KEM-768. Vedle těchto tří hybridů přibyl
v KB5120998 (build 26100.9267, GA 27. 8. 2026) i samostatný, nehybridní ML-KEM jako TLS skupina;
v tabulce skupin na začátku této sekce není proto, že pro něj MS Learn zatím nezveřejnil řetězec skupiny, který by se dal
zapsat do EccCurves.
SslStream…).
Browser stack je taky připomínka, že se kódové body PQC skupin před standardizací měnily: Edge 131
(listopad 2024) přešel z draftu Kyber na finální ML-KEM a s ním ztratil kompatibilitu se servery
nastavenými na tu starší hodnotu. Proto se skupina zapisuje jménem z aktuální MS Learn tabulky,
ne opsaným z návodu.
Enable-TlsEccCurve -Name x25519_mlkem768 -Position 0
Enable-TlsEccCurve -Name secp256r1_mlkem768 -Position 1
Enable-TlsEccCurve -Name secp384r1_mlkem1024 -Position 2
# Pozice jsou vypsane zamerne: tri volani s -Position 0 za sebou by
# hybridy zaradila v obracenem poradi, nez v jakem je tu napsany.
#
# Jsou to tri kroky, ne tri nezavisle prikazy: kazda pozice se vztahuje ke
# stavu PO tom predchozim. Pustit je v jinem poradi se stejnymi cisly da jiny
# vysledek - proto je zapis hodnoty nize bezpecnejsi forma: uvadi rovnou
# vysledny seznam a da se pustit opakovane se stejnym vysledkem. Rozdil neni
# v tom, ze jedno je cmdlet a druhe registr, ale v tom, ze Enable-TlsEccCurve
# odvozuje vysledek ze stavu stroje, kdezto zapis hodnoty ho urcuje cely.
# nebo primo pres registr (stejny klic, ktery cte i audit skript v sekci 11).
# EccCurves je REG_MULTI_SZ, ne REG_SZ - proto New-ItemProperty s -PropertyType
# MultiString a ne .reg soubor: multi-string se v nem zapisuje jako hex(7) a je
# necitelny. Pozor na rozdil proti sousedni hodnote Functions v tomtez klici,
# ta REG_SZ s polozkami oddelenymi carkou je. Overeno merenim na Windows 11
# build 26200.9168: tataz hodnota zapsana jako REG_SZ se po restartu
# neprojevila vubec, jako REG_MULTI_SZ se projevila presne.
New-ItemProperty -Force -PropertyType MultiString `
-Path 'HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002' `
-Name EccCurves `
-Value ('x25519_mlkem768,secp256r1_mlkem768,secp384r1_mlkem1024,curve25519,NistP256,NistP384' -split ',')
# GPO: Computer Configuration > Administrative Templates > Network >
# SSL Configuration Settings > ECC Curve Order > Enabled >
# x25519_mlkem768,secp256r1_mlkem768,secp384r1_mlkem1024,curve25519,NistP256,NistP384
#
# Vsechny tri hybridy, ne jen prvni. EccCurves je uplny seznam a skupina,
# ktera v nem neni, se nepouzije - klient, ktery umi jen secp256r1_mlkem768,
# by tise spadl na klasickou vymenu klice. Vypsat je na serveru nic nestoji:
# skupina se uplatni jen tehdy, kdyz ji klient nabidne. Samotny hybridni
# handshake uz zadarmo neni - vymena klice ma u ML-KEM-768 asi 1200 B,
# u secp384r1_mlkem1024 skoro 1700 B a ten je i narocnejsi na CPU.
#
# Poradi mezi hybridy: x25519_mlkem768 prvni, protoze je to jedina skupina,
# kterou klienti nabizeji ve vychozim nastaveni (prohlizece pres BoringSSL/NSS,
# Go, DEFAULT seznam OpenSSL 3.5). Silnejsi parametr ML-KEM-1024 tim neprichazi zkratka - je
# v seznamu, takze klient, ktery si o nej rekne, ho dostane. Poradi
# rozhoduje az tam, kde klient nabidne vic skupin nez jednu.
#
# EccCurves je uplny seznam: klasicke krivky se musi vypsat taky, jinak
# je tento zapis zahodi.
secp384r1_mlkem1024 je v seznamu, takže
klient, který si o ML-KEM-1024 řekne, ho dostane bez ohledu na to, že je třetí – tím, že není první,
o nic nepřicházíte.
x25519_mlkem768 je vepředu ze dvou důvodů. Je to jediný ze tří,
který klienti nabízejí ve výchozím nastavení: prohlížeče přes BoringSSL/NSS, Go, a OpenSSL 3.5
ho má jako jedinou hybridní skupinu ve svém DEFAULT seznamu – zbylé dvě umí, ale sám je nenabízí.
(Stav k 09/2026. Je to údaj o klientském ekosystému, ne o Schannelu, takže se může změnit dřív než cokoliv
jiného na této stránce.) A druhý důvod je výkonový: v TLS 1.3 posílá klient key share jen
pro několik skupin, které odhadne. Když server preferuje skupinu, kterou klient sice inzeruje v
supported_groups, ale key share pro ni neposlal, odpoví server
HelloRetryRequest a handshake stojí jedno kolo navíc. Prohlížeče posílají share právě pro
X25519MLKEM768, takže toto pořadí je zároveň to, které se s nimi domluví na první pokus.
secp384r1_mlkem1024 – pod tímto režimem patří na první místo,
případně jako jediný hybrid. Odkaz je v .
Mimo něj je ML-KEM-768 (NIST kategorie 3) považovaný za dostatečný.
Get-TlsEccCurve, nebo rovnou audit skript
v sekci 11 – ten PQC skupinu v nastaveném pořadí rozezná a řekne, jestli ji OS opravdu aplikoval,
nebo ji tiše zahodil: kvůli staršímu buildu, protože jde o Windows Server, nebo protože je zapnutý
legacy FIPS režim.
| Scénář | Doporučení |
|---|
Get-TlsCipherSuite nebo obsah
GPO seznamu se rozparsuje beze zbytku. Nenalezená suita nemusí být špatně, jen mimo tento ručně vybraný
katalog; pro vyčerpávající seznam viz
IANA TLS Cipher Suites registry.
Než začnete něco měnit, stojí za to vědět, co server nabízí už teď. Žádný systém není „nenakonfigurovaný“ – jen běží na cizím rozhodnutí. A ta výchozí rozhodnutí se mezi Windows, RHEL, Debianem, nginxem i verzemi OpenSSL liší natolik, že „nic jsme nenastavovali“ neznamená na dvou strojích totéž.
Podstatné je, že výchozí stav nedrží jedna vrstva, ale tři – a generátor v zapisuje pokaždé do jiné z nich:
| Vrstva | Kdo ji drží | Kam píše generátor |
|---|---|---|
| 1 · OS / krypto-politika | Registr Schannelu, crypto-policies na RHEL, openssl.cnf na Debianu a Ubuntu. | Windows – výstup generátoru je zásah přímo do této vrstvy. |
| 2 · Default aplikace | Co nginx, Apache nebo libovolná aplikace nad OpenSSL použije, když jí nic neřeknete. | nginx, Apache, OpenSSL – generátor přepisuje jen tuto vrstvu. |
| 3 · Vaše konfigurace | To, co do konfiguračního souboru napíšete ručně. | — |
PROFILE=SYSTEM
vlastním ssl_ciphers, přestane pro něj platit
update-crypto-policies a údržbu si berete na sebe.
ssl.conf ho mohly dávno změnit. Jediný
spolehlivý zdroj pravdy je sken běžící služby (testssl.sh, sslscan,
nmap --script ssl-enum-ciphers) – dokumentace říká, co má být, sken co je.
Přehled popisuje stav dokumentovaný. Tento skript zjistí ten váš: přečte registr Schannelu, projde protokoly, pořadí cipher suit, křivky i .NET klíče a vypíše nálezy ve třech úrovních plus samostatná doporučení. Je statický – nezávisí na ničem, co nastavíte v generátoru v . Co která kontrola znamená, rozebírají a pod náhledem.
testssl.sh, sslscan, nmap --script ssl-enum-ciphers.
Sekce reportu odpovídají tomuto pořadí. Napříč všemi platí jedna věc, kterou one-liner nad registrem neumí: skript rozliší „klíč není nastaven“ od „je vypnuto“ – chybějící klíč znamená výchozí stav OS, což je nejčastější chybné čtení celého registru Schannelu.
| Sekce reportu | Co v ní zjistíte |
|---|---|
| System | Verzi Windows z CurrentBuildNumber a DisplayVersion (ProductName na Windows 11 hlásí „Windows 10“, skript to opraví a řekne, že opravil) a zapnutý FIPS režim. |
| Protokoly | SSL 2.0 až TLS 1.3, zvlášť v roli serveru a v roli klienta. Pozná i hodnotu 0xFFFFFFFF a řekne, že funguje, ale neodpovídá dokumentaci. |
| Pořadí cipher suites | Porovná nakonfigurovaný Functions proti tomu, co OS opravdu aplikoval – tedy odhalí tiše ignorované položky, které posouvají prioritu zbytku. Každou suitu ohodnotí a zkontroluje jejich pořadí. |
| Legacy klíče | Per-algoritmus klíče Ciphers\, Hashes\ a KeyExchangeAlgorithms\ – a jejich rozpor s aktivním pořadím suit. |
| Délka klíče pro DHE | ServerMinKeyBitLength a ClientMinKeyBitLength, jejichž výchozí hodnoty se liší podle role. |
| .NET Framework | SystemDefaultTlsVersions a SchUseStrongCrypto ve všech čtyřech klíčích, které generátor umí zapsat. |
| Křivky a PQC hybridy | Vlastní pořadí EccCurves z policy i lokálního klíče proti Get-TlsEccCurve. Stejným porovnáním odhalí tiše zahozené x25519 i PQC hybrid nastavený v GPO, který OS neaplikoval (starší build, Windows Server, nebo FIPS režim). |
| Nálezy · Doporučení | Souhrn na konci; s přepínačem -Json totéž strojově, s -OutFile do souboru. Přidáte-li k němu -Markdown, vznikne .md se souhrnnou tabulkou a nálezy po úrovních – tělo sekcí zůstává v blocích kódu, protože jde o zarovnaná data, ne o věty. |
| Úroveň | Kdy ji skript použije | Kód |
|---|---|---|
| CRIT | Prolomená kryptografie, kterou stroj v této konfiguraci opravdu vyjedná. | 2 |
| WARN | Něco k nápravě: vyřazený protokol, slabší suita nad silnější, ignorované položky seznamu. | 1 |
| INFO | Stav, který stojí za vědomí, ale sám o sobě defekt není – nebo nález, u kterého platí podmínka, již skript z registru neověří. | 0 |
| Doporučení | Co jde přidat. Není to defekt, proto má vlastní sekci vedle nálezů. | nemění |
Rozhodnutí, která z reportu nejsou vidět, ale mění, co v něm najdete. Pro použití skriptu je číst nemusíte – hodí se, když se s nějakým nálezem nebo naopak s jeho nepřítomností potřebujete přít.
Serverová strana nabízí zastaralý protokol komukoli na síti, takže je přísnější; klientská ho jen nabídne
protistraně, kterou si stroj vybral sám, a jde tedy o stupeň níž – SSL 2.0/3.0 je na serveru
CRIT a na klientu WARN,
TLS 1.0/1.1 WARN a INFO.
Chybějící moderní protokol je ale stejně vážný v obou: vypnuté TLS 1.2
i 1.3 na klientské straně znamená, že se odsud nenaváže odchozí
spojení. Na pracovní stanici rozhoduje právě tato polovina – serverová tam neposlouchá nic.
Protokolová a suitová část se navíc porovnávají navzájem. Seznam ve
Functions je úplný, takže zapnutý protokol, pro který v něm není
ani jedna vyjednatelná suita, je zapnutý jen v tabulce protokolů – na síti na něm Schannel nedomluví nic.
Suity, které potřebují opt-in aplikace, se za vyjednatelné nepočítají; jinak by
TLS_RSA_WITH_NULL_SHA „pokryla“ všechny staré protokoly naráz,
což je přesně ten stav, kvůli kterému kontrola vznikla. U vyřazených protokolů je to
INFO (zbytek po předchůdci, ne expozice), u TLS 1.2
WARN – tam se nepřipojí klient, který neumí TLS 1.3.
Pořadí se hodnotí jen tam, kde nějaký Functions existuje – bez něj
platí výchozí pořadí OS a není co soudit. Kontroly jsou dvě: slabší suita nad silnější
a HTTP/2-nekompatibilní
TLS 1.2 suita v čele TLS 1.2 části (RFC 9113, příloha A – jen PFS + AEAD). Obojí je otázka výběru
ze společně podporovaných suit a v každé roli znamená něco jiného. V roli
serveru pořadí přímo rozhoduje: Schannel vybere vždy nejvýše prioritní suitu, kterou protistrana
také umí, takže slabší nebo HTTP/2-nekompatibilní suitu dostane ten, kdo ji umí, přesně když je nastavená
výš než ta lepší. V roli klienta stejné pořadí jen určuje
preferenci, se kterou tento stroj suity nabídne – o výsledku rozhoduje server na druhé straně.
Obě kontroly běží zvlášť pro TLS 1.3 a zvlášť pro TLS 1.2 suity, protože verze protokolu
se vyjednává dřív a nezávisle na pořadí ve Functions – klient
s TLS 1.3 dostane TLS 1.3 suitu, ať je v seznamu kdekoli, a klient bez TLS 1.3 na ni nedosáhne vůbec.
Má to dva důsledky, které jdou proti intuici: TLS 1.2 suita nad TLS 1.3 suitou není chyba pořadí
(ty dvě se v jednom handshaku nikdy nepotkají), zatímco CBC suita v čele TLS 1.2 části je nález
i tehdy, když jsou nad ní TLS 1.3 suity – klient, který TLS 1.3 neumí, dostane právě ji.
Dvě věci, které jako chyba pořadí vypadají a záměrně se nehodnotí: AES-128 nad AES-256 (Mozilla dává 128 první schválně) a RSA nad ECDSA (závisí na certifikátu navázaném na službu, ten skript nevidí).
Vedle pořadí umí skript i co doplnit – nejčastější nález této poloviny je hardeningová GPO
starší než TLS 1.3: protokol je zapnutý, jenže seznam ve Functions
je úplný – co v něm není, se nepoužije – takže TLS 1.3 nemá čím vyjednávat.
Dvě rodiny suit Schannel nabídne jen aplikaci, která si o ně řekne: PSK přes
SCH_USE_PRESHAREDKEY_ONLY a NULL suity přes
dwMinimumCipherStrength = -1 (MS Learn je ve výchozím pořadí uvádí
přímo s poznámkou „Only used when application explicitly requests“ a
SCH_USE_STRONG_CRYPTO je odfiltruje). Bez tohoto rozlišení by stroj
s nedotčenými Windows 11 skončil na CRIT kvůli
TLS_PSK_WITH_NULL_SHA384 a oběma
TLS_RSA_WITH_NULL_* ve výchozím pořadí – tedy na alarmu, se kterým
nejde nic dělat, protože odebrat je znamená zmrazit celé Functions.
Snížení úrovně se proto váže na to, kdo tu suitu do pořadí dal, ne na opt-in samotný.
A tuto otázku zodpoví jen policy klíč: ten začíná prázdný a zapisuje se celý najednou
(GPO, MDM, generátor v sekci 12), takže každá položka v něm je něčí volba. Lokální klíč
…\Cryptography\Configuration\Local\SSL\00010002 je naopak
úložiště CNG a výchozí pořadí OS v něm leží taky – MS na něj posílá diagnostiku „jaké suity
ten stroj má“ a Azure Arc do něj nechává suitu přidat do seznamu, tedy do už existujícího. Jeho
existence proto nedokazuje volbu, nanejvýš to, že z něj nikdo nic neubral (CNG cmdlety umí jen odebírat).
Rozdíl je vidět na téže suitě: TLS_RSA_WITH_NULL_SHA256 ve výchozím
pořadí je WARN, tatáž suita dopsaná do GPO je
CRIT. A rodina, která opt-in nepotřebuje, neklesá vůbec – proto
nedotčený Server 2022 na CRIT končí, kvůli
TLS_RSA_WITH_3DES_EDE_CBC_SHA ve svém výchozím pořadí.
Nález ale nikdy nezmizí a podmínku vždycky pojmenuje. Opt-in není nic, co by šlo vyjednat po síti – je to lokální volba aplikace při získávání credentialu, takže ho protistrana nezapne. Riziko je lokální: vývojářský kód, který se dostal do produkce, nebo SDK dodavatele. A právě to skript z registru nevidí. Neověřená podmínka se proto napíše do textu nálezu, neodmávne: pokud taková aplikace běží, jde u NULL suity opravdu o nešifrované spojení a nález platí v plné váze.
Pořadí se naproti tomu soudí u každého existujícího seznamu, i toho lokálního: ruční úprava lokálního klíče je dokumentovaný postup a vázat hodnocení pořadí na policy klíč by ho na takovém stroji vyplo. Jsou to dvě různé otázky – kdo seznam vybral a je vůbec co hodnotit.
Podklíč SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman nenese
Enabled, takže do smyčky nad legacy klíči nespadne a bez vlastní
sekce by po něm v reportu nezůstal řádek. Přitom je pod minimem právě jedna z jeho výchozích hodnot:
ServerMinKeyBitLength je od Windows 10 / Serveru 2016
2048 (advisory 3174644), ale ClientMinKeyBitLength
je 1024 bez ohledu na verzi – a RFC 9325 §4.5 žádá „at least 2048 bits“ jako
REQUIRED.
Výsledek řídí dvě nezávislé osy – stejná dvojice jako u závažnosti suit:
kdo hodnotu nastavil (to je závažnost) a uplatní se teď (to je expozice, tedy jestli je
v aktivním pořadí nějaká TLS_DHE_* suita).
| Hodnota pod 2048 | DHE suita v pořadí | Bez DHE suity |
|---|---|---|
| Někdo ji zapsal | WARN – uplatní se, přepsat na 2048 je jednořádková úprava. | INFO – platí na papíře, ne na síti. Uplatní se ve chvíli, kdy se DHE do pořadí dostane. |
| Nenastavená (výchozí stav Windows) | Doporučení – nezvedá návratový kód komukoli, kdo skript pouští z monitoringu. | Mlčí – rada, kterou by dostal každý stroj při každém běhu, je přesně ten šum, kvůli kterému sekce doporučení vznikla. |
Zapsaná hodnota nižší než výchozí hodnota daného Windows se navíc pojmenuje jako oslabení proti tomu, co OS dělá sám – bez té věty vypadá zápis jako potvrzení výchozího stavu.
Víc než 2048 se nedoporučuje záměrně: DHE je záloha pro klienty bez eliptických křivek a právě ti na delším
modulu spíš spadnou – kdo chce 128 bitů, má sáhnout po ECDHE, ne po větším modulu. RFC 9325 ostatně
doporučuje TLS_DHE_* nevyjednávat vůbec.
Když Ciphers\NULL nebo
Ciphers\RC4 128/128 algoritmus vypíná, ale tatáž rodina je pořád
v aktivním pořadí suit, řekne to skript jedním INFO. Závažnost tím
nesnižuje – MS dnes u AD FS uvádí, že řízení ciphers přes registr „isn't supported“, a odkazuje na
pořadí cipher suit, takže na tento klíč nejde vázat úroveň nálezu. Bez toho ale jeden report na jedné
stránce tvrdil obojí naráz a nic ty dva řádky nespojovalo.
Totéž platí pro výměnu klíče, a tam na tom záleží nejvíc:
KeyExchangeAlgorithms\ECDH vypnutá proti dvanácti
TLS_ECDHE_* suitám v pořadí je stroj, který nejspíš vyjedná už jen
statickou RSA. WARN o tom říká, že klíč přebíjí výběr suit;
INFO vyjmenuje, kterých suit se to týká. Jsou to dvě různé věty, ne
dvakrát táž.
Opačný směr – algoritmus někdo výslovně zapnul – se hlásí jen u prolomených šifer
(NULL, RC4,
Triple DES) a jen tehdy, když v aktivním pořadí žádná taková suita
není. Functions je úplný seznam, takže zapnutý algoritmus sám o sobě
žádnou suitu nevrátí do hry – zbývá případ „někdo to zapnul a nic to nepoužívá“, tedy zbytek po starší
konfiguraci, který se dá smazat. Když ta suita v pořadí je, mluví o ní nález u cipher suit a druhý
řádek by opakoval totéž. Plošně se to ozvat nemůže: na nedotčeném stroji tyto podklíče neexistují.
Hashes\MD5 ani Hashes\SHA
mezi ně nepatří – MS sám u Hashes odkazuje na pořadí cipher suit a tam je to pokryté:
_MD5 je CRIT,
_CBC_SHA WARN.
Minimální sada suit se řídí buildem, takže TLS 1.3 se nedoporučí Serveru 2019, který ho neumí. U PQC
hybridů rozhoduje revize: tentýž build 26100 bez revize 8514 skupiny nezná a na Windows
Serveru zatím v GA nejsou. Skript proto vypisuje Build : 26200.8514
včetně UBR.
Čísla 8514 a 8524 odpovídají na dvě různé otázky a pletou se: 8514 je minimum, které uvádí MS Learn pro to, aby build skupiny znal – a přesně na to se audit ptá. 26100.8524 z KB5089573 je až GA build, tedy odpověď na „je to obecně dostupné“, kterou řeší . Kdyby se audit ptal na GA, odpověděl by „nezná“ i strojům z release preview, které skupiny mají.
SCHANNEL\Hashes – ten je o MAC v cipher suitě – ale samostatná politika
ověřování řetězce v
HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config:
hodnoty WeakMd5ThirdPartyFlags,
WeakSha1ThirdPartyFlags,
WeakRsaAllMinBitLength a další ve tvaru
Weak<Alg><All|ThirdParty><Flags|MinBitLength|AfterTime>.
Vypíšete je příkazem certutil -getreg chain, výchozí chování OS pak
certutil -getreg chain\default. Je to
jiná vrstva než vyjednávání spojení – rozhoduje o tom, co se ověří, ne o tom, co se domluví –
proto ji tento skript nečte. Na hardenovaném stroji ale stojí za samostatnou kontrolu: silné suity a slabě
podepsaný certifikát jsou dva nezávislé problémy.
Vyberete platformu, cílovou generaci systému a profil – nástroj z toho složí konfiguraci a než ji nabídne, zkontroluje, že kombinace vůbec dává smysl (protokol bez použitelné suity, suita bez protokolu, suita, kterou daná platforma nezná).
Ciphers\, Hashes\ a
KeyExchangeAlgorithms\, kterými se konfigurují starší systémy,
negeneruje. Co z toho plyne, rozebírají
.
SystemDefaultTlsVersions=1
předá rozhodnutí systému, SchUseStrongCrypto=1 zapne příznak
SCH_USE_STRONG_CRYPTO, kterým Schannel odfiltruje známé slabé
algoritmy. Bez nich může aplikace nad starším target frameworkem chodit na TLS 1.0, i když máte registr
Schannelu nastavený správně.
v2.0.50727 pokrývají .NET 3.5, WOW6432Node
32bitové aplikace na 64bitových Windows – proto všechny čtyři.
Rozhodnutí za výstupem pro Windows. Ke spuštění je číst nemusíte – hodí se, když se někdo ptá, proč je
v jednom .reg souboru vidět dvakrát jiná větev registru, nebo proč
v něm není hodnota, na kterou je zvyklý z hardeningové baseline.
Windows Schannel se konfiguruje dvěma způsoby, které se v praxi mísí podle stáří systému:
| Přístup | Kde | Kdy |
|---|---|---|
| Legacy (per-algoritmus) | Jednotlivé klíče ...SCHANNEL\Ciphers\, \Hashes\, \KeyExchangeAlgorithms\ – enable/disable po jednotlivých algoritmech, žádné řazení preferencí. | Server 2012 R2, Windows 7/8.1 a starší. |
| Moderní (řetězec + protokoly) | SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\<verze>\{Client,Server}\Enabled pro zapnutí/vypnutí verze protokolu, a SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\Functions jako jeden seřazený řetězec cipher suite (ekvivalent Get/Enable/Disable-TlsCipherSuite). | Server 2016/2019/2022/2025, Windows 10 1607+ / 11. |
HKLM\SYSTEM\…\SCHANNEL\Protocols\, pořadí cipher suit do
HKLM\SOFTWARE\Policies\Microsoft\…\SSL\00010002. Není to
nedůslednost – každá polovina je na svém jediném dokumentovaném místě.
Policies je úložiště té zásady, Microsoft nastavování suit
směruje přes GPO, MDM nebo PowerShell a zápis do lokálního klíče
(…\Cryptography\Configuration\Local\SSL\00010002) výslovně
označuje za nepodporovaný: ten drží výchozí pořadí OS a servisní aktualizace ho může přepsat.
Policies je přesně ta, kterou na
doménovém stroji přepíše policy refresh, pokud tutéž zásadu řídí GPO – proto skript na konci připomíná
dvoukrokové ověření. Audit v
naopak čte oba klíče, protože cmdlety Enable-TlsCipherSuite
a Enable-TlsEccCurve zapisují do toho lokálního.
Functions
i pro pole SSL Cipher Suites v GPO – Microsoft ho uvádí na obou místech. Nejdelší seznam, který tento
generátor umí vydat, má 916 znaků (Custom se vším zaškrtnutým), takže se do limitu vejde;
hlídá to i selftest, protože rezerva jsou zhruba dvě jména suit a katalog roste.
0xFFFFFFFF pochází z hardeningových baseline a starších návodů a rozšířila
se jejich kopírováním; aktuální dokumentace Microsoftu ale u obou hodnot – Enabled
i DisabledByDefault – uvádí výhradně 0 nebo 1.
Generátor proto zapisuje 1: chová se identicky a je to tvar, který
Microsoft dokumentuje. Compliance baseline se v tom ale neshodují mezi sebou – DISA STIG
požaduje Enabled = 1 a DisabledByDefault = 0,
kdežto CIS benchmarky pro IIS předepisují 0xFFFFFFFF. Sken, který porovnává
literál, tedy jednu z těch dvou hodnot označí za odchylku vždycky; kterou, záleží na tom, jakou baseline používáte.
Obě hodnoty zapisuje explicitně (ne jen mazáním klíče), aby výsledný stav nezávisel na tom,
co na stroji nastavil někdo před vámi.
ServerMinKeyBitLength)