Robert Heaton

HTTPS jest po prostu standardowym protokołem HTTP pokrytym hojną warstwą pysznego szyfrowania SSL/TLS. O ile coś nie pójdzie strasznie źle (a może pójść), uniemożliwia to ludziom takim jak niesławna Eve przeglądanie lub modyfikowanie żądań, które składają się na Twoje doświadczenie przeglądania; to właśnie dzięki temu Twoje hasła, komunikacja i dane kart kredytowych są bezpieczne na drodze między Twoim komputerem a serwerami, do których chcesz wysłać te dane. Podczas gdy mała zielona kłódka i litery „https” w pasku adresu nie oznacza, że nie ma jeszcze wystarczająco dużo liny zarówno dla Ciebie i strony internetowej, którą przeglądasz do powieszenia się gdzie indziej, oni przynajmniej pomóc komunikować się bezpiecznie, podczas gdy you do so.

Co to jest HTTPS i co to robi?

HTTPS bierze dobrze znany i zrozumiany protokół HTTP, i po prostu warstwy SSL/TLS (dalej określane po prostu jako „SSL”) warstwa szyfrowania na nim. Serwery i klienci nadal mówią do siebie dokładnie tym samym HTTP, ale przez bezpieczne połączenie SSL, które szyfruje i odszyfrowuje ich żądania i odpowiedzi. Warstwa SSL ma dwa główne cele:

• Weryfikacja, że rozmawiasz bezpośrednio z serwerem, z którym myślisz, że rozmawiasz
• Zapewnienie, że tylko serwer może odczytać to, co mu wysyłasz, i tylko ty możesz odczytać to, co on odsyła

Naprawdę, naprawdę sprytną częścią jest to, że każdy może przechwycić każdą z wiadomości wymienianych z serwerem, w tym te, w których uzgadniasz klucz i strategię szyfrowania do użycia, i nadal nie być w stanie odczytać żadnych z rzeczywistych danych, które wysyłasz.

Jak jest ustanawiane połączenie SSL

Połączenie SSL między klientem a serwerem jest ustanawiane przez handshake, którego celami są:

• Zaspokojenie klienta, że rozmawia z właściwym serwerem (i opcjonalnie visa versa)
• Aby strony uzgodniły „zestaw szyfrów”, który zawiera algorytm szyfrowania, którego będą używać do wymiany danych
• Aby strony uzgodniły niezbędne klucze dla tego algorytmu

Po ustanowieniu połączenia, obie strony mogą używać uzgodnionego algorytmu i kluczy do bezpiecznego wysyłania wiadomości do siebie. Podzielimy uścisk dłoni na 3 główne fazy – Hello, wymianę certyfikatów i wymianę kluczy.

1. Hello – Uścisk dłoni rozpoczyna się od wysłania przez klienta wiadomości ClientHello. Zawiera ona wszystkie informacje, których serwer potrzebuje, aby połączyć się z klientem poprzez SSL, w tym różne zestawy szyfrów i maksymalną wersję SSL, którą obsługuje. Serwer odpowiada komunikatem ServerHello, który zawiera podobne informacje wymagane przez klienta, w tym decyzję opartą na preferencjach klienta co do tego, który zestaw szyfrów i wersja SSL zostaną użyte.

2. Wymiana certyfikatów – Teraz, gdy kontakt został nawiązany, serwer musi udowodnić swoją tożsamość klientowi. Służy do tego certyfikat SSL, który jest trochę jak paszport. Certyfikat SSL zawiera różne dane, w tym nazwę właściciela, własność (np. domenę), do której jest przypisany, klucz publiczny certyfikatu, podpis cyfrowy oraz informacje o terminie ważności certyfikatu. Klient sprawdza, czy albo domyślnie ufa certyfikatowi, albo czy jest on zweryfikowany i zaufany przez jeden z kilku urzędów certyfikacji (CA), którym również domyślnie ufa. Więcej o tym za chwilę. Zauważ, że serwer może również wymagać certyfikatu w celu potwierdzenia tożsamości klienta, ale zazwyczaj ma to miejsce tylko w bardzo wrażliwych zastosowaniach.

3. Wymiana kluczy – Szyfrowanie rzeczywistych danych wiadomości wymienianych przez klienta i serwer będzie się odbywało przy użyciu algorytmu symetrycznego, którego dokładny charakter został już uzgodniony podczas fazy powitania. Algorytm symetryczny używa pojedynczego klucza zarówno do szyfrowania jak i deszyfrowania, w przeciwieństwie do algorytmów asymetrycznych, które wymagają pary kluczy publiczny/prywatny. Obie strony muszą uzgodnić ten pojedynczy klucz symetryczny, który to proces jest bezpiecznie realizowany przy użyciu szyfrowania asymetrycznego i kluczy publicznych/prywatnych serwera.

Klient generuje losowy klucz, który ma być użyty w głównym algorytmie symetrycznym. Szyfruje go przy użyciu algorytmu uzgodnionego również podczas fazy Hello oraz klucza publicznego serwera (znajdującego się na jego certyfikacie SSL). Wysyła ten zaszyfrowany klucz do serwera, gdzie jest on odszyfrowywany przy użyciu klucza prywatnego serwera, a interesujące części handshake’u są zakończone. Strony są wystarczająco zadowolone, że rozmawiają z właściwą osobą, i potajemnie uzgodniły klucz do symetrycznego szyfrowania danych, które mają sobie nawzajem przesłać. Żądania i odpowiedzi HTTP mogą być teraz wysyłane poprzez utworzenie wiadomości w postaci jawnego tekstu, a następnie zaszyfrowanie jej i wysłanie. Druga strona jest jedyną, która wie, jak odszyfrować tę wiadomość, więc atakujący Man In The Middle nie są w stanie odczytać lub zmodyfikować żądań, które mogą przechwycić.

Certyfikaty

Na swoim najbardziej podstawowym poziomie, certyfikat SSL jest po prostu plikiem tekstowym i każdy, kto posiada edytor tekstu, może go stworzyć. Można w prosty sposób stworzyć certyfikat potwierdzający, że jest się firmą Google Inc. i kontroluje się domenę gmail.com. Gdyby to była cała historia, SSL byłby żartem; weryfikacja tożsamości polegałaby zasadniczo na tym, że klient pytałby serwer „czy jesteś Google?”, serwer odpowiadałby „er, yeah totally, here’s a piece of paper with 'I am Google’ written on it”, a klient mówiłby „OK świetnie, oto wszystkie moje dane”. Magia, która zapobiega tej farsie jest w podpisie cyfrowym, który pozwala stronie zweryfikować, że kawałek papieru innej strony jest naprawdę legalny.

Istnieją dwa rozsądne powody, dla których możesz zaufać certyfikatowi:

• Jeśli znajduje się na liście certyfikatów, którym ufasz implicite
• Jeśli jest w stanie udowodnić, że jest zaufany przez administratora jednego z certyfikatów z powyższej listy

Pierwsze kryterium jest łatwe do sprawdzenia. Twoja przeglądarka ma preinstalowaną listę zaufanych certyfikatów SSL z urzędów certyfikacji (CA), które możesz przeglądać, dodawać i usuwać. Certyfikaty te są kontrolowane przez scentralizowaną grupę (w teorii i na ogół w praktyce) niezwykle bezpiecznych, wiarygodnych i godnych zaufania organizacji, takich jak Symantec, Comodo czy GoDaddy. Jeśli serwer prezentuje certyfikat z tej listy, to wiesz, że możesz mu zaufać.

Drugie kryterium jest znacznie trudniejsze. Serwer może łatwo powiedzieć „er yeah, my name is er, Microsoft, you trust Symantec and er, they totally trust me, so it’s all cool”. Nieco sprytny klient może wtedy pójść i zapytać Symantec „Mam tu Microsoft, który mówi, że im ufasz, czy to prawda?”. Ale nawet jeśli Symantec powie „yep, znamy ich, Microsoft są legalni”, nadal nie wiesz, czy serwer podający się za Microsoft faktycznie jest Microsoftem, czy czymś znacznie gorszym. Tu właśnie wkraczają podpisy cyfrowe.

3.2 Podpisy cyfrowe

Jak już wspomniano, certyfikaty SSL mają powiązaną parę kluczy publiczny/prywatny. Klucz publiczny jest dystrybuowany jako część certyfikatu, a klucz prywatny jest niewiarygodnie bezpiecznie strzeżony. Ta para kluczy asymetrycznych jest używana w SSL handshake do wymiany kolejnych kluczy dla obu stron w celu symetrycznego szyfrowania i deszyfrowania danych. Klient używa klucza publicznego serwera do zaszyfrowania klucza symetrycznego i bezpiecznego wysłania go do serwera, a serwer używa swojego klucza prywatnego do jego odszyfrowania. Każdy może szyfrować za pomocą klucza publicznego, ale tylko serwer może odszyfrować za pomocą klucza prywatnego.

Odwrotna sytuacja ma miejsce w przypadku podpisu cyfrowego. Certyfikat może być „podpisany” przez inny organ, w którym to przypadku organ ten w istocie udowadnia, że „sprawdziliśmy, że kontroler tego certyfikatu kontroluje również nieruchomość (domenę) wymienioną na certyfikacie”. W tym przypadku organ używa swojego klucza prywatnego do (ogólnie mówiąc) zaszyfrowania treści certyfikatu, a ten szyfrowany tekst jest dołączony do certyfikatu jako jego podpis cyfrowy. Każdy może odszyfrować ten podpis za pomocą klucza publicznego urzędu i zweryfikować, czy jego wynikiem jest oczekiwana odszyfrowana wartość. Ale tylko autorytet może zaszyfrować treść przy użyciu klucza prywatnego, a więc tylko on może w ogóle złożyć ważny podpis.

Jeśli więc pojawi się serwer twierdzący, że ma certyfikat dla Microsoft.com podpisany przez Symantec (lub inny CA), Twoja przeglądarka nie musi wierzyć mu na słowo. Jeśli jest to legalne, Symantec użyje swojego (ultra-tajnego) klucza prywatnego do wygenerowania podpisu cyfrowego certyfikatu SSL serwera, a więc Twoja przeglądarka może użyć ich (ultra-publicznego) klucza publicznego, aby sprawdzić, czy ten podpis jest ważny. Firma Symantec podjęła kroki, aby upewnić się, że organizacja, dla której podpisuje certyfikat, naprawdę jest właścicielem Microsoft.com, więc biorąc pod uwagę, że klient ufa firmie Symantec, może być pewny, że naprawdę rozmawia z Microsoft Inc.

3.3 Samopodpisywanie

Zauważ, że wszystkie certyfikaty głównego CA są „samopodpisane”, co oznacza, że podpis cyfrowy jest generowany przy użyciu własnego klucza prywatnego certyfikatu. Nie ma nic szczególnego w certyfikacie głównego urzędu certyfikacji – możesz wygenerować swój własny samopodpisany certyfikat i użyć go do podpisania innych certyfikatów, jeśli chcesz. Ale ponieważ Twój losowy certyfikat nie jest wstępnie załadowany jako CA do żadnej przeglądarki, żadna z nich nie zaufa Ci do podpisywania własnych lub innych certyfikatów. Skutecznie mówisz „er yeah, I’m totally Microsoft, here’s an official certificate of identity issued and signed by myself”, a wszystkie poprawnie działające przeglądarki wyrzucą bardzo przerażający komunikat o błędzie w odpowiedzi na Twoje podejrzane poświadczenia.

This puts an enormous burden on all browser and OS publishers to trust only squeaky clean root CAs, as these are the organisations that their users end up trusting to vet site and keep certificates safe. Nie jest to łatwe zadanie.

3.4 What are you trusting?

Ciekawe jest to, że Twój klient technicznie nie próbuje sprawdzić, czy powinien zaufać stronie, która wysłała mu certyfikat, ale czy powinien zaufać kluczowi publicznemu zawartemu w certyfikacie. Certyfikaty SSL są całkowicie jawne i publiczne, więc każdy atakujący mógłby przechwycić certyfikat Microsoftu, przechwycić żądanie klienta skierowane do Microsoft.com i przedstawić mu legalny certyfikat. Klient zaakceptowałby to i z radością rozpocząłby handshake. Jednak gdy klient zaszyfruje klucz, który zostanie użyty do faktycznego szyfrowania danych, zrobi to przy użyciu prawdziwego klucza publicznego Microsoftu z tego prawdziwego certyfikatu. Ponieważ osoba atakująca nie posiada klucza prywatnego Microsoftu, aby go odszyfrować, utknęła w martwym punkcie. Nawet jeśli handshake zostanie zakończony, nadal nie będzie w stanie odszyfrować klucza, a więc nie będzie w stanie odszyfrować żadnych danych, które klient do niego wysyła. Porządek jest zachowany tak długo, jak długo atakujący nie kontroluje klucza prywatnego zaufanego certyfikatu. Jeśli klient zostanie w jakiś sposób oszukany, aby zaufać certyfikatowi i kluczowi publicznemu, którego klucz prywatny jest kontrolowany przez atakującego, zaczynają się kłopoty.

4.1 Czy kawiarnia może monitorować mój ruch HTTPS w swojej sieci? Magia kryptografii z kluczem publicznym oznacza, że napastnik może oglądać każdy bajt danych wymienianych między klientem a serwerem i nadal nie mają pojęcia, co mówisz do siebie poza mniej więcej jak dużo danych wymieniasz. Jednak normalny ruch HTTP jest nadal bardzo podatne na niepewnej sieci Wi-Fi, a flimsy strona może paść ofiarą dowolnej liczby obejść, które jakoś oszukać do wysyłania ruchu HTTPS albo przez zwykły HTTP lub po prostu do niewłaściwego miejsca całkowicie. Na przykład, nawet jeśli formularz logowania przesyła nazwę użytkownika / hasło combo przez HTTPS, jeśli sam formularz jest ładowany niezabezpieczone przez HTTP następnie atakujący może przechwycić formularza HTML w drodze do maszyny i zmodyfikować go do wysyłania szczegółów logowania do własnych endpoint.

4.2 Czy moja firma może monitorować mój ruch HTTPS w ich sieci?

Jeśli używasz również maszyny kontrolowanej przez firmę, a następnie tak. Pamiętaj, że u podstaw każdego łańcucha zaufania leży implicite zaufany CA, i że lista tych władz jest przechowywana w przeglądarce. Twoja firma może wykorzystać dostęp do Twojego komputera, aby dodać do tej listy własne, samodzielnie podpisane certyfikaty. Mogliby wtedy przechwytywać wszystkie żądania HTTPS, prezentując certyfikaty twierdzące, że reprezentują odpowiednią stronę internetową, podpisane przez ich fake-CA i dlatego bezsprzecznie zaufane przez przeglądarkę. Ponieważ byłbyś szyfrowania wszystkich swoich żądań HTTPS przy użyciu ich dodgy certyfikat klucz publiczny, mogliby użyć odpowiedniego klucza prywatnego do odszyfrowania i sprawdzić (nawet modyfikować) swoje żądanie, a następnie wysłać go do jego zamierzonej lokalizacji. Prawdopodobnie tego nie robią. Ale mogliby.

Nawiasem mówiąc, jest to również sposób, w jaki używasz proxy do inspekcji i modyfikacji inaczej niedostępne żądania HTTPS wykonane przez iPhone app.

4.3 Więc co się stało z Lavabit i FBI?

Lavabit był super-secure Edwarda Snowdena dostawcy poczty elektronicznej podczas NSA wycieki szaleństwo 2013. Jak widzieliśmy, żadna ilość standardowych włamań nie mogła pozwolić FBI na zobaczenie jakichkolwiek danych w drodze pomiędzy Lavabit i jego klientami. Bez klucza prywatnego do certyfikatu SSL Lavabit, agencja miała przechlapane. Pomocny sędzia amerykański powiedział jednak założycielowi Lavabit, Ladarowi Levisonowi, że musi on przekazać ten klucz, dając tym samym FBI wolną rękę w szpiegowaniu ruchu sieciowego do woli. Levison podjął odważną próbę gry na zwłokę, przekazując 2560 znakowy klucz na 11 stronach 4-punktowej czcionki, ale został ukarany nakazem przekazania klucza w użytecznym formacie lub karą 5 000 dolarów dziennie, dopóki tego nie zrobi.

Gdy się do tego zastosował, GoDaddy, CA Lavabit, unieważniło certyfikat, uznając go (słusznie) za zagrożony. W ten sposób certyfikat Lavabit został dodany do listy CRL (Certificate Revocation List), czyli listy zdyskredytowanych certyfikatów, którym klienci nie powinni już ufać, aby zapewnić bezpieczne połączenie. Skompromitowane, samopodpisane lub w inny sposób niegodne zaufania certyfikaty powodują, że przeglądarki wyświetlają duży czerwony komunikat o błędzie i albo zniechęcają użytkownika do dalszych działań, albo całkowicie ich zabraniają. Niestety, przeglądarki będą nadal ufać uszkodzonym certyfikatom, dopóki nie wyciągną najnowszych aktualizacji z listy CRL, co w praktyce jest najwyraźniej niedoskonałe.

Podsumowanie

HTTPS nie jest nie do złamania, a protokół SSL musi stale ewoluować, w miarę jak odkrywane są i niszczone nowe ataki na niego. Jest to jednak wciąż imponująco solidny sposób na przesyłanie tajnych danych bez troski o to, kto zobaczy twoje wiadomości. Istnieje oczywiście wiele szczegółów implementacji nie wspomniane tutaj, takie jak dokładny format i kolejność wiadomości handshake, skrócone handshakes odebrać ostatnie sesje bez konieczności renegocjacji kluczy i zestawów szyfrów, a liczne różne opcje szyfrowania dostępne na każdym etapie. Kluczową rzeczą do zapamiętania jest to, że podczas gdy HTTPS utrzymuje dane bezpieczne na przewodzie do miejsca przeznaczenia, to w żaden sposób nie chroni cię (jako użytkownika lub dewelopera) przed XSS lub wycieków bazy danych lub innych rzeczy, które-go-bump-in-the-noc. Ciesz się, że ma twoje plecy, ale bądź czujny. In the immortal words of Will Smith, „Walk in shadow, move in silence, guard against extra-terrestrial violence.”

If you enjoyed this, you’ll probably enjoy my post explaining the details of 2015’s FREAK vulnerability in SSL.

.