Eén extra nieuwe regel kan TLS na CONNECT breken
Inspecteer de HTTP-headerframing wanneer een handgeschreven proxyconnector een tunnel opent en direct een TLS-decodeerfout geeft.
Wanneer CONNECT 200 teruggeeft en TLS direct niet kan decoderen, inspecteer de grensbytes in de connector voordat je certificaten of cijfers wijzigt.
Een gegenereerde autorisatiewaarde kan al eindigen met een nieuwe regel. Nog een regeleinde toevoegen kan de HTTP-headers te vroeg beëindigen, waardoor een bedoeld Host-veld of andere platte tekst achter het verzoek blijft.
Een minimaal HTTP/1.1 CONNECT-verzoek gebruikt CRLF tussen regels en een lege regel aan het einde:
b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"Plaats elk autorisatieveld vóór die laatste lege regel, zonder ingebedde regelafbreking. In Python staat "\n" voor een nieuwe regel; een onbewerkte tekenreeks met een backslash en de letter n niet. Controleer welke bytes een coderingshulp produceert voordat je ze probeert te verwijderen—oudere hulpen konden regeleinden toevoegen.
Zodra CONNECT slaagt, horen die resterende bytes bij het tunnelprotocol. Verdwaalde platte tekst kan een peer bereiken die TLS verwacht. De successtatus kan bytes die al in de wachtrij staan na een misvormd verzoek niet repareren.
Inspecteer ook de ontvangstgrens. Lees het volledige proxyantwoord voordat je de socket aan TLS geeft, behandel gedeeltelijke leesbewerkingen en bewaar alles wat voorbij de headers wordt gelezen. Eén socketleesbewerking hoeft niet één volledig bericht te bevatten.
Als deze parser van jou is, vergelijk dan een geredigeerde byteweergave met de draadgrammatica; houd lengtes en regelgrenzen zichtbaar terwijl je het wachtwoord verbergt. Voor een toepassing die alleen een proxyverbinding nodig heeft, vermijdt een onderhouden connector de noodzaak om deze framingcode te bezitten.