تيم هادسون، رئيس شركة OpenSSL – سلسلة المقابلات

Tim Hudson هو مؤلف مشارك لـ SSLeay وإحدى منظمي OpenSSL Conference، براغ 13-15 أكتوبر 2026. لديه أكثر من 30 عاماً من الخبرة في أمان الأنظمة والشبكات وهو رئيس OpenSSL Corporation ورئيس قسم التكنولوجيا في Cryptsoft Pty Ltd. منذ عام 1995، شملت أعماله المشاركة في تأسيس SSLeay مع إريك يونغ، مكتبة التشفير التي أصبحت OpenSSL Library، وتأسيس مركز تطوير RSA Security أستراليا، والمساهمة في تغييرات تنظيم تصدير التشفير في الولايات المتحدة، وقيادة أكثر من 30 عملية اعتماد FIPS 140، ورئاسة اللجان التقنية OASIS KMIP و SAM، وإلقاء كلمة في مؤتمرات أمان رائدة بما فيها RSA Conference، AusCERT، ICMC، LinuxConf، ومؤتمر OpenSSL.

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

قمت بتأسيس SSLeay مع إريك يونغ في عام 1995 بعد إدراك الحاجة إلى تنفيذ غير أمريكي لـ SSL، وأصبح هذا العمل في النهاية أساساً لـ OpenSSL. ما المشكلة التي كنت تحاول حلها أصلاً، وهل كان لديك أي تصور في ذلك الوقت أن التقنية قد تصبح جزءاً أساسياً من تأمين الإنترنت؟

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

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

لم يكن هذا هو المشهد الكامل. كل جزء كان بسيطاً لكن هناك عدد كبير من الأجزاء. يوفر تنفيذ DES لك شفرة متماثلة واحدة. يتطلب SSL تشفير المفتاح العام، حسابات ذات دقة تعسفية، ASN.1، معالجة شهادات X.509، وآلية حالة بروتوكول، وكل ذلك يجب أن يكون صحيحاً، لأن في التشفير القريب من الصواب يكاد يكون معطلاً. قدمت حجم المشروع بتفاؤل. سرعان ما أدرك إريك مقدار ما كان عليه، واستمتع بذلك، لأن الحجم تحول إلى الجاذبية بدلاً من العقبة. لست متأكداً إذا كان سيبدأ بطريقة أخرى.

هو الذي قام بالجزء الأساسي للتشفير، ولهذا تحمل المكتبة أحرفه الأولى. توليت الأجزاء التي تحول المكتبة إلى شيء يمكن للآخرين نشره فعلياً: تكامل التطبيق، الاختبار، الوثائق، وجانب المجتمع. كما بحثت بنشاط عن أي مكتبة تشفير منافسة تُستخدم وحولتها أو استبدلتها. كان عملي هو SSLtelnet، SSLftp، NCSA httpd والعديد من الحزم الأخرى، وهي تطبيقات مبنية على الخوارزميات والبروتوكولات التي نفذها إريك. هذا المزيج سمح لكل منا بالتركيز على ما يهمه فعلاً، وأعتقد أن هذا هو السبب الرئيسي لاستمرار المشروع.

كوننا في أستراليا هو ما جعل الحل ممكنًا أصلاً، ثم تبين أن الكثير من الأشخاص الآخرين كانوا يواجهون نفس المشكلة لنفس السبب. شيء بُني لتلبية طلب عميل محدد في بريزبن أصبح مفيداً للجميع خارج الولايات المتحدة، وفي النهاية للعديد داخلها أيضاً.

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

لقد عملت في مجال التشفير وأمن الإنترنت لأكثر من ثلاثة عقود. ما هو التغيير الأكثر دراماتيكية في مشهد التهديدات خلال تلك الفترة، وأي مشاكل أمنية ظلت مفاجأةً متشابهة رغم التقدم الهائل في التكنولوجيا؟

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

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

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

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

أهم شيء يجب فهمه حول 4.0 هو أنه في الأساس إصدار حذف، وهذا كان هدفه.

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

هناك إضافات: Encrypted Client Hello، دعم RFC 8998 بما في ذلك مجموعة SM2/ML-KEM الهجينة، cSHAKE، SNMP و SRTP KDFs، و FFDHE المتفاوض عليها لـ TLS 1.2. يغلق ECH على وجه الخصوص فجوة خصوصية حقيقية، لأن إشارة اسم الخادم كانت تسرب هوية كل موقع تزوره منذ إطلاق TLS 1.3. لكن الإزالة هي القصة.

النقطة التي أود أن تستخلصها المنظمات هي هذه: 4.0 ليس الإصدار طويل الأمد (LTS). يدعم حتى مايو 2027. الإصدار المستقر طويل الأمد الحالي هو 3.5، يدعم حتى أبريل 2030، ويحتوي 3.5 بالفعل على خوارزميات ما بعد الكم. إذا أردت أحدث شفرة، استخدم 4.0. إذا أردت هدفاً مستقراً يمكنك بناء خطة ترحيل لخمس سنوات حوله، استخدم 3.5. اختيار الرقم الأعلى لمجرد أنه أعلى هو خطأ نراه الناس يكررونه كل دورة.

انتقلت التشفير ما بعد الكم من مشكلة بحثية إلى تحدي ترحيل، مع دعم OpenSSL بالفعل لـ ML-KEM، ML-DSA، و SLH-DSA وتبادل مفاتيح ما بعد الكم الهجين. بالنسبة للقادة التجاريين الذين يعتقدون أن الحوسبة الكمومية لا تزال بعيدة جداً للقلق، ما المخاطر التي يغفلونها اليوم؟

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

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

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

الأمر الثالث هو القيد الذي لا يخصص له ميزانية أحد: توقيعات ما بعد الكم كبيرة. توقيع ML-DSA-65 هو تقريباً خمسون مرة حجم توقيع ECDSA P-256، وSLH-DSA أكبر من ذلك. هذا يسبب مشاكل: أحجام المصافحة، الأجهزة المقيدة، البروتوكولات ذات الحدود الصلبة للحقول، الروابط الساتلية وإنترنت الأشياء. تكتشف هذه المشكلات بالاختبار، لا بقراءة معيار.

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

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

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

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

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

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

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

الذكاء الاصطناعي يغيّر شيئاً واحداً فعلاً، ويمكنني التحدث عنه مباشرة لأنه حدث لنا.

عدد كبير من الثغرات التي تم الكشف عنها في OpenSSL هذا العام تم اكتشافه بواسطة تحليل مدفوع بالذكاء الاصطناعي. في يناير أصدرنا نسخة أصلحت اثني عشر مشكلة، جميعها تقريباً من مجموعة بحثية واحدة استخدمت التحليل الآلي، وقد قدموا تصحيحات إلى جانب التقارير. في يونيو أصلحنا ثغرة عالية الخطورة من نوع use-after-free في تحقق PKCS#7 تم العثور عليها بواسطة باحث يعمل مع نظام ذكاء اصطناعي. هذا يمثل تغييراً حقيقياً في القدرة على اكتشاف أخطاء أمان الذاكرة وتحليل الشيفرة في كود C ناضج تمت مراجعته من قبل خبراء لسنوات. رأيت نفس النمط في مكتبات تشفير أخرى. عند تحليل مجموعة من CVE الخاصة بـ Bouncy Castle لهذا العام، كان بصمة التحليل الآلي واضحة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يقبلون أن المعلومات الأولية مؤقتة ويتواصلون وفقاً لذلك. معظم الضرر السمعة الذي لاحظته لم يأتِ من الاختراق بل من تصريحات مبكرة وواثقة اضطررت إلى سحبها. القول “هذا ما نعرفه، وهذا ما لا نعرفه بعد، وهذا متى سنحدثكم” ليس ضعفاً. إنه الموقف الوحيد الذي لن تحتاج إلى عكسه.

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

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

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

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

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

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

نظرة إلى العقد القادم، ما هو الانتقال الأمني أو التشفيري الذي تعتقد أن المنظمات ما زالت تقلل من شأنه اليوم، وما هي الدروس المستفادة من تطور SSL، OpenSSL، وثلاثين عاماً من أمان الإنترنت التي يجب على القادة تطبيقها أثناء الاستعداد له؟

الانتقال الذي أعتقد أنه يُقلل من قيمته أكثر هو ليس التشفير ما بعد الكم كمشكلة خوارزمية. إنه هوية الآلة وتسلسل الشهادات تحت كل شيء.

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

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

1. التحولات تستغرق عقداً من الزمن أطول مما يُعلن. تم إلغاء SSLv3 في 2015، وتعطيله افتراضياً في 2016، وأزلنا الشيفرة نهائياً في أبريل 2026. هذا أحد عشر عاماً، لبروتوكول وافق الجميع على أنه معطوب. خطط لترحيل ما بعد الكم وفقاً لهذه الحقيقة، لا وفقاً للبيان الصحفي.
2. الإعدادات الافتراضية هي التحكم الأمني الوحيد الذي يعمل على نطاق واسع. أي شيء يتطلب من كل مسؤول اتخاذ قرار صحيح لن يحدث. السبب في انتشار تبادل المفاتيح ما بعد الكم الهجين بسرعة هو أنه مفعّل افتراضياً ولا يتطلب أي قرار. صمّم للناس الذين لن يقرأوا وثائقك أبداً، لأنهم تقريباً الجميع.
3. أنت تعتمد على عدد أقل من الأشخاص مما تعتقد. تقريباً كل منظمة على الأرض تعتمد على شفرة تشفير يصونها عدد قليل جداً من الأفراد. كان ذلك صحيحاً عندما كنا نحن الاثنين في بريزبن، ولم يتغير الهيكل أساساً رغم أن المخاطر ارتفعت بأ orders of magnitude. أيًا كان ما تخطط له للعقد القادم، جزءاً منه يعتمد على صيانة لم تتواصل معها أبداً ولا تمولها. من المفيد أن تعرف ذلك قبل أن تحتاجهم.

شكرًا على هذه المقابلة الرائعة. القراء الذين يرغبون في معرفة المزيد يجب أن يزوروا OpenSSL.