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

הסבר מקיף מדוע חסימת הרשת של מיקי זוהר לא אפשרית טכנית

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

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

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

בדבר אחד שכחו להתמקד שם ובו אני אעסוק במאמר הזה – האם המערכת של מיקי זוהר היא אפשרית מבחינה טכנית? אני מדגיש – אפשרית מבחינה טכנית ולא האם קל לעקוף אותה כיוון שברור שכל מערכת צנזורה וסינון ברמת ספק האינטרנט (לא התקנת תוכנה על המחשב) היא קלה לעקיפה ברמה שנדרשות דקות בודדות ואפס ידע טכני כדי לעקוף אותה. מי שרוצה דוגמה יכול לשאול את זיר״ה במלחמתה האבודה לחסום את אתר סדרות. שהוא אתר אחד שהיא לא מצליחה לחסום.
אבל השאלה היא האם ניתן לבנות מערכת עם קוד בדומה למה שמיקי זוהר רוצה לבנות? התשובה הקצרה היא: לא. על מנת להבין את התשובה הזו, אני אאלץ להסביר מעט על ארכיטקטורת רשת. אני מתנצל מראש על ההסברים הטכניים, ניסיתי לפשט אותם ככל האפשר – אבל השאלה היא שאלה טכנית ויש לה תשובה טכנית מאוד פשוטה שמצריכה הבנה מסוימת. אני מקווה שאוכל להעביר את חוסר התוחלת הטכני במילים מובנות.

ראשית עלינו להבין שמדובר בחסימה של אתרים בלבד ולא של תוכן. כלומר, גם החסימה הכי רצחנית שיש בישראל ברמת הספק אינה יכולה לסנן תכנים פוגעניים באתרים לגיטימיים לחלוטין. כלומר, אם אני נכנס לאתר לגיטימי לחלוטין המכיל תמונות וסרטונים (כמו טוויטר למשל) ומחפש porn images או אחר תמונות של הציפור ׳כוס׳, אף תוצאה לא תסונן. מדוע? כיוון שמידע המוגש באתרים המאובטחים בפרוטוקול HTTPS אינם ניתן לשינוי או אפילו בדיקה על ידי הספקית. באופן עקרוני, כל ילד שגולש לו בהנאה ביוטיוב עלול להתקל בסרטון הזה של לינדרמן ולחזות במחזות קשים מנשוא ואין ספקית אינטרנט שיכולה למנוע את זה או כל הצגת תמונות/סרטונים אסורים אחרים באתר HTTPS שיש בו תכנים לגיטימיים לצד תכנים "אסורים" ועובד בפרוטוקול מאובטח (כמו ווטסאפ, טלגרם, אינסטגרם, סנאפצ׳אט, טמבלר וכו׳ וכו׳).

https://www.youtube.com/watch?v=5Be1DNHmQP8
קליפ של להקת לינדרמן. לא תרצו שילד יראה דבר כזה

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

ראשית, עלינו להבין איך בדיוק מתבצעת ״תנועה״ לאתר אינטרנט מאובטח. אתרי אינטרנט מאובטחים מהווים את רוב האתרים באינטרנט והדיון יתמקד בהם בלבד. מדובר בתנועה בשכבה הגבוהה ביותר של האינטרנט (שכבה 7) והיא עובדת כך:
הלקוח מבקש מהדפדפן לגשת לאתר פורנו, לצורך העניין https://porn.com
הבקשה נשלחת לשרת DNS של הספקית, שרת ה-DNS מתרגם את כתובת הפורנו לכתובת IP. כתובת ה-IP היא ה״כתובת״ של השרת. הדרך שבה המחשבים מתקשרים. כשאנו טוענים אתר, התקשורת כולה נעשית עם IP כשלכל שרת יש כתובת משלו והתקשורת מתבצעת באמצעות הכתובת הזו. במקרה של pron.com כתובת השרת היא 94.199.252.153.
הדפדפן ניגש אל ה-IP הזה. מדובר בפרוטוקול https מוצפן. אני לא רוצה להכנס אל נושא ההצפנה, אבל בתהליך ההצפנה האתר נדרש להצהיר על שם המתחם שלו באופן שאינו מאפשר זיוף. רק אחרי הצהרה של האתר שהוא porn.com, הדפדפן יציג את התוצאה לגולש.

מערכת צנזורה סטנדרטית משנה את הדרך הזו בכך שהיא גורמת לשרת ה-DNS שלא להחזיר כתובת IP תקינה בתשובה. איך זה עובד?
הלקוח משגר בקשה לאתר פורנו, לצורך העניין https://porn.com
הבקשה נשלחת לשרת ה-DNS של הספקית, אך זו לא מחזירה את כתובת ה-IP שבה השרת הנכון נמצא אלא כתובת IP אחרת, לצורת העניין של שרת בשליטתה שמציג מסך אזהרה ׳אתר זה חסום׳.
השרת של הספקית אינו יכול להצהיר על עצמו שיש לו את שם המתחם המבוקש, כי הוא לא רשום תחת porn.com ותעודת האבטחה שלו לא תומכת בכך. המשתמש מקבל הודעת שגיאה חמורה.
בגלל הארכיטקטורה של הפרוטוקול הודעת השגיאה ׳אתר זה חסום׳ לעולם לא יוצג בלי התראת אבטחה חמורה.

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

  1. הלקוח משגר בקשה לאתר פורנו, לצורך העניין https://porn.com
  2. הבקשה נשלחת לשרת ה-DNS של הספקית, אך זו לא מחזירה את כתובת ה-IP שבה השרת הנכון נמצא אלא כתובת IP אחרת של שרת בשליטתה שבה יש מקום להכניס את מספר תעודת הזהות והסיסמה הסודית.
  3. אם הכל תקין, שרת ה-DNS אמור להחזיר תשובה שונה ולהעביר את המשתמש למקום המתאים.
  4. המשתמש לא יידרש להזין שוב את מספר תעודת הזהות שלו, או לחלופין, יעבור פרק זמן של חודש עד להזנה מחודשת.

הבעיה המרכזית היא עם סעיפים 2, 3 ו-4.

ראשית, לא תוצג אף הודעה מסודרת ללקוח, תוצג הודעת שגיאת דפדפן על אתר לא מאובטח. מדוע? בגלל פרוטוקול ה-https. כאשר שרת ה-DNS של הספקית יחזיר תוצאת IP שונה, לא יוכל להתבצע תהליך הזיהוי והדפדפן במקרה הזה מזהה את השינוי הזה כמתקפה ומציג דף שגיאה ואזהרה חמורה לגולש.

הלקוח המבולבל יצטרך להכנס לAdvanced ואז ללחוץ על proceed to porn.com.

ורק אז הודעת השגיאה המסודרת תטען לו. זה כבר מקל גדול בגלגלים, כיוון שהודעת האזהרה הזו לא באה ״סתם״. היא הודעת אזהרה על התקפה. נכון, זה נראה משונה שמי שמתקיף אותנו היא ספקית הרשת. אבל זו התקפה והלקוח לא יכול לדעת אם מדובר בהתקפה ממשית או מערכת צנזורה שהשתגעה. לחיצה על Proceed היא בעייתית ומסוכנת. שימוש במנגנון כזה יגרום לאדם להתייחס להתראות אבטחה מסוג זה כמשהו בשגרה, וכאשר הוא באמת הוא יותקף בהתקפה כזו (ויש לא מעט התקפות כאלו), לא יהיה באפשרותו לזהות את ההתקפה.
זה כבר הופך את המערכת לבעייתית מבחינה טכנית. כיוון שהמשתמשים לא אמורים לאשר דברים כאלו ורובם לא יעשו את זה. אבל הבעיה האמיתי היא שלא מעט אתרים משתמשים ב-HSTS. מנגנון שמונע גישה לאתר כאשר תעודת האבטחה שלו לקויה. מנגנון כזה לא יאפשר לגולש כלל להמשיך לדף הכנסת הסיסמה של הספקית – כלומר הגולש לא יוכל להזין את הסיסמה הסודית בדף החסימה ולא יוכל לשחרר אותה לעולם ולהכנס לאתר.


דף אזהרה ללא מתן אפשרות להתעלמות מהאזהרה ולהמשיך הלאה

זה קושי טכני שמונע דה פקטו שימוש במנגנון המוצע של חה"כ זוהר. אבל תאמינו או לא, זה לא הקושי הטכני העיקרי. בהנחה שהאתר אינו מכיל מנגנון HSTS והמשתמש אזר אומץ, לחץ על אישור והגיע לאתר הספקית והקליד מספר זהות וסיסמה תקינה, המערכת תוכל לטעון מחדש את האתר האסור, במקרה הזה porn.com. כלומר, תרשים הזרימה יהיה כזה:
כניסה לאתר porn.com
קבלת מסך שגיאה אדום ומפחיד של התקפה. ניווט לתחתית המסך, לחיצה על Advanced ואז על 'Proceed׳
הגעה למסך והזנת מספר הזהות והסיסמה הסודית.
לנסות להכנס שוב לאתר porn.com ולהתפלל שעד אז לא היה לך ניתוק באינטרנט או שינוי IP בדרך אחרת (ספקיות יוזמות שינויי IP כל הזמן מסיבות טכניות).

שימו לב לסעיף 4. בעיה טכנית קריטית ומשמעותית נוספת היא האבחנה – כיצד שרת ה-DNS ידע להבחין בין מישהו ש״קיבל״ אישור לבין מישהו שלא? כיוון שאין יכולת לשרת ה-DNS לשתול עוגיות או אמצעי זיהוי אצל המשתמש, אז שרת ה-DNS יצטרך לבחון את ה-IP של מי שמבקש את הבקשה ורק אז להחליט איזו תוצאה להחזיר לו – דבר שיאט מאוד את הגלישה לכולם. בנוסף, לא תהיה אבחנה בין גולשים שמשתמשים ברשת אחת (כמו רשת בית ספרית, בית קפה, רשת לימודית או מקום עבודה). או משפחה שלמה שמשתמשת בנתב אחד כדי לגלוש (כמו רוב המשפחות) ואז ההורה, שאישר כניסה לאתר ׳אסור׳ באייפד שלו, בעצם איפשר גלישה חופשית גם לילד שגולש בחדר הילדים. הגולשים יצטרכו להקליד שוב ושוב את מספר תעודת הזהות שלהם בכל פעם שהם משנים IP. כלומר אחת לכל כמה ימים בתסריט הטוב או אחת לכל כמה שעות בתסריט הפחות טוב. דבר שהופך את המערכת למטרידה מאוד ובעצם לצנזורה בפועל ושונה לגמרי מהמערכת הנקיה שזוהר רואה בעיני רוחו. ולהזכירכם, בכל פעם שה-IP משתנה, המשתמשים יאלצו שוב ושוב להקליד את מספר הזהות שלהם בכל שינוי IP ולהתמודד עם אזהרות אבטחה חמורות.
ניסיון לפתור את הבעיה הזו או לא לתת עליה את הדעת גורמת לכל המערכת להיות ממש בלתי אפשרית – עם כל שינוי IP אתה מקבל כתובת שהייתה מן הסתם של מישהו אחר, שאולי שחרר את הכתובת הזו (ואז הפך אותה לפתוחה בלי סיסמה) – המערכת בעצם תאפשר גלישה חופשית למי שרוצה סינון וכלל לא תסנן. כתבתי לעיל שמדובר במערכת לא אפשרית טכנית וזו אחת מהסיבות. שרת DNS לא אמור לעקוב מי פונה אליו ולהחזיר תוצאות שונות. ניסיון להכריח אותו לעשות כן עלול לגרור תוצאות כאלו.

חשוב לציין שבעתיד, תוטמע מערכת Domain Name System Security Extensions בשרתים רבים ותמנע מניפולציה בעייתית כזו בשרתי DNS. איגוד האינטרנט כבר הטמיע את המערכת בתשתית האינטרנט וככל שיותר אתרים יתמכו בה, כך לא יהיה ניתן לחסום את האינטרנט באופן הזה ושיטת החסימה הזו תהפוך לא רלוונטית.

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

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

כמה מילים נוספות לחבריי הטכניים – ייתכן גם שמר זוהר אינו כיוון לדרך הפעולה שאותה הצעתי (סינון באמצעות DNS) והוא רוצה לייצר סינון מחוכם יותר (שיש לו בעיות אחרות כמובן). אבל כיוון שהוא לא צירף שום מסמך טכני – כל מה שיש לי אלו ההשערות שלי בנושא. יש דרכים אחרות לבצע חסימת DNS כמו למשל להשתמש ב-DNS Sinkholes, מדובר בדרך אפקטיבית שבה שרת ה-DNS הופך לפרוקסי שיכול לעקוב אחר משתמשים אך יש לדרך זו סט בעיות אחרות הקשורות לעלות תחזוקה גבוהה מאוד ולביצועים נמוכים מאוד. אי אפשר להשתמש בהן באופן ארצי למגוון רחב של אתרים בצורה אפקטיבית. ניתן לכוון לחסימת IP, אך זו מכילה סיכונים משמעותית, יקרה הרבה יותר לתחזוקה ואפילו עלולה להשבית את תשתיות הרשת במדינה (כמו שרוסיה השביתה את תשתיות הרשת שלה במרדף אחר טלגרם) או נזקים אבטחתיים מחרידים שאף מדינה לא גרמה עדיין לתשתית שלה (כמו למשל, תיאורטית, שיתוף פעולה עם Root CA כלשהי שתנפיק לה Sub CA עבור הספקיות השונות). כך או אחרת, כולם יסכימו שהצעת חוק ללא התייעצות עם גורמים מקצועיים וללא חוות דעת של גורמים מקצועיים עלולה לגרום בזבוז כסף משמעותי במקרה הטוב ואסון במקרה הרע. הייתי מצפה מהצעת חוק שבאה להסדיר תשתית, שתציע את הפתרון. כרגע, אין אף פתרון שידוע לנו שלא כולל בחובו אתגרים משמעותיים ביותר ויקרים מאוד לפתרון, אם הם ניתנים לפתרון. יש סיבה שאף מדינה לא בחרה בפתרון המוזר שחבר הכנסת מיקי זוהר הגה ממוחו הקודח. יש פטנטים שעדיף שישארו במגירה.

אני מודה מאוד לאנשים הבאים (מסודרים לפי א'-ב' של שם פרטי) על הביקורת הטכנית:

איתי סעדיה, חוקר אבטחת מידע וסייבר
גיל בהט, יועץ IT
ים מסיקה, חוקר וכתב אבטחת מידע
לביא שיפמן, מהנדס מחשבים, חבר ועד באיגוד האינטרנט
נדב שורק, איש מחשבים
רועי גיל, מהנדס מערכות תקשורת, Oath


פוסטים נוספים שכדאי לקרוא

פיתוח ב-JavaScript

Axios interceptors

תכנון נכון של קריאות AJAX באפליקציה ריאקטית וניהול השגיאות או ההצלחות עם פיצ׳ר נחמד של axios

תמונה של הבית הלבן עם מחשוב ענן וטקסט: FEDRAMP
פתרונות ומאמרים על פיתוח אינטרנט

FedRAMP & FIPS מבוא למתחילים

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

צילום מסך של סוואגר
יסודות בתכנות

openAPI

שימוש בתשתית הפופולרית למיפוי ותיעוד של API וגם הסבר בסיסי על מה זה API

פתרונות ומאמרים על פיתוח אינטרנט

רינדור של קליינט סייד עם SSR

הסבר קצר על SSR מול רינדור קלאסי ולא. לא תמיד זה טוב להשתמש בו. אין כדור כסף שיכול לפתור הכל.

גלילה לראש העמוד