Flytt Beasts CONNECT-buffer inn i TLS-handtrykket

Etter at Beast har lese CONNECT-svarhovudet til ein proxy, undersøk både svarstatusen og den dynamiske bufferen. Lesoperasjonen kan hente byte utover slutten på hovudet og halde dei i bufferen som vart send med. Viss du startar TLS med ei overbelasting som berre les sockelen, blir dei haldne byta liggjande utanfor TLS-inndatavegen.

For ein WebSocket-straum der neste lag er SSL-straumen, bruk den bufre handtrykk-overbelastinga. I ein eksisterande yield_context-økt, med buffer halden i live gjennom alle operasjonane:

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);

Dei tidlege returane er feilutgangane til økta; knytt den vanlege feilrapporteringa og oppryddinga der. Berre eit vellukka CONNECT-svar etablerer tunnelen. Ei avvising av ei side må ikkje bli TLS-inndata.

Den bufre overbelastinga blir fullført med ein feilkode og eit bytetal. Talet skildrar kor mange byte ho brukte frå bufferane som vart sende med. Etter fullføringa fjernar du nøyaktig det prefikset med consume(used). Ikkje tøm bufferen før operasjonen startar, ikkje endre lagringa mens handtrykket ventar, og ikkje gå ut frå at operasjonen brukte kvar byte som vart send med.

Med vanleg klientinitiert TLS rett etter CONNECT kan bufferen vere tom. Overbelastinga handterer også det tilfellet. Føremålet er å ta vare på straumgrenser; ho gjer ikkje vilkårlege påfølgjande proxy-data til gyldig TLS. Hald vertsnamnverifiseringa for målet og SNI-konfigurasjonen på SSL-laget før handtrykket, og start WebSocket-oppgraderinga først etter at TLS har lukkast.