Trzy podstawowe rady:
nobody
)
Subject: Sposoby bezpiecznego przesyłu danych From: Paweł Krawczyk <kravietz@tau.ceti.com.pl> Date: Sun Jun 15 16:01:19 MET DST 1997 Date: Date: Mon, 23 Jun 1997 15:46:33 +0200 (MET DST)
SSL (Secure Socket Layer)---protokół bezpiecznej komunikacji między
klientem a serwerem, stworzony przez Netscape. SSL w założeniu jest podkładką
pod istniejące protokoły, takie jak HTTP, FTP, SMTP, NNTP i telnet.
Powszechnie jest używane głównie HTTPS (HTTP na SSL). SSL zapewnia trzy
rzeczy:
Ze względu na sposób dokonywania autoryzacji SSL jest protokołem
scentralizowanym, inaczej niż np. PGP. Jest on oparty o grupę
instytucji certyfikujących (Certyfing Authorities, w skrócie
CA),
które opatrują swoim podpisem certyfikaty poszczególnych serwerów.
CA z założenia są godni zaufania, a uzyskanie podpisu
wymaga przedstawienia szeregu dowodów tożsamości. W ten sposób
wchodząc na serwer legitymujący się certyfikatem jednego ze znanych
CA mamy pewność że serwer rzeczywiście jest tym za który się podaje.
SSL przewiduje użycie trzech rodzaje certyfikatów:
W tej chwili istnieją dwie specyfikacje SSL:
Wersja 3.0 ma poprawione wiele słabości SSL 2.0 oraz umożliwia kompresję danych. SSL 3.0 jest wstecznie kompatybilne z 2.0.
Podając w URLu protokół https. Na przykład:
https://www.verisign.com/
Z najpopularniejszych: Netscape, MSIE i Lynx.
Niestety amerykańskie prawo nakłada ograniczenia (ITAR) na eksport programów zawierających zaawansowane algorytmy kryptograficzne, wobec czego Netscape i MSIE są rozpowszechniane w dwóch wersjach: eksportowej (klucz 40-to bitowy) i amerykańskiej (128-mio bitowy). Ostatnimi czasy klucze 40-bitowe kilkukrotnie łamano dla wykazania niesłuszności ITAR i nie można ich uznać za bezpieczne.
Oficjalnie wersji 128-mio bitowych nie wolno eksportować ze Stanów, ale oczywiście już dawno zostało to zrobione i można je sobie ściągnąć z Europy. Inne rozwiązanie to użycie programu SafePassage http://stronghold.ukweb.com/safepassage/ , który działa jako serwer proxy i pozwala korzystać z 128-bitowego SSL nawet eksportowym wersjom przeglądarek.
Lynx-SSL (oparty o wersję 2.7) używa kluczy 128-mio bitowych. Obsługa SSL w Lynxie jest w tej chwili bardzo ograniczona (brak zarządzania certyfikatami lub jakiejkolwiek konfiguracji SSL), ale działa poprawnie.
Jest jeszcze jeden program z kluczem 128-mio bitowym---WorkHorse (pod MS Windows), przeznaczony z założenia do home-bankingu. Z tego powodu ma słabo rozbudowane wodotryski i obsługę HTMLa, za to bardzo bogate funkcje zabezpieczania transakcji (PGP, PEM, ECheque, SSL) i inne, równie interesujące.
Wszystkie wymienione programy można ściągnąć z ftp://ftp.replay.com/pub/replay/pub/browsers/ (Holandia) lub z polskiego mirrora ftp://pipeta.chemia.pk.edu.pl/pub/replay/browsers/.
Trzeba uruchomić serwer WWW z wbudowaną obsługą SSL, wygenerować dla niego certyfikat, a następnie zapłacić za podpisanie tego certyfikatu jednemu z Certifying Authorities.
Najpopularniejsze serwery obsługujące SSL to:
Autor tego opracowania z powodzeniem wykorzystuje na firmowym WWW serwer
Apache-SSL. W tym wypadku oprócz samego serwera potrzebne jest także
zaplecze w postaci SSLeay.
Decydując się na komercyjny serwer należy się dokładnie dowiedzieć czy nie jest on objęty ograniczeniami eksportowymi, żeby nie kupić kota w worku (czyli serwera obsługującego klucze max 40-to bitowe).
SSLeay jest zestawem programów i bibliotek stanowiących implementację procedur SSL 2.0 (wersje do 0.6.x) i SSL 3.0 (wersje nowsze niż 0.8.x). SSLeay służy do generowania oraz zarządzania kluczami i certyfikatami, pozwala także na podpisywanie certyfikatów (ma funkcje CA). Z SSLeay korzysta m.in. Apache-SSL.
Najbardziej godne polecenia opisy SSLeay:
Nie. Taka jest konsekwencja centralnego zarządzania certyfikatami w SSL. Certyfikat autoryzowany na podstawie przedstawionych przez jego posiadacza dokumentów i innych dowodów tożsamości jest naturalnie bardziej godny zaufania niż wygenerowany samodzielnie przez administratora serwera.
Różne przeglądarki zachowują się różnie po wejściu na serwer legitymujący się certyfikatem podpisanym przez nieznanego CA:
application/x-x509-ca-cert.
Sposób jego generowania i udostępniania przeglądarkom
jest opisany w
opisie TAMU.
Instytucje podpisujące certyfikaty serwerów oraz wydające certyfikaty osobiste różnią się przede wszystkim regulaminem (rodzaj serwera, wymagane dokumenty) i ceną.
Najpopularniejszym---i jednym z najdroższych CA---jest VeriSign http://www.verisign.com/ . Jego certyfikaty akceptują wszystkie wersje Netscape i MSIE.
Innym popularnym CA jest firma Thawte Consulting http://www.thawte.com/ , która bierze za to 100 USD i jej certyfikaty są rozpoznawane przez wszystkie przeglądarki. Thawte certyfikuje także Apache-SSL.
Poza tym:
Istniejące propozycje można podzielić na dwa rodzaje: protokoły warstwy transportowej (SSL, PCT) i warstwy aplikacyjnej (Shen, S-HTTP). Pierwsze z nich działają tuż nad warstwą TCP/IP i mogą służyć do przenoszenia różnych protokołów wyższych warstw---FTP, POP3, SMTP oraz HTTP. Nic nie stoi także na przeszkodzie, by np. protokół S-HTTP działał na połączeniu zabezpieczonym przez SSL. Kwestie bezpiecznych protokołów WWW wyjaśnia dobrze artykuł The Race to Secure Cyberspace http://www.webdeveloper.com/categories/security/security_race_cyberspace.html Dano Garsona
Teoretycznie w Javę http://www.javasoft.com/ (podobnie jak w ActiveX http://www.ActiveX.com/ wbudowane są mechanizmy ograniczające możliwości destabilizacji pracy systemu. Jednak nie ma oprogramowania bez błędów. Więc najlepiej (na codzień) wyłączyć we własnej przeglądarce możliwość interpretowania obiektów JAVY i ActiveX
Patrz też:
Patrz też:
Patrz też: