העברת מאגר ה-CONNECT של Beast אל ה-handshake של TLS

לאחר ש-Beast קורא את כותרת תגובת ה-CONNECT של פרוקסי, בדוק גם את מצב התגובה וגם את המאגר הדינמי. פעולת הקריאה עשויה להביא בתים מעבר לסוף הכותרת ולהשאיר אותם במאגר שסופק. התחלת TLS עם overload שקורא רק מהשקע משאירה את הבתים השמורים מחוץ לנתיב הקלט של TLS.

עבור זרם WebSocket שהשכבה הבאה שלו היא זרם SSL, השתמש ב-overload של ה-handshake הממואגר. בסשן 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);

החזרות המוקדמות הן יציאות הכשל של הסשן; חבר שם את דיווח השגיאות והניקוי הרגילים. רק תגובת CONNECT מוצלחת יוצרת את המנהרה. דף דחייה אינו צריך להפוך לקלט TLS.

ה-overload הממואגר מסתיים עם קוד שגיאה ומספר בתים. מספר זה מתאר כמה בתים הוא צרך מהמאגרים שסופקו. לאחר ההשלמה הסר בדיוק את הקידומת הזו בעזרת consume(used). אל תנקה את המאגר לפני תחילת הפעולה, אל תשנה את האחסון שלו בזמן שה-handshake ממתין, ואל תניח שהפעולה צרכה כל בית שסופק.

ב-TLS רגיל שמתחיל הלקוח מיד לאחר CONNECT, המאגר עשוי להיות ריק. ה-overload מטפל גם במקרה כזה. מטרתו לשמר גבולות זרם; הוא אינו הופך נתוני פרוקסי אקראיים ל-TLS תקף. שמור על אימות שם המארח של היעד ועל תצורת SNI בשכבת ה-SSL לפני ה-handshake, והתחל את שדרוג ה-WebSocket רק לאחר ש-TLS מצליח.