أمن طبقة النقل

بروتوكول أمان طبقة نقل البيانات (DTLS) هو بروتوكول اتصالات يوفر الحماية لتطبيقات البيانات من خلال تمكينها من التواصل بطريقة مصممة ^{[ 8 ] [ 9 ]} لمنع التنصت أو التلاعب أو تزوير الرسائل . يعتمد بروتوكول DTLS على بروتوكول أمان طبقة النقل الموجه نحو التدفق (TLS)، ويهدف إلى توفير ضمانات أمنية مماثلة. مع ذلك، وعلى عكس TLS، يمكن استخدامه مع معظم بروتوكولات البيانات، بما في ذلك بروتوكول بيانات المستخدم (UDP)، وبروتوكول التحكم في ازدحام البيانات (DCCP)، وبروتوكول التحكم في نقاط الوصول اللاسلكية وتوفيرها (CAPWAP)، وبروتوكول التحكم في نقل التدفق (SCTP)، وبروتوكول النقل الآمن في الوقت الحقيقي (SRTP).

بما أن بروتوكول DTLS يحافظ على دلالات النقل الأساسي، فإن التطبيق لا يعاني من التأخيرات المرتبطة ببروتوكولات التدفق. مع ذلك، يتعين على التطبيق التعامل مع إعادة ترتيب الحزم ، وفقدان حزم البيانات ^، والبيانات الأكبر من حجم حزمة بيانات الشبكة . ولأن DTLS يستخدم UDP أو SCTP بدلاً من TCP، فإنه يتجنب مشكلة انهيار TCP [ ^{10 ] [ 11 ]} عند استخدامه لإنشاء نفق VPN.

لم يكن الإصدار الأصلي من بروتوكول DTLS الإصدار 1.0 لعام 2006 وثيقة مستقلة، بل كان عبارة عن سلسلة من التحديثات لبروتوكول TLS 1.1. ^{[ 8 ] : §4.} وبالمثل، يُعد إصدار DTLS اللاحق لعام 2012 تحديثًا لبروتوكول TLS 1.2، وقد أُعطي رقم الإصدار DTLS 1.2 ليتوافق مع إصدار TLS الخاص به. وأخيرًا، يُعد DTLS 1.3 لعام 2022 تحديثًا لبروتوكول TLS 1.3. وكما هو الحال في الإصدارين السابقين، يهدف DTLS 1.3 إلى توفير "ضمانات أمنية مكافئة [لبروتوكول TLS 1.3] باستثناء حماية الترتيب/عدم إمكانية إعادة الإرسال". ^{[ 12 ]}

تستخدم العديد من برامج عملاء الشبكات الافتراضية الخاصة (VPN) ، بما في ذلك Cisco AnyConnect ^{[ 13 ]} وInterCloud Fabric ^{[ 14 ]} و OpenConnect ^{[ 15 ]} و ZScaler tunnel ^{[ 16 ]} و F5 Networks Edge VPN Client ^{[ 17 ]} وCitrix Systems NetScaler ^{[ 18 ]} ، بروتوكول DTLS لتأمين حركة مرور UDP. بالإضافة إلى ذلك، تدعم جميع متصفحات الويب الحديثة بروتوكول DTLS-SRTP ^{[ 19 ]} لتقنية WebRTC .

للحماية من هجمات "الحصاد الآن، فك التشفير لاحقًا" التي قد تشنها الحواسيب الكمومية المستقبلية ، تم نشر أنظمة تبادل مفاتيح هجينة لما بعد الكموم لبروتوكول TLS 1.3. تجمع هذه الأنظمة بين تبادل ECDHE التقليدي وآلية ML-KEM ، وهي آلية تغليف مفاتيح قائمة على الشبكة، والتي اعتمدها المعهد الوطني للمعايير والتكنولوجيا (NIST) كمعيار FIPS 203 في أغسطس 2024. ^{[ 20 ]} وقد حدد فريق عمل بروتوكول TLS التابع لفرقة عمل هندسة الإنترنت (IETF ) المجموعات الهجينة X25519MLKEM768 وSecP256r1MLKEM768 وSecP384r1MLKEM1024 في مسودة إنترنت، ^{[ 21 ]} إلى جانب إطار عمل عام لتبادل المفاتيح الهجينة في بروتوكول TLS 1.3 ^{[ 22 ]} ومواصفات لاتفاقية مفاتيح ML-KEM المستقلة (غير الهجينة). ^{[ 23 ]}

تم تفعيل بروتوكول X25519MLKEM768 (وسلفه X25519Kyber768) افتراضيًا في متصفح جوجل كروم منذ الإصدار 131 (نوفمبر 2024) ^{[ 24 ]} وفي متصفح فايرفوكس منذ الإصدار 132، ^{[ 25 ]} وهو مدعوم من قبل تطبيقات جانب الخادم بما في ذلك OpenSSL 3.5، ^{[ 26 ]} و BoringSSL و Cloudflare . ^{[ 27 ]}

طوّرت شركة نتسكيب بروتوكولات SSL الأصلية، ويُلقّب طاهر الجمال ، كبير العلماء في نتسكيب كوميونيكيشنز من عام 1995 إلى 1998، بـ"أبو SSL". ^{[ 46 ] [ 47 ] [ 48 ] [ 49 ]} لم يُطرح الإصدار 1.0 من SSL للنشر العام بسبب ثغرات أمنية خطيرة في البروتوكول. أما الإصدار 2.0، الذي طُرح في فبراير 1995، فقد تبيّن سريعًا أنه يحتوي على عدد من الثغرات الأمنية وثغرات في سهولة الاستخدام. فقد استخدم نفس مفاتيح التشفير لمصادقة الرسائل وتشفيرها. كما تميّز ببنية MAC ضعيفة تستخدم دالة التجزئة MD5 مع بادئة سرية، مما جعله عرضةً لهجمات تمديد الطول. بالإضافة إلى ذلك، لم يُوفّر أي حماية لا لعملية المصافحة الافتتاحية ولا لعملية إغلاق الرسالة الصريحة، مما يعني إمكانية مرور هجمات الوسيط دون اكتشافها. علاوة على ذلك، افترضت تقنية SSL 2.0 وجود خدمة واحدة وشهادة نطاق ثابتة، وهو ما يتعارض مع ميزة الاستضافة الافتراضية المستخدمة على نطاق واسع في خوادم الويب، لذلك تم إعاقة معظم مواقع الويب بشكل فعال من استخدام SSL.

استدعت هذه العيوب إعادة تصميم البروتوكول بالكامل إلى الإصدار 3.0 من SSL. ^{[ 50 ] [ 48 ]} صدر هذا الإصدار عام 1996، وقد طوّره بول كوخر بالتعاون مع مهندسي نتسكيب، فيل كارلتون وآلان فراير، مع تطبيق مرجعي من كريستوفر ألين وتيم ديركس من شركة سيرتيكوم. وتستند الإصدارات الأحدث من SSL/TLS إلى الإصدار 3.0 من SSL. وقد نشرت فرقة عمل هندسة الإنترنت (IETF) مسودة الإصدار 3.0 لعام 1996 كوثيقة تاريخية في RFC 6101 . 

تم إيقاف دعم بروتوكول SSL 2.0 في عام 2011 بموجب RFC 6176. وفي عام 2014، تبين أن بروتوكول SSL 3.0 عرضة لهجوم POODLE الذي يؤثر على جميع خوارزميات التشفير الكتلية في SSL؛ كما أن RC4 ، وهي خوارزمية التشفير غير الكتلية الوحيدة المدعومة من SSL 3.0، قابلة للاختراق أيضاً عند استخدامها في SSL 3.0. ^{[ 51 ]} تم إيقاف دعم بروتوكول SSL 3.0 في يونيو 2015 بموجب RFC 7568 .  

تم تعريف بروتوكول TLS 1.0 لأول مرة في RFC 2246 في يناير 1999 كترقية لبروتوكول SSL الإصدار 3.0، وقد كتبه كريستوفر ألين وتيم ديركس من شركة سيرتيكوم. وكما ورد في RFC، "الاختلافات بين هذا البروتوكول وSSL 3.0 ليست جذرية، لكنها كافية لمنع التوافق بين TLS 1.0 وSSL 3.0". وكتب تيم ديركس لاحقًا أن هذه التغييرات، وإعادة تسمية البروتوكول من "SSL" إلى "TLS"، كانت بمثابة محاولة لحفظ ماء الوجه أمام مايكروسوفت، "حتى لا يبدو الأمر وكأن فريق هندسة الإنترنت (IETF) يُصادق على بروتوكول نتسكيب دون تدقيق". ^{[ 52 ]} 

اقترح مجلس PCI أن تنتقل المؤسسات من بروتوكول TLS 1.0 إلى TLS 1.1 أو أعلى قبل 30 يونيو 2018. ^{[ 53 ] [ 54 ]} في أكتوبر 2018، أعلنت كل من Apple و Google و Microsoft و Mozilla بشكل مشترك أنها ستتوقف عن دعم TLS 1.0 و1.1 في مارس 2020. ^{[ 31 ]} تم إيقاف دعم TLS 1.0 و1.1 رسميًا في RFC 8996 في مارس 2021. 

تم تعريف بروتوكول TLS 1.1 في RFC 4346 في أبريل 2006. ^{[ 55 ]} وهو تحديث لبروتوكول TLS الإصدار 1.0. تشمل الاختلافات الهامة في هذا الإصدار ما يلي: 

• حماية إضافية ضد هجمات ربط كتل التشفير (CBC).
  • تم استبدال متجه التهيئة الضمني (IV) بمتجه تهيئة صريح.
  • تغيير في معالجة أخطاء الحشو .
• دعم تسجيل المعلمات لدى هيئة الأرقام المخصصة للأرقام الدولية (IANA) . ^{[ 56 ]}

تم إيقاف دعم إصدارات TLS 1.0 و1.1 على نطاق واسع من قبل مواقع الويب حوالي عام 2020، ^{[ 57 ]} مما أدى إلى تعطيل الوصول إلى إصدارات Firefox الأقدم من 24 والمتصفحات المبنية على Chromium الأقدم من 29، ^{[ 58 ]} على الرغم من إمكانية تطبيق إصلاحات من جهات خارجية على Netscape Navigator والإصدارات الأقدم من Firefox لإضافة دعم TLS 1.2. ^{[ 59 ]}

تم تعريف بروتوكول TLS 1.2 في RFC 5246 في أغسطس 2008. ^{[ 34 ]} وهو مبني على مواصفات TLS 1.1 السابقة. تشمل الاختلافات الرئيسية ما يلي: 

• تم استبدال تركيبة MD5 و SHA-1 في دالة الأرقام العشوائية الزائفة (PRF) بـ SHA - 256 ، مع خيار استخدام دوال الأرقام العشوائية الزائفة المحددة بواسطة مجموعة التشفير .
• تم استبدال مزيج MD5 وSHA-1 في تجزئة الرسالة النهائية بخوارزمية SHA-256، مع إمكانية استخدام خوارزميات تجزئة خاصة بمجموعة التشفير. ومع ذلك، يجب ألا يقل حجم التجزئة في الرسالة النهائية عن 96 بت . ^{[ 34 ] : §7.4.9}
• تم استبدال تركيبة MD5 و SHA-1 في العنصر الموقع رقميًا بتجزئة واحدة يتم التفاوض عليها أثناء المصافحة ، والتي تكون افتراضيًا SHA-1.
• تحسين قدرة العميل والخادم على تحديد خوارزميات التجزئة والتوقيع التي يقبلونها.
• توسيع نطاق دعم تشفير المصادقة ، المستخدمة بشكل أساسي في وضع Galois/Counter (GCM) ووضع CCM لتشفير معيار التشفير المتقدم (AES).
• تمت إضافة تعريف امتدادات TLS ومجموعات تشفير AES. ^{[ 56 ]}

تم تحسين جميع إصدارات TLS بشكل أكبر في RFC 6176 في مارس 2011، مما أدى إلى إزالة توافقها مع الإصدارات السابقة من SSL بحيث لا تتفاوض جلسات TLS أبدًا على استخدام Secure Sockets Layer (SSL) الإصدار 2.0. 

اعتبارًا من يوليو 2026 لا يوجد تاريخ رسمي لإيقاف دعم بروتوكول TLS 1.2، مما يسمح باستخدامه مع البرامج القديمة. مع ذلك، فقد تم إيقاف استخدام طرق التجزئة MD5 وSHA1، بالإضافة إلى خوارزمية ديفي-هيلمان (DH) على حقل محدود وتبادل مفاتيح RSA. ( RFC 9155 ، 10015 ) 

تم تعريف بروتوكول TLS 1.3 في RFC 8446 في أغسطس 2018. ^{[ 7 ]} وتم تحديثه في RFC 9846 في يوليو 2016. وهو مبني على مواصفات TLS 1.2 السابقة. تشمل الاختلافات الرئيسية عن TLS 1.2 ما يلي: ^{[ 4 ]}  

• فصل خوارزميات الاتفاق والمصادقة الرئيسية عن مجموعات التشفير ^{[ 56 ] [ 7 ] : §11}
• إزالة الدعم للمنحنيات الإهليلجية المسماة الضعيفة والأقل استخدامًا
• إزالة دعم وظائف التشفير MD5 و SHA-224
• يتطلب التوقيعات الرقمية حتى عند استخدام تكوين سابق
• دمج HKDF ومقترح DH شبه المؤقت
• استبدال استئناف المباريات بـ PSK والتذاكر
• يدعم مصافحات زمن الاستجابة 1، ودعمًا أوليًا لزمن الاستجابة 0
• فرض السرية التامة للأمام ، عن طريق استخدام مفاتيح مؤقتة أثناء اتفاقية مفاتيح (EC)DH
• تم إسقاط دعم العديد من الميزات غير الآمنة أو القديمة، بما في ذلك الضغط ، وإعادة التفاوض، والتشفير غير المعتمد على AEAD ، والتشفير الفارغ ^، وتبادل المفاتيح ^{غير المعتمد} على PFS (ومن بينها تبادل مفاتيح RSA الثابت وتبادل مفاتيح DH الثابت )، ومجموعات DHE المخصصة ، والتفاوض على تنسيق نقطة EC، وبروتوكول تغيير مواصفات التشفير، ورسالة Hello بتوقيت UNIX، وحقل الطول AD المُدخل إلى تشفيرات AEAD
• حظر التفاوض على بروتوكول SSL أو RC4 لضمان التوافق مع الإصدارات السابقة
• دمج استخدام تجزئة الجلسة
• تم إيقاف استخدام رقم إصدار طبقة التسجيل وتثبيت الرقم لتحسين التوافق مع الإصدارات السابقة.
• نقل بعض تفاصيل الخوارزميات المتعلقة بالأمان من ملحق إلى المواصفات، وإحالة ClientKeyShare إلى ملحق.
• إضافة تشفير تدفق ChaCha20 مع رمز مصادقة الرسائل Poly1305
• إضافة خوارزميات التوقيع الرقمي Ed25519 و Ed448
• إضافة بروتوكولات تبادل المفاتيح x25519 و x448
• إضافة دعم لإرسال استجابات OCSP متعددة
• تشفير جميع رسائل المصافحة بعد رسالة ServerHello، بما في ذلك شهادة الخادم

قامت خدمة أمان الشبكة (NSS)، وهي مكتبة التشفير التي طورتها موزيلا ويستخدمها متصفحها فايرفوكس ، بتفعيل بروتوكول TLS 1.3 افتراضيًا في فبراير 2017. ^{[ 61 ]} ثم أُضيف دعم TLS 1.3 لاحقًا - ولكن نظرًا لمشاكل التوافق لدى عدد قليل من المستخدمين، لم يتم تفعيله تلقائيًا ^{[ 62 ]} - إلى فايرفوكس 52.0 ، الذي صدر في مارس 2017. وتم تفعيل TLS 1.3 افتراضيًا في مايو 2018 مع إصدار فايرفوكس 60.0 . ^{[ 63 ]}

قام متصفح جوجل كروم بتعيين بروتوكول TLS 1.3 كإصدار افتراضي لفترة وجيزة في عام 2017. ثم أزاله من كونه الإصدار الافتراضي، بسبب عدم توافقه مع أجهزة الوسيط مثل وكلاء الويب Blue Coat . ^{[ 64 ]}

تمثلت مشكلة الإصدار الجديد من بروتوكول TLS في جمود البروتوكول ؛ حيث جمدت أجهزة الوسيطة معيار إصدار البروتوكول. ونتيجة لذلك، يُحاكي الإصدار 1.3 بنية الإصدار 1.2. حدث هذا التغيير في مرحلة متأخرة جدًا من عملية التصميم، ولم يُكتشف إلا أثناء نشر المتصفح. ^{[ 65 ]} كما أدى اكتشاف هذه المشكلة إلى التخلي عن استراتيجية التفاوض على الإصدار السابقة، والتي كانت تعتمد على اختيار الإصدار الأكثر تطابقًا، نظرًا لمستويات الجمود غير العملية. ^{[ 66 ]} وقد صُممت آلية " تسهيل " نقطة التمديد، حيث يدّعي أحد المشاركين في البروتوكول دعمه لتمديدات غير موجودة لضمان التسامح مع التمديدات غير المعترف بها ولكنها موجودة بالفعل، وبالتالي مقاومة الجمود، في الأصل لبروتوكول TLS، ولكنها اعتُمدت لاحقًا في بروتوكولات أخرى. ^{[ 66 ]}

خلال هاكاثون IETF 100 الذي عُقد في سنغافورة عام 2017، عمل فريق TLS على تكييف تطبيقات مفتوحة المصدر لاستخدام بروتوكول TLS 1.3. ^{[ 67 ] [ 68 ]} تألف فريق TLS من أفراد من اليابان والمملكة المتحدة وموريشيوس عبر فريق cyberstorm.mu. ^{[ 68 ]} استمر هذا العمل في هاكاثون IETF 101 في لندن ، ^{[ 69 ]} وهاكاثون IETF 102 في مونتريال. ^{[ 70 ]}

أتاح برنامج wolfSSL استخدام بروتوكول TLS 1.3 بدءًا من الإصدار 3.11.1، الذي صدر في مايو 2017. ^{[ 71 ]} وباعتباره أول تطبيق تجاري لبروتوكول TLS 1.3، دعم wolfSSL 3.11.1 الإصدار 18، ويدعم الآن الإصدار 28، ^{[ 72 ]} وهو الإصدار النهائي، بالإضافة إلى العديد من الإصدارات الأقدم. وقد نُشرت سلسلة من المدونات حول فرق الأداء بين بروتوكولي TLS 1.2 و1.3. ^{[ 73 ]}

فيسبتمبر 2018أصدر مشروع OpenSSL الشهير الإصدار 1.1.1 من مكتبته، والذي كان دعم TLS 1.3 فيه "الميزة الجديدة الرئيسية". ^{[ 74 ]}

تمت إضافة دعم TLS 1.3 إلى Secure Channel (schannel) لإصدارات GA من Windows 11 و Windows Server 2022. ^{[ 75 ]}

يعتمد بروتوكول أمان طبقة النقل (TLS) عادةً على مجموعة من جهات إصدار الشهادات الموثوقة التابعة لجهات خارجية للتحقق من صحة الشهادات. وتستند هذه الثقة عادةً إلى قائمة من الشهادات الموزعة مع برامج وكيل المستخدم ، ^{[ 79 ]} ويمكن تعديلها من قِبل الطرف المعتمد.

بحسب شركة Netcraft ، المتخصصة في رصد شهادات TLS النشطة، كانت Symantec هي جهة إصدار الشهادات الرائدة في السوق منذ بداية استطلاعها (أو VeriSign قبل استحواذ Symantec على وحدة خدمات المصادقة التابعة لها). في عام 2015، استحوذت Symantec على ما يقارب ثلث إجمالي الشهادات و44% من الشهادات الصالحة المستخدمة من قبل مليون موقع إلكتروني من أكثر المواقع زيارةً، وفقًا لإحصاءات Netcraft. ^{[ 80 ]} في عام 2017، باعت Symantec قسم TLS/SSL التابع لها إلى DigiCert. ^{[ 81 ]} وفي تقرير مُحدّث، تبيّن أن IdenTrust و DigiCert و Sectigo هي جهات إصدار الشهادات الثلاث الأولى من حيث الحصة السوقية منذ مايو 2019. ^{[ 82 ]}

نتيجةً لاختيار شهادات X.509 ، تُصبح هيئات إصدار الشهادات وبنية المفاتيح العامة ضروريةً للتحقق من العلاقة بين الشهادة ومالكها، بالإضافة إلى إنشاء الشهادات وتوقيعها وإدارة صلاحيتها. ورغم أن هذا قد يكون أكثر ملاءمةً من التحقق من الهويات عبر شبكة ثقة ، إلا أن تسريبات المراقبة الجماعية عام 2013 كشفت على نطاق واسع أن هيئات إصدار الشهادات تُشكّل نقطة ضعف من الناحية الأمنية، مما يسمح بهجمات الوسيط (MITM) في حال تعاونت هيئة إصدار الشهادات (أو تم اختراقها). ^{[ 83 ] [ 84 ]}

في 11 أبريل 2025، وافق منتدى CA/Browser على اقتراح يقضي بتقليص مدة صلاحية جميع شهادات TLS العامة تدريجياً إلى 47 يوماً بحلول عام 2029. ^{[ 85 ]} وقد اقترحت شركة آبل هذا الاقتراح. ^{[ 86 ]}

قبل أن يتمكن العميل والخادم من بدء تبادل المعلومات المحمية بواسطة بروتوكول TLS، يجب عليهما تبادل أو الاتفاق بشكل آمن على مفتاح تشفير وخوارزمية تشفير لاستخدامها في تشفير البيانات (انظر قسم  التشفير ). من بين الطرق المستخدمة لتبادل/الاتفاق على المفاتيح: المفاتيح العامة والخاصة المولدة باستخدام RSA (يُشار إليها بـ TLS_RSA في بروتوكول مصافحة TLS)، و Diffie-Hellman (TLS_DH)، وDiffie-Hellman المؤقت (TLS_DHE)، وDiffie-Hellman ذو المنحنى الإهليلجي (TLS_ECDH)، وDiffie-Hellman ذو المنحنى الإهليلجي المؤقت (TLS_ECDHE)، و Diffie-Hellman المجهول (TLS_DH_anon)، ^{[ 34 ]} والمفتاح المشترك مسبقًا (TLS_PSK) ^{[ 87 ]} وكلمة المرور الآمنة عن بُعد (TLS_SRP). ^{[ 88 ]}

لا تُتيح طريقتَا تبادل المفاتيح TLS_DH_anon وTLS_ECDH_anon التحقق من هوية الخادم أو المستخدم، ولذا نادراً ما تُستخدمان لأنهما عُرضة لهجمات الوسيط . فقط TLS_DHE وTLS_ECDHE تُوفران سرية البيانات الأمامية .

تختلف شهادات المفاتيح العامة المستخدمة أثناء عملية التبادل/الاتفاق في حجم مفاتيح التشفير العامة/الخاصة المستخدمة، وبالتالي في قوة الأمان المُقدم. في يوليو 2013، أعلنت جوجل أنها ستتوقف عن استخدام المفاتيح العامة ذات 1024 بت، وستتحول بدلاً من ذلك إلى مفاتيح ذات 2048 بت لزيادة أمان تشفير TLS الذي توفره لمستخدميها، لأن قوة التشفير ترتبط ارتباطًا مباشرًا بحجم المفتاح . ^{[ 89 ] [ 90 ]}

ملحوظات

يُستخدم رمز مصادقة الرسائل ( MAC) لضمان سلامة البيانات. ويُستخدم HMAC في وضع CBC لتشفير الكتل. أما التشفير المُصادق عليه (AEAD)، مثل وضع GCM ووضع CCM، فيستخدم MAC مُدمجًا مع AEAD ولا يستخدم HMAC . ^{[ 7 ] : §8.4} يُستخدم PRF المُستند إلى HMAC ، أو HKDF، في مصافحة TLS.

يُستخدم بروتوكول TLS بشكل أساسي لتأمين حركة البيانات على شبكة الإنترنت العالمية بين موقع ويب ومتصفح ويب مُشفّر باستخدام بروتوكول HTTP. ويُشكّل هذا الاستخدام لبروتوكول TLS لتأمين حركة بيانات HTTP بروتوكول HTTPS . ^{[ 110 ]}

ملحوظات

اعتبارًا من مارس 2025 تدعم أحدث إصدارات جميع متصفحات الويب الرئيسية بروتوكولي TLS 1.2 و 1.3، وهما مُفعّلان افتراضيًا، باستثناء متصفح IE 11. أما بروتوكولا TLS 1.0 و 1.1 فهما مُعطّلان افتراضيًا في أحدث إصدارات جميع المتصفحات الرئيسية.

إن إجراءات التخفيف من حدة الهجمات المعروفة ليست كافية بعد:

• إجراءات الحماية من هجوم POODLE : تمنع بعض المتصفحات بالفعل الرجوع إلى بروتوكول SSL 3.0؛ ومع ذلك، يجب أن يدعم هذا الإجراء كل من العملاء والخوادم. ويتطلب ذلك تعطيل بروتوكول SSL 3.0 نفسه، أو تطبيق "تقسيم سجلات مكافحة POODLE"، أو رفض تشفيرات CBC في بروتوكول SSL 3.0.
  • جوجل كروم: مكتمل (تم تطبيق TLS_FALLBACK_SCSV منذ الإصدار 33، وتم تعطيل الرجوع إلى SSL 3.0 منذ الإصدار 39، وتم تعطيل SSL 3.0 نفسه بشكل افتراضي منذ الإصدار 40. وتم إسقاط دعم SSL 3.0 نفسه منذ الإصدار 44.)
  • موزيلا فايرفوكس: مكتمل (تم إسقاط دعم SSL 3.0 نفسه منذ الإصدار 39. تم تعطيل SSL 3.0 نفسه بشكل افتراضي وتم تعطيل الرجوع إلى SSL 3.0 منذ الإصدار 34 ، وتم تنفيذ TLS_FALLBACK_SCSV منذ الإصدار 35. في ESR، تم تعطيل SSL 3.0 نفسه بشكل افتراضي وتم تنفيذ TLS_FALLBACK_SCSV منذ ESR 31.3.0.)
  • إنترنت إكسبلورر: جزئي (فقط في الإصدار 11، تم تعطيل SSL 3.0 افتراضيًا منذ أبريل 2015. الإصدار 10 والإصدارات الأقدم لا تزال عرضة لثغرة POODLE.)
  • أوبرا : مكتمل (تم تطبيق TLS_FALLBACK_SCSV منذ الإصدار 20، وتم تطبيق "تقسيم سجلات مكافحة POODLE"، والذي يكون فعالاً فقط مع التنفيذ من جانب العميل، منذ الإصدار 25، وتم تعطيل SSL 3.0 نفسه بشكل افتراضي منذ الإصدار 27. وسيتم إسقاط دعم SSL 3.0 نفسه منذ الإصدار 31.)
  • سفاري: مكتمل (فقط على نظام التشغيل OS X 10.8 والإصدارات الأحدث ونظام iOS 8، يتم رفض تشفير CBC أثناء الرجوع إلى SSL 3.0، ولكن هذا يعني أنه سيستخدم RC4، وهو أمر غير مُوصى به أيضًا. تم إيقاف دعم SSL 3.0 نفسه على نظام التشغيل OS X 10.11 والإصدارات الأحدث ونظام iOS 9.)
• إجراءات التخفيف من هجمات RC4 :
  • قام جوجل كروم بتعطيل RC4 باستثناء استخدامه كخيار احتياطي منذ الإصدار 43. تم تعطيل RC4 منذ الإصدار 48 من كروم.
  • قام متصفح فايرفوكس بتعطيل RC4 باستثناء استخدامه كخيار احتياطي منذ الإصدار 36. أما فايرفوكس 44 فقد قام بتعطيل RC4 بشكل افتراضي.
  • قامت شركة أوبرا بتعطيل RC4 باستثناء استخدامه كخيار احتياطي منذ الإصدار 30. تم تعطيل RC4 منذ الإصدار 35 من أوبرا.
  • في نظامي التشغيل Windows 7 وWindows Server 2008 R2 و Windows 8 وWindows Server 2012، تم ضبط أولوية RC4 على أدنى مستوى، ويمكن تعطيل RC4 نهائيًا من خلال إعدادات التسجيل. أما في Internet Explorer 11 Mobile و Windows Phone 8.1، فقد تم تعطيل RC4 نهائيًا، باستثناء حالة فشل أي خوارزمية أخرى. وفي أغسطس 2016، تم تعطيل RC4 نهائيًا في كل من Edge (الإصدار القديم) وIE 11.
• إجراءات التخفيف من آثار هجوم FREAK :
  • لا يزال متصفح أندرويد المضمن في نظام أندرويد 4.0 والإصدارات الأقدم عرضة لهجوم FREAK.
  • لا يزال متصفح إنترنت إكسبلورر 11 موبايل عرضة لهجوم FREAK.
  • يحتوي كل من متصفح جوجل كروم، وإنترنت إكسبلورر (لأجهزة سطح المكتب)، وسفاري (لأجهزة سطح المكتب والهواتف المحمولة)، وأوبرا (للهواتف المحمولة) على إجراءات وقائية ضد برنامج FREAK.
  • لم تتأثر متصفحات Mozilla Firefox على جميع المنصات وGoogle Chrome على نظام Windows ببرنامج FREAK.

معظم مكتبات برمجة SSL وTLS هي برامج مجانية ومفتوحة المصدر .

• BoringSSL ، وهو نسخة معدلة من OpenSSL لمتصفح Chrome/Chromium ونظام Android بالإضافة إلى تطبيقات Google الأخرى.
• بوتان ، مكتبة تشفير مرخصة بموجب ترخيص BSD مكتوبة بلغة C++.
• مجموعة BSAFE Micro Edition: تطبيق متعدد المنصات لبروتوكول TLS مكتوب بلغة C باستخدام وحدة تشفير معتمدة من FIPS
• BSAFE SSL-J: مكتبة TLS توفر واجهة برمجة تطبيقات خاصة وواجهة برمجة تطبيقات JSSE ، باستخدام وحدة تشفير معتمدة من FIPS
• cryptlib : مكتبة تشفير محمولة مفتوحة المصدر (تتضمن تطبيق TLS/SSL)
• قد يستخدم مبرمجو دلفي مكتبة تسمى Indy والتي تستخدم OpenSSL أو بديلًا لذلك ICS التي تدعم TLS 1.3 الآن.
• GnuTLS : تطبيق مجاني ( مرخص بموجب رخصة LGPL )
• امتداد مقبس جافا الآمن (JSSE): واجهة برمجة تطبيقات جافا وتنفيذ الموفر (المسمى SunJSSE) ^{[ 114 ]}
• LibreSSL : نسخة معدلة من OpenSSL من مشروع OpenBSD.
• MatrixSSL : تطبيق مرخص بترخيص مزدوج
• Mbed TLS (المعروف سابقًا باسم PolarSSL): مكتبة صغيرة الحجم لتطبيق بروتوكول SSL للأجهزة المدمجة، مصممة لسهولة الاستخدام
• خدمات أمن الشبكات : مكتبة مفتوحة المصدر معتمدة وفقًا لمعيار FIPS 140
• OpenSSL : تطبيق مجاني (رخصة BSD مع بعض الإضافات)
• Rustls ، وهو تطبيق لبروتوكول TLS 1.3 مكتوب بلغة البرمجة Rust لضمان سلامة الذاكرة.
• Schannel : تطبيق لبروتوكولي SSL وTLS لنظام التشغيل Microsoft Windows كجزء من حزمته.
• النقل الآمن : تطبيق لبروتوكول SSL وTLS المستخدم في نظامي التشغيل OS X و iOS كجزء من حزم البرامج الخاصة بهما.
• wolfSSL (سابقًا CyaSSL): مكتبة SSL/TLS مضمنة مع تركيز قوي على السرعة والحجم.

أظهرت ورقة بحثية قُدّمت في مؤتمر ACM لعام 2012 حول أمن الحاسوب والاتصالات ^{[ 115 ]} أن العديد من التطبيقات استخدمت بعض مكتبات SSL هذه بشكل غير صحيح، مما أدى إلى ثغرات أمنية. ووفقًا للمؤلفين:

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

يمكن أيضًا حماية بروتوكول نقل البريد البسيط (SMTP) بواسطة بروتوكول أمان طبقة النقل (TLS). تستخدم هذه التطبيقات شهادات المفتاح العام للتحقق من هوية نقاط النهاية.

يمكن استخدام بروتوكول TLS أيضًا لإنشاء شبكة افتراضية خاصة (VPN) عبر نفق كامل لبنية الشبكة ، كما هو الحال مع OpenVPN و OpenConnect . وقد دمج العديد من الموردين الآن إمكانيات التشفير والمصادقة الخاصة ببروتوكول TLS مع نظام التخويل. كما شهدت تقنيات العميل تطورًا ملحوظًا منذ أواخر التسعينيات، حيث تم تطويرها خارج متصفحات الويب لدعم تطبيقات العميل/الخادم. وبالمقارنة مع تقنيات VPN التقليدية القائمة على بروتوكول IPsec ، يتميز بروتوكول TLS بمزايا جوهرية في اجتياز جدران الحماية و NAT ، مما يُسهّل إدارته لشبكات الوصول عن بُعد واسعة النطاق.

يُعدّ بروتوكول أمان طبقة النقل (TLS) أيضًا طريقةً قياسيةً لحماية إشارات تطبيقات بروتوكول بدء الجلسة (SIP). ويمكن استخدام TLS لتوفير المصادقة والتشفير لإشارات SIP المرتبطة بتقنية VoIP وغيرها من التطبيقات القائمة على SIP. ^{[ 116 ]}

ترد أدناه قائمة بالهجمات الهامة ضد بروتوكول TLS/SSL.

في فبراير 2015، أصدرت IETF وثيقة RFC إعلامية ^{[ 117 ]} تلخص مختلف الهجمات المعروفة ضد TLS/SSL.

السرية الأمامية هي خاصية من خصائص أنظمة التشفير تضمن عدم اختراق مفتاح الجلسة المُشتق من مجموعة من المفاتيح العامة والخاصة في حال اختراق أحد المفاتيح الخاصة لاحقًا. ^{[ 175 ]} بدون السرية الأمامية، إذا تم اختراق المفتاح الخاص للخادم، فلن تقتصر المخاطر على جميع جلسات TLS المُشفرة التي تستخدم شهادة الخادم فحسب، بل ستشمل أيضًا أي جلسات سابقة استخدمتها (بشرط أن تكون هذه الجلسات السابقة قد تم اعتراضها وتخزينها وقت الإرسال). ^{[ 176 ]} يمكن لتطبيق TLS توفير السرية الأمامية من خلال اشتراط استخدام تبادل مفاتيح ديفي-هيلمان المؤقت لإنشاء مفاتيح الجلسة، وتعتمد بعض تطبيقات TLS البارزة على ذلك حصريًا، مثل Gmail وخدمات HTTPS الأخرى من Google التي تستخدم OpenSSL . ^{[ 177 ]} مع ذلك، فإن العديد من العملاء والخوادم التي تدعم TLS (بما في ذلك المتصفحات وخوادم الويب) غير مُهيأة لتطبيق هذه القيود. ^{[ 178 ] [ 179 ]} عمليًا، ما لم تستخدم خدمة الويب تبادل مفاتيح ديفي-هيلمان لتطبيق السرية الأمامية، يمكن لطرف ثالث فك تشفير جميع بيانات الويب المشفرة من وإلى تلك الخدمة إذا حصل على المفتاح الرئيسي (الخاص) للخادم؛ على سبيل المثال، عن طريق أمر قضائي. ^{[ 180 ]}

حتى في حال تطبيق تبادل مفاتيح ديفي-هيلمان، قد تؤثر آليات إدارة الجلسات على جانب الخادم على سرية البيانات. يؤدي استخدام تذاكر جلسات TLS (امتداد لبروتوكول TLS) إلى حماية الجلسة باستخدام AES128-CBC-SHA256 بغض النظر عن أي معلمات TLS أخرى متفق عليها، بما في ذلك مجموعات تشفير سرية البيانات، كما أن مفاتيح تذاكر جلسات TLS طويلة الأمد تُفشل محاولة تطبيق سرية البيانات. ^{[ 181 ] [ 182 ] [ 183 ]} ​​ووجدت دراسة أجرتها جامعة ستانفورد عام 2014 أن 82.9% من خوادم TLS التي شملها الاستطلاع (من أصل 473,802 خادمًا) والتي تستخدم تبادل مفاتيح ديفي-هيلمان المؤقت (DHE) لدعم سرية البيانات، كانت تستخدم معلمات ديفي-هيلمان ضعيفة. قد تُضعف هذه الخيارات الضعيفة للمعلمات فعالية سرية البيانات التي تسعى الخوادم إلى توفيرها. ^{[ 184 ]}

منذ أواخر عام 2011، وفرت جوجل خاصية السرية الأمامية باستخدام بروتوكول TLS افتراضيًا لمستخدمي خدمة Gmail ، بالإضافة إلى خدمات أخرى مثل مستندات جوجل والبحث المشفر. ^{[ 185 ]} ومنذ نوفمبر 2013، وفر تويتر خاصية السرية الأمامية باستخدام بروتوكول TLS لمستخدمي خدمته. ^{[ 186 ]} اعتبارًا من أغسطس 2019 يتم تكوين حوالي 80% من مواقع الويب التي تدعم بروتوكول TLS لاستخدام مجموعات تشفير توفر سرية تامة لمعظم متصفحات الويب. ^{[ 111 ]}

اعتراض بروتوكول TLS (أو اعتراض بروتوكول HTTPS إذا طُبِّق تحديدًا على هذا البروتوكول) هو عملية اعتراض تدفق بيانات مُشفَّر بهدف فك تشفيره وقراءته وربما التلاعب به، ثم إعادة تشفيره وإرساله مرة أخرى. ويتم ذلك عبر " وكيل شفاف ": حيث يقوم برنامج الاعتراض بإنهاء اتصال TLS الوارد، وفحص نص HTTP الأصلي، ثم إنشاء اتصال TLS جديد بالوجهة. ^{[ 187 ]}

يستخدم مشغلو الشبكات اعتراض بروتوكول TLS/HTTPS كإجراء أمني لفحص الشبكات والحماية من اختراق المحتوى الضار، مثل فيروسات الحاسوب والبرامج الخبيثة الأخرى . ^{[ 187 ]} ولا يمكن اكتشاف هذا المحتوى لولا ذلك طالما أنه محمي بالتشفير، وهو ما يتزايد نتيجة الاستخدام الروتيني لبروتوكول HTTPS وغيره من البروتوكولات الآمنة.

من أبرز عيوب اعتراض بروتوكولات TLS/HTTPS أنها تُضيف مخاطر أمنية جديدة. ومن أهم هذه العيوب أنها تُتيح الوصول إلى بيانات الشبكة غير المُشفّرة، مما يُشجع المُهاجمين على استهداف هذه النقطة تحديدًا للوصول إلى محتوى آمن. كما يُتيح الاعتراض لمُشغل الشبكة، أو لمن يتمكن من الوصول إلى نظام الاعتراض، شنّ هجمات الوسيط ضد مُستخدمي الشبكة. وقد وجدت دراسة أُجريت عام 2017 أن "اعتراض بروتوكول HTTPS أصبح واسع الانتشار بشكلٍ مُثير للقلق، وأن منتجات الاعتراض، كفئة، تُؤثر سلبًا بشكلٍ كبير على أمن الاتصال". ^{[ 187 ]}

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

هذا هو التنسيق العام لجميع سجلات TLS.

تنسيق سجل TLS العام

إزاحة	ثمانية	0								1								2								3
ثمانية	قليل	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	نوع المحتوى								الإصدار القديم (الرئيسي/الثانوي)																الطول ↴
4	32	↪ الطول (تابع)
8	64	رسالة (رسائل) البروتوكول
12	96
⋮	⋮
⁠${\displaystyle 5+m}$⁠	⁠${\displaystyle 40+m*8}$⁠	رمز التحقق من الرسالة (اختياري)
⋮	⋮
⋮	⋮
⁠${\displaystyle 5+m+q}$⁠	⁠${\displaystyle 40+(m+q)*8}$⁠	الحشو (التشفير الكتلي فقط)

نوع المحتوى : 8 بت

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

أنواع المحتوى

عرافة	ديسمبر	يكتب
0x14	20	تغيير مواصفات التشفير
0x15	21	يُحذًِر
0x16	22	مصافحة
0x17	23	طلب
0x18	24	نبض القلب

الإصدار القديم : 16 بت

يُحدد هذا الحقل الإصدار الرئيسي والثانوي لبروتوكول TLS قبل الإصدار 1.3 للرسالة المُضمنة. بالنسبة لرسالة ClientHello ، لا يشترط أن يكون هذا هو أعلى إصدار يدعمه العميل. أما بالنسبة لبروتوكول TLS 1.3 والإصدارات الأحدث، فيجب ضبط هذا الحقل على 0x0303 ، ويجب على التطبيق إرسال الإصدارات المدعومة في كتلة إضافية لتمديد الرسالة.

الإصدارات

الإصدار الرئيسي	نسخة ثانوية	نوع الإصدار
3	0	SSL 3.0
3	1	TLS 1.0
3	2	TLS 1.1
3	3	TLS 1.2
3	4	TLS 1.3

الطول : 16 بت ؛ الطول < ²¹⁴

يبلغ طول رسالة (رسائل) البروتوكول ، وحقول MAC والحشو مجتمعة. يجب ألا يتجاوز الطول ²¹⁴ بايت (16 كيلوبايت).

رسالة (رسائل) البروتوكول : متغير

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

رمز مصادقة الرسالة  (MAC) : 16 أو 20 أو 32 بايت (اختياري)

رمز مصادقة الرسالة (MAC) محسوب على حقل رسالة (رسائل) البروتوكول ، مع تضمين بيانات مفتاح إضافية. يبلغ طوله 32 بايتًا لرمز HMAC المستند إلى SHA-256 ، و20 بايتًا لرمز HMAC المستند إلى SHA-1 ، و16 بايتًا لرمز HMAC المستند إلى MD5 . يُرجى ملاحظة أن هذا الحقل قد يكون مُشفّرًا أو غير مُضمّن بالكامل، وذلك حسب حالة الاتصال. يُشار إلى طول رمز MAC (بالبايت) بالحرف q .

الحشو : متغير (اختياري)

لا تتم إضافة الحشوة إلا عند الحاجة.

لا يمكن أن تكون هناك حقول MAC أو Padding في نهاية سجلات TLS قبل التفاوض على جميع خوارزميات التشفير والمعلمات والمصافحة ثم تأكيدها عن طريق إرسال سجل CipherStateChange (انظر أدناه) للإشارة إلى أن هذه المعلمات ستدخل حيز التنفيذ في جميع السجلات اللاحقة التي يرسلها نفس الطرف.

بروتوكول التطبيق

تنسيق سجل TLS للتطبيق

إزاحة	ثمانية	0								1								2								3
ثمانية	قليل	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	نوع المحتوى  (23)								الإصدار القديم (الرئيسي/الثانوي)																الطول ↴
4	32	↪ الطول (تابع)
8	64	بيانات التطبيق
12	96
⋮	⋮
⁠${\displaystyle 5+m}$⁠	⁠${\displaystyle 40+m*8}$⁠	رمز التحقق من الرسالة (اختياري)
⋮	⋮
⋮	⋮
⁠${\displaystyle 5+m+q}$⁠	⁠${\displaystyle 40+(m+q)*8}$⁠	الحشو (التشفير الكتلي فقط)

نوع المحتوى : 8 بتات ؛ == 23

يحدد هذا الحقل نوع بروتوكول التطبيق .

الطول : 16 بت ؛ الطول < ²¹⁴

يبلغ طول حقول بيانات التطبيق ، وعنوان MAC ، والحشو مجتمعة. يجب ألا يتجاوز الطول ²¹⁴ بايت (16 كيلوبايت).

بيانات التطبيق : متغير

بيانات التطبيق. يُشار إلى طول البيانات (بالبايت) بالحرف m .

رمز مصادقة الرسالة  (MAC) : 16 أو 20 أو 32 بايت (اختياري)

رمز مصادقة الرسالة ( MAC) محسوب بناءً على حقل بيانات التطبيق . يبلغ طوله 32 بايتًا لرمز HMAC المستند إلى SHA-256 ، و20 بايتًا لرمز HMAC المستند إلى SHA-1 ، و16 بايتًا لرمز HMAC المستند إلى MD5 . يُشار إلى طول رمز MAC (بالبايت) بالحرف q .

الحشو : متغير (اختياري)

يحتوي البايت الأخير على طول الحشو.

الإصدار المعتمد حاليًا من (D)TLS هو الإصدار 1.3، والذي تم تحديده في:

• RFC 8446 – " بروتوكول أمان طبقة النقل (TLS) الإصدار 1.3، " ^{[ 7 ]} المعيار المقترح. 
• RFC 9147 – " بروتوكول أمان طبقة نقل البيانات (DTLS) الإصدار 1.3، " ^{[ 12 ]} معيار مقترح. 

تحل المعايير الحالية محل هذه الإصدارات السابقة:

• RFC 5246 – " بروتوكول أمان طبقة النقل (TLS) الإصدار 1.2، " ^{[ 34 ]} قديم. 
• RFC 6347 – " أمان طبقة نقل البيانات الإصدار 1.2، " ^{[ 9 ]} قديم. 
• RFC 4346 – " بروتوكول أمان طبقة النقل (TLS) الإصدار 1.1، " ^{[ 55 ]} تاريخي. 
• RFC 2246 – " بروتوكول TLS الإصدار 1.0، " ^{[ 197 ]} تاريخي. 
• RFC 6101 – " بروتوكول طبقة المقابس الآمنة (SSL) الإصدار 3.0، " ^{[ 198 ]} تاريخي. 
• مسودة الإنترنت (1995) : "بروتوكول SSL"

قامت بعض طلبات التعليقات الأخرى بتوسيع نطاق بروتوكول أمان طبقة النقل (D)TLS.

تشمل الإضافات إلى بروتوكول (D)TLS 1.3 ما يلي:

• RFC 9367 – " مجموعات تشفير GOST لبروتوكول أمان طبقة النقل (TLS) الإصدار 1.3، " ^{[ 95 ]} معلوماتي. 

تشمل الإضافات إلى بروتوكول (D)TLS 1.2 ما يلي:

• RFC 5288 – " مجموعات تشفير AES Galois Counter Mode (GCM) لـ TLS، " ^{[ 96 ]} معيار مقترح. 
• RFC 5289 – " مجموعات تشفير المنحنى الإهليلجي TLS مع SHA-256/384 ووضع عداد AES Galois (GCM) " ، ^{[ 97 ]} معيار مقترح. 
• RFC 5746 – " امتداد إشارة إعادة التفاوض لأمن طبقة النقل (TLS) " ، ^{[ 119 ]} معيار مقترح. 
• RFC 5878 – " امتدادات ترخيص أمان طبقة النقل (TLS) " ، ^{[ 199 ]} تجريبي. 
• RFC 5932 – " مجموعات تشفير كاميليا لـ TLS، " ^{[ 101 ]} معيار مقترح. 
• RFC 6066 – " امتدادات أمان طبقة النقل (TLS): تعريفات الامتدادات، " ^{[ 196 ]} معيار مقترح. 
  يتضمن ذلك تحديد اسم الخادم وتثبيت بروتوكول OCSP .
• RFC 6091 – " استخدام مفاتيح OpenPGP لمصادقة أمان طبقة النقل (TLS) " ، ^{[ 200 ]} معلوماتي. 
• RFC 6176 – " حظر طبقة المقابس الآمنة (SSL) الإصدار 2.0، " ^{[ 28 ]} معيار مقترح. 
• RFC 6209 – " إضافة مجموعات تشفير ARIA إلى أمان طبقة النقل (TLS) " ، ^{[ 102 ]} معلوماتي. 
• RFC 6347 – " أمان طبقة نقل البيانات الإصدار 1.2، " ^{[ 9 ]} قديم. 
  أصبح التعريف الآن جزءًا من مواصفات DTLS 1.3.
• RFC 6367 – " إضافة مجموعات تشفير كاميليا إلى أمان طبقة النقل (TLS) " ، ^{[ 100 ]} معلوماتي. 
• RFC 6460 – " ملف تعريف المجموعة ب لأمن طبقة النقل (TLS) " ، ^{[ 201 ]} تاريخي. 
  أوقفت وكالة الأمن القومي دعم برنامج التشفير Suite B.
• RFC 6655 – " مجموعات تشفير AES-CCM لأمن طبقة النقل (TLS) " ، ^{[ 98 ]} معيار مقترح. 
• RFC 7027 – " منحنيات Brainpool لتشفير المنحنى الإهليلجي (ECC) لأمن طبقة النقل (TLS) " ، ^{[ 202 ]} معلوماتي. 
• RFC 7251 – " مجموعات تشفير AES-CCM Elliptic Curve Crygraphy (ECC) لـ TLS، " ^{[ 99 ]} معلوماتي. 
• RFC 7301 – " امتداد التفاوض لبروتوكول طبقة التطبيق لأمن طبقة النقل (TLS) " ، ^{[ 203 ]} معيار مقترح. 
• RFC 7366 – " التشفير ثم رمز التحقق من الرسالة لأمان طبقة النقل (TLS) وأمان طبقة نقل البيانات (DTLS) " ، ^{[ 147 ]} معيار مقترح. 
• RFC 7465 – " حظر مجموعات تشفير RC4، " ^{[ 109 ]} معيار مقترح. 
• RFC 7507 – " قيمة مجموعة تشفير الإشارة الاحتياطية لـ TLS (SCSV) لمنع هجمات خفض مستوى البروتوكول، " ^{[ 204 ]} قديم. 
• RFC 7568 – " إلغاء استخدام طبقة المقابس الآمنة الإصدار 3.0، " ^{[ 29 ]} معيار مقترح. 
• RFC 7627 – " تجزئة جلسة أمان طبقة النقل (TLS) وامتداد السر الرئيسي الموسع، " ^{[ 205 ]} معيار مقترح. 
• RFC 7685 – " امتداد حشو ClientHello لأمن طبقة النقل (TLS) " ، ^{[ 206 ]} معيار مقترح. 
• RFC 8422 – " مجموعات تشفير المنحنى الإهليلجي (ECC) لأمن طبقة النقل (TLS) الإصدارات 1.2 وما قبلها، " ^{[ 92 ]} معيار مقترح. 
• RFC 9189 – " مجموعات تشفير GOST لبروتوكول أمان طبقة النقل (TLS) الإصدار 1.2، " ^{[ 94 ]} معلوماتي. 

تشمل الإضافات إلى بروتوكول (D)TLS 1.1 ما يلي:

• RFC 4366 – " امتدادات أمان طبقة النقل (TLS) " ، ^{[ 207 ]} قديم. 
  يصف كلاً من مجموعة من الامتدادات المحددة وآلية الامتداد العامة.
• RFC 4492 – " مجموعات تشفير المنحنى الإهليلجي (ECC) لأمن طبقة النقل (TLS) " ، ^{[ 208 ]} قديم. 
• RFC 4680 – " رسالة مصافحة TLS للبيانات التكميلية، " ^{[ 209 ]} معيار مقترح. 
• RFC 4681 – " امتداد تعيين مستخدم TLS، " ^{[ 210 ]} معيار مقترح. 
• RFC 4785 – " مجموعات التشفير ذات المفتاح المشترك مسبقًا (PSK) مع تشفير NULL لأمان طبقة النقل (TLS) " ، ^{[ 211 ]} معيار مقترح. 
• RFC 5054 – " استخدام بروتوكول كلمة المرور عن بعد الآمنة (SRP) لمصادقة TLS، " ^{[ 212 ]} معلوماتي. 
  يحدد مجموعات التشفير TLS-SRP .
• RFC 5077 – " استئناف جلسة أمان طبقة النقل (TLS) بدون حالة جانب الخادم، " ^{[ 193 ]} قديم. 
• RFC 5081 – " استخدام مفاتيح OpenPGP لمصادقة أمان طبقة النقل (TLS) " ، ^{[ 213 ]} تجريبي. 
• RFC 5216 – " بروتوكول مصادقة EAP-TLS، " [ 214 ^{] معيار مقترح} . 

تشمل الإضافات إلى بروتوكول TLS 1.0 ما يلي:

• RFC 2595 – " استخدام TLS مع IMAP وPOP3 وACAP، " ^{[ 215 ]} معيار مقترح. 
  يحدد امتدادًا لخدمات IMAP و POP3 و ACAP التي تسمح للخادم والعميل باستخدام أمان طبقة النقل لتوفير اتصال خاص وموثق عبر الإنترنت.
• RFC 2712 – " إضافة مجموعات تشفير Kerberos إلى أمان طبقة النقل (TLS) " ، ^{[ 216 ]} معيار مقترح. 
  تظهر مجموعات التشفير ذات 40 بت المحددة في هذه المذكرة فقط لغرض توثيق حقيقة أن رموز مجموعات التشفير هذه قد تم تعيينها بالفعل.
• RFC 2817 – " الترقية إلى TLS ضمن HTTP/1.1، " ^{[ 2 ]} معيار مقترح. 
  يشرح هذا كيفية استخدام آلية الترقية في بروتوكول HTTP/1.1 لتفعيل بروتوكول أمان طبقة النقل (TLS) عبر اتصال TCP قائم. يسمح هذا لحركة مرور HTTP غير الآمنة والآمنة بمشاركة نفس المنفذ المعروف (في هذه الحالة، http: على المنفذ 80 بدلاً من https: على المنفذ 443).
• RFC 2818 – " HTTP Over TLS, " ^{[ 217 ]} قديم. 
  يميز حركة المرور الآمنة عن حركة المرور غير الآمنة باستخدام "منفذ خادم" مختلف.
• RFC 3207 – " امتداد خدمة SMTP لـ SMTP الآمن عبر أمان طبقة النقل، " ^{[ 218 ]} معيار مقترح. 
  يحدد امتدادًا لخدمة SMTP يسمح لخادم SMTP وعميله باستخدام أمان طبقة النقل لتوفير اتصال خاص وموثق عبر الإنترنت.
• RFC 3268 – " مجموعات تشفير معيار التشفير المتقدم (AES) لأمن طبقة النقل (TLS) " ، ^{[ 219 ]} قديم. 
  يضيف مجموعات تشفير معيار التشفير المتقدم (AES) إلى التشفيرات المتناظرة الموجودة مسبقًا.
• RFC 3546 – ​​" امتدادات أمان طبقة النقل (TLS) " ، ^{[ 220 ]} قديم. 
  يضيف آلية للتفاوض على امتدادات البروتوكول أثناء تهيئة الجلسة ويحدد بعض الامتدادات.
• RFC 3749 – " طرق ضغط بروتوكول أمان طبقة النقل، " ^{[ 221 ]} معيار مقترح. 
  يحدد إطار عمل أساليب الضغط وطريقة ضغط DEFLATE .
• RFC 3943 – " ضغط بروتوكول أمان طبقة النقل (TLS) باستخدام Lempel-Ziv-Stac (LZS) " ، ^{[ 222 ]} معلوماتي. 
• RFC 4132 – " إضافة مجموعات تشفير كاميليا إلى أمان طبقة النقل (TLS) " ، ^{[ 223 ]} قديم. 
• RFC 4162 – " إضافة مجموعات تشفير SEED إلى أمان طبقة النقل (TLS) " ، ^{[ 103 ]} المعيار المقترح. 
• RFC 4217 – " تأمين بروتوكول نقل الملفات باستخدام TLS، " ^{[ 224 ]} معيار مقترح. 
• RFC 4279 – " مجموعات التشفير ذات المفاتيح المشتركة مسبقًا لأمن طبقة النقل (TLS) " ، ^{[ 225 ]} معيار مقترح. 
  يضيف ثلاث مجموعات من مجموعات التشفير الجديدة لبروتوكول TLS لدعم المصادقة القائمة على المفاتيح المشتركة مسبقًا.

• RFC 7457 – " تلخيص الهجمات المعروفة على أمان طبقة النقل (TLS) و Datagram TLS (DTLS) " ، ^{[ 226 ]} معلوماتي. 
• RFC 9325 – " توصيات للاستخدام الآمن لبروتوكول أمان طبقة النقل (TLS) وبروتوكول أمان طبقة نقل البيانات (DTLS) " ، ^{[ 227 ]} أفضل الممارسات الحالية 195.