SSL/TLS — چیست، پروتکل‌ها و اصل عملکرد رمزنگاری

SSL/TLS چیست؟

SSL (Secure Sockets Layer) — پروتکلی است که توسط شرکت Netscape در سال ۱۹۹۵ برای حفاظت از ترافیک وب توسعه یافت. نسخه اول SSL 1.0 هرگز منتشر نشد، SSL 2.0 (۱۹۹۵) و SSL 3.0 (۱۹۹۶) تا اوایل دهه ۲۰۰۰ استفاده می‌شدند، اما دارای آسیب‌پذیری‌های بحرانی بودند. به جای SSL، TLS (Transport Layer Security) — نسخه بهبود یافته استاندارد شده توسط IETF — آمد. TLS 1.0 (۱۹۹۹) بر اساس SSL 3.0 بود و نسخه‌های بعدی TLS 1.1 (۲۰۰۶)، TLS 1.2 (۲۰۰۸) و TLS 1.3 (۲۰۱۸) به تدریج از معماری اصلی فاصله گرفتند، الگوریتم‌های رمزنگاری جدید اضافه کردند و آسیب‌پذیری‌ها را برطرف کردند. امروزه SSL منسوخ تلقی می‌شود و تمام سیستم‌های مدرن از TLS استفاده می‌کنند، اگرچه از روی عادت هر دو پروتکل اغلب با هم به عنوان SSL/TLS ذکر می‌شوند.

تاریخچه ایجاد پروتکل

تاریخچه SSL/TLS با نیاز به انتقال امن داده‌ها در وب اولیه آغاز شد. در سال ۱۹۹۴، شرکت Netscape SSL 1.0 را برای مرورگر Navigator خود توسعه داد، اما این پروتکل به دلیل مشکلات جدی امنیتی هرگز منتشر نشد. SSL 2.0 در سال ۱۹۹۵ منتشر شد و در عمل استفاده می‌شد، اما دارای آسیب‌پذیری‌های متعددی بود: عدم محافظت در برابر حملات Man-in-the-Middle، الگوریتم‌های رمزنگاری ضعیف و آسیب‌پذیری در برابر حملات truncation. SSL 3.0 (۱۹۹۶) بیشتر مشکلات را برطرف کرد، اما تا سال ۲۰۱۴ آسیب‌پذیری POODLE در آن کشف شد، پس از آن IETF رسماً تمام نسخه‌های SSL را منسوخ اعلام کرد. TLS 1.0–1.3 به ترتیب قدرت رمزنگاری، عملکرد و محرمانگی را بهبود بخشیدند، به‌طوری که TLS 1.3 handshake را از دو round-trip به یک کاهش داد که برای برنامه‌های موبایل با اتصال ناپایدار حیاتی است.

SSL/TLS Handshake چگونه کار می‌کند

Handshake — فرآیند برقراری اتصال امن بین کلاینت و سرور است. این فرآیند شامل چند مرحله متوالی است که در طی آن طرفین نسخه پروتکل را توافق می‌کنند، الگوریتم‌های رمزنگاری را انتخاب می‌کنند، کلیدها را مبادله می‌کنند و یکدیگر را احراز هویت می‌کنند. در TLS 1.3، handshake تنها یک تعامل شبکه‌ای (1-RTT) طول می‌کشد، در حالی که در TLS 1.2 دو تعامل (2-RTT) لازم بود.

در اولین گام، کلاینت ClientHello — پیامی حاوی لیست نسخه‌های پشتیبانی شده TLS، مجموعه رمزهای (cipher suites) و یک عدد تصادفی — ارسال می‌کند. سرور با ServerHello شامل نسخه و رمز انتخاب شده، گواهی X.509 خود و امضای دیجیتال پاسخ می‌دهد. کلاینت گواهی را از طریق زنجیره مراکز گواهی (CA) بررسی می‌کند، یک کلید جلسه تولید می‌کند و آن را رمزنگاری شده با کلید عمومی سرور از گواهی ارسال می‌کند. پس از تأیید توسط سرور، انتقال امن داده‌ها آغاز می‌شود. کل handshake در ۱–۳ میلی‌ثانیه در دستگاه‌های مدرن انجام می‌شود که آن را برای کاربر نامرئی می‌کند.

گواهی‌های X.509 و زنجیره اعتماد

اساس احراز هویت TLS زیرساخت کلید عمومی (PKI) ساخته شده بر روی گواهی‌های فرمت X.509 است. هر گواهی شامل: نام دامنه (Common Name یا Subject Alternative Name)، کلید عمومی سرور، نام صادرکننده (Certificate Authority)، مدت اعتبار و امضای دیجیتال CA است. کلاینت گواهی سرور را از طریق زنجیره اعتماد بررسی می‌کند: از گواهی سرور تا CA ریشه که گواهی آن در سیستم عامل تعبیه شده است. در دستگاه‌های Android، گواهی‌های ریشه در فروشگاه سیستم ذخیره می‌شوند که از طریق Google Play Services به‌روزرسانی می‌شود؛ در iOS — از طریق iOS Updates. در صورت نقض هر حلقه از زنجیره (گواهی منقضی، عدم تطابق دامنه، CA ناشناخته)، کلاینت اتصال را قطع می‌کند. برای گواهی‌های خودامضا (مورد استفاده در توسعه)، اعتماد صریح لازم است — در Android از طریق Network Security Config، در iOS از طریق NSExceptionDomains در Info.plist. فرآیند اعتبارسنجی زنجیره گواهی همچنین شامل بررسی وضعیت ابطال از طریق CRL (Certificate Revocation List) یا OCSP (Online Certificate Status Protocol) است، اگرچه در دستگاه‌های موبایل درخواست‌های OCSP اغلب برای تسریع اتصال نادیده گرفته می‌شوند — این مصالحه‌ای بین امنیت و عملکرد است که معماران باید در نظر بگیرند.

SSL در مقابل TLS: تفاوت‌های کلیدی

اگرچه اصطلاحات SSL و TLS اغلب به عنوان مترادف استفاده می‌شوند، تفاوت‌های فنی اساسی بین آنها وجود دارد که بر امنیت و عملکرد برنامه‌های موبایل تأثیر می‌گذارد.

تفاوت اصلی TLS 1.3 با نسخه‌های قبلی — استفاده اجباری از Perfect Forward Secrecy (PFS) از طریق پروتکل ECDHE است. این بدان معناست که حتی اگر مهاجم به کلید خصوصی سرور دسترسی پیدا کند، نمی‌تواند ترافیک قبلاً رهگیری شده را رمزگشایی کند. برای برنامه‌های موبایل، جایی که نفوذ به سرور یک تهدید واقعی است، TLS 1.3 با PFS یک الزام امنیتی اجباری است.

آسیب‌پذیری‌های شناخته شده نسخه‌های قدیمی

نسخه‌های قدیمی SSL و TLS دارای آسیب‌پذیری‌های مستندی هستند که آنها را برای استفاده در تولید نامناسب می‌کند. POODLE (CVE-2014-3566) از طریق padding oracle به SSL 3.0 حمله می‌کند و امکان رمزگشایی کوکی جلسه را در ۲۵۶ درخواست فراهم می‌کند. BEAST (CVE-2011-3389) از آسیب‌پذیری TLS 1.0 در حالت CBC از طریق IV قابل پیش‌بینی بهره‌برداری می‌کند. Heartbleed (CVE-2014-0160) — آسیب‌پذیری پروتکل نیست، بلکه یک اشکال در پیاده‌سازی OpenSSL است که امکان خواندن حافظه سرور را فراهم می‌کند: به گفته Netcraft، در سال ۲۰۱۴ بیش از ۵۰۰ هزار سرور آسیب‌پذیر بودند. از Android 10 (API 29) و iOS 13 به بعد، تمام پروتکل‌های ذکر شده در سطح سیستم غیرفعال شده‌اند. با این حال، توسعه‌دهندگان باید پیکربندی سرور را از طریق SSL Labs Test (qualys.com) قبل از راه‌اندازی برنامه بررسی کنند تا از عدم وجود cipher suites قدیمی و پشتیبانی از TLS 1.3 اطمینان حاصل کنند.

SSL/TLS چگونه از داده‌ها در برنامه‌های موبایل محافظت می‌کند

در برنامه‌های موبایل، TLS از داده‌ها در سه سطح محافظت می‌کند: رمزنگاری محتوا (هیچ کس به جز سرور نمی‌تواند داده‌ها را بخواند)، بررسی یکپارچگی (داده‌ها نمی‌توانند در مسیر تغییر کنند) و احراز هویت سرور (کلاینت مطمئن است که به سرور درست متصل می‌شود). احراز هویت به ویژه حیاتی است: بدون آن، مهاجم می‌تواند سرور را از طریق DNS-spoofing یا نقطه دسترسی Wi-Fi جعلی جعل کند.

طبق تحقیق Google Play Protect (۲۰۲۴)، ۷۶٪ از برنامه‌های Android از TLS با بررسی گواهی به درستی استفاده می‌کنند. ۲۴٪ باقی مانده مرتکب اشتباهاتی می‌شوند: بررسی گواهی را برای تست غیرفعال می‌کنند (و فراموش می‌کنند در تولید فعال کنند)، از گواهی‌های خودامضا بدون اعتبارسنجی استفاده می‌کنند یا به پروتکل‌های قدیمی SSL 3.0 و TLS 1.0 اجازه می‌دهند. Apple App Transport Security (ATS) در iOS از سال ۲۰۱۷ حداقل TLS 1.2 را الزامی می‌کند و از iOS 15 به طور پیش‌فرض از TLS 1.3 برای تمام درخواست‌های شبکه استفاده می‌کند. برای محافظت اضافی، پیاده‌سازی Certificate Pinning — اتصال به گواهی خاص سرور — نیز توصیه می‌شود.

پیاده‌سازی SSL/TLS در برنامه‌های موبایل

بیایید نمونه پیکربندی اتصال امن HTTPS در Android با استفاده از OkHttp — یکی از محبوب‌ترین کتابخانه‌ها برای کار با شبکه — را بررسی کنیم. پیکربندی صحیح شامل استفاده اجباری از TLS 1.3 و بررسی گواهی‌ها است.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()

در این مثال، مجموعه نسخه‌های پشتیبانی شده TLS را فقط به پروتکل‌های ۱.۳ و ۱.۲ محدود می‌کنیم و TLS 1.0/1.1 قدیمی را حذف می‌کنیم. Cipher suites از الگوریتم‌های مدرن با حالت AEAD و Perfect Forward Secrecy اجباری انتخاب می‌شوند. HostnameVerifier تطابق نام میزبان با گواهی را بررسی می‌کند. برای iOS، پیکربندی مشابه از طریق تنظیمات URLSession با پارامتر tlsMinimumSupportedProtocolVersion انجام می‌شود که در آن .TLSv13 مشخص می‌شود. علاوه بر این، در iOS می‌توان tlsMaximumSupportedProtocolVersion را برای محدود کردن حد بالای نسخه‌ها تنظیم کرد — این برای سازگاری با سرورهای قدیمی که هنوز به TLS 1.3 مهاجرت نکرده‌اند مفید است. چنین پیکربندی حداکثر سطح امنیت را هنگام انتقال داده‌ها در برنامه موبایل تضمین می‌کند.