אימות בסיסי מעל HTTPS מול IPsec: מה כל אחד מגן עליו

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

נקודת ביקורת ראשונה: האם זה השרת שאליו התכוונתם לדבר

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

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

נקודת ביקורת שנייה: מה באמת עובר בחילופי 401

אימות בסיסי של HTTP שולח את מזהה המשתמש והסיסמה בכותרת, מקודדים ב-Base64 כמתואר ב-RFC 7617. Authorization: Basic dXNlcjpwYXNz הוא הצורה; כל מי שיכול לקרוא את הבקשה יכול להפוך את הקידוד, ולכן כל הסודיות מגיעה מהתעבורה שמתחת. curl -v מציג גם את אתגר WWW-Authenticate: Basic וגם את הכותרת שאתם מחזירים.

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

היכן נמצאת מנהרת IPsec בנתיב הזה

כעת צאו החוצה מהדפדפן. מנהרת IPsec בין שער לשער מגנה על תעבורה נבחרת בין שני שערי אבטחה, לא בין המחשב הנייד שלכם לתהליך האפליקציה. ESP במצב מנהרה עוטף את החבילה המקורית, השערים מצפינים ומאמתים אותה, והכתובות הפנימיות שורדות כדי שהצד המרוחק יוכל לנתב את הבקשה לאפליקציה.

הבחירה היא החלק שמכשיל אנשים. מנהרות מבוססות מדיניות משתמשות בבוררי תעבורה, שלעיתים קרובות מבוטאים כרשימות בקרת גישה, כדי להחליט אילו חבילות נכנסות למנהרה. מנהרות מבוססות נתיב משתמשות במקום זאת בממשק וירטואלי ובטבלת הניתוב. ב-Linux מציג ip xfrm policy את הבוררים ו-ip xfrm state מציג את אגודות האבטחה שהוקמו; במכשיר חומת אש המקבילה היא טבלת ה-SA של המנהרה בתוספת עוקב חבילות.

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

קראו את הכשל בשכבה שדיווחה עליו

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

השתמשו בראיות שכל שכבה מייצרת: פאנל הרשת של הדפדפן לסטטוסים ולכותרות, openssl s_client -connect host:443 לשרשרת האישורים, מוני SA ויומני השער לתעבורת המנהרה, ויומן האפליקציה להחלטת החשבון. כששתי שכבות מדווחות על שגיאות בו זמנית, תקנו קודם את התחתונה, כי מנהרה מתה יכולה להסוות בקלות כשל אימות ולהפך.

מפו שירות אחד מקצה לקצה

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

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

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