Wiem, że TLS jest zasadniczo nowszą wersją SSL i że ogólnie obsługuje przejście z niezabezpieczonego na bezpieczne (zwykle za pomocą komendy STARTTLS).
Nie rozumiem tylko, dlaczego TLS jest ważny dla informatyków i dlaczego, biorąc pod uwagę wybór, wybrałbym jedną z nich. Czy TLS to naprawdę tylko nowsza wersja, a jeśli tak, to czy jest to zgodny protokół?
Jako specjalista IT: kiedy korzystać z którego? Kiedy nie korzystam z którego?
Krótka odpowiedź:
SSL jest prekursorem TLS. SSL był zastrzeżonym protokołem opracowanym przez Netscape Communications, później znormalizowanym w IETF i przemianowanym na TLS. Krótko mówiąc, wersje mają następującą kolejność: SSLv2, SSLv3, TLSv1.0, TLSv1.1 i TLSv1.2.
W przeciwieństwie do stosunkowo szerokiego przekonania, wcale nie chodzi o to, aby uruchomić usługę na odrębnym porcie z SSL i móc korzystać z tego samego portu, co wariant zwykłego tekstu z TLS. Zarówno SSL, jak i TLS mogą być używane dla obu metod. Chodzi o różnicę między SSL / TLS po połączeniu (czasami określanym jako „niejawny SSL / TLS”) a SSL / TLS po wydaniu polecenia na poziomie protokołu, zwykle STARTTLS(czasami nazywanym „jawnym SSL / TLS”) . Kluczowym słowem STARTTLSjest „START”, a nie TLS. Jest to komunikat, na poziomie protokołu aplikacji, wskazujący, że konieczne jest przejście na SSL / TLS, jeśli nie zostało zainicjowane przed wymianą protokołu aplikacji.
Korzystanie z obu trybów powinno być równoważne, pod warunkiem, że klient jest skonfigurowany tak, aby oczekiwał SSL / TLS w taki czy inny sposób, aby nie zostać obniżony do połączenia zwykłego tekstu.
Dłuższa odpowiedź:
O ile mi wiadomo, SSLv1 nigdy nie opuścił laboratoriów. SSLv2 i SSLv3 to protokoły opracowane przez Netscape. Przez pewien czas protokół SSLv2 był uważany za niebezpieczny, ponieważ jest podatny na ataki z niższej wersji. SSLv3 wewnętrznie używa (3,0)jako numeru wersji (w ClientHellokomunikacie).
TLS jest wynikiem standaryzacji jako bardziej otwartego protokołu w IETF. (Myślę, że gdzieś przeczytałem, być może w książce E. Rescorli, że nazwa została wybrana w taki sposób, że wszyscy uczestnicy byli równie niezadowoleni z niej, aby nie faworyzować konkretnej firmy: jest to dość powszechna praktyka w standardach ciało.) Osoby zainteresowane sposobem dokonania przejścia mogą przeczytać listę najczęściej zadawanych pytań dotyczących listy SSL ; istnieje wiele kopii tego dokumentu, ale większość linków (do ) jest nieaktualna.netscape.com
TLS używa bardzo podobnych komunikatów (wystarczająco różniących się, aby protokoły były niekompatybilne, chociaż możliwe jest wynegocjowanie wspólnej wersji ). Do TLS 1.0 , 1.1 i 1.2 ClientHello Komunikaty użyć (3,1), (3,2), (3,3)aby podać numer wersji, który wyraźnie pokazuje kontynuację z SSL.
W tej odpowiedzi znajduje się więcej szczegółów na temat różnic w protokole .
Kiedy korzystać z którego? Kiedy nie korzystam z którego?
Jeśli to możliwe, użyj najwyższej możliwej wersji. W praktyce jako dostawca usług będzie to wymagało od użytkowników posiadania klientów obsługujących te wersje. Jak zwykle zawsze jest to ocena ryzyka (najlepiej poparta uzasadnieniem biznesowym, jeśli to właściwe). To powiedziawszy, i tak odetnij SSLv2.
Ponadto należy pamiętać, że bezpieczeństwo zapewniane przez SSL / TLS nie dotyczy tylko używanej wersji, ale także właściwej konfiguracji: z pewnością lepiej jest używać SSLv3 z silnym pakietem szyfrów niż TLSv1.0 z słabym (lub pakiet szyfrów anonimowych / zerowych). Niektóre zestawy szyfrów, uważane za zbyt słabe, zostały wyraźnie zabronione przez nowsze wersje TLS. Tabele w dostawcy SunJSSE Java 7 (i ich przypisy) mogą być interesujące, jeśli chcesz uzyskać więcej szczegółów.
Lepiej byłoby używać przynajmniej TLS 1.1, ale nie wszyscy klienci jeszcze je obsługują (np. Java 6). Korzystając z wersji poniżej 1.1, z pewnością warto zminimalizować podatność BEAST .
Generalnie polecam książkę Erica Rescorli - SSL i TLS: Projektowanie i budowanie bezpiecznych systemów, Addison-Wesley, 2001 ISBN 0-201-61598-3 dla osób, które naprawdę chcą więcej szczegółów.
Istnieje mit mówiący, że TLS pozwala na korzystanie z tego samego portu, podczas gdy SSL nie. To po prostu nieprawda (i zostawię unifikację portów dla tej dyskusji). Niestety, mit ten zdaje się być rozpowszechniany wśród użytkowników przez fakt, że niektóre aplikacje, takie jak MS Outlook, czasami oferują wybór między SSL i TLS w opcjach konfiguracji, podczas gdy w rzeczywistości oznaczają wybór między niejawnym a jawnym SSL / TLS. (W Microsoft są eksperci od SSL / TLS, ale wygląda na to, że nie byli zaangażowani w interfejs użytkownika Outlooka.)
Myślę, że przyczyną tego zamieszania jest STARTTLStryb. Wydaje się, że niektórzy rozumieli to jako STARTTLS= TLS, ale tak nie jest. Kluczowym słowem STARTTLSjest „START”, a nie TLS. Dlaczego nie zostało to wywołane STARTSSLlub STARTSSLORTLSdlatego, że te rozszerzenia zostały określone w IETF, który używał tylko nazw użytych w jego specyfikacjach (zakładając, że nazwa TLS ostatecznie będzie jedyną stałą, jak sądzę).
Obecnie większość serwerów HTTPS może obsługiwać TLS, ale kilka lat temu większość ludzi używała SSLv3 do HTTPS. HTTPS (ściśle mówiąc, znormalizowany jako HTTP przez TLS ) zwykle ustanawia połączenie SSL / TLS po połączeniu TCP, a następnie wymienia komunikat HTTP przez warstwę SSL / TLS. Istnieje wyjątek od tego, gdy używa się pośredniczącego serwera proxy HTTP. W takim przypadku klient łączy się z serwerem proxy HTTP w sposób wyraźny (zwykle na porcie 3128), a następnie wydaje CONNECTpolecenie HTTP i, pod warunkiem, że odpowiedź się powiodła, inicjuje uzgadnianie SSL / TLS, wysyłając polecenieClientHellowiadomość. Wszystko to dzieje się na tym samym porcie, jeśli chodzi o połączenie między przeglądarką a serwerem proxy (oczywiście nie między serwerem proxy a serwerem docelowym: nie jest to nawet ten sam komputer). Działa to dobrze z SSLv3. Wielu z nas w sytuacjach za serwerem proxy użyłoby tego przeciwko serwerom, które nie obsługiwały co najmniej TLS 1.0.
Ten jest wyraźnie niezgodny ze specyfikacjami, ale w praktyce często działa. Ściśle mówiąc, specyfikacje mówią o przejściu na TLS (nie SSL) po użyciu komendy STARTTLS. W praktyce często też działa protokół SSL (podobnie jak specyfikacja „HTTP przez TLS” obejmuje również używanie protokołu SSL zamiast protokołu TLS). Możesz spróbować sam. Zakładając, że masz serwer SMTP lub IMAP, który obsługuje STARTTLS, użyj Thunderbirda, przejdź do preferencji, opcji zaawansowanych, edytora konfiguracji i wyłącz security.enable_tls. Wiele serwerów nadal akceptuje połączenie, po prostu dlatego, że ich implementacje delegują warstwę SSL / TLS do biblioteki SSL / TLS, która ogólnie będzie w stanie obsługiwać SSL i TLS w ten sam sposób, chyba że skonfigurowano inaczej. Jak ujmuje to OpenLDAP FAQ , „Chociaż mechanizm jest przeznaczony do użytku z TLSv1, większość implementacji w razie potrzeby zastąpi SSLv3 (i SSLv2). ". Jeśli nie jesteś pewien, sprawdź za pomocą narzędzia takiego jak Wireshark.
Wielu klientów może używać TLS 1.0 (przynajmniej) dla protokołów, w których zabezpieczony wariant znajduje się na innym porcie. Oczywiście istnieje wiele przeglądarek i serwerów internetowych, które obsługują TLS 1.0 (lub nowszy) dla HTTPS. Podobnie, SMTPS, IMAPS, POPS i LDAPS mogą również korzystać z TLS. Nie są ograniczone do SSL.
Kiedy korzystać z którego? Kiedy nie korzystam z którego?
Między jawnym a niejawnym SSL / TLS tak naprawdę nie ma to znaczenia. Liczy się to, że klient wie, czego się spodziewać i jest odpowiednio skonfigurowany. Co ważniejsze, należy go skonfigurować tak, aby odrzucał połączenia zwykłego tekstu, gdy oczekuje połączenia SSL / TLS, bez względu na to, czy jest ono niejawne czy jawne .
Główna różnica między jawnym i niejawnym protokołem SSL / TLS polega na przejrzystości ustawień konfiguracji.
Na przykład w przypadku LDAP, jeśli klient jest serwerem Apache Httpd ( mod_ldap- jego dokumentacja również błędnie znakuje różnicę między SSL a TLS, niestety), możesz użyć niejawnego SSL / TLS, używając ldaps://adresu URL (np. AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one) Lub jawnego SSL / TLS przy użyciu dodatkowego parametru (np AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS.).
Nie ma chyba generalnie nieco mniejsze ryzyko przy określaniu protokół zabezpieczeń w systemie URL ( https, ldaps...), niż gdy spodziewa klienta, aby skonfigurować dodatkowe ustawienia, aby włączyć SSL / TLS, ponieważ mogą oni zapomnieć. To jest dyskusyjne. Mogą również występować problemy z poprawnością implementacji jednego z drugim (na przykład, myślę, że klient Java LDAP nie obsługuje weryfikacji nazwy hosta podczas używania ldaps://, kiedy powinien, podczas gdy jest obsługiwany z ldap://+ StartTLS).
Wątpliwości i, jeśli to możliwe, kompatybilność z większą liczbą klientów, nie szkodzi oferowaniu obu usług, gdy serwer je obsługuje (serwer będzie nasłuchiwał na dwóch portach jednocześnie). Wiele implementacji serwerów dla protokołów, które mogą być używane w obu trybach, będzie obsługiwać oba.
Obowiązkiem klienta jest, aby nie zostać obniżonym do połączenia zwykłego tekstu. Jako administrator serwera nic nie możesz technicznie zrobić po swojej stronie, aby zapobiec atakom na niższą wersję (poza wymaganiem być może certyfikatu klienta). Klient musi sprawdzić, czy protokół SSL / TLS jest włączony, niezależnie od tego, czy jest to połączenie, czy STARTTLSpolecenie podobne. W taki sam sposób, jak przeglądarka nie powinien dać się przekierowany od https://celu http://, dla klienta protokołu, że wsparcie STARTTLS
powinno mieć pewność, odpowiedź była pozytywna i SSL / TLS połączenia była włączona przed przejściem dalej. Aktywny atakujący MITM mógłby w przeciwnym razie łatwo obniżyć jakość obu połączeń.
Na przykład starsze wersje Thunderbirda miały złą opcję o nazwie „Użyj TLS, jeśli jest dostępna” , co zasadniczo sugerowało, że jeśli osoba atakująca MITM mogłaby zmienić komunikaty serwera, aby nie reklamowała obsługi STARTTLS, klient po cichu dałoby się obniżyć do połączenia zwykłego tekstu. (Ta niepewna opcja nie jest już dostępna w Thunderbird.)
TLS to nowszy protokół niż SSL (ale AFAIK, jest zgodny z SSL v3). Zwykle jest tylko jedna różnica, o którą musisz się martwić:
Protokół SSL ma zwykle osobny port - na przykład 80 dla HTTP i 443 dla HTTPS (HTTP / SSL). Po połączeniu z portem SSL cała sesja jest szyfrowana.
TLS jest nowszy niż SSL i nie wymaga oddzielnego portu - zamiast tego musi być negocjowany przez klienta. Na przykład możesz uruchomić IMAP na porcie 143, a jeśli zarówno serwer pocztowy, jak i klient obsługują TLS, klient wyśle
STARTTLSpolecenie, a dopiero potem włączy szyfrowanie. W ten sposób nie potrzebujesz osobnego portu tylko dla SSL, pozostając kompatybilnym z aplikacjami bez SSL.Podsumowanie:
SSL : nieco starszy. Oddzielne porty dla połączeń zwykłych i szyfrowanych. Cały ruch na porcie SSL jest zawsze szyfrowany.
TLS : Pojedynczy port dla połączeń zwykłych i szyfrowanych. Szyfrowanie jest włączane tylko po wydaniu
STARTTLSpolecenia przez klienta .źródło
STARTTLSz niektórych protokołów umożliwia przełączanie na TLS na tym samym połączeniu, nie stanowi różnicy między SSL a TLS. Technicznie możesz przejść na SSLv3 w ten sam sposób.TLS to po prostu nowsza wersja SSL. Użyj TLS, jeśli masz taką opcję. Więcej, jak zwykle, na Wikipedii .
źródło
Z tego artykułu z bazy wiedzy Uniwersytetu Indiana :
źródło
TLS to nowsza wersja protokołu SSL. Chociaż w niektórych miejscach słowa te mogą oznaczać coś innego niż tylko protokoły, prosimy o wyjaśnienie pytania.
źródło