Według Wikipedii: http://en.wikipedia.org/wiki/Transport_Layer_Security
Wygląda na to, że TLS zastępuje SSL, ale większość witryn nadal korzysta z SSL?
Według Wikipedii: http://en.wikipedia.org/wiki/Transport_Layer_Security
Wygląda na to, że TLS zastępuje SSL, ale większość witryn nadal korzysta z SSL?
Odpowiedzi:
Krótko mówiąc, TLSv1.0 to mniej więcej SSLv3.1. Więcej szczegółów w tym pytaniu można znaleźć w witrynie ServerFault .
Większość stron internetowych faktycznie obsługuje co najmniej SSLv3 i TLSv1.0, jak wskazuje to badanie (artykuł Lee, Malkin i Nahuma: Cryptographic Strength of SSL / TLS Servers: Current and Recent Practices , IMC 2007) (link uzyskany z listy IETF TLS ). Ponad 98% obsługuje TLSv1 +.
Myślę, że powodem, dla którego SSLv3 jest nadal używany, była obsługa starszych wersji (chociaż większość przeglądarek obsługuje obecnie TLSv1 i niektóre TLSv1.1, a nawet TLSv1.2). Jeszcze nie tak dawno niektóre dystrybucje nadal miały domyślnie włączony SSLv2 (uważany za niezabezpieczony) wraz z innymi.
(Możesz również uznać to pytanie za interesujące, chociaż dotyczy ono wzorca użycia TLS zamiast SSL w porównaniu z TLS (w rzeczywistości możesz mieć ten sam wzorzec z SSL). Nie dotyczy to i tak HTTPS, ponieważ HTTPS używa SSL / TLS od początku połączenia.)
Od http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/
We wczesnych latach 90-tych, u zarania World Wide Web, niektórzy inżynierowie w firmie Netscape opracowali protokół do wykonywania bezpiecznych żądań HTTP, a to, co wymyślili, nazywało się SSL. Biorąc pod uwagę stosunkowo niewielką ilość wiedzy na temat bezpiecznych protokołów w tamtym czasie, a także ogromną presję , pod jaką pracowali wszyscy w Netscape, ich wysiłki można postrzegać jedynie jako niewiarygodnie heroiczne. To niesamowite, że SSL przetrwał tak długo, jak ma, w przeciwieństwie do wielu innych protokołów z tego samego rocznika. Jednak od tamtego czasu na pewno wiele się nauczyliśmy, ale w protokołach i interfejsach API bardzo niewiele się dzieje.
Były dwie główne aktualizacje protokołu SSL, SSL 2 (1995) i SSL 3 (1996). Zostały one starannie wykonane, aby były kompatybilne wstecz, aby ułatwić adopcję. Jednak zgodność wsteczna jest ograniczeniem dla protokołu bezpieczeństwa, dla którego może oznaczać podatność wsteczną.
Dlatego zdecydowano się przełamać kompatybilność wsteczną i nowy protokół nazwany TLS 1.0 (1999). (Z perspektywy czasu łatwiej byłoby nazwać to TLS 4)
Różnice między tym protokołem a SSL 3.0 nie są dramatyczne, ale są na tyle istotne, że protokoły TLS 1.0 i SSL 3.0 nie współpracują.
TLS został poprawiony dwukrotnie, TLS 1.1 (2006) i TLS 1.2 (2008).
Od 2015 roku wszystkie wersje SSL są zepsute i niezabezpieczone (atak POODLE), a przeglądarki usuwają wsparcie. TLS 1.0 jest wszechobecny, ale tylko 60% witryn obsługuje TLS 1.1 i 1.2 , niestety .
Jeśli jesteś zainteresowany tymi rzeczami, polecam sprytną i zabawną rozmowę Moxie Marlinspike na https://www.youtube.com/watch?v=Z7Wl2FW2TcA
TLS zachowuje wsteczną kompatybilność z SSL, dlatego protokół komunikacyjny jest prawie identyczny w każdej z wymienionych tutaj wersji. Dwie ważne różnice między SSL v.3, TLS 1.0 i TLS 1.2 to funkcja pseudolosowa (PRF) i funkcja mieszająca HMAC (SHA, MD5, handshake), która służy do konstruowania bloku kluczy symetrycznych dla Szyfrowanie danych aplikacji (klucze serwera + klucze klienta + IV). Główna różnica między TLS 1.1 i TLS 1.2 polega na tym, że 1.2 wymaga użycia „jawnego” IV w celu ochrony przed atakami CBC, chociaż nie są do tego potrzebne żadne zmiany w PRF ani protokole. TLS 1.2 PRF jest specyficzny dla zestawu szyfrów, co oznacza, że PRF może być negocjowany podczas uzgadniania. SSL został pierwotnie opracowany przez Netscape Communications (historyczny), a później utrzymywany przez Internet Engineering Task Force (IETF, obecnie). Protokół TLS jest obsługiwany przez grupę roboczą sieci. Oto różnica między funkcjami PRF HMAC w TLS:
TLS 1.0 i 1.1
PRF (sekret, etykieta, ziarno) = P_MD5 (S1, etykieta + ziarno) XOR P_SHA-1 (S2, etykieta + ziarno);
TLS 1.2
PRF (sekret, etykieta, ziarno) = P_hash (sekret, etykieta + ziarno)
„Jeśli nie jest uszkodzony, nie dotykaj go”. SSL3 działa dobrze w większości scenariuszy (w październiku znaleziono fundamentalną lukę w protokole SSL / TLS, ale jest to wada aplikacji bardziej niż sam procol), więc programiści nie spieszą się z aktualizacją swoich modułów SSL. TLS oferuje wiele przydatnych rozszerzeń i algorytmów bezpieczeństwa, ale są one przydatnym dodatkiem i nie są koniecznością. Dlatego TLS na większości serwerów pozostaje opcją. Jeśli obsługują go zarówno serwer, jak i klient, zostanie on użyty.
Aktualizacja: w 2016 roku SSL 3, a nawet TLS do 1.2 okazały się podatne na różne ataki i zalecana jest migracja do TLS 1.2. Istnieją również ataki na implementacje TLS 1.2, chociaż są one zależne od serwera. Protokół TLS 1.3 jest obecnie w fazie rozwoju. A teraz TLS 1.2 jest koniecznością.
https://hpbn.co/transport-layer-security-tls/ to dobre wprowadzenie
Protokół SSL został pierwotnie opracowany w firmie Netscape w celu zapewnienia bezpieczeństwa transakcji e-commerce w Internecie, co wymagało szyfrowania w celu ochrony danych osobowych klientów, a także gwarancji uwierzytelniania i integralności w celu zapewnienia bezpiecznej transakcji. Aby to osiągnąć, protokół SSL został zaimplementowany w warstwie aplikacji, bezpośrednio na szczycie TCP (Rysunek 4-1), umożliwiając protokołom nad nim (HTTP, e-mail, komunikatory i wiele innych) działanie bez zmian, zapewniając jednocześnie bezpieczeństwo komunikacji, gdy komunikowanie się w sieci.
Gdy protokół SSL jest używany prawidłowo, obserwator będący stroną trzecią może jedynie wywnioskować punkty końcowe połączenia, typ szyfrowania, a także częstotliwość i przybliżoną ilość wysyłanych danych, ale nie może odczytać ani zmodyfikować żadnych rzeczywistych danych.
SSL 2.0 był pierwszą publicznie udostępnioną wersją protokołu, ale został szybko zastąpiony przez SSL 3.0 ze względu na wiele wykrytych luk w zabezpieczeniach. Ponieważ protokół SSL był własnością firmy Netscape, IETF podjął próbę jego standaryzacji, w wyniku czego powstał dokument RFC 2246, który został opublikowany w styczniu 1999 r. I stał się znany jako TLS 1.0. Od tego czasu IETF kontynuuje iterację protokołu w celu usunięcia luk w zabezpieczeniach, a także rozszerzenia jego możliwości: TLS 1.1 (RFC 2246) został opublikowany w kwietniu 2006 r., TLS 1.2 (RFC 5246) w sierpniu 2008 r., A prace są obecnie w trakcie tworzenia definicji TLS 1.3.