ما هو TLS؟ شرح المصافحة وTLS 1.3 والشهادات

TLS وSSL: مهمة واحدة واسمان

يعمل TLS (Transport Layer Security) بين TCP وHTTP، ويحوّل الاتصال المكشوف إلى اتصال خاص. حين يبدأ العنوان بـ https:// فإن TLS هو ما يجعله آمنًا، والبروتوكول نفسه يحمي البريد الإلكتروني وDNS over TLS ومعظم واجهات API.

أما SSL (Secure Sockets Layer) فهو نقطة البداية. أطلقت Netscape الإصدار SSL 2.0 عام 1995 ثم SSL 3.0 عام 1996. وحين تولّت IETF البروتوكول غيّرت اسمه: فـ TLS 1.0 (1999) هو في جوهره SSL 3.1. ثم جاء TLS 1.1 (2006) وTLS 1.2 (2008) وTLS 1.3 (2018).

كل إصدارات SSL محظورة اليوم. سقط SSL 3.0 أمام هجوم POODLE عام 2014 وحُظر رسميًا عام 2015، وأُعلن TLS 1.0 و1.1 متقادمين عام 2021 بعد أن كانت المتصفحات قد تخلّت عنهما. ما يُستخدم اليوم هو TLS 1.2 وTLS 1.3.

لكن الاسم القديم ما زال حيًّا في الاستخدام اليومي. حين يُقال "شهادة SSL" فالمقصود هو الشهادة التي يقدّمها خادم TLS؛ ولا توجد شهادة SSL منفصلة عن شهادة TLS، بل هو ملف X.509 نفسه، يعمل مع أي إصدار من البروتوكول يتفق عليه الطرفان. وإن كنت تبحث عن الشهادة نفسها فابدأ بدليل شهادات SSL المجانية.

ما الذي يضمنه TLS وما الذي لا يضمنه

يمنح TLS الاتصالَ ثلاث خصائص.

السرية. كل ما يأتي بعد المصافحة يُشفَّر بمفاتيح لا يعرفها إلا الطرفان. من يجلس على شبكة Wi-Fi نفسها، أو لدى مزوّد الإنترنت، أو على أي وصلة عبور، لا يرى إلا بايتات مشفّرة.

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

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

ومن المفيد بالقدر نفسه أن تعرف ما لا يفعله TLS. فهو لا يُخفي أي خادم تتحدث إليه: عناوين IP ظاهرة، وكذلك اسم النطاق في SNI (نعود إليه أدناه). ولا يجعل المحتوى آمنًا: حقن SQL يصل مشفّرًا تمامًا مثل نموذج تسجيل الدخول، وإيقافه مهمة جدار حماية تطبيقات الويب WAF. كما أنه يحمي البيانات أثناء النقل فقط؛ فبمجرد أن يفك الخادم تشفيرها ينتهي دور TLS.

مصافحة TLS 1.2: رحلتا ذهاب وإياب

قبل أن يُرسَل بايت واحد من HTTP، على المتصفح والخادم أن يتفقا على إصدار وخوارزمية تشفير، وأن يتحققا من الشهادة، وأن يشتقّا مفاتيح مشتركة. هذا التفاوض هو مصافحة TLS (TLS handshake)، ويستغرق في TLS 1.2 رحلتَي ذهاب وإياب كاملتين فوق اتصال TCP.

الرحلة الأولى. يرسل المتصفح ClientHello: الإصدارات ومجموعات التشفير التي يدعمها، وقيمة عشوائية، وامتدادات مثل SNI وALPN (أي إصدار من HTTP يريد). ويردّ الخادم بـ ServerHello (الإصدار والتشفير المختاران) وسلسلة شهاداته، ومع مجموعات ECDHE حصّته من تبادل المفاتيح موقّعةً بمفتاح الشهادة.

الرحلة الثانية. يتحقق المتصفح من الشهادة، ويرسل حصّته من المفتاح، فيحسب الطرفان مفاتيح الجلسة نفسها. ثم يرسل كلٌّ منهما Finished، وهو بصمة لكل ما تبادلاه حتى تلك اللحظة؛ فإن عبث أحد بالمصافحة فشلت هنا تحديدًا.

الآن فقط يمكن أن يخرج الطلب الأول. وإذا احتسبنا مصافحة TCP أيضًا، فإن كل اتصال HTTPS جديد عبر TLS 1.2 يستهلك ثلاث رحلات ذهاب وإياب قبل أن يتمكن المتصفح من طلب الصفحة أصلًا. عند 20 ميلي ثانية للرحلة لا يلاحظ أحد ذلك، أما على اتصال جوّال بزمن 150 ميلي ثانية بين الزائر والخادم فيقترب الأمر من نصف ثانية. وهذا أحد أسباب إنهاء شبكات CDN لاتصال TLS عند الـ edge بدل الخادم الأصلي (origin) البعيد: تصبح رحلات المصافحة قصيرة.

TLS 1.3: رحلة واحدة وأخطاء أقل

يقوم TLS 1.3 (RFC 8446، عام 2018) على ملاحظة واحدة: المتصفح يستطيع التخمين. فكل الخوادم تقريبًا تدعم المجموعات القليلة نفسها لتبادل المفاتيح، لذا يرسل المتصفح حصّته من المفتاح داخل ClientHello مباشرةً بدل أن ينتظر حتى يُسأل.

يختار الخادم خوارزمية التشفير ويردّ بحصّته، ومنذ تلك اللحظة يملك الطرفان المفاتيح. كل ما يلي ServerHello، بما في ذلك الشهادة، يكون مشفّرًا أصلًا. يتحقق المتصفح من الشهادة، ويرسل Finished، ويضع طلبه الأول خلفها مباشرةً: رحلة واحدة لـ TLS، ورحلتان إجمالًا مع TCP. وفي HTTP/3، حيث يحمل QUIC بروتوكول TLS 1.3 داخل مصافحته الخاصة، يكتمل النقل والتشفير معًا في رحلة واحدة.

وإن أخطأ التخمين، أي أراد الخادم مجموعة لم يرسل المتصفح حصّة لها، فإنه يردّ بـ HelloRetryRequest وتكلّف المصافحة رحلة إضافية. ولأن كل المتصفحات تقريبًا تعرض X25519، فهذا نادر.

النصف الآخر من TLS 1.3 هو ما حذفه.

لا مزيد من تبادل المفاتيح عبر RSA. كل مصافحة تستخدم (EC)DHE مؤقتًا، فيتمتع كل اتصال بـ السرية الأمامية: مفتاح خاص يُسرق العام المقبل لا يستطيع فك حركة مرور سُجّلت اليوم.

لم يبقَ إلا تشفير AEAD: ‏AES-GCM وChaCha20-Poly1305. أما نمط CBC وRC4 و3DES وSHA-1 وMD5 فليست جزءًا من البروتوكول أصلًا.

أُلغيت إعادة التفاوض والضغط، ومعهما عائلات كاملة من الهجمات.

ويحمل TLS 1.3 كذلك حماية من خفض الإصدار: الخادم الذي يدعم TLS 1.3 ويُدفع إلى إصدار أقدم يضع علامة في ردّه، والعميل الذي يدعم TLS 1.3 يقطع الاتصال حين يرى العلامة. فإذا كان الطرفان يتحدثان 1.3 استخدماه، ولا يوجد إعداد "فضّل 1.3" يجب تذكّره.

0-RTT واستئناف الجلسة: الطريق المختصر وثمنه

الزائر الذي اتصل من قبل لا يحتاج إلى المصافحة الكاملة. ففي نهاية مصافحة TLS 1.3 يستطيع الخادم أن يعطي المتصفح تذكرة جلسة (session ticket)؛ وفي المرة التالية يقدّمها المتصفح، فيتخطى الطرفان الشهادة واتفاق المفاتيح المكلف. هذا هو استئناف الجلسة، وهو ما زال يستغرق رحلة ذهاب وإياب واحدة.

ويذهب 0-RTT (البيانات المبكرة early data) خطوة أبعد. فبالتذكرة يشفّر المتصفح طلبه الأول بمفاتيح الجلسة السابقة ويرسله في الحزمة نفسها مع ClientHello. يستطيع الخادم الرد فورًا، فلا ينتظر الطلب أي مصافحة.

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

ومن هنا تأتي القواعد. اقبل 0-RTT للطلبات المتساوية القوة (idempotent) فقط، أي GET وHEAD بلا آثار جانبية. واجعل الخادم أو الوكيل يعلّم طلبات البيانات المبكرة بالترويسة Early-Data: 1 والحالة 425 Too Early من RFC 8470، حتى يستطيع التطبيق رفض تنفيذها. ولا تتعامل مع 0-RTT كتسريع مجاني تفعّله في كل مكان.

لا يقبل الـ edge في CDN.com.tr بيانات 0-RTT المبكرة، فلا تصل مسألة إعادة الإرسال إلى تطبيقك أصلًا. والزائر العائد يستأنف جلسته بمصافحة TLS من رحلة واحدة.

الشهادات وسلسلة الثقة

الشهادة هي وسيلة الخادم لإثبات هويته. فهي تربط مفتاحًا عامًا باسم نطاق واحد أو أكثر، مدرجة في حقل Subject Alternative Name، وتحمل مدة صلاحية، وتوقّعها جهة إصدار شهادات (CA).

المتصفحات لا تثق بشهادتك مباشرةً. إنها تثق ببضع عشرات من الشهادات الجذرية في مخزن الثقة لديها، والجذور لا توقّع شهادات المواقع بنفسها: إنها توقّع شهادات وسيطة، والشهادة الوسيطة هي التي توقّع شهادتك. على المتصفح أن يبني مسارًا من شهادتك حتى جذر يعرفه: الشهادة الطرفية (شهادتك لـ www.example.com) ← الوسيطة (شهادة الإصدار لدى الجهة) ← الجذر (في مخزن الثقة).

يُتوقَّع من الخادم أن يرسل الشهادة الطرفية والشهادات الوسيطة. ونسيان الوسيطة هو العطل الكلاسيكي: كثيرًا ما تعمل متصفحات سطح المكتب رغم ذلك لأنها خزّنت الشهادة الناقصة أو تستطيع جلبها، بينما تفشل أدوات مثل curl وتطبيقات Android واستدعاءات الدفع (callbacks) وعملاء API برسالة "unable to get local issuer certificate". فإذا عمل شيء في متصفحك ولم يعمل من خادم، فافحص السلسلة أولًا.

مثال حقيقي: في 7 أكتوبر 2026 كان cdn.com.tr يقدّم شهادة من Let's Encrypt وقّعتها الشهادة الوسيطة YR1، وتتصل السلسلة بـ ISRG Root YR، وكان الخادم يرسل أيضًا نسخة من Root YR موقّعة توقيعًا متقاطعًا من ISRG Root X1، وهو الجذر الذي تثق به المتصفحات منذ سنوات. هذا التوقيع المتقاطع هو ما يسمح لجذر جديد تمامًا بالعمل على أجهزة لم تسمع به قط.

مدة الصلاحية. تدوم شهادات Let's Encrypt تسعين يومًا، والقطاع كله يسير في الاتجاه نفسه: بموجب قواعد CA/Browser Forum المعتمدة عام 2025 انخفض العمر الأقصى للشهادة العامة إلى 200 يوم في مارس 2026، وسيصبح 47 يومًا بحلول 2029. لم يعد التجديد مهمة سنوية، بل عملية يجب أن تعمل وحدها.

DV وOV وEV. يحدد مستوى التحقق ما الذي فحصته الجهة (السيطرة على النطاق فقط، أم المؤسسة أيضًا)، لا قوة التشفير. شهادة مجانية متحقَّق منها على مستوى النطاق وشهادة EV باهظة الثمن تُنتجان اتصال TLS نفسه تمامًا.

SNI: مواقع HTTPS كثيرة على عنوان IP واحد

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

يحلّ SNI (Server Name Indication) هذه المشكلة بوضع اسم النطاق داخل ClientHello. يقرؤه الخادم قبل اختيار الشهادة، وهكذا يستطيع عنوان واحد استضافة آلاف مواقع HTTPS لكل منها شهادته. تعتمد عليه كل شبكات CDN وكل الاستضافات المشتركة، ويرسله كل متصفح صدر في العقد الأخير.

ولذلك نتيجتان تستحقان المعرفة.

العميل الذي لا يرسل SNI يتلقى الشهادة الافتراضية. العملاء القدامى جدًا، وبعض الأجهزة المدمجة، والسكربتات التي تتصل بعنوان IP دون تحديد اسم الخادم، تتلقى الشهادة الاحتياطية للخادم ثم تفشل بسبب عدم تطابق الاسم. وعند الاختبار بـ openssl مرّر دائمًا الخيار -servername.

SNI غير مشفّر. يسافر اسم النطاق نصًا مكشوفًا داخل ClientHello، فتستطيع الشبكة أن ترى أي موقع تفتحه، وأن تحجبه بناءً على ذلك، حتى لو لم ترَ الصفحة نفسها. هكذا يعمل الحجب المعتمد على SNI. والامتداد الذي يُخفيه هو Encrypted Client Hello (ECH)، وقد بدأت المتصفحات بدعمه؛ وإلى أن ينتشر في كل مكان، افترض أن اسم النطاق ظاهر.

مجموعات التشفير: كيف تُقرأ أسماؤها

مجموعة التشفير (cipher suite) تسمّي الخوارزميات التي يستخدمها الاتصال. يحشر TLS 1.2 أربعة اختيارات في اسم واحد.

ECDHE-RSA-AES128-GCM-SHA256 يعني: تبادل المفاتيح عبر ECDHE (ديفي-هيلمان المؤقت على المنحنيات الإهليلجية، وهو ما يمنح السرية الأمامية)، والمصادقة عبر RSA (نوع مفتاح الشهادة)، وتشفير البيانات بـ AES-128 بنمط GCM (تشفير AEAD: السرية والسلامة في خطوة واحدة)، وSHA-256 لاشتقاق المفاتيح.

أسماء TLS 1.3 أقصر، لأن تبادل المفاتيح والتوقيع يُتفاوض عليهما منفصلين، ولا توجد إلا خمس مجموعات يُستخدم ثلاث منها فعليًا: TLS_AES_128_GCM_SHA256 وTLS_AES_256_GCM_SHA384 وTLS_CHACHA20_POLY1305_SHA256. كلها من نوع AEAD وكلها توفر السرية الأمامية، فلا يبقى شيء لضبطه.

القائمة الجيدة في TLS 1.2 تضع تبادل ECDHE وتشفير AEAD في أعلاها، ولا تحتوي شيئًا فيه RC4 أو 3DES أو MD5 أو NULL أو EXPORT، والخادم هو من يختار وفق ترتيبه الخاص لا ترتيب العميل. كثيرًا ما تُترك مجموعات CBC القديمة في آخر القائمة للعملاء القدامى جدًا، وحين يختار الخادم لا يصل إليها متصفح حديث أبدًا. أداة الفحص تعدّد كل ما يعرضه الخادم؛ ولمعرفة ما يستخدمه اتصال حقيقي، انظر إلى المجموعة المتفاوض عليها بالأوامر الواردة في آخر هذا الدليل.

ووُجدت ChaCha20-Poly1305 للأجهزة التي لا تملك تسريعًا عتاديًا لـ AES، وأغلبها هواتف قديمة، إذ تعمل فيها برمجيًا أسرع من AES-GCM.

أخطاء TLS الشائعة وما تعنيه فعلًا

ERR_SSL_PROTOCOL_ERROR (Chrome): انقطعت المصافحة بطريقة لم يستطع المتصفح تصنيفها. الأسباب المعتادة: شيء غير TLS يجيب على المنفذ 443 (HTTP مكشوف، أو صفحة دخول شبكة عامة)، أو برنامج مكافحة فيروسات أو جهاز شبكي يعترض الاتصال، أو خادم لا يملك شهادة لهذا النطاق. جرّب أولًا من شبكة أخرى؛ فإن ظهر الخطأ على شبكة واحدة فقط فالمشكلة ليست في الخادم.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH، وفي Firefox ‏SSL_ERROR_NO_CYPHER_OVERLAP: لا يتشارك العميل والخادم أي إصدار أو مجموعة تشفير. ويعني ذلك اليوم في الغالب أن أحد الطرفين قديم جدًا، كجهاز مدمج لا يتحدث إلا TLS 1.0 أو خادم ما زال مضبوطًا عليه.

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

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

unable to get local issuer certificate (curl وOpenSSL وكثير من حِزم SDK): لم يرسل الخادم شهادته الوسيطة. أصلح السلسلة على الخادم، لا مخزن الثقة لدى العميل.

خطأ 502 من وكيل أو CDN بينما يُظهر المتصفح قفلًا صالحًا: كان TLS لدى الزائر سليمًا، لكن اتصال الوكيل نفسه بخادمك الأصلي فشل. إنها مصافحة منفصلة لها شهادتها وإصداراتها؛ ويشرحها دليل خطأ 502 Bad Gateway خطوة بخطوة.

كيف ينهي CDN.com.tr اتصال TLS عند الـ edge

حين يكون موقعك خلف CDN.com.tr، ينتهي اتصال TLS الخاص بالزائر عند خادم edge تابع لـ CDN.com.tr لا عند خادمك الأصلي: الـ edge يحمل شهادتك ويُجري المصافحة. ويفعل ذلك لكل اسم نطاق، دون إعداد لكل موقع قد يُنسى.

TLS 1.2 وTLS 1.3 فقط. يُرفض TLS 1.0 و1.1 عند المصافحة، ولا يُخفَّض إليهما. يختار الـ edge خوارزمية التشفير من قائمته الخاصة، وفي مقدمتها تبادل ECDHE وتشفير AEAD؛ وفي اختبارنا بتاريخ 7 أكتوبر 2026 تفاوض TLS 1.3 على TLS_AES_256_GCM_SHA384 فوق X25519. السياسة واحدة لكل الحسابات، وتجد التفاصيل التي تطلبها استبيانات الأمان في صفحة سياسة TLS.

HTTP/3 لكل موقع. يعمل HTTP/3 فوق QUIC الذي يتضمن TLS 1.3. تكتشفه المتصفحات من ترويسة Alt-Svc وتنتقل إليه في الاتصال التالي، ولا شيء يحتاج إلى تفعيل. المزيد في HTTP/3 وIPv6.

شهادة لكل اسم نطاق، تُختار عبر SNI. يُخدَم كل نطاق من نطاقاتك بشهادته الخاصة.

Let's Encrypt، تُصدَر وتُجدَّد نيابةً عنك. مع SSL التلقائي تُطلب الشهادة بمجرد التحقق من نطاقك وتوجيه DNS الخاص به إلينا، وتُجدَّد تلقائيًا قبل انتهاء صلاحيتها بثلاثين يومًا. وإن كان DNS نطاقك لدى CDN.com.tr، فيمكن أن تكون الشهادة من نوع wildcard تغطي النطاق الجذري وكل النطاقات الفرعية من المستوى الأول، ويُتحقَّق منها بسجل DNS. هل تنقل موقعًا يعمل حاليًا؟ يُصدر معالج الإصدار دون انقطاع تلك الشهادة عبر سجل TXT لدى مزوّد DNS الحالي قبل التبديل، فيعمل HTTPS من الثانية الأولى.

شهادتك الخاصة عند الحاجة. يمكن رفع شهادة OV أو EV وربطها باسم نطاق بعد شرائها من جهة أخرى، وتحصل على سياسة TLS نفسها تمامًا.

اتصال TLS منفصل إلى خادمك الأصلي. افتراضيًا يُجلب طلب HTTPS من خادمك الأصلي عبر HTTPS أيضًا، من خلال اتصال الـ edge الخاص بمنفذ HTTPS لديك. لا يرى الزائر هذه المصافحة أبدًا؛ وإن فشلت فسيتلقى 502 لا تحذيرًا من الشهادة.

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

افحص TLS لأي موقع في دقيقة

خمسة أوامر تجيب عن معظم أسئلة TLS: أي إصدار وأي تشفير يستخدمه اتصال حقيقي، وأي سلسلة يرسلها الخادم، ومتى تنتهي صلاحية الشهادة، وهل تُرفض الإصدارات القديمة، وكم تستغرق المصافحة. استبدل www.example.com باسم نطاقك ولا تحذف -servername، فمن دونه تختبر شهادة الخادم الافتراضية لا شهادتك.

الإصدار والتشفير والسلسلة وتاريخ الانتهاء ومدة المصافحة من سطر الأوامر

# Negotiated version and cipher
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | grep -E "Protocol|Cipher is"

# The chain the server sends: subject (s:) and issuer (i:) of each certificate
openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/null 2>/dev/null | grep -E "^ *[0-9]+ s:|^ *i:"

# When the certificate expires
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate

# TLS 1.1 must be refused (SECLEVEL=0 stops your own OpenSSL from refusing first)
openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_1 -cipher 'DEFAULT:@SECLEVEL=0' </dev/null

# Seconds spent on TCP and on TCP + TLS
curl -so /dev/null -w 'tcp %{time_connect}  tls %{time_appconnect}\n' https://www.example.com/