DYSKUSJA ARCHIWALNA:

Andrzej J. Majewski
--------------------------------------------

Protokół SSL zapewnia bezpieczeństwo sesji w relacji end-to-end, czyli od biurka do serwera. Otwarty charakter interfejsu SSL umożliwia integrację protokołu z aplikacjami np. przeglądarkami WWW. SSL może także tworzyć niezależną od aplikacji "warstwę", umieszczoną pomiędzy transportem i warstwą sesji, na której można w przeźroczysty sposób osadzić protokoły aplikacyjne np. HTTP, FTP, Telnet, SMTP. Wstawka (plug-in) SSL może wynegocjować algorytm szyfrowania, klucz sesyjny oraz dokonać uwierzytelnienia klienta i serwera, zanim protokół aplikacyjny prześle pierwszy bajt informacji. Wszystkie protokoły aplikacyjne, osadzone na warstwie SSL mogą korzystać z szyfrowanego kanału, gwarantując prywatność.
Posiadanie serwera WWW z zaimplementowaną 128-bitową wersją SSL, nie jest jednak gwarancją (!) uzyskania bezpiecznego połączenia z każdym klientem - przeglądarką WWW. Dodatkowo, należy bezwzględnie pamiętać, że SSL zapewnia bezpieczny, szyfrowany kanał transmisji danych i uwierzytelnienie serwera. Są to elementy bezpiecznej sesji WWW. SSL nie zapewnia żadnej ochrony danych, rezydujących w środowisku serwera i przeglądarki. Ochrona zasobów należy do niezależnych obowiązków dysponentów informacji przekazywanej tą drogą. Uwierzytelnienie serwera, jako mechanizm wbudowany w protokół SSL, gwarantuje informację z kim jesteśmy połączeni, o ile sprawdzimy certyfikat korespondenta, ale o zaufaniu do drugiej strony nie decyduje. Opcjonalne uwierzytelnienie klienta, oferowane przez protokół SSL, jest drogą, którą serwer może rozstrzygać, czy udostępnić wrażliwą informację. Aby można jej było użyć, klienci muszą zaopatrzyć się w akceptowane przez serwer certyfikaty.
Centrum Certyfikacji Kluczy Publicznych (CA) może być produktem - system sprzętowo-programowy lub usługą realizowaną zewnętrznie. W każdym przypadku krytycznymi elementami CA są poziom zaufania do wydawanych certyfikatów oraz poziom bezpieczeństwa kluczy prywatnych CA.
Główne CA (root CA) podpisuje swój klucz publiczny samodzielnie (self-certificate), ponieważ nie ma jednostki nadrzędnej. Z tego powodu, zaufanie do jego klucza publicznego jest tak krytycznym elementem. Opublikowanie samego klucza i jego identyfikatora w wielu mediach (sieć, prasa, biuletyny specjalistyczne) pozwala wzbudzić zaufanie także wśród „paranoicznie” nastawionych oportunistów. Konieczne jest podjęcie wszelkich działań, mających na celu zabezpieczenie klucza prywatnego głównego CA.
W internetowych usługach handlowo-rozliczeniowych spotykane są oba modele realizacji CA - jako własne przedsięwzięcie - element PKI instytucji handlowej, finansowej lub banku, regionalne /narodowe CA - element infrastruktury kluczy publicznych (PKI) państwa lub społeczności internetowej. O wyborze modelu decydują względy ekonomiczne - CA jest najbardziej kapitałochłonnym elementem PKI. Na drugiej szali wagi spoczywa zaufanie, jakim przedsiębiorstwo musi obdarzyć zewnętrzną instytucję, której poręczenie ma wymierny skutek, w transakcjach finansowych jego klientów.

Należy pamiętać, że certyfikaty kluczy publicznych, wytwarzane przez CA, stanowią wyłącznie potwierdzenie relacji pomiędzy kluczem publicznym i jego identyfikatorem. Żadną miarą nie mogą być traktowane jako certyfikaty wiarygodności treści prezentowanych przez posiadaczy certyfikatów, a tym samym jako potwierdzenie tożsamości ich właścicieli.

Certyfikat klucza to nie to samo co certyfikat handlowy, wypis z rejestru handlowego czy potwierdzenie notarialne. Zaufanie do certyfikatu nie może i nie powinno być wyłącznie konsekwencją faktu istnienia i otrzymania takiego certyfikatu.

Spore zamieszanie wśród wielu użytkowników Internetu wywołują certyfikaty wbudowane do przeglądarek np. VeriSign, Thawte, GTE, . Są bezkrytycznie deklarowane i niestety przyjmowane jako podstawa do zbudowania zaufania w Sieci. Tym czasem są to certyfikaty miejsc, o których wiadomo tyle, że ufał im producent oprogramowania. Ani Microsoft Corp. ani Netscape Communications Corp. nie są jednak nieomylne.
O tym, czy wbudowanym certyfikatom winien zaufać użytkownik przeglądarki, powinna zadecydować analiza dokumentów CA: Polityka Certyfikacji (ang. Certification Policy - CP) i Kodeks Certyfikacji (ang. Certification Practice Statement - CPS). To z tych dokumentów wynika, czy sposób rejestracji, wytworzenia certyfikatu, jego obsługi, zakres obowiązków, gwarancji i zobowiązań instytucji certyfikującej jest właściwy do biznesu, w którym certyfikat ma być użyty, czy jest niewystarczający w jakimkolwiek aspekcie. W praktyce okazuje się, że pojawienie się na ikony bezpiecznego połączenia, na stronie przeglądanego serwisu, winno zdaniem właścicieli serwera, zaspokoić oczekiwania co do autentyczności i poufności. Domyślne zaufanie do certyfikatów wbudowanych, jest w myśl normalnych reguł biznesowych, niebezpieczną nadinterpretacją określenia „zaufany”.

To czego w takiej sytuacji można być pewnym, to tylko tyle, że połączenie jest realizowane przez szyfrowany kanał, z serwerem, który posiada certyfikat od znanego CA. Czy jest to miejsce godne zaufania, użytkownik winien zadecydować sam, w oparciu o własne kryteria. Opis lokalizacji zawarty w opisie certyfikatu może być pomocny jako jedna z informacji identyfikujących, ale nie powinien być przyjmowany bezkrytycznie jako wiarygodny, bez porównania z podobnym opisem z innych źródeł, np. dokumentów handlowych. W przeciwnym razie, możemy obdarzyć zaufaniem dobrze zakamuflowanych oszustów, powierzając im nasze poufne informacje.

_________________
Z poważaniem,
Andrzej J. Majewski
Konsultant i Rzeczoznawca PTI
ds. systemów Public Key Infrastructure Czytaj na Forum Merytorium.pl