Przekierowywanie wybranych żądań HTTP z Squida na HTTPS
Zwracaj przekierowanie klienta dla znanych witryn obsługujących HTTPS zamiast po cichu zmieniać każdy pierwotny URL HTTP lub zakładać, że proxy może utworzyć obsługę TLS w źródle.
Squid może poprosić przeglądarkę o ponowienie wybranego URL HTTP przez HTTPS. Miejsce docelowe musi już udostępniać odpowiedni zasób przez HTTPS; uruchomienie Squida na Raspberry Pi nie tworzy tej możliwości w witrynie.
Dla interfejsu url_rewrite_program Squida 7 helper może zwrócić przekierowanie klienta, na przykład:
OK status=307 url="https://www.example.com/help"To jeden przykładowy odpowiedź helpera dla pasującego żądania, a nie kompletny program helpera. Przeglądarka otrzymuje przekierowanie i wysyła nowe żądanie do URL HTTPS. URL spoza polityki aktualizacji może otrzymać OK i pozostać niezmieniony.
Używaj znanej listy miejsc docelowych obsługujących HTTPS i analizuj przychodzący URL. Zachowaj zamierzony zasób i query, uwzględnij jawne porty i świadomie obsługuj metody żądań. Bezmyślne zastępowanie każdego prefiksu http zakłada, że każde źródło ma równoważną usługę HTTPS.
Helper musi odpowiadać na każdy wiersz wejściowy zgodnie z protokołem zainstalowanej wersji Squida. Jeśli włączono równoległe kanały helpera, zachowaj identyfikator kanału w odpowiedzi. Stary czysty przykład 301:URL nie jest wymienny z obecnym formatem result-and-key/value.
Wybierz przekierowanie klienta, gdy przeglądarka powinna poznać nowy URL. Odpowiedź rewrite-url zamiast tego prosi Squida o pobranie innego URL za pierwotnym żądaniem klienta, co może pozostawić adresy URL aplikacji i jej stan niespójne.
Początkowe żądanie HTTP dotarło już do Squida, zanim helper może je przekierować. Ta polityka nie może wstecznie ochronić tego żądania. TLS rozpoczyna się przy następnym połączeniu HTTPS; sam tunel CONNECT nie zapewnia żadnego szyfrowania.