DNS غافل عبر HTTPS (ODoH): محاولة لتحسين خصوصية DNS

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

أحد هذه العطاءات - وهو عرض حديث جدًا - هو إدخال DNS عبر بروتوكول HTTPS (DoH) ، والذي يعد بتأمين اتصال DNS عن طريق إرساله بطريقة مشفرة. في حين أن DoH تبدو واعدة من الناحية النظرية وتمكنت من إصلاح إحدى المشكلات مع DNS ، فإنها تثير قلقًا آخر عن غير قصد. لإصلاح ذلك ، لدينا الآن بروتوكول جديد آخر ، يسمى Oblivious DNS over HTTPS (ODoH) ، والذي تم تطويره بالاشتراك مع Cloudflare و Apple و Fastly. Oblivious DoH هو في الأساس امتداد لبروتوكول DoH الذي يفصل استعلامات DNS من عناوين IP (للمستخدم) لمنع محلل DNS من معرفة المواقع التي يزورها المستخدم - نوع من [المزيد حول هذا لاحقًا].

قال نيك سوليفان ، رئيس الأبحاث في Cloudflare ، في مدونة: " ما يُقصد به ODoH هو فصل المعلومات حول من يقوم بالاستعلام وما هو الاستعلام ".

DNS غافل عبر HTTPS (أو ODoH)

قبل القفز مباشرة إلى ماهية ODoH ، دعنا أولاً نفهم ما هو DNS ، وبالتالي ، DNS عبر HTTPS ، والقيود التي يفرضها كلاهما.

DNS (نظام اسم المجال)

نظام اسم المجال أو DNS هو نظام لامركزي لحفظ سجلات جميع مواقع الويب على الإنترنت. يمكنك التفكير في الأمر كمستودع (أو دليل هاتف) لأرقام الهواتف التي تحتوي على قائمة بمشتركي الهاتف وأرقام هواتفهم المقابلة.

فيما يتعلق بالإنترنت ، يعد DNS لاعبًا مهمًا في إنشاء نظام يمكّنك من الوصول إلى موقع ويب بمجرد إدخال اسم المجال الخاص به ، دون مطالبتك بتذكر عنوان IP (بروتوكول الإنترنت) المرتبط به. نتيجة لذلك ، يمكنك إدخال techpp.com في حقل العنوان لعرض هذا الموقع دون الحاجة إلى تذكر عنوان IP الخاص به ، والذي قد يبدو مثل 103.24.1.167 [وليس عنوان IP الخاص بنا]. كما ترى ، فإن عنوان IP هو المطلوب لإنشاء اتصال بين جهازك وموقع الويب الذي تحاول الوصول إليه. ولكن نظرًا لأن عنوان IP ليس من السهل تذكره مثل اسم المجال ، فهناك حاجة لمحلل DNS لحل أسماء المجال في عناوين IP المرتبطة بها وإعادة صفحة الويب المطلوبة.

مشكلة مع DNS

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

DoH (DNS عبر HTTPS)

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

مشكلة مع DoH

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

بروتوكول ODoH وعمله

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

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

باختصار ، يعمل ODoH كامتداد لبروتوكول DoH الذي يهدف إلى تحقيق ما يلي:

أنا. منع محلل DoH من معرفة العميل الذي طلب أسماء النطاقات عن طريق توجيه الطلبات عبر الوكيل لإزالة عناوين العملاء ،

ثانيا. منع الوكيل من معرفة محتويات الاستعلامات والردود ، ومنع المحلل من معرفة عناوين العملاء من خلال تشفير الاتصال في طبقات.

تدفق الرسائل مع ODoH

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

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

وفقًا لمدونة من Cloudflare ، إليك ما يضمنه التشفير والوكيل:

أنا. الهدف يرى فقط الاستعلام وعنوان IP الخاص بالوكيل.

ثانيا. الوكيل ليس لديه رؤية لرسائل DNS ، مع عدم القدرة على تحديد أو قراءة أو تعديل الاستعلام الذي يتم إرساله من قبل العميل أو الإجابة التي يتم إرجاعها من قبل الهدف.

ثالثا. يمكن فقط للهدف المقصود قراءة محتوى الاستعلام وتقديم استجابة.

توافر ODoH

DNS غافل عبر HTTPS (ODoH) هو مجرد بروتوكول مقترح حتى الآن ويحتاج إلى الموافقة عليه من قبل IETF (فريق مهام هندسة الإنترنت) قبل اعتماده عبر الويب. على الرغم من أن Cloudflare تقترح ، حتى الآن ، أنها حصلت على شركات مثل PCCW و SURF و Equinix كشركاء وكيل للمساعدة في إطلاق البروتوكول وأنها أضافت القدرة على تلقي طلبات ODoH على خدمة DNS 1.1.1.1. ، حقيقة الأمر هي أنه ما لم تضيف متصفحات الويب دعمًا أصليًا للبروتوكول ، فلا يمكنك استخدامه. بالنسبة إلى البروتوكول ، لا يزال في مرحلة التطوير ويتم اختباره من أجل الأداء عبر الوكلاء ومستويات زمن الانتقال والأهداف المختلفة. كسبب ، قد لا يكون من الحكمة التحكيم في مصير مكتب ODoH على الفور.

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

ولكن ، إذا تمكن ODoH من الارتقاء إلى مستوى مطالباته فيما يتعلق بالخصوصية والأداء ، فإن دمجه مع DoH ، أثناء العمل جنبًا إلى جنب ، يمكن أن يعالج كلاً من الخصوصية والمخاوف الأمنية الخاصة بـ DNS. وبدوره ، اجعل الأمر أكثر خصوصية وأمانًا مما هو عليه اليوم.