חזית דומיין מבוססת על TLS 1.3

מבוא

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

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

לא מעט מאמרים כבר נכתבו על הטכנולוגיה הזו וניתנו דוגמאות רבות. עם זאת, טכנולוגיות ה-DNS-over-HTTPS וה-SNI הפופולריות והנדונות לאחרונה, כמו גם הגרסה החדשה של פרוטוקול TLS 1.3, מאפשרים לשקול אפשרות נוספת לחזית דומיין.

הבנת הטכנולוגיה

ראשית, בואו נגדיר מעט מושגים בסיסיים כך שלכל אחד תהיה הבנה מי הוא מי ולמה כל זה נחוץ. הזכרנו את מנגנון ה-eSNI, שתפעולו יידון בהמשך. מנגנון eSNI (אינדיקציית שם שרת מוצפנת) הוא גרסה מאובטחת של SNI, זמינה רק עבור פרוטוקול TLS 1.3. הרעיון המרכזי הוא להצפין, בין היתר, מידע לאיזה דומיין נשלחת הבקשה.

כעת נסתכל כיצד פועל מנגנון ה-eSNI בפועל.

נניח שיש לנו משאב אינטרנט שנחסם על ידי פתרון DPI מודרני (בוא ניקח, למשל, את מעקב הטורנטים המפורסם rutracker.nl). כאשר אנו מנסים לגשת לאתר של עוקב טורנטים, אנו רואים את הסטב הסטנדרטי של הספק המציין שהמשאב חסום:

באתר RKN הדומיין הזה רשום למעשה ברשימות העצירה:

כאשר אתה שואל whois, אתה יכול לראות שהדומיין עצמו "מוסתר" מאחורי ספק הענן Cloudflare.

אבל בניגוד ל"מומחים" מ-RKN, עובדים בעלי ידע טכני יותר מ-Beeline (או לימדו על ידי הניסיון המר של הרגולטור המפורסם שלנו) לא אסרו בטיפשות את האתר לפי כתובת IP, אלא הוסיפו את שם הדומיין לרשימת העצירה. אתה יכול לאמת זאת בקלות אם אתה מסתכל אילו דומיינים אחרים מסתתרים מאחורי אותה כתובת IP, בקר באחד מהם ותראה שהגישה אינה חסומה:

איך זה קורה? איך ה-DPI של הספק יודע באיזה דומיין נמצא הדפדפן שלי, מאחר שכל התקשורת מתרחשת באמצעות פרוטוקול https, ועדיין לא שמנו לב להחלפה של תעודות https מ-Beeline? האם הוא בעל ראיית רוח או שעוקבים אחריי?

בואו ננסה לענות על שאלה זו על ידי התבוננות בתנועה דרך wireshark

צילום המסך מראה שתחילה הדפדפן מקבל את כתובת ה-IP של השרת באמצעות DNS, לאחר מכן מתרחשת לחיצת יד רגילה של TCP עם שרת היעד, ולאחר מכן הדפדפן מנסה ליצור חיבור SSL עם השרת. לשם כך, הוא שולח חבילת SSL Client Hello, המכילה את שם תחום המקור בטקסט ברור. שדה זה נדרש על ידי שרת החזית Cloudflare על מנת לנתב נכון את החיבור. זה המקום שבו הספק DPI תופס אותנו, שובר את הקשר שלנו. יחד עם זאת, אנחנו לא מקבלים שום בדל מהספק, ואנו רואים את שגיאת הדפדפן הרגילה כאילו האתר מושבת או פשוט לא עובד:

כעת נפעיל את מנגנון eSNI בדפדפן, כפי שנכתב בהוראות עבור Firefox :
לשם כך אנו פותחים את דף התצורה של Firefox about: config והפעל את ההגדרות הבאות:

network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true

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

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

הפעם, חבילת ssl client hello אינה מכילה במפורש את דומיין היעד, אלא במקום זאת הופיע שדה חדש בחבילה - encrypted_server_name - כאן נמצא הערך של rutracker.nl, ורק שרת החזית של cloudflare יכול לפענח את זה שדה. ואם כן, אז לספק DPI אין ברירה אלא לשטוף ידיים ולאפשר תעבורה כזו. אין אפשרויות אחרות עם הצפנה.

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

חזית דומיין עם eSNI

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

אנו משכפלים את המאגר מ-GitHub ומרכיבים כרגיל:

$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config

$ make
$ cd esnistuff
$ make

לאחר מכן, אנו משכפלים את המאגר עם curl ומגדירים את ההידור שלו באמצעות ספריית openssl המהידור שלנו:

$ cd $HOME/code
$ git clone https://github.com/niallor/curl.git curl-esni
$ cd curl-esni

$ export LD_LIBRARY_PATH=/opt/openssl
$ ./buildconf
$ LDFLAGS="-L/opt/openssl" ./configure --with-ssl=/opt/openssl --enable-esni --enable-debug

כאן חשוב לציין נכון את כל הספריות שבהן נמצא openssl (במקרה שלנו, זה /opt/openssl/) ולוודא שתהליך ההגדרה יעבור ללא שגיאות.

אם ההגדרה תצליח, נראה את השורה:

אזהרה: esni ESNI מופעל אך מסומן ניסיוני. השתמש בזהירות!

$ make

לאחר בניית החבילה בהצלחה, נשתמש בקובץ bash מיוחד מ-openssl כדי להגדיר ולהפעיל את curl. בואו נעתיק אותו לספרייה עם סלסול לנוחות:

cp /opt/openssl/esnistuff/curl-esni 

ולבצע בקשת https לבדיקה לשרת cloudflare, תוך הקלטת מנות DNS ו-TLS בו-זמנית ב-Wireshark.

$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/

בתגובת השרת, בנוסף למידע רב על ניפוי באגים מ-openssl ו-curl, נקבל תגובת HTTP עם קוד 301 מ-cloudflare.

HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 13:12:55 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Sun, 03 Nov 2019 14:12:55 GMT
< Location: https://www.cloudflare.com/

מה שמצביע על כך שהבקשה שלנו נמסרה בהצלחה לשרת היעד, נשמעה ועובדה.

עכשיו בואו נסתכל על מזבלה התנועה ב-wireshark, כלומר. מה שראה הספק DPI במקרה זה.

ניתן לראות ש-curl פנה תחילה לשרת ה-DNS לקבלת מפתח eSNI ציבורי עבור שרת cloudflare - בקשת TXT DNS ל-_esni.cloudflare.com (חבילה מס' 13). לאחר מכן, באמצעות ספריית openssl, curl שלח בקשת TLS 1.3 לשרת cloudflare בה הוצפן שדה ה-SNI עם המפתח הציבורי שהושג בשלב הקודם (חבילה מס' 22). אבל, בנוסף לשדה eSNI, חבילת SSL-hello כללה גם שדה עם ה-SNI הרגיל - פתוח, אותו נוכל לציין בכל סדר (במקרה זה - www.hello-rkn.ru).

שדה SNI פתוח זה לא נלקח בחשבון בשום צורה בעת עיבוד על ידי שרתי cloudflare ורק שימש כמסיכה עבור הספק DPI. שרת cloudflare קיבל את חבילת ה-ssl-hello שלנו, פענח את ה-eSNI, חילץ משם את ה-SNI המקורי ועיבד אותו כאילו כלום לא קרה (הוא עשה הכל בדיוק כפי שתוכנן בעת ​​פיתוח eSNI).

הדבר היחיד שניתן לתפוס במקרה זה מנקודת מבט של DPI הוא בקשת ה-DNS העיקרית אל _esni.cloudflare.com. אבל הפכנו את בקשת ה-DNS רק כדי להראות איך המנגנון הזה פועל מבפנים.

כדי לשלוף סוף סוף את השטיח מתחת ל-DPI, אנו משתמשים במנגנון DNS-over-HTTPS שהוזכר כבר. הסבר קטן - DOH הוא פרוטוקול המאפשר להגן מפני התקפה של man-in-the-middle על ידי שליחת בקשת DNS דרך HTTPS.

בוא נבצע את הבקשה שוב, אבל הפעם נקבל מפתחות eSNI ציבוריים באמצעות פרוטוקול https, לא DNS:

ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/

dump תעבורת הבקשה מוצג בצילום המסך למטה:

ניתן לראות כי curl ניגש תחילה לשרת mozilla.cloudflare-dns.com באמצעות פרוטוקול DoH (חיבור https לשרת 104.16.249.249) כדי לקבל מהם את ערכי המפתחות הציבוריים להצפנת SNI, ולאחר מכן אל היעד שרת, מסתתר מאחורי הדומיין www.hello-rkn.ru.

בנוסף לפתרון DoH הנ"ל mozilla.cloudflare-dns.com, אנו יכולים להשתמש בשירותי DoH פופולריים אחרים, למשל, מתאגיד הרשע המפורסם.
בוא נריץ את השאילתה הבאה:

ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

ונקבל את התשובה:

< HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 14:10:22 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure
< Location: https://rutracker.nl/forum/index.php
< CF-Cache-Status: DYNAMIC
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 52feee696f42d891-CPH

במקרה זה, פנינו לשרת rutracker.nl החסום, באמצעות ה-DoH resolver dns.google (אין כאן שגיאת הקלדה, כעת לתאגיד המפורסם יש דומיין ברמה ראשונה משלו) וכיסינו את עצמנו בדומיין אחר, שהוא בהחלט אסור לכל DPI לחסום תחת כאב מוות. בהתבסס על התגובה שהתקבלה, אתה יכול להבין שהבקשה שלנו טופלה בהצלחה.

כבדיקה נוספת לכך שה-DPI של הספק מגיב ל-SNI הפתוח, שאנו משדרים ככיסוי, אנו יכולים להגיש בקשה ל-rutracker.nl במסווה של משאב אסור אחר, למשל, עוקב אחר טורנטים "טוב":

$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

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

סיכום קצר לחלק הראשון

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

מקור: www.habr.com