r08 05

[ Pobierz całość w formacie PDF ]
.llPrzeglądarka używa klucza publicznego serwera, by sprawdzić, czy osoba podpisująca klucz jest w jego posiadaniu.llPrzeglądarka upewnia się, czy zaufane centrum certyfikacji podpisało klucz.Jeśli nie, przeglądarka pyta użytkownika, czy klucz można uznać za wiarygodny i postępuje zgodnie z jego zaleceniami.llKlient generuje dla tej sesji klucz symetryczny DES, koduje publicznym kluczem serwera i odsyła serwerowi.Powstały w ten sposób nowy klucz jest użyty do zakodowania transakcji.Klucz symetryczny jest używany dlatego, że systemy oparte o klucze asymetryczne bardzo obciążają system.lWszystkie opisane tu procedury są niewidoczne dla twórców serwerów i serwletów.Należy po prostu otrzymać odpowiedni certyfikat serwerowy, zainstalować go i odpowiednio skonfigurować serwer.Informacje przesyłane pomiędzy serwletami i klientami będą od tej pory zakodowane.Uwierzytelnianie klienta za pomocą SSLNasza skrzynka z narzędziami zabezpieczającymi zawiera już solidne systemy kodowania i uwierzytelnienia serwera, ale słaby system uwierzytelniania klienta.Oczywiście użycie SSL 2.0 stawia nas w dużo lepszej sytuacji.Serwery wyposażone w SSL mogą jednocześnie używać podstawowych metod uwierzytelniania omówionych na początku niniejszego rozdziału, ponieważ nie ma możliwości przechwycenia informacji.Nadal jednak nie mamy dowodu na wiarygodność klienta, bo każdy mógłby zgadnąć lub zawładnąć hasłem i nazwą użytkownika.Powyższy problem rozwiązano w nowszej wersji SSL 3.0 poprzez zapewnienie obsługi certyfikatów klienckich.Te certyfikaty są zarejestrowane jako klienckie, ale niczym nie różnią się od serwerowych.SSL 3.0 z uwierzytelnieniem klienckim pracuje podobnie do SSL 2.0, ale po uwierzytelnieniu serwera przez klienta, serwer żąda od niego certyfikatu.Klient przesyła podpisany certyfikat i serwer przeprowadza taką samą procedurę uwierzytelniającą, jaka odbyła się po stronie klienta (serwer porównuje certyfikat klienta z biblioteką istniejących certyfikatów lub przechowuje certyfikat, aby zweryfikować użytkownika przy kolejnej wizycie).Wiele przeglądarek zanim wyśle certyfikat, jako zabezpieczenie, wymaga podania hasła przez użytkownika.Klientowi raz uwierzytelnionemu serwer udostępni chronione zasoby (serwlety lub pliki) tak, jak za pomocą uwierzytelnienia HTTP.Cały proces przebiega w sposób niewidoczny dla użytkownika.Ponadto ten sposób dostarcza dodatkowy poziom uwierzytelnienia, bo serwer wie, że klient posługujący się certyfikatem Jasia Kowalskiego jest w istocie Jasiem Kowalskim (w dodatku może rozpoznać konkretnego Jasia Kowalskiego poprzez jego unikatowy certyfikat).Wadami certyfikatów klienckich jest konieczność ich otrzymania i instalacji przez użytkowników.Ponadto serwery muszą zawierać bazę danych z kluczami publicznymi, a przede wszystkim obsługiwać SSL 3.Konfigurowanie ochrony za pomocą SSLAplikacja sieciowa, która wymaga ochrony za pomocą SSL (HTTPS) może o tym powiadomić serwer przy użyciu deskryptora rozmieszczenia.Wymaganie SSL modyfikuje plik web.xml w ten sposób, że znacznik <security-constraint> zawiera znacznik <user-data-constraint> wskazujący wymagania dotyczące systemu zabezpieczeń.Przykład 8.12 przedstawia ten plik.Przykład 8.12.Ta kolekcja wymaga bezpiecznego połączenia<security-constraint><web-resource-collection><web-resource-name>SecretProtection</web-resource-name><url-pattern>/servlet/SalaryServer</url-pattern><url-pattern>/servlet/secret</url-pattern><url-method>GET</url-method><url-method>POST</url-method></web-resource-collection><auth-constraint><role-name>manager</role-name></auth-constraint><user-data-constraint><transport-guarantee>CONFIDENTIAL</transport-guarantee></user-data-constraint></security-constraint><!--.itp [ Pobierz całość w formacie PDF ]

Linki