פרוקסי HTTPS פירושו שני חיבורי TLS, לא אחד
קפיצת הפרוקסי והאתר הם קשרי TLS נפרדים עם אמון נפרד. קראו איזה קצה נכשל לפני שתשנו הגדרת תעודה כלשהי.
התווית פרוקסי HTTPS מתארת רק את התעבורה בין הלקוח שלכם לפרוקסי, ותו לא. היא אינה אומרת שהאתר שמאחוריו מוצפן באותו חיבור, ואינה אומרת שהפרוקסי יכול לקרוא את הדף. ברגע שמפרידים בין שני החיבורים, שגיאות תעודה מפסיקות להיות מסתוריות וההשוואה ל-VPN נעשית מוחשית.
שני זוגות קצוות, שתי בדיקות
במצב מנהרה רגיל יש שני קשרי TLS. הראשון עובר מהלקוח שלכם אל הפרוקסי ומאמת את הפרוקסי. השני עובר מהלקוח שלכם אל האתר שבתוך המנהרה ומאמת את האתר. הם נכשלים בנפרד ומוגדרים בנפרד.
יש להם החלטות אמון נפרדות, שרשראות תעודה נפרדות והודעות כשל נפרדות. פרוקסי שמשתמש ב-CA ארגוני ואתר ציבורי שמשתמש בשרשרת ציבורית עשויים בהחלט להזדקק להגדרת אימות שונה, וזו אינה הגדרה שגויה.
התייחסו אליהם כאל שני חיבורים שמקרה חולקים שקע אחד, כי זה מה שהם.
מה CONNECT באמת מנהר
הלקוח שולח בקשת CONNECT עם שם המארח והפורט, והפרוקסי פותח חיבור TCP אל היעד הזה. לאחר שהפרוקסי עונה, הבייטים שאחריו מועברים ללא פרשנות, ולכן לחיצת היד של TLS של האתר עוברת דרך הפרוקסי בלי שינוי. כך הפרוקסי לומד את שם היעד ואת מטא-נתוני החיבור, והוא אינו מקבל דפים מפוענחים מאותו סידור.
ההבחנה הזו היא כל טיעון האבטחה של מצב מנהרה, והיא גם גבולו.
פרוקסי HTTP בלי TLS בקפיצת הפרוקסי עדיין נושא אתר HTTPS דרך CONNECT. החלפת הלקוח עם הפרוקסי היא בגלוי ואילו חיבור האתר אינו, וקריאה לכל הדבר פרוקסי HTTPS מסתירה את ההבדל הזה.
איזו תעודה נכשלה
כשהאימות נכשל, קראו את הקצה הנקוב בשגיאה לפני שתשנו הגדרת אמון כלשהי. שני הכשלים נראים דומה במסוף ומצביעים על תיקונים שונים לגמרי, ולכן השאלה הראשונה היא תמיד איזה חיבור סירב.
curl מפריד את האפשרויות בדיוק מהסיבה הזו. קובץ ה-CA של הפרוקסי מגדיר את אימות הפרוקסי, ואילו קובץ ה-CA מגדיר את אימות השרת, והתנהגות מאגר האמון החל גם תלויה באופן שבו curl נבנה.
curl -v --proxy https://proxy.example.net:443 \
--proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/דיכוי בדיקה אינו תיקון. הוא אינו מוכיח דבר על אף אחד משני הקצוות.
בדיקה היא סידור אחר
בדיקת TLS אינה נהור. מתווך בודק מסיים את קשר האמון כלפי האתר ומציג ללקוח תעודה משלו, ולכן הלקוח מאמת את המתווך ולא את האתר. זה יכול להיות לגיטימי בתכנון מאושר, וזו טענה שונה מהותית מהעברה בייט אחר בייט. אל תניחו שכל פרוקסי בודק, ואל תניחו שקפיצת פרוקסי מוצפנת שוללת זאת.
CA ארגוני במאגר האמון שלכם הוא רמז לאיזה סידור אתם נמצאים בו, לא הוכחה. בקשו את התכנון במקום להסיק אותו משרשרת תעודה.
שני הסידורים האלה נותנים תשובות שונות לשאלה מי יכול לקרוא את הדף.
השוו פרוקסי ו-VPN על אותן ארבע שורות
ההשוואה נעשית שימושית רק כששני הפריסות מתוארות באותו אופן.
| Line | What to state |
|---|---|
| Protected segments | Which hops are encrypted, and between which endpoints |
| Verified identities | What each end proves, and against which trust anchor |
| Trusted intermediaries | Who can read or alter traffic by design |
| Traffic included | Which processes and destinations the policy actually covers |
פרוקסי שמוגדר לבקשה אחת מכסה את הבקשה ההיא. הוא אינו מעביר כל תהליך במכשיר דרכו, ופקודת הדוגמה צרה בדיוק במידה הזו. הכיסוי של VPN תלוי בניתוב ובמדיניות האפליקציות שלו, שגם אותם יש לבדוק ולא להניח. אף אחת משתי האפשרויות לא מכסה הכול רק משום שהותקנה.
כתבו את ארבע השורות לכל אפשרות והטיעון בדרך כלל פותר את עצמו. ההשוואה השימושית אינה איזו תווית נשמעת מוצפנת יותר. אלא אילו מקטעים מוגנים, מי מאומת בקצותיהם, באילו מתווכים אתם בוטחים, ואיזו תעבורה המדיניות כוללת בפועל.