IBM i Wersja 7.3. Bezpieczeństwo Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS) IBM

Transkrypt

1 IBM i Wersja 7.3 Bezpieczeństwo Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS) IBM

2

3 IBM i Wersja 7.3 Bezpieczeństwo Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS) IBM

4 Uwaga Przed skorzystaniem z tych informacji oraz z produktu, którego dotyczą, należy przeczytać informacje zawarte w sekcji Uwagi na stronie 35. Niniejsze wydanie dotyczy wersji 7.3 systemu IBM i (numer produktu 5770-SS1) oraz wszystkich kolejnych wersji i modyfikacji tego produktu, chyba że w nowych wydaniach zostanie określone inaczej. Wersja ta nie działa na wszystkich modelach komputerów z procesorem RISC ani na modelach z procesorem CISC. Niniejszy dokument może zawierać odniesienia do Licencjonowanego Kodu Wewnętrznego. Licencjonowany Kod Wewnętrzny jest kodem maszynowym i jest licencjonowany zgodnie z warunkami Umowy Licencyjnej IBM dotyczącej Kodu Maszynowego. Copyright IBM Corporation 2002, 2015.

5 Spis treści Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS) Co nowego w systemie IBM i Plik PDF z informacjami na temat protokołu SSL/TLS.. 1 Implementacje protokołu SSL/TLS Biuletyny bezpieczeństwa Systemowa implementacja protokołu SSL/TLS Jak tworzyć kod korzystający z systemowej implementacji protokołu SSL/TLS Ustawienia systemowej implementacji protokołu SSL/TLS na poziomie systemu Konfiguracja protokołu Konfiguracja zestawów algorytmów szyfrowania.. 7 Algorytmy podpisu Minimalna wielkość klucza RSA Nazwane krzywe ECDSA Renegocjacja Protokół OCSP (Online Certificate Status Protocol).. 18 Konfiguracja protokołu OCSP Status wycofania OCSP Wycofywanie certyfikatów Wybór wielu certyfikatów Definicje aplikacji w programie DCM Protokoły SSL Opcje specyfikacji szyfrów SSL Tryb krytyczny rozszerzonej renegocjacji Wskazanie nazwy serwera Atrybuty protokołu OCSP (Online Certificate Status Protocol) Adres URL protokołu OCSP Przetwarzanie informacji AIA za pomocą protokołu OCSP Algorytmy podpisu SSL Komenda SSLCONFIG Sposoby określania protokołów i zestawów algorytmów szyfrowania systemowej implementacji protokołu SSL/TLS używanych w systemie Kronika kontroli Śledzenie kodu LIC Liczniki wersji protokołów systemowej implementacji protokołu SSL/TLS Rozwiązywanie problemów z protokołem SSL/TLS Wymagania wstępne dotyczące protokołu SSL/TLS Zabezpieczanie aplikacji za pomocą protokołu SSL/TLS 33 Informacje pokrewne dotyczące protokołu SSL/TLS.. 33 Uwagi Znaki towarowe Warunki Copyright IBM Corp. 2002, 2015 iii

6 iv IBM i: Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS)

7 Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS) Sekcja ta opisuje, w jaki sposób można użyć protokołu SSL/TLS w systemie. SSL i TLS to ogólne terminy określające zestaw standardów branżowych używanych do obsługi bezpiecznych sesji komunikacyjnych w niezabezpieczonej sieci, na przykład w Internecie. Protokół SSL podlegał zmianom i przekształcił się w TLS, który zastąpił poprzednie wersje. TLS to bardziej precyzyjny termin, jednak w niniejszej dokumentacji stosowane jest określenie SSL/TLS w celu zachowania odniesień do terminu SSL, zawartych w istniejących interfejsach aplikacji, dokumentacji oraz konfiguracji Wersja specyfikacji protokołu SSL lub TLS określa względny poziom bezpieczeństwa. Obecnie nie powinna być używana żadna z wersji specyfikacji protokołu SSL. W przypadku niektórych branż dozwolone jest korzystanie tylko z jednej wersji protokołu TLS. Co nowego w systemie IBM i 7.3 Poniżej omówiono nowe lub znacznie zmienione informacje dotyczące protokołu Secure Sockets Layer (SSL) / Transport Layer Security (TLS). Udoskonalenia systemowej implementacji protokołu SSL/TLS v Zaktualizowano temat Konfiguracja protokołu na stronie 5: opisano włączone i domyślne protokoły systemowej implementacji protokołu SSL/TLS oraz opcje konfiguracji służące do zmiany tych wartości. v Zaktualizowano temat Konfiguracja zestawów algorytmów szyfrowania na stronie 7: opisano włączone i domyślne zestawy algorytmów szyfrowania systemowej implementacji protokołu SSL/TLS oraz opcje konfiguracji służące do zmiany tych wartości. v Zaktualizowano domyślne algorytmy podpisu używane przez systemową implementację protokołu SSL/TLS. v Dodano obsługę określania minimalnej wielkości klucza RSA dozwolonej dla certyfikatu używanego przez systemową implementację protokołu SSL/TLS do uzgadniania zabezpieczeń. v Dodano temat Nazwane krzywe ECDSA na stronie 15 opisujący opcje konfiguracji służące do zmiany wielkości klucza ECDSA dozwolonego w systemowej implementacji protokołu SSL/TLS. v Dodano informacje na temat sposobów uzyskiwania aktualnych biuletynów bezpieczeństwa. v Dodano szczegółowe informacje na temat sposobów określania protokołów i zestawów algorytmów szyfrowania używanych w systemie. Znajdowanie nowych lub zmienionych informacji Aby ułatwić określenie obszarów, w których zostały wprowadzone zmiany techniczne, w Centrum informacyjnym zastosowano: v symbol v symbol służący do zaznaczania początku nowego lub zmienionego fragmentu; służący do zaznaczania końca nowego lub zmienionego fragmentu. Nowe i zmienione informacje w plikach PDF mogą być oznaczone symbolem na lewym marginesie. Więcej informacji na temat zmian i nowości w bieżącej wersji zawiera Wiadomość dla użytkowników. Plik PDF z informacjami na temat protokołu SSL/TLS Informacje zawarte w tym temacie są także dostępne w postaci pliku PDF, który można wyświetlić i wydrukować. Copyright IBM Corp. 2002,

8 Aby wyświetlić lub pobrać wersję PDF tego dokumentu, wybierz temat Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS). Zapisywanie plików PDF Aby zapisać plik PDF na stacji roboczej w celu jego wyświetlenia lub wydrukowania, wykonaj następujące czynności: 1. Kliknij prawym przyciskiem myszy odsyłacz do pliku PDF w przeglądarce. 2. Kliknij opcję zapisania pliku PDF lokalnie. 3. Przejdź do katalogu, w którym ma zostać zapisany plik PDF. 4. Kliknij opcję Zapisz. Pobieranie programu Adobe Reader Do przeglądania i drukowania plików PDF potrzebny jest program Adobe Reader. Bezpłatną kopię tego programu można pobrać z serwisu WWW firmy Adobe. Implementacje protokołu SSL/TLS System zawiera wiele implementacji protokołu SSL/TLS. Każda implementacja uwzględnia jedną lub więcej wersji protokołu SSL lub TLS zgodnie ze standardami branżowymi. Implementacje muszą współdziałać z innymi implementacjami, zgodnie ze specyfikacjami poszczególnych wersji protokołów, opracowanymi przez grupę wykonawczą IETF (Internet Engineering Task Force). Każda implementacja ma unikalną charakterystykę i udostępnia różne zestawy funkcji opcjonalnych. Używany zestaw funkcji API określa, która implementacja jest używana przez poszczególne chronione aplikacje w systemie. W języku Java skonfigurowany dostawca JSSE określa implementację, ponieważ interfejsy języka Java są standardowe. Aplikacja może również zawierać implementację, która jest znana tylko tej aplikacji. Podczas tworzenia aplikacji w systemie IBM i można skorzystać z opisanych poniżej implementacji. v Systemowa implementacja protokołu SSL/TLS Aplikacje ILE używają systemowej implementacji protokołu SSL/TLS. Zarządzanie certyfikatami jest wykonywane za pomocą produktu Digital Certificate Manager (DCM), a typ bazy certyfikatów to CMS (Certificate Management Services), z rozszerzeniem nazwy pliku *.KDB. Aplikacje Java mogą używać systemowej implementacji protokołu SSL/TLS, ale nie jest to typowa sytuacja. Jeszcze rzadziej aplikacja Java używa systemowej implementacji protokołu SSL/TLS, korzystając jednocześnie z mechanizmu Java Keystore. v Dostawca IBMJSSE2 (IBMJSSEProvider2) Ten dostawca JSSE (Java Secure Socket Extension) zawiera implementację protokołów SSL/TLS w czystym języku Java i jest dostępny na wielu platformach. Implementacja występuje pod nazwą com.ibm.jsse2.ibmjsseprovider2 na liście dostawców java.security. Większość aplikacji Java w systemie używa tej implementacji JSSE, ponieważ jest to domyślny dostawca dla wszystkich wersji pakietu JDK. Certyfikaty zwykle znajdują się w pliku kluczy Java (JKS) i są zarządzane za pomocą komendy Java keytool lub IBM Key Management (programu narzędziowego ikeyman). Więcej ogólnych informacji na temat biblioteki JSSE w systemie zawiera sekcja Java Secure Socket Extension (JSSE). Szczegółowe informacje zawiera także niezależna od platformy dokumentacja biblioteki IBMJSSE2 przeznaczona dla odpowiedniej wersji pakietu JDK. Informacje dotyczące pakietu JDK8 zawiera dokumentacja Security Reference for IBM SDK, Java Technology Edition, Version 8. v OpenSSL OpenSSL to zestaw narzędzi Open Source, który implementuje protokoły SSL/TLS i bibliotekę kryptograficzną ogólnego przeznaczenia zawierającą silne mechanizmy szyfrowania. Środowisko PASE for i (IBM Portable 2 IBM i: Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS)

9 Application Solutions Environment for i) to jedyne środowisko, w którym ten pakiet jest dostępny. Certyfikaty znajdują się zwykle w plikach PEM i można nimi zarządzać za pomocą komend OpenSSL. Aplikacja CIMOM (Common Information Model Object Manager) korzysta z tej implementacji. Więcej informacji na ten temat zawiera sekcja Common Information Model. Implementacje osadzone w aplikacji: v Domino for i Korzysta z własnej implementacji protokołu SSL/TLS wbudowanej w produkcie. Zarządzanie konfiguracją i certyfikatami odbywa się w aplikacji. Serwer HTTP Domino można skonfigurować tak, aby używał systemowej implementacji protokołu SSL/TLS i certyfikatów DCM, domyślnie jednak korzysta z własnej implementacji. Pojęcia pokrewne: Biuletyny bezpieczeństwa Biuletyn bezpieczeństwa jest tworzony, gdy implementacja umożliwia ograniczenie ryzyka związanego z ujawnionym słabym punktem zabezpieczeń. Słabe punkty zabezpieczeń mogą być specyficzne dla danej implementacji lub ogólne, związane z protokołem. Biuletyny bezpieczeństwa Biuletyn bezpieczeństwa jest tworzony, gdy implementacja umożliwia ograniczenie ryzyka związanego z ujawnionym słabym punktem zabezpieczeń. Słabe punkty zabezpieczeń mogą być specyficzne dla danej implementacji lub ogólne, związane z protokołem. Ważne jest, aby administratorzy na bieżąco śledzili wszystkie metody ograniczania ryzyka udostępniane przez implementacje. Z powodu różnic w implementacjach nie wszystkie implementacje są narażone na ryzyko związane z konkretnym słabym punktem zabezpieczeń. Jeśli dane zagrożenie występuje, sposób jego ograniczenia może być różny dla poszczególnych implementacji. Biuletyn bezpieczeństwa zawiera działania, które należy podjąć w celu wyeliminowania problemu. Jeśli protokół lub algorytm nie może zostać naprawiony, rozwiązanie może polegać na wyłączeniu danej funkcji. Uwaga: Taka wyłączona funkcja może spowodować problem ze współdziałaniem w przypadku środowisk, których działanie zależy od danego protokołu. Warto skorzystać z subskrypcji, aby otrzymywać powiadomienia, gdy zostaną utworzone lub zaktualizowane biuletyny bezpieczeństwa dotyczące protokołu SSL/TLS. Więcej informacji na temat tego procesu można znaleźć w dokumencie My Notifications Subscription Service w Portalu wsparcia IBM. Zasubskrybuj pilne powiadomienia dotyczące wsparcia ( Urgent support notifications ), aby otrzymywać powiadomienia w przypadku zaktualizowania publikacji biuletynu bezpieczeństwa. Publikacja biuletynu bezpieczeństwa stanowi agregację pojedynczych biuletynów bezpieczeństwa, które są tworzone dla określonych słabych punktów zabezpieczeń. Aby dysponować aktualnymi informacjami, należy przeczytać je wszystkie. Biuletyny bezpieczeństwa mogą być aktualizowane po ich początkowej publikacji, jeśli zostaną udostępnione nowe informacje. Zaktualizowane biuletyny przenoszone są na początek zagregowanego biuletynu. Zaktualizowany biuletyn nie jest oznaczony flagami zmiany, ale zawiera krótką notatkę wskazującą, co zostało dodane do biuletynu lub w nim zmienione. Aby zapoznać się ze wszystkimi aktualizacjami, należy ponownie przeczytać pełną treść biuletynu. Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS) 3

10 Systemowa implementacja protokołu SSL/TLS Systemowa implementacja protokołu SSL/TLS to zestaw ogólnych usług udostępnionych w Licencjonowanym Kodzie Wewnętrznym systemu IBM i, które służą do zabezpieczania połączeń TCP/IP przy użyciu protokołu SSL/TLS. Systemowa implementacja protokołu SSL/TLS jest ściśle powiązana z systemem operacyjnym oraz kodem LIC do obsługi gniazd, aby zwiększyć wydajność i poziom bezpieczeństwa. Jak tworzyć kod korzystający z systemowej implementacji protokołu SSL/TLS Systemowa implementacja protokołu SSL/TLS jest dostępna dla programistów aplikacji poprzez następujące interfejsy programistyczne i implementacje JSSE. v Funkcje API z zestawu Global Security Kit (GSKit) Te interfejsy API języka ILE C są dostępne przy użyciu innych języków środowiska ILE. Więcej informacji na temat funkcji API z zestawu Global Security Kit (GSKit) zawiera temat Programowanie z użyciem gniazd. v Zintegrowane z systemem IBM i interfejsy API SSL_ Te interfejsy API języka ILE C są dostępne przy użyciu innych języków środowiska ILE. Nie należy tworzyć kodu z wykorzystaniem tego nieaktualnego interfejsu. Ten zestaw funkcji API nie udostępnia nowych funkcji zabezpieczeń dostępnych w pakiecie GSKit, który jest zalecanym interfejsem w języku C. v Zintegrowana z systemem IBM i implementacja JSSE Implementacja JSSE w systemie IBM i jest dostępna dla wersji JDK 7 i JDK 8. Implementacja występuje pod nazwą com.ibm.i5os.jsse.jsseprovider na liście dostawców java.security. Aplikacje korzystające z protokołu SSL/TLS utworzone przez IBM, Partnerów Handlowych IBM, niezależnych producentów oprogramowania lub klientów, które korzystają z jednego z powyższych interfejsów systemowej implementacji protokołu SSL/TLS, będą korzystać z systemowej implementacji protokołu SSL/TLS. Na przykład FTP oraz Telnet są aplikacjami firmy IBM, które wykorzystują systemową implementację protokołu SSL/TLS. Nie wszystkie aplikacje obsługujące protokół SSL/TLS działające w systemie IBM i używają systemowej implementacji protokołu SSL/TLS. Ustawienia systemowej implementacji protokołu SSL/TLS na poziomie systemu Systemowa implementacja protokołu SSL/TLS zawiera wiele atrybutów, które określają sposób negocjowania sesji chronionych. Każda wartość atrybutu jest ustawiana na jeden z trzech sposobów: 1. Twórca aplikacji ustawia jawną wartość atrybutu za pomocą kodu. 2. Twórca aplikacji udostępnia interfejs użytkownika, który umożliwia administratorowi aplikacji ustawienie wartości atrybutu w sposób pośredni. 3. Twórca aplikacji nie ustawia wartości atrybutu. Systemowa implementacja protokołu SSL/TLS używa wartości domyślnej atrybutu. Wymagania dotyczące zgodności zabezpieczeń zmieniają się w trakcie cyklu życia wersji. Aby zachować zgodność, administratorzy systemu muszą przesłonić wartości niektórych atrybutów. Systemowa implementacja protokołu SSL/TLS zawiera różne ustawienia na poziomie systemu, które pozwalają wdrożyć taki poziom kontroli. Istnieją dwa rodzaje mechanizmów kontrolnych na poziomie systemu: v Całkowite wyłączenie wartości atrybutu Wyłączona wartość jest ignorowana, jeśli jest używana w dowolnej z trzech metod ustawiania wartości atrybutów W aplikacji występuje błąd krytyczny, jeśli żadna poprawna wartość nie jest włączona dla atrybutu 4 IBM i: Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS)

11 W aplikacji występuje błąd programowy, jeśli węzeł sieci wymaga podania wyłączonej wartości v Wyłączenie wartości domyślnej atrybutu Zmiana dotyczy jedynie aplikacji, które używają wartości domyślnych systemowej implementacji protokołu SSL/TLS do ustawiania danego atrybutu W aplikacji występuje błąd programowy, jeśli węzeł sieci wymaga podania wyłączonej wartości Ustawienia na poziomie systemu są sterowane za pomocą kombinacji następujących interfejsów: v Wartości systemowe SSL/TLS v Komenda zaawansowanej analizy SSLCONFIG z zestawu Systemowych narzędzi serwisowych (System Service Tools SST) zgodnie z podanymi informacjami. Wartości włączone i/lub wartości domyślne następujących atrybutów systemowej implementacji protokołu SSL/TLS mogą być zmieniane na poziomie systemu. Pojęcia pokrewne: Komenda SSLCONFIG na stronie 27 Komenda SSLCONFIG jest komendą zaawansowanej analizy systemowych narzędzi serwisowych (SST), która umożliwia wyświetlanie lub zmienianie domyślnych właściwości systemowej implementacji protokołu SSL/TLS na poziomie systemu. Informacje pokrewne: Wartość systemowa SSL/TLS: QSSLPCL Wartość systemowa SSL/TLS: QSSLCSLCTL Wartość systemowa SSL/TLS: QSSLCSL Konfiguracja protokołu Systemowa implementacja protokołu SSL/TLS obejmuje infrastrukturę obsługującą wiele protokołów. Systemowa implementacja protokołu SSL/TLS obsługuje następujące protokoły: v Protokół Transport Layer Security, wersja 1.2 (TLSv1.2) v Protokół Transport Layer Security, wersja 1.1 (TLSv1.1) v Protokół Transport Layer Security, wersja 1.0 (TLSv1.0) v Protokół Secure Sockets Layer, wersja 3.0 (SSLv3) v Protokół Secure Sockets Layer, wersja 2.0 (SSLv2) Nie można używać protokołu SSLv2, jeśli protokół TLSv1.2 jest włączony w systemie w wartości systemowej QSSLPCL. Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS) 5

12 UWAGA: Firma IBM zdecydowanie zaleca, aby zawsze uruchamiać serwer IBM i z wyłączonymi protokołami sieciowymi wymienionymi poniżej. Zastosowanie opcji konfiguracyjnych udostępnianych przez IBM do włączenia słabych protokołów skutkuje skonfigurowaniem serwera IBM i w sposób umożliwiający użycie słabych protokołów. W takiej konfiguracji serwer IBM i jest potencjalnie narażony na naruszenie bezpieczeństwa sieci. IBM NIE PONOSI ŻADNEJ ODPOWIEDZIALNOŚCI, A KLIENT PONOSI WSZELKĄ ODPOWIEDZIALNOŚĆ ZA JAKIEKOLWIEK SZKODY LUB STRATY, W TYM UTRATĘ DANYCH, POWSTAŁE W WYNIKU KORZYSTANIA Z OKREŚLONYCH PROTOKOŁÓW SIECIOWYCH LUB Z TAKIM KORZYSTANIEM POWIĄZANE. Słabe protokoły (stan na kwiecień 2016 r.): v Protokół Secure Sockets Layer, wersja 3.0 (SSLv3) v Protokół Secure Sockets Layer, wersja 2.0 (SSLv2) Włączone protokoły Ustawienie wartości systemowej QSSLPCL określa konkretne protokoły, które są włączone w systemie. Aplikacje mogą negocjować sesje chronione tylko z wykorzystaniem protokołów, które są wymienione w wartości QSSLPCL. Na przykład, aby w systemowej implementacji protokołu SSL/TLS zezwolić wyłącznie na korzystanie z protokołu TLSv1.2 i nie zezwolić na używanie żadnej ze starszych wersji protokołu, ustaw dla wartości systemowej QSSLPCL jedynie wartość *TLSV1.2. Wartość specjalna *OPSYS wartości systemowej QSSLPCL umożliwia systemowi operacyjnemu zmianę protokołów włączonych w systemie w trakcie zmiany wersji. Wartość QSSLPCL pozostaje bez zmian w przypadku aktualizacji systemu do nowej wersji. Jeśli wartością QSSLPCL nie jest *OPSYS, to administrator musi ręcznie dodać nowsze wersje protokołów do wartości QSSLPCL, gdy system zostanie zaktualizowany do nowej wersji. Wersja systemu IBM i i 6.1 i 7.1 i 7.2 i 7.3 Protokoły domyślne Definicja QSSLPCL *OPSYS *TLSV1, *SSLV3 *TLSV1, *SSLV3 *TLSV1.2, *TLSV1.1, *TLSV1 *TLSV1.2, *TLSV1.1, *TLSV1 Jeśli aplikacja nie określa włączanych protokołów, używane są protokoły domyślne systemowej implementacji protokołu SSL/TLS. Aplikacje używają tej metody, aby można było uwzględnić obsługę nowych wersji protokołu TLS bez konieczności zmiany kodu aplikacji. Domyślne ustawienie protokołów nie ma znaczenia dla aplikacji, które jawnie określają włączane protokoły. Zbiór domyślnych protokołów w systemie stanowi część wspólną zbioru włączonych protokołów określonych w wartości systemowej QSSLPCL oraz zbioru dostępnych domyślnych protokołów. Listę dostępnych domyślnych protokołów można zmienić za pomocą komendy zaawansowanej analizy SSLCONFIG z zestawu systemowych narzędzi serwisowych (System Service Tools SST). Aby określić bieżącą wartość listy dostępnych domyślnych protokołów i listy domyślnych protokołów w systemie, należy użyć opcji -display komendy SSLCONFIG. Administrator powinien rozważyć zmianę ustawień domyślnych protokołów jedynie wówczas, gdy żadne inne ustawienie konfiguracji nie pozwala aplikacji pomyślnie współdziałać z węzłami sieci. Zalecane jest włączanie starszych protokołów tylko dla konkretnych aplikacji, które tego wymagają. Jeśli aplikacja ma definicję aplikacji, to włączanie jest wykonywane za pomocą programu Digital Certificate Manager (DCM). 6 IBM i: Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS)

13 Ostrzeżenie: Dodanie starszego protokołu do domyślnej listy skutkuje powstaniem we wszystkich aplikacjach, które korzystają z domyślnej listy, znanych słabych punktów zabezpieczeń. Załadowanie grupowej poprawki PTF zabezpieczeń może spowodować usunięcie protokołu z listy domyślnych protokołów. Subskrybuj biuletyn bezpieczeństwa, aby otrzymywać powiadomienia, gdy procedury ograniczania ryzyka obejmują tego typu zmiany. Jeśli administrator dodaje z powrotem dostępny protokół, który został usunięty przez poprawkę PTF zabezpieczeń, system zapamiętuje tę zmianę i nie usuwa takiego protokołu ponownie podczas stosowania następnej poprawki PTF zabezpieczeń. Jeśli lista domyślnych protokołów musi zostać zmieniona w systemie, to do zmiany jej wartości należy użyć opcji eligibledefaultprotocols komendy SSLCONFIG. Opcja -h komendy SSLCONFIG powoduje wyświetlenie panelu pomocy, który opisuje sposób ustawiania listy protokołów. Tylko wersje protokołów wymienione w tekście pomocy można dodać do listy. Uwaga: Ustawienie eligibledefaultprotocols komendy SSLCONFIG jest resetowane po zainstalowaniu licencjonowanego kodu wewnętrznego (LIC). Przykład ustawienia protokołu TLSv1.2 jako jedynego domyślnego protokołu w systemie: SSLCONFIG -eligibledefaultprotocols:10 Wersja systemu IBM i i 6.1 i 7.1 i 7.2 i 7.3 Pojęcia pokrewne: Lista dostępnych domyślnych protokołów w najnowszej grupowej poprawce PTF zabezpieczeń TLSv1.0 TLSv1.0 TLSv1.2, TLSv1.1, TLSv1.0 TLSv1.2, TLSv1.1, TLSv1.0 Komenda SSLCONFIG na stronie 27 Komenda SSLCONFIG jest komendą zaawansowanej analizy systemowych narzędzi serwisowych (SST), która umożliwia wyświetlanie lub zmienianie domyślnych właściwości systemowej implementacji protokołu SSL/TLS na poziomie systemu. Biuletyny bezpieczeństwa na stronie 3 Biuletyn bezpieczeństwa jest tworzony, gdy implementacja umożliwia ograniczenie ryzyka związanego z ujawnionym słabym punktem zabezpieczeń. Słabe punkty zabezpieczeń mogą być specyficzne dla danej implementacji lub ogólne, związane z protokołem. Informacje pokrewne: Wartość systemowa SSL/TLS: QSSLPCL Konfiguracja zestawów algorytmów szyfrowania Systemowa implementacja protokołu SSL/TLS obejmuje infrastrukturę obsługującą wiele zestawów algorytmów szyfrowania. Zestawy algorytmów szyfrowania są określane w różny sposób w poszczególnych interfejsach programistycznych. Poniższa tabela zawiera listę specyfikacji zestawów algorytmów szyfrowania (w postaci wartości systemowych), które mogą być obsługiwane przez systemową implementację protokołu SSL/TLS dla poszczególnych wersji protokołu. Obsługiwane specyfikacje algorytmów szyfrowania dla poszczególnych protokołów są wskazane za pomocą znaków X w odpowiednich kolumnach. Tabela 1. Specyfikacje algorytmów szyfrowania obsługiwane w protokołach TLS i SSL Reprezentacja wartości systemowej QSSLCSL TLSv1.2 TLSv1.1 TLSv1.0 SSLv3 SSLv2 *ECDHE_ECDSA_AES_128_GCM_SHA256 *ECDHE_ECDSA_AES_256_GCM_SHA384 X X Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS) 7

14 Tabela 1. Specyfikacje algorytmów szyfrowania obsługiwane w protokołach TLS i SSL (kontynuacja) Reprezentacja wartości systemowej QSSLCSL TLSv1.2 TLSv1.1 TLSv1.0 SSLv3 SSLv2 *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 Włączone zestawy algorytmów szyfrowania Ustawienie wartości systemowej QSSLCSL określa konkretne zestawy algorytmów szyfrowania, które są włączone w systemie. Aplikacje mogą negocjować sesje chronione tylko z wykorzystaniem tego zestawu algorytmów szyfrowania, który jest wymieniony w wartości QSSLCSL. Bez względu na kod i konfigurację aplikacja nie może negocjować sesji chronionych z wykorzystaniem zestawu algorytmów szyfrowania niewymienionych w wartości QSSLCSL. Konfiguracja konkretnej aplikacji określa, które z włączonych pakietów szyfrowania są używane dla tej aplikacji. Na przykład, aby w systemowej implementacji protokołu SSL/TLS zezwolić jedynie na korzystanie z protokołu ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) i nie zezwolić na wymianę kluczy RSA, wykonaj następujące czynności: 8 IBM i: Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS)

15 1. Zmień wartość systemową QSSLCSLCTL, podając wartość specjalną *USRDFN, aby zezwolić na edytowanie wartości systemowej QSSLCSL. 2. Usuń z wartości QSSLCSL wszystkie zestawy algorytmów szyfrowania, których nazwa nie zawiera słowa kluczowego ECDHE. Wartość specjalna *OPSYS wartości systemowej QSSLCSLCTL umożliwia systemowi operacyjnemu zmianę zestawów algorytmów szyfrowania włączonych w systemie w trakcie zmiany wersji. Wartość QSSLCSLCTL pozostaje bez zmian w przypadku aktualizacji systemu do nowej wersji. Jeśli wartością QSSLCSLCTL jest *USRDFN, administrator musi ręcznie dodać nowe zestawy algorytmów szyfrowania do wartości QSSLCSL, gdy system zostanie zaktualizowany do nowej wersji. Ustawienie wartości QSSLCSLCTL ponownie na *OPSYS powoduje także dodanie nowych wartości do wartości QSSLCSL. Zestawu algorytmów szyfrowania nie można dodać do wartości QSSLCSL, jeśli protokół SSL/TLS wymagany przez zestaw algorytmów szyfrowania nie jest ustawiony w wartości QSSLPCL. Zestawy algorytmów szyfrowania włączone za pomocą wartości QSSLCSLCTL *OPSYS w systemie IBM i 7.3 są wyświetlane w wartości systemowej QSSLCSL. Są one następujące: 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 Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS) 9

16 UWAGA: Firma IBM zdecydowanie zaleca, aby zawsze uruchamiać serwer IBM i z wyłączonymi zestawami algorytmów szyfrowania wymienionymi poniżej. Zastosowanie opcji konfiguracyjnych udostępnianych przez IBM do włączenia zestawów słabych algorytmów szyfrowania skutkuje skonfigurowaniem serwera IBM i w sposób umożliwiający użycie listy zestawów słabych algorytmów szyfrowania. W takiej konfiguracji serwer IBM i jest potencjalnie narażony na naruszenie bezpieczeństwa sieci. IBM NIE PONOSI ŻĄDNEJ ODPOWIEDZIALNOŚCI, A KLIENT PONOSI WSZELKĄ ODPOWIEDZIALNOŚĆ ZA JAKIEKOLWIEK SZKODY LUB STRATY, W TYM UTRATĘ DANYCH, POWSTAŁE W WYNIKU KORZYSTANIA Z OKREŚLONYCH ZESTAWÓW ALGORYTMÓW SZYFROWANIA LUB Z TAKIM KORZYSTANIEM POWIĄZANE. Zestawy słabych algorytmów szyfrowania (stan na kwiecień 2016 r.): 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 Domyślne zestawy algorytmów szyfrowania Jeśli aplikacja nie określa włączanych algorytmów szyfrowania, używana jest uporządkowana lista domyślnych zestawów algorytmów szyfrowania systemowej implementacji protokołu SSL/TLS. Aplikacje używają tej metody, aby można było uwzględnić obsługę nowych wersji protokołu TLS bez konieczności zmiany kodu aplikacji. Domyślne ustawienie zestawów algorytmów szyfrowania nie ma znaczenia dla aplikacji, które jawnie określają włączane zestawy algorytmów szyfrowania. Zbiór domyślnych zestawów algorytmów szyfrowania w systemie stanowi część wspólną zbioru włączonych zestawów algorytmów szyfrowania określonych w wartości systemowej QSSLCSL oraz zbioru dostępnych domyślnych zestawów algorytmów szyfrowania. Listę dostępnych domyślnych zestawów algorytmów szyfrowania można zmienić za pomocą komendy zaawansowanej analizy SSLCONFIG z zestawu systemowych narzędzi serwisowych (System Service Tools SST). Kolejność na liście domyślnych zestawów algorytmów szyfrowania odpowiada kolejności zestawów algorytmów szyfrowania w wartości systemowej QSSLCSL. Aby zmienić kolejność, należy zmienić wartość QSSLCSL. Aby określić bieżącą wartość listy dostępnych domyślnych zestawów algorytmów szyfrowania i listy domyślnych zestawów algorytmów szyfrowania w systemie, należy użyć opcji -display komendy SSLCONFIG. Administrator powinien rozważyć zmianę ustawień listy domyślnych zestawów algorytmów szyfrowania jedynie wówczas, gdy żadne inne ustawienie konfiguracji nie pozwala aplikacji pomyślnie współdziałać z węzłami sieci. Zalecane jest włączanie starszych zestawów algorytmów szyfrowania tylko dla konkretnych aplikacji, które tego wymagają. Jeśli aplikacja ma definicję aplikacji, to włączanie jest wykonywane za pomocą programu Digital Certificate Manager (DCM). 10 IBM i: Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS)

17 Ostrzeżenie: Dodanie starszego zestawu algorytmów szyfrowania do domyślnej listy skutkuje powstaniem we wszystkich aplikacjach, które korzystają z domyślnej listy, znanych słabych punktów zabezpieczeń. Załadowanie grupowej poprawki PTF zabezpieczeń może spowodować usunięcie zestawu algorytmów szyfrowania z listy domyślnych zestawów algorytmów szyfrowania. Subskrybuj biuletyn bezpieczeństwa, aby otrzymywać powiadomienia, gdy procedury ograniczania ryzyka obejmują tego typu zmiany. Jeśli administrator dodaje z powrotem dostępny zestaw algorytmów szyfrowania, który został usunięty przez poprawkę PTF zabezpieczeń, system zapamiętuje tę zmianę i nie usuwa takiego zestawu ponownie podczas stosowania następnej poprawki PTF zabezpieczeń. Jeśli lista domyślnych zestawów algorytmów szyfrowania musi być zmieniona w systemie, to do zmiany jej wartości należy użyć opcji eligibledefaultciphersuites komendy SSLCONFIG. Opcja -h komendy SSLCONFIG powoduje wyświetlenie panelu pomocy, który opisuje sposób określania zmienionej listy zestawów algorytmów szyfrowania. Tekst pomocy zawiera skrócone informacje na temat wartości wymaganych przez opcję. Tylko zestawy algorytmów szyfrowania wymienione w tekście pomocy można dodać do listy. Uwaga: Ustawienie eligibledefaultciphersuites komendy SSLCONFIG jest resetowane po zainstalowaniu licencjonowanego kodu wewnętrznego (LIC). Przykład ustawienia tylko zestawów algorytmów szyfrowania ECDHE jako domyślnych w systemie: SSLCONFIG -eligibledefaultciphersuites:ye,yd,yc,yb,ya,y9,y8,y7,y6,y3 Zestawy algorytmów szyfrowania uwzględnione na liście dostępnych domyślnych zestawów algorytmów szyfrowania instalowanej w ramach najnowszej grupowej poprawki PTF zabezpieczeń są następujące: 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 Pojęcia pokrewne: Komenda SSLCONFIG na stronie 27 Komenda SSLCONFIG jest komendą zaawansowanej analizy systemowych narzędzi serwisowych (SST), która umożliwia wyświetlanie lub zmienianie domyślnych właściwości systemowej implementacji protokołu SSL/TLS na poziomie systemu. Informacje pokrewne: Wartość systemowa SSL/TLS: QSSLCSLCTL Wartość systemowa SSL/TLS: QSSLCSL Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS) 11

18 Algorytmy podpisu W protokole TLSv1.2 algorytm podpisu i algorytm mieszania używane w podpisach cyfrowych są niezależnymi atrybutami. Wcześniej te algorytmy zależały od wynegocjowanego zestawu algorytmów szyfrowania. Systemowa implementacja protokołu SSL/TLS obejmuje infrastrukturę obsługującą wiele algorytmów podpisu. Uporządkowana lista dozwolonych par algorytmów podpisu i mieszania jest w protokole TLSv1.2 wykorzystywana na dwa sposoby i nie ma znaczenia dla wcześniejszych wersji protokołu: Wybór certyfikatu Uporządkowana lista algorytmów podpisu jest wysyłana do systemu węzła sieci, gdy systemowa implementacja protokołu SSL/TLS żąda certyfikatu podczas uzgadniania. Węzeł sieci używa odebranej listy jako wytycznych w procesie wyboru certyfikatu. Węzeł sieci powinien wybrać certyfikat zgodny z listą, ale nie we wszystkich implementacjach i konfiguracjach tak się dzieje. Systemowa implementacja protokołu SSL/TLS traktuje odebrany certyfikat o niepożądanym algorytmie podpisu jako błąd sesji, chyba że jest skonfigurowane opcjonalne uwierzytelnianie klienta. Jeśli systemowa implementacja protokołu SSL/TLS otrzymuje żądanie certyfikatu i nie jest w stanie wybrać zgodnego certyfikatu, wysyła dostępny niezgodny certyfikat RSA lub ECDSA. Węzeł sieci decyduje, czy taki certyfikat jest traktowany jako błąd sesji. Więcej informacji na temat algorytmu wyboru certyfikatu w systemowej implementacji protokołu SSL/TLS zawiera sekcja Wybór wielu certyfikatów na stronie 22. Podpisywanie komunikatów Lista par algorytmów ogranicza algorytmy podpisu i mieszania używane w cyfrowych podpisach komunikatów uzgadniania. Podpis komunikatu uzgadniania protokołu TLSv1.2 może się różnić od algorytmu podpisu certyfikatu używanego w tej sesji. Na przykład komunikat uzgadniania może być chroniony algorytmem SHA512, mimo że dla sesji został wybrany certyfikat MD5. Systemowa implementacja protokołu SSL/TLS obejmuje infrastrukturę obsługującą następujące algorytmy podpisu: 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 Włączone algorytmy podpisu Komenda zaawansowanej analizy systemowych narzędzi serwisowych (SST) o nazwie SSLCONFIG pozwala określić algorytmy podpisu włączone w systemie. Aplikacje mogą negocjować sesje chronione tylko z wykorzystaniem tych algorytmów podpisu, które są wyszczególnione za pomocą opcji supportedsignaturealgorithmlist komendy SSLCONFIG. Aby określić bieżącą wartość listy algorytmów podpisu włączonych w systemie, należy użyć opcji -display komendy SSLCONFIG. Jeśli lista włączonych algorytmów podpisu musi zostać zmieniona w systemie, to do zmiany jej wartości należy użyć opcji supportedsignaturealgorithmlist komendy SSLCONFIG. Opcja -h komendy SSLCONFIG powoduje wyświetlenie panelu pomocy, który opisuje sposób ustawiania listy algorytmów podpisu. Tylko wersje algorytmów podpisu wymienione w tekście pomocy można dodać do listy. 12 IBM i: Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS)

19 Uwaga: Ustawienie supportedsignaturealgorithmlist komendy SSLCONFIG jest resetowane po zainstalowaniu licencjonowanego kodu wewnętrznego (LIC). Przykład ustawiania algorytmów podpisu ECDSA i RSA jako obsługiwanych algorytmów podpisu w systemie: SSLCONFIG -supportedsignaturealgorithmlist:36,35,34,33,32,16,15,14,13,12 W konfiguracji fabrycznej systemowa implementacja protokołu SSL/TLS obsługuje następującą listę algorytmów podpisu: 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 Domyślne algorytmy podpisu Jeśli aplikacja nie określa listy algorytmów podpisu, używana jest lista domyślnych algorytmów podpisu systemowej implementacji protokołu SSL/TLS. Aplikacje używają tej metody, aby można było uwzględnić obsługę nowych wersji protokołu TLS bez konieczności zmiany kodu aplikacji. Lista domyślnych algorytmów podpisu nie ma znaczenia dla tych aplikacji, które jawnie określają używaną listę algorytmów podpisu. Lista domyślnych algorytmów podpisu w systemie stanowi część wspólną listy włączonych algorytmów podpisu i listy dostępnych domyślnych algorytmów podpisu. Lista dostępnych domyślnych algorytmów podpisu jest konfigurowana za pomocą opcji signaturealgorithmlist komendy SSLCONFIG. Aby określić bieżącą wartość listy dostępnych domyślnych algorytmów podpisu w systemie, należy użyć opcji -display komendy SSLCONFIG. Administrator powinien rozważyć zmianę ustawień domyślnych algorytmów podpisu jedynie wówczas, gdy żadne inne ustawienie konfiguracji nie pozwala aplikacji pomyślnie współdziałać z węzłami sieci. Zalecane jest włączanie starszych algorytmów podpisu tylko dla konkretnych aplikacji, które tego wymagają. Jeśli aplikacja ma definicję aplikacji, to włączanie jest wykonywane za pomocą programu Digital Certificate Manager (DCM). Jeśli lista domyślnych algorytmów podpisu musi zostać zmieniona w systemie, to do zmiany jej wartości należy użyć opcji signaturealgorithmlist komendy SSLCONFIG. Opcja -h komendy SSLCONFIG powoduje wyświetlenie panelu pomocy, który opisuje sposób ustawiania listy algorytmów podpisu. Tylko wersje algorytmów podpisu wymienione w tekście pomocy można dodać do listy. Uwaga: Ustawienie signaturealgorithmlist komendy SSLCONFIG jest resetowane po zainstalowaniu licencjonowanego kodu wewnętrznego (LIC). Przykład ustawiania algorytmu podpisu ECDSA jako domyślnego algorytmu podpisu w systemie: SSLCONFIG -signaturealgorithmlist:36,35,34,33,32 Kolejność listy domyślnych algorytmów podpisu w konfiguracji fabrycznej jest następująca: v ECDSA_SHA512 Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS) 13

20 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 Pojęcia pokrewne: Komenda SSLCONFIG na stronie 27 Komenda SSLCONFIG jest komendą zaawansowanej analizy systemowych narzędzi serwisowych (SST), która umożliwia wyświetlanie lub zmienianie domyślnych właściwości systemowej implementacji protokołu SSL/TLS na poziomie systemu. Minimalna wielkość klucza RSA Minimalna wielkość klucza RSA dozwolona dla certyfikatu, który jest używany przez dowolną stronę podczas uzgadniania, może być ograniczona w systemowej implementacji protokołu SSL/TLS. Certyfikat cyfrowy RSA zawiera parę kluczy: publiczny i prywatny. Wielkość klucza dla pary jest mierzona w bitach. Niektóre strategie zgodności zabezpieczeń wymagają, aby wielkość klucza RSA osiągała wielkość minimalną. Wielkość klucza RSA jest ustawiana podczas tworzenia certyfikatu. Administrator systemu musi utworzyć nowe certyfikaty z dłuższymi kluczami RSA i zastąpić nimi certyfikaty o wielkości klucza mniejszej niż ustawiona wielkość minimalna. Systemowa implementacja protokołu SSL/TLS zawiera ustawienie na poziomie systemu, które pozwala wprowadzić wielkość minimalną klucza RSA dozwoloną dla certyfikatu. Ograniczenie to odnosi się do certyfikatów lokalnych oraz certyfikatów węzłów sieci i obejmuje zarówno certyfikaty klienta, jak i serwera. Ustawianie minimalnej wielkości klucza spowoduje niepowodzenie uzgadniania, jeśli certyfikat jednej ze stron zawiera klucz RSA o wielkości mniejszej niż minimalna. Zanim administrator zmieni ustawienie minimalnej wielkości klucza na poziomie systemu, powinien ręcznie sprawdzić i wymienić istniejące certyfikaty lokalne, które mają klucze o wielkości mniejszej niż wymagane minimum, aby uniknąć awarii aplikacji. Ustawienie minimalnej wielkości klucza RSA uniemożliwia współdziałanie z węzłami sieci, które wykorzystują certyfikaty RSA z kluczem o wielkości mniejszej niż wartość minimalna. Początkowe ustawienie minimalnej wielkości klucza RSA na poziomie systemu ma wartość 0. Wartość 0 oznacza brak ograniczenia wielkości klucza. Ustawienie systemowej implementacji protokołu SSL/TLS na poziomie systemu można zmienić za pomocą komendy zaawansowanej analizy SSLCONFIG z zestawu systemowych narzędzi serwisowych (System Service Tools SST). Aby określić bieżące ustawienie, należy użyć opcji -display komendy SSLCONFIG. Opcja minimumrsakeysize komendy SSLCONFIG umożliwia zmianę minimalnej długości klucza. Opcja -h komendy SSLCONFIG powoduje wyświetlenie panelu pomocy, który opisuje sposób ustawiania wielkości klucza. Na przykład następująca komenda pozwala ustawić minimalną wielkość klucza RSA dozwoloną w systemie na 2 kilobajty (2048 bitów): SSLCONFIG -minimumrsakeysize:2048 Aplikacja może ustawić wartość atrybutu GSKit o nazwie GSK_MIN_RSA_KEY_SIZE i określić wyższą wartość minimalnej wielkości klucza, dzięki czemu poszczególne aplikacje mogą wprowadzać bardziej rygorystyczne ograniczenia niż pozostała część systemu. Jeśli aplikacja ustawi wartość atrybutu GSK_MIN_RSA_KEY_SIZE niższą 14 IBM i: Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS)

21 niż opcja minimumrsakeysize komendy SSLCONFIG, to używana jest wartość opcji minimumrsakeysize komendy SSLCONFIG, a podejmowana przez aplikację próba zmniejszenia minimalnej wielkości klucza jest ignorowana. To ustawienie nie ma wpływu na certyfikaty ECDSA, ponieważ nie używają one kluczy RSA. Pojęcia pokrewne: Komenda SSLCONFIG na stronie 27 Komenda SSLCONFIG jest komendą zaawansowanej analizy systemowych narzędzi serwisowych (SST), która umożliwia wyświetlanie lub zmienianie domyślnych właściwości systemowej implementacji protokołu SSL/TLS na poziomie systemu. Nazwane krzywe ECDSA Systemowa implementacja protokołu SSL/TLS obsługuje certyfikaty oparte na algorytmie ECDSA (Elliptic Curve Digital Signature Algorithm). Wielkość klucza dla certyfikatu ECDSA jest określana przez nazwaną krzywą ustawianą w momencie utworzenia certyfikatu. Systemowa implementacja protokołu SSL/TLS i program Digital Certificate Manager (DCM) zawierają infrastrukturę obsługi następujących nazwanych krzywych: v Secp521r1 v Secp384r1 v Secp256r1 v Secp224r1 v Secp192r1 Liczba w nazwie krzywej oznacza wielkość klucza w bitach używanego w programie DCM do utworzenia certyfikatu. Podczas wyświetlania certyfikatu w programie DCM wielkość klucza powiązanego z nazwaną krzywą jest podawana w bitach. Włączone nazwane krzywe Komenda zaawansowanej analizy SSLCONFIG z zestawu systemowych narzędzi serwisowych (SST) pozwala określić minimalną wielkość klucza ECDSA dozwoloną dla certyfikatów używanych przez systemową implementację protokołu SSL/TLS. Ograniczenie to odnosi się do certyfikatów lokalnych oraz certyfikatów węzłów sieci i obejmuje zarówno certyfikaty klienta, jak i serwera. Ograniczenie listy nazwanych krzywych skutkuje niepowodzeniem uzgadniania, jeśli certyfikat serwera lub klienta zawiera klucz ECDSA o wielkości nieznajdującej się na obsługiwanej liście. Aby określić bieżącą wartość listy włączonych w systemie nazwanych krzywych eliptycznych, należy użyć opcji -display komendy SSLCONFIG. Jeśli lista włączonych nazwanych krzywych ma być zmieniona w systemie, należy użyć opcji supportednamedcurve komendy SSLCONFIG, aby zmienić jej wartość. Opcja -h komendy SSLCONFIG powoduje wyświetlenie panelu pomocy, który opisuje sposób ustawiania wartości listy nazwanych krzywych. Tylko nazwane krzywe wymienione w tekście pomocy można dodać do listy. Uwaga: Ustawienie supportednamedcurve komendy SSLCONFIG jest resetowane po zainstalowaniu licencjonowanego kodu wewnętrznego (LIC). Przykład: ustawienie kluczy o wielkości 256, 384 i 521 bitów na liście obsługiwanych nazwanych krzywych w systemie: SSLCONFIG -supportednamedcurve:23,24,25 W konfiguracji fabrycznej systemowa implementacja protokołu SSL/TLS obsługuje następującą listę nazwanych krzywych: v Secp521r1 v Secp384r1 Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS) 15

22 v Secp256r1 v Secp224r1 v Secp192r1 Domyślne nazwane krzywe Jeśli aplikacja nie określa listy nazwanych krzywych, używana jest lista domyślnych nazwanych krzywych systemowej implementacji protokołu SSL/TLS. Aplikacje używają tej metody, aby można było uwzględnić obsługę nowych wersji protokołu TLS bez konieczności zmiany kodu aplikacji. Lista domyślnych nazwanych krzywych nie ma znaczenia dla tych aplikacji, które jawnie określają używaną listę nazwanych krzywych. Lista domyślnych nazwanych krzywych w systemie stanowi część wspólną listy włączonych nazwanych krzywych i listy dostępnych domyślnych nazwanych krzywych. Lista dostępnych domyślnych nazwanych krzywych jest konfigurowana za pomocą opcji namedcurve komendy SSLCONFIG. Aby określić bieżącą wartość listy domyślnych nazwanych krzywych eliptycznych w systemie, należy użyć opcji -display komendy SSLCONFIG. Administrator powinien rozważyć zmianę ustawień domyślnych nazwanych krzywych jedynie wówczas, gdy żadne inne ustawienie konfiguracji nie pozwala aplikacji pomyślnie współdziałać z węzłami sieci. Zalecane jest włączanie nazwanych krzywych o krótszym kluczu tylko dla konkretnych aplikacji, które tego wymagają. Jeśli aplikacja ma definicję aplikacji, to włączanie jest wykonywane za pomocą programu Digital Certificate Manager (DCM). Jeśli lista domyślnych nazwanych krzywych musi zostać zmieniona w systemie, to do zmiany jej wartości należy użyć opcji namedcurve komendy SSLCONFIG. Opcja -h komendy SSLCONFIG powoduje wyświetlenie panelu pomocy, który opisuje sposób ustawiania listy nazwanych krzywych. Tylko nazwane krzywe wymienione w tekście pomocy można dodać do listy. Uwaga: Ustawienie namedcurve komendy SSLCONFIG jest resetowane po zainstalowaniu licencjonowanego kodu wewnętrznego (LIC). Przykład: ustawienie kluczy o wielkości 384 i 521 bitów na liście domyślnych nazwanych krzywych w systemie: SSLCONFIG -namedcurve:24,25 Kolejność listy domyślnych nazwanych krzywych w konfiguracji fabrycznej jest następująca: v Secp521r1 v Secp384r1 v Secp256r1 Pojęcia pokrewne: Komenda SSLCONFIG na stronie 27 Komenda SSLCONFIG jest komendą zaawansowanej analizy systemowych narzędzi serwisowych (SST), która umożliwia wyświetlanie lub zmienianie domyślnych właściwości systemowej implementacji protokołu SSL/TLS na poziomie systemu. Renegocjacja Rozpoczęcie nowej operacji uzgadniania w istniejącej bezpiecznej sesji określa się jako renegocjację. Renegocjacja w systemowej implementacji protokołu SSL/TLS jest charakteryzowana przez dwie właściwości. Aplikacja może podjąć renegocjację z wielu powodów. Renegocjacja może zostać rozpoczęta przez klienta lub przez serwer. Warstwa aplikacji może nie mieć informacji o renegocjacji bezpiecznej sesji na żądanie węzła sieci. Uwaga: Do zainicjowania renegocjacji w aplikacjach GSKit korzystających z systemowej implementacji protokołu SSL/TLS używana jest funkcja gsk_secure_soc_misc(). 16 IBM i: Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS)

23 Architektury protokołów SSL i TLS zdefiniowane w odpowiednich dokumentach RFC zawierają błąd związany z renegocjacją. Protokoły nie udostępniają potwierdzenia kryptograficznego, że renegocjacja sesji jest powiązana z istniejącą bezpieczną sesją. Dodatkowy dokument RFC 5746 definiuje opcjonalne rozszerzenie podstawowych protokołów, które rozwiązuje ten problem. Dokument RFC 5746 został dodany do wcześniej zdefiniowanego protokołu dopiero niedawno, więc nie jest obecnie obsługiwany przez wszystkie implementacje protokołu SSL/TLS. Niektóre implementacje protokołu SSL/TLS nie zostały zaktualizowane o obsługę dokumentu RFC 5746 lub taka aktualizacja nie jest w ich przypadku możliwa. W celu zapewnienia ciągłości biznesowej i współdziałania na różnych etapach przejścia między wersjami protokołu wprowadzono dwie właściwości służące do określania trybu renegocjacji. Tryb renegocjacji SSL/TLS Domyślnie systemowa implementacja protokołu SSL/TLS wymaga użycia semantyki opisanej w dokumencie RFC 5746 we wszystkich operacjach renegocjacji. Tryb domyślny można zmienić za pomocą opcji sslrenegotiation komendy zaawansowanej analizy SSLCONFIG z zestawu Systemowych narzędzi serwisowych (System Service Tools SST). Można ustawić tryb zezwalania na wszystkie niezabezpieczone operacje renegocjacji lub zezwalania tylko na skrócone niezabezpieczone operacje renegocjacji. Użycie tych trybów wymaga dokładnego rozważenia. Opcja -h komendy SSLCONFIG powoduje wyświetlenie panelu pomocy, który opisuje sposób ustawiania trybu renegocjacji SSL/TLS. Istnieje tryb wyłączający całkowicie możliwość renegocjacji zainicjowanej przez węzeł sieci. Ten tryb uniemożliwia renegocjację bezpieczną (w semantyce dokumentu RFC 5746) i niezabezpieczoną. Ten tryb może spowodować problemu ze współdziałaniem w przypadku aplikacji, które wymagają korzystania z renegocjacji. Bezpieczne operacje renegocjacji zainicjowane lokalnie, takie jak gsk_secure_soc_misc(), są w tym trybie dozwolone. Tryb krytyczny rozszerzonej renegocjacji SSL/TLS Tryb krytyczny rozszerzonej renegocjacji określa, czy systemowa implementacja protokołu SSL/TLS wymaga, aby wszystkie węzły sieci wskazywały renegocjację zgodną z dokumentem RFC 5746 podczas początkowej negocjacji sesji. Aby całkowicie ochronić obie strony bezpiecznej sesji przed wektorem ataku przez renegocjację, wszystkie operacje negocjacji początkowych muszą wskazać obsługę dokumentu RFC Takie wskazanie może mieć postać rozszerzenia TLS renegotiation_info lub sygnalizowanej wartości zestawu algorytmów szyfrowania (Signaling Cipher Suite Value SCSV) zgodnie z definicją w dokumencie RFC Tryb krytyczny jest domyślnie wyłączony w celu zapewnienia współdziałania z implementacjami protokołu SSL/TLS, w których nie zaimplementowano obsługi dokumentu RFC Jeśli tryb krytyczny jest włączony, systemowa implementacja protokołu SSL/TLS może negocjować tylko z systemami, w których została zaimplementowana obsługa dokumentu RFC To ograniczenie obowiązuje nawet wtedy, gdy żadna ze stron nie obsługuje renegocjacji ani z niej nie korzysta. Jeśli okaże się, że wszystkie węzły sieci w systemowej implementacji protokołu SSL/TLS obsługują dokument RFC 5746, ustawienie trybu powinno zostać zmienione na włączony. Domyślny tryb krytyczny rozszerzonej renegocjacji można zmienić za pomocą komendy zaawansowanej analizy SSLCONFIG z zestawu Systemowych narzędzi serwisowych (System Service Tools SST). Istnieje właściwość dotycząca aplikacji klienckich, opcja sslrfc5746negotiationrequiredclient komendy SSLCONFIG, oraz odrębna właściwość dotycząca aplikacji serwerowych, opcja sslrfc5746negotiationrequiredserver komendy SSLCONFIG. Systemowa implementacja protokołu SSL/TLS zawsze wysyła rozszerzenie TLS "renegotiation_info" lub wartość SCSV w komunikacie ClientHello. Wartość SCSV jest wysyłana tylko wtedy, gdy komunikat ClientHello nie zawiera żadnych innych rozszerzeń. Pojęcia pokrewne: Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS) 17