Jeden dodatkowy znak nowej linii może zepsuć TLS po CONNECT
Sprawdź ramkowanie nagłówków HTTP, gdy ręcznie napisany łącznik proxy otwiera tunel i natychmiast daje błąd dekodowania TLS.
Gdy CONNECT zwraca 200, a TLS natychmiast nie może zdekodować, sprawdź bajty graniczne w łączniku, zanim zmienisz certyfikaty lub szyfry.
Wygenerowana wartość autoryzacji może już kończyć się znakiem nowej linii. Dodanie kolejnego końca linii może przedwcześnie zakończyć nagłówki HTTP, pozostawiając zamierzone pole Host lub inny zwykły tekst za żądaniem.
Minimalne żądanie HTTP/1.1 CONNECT używa CRLF między wierszami i pustej linii na końcu:
b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"Umieść dowolne pole autoryzacji przed tą ostatnią pustą linią, bez osadzonego podziału wiersza. W Pythonie "\n" oznacza nową linię; surowy ciąg zawierający ukośnik wsteczny i literę n nie. Sprawdź, jakie bajty tworzy pomocnik kodowania, zanim spróbujesz je usunąć—starsze pomocniki mogły dodawać podziały wierszy.
Gdy CONNECT się powiedzie, te pozostałe bajty należą do protokołu tunelu. Zabłąkany zwykły tekst może dotrzeć do partnera oczekującego TLS. Pomyślny status nie naprawi bajtów już ustawionych w kolejce po błędnym żądaniu.
Sprawdź także granicę odbioru. Przeczytaj pełną odpowiedź proxy, zanim przekażesz gniazdo do TLS, obsłuż częściowe odczyty i zachowaj wszystko, co odczytano poza nagłówkami. Jeden odczyt gniazda nie musi zawierać jednej całej wiadomości.
Jeśli ten parser jest twój, porównaj zredagowaną reprezentację bajtów z gramatyką przewodu; utrzymuj widoczne długości i granice wierszy, ukrywając hasło. Dla aplikacji, która potrzebuje tylko połączenia proxy, utrzymywany łącznik pozwala uniknąć konieczności posiadania tego kodu ramkowania.