Flytt Beasts CONNECT-buffer inn i TLS-håndtrykket

Etter at Beast har lest CONNECT-svarhodet til en proxy, må du undersøke både svarstatusen og den dynamiske bufferen. Lesoperasjonen kan hente byte utover hodets slutt og beholde dem i den medsendte bufferen. Hvis du starter TLS med en overbelastning som bare leser sockelen, blir de beholdte byte-ene liggende utenfor TLS-inndataveien.

For en WebSocket-strøm der neste lag er SSL-strømmen, bruk den bufrede håndtrykk-overbelastningen. I en eksisterende yield_context-økt, med buffer holdt i live gjennom alle operasjonene:

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 tidlige returene er øktas feilutganger; knytt den vanlige feilrapporteringen og oppryddingen der. Bare et vellykket CONNECT-svar etablerer tunnelen. En avvisningsside må ikke bli TLS-inndata.

Den bufrede overbelastningen fullføres med en feilkode og et byteantall. Tallet beskriver hvor mange byte den forbrukte fra de medsendte bufferne. Etter fullføringen fjerner du nøyaktig det prefikset med consume(used). Ikke tøm bufferen før operasjonen starter, ikke endre lagringen mens håndtrykket venter, og ikke anta at operasjonen forbrukte hver medsendt byte.

Med vanlig klientinitiert TLS rett etter CONNECT kan bufferen være tom. Overbelastningen håndterer også det tilfellet. Formålet er å bevare strømgrenser; den gjør ikke vilkårlige påfølgende proxy-data til gyldig TLS. Behold vertsnavnverifiseringen for målet og SNI-konfigurasjonen på SSL-laget før håndtrykket, og start WebSocket-oppgraderingen først etter at TLS har lykkes.