لماذا لا يستطيع openssl rand إنشاء المفتاح الذي يريده tls-crypt

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

ما يجب أن يكونه الملف على القرص فعليًا

ملف المفتاح الثابت في OpenVPN نصّي. يبدأ بسطر تعليق يعلن ما هو، ويحمل بيانات سداسية عشرية في صفوف ذات عرض ثابت، ويبلغ مجموع مادة المفتاح فيه 256 بايت. يقرأه OpenVPN كالسر المشترك لقناة التحكم، لا كشهادة، ولا كعبارة مرور، ولا كشيء تعرفه مكتبة TLS.

يخدم النوع نفسه من الكائنات ميزتي قناة التحكم. مع tls-auth، يحتاج كل طرف أيضًا إلى اتجاه حتى لا يمكن إعادة إرسال حزم أحد الجانبين إليه. مع tls-crypt، يشفّر سر مشترك واحد قناة التحكم ويوثّقها في الاتجاهين، ما يخفي المصافحة ويحميها في الوقت نفسه.

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

الطريقة المدعومة لإنشاء واحد

ولّد المفتاح الثابت البسيط بالأداة التي ستستهلكه، ثم أشر إليه من الطرفين:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

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

يضيف الجيل الثاني بنية لا يستطيع أي مولّد خارجي اختراعها. يُنشأ مفتاح الخادم مرة واحدة، ويتلقى كل عميل مفتاحًا مغلّفًا مشتقًا منه:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

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

أين تنهار البايتات المصنوعة يدويًا

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

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

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

التدوير دون إغلاق الباب على الجميع

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

مع ترتيب v2، يكون التدوير لكل جهاز: أصدر مفتاحًا مغلّفًا جديدًا لجهاز واحد وأحِل المفتاح القديم للتقاعد لذلك الجهاز وحده. هذه هي الحجة الرئيسية للانتقال بمجرد أن يصبح كل عميل على إصدار يدعمه.

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