Proxy HTTPS oznacza dwa połączenia TLS, a nie jedno

Etykieta proxy HTTPS opisuje wyłącznie transport między klientem a proxy i nic więcej. Nie mówi, że witryna za nim jest szyfrowana przez to samo połączenie, ani że proxy może odczytać stronę. Gdy rozdzielisz oba połączenia, błędy certyfikatów przestają być zagadkowe, a porównanie z VPN staje się konkretne.

Dwie pary punktów końcowych, dwie weryfikacje

W zwykłym trybie tunelu istnieją dwie relacje TLS. Pierwsza biegnie od klienta do proxy i uwierzytelnia proxy. Druga biegnie od klienta do witryny wewnątrz tunelu i uwierzytelnia witrynę. Zawodzą niezależnie i są konfigurowane niezależnie.

Mają odrębne decyzje o zaufaniu, odrębne łańcuchy certyfikatów i odrębne komunikaty o błędach. Proxy korzystające z organizacyjnego CA i publiczna witryna korzystająca z publicznego łańcucha mogą legalnie wymagać innej konfiguracji weryfikacji, i nie jest to błędna konfiguracja.

Traktuj je jako dwa połączenia, które przypadkiem dzielą jeden socket, bo właśnie tym są.

Co CONNECT faktycznie tuneluje

Klient wysyła żądanie CONNECT z nazwą hosta i portu, a proxy otwiera połączenie TCP do tego celu. Po odpowiedzi proxy kolejne bajty są przekazywane bez interpretacji, dlatego uzgadnianie TLS witryny przechodzi przez proxy nietknięte. Proxy poznaje więc nazwę celu i metadane połączenia, ale nie otrzymuje odszyfrowanych stron z tego układu.

Ta różnica to cały argument bezpieczeństwa trybu tunelu i zarazem jego granica.

Proxy HTTP bez TLS na przeskoku proxy nadal przenosi witrynę HTTPS przez CONNECT. Wymiana klient-proxy odbywa się jawnie, a połączenie z witryną nie, i nazywanie całości proxy HTTPS ukrywa tę różnicę.

Który certyfikat zawiódł

Gdy weryfikacja zawodzi, przeczytaj punkt końcowy nazwany w błędzie, zanim zmienisz jakiekolwiek ustawienie zaufania. Oba błędy wyglądają w terminalu podobnie i wskazują na zupełnie różne poprawki, dlatego pierwsze pytanie zawsze brzmi, które połączenie odmówiło.

curl rozdziela opcje dokładnie z tego powodu. Plik CA proxy konfiguruje weryfikację proxy, natomiast plik CA konfiguruje weryfikację serwera, a zachowanie właściwego magazynu zaufania zależy również od tego, jak zbudowano curl.

curl -v --proxy https://proxy.example.net:443 \
  --proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/

Tłumienie sprawdzenia nie jest naprawą. Nic nie dowodzi o którymkolwiek z dwóch punktów końcowych.

Inspekcja to inny układ

Inspekcja TLS nie jest tunelowaniem. Pośrednik inspekcjonujący kończy relację zaufania wobec witryny i przedstawia klientowi własny certyfikat, więc klient weryfikuje pośrednika, a nie witrynę. Może to być zgodne z prawem w ramach zatwierdzonego projektu, i jest to zasadniczo inne twierdzenie niż przekazywanie bajt po bajcie. Nie zakładaj, że każde proxy inspekcjonuje, i nie zakładaj, że szyfrowany przeskok proxy to wyklucza.

Organizacyjny CA w magazynie zaufania to wskazówka, w jakim układzie się znajdujesz, a nie dowód. Zapytaj o projekt, zamiast wnioskować go z łańcucha certyfikatów.

Te dwa układy dają różne odpowiedzi na pytanie, kto może odczytać stronę.

Porównaj proxy i VPN w tych samych czterech wierszach

Porównanie staje się użyteczne dopiero wtedy, gdy oba wdrożenia opisano w ten sam sposób.

Proxy skonfigurowane dla jednego żądania obejmuje to żądanie. Nie przepuszcza przez siebie każdego procesu w urządzeniu, a przykładowe polecenie jest dokładnie tak wąskie. Zasięg VPN zależy od jego routingu i polityki aplikacji, które również trzeba sprawdzić, a nie zakładać. Żadna z opcji nie obejmuje wszystkiego tylko dlatego, że została zainstalowana.

Zapisz cztery wiersze dla każdej opcji, a spór zwykle rozwiązuje się sam. Użyteczne porównanie to nie to, która etykieta brzmi bardziej zaszyfrowanie. Lecz to, które segmenty są chronione, kto jest weryfikowany na ich końcach, którym pośrednikom ufasz i jaki ruch polityka faktycznie obejmuje.