Ço buffer-in CONNECT të Beast në handshake-un TLS

Pasi Beast lexon kokën e përgjigjes CONNECT të një proxy, inspekto si statusin e përgjigjes ashtu edhe buffer-in dinamik. Operacioni i leximit mund të marrë bajt-e përtej përfundimit të kokës dhe t’i mbajë në buffer-in e dhënë. Nëse TLS niset me një mbingarkesë që lexon vetëm socket-in, ato bajt-e të mbajtura mbeten jashtë rrugës së hyrjes TLS.

Për një rrjedhë WebSocket shtresa e radhës e së cilës është rrjedha SSL, përdor mbingarkesën e handshake-ut me buffer. Në një sesion yield_context ekzistues, duke e mbajtur buffer gjallë gjatë të gjithë operacioneve:

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

Kthimet e hershme janë daljet e dështimit të sesionit; atje lidh raportimin e zakonshëm të gabimeve dhe pastrimin. Vetëm një përgjigje CONNECT e suksesshme vendos tunelin. Një faqe refuzimi nuk duhet të bëhet hyrje TLS.

Mbingarkesa me buffer përfundon me një kod gabimi dhe një numër bajt-esh. Ai numër përshkruan sa bajt-e konsumoi nga buffer-at e dhënë. Pas përfundimit, hiq saktësisht atë prefiks me consume(used). Mos e pastro buffer-in përpara se të nisë operacioni, mos e ndrysho ruajtjen e tij ndërsa handshake-u është në pritje dhe mos supozoni se operacioni konsumoi çdo bajt të dhënë.

Me TLS të zakonshëm të nisur nga klienti menjëherë pas CONNECT, buffer-i mund të jetë bosh. Mbingarkesa trajton edhe atë rast. Qëllimi i saj është ruajtja e kufijve të rrjedhës; ajo nuk i bën të dhënat arbitrare të proxy-t pasuese TLS të vlefshëm. Mbaj verifikimin e emrit të hostit të destinacionit dhe konfigurimin SNI në shtresën SSL përpara handshake-ut dhe nis përmirësimin në WebSocket vetëm pasi TLS të ketë sukses.