Transport Layer Security: Różnice pomiędzy wersjami

'''TLS''' ([[język angielski|ang.]] '''''T'''ransport '''L'''ayer '''S'''ecurity'') – przyjęte jako standard w [[Internet|Internecie]] rozwinięcie [[protokoły internetowe|protokołu]] '''SSL''' (ang. '''''S'''ecure '''S'''ocket '''L'''ayer''), wzaprojektowanego swojej pierwotnej wersji zaprojektowanegopierwotnie przez firmę [[Netscape Communications Corporation]]. TLS mazapewnia na celu zapewnienie poufnościpoufność i integralnościintegralność transmisji danych, oraza zapewnienietakże [[Uwierzytelnianie|uwierzytelnieniauwierzytelnienie]] [[Klient-serwer|serwera]], opieraa niekiedy również klienta. Opiera się na szyfrachszyfrowaniu asymetrycznychasymetrycznym oraz [[certyfikat klucza publicznego|certyfikatach]] standardu [[X.509]].

Zaletą protokołu jest fakt,działanie że działa on na warstwiew [[TCP (protokół)Model_OSI#Warstwa_transportowa|TCPwarstwie transportowej]],. więcDzięki temu można go łatwo zastosować do zabezpieczenia protokołów [[Model_OSI#Warstwa_aplikacji|warstwy aplikacyjnejaplikacji]] (np.: [[telnet]], [[Hypertext Transfer Protocol|HTTP]], [[gopher]], [[POP3]], [[Internet Message Access Protocol|IMAP]], [[Network News Transfer Protocol|NNTP]]).

W 1994 roku firma Netscape stworzyła protokół, służący do bezpiecznej transmisji zaszyfrowanego strumienia danych, nazwany SSL (Secure Socket Layer), a już rok później pojawiła się wersjatrzecia v3jego tego protokołuwersja. W 1996 roku [[Internet Engineering Task Force]] (IETF) powołało grupę roboczą pod nazwą TLS (Transport Layer Security), której zadaniem było rozwijanie protokołu SSL. W 1999 roku został opublikowany standard TLS 1.0, który jest również czasem określany jako SSL 3.1. SSLCałość jestdziała więcw protokołem typuarchitekturze klient-serwer, pozwalającympozwalając na nawiązanie bezpiecznego połączenia z użyciem certyfikatów. JestArchitektura onjest zorientowanyzorientowana głównie na uwierzytelnianie serwera (np. sklepu internetowego, do którego klient wysyła numer karty kredytowej i chce mieć pewność co do odbiorcy), ale przewiduje również możliwość uwierzytelniania klienta.

NiektóreZ wczesnepowodu implementacjeograniczeń protokołuw używałyeksporcie technologii kryptograficznych ze [[Szyfrowanie 40bitStany_Zjednoczone|szyfrowaniaStanów 40-bitowymZjednoczonych]], kluczemwiększość zeimplementacji względuprotokołu naSSL [[ograniczenia]]nie nałożonemogła przezwykorzystywać rządkluczy USAsymetrycznych nadłuższych eksportniż technologii40 kryptograficznych[[Bit|bitów]]. RządDzięki nałożyłtemu ograniczenierządowe 40-bitowe,agencje abybezpieczeństwa rządowedysponujące agencjeodpowiednio dużą mocą obliczeniową (takie jakm.in. [[National Security Agency|NSA]]) były w stanie złamać szyfr za pomocą [[Atak brute force|atakumetodą brute-force]], a jednocześnie było wystarczająco kosztowne, aby nie każdy mógł go złamać. Po kilku latach publicznej debaty, lepszemu rozpoznaniupoznaniu dłuższych kluczy przez agencjezainteresowane rządowestrony oraz kilku sprawach sądowych, rząd złagodził nieco swoje stanowisko wobec stosowania dłuższychwiększych kluczy. Obecnie 40-bitowe klucze wyszły praktycznie z użycia, i zostały zastąpione przez ozapewniające wielewiększe bezpieczniejszebezpieczeństwo klucze o długości 128-bitowe i więcej bitów.

W 2009 w protokole SSL odkryto podatność na atak w procesie renegocjacji sesji,. umożliwiającąBłąd wstrzyknięcieumożliwiał nieautoryzowanego fragmentuwysłanie danych do zaszyfrowanejserwera przed użytkownikiem bez jego wiedzy (zobacz: [[Atak man in the middle]]) sesji<ref>{{cytuj stronę |url=http://www.securitystandard.pl/news/352295/Dziura.w.protokolach.SSL.i.TLS.html |tytuł=Dziura w protokołach SSL i TLS |opublikowany=Security Standard |data=2009}}</ref><ref>{{cytuj stronę|url=http://www.phonefactor.com/sslgap/ssl-tls-authentication-patches |tytuł=SSL/TLS Authentication Gap – Status of Patches |opublikowany=Phone Factor}}</ref>. W związku z tym, że podatność istnieje na poziomiedotyczyła protokołu, a nie jednej implementacji, jedyną metodą jegojej obejścia w momencie odkrycia jestbyło wyłączenie możliwości renegocjacji w ogóle. Równocześnie zaproponowana została poprawka do specyfikacji protokołu w postaci rozszerzenia <ref>{{cytuj stronę |url=https://datatracker.ietf.org/drafts/draft-rescorla-tls-renegotiation/ |autor=E. Rescorla, M. Ray, S. Dispensa, N. Oskov |data=2009 |tytuł=Transport Layer Security (TLS) Renegotiation Indication Extension}}</ref>.

* SSL 1 – ta wersja miała poważną dziurę w bezpieczeństwie. biorącąProcedury sięuzgadniania zszyfru nieweryfikowanianie procedurybyły uzgadnianiazabezpieczone, szyfru.więc Atakującyatakujący mógł wymusić używanie przez strony najsłabszego szyfru obsługiwanego przez obiekomunikujących stronysię, ze złamaniem którego mógł sobie poradzić znacznie łatwiej niż z szyfrem, który strony wybrałyby normalnie.

* SSL 2 – ta wersja weryfikujezmienia procedurę negocjacyjną.

* SSL 3 – popularna wersja, obecnie najczęściejwypierana przez TLS używana1.0.

* '''[[Kryptografia_symetryczna|symetryczne]]''' – do szyfrowania i deszyfrowania danych używany jest ten sam klucz; znając klucz szyfrujący możemy dokonać również deszyfracji danych (wyznaczyć klucz deszyfrujący)

* '''[[Kryptografia_asymetryczna|asymetryczne (z kluczem publicznym)]]''' – do szyfrowania i deszyfrowania używane są różne klucze; znając klucz szyfrujący nie możemy odszyfrować wiadomości (klucza deszyfrującego nie da się w prosty sposób wyznaczyć z klucza szyfrującego); klucz służący do szyfrowania jest udostępniany publicznie (klucz publiczny), ale informację nim zakodowaną może odczytać jedynie posiadacz klucza deszyfrującego (klucz prywatny), który nie jest nikomu ujawniany.

SSL jest najczęściej kojarzony z protokołem HTTP (HTTPS), ale może służyć do szyfrowaniazabezpieczania wielu innych protokołów, m.in.: Telnet, SMTP, POP, IMAP czy FTP., Ponieważgdyż protokoły te same w sobie nie zapewniają szyfrowania transmisji, warto w nich zastosować SSL, który oferuje szyfrowanie, uwierzytelnianie (algorytmami [[RSA (kryptografia)|RSA]] lub [[Protokół Diffiego-Hellmana|Diffiego-Hellmana]]), zapewnianie integralności danych oraz opcjonalnie również uwierzytelnienie klienta.

SSL v3 dopuszcza m.in. następujące algorytmy szyfrowaniai protokoły: [[Data Encryption Standard|DES]], [[3DES]], [[International Data Encryption Algorithm|IDEA]], [[RC2]], [[RC4]], [[RSA (kryptografia)|RSA]], [[DSS]], [[Protokół Diffiego-Hellmana|Diffiego-Hellmana]].

Krytycznym parametrem określającym siłę szyfrowania SSL jest długość użytych kluczy. Oczywiście imIm dłuższy klucz, tym trudniej jest dokonaćgo deszyfracjizłamać, a przez to odszyfrować transmisjitransmisję. Dla kluczy asymetrycznych, zgodnie z zaleceniami organizacji NIST, długością sugerowaną jest obecnie 2048 bitów. Powszechnie używane są określeniawyrażenia '''„SSL 128 bitów”''' (sugerowane stosowanie) oraz '''„SSL 40 bitów”'''. Podana w bitach długość określaokreślające długość użytego klucza symetrycznego.

* '''K ← S ChangeCipherSpec'''<br />Serwer zawiadamia, że wykonał polecenie – od tej pory wysyłał będzie tylko zaszyfrowane informacje...

* '''K ← S Finished'''<br />... i od razu wypróbowuje mechanizm – ten komunikat jest już wysyłany bezpiecznym kanałem

* [http://globalsignthawte.com/ GlobalSignThawte Consulting]