HTTP CONNECT: איך פרוקסי HTTP מטפל ב־HTTPS

״200 Connection Established״ פירושו שהפרוקסי מקבל מנהרה. האתר עדיין לא החזיר דף. כעת מגיע TLS מול היעד, ואחריו בקשת HTTPS עצמה.

מהחיבור לפרוקסי ועד לתגובת האתר

1. הלקוח מתחבר לנקודת הקצה של הפרוקסי.
2. הוא מבקש מהפרוקסי להתחבר למארח ולפורט של היעד.
3. הפרוקסי מקבל או דוחה את הבקשה.
4. לאחר הקבלה, הלקוח מנהל משא ומתן ל־TLS עם היעד דרך המנהרה.
5. הלקוח שולח את בקשת HTTPS ומקבל את תגובת האתר בתוך TLS.

סירוב לחיבור לפרוקסי, דחיית מנהרה ושגיאת תעודה מתרחשים בנקודות שונות ברצף הזה. מצאו את השלב האחרון שהושלם לפני שינוי ההגדרות.

חילופי CONNECT

ב־HTTP/1.1, חילופי הודעות מפושטים נראים כך:

CONNECT example.com:443 HTTP/1.1
Host: example.com:443

HTTP/1.1 200 Connection Established

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

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

צפייה באמצעות curl

לפרוקסי HTTP בפורט המקומי 8080:

curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/

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

היעד יכול להחזיר 404, 429 או 500 אחרי שהפרוקסי קיבל את המנהרה. הוא יכול גם להיכשל במהלך TLS לפני החזרת תגובת HTTP כלשהי.

היכן זה נעצר?

בהשוואות, השאירו צד אחד קבוע: נסו יעד אחר דרך אותו פרוקסי, או השוו את אותו יעד במסלול ישיר מורשה.

למנהרה עדיין יש מפעיל

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