Apache: czy zweryfikować łańcuch zaufania SSL, aby zapobiec atakom MITM?


11

Właśnie zdałem sobie sprawę, że ataki typu man-in-the-middle SSL są znacznie częstsze niż myślałem, szczególnie w środowiskach korporacyjnych. Słyszałem o kilku przedsiębiorstwach, które mają przezroczysty serwer proxy SSL. Wszyscy klienci są skonfigurowani do zaufania certyfikatu tego serwera proxy. Zasadniczo oznacza to, że pracodawca teoretycznie może przechwytywać nawet ruch szyfrowany za pomocą protokołu SSL bez wyskakujących ostrzeżeń w przeglądarce. Jak wspomniano powyżej, klienci pochodzą z zaufanym certyfikatem. Można to ujawnić jedynie poprzez ręczne sprawdzenie poprawności używanego certyfikatu.

Wydaje mi się, że pracodawca wykorzystuje swoją wyższą pozycję do szpiegowania ruchu SSL pracownika. Dla mnie powoduje to, że cała koncepcja SSL jest niewiarygodna. Z powodzeniem przetestowałem podobną konfigurację za pomocą mitmproxy i byłem w stanie odczytać komunikację między klientem a moim serwerem bankowości elektronicznej. To informacje, których nikomu nie należy ujawniać.

Zatem moje pytanie jest raczej proste: jak mogę zweryfikować łańcuch zaufania po stronie serwera? Chcę się upewnić, że klient korzysta z certyfikatu mojego serwera i tylko jednego łańcucha zaufania. Zastanawiam się, czy można to osiągnąć dzięki konfiguracji SSL Apache? Byłoby to wygodne, ponieważ można je łatwo zastosować do wielu aplikacji. Jeśli nie jest to możliwe, czy ktoś wie, jak to zrobić w PHP? Czy masz jakieś inne sugestie?


1
Jest ok, jeśli pracodawca widzi ruch pracowników. Korzystasz z zasobów pracodawcy (komputer, połączenia sieciowe itp.), To nie są twoje. A jeśli martwisz się, że emplyer może zobaczyć dane, które przesyłasz na swoje konto bankowe - rób to w domu, a nie w pracy. Próby naruszenia zasad bezpieczeństwa korporacyjnego mogą być przedmiotem postępowania sądowego przeciwko tobie.
Crypt32

2
W wielu europejskich firmach prywatne wykorzystanie sprzętu biurowego jest regulowane w umowie o pracę. W firmie, w której pracuję, mogę surfować prywatnie, to nie jest problem. Istnieją wyjątki, takie jak pornografia, udostępnianie plików itp. Jednocześnie istnieją przepisy zabraniające firmom szpiegującym ich pracowników. Dlatego dla mnie - i wielu innych - NIE jest w porządku, gdy pracodawcy przechwytują ruch pracowników, ponieważ jest to wyraźnie zabronione, podczas gdy prywatne surfowanie jest tolerowane w wielu firmach.
Aileron79

2
Większość (z mojego doświadczenia) stacji roboczych należących do rządu USA zawiera te dwa powiadomienia przy każdym logowaniu: „Komunikacja wykorzystująca lub dane przechowywane w tym IS nie są prywatne, podlegają rutynowemu monitorowaniu, przechwytywaniu i wyszukiwaniu i mogą zostać ujawnione lub wykorzystane do dowolnego autoryzowanego celu USG. IS obejmuje środki bezpieczeństwa (np. uwierzytelnianie i kontrolę dostępu) w celu ochrony interesów USG - nie dla osobistych korzyści lub prywatności ”. Korzystanie z tych systemów jest często objęte taką samą podpisaną umową. Kluczowym szczegółem jest to, że właściciel systemu chroni się przed tobą.
Randall,

To jedna z wielu różnic między USA a Europą. Warunki cytowane powyżej @Randall są nielegalne w większości krajów europejskich.
Aileron79

Warunki, które zacytowałem, są niekompletne, inne terminy zawierają listę działań, których wyraźnie nie należy monitorować. Nie mogę znaleźć żadnej wzmianki o tym, że europejscy pracodawcy nie mogą uczynić takich warunków warunkiem korzystania z ich komputerów (pracuję dla firmy działającej w Europie, która ustanawia takie procesy monitorowania, chociaż pracuję dla oddziału, który nie prowadzi działalności Europa), ale można znaleźć odniesienia, które sugerują, że takie warunki nie są nielegalne, o ile są wyraźne i przejrzyste.
Randall

Odpowiedzi:


9

Myślę, że to pytanie byłoby bardziej odpowiednie dla security.stackexchange.com, gdzie temat MITM jest omawiany w wielu pytaniach. Ale w każdym razie:

Sprawdzanie poprawności certyfikatu serwera odbywa się tylko na kliencie i nie można go w jakiś sposób przenieść na serwer, ponieważ sprawdzanie poprawności certyfikatu u klienta polega na tym, że klienci muszą upewnić się, że rozmawia z właściwym serwerem i nie mogą zaufać (niezaufany) serwer, aby podjąć decyzję dla klienta.

W przypadku przechwytywania SSL klient TLS z perspektywy serwera to zapora przechwytująca SSL / AV. Dlatego problemem po stronie serwera jest wykrycie, czy rozmawia on z oczekiwanym klientem (przeglądarką), czy nie (firewall / AV). Najbezpieczniejszym sposobem na to jest użycie certyfikatów klienta do uwierzytelnienia klienta - w rzeczywistości przechwytywanie protokołu SSL nie będzie działać, jeśli zostanie użyte uwierzytelnienie klienta, tzn. Uzgadnianie TLS nie powiedzie się, ponieważ MITM nie jest w stanie dostarczyć oczekiwanego certyfikatu klienta.

Tylko certyfikaty klienta są rzadko używane. Niepowodzenie uzgadniania TLS nie oznacza, że ​​klient może komunikować się z serwerem bez przechwytywania protokołu SSL, ale że klient nie może w ogóle komunikować się z serwerem. Alternatywnym sposobem byłoby użycie pewnej heurystyki do wykrycia rodzaju klienta TLS na podstawie odcisku palca uzgadniania TLS, tj. Rodzaju i kolejności szyfrów, użycia określonych rozszerzeń ... Podczas gdy proxy przechwytujące SSL mógłby teoretycznie naśladować oryginał ClientHello doskonale nie. Zobacz także Wykrywanie człowieka po środku dla serwera dla HTTPS lub sekcję III Heurystyka implementacji TLS w Wpływ na przechwytywanie HTTPS dla bezpieczeństwa .


14

Wydaje mi się, że pracodawca wykorzystuje swoją wyższą pozycję do szpiegowania ruchu SSL pracownika. Dla mnie powoduje to, że cała koncepcja SSL jest niewiarygodna

Problemem nie jest koncepcja SSL ani implementacja techniczna, ale raczej to, że ktoś inny ma pełną kontrolę nad jednym punktem końcowym połączenia, tj. Twoją stacją roboczą.
To jest podstawa rzeczywistego ryzyka bezpieczeństwa ...

Z punktu widzenia bezpieczeństwa zagrożona jest twoja stacja robocza, która przerywa łańcuch zaufania, który w normalnych okolicznościach uniemożliwia sukces MITM.

Jak mogę zweryfikować łańcuch zaufania po stronie serwera?

Nie możesz Odbywa się to po stronie klienta.

W zależności od przypadku użycia można zastosować przypinanie klucza publicznego HTTP RFC 7469, w którym wysłano dodatkowy nagłówek do klienta z listą (skrótami) rzeczywistych certyfikatów SSL lub używanych przez siebie urzędów certyfikacji.


4
HPKP nie pomoże, ponieważ zostanie zignorowany przez przeglądarki, jeśli certyfikat zostanie podpisany przez wyraźnie dodany urząd certyfikacji. Odbywa się to w szczególności w celu umożliwienia przechwytywania protokołu SSL przez zaufaną stronę, tj. Korporacyjną zaporę ogniową lub komputer stacjonarny AV (wiele z nich przechwytuje protokół SSL).
Steffen Ullrich,

2
Masz absolutną rację: §2.6 z RFC: „Dopuszczalne jest, aby zezwolić na wyłączanie sprawdzania poprawności PIN dla niektórych hostów zgodnie z lokalnymi zasadami. Na przykład, UA może wyłączyć sprawdzanie poprawności PIN dla przypiętych hostów, których sprawdzony łańcuch certyfikatów kończy się o zdefiniowana przez użytkownika kotwica zaufania, a nie wbudowana kotwica zaufania do UA (lub platformy bazowej). ”
HBruijn,

3

To zły sposób. Nie serwer sprawdza łańcuch zaufania. To jest klient. Dlatego powodem, dla którego firma korzysta z tego sposobu, jest zabezpieczenie środowiska firmy i sprawdzenie, co robi pracownik w swoim czasie pracy.


Tak, jestem świadomy, że prawdopodobnie nie można temu zapobiec tylko po stronie serwera. Jednak niektóre JS po stronie klienta mogą również zostać oszukane. BTW, szpiegowanie pracowników jest nielegalne w większości krajów europejskich. Jako operator strony internetowej chcę zapobiec oszukiwaniu moich klientów, dlatego zastanawiam się, czy jest jakiś sposób, aby w bezpieczny sposób zweryfikować łańcuch zaufania.
Aileron79

Może nie jest to dozwolone. Ale większość firm nie szpieguje pracowników, którzy chcą tylko zabezpieczyć sieć firmową, a większość filtrów internetowych lub skanerów musi zerwać połączenie SSL, aby to sprawdzić. To legalny mężczyzna w środku ataku
beli3ver

Rozumiem twój punkt widzenia. To pytanie dotyczy jednak tego, w jaki sposób mogę zapewnić szyfrowanie połączenia HTTPS od końca do końca. Konfiguracja, którą opisałem powyżej, jest bardzo powszechna w środowiskach korporacyjnych, ale ten sam rodzaj ataku może być zastosowany przez zazdrosnych chłopców do szpiegowania swoich dziewczyn lub przez właścicieli przechwytujących ruch najemców. Tych ludzi nadal trzeba oszukać, aby zainstalować certyfikat, ale to prosta część. Jest to jednak nielegalne - i wciąż zastanawiam się, czy jest jakiś sposób, aby upewnić się, że połączenie HTTPS naprawdę jest szyfrowane e2e.
Aileron79

3
To nie jest możliwe. Po zmianie certyfikatu głównego na kliencie nie można go sprawdzić. Serwer nie sprawdza, klient sprawdza.
beli3ver

3

Państwo mogłoby (niby), ale prawdziwe pytanie brzmi, czy POWINIEN .

Ale uwaga, nie jest to tak proste jak zmiana flagi w apache.conf.

Ponadto, ponieważ „atakujący” (np. Pracodawca) kontroluje komputer kliencki, zawsze może udaremnić twoje próby, jeśli są skłonni do zainwestowania wystarczającego wysiłku (z drugiej strony, chyba że jesteś bardzo dużą rybą, najprawdopodobniej nie są skłonni, abyś osiągnął swój cel, że Twoi użytkownicy nie będą mogli się z Tobą połączyć, chyba że będzie to bezpieczne))

  • możesz ponownie wdrożyć TLS w javascript i sprawdzić tam, czy certyfikat klienta jest połączony z certyfikatem twojej witryny.

  • jeśli masz szczęście , użytkownik może korzystać z przeglądarki, w której skrypt JavaScript po stronie klienta może uzyskać informacje o używanym certyfikacie zdalnym (a tym samym łatwo zweryfikować go na podstawie zakodowanej wartości certyfikatu serwera).

  • możesz użyć JavaScript, aby uruchomić niestandardowe szyfrowanie . Tak więc, nawet jeśli zła firma TLS MiTM odniosła sukces, nadal nie zapewniłaby jej dostępu do twoich danych. Oczywiście, jeśli są wystarczająco zainteresowani (a ponieważ kontrolują klienta), mogą po prostu w locie zastąpić bezpieczny skrypt javascript własnym, który również rejestruje (lub zmienia) wszystkie przesyłane informacje.

Ponadto, ponieważ firmy korzystające z serwerów proxy TLS MiTM zwykle również całkowicie kontrolują komputer kliencki, mogą równie łatwo zainstalować ekran i keylogger, aby po prostu nagrywać wideo wszystkiego, co widzi użytkownik, i rejestrować wszystkie naciśnięcia klawiszy (i ruchy myszy) tego typu użytkownika. Jak widać, gdy atakujący JEST klientem, nie ma absolutnie bezpiecznego sposobu na oszukanie go. To naprawdę tylko pytanie, jak bardzo będą zawracać sobie głowę ... A niektóre z powyższych rozwiązań mogą być dla Ciebie wystarczające.


możesz ponownie wdrożyć TLS w javascript ” Jak? Gdzie?
ciekawy

@curiousguy, że tekst qouted jest linkiem - kliknij na niego, a zaprowadzi Cię do kolejnego pytania i odpowiedzi, a wreszcie do projektu digitalbazaar / Forge
Matija Nalis

Kiedy to jest użyteczne? W jakim celu?
ciekawy

@curiousguy wśród wielu innych rzeczy, szczególnie do celów zadanych w tym pytaniu dotyczącym błędu serwera. Gdy masz własny JS TLS uruchomiony na kliencie, ten klient JS będzie dokładnie wiedział, z którym serwerem TLS klient został podłączony (i jest to klucz publiczny). Następnie możesz porównać ten klucz publiczny z kluczem publicznym autoryzowanego serwera (również zapisanym na stałe w JS) i czy będziesz wiedział, czy są takie same. Jeśli nie są takie same, połączenie zostało przejęte przez MiTM.
Matija Nalis
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.