עדכונים
23 במרץ 2023: לוח הזמנים עודכן, וההוצאה משימוש תתבצע רק בגרסה 117 של Chrome.
19 בינואר 2023: לוח הזמנים עודכן, וההוצאה משימוש תתבצע רק בגרסה 114 של Chrome.
12 באוגוסט 2022: לוח הזמנים עודכן, וההוצאה משימוש תתבצע רק בגרסה 109 של Chrome.
10 בפברואר 2022: פורסם מאמר מעודכן בנושא גישה לרשת פרטית: אנחנו משיקים את תכונת 'בדיקות מקדימות'
25 באוגוסט 2021: עדכנו את לוח הזמנים והשקנו תקופת ניסיון להוצאה משימוש.
Chrome מוציא משימוש את הגישה לנקודות קצה של רשת פרטית מאתרים לא מאובטחים, כחלק ממפרט הגישה לרשת פרטית. המטרה היא להגן על המשתמשים מפני התקפות זיוף בקשות בין אתרים (CSRF) שמטרגטות נתבים ומכשירים אחרים ברשתות פרטיות. ההתקפות האלה השפיעו על מאות אלפי משתמשים, והתוקפים השתמשו בהן כדי להפנות אותם לשרתים זדוניים.
השינויים הבאים יוצגו ב-Chrome:
- חסימה של בקשות לרשתות פרטיות מאתרים ציבוריים לא מאובטחים, החל מ-Chrome 94.
- חדש: תקופת ניסיון להוצאה משימוש שתסתיים ב-Chrome
- המפתחים יוכלו לבקש הארכה של פרק הזמן למקורות שנבחרו, שלא יושפעו במהלך תקופת הניסיון להוצאה משימוש.
- אנחנו משיקים מדיניות של Chrome שתאפשר לפריסות מנוהלות של Chrome לעקוף את ההוצאה משימוש באופן סופי. התכונה זמינה ב-Chrome 92.
אם אתם זקוקים לזמן נוסף כדי לצמצם את ההשפעה של רישום ההוצאה משימוש, תוכלו להשתמש בתקופת הניסיון של ההוצאה משימוש.
אם יש לכם שליטה אדמיניסטרטיבית על המשתמשים, תוכלו להפעיל מחדש את התכונה באמצעות כללי המדיניות של Chrome.
כדי לצמצם את ההשפעה של ההגבלות החדשות, תוכלו להשתמש באחת מהאסטרטגיות הבאות:
- משדרגים את האתר ל-HTTPS, ואם צריך גם את שרת היעד.
- שדרוג האתר ל-HTTPS ושימוש ב-WebTransport
- היפוך הקשר המוטמע.
ציר הזמן
- נובמבר 2020: בקשה לקבלת משוב על השינויים הצפויים.
- מרץ 2021: אחרי בדיקת המשוב ופניות לגורמים שונים, אנחנו מכריזים על השינויים הצפויים. השם של המפרט השתנה מ-CORS-RFC1918 ל'גישה לרשת פרטית'.
- אפריל 2021: השקת Chrome 90 בגרסה היציבה, עם התראות על הוצאה משימוש.
- יוני 2021: הגרסה 92 של Chrome זמינה בגרסת בטא, ומונעת שליחת בקשות לרשתות פרטיות מהקשרים לא מאובטחים. בעקבות משוב ממפתחים שביקשו זמן נוסף להתאמה, דחיית ההוצאה משימוש הועברה ל-Chrome 93, ותהיה מלווה בתוכנית ניסיון להוצאה משימוש.
- יולי 2021: אחרי משוב נוסף מהמפתחים, הפסקת השימוש והתקופת הניסיון המלווה שלה נדחו ל-Chrome 94. בנוסף, הוצאת התכונה משימוש לא משפיעה יותר על אתרים פרטיים.
- אוגוסט 2021: השקת גרסת הבטא של Chrome 94. מפתחי אתרים יכולים להתחיל להירשם לתקופת הניסיון לקראת ההוצאה משימוש.
- ספטמבר 2021: השקת Chrome 94 בגרסה היציבה. מפתחי האינטרנט צריכים להירשם לתקופת הניסיון לקראת ההוצאה משימוש ולפרוס אסימוני ניסיון בסביבת הייצור.
- דצמבר 2022: סקר לגבי תקופת הניסיון של Origin נשלח והתקבל משוב. תקופת הניסיון להוצאה משימוש הורחבה לגרסה 113 של Chrome.
- מרץ 2023: תקופת הניסיון להוצאה משימוש מורחבת לגרסה 116 של Chrome, ותסתיים בגרסה 117. אנחנו מפתחים מנגנון חלופי שמבוסס על הרשאות, שמטרגט להשקה ראשונית ב-Chrome 114.
- מאי 2023 (משוער): ההשקה של המנגנון המבוסס על הרשאות תתבצע ב-Chrome 114. אתרים יכולים להשתמש בו כדי לצאת מתקופת הניסיון להוצאה משימוש.
- ספטמבר 2023: השקת Chrome 117 בגרסה היציבה, סיום תקופת הניסיון להוצאה משימוש. Chrome חוסם את כל הבקשות לרשתות פרטיות מהקשרים ציבוריים לא מאובטחים.
מהי גישה לרשת פרטית
גישה לרשת פרטית (לשעבר CORS-RFC1918) מגבילה את היכולת של אתרים לשלוח בקשות לשרתים ברשתות פרטיות. הוא מאפשר בקשות כאלה רק מהקשרים מאובטחים. המפרט גם מרחיב את הפרוטוקול של שיתוף משאבים בין מקורות שונים (CORS), כך שאתרים צריכים לבקש באופן מפורש הרשאה מהשרתים ברשתות פרטיות לפני שמותר להם לשלוח בקשות שרירותיות.
בקשות לרשת פרטית הן בקשות שכתובת ה-IP של שרת היעד שלהן פרטית יותר מכתובת ה-IP שממנה הוזן מפעיל הבקשה. לדוגמה, בקשה מאתר ציבורי (https://example.com) לאתר פרטי (http://router.local), או בקשה מאתר פרטי ל-localhost.
מידע נוסף זמין במאמר אנחנו מבקשים משוב: CORS לרשתות פרטיות (RFC1918).
מהו ניסיון בתכונה שהוצאה משימוש
ניסויים להוצאה משימוש (לשעבר ניסויים הפוכים לגרסאות מקור) הם סוג של ניסויים לגרסאות מקור, שמשמשים להוצאה נוחה משימוש של תכונות אינטרנט. תקופות הניסיון להוצאה משימוש מאפשרות ל-Chrome להוציא משימוש תכונות אינטרנט מסוימות ולמנוע מהאתרים ליצור יחסי תלות חדשים בהן, ובמקביל לתת לאתרים הנוכחיים שתלויים בהן זמן נוסף להעביר את עצמם.
במהלך תקופת הניסיון להוצאה משימוש, התכונות הוצאו משימוש כברירת מחדל בכל האתרים. מפתחים שעדיין צריכים להשתמש בתכונות שהושפעו צריכים להירשם לתוכנית הניסוי לקראת ההוצאה משימוש ולקבל אסימונים למקורות אינטרנט ספציפיים. לאחר מכן, הם צריכים לשנות את האתרים שלהם כדי להציג את האסימונים האלה בכותרות HTTP או במטא תגים (חוץ מהמקרה הזה). אם אתר מסוים מציג אסימונים תקינים שתואמים למקור שלהם, Chrome יאפשר להשתמש בתכונה הזולת זמן מוגבל.
למידע נוסף, אפשר לעיין במאמר תחילת העבודה עם גרסת המקור לניסיון של Chrome ובמדריך למפתחי אינטרנט בנושא גרסת המקור לניסיון.
מה עומד להשתנות ב-Chrome
Chrome 94
החל מגרסה 94 של Chrome, אסור להקשרים ציבוריים לא מאובטחים (באופן כללי, אתרים שלא מועברים דרך HTTPS או מכתובת IP פרטית) לשלוח בקשות לרשת הפרטית. בעבר התכנון היה להוציא אותה משימוש ב-Chrome 92, ולכן ייתכן שעדיין יופיעו הודעות על הוצאה משימוש עם ציון ציון הדרך הקודם.
ההוצאה משימוש מלווה בתקופת ניסיון להוצאה משימוש, שמאפשרת למפתחי אתרים שהאתרים שלהם משתמשים בתכונה הזו להמשיך להשתמש בה עד Chrome 116 על ידי רישום לאסימונים. בהמשך מפורטות הוראות לרישום ולהפעלת תקופת הניסיון באתר.
אפשר להשתמש בשני כללי מדיניות של Chrome כדי להשבית את ההוצאה משימוש באופן מלא או במקורות ספציפיים, ללא הגבלת זמן. כך אפשר למנוע שיבושים בהתקנות מנוהלות של Chrome, למשל בהתקנות בארגונים.
Chrome 117
תקופת הניסיון לקראת ההוצאה משימוש מסתיימת. צריך להעביר את כל האתרים מהתכונה הזו, או להגדיר את כללי המדיניות של המשתמשים כך שהתכונה תמשיך לפעול.
פעולות מומלצות למפתחים
השלב הראשון לאתרים שהושפעו הוא כנראה לרכוש זמן עד שאפשר יהיה לפרוס תיקון מתאים: על ידי הרשמה לתקופת הניסיון לקובצי Cookie שהוצאו משימוש או על ידי שימוש בכללי מדיניות. לאחר מכן, הצעדים המומלצים משתנים בהתאם לנסיבות של כל אתר מושפע.
הרשמה לניסיון בתכונה שהוצאה משימוש
- לוחצים על Register (רישום) כדי לקבל אסימון ניסיון למקור המשתתף בתוכנית הניסוי של Private Network Access from non-secure contexts.
- מוסיפים את הערך
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 over HTTP/3 יושק ב-Chrome 96 (הוא התחיל תקופת ניסיון בגרסת המקור) עם אמצעי מיטיגציה להגנה מפני שיתוף מפתחות ושיטות אבטחה אחרות ברמה נמוכה, כולל:
- זמן תפוגה מקסימלי קצר לאישורים מוצמדים.
- מנגנון ספציפי לדפדפן לביטול מפתחות מסוימים שהיו נתונים לשימוש לרעה.
לא נשיק את ההגבלה על הקשר מאובטח עד שנגיע לפחות לשני ציוני דרך אחרי ההשקה המלאה של WebTransport. אם יהיה צורך, נארוך את תקופת הניסיון לקראת ההוצאה משימוש.
הטמעה הפוכה
הפתרון הזה לא דורש שליטה אדמיניסטרטיבית ברשת, וניתן להשתמש בו כששרת היעד לא חזק מספיק כדי להריץ HTTPS.
במקום לאחזר משאבי משנה פרטיים מאפליקציית אינטרנט ציבורית, אפשר להציג שלד של האפליקציה מהשרת הפרטי, שמאחזר את כל משאבי המשנה שלה (כמו סקריפטים או תמונות) משרת ציבורי, כמו CDN. לאחר מכן, אפליקציית האינטרנט שנוצרה יכולה לשלוח בקשות לשרת הפרטי, כי הן נחשבות לאותו מקור. הוא יכול גם לשלוח בקשות לשרתים אחרים עם כתובות IP פרטיות (אבל לא localhost), אבל יכול להיות שהמצב הזה ישתנה בטווח הארוך.
כשמארחים רק שלד בשרת הפרטי, אפשר לעדכן את אפליקציית האינטרנט על ידי דחיפת משאבים חדשים לשרת הציבורי, בדיוק כמו שמעדכנים אפליקציית אינטרנט ציבורית. מצד שני, אפליקציית האינטרנט שמתקבלת היא לא הקשר מאובטח, ולכן אין לה גישה לחלק מהתכונות החזקות יותר של האינטרנט.
תוכניות לעתיד
הגבלת הבקשות לרשת פרטית להקשרים מאובטחים היא רק הצעד הראשון בהשקת Private Network Access. אנחנו פועלים להטמעת שאר המפרט ב-Chrome בחודשים הקרובים. עדכונים נוספים יפורסמו בקרוב.
הגבלת הגישה של localhost מאתרים פרטיים
השינויים ב-Chrome 94 משפיעים רק על אתרים גלויים לכולם שמקבלים גישה לכתובות IP פרטיות או ל-localhost. המפרט של הגישה לרשת פרטית מסווג גם בקשות מאתרים פרטיים אל localhost כבעייתיות. בסופו של דבר, גם האפשרויות האלה יוצאו משימוש ב-Chrome. עם זאת, יש כאן כמה אתגרים שונים, כי לאתרים פרטיים רבים אין שמות דומיין, ולכן קשה יותר להשתמש באסימונים לניסיון של ההוצאה משימוש.
בקשות קדם-הפעלה של CORS
החלק השני של Private Network Access הוא סינון בקשות לרשת פרטית שמגיעות מהקשרים מאובטחים באמצעות בקשות CORS של קדם-הפעלה. הרעיון הוא שגם אם הבקשה בוצעה מהקשר מאובטח, שרת היעד יתבקש לספק הרשאה מפורשת למבצע הבקשה. הבקשה נשלחת רק אם ההענקה מתבצעת.
בקצרה, בקשת קדם-הפעלה של CORS היא בקשת HTTP OPTIONS עם כמה כותרות Access-Control-Request-* שמציינות את אופי הבקשה הבאה. לאחר מכן, השרת יכול להחליט אם להעניק גישה מפורטת או לא, על ידי שליחת תגובה 200 OK עם כותרות Access-Control-Allow-*.
פרטים נוספים מופיעים במפרט.
הגבלת אחזור הניווט
מערכת Chrome מוציאה משימוש בקשות למשאבי משנה ברשתות פרטיות, ובסופו של דבר תחסום אותן. השינוי הזה לא ישפיע על ניווט לרשתות פרטיות, שאפשר להשתמש בהן גם בהתקפות CSRF.
במפרט של Private Network Access אין הבחנה בין שני סוגי האחזור, שיחויבו בסופו של דבר באותן הגבלות.
תמונת השער של Markus Spiske מ-Unsplash