الخلاصة

  • لم يستبدل RFC 3268 آلية تفاوض TLS؛ بل أضاف اثني عشر معرّفاً لمجموعات AES إلى القائمة القائمة: ستة أنماط لتبادل المفاتيح والمصادقة، ولكل منها طولان للمفتاح.
  • لا يثبت AES-256 هوية الطرف المقابل ولا يوفر السرية الأمامية بذاته؛ فذلك يتوقف على أسلوب المصافحة وتنفيذه.

احتاج AES إلى اسم يفهمه الطرفان

لم يكن اعتماد AES معياراً كافياً كي يتفاوض عميل وخادم TLS على استخدامه. كان لا بد من تسمية مشتركة لمجموعة الإعدادات كاملة. ووفّر TLS 1.0 هذه الآلية بالفعل: يرسل العميل قائمة مجموعات في ClientHello، ويختار الخادم واحدة يدعمها. عرّف RFC 2246 المجموعة بوصفها مزيجاً من تبادل المفاتيح وتشفير البيانات وخوارزمية مصادقة الرسائل.

استفاد RFC 3268، المنشور في يونيو 2002، من ذلك الإطار. أضاف AES في نمط CBC مع HMAC-SHA-1، لا خياراً منفرداً اسمه «AES». فقد وضع ستة أنواع للمصافحة: RSA، وDH ثابتاً بشهادة DSS أو RSA، وDHE مؤقتاً بتوقيع DSS أو RSA، وDH مجهولاً. ولكل نوع مفتاح AES بطول 128 أو 256 بت؛ أي اثنتا عشرة مجموعة.

لم يجعل التشفير هذه الأساليب متكافئة. فـRSA وDH الموثق وDH المجهول تختلف في أساس الثقة. يمكن لـDHE توفير السرية الأمامية إذا استُخدمت مفاتيح مؤقتة جديدة، وأُتلفت بأمان، واستندت إلى مولد عشوائي سليم. أما DH المجهول فلا يصادق على الطرف الآخر ويظل عرضة لهجوم الوسيط، ما لم تربط وسيلة أخرى الطرفين برسالة Finished نفسها في TLS. لا يجيب طول مفتاح AES عن أي من ذلك.

يدعم AES أطوال مفاتيح 128 و192 و256 بت؛ لكن RFC 3268 حدد 128 و256 فقط كي لا تتكاثر أسماء المجموعات. واستخدمت جميعها كتل AES بطول 128 بت؛ فالمفتاح الأطول لا يوسّع الكتلة. كما اشتركت في CBC وSHA-1 داخل HMAC. لذلك لم تكن كلمة «AES» تصف سوى جزء من الحزمة.

ثمن التوافق كان توسيع القائمة

أشار RFC إلى أن مجموعات DHE المتاحة آنذاك اعتمدت أساساً على Triple-DES، إلى جانب خيارات تصدير بمفاتيح غير مرضية. أمكن إدخال AES مع إبقاء ClientHello وآلية TLS 1.0، لكن كل تركيبة جديدة احتاجت اسماً ورقماً وسياسة وتنفيذاً.

لا يثبت التسجيل في سجل IANA أن المنتجات دعمت المجموعة أو فضّلتها أو تفاوضت عليها. وتوضح التصاميم اللاحقة تغير الحدود: كثير من مجموعات TLS 1.2 ما زال يجمع مكونات عدة، بينما يحدد TLS 1.3 في المجموعة خوارزمية AEAD ووسم التجزئة، ويفاوض مجموعات تبادل المفاتيح وخوارزميات التوقيع بصورة منفصلة. لذلك يسجل RFC 3268 أيضاً تطور موضع القرار في TLS.

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

المصادر