IBM i Verze 7.3. Zabezpečení Secure Sockets Layer/Transport Layer Security IBM

IBM i Verze 7.3 Zabezpečení Secure Sockets Layer/Transport Layer Security IBM

IBM i Verze 7.3 Zabezpečení Secure Sockets Layer/Transport Layer Security IBM

Poznámka Před použitím těchto informací a produktu, ke kterému se tyto informace vztahují, si přečtěte informace uvedené v části Poznámky na stránce 33. Toto vydání je určeno pro operační systém IBM i 7.3 (číslo produktu 5770-SS1) a pro všechna následná vydání a modifikace, dokud nebude v nových vydáních uvedeno jinak. Tato verze nemůže být provozována na žádném počítači RISC (Reduced Instruction Set Computer) ani na modelech CISC. Tento dokument může obsahovat odkazy na licenční interní kód (LIC). Licenční interní kód je strojový kód, který jste dle podmínek licenční smlouvy IBM pro strojový kód oprávněni užívat. Copyright IBM Corporation 2002, 2015.

Obsah Secure Sockets Layer/Transport Layer Security............... 1 Novinky ve verzi 7.3 systému IBM i........ 1 Soubor ve formátu PDF pro protokol SSL/TLS.... 1 Implementace zabezpečení protokolu SSL/TLS.... 2 Vývěsky zabezpečení............ 3 SSL/TLS systému............. 3 Jak nakódovat použití systémového protokolu SSL/TLS systému............... 3 Nastavení systémového protokolu SSL/TLS systému na systémové úrovni............ 4 Konfigurace protokolu.......... 5 Konfigurace šifrovací sady........ 6 Podpisové algoritmy.......... 10 Minimální velikost klíče RSA....... 13 Pojmenovaná křivka ECDSA....... 13 Opětné vyjednávání.......... 15 Protokol OCSP............. 16 Konfigurace OCSP.......... 17 Stav odvolání OCSP.......... 18 Odvolání certifikátů........... 19 Výběr více certifikátů........... 20 Definice aplikací DCM.......... 21 Protokoly SSL............ 22 Volby specifikace šifrování SSL...... 22 Kritický režim rozšířeného opětného vyjednávání 23 Indikace názvu serveru......... 23 Atributy protokolu OCSP........ 24 OCSP URL............ 24 Zpracování OCSP AIA........ 25 Podpisové algoritmy SSL........ 25 Příkaz SSLCONFIG........... 25 Jak určit, které systémové protokoly SSL/TLS systému a šifrovací sady se na systému používají..... 26 Žurnál auditu............ 26 Trasování kódu LIC.......... 26 Čítače verzí systémového protokolu SSL/TLS systému.............. 27 Odstraňování problémů s protokolem SSL/TLS.... 28 Předpoklady protokolu SSL/TLS........ 30 Zabezpečení aplikací pomocí protokolu SSL/TLS... 30 Související informace pro protokol SSL/TLS..... 31 Poznámky............. 33 Ochranné známky............. 35 Ustanovení a podmínky........... 35 Copyright IBM Corp. 2002, 2015 iii

iv IBM i: Secure Sockets Layer/Transport Layer Security

Secure Sockets Layer/Transport Layer Security Sekce Secure Sockets Layer (SSL)/Transport Layer Security (TLS) popisuje, jak používat protokol SSL/TLS na vašem systému. SSL a TLS jsou generické termíny pro sadu odvětvových standardů umožňujících aplikacím vytvářet zabezpečené komunikační relace v nechráněné síti, jako např. v síti Internet. Protokol SSL se vyvinul a byl nahrazen protokolem TLS. Protokol TLS je přesnější termín, zde se však používá termín protokol SSL/TLS, aby se udrželo spojení s termínem protokol SSL, který zůstává vestavěný v existujících aplikačních rozhraních, dokumentaci a konfiguraci. Verze specifikace protokolu SSL nebo TLS identifikuje relativní úroveň poskytovaného zabezpečení. Neexistují žádné verze specifikace protokolu SSL, které by se měly v současnosti používat. Pouze jedna verze protokolu TLS je povolena za účelem zajištění kompatibility zabezpečení v některých odvětvích. Novinky ve verzi 7.3 systému IBM i Přečtěte si informace o novinkách a významných změnách protokolu Secure Sockets Layer/Transport Layer Security. Vylepšení systémového protokolu SSL/TLS systému v Aktualizována sekce Konfigurace protokolu na stránce 5 systémového protokolu SSL/TLS systému s popisem povolených a výchozích protokolů a voleb konfigurace pro změnu těchto hodnot. v Aktualizována sekce Konfigurace šifrovací sady na stránce 6 systémového protokolu SSL/TLS systému s popisem povolených a výchozích šifrovacích sad a voleb konfigurace pro změnu těchto hodnot. v Aktualizována výchozí sekce Podpisové algoritmy na stránce 10 používaná systémovým protokolem SSL/TLS systému. v Přidána podpora pro Minimální velikost klíče RSA na stránce 13 povolenou pro certifikát, který používá systémový protokol SSL/TLS systému k navázání zabezpečené komunikace. v Přidána sekce Pojmenovaná křivka ECDSA na stránce 13 s popisem voleb konfigurace pro změnu velikostí klíčů ECDSA povolených pro systémový protokol SSL/TLS systému. v Přidány informace o tom, jak získávat poslední novinky, které poskytuje Vývěsky zabezpečení na stránce 3. v Přidány podrobnosti do sekce Jak určit, které systémové protokoly SSL/TLS systému a šifrovací sady se na systému používají na stránce 26. Informace o změnách a novinkách Technické změny jsou v Informačním centru označeny takto: v Symbol v Symbol označuje začátek nových nebo změněných informací. označuje konec nových nebo změněných informací. V souborech ve formátu PDF se u nových nebo změněných informací můžete setkat na levém okraji s revizními značkami (). Více informací o tom, co je nového a co se změnilo, najdete v tématu Sdělení pro uživatele. Soubor ve formátu PDF pro protokol SSL/TLS Soubor ve formátu PDF obsahující tyto informace si můžete zobrazit a vytisknout. Chcete-li si zobrazit nebo vytisknout PDF verzi tohoto dokumentu, vyberte odkaz SSL (Secure Sockets Layer)/TLS (Transport Layer Security). Copyright IBM Corp. 2002, 2015 1

Uložení souborů ve formátu PDF Chcete-li uložit soubor PDF na pracovní stanici za účelem zobrazení nebo tisku: 1. Klepněte pravým tlačítkem myši na odkaz na PDF ve vašem prohlížeči. 2. Klepněte na volbu pro lokální uložení souboru PDF. 3. Přejděte do adresáře, do kterého chcete soubor PDF uložit. 4. Klepněte na tlačítko Uložit. Stažení programu Adobe Reader K prohlížení a tisku souborů ve formátu PDF musíte mít v systému nainstalován program Adobe Reader. Kopii zdarma můžete stáhnout z webového serveru Adobe. Implementace zabezpečení protokolu SSL/TLS Systém obsahuje několik implementací protokolu SSL/TLS. Každá implementace implementuje jednu nebo více verzí protokolů TLS nebo SSL podle odvětvových definic. Implementace musejí spolupracovat s ostatními implementacemi podle specifikací IETF (Internet Engineering Task Force) pro každou verzi protokolu. Každá implementace má jedinečnou charakteristiku a poskytuje různé sady volitelných funkčností. Sada použitých rozhraní API určuje, která implementace se použije pro každou zabezpečenou aplikaci na systému. Pomocí jazyka Java určí nakonfigurovaný poskytovatel JSSE příslušnou implementaci, protože rozhraní jazyka Java jsou standardizovaná. Do aplikace může být také vložena implementace, kterou zná pouze tato aplikace. Tyto implementace jsou dostupné pro vývoj aplikací na systému IBM i. v SSL/TLS systému Aplikace ILE používají systémový protokol SSL/TLS systému. Správu certifikátů provádí produkt DCM (Digital Certificate Manager) (DCM) a typ úložiště certifikátů je CMS (Certificate Management Services) s příponou souboru *.KDB. Aplikace v jazyce Java mohou používat systémový protokol SSL/TLS systému, ale to není běžné. Ještě méně častý bude případ, kdy aplikace v jazyce Java používá systémový protokol SSL/TLS systému a zároveň úložiště klíčů Java Keystore. v IBMJSSE2 (IBMJSSEProvider2) Tento poskytovatel JSSE (Java Secure Socket Extension) obsahuje čistou implementaci jazyka Java pro protokoly SSL/TLS a je dostupný na více platformách. Tato implementace je na seznamu poskytovatelů java.security známá jako com.ibm.jsse2.ibmjsseprovider2. Většina aplikací v jazyce Java na systému používá tohoto poskytovatele JSSE, protože se jedná o výchozího poskytovatele pro všechny verze sady JDK. Certifikáty se obvykle nacházejí v souboru úložiště klíčů jazyka Java (JKS) a jsou spravovány pomocí příkazu nástroje keytool jazyka Java nebo obslužného programu IBM Key Management (ikeyman). Obecné informace o poskytovateli JSSE na systému najdete v části JSSE (Java Secure Socket Extension) Konkrétní podrobnosti naleznete v na platformě nezávislé dokumentaci IBMJSSE2 pro odpovídající verzi sady JDK. V případě sady JDK8 si prohlédněte Reference k zabezpečení pro sadu IBM SDK, Java Technology Edition, verze 8. v OpenSSL Je sada nástrojů typu open source, která implementuje protokoly SSL/TLS a úplnou univerzální knihovnu šifrování. Je k dispozici pouze v systému IBM Portable Application Solutions Environment for i (PASE for i). Certifikáty se obvykle nacházejí v souborech PEM a jsou spravovány pomocí příkazů OpenSSL. Common Information Model Object Manager je aplikace, která tuto implementaci používá. Další informace viz téma Common Information Model. Implementace vestavěné v aplikaci: v Domino for i 2 IBM i: Secure Sockets Layer/Transport Layer Security

Používá vlastní nativní implementaci protokolu SSL/TLS vestavěnou v produktu. Správu konfigurace a certifikátů poskytuje aplikace. Server Domino HTTP lze nakonfigurovat tak, aby používal systémový protokol SSL/TLS systému s certifikáty DCM, ale standardně používá nativní implementaci Domino. Související pojmy: Vývěsky zabezpečení Vývěska zabezpečení se vytvoří, pokud implementace poskytuje zmírnění rizik spojených s ohrožením zabezpečení. Ohrožení zabezpečení může být specifické pro implementaci nebo generické pro protokol. Vývěsky zabezpečení Vývěska zabezpečení se vytvoří, pokud implementace poskytuje zmírnění rizik spojených s ohrožením zabezpečení. Ohrožení zabezpečení může být specifické pro implementaci nebo generické pro protokol. Je důležité, aby byli administrátoři informováni o všech zmírněních rizik jednotlivých implementací. Kvůli rozdílech mezi implementacemi nejsou všechny implementace náchylné ke specifickým ohrožením zabezpečení. Pokud jsou, zmírnění rizik nemusí být pro všechny implementace stejné. Vývěska zabezpečení obsahuje akce, které musejí být provedeny ke zmírnění problému. Pokud nelze protokol nebo algoritmus opravit, zmírnění rizik může tuto funkci zakázat. Poznámka: Výsledkem zakázané funkce mohou být problémy s interoperabilitou pro prostředí, která závisí na protokolu náchylném k ohrožení zabezpečení. Přihlaste se k odběru upozornění, když se vytvoří nebo aktualizují vývěsky zabezpečení protokolu SSL/TLS. Další informace o tomto procesu naleznete v sekci Moje služba odběru upozornění na portálu IBM Support Portal. Přihlaste se k odběru volbou "Urgentní upozornění týkající se podpory", chcete-li obdržet upozornění při každé aktualizaci publikace Vývěska zabezpečení. Publikace Vývěska zabezpečení je agregací jednotlivých vývěsek zabezpečení, které jsou vytvořeny pro konkrétní ohrožení zabezpečení. Přečtěte si každou jednotlivou vývěsku zabezpečení, chcete-li mít aktuální informace. Vývěsky zabezpečení lze aktualizovat po jejich počátečním publikování, jakmile jsou k dispozici nové informace. Aktualizované vývěsky se přesunou zpět na začátek agregované vývěsky. Aktualizovaná vývěska neobsahuje příznaky změny, ale zahrnuje krátkou poznámku označující co se změnilo nebo co bylo přidáno. Znovu si přečtěte celý obsah vývěsky, chcete-li vidět všechny aktualizace. SSL/TLS systému Systémový protokol SSL/TLS systému je sada generických služeb poskytovaných licenčním interním kódem systému IBM i za účelem ochrany komunikací TCP/IP pomocí protokolu SSL/TLS. Systémový protokol SSL/TLS systému je propojen s operačním systémem a kódem soketů LIC a poskytuje dodatečný výkon a zabezpečení. Jak nakódovat použití systémového protokolu SSL/TLS systému Systémový protokol SSL/TLS systému je přístupný vývojářům aplikací z následujících programovacích rozhraní a implementací JSSE. v Rozhraní API produktu Global Security Kit (GSKit) Tato rozhraní API ILE C jsou přístupná z ostatních jazyků ILE. Další informace o Rozhraních API produktu Global Security Kit (GSKit) najdete v tématu Programování soketů. v Integrovaná Rozhraní API SSL_ systému IBM i Tato rozhraní API ILE C jsou přístupná z ostatních jazyků ILE. Nekódujte do tohoto zamítnutého rozhraní. Tato sada rozhraní API neposkytuje novější funkce zabezpečení dostupné v produktu GSKit, což je doporučené rozhraní C. Secure Sockets Layer/Transport Layer Security 3

v Integrovaná implementace JSSE systému IBM i Implementace JSSE systému IBM i je dostupná pro sady JDK 7 a JDK 8. Tato implementace je v seznamu poskytovatelů java.security známá jako com.ibm.i5os.jsse.jsseprovider. Aplikace protokolu SSL/TLS od IBM nebo obchodních partnerů IBM či dodavatelů ISV nebo zákazníků, kteří používají jedno ze tří výše uvedených rozhraní systémového protokolu SSL/TLS systému, používají systémový protokol SSL/TLS systému. Například FTP a Telnet jsou aplikace IBM, které využívají systémový protokol SSL/TLS systému. Ne všechny aplikace s povoleným protokolem SSL/TLS, které jsou spuštěné na systému IBM i, používají systémový protokol SSL/TLS systému. Nastavení systémového protokolu SSL/TLS systému na systémové úrovni Systémový protokol SSL/TLS systému má mnoho atributů, které určují, jak jsou vyjednávány zabezpečené relace. Každá hodnota atributu je nastavena jedním ze tří způsobů: 1. Vývojář aplikací nastavují explicitní hodnotu atributu pomocí kódu. 2. Vývojář aplikací vytvoří uživatelské rozhraní, ve kterém může administrátor aplikace nepřímo nastavit hodnotu tohoto atributu. 3. Vývojář aplikací nenastavuje hodnotu atributu. Systémový protokol SSL/TLS systému použije výchozí hodnotu atributu. Požadavky na kompatibilitu zabezpečení se mění v průběhu životnosti vydání. Aby byla zachována kompatibilita, administrátoři systému musí přepsat některé hodnoty atributů. Systémový protokol SSL/TLS poskytuje pro implementaci této úrovně řízení různá nastavení na systémové úrovni. Existují dva typy řízení na systémové úrovni: v Zcela zakázat hodnotu atributu Zakázaná hodnota se ignoruje, když je použita kterýmkoli ze tří způsobů nastavení hodnoty atributu. Aplikace zjistí závažné selhání, pokud žádná platná hodnota nezůstane pro atribut povolena. Aplikace zjistí selhání, pokud partner vyžaduje zakázanou hodnotu. v Zakázat výchozí hodnotu atributu Změní pouze aplikace, které používají předvolby systémového protokolu SSL/TLS systému k nastavení tohoto konkrétního atributu. Selhání aplikace, pokud partner požaduje zakázanou hodnotu. Nastavení na systémové úrovni jsou kontrolována pomocí kombinace těchto rozhraní: v Systémové hodnoty protokolu SSL/TLS. v Příkaz SSLCONFIG modulu Advanced Analysis nástrojů SST (System Service Tools), jak je uvedeno. Pro následující atributy systémového protokolu SSL/TLS systému se mohou povolené hodnoty, výchozí hodnoty, nebo obojí, změnit na systémové úrovni. Související pojmy: Příkaz SSLCONFIG na stránce 25 Příkaz SSLCONFIG je příkaz modulu Advanced Analysis nástrojů SST (System Service Tools), který umožňuje zobrazení nebo změnu celosystémových výchozích vlastností systémového protokolu SSL/TLS systému. Související informace: Systémová hodnota SSL/TLS: QSSLPCL Systémová hodnota SSL/TLS: QSSLCSLCTL Systémová hodnota SSL/TLS: QSSLCSL 4 IBM i: Secure Sockets Layer/Transport Layer Security

Konfigurace protokolu Systémový protokol SSL/TLS systému má infrastrukturu pro podporu více protokolů. Následující protokoly mohou být podporovány systémovým protokolem SSL/TLS systému: v Transport Layer Security, verze 1.2 (TLSv1.2) v Transport Layer Security, verze 1.1 (TLSv1.1) v Transport Layer Security, verze 1.0 (TLSv1.0) v Secure Sockets Layer, verze 3.0 (SSLv3) v Secure Sockets Layer, verze 2.0 (SSLv2) Protokol SSLv2 nelze použít, je-li protokol TLSv1.2 povolen na systému v systémové hodnotě QSSLPCL. POZOR: IBM důrazně doporučuje vždy spustit server IBM i s následujícími sí ovými protokoly zakázanými. Použití voleb konfigurace poskytovaných IBM pro povolení slabých protokolů bude mít za následek, že server IBM i bude konfigurován tak, aby umožňoval použití seznamu slabých protokolů. Výsledkem této konfigurace bude, že server IBM i bude potenciálně vystaven riziku narušení zabezpečení sítě. IBM SE ZŘÍKÁ A VY PŘEBÍRÁTE VEŠKEROU ZODPOVĚDNOST ZA JAKÉKOLI POŠKOZENÍ NEBO ZTRÁTU, VČETNĚ ZTRÁTY DAT, KTERÁ JE DŮSLEDKEM NEBO SOUVISÍ S POUŽITÍM UVEDENÉHO SÍŤOVÉHO PROTOKOLU. Slabé protokoly (duben 2016): v Secure Sockets Layer, verze 3.0 (SSLv3) v Secure Sockets Layer, verze 2.0 (SSLv2) Povolené protokoly Nastavení systémové hodnoty QSSLPCL identifikuje specifické protokoly povolené na systému. Aplikace mohou vyjednávat zabezpečené relace pouze s protokoly uvedenými v parametru QSSLPCL. Chcete-li například omezit implementaci systémového protokolu SSL/TLS systému, aby používal pouze protokol TLSv1.2 a nepovolil žádné starší verze protokolu, nastavte parametr QSSLPCL, aby obsahoval pouze hodnotu *TLSV1.2. Speciální hodnota *OPSYS parametru QSSLCSLCTL umožňuje, aby operační systém změnil protokoly povolené na systému na hranici vydání. Hodnota QSSLPCL zůstane stejná, když se systém upgraduje na novější vydání operačního systému. Pokud hodnota parametru QSSLPCL není *OPSYS, administrátor musí ručně přidat novější verze protokolu do parametru QSSLPCL poté, co se systém přesune na nové vydání. Vydání systému IBM i i 6.1 i 7.1 i 7.2 i 7.3 Výchozí protokoly Definice hodnoty QSSLPCL *OPSYS *TLSV1, *SSLV3 *TLSV1, *SSLV3 *TLSV1.2, *TLSV1.1, *TLSV1 *TLSV1.2, *TLSV1.1, *TLSV1 Pokud aplikace neuvádí povolené protokoly, použijí se výchozí protokoly systémového protokolu SSL/TLS systému. Aplikace používají tento návrh kvůli podpoře nového protokolu TLS bez nutnosti změn v kódu aplikace. Výchozí nastavení protokolu nemá význam pro aplikace, které explicitně uvádějí protokoly povolené pro danou aplikaci. Výchozí protokoly na systému jsou průnikem povolených protokolů z parametru QSSLPCL a vhodných výchozích protokolů. Výchozí seznam vhodných protokolů je konfigurován pomocí příkazu SSLCONFIG modulu Advanced Analysis nástrojů SST (System Service Tools). Secure Sockets Layer/Transport Layer Security 5

Chcete-li určit aktuální hodnotu výchozího seznamu vhodných protokolů a výchozí seznam protokolů na systému, použijte volbu display příkazu SSLCONFIG. Administrátor by měl uvažovat o změně nastavení výchozího protokolu pouze v případě, kdy žádné jiné nastavení konfigurace neumožňuje úspěšnou spolupráci aplikace s partnery. Doporučuje se povolit starší protokol pouze pro specifickou aplikaci, která jej vyžaduje. Pokud má aplikace definici aplikace, ke zpřístupnění dojde pomocí správce DCM (Digital Certificate Manager). Varování: Přidání staršího protokolu na výchozí seznam bude mít za následek vystavení všech aplikací, které používají výchozí seznam, jako cílů pro známá ohrožení zabezpečení. Načtení PTF zabezpečení skupiny může mít za následek odebrání protokolu z výchozího seznamu protokolů. Přihlaste se k odběru vývěsky zabezpečení, chcete-li obdržet upozornění, když v rámci úprav zabezpečení dojde k tomuto typu změny. Pokud administrátor přidá zpět vhodný protokol, který byl odebrán pomocí PTF zabezpečení, systém si tuto změnu zapamatuje a nebude jej odebírat znovu při dalším použití PTF zabezpečení. Pokud musí být výchozí protokoly na systému změněny, použijte ke změně hodnoty volbu signaturealgorithmlist příkazu SSLCONFIG. Volba -h příkazu SSLCONFIG zobrazí panel nápovědy, který popisuje, jak nastavit seznam protokolů. Pouze verze protokolů uvedené v textu nápovědy je možné přidat na seznam. Poznámka: Nastavení volby eligibledefaultprotocols příkazu SSLCONFIG se resetuje instalací kódu LIC (Licensed Internal Code). Příklad nastavení protokolu TLSv1.2 jako jediného výchozího protokolu na systému: SSLCONFIG -eligibledefaultprotocols:10 Vydání systému IBM i i 6.1 i 7.1 i 7.2 i 7.3 Související pojmy: Výchozí seznam vhodných protokolů s poslední PTF skupiny zabezpečení TLSv1.0 TLSv1.0 TLSv1.2, TLSv1.1, TLSv1.0 TLSv1.2, TLSv1.1, TLSv1.0 Příkaz SSLCONFIG na stránce 25 Příkaz SSLCONFIG je příkaz modulu Advanced Analysis nástrojů SST (System Service Tools), který umožňuje zobrazení nebo změnu celosystémových výchozích vlastností systémového protokolu SSL/TLS systému. Vývěsky zabezpečení na stránce 3 Vývěska zabezpečení se vytvoří, pokud implementace poskytuje zmírnění rizik spojených s ohrožením zabezpečení. Ohrožení zabezpečení může být specifické pro implementaci nebo generické pro protokol. Související informace: Systémová hodnota SSL/TLS: QSSLPCL Konfigurace šifrovací sady Systémový protokol SSL/TLS systému má infrastrukturu pro podporu více šifrovacích sad. Šifrovací sady jsou specifikovány rozdílně pro každé programovací rozhraní. Následující tabulka uvádí specifikace šifrovacích sad, které jsou zde uvedeny ve formátu systémové hodnoty, kterou může systémový protokol SSL/TLS systému podporovat pro každou verzi protokolu. Podporované specifikace šifrovacích sad daného protokolu jsou označeny znakem "X" v příslušném sloupci. Tabulka 1. Podporované specifikace šifrovacích sad pro protokoly TLS a SSL Znázornění systémové hodnoty QSSLCSL TLSv1.2 TLSv1.1 TLSv1.0 SSLv3 SSLv2 *ECDHE_ECDSA_AES_128_GCM_SHA256 X 6 IBM i: Secure Sockets Layer/Transport Layer Security

Tabulka 1. Podporované specifikace šifrovacích sad pro protokoly TLS a SSL (pokračování) Znázornění systémové hodnoty QSSLCSL TLSv1.2 TLSv1.1 TLSv1.0 SSLv3 SSLv2 *ECDHE_ECDSA_AES_256_GCM_SHA384 X *ECDHE_RSA_AES_128_GCM_SHA256 X *ECDHE_RSA_AES_256_GCM_SHA384 X *RSA_AES_128_GCM_SHA256 X *RSA_AES_256_GCM_SHA384 X *ECDHE_ECDSA_AES_128_CBC_SHA256 X *ECDHE_ECDSA_AES_256_CBC_SHA384 X *ECDHE_RSA_AES_128_CBC_SHA256 X *ECDHE_RSA_AES_256_CBC_SHA384 X *RSA_AES_128_CBC_SHA256 X *RSA_AES_128_CBC_SHA X X X *RSA_AES_256_CBC_SHA256 X *RSA_AES_256_CBC_SHA X X X *ECDHE_ECDSA_3DES_EDE_CBC_SHA X *ECDHE_RSA_3DES_EDE_CBC_SHA X *RSA_3DES_EDE_CBC_SHA X X X X *ECDHE_ECDSA_RC4_128_SHA X *ECDHE_RSA_RC4_128_SHA X *RSA_RC4_128_SHA X X X X *RSA_RC4_128_MD5 X X X X X *RSA_DES_CBC_SHA X X X *RSA_EXPORT_RC4_40_MD5 X X X *RSA_EXPORT_RC2_CBC_40_MD5 X X X *RSA_RC2_CBC_128_MD5 X *RSA_3DES_EDE_CBC_MD5 X *RSA_DES_CBC_MD5 X *ECDHE_ECDSA_NULL_SHA X *ECDHE_RSA_NULL_SHA X *RSA_NULL_SHA256 X *RSA_NULL_SHA X X X X *RSA_NULL_MD5 X X X X Povolené šifrovací sady Nastavení systémové hodnoty QSSLCSL identifikuje specifické šifrovací sady povolené na systému. Aplikace mohou vyjednávat zabezpečené relace pouze s šifrovací sadou uvedenou v parametru QSSLCSL. Bez ohledu na to, co aplikace dělá s kódem nebo konfigurací, nemůže vyjednávat zabezpečené relace s šifrovací sadou, pokud není uvedena v parametru QSSLCSL. Konfigurace jednotlivých aplikací určuje, které z povolených šifrovacích sad se pro danou aplikaci používají. Chcete-li například omezit implementaci systémového protokolu SSL/TLS systému, aby používala pouze výměnu klíčů ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) a nikoli RSA: Secure Sockets Layer/Transport Layer Security 7

1. Změňte systémovou hodnotu QSSLCSLCTL na speciální hodnotu *USRDFN, chcete-li umožnit úpravu systémové hodnoty QSSLCSL. 2. Odeberte z parametru QSSLCSL všechny šifrovací sady, které neobsahují klíčové slovo ECDHE. Speciální hodnota *OPSYS systémové hodnoty QSSLCSLCTL umožňuje, aby operační systém změnil šifrovací sady povolené na systému na hranici vydání. Hodnota QSSLCSLCTL zůstane stejná, když se systém upgraduje na novější vydání operačního systému. Pokud je hodnota QSSLCSLCTL *USRDFN, musí administrátor do parametru QSSLCSL ručně přidat novější šifrovací sady poté, co se systém přesune na nové vydání. Nastavení hodnoty QSSLCSLCTL zpět na *OPSYS také přidá nové hodnoty do parametru QSSLCSL. Šifrovací sadu nelze přidat do parametru QSSLCSL, pokud není protokol SSL/TLS požadovaný šifrovací sadou nastaven v parametru QSSLPCL. Šifrovací sady povolené hodnotou QSSLCSLCTL *OPSYS v systému IBM i 7.3 se zobrazí v systémové hodnotě QSSLCSL. Následuje jejich seznam: v *ECDHE_ECDSA_AES_128_GCM_SHA256 v *ECDHE_ECDSA_AES_256_GCM_SHA384 v *ECDHE_RSA_AES_128_GCM_SHA256 v *ECDHE_RSA_AES_256_GCM_SHA384 v *RSA_AES_128_GCM_SHA256 v *RSA_AES_256_GCM_SHA384 v *ECDHE_ECDSA_AES_128_CBC_SHA256 v *ECDHE_ECDSA_AES_256_CBC_SHA384 v *ECDHE_RSA_AES_128_CBC_SHA256 v *ECDHE_RSA_AES_256_CBC_SHA384 v *RSA_AES_128_CBC_SHA256 v *RSA_AES_128_CBC_SHA v *RSA_AES_256_CBC_SHA256 v *RSA_AES_256_CBC_SHA v *ECDHE_ECDSA_3DES_EDE_CBC_SHA v *ECDHE_RSA_3DES_EDE_CBC_SHA v *RSA_3DES_EDE_CBC_SHA 8 IBM i: Secure Sockets Layer/Transport Layer Security

POZOR: IBM důrazně doporučuje vždy spustit server IBM i s následujícími šifrovacími sadami zakázanými. Použití voleb konfigurace poskytovaných IBM pro povolení slabých šifrovacích sad bude mít za následek, že server IBM i bude konfigurován tak, aby umožňoval použití seznamu slabých šifrovacích sad. Výsledkem této konfigurace bude, že server IBM i bude potenciálně vystaven riziku narušení zabezpečení sítě. IBM SE ZŘÍKÁ A VY PŘEBÍRÁTE VEŠKEROU ZODPOVĚDNOST ZA JAKÉKOLI POŠKOZENÍ NEBO ZTRÁTU, VČETNĚ ZTRÁTY DAT, KTERÁ JE DŮSLEDKEM NEBO SOUVISÍ S POUŽITÍM UVEDENÝCH ŠIFROVACÍCH SAD. Slabé šifrovací sady (duben 2016): v SSL_RSA_WITH_RC4_128_SHA v SSL_RSA_WITH_RC4_128_MD5 v SSL_RSA_WITH_NULL_MD5 v SSL_RSA_WITH_NULL_SHA v SSL_RSA_WITH_DES_CBC_SHA v SSL_RSA_EXPORT_WITH_RC4_40_MD5 v SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 v SSL_RSA_WITH_RC2_CBC_128_MD5 v SSL_RSA_WITH_DES_CBC_MD5 v SSL_RSA_WITH_3DES_EDE_CBC_MD5 v TLS_ECDHE_ECDSA_WITH_NULL_SHA v TLS_ECDHE_ECDSA_WITH_RC4_128_SHA v TLS_ECDHE_RSA_WITH_NULL_SHA v TLS_ECDHE_RSA_WITH_RC4_128_SHA Výchozí šifrovací sady Když aplikace neuvádí šifrovací sady, které mohou být povoleny, použije se seřazený výchozí seznam šifrovacích sad systémového protokolu SSL/TLS systému. Aplikace používají tento návrh kvůli budoucí podpoře nového protokolu TLS bez nutnosti změn v kódu aplikace. Výchozí nastavení šifrovací sady nemá význam pro aplikace, které explicitně uvádějí šifrovací sady povolené pro danou aplikaci. Výchozí šifrovací sady na systému jsou průnikem povolených šifrovacích sad z parametru QSSLCSL a vhodných výchozích šifrovacích sad. Výchozí seznam vhodných šifrovacích sad je konfigurován pomocí příkazu SSLCONFIG modulu Advanced Analysis nástrojů SST (System Service Tools). Pořadí na výchozím seznamu šifrovacích sad je pořadí, v jakém se šifrovací sady zobrazí v systémové hodnotě QSSLCSL. Chcete-li pořadí změnit, změňte parametr QSSLCSL. Chcete-li určit aktuální hodnotu výchozího seznamu vhodných šifrovacích sad a výchozí seznam šifrovacích sad na systému, použijte volbu display příkazu SSLCONFIG. Administrátor by měl uvažovat o změně nastavení výchozího seznamu šifrovacích sad pouze v případě, kdy žádné jiné nastavení konfigurace neumožňuje úspěšnou spolupráci aplikace s partnery. Doporučuje se povolit starší šifrovací sadu pouze pro specifickou aplikaci, která ji vyžaduje. Pokud má aplikace definici aplikace, ke zpřístupnění dojde pomocí správce DCM (Digital Certificate Manager). Varování: Přidání starší šifrovací sady na výchozí seznam bude mít za následek vystavení všech aplikací, které používají výchozí seznam, jako cílů pro známá ohrožení zabezpečení. Načtení PTF zabezpečení skupiny může mít za následek odebrání šifrovací sady z výchozího seznamu šifrovacích sad. Přihlaste se k odběru vývěsky zabezpečení, Secure Sockets Layer/Transport Layer Security 9

chcete-li obdržet upozornění, když v rámci úprav zabezpečení dojde k tomuto typu změny. Pokud administrátor přidá zpět vhodnou šifrovací sadu, která byla odebrána pomocí PTF zabezpečení, systém si tuto změnu zapamatuje a nebude ji odebírat znovu při dalším použití PTF zabezpečení. Pokud musí být výchozí seznam šifrovacích sad na systému změněn, použijte ke změně hodnoty volbu eligibledefaultciphersuites příkazu SSLCONFIG. Volba -h příkazu SSLCONFIG zobrazí panel nápovědy, který popisuje, jak zadat změněný seznam šifrovacích sad. Text nápovědy zahrnuje zkrácené hodnoty požadované touto volbou. Pouze šifrovací sady uvedené v textu nápovědy je možné přidat na seznam. Poznámka: Nastavení volby eligibledefaultciphersuites příkazu SSLCONFIG se resetuje instalací kódu LIC (Licensed Internal Code). Příklad nastavení pouze šifrovacích sad ECDHE jako předvoleb na daném systému: SSLCONFIG -eligibledefaultciphersuites:ye,yd,yc,yb,ya,y9,y8,y7,y6,y3 Šifrovací sady zahrnuté ve výchozím seznamu vhodných šifrovacích sad s poslední PTF skupiny zabezpečení jsou: v *ECDHE_ECDSA_AES_128_GCM_SHA256 v *ECDHE_ECDSA_AES_256_GCM_SHA384 v *ECDHE_RSA_AES_128_GCM_SHA256 v *ECDHE_RSA_AES_256_GCM_SHA384 v *RSA_AES_128_GCM_SHA256 v *RSA_AES_256_GCM_SHA384 v *ECDHE_ECDSA_AES_128_CBC_SHA256 v *ECDHE_ECDSA_AES_256_CBC_SHA384 v *ECDHE_RSA_AES_128_CBC_SHA256 v *ECDHE_RSA_AES_256_CBC_SHA384 v *RSA_AES_128_CBC_SHA256 v *RSA_AES_128_CBC_SHA v *RSA_AES_256_CBC_SHA256 v *RSA_AES_256_CBC_SHA v *ECDHE_ECDSA_3DES_EDE_CBC_SHA v *ECDHE_RSA_3DES_EDE_CBC_SHA v *RSA_3DES_EDE_CBC_SHA Související pojmy: Příkaz SSLCONFIG na stránce 25 Příkaz SSLCONFIG je příkaz modulu Advanced Analysis nástrojů SST (System Service Tools), který umožňuje zobrazení nebo změnu celosystémových výchozích vlastností systémového protokolu SSL/TLS systému. Související informace: Systémová hodnota SSL/TLS: QSSLCSLCTL Systémová hodnota SSL/TLS: QSSLCSL Podpisové algoritmy Protokol TLSv1.2 definuje podpisové a hašovací algoritmy, které se používají u digitálních podpisů, jako nezávislý atribut. Dříve byly tyto algoritmy určovány vyjednanou šifrovací sadou. Systémový protokol SSL/TLS systému má infrastrukturu pro podporu více podpisových algoritmů. Seřazený seznam povolených párů podpisového a šifrovacího algoritmu slouží v protokolu TLSv1.2 ke dvěma účelům (ve starších protokolech však nemá žádný význam): Výběr certifikátů 10 IBM i: Secure Sockets Layer/Transport Layer Security

Podpis zprávy Seřazený seznam podpisových algoritmů se pošle partnerovi, jakmile systémový protokol SSL/TLS systému během navázání komunikace požádá o certifikát. Partner použije přijatý seznam v procesu výběru certifikátu jako vodítko. Partner by si měl vybrat takový certifikát, který bude odpovídat předloženému seznamu, ale to neplatí ve všech implementacích a konfiguracích. Systémový protokol SSL/TLS systému považuje přijatý certifikát s neočekávaným podpisovým algoritmem za chybu relace, pokud není nakonfigurované volitelné ověření klienta. Když systémový protokol SSL/TLS systému obdrží žádost o certifikát a nemůže vybrat odpovídající certifikát, odešle nějaký dostupný neodpovídající certifikát RSA nebo ECDSA. Partner určí, zda bude výsledkem tohoto certifikátu chyba relace. Další informace o logice výběru certifikátu systémového protokolu SSL/TLS systému najdete v části Výběr více certifikátů na stránce 20. Seznam párů algoritmů omezuje, které podpisové a hašovací algoritmy lze použít pro digitální podpisy zpráv při navázání spojení. Podpisový algoritmus zprávy pro navázání komunikace protokolu TLSv1.2 se může lišit od podpisového algoritmu certifikátu, který se používá pro relaci. Zpráva pro navázání komunikace může být například chráněna certifikátem SHA512, přestože byl pro relaci vybrán certifikát MD5. Systémový protokol SSL/TLS systému má infrastrukturu pro podporu následujících podpisových algoritmů: v ECDSA_SHA512 v ECDSA_SHA384 v ECDSA_SHA256 v ECDSA_SHA224 v ECDSA_SHA1 v RSA_SHA512 v RSA_SHA384 v RSA_SHA256 v RSA_SHA224 v RSA_SHA1 v RSA_MD5 Povolené podpisové algoritmy Příkaz SSLCONFIG modulu Advanced Analysis nástrojů SST (System Service Tools) identifikuje podpisové algoritmy povolené na systému. Aplikace mohou vyjednávat zabezpečené relace pouze s podpisovými algoritmy, které jsou uvedeny ve volbě supportedsignaturealgorithmlist příkazu SSLCONFIG. Chcete-li určit aktuální hodnotu seznamu povolených podpisových algoritmů na systému, použijte volbu display příkazu SSLCONFIG. Pokud musí být seznam povolených podpisových algoritmů na systému změněn, použijte ke změně hodnoty volbu supportedsignaturealgorithmlist příkazu SSLCONFIG. Volba -h příkazu SSLCONFIG zobrazí panel nápovědy, který popisuje, jak nastavit seznam podpisových algoritmů. Pouze verze podpisových algoritmů uvedené v textu nápovědy je možné přidat na seznam. Poznámka: Nastavení volby supportedsignaturealgorithmlist příkazu SSLCONFIG se resetuje instalací kódu LIC (Licensed Internal Code). Příklad nastavení podpisových algoritmů ECDSA a RSA jako podporovaných podpisových algoritmů na systému: SSLCONFIG -supportedsignaturealgorithmlist:36,35,34,33,32,16,15,14,13,12 Systémový protokol SSL/TLS systému se dodává s následujícím seznamem podporovaných podpisových algoritmů: v ECDSA_SHA512 v ECDSA_SHA384 v ECDSA_SHA256 Secure Sockets Layer/Transport Layer Security 11

v ECDSA_SHA224 v ECDSA_SHA1 v RSA_SHA512 v RSA_SHA384 v RSA_SHA256 v RSA_SHA224 v RSA_SHA1 v RSA_MD5 Výchozí podpisové algoritmy Pokud aplikace neuvádí seznam podpisových algoritmů, použije se výchozí seznam podpisových algoritmů systémového protokolu SSL/TLS systému. Aplikace používají tento návrh kvůli podpoře nového protokolu TLS bez nutnosti změn v kódu aplikace. Výchozí seznam podpisových algoritmů nemá význam pro aplikace, které explicitně uvádějí seznam podpisových algoritmů pro danou aplikaci. Výchozí seznam podpisových algoritmů na systému je průnikem seznamu povolených podpisových algoritmů a výchozího seznamu vhodných podpisových algoritmů. Výchozí seznam vhodných podpisových algoritmů je konfigurován pomocí volby signaturealgorithmlist příkazu SSLCONFIG. Chcete-li určit aktuální hodnotu výchozího seznamu vhodných podpisových algoritmů na systému, použijte volbu display příkazu SSLCONFIG. Administrátor by měl uvažovat o změně nastavení výchozího podpisového algoritmu pouze v případě, kdy žádné jiné nastavení konfigurace neumožňuje úspěšnou spolupráci aplikace s partnery. Doporučuje se povolit starší podpisový algoritmus pouze pro specifickou aplikaci, která jej vyžaduje. Pokud má aplikace definici aplikace, ke zpřístupnění dojde pomocí správce DCM (Digital Certificate Manager). Pokud musí být výchozí seznam podpisových algoritmů na systému změněn, použijte ke změně hodnoty volbu signaturealgorithmlist příkazu SSLCONFIG. Volba -h příkazu SSLCONFIG zobrazí panel nápovědy, který popisuje, jak nastavit seznam podpisových algoritmů. Pouze verze podpisových algoritmů uvedené v textu nápovědy je možné přidat na seznam. Poznámka: Nastavení volby signaturealgorithmlist příkazu SSLCONFIG se resetuje instalací kódu LIC (Licensed Internal Code). Příklad nastavení podpisových algoritmů ECDSA jako výchozích podpisových algoritmů na systému: SSLCONFIG -signaturealgorithmlist:36,35,34,33,32 Následující seznam představuje seřazený seznam dodávaných výchozích podpisových algoritmů: v ECDSA_SHA512 v ECDSA_SHA384 v ECDSA_SHA256 v ECDSA_SHA224 v ECDSA_SHA1 v RSA_SHA512 v RSA_SHA384 v RSA_SHA256 v RSA_SHA224 v RSA_SHA1 Související pojmy: 12 IBM i: Secure Sockets Layer/Transport Layer Security

Příkaz SSLCONFIG na stránce 25 Příkaz SSLCONFIG je příkaz modulu Advanced Analysis nástrojů SST (System Service Tools), který umožňuje zobrazení nebo změnu celosystémových výchozích vlastností systémového protokolu SSL/TLS systému. Minimální velikost klíče RSA Minimální velikost klíče RSA povolená pro certifikát použitá kteroukoli stranou při navázání komunikace může být pro systémový protokol SSL/TLS systému omezena. Digitální certifikát RSA má dvojici klíčů veřejný/soukromý. Velikost klíčů ve dvojici se měří v bitech. Existují zásady slučitelnosti zabezpečení, které vyžadují, aby velikost klíče RSA splňovala minimální úroveň. Velikost klíče RSA se nastavuje při vytvoření certifikátu. Administrátor systému musí vytvořit nové certifikáty s větším klíčem RSA, které nahradí jakýkoli certifikát, který používá menší velikost klíče, než je minimální nastavená hodnota velikosti klíče RSA. Systémový protokol SSL/TLS systému má nastavení systémové úrovně kvůli omezení velikosti klíče RSA, která je povolená pro používaný certifikát. Omezení platí pro lokální i partnerské certifikáty a zahrnuje jak certifikáty klienta, tak serveru. Nastavení minimální velikosti klíče má za následek selhání při navázání komunikace, pokud certifikát jedné ze stran obsahuje menší klíč RSA, než je minimální velikost. Než administrátor změní nastavení systémové úrovně pro minimální velikost klíče, chcete-li se vyhnout selhání aplikace, ručně zkontrolujte a nahra te existující lokální certifikáty, které mají menší klíče, než je požadované minimum. Nastavení omezení pro minimální velikost klíče RSA zabrání spolupráci s partnery, kteří používají certifikáty RSA s menší velikostí klíče, než je minimum. Počáteční nastavení minimální velikosti klíče RSA na systémové úrovni je 0. Hodnota 0 velikost klíče nijak neomezuje. Nastavení systémové úrovně systémového protokolu SSL/TLS se změní pomocí příkazu SSLCONFIG modulu Advanced Analysis nástrojů SST (System Service Tools). Chcete-li zjistit aktuální nastavení, použijte volbu display příkazu SSLCONFIG. Použijte volbu minimumrsakeysize příkazu SSLCONFIG ke změně hodnoty. Volba -h příkazu SSLCONFIG zobrazí panel nápovědy, který popisuje, jak nastavit velikost klíče. Například, pomocí následujícího příkazu nastavte 2 kb (2048 bitů) jako minimální velikost klíče RSA povolenou na systému: SSLCONFIG -minimumrsakeysize:2048 Atribut produktu GSKit GSK_MIN_RSA_KEY_SIZE může pro aplikaci nastavit větší minimální velikost klíče, pokud mají být jednotlivé aplikace více omezující než zbytek systému. Pokud má aplikace nastavenou hodnotu GSK_MIN_RSA_KEY_SIZE menší, než je volba minimumrsakeysize příkazu SSLCONFIG, použije se hodnota minimumrsakeysize příkazu SSLCONFIG a pokus aplikace o omezení minimální velikosti klíče se bude ignorovat. Certifikáty ECDSA nejsou tímto nastavením ovlivněny, protože nemají klíč RSA. Související pojmy: Příkaz SSLCONFIG na stránce 25 Příkaz SSLCONFIG je příkaz modulu Advanced Analysis nástrojů SST (System Service Tools), který umožňuje zobrazení nebo změnu celosystémových výchozích vlastností systémového protokolu SSL/TLS systému. Pojmenovaná křivka ECDSA Systémový protokol SSL/TLS systému podporuje certifikáty založené na algoritmu ECDSA (Elliptic Curve Digital Signature Algorithm). Velikost klíče certifikátu ECDSA je určena pojmenovanou křivkou nastavenou při vytvořená certifikátu. Systémový protokol SSL/TLS systému a správce DCM (Digital Certificate Manager) mají infrastrukturu pro podporu následujících pojmenovaných křivek: v Secp521r1 Secure Sockets Layer/Transport Layer Security 13

v Secp384r1 v Secp256r1 v Secp224r1 v Secp192r1 Číslo v názvu křivky znamená velikost klíče v bitech, kterou použije správce DCM pro vytvoření certifikátu. Prohlížíte-li certifikát ve správci DCM, velikost klíče přidružená k pojmenované křivce se zobrazí v bitech. Povolené pojmenované křivky Příkaz SSLCONFIG modulu Advanced Analysis nástrojů SST (System Service Tools) identifikuje nastavení na systémové úrovni kvůli omezení velikostí klíčů ECDSA povolené pro použití certifikátů systémovým protokolem SSL/TLS systému. Omezení platí pro lokální i partnerské certifikáty a zahrnuje jak certifikáty klienta, tak serveru. Omezení podporovaného seznamu pojmenovaných křivek má za následek selhání při navázání komunikace, pokud certifikát serveru nebo klienta obsahuje velikost klíče ECDSA, která není na seznamu podporovaných. Chcete-li určit aktuální hodnotu seznamu povolených pojmenovaných křivek Elliptic Curve, použijte volbu display příkazu SSLCONFIG. Pokud se musí seznam povolených pojmenovaných křivek na systému změnit, použijte ke změně hodnoty volbu supportednamedcurve příkazu SSLCONFIG. Volba -h příkazu SSLCONFIG zobrazí panel nápovědy, který popisuje, jak nastavit hodnoty pojmenovaných křivek. Pouze hodnoty pojmenovaných křivek uvedené v textu nápovědy je možné přidat na seznam. Poznámka: Nastavení volby supportednamedcurve příkazu SSLCONFIG se resetuje instalací kódu LIC (Licensed Internal Code). Příklad nastavení velikostí klíčů s počtem 256, 384 a 521 bitů jako seznamu podporovaných pojmenovaných křivek na systému: SSLCONFIG -supportednamedcurve:23,24,25 Systémový protokol SSL/TLS systému se dodává s následujícím seznamem podporovaných pojmenovaných křivek: v Secp521r1 v Secp384r1 v Secp256r1 v Secp224r1 v Secp192r1 Výchozí pojmenované křivky Pokud aplikace neuvádí seznam pojmenovaných křivek, použije se výchozí seznam pojmenovaných křivek systémového protokolu SSL/TLS systému. Aplikace používají tento návrh kvůli podpoře nového protokolu TLS bez nutnosti změn v kódu aplikace. Výchozí seznam pojmenovaných křivek nemá význam pro aplikace, které explicitně uvádějí seznam pojmenovaných křivek pro danou aplikaci. Výchozí seznam pojmenovaných křivek na systému je průnikem seznamu povolených pojmenovaných křivek a výchozího seznamu vhodných pojmenovaných křivek. Výchozí seznam vhodných pojmenovaných křivek je konfigurován pomocí volby namedcurve příkazu SSLCONFIG. Chcete-li určit aktuální hodnotu seznamu výchozích pojmenovaných křivek Elliptic Curve na systému, použijte volbu display příkazu SSLCONFIG. Administrátor by měl uvažovat o změně nastavení výchozí pojmenované křivky pouze v případě, kdy žádné jiné nastavení konfigurace neumožňuje úspěšnou spolupráci aplikace s partnery. Doporučuje se povolit nižší pojmenovanou křivku pouze pro specifickou aplikaci, která ji vyžaduje. Pokud má aplikace definici aplikace, ke zpřístupnění dojde pomocí správce DCM (Digital Certificate Manager). 14 IBM i: Secure Sockets Layer/Transport Layer Security

Pokud musí být výchozí seznam pojmenovaných křivek na systému změněn, použijte ke změně hodnoty volbu namedcurve příkazu SSLCONFIG. Volba -h příkazu SSLCONFIG zobrazí panel nápovědy, který popisuje, jak nastavit seznam pojmenovaných křivek. Pouze pojmenované křivky uvedené v textu nápovědy je možné přidat na seznam. Poznámka: Nastavení volby namedcurve příkazu SSLCONFIG se resetuje instalací kódu LIC (Licensed Internal Code). Příklad nastavení velikostí klíčů s počtem 384 a 521 bitů jako seznamu výchozích pojmenovaných křivek na systému: SSLCONFIG -namedcurve:24,25 Následující seznam uvádí pořadí dodaných výchozích pojmenovaných křivek: v Secp521r1 v Secp384r1 v Secp256r1 Související pojmy: Příkaz SSLCONFIG na stránce 25 Příkaz SSLCONFIG je příkaz modulu Advanced Analysis nástrojů SST (System Service Tools), který umožňuje zobrazení nebo změnu celosystémových výchozích vlastností systémového protokolu SSL/TLS systému. Opětné vyjednávání Zahájení nového vyjednávání o navázání komunikace uvnitř existující zabezpečené relace se nazývá opětné vyjednávání. Existují dvě vlastnosti, které určují charakteristiku opětného vyjednávání systémového protokolu SSL/TLS systému. Existuje řada důvodů, proč má aplikace používat opětné vyjednávání. Opětné vyjednávání může spustit klient i server. Aplikační vrstva si nemusí být vědoma toho, že na žádost partnera se znovu vyjednává zabezpečená relace. Poznámka: Aplikace systémového protokolu SSL/TLS systému produktu GSKit použije k zahájení opětného vyjednávání rozhraní gsk_secure_soc_misc(). Architektura protokolu SSL a TLS tak, jak je definovaná v základním dokumentu RFC, obsahuje nedostatky v opětném vyjednávání. Protokoly nedokážou poskytovat šifrovací verifikaci, že je opětné vyjednávání relace propojeno s existující zabezpečenou relací. Dodatečný RFC 5746 definuje volitelné rozšíření základních protokolů, které tento problém opravuje. Jelikož je RFC 5746 doplňkem dříve definovaného protokolu, nepodporují ho v současnosti všechny implementace protokolu SSL/TLS. Některé implementace protokolu SSL/TLS nebyly aktualizovány nebo je nelze aktualizovat na podporu RFC 5746. Za účelem zajištění kontinuity a interoperability během různých fází tohoto přechodu lze použít dvě vlastnosti opětného vyjednávání pro zadání režimu opětného vyjednávání. Režim opětného vyjednávání protokolu SSL/TLS Předvolba systémového protokolu SSL/TLS systému vyžaduje použití sémantiky RFC 5746 u všech opětně vyjednávaných navázání komunikace. Výchozí režim můžete změnit volbou sslrenegotiation v příkazu SSLCONFIG v modulu Advanced Analysis nástrojů SST (System Service Tools). Tento režim můžete nastavit tak, aby povoloval všechna nezabezpečená opětná vyjednávání nebo aby povoloval pouze zkrácená nezabezpečená opětná vyjednávání. Tyto režimy používejte pouze po velmi pečlivém zvážení. Volba -h příkazu SSLCONFIG zobrazí panel nápovědy, který popisuje, jak nastavit režim opětného vyjednávání protokolu SSL/TLS. Existuje režim, který zablokuje všechna partnerem vyvolaná opětná vyjednávání navázání spojení. Tento režim zabrání realizaci zabezpečeného (dle sémantiky RFC 5746) i nezabezpečeného opětného vyjednávání. Výsledkem tohoto režimu mohou být problémy s interoperabilitou u aplikací, které vyžadují použití opětného vyjednávání. V tomto Secure Sockets Layer/Transport Layer Security 15

režimu je i nadále povoleno lokálně zahájené zabezpečené opětné vyjednávání, jako např. gsk_secure_soc_misc(). Kritický režim rozšířeného opětného vyjednávání protokolu SSL/TLS Kritický režim rozšířeného opětného vyjednávání určuje, kdy systémový protokol SSL/TLS systému vyžaduje, aby všichni partneři poskytli během počátečního vyjednávání relace indikaci opětného vyjednávání dle RFC 5746. Aby obě strany zabezpečené relace byly úplně chráněny před slabinou opětného vyjednávání, musí všechna počáteční vyjednávání indikovat podporu standardu RFC 5746. Tato indikace může být ve tvaru rozšíření TLS "renegotiation_info" nebo ve tvaru hodnoty SCSV (Signaling Cipher Suite Value), jak definuje standard RFC 5746. Kritický režim je standardně zablokován, aby se udržovala interoperabilita s implementacemi protokolu SSL/TLS, které dosud nepoužívají standard RFC 5746. Je-li kritický režim povolen, systémový protokol SSL/TLS systému je omezen na vyjednávání pouze s těmi systémy, které implementují standard RFC 5746. Toto omezení je platné i v případě, že ani jedna ze stran nepodporuje ani nepoužívá opětné vyjednávání. Pokud je známo, že všichni partneři systémového protokolu SSL/TLS systému podporují standard RFC 5746, měl by se tento režim povolit. Výchozí kritický režim rozšířeného opětného vyjednávání můžete změnit příkazem SSLCONFIG modulu Advanced Analysis nástrojů SST (System Service Tools). K dispozici je jedna vlastnost pro klientské aplikace, volba sslrfc5746negotiationrequiredclient příkazu SSLCONFIG, a jedna vlastnost pro serverové aplikace, volba sslrfc5746negotiationrequiredserver příkazu SSLCONFIG. Systémový protokol SSL/TLS systému vždy posílá rozšíření TLS "renegotiation_info" nebo hodnotu SCSV v části ClientHello. Hodnota SCSV se posílá pouze v případě, že součástí ClientHello nejsou žádná jiná rozšíření. Související pojmy: Příkaz SSLCONFIG na stránce 25 Příkaz SSLCONFIG je příkaz modulu Advanced Analysis nástrojů SST (System Service Tools), který umožňuje zobrazení nebo změnu celosystémových výchozích vlastností systémového protokolu SSL/TLS systému. Související informace: RFC 5746: "TLS (Transport Layer Security) Renegotiation Indication Extension" Protokol OCSP Protokol OCSP (Online Certificate Status Protocol) nabízí aplikacím způsob, jak určit stav odvolání digitálního certifikátu. Stav odvolání certifikátu, který se kontroluje prostřednictvím protokolu OCSP, poskytuje poslední informace o stavu dostupné prostřednictvím CRL. Implementace kontroly stavu odvolání OCSP se provádí v souladu se standardem RFC 2560. Kontrola stavu odvolání certifikátu OCSP je dostupná pro certifikáty koncových entit. Podporuje se protokol verze 1 přes protokol HTTP a základní typ odpovědi. Stav odvolání certifikátu se kontroluje jménem aplikace prostřednictvím protokolu OCSP, je-li platná minimálně jedna z následujících podmínek: v Je nakonfigurovaná adresa URL odpovídacího modulu OCSP. v Je povolena kontrola Authority Information Access (AIA) a ověřovaný certifikát má rozšíření AIA. Rozšíření AIA musí obsahovat přístupovou metodu PKIK_AD_OCSP s indikátorem URI, který uvádí umístění HTTP odpovídacího modulu OCSP. Poznámka: Na stav odvolání se dotazuje pouze první odpovídací modul OCSP, který je identifikován v rozšíření AIA. Je-li povolena kontrola AIA a adresy URL, odpovídací modul adresy URL bude dotazován jako první. Toto pořadí lze pro jednotlivé aplikace změnit, nastavíte-li atribut rozhraní API produktu Global Security Kit (GSKit), GSK_OCSP_CHECK_AIA_FIRST. Dotaz na druhý odpovídací modul se odešle pouze tehdy, když je výsledkem dotazu odeslaného na první odpovídací modul neurčitý stav odvolání. 16 IBM i: Secure Sockets Layer/Transport Layer Security

Související pojmy: Odvolání certifikátů na stránce 19 Kontrola odvolání certifikátu je jednou fází ověření certifikátu, která se provádí v rámci vyjednávání relace. Ověřujete řetěz certifikátů, abyste se přesvědčili, že daný certifikát nebyl odvolán. Související informace: RFC 2560: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP Konfigurace OCSP Kromě povolení protokolu Online Certificate Status Protocol (OCSP) existuje celá řada vlastností, které může aplikace nakonfigurovat, aby přizpůsobila chování klienta OCSP. Je-li povolena kontrola odvolání OCSP, pošle se požadavek HTTP na odpovídací modul OCSP. Tento požadavek obsahuje informace k identifikaci certifikátu, na jehož stav odvolání se dotazujete, a volitelný podpis. Volitelný podpis se u požadavku používá, aby odpovídací modul snáze ověřil platné požadavky, které obdržel od klientů. Podpisy požadavků jsou standardně zablokovány. Požadavek se posílá odpovídacímu modulu prostřednictvím protokolu HTTP metodou GET nebo POST. Požadavky poslané metodou GET povolují ukládání HTTP do mezipaměti. Pokud konfigurace uvádí, že metoda GET má přednost a že je požadavek menší než 255 bajtů, pošle se požadavek metodou GET. V opačném případě se požadavek pošle metodou POST. Metoda GET je standardně preferovaná. Po odeslání požadavku se kontrola odvolání OCSP blokuje, dokud se neobdrží odpově od odpovídacího modulu nebo dokud jí nevyprší časový limit. Kontrola odvolání je součástí vyjednávání relace. Proto se vyjednávání relace zablokuje, dokud se provádí kontrola odvolání. Je-li časový limit nastavený pro vyjednávání relace menší než nakonfigurovaný časový limit OCSP, použije se i pro časový limit OCSP menší hodnota. Hodnota časového limitu OCSP je standardně nastavena na 10 sekund, ale aplikace jí může nakonfigurovat. Platná odpově je podepsána a obsahuje data, která uvádí stav odvolání certifikátu, na který jste se dotazovali. Stav odvolání certifikátu může být dobrý, neznámý a odvolaný. Odpově musí být podepsána certifikátem, který splňuje minimálně jeden z následujících požadavků: v Podpisový certifikát je pro lokální úložiště certifikátů důvěryhodný. v Podpisový certifikát patří certifikační autoritě (CA), která vydala ověřovaný certifikát. v Podpisový certifikát obsahuje hodnotu id-ad-ocspsigning v rozšíření ExtendedKeyUsage a byl vydán certifikační autoritou, který vydala ověřovaný certifikát. Velikost odezvy se může lišit. Závisí na aplikaci, aby určila maximální povolenou velikost odpovědi. Standardně je maximální povolená velikost odpovědi nastavena na 20 480 bajtů. Je-li odpově větší než maximální povolená velikost, bude se tato odezva ignorovat a bude se považovat za odezvu, která udává neznámý stav certifikátu. Šifrovací hodnota typu nonce je bezpečnostní mechanismus, který se používá k ověření toho, že přijatá odpově je odpovědí na určitý požadavek. Hodnota nonce, což je náhodně vygenerovaný řetězec bitů, se vypočítá a zahrne jak do požadavku, tak i do odpovědi. Je-li povolena kontrola hodnoty nonce, ověří se hodnota nonce z odpovědi s hodnotou poslanou v požadavku. Pokud nejsou hodnoty nonce shodné, bude se odpově ignorovat. Kontrola hodnoty nonce je standardně vypnutá. Kontrola odvolání může zpomalit vyjednávání relace. Avšak ukládání odpovědí OCSP do mezipaměti umožňuje klientovi získat stav odvolání z předchozích požadavků, aniž by musel znovu poslat stejný požadavek. Mezipamě odpovědí OCSP je standardně povolena, ale aplikace jí může zakázat. Server proxy HTTP se může použít jako intermediační server, který obsluhuje požadavky OCSP z odpovědí uložených do mezipaměti nebo který postupuje požadavky na nakonfigurovaný odpovídací modul. Je-li pro danou aplikaci nakonfigurovaný server proxy, budou se požadavky OCSP na aplikaci posílat na tento nakonfigurovaný server. Výchozí port proxy je 80. Server proxy se standardně nekonfiguruje. Rozhraní gsk_attribute_set_buffer(), gsk_attribute_set_numeric_value() a gsk_attribute_set_enum() API, která jsou součástí produktu GSKit (Global Security Kit), se používají ke konfiguraci OCSP pomocí těchto atributů rozhraní API: Secure Sockets Layer/Transport Layer Security 17