W połowie mijającego właśnie tygodnia mogliśmy przeczytać o planowanych przez Google zmianach dotyczących zestawów szyfrów wykorzystywanych przez przeglądarkę Chrome podczas zestawiania bezpiecznych połączeń HTTPS. O tym jakie to zmiany, co jest przyczyną ich wprowadzania i co się z nimi wiąże możecie przeczytać w tym wpisie.
DHE zniknie z Chrome
W celu zabezpieczenia transmisji danych za pomocą protokołu TLS (SSL) wykorzystywanych jest szereg algorytmów kryptograficznych połączonych w tak zwane zestawy szyfrów (ang. cipher suites). Cześć z nich służy szyfrowania treści, część do zapewnienia integralności przesyłanych danych, a jeszcze inne pozwalają na bezpieczne uzgadnianie sekretów (kluczy, które posłużą do szyfrowania). I to właśnie w tej ostatniej grupie Google planuje wprowadzić pewne zmiany.
Chrome
Zmiany dotyczą protokołu Diffiego-Hellmana, który pozwala na bezpieczne uzgadnianie sekretów. Ze względu na jedną ze swoich głównych zalet jaką jest wsparcie dla Perfect Forward Secrecy, był/jest on powszechnie wykorzystywany w wielu protokołach m.in. w HTTPS czy SSH. Od wersji Chrome 39 wszystkie zestawy szyfrów oparte o algorytm wymiany kluczy klasycznego, efemerycznego Diffi-Hellman’a (DHE) zostaną przesunięte do tak zwanej opcji fallback. Oznaczało to będzie, że nie będą dostępne do użycia (wynegocjowania) przy pierwszej próbie zestawienia połączenia TLS. Dopiero, gdy żaden inny wspólny zestaw szyfrów nie zostanie znaleziony przeglądarka pozwoli na użyciu tego opartego na DHE. Finalnie DHE nie będzie dostępny w ogóle.
Protokół Diffiego-Hellmana (źródło: wikimedia.org)
W pierwszym zdaniu poprzedniego akapitu celowo użyłem słowa “klasyczny” w odniesieniu do algorytmu DHE. Istnieje jeszcze inna odmiana algorytmu Diffie-Hellmana oparta na krzywych eliptycznych, znana pod skrótem ECDHE. Ta nie zostanie usunięta z Chrome, a wręcz przeciwnie. ECDHE jest zalecany jako ten, który powinien wskoczyć na miejsce DHE wszędzie tam, gdzie jeszcze nie wskoczył.
Dlaczego?
Zamiar usunięcia DHE z Chrome jest skutkiem podatności w implementacji tego protokołu o której mogliśmy usłyszeć już pół roku temu. Logjam, bo o tym ataku mowa – poprzez wymuszenie wykorzystania ze zbyt małych rozmiarów grup (struktura algebraiczna) na których opiera się bezpieczeństwa DHE – pozwalał na przechwycenie uzgadnianych sekretów co w konsekwencji mogło prowadzić do przechwycenie całej szyfrowanej transmisji danych. Podatność wskazywała na możliwość przeprowadzenie skutecznego ataku na grupy 512 i 768 bitowe, a w przypadku dysponowania wielkimi mocami obliczeniowymi, nawet na 1024 bitowe.
W odpowiedzi na tę podatność przeglądarki, w tym Chrome, zablokowały możliwość wykorzystywania DHE opartego na grupach mniejszych niż 1024 bitowe. Było to rozwiązanie doraźnie, ponieważ i ten rozmiar grup (1024 bitów) nie gwarantował bezpieczeństwa. A jak niestety podaje Google, nadal około 95% połączeń opartych na DHE korzysta z 1024 bitowych grup (mowa o statystykach Chrome). Dobrą wiadomością jest to, że tylko około 2% połączeń w ogóle korzysta z DHE. Podsumowując, DHE wykorzystywany jest już naprawdę rzadko, a jak już jest to korzysta ze słabych rozmiarów grup. Stąd w ocenie Google bardziej praktyczną opcją jest całkowite wyłączenie wsparcia dla DHE niż na przykład zwiększanie minimalnego, akceptowalnego rozmiaru grup.
Co to wszystko dla mnie oznacza?
Jeżeli przeglądarka i serwer podczas próby zestawienia połączenia HTTPS nie znajdą przynajmnej jednego wspólnego zestawu szyfrów, który mógłby zostać przez nich wykorzystany do zapewnienia bezpieczeństwa transmisji danych, to takie połączenie nie dojdzie do skutku. W praktyce, dla użytkownika oznacza to po prostu brak możliwości odwiedzenia danej strony WWW.
Przede wszystkim warto więc sprawdzić jakie zestawy szyfrów oferuje w tym momencie Wasz serwer. Można użyć do tego narzędzia SSLLabs. Wynik znajdziecie w sekcji Configuration -> Cipher Suites. Jeżeli po usunięciu z listy zwróconej przez SSLLabs zestawów szyfrów korzystających DHE nie pozostanie Wam żaden inny to powinniście czym prędzej wdrożyć zmiany, które pozwolą Wam na udostępnienie dodatkowych zestawów.
Jeżeli zaś po usunięciu szyfrów opartych o DHE pozostanie Wam wiele innych to raczej nie macie powodów do obaw. Póki co warto sprawdzić czy są wśród nich te oparte o ECDHE. Jeżeli Wasz serwer wspiera protokół TLS w wersji 1.2 (sekcja Configuration -> Protocols) to z pewnością możecie i powinniście skorzystać z tego algorytmu, który podobnie jak DHE wspiera Perfect Forward Secrecy.
