یک خط جدید اضافی می‌تواند 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"

هر فیلد مجوز را پیش از آن خط خالی نهایی قرار دهید، بدون شکست خط درونی. در Python، "\n" نماینده خط جدید است؛ رشته خامی که شامل بک‌اسلش و حرف n باشد نه. پیش از تلاش برای حذف، بررسی کنید کدام بایت‌ها را کمک‌تابع کدگذاری تولید می‌کند—کمک‌تابع‌های قدیمی‌تر می‌توانستند شکست خط اضافه کنند.

پس از موفقیت CONNECT، آن بایت‌های باقی‌مانده به پروتکل تونل تعلق دارند. متن ساده سرگردان می‌تواند به همتایی برسد که انتظار TLS دارد. وضعیت موفق نمی‌تواند بایت‌هایی را که پس از یک درخواست بدشکل در صف قرار گرفته‌اند ترمیم کند.

مرز دریافت را هم بررسی کنید. پاسخ کامل پروکسی را پیش از سپردن سوکت به TLS بخوانید، خواندن‌های جزئی را مدیریت کنید و هر چیزی را که فراتر از سرآیندها خوانده می‌شود نگه دارید. یک خواندن سوکت لازم نیست یک پیام کامل را در خود داشته باشد.

اگر این تجزیه‌گر مال شماست، نمایش بایت ویرایش‌شده را با دستور زبان سیم مقایسه کنید؛ طول‌ها و مرزهای خط را در حالی که گذرواژه را پنهان می‌کنید نمایان نگه دارید. برای برنامه‌ای که فقط به اتصال پروکسی نیاز دارد، یک اتصال‌دهنده نگهداری‌شده نیاز به مالکیت این کد قالب‌بندی را از بین می‌برد.