احتفظ به مشفرًا وحافظ عليه آمنًا: العمل مع ESNI و DoH و DoT

تشمل أحدث التطورات في حماية الخصوصية على الإنترنت إشارة اسم خادم TLS المشفر (ESNI) و DNS المشفر في شكل DNS عبر HTTPS (DoH) ، وكلاهما يعتبران مثيرًا للجدل من قبل جامعي البيانات.

لذا ، إليك نظرة سريعة على أسباب وجودهم ، والتفاصيل حول ماهيتهم ، والتكنولوجيا الكامنة وراء كيفية عملهم.

يحتاج DNS إلى العمل بشكل صحيح

اتصالات الشبكة الخاصة الافتراضية (VPN) ذات النفق المنفصل ، وبروتوكول الاكتشاف التلقائي لوكيل الويب (WPAD) ، ونظام DNS للبث المتعدد ذي التكوين الصفري (mDNS) ، والقوائم السوداء في الوقت الفعلي (RBL) ، والعديد من التقنيات الأخرى المنتشرة على نطاق واسع تتعطل عندما يتعطل DNS ر تعمل بشكل صحيح.

كسر الإنترنت من أجل الربح والشهرة

منذ عام 2003 ، تعرف مستخدمو الإنترنت على أهمية DNS على نطاق عالمي عندما اختارت الشركة التي كانت تدير نطاق المستوى الأعلى .com (TLD) التوقف عن إصدار استجابات NXDOMAIN . وبدلاً من ذلك ، قاموا بانتحال هوية أي مجال غير موجود في محاولة لعرض المزيد من الإعلانات وبيع المزيد من المجالات وتحقيق المزيد من الأرباح في نهاية المطاف. أدى التأثير غير المتوقع إلى مناقشة عامة وتقرير مدين من اللجنة الاستشارية للأمان والاستقرار (SSAC) التابعة لـ ICANN. تم إغلاق هذا المشروع بالفعل ولكن من الناحية الفنية ، استمرت الثغرة الأمنية.

في وقت لاحق من عام 2008 ، تم استدعاء محاولة أخرى للتلاعب بـ DNS من أجل الربح بشكل علني عندما انتهى الأمر ببعض أكبر مزودي خدمات الإنترنت إلى تقديم طرق مختلفة لهجمات البرمجة النصية عبر المواقع ضد أي موقع ويب حرفيًا. نظرًا لطبيعة الثغرات الأمنية ، يمكن استغلال حتى مواقع الويب المستضافة على شبكة خاصة والتي يتعذر الوصول إليها من الإنترنت.

المشكلة التي تم العثور عليها ليست في بروتوكولات الإنترنت الأساسية ولكنها بدلاً من ذلك مشكلة تفاقمت بسبب تسييل بعض ميزات DNS بشكل غير مناسب.

بول فيكسي ، اتحاد أنظمة الإنترنت (ISC)

على الرغم من صحة أن البروتوكولات نفسها ليست سبب المشكلة حقًا ، إلا أنه من الصحيح أيضًا أن هذه البروتوكولات لا تمنع الجهات الفاعلة السيئة من إساءة استخدام النظام. لذا من وجهة نظر فنية ، استمرت قابلية التأثر.

كسر الإنترنت للمراقبة والرقابة

في عام 2016 ، لوحظ أن مزودي خدمة الإنترنت في إيران كانوا يتلاعبون بـ DNS. هذه المرة ، بدلاً من حقن الإعلانات ، قاموا بحظر الوصول إلى خوادم البريد الإلكتروني في 139 من أصل 10000 نطاق على الإنترنت. ليس من الواضح ما إذا كانت هذه سياسة مقصودة لرفض الخدمة ضد هذه المجالات المحددة - على غرار الرقابة المشهورة عالميًا في الصين - أو ربما مجرد مثال على التنفيذ التقني السيئ لأي نظام يعترض استفسارات DNS.

إن عدم معرفة سبب اعتراض DNS أمر مهم: حتى إذا وضعنا جانبًا الأسئلة الأخلاقية والقانونية حول المراقبة الشاملة والرقابة ، فإن التكنولوجيا المستخدمة للقيام بذلك - بحكم طبيعتها - ليست متوافقة مع المعايير ويمكن أن تتداخل معها استخدامك العادي واليومي والمعقول والقانوني للإنترنت.

ومع ذلك ، من وجهة نظر فنية ، استمر الضعف.

كسر الإنترنت لأغراض شائنة

بالطبع ، ليست الكيانات التجارية والحكومات فقط هي التي تحاول اعتراض حركة الإنترنت بوسائلها الخاصة. هناك العديد من الأمثلة على المجرمين الذين يحاولون اختطاف الاتصالات ، عادة لأغراض سرقة بيانات المستخدم أو خداع المستخدمين للكشف عن بيانات اعتماد وصول مهمة. الأهم من ذلك ، تم استخدام تسميم ذاكرة التخزين المؤقت لنظام أسماء النطاقات لتوجيه المستخدمين إلى مواقع التصيد الاحتيالي ، ونشر برامج الفدية ، ونشر شبكات الروبوت ، ورفض الخدمة إلى مواقع ويب محددة ، وأكثر من ذلك بكثير.

تسرب TLS من يتصل بمن

أمان طبقة النقل (TLS) هي التقنية التي تكمن وراء HTTPS ، الإصدار الآمن من HTTP الذي نعتمد عليه جميعًا كل يوم. يتطلب إنشاء اتصال TLS عددًا من الخطوات ، يُثبت خلالها الخادم هويته من خلال تقديم شهادة ، ويتم تبادل مفاتيح التشفير الجديدة.

يعد استخدام الخادم لشهادة لإثبات هويته خطوة مهمة للغاية ، حيث يعد جزء من الشهادة مفتاح تشفير عام غير متماثل.

عندما يرسل العميل رسالة باستخدام هذا المفتاح ، يمكن فقط للخادم الذي يمتلك المفتاح الخاص المرتبط قراءة الرسالة. نتيجة لذلك ، يتم حظر أي شخص يعترض الاتصال أو يستمع إليه ولا يمكنه قراءة المحتوى.

ومع ذلك ، لا يزال هذا التبادل الأولي يتم بشكل واضح بدون تشفير ، مما يعني أن المراقب سيعرف دائمًا هوية الخادم.

مواجهة المجال

عملت بعض أدوات نوع مكافحة الرقابة على حل هذا التسرب في TLS لفترة من الوقت باستخدام تقنية تُعرف باسم واجهة المجال. يستغل هذا حقيقة أنه بمجرد إنشاء اتصال HTTPS ، لا يتحقق معظم موفري الاستضافة الكبار لمعرفة ما إذا كان اسم المضيف المقدم في كل طلب HTTP يطابق الاسم المستخدم في مصافحة TLS. فيما يتعلق بأدوات الخصوصية ، فقد تم النظر إلى هذا على أنه ميزة مفيدة تسمح بالاتصال السري مع موقع مخفي. بالنسبة لموفري الاستضافة وجامعي البيانات ، كان يُنظر إلى هذا على أنه إساءة استخدام للطريقة التي تم بها تنفيذ المواصفات.

هذه في حد ذاتها ثغرة أمنية ، وعلى هذا النحو تم إصلاحها من قبل العديد من مزودي الاستضافة الرئيسيين ، بما في ذلك AWS.

حل المشكلة عن طريق تغيير المعيار: SNI المشفر (ESNI)

الفكرة من ESNI هي منع TLS من تسريب أي بيانات عن طريق تشفير جميع الرسائل ، بما في ذلك رسالة Client Hello الأولية. هذا يترك أي مراقب في حالة جهل تمامًا بشأن شهادة الخادم التي يقدمها الخادم.

للقيام بذلك ، يحتاج العميل إلى مفتاح تشفير قبل إجراء الاتصال. لذلك ، يتطلب ESNI وضع مجموعة محددة من مفاتيح تشفير ESNI في سجل SRV في DNS.

ومع ذلك ، لا تزال التفاصيل الدقيقة لهذا في حالة تغير مستمر ، حيث لم يتم الانتهاء من المواصفات بعد. على الرغم من ذلك ، تم تنفيذ تطبيق ESNI بالفعل بواسطة Mozilla Firefox و Cloudflare.

تأمين وتشفير DNS

لتسليم مفاتيح ESNI دون اعتراضها ، من المهم الحماية من العبث بنظام DNS.

منذ عام 1993 ، كان مجتمع الإنترنت يحاول تأمين DNS. يلاحظ IETF أن اجتماعات حل المشكلات المبكرة ناقشت:

1. الحماية من الكشف عن بيانات DNS لأطراف غير مصرح لها
2. ضمان سلامة البيانات
3. مصادقة أصل البيانات

نتج عن هذه الاجتماعات معيار امتدادات أمان نظام أسماء النطاقات (DNSSEC) في عام 1997. اختار المعيار معالجة اثنين من ثلاثة من هذه المخاوف ، حيث اتخذ فريق التصميم قرارًا صريحًا لحكم جميع تهديدات الكشف عن البيانات بشكل صريح خارج النطاق.

على هذا النحو ، يعني DNSSEC أنه يمكن للمستخدمين الوثوق في أن الإجابات على استفسارات DNS الخاصة بهم هي ما ينوي أصحاب المجال أن يكونوا عليه. في سياق ESNI ، هذا يعني أننا نعلم أن المفتاح الذي نتلقاه لم يتم العبث به ، ولحسن الحظ ، تختفي الكثير من نقاط الضعف المذكورة أعلاه عندما يكون DNSSEC قيد الاستخدام. ومع ذلك ، فهو لا يضمن الخصوصية وبالتالي لا يزال عرضة للمشاكل التي تسببها أنظمة المراقبة والرقابة.

لسوء الحظ ، نظرًا لأنه متوافق تمامًا مع الإصدارات السابقة مع "DNS غير الآمن" ومن الصعب جدًا تنفيذه بشكل صحيح ، فإن اعتماد DNSSEC منخفض جدًا. يستسلم العديد من مالكي النطاقات جزئيًا من خلال محاولة تهيئته ، كما يتضح من العديد من التكوينات غير الصالحة ونصف الإعداد التي شوهدت في البرية.

DNS عبر HTTPS (DoH)

لكي يتم تسليم مفاتيح ESNI دون معرفة المراقبين بالموقع الذي يحاول المستخدمون زيارته ، من المهم الحماية من تنصت DNS. على هذا النحو ، فمن المنطقي والمفهوم أن نقول إن DNS المشفر (مثل DoH) شيء جيد. ومع ذلك ، كما هو الحال اليوم ، فإن DNS غير مشفر.

هناك تحركات من قبل Mozilla و Google و APNIC و Cloudflare و Microsoft وآخرين لتغيير هذا.

تجربة المستخدم المشفرة المثالية

قد يكون لدى المستخدم الذي يرغب في الاستفادة من التقنيات المذكورة أعلاه قائمة طويلة من المتطلبات عندما يتعلق الأمر بتفاصيل تجربة المستخدم العملية للعمل مع التشفير. على الأرجح ، يريدون تجنب ما يلي:

• الاضطرار إلى استخدام مزود خدمة DNS محدد (بغض النظر عن مدى جودته) أو أن يكون الاختيار غير مرئي أو يصعب العثور عليه
• كل تطبيق على جهاز يتعامل مع DNS بشكل مختلف (على سبيل المثال ، يمكن لمتصفح Firefox العثور على أشياء لا يستطيع Safari العثور عليها)
• يتعين على جميع التطبيقات الموجودة على الجهاز إنشاء تطبيق DNS آمن خاص بها داخل نفسه
• الحاجة إلى تكوين DNS يدويًا عدة مرات
• الحاجة إلى الاشتراك في الخصوصية والأمان
• عودة التطبيقات إلى التشغيل غير الآمن بدون موافقة المستخدم

بدلاً من ذلك ، قد يرغب المستخدمون المهتمون بالخصوصية في:

• الخصوصية من المراقبة غير المبررة من قبل أي شخص
• الحماية من الإعلانات المستهدفة التي لم يوافقوا عليها
• حماية المحتوى المنشور الخاص بهم (على سبيل المثال ، على موقع ويب شخصي) من التغيير أو التلاعب به في طريقه إلى مشاهدين آخرين
• التأكد من أن مشاهدي المحتوى المنشور الخاص بهم لن يواجهوا مشكلة لمجرد الوصول إليه
• للاستمرار في الحصول على خيار التحكم في DNS على شبكاتهم الخاصة (لأنه في بعض الأحيان ، يكون تقسيم الأفق DNS مفيدًا للحفاظ على الموارد الداخلية في نطاق المستخدمين الداخليين)
• القدرة على الاشتراك أو على الأقل إلغاء الاشتراك في التصفية على مستوى DNS (على سبيل المثال ، Quad9 و CleanBrowsing و OpenDNS Family Shield)
• تكوين سهل وخالي من المتاعب (على سبيل المثال ، DHCP)
• أن يُطلب منك الموافقة على استخدام DNS بدون تشفير
• الحماية ليس فقط لحركة مرور المتصفح ، ولكن لجميع أنواع حركة المرور ، على سبيل المثال ، البريد الإلكتروني ، Slack ، VoIP ، SSH ، VPN ، إلخ.

جهود التشفير الحالية

ما هي الخيارات المتاحة للمستخدمين مع الأهداف المذكورة أعلاه؟

يعتبر حل Mozilla مجرد بداية ، ولكنه بعيد عن أن يكون مثاليًا. إنهم يؤمنون Firefox فقط ؛ الافتراضي هو تجاوز إعدادات نظام التشغيل لصالح اختيارهم للمزود (Cloudflare) دون قول ذلك ، ويعود الأمر بصمت إلى كونه غير آمن (في حالات حظر DNS المشفر ، وما إلى ذلك)

حل Google هو نهج أفضل. إنهم يقومون بتأمين Android 9 + - وهو ما ينطبق على جميع التطبيقات. (لست متأكدًا من خططهم لنظام التشغيل Chrome ، لكنني أظن أنها قيد العمل.) إنهم يؤمنون أيضًا Chrome على جميع الأنظمة الأساسية ، لكنه لا يقوم بتشغيل الأمان إلا عندما يتم تكوين النظام الأساسي المضيف لاستخدام موفر يدعم الأمان. يعد هذا أمرًا جيدًا من حيث اختيار المستخدم ، ولكنه ليس مثاليًا لأنه يعود بصمت إلى كونه غير آمن.

جميع المتصفحات الرئيسية الأخرى تقدم الدعم أيضًا.

في الوضع المثالي للمستخدمين ، فإن المجتمع الأوسع لمطوري البرامج وأنظمة التشغيل سوف:

1. توقف عن تنفيذ ميزات أمان DNS الجديدة على مستوى التطبيق
2. ابدأ في تنفيذها على مستوى نظام التشغيل
3. احترم التكوين على مستوى نظام التشغيل ، أو احصل على موافقة المستخدم

عند تنفيذ DNS المشفر على مستوى نظام التشغيل ، يمكننا الاستمرار في اتباع نفس النموذج الموزع الذي لدينا حاليًا لمحللي DNS. تشغيل خادم DNS الخاص بالفرد على شبكته الخاصة ، والقدرة على جعل هذا المحلل آمنًا ، من المنطقي الاستمرار في كونه خيارًا ، كما ينبغي استخدام مزود مركزي.

يحتوي كل من Linux و BSD بالفعل على هذه الوظيفة مع مجموعة متنوعة من الخيارات المتاحة. لسوء الحظ ، لا يوجد توزيعة تمكّن أيًا منها افتراضيًا ، على حد علمي. تحقق من nss-tls إذا كنت تريد شيئًا سيتم توصيله بـ glibc.

يقوم تطبيق DNS-over-TLS من Google في Android 9+ بهذا أيضًا بالفعل. يعمل عن طريق اختبار خادم DNS لدعم التشفير. إذا كان يحتوي عليه ، فسيستخدمه. إذا لم يحدث ذلك ، فسيستمر - كما هو الحال مع Chrome - بطريقة غير آمنة ، دون المطالبة بالموافقة.

تجدر الإشارة إلى أن معظم الشبكات مهيأة لاستخدام خوادم DNS التي لا تدعم التشفير ، وبالتالي فإن الحل المدمج في Android لا يغير أي شيء بالنسبة لمعظم المستخدمين. ربما يكون من الأفضل عرض الرجوع إلى DNS المركزي المشفر في الحالات التي لا تدعم فيها اللامركزية التشفير.

بالنسبة لأجهزة Apple و Microsoft ذات النكهة ، لم يصل دعم DNS المشفر رسميًا حتى كتابة هذه السطور. مع إعلان Microsoft في نوفمبر 2019 عن نواياها لدعم DNS المشفر ، نأمل أن تتبعها Apple قريبًا.

حلول DNS المشفرة

هناك بعض الحلول في شكل وكلاء يمكن تشغيلها محليًا. باستخدام هذه ، يتحدث كمبيوتر المستخدم DNS غير المشفر لنفسه ، والذي يتحدث بعد ذلك DNS المشفر إلى أي مزود تم تكوينه لاستخدامه. هذا ليس حلاً مثاليًا ، ولكن مع استمرار الحلول ، فهو لائق.

مصدر الإلهام لكتابة هذا المقال هو وكيل DNSCrypt ، وهو مستقر للغاية ، ولديه الكثير من الأجراس والصفارات ، وهو متعدد المنصات. وهو يدعم بروتوكول DNSCrypt الأقدم ، بالإضافة إلى DNS الأحدث عبر TLS (DoT) و DNS عبر بروتوكولات HTTPS (DoH).

بالنسبة لمستخدمي Windows ، هناك مثبت وواجهة مستخدم رسومية تسمى Simple DNSCrypt ، وهي ميزة كاملة وسهلة الاستخدام.

أوصي بذلك ، ولكن اعلم أن العالم ربما ليس جاهزًا لك بعد ، وقد تحتاج إلى تعطيله من وقت لآخر (على سبيل المثال ، عندما تضطر إلى استخدام بوابة مقيدة في المقهى المفضل لديك ، أو في شبكة محلية) حفل).

خيارات أخرى

بالإضافة إلى ذلك ، هناك خادم Technitium DNS Server ، الذي يدعم DNS المشفر ، وهو متعدد المنصات (Windows ، MacOS ، Linux على ARM / Raspberry Pi) ، ويتميز بواجهة ويب أنيقة. إنه موجود ضمن "أخرى" لأنه يمثل أداة شاملة أكثر من كونه حلًا خاصًا بهذه المشكلة. (من المحتمل أن يكون اختيارًا جيدًا إذا كنت ترغب في تشغيل خادم Raspberry Pi DNS في المنزل. سأكون مهتمًا بسماع التعليقات من الأشخاص الذين جربوها في التعليقات أدناه.)

بالنسبة لأجهزة Android أو iOS (iPhone ، iPad ، إلخ) ، يوجد أيضًا تطبيق 1.1.1.1 ، والذي سيفرض جميع استعلامات DNS الخاصة بك عبر خدمة Cloudflare Encrypted DNS. سمعت أن هناك تطبيقات أكثر مرونة أيضًا ، مثل Intra ، لكنني لم أقضي الوقت في اختبارها بعد.

بالطبع ، يمكنك أيضًا تمكين DNS المشفر في كل من Firefox و Chrome - فقط ضع في اعتبارك جميع التحذيرات التي تمت مناقشتها أعلاه.

موثوقية DNS: المهمة الأولى

هناك الكثير من الجدل حول تقنية الخصوصية على الإنترنت. ومع ذلك ، عندما يتعلق الأمر بتنفيذ تدابير الأمان والخصوصية ، فإن التكنولوجيا المعنية لا تتعلق أساسًا بالحفاظ على الأسرار. يتعلق الأمر بضمان الموثوقية وضمان استمرار التكنولوجيا في العمل بشكل صحيح على الرغم من سلوك الآخرين. ومع ذلك ، يجب أن نضع في اعتبارنا أنه ، تمامًا كما أن التكنولوجيا بدون ضمانات الخصوصية سيئة ، فإن الضمانات التي يتم تنفيذها بشكل سيء لا يمكن إلا أن تزيد الوضع سوءًا.