الأمان باستخدام بروتوكولات الشبكة

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

تتناول هذه المقالة أفضل الممارسات المتعلقة بأفضل الممارسات المتعلقة ببروتوكول الشبكة الآمن والبنية الأساسية للمفاتيح العامة (PKI). لمزيد من التفاصيل، يُرجى الاطّلاع على نظرة عامة على أمان Android ونظرة عامة على الأذونات.

المفاهيم

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

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

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

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

يتم عادةً إدراج جهات إصدار الشهادات الموثوق بها على منصّة المضيف. يتضمّن الإصدار Android 8.0 (المستوى 26 لواجهة برمجة التطبيقات) أكثر من 100 هيئة اعتماد يتم تعديلها في كل إصدار ولا تتغيّر بين الأجهزة.

تحتاج تطبيقات العميل إلى آلية للتحقّق من الخادم لأنّ مرجع التصديق يقدّم شهادات لعدة خوادم. تحدِّد شهادة CA الخادم باستخدام اسم محدّد، مثل gmail.com، أو باستخدام علامة متعلّقة، مثل *.google.com.

للاطّلاع على معلومات شهادة خادم موقع إلكتروني، استخدِم الأمر s_client في أداة openssl مع إدخال رقم المنفذ. يستخدم بروتوكول HTTPS المنفذ 443 تلقائيًا.

ينقل الأمر إخراج openssl s_client إلى openssl x509، الذي يصيغ معلومات الشهادة في معيار X.509. يطلب الأمر الموضوع (اسم الخادم) وجهة الإصدار (مُقدِّم خدمات إصدار الشهادات).

openssl s_client -connect WEBSITE-URL:443 | \
  openssl x509 -noout -subject -issuer

مثال على HTTPS

بافتراض أنّ لديك خادم ويب لديه شهادة صادرة عن مرجع تصديق معروف، يمكنك تقديم طلب آمن كما هو موضّح في الرمز البرمجي التالي:

Kotlin

val url = URL("https://wikipedia.org")
val urlConnection: URLConnection = url.openConnection()
val inputStream: InputStream = urlConnection.getInputStream()
copyInputStreamToOutputStream(inputStream, System.out)

Java

URL url = new URL("https://wikipedia.org");
URLConnection urlConnection = url.openConnection();
InputStream in = urlConnection.getInputStream();
copyInputStreamToOutputStream(in, System.out);

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

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

المشاكل الشائعة في التحقّق من شهادات الخادم

لنفترض أنّ getInputStream()، بدلاً من عرض المحتوى، يُلقي استثناءً:

javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
        at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:374)
        at libcore.net.http.HttpConnection.setupSecureSocket(HttpConnection.java:209)
        at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.makeSslConnection(HttpsURLConnectionImpl.java:478)
        at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:433)
        at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:290)
        at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:240)
        at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:282)
        at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177)
        at libcore.net.http.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:271)

قد يحدث ذلك لعدة أسباب، منها:

  1. كانت هيئة إصدار الشهادات التي أصدرت شهادة الخادم غير معروفة.
  2. لم يتم توقيع شهادة الخادم من قِبل هيئة إصدار الشهادات، بل تم توقيعها ذاتيًا.
  3. تُفتقد شهادة هيئة إصدار مصدق وسيطة في إعدادات الخادم.

تتناول الأقسام التالية كيفية معالجة هذه المشاكل مع الحفاظ على أمان الاتصال بالخادم.

هيئة إصدار الشهادات غير معروفة

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

لتصديق شهادات CA المخصّصة بدون الحاجة إلى تغيير رمز تطبيقك، عليك تغيير إعدادات أمان الشبكة.

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

شهادة الخادم الموقَّعة ذاتيًا

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

عدم توفّر هيئة إصدار الشهادات المتوسطة

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

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

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

على سبيل المثال، إليك سلسلة شهادات mail.google.com كما تظهر من خلال الأمر openssl s_client:

$ openssl s_client -connect mail.google.com:443
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=mail.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---

يشير ذلك إلى أنّ الخادم يرسل شهادة mail.google.com صادرة عن مرجع التصديق Thawte SGC، وهو مرجع تصديق وسيط، وشهادة ثانية لمرجع التصديق Thawte SGC صادرة عن مرجع التصديق Verisign، وهو مرجع التصديق الأساسي الذي يثق فيه Android.

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

$ openssl s_client -connect egov.uscis.gov:443
---
Certificate chain
 0 s:/C=US/ST=District Of Columbia/L=Washington/O=U.S. Department of Homeland Security/OU=United States Citizenship and Immigration Services/OU=Terms of use at www.verisign.com/rpa (c)05/CN=egov.uscis.gov
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
---

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

وبعض المواقع الإلكترونية تفعل ذلك عن قصد لخوادم الويب الثانوية التي تعرِض الموارد. لتوفير عرض النطاق، قد يعرضون صفحة HTML الرئيسية من خادم يتضمّن سلسلة شهادات كاملة، ولكنهم قد يعرضون الصور وCSS وJavaScript بدون مرجع التصديق. في بعض الأحيان، قد تقدّم هذه الخوادم خدمة ويب تحاول الوصول إليها من تطبيق Android، وهي ليست متسامحة بقدر الخوادم الأخرى.

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

تحذيرات بشأن استخدام SSLSocket مباشرةً

حتى الآن، ركّزت الأمثلة على بروتوكول HTTPS باستخدام HttpsURLConnection. تحتاج التطبيقات أحيانًا إلى استخدام بروتوكول TLS منفصل عن بروتوكول HTTPS. على سبيل المثال، قد يستخدم تطبيق البريد الإلكتروني أنواعًا مختلفة من بروتوكول TLS لبروتوكول SMTP أو POP3 أو IMAP. وفي هذه الحالات، يمكن للتطبيق استخدام SSLSocket مباشرةً، بالطريقة نفسها التي يستخدمها HttpsURLConnection داخليًا.

تنطبق أيضًا الأساليب الموضّحة حتى الآن للتعامل مع مشاكل إثبات صحة الشهادة على SSLSocket. في الواقع، عند استخدام TrustManager مخصّص، يتمّ تمرير SSLSocketFactory إلى HttpsURLConnection. إذا كنت بحاجة إلى استخدام TrustManager مخصّص مع SSLSocket، اتّبِع الخطوات نفسها واستخدِمSSLSocketFactory هذا لإنشاء SSLSocket.

تحذير: SSLSocket لا تُجري عملية التحقّق من اسم المضيف. على تطبيقك التحقّق من اسم المضيف، ويُفضَّل أن يتم ذلك من خلال الاتصال بـ getDefaultHostnameVerifier() باستخدام اسم المضيف المتوقّع. يُرجى العلم أيضًا أنّ HostnameVerifier.verify() لا يُلقي استثناءً عند حدوث خطأ. بدلاً من ذلك، يعرض نتيجة منطقية يجب التحقّق منها صراحةً.

التحقّق من الشهادة

يعتمد بروتوكول أمان طبقة النقل (TLS) على مراجِع التصديق لإصدار الشهادات للمالكين الذين تم إثبات هويتهم فقط للخوادم والنطاقات. في حالات نادرة، يتم خداع خدمات إصدار الشهادات أو اختراقها، كما حدث في Comodo أو DigiNotar، مما يؤدي إلى إصدار شهادات اسم مضيف لمستخدم غير مالك الخادم أو النطاق.

للحد من هذا الخطر، يعالج نظام التشغيل Android عملية إبطال الشهادة على مستوى النظام، من خلال تركيبة من قائمة الحظر وشفافية الشهادة، بدون الاعتماد على عملية التحقّق من الشهادة على الإنترنت. بالإضافة إلى ذلك، سيتحقّق نظام التشغيل Android من استجابات OCSP المُدمَجة في تأكيد الاتصال ببروتوكول أمان طبقة النقل (TLS).

لتفعيل مبادرة Certificate Transparency في تطبيقك، اطّلِع على القسم تفعيل مبادرة Certificate Transparency في مستندات "إعداد أمان الشبكات".

حصر تطبيقك بشهادات معيّنة

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

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

شهادات العميل

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

Nogotofail: أداة لاختبار أمان حركة المرور على الشبكة

‫Nogotofail هي أداة تمنحك طريقة سهلة للتأكّد من أمان تطبيقاتك ضد الثغرات الأمنية المعروفة في بروتوكول أمان طبقة النقل/طبقة المقابس الآمنة وعمليات الضبط الخاطئة. وهي أداة مبرمَجة وفعّالة وقابلة للتطوير لاختبار مشاكل أمان الشبكة على أي جهاز يمكن توجيه حركة بياناته على الشبكة من خلاله.

يكون Nogotofail مفيدًا في ثلاث حالات استخدام رئيسية:

  • العثور على الأخطاء والثغرات الأمنية
  • التحقّق من الإصلاحات وملاحظة أيّ تراجعات
  • فهم التطبيقات والأجهزة التي تجذب الزيارات

يعمل Nogotofail مع Android وiOS وLinux وWindows وChromeOS وmacOS، وبشكلٍ عام مع أي جهاز تستخدمه للاتصال بالإنترنت. يتوفّر برنامج عميل ل ضبط الإعدادات والحصول على الإشعارات على Android وLinux، و يمكن نشر محرّك الهجوم نفسه كجهاز توجيه أو خادم شبكة VPN أو خادم وكيل.

يمكنك الوصول إلى الأداة من خلال مشروع Nogotofail المفتوح المصدر.

تعديلات على طبقة المقابس الآمنة وطبقة النقل الآمنة

Android 10

تسمح بعض المتصفّحات، مثل Google Chrome، للمستخدمين باختيار شهادة عندما يُرسِل خادم بروتوكول أمان طبقة النقل (TLS) رسالة طلب شهادة كجزء من عملية تأكيد اتصال بروتوكول أمان طبقة النقل. اعتبارًا من Android 10، تلتزم عناصر KeyChain بمُصدِري الشهادات ومَعلمات مواصفات المفاتيح عند استدعاء KeyChain.choosePrivateKeyAlias() لعرض طلب اختيار شهادة للمستخدمين. على وجه الخصوص، لا يحتوي هذا الطلب على خيارات لا تلتزم بمواصفات الخادم.

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

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

تفعيل الإصدار 1.3 من بروتوكول أمان طبقة النقل (TLS) تلقائيًا

في الإصدار 10 من نظام التشغيل Android والإصدارات الأحدث، يكون بروتوكول TLS 1.3 مفعّلاً تلقائيًا لجميع اتصالات TLS. في ما يلي بعض التفاصيل المهمة حول تنفيذ بروتوكول TLS 1.3:

  • لا يمكن تخصيص مجموعات رموز التشفير في بروتوكول أمان طبقة النقل (TLS) 1.3. يتم دائمًا تفعيل مجموعات رموز التشفير المتوافقة مع الإصدار 1.3 من بروتوكول أمان طبقة النقل عند تفعيل هذا البروتوكول. ويتم تجاهل أي محاولة لإيقاف هذه الميزة من خلال الاتصال بالرقم setEnabledCipherSuites().
  • عند التفاوض على بروتوكول أمان طبقة النقل (TLS) 1.3، يتمّ استدعاء عناصر HandshakeCompletedListener قبل إضافة الجلسات إلى ذاكرة التخزين المؤقت للجلسات. (في الإصدار 1.2 من طبقة النقل الآمنة والإصدارات السابقة الأخرى، يتمّ استدعاء هذه العناصر بعد إضافة الجلسات إلى ذاكرة التخزين المؤقت للجلسات).
  • في بعض الحالات التي تُعرِض فيها نُسخ SSLEngine الخطأ SSLHandshakeException على الإصدارات السابقة من Android، تعرِض هذه النُسخ الخطأ SSLProtocolException بدلاً من ذلك على الإصدار 10 من Android والإصدارات الأحدث.
  • وضع 0-RTT غير متاح.

إذا أردت، يمكنك الحصول على SSLContext تم إيقاف بروتوكول TLS 1.3 فيه من خلال الاتصال بـ SSLContext.getInstance("TLSv1.2"). يمكنك أيضًا تفعيل إصدارات البروتوكول أو إيقافها لكل اتصال على حدة من خلال استدعاء setEnabledProtocols() على عنصر مناسب.

إنّ الشهادات الموقَّعة باستخدام SHA-1 غير موثوق بها في بروتوكول أمان طبقة النقل (TLS).

في Android 10، لا تكون الشهادات التي تستخدم خوارزمية تجزئة SHA-1 موثوق بها في اتصالات بروتوكول أمان طبقة النقل (TLS). لم تُصدر هيئات إصدار الشهادات الجذر هذه الشهادات منذ عام 2016، ولم تعُد موثوقًا بها في Chrome أو المتصفحات الرئيسية الأخرى.

وتؤدّي أي محاولة للاتصال إلى تعذُّر الاتصال إذا كان الموقع الإلكتروني الذي يتم الاتصال به يقدّم شهادة باستخدام SHA-1.

التغييرات والتحسينات في سلوك KeyChain

تسمح بعض المتصفّحات، مثل Google Chrome، للمستخدمين باختيار شهادة عندما يُرسِل خادم بروتوكول أمان طبقة النقل (TLS) رسالة طلب شهادة كجزء من عملية تأكيد اتصال بروتوكول أمان طبقة النقل. اعتبارًا من Android 10، تمتثل عناصر KeyChain لمَعلمات المُصدرين والمواصفات الرئيسية عند استدعاء KeyChain.choosePrivateKeyAlias() لعرض طلب اختيار شهادة للمستخدمين. على وجه التحديد، لا يحتوي هذا الطلب على خيارات لا تتوافق مع مواصفات الخادم.

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

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

تغييرات أخرى في بروتوكول أمان طبقة النقل (TLS) والتشفير

تم إجراء العديد من التغييرات البسيطة في مكتبات التشفير وطبقة النقل الآمنة (TLS) التي تسري على نظام التشغيل Android 10:

  • تُعرِض شفرات AES/GCM/NoPadding وChaCha20/Poly1305/NoPadding أحجامًا أكثر دقة للوسائط المُخزَّنة مؤقتًا اعتبارًا من getOutputSize().
  • تم حذف مجموعة التشفير TLS_FALLBACK_SCSV من محاولات الاتصال باستخدام بروتوكول بحد أقصى TLS 1.2 أو إصدار أحدث. بسبب التحسينات في عمليات تنفيذ خادم TLS، لا ننصحك بمحاولة استخدام نظام TLS الاحتياطي الخارجي. بدلاً من ذلك، ننصحك بالاعتماد على التفاوض بشأن إصدار بروتوكول TLS.
  • ChaCha20-Poly1305 هو اسم بديل لـ ChaCha20/Poly1305/NoPadding.
  • لا تُعدّ أسماء المضيفين التي تحتوي على نقاط متسلسلة أسماء مضيفين صالحة لبروتوكول SNI.
  • يتمّ الالتزام بإضافة supported_signature_algorithms في CertificateRequest عند اختيار مفتاح توقيع للردّ على الشهادة.
  • يمكن استخدام مفاتيح التوقيع غير الشفافة، مثل تلك الواردة من "متجر مفاتيح Android"، مع توقيعات RSA-PSS في بروتوكول TLS.

تغييرات في الاتصال عبر HTTPS

إذا كان أحد التطبيقات التي تعمل بنظام Android 10 يُرسل قيمة فارغة إلى setSSLSocketFactory()، يحدث خطأ IllegalArgumentException. في الإصدارات السابقة، كان لضبط القيمة null في setSSLSocketFactory() التأثير نفسه لضبط المصنع التلقائي الحالي.

Android 11

تستخدم مقابس طبقة المقابس الآمنة محرك Conscrypt SSL تلقائيًا.

يستند تنفيذ SSLSocket التلقائي في Android إلى Conscrypt. منذ الإصدار 11 من Android، تم إنشاء هذا التنفيذ داخليًا على أساس SSLEngine من Conscrypt.