Ein zusätzlicher Zeilenumbruch kann TLS nach CONNECT brechen

Wenn CONNECT 200 zurückgibt und TLS sofort nicht dekodieren kann, prüfen Sie die Grenzbytes im Connector, bevor Sie Zertifikate oder Cipher wechseln.

Ein generierter Autorisierungswert kann bereits mit einem Zeilenumbruch enden. Ein weiteres Zeilenende kann die HTTP-Header vorzeitig beenden und ein beabsichtigtes Host-Feld oder anderen Klartext hinter der Anfrage zurücklassen.

Eine minimale HTTP/1.1-CONNECT-Anfrage verwendet CRLF zwischen den Zeilen und eine Leerzeile am Ende:

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

Setzen Sie jedes Autorisierungsfeld vor diese letzte Leerzeile, ohne eingebetteten Zeilenumbruch. In Python steht "\n" für einen Zeilenumbruch; ein Rohstring mit einem Backslash und dem Buchstaben n nicht. Prüfen Sie, welche Bytes ein Kodierungshelfer erzeugt, bevor Sie sie entfernen—ältere Helfer konnten Zeilenumbrüche hinzufügen.

Nach erfolgreichem CONNECT gehören diese restlichen Bytes zum Tunnelprotokoll. Verirrter Klartext kann einen Peer erreichen, der TLS erwartet. Der Erfolgsstatus kann bereits in die Warteschlange gestellte Bytes nach einer fehlerhaften Anfrage nicht reparieren.

Prüfen Sie auch die Empfangsgrenze. Lesen Sie die vollständige Proxy-Antwort, bevor Sie den Socket an TLS übergeben, behandeln Sie Teil-Lesevorgänge und bewahren Sie alles auf, was über die Header hinaus gelesen wird. Ein Socket-Lesevorgang muss nicht eine ganze Nachricht enthalten.

Wenn Ihnen dieser Parser gehört, vergleichen Sie eine redigierte Byte-Darstellung mit der Wire-Grammatik; halten Sie Längen und Zeilengrenzen sichtbar, während Sie das Passwort verbergen. Für eine Anwendung, die nur eine Proxy-Verbindung benötigt, vermeidet ein gepflegter Connector, diesen Framing-Code besitzen zu müssen.