Protokół SSL (Secure Sockets Layer)

Transkrypt

IBM i
Wersja 7.2
Bezpieczeństwo
Protokół Secure Sockets Layer
IBM i
Wersja 7.2
Bezpieczeństwo
Uwaga
Przed skorzystaniem z tych informacji oraz z produktu, którego dotyczą, należy przeczytać informacje zawarte w sekcji “Uwagi” na stronie
37.
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, 2014.
Spis treści
Protokół Secure Sockets Layer . . . . . 1
|
Co nowego w systemie IBM i 7.2 . . . . . . . . 1
Plik PDF z informacjami na temat protokołu SSL . . . . 1
Pojęcia związane z protokołem SSL . . . . . . . . 2
Jak działa SSL . . . . . . . . . . . . . 2
Obsługiwane wersje protokołów SSL i TLS . . . . 2
System SSL . . . . . . . . . . . . . . 4
Właściwości Systemu SSL . . . . . . . . 5
Protokoły SSL . . . . . . . . . . . 5
Zestawy algorytmów szyfrowania SSL . . . . 6
Algorytmy podpisu . . . . . . . . . . 9
Renegocjacja . . . . . . . . . . . 11
Definicje aplikacji w programie DCM . . . . . 12
Protokoły SSL . . . . . . . . . . . 13
Opcje specyfikacji algorytmów szyfrowania
warstwy SSL . . . . . . . . . . . 13
Tryb krytyczny rozszerzonej renegocjacji . . . 13
Wskazanie nazwy serwera . . . . . . . 14
Atrybuty protokołu OCSP (Online Certificate
Status Protocol) . . . . . . . . . . 15
Algorytm podpisu SSL . . . . . . . . 16
Protokół OCSP (Online Certificate Status Protocol) 16
Konfiguracja OCSP . . . . . . . . . 17
Status wycofania OCSP . . . . . . . . 19
Wycofywanie certyfikatów . . . . . . . . 19
Wybór wielu certyfikatów . . . . . . . . 20
Makro SSLCONFIG . . . . . . . . . . 21
Uwierzytelnianie serwera. . . . . . . . . . 22
Uwierzytelnianie klienta . . . . . . . . . . 22
Wymagania wstępne dotyczące protokołu SSL . . . . 22
Zabezpieczanie aplikacji za pomocą protokołu SSL . . . 23
Scenariusze: protokół SSL . . . . . . . . . . 23
Scenariusz: zabezpieczanie połączenia klienta z
serwerem Centrum Zarządzania za pomocą protokołu
SSL . . . . . . . . . . . . . . . . 23
Szczegóły konfiguracji: zabezpieczanie połączenia
klienta z systemem Centrum Zarządzania za pomocą
protokołu SSL . . . . . . . . . . . . 25
Czynność 1: dezaktywowanie protokołu SSL dla
klienta System i Navigator . . . . . . . 26
Czynność 2: ustawianie poziomu
uwierzytelniania dla serwera Centrum
Zarządzania. . . . . . . . . . . . 26
© Copyright IBM Corp. 2002, 2014
Czynność 3: restartowanie systemu Centrum
Zarządzania w systemie centralnym . . . .
Czynność 4: aktywowanie protokołu SSL dla
klienta System i Navigator . . . . . . .
Punkt opcjonalny: dezaktywowanie protokołu
SSL dla klienta System i Navigator . . . . .
Scenariusz: zabezpieczanie wszystkich połączeń z
serwerem Centrum Zarządzania za pomocą protokołu
SSL . . . . . . . . . . . . . . . .
Szczegóły konfiguracji: zabezpieczanie wszystkich
połączeń z systemem Centrum Zarządzania za
pomocą protokołu SSL . . . . . . . . .
Czynność 1: konfigurowanie systemu
centralnego pod kątem uwierzytelniania serwera .
Czynność 2: konfigurowanie systemów
końcowych pod kątem uwierzytelniania serwera .
Zarządzania we wszystkich systemach
końcowych . . . . . . . . . . . .
Czynność 5: aktywowanie protokołu SSL dla
klienta System i Navigator . . . . . . .
Czynność 6: konfigurowanie systemu
centralnego pod kątem uwierzytelniania klientów
Czynność 7: konfigurowanie systemów
końcowych pod kątem uwierzytelniania klientów
Czynność 8: kopiowanie listy sprawdzania do
systemów końcowych. . . . . . . . .
Zarządzania we wszystkich systemach
końcowych . . . . . . . . . . . .
Rozwiązywanie problemów z protokołem SSL . . . .
Informacje pokrewne dotyczące protokołu SSL . . . .
26
26
27
27
31
32
32
32
33
33
33
33
34
34
35
35
36
Uwagi . . . . . . . . . . . . . . . 37
Znaki towarowe
Warunki . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 39
. 39
iii
iv
IBM i: Protokół Secure Sockets Layer
W tej publikacji opisano wykorzystanie na serwerach protokołu Secure Sockets Layer (SSL).
Protokół SSL jest standardem przemysłowym umożliwiającym aplikacjom nawiązywanie bezpiecznych sesji
komunikacyjnych poprzez niezabezpieczoną sieć, taką jak Internet.
Co nowego w systemie IBM i 7.2
Poniżej omówiono nowe lub znacznie zmienione informacje dotyczące warstwy Secure Sockets Layer.
v Dodano obsługę protokołów TLS (Transport Layer Security): TLS w wersji 1.2 i TLS w wersji 1.1
v Dodano do sekcji “Właściwości Systemu SSL” na stronie 5 nowe protokoły SSL i zestawy algorytmów szyfrowania
oraz wprowadzono nowe właściwości algorytmów podpisu i renegocjacji uzgadniania.
v Dodano możliwość konfigurowania wielu certyfikatów dla bezpiecznego środowiska. Wybór wielu certyfikatów
umożliwia włączenie w bezpiecznym środowisku algorytmu ECDSA (Elliptic Curve Digital Signature Algorithm)
przy jednoczesnej obsłudze certyfikatów RSA.
v Dodano do sekcji “Definicje aplikacji w programie DCM” na stronie 12 obsługę niektórych atrybutów systemowej
implementacji protokołu SSL.
v Dodano obsługę “Protokół OCSP (Online Certificate Status Protocol)” na stronie 16 od strony klienta.
Znajdowanie nowych lub zmienionych informacji
Aby ułatwić określenie obszarów, w których zostały wprowadzone zmiany techniczne, w Centrum informacyjnym
zastosowano:
służący do zaznaczania początku nowego lub zmienionego fragmentu;
v symbol
służący do zaznaczania końca nowego lub zmienionego fragmentu.
v symbol
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
Informacje zawarte w tym temacie są także dostępne w postaci pliku PDF, który można wyświetlić i wydrukować.
Aby wyświetlić lub pobrać wersję PDF tego dokumentu, wybierz temat Protokół SSL (Secure Sockets Layer).
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 (www.adobe.com/products/acrobat/readstep.html)
.
1
Pojęcia związane z protokołem SSL
Temat zawiera informacje uzupełniające dotyczące protokołów Secure Sockets Layer (SSL).
Dzięki protokołowi SSL można nawiązywać bezpieczne połączenia pomiędzy aplikacjami serwera i klienta,
uwierzytelniając jeden lub dwa punkty końcowe sesji komunikacyjnej. SSL zapewnia także prywatność i integralność
danych wymienianych pomiędzy aplikacjami serwera i klienta.
Jak działa SSL
SSL składa się obecnie z dwóch protokołów: rekordów i uzgadniania. Protokół rekordów steruje przepływem danych
pomiędzy dwoma punktami końcowymi sesji SSL.
Protokół uzgadniania uwierzytelnia jeden lub oba punkty końcowe sesji SSL i ustanawia unikalny symetryczny klucz
używany do generowania kluczy służących do szyfrowania i deszyfrowania danych w sesji SSL. Protokół SSL używa
asymetrycznego szyfrowania, certyfikatów cyfrowych i przepływu uzgadniania SSL do uwierzytelniania jednego lub
obu systemów końcowych sesji SSL. Zwykle protokół SSL wymaga uwierzytelnienia serwera. Opcjonalnie protokół
SSL wymaga uwierzytelnienia klienta. Certyfikat cyfrowy wydawany przez ośrodek certyfikacji może zostać
przypisany każdemu z punktów końcowych lub każdej z aplikacji korzystającej z SSL we wszystkich punktach
końcowych połączenia.
Certyfikat cyfrowy składa się z klucza publicznego i informacji identyfikacyjnych podpisanych cyfrowo przez zaufany
ośrodek certyfikacji. Każdemu kluczowi publicznemu przypisany jest klucz prywatny, którego nie przechowuje się ani
jako jednej z części certyfikatu, ani z samym certyfikatem. Zarówno podczas uwierzytelniania serwera, jak i klienta,
uwierzytelniany punkt końcowy musi udowadniać, że ma dostęp do klucza prywatnego przypisanego kluczowi
publicznemu, zawartemu w certyfikacie cyfrowym.
Uzgadnianie SSL, ze względu na operacje szyfrujące z użyciem kluczy publicznych i prywatnych, jest działaniem
wymagającym dużej wydajności. Po nawiązaniu pomiędzy dwoma punktami końcowymi początkowej sesji SSL,
informacje o sesji SSL przeznaczone dla nich i dla aplikacji mogą być przechowywane w pamięci chronionej, dzięki
czemu kolejne aktywacje sesji SSL będą szybsze. Punkty końcowe korzystają ze skróconego przepływu uzgodnień do
uwierzytelnienia, że każdy z nich ma dostęp do unikalnych danych bez korzystania z kluczy publicznych lub
prywatnych, gdy sesja SSL jest wznawiana. Jeśli oba mogą udowodnić, że mają dostęp do tych unikalnych informacji,
ustanawiane są nowe klucze symetryczne i wznawiana jest sesja SSL. W sesjach protokołów TLS w wersji 1.2, 1.1, 1.0
oraz SSL w wersji 3.0 buforowane informacje są przechowywane w pamięci chronionej nie dłużej niż 24 godziny.
Można zminimalizować wpływ wydajności uzgadniania SSL na procesor główny poprzez używanie sprzętu
szyfrującego.
Informacje pokrewne:
Koncepcje dotyczące certyfikatów cyfrowych
Sprzęt szyfrujący
Obsługiwane wersje protokołów SSL i TLS
Ten temat zawiera informacje o wersjach protokołów Secure Sockets Layer (SSL) i Transport Layer Security (TLS)
obsługiwanych przez ich implementację w systemie IBM® i.
Istnieje kilka zdefiniowanych wersji protokołu SSL. Implementacja w systemie IBM i obsługuje następujące wersje
protokołów SSL i TLS:
v protokół TLS w wersji 1.2
v protokół SSL w wersji 3.0
v protokół SSL w wersji 2.0
Uwaga:
2
1. Określenie więcej niż jednego protokołu naraz oznacza tryb zgodności. Zgodność oznacza, że jest negocjowany
najnowszy z określonych protokołów, jeśli to możliwe, a jeśli nie jest to możliwe, do negocjacji jest używany
protokół kolejny co do numeru wersji. Jeśli nie jest możliwa negocjacja żadnego z określonych protokołów,
uzgadnianie warstwy SSL kończy się niepowodzeniem.
2. W trybie zgodności zaleca się określenie wszystkich protokołów z przedziału od najnowszego do najstarszego
włączonego protokołu. Sytuacje, gdy określone są wersje protokołu TLS 1.2 i 1.0, a wersja protokołu TLS 1.1 nie
jest określona, mogą prowadzić do nieprzewidywalnych rezultatów.
Protokół TLS w wersji 1.2 a protokół TLS w wersji 1.1
Najnowszym standardem przemysłowym protokołu SSL jest protokół TLS (Transport Layer Security) w wersji 1.2.
Jego specyfikacje są zdefiniowane w dokumencie RFC 5246 grupy wykonawczej IETF - The TLS Protocol Version
1.2.
Protokół TLS w wersji 1.2 oferuje następujące udoskonalenia protokołu TLS w wersji 1.1:
v Wszystkie algorytmy szyfrowania negocjowane przy użyciu protokołu TLS 1.2 muszą korzystać co najmniej z
funkcji SHA256. Istniejące algorytmy szyfrowania, których nazwy zawierają ciąg SHA(1), korzystają z funkcji
SHA256.
v Kombinacja wartości MD5/SHA-1 w elemencie podpisanym cyfrowo została zastąpiona pojedynczą wartością
funkcji mieszającej. Podpisane elementy zawierają teraz pole, w którym jest jawnie określony użyty algorytm
mieszający.
v Obsługa rozszerzeń, wcześniej zdefiniowana osobno, została scalona z dokumentem RFC.
v Algorytm szyfrowania DES jest niedozwolony. To oznacza, że nie można negocjować tego zestawu algorytmów
szyfrowania w połączeniach protokołu TLSv1.2.
– 09 = *RSA_DES_CBC_SHA
Protokół TLS w wersji 1.1 a protokół TLS w wersji 1.0
Poprzednim standardem przemysłowym protokołu SSL jest protokół TLS (Transport Layer Security) w wersji 1.1. Jego
specyfikacje są zdefiniowane w dokumencie RFC 4346 grupy wykonawczej IETF - The TLS Protocol Version 1.1.
Protokół TLS w wersji 1.1 oferuje następujące udoskonalenia protokołu TLS w wersji 1.0:
v Niejawny wektor inicjujący (Initialization Vector - IV) został zastąpiony jawnym wektorem inicjującym w celu
ochrony przed atakami typu Cipher Block Chaining (CBC). Jawność wektora inicjującego zmienia sposób działania
algorytmów szyfrowania AES i DES.
v Algorytmy szyfrujące eksport są niedozwolone. To oznacza, że nie można negocjować tych dwóch wcześniej
obsługiwanych zestawów algorytmów szyfrowania w połączeniach protokołu TLSv1.1.
– 03 = *RSA_EXPORT_RC4_40_MD5
– 06 = *RSA_EXPORT_RC2_CBC_40_MD5
v Różne udoskonalenia wewnętrzne; szczegółowe informacje zawiera dokument RFC 4346.
Protokół TLS wersja 1.0 a protokół SSL wersja 3.0
Pierwszym standardem przemysłowym protokołu SSL opartym na SSL w wersji 3.0 był protokół TLS (Transport Layer
Security) w wersji 1.0. Jego specyfikacje są zdefiniowane w dokumencie RFC 2246 grupy wykonawczej IETF - The
TLS Protocol.
Głównym celem protokołu TLS jest uczynienie protokołu SSL bezpieczniejszym, a jego specyfikacji pełniejszą i
bardziej precyzyjną. TLS, w porównaniu do wersji 3.0 SSL, zapewnia następujące udoskonalenia:
v bezpieczniejszy algorytm MAC,
v dokładniejsze alerty,
v prostsze definicje specyfikacji "szarej strefy".
3
TLS zapewnia następujące sposoby zwiększenia bezpieczeństwa:
v Key-Hashing for Message Authentication Protokół TLS korzysta z metody HMAC gwarantującej, że rekord nie
zostanie zmodyfikowany w trakcie przejścia przez otwartą sieć, taką jak Internet. SSL wersja 3.0 zapewnia
uwierzytelnianie wiadomości zabezpieczonych kluczem, ale funkcja HMAC jest bardziej bezpieczna niż funkcja
MAC (Message Authentication Code) używana przez protokół SSL w wersji 3.0.
v Rozszerzony pseudolosowy generator funkcji (PRF) PRF generuje dane klucza. W TLS funkcja HMAC definiuje
generator PRF. Generator PRF korzysta z dwóch algorytmów mieszających, które gwarantują jego bezpieczeństwo.
Jeśli złamany zostanie jeden z algorytmów, dane będą bezpieczne tak długo, jak długo sposób złamania drugiego
algorytmu pozostanie nieznany.
v Udoskonalona weryfikacja końcowa komunikatów Zarówno wersja 1.0 protokołu TLS, jak i wersja 3.0 protokołu
SSL wysyłają do obu punktów końcowych komunikat uwierzytelniający brak zmian w wymienianych
komunikatach. Protokół TLS wykorzystuje do utworzenia komunikatu końcowego wartości PRF i HMAC, co
również jest bezpieczniejsze niż w wersji 3.0 protokołu SSL.
v Spójna obsługa certyfikatów W przeciwieństwie do protokołu SSL wersja 3.0, protokół TLS próbuje określić typ
certyfikatu, który musi być wymieniany między implementacjami protokołu TLS.
v Dokładniejsze komunikaty alertów TLS udostępnia dodatkowe i dokładniejsze alerty, wskazując problemy
wykryte przez punkt końcowy sesji. Dokumentuje także, kiedy określone alerty powinny zostać wysłane.
Protokół SSL wersja 3.0 a protokół SSL wersja 2.0
W porównaniu z wersją 2.0 protokół SSL wersja 3.0 jest niemal całkiem innym protokołem. Niektóre z ważniejszych
różnic pomiędzy tymi dwoma protokołami to:
v Różnice w przepływie protokołu uzgadniania.
v Protokół SSL w wersji 3.0 zawiera poprawki analizy czasowej i algorytm kodowania mieszającego SHA-1.
Algorytm kodowania mieszającego SHA-1 uważa się za bardziej bezpieczny niż algorytm kodowania mieszającego
MD5. SHA-1 umożliwia SSL w wersji 3.0 obsługę dodatkowych zestawów algorytmów szyfrowania używających
SHA-1 zamiast MD5.
v Wersja 3.0 protokołu SSL redukuje możliwość wystąpienia ataku typu przechwycenie połączenia
(man-in-the-middle) podczas przetwarzania uzgadniania SSL. W wersji 2.0 było możliwe, chociaż mało
prawdopodobne, że taki typ ataku mógł spowodować osłabienie specyfikacji szyfru. Osłabienie szyfru może
umożliwić osobie nie posiadającej uprawnień złamanie klucza sesji SSL.
RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2"
RFC 4346: "The Transport Layer Security (TLS) Protocol Version 1.1"
RFC 2246: "The TLS Protocol Version 1.0"
System SSL
System SSL to zestaw ogólnych usług udostępnionych w Licencjonowanym Kodzie Wewnętrznym systemu IBM i,
które zabezpieczają połączenia TCP/IP przy użyciu protokołów SSL i TLS. System SSL jest ściśle powiązany z
systemem operacyjnym oraz kodem gniazd, aby zwiększyć wydajność i poziom bezpieczeństwa.
System SSL jest dostępny 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.
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.
– Używanie tego zestawu funkcji API nie jest zalecane. Zalecany interfejs w języku C to GSKit.
v Zintegrowana z systemem IBM i implementacja JSSE
|
– Implementacja JSSE w systemie IBM i jest dostępna dla wersji JDK 1.6, JDK 7 i JDK 8.
4
Aplikacje korzystające z protokołu SSL utworzone przez firmę IBM, partnerów handlowych IBM, niezależnych
producentów oprogramowania lub klientów, które korzystają z jednego z powyższych interfejsów Systemu SSL, będą
wykorzystywać System SSL. Na przykład FTP i Telnet są aplikacjami firmy IBM, które wykorzystują System SSL.
Nie wszystkie aplikacje na platformie IBM i, które mogą korzystać z protokołu SSL, wykorzystują System SSL.
Właściwości Systemu SSL
Właściwości niektórych atrybutów systemowej implementacji protokołu SSL można modyfikować na poziomie
systemu. Ten podzbiór atrybutów jest określany jako właściwości systemowej implementacji protokołu SSL.
Systemowa implementacja protokołu SSL obejmuje wiele atrybutów, które określają sposób tworzenia bezpiecznych
środowisk lub bezpiecznych sesji. Podczas tworzenia aplikacji jej projektant decyduje o wartościach poszczególnych
atrybutów. W niektórych przypadkach decyzja przewiduje jawne ustawienie konkretnej wartości atrybutu. Dla
niektórych atrybutów jest udostępniany interfejs użytkownika, który umożliwia administratorowi aplikacji sterowanie
wartością atrybutu. W przypadku większości atrybutów projektant używa domyślnych wartości atrybutu z systemowej
implementacji protokołu SSL i nie modyfikuje ich w kodzie. Domyślna wartość atrybutu jest również używana za
każdym razem, gdy po skompilowaniu aplikacji są dodawane nowe atrybuty systemowej implementacji protokołu SSL.
Jak wszystkie atrybuty, właściwości systemowej implementacji protokołu SSL podlegają ograniczeniom
obsługiwanych wartości i wartości domyślnych. Obsługiwane wartości ograniczają możliwości zastosownia atrybutów
w systemowej implementacji protokołu SSL. Wartości domyślne określają, co się dzieje w sytuacji, gdy projektant nie
ustawił jawnie wartości atrybutu.
Można zmieniać wartości domyślne, obsługiwane lub oba te rodzaje wartości następujących właściwości systemowej
implementacji protokołu SSL. Należy korzystać z wartości systemowych lub komendy zaawansowanej analizy
SSLCONFIG z zestawu Systemowych narzędzi serwisowych (System Service Tools - SST) zgodnie z podanymi
informacjami.
Pojęcia pokrewne:
“Makro SSLCONFIG” na stronie 21
Makro SSLCONFIG umożliwia wyświetlanie lub zmienianie domyślnych właściwości systemowej implementacji
protokołu SSL na poziomie systemu.
Wartość systemowa SSL: QSSLPCL
Wartość systemowa SSL: QSSLCSLCTL
Wartość systemowa SSL: QSSLCSL
Protokoły SSL:
Systemowa implementacja protokołu SSL (System SSL) obejmuje infrastrukturę obsługującą wiele protokołów.
System SSL obsługuje następujące protokoły:
v Transport Layer Security w wersji 1.2 (TLSv1.2)
v Protokół Secure Sockets Layer w wersji 3.0 (SSLv3)
v Protokół Secure Sockets Layer w wersji 2.0 (SSLv2)
– Nie można używać protokołu SSLv2, jeśli jest obsługiwany protokół TLSv1.2.
Protokoły SSL obsługiwane w konfiguracji fabrycznej
|
W konfiguracji fabrycznej System SSL obsługuje następujące protokoły:
5
| v Transport Layer Security w wersji 1.2 (TLSv1.2)
| Uwaga: Protokoły SSLv3 i SSLv2 są fabrycznie dezaktywowane w systemowej implementacji protokołu SSL. Za
| pomocą wartości systemowej QSSLPCL można wyłączać i włączać wszystkie spośród opisanych protokołów.
Domyślne protokoły SSL w konfiguracji fabrycznej
Na żądanie aplikacji System SSL używa domyślnie następujących protokołów:
v Protokół Transport Layer Security w wersji 1.0 (TLSv1)
|
|
|
|
Uwaga: Jeśli administrator dodał protokół SSLv3 do listy obsługiwanych protokołów, jest on dodawany listy
protokołów domyślnych. Jeśli jednak administrator dodał protokół SSLv2 do listy obsługiwanych protokołów, nie jest
on dodawany listy protokołów domyślnych. Usunięcie domyślnego protokołu z listy obsługiwanych protokołów
powoduje usunięcie go także z listy domyślnych protokołów.
Zestawy algorytmów szyfrowania SSL:
Systemowa implementacja protokołu SSL (System SSL) 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.
Następujące zestawy algorytmów szyfrowania, wyświetlone w formacie wartości systemowych, są obsługiwane przez
systemową implementację protokołu SSL:
| v *RSA_AES_128_GCM_SHA256
| v *RSA_AES_256_GCM_SHA384
|
|
|
|
v
v
v
v
*ECDHE_ECDSA_NULL_SHA
*ECDHE_ECDSA_RC4_128_SHA
*ECDHE_ECDSA_3DES_EDE_CBC_SHA
*ECDHE_RSA_NULL_SHA
|
|
|
|
|
v
v
v
v
v
*ECDHE_RSA_RC4_128_SHA
*ECDHE_RSA_3DES_EDE_CBC_SHA
*ECDHE_ECDSA_AES_128_CBC_SHA256
*ECDHE_RSA_AES_128_CBC_SHA256
|
|
|
|
|
v
v
v
v
v
v
v
v
*ECDHE_ECDSA_AES_128_GCM_SHA256
*ECDHE_RSA_AES_128_GCM_SHA256
*RSA_AES_128_CBC_SHA256
*RSA_NULL_SHA256
v *RSA_NULL_MD5
v *RSA_NULL_SHA
v *RSA_EXPORT_RC4_40_MD5
6
v
v
v
v
v
*RSA_RC4_128_MD5
*RSA_RC4_128_SHA
*RSA_EXPORT_RC2_CBC_40_MD5
*RSA_DES_CBC_SHA
*RSA_3DES_EDE_CBC_SHA
v
v
v
v
v
*RSA_AES_128_CBC_SHA
*RSA_RC2_CBC_128_MD5
*RSA_DES_CBC_MD5
*RSA_3DES_EDE_CBC_MD5
Lista algorytmów szyfrowania SSL obsługiwanych w konfiguracji fabrycznej
Na poniższej liście wyszczególnione są zestawy algorytmów szyfrowania. Systemowa implementacja protokołu SSL
ma wbudowaną obsługę 29 zestawów algorytmów szyfrowania. Administratorzy mogą zmieniać algorytmy
szyfrowania obsługiwane przez System SSL za pomocą wartości systemowych QSSLCSL i QSSLCSLCTL. Zestaw
algorytmów szyfrowania nie może być obsługiwany, jeśli nie jest również obsługiwany protokół SSL, którego wymaga
dany zestaw.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
W konfiguracji fabrycznej System SSL obsługuje następujące zestawy algorytmów szyfrowania:
v *ECDHE_ECDSA_AES_128_CBC_SHA256
v *ECDHE_ECDSA_AES_256_CBC_SHA384
v *ECDHE_ECDSA_AES_128_GCM_SHA256
v *ECDHE_ECDSA_AES_256_GCM_SHA384
v *RSA_AES_128_CBC_SHA256
v *RSA_AES_128_CBC_SHA
v *RSA_AES_256_CBC_SHA256
v *RSA_AES_256_CBC_SHA
v *RSA_AES_128_GCM_SHA256
v *RSA_AES_256_GCM_SHA384
v
v
v
v
v
v *ECDHE_RSA_3DES_EDE_CBC_SHA
v *RSA_3DES_EDE_CBC_SHA
|
|
v
v
v
v
v
v
v
|
v *ECDHE_ECDSA_NULL_SHA
v *ECDHE_RSA_NULL_SHA
v *RSA_NULL_SHA256
|
|
*RSA_RC4_128_SHA
*RSA_RC4_128_MD5
*RSA_DES_CBC_SHA
*RSA_EXPORT_RC4_40_MD5
7
v *RSA_NULL_SHA
v *RSA_NULL_MD5
Lista obsługiwanych algorytmów szyfrowania zależy od protokołów SSL obsługiwanych przez system oraz zmian
dokonanych w wartości systemowej QSSLCSL. Listę algorytmów szyfrowania można obejrzeć, wyświetlając wartość
QSSLCSL.
Lista domyślnych algorytmów szyfrowania SSL w konfiguracji fabrycznej
Kolejność listy domyślnych algorytmów szyfrowania w konfiguracji fabrycznej jest następująca:
| v *ECDHE_ECDSA_AES_128_CBC_SHA256
| v *ECDHE_ECDSA_AES_256_CBC_SHA384
| v *ECDHE_ECDSA_AES_128_GCM_SHA256
| v *ECDHE_ECDSA_AES_256_GCM_SHA384
| v *RSA_AES_128_CBC_SHA256
v
| v
v
| v
| v
| v
*RSA_AES_128_GCM_SHA256
| v *ECDHE_RSA_AES_256_CBC_SHA384
| v *ECDHE_RSA_AES_128_GCM_SHA256
| v *ECDHE_RSA_AES_256_GCM_SHA384
| v *ECDHE_ECDSA_3DES_EDE_CBC_SHA
| v *ECDHE_RSA_3DES_EDE_CBC_SHA
v *RSA_3DES_EDE_CBC_SHA
| v *ECDHE_ECDSA_RC4_128_SHA
| v *ECDHE_RSA_RC4_128_SHA
v *RSA_RC4_128_SHA
Listę domyślnych algorytmów szyfrowania w konfiguracji fabrycznej można skrócić, a jej elementy zamienić
miejscami, modyfikując wartość systemową QSSLCSL.
Następująca tabela zawiera listę specyfikacji algorytmów szyfrowania obsługiwanych przez poszczególne wersje
protokołu. Obsługiwane przez poszczególne protokoły specyfikacje algorytmów szyfrowania 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
|
X
|
X
|
*ECDHE_ECDSA_NULL_SHA
X
|
X
|
X
|
*ECDHE_RSA_NULL_SHA
X
|
X
|
*ECDHE_RSA_3DES_EDE_CBC_SHA
X
8
TLSv1.1
TLSv1.0
SSLv3
SSLv2
Tabela 1. Specyfikacje algorytmów szyfrowania obsługiwane w protokołach TLS i SSL (kontynuacja)
Reprezentacja wartości systemowej QSSLCSL
TLSv1.2
TLSv1.1
TLSv1.0
SSLv3
SSLv2
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
|
X
X
X
X
X
X
X
*RSA_3DES_EDE_CBC_SHA
X
X
X
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
X
X
X
*RSA_DES_CBC_SHA
*RSA_NULL_SHA256
X
*RSA_NULL_SHA
X
X
X
X
*RSA_NULL_MD5
X
X
X
X
X
*RSA_RC2_CBC_128_MD5
X
*RSA_3DES_EDE_CBC_MD5
X
*RSA_DES_CBC_MD5
X
Wartość systemowa SSL: QSSLCSLCTL
Algorytmy podpisu:
W protokole TLSv1.2 algorytm podpisu i algorytm mieszania używane w podpisach cyfrowych zostały rozdzielone na
osobne atrybuty. Wcześniej te algorytmy zależały od wynegocjowanego zestawu algorytmów szyfrowania. Systemowa
implementacja protokołu SSL (System SSL) 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 żą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
traktuje odebrany certyfikat o niepożądanym algorytmie podpisu jako błąd sesji, chyba że jest skonfigurowane
opcjonalne uwierzytelnianie klienta.
9
|
|
|
|
Jeśli systemowa implementacja protokołu SSL otrzymuje żądanie certyfikatu i nie jest w stanie wybrać
zgodnego certyfikatu, wysyła dostępny niezgodny certyfikat RSA. Węzeł sieci decyduje, czy taki certyfikat
jest traktowany jako błąd sesji. Szczegółowe informacje na temat logiki wyboru certyfikatu w sesji
systemowej implementacji protokołu SSL można znaleźć w sekcji “Wybór wielu certyfikatów” na stronie 20.
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 podpisu
certyfikatu używanego w tej sesji. Na przykład komunikat uzgadniania może być chroniony algorytmem
SHA512, chociaż dla sesji został wybrany certyfikat MD5.
System SSL obsługuje następujące algorytmy:
| v ECDSA_SHA512
| v ECDSA_SHA384
| v ECDSA_SHA256
| v ECDSA_SHA224
| v
v
v
v
v
ECDSA_SHA1
RSA_SHA512
RSA_SHA384
RSA_SHA256
RSA_SHA224
v RSA_SHA1
v RSA_MD5
Algorytmy podpisu obsługiwane w konfiguracji fabrycznej
|
|
|
|
W konfiguracji fabrycznej System SSL obsługuje następującą listę algorytmów podpisu:
v ECDSA_SHA512
v
v
v
| v
v
v
v
ECDSA_SHA384
ECDSA_SHA256
ECDSA_SHA224
ECDSA_SHA1
RSA_SHA512
RSA_SHA384
RSA_SHA256
v RSA_SHA224
v RSA_SHA1
v RSA_MD5
Algorytmy podpisu domyślne w konfiguracji fabrycznej
Kolejność listy domyślnych algorytmów podpisu w konfiguracji fabrycznej jest następująca:
| v ECDSA_SHA512
| v ECDSA_SHA384
| v ECDSA_SHA256
| v ECDSA_SHA224
| v ECDSA_SHA1
v RSA_SHA512
v RSA_SHA384
10
v
v
v
v
RSA_SHA256
RSA_SHA224
RSA_SHA1
RSA_MD5
Domyślną listę algorytmów podpisu z konfiguracji fabrycznej można zmienić za pomocą komendy zaawansowanej
analizy SSLCONFIG z zestawu Systemowych narzędzi serwisowych (System Service Tools - SST).
Pojęcia pokrewne:
Renegocjacja:
Rozpoczęcie nowej operacji uzgadniania w istniejącej bezpiecznej sesji określa się jako renegocjację. Renegocjacja w
systemowej implementacji protokołu SSL 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. Do
zainicjowania renegocjacji w aplikacjach GSKit wykorzystujących System SSL jest używana funkcja
gsk_secure_soc_misc().
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. Niektóre implementacje protokołu SSL nie zostały
zaktualizowane o obsługę dokumentu RFC 5746 lub taka aktualizacja nie jest w ich przypadku możliwa. Aby
umożliwić ciągłość działalności i współdziałanie na różnych etapach przejścia między wersjami protokołu, istnieją
dwie właściwości renegocjacji.
Tryb renegocjacji SSL
Domyślnie systemowa implementacja protokołu SSL wymaga użycia semantyki opisanej w dokumencie RFC 5746 we
wszystkich operacjach renegocjacji. Tryb domyślny można zmienić za pomocą 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.
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
Tryb krytyczny rozszerzonej renegocjacji określa, czy systemowa implementacja protokołu SSL wymaga, aby
wszystkie węzły sieci wskazały, czy obsługują 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ć
11
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, w
których nie wdrożono obsługi dokumentu RFC 5746. Jeśli tryb krytyczny jest włączony, systemowa implementacja
protokołu SSL może negocjować tylko z systemami, w których jest zaimplementowany dokument 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ę, ze wszystkie węzły sieci systemowej implementacji protokołu SSL obsługują dokument RFC 5746, ustawienie
trybu jest zmieniane 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 i osobna właściwość dla aplikacji serwerowych.
System SSL 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:
RFC 5746: "Transport Layer Security (TLS) Renegotiation Indication Extension"
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óry atrybuty systemowej implementacji protokołu SSL
dotyczące tej aplikacji. Taka definicja aplikacji jest znana użytkownikom systemowej implementacji protokołu SSL
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.
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 do identyfikowania definicji aplikacji
zawierającej informacje konfiguracyjne.
Każdy z następujących interfejsów programowania systemowej implementacji protokołu SSL zawiera metodę
identyfikowania 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
– Ustawienie właściwości systemowej języka Java™ os400.secureApplication
Do sterowania odpowiednimi atrybutami systemowej implementacji protokołu SSL w aplikacji można użyć
następujących pól definicji aplikacji w programie DCM:
12
Protokoły SSL:
Pole definicji aplikacji Protokoły SSL określa, które wersje protokołu SSL są obsługiwane w aplikacji.
Wartość domyślna *PGM oznacza, że program korzystający z danego "ID aplikacji" ustawia atrybut protokołu SSL na
odpowiednią wartość. Wszystkie programy systemowej implementacji protokołu SSL 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 wiadomo, że wymagana wartość atrybutu nie jest ustawiana w
programie.
Jeśli ustawienie *PGM nie powoduje użycia właściwych protokołów, to pole 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 algorytmów szyfrowania warstwy SSL:
Pole definicji aplikacji Opcje specyfikacji algorytmów szyfrowania warstwy SSL określa, jakie zestawy algorytmów
szyfrowania są obsługiwane w aplikacji.
Wartość domyślna *PGM oznacza, że program korzystający z danego "ID aplikacji" ustawia atrybut obsługiwanych
zestawów algorytmów szyfrowania na odpowiednią wartość. 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 niewłaściwej wartości, w tym polu można zdefiniować zestawy algorytmów
szyfrowania warstwy SSL 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 słabszą konfigurację zabezpieczeń 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).
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.
Szczegółowe informacje dotyczące tej koncepcji można znaleźć w temacie “Renegocjacja” na stronie 11 w sekcji
Właściwości systemowej implementacji protokołu SSL.
13
Wartość domyślna *PGM oznacza, że program korzystający z danego "ID aplikacji" już ustawił tryb na odpowiednią
wartość. Program albo korzysta z domyślnej wartości systemowej implementacji protokołu SSL, albo z wartości
ustawionej jawnie za pomocą wywołania funkcji API gsk_attribute_set_enum() dla tego atrybutu.
Ustawienie "włączony" 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, 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 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 jakimi 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.
Ustawienie nazwy FQDN serwera umożliwia systemowej implementacji protokołu SSL 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.
14
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 16
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.
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 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ązywania połączenia z żądanym responderem OCSP, należy wprowadzić
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
odpowiednio 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ć to pole na 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:
“Wycofywanie certyfikatów” na stronie 19
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.
15
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 mają początkową wartość domyślną, a w
przypadku tego atrybutu jest to wartość "wyłączone". 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ć to pole na 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ć to pole na 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:
Algorytm podpisu SSL:
Pole definicji aplikacji Algorytmy podpisu SSL określa, jakie algorytmy są obsługiwane w aplikacji.
Przegląd informacji o algorytmach podpisu i ich zastosowaniach zawiera temat “Algorytmy podpisu” na stronie 9 w
sekcji Właściwości systemowej implementacji protokołu SSL.
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 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.
Protokół OCSP (Online Certificate Status Protocol)
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.
16
Aplikacje sprawdzają status wycofania certyfikatu za pomocą 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 są włączone zarówno adres URL, jak i sprawdzanie informacji AIA, wówczas informacje AIA są sprawdzane
tylko wtedy, gdy zapytanie wysłane na adres URL respondera zwraca nieokreślony status wycofania.
Pojęcia pokrewne:
RFC 2560: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
Konfiguracja 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
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.
17
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 sprawdzania 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_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,
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_ APIs lub 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 15
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)
18
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. Wartości statusu certyfikatu to
ważny (good), wycofany (revoked) lub nieznany (unknown). 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 nieustalony zarówno w przypadku sprawdzenia adresu URL, jak i sprawdzenia AIA,
sprawdzanie poprawności jest kontynuowane tak, jakby zwrócono status inny niż "wycofany". Informacje o
certyfikacie o nieokreślonym statusie wycofania można uzyskać za pomocą funkcji gsk_attribute_get_buffer() i
atrybutu GSK_UNKNOWNREVOCATIONSTATUS_SUBJECT.
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 (SA), który wystawić certyfikat podlegający sprawdzeniu
–
–
–
–
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).
19
a. Jeśli położenie listy wycofań certyfikatów jest skonfigurowane przy użyciu Menedżera certyfikatów cyfrowych
(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).
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.
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 16
Zarządzanie położeniami listy CRL
|
|
|
|
|
Wybór wielu certyfikatów
Funkcja System SSL umożliwia przypisanie nie więcej niż czterech certyfikatów do bezpiecznego środowiska. Obsługę
wielu certyfikatów stosuje się w sytuacjach, gdy mają zostać włączone certyfikaty 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 warstwy SSL. Jeśli dany klient nie obsługuje certyfikatów TLSv1.2 ani ECDSA,
| serwer musi nadal obsługiwać negocjacje w oparciu o certyfikat RSA.
20
|
|
|
|
|
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 Menedżerze
certyfikatów cyfrowych (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 odpowiedni certyfikat dla tej sesji jest wybierany na podstawie atrybutów sesji.
Przy podejmowaniu decyzji są uwzględniane atrybuty SSL zarówno ze strony 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 prokotołó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.
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. Istnieje jeszcze jedna uwaga dotycząca certyfikatów RSA związana ze zgodnością z poprzednimi wersjami. 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.
|
Makro SSLCONFIG
Aby skorzystać z obsługi makro konfiguracji SSL, należy wykonać następujące czynności:
1. Uruchom Systemowe narzędzia serwisowe (SST).
21
2.
3.
4.
5.
6.
Wybierz opcję Uruchomienie narzędzia serwisowego.
Wybierz Wyświetl/Zmień/Zrzuć.
Wybierz Wyświetl/Zmień pamięć.
Wybierz Dane Licencjonowanego kodu wewnętrznego (LIC).
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.
Uwierzytelnianie serwera
Dzięki uwierzytelnieniu serwera klient upewnia się, że certyfikat serwera jest poprawny i że podpisał go zaufany
ośrodek wydający certyfikaty.
Protokół SSL korzysta z szyfrowania asymetrycznego i przepływu protokołu uzgadniania do wygenerowania klucza
symetrycznego, którego używa się tylko podczas jednej sesji SSL. Klucz ten zostaje użyty do wygenerowania zestawu
kluczy, które z kolei zostaną wykorzystane do szyfrowania i deszyfrowania danych przesyłanych podczas sesji SSL.
Następnie po zakończeniu uzgadniania SSL jeden lub oba końce łącza komunikacyjnego zostaną uwierzytelnione.
Dodatkowo wygenerowany zostanie unikalny klucz do szyfrowania i deszyfrowania danych. Zaszyfrowane dane na
poziomie warstwy aplikacji będą przesłane w ramach sesji SSL.
Uwierzytelnianie klienta
Wiele aplikacji ma opcję włączania uwierzytelniania klienta. Korzystając z możliwości uwierzytelniania klienta serwer
upewnia się, że certyfikat klienta jest poprawny i że podpisał go zaufany ośrodek wydający certyfikaty.
Funkcję uwierzytelniania klienta obsługują następujące aplikacje dostępne na platformie IBM i:
v IBM HTTP Server for i
v Serwer FTP
v Serwer Telnet
v System końcowy Centrum Zarządzania
v IBM Tivoli Directory Server for IBM i
Protokoły SSL (Secure Sockets Layer) i TLS (Transport Layer Security) na serwerze Directory Server
Zabezpieczanie klientów FTP za pomocą protokołu TLS lub SSL
Zabezpieczanie programu Telnet za pomocą protokołu SSL
Konfigurowanie protokołu SSL dla serwera administracyjnego (ADMIN) serwera HTTP
Wymagania wstępne dotyczące protokołu SSL
Ten temat zawiera opis wymagań wstępnych dotyczących protokołu SSL na platformie IBM i, a także kilka
przydatnych wskazówek.
Przed rozpoczęciem używania protokołu SSL 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)
22
v Jeśli program DCM ma być używany na serwerze HTTP, należy zainstalować oprogramowanie IBM Developer Kit
for Java (5770-JV1). W przeciwnym razie serwer administratora HTTP nie zostanie uruchomiony.
v Aby przyspieszyć przetwarzanie uzgadniania SSL, można zainstalować sprzęt szyfrujący do obsługi protokołu SSL.
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” na stronie 35
Ten temat zawiera podstawowe informacje, które mogą pomóc zmniejszyć liczbę potencjalnych problemów z
protokołem SSL na platformie IBM i.
Sprzęt szyfrujący
Certyfikaty publiczne a certyfikaty prywatne
Konfigurowanie programu DCM
Zabezpieczanie aplikacji za pomocą protokołu SSL
Za pomocą protokołu SSL można zabezpieczyć szereg aplikacji systemu IBM i. Szczegółowe informacje na ten temat
zawiera dokumentacja poszczególnych aplikacji.
Pojęcia pokrewne:
“Scenariusz: zabezpieczanie wszystkich połączeń z serwerem Centrum Zarządzania za pomocą protokołu SSL” na
stronie 27
W scenariuszu opisano zabezpieczanie za pomocą protokołu SSL wszystkich połączeń z serwerem IBM i działającym
jako system centralny. Opisywane czynności wykonywane są przy użyciu systemu Centrum Zarządzania System i
Navigator.
Odwzorowywanie tożsamości w przedsiębiorstwie (EIM)
Używanie protokołu SSL do zabezpieczania serwera FTP
Serwer HTTP
Administrowanie protokołem SSL (temat dotyczący programu iSeries Access for Windows)
Scenariusz Telnet: zabezpieczanie aplikacji Telnet za pomocą SSL
Interfejs API protokołu SSL
Scenariusze: protokół SSL
Scenariusze dotyczące protokołu SSL mają za zadanie pomóc użytkownikom osiągnąć jak największe korzyści z
włączenia protokołu SSL na serwerze IBM i.
Scenariusze dotyczące protokołu SSL zawierają praktyczne przykłady zastosowania tego protokołu i pozwalają lepiej
zrozumieć jego działanie w systemie IBM i.
Scenariusz: zabezpieczanie aplikacji Telnet za pomocą protokołu SSL
Scenariusz: wykorzystanie sprzętu szyfrującego do zabezpieczania prywatnych kluczy
Scenariusz: zabezpieczanie połączenia klienta z serwerem Centrum
Zarządzania za pomocą protokołu SSL
W scenariuszu opisano zabezpieczanie za pomocą protokołu SSL połączenia klienta zdalnego z serwerem IBM i
działającym jako system centralny. Opisywane czynności wykonywane są przy użyciu serwera Centrum Zarządzania
System i Navigator.
23
Sytuacja
Firma dysponuje siecią LAN, w której znajduje się kilka systemów IBM i. Administrator systemu w tej firmie, Robert,
wyznaczył jeden z systemów IBM i na system centralny (System A) w sieci lokalnej. Robert używa serwera Centrum
Zarządzania w Systemie A do zarządzania wszystkimi pozostałymi systemami końcowymi w tej sieci LAN.
Robert chce się połączyć z serwerem Centrum Zarządzania w Systemie A z sieci lokalnej znajdującej się poza jego
firmą. Robert wiele podróżuje i podczas podróży potrzebuje bezpiecznego połączenia z serwerem Centrum
Zarządzania. Chce mieć bezpieczne połączenie między komputerem PC i serwerem Centrum Zarządzania, gdy znajduje
się poza biurem. Robert decyduje się na włączenie protokołu SSL na swoim komputerze PC oraz na serwerze Centrum
Zarządzania w Systemie A. W przypadku protokołu SSL włączonego w ten sposób Robert może być pewien, że
podczas podróży jego połączenie z serwerem Centrum Zarządzania jest bezpieczne.
Cele
Robert chce zabezpieczyć połączenie między swoim komputerem PC i serwerem Centrum Zarządzania. Robert nie
wymaga dodatkowego zabezpieczenia połączenia między serwerem Centrum Zarządzania w Systemie A i systemami
końcowymi w sieci LAN. Pozostali pracownicy biura nie potrzebują dodatkowego zabezpieczenia połączeń z serwerem
Centrum Zarządzania. Robert planuje skonfigurować swój komputer PC i serwer Centrum Zarządzania w Systemie A
tak, aby połączenie używało uwierzytelniania serwera. Połączenia z serwerem Centrum Zarządzania z komputerów PC
lub systemów IBM i w sieci lokalnej nie są zabezpieczone przez protokół SSL.
Szczegóły
Poniższa tabela przedstawia typy używanego uwierzytelniania na podstawie włączania i wyłączania protokołu SSL w
kliencie PC:
Tabela 2. Wymagane elementy dla połączenia między klientem i serwerem Centrum Zarządzania zabezpieczonego za
pomocą protokołu SSL
Status SSL na komputerze PC
Roberta
Określony poziom uwierzytelniania dla serwera
Centrum Zarządzania w Systemie A
Czy włączono połączenie SSL?
Protokół SSL wyłączony
Dowolny
Nie
Protokół SSL jest włączony
Dowolny
Tak (uwierzytelnianie serwera)
Uwierzytelnianie serwera oznacza, że komputer PC Roberta uwierzytelnia certyfikat serwera Centrum Zarządzania.
Komputer PC Roberta podczas łączenia się z serwerem Centrum Zarządzania działa jako klient SSL. Serwer Centrum
Zarządzania działa jako serwer SSL i musi udowodnić swoją tożsamość. Serwer Centrum Zarządzania czyni to,
udostępniając certyfikat wystawiony przez ośrodek certyfikacji (CA), któremu ufa komputer PC Roberta.
Wymagania wstępne i założenia
Robert musi wykonać poniższe zadania administrowania i konfiguracji, aby zabezpieczyć połączenie między swoim
komputerem PC a serwerem Centrum Zarządzania w systemie A:
1. Sprawdzić, czy System A spełnia wymagania wstępne dla protokołu SSL.
2. Sprawdzić, czy na Systemie A działa system operacyjny i5/OS w wersji V5R3 lub nowszej.
3. Sprawdzić, czy na klienckim komputerze PC działa oprogramowanie IBM i Access for Windows w wersji V5R3
lub nowszej.
4. Uzyskać ośrodek certyfikacji dla systemów IBM i.
5. Utworzyć certyfikat podpisany przez ośrodek certyfikacji dla Systemu A.
6. Wysłać ośrodek certyfikacji i certyfikat do Systemu A oraz zaimportować go do bazy danych kluczy.
7. Przypisać do certyfikatu identyfikator serwera Centrum Zarządzania i identyfikatory aplikacji wszystkich
systemów IBM i. Systemami IBM i są: serwer centralny TCP, serwer bazy danych, serwer kolejek danych, serwer
plików, sieciowy serwer wydruków, serwer komend zdalnych i serwer wpisywania się do systemu.
24
a. W Systemie A uruchom program IBM Digital Certificate Manager. Robert uzyskuje lub tworzy certyfikaty albo
konfiguruje lub zmienia system certyfikacji.
b. Kliknij Wybierz bazę certyfikatów (Select a Certificate Store).
c. Wybierz *SYSTEM i kliknij Kontynuuj.
d. Wpisz hasło bazy certyfikatów *SYSTEM i kliknij przycisk Kontynuuj. Po przeładowaniu menu rozwiń
Zarządzanie aplikacjami.
e. Kliknij Aktualizacja przypisania certyfikatów.
f. Wybierz Serwer i kliknij Kontynuuj.
g. Wybierz pozycję Serwer Centrum Zarządzania i kliknij przycisk Aktualizacja przypisania certyfikatów.
Powoduje to przypisanie certyfikatu do serwera Centrum Zarządzania.
h. Kliknij Przypisanie nowego certyfikatu. Program DCM zostanie przeładowany do strony Aktualizacja
przypisania certyfikatów z komunikatem potwierdzającym.
i. Kliknij Gotowe.
j. Przypisz certyfikat do wszystkich serwerów dostępu klienta.
8. Pobrać ośrodek certyfikacji (CA) do klienta PC.
Zanim Robert będzie mógł włączyć protokół SSL na serwerze Centrum Zarządzania musi zainstalować wymagane
programy oraz skonfigurować certyfikaty cyfrowe w systemie. Po spełnieniu wymagań wstępnych Robert może
wykonać poniższe procedury w celu włączenia protokołu SSL dla serwera Centrum Zarządzania.
Etapy konfigurowania
Robert musi wykonać poniższe czynności, aby zabezpieczyć połączenie swojego komputera PC z serwerem Centrum
Zarządzania w Systemie A za pomocą protokołu SSL:
1. “Czynność 1: dezaktywowanie protokołu SSL dla klienta System i Navigator” na stronie 26
2. “Czynność 2: ustawianie poziomu uwierzytelniania dla serwera Centrum Zarządzania” na stronie 26
3. “Czynność 3: restartowanie systemu Centrum Zarządzania w systemie centralnym” na stronie 26
4. “Czynność 4: aktywowanie protokołu SSL dla klienta System i Navigator” na stronie 26
5. “Punkt opcjonalny: dezaktywowanie protokołu SSL dla klienta System i Navigator” na stronie 27
Pojęcia pokrewne:
“Wymagania wstępne dotyczące protokołu SSL” na stronie 22
Uruchamianie programu Digital Certificate Manager
Szczegóły konfiguracji: zabezpieczanie połączenia klienta z systemem Centrum
W tym temacie szczegółowo przedstawiono etapy zabezpieczania połączeń klienta z serwerem Centrum Zarządzania za
pomocą protokołu SSL.
W poniższym opisie przyjęto, że użytkownik zapoznał się z tematem Scenariusz: zabezpieczanie połączenia klienta z
serwerem Centrum Zarządzania za pomocą protokołu SSL.
W tym scenariuszu serwer IBM i jest wyznaczony jako system centralny w sieci lokalnej firmy. Robert używa serwera
Centrum Zarządzania w systemie centralnym (nazywanym tutaj Systemem A) do zarządzania systemami końcowymi w
firmowej sieci. Poniższe informacje wyjaśniają sposób wykonywania czynności wymaganych do zabezpieczenia
połączenia klienta zewnętrznego z serwerem Centrum Zarządzania. Należy śledzić sposób wykonywania przez Roberta
czynności konfiguracyjnych w tym scenariuszu.
Pojęcia pokrewne:
25
stronie 27
Navigator.
Pierwsze konfigurowanie certyfikatów
Czynność 1: dezaktywowanie protokołu SSL dla klienta System i Navigator:
Ten etap jest konieczny tylko wtedy, gdy protokół SSL dla klienta System i Navigator został wcześniej aktywowany.
1. W programie System i Navigator rozwiń węzeł Moje połączenia.
2. Prawym przyciskiem myszy kliknij System A i wybierz Właściwości.
3. Kliknij zakładkę Protokół SSL i usuń zaznaczenie z pola wyboru Podczas połączenia używaj protokołu SSL.
4. Wyjdź z programu System i Navigator i zrestartuj go.
Na elemencie Centrum Zarządzania w programie System i Navigator przestanie być wyświetlana kłódka, co oznacza
połączenie niezabezpieczone. Informuje to Roberta o tym, że nie ma już zabezpieczonego przez SSL połączenia
między klientem i systemem centralnym w swojej firmie.
Czynność 2: ustawianie poziomu uwierzytelniania dla serwera Centrum Zarządzania:
1. W programie System i Navigator kliknij prawym przyciskiem myszy Centrum Zarządzania i wybierz opcję
Właściwości.
2. Kliknij zakładkę Ochrona, a następnie zaznacz opcję Używaj protokołu SSL.
3. Wybierz opcję Dowolny jako poziom uwierzytelniania (opcja dostępna w programie IBM i Access for Windows).
4. Kliknij OK, aby ustawić tę wartość w systemie centralnym.
Czynność 3: restartowanie systemu Centrum Zarządzania w systemie centralnym:
2. W Systemie A rozwiń pozycję Sieć-->Serwery i wybierz TCP/IP.
3. Kliknij prawym przyciskiem myszy Centrum Zarządzania i wybierz Zatrzymaj. Widok systemu centralnego
zostaje zwinięty i wyświetlany jest komunikat wyjaśniający, że użytkownik nie jest połączony z serwerem.
4. Po zatrzymaniu serwera Centrum Zarządzania kliknij przycisk Uruchom, aby go zrestartować.
Czynność 4: aktywowanie protokołu SSL dla klienta System i Navigator:
3. Kliknij zakładkę Protokół SSL i wybierz opcję Podczas połączenia używaj protokołu SSL.
W programie System i Navigator obok serwera Centrum Zarządzania zostanie wyświetlona kłódka, która oznacza
połączenie zabezpieczone przez protokół SSL. Informuje ona Roberta o tym, że połączenie między jego klientem i
systemem centralnym w jego firmie jest zabezpieczone przez protokół SSL.
Uwaga: Ta procedura zabezpiecza tylko połączenie między jednym komputerem PC i systemem Centrum
Zarządzania. Pozostałe połączenia klientów z serwerem Centrum Zarządzania, jak również połączenia systemów
końcowych z serwerem Centrum Zarządzania nie będą zabezpieczone. Aby chronić inne klienty, należy sprawdzić, czy
spełniają one wymagania wstępne i powtórzyć “Czynność 4: aktywowanie protokołu SSL dla klienta System i
Navigator”. Informacje o zabezpieczaniu innych połączeń z serwerem Centrum Zarządzania zawiera temat Scenariusz:
zabezpieczanie wszystkich połączeń z serwerem Centrum Zarządzania za pomocą protokołu SSL.
26
Punkt opcjonalny: dezaktywowanie protokołu SSL dla klienta System i Navigator:
Jeśli Robert chce pracować w biurze firmy i nie chce używać połączenia zabezpieczonego za pomocą protokołu SSL
wpływającego na wydajność komputera PC, może je w prosty sposób dezaktywować, wykonując następujące
czynności:
3. Kliknij zakładkę Protokół SSL i usuń zaznaczenie z pola wyboru Podczas połączenia używaj protokołu SSL.
Scenariusz: zabezpieczanie wszystkich połączeń z serwerem Centrum
Navigator.
Sytuacja
W firmie skonfigurowano sieć WAN zawierającą kilka systemów IBM i w miejscach zdalnych (systemy końcowe).
Systemy końcowe są zarządzane przez jeden system centralny znajdujący się w głównym biurze. Tomek jest specjalistą
do spraw bezpieczeństwa w firmie. Chce używać protokołu SSL (Secure Sockets Layer) do zabezpieczania wszystkich
połączeń między serwerem Centrum Zarządzania zainstalowanym w systemie centralnym firmy a wszystkimi
systemami i klientami IBM i.
Szczegóły
Tomek może bezpiecznie, za pomocą protokołu SSL, zarządzać wszystkimi połączeniami z serwerem Centrum
Zarządzania. Aby używać protokołu SSL na serwerze Centrum Zarządzania, Tomek musi zabezpieczyć program
System i Navigator na komputerze PC używanym do uzyskiwania dostępu do systemu centralnego.
Może wybrać jeden z dwóch poziomów uwierzytelniania serwera Centrum Zarządzania:
Uwierzytelnianie serwera
Uwierzytelnianie certyfikatu serwera. Klient musi sprawdzić poprawność serwera bez względu na to, czy tym
klientem jest program System i Navigator na komputerze PC, czy serwer Centrum Zarządzania w systemie
centralnym. Gdy program System i Navigator nawiązuje połączenie z systemem centralnym, komputer PC jest
klientem SSL, a Centrum Zarządzania uruchomione na systemie centralnym jest serwerem SSL. System
centralny podczas łączenia się z systemem końcowym działa jako klient SSL. System końcowy działa jako
serwer SSL. Serwer musi udowodnić swoją tożsamość klientowi, dostarczając certyfikat wydany przez
ośrodek certyfikacji, któremu ufa klient. Każdy serwer SSL musi mieć poprawny certyfikat wydany przez
zaufany ośrodek certyfikacji (CA).
Uwierzytelnianie klienta i serwera
Uwierzytelnianie certyfikatów systemu centralnego i końcowego. Jest to wyższy poziom zabezpieczeń niż
poziom uwierzytelniania serwera. W innych aplikacjach nazywane jest ono uwierzytelnianiem klienta,
ponieważ klient musi dostarczyć poprawny zaufany certyfikat. Gdy system centralny (klient SSL) próbuje
nawiązać połączenie z systemem końcowym (serwer SSL), obydwa systemy uwierzytelniają wzajemnie swoje
certyfikaty pod kątem autentyczności ośrodka certyfikacji.
Uwaga: Uwierzytelnianie klienta i serwera jest wykonywane tylko między dwoma systemami IBM i. Serwer
nie wykonuje uwierzytelniania klienta, gdy klientem jest komputer PC.
W przeciwieństwie do innych aplikacji, Centrum Zarządzania umożliwia także uwierzytelnianie przez listę
weryfikacji, nazywaną listą weryfikacji zaufanych grup. Zazwyczaj lista weryfikacji przechowuje informacje
identyfikujące użytkownika, takie jak identyfikator użytkownika, oraz informacje uwierzytelniające, takie jak
hasło, osobisty numer identyfikacyjny lub certyfikat cyfrowy. Informacje uwierzytelniające są zaszyfrowane.
27
Większość aplikacji nie informuje o włączeniu uwierzytelniania serwera i klienta, ponieważ uwierzytelnianie serwera
prawie zawsze ma miejsce podczas włączania sesji SSL. Wiele aplikacji ma opcje konfiguracyjne uwierzytelniania
klienta. Centrum Zarządzania używa terminu "uwierzytelnianie serwera i klienta" zamiast "uwierzytelnianie klienta" z
uwagi na podwójną rolę systemu centralnego w sieci. Gdy komputer PC używa połączenia z systemem centralnym,
system centralny działa jako serwer. Jeśli jednak system centralny łączy się z systemem końcowym, działa jako klient.
Rysunek ilustruje, jak system centralny funkcjonuje w sieci jako serwer i jako klient.
Uwaga: Na tej ilustracji certyfikat powiązany z ośrodkiem certyfikacji musi zostać zapisany w bazie danych kluczy w
systemie centralnym i we wszystkich systemach końcowych. Ośrodek certyfikacji musi zostać zapisany w systemie
centralnym, systemach końcowych, a także na komputerze PC.
28
Wymagania wstępne i założenia
Tomek musi wykonać następujące zadania administrowania i konfiguracji, aby zabezpieczyć wszystkie połączenia z
serwerem Centrum Zarządzania:
29
1. Sprawdzić, czy System A spełnia wymagania wstępne dla protokołu SSL.
2. Sprawdzić, czy na systemie centralnym i wszystkich systemach końcowych działa system operacyjny OS/400 w
wersji V5R2 lub system operacyjny i5/OS w wersji V5R3 lub nowszej.
3.
4.
5.
6.
Uwaga: System operacyjny IBM i 5.4 lub nowsze: połączenia z systemem OS/400 V5R1 są niedozwolone.
Sprawdzić, czy na klienckim komputerze PC działa program System i Navigator, będący częścią oprogramowania
IBM i Access for Windows w wersji V5R3 lub nowszej.
Uzyskać ośrodek certyfikacji (CA) dla systemów IBM i.
Utworzyć certyfikat podpisany przez ośrodek certyfikacji dla Systemu A.
Wysłać ośrodek certyfikacji i certyfikat do Systemu A oraz zaimportować go do bazy danych kluczy.
7. Przypisać certyfikatom identyfikatory aplikacji Centrum Zarządzania i identyfikatory aplikacji wszystkich
systemów IBM i. Systemami IBM i są: serwer centralny TCP, serwer bazy danych, serwer kolejek danych, serwer
plików, sieciowy serwer wydruków, serwer komend zdalnych i serwer wpisywania się do systemu.
a. Na serwerze Centrum Zarządzania uruchom program IBM Digital Certificate Manager. Jeśli chcesz uzyskać
lub utworzyć certyfikaty, zmienić lub skonfigurować system certyfikatów, zrób to w tym momencie.
b. Kliknij Wybierz bazę certyfikatów (Select a Certificate Store).
c. Wybierz *SYSTEM i kliknij Kontynuuj.
d. Wpisz hasło bazy certyfikatów *SYSTEM i kliknij przycisk Kontynuuj. Po przeładowaniu menu rozwiń
Zarządzanie aplikacjami.
e. Kliknij Aktualizacja przypisania certyfikatów.
f. Wybierz Serwer i kliknij Kontynuuj.
g. Wybierz pozycję Serwer Centrum Zarządzania i kliknij przycisk Aktualizacja przypisania certyfikatów.
Spowoduje to przypisanie certyfikatu do systemu Centrum Zarządzania.
h. Wybierz certyfikat, który ma być przypisany do aplikacji i kliknij polecenie Przypisz nowy certyfikat.
Program DCM zostanie przeładowany do strony Aktualizacja przypisania certyfikatów z komunikatem
potwierdzającym.
i. Kliknij przycisk Anuluj, aby powrócić do listy aplikacji.
j. Powtórz tę procedurę dla wszystkich serwerów z systemem operacyjnym IBM i.
8. Pobierz ośrodek CA na kliencki komputer PC z programem System i Navigator.
Etapy konfiguracji
Zanim Tomek będzie mógł włączyć protokół SSL na serwerze Centrum Zarządzania, musi zainstalować wymagane
wstępnie programy oraz skonfigurować certyfikaty cyfrowe w systemie centralnym. Przed kontynuowaniem zapoznaj
się z wymaganiami wstępnymi i założeniami dla tego scenariusza. Po spełnieniu wymagań wstępnych może wykonać
poniższe procedury, aby zabezpieczyć wszystkie połączenia z serwerem Centrum Zarządzania:
Uwaga: Jeśli protokół SSL włączono w programie System i Navigator, Tomek musi go wyłączyć przed włączeniem
protokołu SSL na serwerze Centrum Zarządzania. Jeśli protokół SSL włączono w programie System i Navigator, a nie
włączono na serwerze Centrum Zarządzania, próby nawiązania połączenia programu System i Navigator z systemem
centralnym zakończą się niepowodzeniem.
1. “Czynność 1: konfigurowanie systemu centralnego pod kątem uwierzytelniania serwera” na stronie 32
2. “Czynność 2: konfigurowanie systemów końcowych pod kątem uwierzytelniania serwera” na stronie 32
4. “Czynność 4: restartowanie systemu Centrum Zarządzania we wszystkich systemach końcowych” na stronie 33
5. “Czynność 5: aktywowanie protokołu SSL dla klienta System i Navigator” na stronie 33
6. “Czynność 6: konfigurowanie systemu centralnego pod kątem uwierzytelniania klientów” na stronie 33
7. “Czynność 7: konfigurowanie systemów końcowych pod kątem uwierzytelniania klientów” na stronie 33
8. “Czynność 8: kopiowanie listy sprawdzania do systemów końcowych” na stronie 34
30
10. “Czynność 10: restartowanie systemu Centrum Zarządzania we wszystkich systemach końcowych” na stronie 35
Pojęcia pokrewne:
“Zabezpieczanie aplikacji za pomocą protokołu SSL” na stronie 23
Za pomocą protokołu SSL można zabezpieczyć szereg aplikacji systemu IBM i. Szczegółowe informacje na ten temat
zawiera dokumentacja poszczególnych aplikacji.
Zadania pokrewne:
“Szczegóły konfiguracji: zabezpieczanie połączenia klienta z systemem Centrum Zarządzania za pomocą protokołu
SSL” na stronie 25
W tym temacie szczegółowo przedstawiono etapy zabezpieczania połączeń klienta z serwerem Centrum Zarządzania za
pomocą protokołu SSL.
“Szczegóły konfiguracji: zabezpieczanie wszystkich połączeń z systemem Centrum Zarządzania za pomocą protokołu
SSL”
W temacie przedstawiono szczegóły używania protokołu SSL do zabezpieczania wszystkich połączeń z serwerem
Centrum Zarządzania.
Szczegóły konfiguracji: zabezpieczanie wszystkich połączeń z systemem Centrum
W temacie przedstawiono szczegóły używania protokołu SSL do zabezpieczania wszystkich połączeń z serwerem
Centrum Zarządzania.
W poniższych informacjach przyjęto, że użytkownik zapoznał się z następującym tematem: Scenariusz: zabezpieczanie
wszystkich połączeń z serwerem Centrum Zarządzania za pomocą protokołu SSL.
Użytkownik chce zrozumieć sposób wykonywania czynności wymaganych do zabezpieczenia wszystkich połączeń z
serwerem Centrum Zarządzania. Należy śledzić sposób wykonywania operacji przez Tomka w tym scenariuszu.
Zanim Tomek będzie mógł aktywować protokół SSL w systemie Centrum Zarządzania, musi zainstalować wymagane
programy oraz skonfigurować certyfikaty cyfrowe na serwerze IBM i. Po spełnieniu wymagań wstępnych może
wykonać poniższe procedury, aby zabezpieczyć wszystkie połączenia z serwerem Centrum Zarządzania.
Uwaga: Jeśli protokół SSL włączono w programie System i Navigator, Tomek musi go wyłączyć przed włączeniem
protokołu SSL na serwerze Centrum Zarządzania. Jeśli protokół SSL włączono w programie System i Navigator, a nie
włączono na serwerze Centrum Zarządzania, próby nawiązania połączenia między programem System i Navigator a
systemem centralnym zakończą się niepowodzeniem.
Protokół SSL umożliwia zabezpieczanie transmisji zarówno między systemem centralnym i systemem końcowym, jak i
między klientem System i Navigator a systemem centralnym. Protokół SSL umożliwia transport i uwierzytelnianie
certyfikatów oraz szyfrowanie danych. Połączenie SSL może zostać nawiązane jedynie pomiędzy systemem
centralnym z włączonym SSL i systemem końcowym z włączonym SSL. Tomek musi skonfigurować uwierzytelnianie
serwera, zanim skonfiguruje uwierzytelnianie klienta.
Pojęcia pokrewne:
31
stronie 27
Navigator.
Czynność 1: konfigurowanie systemu centralnego pod kątem uwierzytelniania serwera:
Właściwości.
2. Kliknij zakładkę Ochrona, a następnie zaznacz opcję Używaj protokołu SSL.
3. Jako poziom uwierzytelniania wybierz Serwer.
Uwaga: NIE restartuj serwera Centrum Zarządzania, zanim zostaniesz o to poproszony. Jeśli serwer zostanie
zrestartowany w tej chwili, nie będzie można się połączyć z serwerami końcowymi. Aby zrestartować serwer w
celu włączenia SSL, konieczne jest wcześniejsze wykonanie określonych zadań konfiguracyjnych. W pierwszej
kolejności należy wykonać zadania porównania i aktualizacji, aby skonfigurować systemy końcowe pod kątem
SSL.
Czynność 2: konfigurowanie systemów końcowych pod kątem uwierzytelniania serwera:
Po skonfigurowaniu systemu centralnego pod kątem uwierzytelniania serwera Tomek musi skonfigurować w tym celu
również systemy końcowe. Należy wykonać następujące zadania:
1. Rozwiń Centrum Zarządzania (Management Central).
2. Porównaj i zaktualizuj wartości systemowe dla systemów końcowych:
a. W oknie Systemy końcowe kliknij prawym przyciskiem myszy system centralny i wybierz polecenie Zasoby >
Kolekcjonuj.
b. Zaznacz opcję Wartości systemowe w oknie dialogowym kolekcjonowania, aby gromadzić ustawienia
wartości systemowych w systemie centralnym. Usuń zaznaczenie wszystkich pozostałych opcji. Kliknij
przycisk OK i czekaj na zakończenie spisywania zasobów.
c. Kliknij prawym przyciskiem myszy opcję Grupy systemów > >Nowa grupa systemów.
d. Zdefiniuj nową grupę systemową zawierającą wszystkie systemy końcowe, z którymi będziesz się łączyć,
korzystając z SSL. Nadaj tej grupie nazwę Zaufana grupa.
e. Aby wyświetlić nową grupę (Zaufaną grupę), rozwiń grupy systemów.
f. Po zakończeniu zbierania informacji kliknij prawym przyciskiem myszy nową grupę systemów i wybierz
polecenie Wartości systemowe > Porównaj i zaktualizuj.
g. Sprawdź, czy system centralny jest wyświetlany w polu System modelowy.
h. W polu Kategoria zaznacz pozycję Centrum Zarządzania.
i. Sprawdź, czy dla opcji Użyj protokołu SSL ustawiona jest wartość Tak i wybierz polecenie Aktualizuj, aby
przesłać tę wartość do Zaufanej grupy.
j. Sprawdź, czy dla opcji Poziom uwierzytelniania SSL ustawiona jest wartość Serwer i wybierz polecenie
Aktualizuj, aby przesłać tę wartość do Zaufanej grupy.
Uwaga: Jeśli te wartości nie są ustawione, wykonaj Czynność 1: konfigurowanie systemu centralnego pod
kątem uwierzytelniania serwera .
k. Kliknij przycisk OK. Zanim przejdziesz do kolejnego etapu, poczekaj na zakończenie przetwarzania polecenia
Porównaj i zaktualizuj.
32
2. Rozwiń system centralny.
3. Rozwiń opcje Sieć > Serwery i wybierz pozycję TCP/IP.
Czynność 4: restartowanie systemu Centrum Zarządzania we wszystkich systemach końcowych:
2.
3.
4.
5.
6.
Rozwiń system końcowy, który chcesz zrestartować.
Rozwiń opcje Sieć > Serwery i wybierz pozycję TCP/IP.
Kliknij prawym przyciskiem myszy Centrum Zarządzania i wybierz Zatrzymaj.
Po zatrzymaniu serwera Centrum Zarządzania kliknij przycisk Uruchom, aby go zrestartować.
Powtórz procedurę dla każdego systemu końcowego.
Czynność 5: aktywowanie protokołu SSL dla klienta System i Navigator:
1.
2.
3.
4.
W programie System i Navigator rozwiń węzeł Moje połączenia.
Kliknij prawym przyciskiem myszy system centralny i wybierz Właściwości.
Kliknij zakładkę Protokół SSL i wybierz opcję Podczas połączenia używaj protokołu SSL.
Wyjdź z programu System i Navigator i zrestartuj go.
Uwaga: Po wykonaniu wszystkich czynności opisanych powyżej uwierzytelnianie serwera jest skonfigurowane dla
systemu centralnego i systemów końcowych. Opcjonalnie można także skonfigurować system centralny i systemy
końcowe pod kątem uwierzytelniania klientów. Aby umożliwić uwierzytelnianie klientów w systemie centralnym i
systemach końcowych, należy kolejno wykonać zadania opisane w punktach 6 - 10.
Czynność 6: konfigurowanie systemu centralnego pod kątem uwierzytelniania klientów:
Po zakończeniu konfiguracji pod kątem uwierzytelniania serwera Tomek może wykonać następujące opcjonalne
procedury uwierzytelniania klienta. Uwierzytelnianie klienta umożliwia sprawdzenie ośrodka certyfikacji i zaufanej
grupy dla systemów końcowych i systemu centralnego. Gdy system centralny (klient SSL) próbuje użyć SSL w celu
połączenia się z systemem końcowym (serwerem SSL), system centralny i system końcowy wzajemnie uwierzytelniają
swoje certyfikaty poprzez uwierzytelnianie serwera i uwierzytelnianie klienta. Taka operacja jest czasem nazywana
uwierzytelnianiem ośrodka certyfikacji i zaufanej grupy.
Uwaga: Konfiguracji uwierzytelniania klienta nie można zakończyć do momentu skonfigurowania uwierzytelniania
serwera. Jeśli jeszcze nie skonfigurowano uwierzytelniania serwera, należy to zrobić teraz.
Właściwości.
2. Kliknij zakładkę Ochrona i wybierz Używaj protokołu SSL.
3. Wybierz Klient i serwer w celu wybrania poziomu uwierzytelniania.
Uwaga: NIE restartuj serwera Centrum Zarządzania, zanim zostaniesz o to poproszony. Jeśli serwer zostanie
zrestartowany w tej chwili, nie będzie można się połączyć z serwerami końcowymi. Aby zrestartować serwer w
celu włączenia SSL, konieczne jest wcześniejsze wykonanie określonych zadań konfiguracyjnych. W pierwszej
kolejności należy wykonać zadania porównania i aktualizacji, aby skonfigurować systemy końcowe pod kątem
SSL.
Czynność 7: konfigurowanie systemów końcowych pod kątem uwierzytelniania klientów:
Porównaj i zaktualizuj wartości systemowe dla systemów końcowych:
1. Rozwiń Centrum Zarządzania (Management Central).
2. Porównaj i zaktualizuj wartości systemowe dla systemów końcowych:
33
a. W oknie Systemy końcowe kliknij prawym przyciskiem myszy system centralny i wybierz polecenie Zasoby >
Kolekcjonuj.
b. Zaznacz opcję Wartości systemowe w oknie dialogowym kolekcjonowania, aby gromadzić ustawienia
wartości systemowych w systemie centralnym. Usuń zaznaczenie wszystkich pozostałych opcji. Kliknij
przycisk OK i czekaj na zakończenie spisywania zasobów.
c. Po zakończeniu zbierania informacji kliknij prawym przyciskiem myszy Zaufaną grupę i wybierz polecenie
Wartości systemowe > Porównaj i zaktualizuj.
d. Sprawdź, czy system centralny jest wyświetlany w polu System modelowy.
e. W polu Kategoria zaznacz pozycję Centrum Zarządzania.
f. Sprawdź, czy dla opcji Użyj protokołu SSL ustawiona jest wartość Tak i wybierz polecenie Aktualizuj, aby
przesłać tę wartość do Zaufanej grupy.
g. Sprawdź, czy dla opcji Poziom uwierzytelniania SSL ustawiona jest wartość Klient i Serwer i wybierz
polecenie Aktualizuj aby przesłać tę wartość do Zaufanej grupy.
Uwaga: Jeśli te wartości nie są ustawione, wykonaj Czynność 6: skonfiguruj system centralny pod kątem
uwierzytelniania klientów.
h. Kliknij przycisk OK. Zanim przejdziesz do kolejnego etapu, poczekaj na zakończenie przetwarzania polecenia
Porównaj i zaktualizuj.
Czynność 8: kopiowanie listy sprawdzania do systemów końcowych:
Opisywana procedura zakłada, że na systemie centralnym działa system operacyjny IBM i w wersji V5R3 lub nowszej.
W systemie OS/400 w wersji V5R2 lub starszej obiekt QYPSVLDL.VLDL znajdował się w bibliotece QUSRSYS.LIB,
a nie QMGTC2.LIB. Dlatego w wersjach systemu starszych niż V5R3 konieczne będzie wysłanie listy sprawdzania do
tych systemów i umieszczenie jej w bibliotece QUSRSYS.LIB, zamiast w bibliotece QMGTC2.LIB. Jeśli korzystasz z
systemu w wersji V5R3 lub nowszej, przejdź do wykonywania następujących czynności:
1. W programie System i Navigator rozwiń węzły Centrum Zarządzania > Definicje.
2. Kliknij prawym przyciskiem myszy Pakiety i wybierz Nowa definicja.
3. W oknie Nowa definicja wypełnij następujące pola:
a. Nazwa: wpisz nazwę definicji.
b. System źródłowy: wybierz nazwę systemu centralnego.
c. Wybrane pliki i foldery: kliknij pole i wpisz /QSYS.LIB/QMGTC2.LIB/QYPSVLDL.VLDL.
4. Kliknij zakładkę Opcje i wybierz Zastępuj istniejące zbiory przysłanymi.
5. Kliknij Zaawansowane.
6.
W oknie Opcje zaawansowane wybierz opcję Tak, aby zezwolić na różnice w obiektach podczas odtwarzania i
zmień wartość pozycji Wersja docelowa na najwcześniejszą wersję systemów końcowych.
7. Kliknij OK, aby odświeżyć spis definicji i wyświetlić nowy pakiet.
8. Kliknij prawym przyciskiem myszy nowy pakiet i wybierz Wyślij.
9. W oknie dialogowym Wyślij rozwiń węzeł Grupy systemów->Zaufana grupa znajdujący się na liście Dostępne
systemy i grupy. Jest to jedna z grup, które zdefiniowano, wykonując “Czynność 2: konfigurowanie systemów
końcowych pod kątem uwierzytelniania serwera” na stronie 32.
Uwaga: Zadanie Wyślij nigdy nie powiedzie się w systemie centralnym, gdyż jest on zawsze systemem
źródłowym. Zadanie Wyślij powinno zakończyć się pomyślnie we wszystkich systemach końcowych.
10. Jeśli w Zaufanej grupie znajdują się jakiekolwiek serwery, na których działa system operacyjny IBM i w wersji
V5R3 lub starszej, należy na nich ręcznie przenieść obiekt QYPSVLDL.VLDL z biblioteki QMGTC2.LIB do
biblioteki QUSRSYS.LIB. Jeśli w bibliotece QUSRSYS.LIB znajduje się już jedna wersja obiektu
QYPSVLDL.VLDL, usuń ją i zastąp nowszą wersją z biblioteki QMGTC2.LIB
2. Rozwiń system centralny.
34
Czynność 10: restartowanie systemu Centrum Zarządzania we wszystkich systemach końcowych:
Uwaga: Powtórz procedurę dla każdego systemu końcowego.
2. Rozwiń system końcowy, który chcesz zrestartować.
4. Kliknij prawym przyciskiem myszy Centrum Zarządzania i wybierz Zatrzymaj.
Rozwiązywanie problemów z protokołem SSL
Ten temat zawiera podstawowe informacje, które mogą pomóc zmniejszyć liczbę potencjalnych problemów z
protokołem SSL na platformie IBM i.
Należy pamiętać, że w dział ten nie stanowi obszernego źródła informacji, gdyż jego zadaniem jest tylko pomoc w
rozwiązywaniu typowych problemów.
Sprawdź, czy zostały spełnione następujące warunki:
v spełnione są wymagania wstępne dotyczące protokołu SSL na platformie IBM i,
v ośrodek certyfikacji i certyfikaty są poprawne i nie wygasły.
Jeśli poprzednie stwierdzenia są prawdziwe w danym systemie i nadal występują problemy związane z protokołem
SSL, należy skorzystać z poniższych opcji:
v Kod błędu SSL w protokole zadania serwera może być odniesieniem w tabeli błędów umożliwiającym 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 (kreska przed numerem kodu) wskazuje, że używane są funkcje API SSL_.
– Dodatni kod powrotu wskazuje na użycie funkcji API GSKit. 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ą funkcji API i zapisują w protokole zadania komunikat zawierający to zdanie.
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. Dodatkowa dokumentacja
wyjaśniająca kody błędów może znajdować się w zwracających ten błąd konkretnych funkcjach API SSL.
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.
v Następujące pliki nagłówkowe zawierają takie same nazwy stałych dla kodów powrotu SSL jak tabela, ale bez
odniesienia do identyfikatora komunikatu:
– QSYSINC/H.GSKSSL
– QSYSINC/H.QSOSSL
Należy pamiętać, że wprawdzie nazwy kodów powrotu SSL pozostają stałe w obu plikach nagłówkowych, jednak
każdemu z tych kodów może być przypisany więcej niż jeden unikalny kod powrotu.
Pojęcia pokrewne:
35
Komunikaty z kodami błędów funkcji API gniazd chronionych
Informacje pokrewne dotyczące protokołu SSL
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"
Zawiera szczegółowe informacje na temat protokołu TLS w wersji 1.2.
(http://www.ietf.org/rfc/rfc5246.txt)
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.
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
36
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.
37
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:
38
© (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
39
40
Numer Programu: 5770-SS1

Protokół SSL (Secure Sockets Layer)

Transkrypt

Podobne dokumenty

Poradnik jak włączyć szyfrowanie SSL w systemie OS X

Jak sprawdzić swoją wersję systemu Windows? - Bankujesz

head premium ssl hybrid

Certyfikat SSL W zasadzie dla bezpiecznych połączeń

Ochrona danych osobowych Dane osobowe przekazywane nam

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

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

Wstęp. 1. Szyfrowanie danych zarys historyczny. 2. Matematyczne

Poradnik jak włączyć szyfrowanie SSL w kliencie poczty