עדכונים
23 במרץ 2023: ציר הזמן עודכן, וההוצאה משימוש לא תתבצע עד לגרסה 117 של Chrome.
19 בינואר 2023: ציר הזמן עודכן, וההוצאה משימוש לא תתבצע עד לגרסה 114 של Chrome.
12 באוגוסט 2022: ציר הזמן עודכן, וההוצאה משימוש לא תתבצע עד לגרסה 109 של Chrome.
10 בפברואר 2022: מאמר מעודכן יפורסם בדף גישה לרשת פרטית: הצגת קדם-הפעלה
25 באוגוסט 2021: הודעה מעודכנת לגבי ציר הזמן והשקת תקופת ניסיון להוצאה משימוש.
בהתאם למפרט גישה לרשת פרטית, Chrome מוציא משימוש את הגישה של אתרים לא מאובטחים לנקודות קצה (endpoint) ברשת פרטית. המטרה היא להגן על המשתמשים מפני התקפות זיוף של בקשות חוצי אתרים שמטרגטות נתבים ומכשירים אחרים ברשתות פרטיות. ההתקפות השפיעו על מאות אלפי משתמשים ואפשרו לתוקפים להפנות אותם לשרתים זדוניים.
Chrome יבצע את השינויים הבאים:
- חסימת בקשות לרשתות פרטיות מאתרים ציבוריים לא מאובטחים החל מגרסה 94 של Chrome.
- תקופת ניסיון להוצאה משימוש שתסתיים ב-Chrome
- המפתח יאפשר למפתחים לבקש הארכת זמן למקורות נבחרים, שלא תהיה לכך השפעה במהלך תקופת הניסיון להוצאה משימוש.
- השקה של מדיניות Chrome, שתאפשר לפריסות מנוהלות של Chrome לעקוף את ההוצאה משימוש באופן סופי. זמין ב-Chrome בגרסה 92.
אם אתם זקוקים לזמן נוסף כדי לצמצם את ההשפעה של רישום ההוצאה משימוש של תקופת הניסיון של ההוצאה משימוש.
אם יש לכם שליטה של אדמין על המשתמשים, תוכלו להפעיל מחדש את התכונה באמצעות כללי המדיניות של Chrome.
כדי לצמצם את ההשפעה של ההגבלות החדשות, כדאי להשתמש באחת מהאסטרטגיות הבאות:
- משדרגים את האתר ל-HTTPS, ובמידת הצורך גם לשרת היעד.
- מומלץ לשדרג את האתר ל-HTTPS ולהשתמש ב-WebTransport.
- לבטל את יחסי ההטמעה.
ציר הזמן
- נובמבר 2020: התקשרו כדי לקבל משוב על השינויים הצפויים.
- מרץ 2021: אחרי בדיקת המשוב ופנייה, יוכרזו השינויים הצפויים. שם המפרט ישתנה מ-CORS-RFC1918 ל'גישה לרשת פרטית'.
- אפריל 2021: נשיק את Chrome 90 לגרסה יציבה ומוצגות בו אזהרות על הוצאה משימוש.
- יוני 2021: השקה של Chrome 92 בגרסת בטא, לאי-בידינג של בקשות רשת פרטיות מהקשרים לא מאובטחים. בעקבות משוב ממפתחים שביקשו עוד זמן התאמה, ההוצאה משימוש תידחה לגרסה 93 של Chrome ותצורף תקופת ניסיון להוצאה משימוש.
- יולי 2021: לאחר משוב נוסף ממפתחים, ההוצאה משימוש ותקופת הניסיון הנלווה נדחו ל-Chrome 94. בנוסף, אתרים פרטיים כבר לא מושפעים מההוצאה משימוש.
- אוגוסט 2021: השקת Chrome 94 בגרסת בטא. מפתחי אתרים יכולים להתחיל להירשם לתקופת הניסיון להוצאה משימוש.
- ספטמבר 2021: השקת Chrome 94 לגרסה יציבה. מפתחי אתרים היו צריכים להירשם לתקופת הניסיון להוצאה משימוש ולפרוס אסימונים של גרסת ניסיון לייצור.
- דצמבר 2022: נשלח סקר לגבי ניסוי המקור והתקבל משוב. תקופת הניסיון להוצאה משימוש מורחבת ל-Chrome 113.
- מרץ 2023: תקופת הניסיון להוצאה משימוש מורחבת ל-Chrome בגרסה 116, ומוגדרת להסתיים בגרסה 117 של Chrome. מנגנון חלופי מבוסס הרשאות נמצא בפיתוח, ומטרגט את הגרסה הראשונית ב-Chrome 114.
- מאי 2023 (לא סופי): המנגנון מבוסס ההרשאות יושק ב-Chrome 114. אתרים יכולים להשתמש בו כדי לצאת מתקופת הניסיון של ההוצאה משימוש.
- ספטמבר 2023: נשיק את Chrome 117 לגרסה יציבה ותסתיים תקופת הניסיון של ההוצאה משימוש. Chrome חוסם את כל הבקשות מהרשת הפרטית מהקשרים ציבוריים ולא מאובטחים.
מהי גישה לרשת פרטית
גישה לרשת פרטית (לשעבר CORS-RFC1918) מגבילה את היכולת של האתרים לשלוח בקשות לשרתים ברשתות פרטיות. היא מאפשרת בקשות כאלה רק מהקשרים מאובטחים. המפרט גם מרחיב את הפרוטוקול של שיתוף משאבים בין מקורות (CORS), כך שאתרים צריכים לבקש מענק באופן מפורש משרתים ברשתות פרטיות לפני שיוכלו לשלוח בקשות שרירותיות.
בקשות לרשת פרטית הן בקשות שכתובת ה-IP של שרת היעד שלהן פרטית יותר מהכתובת שממנה נשלף יוזם הבקשה. לדוגמה, בקשה מאתר ציבורי (https://example.com) לאתר פרטי (http://router.local) או בקשה מאתר פרטי אל Localhost.
מידע נוסף זמין במאמר משוב רצוי: CORS לרשתות פרטיות (RFC1918).
מהי תקופת ניסיון להוצאה משימוש
תקופות ניסיון להוצאה משימוש (לשעבר גרסאות מקור הפוך) הן סוג של גרסאות מקור לניסיון, כדי להקל את ההוצאה משימוש של תכונות אינטרנט. תקופות ניסיון להוצאה משימוש מאפשרות ל-Chrome להוציא משימוש תכונות אינטרנט מסוימות ולמנוע מאתרים ליצור יחסי תלות חדשים בהן, ובמקביל לתת לאתרים התלויים הקיימים זמן נוסף כדי לעבור מהן.
במהלך תקופת ניסיון להוצאה משימוש, התכונות שהוצאו משימוש לא זמינות לכל האתרים כברירת מחדל. מפתחים שעדיין צריכים להשתמש בתכונות המושפעות חייבים להירשם לתקופת ניסיון להוצאה משימוש ולקבל אסימונים למקורות אינטרנט ספציפיים, ואז לשנות את האתרים שלהם כך שיציגו את האסימונים האלו בכותרות HTTP או במטא תגים (למעט במקרה הזה). אם אתר מסוים מציג אסימונים תקפים שתואמים למקור שלהם, Chrome יאפשר להשתמש בתכונה שהוצאה משימוש לפרק זמן מוגבל.
מידע נוסף זמין במאמר תחילת העבודה עם גרסאות המקור של Chrome ובמדריך למפתחי אתרים לגרסאות מקור לניסיון.
מה עומד להשתנות ב-Chrome
Chrome 94
החל מ-Chrome 94, הקשרים ציבוריים לא מאובטחים (ברוב המקרים, אתרים שלא מועברים באמצעות HTTPS או מכתובת IP פרטית) לא יכולים לשלוח בקשות לרשת הפרטית. תוכנן בעבר ל-Chrome 92, לכן ייתכן שהודעות על הוצאה משימוש עדיין יזכירו את אבן הדרך הקודמת.
ההוצאה משימוש נלווה גם בגרסת ניסיון של הוצאה משימוש, כדי לאפשר למפתחי אתרים באתרים שלהם להשתמש בתכונה שהוצאה משימוש להמשיך להשתמש בה עד גרסה Chrome 116 באמצעות רישום לקבלת אסימונים. בהמשך מוסבר איך להירשם ולהפעיל את תקופת הניסיון באתר.
אפשר להשתמש בצמד של כללי מדיניות Chrome כדי להשבית את ההוצאה משימוש באופן מלא או במקורות ספציפיים, ללא הגבלת זמן. כך אפשר למנוע תקלות בהתקנות של Chrome, למשל התקנות בהגדרות הארגון.
גרסה 117 של Chrome
תקופת הניסיון להוצאה משימוש מסתיימת. צריך להעביר את כל האתרים מהתכונה שהוצאה משימוש או את כללי המדיניות של המשתמשים שלהם להמשך הפעלת התכונה.
פעולות מומלצות למפתחים
באתרים המושפעים סביר להניח שהצעד הראשון ירכוש זמן מה עד לפתרון הנכון: הרשמה לתקופת הניסיון של ההוצאה משימוש או באמצעות מדיניות. לאחר מכן, דרך הפעולה המומלצת משתנה בהתאם לנסיבות של כל אתר מושפע.
הרשמה לתקופת הניסיון להוצאה משימוש
- לוחצים על Register לגרסת המקור לניסיון של גישה לרשת פרטית מהקשרים לא מאובטחים כדי לקבל אסימון ניסיון עבור המקור המשתתף.
- מוסיפים
Origin-Trial: $tokenהספציפי למקור אל כותרת התגובה. צריך להגדיר את כותרת התגובה הזו בתגובות של המשאב הראשי והניווט רק כשבמסמך שנוצר נעשה שימוש בתכונה שהוצאה משימוש. צירוף הכותרת הזו לתגובות של משאבי משנה לא מועיל (אם כי לא מזיק).
מכיוון שצריך להפעיל או להשבית את תקופת הניסיון הזו לפני שמסמך יכול לשלוח בקשות, אי אפשר להפעיל אותה באמצעות תג <meta>. תגים כאלה מנותחים מגוף התגובה רק אחרי שייתכן שהונפקו בקשות למשאבי משנה. מצב זה מהווה אתגר לאתרים שאין להם שליטה על כותרות התגובות, כמו אתרים סטטיים של github.io שמוצגים על ידי צד שלישי.
פרטים נוספים זמינים במדריך למפתחי אתרים לגרסאות מקור לניסיון.
הפעלת כללי מדיניות
אם יש לכם שליטה של אדמין על המשתמשים, תוכלו להפעיל מחדש את התכונה שהוצאה משימוש באמצעות אחד מכללי המדיניות הבאים:
אפשר לקרוא פרטים נוספים על ניהול המדיניות עבור המשתמשים שלך במאמר הזה במרכז העזרה.
מתבצעת גישה ל-localhost
אם האתר שלכם צריך לשלוח בקשות ל-localhost, אתם רק צריכים לשדרג את האתר ל-HTTPS.
בקשות שמטרגטות את http://localhost (או http://127.*.*.*, http://[::1]) לא חסומות על ידי תוכן מעורב, גם אם הן נשלחות מהקשרים מאובטחים.
שים לב שמנוע WebKit והדפדפנים שמבוססים עליו (הבמיוחד ב-Safari) חורגים ממפרט התוכן המעורב של W3C שמופיע כאן, ואוסר על הבקשות האלה כתוכן מעורב. הם גם לא מטמיעים גישה לרשת פרטית, ולכן ייתכן שאתרים ירצו להפנות לקוחות שמשתמשים בדפדפנים כאלה לגרסת HTTP בטקסט ללא הצפנה של האתר, שדפדפנים כאלה עדיין יורשה לשלוח בקשות ל-localhost.
גישה לכתובות IP פרטיות
אם האתר שלכם צריך לשלוח בקשות לשרת יעד עם כתובת IP פרטית, האפשרות פשוט לשדרג את האתר שיזם ל-HTTPS לא תעבוד. 'תוכן מעורב' מונע מהקשרים מאובטחים לשלוח בקשות באמצעות HTTP פשוט, כך שהאתר המאובטח החדש עדיין לא יוכל לבצע את הבקשות. יש כמה דרכים לפתור את הבעיה:
- יש לשדרג את שני הקצוות ל-HTTPS.
- משתמשים ב-WebTransport כדי להתחבר לשרת היעד באופן מאובטח.
- להפוך את קשר הגומלין של ההטמעה.
שדרוג שני הקצוות ל-HTTPS
הפתרון הזה מחייב שליטה על רזולוציית ה-DNS של המשתמשים, כמו במקרים כאלה בהקשרים של אינטראנט, או אם המשתמשים מקבלים את הכתובות של שרתי השמות שלהם משרת DHCP שבשליטתכם. הוא גם מחייב שיהיה לכם שם דומיין ציבורי.
הבעיה העיקרית בהצגת אתרים פרטיים ב-HTTPS היא שרשויות אישורים לתשתית של מפתחות ציבוריים (PKI CA) מספקות אישורי TLS רק לאתרים עם שמות דומיינים ציבוריים. כדי לעקוף את הבעיה:
- רישום שם של דומיין ציבורי (למשל,
intranet.example) ופרסום רשומות DNS שמפנות את שם הדומיין לשרת ציבורי לבחירתכם. - קבלת אישור TLS עבור
intranet.example. - ברשת הפרטית שלכם, מגדירים את ה-DNS כך שישייך את
intranet.exampleלכתובת ה-IP הפרטית של שרת היעד. - צריך להגדיר את השרת הפרטי לשימוש באישור TLS עבור
intranet.example. כך המשתמשים יוכלו לגשת לשרת הפרטי בכתובתhttps://intranet.example.
לאחר מכן אפשר לשדרג את האתר שמתחיל את הבקשות ל-HTTPS ולהמשיך לבצע את הבקשות כמו קודם.
הפתרון הזה עמיד לעתיד ומפחית את האמון שלכם ברשת, ומרחיב את השימוש בהצפנה מקצה לקצה ברשת הפרטית.
WebTransport
לפתרון הזה לא נדרשת שליטה על רזולוציית ה-DNS של המשתמשים. כן נדרש ששרת היעד יפעיל שרת WebTransport מינימלי (שרת HTTP/3 עם שינויים מסוימים).
כדי לעקוף את היעדר אישור TLS חוקי שחתום על ידי רשות אישורים מהימנה, אפשר להשתמש ב-WebTransport ובמנגנון הצמדת האישורים. כך אפשר ליצור חיבורים מאובטחים למכשירים פרטיים שיש להם, למשל, אישור בחתימה עצמית. חיבורי WebTransport מאפשרים העברת נתונים דו-כיוונית, אבל לא מאפשרים אחזור בקשות. אפשר לשלב את הגישה הזו עם Service Worker לבקשות HTTP שקופות לשרת proxy במהלך החיבור, מנקודת המבט של אפליקציית האינטרנט. בצד השרת, שכבת תרגום תואמת יכולה להמיר את הודעות WebTransport לבקשות HTTP.
אנחנו מבינים שהתהליך הזה כולל כמות לא מבוטלת של עבודה, אבל הוא צריך להיות קל מאוד מאשר פיתוח על גבי WebRTC. אנחנו גם מקווים שחלק מההשקעה הנדרשת יוטמעה כספריות לשימוש חוזר. אנחנו גם מאמינים כדאי במיוחד להביא בחשבון את העובדה שהקשרים לא מאובטחים עלולים לאבד את הגישה ליותר ויותר תכונות של פלטפורמת האינטרנט, ככל שהפלטפורמה פועלת לעודד שימוש ב-HTTPS באופן מחזק יותר לאורך זמן. בלי קשר לגישה לרשת פרטית, סביר להניח שזו השקעה נבונה בכל מקרה.
אנחנו מצפים ש-WebTransport באמצעות HTTP/3 יישלח ל-Chrome 96 (החל בגרסת מקור לניסיון) עם מיטיגציות לצורך הגנה מפני שיתוף מפתחות ושיטות אבטחה תת-סטנדרטיות אחרות, כולל:
- זמן תפוגה מקסימלי קצר של אישורים מוצמדים.
- מנגנון ספציפי לדפדפן לביטול מפתחות מסוימים שהיו כפופים לניצול לרעה.
אנחנו לא נשלח את הגבלת ההקשר המאובטח לפני לפחות שתי אבני דרך אחרי ההשקה המלאה של WebTransport. במקרה הצורך, תקופת הניסיון של ההוצאה משימוש תוארך.
הטמעה הפוכה
לפתרון הזה לא נדרשת שליטה ניהולית ברשת, ואפשר להשתמש בו כששרת היעד לא חזק מספיק כדי להריץ HTTPS.
במקום לאחזר משאבי משנה פרטיים מאפליקציית אינטרנט ציבורית, ניתן להציג שלד של האפליקציה מהשרת הפרטי, שמאחזר את כל משאבי המשנה שלו (כמו סקריפטים או תמונות) משרת ציבורי כמו CDN. אפליקציית האינטרנט שתתקבל תוכל לשלוח בקשות לשרת הפרטי, כי הן נחשבות לאותו מקור. הוא יכול אפילו לשלוח בקשות לשרתים אחרים עם כתובות IP פרטיות (אבל לא מארח מקומי), אבל זה עשוי להשתנות בטווח הארוך.
אירוח של שלד בלבד בשרת הפרטי מאפשר לעדכן את אפליקציית האינטרנט על ידי דחיפת משאבים חדשים לשרת הציבורי, בדיוק כמו שמעדכנים אפליקציית אינטרנט ציבורית. מצד שני, אפליקציית האינטרנט שנוצרת אינה הקשר מאובטח, כך שאין לה גישה לחלק מהתכונות החזקות יותר של האינטרנט.
תוכניות לעתיד
הגבלת בקשות מהרשת הפרטית בהקשרים מאובטחים היא רק השלב הראשון בהשקת הגישה לרשת הפרטית. Chrome פועל ליישם את שאר המפרט בחודשים הקרובים. כדאי להמשיך להתעדכן.
הגבלת הגישה של מארח מקומי מאתרים פרטיים
השינויים ב-Chrome 94 משפיעים רק על אתרים ציבוריים שמקבלים גישה לכתובות IP פרטיות או מארח מקומי. מפרט הגישה לרשת הפרטית גם מסווג בקשות מאתרים פרטיים למארח מקומי כבעייתיות. בסופו של דבר, Chrome יצא משימוש גם אותם. עם זאת, המצב הזה מציג אתגרים מעט שונים, מכיוון שלאתרים פרטיים רבים אין שמות דומיינים, והדבר מסכן את השימוש באסימונים של גרסאות ניסיון שהוצאו משימוש.
בקשות קדם-הפעלה של CORS
החלק השני של 'גישה לרשת פרטית' הוא להגביל בקשות רשת פרטית שבוצעו מהקשרים מאובטחים באמצעות בקשות קדם-הפעלה של CORS. הרעיון הוא שגם כשהבקשה נשלחה מהקשר מאובטח, שרת היעד מתבקש לתת ליוזם הרשאה מפורשת. הבקשה נשלחת רק אם המענק מתבצע בהצלחה.
בקיצור, בקשת קדם-הפעלה של CORS היא בקשת HTTP OPTIONS שכוללת כמה כותרות Access-Control-Request-* שמציינות את אופי הבקשה הבאה. לאחר מכן השרת יכול להחליט אם להעניק גישה פרטנית באמצעות תגובה ל-200 OK עם כותרות Access-Control-Allow-*.
מידע נוסף בנושא זמין במפרט.
הגבלת אחזורים של ניווט
Chrome מוציאים משימוש, ובסופו של דבר חוסם בקשות של משאבי משנה לרשתות פרטיות. המעבר לא ישפיע על הניווטים לרשתות פרטיות, ואפשר להשתמש בהם גם בהתקפות CSRF.
במפרט הגישה לרשת הפרטית אין הבחנה בין שני סוגי האחזורים, שבסופו של דבר יהיו כפופים לאותן הגבלות.
תמונת השער מאת Markus Spiske ב-UnFlood