Co nazywamy nowoczesną kryptografią? A co przestarzałą? Jakie algorytmy kryptograficzne możemy zaliczyć do tej pierwszej grupy, a jakie do drugiej? W tym wpisie postaram się przedstawić jak widzą to twórcy przeglądarki Chrome.

Wprowadzenie

Każda przeglądarka na swój sposób przedstawia szczegóły połączenia TLS. Wśród tych szczegółów odnaleźć można m.in. informacje o algorytmach wykorzystanych do zapewnienia bezpiecznej komunikacji. To, które z nich mogą być obecnie uznawane za bezpieczne, a które nie, nie podlega raczej większej dyskusji. Mimo to, czasami nie jest łatwo określić przyczyny wyświetlania ostrzeżeń dotyczących poziomu bezpieczeństwa algorytmów, które skonfigurowaliśmy na serwerze. Zwłaszcza, jeżeli ostrzeżenia te występują tylko w jednej z przeglądarek.

W tym wpisie skupię się na ostatnich zmianach, które zaszły w przeglądarce Chrome. Być może wielu z Was zauważyło, że w wersji 41 przeglądarki tworzonej przez Google w szczegółach połączenia TLS dodane zostały dwa komunikaty:

1. Połączenie z NAZWA-TWOJEJ-DOMENY jest szyfrowane przy użyciu nowoczesnej kryptografii.
2. Połączenie z NAZWA-TWOJEJ-DOMENY jest szyfrowane przy użyciu przestarzałej kryptografii.

Przyjrzyjmy się zatem co warunkuje wyświetlanie powyższych komunikatów. Na początek, dla lepszego zrozumienia tematu, krótko o tym czym są zestawy szyfrów.

Zestawy szyfrów

Podczas nawiązywania i później podczas trwania połączenia TLS wykorzystywane są różne algorytmy kryptograficzne. Wśród nich wyróżnić można te, które pozwalają na:

• wymianę kluczy kryptograficznych – RSA, DH, ECDH;
• uwierzytelnienie – RSA, DSA;
• szyfrowanie – AES, 3DES;
• zapewnienie integralności – SHA-1, SHA-2.

Te cztery rodzaje algorytmów łączone są w, tak zwane, zestawy szyfrów, i tak na przykład zestaw:

DHE-RSA-AES256-SHA256

oznacza, że :

• za wymianę kluczy kryptograficznych odpowiada algorytm Diffie-Hellman’a,
• do uwierzytelniania wykorzystywany jest algorytm RSA (Rivest-Shamir-Adleman),
• szyfrowanie danych odbywa się przy użyciu algorytmu Advanced Encryption Standard (Rijndael) korzystającego z kluczy 256 bitowych,
• zapewnienie integralności przesyłanych danych oparte na funkcji skrótu SHA-256  (Secure Hash Algorithm).

Wracając od wspomnianych komunikatów w najnowszym Chrome. Jako, że nie udało mi się odnaleźć (być może nie szukałem zbyt dokładnie) oficjalnego oświadczenia Google na temat tego, które algorytmy traktuje jako nowoczesne, a które uznaje jako przestarzałe, postanowiłem wykonać kilka testów licząc na to, że uda się wyciągnąć jakieś wnioski, a następnie opisać je na Kryptosferze i tym samym wesprzeć wielu – zakłopotanych komunikatami w Chrome – administratorów i użytkowników.

Testy

Testy polegały na definiowaniu różnych zestawów szyfrowych na serwerze HTTP (Apache), a następnie na sprawdzaniu tego co na ich temat ma do powiedzenia Chrome. Wybrałem sześć różnych zestawów pamiętając o tym, żeby były zgodnie z tymi które wspiera Chrome (jeżeli serwer nie posiada przynajmniej jednego wspólnego zestawu szyfrów z przeglądarką połączenie nie może zostać nawiązane). Oto otrzymane wyniki:

1. ECDHE-RSA-AES128-SHA (wymiana kluczy: ECDHE – Elipic Curve Diffie Hellman; uwierzytelnienie: RSA; szyfrowanie: AES klucze 128 bitowe, tryb CBC – Cipher Block Chaining; integralność: SHA-1)
   

   ECDHE-RSA-AES128-SHA

2. ECDHE-RSA-AES128-GCM-SHA256 (wymiana kluczy: ECDHE; uwierzytelnienie: RSA; szyfrowanie: AES klucze 128 bitowe, tryb GCM – Galois/Counter Mode; integralność: SHA-2)
   

   ECDHE-RSA-AES128-GCM-SHA256

3. DHE-RSA-AES128-GCM-SHA256 (wymiana kluczy: DHE – Diffie-Hellman; uwierzytelnienie: RSA; szyfrowanie: AES klucze 128 bitowe, tryb GCM; integralność: SHA-2)
   

   DHE-RSA-AES128-GCM-SHA256

4. DHE-RSA-AES128-SHA (wymiana kluczy: DHE; uwierzytelnienie: RSA; szyfrowanie: AES klucze 128 bitowe, tryb CBC; integralność: SHA-1)
   

   DHE-RSA-AES128-SHA

5. AES128-SHA (wymiana kluczy: RSA, uwierzytelnienie: RSA, szyfrowanie: AES klucze 128 bitowe, tryb CBC; integralność: SHA-1)
   

   AES128-SHA

6. AES128-GCM-SHA256 (wymiana kluczy: RSA, uwierzytelnienie: RSA, szyfrowanie: AES klucze 128 bitowe, tryb GCM, integralność: SHA-2)
   

   AES128-GCM-SHA256

Wnioski

Co wynika z powyższych testów?

Otóż, aby mieć pewność, że Chrome zawsze określi algorytmy kryptograficzne, wykorzystywane w połączeniu TLS, jako nowoczesne (zauważcie, że tylko 2 z 6 powyższych zestawów zostało za takie uznane) należy spełnić dwa warunki:

1. Do wymiany kluczy używać wyłącznie ECDHE i DHE.
2. Do zapewnienia integralności nie wykorzystywać funkcji skrótu SHA-1 i starszych.

Punkt pierwszy ma związek z czymś co nazywa się Perfect Forward Secrecy (PFS). Termin ten odnosi się do sposobu w jaki wymieniane są klucze sesyjne (pomiędzy przeglądarką a serwerem) wykorzystywane podczas połączenia TLS. Algorytmy ECDHE i DHE mają tę właściwość, że klucze sesyjne wymieniane są w taki sposób, że nie mają bezpośredniego powiązania z kluczem prywatnym serwera (nie da się ich odtworzyć na jego podstawie). Dzięki temu nawet, gdy komuś uda się wykraść nasz klucz prywatny nie będzie on w stanie zdeszyfrować wcześniej przesyłanych danych (które mógł kolekcjonować przez minione dni, tygodnie, miesiące, a nawet lata). Osiągnięcie PFS zapewnia właśnie użycie algorytmów ECDHE i DHE w procesie uzgadniania kluczy sesyjnych.

Co do punktu drugiego, to jest on wynikiem rozpoczętego jakiś czas temu przez Google procesu wycofywania funkcji skrótu SHA-1 z szerokiego użycia. SHA-1 powoli przestaje po prostu być uznawany za bezpieczny.

Podsumowując, komunikaty o nowoczesnej i przestarzałej kryptografii w Chrome mają swoje uzasadnienie i nie są czymś co może, w kontekście bezpiecznej komunikacji, bardzo zaskakiwać. Jedyny zarzut pod adresem Google to brak klarownej i szeroko rozpowszechnionej informacji o tym co determinuje wyświetlenie takiego czy innego komunikatu (nie dotarł on, przynajmniej do mnie, w prosty i jasny sposób).

Mam nadzieję, że ten wpis, przynajmniej części z Wam, pomoże skonfigurować serwer w taki sposób, aby być na czasie z Chrome, a przede wszystkim ze standardami bezpieczeństwa.