S

SL / TLS jest pozornie prostą techniką zapewniającą m.in. ochronę witryn internetowych. Gwarantuje poufność transmisji danych przesyłanych przez internet, zachowując przy tym prostotę instalacji i działania – z wyjątkiem, gdy tak nie jest. Przy końcówce 2014 roku, gigant z Mountain View – Google – na swoim blogu poinformował, że strony korzystające z certyfikatów SSL, będą bardziej „lubiane” w wynikach wyszukiwania, a także chętniej indeksowane. Nie jest to jednak ostatnie słowo. Główna litera Alfabetu nie tylko tą akcją chce wprowadzić strony WWW w kolejny etap bezpiecznego internetu. Już na początku 2017 roku, rodzima przeglądarka Chrome będzie posiadała mechanizmy, które podczas łączenia z dowolną witryną jednoznacznie odpowiedzą użytkownikowi na pytanie: czy korzystanie z niej jest bezpieczne?

Finalnie, Google nie chodzi tylko o bezpieczeństwo, ale także o jakość i szybkość komunikacji. Implementując HTTPS, jest się tylko o jeden krok od implementacji HTTP 2.0, czyli zyskania kilku nowych funkcjonalności podczas transmisji z aplikacjami internetowymi. Jak każda zmiana – posiada swoich orędowników oraz przeciwników. Faktem jest, że najwięksi gracze wyznaczają standardy, a inni za nimi podążają. Wszystkie te znaki wskazują, że właśnie kończy się era „czystej” komunikacji, a zaczyna dominacja „szyfru”. Dlatego, jeśli mamy wejść w szyfrowanie połączone z wydajnością – co często nie jest łatwe do poprawnego wdrożenia – chcę przedstawić administratorom oraz programistom, na co należy przeznaczyć dodatkowy wysiłek odpowiednio konfigurując swoje serwery oraz aplikacje (obrazek #1 – HTTP 2.0 – źródło).

1. Klucze i certyfikaty:

W mechanizmie T)ransport L)ayer S)ecurity, bezpieczeństwo zaczyna się od tożsamości kryptograficznej serwera. Na początku potrzebujemy silnego klucza prywatnego, aby powstrzymać osoby postronne od przeprowadzania ataków personifikacji nas i naszych klientów. Drugim ważnym czynnikiem, jest aktualny (czasowo) i silny certyfikat, który przyznaje prawo naszemu kluczowi do reprezentowania naszego serwera lub domeny. Bez tych dwóch podstawowych filarów, nie jesteśmy w stanie zbudować bezpiecznego tunelu komunikacji.

1.1 Prywatne 2048-bitowe klucze:

W 2005 roku, amerykański National Institute of Standards and Technology (NIST) wydał pierwszą rewizję dokumentu: „NIST Special Publication 800-57 – Recommendation for Key Management”, w którym sugeruje, że klucze 1024-bitowe RSA nie będą zdolne do użycia po 2010 roku, wobec czego, należy przejść na klucze 2048-bitowe, które powinny być ważne aż do roku 2030. Niektórzy z miejsca stosują klucze 4096-bitowe uważając, że „jeszcze więcej – to lepiej”. Jednakże „więcej = lepiej”, nie zawsze pokrywa się z prawdą, ponieważ im dłuższy klucz – tym wymaga więcej zasobów obliczeniowych i pamięci – a to zużywa więcej energii niż zazwyczaj. Dla większości stron internetowych, bezpieczeństwo dostarczane przez 2048-bitowe klucze RSA, powinno być wystarczające. Algorytm klucza publicznego RSA jest powszechnie wspierany, co sprawia, że póki co – klucze tego typu są bezpiecznym, domyślnym wyborem. Przy 2048 bitach dysponujemy 112 bitami bezpieczeństwa.

Jeśli chcemy zapewnić większy poziom bezpieczeństwa niż ta liczba, należy pamiętać, że klucze RSA nie są najlepszym wyborem przy skalowaniu. Chcąc uzyskać 128 bitów bezpieczeństwa, potrzeba 3072-bitowego klucza RSA, który jest już znacznie wolniejszy. Klucze ECDSA stanowią dobrą alternatywę, która oferuje większe bezpieczeństwo i wydajność. Według ENCRYPT II, klucz krzywych eliptycznych o długości 256-bitów oferuje ten sam poziom bezpieczeństwa, co 3248-bitowy klucz asymetryczny oraz umożliwia wykonanie znacznie więcej operacji pozwalając oszczędzić wiele cykli procesora, a co za tym idzie – możliwość obsługi większej ilości klientów. Tak naprawdę tylko mała liczba starszych klientów nie obsługuje ECC (Elliptic Curve Cryptography), ale jeśli chcemy zachować pełną równowagę światów i nie przeszkadza nam nakład takiej konfiguracji możemy wdrożyć obsługę zarówno kluczy RSA i ECDSA (obrazek #2 – Podpis i weryfikacja ECDSA – źródło).

1.2 Ochrona prywatnych kluczy:

Przy ochronie i sposobie postępowania z prywatnymi kluczami, należy mieć na względzie kilka zasad, którymi możemy się kierować:

• Klucze należy traktować jak hasła do kont administracyjnych. Dostęp do nich powinna posiadać tylko ograniczona grupa pracowników, która jest bezpośrednio związana z procesem ich generowania i wgrywania do określonych systemów i urządzeń.
• Generowanie kluczy powinno odbywać się na zaufanych maszynach, które posiadają odpowiedni poziom entropii. Niektóre urzędy certyfikacji oferują generowanie kluczy prywatnych za nas – należy wystrzegać się tego typu rozwiązań, ponieważ nie jest to dla nas w pełni transparentny proces, który możemy kontrolować lub nawet mieć do niego wgląd na każdym kroku.
• Hasła wprawdzie nie chronią produkcyjnych systemów przed uzyskaniem odszyfrowanych kluczy z pamięci procesów przez bardzo doświadczonych atakujących (chyba, że stosujemy sprzętowe moduły kryptograficzne) to i tak powinny być stosowane, aby zapobiec ich wyciekowi np. poprzez kompromitację systemu kopii zapasowych.
• Po wycieku jakichkolwiek komponentów naszego szyfrowania należy od razu unieważnić stare certyfikaty oraz klucze i wygenerować zupełnie nowe.
• Odnawianie certyfikatów powinno odbywać się w cyklach rocznych lub jeśli posiadamy możliwości technologiczne (w postaci automatyzacji procesu – o czym później) oraz środki finansowe – częściej. Dlaczego? Po pierwsze certyfikaty o krótszych cyklach życia są bardziej bezpieczne w praktyce (czas złamania > czasu życia). Po drugie – ciągły rozwój technologii oraz badań nad kryptografią czyni ten proces dynamicznym – algorytmy szyfrujące używane do budowy TLS w tym roku mogą zostać złamane i uznane za niebezpieczne w przyszłym. Dlatego dłuższe cykle mogą okazać się tylko stratą czasu i pieniędzy.
• Za każdym odnowieniem certyfikatu – nawet jeśli nie doszło do żadnego ataki i wycieku – należy używać nowych kluczy – chyba, że wykorzystujemy mechanizm Public Key Pinning, ale i w tym przypadku posiadamy także możliwość określenia czasu ważności klucza publicznego oraz zdefiniowanie jego zapasowej wersji, więc możemy zgrać te czynności w czasie.

1.3 Pokrycie wszystkich nazw domenowych:

Planując wdrożenie szyfrowanej komunikacji, musimy wykonać listę wszystkich nazw domenowych, którym chcemy zapewnić certyfikat. Najgorszym, co może się zdarzyć od strony naszego użytkownika, to ostrzeżenia przeglądarki, że certyfikat dla wybranej strony jest nieprawidłowy. Dezorientacja użytkowników i osłabienie ich zaufania w takiej sytuacji, jest bardziej niż prawdopodobne. Nawet jeśli chcemy tylko używać SSL dla jednej domeny, musimy pamiętać, że w internecie do dzisiaj panuje chaos w kwestii uznawania WWW za część adresu, czy subdomenę. Dlatego nie jesteśmy w stanie kontrolować, z jakiej wersji naszego adresu trafi do nas użytkownik. W większości przypadków, problem ten rozwiązuje jeden certyfikat zapewniający ochronę dla domeny – z i bez przedrostka www (domena.pl / www.domena.pl), np. za pomocą Subject Alternative Name. Żelazną zasadą posiadania bezpiecznego serwera WWW, jest posiadanie certyfikatu SSL dla każdej domeny, która na niego wskazuje odpowiednimi rekordami DNS.

Istnieją oczywiście jeszcze certyfikaty typu wildcard (*.domena.pl), pokrywające wszystkie subdomeny do pierwszej kropki „.” z prawej. W tym przypadku również należy uważać na udostępnianie kluczy do tego typu certyfikatów – szczególnie, jeśli oznacza to dostęp dla większej grupy osób z innych zespołów lub działów (nawet w obrębie tej samej firmy). W takich wypadkach, warto rozważyć rezygnację z takiego rozwiązania na rzecz kilku pojedynczych subdomen. Innymi słowy, im mniej ludzi posiada wgląd do kulis szyfrowania, tym lepiej. Należy sobie zdawać sprawę, że dzielenie certyfikatów tworzy również wieź niebezpieczeństwa. Luka w jednej stronie internetowej, serwerze lub aplikacji, dotyka wszystkich innych stron i serwerów, które używają tego samego certyfikatu (obrazek #3 – Subject Alternative Name – źródło).

1.4 Pozyskiwanie certyfikatów od wiarygodnych Urzędów Certyfikacji (CA):

Przy wyborze Urzędów Certyfikacji, musimy kierować się kilkoma przesłankami. Nie raz w historii internetu dochodziło do wyrzucania różnych CA z topowych przeglądarek i unieważniania ich produktów. Najlepiej wówczas – przed wyborem – zapoznać się z historią i reputacją danego centrum, aby upewnić się, że poważnie traktuje swoją działalność na rynku certyfikatów bezpieczeństwa. Przede wszystkim, przed podjęciem decyzji warto wiedzieć o:

• Postawie danego CA do kwestii bezpieczeństwa – wszystkie centra przechodzą regularne audyty, ale niektóre podchodzą do nich bardziej poważnie i rygorystycznie od innych. Przeglądając historię opinii oraz artykułów w internecie o danej firmie, można natknąć się na różne wzmianki o różnych incydentach, reakcji na nie, a także – czy firma wyciągnęła wnioski ucząc się na własnych błędach.
• Skoncentrowaniu na konkretnej działalności – firmy, których główna działalność orbituje tylko wokół certyfikatów, mają wiele do stracenia jeśli dopuszczą do zaniedbań standardów, które wcześniej wyznaczały. Dlatego warto wybierać firmy, które są skoncentrowane na świadczeniu konkretnych usług związanych z szyfrowaniem ruchu internetowego.
• Jeśli mówimy o usługach to z pewnością Urzędy takie powinny posiadać CRL – Certificate Revocation List, czyli listę unieważnionych certyfikatów oraz OCSP – Online Certificate Status Protocol, które są metodami wspierającymi odwołanie i sprawdzenie statusu poszczególnych certyfikatów. Standardem powinna być duża wydajność i dostępność takich serwisów – świetnie, jeżeli posiadają dedykowaną stronę informującą o dostępności poszczególnych podstron i usług. Jeśli planujemy zarządzać dużą liczbą certyfikatów, naturalnie musimy również położyć nacisk na dostępność narzędzi, które ułatwiają nam ich zarządzanie (obrazek #4 – OSCP/CRL – źródło).

1.5 Silne algorytmy podpisu certyfikatów:

Bezpieczeństwo certyfikatu zależy do mocy klucza prywatnego, który został użyty do podpisania certyfikatu oraz siły funkcji skrótu, wykorzystywanej do cyfrowego podpisywania danych zawartych w certyfikacje. Do niedawna, większość certyfikatów opierała się na funkcji SHA-1. Ze względu na jego coraz słabszą siłę szyfrującą, w dobie mocy obliczeniowej dzisiejszych komputerów, został on uznany za niebezpieczny i rozpoczął się proces migracji do SHA-2 (256). Dobrą wiadomością jest fakt, że od stycznia 2016, nie powinniśmy już otrzymywać certyfikatu podpisanego SHA-1 od któregokolwiek z CA – a zgodnie z deklaracją firm Microsoft, Mozilla i Google – od 1 stycznia 2017 roku, wszystkie certyfikaty SSL podpisane tym algorytmem, nie będą obsługiwane w produktach tych firm.