IBM i: Protok|fo|fl Secure Sockets Layer (SSL) / Transport Layer

Transkrypt

IBM i
Wersja 7.3
Bezpieczeństwo
Protokół Secure Sockets Layer (SSL)
/ Transport Layer Security (TLS)
IBM
IBM i
Wersja 7.3
Bezpieczeństwo
Protokół Secure Sockets Layer (SSL)
/ Transport Layer Security (TLS)
IBM
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.
Spis treści
Protokół Secure Sockets Layer (SSL) /
Transport Layer Security (TLS) . . . . . 1
|
|
|
|
|
|
Co nowego w systemie IBM i 7.3 . . . . . . .
Plik PDF z informacjami na temat protokołu SSL/TLS .
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 .
Algorytmy podpisu . . . . . . . . .
Minimalna wielkość klucza RSA . . . . .
Nazwane krzywe ECDSA . . . . . . .
Renegocjacja . . . . . . . . . . .
Protokół OCSP (Online Certificate Status Protocol) .
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. . . . . .
© Copyright IBM Corp. 2002, 2015
.
.
.
.
.
1
1
2
3
4
. 4
. 4
. 5
. 7
. 12
. 14
. 15
. 16
. 18
. 18
. 20
. 21
. 22
. 23
. 24
. 24
|
|
|
|
|
|
|
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
Informacje pokrewne dotyczące protokołu SSL/TLS . .
25
25
26
26
27
27
27
28
28
29
30
31
32
33
33
Uwagi . . . . . . . . . . . . . . . 35
Znaki towarowe
Warunki . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 37
. 37
iii
iv
IBM i: Protokół Secure Sockets Layer (SSL) / Transport Layer Security (TLS)
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
służący do zaznaczania początku nowego lub zmienionego fragmentu;
v symbol
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ć.
1
Aby wyświetlić lub pobrać wersję PDF tego dokumentu, wybierz temat Protokół Secure Sockets Layer (SSL) /
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
|
|
|
|
|
|
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
|
|
|
|
|
|
|
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
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
– 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ół 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.
5
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
Definicja QSSLPCL *OPSYS
|
i 6.1
*TLSV1, *SSLV3
|
i 7.1
*TLSV1, *SSLV3
|
i 7.2
*TLSV1.2, *TLSV1.1, *TLSV1
|
|
i 7.3
*TLSV1.2, *TLSV1.1, *TLSV1
| Protokoły domyślne
|
|
|
|
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
|
|
|
|
|
|
|
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
Lista dostępnych domyślnych protokołów w najnowszej
grupowej poprawce PTF zabezpieczeń
|
i 6.1
TLSv1.0
|
i 7.1
TLSv1.0
|
i 7.2
TLSv1.2, TLSv1.1, TLSv1.0
|
|
|
i 7.3
TLSv1.2, TLSv1.1, TLSv1.0
Pojęcia pokrewne:
poziomie systemu.
“Biuletyny bezpieczeństwa” na stronie 3
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
*ECDHE_ECDSA_AES_128_GCM_SHA256
X
*ECDHE_ECDSA_AES_256_GCM_SHA384
X
TLSv1.1
TLSv1.0
SSLv3
SSLv2
7
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
X
X
X
X
X
X
X
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
*RSA_AES_256_CBC_SHA256
X
*RSA_AES_256_CBC_SHA
X
*ECDHE_ECDSA_3DES_EDE_CBC_SHA
X
*ECDHE_RSA_3DES_EDE_CBC_SHA
X
*RSA_3DES_EDE_CBC_SHA
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
X
X
*RSA_EXPORT_RC4_40_MD5
X
X
X
*RSA_EXPORT_RC2_CBC_40_MD5
X
X
X
*RSA_DES_CBC_SHA
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
|
|
|
|
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_RSA_AES_128_GCM_SHA256
|
|
v *RSA_AES_128_GCM_SHA256
|
|
v *ECDHE_ECDSA_AES_128_CBC_SHA256
|
|
|
v *ECDHE_RSA_AES_128_CBC_SHA256
|
v *RSA_AES_128_CBC_SHA256
|
v *RSA_AES_128_CBC_SHA
|
|
|
v *ECDHE_ECDSA_3DES_EDE_CBC_SHA
|
v *ECDHE_RSA_3DES_EDE_CBC_SHA
|
v *RSA_3DES_EDE_CBC_SHA
9
| 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
|
|
|
|
|
|
|
|
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
|
|
Przykład ustawienia tylko zestawów algorytmów szyfrowania ECDHE jako domyślnych w systemie:
|
|
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_3DES_EDE_CBC_SHA
|
|
v *ECDHE_RSA_3DES_EDE_CBC_SHA
v *RSA_3DES_EDE_CBC_SHA
SSLCONFIG -eligibleDefaultCipherSuites:YE,YD,YC,YB,YA,Y9,Y8,Y7,Y6,Y3
Pojęcia pokrewne:
poziomie systemu.
Wartość systemowa SSL/TLS: QSSLCSLCTL
11
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
|
|
Uwaga: Ustawienie supportedSignatureAlgorithmList komendy SSLCONFIG jest resetowane po zainstalowaniu
|
|
|
Przykład ustawiania algorytmów podpisu ECDSA i RSA jako obsługiwanych algorytmów podpisu w systemie:
|
|
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
|
|
Przykład ustawiania algorytmu podpisu ECDSA jako domyślnego algorytmu podpisu w systemie:
|
Kolejność listy domyślnych algorytmów podpisu w konfiguracji fabrycznej jest następująca:
|
v ECDSA_SHA512
SSLCONFIG
-supportedSignatureAlgorithmList:36,35,34,33,32,16,15,14,13,12
SSLCONFIG -signatureAlgorithmList:36,35,34,33,32
13
| 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:
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
|
|
|
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:
poziomie systemu.
|
|
|
|
Nazwane krzywe ECDSA
|
|
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
|
|
|
Przykład: ustawienie kluczy o wielkości 256, 384 i 521 bitów na liście obsługiwanych nazwanych krzywych w
systemie:
|
|
W konfiguracji fabrycznej systemowa implementacja protokołu SSL/TLS obsługuje następującą listę nazwanych
krzywych:
|
v Secp521r1
|
v Secp384r1
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.
SSLCONFIG -supportedNamedCurve:23,24,25
15
| 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:
|
|
|
|
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
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 5746. 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 5746.
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 5746. 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 5746. 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:
17
poziomie systemu.
RFC 5746: "Transport Layer Security (TLS) Renegotiation Indication Extension"
Protokół OCSP (Online Certificate Status Protocol)
Protokół OCSP (Online Certificate Status Protocol) umożliwia aplikacjom ustalenie statusu wycofania certyfikatu
cyfrowego. Status wycofania certyfikatu sprawdzony za pomocą protokołu OCSP zawiera informacje bliższe stanowi
faktycznemu niż te dostępne na listach wycofania certyfikatów.
Implementacja sprawdzania statusu za pomocą protokołu OCSP jest zgodna z dokumentem RFC 2560. Sprawdzanie
statusu wycofania certyfikatu za pomocą protokołu OCSP dotyczy certyfikatów jednostek końcowych. Obsługiwane są
komunikacja HTTP przy użyciu wersji 1 protokołu oraz podstawowy typ odpowiedzi.
Aplikacje sprawdzają status wycofania certyfikatu za pośrednictwem protokołu OCSP, gdy jest spełniony co najmniej
jeden z następujących warunków:
v Jest skonfigurowany adres URL respondera OCSP.
v Jest włączone sprawdzanie informacji AIA (Authority Information Access), a sprawdzany certyfikat zawiera
rozszerzenie AIA. Rozszerzenie AIA musi zawierać metodę dostępu PKIK_AD_OCSP z identyfikatorem URI
wskazującym położenie HTTP respondera OCSP.
Uwaga: Status wycofania jest sprawdzany tylko z pierwszym responderem OCSP znalezionym w rozszerzeniu
AIA.
|
|
|
|
|
Jeśli włączone jest zarówno sprawdzanie adresu URL, jak i sprawdzanie informacji AIA, adres URL respondera jest
sprawdzany w pierwszej kolejności. Tę kolejność można zmienić dla poszczególnych aplikacji przez ustawienie
atrybutu interfejsu API Global Security Kit (GSKit) o nazwie GSK_OCSP_CHECK_AIA_FIRST. Zapytanie do
drugiego respondera jest wysyłane tylko wtedy, gdy zapytanie wysłane do pierwszego respondera zwraca nieokreślony
status wycofania.
Pojęcia pokrewne:
“Wycofywanie certyfikatów” na stronie 21
Sprawdzanie wycofania certyfikatu jest jedną z faz sprawdzania poprawności certyfikatu wykonywanego w ramach
negocjacji sesji. Poprawność łańcucha certyfikatów jest sprawdzana, aby zapewnić, że certyfikat nie został wycofany.
RFC 2560: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP
Konfiguracja protokołu OCSP
Poza włączeniem protokołu OCSP (Online Certificate Status Protocol) istnieje szereg właściwości, które aplikacje
mogą konfigurować w celu dostosowania zachowania klienta OCSP.
Jeśli sprawdzanie wycofania certyfikatu za pomocą protokołu OCSP jest włączone, do respondera OCSP jest wysyłane
żądanie HTTP. Żądanie zawiera informacje identyfikujące certyfikat, którego status wycofania jest sprawdzany, oraz
opcjonalny podpis. Opcjonalny podpis w żądaniu umożliwia responderowi zweryfikowanie poprawnych żądań
otrzymywanych z klientów. Domyślnie podpisy żądań są wyłączone. Żądanie jest przesyłane do respondera przy
użyciu metody GET lub POST protokołu HTTP. Żądania wysyłane metodą GET włączają buforowanie protokołu
HTTP. Jeśli zgodnie z konfiguracją metoda GET jest preferowaną metodą, a żądanie jest mniejsze niż 255 bajtów,
żądanie jest wysyłane przy użyciu metody GET. W przeciwnym razie żądanie jest wysyłane przy użyciu metody POST.
Domyślnie preferowaną metodą jest metoda GET.
Po wysłaniu żądania operacja sprawdzenia wycofania certyfikatu za pomocą protokołu OCSP ulega zablokowaniu do
chwili otrzymania odpowiedzi z respondera lub upływu limitu czasu oczekiwania. Sprawdzanie wycofania certyfikatu
18
odbywa się w ramach negocjacji sesji, więc negocjacja sesji zostaje zablokowana do czasu zakończenia tego
sprawdzenia. Jeśli limit czasu ustawiony dla negocjacji sesji jest krótszy niż skonfigurowany limit czasu protokołu
OCSP, jako limit czasu protokołu OCSP jest używana niższa wartość. Domyślna wartość limitu czasu protokołu OCSP
to 10 sekund, ale można ją skonfigurować w aplikacji.
Poprawna odpowiedź jest podpisana i zawiera dane określające status wycofania certyfikatu, którego dotyczy
zapytanie. Status wycofania certyfikatu może mieć wartości: ważny (good), nieznany (unknown) lub wycofany
(revoked). Odpowiedź musi być podpisana przy użyciu certyfikatu spełniającego co najmniej jedno z następujących
wymagań:
v Certyfikat użyty do podpisania jest certyfikatem zaufanym w lokalnej bazie certyfikatów.
v Certyfikat użyty do podpisania jest certyfikatem ośrodka certyfikacji (CA), który wystawił certyfikat podlegający
sprawdzeniu.
v Certyfikat użyty do podpisania zawiera wartość id-ad-ocspSigning w rozszerzeniu ExtendedKeyUsage i został
wystawiony przez ośrodek CA, który wystawił certyfikat podlegający sprawdzeniu.
Odpowiedzi mogą być różnej wielkości. Ustalenie maksymalnej dozwolonej wielkości odpowiedzi jest zadaniem
aplikacji. Domyślnie maksymalna dozwolona wielkość odpowiedzi wynosi 20480 bajtów. Jeśli wielkość odpowiedzi
przekracza maksymalną dozwoloną wartość, wówczas odpowiedź jest ignorowana, a certyfikat traktowany, jakby miał
nieznany status.
Wartość jednorazowa w szyfrowaniu to mechanizm zabezpieczeń, który może służyć do sprawdzenia, czy otrzymana
odpowiedź dotyczy określonego żądania. Wartość jednorazowa w postaci generowanego losowo łańcucha bitowego
jest obliczana i umieszczana zarówno w żądaniu, jak i w odpowiedzi. Jeśli sprawdzanie wartości jednorazowej jest
włączone, jest sprawdzana zgodność wartości umieszczonej w odpowiedzi z wartością wysłaną w żądaniu. Jeśli
wartości jednorazowe nie są zgodne, taka odpowiedź jest ignorowana. Domyślnie sprawdzanie wartości jednorazowej
jest wyłączone.
Sprawdzanie wycofania certyfikatu może spowolnić negocjację sesji. Buforowanie odpowiedzi protokołu OCSP
umożliwia jednak klientowi uzyskanie statusów wycofania odpytywanych wcześniejszymi żądaniami bez ponownego
wysyłania tego samego żądania. Buforowanie odpowiedzi protokołu OCSP jest domyślnie włączone, ale można je
wyłączyć dla danej aplikacji.
Można użyć serwera proxy HTTP jako serwera pośredniego do obsługi żądań protokołu OCSP z zapisanymi w pamięci
podręcznej odpowiedziami albo do przekazywania żądań do respondera. Jeśli dla aplikacji jest skonfigurowany serwer
proxy, wszystkie żądania protokołu OCSP z tej aplikacji są wysyłane do tego serwera. Domyślny port serwera proxy to
port 80. Serwer proxy nie jest domyślnie skonfigurowany.
Funkcje API Global Security Kit (GSKit): gsk_attribute_set_buffer(), gsk_attribute_set_numeric_value() i
gsk_attribute_set_enum() służą do konfigurowania w protokole OCSP następujących atrybutów interfejsu API:
v GSK_OCSP_URL – adres URL respondera protokołu OCSP, do którego są wysyłane żądania OCSP,
v GSK_OCSP_ENABLE – włączenie sprawdzania AIA,
|
|
v GSK_OCSP_CHECK_AIA_FIRST – określenie, czy w protokole OCSP najpierw należy wykonywać sprawdzanie
adresu URL, czy informacji rozszerzenia AIA,
v GSK_OCSP_REQUEST_SIGKEYLABEL – etykieta certyfikatu użytego do podpisania żądania OCSP,
v GSK_OCSP_REQUEST_SIGALG – algorytm podpisu użyty do wygenerowania podpisu żądania OCSP,
v GSK_OCSP_RETRIEVE_VIA_GET – metoda wysyłania żądania OCSP,
v GSK_OCSP_TIMEOUT – liczba sekund oczekiwania na odpowiedź z respondera OCSP,
v GSK_OCSP_MAX_RESPONSE_SIZE – maksymalna akceptowana wielkość odpowiedzi z respondera OCSP w
bajtach,
v GSK_OCSP_CLIENT_CACHE_SIZE – włączenie lub wyłączenie pamięci podręcznej odpowiedzi w kliencie
OCSP,
v GSK_OCSP_NONCE_GENERATION_ENABLE – wysłanie rozszerzenia z wartością jednorazową w żądaniu
OCSP,
19
v GSK_OCSP_NONCE_CHECK_ENABLE – sprawdzenie zgodności rozszerzenia z wartością jednorazową w
odpowiedzi OCSP z wartością wysłaną w żądaniu OCSP,
v GSK_OCSP_NONCE_SIZE – liczba bajtów, jaka ma zostać użyta przy generowaniu wartości jednorazowej,
v GSK_OCSP_PROXY_SERVER_NAME – nazwa serwera proxy, do którego są wysyłane żądania OCSP,
v GSK_OCSP_PROXY_SERVER_PORT – numer portu serwera proxy, do którego są wysyłane żądania OCSP,
Aplikacje, w których wykorzystano zintegrowane funkcje API IBM i SSL_ lub implementację IBM i JSSE, nie są
wyposażone w interfejs konfiguracji protokołu OCSP. Dowolny program korzystający z "ID aplikacji" może jednak
włączać i wyłączać sprawdzanie wycofania certyfikatu za pomocą protokołu OCSP przy użyciu narzędzia DCM. Dla
wszystkich pozostałych opcji konfiguracji protokołu OCSP są używane wartości domyślne.
Pojęcia pokrewne:
“Atrybuty protokołu OCSP (Online Certificate Status Protocol)” na stronie 26
Pola atrybutów protokołu OCSP (Online Certificate Status Protocol) służą do sterowania włączaniem obsługi protokołu
OCSP.
Funkcje API z zestawu Global Security Kit (GSKit)
Status wycofania OCSP
Status wycofania OCSP jest określany na podstawie odpowiedzi OCSP wysyłanej w reakcji na żądanie OCSP. Istnieją
dwa rodzaje odpowiedzi. Jeden rodzaj wskazuje, że responder OCSP wysłał poprawną odpowiedź; drugi rodzaj jest
sygnałem, że responder napotkał problem przy przetwarzaniu wcześniejszego żądania.
Problemy, jakie może napotkać responder podczas przetwarzania żądania, to m.in.:
v malformedRequest – zniekształcone żądanie.
v internalError – błąd wewnętrzny respondera OCSP.
v tryLater – tymczasowa niemożność wysłania odpowiedzi przez responder OCSP; należy ponowić żądanie później.
v sigRequired – responder OCSP wymaga, aby żądanie było podpisane.
v unauthorized – klient OCSP nie jest uprawniony do odpytywania respondera OCSP.
Poprawna odpowiedź zawiera status wycofania certyfikatu, którego dotyczy zapytanie. Możliwe wartości statusu
certyfikatu to ważny (good), wycofany (revoked) oraz nieznany. Sprawdzenie statusu wycofania certyfikatu za pomocą
protokołu OCSP uważa się za ukończone, jeśli został zwrócony status wycofania certyfikatu „ważny” lub „wycofany”.
Status „ważny” umożliwia kontynuowanie uzgadniania, a status „wycofany” powoduje niepowodzenie uzgadniania.
Jeśli status wycofania pozostaje nieokreślony zarówno w przypadku sprawdzenia adresu URL, jak i sprawdzenia AIA,
certyfikat może być używany. Informacje o certyfikacie o nieokreślonym statusie wycofania można uzyskać za pomocą
funkcji gsk_attribute_get_buffer() i atrybutu GSK_UNKNOWNREVOCATIONSTATUS_SUBJECT. Aplikacja
powinna zamknąć połączenie, jeśli nieokreślony status wycofania nie jest dozwolony.
Nieokreślony status wycofania
Status wycofania pozostaje nieokreślony w przypadku następujących odpowiedzi:
v Brak odpowiedzi w ciągu określonego limitu czasu
v Status odpowiedzi OCSP wskazujący, że responder napotkał problem
v Poprawna odpowiedź spełniająca jeden z następujących warunków:
– Nieznany typ odpowiedzi (obsługiwany jest tylko typ odpowiedzi PKIX_AD_OCSP_basic)
– Nieznana wersja odpowiedzi (obsługiwana jest tylko wersja 1)
– Niepoprawny podpis lub niepoprawny certyfikat użyty do podpisania odpowiedzi
- Certyfikat użyty do podpisania odpowiedzi musi spełniać jedno z następujących kryteriów:
v Być certyfikatem zaufanym w lokalnym magazynie kluczy
v Być certyfikatem ośrodka certyfikacji (CA), który wystawić certyfikat podlegający sprawdzeniu
20
v Zawierać wartość id-ad-ocspSigning w rozszerzeniu ExtendedKeyUsage i być wystawiony przez ośrodek
CA, który wystawił certyfikat podlegający sprawdzeniu
– Brak wartości jednorazowej w odpowiedzi w przypadku, gdy sprawdzanie wartości jednorazowych jest
wymagane
– Niepoprawna wartość jednorazowa w odpowiedzi w przypadku, gdy sprawdzanie wartości jednorazowych jest
wymagane
– Niepoprawna lub nieważna wartość nextUpdate określona w odpowiedzi
– Wartość statusu certyfikatu "unknown", która wskazuje, że responder nie zna statusu certyfikatu
Wycofywanie certyfikatów
Przy sprawdzaniu wycofania certyfikatu są wykonywane następujące kroki:
1. Sprawdzenie statusu wycofania w położeniu listy wycofań certyfikatów (CRL).
a. Jeśli położenie listy wycofań certyfikatów jest skonfigurowane przy użyciu programu Digital Certificate
Manager (DCM), serwer LDAP bazy danych list wycofań certyfikatów jest odpytywany w poszukiwaniu list
wycofań certyfikatów zawierających status wycofania danego certyfikatu.
v Jeśli certyfikat jest wycofany, faza wycofywania certyfikatu w ramach sprawdzania poprawności certyfikatu
zostaje zakończona, a negocjacja sesji kończy się niepowodzeniem.
v W przeciwnym razie przetwarzanie wycofania certyfikatu jest kontynuowane.
Uwaga: Położenia list wycofań certyfikatów są konfigurowane w lokalnej bazie certyfikatów osobno dla
każdego ośrodka certyfikacji (CA).
2. Status wycofania jest sprawdzany za pomocą protokołu OCSP (Online Certificate Status Protocol).
|
|
|
Jeśli włączone jest zarówno sprawdzanie adresu URL, jak i sprawdzanie informacji AIA, to kolejność odpytywania
responderów jest ustalana na podstawie wartości atrybutu interfejsu API Global Security Kit (GSKit) o nazwie
GSK_OCSP_CHECK_AIA_FIRST. Domyślnie najpierw jest sprawdzany adres URL respondera.
a. Jeśli jest skonfigurowany adres URL respondera OCSP, responder jest odpytywany.
v Jeśli certyfikat jest poprawny, faza wycofywania certyfikatu w ramach sprawdzania poprawności certyfikatu
zostaje zakończona i negocjacja sesji jest kontynuowana.
v Jeśli nie udało się ustalić stanu wycofania certyfikatu, przetwarzanie wycofania certyfikatu jest
kontynuowane.
b. Jeśli jest włączone sprawdzanie AIA, a dla certyfikatu jest zdefiniowana metoda dostępu PKIK_AD_OCSP z
identyfikatorem URI wskazującym adres protokołu HTTP, taki responder jest odpytywany.
v Jeśli certyfikat jest poprawny, faza wycofywania certyfikatu w ramach sprawdzania poprawności certyfikatu
zostaje zakończona i negocjacja sesji jest kontynuowana.
v Jeśli nie udało się ustalić stanu wycofania certyfikatu, faza wycofywania certyfikatu w ramach sprawdzania
poprawności certyfikatu zostaje zakończona i sprawdzanie poprawności certyfikatu jest kontynuowane.
Uwaga: Jeśli status wycofania pozostaje nieustalony, GSKit zapisuje informacje o certyfikacie z nieustalonym
statusem wycofania i kontynuuje działanie tak, jakby zwrócono status inny niż "wycofany". Aplikacja może pobrać
informacje o nieustalonym statusie certyfikatu za pomocą funkcji gsk_attribute_get_buffer() oraz atrybutu
GSK_UNKNOWNREVOCATIONSTATUS_SUBJECT i zdecydować w oparciu o zdefiniowaną strategię, czy
połączenie ma być kontynuowane, czy przerwane.
21
Uwaga: Definicja aplikacji skonfigurowana w narzędziu DCM może nadpisywać sprawdzanie wycofań za pomocą list
CRL i protokołu OCSP skonfigurowane w aplikacji korzystającej z tej definicji.
Pojęcia pokrewne:
“Protokół OCSP (Online Certificate Status Protocol)” na stronie 18
Zarządzanie położeniami listy CRL
Wybór wielu certyfikatów
Systemowa implementacja protokołu SSL/TLS umożliwia przypisanie nie więcej niż czterech certyfikatów do
bezpiecznego środowiska. Obsługę wielu certyfikatów stosuje się w sytuacjach, gdy ma zostać włączona obsługa
certyfikatów ECDSA (Elliptic Curve Digital Signature Algorithm), a jednocześnie mają być obsługiwane certyfikaty
RSA dla klientów, które wymagają szyfrowania RSA.
W celu zapewnienia najlepszego współdziałania serwer musi być w stanie negocjować z wieloma rodzajami klientów o
zróżnicowanych możliwościach obsługi protokołu SSL/TLS. Jeśli dany klient nie obsługuje certyfikatów TLSv1.2 ani
ECDSA, serwer musi nadal obsługiwać używany certyfikat RSA w celu negocjowania bezpiecznego połączenia z
klientem.
Istnieją dwie metody konfigurowania obsługi wielu certyfikatów przez dane środowisko:
v Przypisanie wielu certyfikatów do definicji aplikacji skonfigurowanej dla bezpiecznego środowiska w programie
Digital Certificate Manager (DCM).
v Skonfigurowanie listy etykiet certyfikatów, które mają być używane, za pomocą funkcji interfejsu API GSKit
gsk_attribute_set_buffer(GSK_KEYRING_LABEL_EX).
Podczas uzgadniania każdej sesji SSL/TLS odpowiedni certyfikat dla tej sesji jest wybierany na podstawie atrybutów
sesji. Przy podejmowaniu decyzji są uwzględniane atrybuty SSL/TLS zarówno po stronie klienta, jak i serwera. Może
dojść do sytuacji, że dla danej kombinacji atrybutów nie zostanie znaleziony certyfikat możliwy do użycia.
Uwagi dotyczące wyboru
W przypadku negocjacji protokołów TLSv1.1, TLSv1.0, SSLv3 oraz SSLv2 jest używany pierwszy znaleziony
certyfikat RSA, dla którego istnieje również podpis RSA.
Jeśli negocjowanym protokołem jest protokół TLSv1.2, wówczas proces wyboru składa się z kilku kroków.
1. Proces wyboru zaczyna się od typu klucza zestawu algorytmów szyfrowania preferowanego na serwerze i
obsługiwanego przez klienta. Certyfikat może być zaopatrzony w klucz ECDSA albo w klucz RSA. Jeśli nazwa
zestawu algorytmów szyfrowania zawiera ciąg “ECDSA”, wówczas należy użyć klucza/certyfikatu ECDSA. Jeśli
nazwa zestawu algorytmów szyfrowania zawiera ciąg “RSA”, wówczas należy użyć klucza/certyfikatu RSA. Jeśli
nie istnieje zgodny certyfikat, proces wyboru przechodzi do następnego zestawu algorytmów szyfrowania do chwili
znalezienia zestawu, który działa z jednym z certyfikatów.
W przypadku znalezienia co najmniej jednego dopasowania typu klucza certyfikatu są sprawdzane dodatkowe
kryteria w celu ustalenia, czy któryś z tych certyfikatów może zostać użyty, na podstawie atrybutów uzgadniania.
2. Jeśli rozważanym typem klucza jest ECDSA, nazwana krzywa (odpowiadająca wielkości klucza) musi być
obsługiwana przez węzeł sieci. Jeśli rozważane certyfikaty ECDSA mają różne nazwane krzywe, wówczas
preferowany certyfikat jest ustalany zgodnie z preferowaną przez węzeł sieci kolejnością nazwanych krzywych. Po
wykonaniu tego kroku może zostać wybrany więcej niż jeden certyfikat. Jeśli po tym kroku nie pozostały żadne
zakwalifikowane certyfikaty, należy wrócić do poprzedniego kroku.
3. Zarówno certyfikaty RSA, jak i ECDSA są opatrzone podpisem wystawiającego ośrodka certyfikacji. Typ klucza
podpisu może być inny niż typ klucza certyfikatu serwera. Jeśli w tej fazie pozostał więcej niż jeden
zakwalifikowany certyfikat, jest wybierany taki, którego podpis jest pierwszy w kolejności preferencji węzła sieci.
22
Certyfikat ECDSA musi korzystać z algorytmu podpisu dozwolonego na uporządkowanej liście algorytmów
podpisu po stronie węzła sieci. Jeśli żaden certyfikat ECDSA w tym kroku nie korzysta z obsługiwanego algorytmu
podpisu, należy wrócić do poprzedniego kroku i uwzględnić przy przetwarzaniu wyboru nazwaną krzywą o niższej
pozycji w kolejności preferencji.
Jeśli żaden certyfikat RSA w tym kroku nie korzysta z obsługiwanego algorytmu podpisu, należy wrócić do
pierwszego kroku i uwzględnić przy przetwarzaniu wyboru inny typ klucza.
Jeśli po wykonaniu tego kroku nadal pozostaje więcej niż jeden równoważny certyfikat, zostaje wybrany pierwszy
przetwarzany certyfikat. Pozostałe równoważne certyfikaty nie zostają nigdy wybrane, ponieważ są
kryptograficznie identyczne z pierwszym certyfikatem. Należy usunąć dodatkowe certyfikaty z konfiguracji, aby
wyeliminować zbędne przetwarzanie w procesie wyboru.
|
|
|
|
4. Jeśli przetwarzanie zakończy się bez znalezienia certyfikatu, który spełniałby wymienione kryteria wyboru,
wówczas zostaje wybrany pierwszy przetwarzany certyfikat RSA, jeśli na liście znajduje się zestaw algorytmów
szyfrowania RSA. Jeśli nie zostanie wybrany żaden certyfikat RSA, to wybierany jest pierwszy przetwarzany
certyfikat ECDSA, pod warunkiem że zestaw algorytmów szyfrowania ECDSA znajduje się na liście.
|
|
Węzeł sieci podejmuje ostateczną decyzję o zezwoleniu na użycie certyfikatu, a zatem o tym, czy połączenie
będzie działać.
Definicje aplikacji w programie DCM
Program Digital Certificate Manager (DCM) służy do zarządzania bazą danych aplikacji, zawierającą definicje
aplikacji. Każda definicja aplikacji obejmuje informacje o sposobie przetwarzania certyfikatów w danej aplikacji. W
wersji IBM i 7.1 definicja aplikacji zawiera również niektóre atrybuty systemowej implementacji protokołu SSL/TLS
dotyczące tej aplikacji. Taka definicja aplikacji jest znana użytkownikom systemowej implementacji protokołu
SSL/TLS jako „ID aplikacji”.
Definicje aplikacji są używane do konfigurowania informacji o certyfikatach w wielu aplikacjach udostępnianych z
systemem IBM i. Programiści aplikacji mogą zaprojektować dowolne aplikacje tak, aby korzystały one z definicji
aplikacji.
Definicjami aplikacji można zarządzać za pomocą menu Zarządzaj aplikacjami w programie DCM.
v Zarządzanie definicjami aplikacji w bazie certyfikatów *SYSTEM
1. Kliknij opcję Wybierz bazę certyfikatów w lewym panelu nawigacyjnym.
2. Wybierz *SYSTEM i kliknij przycisk Kontynuuj.
3. Wpisz hasło powiązane z bazą certyfikatów *SYSTEM i kliknij przycisk Kontynuuj.
4. Rozwiń menu Zarządzaj aplikacjami w lewym panelu nawigacyjnym.
v Wyświetlanie definicji aplikacji w bazie certyfikatów *SYSTEM
1. Kliknij opcję Wyświetl definicję aplikacji w menu Zarządzaj aplikacjami.
2. Wybierz opcję Serwer lub Klient dla typu definicji aplikacji, która ma zostać wyświetlona. Kliknij przycisk
Kontynuuj (Continue).
3. Wybierz definicję aplikacji, która ma zostać wyświetlona. Kliknij opcję Wyświetl.
v Aktualizowanie definicji aplikacji w bazie certyfikatów *SYSTEM.
1. Kliknij opcję Aktualizuj definicję aplikacji w menu Zarządzaj aplikacjami.
2. Wybierz opcję Serwer lub Klient dla typu definicji aplikacji, która ma zostać zaktualizowana. Kliknij przycisk
Kontynuuj (Continue).
3. Wybierz definicję aplikacji, która ma zostać zaktualizowana. Kliknij opcję Aktualizuj definicję aplikacji.
4. Zaktualizuj atrybuty protokołu TLS/SSL, które mają zostać zmienione, a następnie kliknij przycisk Zastosuj,
aby zapisać zmiany.
Definicja aplikacji w programie DCM zawiera dwa pola, na podstawie których jest identyfikowana. Pole Opis
aplikacji służy do odnajdywania definicji aplikacji w programie DCM i do wykonywania działań z nią związanych.
Pole ID aplikacji jest używane przez systemową implementację protokołu SSL/TLS do identyfikowania definicji
aplikacji zawierającej informacje konfiguracyjne.
23
Każdy z następujących interfejsów programowania systemowej implementacji protokołu SSL/TLS zawiera metodę
określania ID aplikacji, jakie powinno zostać użyte.
v Funkcje API z zestawu Global Security Kit (GSKit)
– gsk_attribute_set_buffer(z atrybutem GSK_IBMI_APPLICATION_ID)
v Zintegrowane z systemem IBM i interfejsy API SSL_
– SSL_Init_Application(wartość ustawiana w strukturze SSLInitAppStr)
v Zintegrowana z systemem IBM i implementacja JSSE
– Właściwość systemowa języka Java os400.secureApplication
Do sterowania odpowiednimi atrybutami systemowej implementacji protokołu SSL/TLS w aplikacji można użyć
następujących pól definicji aplikacji w programie DCM:
Protokoły SSL
Pole definicji aplikacji Protokoły SSL określa, które wersje protokołu SSL/TLS są obsługiwane w aplikacji.
Wartość domyślna *PGM oznacza, że program korzystający z danego „ID aplikacji” ustawia atrybut protokołu
SSL/TLS na odpowiednią wartość. Wszystkie programy systemowej implementacji protokołu SSL/TLS zawierają
wartość atrybutu ustawianą jawnie za pomocą wywołania funkcji API lub niejawnie przez zezwolenie na użycie
systemowej wartości domyślnej. Należy używać wartości *PGM, chyba że wymagana wartość atrybutu nie jest
ustawiana w programie.
Jeśli ustawienie *PGM nie powoduje użycia właściwych protokołów, to wartość tego pola definicji aplikacji może
nadpisywać protokoły obsługiwane w aplikacji. Jeśli co najmniej jeden ze wskazanych tu protokołów jest włączony w
systemie za pomocą wartości systemowej QSSLPCL, to protokoły, które nie są włączone w systemie, są ignorowane
w trybie cichym. Należy w miarę możliwości trzymać się kroków konfiguracji opisanych w dokumentacji aplikacji w
celu ustawienia protokołów zamiast korzystać z pola definicji aplikacji. Administrator może skonfigurować słabsze
właściwości zabezpieczeń dla aplikacji IBM, niż wcześniej było to możliwe przy użyciu tego pola.
Opcje specyfikacji szyfrów SSL
Pole definicji aplikacji Opcje specyfikacji algorytmów szyfrowania warstwy SSL określa, jakie zestawy algorytmów
szyfrowania SSL/TLS są obsługiwane w aplikacji.
Wartość domyślna *PGM oznacza, że program korzystający z danego „ID aplikacji” ustawia odpowiednią wartość
atrybutu obsługiwanych zestawów algorytmów szyfrowania. Wartość może być w programie ustawiana jawnie za
pomocą wywołania funkcji API lub niejawnie przez zezwolenie na użycie systemowej wartości domyślnej.
Jeśli wartość *PGM powoduje ustawienie niepoprawnej wartości, w tym polu można zdefiniować zestawy algorytmów
szyfrowania warstwy SSL/TLS obsługiwane przez tę aplikację. Zestawy algorytmów szyfrowania wyłączone za
pomocą wartości systemowej QSSLCSL są ignorowane, jeśli jest włączony co najmniej jeden zestaw algorytmów
szyfrowania.
Serwer steruje obsługiwanymi zestawami algorytmów szyfrowania za pomocą listy uporządkowanej według priorytetu.
W celu określenia odpowiedniej konfiguracji administrator korzysta z uwag dotyczących strategii bezpieczeństwa,
wydajności i współdziałania. Ewentualne zmiany na liście należy dokładnie rozważyć. Elastyczność listy
zdefiniowanej przez użytkownika umożliwia konfigurację zabezpieczeń słabszych w porównaniu z konfiguracją
dyktowaną przez wartość *PGM. Osłabienie zabezpieczeń może polegać na:
v wyborze wyższego priorytetu dla stosunkowo słabego algorytmu szyfrowania,
v wyłączeniu stosunkowo silnego algorytmu szyfrowania,
v włączeniu stosunkowo słabego algorytmu szyfrowania.
Serwer jest chroniony jedynie w takim stopniu, na jaki pozwala najsłabszy dozwolony zestaw algorytmów szyfrowania
(niezależnie od miejsca zestawu na liście).
24
Tryb krytyczny rozszerzonej renegocjacji
To pole definicji aplikacji określa, czy aplikacja wymaga, aby węzeł sieci udostępnił wskazanie renegocjacji zgodne z
dokumentem RFC 5746 podczas wstępnego uzgadniania sesji.
Więcej informacji na ten temat zawiera sekcja Tryb krytyczny rozszerzonej renegocjacji SSL/TLS w temacie
“Renegocjacja” na stronie 16, w ramach tematu nadrzędnego “Ustawienia systemowej implementacji protokołu
SSL/TLS na poziomie systemu” na stronie 4.
Wartość domyślna *PGM oznacza, że program korzystający z danego „ID aplikacji” już ustawił odpowiednią wartość
trybu. Program albo korzysta z domyślnej wartości systemowej implementacji protokołu SSL/TLS, albo z wartości
ustawionej jawnie za pomocą wywołania funkcji API gsk_attribute_set_enum() dla tego atrybutu.
Ustawienie "włączony" ("Enable") powoduje, że wskazanie renegocjacji zgodne z dokumentem RFC 5746 podczas
wstępnego uzgadniania sesji jest wymagane, aby uzgadnianie się powiodło. Z założenia taka aplikacja nie może wtedy
uzgodnić sesji z węzłami sieci, które nie zostały lub nie mogą zostać zaktualizowane o obsługę dokumentu RFC 5746.
Należy ustawić to pole definicji aplikacji na wartość "wyłączony" ("Disable"), jeśli aplikacja nie wymaga wskazania
renegocjacji zgodnego z dokumentem RFC 5746 od węzła sieci podczas wstępnego uzgadniania. Wskazanie ponownej
negocjacji zgodnie z dokumentem RFC 5746 będzie nadal wymagane w przypadku każdego uzgadniania z ponowną
negocjacją.
Uwaga: Aplikacja zawsze będzie udostępniać węzłowi sieci informacje dotyczące wskazania ponownej negocjacji
zgodnie z dokumentem RFC 5746 niezależnie od wartości tego ustawienia.
RFC 5746: "Transport Layer Security (TLS) Renegotiation Indication Extension"
Wskazanie nazwy serwera
Pole definicji aplikacji Wskazanie nazwy serwera (SNI) służy do instruowania systemowej implementacji protokołu
SSL/TLS, aby zapewniała ograniczoną obsługę SNI dla tej aplikacji.
Zgodnie z definicją w dokumencie RFC 6066, mechanizm SNI umożliwia klientom TLS podanie serwerowi TLS
nazwy serwera, z którym nawiązują kontakt. Ta funkcja jest używana do obsługi bezpiecznych połączeń z serwerami
udostępniającymi wiele serwerów wirtualnych pod jednym bazowym adresem sieciowym. Aby korzystać z
mechanizmu SNI w ten sposób na kliencie lub serwerze, należy użyć funkcji gsk_attribute_set_buffer() do
skonfigurowania SNI w aplikacji.
Jeśli jest potrzebna ograniczona obsługa SNI, wprowadź pełną nazwę domeny (FQDN) aplikacji serwerowej. Jeśli
obsługa nie jest wymagana, zaakceptuj domyślną wartość *NONE w celu włączenia ograniczonej obsługi SNI bez
nadpisywania istniejącej konfiguracji aplikacji związanej z mechanizmem SNI.
Jeśli w aplikacji informacje SNI są konfigurowane przy użyciu funkcji gsk_attribute_set_buffer(), wówczas wartość
ustawiona w tym polu definicji aplikacji jest dopisywana na końcu istniejących informacji w tym polu. Jeśli istniejące
informacje są skonfigurowane jako newralgiczne, wówczas ta wartość również zostanie uznana za newralgiczną.
Wartość newralgiczna oznacza, że jeśli nazwa FQDN podana przez klienta nie jest zgodna z żadną nazwą na liście
serwera, serwer powoduje niepowodzenie negocjacji sesji. Jeśli nie ma zdefiniowanych wcześniej informacji,
ograniczona obsługa SNI nie jest traktowana jako newralgiczna.
Przypadek użycia ustawienia pola ograniczonej obsługi SNI: z przedsiębiorstwem kontaktuje się użytkownik jego
usług. Użytkownik ma nowe wymaganie w zakresie bezpieczeństwa – wszystkie serwery TLS, z którymi się
komunikuje, mają udostępniać potwierdzenie SNI serwera. Serwer przedsiębiorstwa jest prostym serwerem, używanym
tylko do udostępniania jednej usługi, i nie ma potrzeby konfigurowania na nim serwerów wirtualnych.
25
Ustawienie nazwy FQDN serwera umożliwia systemowej implementacji protokołu SSL/TLS wysłanie potwierdzenia
SNI serwera, jeśli nadejdzie odpowiednie żądanie. Wysyłany jest certyfikat serwera przypisany do definicji aplikacji. Z
punktu widzenia serwera nic się nie zmienia, ale wymaganie klienta węzła sieci jest spełnione.
Jeśli zażądana przez klienta nazwa FQDN nie jest zgodna (ponieważ to pole nie zostało ustawione lub zawierało inną
wartość), nie zostanie wysłane żadne potwierdzenie SNI serwera. Serwer kontynuuje proces negocjowania uzgadniania
tak, jakby nie zostało utworzone żadne żądanie SNI. Klient określa, czy taka sytuacja stanowi błąd krytyczny
dotyczący negocjacji sesji.
RFC 6066: "Transport Layer Security (TLS) Extensions: Extension Definitions"
Atrybuty protokołu OCSP (Online Certificate Status Protocol)
Pola atrybutów protokołu OCSP (Online Certificate Status Protocol) służą do sterowania włączaniem obsługi protokołu
OCSP.
Protokół OSCP jest mechanizmem ustalania statusu wycofania certyfikatu. Więcej informacji dotyczących
przetwarzania tego statusu można znaleźć w szczegółowym opisie protokołu OCSP. Funkcje API z pakietu GSKit
umożliwiają konfigurowanie licznych atrybutów opisujących przetwarzanie za pomocą protokołu OCSP.
Definicja aplikacji zawiera dwa pola atrybutów OCSP używane do sterowania włączaniem obsługi protokołu OCSP.
Innych atrybutów protokołu OCSP nie można zmieniać w definicji aplikacji. Wartości takich innych atrybutów są
ustalane za pomocą ustawień interfejsu API GSKit lub jako wewnętrzne wartości domyślne.
Pojęcia pokrewne:
“Protokół OCSP (Online Certificate Status Protocol)” na stronie 18
RFC 2560: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP
Adres URL protokołu OCSP:
Pole definicji aplikacji Adres URL protokołu OCSP określa, czy ta aplikacja korzysta z ogólnego respondera
protokołu OCSP (Online Certificate Status Protocol) do wysyłania żądań podczas sprawdzania poprawności
certyfikatów jednostek końcowych.
Jeśli adres URL jest ustawiony, z określonym responderem OCSP jest nawiązywane połączenie przy ustalaniu statusu
wycofania wszystkich certyfikatów jednostek końcowych.
Wartość domyślna *PGM oznacza, że program korzystający z danego „ID aplikacji” ustawia atrybut na odpowiednią
wartość. Wszystkie atrybuty systemowej implementacji protokołu SSL/TLS mają początkową wartość domyślną, a w
przypadku tego atrybutu jest to brak adresu URL. Programy mogą wywoływać funkcję gsk_attribute_set_buffer() w
celu jawnego ustawienia wartości adresu URL.
Jeśli ustawienie *PGM nie powoduje nawiązania połączenia z żądanym responderem OCSP, należy wprowadzić w tym
polu odpowiedni adres URL respondera OCSP. HTTP to jedyny obsługiwany protokół adresów URL. Oznacza to, że ta
wartość musi rozpoczynać się łańcuchem http://. Ustawienie tej wartości nadpisuje wewnętrzną konfigurację programu
w zakresie miejsca docelowego adresu URL. Inne skonfigurowane atrybuty OCSP są jednak nadal używane.
Jeśli ustawienie *PGM powoduje użycie respondera OCSP przez aplikację, ale ogólne przetwarzanie respondera OCSP
jest niepożądane, należy ustawić w tym polu wartość „Disable” (Wyłącz). To ustawienie nadpisuje adres URL
skonfigurowany wewnętrznie za pomocą funkcji gsk_attribute_set_buffer(). Wyłączenie obsługi protokołu OCSP
osłabia model zabezpieczeń aplikacji, więc taką decyzję należy podejmować po jej dokładnym rozważeniu.
Pojęcia pokrewne:
26
Przetwarzanie informacji AIA za pomocą protokołu OCSP:
Pole definicji aplikacji Przetwarzanie informacji AIA (Authority Information Access) za pomocą protokołu
OCSP (Online Certificate Status Protocol) określa, czy wykonywane przy użyciu protokołu OCSP sprawdzanie
wycofania certyfikatu korzysta z informacji rozszerzenia AIA tego certyfikatu.
Informacje rozszerzenia AIA certyfikatu są używane do sprawdzania wycofania, jeśli status wycofania OCSP jest
nieokreślony i są spełnione oba poniższe warunki:
v Sprawdzanie informacji AIA za pomocą protokołu OCSP jest włączone.
v Sprawdzany certyfikat ma rozszerzenie AIA o metodzie dostępu PKIK_AD_OCSP, zawierające identyfikator URI
położenia HTTP respondera OCSP.
Uwaga: Status wycofania jest sprawdzany z pierwszym responderem OCSP znalezionym w rozszerzeniu AIA.
Wartość domyślna *PGM oznacza, że program korzystający z danego „ID aplikacji” ustawia atrybut na odpowiednią
wartość. Wszystkie atrybuty systemowej implementacji protokołu SSL/TLS mają początkową wartość domyślną. Dla
tego atrybutu wartość domyślna jest wyłączona. W programach można jawnie włączać i wyłączać sprawdzanie
informacji AIA za pomocą protokołu OCSP przy użyciu metody gsk_attribute_set_enum().
Jeśli wartość *PGM nie powoduje sprawdzania informacji AIA za pomocą protokołu OCSP, a sprawdzanie wycofania
jest pożądane, należy ustawić w tym polu wartość „włączone” (Enable). Ustawienie wewnętrzne jest nadpisywane i
sprawdzanie za pomocą protokołu OCSP zostaje wykonane, jeśli informacje AIA są dostępne.
Jeśli wartość *PGM powoduje sprawdzanie informacji AIA za pomocą protokołu OCSP, a sprawdzanie wycofania nie
jest pożądane, należy ustawić w tym polu wartość „wyłączone” (Disable). Wyłączenie obsługi protokołu OCSP osłabia
model zabezpieczeń aplikacji, więc taką decyzję należy podejmować po jej dokładnym rozważeniu.
Pojęcia pokrewne:
Algorytmy podpisu SSL
Pole definicji aplikacji Algorytmy podpisu SSL określa, jakie algorytmy są obsługiwane w aplikacji.
Więcej informacji na temat algorytmów podpisu i ich zastosowań zawiera temat “Algorytmy podpisu” na stronie 12 w
sekcji “Ustawienia systemowej implementacji protokołu SSL/TLS na poziomie systemu” na stronie 4.
Wartość domyślna *PGM oznacza, że program korzystający z danego „ID aplikacji” ustawia pole algorytmów podpisu
SSL na odpowiednią wartość. Wszystkie atrybuty systemowej implementacji protokołu SSL/TLS mają początkową
wartość domyślną. Programy mogą jawnie definiować listę przy użyciu funkcji gsk_attribute_set_buffer().
Jeśli ustawienie *PGM powoduje niepoprawność konfiguracji, należy ustawić w tym polu wartość zawierającą
wymaganą uporządkowaną listę obsługiwanych algorytmów podpisu.
Komenda SSLCONFIG
poziomie systemu.
Aby skorzystać z obsługi konfiguracji protokołu SSL/TLS za pomocą komend dostarczonych przez IBM, wykonaj
następujące czynności:
27
1. Uruchom Systemowe narzędzia serwisowe (SST) za pomocą komendy CL Uruchomienie SST (STRSST).
2. Wybierz opcję Uruchomienie narzędzia serwisowego.
3. Wybierz Wyświetl/Zmień/Zrzuć.
4. Wybierz Wyświetl/Zmień pamięć.
5. Wybierz Dane Licencjonowanego kodu wewnętrznego (LIC).
6. Wybierz Zaawansowana analiza. (Aby zobaczyć tę opcję, należy przewinąć stronę do góry.)
7. Przewiń do dołu aż do znalezienia opcji SSLCONFIG. Następnie umieść 1 (Wybierz) obok opcji i naciśnij klawisz
Enter. Bieżącym oknem jest okno Określanie opcji zaawansowanej analizy. Jest wyświetlona komenda
SSLCONFIG.
8. Wpisz "-h" bez cudzysłowów i naciśnij klawisz Enter, aby wyświetlić dostępne opcje.
|
|
Sposoby określania protokołów i zestawów algorytmów szyfrowania
systemowej implementacji protokołu SSL/TLS używanych w systemie
| Protokoły i zestawy algorytmów szyfrowania systemowej implementacji protokołu SSL/TLS używane w systemie
| można określić za pomocą funkcji kontroli lub śledzenia dostępnych w systemie.
| Kronika kontroli
| Protokół i zestaw algorytmów szyfrowania dla połączenia systemowej implementacji protokołu SSL/TLS są
| przechwytywane podczas kontroli chronionych połączeń przez gniazdo.
|
|
|
|
|
Kontrola chronionych połączeń przez gniazdo jest włączona, jeśli dla wartości systemowej QAUDLVL/QAUDLVL2
zostanie ustawiona wartość *NETSECURE. Każde pomyślne połączenie generuje pozycję kroniki SK (połączenia
przez gniazdo) z typem pozycji S (pomyślne połączenie chronione). Pozycja kroniki zawiera informacje o protokole w
polu "Secure version" ("Wersja zabezpieczeń") oraz o zestawie algorytmów szyfrowania w polu "Secure properties"
("Właściwości zabezpieczeń").
|
|
|
|
W poniższym przykładzie pozycji kroniki SK typu S zawartość pola "Secure version" wskazuje, że wynegocjowany
został protokół TLSv1.2 wraz z zestawem algorytmów szyfrowania TLS_RSA_WITH_AES_128_CBC_SHA256
wskazanym w polu "Secure properties". Został użyty algorytm podpisu ECDSA_SHA512, również wymieniony w polu
"Secure properties".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Kolumna
00901
00951
01001
Dane specyficzne dla pozycji
*...+....1....+....2....+....3....+....4....+....5
’
’
’
TLSV1.2
TLS_RSA_WITH_AES_128_CBC_SHA25’
’6 ECDSA_SHA512
’
Więcej...
W poniższym przykładzie pozycji kroniki SK typu S zawartość pól "Secure version" i "Secure properties" wskazuje, że
wynegocjowany został protokół TLSv1.2 wraz z zestawem algorytmów szyfrowania
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. Algorytm podpisu to ECDSA_SHA512, a nazwana krzywa
eliptyczna, która określa wielkość klucza, to Secp521r1.
Kolumna
00901
00951
01001
*...+....1....+....2....+....3....+....4....+....5
’
’
’
TLSV1.2
TLS_ECDHE_ECDSA_WITH_AES_256_G’
’CM_SHA384 ECDSA_SHA512 SECP521R1
’
Więcej...
| Więcej informacji na temat interpretowania wszystkich pól pozycji SK zawiera sekcja Pozycje kroniki SK (połączenia
| przez gniazda). Więcej informacji dotyczących analizowania zarejestrowanych zdarzeń zawiera sekcja Analizowanie
| pozycji kroniki kontroli w temacie nadrzędnym Bezpieczeństwo.
28
|
|
Kopiowanie pozycji kroniki kontroli (CPYAUDJRNE)
|
|
|
|
|
Śledzenie kodu LIC
|
|
Aby śledzić wszystkie wersje protokołu, w celu uruchomienia śledzenia wpisz następującą komendę:
|
|
Poczekaj na nawiązanie wszystkich połączeń chronionych i zakończ śledzenie za pomocą komendy:
|
|
Aby usunąć dane śledzenia, wprowadź następującą komendę:
|
|
W celu śledzenia połączeń korzystających z określonej wersji protokołu, użyj co najmniej jednego z następujących
punktów śledzenia.
||
Wersja protokołu
Identyfikator śledzenia
|
TLSv1.2
17004
|
TLSv1.1
17003
|
TLSv1.0
17002
|
SSLv3
17001
|
|
SSLv2
17000
|
|
|
Na przykład, aby znaleźć połączenia korzystające wyłącznie z protokołu TLSv1.0, należy użyć punktu śledzenia
17002:
|
|
|
Aby śledzić pewien zakres wersji protokołu, określ początkowy i końcowy identyfikator śledzenia. Poniższy przykład
ilustruje śledzenie protokołów od SSLv2 do TLSv1.0.
|
|
|
|
Dla użytkownika, który uruchomił komendę TRCINT SET(*OFF), tworzony jest zbiór buforowy o nazwie
QPCSMPRT. Wprowadź komendę TRCINT SET(*OFF), aby uruchomić zadanie w tle, jeśli pracujesz z dużą liczbą
danych śledzenia. Poniższe dane wyjściowe punktu śledzenia zawierają właściwości połączenia określone w tym
punkcie.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Narzędzie Śledzenie kodu LIC (Trace Licensed Internal Code) może rejestrować punkty śledzenia systemowej
implementacji protokołu SSL/TLS zawierające informacje o protokołach i zestawach algorytmów szyfrowania
systemowej implementacji protokołu SSL/TLS. Komenda Śledzenie wewnętrzne (Trace Internal – TRCINT) stanowi
interfejs do obsługi narzędzia serwisowego Śledzenie kodu LIC.
TRCINT SET(*ON) TRCTBL(’SCKSSL-1700x’) TRCTYPE(*SCKSSL) SLTTRCPNT((17000 17009))
TRCINT SET(*OFF) TRCTBL(’SCKSSL-1700x’) OUTPUT(*PRINT)
TRCINT SET(*END) TRCTBL(’SCKSSL-1700x’)
TRCINT SET(*ON) TRCTBL(’SCKSSL-17002’) TRCTYPE(*SCKSSL) SLTTRCPNT((17002))
TRCINT SET(*ON) TRCTBL(’SCKSSL-1700x’) TRCTYPE(*SCKSSL) SLTTRCPNT((17000 17002))
SOCKETS
#1
#2
#3
#4
#5
#6
#7
#8
#9
#10
#11
#12
#13
(
(
(
(
(
(
(
(
(
(
(
(
(
21)
7)
28)
10)
3)
16)
20)
11)
5)
17)
20)
16)
22)
IDENTIFIER : SC#17003
+0000 C3D6D5D5C5C3E3C9
+0000 E3D3E2E5F14BF1
+0000 E3D3E26DD9E2C16D
+0000 D3D6C3C1D340D7D6
+0000 F9F9F2
+0000 D3D6C3C1D340C9D7
+0000 7A7A868686867AF1
+0000 D9C5D4D6E3C540D7
+0000 F6F1F8F5F2
+0000 D9C5D4D6E3C540C9
+0000 7A7A868686867AF1
+0000 E3D5C1C3C3C5D7E3
+0000 D8C9C2D46DD8E3E5
D6D540D7D9D6D7C5
E6C9E3C86DC1C5E2
D9E3
40C1C4C4D9C5E2E2
F9F84BF5F14BF1F0
D6D9E3
D740C1C4C4D9C5E2
F9F84BF5F14BF1F0
E3C1E2D240404040
6DE3C5D3D5C5E36D
TIME 02/17/15 11:03:33.151908 TDE# 000000003C94
D9E3C9C5E2
*CONNECTION PROPERTIES
*TLSV1.1
6DF1F2F86DC3C2C3 6DE2C8C1 *TLS_RSA_WITH_AES_128_CBC_SHA
*LOCAL PORT
*992
*LOCAL IP ADDRESS
F04BF1F5
*::ffff:198.51.100.15
*REMOTE PORT
*61852
E2
*REMOTE IP ADDRESS
F04BF1F6
*::ffff:198.51.100.16
*TNACCEPTTASK
E2C5D9E5C5D9
*QIBM_QTV_TELNET_SERVER
W danych pozycji punktu śledzenia znajdują się następujące informacje:
29
| v Wynegocjowany protokół
| v Wynegocjowany zestaw algorytmów szyfrowania
| v Lokalny port i adres IP
| v Zdalny port i adres IP
| v Nazwa zadania/urządzenia
| v Identyfikator aplikacji (jeśli jest używany)
|
|
|
|
Liczniki wersji protokołów systemowej implementacji protokołu SSL/TLS
|
|
|
|
|
Aby określić protokoły systemowej implementacji protokołu SSL/TLS używane w systemie, można użyć opcji
sslConnectionCounts komendy SSLCONFIG. Jeśli opcja sslConnectionCounts komendy SSLCONFIG jest
włączona, zachowywane są informacje o bieżącej liczbie połączeń systemowej implementacji protokołu SSL/TLS,
pogrupowane według wynegocjowanego protokołu SSL/TLS. Z liczeniem połączeń wiąże się niewielki spadek
wydajności.
Do włączenia liczników wersji protokołów systemowej implementacji protokołu SSL/TLS można użyć komendy
zaawansowanej analizy SSLCONFIG z zestawu systemowych narzędzi serwisowych (SST). Liczniki pokazują
protokoły, które są aktywnie negocjowane przez systemową implementację protokołu SSL/TLS.
| Opcja -h komendy SSLCONFIG powoduje wyświetlenie panelu pomocy, który opisuje sposób użycia opcji
| sslConnectionCounts komendy SSLCONFIG.
| Aby przed wyłączeniem obsługi danego protokołu określić, czy jest on używany w systemie, można wykonać
| następujące czynności:
|
|
|
|
|
|
|
|
|
|
1. Zresetuj wartość sslConnectionCounts, aby wyzerować liczniki bieżącej wersji protokołu.
SSLCONFIG -sslConnectionCounts:reset
2. Śledź połączenia systemowej implementacji protokołu SSL/TLS, aby określić, które protokoły są używane w
aktywnych połączeniach.
SSLCONFIG -sslConnectionCounts:enable
3. Po upływie czasu odpowiadającego normalnej komunikacji systemowej implementacji protokołu SSL/TLS w
systemie wyświetl liczbę połączeń SSL/TLS dla poszczególnych protokołów od ostatniego resetowania.
SSLCONFIG -sslConnectionCounts:display
4. Określ, jakie aplikacje korzystają z protokołów, które mają zostać wyłączone. Zaktualizuj konfigurację aplikacji,
tak aby nie używały tych protokołów.
Uwaga: Licznik nie udostępnia informacji wskazujących, która aplikacja używa danego protokołu. Więcej
informacji o sposobach określania aplikacji korzystających z konkretnego protokołu zawiera sekcja “Sposoby
określania protokołów i zestawów algorytmów szyfrowania systemowej implementacji protokołu SSL/TLS
używanych w systemie” na stronie 28.
|
|
|
|
| 5. Zresetuj wartość sslConnectionCounts, aby wyzerować liczniki bieżącej wersji protokołu.
|
SSLCONFIG -sslConnectionCounts:reset
| 6. Po upływie kolejnego odstępu czasu odpowiadającego normalnej komunikacji systemowej implementacji
|
protokołu SSL/TLS w systemie wyświetl liczbę połączeń SSL/TLS dla poszczególnych protokołów od ostatniego
|
resetowania.
|
SSLCONFIG -sslConnectionCounts:display
|
Jeśli dla protokołu, który ma zostać wyłączony, liczba połączeń wynosi 0, to znaczy, że dana wersja protokołu nie
|
była używana w monitorowanym okresie.
| 7. Wyłącz funkcję liczenia połączeń SSL.
|
SSLCONFIG -sslConnectionCounts:disable
30
|
Rozwiązywanie problemów z protokołem SSL/TLS
Ten temat zawiera podstawowe informacje, które mogą pomóc zmniejszyć liczbę potencjalnych problemów
dotyczących systemowej implementacji protokołu SSL/TLS.
Należy pamiętać, że ta sekcja nie stanowi obszernego źródła informacji, gdyż jej zadaniem jest tylko pomoc w
rozwiązywaniu typowych problemów.
Sprawdź, czy zostały spełnione następujące warunki:
v System IBM i spełnia wszystkie wymagania wstępne dotyczące protokołu SSL/TLS.
v Ośrodek certyfikacji i certyfikaty są poprawne i nie wygasły. Więcej informacji na temat sprawdzania poprawności
certyfikatów zawiera sekcja Sprawdzanie poprawności certyfikatów i aplikacji w dokumentacji programu Digital
Certificate Manager.
v System IBM i i zdalny serwer obsługują co najmniej jeden wspólny protokół SSL/TLS i zestaw algorytmów
szyfrowania.
– Sprawdź wartości systemowe systemowej implementacji protokołu SSL/TLS: QSSLPCL, QSSLCSLCTL i
QSSLCSL.
– Sprawdź, czy definicje aplikacji w programie DCM określają protokoły SSL/TLS i zestawy algorytmów
szyfrowania włączone dla aplikacji.
– Przejrzyj ustawienia komendy zaawansowanej analizy SSLCONFIG z zestawu Systemowych narzędzi
serwisowych (System Service Tools – SST).
- Użyj opcji -display komendy SSLCONFIG, aby wyświetlić domyślne atrybuty SSL/TLS.
– Przejrzyj atrybuty SSL/TLS specyficzne dla aplikacji.
Inne opcje określania przyczyn problemów:
v Kod błędu SSL/TLS w protokole zadań serwera może posłużyć jako odniesienie do tabeli błędów, umożliwiające
odnalezienie dalszych informacji na temat błędu. Na przykład ta tabela przypisuje kod -93, który może znajdować
się w protokole zadania serwera, do stałej SSL_ERROR_SSL_NOT_AVAILABLE.
– Ujemny kod powrotu (myślnik przed numerem kodu) wskazuje, że aplikacja używa funkcji API SSL_.
– Dodatni kod powrotu wskazuje, że aplikacja używa funkcji API GSKit.
Jeśli potrzebny jest bardziej dokładny opis, to serwer IBM i może wyświetlić komunikat o identyfikatorze podanym
w tabeli, pokazując prawdopodobną przyczynę i sposób usunięcia tego błędu. Więcej informacji z opisem kodów
błędów może znajdować się w dokumentacji funkcji API gniazd chronionych, która zwróciła błąd.
v Następujące pliki nagłówkowe zawierają takie same nazwy stałych dla kodów powrotu systemowej implementacji
protokołu SSL/TLS jak tabela, ale bez odniesienia do identyfikatora komunikatu:
– QSYSINC/H.GSKSSL
– QSYSINC/H.QSOSSL
Należy pamiętać, że wprawdzie nazwy kodów powrotu systemowej implementacji protokołu SSL/TLS pozostają
stałe w obu plikach nagłówkowych, jednak z każdym z tych kodów może być powiązany więcej niż jeden unikalny
błąd.
|
|
|
Jeśli zachodzi podejrzenie, że działanie aplikacji zakończyło się niepowodzeniem podczas negocjacji SSL/TLS, ale
szczegółowe informacje o błędzie nie są rejestrowanie lub przekazywane w inny sposób, to można spróbować uzyskać
więcej informacji przy użyciu mechanizmów kontroli.
|
|
|
|
|
|
Nieudane połączenia systemowej implementacji protokołu SSL/TLS będą rejestrowane, gdy włączona zostanie
kontrola chronionych połączeń przez gniazdo. Funkcja kontroli bezpiecznych połączeń przez gniazdo będzie włączona,
jeśli w wartości systemowej QAUDLVL/QAUDLVL2 zostanie ustawiona opcja *NETSECURE. Każde połączenie
zakończone niepowodzeniem generuje pozycję kroniki SK (połączenia przez gniazdo) z typem pozycji X
(niepowodzenie połączenia systemowej implementacji protokołu SSL/TLS). Pole "Secure information" ("Informacje
dotyczące zabezpieczeń") zawiera łańcuch z opisem niepowodzenia.
31
W poniższym przykładzie pozycji kroniki dotyczącej połączenia przez gniazdo, o typie pozycji X, pole "Secure
version" ("Wersja zabezpieczeń") wskazuje, że do próby negocjowania uzgodnienia zabezpieczeń został użyty protokół
TLSv1.2. Jednak uzgadnianie nie powiodło się i został zwrócony kod błędu GSK_ERROR_NO_CIPHERS,
wyświetlony w polu "Secure properties" ("Właściwości zabezpieczeń"). Pole "Secure information" ("Informacje
dotyczące zabezpieczeń") zawiera łańcuch z opisem niepowodzenia.
Kolumna
00901
00951
01001
01051
01101
01151
*...+....1....+....2....+....3....+....4....+....5
’
’
’
TLSV1.2
GSK_ERROR_NO_CIPHERS
’
’
’
’
No compatible cipher suite ava’
’ilable between SSL end points.
’
’
’
Więcej informacji na temat wszystkich pól pozycji SK zawiera sekcja Pozycje kroniki SK (połączenia przez gniazda).
Opcje określania przyczyn problemów w aplikacji:
v Programiści mogą wykorzystywać w swoich programach funkcje API gsk_strerror() lub SSL_Strerror(), aby
otrzymać krótki opis kodu powrotu dla błędu. Niektóre aplikacje używają tej funkcji API i zapisują w protokole
zadania komunikat zawierający krótki opis błędu.
v Dodatkowe informacje dotyczące ostatniego błędu sprawdzania poprawności certyfikatu w bieżącej bezpiecznej
sesji można pobrać za pomocą atrybutu GSK_LAST_VALIDATION_ERROR i funkcji
gsk_attribute_get_numeric_value(). Jeśli jedna z funkcji gsk_secure_soc_init() lub gsk_secure_soc_startInit()
zwróciła błąd, w tym atrybucie mogą się znajdować dodatkowe informacje dotyczące tego błędu.
Pojęcia pokrewne:
“Wymagania wstępne dotyczące protokołu SSL/TLS”
Ten temat zawiera opis wymagań wstępnych dotyczących systemowej implementacji protokołu SSL/TLS na platformie
IBM i, a także kilka przydatnych wskazówek.
poziomie systemu.
Komunikaty z kodami błędów funkcji API gniazd chronionych
Wymagania wstępne dotyczące protokołu SSL/TLS
Ten temat zawiera opis wymagań wstępnych dotyczących systemowej implementacji protokołu SSL/TLS na platformie
IBM i, a także kilka przydatnych wskazówek.
Przed rozpoczęciem używania protokołu SSL/TLS należy sprawdzić, czy w systemie zainstalowane są następujące
opcje:
v IBM Digital Certificate Manager (DCM) (5770-SS1 opcja 34)
Uwaga: Program DCM nie jest wymagany przez oprogramowanie IBM Java Secure Socket Extension (JSSE) i
OpenSSL.
v IBM TCP/IP Connectivity Utilities for i (5770-TC1)
v IBM HTTP Server for i (5770-DG1)
v Jeśli podejmowane są próby uzyskania dostępu do aplikacji IBM Navigator for i lub DCM poprzez port 2001/2005,
to należy upewnić się, że zainstalowane są wymagane opcje produktu IBM Developer Kit for Java (5770-JV1). W
przeciwnym razie serwer administracyjny HTTP systemu IBM i nie zostanie uruchomiony. Wymagane opcje
produktu są zdefiniowane w liście przewodnim grupowej PTF serwera IBM HTTP Server.
32
v Aby przyspieszyć przetwarzanie uzgadniania SSL/TLS, można zainstalować sprzęt szyfrujący do obsługi protokołu
SSL/TLS. Jeśli ma zostać zainstalowany sprzęt szyfrujący, należy również zainstalować moduły IBM CCA Service
Provider (5770-SS1 opcja 35) i IBM Cryptographic Device Manager (5733-CY3).
Pojęcia pokrewne:
“Rozwiązywanie problemów z protokołem SSL/TLS” na stronie 31
Ten temat zawiera podstawowe informacje, które mogą pomóc zmniejszyć liczbę potencjalnych problemów
dotyczących systemowej implementacji protokołu SSL/TLS.
Sprzęt szyfrujący
Certyfikaty publiczne a certyfikaty prywatne
Konfigurowanie programu DCM
Zabezpieczanie aplikacji za pomocą protokołu SSL/TLS
Za pomocą protokołu SSL/TLS można zabezpieczyć szereg aplikacji systemu IBM i. Szczegółowe informacje na ten
temat zawiera dokumentacja poszczególnych aplikacji.
Odwzorowywanie tożsamości w przedsiębiorstwie (EIM)
Zabezpieczanie protokołu FTP
Konfigurowanie protokołu SSL/TLS dla serwera administracyjnego (ADMIN) serwera HTTP
Dodawanie zabezpieczeń SSL/TLS na serwerze HTTP
Scenariusz Telnet: zabezpieczanie aplikacji Telnet za pomocą protokołu SSL/TLS
Protokoły SSL (Secure Sockets Layer) i TLS (Transport Layer Security) na serwerze Directory Server
Interfejsy API do bezpiecznych połączeń przez gniazda
Scenariusz: wykorzystanie sprzętu szyfrującego do zabezpieczania prywatnych kluczy
Informacje pokrewne dotyczące protokołu SSL/TLS
Poniżej znajdują się odsyłacze do innych zasobów i informacji dotyczących protokołu Secure Sockets Layer (SSL) /
Serwisy WWW
v RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2"
(http://www.ietf.org/rfc/rfc5246.txt)
Zawiera szczegółowe informacje na temat protokołu TLS w wersji 1.2.
v RFC 4346: "The Transport Layer Security (TLS) Protocol Version 1.1"
v RFC 2246: "The TLS Protocol Version 1.0 "
v RFC2818: "HTTP Over TLS"
Opisuje, jak korzystać z protokołu TLS do zabezpieczania połączeń HTTP w Internecie.
v RFC 5746: "Transport Layer Security (TLS) Renegotiation Indication Extension"
rfc5746.txt)
(http://www.ietf.org/rfc/
Definiuje rozszerzenie protokołu TLS o wskazanie renegocjacji.
v RFC 6066: "Transport Layer Security (TLS) Extensions: Extension Definitions"
rfc6066.txt)
(http://www.ietf.org/rfc/
Definiuje rozszerzenia protokołu TLS.
33
v RFC 2560: "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP"
Definiuje protokół OCSP, używany do ustalania statusu wycofania certyfikatów cyfrowych.
v RFC 4492: "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)"
Definiuje nowe algorytmy wymiany kluczy w protokole TLS.
Inne informacje
v SSL i Java Secure Socket Extension
v IBM Toolbox for Java
34
Uwagi
Niniejsza publikacja została przygotowana z myślą o produktach i usługach oferowanych w Stanach Zjednoczonych.
IBM może nie oferować w innych krajach produktów, usług lub opcji omawianych w tej publikacji. Informacje o
produktach i usługach dostępnych w danym kraju można uzyskać od lokalnego przedstawiciela IBM. Odwołanie do
produktu, programu lub usługi IBM nie oznacza, że można użyć wyłącznie tego produktu, programu lub usługi.
Zamiast nich można zastosować ich odpowiednik funkcjonalny pod warunkiem, że nie narusza to praw własności
intelektualnej IBM. Jednakże cała odpowiedzialność za ocenę przydatności i sprawdzenie działania produktu,
programu lub usługi pochodzących od producenta innego niż IBM spoczywa na użytkowniku.
IBM może posiadać patenty lub złożone wnioski patentowe na towary i usługi, o których mowa w niniejszej publikacji.
Przedstawienie niniejszej publikacji nie daje żadnych uprawnień licencyjnych do tychże patentów. Pisemne zapytania
w sprawie licencji można przesyłać na adres:
IBM Director of
Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
USA
Zapytania w sprawie licencji na informacje dotyczące zestawów znaków dwubajtowych (DBCS) należy kierować do
lokalnych działów własności intelektualnej IBM (IBM Intellectual Property Department) lub zgłaszać na piśmie pod
adresem:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan, Ltd.
1623-14, Shimotsuruma, Yamato-shi
Kanagawa 242-8502 Japonia
Poniższy akapit nie obowiązuje w Wielkiej Brytanii, a także w innych krajach, w których jego treść pozostaje w
sprzeczności z przepisami prawa miejscowego: INTERNATIONAL BUSINESS MACHINES CORPORATION
DOSTARCZA TĘ PUBLIKACJĘ W STANIE, W JAKIM SIĘ ZNAJDUJE ("AS IS") BEZ UDZIELANIA
JAKICHKOLWIEK GWARANCJI (W TYM TAKŻE RĘKOJMI), WYRAŹNYCH LUB DOMNIEMANYCH, A W
SZCZEGÓLNOŚCI DOMNIEMANYCH GWARANCJI PRZYDATNOŚCI HANDLOWEJ, PRZYDATNOŚCI DO
OKREŚLONEGO CELU ORAZ GWARANCJI, ŻE PUBLIKACJA NIE NARUSZA PRAW STRON TRZECICH.
Ustawodawstwa niektórych krajów nie dopuszczają zastrzeżeń dotyczących gwarancji wyraźnych lub domniemanych
w odniesieniu do pewnych transakcji; w takiej sytuacji powyższe zdanie nie ma zastosowania.
Informacje zawarte w niniejszej publikacji mogą zawierać nieścisłości techniczne lub błędy drukarskie. Informacje te
są okresowo aktualizowane, a zmiany te zostaną uwzględnione w kolejnych wydaniach tej publikacji. IBM zastrzega
sobie prawo do wprowadzania ulepszeń i/lub zmian w produktach i/lub programach opisanych w tej publikacji w
dowolnym czasie, bez wcześniejszego powiadomienia.
Wszelkie wzmianki w tej publikacji na temat stron internetowych innych firm zostały wprowadzone wyłącznie dla
wygody użytkowników i w żadnym wypadku nie stanowią zachęty do ich odwiedzania. Materiały dostępne na tych
stronach nie są częścią materiałów opracowanych dla tego produktu IBM, a użytkownik korzysta z nich na własną
odpowiedzialność.
IBM ma prawo do używania i rozpowszechniania informacji przysłanych przez użytkownika w dowolny sposób, jaki
uzna za właściwy, bez żadnych zobowiązań wobec ich autora.
35
Licencjobiorcy tego programu, którzy chcieliby uzyskać informacje na temat programu w celu: (i) wdrożenia wymiany
informacji między niezależnie utworzonymi programami i innymi programami (łącznie z tym opisywanym) oraz (ii)
wspólnego wykorzystywania wymienianych informacji, powinni skontaktować się z:
IBM Corporation
Software Interoperability Coordinator, Department YBWA
3605 Highway 52 N
Rochester, MN 55901
USA
Informacje takie mogą być udostępnione, o ile spełnione zostaną odpowiednie warunki, w tym, w niektórych
przypadkach, uiszczenie odpowiedniej opłaty.
Licencjonowany program opisany w niniejszym dokumencie oraz wszystkie inne licencjonowane materiały dostępne
dla tego programu są dostarczane przez IBM na warunkach określonych w Umowie IBM z Klientem,
Międzynarodowej Umowie Licencyjnej IBM na Program lub w innych podobnych umowach zawartych między IBM a
użytkownikami.
Wszelkie dane dotyczące wydajności zostały zebrane w kontrolowanym środowisku. W związku z tym rezultaty
uzyskane w innych środowiskach operacyjnych mogą się znacząco różnić. Niektóre pomiary mogły być dokonywane
na systemach będących w fazie rozwoju i nie ma gwarancji, że pomiary te wykonane na ogólnie dostępnych systemach
dadzą takie same wyniki. Niektóre z pomiarów mogły być estymowane przez ekstrapolację. Rzeczywiste wyniki mogą
być inne. Użytkownicy powinni we własnym zakresie sprawdzić odpowiednie dane dla ich środowiska.
Informacje dotyczące produktów firm innych niż IBM pochodzą od dostawców tych produktów, z opublikowanych
przez nich zapowiedzi lub innych powszechnie dostępnych źródeł. Firma IBM nie testowała tych produktów i nie może
potwierdzić dokładności pomiarów wydajności, kompatybilności ani żadnych innych danych związanych z tymi
produktami. Pytania dotyczące możliwości produktów firm innych niż IBM należy kierować do dostawców tych
produktów.
Wszelkie stwierdzenia dotyczące przyszłych kierunków rozwoju i zamierzeń IBM mogą zostać zmienione lub
wycofane bez powiadomienia.
Niniejsza informacja służy jedynie do celów planowania. Informacja ta podlega zmianom do chwili, gdy produkty,
których ona dotyczy, staną się dostępne.
Publikacja ta zawiera przykładowe dane i raporty używane w codziennych operacjach działalności gospodarczej. W
celu kompleksowego ich zilustrowania, podane przykłady zawierają nazwiska osób prywatnych, nazwy
przedsiębiorstw oraz nazwy produktów. Wszystkie te nazwy/nazwiska są fikcyjne i jakiekolwiek podobieństwo do
istniejących nazw/nazwisk i adresów jest całkowicie przypadkowe.
LICENCJA W ZAKRESIE PRAW AUTORSKICH:
Niniejsza publikacja zawiera przykładowe aplikacje w kodzie źródłowym, ilustrujące techniki programowania w
różnych systemach operacyjnych. Użytkownik może kopiować, modyfikować i dystrybuować te programy
przykładowe w dowolnej formie bez uiszczania opłat na rzecz IBM, w celu projektowania, używania, sprzedaży lub
dystrybucji aplikacji zgodnych z aplikacyjnym interfejsem programowym dla tego systemu operacyjnego, dla którego
napisane zostały programy przykładowe. Programy przykładowe nie zostały gruntownie przetestowane. IBM nie może
zatem gwarantować ani sugerować niezawodności, użyteczności i funkcjonalności tych programów. Programy
przykładowe są dostarczane w stanie, w jakim się znajdują ("AS IS"), bez udzielania jakichkolwiek gwarancji, w tym
także rękojmi. IBM nie ponosi odpowiedzialności za jakiekolwiek szkody wynikające z używania programów
przykładowych.
Każda kopia programu przykładowego lub jakikolwiek jego fragment, jak też jakiekolwiek prace pochodne muszą
zawierać następujące uwagi dotyczące praw autorskich:
36
© (nazwa przedsiębiorstwa użytkownika, rok). Fragmenty tego kodu pochodzą z programów przykładowych IBM
Corp.
© Copyright IBM Corp. (wpisać rok lub lata).
Znaki towarowe
IBM, logo IBM oraz ibm.com są znakami towarowymi lub zastrzeżonymi znakami towarowymi International Business
Machines Corp., zarejestrowanymi w wielu systemach prawnych na całym świecie. Nazwy innych produktów lub usług
mogą być znakami towarowymi IBM lub innych podmiotów. Aktualna lista znaków towarowych IBM dostępna jest w
serwisie WWW, w sekcji “Copyright and trademark information” (Informacje o prawach autorskich i znakach
towarowych), pod adresem www.ibm.com/legal/copytrade.shtml.
Adobe, logo Adobe, PostScript i logo PostScript są znakami towarowymi lub zastrzeżonymi znakami towarowymi
firmy Adobe Systems Incorporated w Stanach Zjednoczonych i/lub w innych krajach.
Java oraz wszystkie znaki towarowe i logo dotyczące języka Java są znakami towarowymi Oracle, Inc. w Stanach
Zjednoczonych i/lub w innych krajach.
Nazwy innych produktów lub usług mogą być znakami towarowymi IBM lub innych podmiotów.
Warunki
Zezwolenie na korzystanie z tych publikacji jest przyznawane na poniższych warunkach.
Użytek osobisty: Użytkownik ma prawo kopiować te publikacje do własnego, niekomercyjnego użytku pod
warunkiem zachowania wszelkich uwag dotyczących praw własności. Użytkownik nie ma prawa dystrybuować ani
wyświetlać tych publikacji czy ich części, ani też wykonywać na ich podstawie prac pochodnych bez wyraźnej zgody
IBM.
Użytek służbowy: Użytkownik ma prawo kopiować te publikacje, dystrybuować je i wyświetlać wyłącznie w ramach
przedsiębiorstwa Użytkownika pod warunkiem zachowania wszelkich uwag dotyczących praw własności. Użytkownik
nie ma prawa wykonywać na podstawie tych publikacji ani ich fragmentów prac pochodnych, kopiować ich,
dystrybuować ani wyświetlać poza przedsiębiorstwem Użytkownika bez wyraźnej zgody IBM.
Z wyjątkiem zezwoleń wyraźnie udzielonych w niniejszym dokumencie, nie udziela się jakichkolwiek innych
zezwoleń, licencji ani praw, wyraźnych czy domniemanych, odnoszących się do tych publikacji czy jakichkolwiek
informacji, danych, oprogramowania lub innej własności intelektualnej, o których mowa w niniejszym dokumencie.
IBM zastrzega sobie prawo do anulowania zezwolenia przyznanego w niniejszym dokumencie w każdej sytuacji, gdy,
według uznania IBM, korzystanie z tych publikacji jest szkodliwe dla IBM lub jeśli IBM uzna, że warunki niniejszego
dokumentu nie są przestrzegane.
Użytkownik ma prawo pobierać, eksportować lub reeksportować niniejsze informacje pod warunkiem zachowania
bezwzględnej i pełnej zgodności z obowiązującym prawem i przepisami, w tym ze wszelkimi prawami i przepisami
eksportowymi Stanów Zjednoczonych.
IBM NIE UDZIELA JAKICHKOLWIEK GWARANCJI, W TYM TAKŻE RĘKOJMI, DOTYCZĄCYCH TREŚCI
TYCH PUBLIKACJI. PUBLIKACJE TE SĄ DOSTARCZANE W STANIE, W JAKIM SIĘ ZNAJDUJĄ ("AS IS")
BEZ UDZIELANIA JAKICHKOLWIEK GWARANCJI, W TYM TAKŻE RĘKOJMI, WYRAŹNYCH CZY
DOMNIEMANYCH, A W SZCZEGÓLNOŚCI DOMNIEMANYCH GWARANCJI PRZYDATNOŚCI
HANDLOWEJ, PRZYDATNOŚCI DO OKREŚLONEGO CELU ORAZ NIENARUSZANIA PRAW STRON
TRZECICH.
Uwagi
37
38
IBM®
Numer Programu: 5770-SS1

IBM i: Protok|fo|fl Secure Sockets Layer (SSL) / Transport Layer

Transkrypt

Podobne dokumenty

Serwer poczty przychodzącej i wychodzącej: poczta.uw.edu.pl POP3

Poradnik jak włączyć szyfrowanie SSL w programie Mozilla

Dokumentacja w formacie PDF (wersja polska)

zobacz spis treści

head premium ssl hybrid

Ustawienia konta pocztowego (na przykładzie MS Office): POP3

nitro fader tls