Един нов ред може да счупи TLS след CONNECT

Когато CONNECT върне 200 и TLS веднага не успее да декодира, проверете граничните байтове в конектора, преди да сменяте сертификати или шифри.

Генерирана стойност за оторизация може вече да завършва с нов ред. Добавянето на още един край на ред може да приключи HTTP заглавките преждевременно и да остави желаното поле Host или друг открит текст зад заявката.

Минимална HTTP/1.1 CONNECT заявка използва CRLF между редовете и празен ред в края:

b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"

Поставете всяко поле за оторизация преди този последен празен ред, без вграден нов ред. В Python "\n" означава нов ред; суров низ с обратна наклонена черта и буквата n — не. Проверете какви байтове произвежда помощникът за кодиране, преди да се опитате да ги премахнете—по-старите помощници може да добавят нови редове.

След успешен CONNECT тези останали байтове принадлежат на тунелния протокол. Отклонил се открит текст може да достигне до партньор, който очаква TLS. Успешният статус не може да поправи байтове, вече поставени в опашка след неправилна заявка.

Проверете и границата на получаване. Прочетете пълния отговор на проксито, преди да предадете сокета на TLS, обработвайте частичните четения и запазвайте всичко прочетено след заглавките. Едно четене на сокет не е длъжно да съдържа едно цяло съобщение.

Ако този парсер е ваш, сравнете редактирано представяне на байтовете с граматиката на връзката; дръжте дължините и границите на редовете видими, като криете паролата. За приложение, което се нуждае само от прокси връзка, поддържан конектор избягва необходимостта да притежавате този код за рамкиране.