سجّل ما كشفه المؤلف، ولا تمنح القفل سلطة على كل الترويسات: RFC 9788

الخلاصة

• يحفظ HP-Outer داخل الحمولة المشفرة نسخة محمية من كل ترويسة غير بنيوية كشفها المؤلف عمداً في الخارج؛ فهو إيصال لقرار الإنشاء لا مراقب لمسار التسليم كله.
• تحدد طبقات MIME المشفرة التي وصلت حالة الحماية الفعلية، أما hp فيصف نية المؤلف ولا يحول محاولة التشفير إلى سرية منجزة.
• يجب الفصل بين From الداخلي والخارجي، وصحة التوقيع وربطه بالعنوان، ومصادقة النقل، والقيمة المعروضة، وعنوان الرد، لأن لكل قرار سلطة إثبات مختلفة.

لنتخيل أن نظام أرشفة يستقبل رسالة مشفرة. لا يحتاج المشغّل إلى فتح النص أولاً؛ يكفيه أن يرى سجلاً محمياً يقول إن المؤلف وضع Date وFrom في الخارج، وأخفى Subject بالقيمة [...]. هذا السجل مفيد، لكنه لا يقول إن وسيطاً لاحقاً لم يغير From، ولا إن التاريخ لم يُستدل عليه من Received، ولا إن الشهادة الموقعة مرتبطة فعلاً بعنوان المرسل الداخلي.

الخطأ الإداري يبدأ عندما تُختزل هذه الوقائع في حقل واحد: secure=true. عندها ترث واجهة العرض سلطة طبقة التشفير، ويرث عنوان الرد سلطة الترويسة الخارجية، ويصبح قصد المؤلف بديلاً عن البنية التي وصلت.

RFC 9788 يقاوم هذا الضغط. إنه يبني سلسلة إيصالات بدلاً من وصف شامل.

التشفير بنية MIME لا شارة

يصف RFC 9787 البريد المحمي بوصفه شجرة MIME تحتوي طبقات تشفير متعاقبة. طبقة التوقيع توفر السلامة والأصالة بقدر ما تنجح عملية التحقق. طبقة التشفير توفر السرية، وقد توفر السلامة وفق الصيغة المستخدمة. ترتيب الطبقات يغير المعنى؛ فالتوقيع ثم التشفير ليس هو التشفير ثم التوقيع.

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

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

حاول RFC 8551 حماية الترويسات بتغليف كائن message/rfc822 كامل. أظهرت برامج قديمة مشكلات في العرض والمعالجة الأمنية. يستبدل RFC 9788 ذلك الأسلوب بنسخ الترويسات المعروفة للمؤلف مباشرة إلى الحمولة المشفرة. في الرسالة المشفرة يمكن إبقاء الحقل الخارجي كما هو، أو حجبه بقيمة أخرى، أو حذفه.

وجود نسخة مشفرة لا يثبت أي خيار استُخدم. قد تكون هناك نسخة داخلية سرية ونسخة خارجية واضحة في الوقت نفسه.

HP-Outer إيصال لقرار الكشف

يوضع HP-Outer داخل رأس الحمولة المشفرة. لكل ترويسة غير بنيوية قرر برنامج الإنشاء إخراجها، يجب أن يسجل الاسم والقيمة الخارجية في نسخة محمية.

إذا استبدل Subject الخارجي بـ[...]، يظهر هذا البديل في الإيصال. وإذا مر Date بلا تغيير، تظهر قيمته الواضحة. وإذا لم توجد أي نسخة HP-Outer لحقل محمي، فإن المؤلف يقرر أنه لم يضع نسخة خارجية منه لحظة إدخال الرسالة في نظام البريد.

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

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

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

هذه هي حدود طبقات الواقع: السجل يصف القرار الذي شهده ولا يملك بقية المسار.

سياسة تنفذ ولا تُرسل باسمها

سياسة سرية الترويسات HCP هي دالة تتلقى اسم الحقل وقيمته، ثم تعيد القيمة نفسها، أو بديلاً محجوباً، أو null لإزالة الحقل من الرأس الخارجي.

الخيار الموصى به hcp_baseline متحفظ. يحوّل Subject إلى [...]، ويحذف Comments وKeywords، ويمرر الباقي. أما hcp_shy فيزيل أيضاً أسماء العرض من From وTo وCc، ويحوّل Date إلى UTC. يقلل معلومات قابلة للقراءة، لكنه يحتاج تحليلاً أدق وقد يضر التسليم أو العرض، لذلك ليس الافتراضي الموصى به.

اسم السياسة لا يظهر على السلك. يرى المستقبل نتائجها من خلال HP-Outer. يسجل IANA أوصافاً ثابتة قابلة للتنفيذ وحالة التوصية. لا يثبت السجل أن منتجاً نفذ السياسة، أو أن حساباً فعّلها، أو أن رسالة بعينها استخدمتها.

يبقى المستوى المشترك رفيعاً: صيغة الحقل، دالة قابلة للاختبار، وقواعد التسجيل. قد تختار بيئة إخفاء To أو Cc أو References أو In-Reply-To، لكن المرشحات والخيوط والقوائم والتشخيص قد تعتمد عليها. تحتاج السرية الأوسع إلى إثبات محلي للتسليم والاستخدام؛ لا يدفع اسم السياسة كلفتها.

hp يصف القصد لا النتيجة

يحمل Content-Type المحمي معامل hp. القيمة cipher تقول إن المؤلف حاول حماية الترويسات مع التشفير، وclear تصف بناءً موقّعاً فقط. يجب أن تأتي الحالة الفعلية من طبقات MIME التي وصلت.

رسالة موقعة فقط تحمل hp=cipher تبقى بلا سرية. لا يجوز للتطبيق أن يرفع تقديره بسبب النية. والعكس ممكن أيضاً: قد يلف وسيط رسالة كانت موقعة فقط بطبقة تشفير. يرى المستقبل تشفيراً حقيقياً في النسخة التي وصلته، لكنه لا يثبت أن المؤلف الأصلي أنشأه.

عندما يختلف القصد عن الغلاف، لا يثبت غياب HP-Outer أن المؤلف أخفى كل الحقول. يجب حفظ شجرة MIME وترتيب الطبقات وhp وسجلات HP-Outer والرأس الخارجي الفعلي وقرار المحلل كل على حدة. السجل المختصر encrypted=true يمحو السبب.

ما يُعرض ليس بالضرورة ما يتحكم في الرد

قد يصادق نظام النقل From الخارجي، بينما يحمي التوقيع من طرف إلى طرف From الداخلي. يعرّف RFC عدم التطابق حين يختلف جزء addr-spec بينهما.

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

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

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

لا تناقض هنا. العرض يدافع ضد انتحال المؤلف، والرد يدافع ضد اختطاف الوجهة. اسم العرض البشري طبقة ثالثة؛ فهو ليس فريداً عالمياً كعنوان البريد ولا يرتبط تلقائياً بالشهادة.

السرية تعتمد على المراقب

الحقل الموجود داخلاً وخارجاً ليس سرياً عن وكلاء النقل. وإذا حُذف من الخارج، فإنه يظهر لكل مستلم مقصود يستطيع فك التشفير. قد تكشف معرفات المفاتيح وغلاف SMTP وحقول Received والتوقيت علاقات مهمة.

يمكن للمؤلف نفسه أن يرسل إلى المستقبل معلومات لم يقصدها: إصدار البرنامج في User-Agent، أو اسم الجهاز في Message-ID، أو Bcc في نسخة غير مناسبة. يحمي التشفير تسليم هذا الخطأ ولا يصححه.

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

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

المصادر

1. RFC 9788 — Header Protection for Cryptographically Protected Email
2. RFC 9787 — Guidance on End-to-End Email Security
3. RFC 8551 — S/MIME 4.0 Message Specification
4. RFC 5322 — Internet Message Format
5. RFC 3156 — MIME Security with OpenPGP
6. RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance
7. IANA — Mail Header Confidentiality Policies
8. IANA — Message Headers
9. Heng Lu — أولوية الشفرة العاملة
10. Heng Lu — الحد الأدنى للمواصفة الأولية والقرار المستقبلي المحلي
11. Heng Lu — طبقات الواقع والقوة الرمزية