Breng de CONNECT-buffer van Beast de TLS-handshake in

Geef de bytes die na een CONNECT-antwoord achterblijven door aan de gebufferde TLS-handshake van Asio en verbruik daarna precies de hoeveelheid die hij heeft gebruikt.

Nadat Beast de CONNECT-antwoordheader van een proxy heeft gelezen, controleer je zowel de responsstatus als de dynamische buffer. De leesbewerking kan bytes voorbij het einde van de header ophalen en in de meegegeven buffer bewaren. Als je TLS start met een overload die alleen de socket leest, blijven die bewaarde bytes buiten het TLS-invoerpad.

Voor een WebSocket-stream waarvan de volgende laag de SSL-stream is, gebruik je de gebufferde handshake-overload. In een bestaande yield_context-sessie, waarbij buffer tijdens alle bewerkingen in leven blijft:

http::response_parser<http::empty_body> response;
http::async_read_header(
    beast::get_lowest_layer(ws), buffer, response, yield[ec]);
if (ec) return;

auto status = response.get().result_int();
if (status < 200 || status >= 300) return;

std::size_t used = ws.next_layer().async_handshake(
    ssl::stream_base::client, buffer.data(), yield[ec]);
if (ec) return;
buffer.consume(used);

De vroege returns zijn de faaluitgangen van de sessie; koppel daar de gebruikelijke foutrapportage en opschoning aan. Alleen een geslaagd CONNECT-antwoord brengt de tunnel tot stand. Een afwijzingspagina mag geen TLS-invoer worden.

De gebufferde overload eindigt met een foutcode en een byteaantal. Dat aantal beschrijft hoeveel bytes hij uit de meegegeven buffers heeft verbruikt. Verwijder na afloop precies dat voorvoegsel met consume(used). Maak de buffer niet leeg voordat de bewerking begint, wijzig de opslag niet terwijl de handshake wacht, en ga er niet van uit dat de bewerking elke meegegeven byte heeft verbruikt.

Bij gewone door de client gestarte TLS direct na CONNECT kan de buffer leeg zijn. De overload behandelt dat geval ook. Het doel is streamgrenzen te bewaren; hij maakt willekeurige volgende proxygegevens niet tot geldige TLS. Houd de verificatie van de doelserverhostnaam en de SNI-configuratie op de SSL-laag vóór de handshake, en start de WebSocket-upgrade pas nadat TLS is geslaagd.

Gerelateerde artikelen