OAuth בתוך VPN: אילו שלבים עדיין דורשים TLS

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

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

החליטו לפי שלב, לא לפי רשת

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

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

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

תגובת ההרשאה וה-URI להפניה מחדש

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

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

רשמו את ה-URI המדויק של הפניה מחדש ב-HTTPS אצל שרת ההרשאה והשאירו את אימות התעודות מופעל בלקוח. קיצור דרך לפיתוח שמדכא את דרישת ה-HTTPS מייצר זרימה שמתנהגת אחרת מתצורת הייצור שאמורה להיות מדומה.

נקודת הקצה של האסימון ובקשות אסימון נושא

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

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

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

היכן TLS מסתיים ומה זה משאיר

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

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

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

חריגת הלולאה המקורית צרה

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

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

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