שורה חדשה אחת נוספת יכולה לשבור TLS אחרי CONNECT

כאשר CONNECT מחזיר 200 ו-TLS נכשל מיד בפענוח, בדקו את בייטי הגבול במחבר לפני שתחליפו תעודות או צפנים.

ערך הרשאה שנוצר עשוי כבר להסתיים בשורה חדשה. הוספת סוף שורה נוסף עלולה לסיים את כותרות ה-HTTP מוקדם מדי, ולהשאיר שדה Host מיועד או טקסט גלוי אחר מאחורי הבקשה.

בקשת HTTP/1.1 CONNECT מינימלית משתמשת ב-CRLF בין השורות ובשורה ריקה בסוף:

b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"

שימו כל שדה הרשאה לפני השורה הריקה האחרונה, בלי שבירת שורה מוטמעת. בפייתון, "\n" מייצג שורה חדשה; מחרוזת גולמית המכילה קו נטוי אחורי והאות n לא. בדקו אילו בייטים עוזר קידוד מייצר לפני שתנסו להסיר אותם—עוזרים ישנים יכלו להוסיף שבירות שורה.

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

בדקו גם את גבול הקליטה. קראו את תגובת הפרוקסי המלאה לפני מסירת ה-socket ל-TLS, טפלו בקריאות חלקיות ושמרו כל מה שנקרא מעבר לכותרות. קריאת socket אחת אינה חייבת להכיל הודעה שלמה אחת.

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