امنیت با پروتکل‌های شبکه

تعاملات رمزگذاری‌شده کارخواه-سرور از امنیت لایه انتقال (TLS) برای محافظت از داده‌های برنامه‌تان استفاده می‌کنند.

این مقاله روال‌های مطلوب مربوط به روال‌های مطلوب پروتکل شبکه امن و ملاحظات زیرساخت کلید عمومی (PKI) را مورد بحث قرار می‌دهد. برای جزئیات بیشتر، نمای کلی امنیت Android و همچنین نمای کلی اجازه‌ها را بخوانید.

مفاهیم

سرور دارای گواهی TLS یک کلید عمومی و یک کلید خصوصی منطبق دارد. سرور از رمزنگاری کلید عمومی برای امضای گواهی‌اش درطول دست‌دهی TLS استفاده می‌کند.

یک دست‌دهی ساده فقط ثابت می‌کند که سرور کلید خصوصی گواهینامه را می‌داند. برای رسیدگی به این وضعیت، به کارخواه اجازه دهید به چند گواهی اعتماد کند. اگر گواهی سرور در مجموعه گواهی‌های معتبر سمت کارخواه نشان داده نشود، آن سرور غیرقابل‌اعتماد است.

بااین‌حال، سرورها ممکن است از چرخش کلید برای تغییر کلید عمومی گواهی‌شان با کلید جدید استفاده کنند. تغییر پیکربندی سرور مستلزم به‌روزرسانی برنامه کارخواه است. اگر سرور یک سرویس وب شخص ثالث باشد، مانند مرورگر وب یا برنامه ایمیل، تشخیص زمان به‌روزرسانی برنامه کارخواه دشوارتر است.

سرورها معمولاً برای صدور گواهینامه به گواهینامه‌های مرکز صدور گواهی (CA) متکی هستند که باعث می‌شود پیکربندی سمت کارخواه درطول زمان پایدارتر بماند. یک CA گواهی سرور را بااستفاده از کلید خصوصی خود امضا می‌کند. سپس کارخواه می‌تواند بررسی کند که سرور گواهینامه CA شناخته‌شده در پلاتفرم را دارد یا نه.

مرجع‌های صدور گواهی معتمد معمولاً در پلاتفرم میزبان فهرست می‌شوند. ‫Android نسخه ۸.۰ (میانای برنامه‌سازی کاربردی سطح ۲۶) شامل بیش‌از ۱۰۰ مرجع صدور گواهی است که در هر نسخه به‌روزرسانی می‌شوند و بین دستگاه‌ها تغییر نمی‌کنند.

برنامه‌های کارخواه به سازوکاری برای درستی‌سنجی سرور نیاز دارند زیرا CA گواهینامه‌هایی را برای سرورهای متعددی ارائه می‌دهد. گواهی مرجع صدور گواهی، سرور را بااستفاده از نامی خاص، مثل gmail.com، یا بااستفاده از نویسه عام، مثل ‎*.google.com، شناسایی می‌کند.

برای مشاهده اطلاعات گواهینامه سرور وب‌سایت، از فرمان s_client ابزار openssl استفاده کنید و شماره درگاه را وارد کنید. به‌طور پیش‌فرض، HTTPS از درگاه ۴۴۳ استفاده می‌کند.

این فرمان خروجی openssl s_client را به openssl x509 منتقل می‌کند که اطلاعات گواهینامه را در استاندارد X.509 قالب‌بندی می‌کند. فرمان موضوع (نام سرور) و صادرکننده (مرجع صدور گواهی) را درخواست می‌کند.

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

نمونه‌ای از HTTPS

با فرض اینکه سرور وبی با گواهی صادرشده توسط یک «مرجع صدور گواهی» شناخته‌شده دارید، می‌توانید درخواستی امن مطابق کد زیر ایجاد کنید:

کاتلین

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

جاوا

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

برای سفارشی‌سازی درخواست‌های HTTP، به HttpURLConnection ارسال کنید. اسناد Android HttpURLConnection شامل نمونه‌هایی برای مدیریت سرایندهای درخواست و پاسخ، انتشار محتوا، مدیریت کوکی‌ها، استفاده از پراکسی‌ها، ذخیره پاسخ‌ها در حافظه نهان، و موارد دیگر است. چارچوب 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. گواهینامه سرور توسط CA امضا نشده است، بلکه خودامضا است.
3. پیکربندی سرور فاقد CA واسطه است.

بخش‌های زیر نحوه رسیدگی به این مشکلات را ضمن حفظ امنیت اتصال به سرور توضیح می‌دهند.

مرجع صدور گواهی نامشخص

SSLHandshakeException به این دلیل رخ می‌دهد که سیستم به CA اعتماد ندارد. این مشکل ممکن است به‌دلیل داشتن گواهی از یک مرجع صدور گواهی جدید باشد که Android به آن اعتماد ندارد، یا به‌دلیل اینکه برنامه شما در نسخه قدیمی‌تری بدون مرجع صدور گواهی کار می‌کند. ازآنجایی‌که این مرجع خصوصی است، به‌ندرت شناخته می‌شود. اغلب، «مرجع صدور گواهی» ناشناخته است چون «مرجع صدور گواهی» عمومی نیست، بلکه خصوصی است و توسط سازمانی مثل دولت، شرکت، یا مؤسسه آموزشی برای استفاده خودش صادر شده است.

برای اعتماد به CAهای سفارشی بدون نیاز به تغییر کد برنامه، پیکربندی امنیت شبکه را تغییر دهید.

احتیاط: بسیاری از وب‌سایت‌ها راه‌حل جایگزین ضعیفی را شرح می‌دهند که عبارت است از نصب TrustManager که هیچ کاری انجام نمی‌دهد. انجام این کار باعث می‌شود کاربران شما هنگام استفاده از نقطه اتصال Wi-Fi عمومی دربرابر حملات آسیب‌پذیر شوند، زیرا مهاجم می‌تواند بااستفاده از ترفندهای ساناد، ترافیک کاربران شما را ازطریق پراکسی‌ای ارسال کند که وانمود می‌کند سرور شما است. سپس مهاجم می‌تواند گذرواژه‌ها و دیگر داده‌های شخصی را ضبط کند. این روش کار می‌کند چون مهاجم می‌تواند گواهینامه تولید کند و بدون TrustManager که تأیید کند گواهینامه از منبعی قابل‌اعتماد آمده است، نمی‌توانید این نوع حمله را مسدود کنید. بنابراین این کار را حتی به‌طور موقت انجام ندهید. درعوض، برنامه‌تان را طوری تنظیم کنید که به صادرکننده گواهینامه سرور اعتماد کند.

گواهی سرور خودامضا

دوم، SSLHandshakeException ممکن است به‌دلیل گواهینامه خودامضا رخ دهد که باعث می‌شود سرور خودش مرکز صدور گواهی باشد. این مورد مشابه مرجع صدور گواهینامه ناشناخته است، بنابراین «پیکربندی امنیت شبکه» برنامه‌تان را تغییر دهید تا به گواهینامه‌های خودامضاشده‌تان اعتماد کند.

مرجع صدور گواهی واسط وجود ندارد

سوم، SSLHandshakeException به‌دلیل نبودن CA واسطه رخ می‌دهد. «مرکز صدور گواهی» عمومی به‌ندرت گواهینامه‌های سرور را امضا می‌کند. درعوض، مرجع گواهی ریشه مراجع گواهی میانی را امضا می‌کند.

برای کاهش خطر به‌خطر افتادن، مراجع صدور گواهی، مرجع صدور گواهی ریشه را آفلاین نگه می‌دارند. بااین‌حال، سیستم‌عامل‌هایی مانند Android معمولاً فقط به مراجع صدور گواهی ریشه به‌طور مستقیم اعتماد می‌کنند، که این امر باعث ایجاد یک شکاف اعتماد کوتاه بین گواهینامه سرور (امضاشده توسط مرجع صدور گواهی واسطه) و تأییدکننده گواهینامه می‌شود، که مرجع صدور گواهی ریشه را تشخیص می‌دهد.

برای ازبین بردن این شکاف اعتماد، سرور درطول دست‌دهی TLS زنجیره‌ای از گواهینامه‌ها را از CA سرور ازطریق هر واسطی به CA ریشه قابل‌اعتماد ارسال می‌کند.

برای مثال، در اینجا زنجیره گواهی 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 ارسال می‌کند که توسط CA Thawte SGC صادر شده است که یک CA واسطه است، و گواهینامه دومی برای CA Thawte SGC که توسط CA Verisign صادر شده است که CA اصلی مورد اعتماد Android است.

اما ممکن است سرور برای گنجاندن CA واسط ضروری پیکربندی نشده باشد. برای مثال، در اینجا سروری وجود دارد که می‌تواند باعث بروز خطا در مرورگرهای 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 خود را بدون CA ارائه دهند. متأسفانه گاهی این سرورها می‌توانند سرویس وبی را ارائه دهند که شما سعی دارید ازطریق برنامه Android خود به آن دسترسی پیدا کنید، که این برنامه چندان سازگار نیست.

برای برطرف کردن این مشکل، سرور را پیکربندی کنید تا مرجع گواهی میانی را در زنجیره سرور قرار دهد. اکثر «مرجع‌های صدور گواهی» دستورالعمل‌هایی درباره نحوه انجام این کار برای سرورهای وب رایج ارائه می‌دهند.

هشدارهای مربوط به استفاده مستقیم از SSLSocket

تاکنون، مثال‌ها بر HTTPS بااستفاده از HttpsURLConnection متمرکز بوده‌اند. گاهی اوقات برنامه‌ها باید از TLS جدا از HTTPS استفاده کنند. برای نمونه، برنامه ایمیل ممکن است از انواع «امنیت لایه انتقال» SMTP،‏ POP3، یا IMAP استفاده کند. در این موارد، برنامه می‌تواند مستقیماً از SSLSocket استفاده کند، درست همان‌طور که HttpsURLConnection به‌طور داخلی این کار را انجام می‌دهد.

روش‌هایی که تاکنون برای رفع مشکلات درستی‌سنجی گواهینامه شرح داده شد برای SSLSocket نیز کاربرد دارد. درواقع، هنگام استفاده از TrustManager سفارشی، آنچه به HttpsURLConnection منتقل می‌شود SSLSocketFactory است. بنابراین اگر لازم است از TrustManager سفارشی با SSLSocket استفاده کنید، همین مراحل را دنبال کنید و از آن SSLSocketFactory برای ایجاد SSLSocket استفاده کنید.

احتیاط: SSLSocket درستی‌سنجی نام میزبان را انجام نمی‌دهد. برنامه‌تان باید درستی‌سنجی نام میزبان را خودش انجام دهد، ترجیحاً با فراخوانی getDefaultHostnameVerifier() با نام میزبان موردانتظار. همچنین توجه داشته باشید که HostnameVerifier.verify() درصورت بروز خطا، استثنایی ایجاد نمی‌کند. درعوض، نتیجه‌ای بولی برمی‌گرداند که باید به‌طور صریح بررسی کنید.

اعتبارسنجی گواهینامه

«امنیت لایه انتقال» به «مرکز صدور گواهی» متکی است تا گواهی‌ها را فقط برای مالکان تأییدشده سرورها و دامنه‌ها صادر کند. در موارد نادر، CAها فریب می‌خورند یا در مورد Comodo یا DigiNotar، نقض می‌شوند، که منجر به صدور گواهینامه‌های نام میزبان برای شخصی غیر از مالک سرور یا دامنه می‌شود.

برای کاهش این خطر، Android ابطال گواهینامه را در سراسر سیستم ازطریق ترکیبی از فهرست غیرمجازها و شفافیت گواهینامه، بدون تکیه بر درستی‌سنجی آنلاین گواهینامه، مدیریت می‌کند. علاوه‌براین، Android پاسخ‌های OCSP منگنه شده به دست‌دهی TLS را اعتبارسنجی خواهد کرد.

برای فعال کردن «شفافیت گواهینامه» در برنامه‌تان، به بخش موافقت کردن با شفافیت گواهینامه در سند «پیکربندی امنیت شبکه» ما مراجعه کنید.

محدود کردن برنامه به گواهی‌های خاص

احتیاط: سنجاق کردن گواهی، یعنی محدود کردن گواهی‌هایی که برای برنامه‌تان معتبر درنظر گرفته می‌شوند به گواهی‌هایی که قبلاً مجاز کرده‌اید، برای برنامه‌های Android توصیه نمی‌شود. تغییرات پیکربندی سرور در آینده، مانند تغییر به یک CA دیگر، باعث می‌شود برنامه‌هایی که گواهینامه‌های پین‌شده دارند نتوانند بدون دریافت به‌روزرسانی نرم‌افزار کارخواه به سرور متصل شوند.

اگر می‌خواهید برنامه‌تان را محدود کنید تا فقط گواهی‌هایی را که مشخص می‌کنید بپذیرد، بسیار مهم است که چندین پین پشتیبان اضافه کنید، ازجمله حداقل یک کلید که کاملاً تحت کنترل شما باشد، و دوره انقضای به‌اندازه کافی کوتاه برای جلوگیری از مشکلات سازگاری. پیکربندی امنیت شبکه سنجاق کردن را با این قابلیت‌ها ارائه می‌دهد.

گواهینامه‌های کارخواه

این مقاله بر استفاده از TLS برای ایمن‌سازی ارتباطات با سرورها تمرکز دارد. «امنیت لایه انتقال» همچنین از مفهوم گواهینامه‌های کارخواه پشتیبانی می‌کند که به سرور اجازه می‌دهد هویت کارخواه را اعتبارسنجی کند. اگرچه این موضوع فراتر از محدوده این مقاله است، اما تکنیک‌های مربوطه مشابه مشخص کردن TrustManager سفارشی است.

Nogotofail: ابزار آزمایش امنیت ترافیک شبکه

Nogotofail ابزاری است که روشی آسان برای تأیید ایمن بودن برنامه‌هایتان دربرابر آسیب‌پذیری‌ها و پیکربندی‌های نادرست TLS/SSL شناخته‌شده ارائه می‌دهد. این ابزار خودکار، قدرتمند، و مقیاس‌پذیر برای آزمایش مشکلات امنیتی شبکه در هر دستگاهی است که ترافیک شبکه آن را بتوان ازطریق آن هدایت کرد.

Nogotofail برای سه مورد استفاده اصلی مفید است:

• پیدا کردن اشکالات و آسیب‌پذیری‌ها.
• درستی‌سنجی اصلاحات و مراقبت از پس‌رفت‌ها.
• درک اینکه کدام برنامه‌ها و دستگاه‌ها چه ترافیکی ایجاد می‌کنند.

Nogotofail برای Android،‏ iOS،‏ Linux،‏ Windows،‏ ChromeOS،‏ macOS، و درواقع هر دستگاهی که برای اتصال به اینترنت استفاده می‌کنید کار می‌کند. یک کارخواه برای پیکربندی تنظیمات و دریافت اعلان‌ها در Android و Linux دردسترس است و خود موتور حمله می‌تواند به‌عنوان رهیاب، سرور VPN، یا پراکسی مستقر شود.

می‌توانید در پروژه متن‌باز Nogotofail به این ابزار دسترسی پیدا کنید.

به‌روزرسانی‌های SSL و TLS

‫Android 10

برخی‌از مرورگرها، مثل Google Chrome، به کاربران اجازه می‌دهند وقتی سرور TLS پیام درخواست گواهینامه را به‌عنوان بخشی از دست‌دهی TLS ارسال می‌کند، گواهینامه‌ای را انتخاب کنند. از Android 10، اشیای KeyChain هنگام فراخوانی KeyChain.choosePrivateKeyAlias() برای نمایش پیام‌واره انتخاب گواهینامه به کاربران، پارامترهای مشخصات کلید و صادرکنندگان را رعایت می‌کنند. به‌ویژه، این پیام‌واره حاوی انتخاب‌هایی نیست که از مشخصات سرور پیروی نکنند.

اگر گواهینامه قابل‌انتخابی برای کاربر دردسترس نباشد، مثلاً وقتی هیچ گواهینامه‌ای با مشخصات سرور مطابقت نداشته باشد یا هیچ گواهینامه‌ای در دستگاه نصب نشده باشد، پیام‌واره انتخاب گواهینامه اصلاً ظاهر نمی‌شود.

علاوه‌براین، در Android نسخه ۱۰ یا بالاتر، برای وارد کردن کلیدها یا گواهینامه‌های CA به شیء KeyChain، نیازی به قفل صفحه دستگاه نیست.

TLS 1.3 به‌طور پیش‌فرض فعال است

در Android 10 و بالاتر، «امنیت لایه انتقال» نسخه ۱.۳ به‌طور پیش‌فرض برای همه اتصال‌های «امنیت لایه انتقال» فعال است. در اینجا چند جزئیات مهم درباره پیاده‌سازی TLS 1.3 ما آورده شده است:

• مجموعه رمزهای TLS 1.3 را نمی‌توان سفارشی‌سازی کرد. مجموعه رمزهای پشتیبانی‌شده «امنیت لایه انتقال» نسخه ۱.۳ همیشه هنگام فعال بودن «امنیت لایه انتقال» نسخه ۱.۳ فعال هستند. هرگونه تلاش برای غیرفعال کردن آن‌ها با فراخوانی setEnabledCipherSuites() نادیده گرفته می‌شود.
• وقتی TLS 1.3 مذاکره می‌شود، اشیای HandshakeCompletedListener پیش‌از اینکه جلسه‌ها به حافظه نهان جلسه اضافه شوند فراخوانی می‌شوند. (در TLS 1.2 و دیگر نسخه‌های قبلی، این اشیاء پس‌از اضافه شدن جلسه‌ها به حافظه نهان جلسه فراخوانی می‌شوند.)
• در برخی شرایط که نمونه‌های SSLEngine در نسخه‌های قبلی Android یک SSLHandshakeException را برمی‌گردانند، این نمونه‌ها در Android 10 و بالاتر به‌جای آن یک SSLProtocolException را برمی‌گردانند.
• حالت 0-RTT پشتیبانی نمی‌شود.

درصورت تمایل، می‌توانید با فراخوانی SSLContext.getInstance("TLSv1.2")، یک SSLContext دریافت کنید که TLS 1.3 در آن غیرفعال شده است. همچنین می‌توانید نسخه‌های پروتکل را براساس هر اتصال با فراخوانی setEnabledProtocols() در شیء مناسب فعال یا غیرفعال کنید.

گواهی‌های امضاشده با SHA-1 در TLS مورداعتماد نیستند

در Android 10، گواهینامه‌هایی که از الگوریتم درهم‌سازی SHA-1 استفاده می‌کنند در اتصالات TLS قابل‌اعتماد نیستند. «مرجع صدور گواهی ریشه» از سال ۲۰۱۶ چنین گواهی‌هایی صادر نکرده است و این گواهی‌ها دیگر در Chrome یا مرورگرهای اصلی دیگر قابل‌اعتماد نیستند.

اگر اتصال به سایتی باشد که گواهینامه‌ای بااستفاده از «الگوریتم درهم‌سازی ایمن ۱» ارائه می‌دهد، هرگونه تلاش برای اتصال ناموفق خواهد بود.

تغییرات و بهبودهای رفتار KeyChain

برخی‌از مرورگرها، مانند Google Chrome، به کاربران اجازه می‌دهند وقتی سرور TLS پیام درخواست گواهینامه را به‌عنوان بخشی از دست‌دهی TLS ارسال می‌کند، گواهینامه‌ای را انتخاب کنند. از Android 10، اشیاء KeyChain هنگام فراخوانی KeyChain.choosePrivateKeyAlias() برای نمایش پیام‌واره انتخاب گواهی به کاربران، از صادرکنندگان و پارامترهای مشخصات کلیدی پیروی می‌کنند. به‌ویژه، این پیام‌واره حاوی انتخاب‌هایی نیست که از مشخصات سرور پیروی نکنند.

اگر گواهینامه قابل‌انتخاب توسط کاربر دردسترس نباشد، مثلاً وقتی هیچ گواهینامه‌ای با مشخصات سرور مطابقت نداشته باشد یا هیچ گواهینامه‌ای در دستگاه نصب نشده باشد، پیام‌واره انتخاب گواهینامه اصلاً نشان داده نمی‌شود.

علاوه‌براین، در Android نسخه ۱۰ یا بالاتر، برای وارد کردن کلیدها یا گواهینامه‌های CA به شیء 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 Keystore، می‌توانند با امضاهای RSA-PSS در TLS استفاده شوند.

تغییرات اتصال HTTPS

اگر برنامه‌ای که Android 10 را اجرا می‌کند، null را به setSSLSocketFactory() منتقل کند، IllegalArgumentException رخ می‌دهد. در نسخه‌های قبلی، ارسال null به setSSLSocketFactory() همان تأثیر ارسال کارخانه پیش‌فرض فعلی را داشت.

Android 11

سوکت‌های SSL به‌طور پیش‌فرض از موتور Conscrypt SSL استفاده می‌کنند

پیاده‌سازی SSLSocket پیش‌فرض Android براساس Conscrypt است. از Android 11، این پیاده‌سازی به‌طور داخلی روی SSLEngine مربوط به Conscrypt ساخته شده است.