-15% na nową książkę sekuraka: Wprowadzenie do bezpieczeństwa IT. Przy zamówieniu podaj kod: 10000

Kilka słów o wdrożeniu SSL i TLS – cz. I

09 lutego 2017, 07:44 | Teksty | komentarzy 20

SSL / 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.

http 2.0

HTTP 2.0 ( źródło: https://giuseppeciotta.net/getting-to-know-http20-with-the-mosaic-demo.html)

1. Klucze i certyfikaty

 

W mechanizmie T)ransport L)ayer S)security, 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.

sign & verify

Podpis i weryfikacja ECDSA (źródło: https://realtimelogic.com/ba/doc/en/C/shark/md_md_Examples.html)

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 transparenty 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 ataku 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.

Entropia

Entropia (źródło: http://kwejk.pl/obrazek/2011735/entropia.html )

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ż więź niebezpieczeństwa. Luka w jednej stronie internetowej, serwerze lub aplikacji, dotyka wszystkich innych stron i serwerów, które używają tego samego certyfikatu.

SAN

Subject Alternative Name (źródło: https://www.digicert.com/subject-alternative-name.htm)

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

 

Przy wyborze Urzędów Certyfikacji, musimy kierować się kilkoma przesłankami. Nieraz 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 wyznaczył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 OCSPOnline 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łatwią nam ich zarządzanie.

OSCP

OSCP/CRL (źródło: http://problemsolvedweb.blogspot.com/2014/03/wso2-esb-ocspcrl-verification.html)

1.5 Silne algorytmy podpisu certyfikatów

 

Bezpieczeństwo certyfikatu zależy od mocy klucza prywatnego, który został użyty do podpisania certyfikatu oraz siły funkcji skrótu, wykorzystywanej do cyfrowego podpisywania danych zawartych w certyfikacie. 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ż otrzymać 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.

CDN.

W kolejnej części zajmiemy się wskazówkami poprawnej konfiguracji TLS od strony serwera (i nie tylko), aby upewnić się, że nasze dane są prezentowane klientom poprzez bezpieczne szyfry kryptograficzne, a wszystkie znane słabości wykluczone z tej komunikacji.

Patryk Krawaczyński

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Pitasato

    Ilustracja pierwsza świetnie prezentuje rozwój protokołu http!

    Odpowiedz
  2. Kilka uwag:
    1) Po wspomnieniu „odpowiedniej entropii” wiele osób rzuci się na „/dev/random”. Nie trzeba: „/dev/urandom” jest ok⁽¹⁾.
    2) Przed zastosowaniem HPKP i HSTS dowiedzieć się dokładnie, na czym polegają i jak je wdrożyć: w szczególności po co ma się drugi, zapasowy certyfikat. Inaczej można niechcący odciąć użytkowników od swojego serwisu. Nie ma użytecznej możliwości obejścia takiej sytuacji, a przy ustawionej długiej ważności odcięcie może trwać miesiące — czyli można sobie zabić biznes.
    3) W kontekście TLS w kółko gada się o szyfrowaniu, co jest zwodnicze, bo ważniejszą rzeczą zapewnianą przezeń jest uwierzytelnienie serwera. Warto o tym pamiętać, rozważając „za i przeciw” — szyfrowanie może wydawać się nieistotne dla twojej usługi, ale wiarygodność to co innego.
    4) Jeśli wdrażać, to po całości, a nie robić teatrzyk z „chronieniem formularza do logowania”. Formularz chroniony, tylko link do niego podawany niezabezpieczonym kanałem, a po zalogowaniu ID sesji lata sobie radośnie bez szyfrowania.
    ____
    [1] ; na końcu cytaty m.in. Bernsheina, gdyby ktoś potrzebował autorytetów.

    Odpowiedz
    • Zniknięto linka do artykułu, w którym Hühn opisuje temat :(. Zatem tylko zacytuję Bernsteina:

          Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that
              (1) we can’t figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but
              (2) we _can_ figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.).
          For a cryptographer this doesn’t even pass the laugh test.

      Rzecz dotyczy Linuksa — na innych platformach „/dev/[u]random” mogą być oczywiście zaimplementowane inaczej

      Odpowiedz
  3. Krzysiek

    Szkoda tylko, że te trendy generują duże koszta, certyfikaty nie są tanie, a darmowe nie są pewne (StartSSL zostało zablokowane przez mozzille)…

    Odpowiedz
    • @Krzysiek: Zablokowane przez Mozillę? Sprawdziłeś dlaczego? Podpowiem: bo StartSSL przestało istnieć, a nie dlatego, że było darmowe albo „niepewne”. Markę przejęli Chińczycy, z którymi Mozilla zaczęła się rozprawiać dobry rok wcześniej.

      „Darmowe nie jest pewne”? No to ile zapłaciłeś za swoją przeglądarkę, której w tej chwili używasz do weryfikacji tych „drogich, więc bezpiecznych certyfikatów”? Nie wiem, skąd taka opinia, ale mniejsza z tym. WoSign, który podałeś jako argument, najtańszy certyfikat EV miał po 3000zł/rok, droższy po 5000zł/rok. Sam sobie podłożyłeś nogę w tej dyskusji.

      Certyfikaty EV oraz, jeśli chcesz płatny DV, nie są drogie. Tylko najpierw musisz zrozumieć, co kupujesz. Nie płacisz za magiczną „pewność”, bo wszyscy poważni CA — od darmowego LE czy Comodo⁽¹⁾, po najdroższe opcje — dają bezpieczeństwo na podobnym poziomie. To, co kupujesz i za co płacisz, to ubezpieczenie. Jeżeli sądzisz, że jest ono drogie, to znaczy, że po prostu wcale go nie potrzebujesz.
      ____
      [1] Jeśli uważasz, że Comodo oferuje „niepewne certyfikaty”, to lepiej wpadnij w przerażenie: zabezpieczają prawie połowę WWW.

      Odpowiedz
    • lcf

      1. Certyfikaty DV z powszechnie uznawanych CA można kupić w cenie za $8 / rok.
      2. Jeśli $8 / rok przekracza zakładany budżet i/lub lubimy automatyzować rzeczy, to można skorzystać z usług Let’s Encrypt, dostawcy automatycznie wydającego certyfikaty w oparciu o protokół ACME:
      https://letsencrypt.org/
      (rozwiązanie wykorzystywane m.in. przez sekurak.pl ;])

      Odpowiedz
  4. MG

    A może chcelibyście popisać w następnych częściach jeszcze o własnym CA, wewnętrznych drzewach, dobrych praktykach w zarządzaniu takimi oraz stosowaniu Mutual Authentication?

    Odpowiedz
  5. Tomasz

    Jak ktoś korzysta z usług hostingowych to i tak musi przesłać klucz prywatny w obce ręce.

    Odpowiedz
  6. erger

    tyle znakow i nikt nie napisal, ze klucz moze miec dowolna dlugosc. wystarczy np. 2050 a nie zaraz 4096

    Odpowiedz
  7. Pako

    NIE WIEM CZY DODAŁO …

    7zytałem drugą część artykułu, powróciłem do pierwszej i nadal mam mętlik w głowie, jak to działa.

    Ideę kryptografii asymetrycznej niby rozumiem. Jest para kluczy: publiczny, prywatny. Prywatny jest do podpisywania, a publiczny aby odbiorca tę informację odszyfrował. Jeśli nie pokręciłem.

    Więc o co chodzi z tym?

    „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.”

    Co robi tutaj ten certyfikat? Wiem że są certyfikaty serwera. Wiem że są klucze prywatne i publiczne. Jak to się wszystko ze sobą wiąże? Z góry dziękuję za łopatologiczne wytłumaczenie.

    Odpowiedz
  8. Pako

    Ktoś poratuje tymi podstawami o które pytam?

    Odpowiedz
    • Tomo

      Zobacz mój ostatni komentarz, bo nie mam pewności czy odpowiedziałem czy dodałem do ogólnego watku

      Odpowiedz
  9. Tomo
    Odpowiedz
  10. g
    Odpowiedz

Odpowiedz na mpan