Porta il buffer CONNECT di Beast nell’handshake TLS

Passa i byte rimasti dopo una risposta CONNECT all’handshake TLS con buffer di Asio, poi consuma esattamente la quantità che ha usato.

Dopo che Beast ha letto l’intestazione della risposta CONNECT di un proxy, controlla sia lo stato della risposta sia il buffer dinamico. L’operazione di lettura può recuperare byte oltre il terminatore dell’intestazione e trattenerli nel buffer fornito. Avviare TLS con un overload che legge solo il socket lascia quei byte trattenuti fuori dal percorso di input TLS.

Per uno stream WebSocket il cui livello successivo è lo stream SSL, usa l’overload dell’handshake con buffer. In una sessione yield_context esistente, mantenendo buffer vivo per tutte le operazioni:

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

I ritorni anticipati sono le uscite di errore della sessione; vi si collegano la normale segnalazione degli errori e la pulizia. Solo una risposta CONNECT riuscita stabilisce il tunnel. Una pagina di rifiuto non deve diventare input TLS.

L’overload con buffer termina con un codice di errore e un conteggio di byte. Quel conteggio indica quanti byte ha consumato dai buffer forniti. Al termine, rimuovi esattamente quel prefisso con consume(used). Non svuotare il buffer prima di iniziare l’operazione, non modificarne l’archiviazione mentre l’handshake è in sospeso e non presumere che l’operazione abbia consumato ogni byte fornito.

Con il normale TLS avviato dal client subito dopo CONNECT, il buffer può essere vuoto. L’overload gestisce anche questo caso. Il suo scopo è preservare i confini dello stream; non rende dati proxy arbitrari successivi un TLS valido. Mantieni la verifica del nome host di destinazione e la configurazione SNI sul livello SSL prima dell’handshake e avvia l’upgrade a WebSocket solo dopo che TLS è riuscito.

Articoli correlati