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