יש דעה: טכנולוגיית DANE לדפדפנים נכשלה

אנחנו מדברים על מהי טכנולוגיית DANE לאימות שמות דומיין באמצעות DNS ומדוע אין בה שימוש נרחב בדפדפנים.

/unsplash/ פאוליוס דראגונאס

מה זה DANE

רשויות אישורים (CA) הן ארגונים אשר מאורסים תעודה קריפטוגרפית תעודות SSL. הם שמו עליהם את החתימה האלקטרונית שלהם, המאשרים את האותנטיות שלהם. עם זאת, לפעמים נוצרים מצבים שבהם מונפקים תעודות עם הפרות. לדוגמה, בשנה שעברה גוגל יזמה "הליך של אי-אמון" עבור אישורי סימנטק עקב הפשרה שלהם (סיקרנו את הסיפור הזה בפירוט בבלוג שלנו - זמן и два).

כדי למנוע מצבים כאלה, לפני מספר שנים ה-IETF התחיל להתפתח טכנולוגיית DANE (אבל היא לא נמצאת בשימוש נרחב בדפדפנים - נדבר על למה זה קרה מאוחר יותר).

DANE (אימות מבוסס DNS של ישויות שמות) הוא קבוצה של מפרטים המאפשרת לך להשתמש ב-DNSSEC (Name System Security Extensions) כדי לשלוט בתוקף של תעודות SSL. DNSSEC היא הרחבה למערכת שמות הדומיין שממזערת את התקפות זיוף כתובות. באמצעות שתי הטכנולוגיות הללו, מנהל אתרים או לקוח יכולים ליצור קשר עם אחד ממפעילי אזור ה-DNS ולאשר את תקפות האישור בשימוש.

בעיקרו של דבר, DANE פועלת כאישור בחתימה עצמית (הערב לאמינותו הוא DNSSEC) ומשלים את הפונקציות של CA.

אֵיך מַפעִילִים אֶת זֶה

מפרט DANE מתואר ב RFC6698. על פי המסמך, ב רשומות משאבי DNS נוסף סוג חדש - TLSA. הוא מכיל מידע על התעודה המועברת, גודל וסוג הנתונים המועברים, כמו גם הנתונים עצמם. מנהל האתר יוצר טביעת אצבע דיגיטלית של התעודה, חותם עליה ב-DNSSEC ומציב אותה ב-TLSA.

הלקוח מתחבר לאתר באינטרנט ומשווה את האישור שלו ל"העתק" שהתקבל ממפעיל ה-DNS. אם הם תואמים, המשאב נחשב לאמין.

דף הוויקי של DANE מספק את הדוגמה הבאה של בקשת DNS אל example.org ביציאת TCP 443:

IN TLSA _443._tcp.example.org

התשובה נראית כך:

 _443._tcp.example.com. IN TLSA (
   3 0 0 30820307308201efa003020102020... )

ל-DANE יש מספר הרחבות שעובדות עם רשומות DNS מלבד TLSA. הראשון הוא רשומת SSHFP DNS לאימות מפתחות בחיבורי SSH. זה מתואר ב RFC4255, RFC6594 и RFC7479. השני הוא ערך OPENPGPKEY להחלפת מפתחות באמצעות PGP (RFC7929). לבסוף, השלישי הוא רשומת SMIMEA (התקן אינו רשמי ב-RFC, יש רק טיוטה שלו) להחלפת מפתחות קריפטוגרפיים באמצעות S/MIME.

מה הבעיה עם DANE

באמצע חודש מאי התקיים כנס DNS-OARC (מדובר בארגון ללא מטרות רווח העוסק באבטחה, יציבות ופיתוח מערכת שמות הדומיין). מומחים באחד הפאנלים הגיע למסקנהשטכנולוגיית DANE בדפדפנים נכשלה (לפחות ביישום הנוכחי שלה). נכח בכנס ג'ף יוסטון, מדען מחקר מוביל APNIC, אחד מחמישה רשמי אינטרנט אזוריים, השיב על DANE כ"טכנולוגיה מתה".

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

בעיות בהפצת DANE בדפדפנים קשורות לאורך תהליך האימות של DNSSEC. המערכת נאלצת לבצע חישובים קריפטוגרפיים כדי לאשר את האותנטיות של תעודת ה-SSL ולעבור את כל שרשרת שרתי ה-DNS (מאזור השורש ועד לדומיין המארח) בעת החיבור הראשון למשאב.

/unsplash/ קיילי דיקסטרה

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

סיבה נוספת לפופולריות הנמוכה של DANE היא השכיחות הנמוכה של DNSSEC בעולם - רק 19% מהמשאבים עובדים איתו. מומחים סברו שזה לא מספיק כדי לקדם את DANE באופן פעיל.

סביר להניח שהתעשייה תתפתח לכיוון אחר. במקום להשתמש ב-DNS לאימות תעודות SSL/TLS, שחקני השוק יקדמו במקום זאת פרוטוקולי DNS-over-TLS (DoT) ו-DNS-over-HTTPS (DoH). הזכרנו את האחרון באחד שלנו חומרים קודמים על האברה. הם מצפינים ומאמתים בקשות משתמשים לשרת ה-DNS, ומונעים מתוקפים לזייף נתונים. בתחילת השנה, DoT כבר היה מוטמע ל-Google עבור ה-DNS הציבורי שלה. באשר ל-DANE, האם הטכנולוגיה תוכל "לחזור לאוכף" ועדיין להיות נפוצה נותר לראות בעתיד.

מה עוד יש לנו לקריאה נוספת:

כיצד להפוך את ניהול תשתיות ה-IT לאוטומטי - דיון בשלוש מגמות
JMAP - פרוטוקול פתוח שיחליף את IMAP בעת החלפת מיילים

כיצד לשמור עם ממשק תכנות יישומים
DevOps בשירות ענן באמצעות הדוגמה של 1cloud.ru
האבולוציה של ארכיטקטורת הענן 1cloud

כיצד פועלת התמיכה הטכנית של 1cloud?
מיתוסים על טכנולוגיות ענן

מקור: www.habr.com