Hamisha buffer ya CONNECT ya Beast kwenye handshake ya TLS

Baada ya Beast kusoma kichwa cha jibu la CONNECT la proksi, chunguza hali ya jibu na buffer inayobadilika. Operesheni ya kusoma inaweza kuleta bait zilizo zaidi ya mwisho wa kichwa na kuzihifadhi kwenye buffer uliyotolewa. Ukianzisha TLS kwa overload inayosoma soketi pekee, bait hizo zilizohifadhiwa zinabaki nje ya njia ya pembejeo ya TLS.

Kwa mtiririko wa WebSocket ambao tabaka lake linalofuata ni mtiririko wa SSL, tumia overload ya handshake yenye buffer. Katika kikao yield_context kilichopo, ukiiweka buffer hai katika shughuli zote:

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

Marejeo ya mapema ni njia za kutoka za kushindwa kwa kikao; ambatisha hapo utoaji wa ripoti za makosa na usafishaji wa kawaida. Jibu la CONNECT lililofanikiwa pekee ndilo huanzisha handaki. Ukurasa wa kukataa haupaswi kuwa pembejeo ya TLS.

Overload yenye buffer hukamilika kwa msimbo wa kosa na hesabu ya bait. Hesabu hiyo hueleza ni bait ngapi ilitumia kutoka kwenye buffer zilizotolewa. Baada ya kukamilika, ondoa kwa usahihi kiambishi hicho kwa consume(used). Usifute buffer kabla ya operesheni kuanza, usibadilishe hifadhi yake wakati handshake inasubiri, na usidhani kwamba operesheni ilitumia kila bait iliyotolewa.

Kwa TLS ya kawaida inayoanzishwa na mteja mara moja baada ya CONNECT, buffer inaweza kuwa tupu. Overload pia hushughulikia hali hiyo. Madhumuni yake ni kuhifadhi mipaka ya mtiririko; haifanyi data yoyote ya proksi inayofuata kuwa TLS halali. Weka uthibitishaji wa jina la mwenyeji lengwa na usanidi wa SNI kwenye tabaka la SSL kabla ya handshake, na anza uboreshaji wa WebSocket tu baada ya TLS kufaulu.