Beasts CONNECT-Puffer in den TLS-Handshake übernehmen

Übergib die nach einer CONNECT-Antwort zurückbehaltenen Bytes an Asios gepufferten TLS-Handshake und verbrauche danach genau die Menge, die er verwendet hat.

Nachdem Beast den CONNECT-Antwortheader eines Proxys gelesen hat, prüfe sowohl den Antwortstatus als auch den dynamischen Puffer. Der Lesevorgang kann Bytes über das Header-Ende hinaus holen und im übergebenen Puffer behalten. Wenn du TLS mit einer Überladung startest, die nur den Socket liest, bleiben diese zurückbehaltenen Bytes außerhalb des TLS-Eingabepfads.

Für einen WebSocket-Stream, dessen nächste Schicht der SSL-Stream ist, verwende die gepufferte Handshake-Überladung. In einer bestehenden yield_context-Sitzung, wobei buffer während der gesamten Operationen am Leben bleibt:

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

Die frühen Returns sind die Fehlerausgänge der Sitzung; hänge dort die übliche Fehlerberichterstattung und Bereinigung an. Nur eine erfolgreiche CONNECT-Antwort errichtet den Tunnel. Eine Ablehnungsseite darf nicht zu TLS-Eingabe werden.

Die gepufferte Überladung endet mit einem Fehlercode und einer Byteanzahl. Diese Anzahl beschreibt, wie viele Bytes sie aus den übergebenen Puffern verbraucht hat. Entferne genau dieses Präfix nach dem Abschluss mit consume(used). Lösche den Puffer nicht vor dem Start, verändere seinen Speicher nicht, während der Handshake aussteht, und nimm nicht an, dass der Vorgang jedes übergebene Byte verbraucht hat.

Bei gewöhnlichem, vom Client unmittelbar nach CONNECT gestartetem TLS kann der Puffer leer sein. Die Überladung behandelt auch diesen Fall. Ihr Zweck ist die Wahrung von Stream-Grenzen; sie macht beliebige nachfolgende Proxy-Daten nicht zu gültigem TLS. Behalte die Hostnamenprüfung des Ziels und die SNI-Konfiguration vor dem Handshake auf der SSL-Schicht und starte das WebSocket-Upgrade erst, nachdem TLS erfolgreich war.

Ähnliche Artikel