Szyfry odporne na kradzież klucza
Jak działa szyfrowane połączenie SSL?
W skrócie wygląda to w ten sposób, że klient (np. przeglądarka WWW, program pocztowy) łączy się z serwerem (np. strona WWW). Serwer przechowuje klucz szyfrujący podzielony na dwie części: prywatną i publiczną. To, co zostanie zaszyfrowane częścią publiczną - może zostać odszyfrowane częścią prywatną.
Serwer wysyła więc część publiczną do klienta, klient weryfikuje czy jest podpisana przez zaufane organizacje, i jest gotowy do wysyłania zaszyfrowanych wiadomości do serwera. Ponieważ jednak szyfrowanie asymetryczne (za pomocą klucza prywatnego/publicznego) jest powolne i nie nadaje się do transmisji dużej ilości danych, dalsza część połączenia jest zabezpieczona symetrycznie.
Szyfrowanie symetryczne to dokładnie to, którego używa się wysyłając plik ZIP z hasłem. Obie strony znają hasło, problem leży tylko w jego bezpiecznym przekazaniu. W transmisji SSL klient losuje długie hasło (32 albo 64 znaki-bajty), szyfruje je kluczem publicznym serwera i wysyła do niego. W tym momencie obie strony znają hasło (klucz symetryczny) i mogą swobodnie wysyłać komunikaty w obie strony.
Zagrożenie
Jeśli ktoś nagrywa całą transmisję pomiędzy klientem a serwerem na dysk, prawdopodobnie do niczego mu się te dane nie przydadzą - odzyskanie danych z zaszyfrowanej w ten sposób transmisji zajmie miliony lat (o ile nie dysponuje się komputerem kwantowym).
Co się jednak stanie, jeśli organizacja która nagrywała ruch uzyska klucz prywatny serwera, w wyniku włamania bądź wyroku sądu? Atakujący będzie mógł za pomocą klucza odtworzyć i odszyfrować całą przechwyconą transmisję. Jeśli był tam numer karty kredytowej klienta bądź jego opinia o Prezydencie, ma on problem.
Klucze efemeryczne
Na szczęście kryptografowie znaleźli sposób na rozwiązanie tego problemu, kosztem zwiększenia skomplikowania algorytmu uzgadniania klucza. Do każdego połączenia serwer tworzy nową parę kluczy prywatny-publiczny, wysyła nowy klucz publiczny do klienta, i dalej wymiana kluczy przebiega tak, jak poprzednio. Zaraz po zakończeniu połączenia, para kluczy jest zapominana przez serwer.
Główny klucz prywatny, podpisany przez zaufane instytucje, służy wyłącznie do podpisania klucza tymczasowego ("efemerycznego"). W ten sposób, klient nadal jest w stanie zweryfikować że łączy się z właściwym serwerem, natomiast atakujący nie ma możliwości odszyfrowania transmisji nawet jeśli zdobędzie prywatny klucz zapisany na serwerze. Właściwa para kluczy użyta do transmisji z klientem już dawno zniknęła z pamięci serwera.
W praktyce
W praktyce klienci niewiele mają do powiedzenia w kwestii wyboru algorytmu szyfrującego. Troche może pomóc dbałość o posiadanie najnowszej wersji przeglądarki - popularna biblioteka szyfrująca OpenSSL dorobiła się obsługi kluczy efemerycznych dopiero w 2010 roku. Przeglądarka Opera nie dorobiła się obsługi tego typu szyfrowania do dziś (wersja 12).
Więcej można zdziałać po stronie serwera. Wszystkie serwery WWW obsługujące protokół HTTPS, podobnie jak i większość serwerów pocztowych z obsługą TLS, mają możliwość ręcznego wyboru akceptowanych szyfrów oraz ustalenia ich priorytetów.
Szyfry które interesują tutaj nas najbardziej to rodzina ECDHE (Elliptic curve Diffie–Hellman Ephemeral) oraz, trochę mniej, DHE (Diffie–Hellman Ephemeral). Słowo "Ephemeral" oznacza właśnie to, że używane są klucze efemeryczne i mamy zapewnioną właściwość "perfect forward secrecy".
Nazwy szyfrów w powszechnie używanym OpenSSL składają się z:
- Algorytm wymiany klucza (ECDHE, DHE, RSA)
- Algorytm podpisu cyfrowego (ECDSA, RSA, DSS)
- Algorytm szyfru symetrycznego (AES, CAMELLIA, ARCFOUR)
- Długość klucza symetrycznego (128, 256)
- Tryb szyfru symetrycznego (CBC, GCM)
- Algorytm skrótu (hashowania) (SHA384, SHA, MD5)
Przykładowe powstałe w ten sposób nazwy to ECDHE_ECDSA_AES_256_GCM_SHA384 czy DHE-DSS-CAMELLIA128-SHA.
Tak powstałe nazwy łączy się dwukropkiem w ciąg szyfrów, od najbardziej do najmniej preferowanego. Dokładny opis jest w manualu
Na jednym z serwerów którymi administruję, gdzie bezpieczeństwo jest ważniejsze od obsługi Internet Explorera i użytkownikom można po prostu powiedzieć "zmień przeglądarkę" - używam następujących szyfrów:
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES256-SHA
Jak widać, są to tylko szyfry z symetrycznym szyfrowaniem 256-bitowym i tylko te z kluczami tymczasowymi. Jest tu również ciche założenie, że w miare wychodzenia silniejszych szyfrów będę uzupełniał tę listę.
Na stronie internetowej niestety nie mogę pozwolić sobie na tak silną selekcję szyfrów - starsze przeglądarki oraz różne dziwne "urządzenia mobilne" nie dadzą sobie z nimi rady, a przecież tutaj na klientach zależy bardziej niż na silnym szyfrowaniu. Pozostawiłem więc słabsze szyfry, ale z niższym priorytetem.
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:AECDH-AES256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE:ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:-LOW:+SSLv3:+EXP;
W nginx dyrektywa do wyboru kolejności dozwolonych szyfrów nazywa się ssl_ciphers, w Apache jest to SSLCipherSuite, w postfixie - smtpd_tls_mandatory_ciphers oraz smtpd_tls_mandatory_exclude_ciphers.
Powyższe ciągi szyfrów niekoniecznie muszą być optymalne, na pewno da się to zrobić lepiej, nie jestem ekspertem w dziedzinie kryptografii tylko zwykłym gościem który zaliczył kiedyś na studiach matematykę dysktetną, a teraz ma hopla na punkcie ukrywania swojej komunikacji.
Wyswietlen: 10155, komentarzy: 4 Feed z komentarzami
Imię: Pawel Dondziak (27. 06. 2013 - 16:00:59)Treść:
Poruszyłeś bardzo ciekawy temat. Ja właśnie niedawno zajmowałem się konfiguracją szyfrowania dla nowego serwera mailowe-go. Niestety używamy OpenSSL w wersji 0.9.8 (czas pomyśleć o update-cie). Przy okazji natknąłem się na artykuł na ten temat na NETCRAF-cie "SSL: Intercepted today, decrypted tomorrow" z którego wynika, że najlepiej z obsługą PFS radzi sobie rosyjski nginx co pewnie jest czystym przypadkiem :)
Imię: GDR! (27. 06. 2013 - 18:22:02)Treść:
No, nginx (i OpenSSL) z kolei nie obsluguje TLS 1.2 i jest podatny na atak BEAST. Nie jest lekko.
0.9.8 to Debian Squeeze pewnie? Tez mam mailserver w ktorym utknalem na tej wersji.
Imię: Pawel Dondziak (28. 06. 2013 - 09:44:10)Treść:
Zgadza się Debian Squeeze. Też nie jestem ekspertem od kryptografii ale zastanawia mnie jedna rzecz w tym PFS. Skoro mam dostęp do całej zapisanej komunikacji i uzyskałem dostęp do prywatnego klucza serwera to co mnie powstrzymuje przed:
1. wyłuskaniem za jego pomocą tymczasowo stworzonego klucza prywatnego
2. tymczasowym kluczem odszyfrowuje klucz symetryczny
3. kluczem symetrycznym odszyfrowuje właściwą komunikacje
Chyba, że masz mały błąd w opisie i serwer wysyła do klienta tymczasowy klucz publiczny a nie prywatny wtedy według mnie cały algorytm ma sens.
Imię: GDR! (28. 06. 2013 - 10:54:19)Treść:
Oczywiscie ze mam blad w opisie i serwer wysyla tymczasowy klucz publiczny. Dzięki!