Zadaniem firmy świadczącej usługi testów penetracyjnych jest wskazanie potencjalnych ścieżek ataku dla danej aplikacji. Czy fakt stosowania szyfru RC4-MD5 w serwerze SSL jest już podatnością, którą należy wykazać w rapocie, czy też praktyką dopuszczalną z punktu widzenia bezpieczeństwa?
Chodzi konkretnie o zestaw algorytmów (cipher suite) dla protokołu SSL o nazwie TLS_RSA_WITH_RC4_128_MD5 czyli taki, w którym poufność zapewniona jest przez szyfr RC4, zaś autentyczność i integralność - przez HMAC-MD5.
Argumentacja w raporcie, z którym się ostatnio zetknąłem brzmiała następująco: na oba algorytmy "są znane ataki" i dlatego trzeba się z nich trzymać daleka. W rzeczywistości jest to jednak uzasadnienie dalekie od prawdy. A piszę o tym dlatego, że z każdej takiej "dziury" trzeba się potem tłumaczyć klientowi, więc raportowane na wyrost rzekome podatności przyczyniają się do siania FUD.
Dla szyfru RC4 znanych jest kilka praktycznych ataków. Do najszerzej znanych - i najpoważniejszych - należy atak Fluhrera, Mantina i Shamira, który umożliwia odtworzenie klucza szyfrującego jeśli wiele bloków danych jest szyfrowanych tym samym kluczem z różnymi wektorami inicjalizującymi i z podobnym początkiem tekstu jawnego. Taka specyficzna implementacja stała się przyczyną złamania protokołu WEP.
Jednak w przypadku SSL nie mamy do czynienia z taką implementacją - w protokole tym cała transmisja w ramach danej sesji SSL jest szyfrowana jednym losowym kluczem. Dla nowej sesji generowany jest nowy klucz sesyjny. Podsumowując, algorytm RC4 w tej konkretnej implementacji jaką jest SSL nie jest podatny na żaden praktyczny dzisiaj atak:
There are two reasons why the new attacks do not apply to RC4-based SSL. First, SSL generates the encryption keys it uses for RC4 by hashing (using both MD5 and SHA1), so that different sessions have unrelated keys. Second, SSL does not re-key RC4 for each packet, but uses the RC4 algorithm state from the end of one packet to begin encryption with the next packet. The recent techniques of Fluhrer, Mantis and Shamir thus do not apply to SSL. (RSA Security Response to Weaknesses in Key Scheduling Algorithm of RC4)
Drugi z algorytmów czyli MD5 również jest uważany za złamany, zwłaszcza po wykryciu szeregu problemów ułatwiajacych tworzenie kolizji oraz praktycznej demonstracji z użyciem fałszywych certyfikatów X.509. W szczególności problemy te dyskwalifikują go z zastosowań długoterminowych, takich jak jakakolwiek forma podpisu cyfrowego. Kwestia użycia MD5 jest w protokole SSL nieco bardziej skomplikowana, bo jest on używany w wielu miejscach. W szczególności - w skrótach chroniących poszczególne pakiety oraz w komunikacie końcowym, który też zawiera podsumowanie skrótu wszystkich wcześniejszych danych.
W przypadku MD5 stosowanego w SSL również zagrożenie ze strony znanych ataków nie jest praktyczne. MD5 jest wykorzystywany w trybie HMAC, czyli jako skrót sparametryzowany kluczem kryptograficznym. Ktoś kto nie zna tego klucza, nie może podejmować prób wygenerowania kolizji i znowu mamy do czynienia z atakiem realnym, ale niepraktycznym w tym konkretnym zastosowaniu.
Podsumowując, zestaw TLS_RSA_WITH_RC4_128_MD5 jest nadal praktycznie bezpieczny w protokole SSL 3. I jest to zapewne przyczyna, dla której nawet w ostatniej wersji MSIE 8 pod aktualizowanym Windows XP SP3 szyfr ten jest nadal dostępny i negocjowany z wieloma produkcyjnymi serwerami SSL. Wybór zestawu szyfrowego należy do serwera i wiele serwerów - zwłaszcza IIS - nadal ma go na początku listy szyfrów preferowanych.I istnieje ku temu bardzo praktyczny powód.
RC4 i MD5 pomimo swoich wad należą do jednych z najszybszych współczesnych algorytmów kryptograficznych. Jeśli przełożymy to na cykle procesora i pomnożymy przez tysiące użytkowników otwierających sesje SSL do danego serwera to nawet kilkunastoprocentowa różnica (np. w stosunku do 3DES-SHA1) może przekładać się na spory zysk wydajnościowy.
Podsumowując, wydaje mi się że firmy testujące bezpieczeństwo nie mają podstaw do zgłaszania TLS_RSA_WITH_RC4_128_MD5 jako "podatności" jeśli testują pod kątem ogólnego bezpieczeństwa serwera (a nie np. pod kątem zgodności z FIPS). Warto zauważyć, że milczą na ten temat takie metodyki testów penetracyjnych jak OWASP i być może jest to potencjalny obszar do uzupełnienia. Jest to temat skomplikowany i w jednym z raportów spotkałem się np. z myleniem MD5 w certyfikacie (źle) z MD5 w SSL (nie tak strasznie).
RC4-MD5 a standardy
Amerykański standard NIST SP 800-52 w ogóle nie dopuszcza stosowania ani RC4 ani MD5 do ochrony informacji przetwarzanych przez amerykańskie agencje federalne bo nie są one standardami FIPS. Z jednym wyjątkiem - uwzględniając ich powszechność SP 800-52 dopuszcza stosowanie RC4-MD5-128 w systemach klienckich, negocjujących SSL z zewnętrznym światem. Standardy FIPS są wiążące tylko dla amerykańskich agencji federalnych, choć często wykorzystywane jako ogólny punkt odniesienia w kwestii standardów kryptograficznych.
Finansowy standard branżowy PCI-DSS w ostatniej wersji 1.2 nie mówi nic o konkretnych algorytmach (w przeciwieństwie do poprzednich wersji), żąda jedynie korzystania z "silnego szyfrowania" (strong encryption). Dostępne interpretacje oraz spotykane w rzeczywistości konfiguracje serwerów instytucji finansowych sugerują, że RC4-MD5 mieści się w kategorii "silnych" pod warunkiem korzystania z klucza 128 bitów (jako taki jest zresztą określany przez Internet Explorera).
Realne błędy w konfiguracji SSL
Co należy zatem uznać za rzeczywiste błędy w konfiguracji SSL?
- Użycie MD5 w podpisie cyfrowym w certyfikacie serwera lub klienta. Obecnie rzadkość bo żaden znany mi root publiczny takich nie wystawia. Możliwe tylko w przypadku certyfikatów wystawianych w drzewach prywatnych.
- Dopuszczalność stosowania algorytmów określanych jako "eksportowe" (exportable) lub "słabe" (weak). Zaliczają się do nich zestawy z kluczami symetrycznymi poniżej 128 bitów oraz asymetrycznymi (RSA, DSA) poniżej 1024 bitów.
- Cała gama błędów związanych z certyfikatami SSL, które opisałem w artykule "Po co nam SSL?"