ນຳ buffer CONNECT ຂອງ Beast ເຂົ້າໃນ handshake TLS

ຫຼັງຈາກ Beast ອ່ານ header ການຕອບສະໜອງ CONNECT ຂອງ proxy ແລ້ວ, ໃຫ້ກວດທັງສະຖານະການຕອບສະໜອງ ແລະ buffer ແບບເຄື່ອນໄຫວ. ການອ່ານອາດດຶງ byte ທີ່ເກີນຈຸດສິ້ນສຸດຂອງ header ມາ ແລະເກັບໄວ້ໃນ buffer ທີ່ໃຫ້ມາ. ຖ້າເລີ່ມ TLS ດ້ວຍ overload ທີ່ອ່ານພຽງ socket, byte ທີ່ເກັບໄວ້ເຫຼົ່ານັ້ນຈະຢູ່ນອກເສັ້ນທາງອິນພຸດຂອງ TLS.

ສຳລັບ stream WebSocket ທີ່ຊັ້ນຕໍ່ໄປແມ່ນ stream SSL, ໃຫ້ໃຊ້ overload ຂອງ handshake ທີ່ມີ buffer. ໃນ session yield_context ທີ່ມີຢູ່ແລ້ວ, ໂດຍຮັກສາ buffer ໃຫ້ມີຊີວິດຕະຫຼອດການດຳເນີນການ:

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

ການກັບຄືນໃນຕອນຕົ້ນແມ່ນທາງອອກຄວາມລົ້ມເຫຼວຂອງ session; ໃຫ້ຕິດການລາຍງານຂໍ້ຜິດພາດ ແລະການເຮັດຄວາມສະອາດປົກກະຕິໄວ້ທີ່ນັ້ນ. ມີພຽງການຕອບສະໜອງ CONNECT ທີ່ສຳເລັດເທົ່ານັ້ນທີ່ສ້າງ tunnel. ໜ້າການປະຕິເສດຕ້ອງບໍ່ກາຍເປັນອິນພຸດຂອງ TLS.

overload ທີ່ມີ buffer ຈະສຳເລັດດ້ວຍລະຫັດຂໍ້ຜິດພາດ ແລະຈຳນວນ byte. ຈຳນວນນັ້ນບອກວ່າມັນບໍລິໂພກໄປຈັກ byte ຈາກ buffer ທີ່ໃຫ້ມາ. ຫຼັງຈາກສຳເລັດແລ້ວ, ໃຫ້ລຶບ prefix ນັ້ນອອກຢ່າງຊັດເຈນດ້ວຍ consume(used). ຢ່າລ້າງ buffer ກ່ອນເລີ່ມການດຳເນີນການ, ຢ່າປ່ຽນບ່ອນເກັບຂອງມັນໃນຂະນະທີ່ handshake ຍັງລໍຖ້າ, ແລະຢ່າສົມມຸດວ່າການດຳເນີນການໄດ້ບໍລິໂພກທຸກ byte ທີ່ໃຫ້ມາ.

ກັບ TLS ປົກກະຕິທີ່ client ເລີ່ມທັນທີຫຼັງ CONNECT, buffer ອາດຫວ່າງເປົ່າ. overload ຍັງຮັບມືກັບກໍລະນີນັ້ນດ້ວຍ. ຈຸດປະສົງຂອງມັນແມ່ນຮັກສາຂອບເຂດຂອງ stream; ມັນບໍ່ໄດ້ເຮັດໃຫ້ຂໍ້ມູນ proxy ທີ່ຕາມມາຢ່າງສຸ່ມກາຍເປັນ TLS ທີ່ຖືກຕ້ອງ. ຮັກສາການກວດສອບຊື່ host ປາຍທາງ ແລະການຕັ້ງຄ່າ SNI ໄວ້ໃນຊັ້ນ SSL ກ່ອນ handshake, ແລະເລີ່ມການອັບເກຣດ WebSocket ຫຼັງຈາກ TLS ສຳເລັດເທົ່ານັ້ນ.