SSL/TLS: مفاهیم کلیدی و پروتکل‌ها در برنامه‌نویسی

SSL/TLS چیست؟

SSL (Secure Sockets Layer) و TLS (Transport Layer Security) — پروتکل‌های رمزنگاری هستند که انتقال امن داده‌ها از طریق شبکه را تضمین می‌کنند. SSL که توسط Netscape در دهه 1990 توسعه یافت، پس از نسخه 3.0 به دلیل آسیب‌پذیری‌های POODLE و BEAST منسوخ اعلام شد. TLS، جانشین آن، از نسخه‌های 1.0، 1.1، 1.2 و 1.3 عبور کرده است — در حال حاضر فقط TLS 1.2 و TLS 1.3 به‌روز محسوب می‌شوند. همه پلتفرم‌های موبایل مدرن استفاده از TLS را برای اتصالات شبکه الزامی می‌کنند و App Store و Google Play این موضوع را در مرحله بررسی تأیید می‌کنند.

چرا TLS برای برنامه‌های موبایل ضروری است

بدون TLS، ترافیک بین برنامه و سرور به صورت متن ساده منتقل می‌شود — هر کسی در همان شبکه Wi-Fi می‌تواند با استفاده از Wireshark یا tcpdump نام‌های کاربری، رمزهای عبور، توکن‌ها و داده‌های شخصی کاربران را رهگیری کند. TLS تمام داده‌های منتقل شده را رمزگذاری می‌کند (رمزنگاری در سطح حمل‌ونقل) و اصالت سرور را از طریق زنجیره گواهی‌های X.509 تأیید می‌کند. به گفته IETF (2018)، TLS 1.3 فقط از رمزنگارهای مدرن AEAD (AES-GCM، ChaCha20-Poly1305) استفاده می‌کند و الگوریتم‌های منسوخ مانند RC4 و 3DES را حذف می‌کند.

HTTPS و TLS

HTTPS (HTTP Secure) — HTTP از طریق TLS است. وقتی برنامه موبایل درخواستی را از طریق https:// ارسال می‌کند، ابتدا یک اتصال TLS با سرور برقرار می‌کند و سپس هدرهای HTTP و بدنه درخواست را از طریق کانال رمزگذاری شده منتقل می‌کند. بدون HTTPS هیچ API جدی نباید کار کند — این بهداشت پایه امنیتی است. به گفته OWASP (2026)، اتصالات ناامن در بین 3 آسیب‌پذیری برتر برنامه‌های موبایل قرار دارند.

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

TLS Handshake — فرآیند برقراری اتصال امن بین کلاینت و سرور است. طرفین نسخه پروتکل را توافق می‌کنند، مجموعه رمزنگار (cipher suite) را انتخاب می‌کنند، کلیدها را از طریق رمزنگاری نامتقارن مبادله می‌کنند و گواهی‌ها را تأیید می‌کنند. در TLS 1.2 دست‌دهی به 2 Round Trip Time (2 RTT) نیاز دارد: کلاینت → سرور با ClientHello، سرور → کلاینت با ServerHello و Certificate، سپس پیام‌های نهایی Finished. TLS 1.3 این فرآیند را به 1 RTT کاهش می‌دهد.

مراحل دقیق دست‌دهی TLS 1.2

مرحله اول: ClientHello — کلاینت نسخه‌های TLS پشتیبانی شده، لیست مجموعه رمزنگارها و یک عدد تصادفی را ارسال می‌کند. سرور با ServerHello پاسخ می‌دهد، نسخه و مجموعه رمزنگار را انتخاب می‌کند، گواهی X.509 خود (Certificate) و پیام ServerHelloDone را ارسال می‌کند. کلاینت گواهی را از طریق زنجیره مراکز صدور گواهی معتبر (CA) تأیید می‌کند، pre-master secret تولید می‌کند، آن را با کلید عمومی موجود در گواهی رمزگذاری می‌کند و در ClientKeyExchange به سرور ارسال می‌کند. پس از آن، هر دو طرف کلیدهای جلسه را تولید کرده و پیام‌های ChangeCipherSpec و Finished را مبادله می‌کنند. از این لحظه به بعد، تمام داده‌ها به صورت متقارن رمزگذاری می‌شوند.

import Security

let url = URL(string: "https://api.example.com")!
let session = URLSession(configuration: .default,
                           delegate: self,
                           delegateQueue: nil)

func urlSession(
    _ session: URLSession,
    didReceive challenge: URLAuthenticationChallenge,
    completionHandler: @escaping (URLSession.AuthChallengeDisposition,
                                    URLCredential?) -> Void
) {
    let trust = challenge.protectionSpace.serverTrust
    guard let trust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    completionHandler(.useCredential, URLCredential(trust: trust))
}

نمونه پردازش URLAuthenticationChallenge در iOS از طریق URLSessionDelegate. این متد در هر TLS Handshake فراخوانی می‌شود و به برنامه اجازه می‌دهد گواهی سرور را به صورت سفارشی بررسی کند. برای استفاده تولید، بررسی گواهی را از طریق SecTrustEvaluateWithError اضافه کنید و با اثر انگشت از پیش ذخیره شده مقایسه کنید — فقط پس از آن useCredential را فراخوانی کنید.

TLS 1.2 در مقابل TLS 1.3

TLS 1.3 (RFC 8446، 2018) — اولین به‌روزرسانی بزرگ پروتکل در 10 سال گذشته است. بهبودهای اصلی: دست‌دهی به 1 RTT کاهش یافته (0 RTT برای اتصالات مجدد)، مجموعه رمزنگارهای منسوخ (RSA key exchange، CBC-mode) حذف شده، رمزنگاری پیشرو اجباری (PFS) و محافظت در برابر حملات downgrade از طریق signed transcript. به گفته Qualys SSL Labs (2026)، TLS 1.3 به لطف PFS حتی در صورت به خطر افتادن کلید بلندمدت سرور نیز محافظت را تضمین می‌کند.

0-RTT (Zero Round Trip Time) — ویژگی TLS 1.3 که به کلاینت اجازه می‌دهد در اتصالات مجدد از طریق PSK (Pre-Shared Key) بلافاصله همراه با ClientHello داده ارسال کند. این کار بارگذاری صفحات بعدی در برنامه‌های موبایل را تسریع می‌کند، به ویژه هنگام درخواست‌های مکرر به یک سرور. با این حال، داده‌های 0-RTT در برابر حملات replay محافظت نمی‌شوند — می‌توان آنها را رهگیری و مجدداً ارسال کرد. از 0-RTT فقط برای درخواست‌های ایدمپوتنت (GET، PUT) بدون عوارض جانبی استفاده کنید.

TLS در iOS: App Transport Security

App Transport Security (ATS) — مکانیزم اپل که اتصالات HTTPS با TLS 1.2 یا بالاتر را الزامی می‌کند و از iOS 9 به طور پیش‌فرض فعال است. ATS تمام اتصالات HTTP و HTTPS با TLS پایین‌تر از 1.2 را مسدود می‌کند. توسعه‌دهنده می‌تواند استثناهایی را در Info.plist از طریق NSAppTransportSecurity برای دامنه‌های خاص پیکربندی کند، اما اپل توصیه می‌کند استثناها را به حداقل برسانید و در همه جا از HTTPS استفاده کنید. نقض الزامات ATS دلیلی برای رد برنامه در بررسی App Store است.

<!-- Info.plist — App Transport Security -->
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <false/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>cdn.example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
        </dict>
    </dict>
    <key>NSAllowsLocalNetworking</key>
    <true/>
</dict>

پیکربندی ATS در Info.plist. NSAllowsArbitraryLoads روی false تنظیم شده — همه اتصالات باید از HTTPS استفاده کنند. برای دامنه cdn.example.com حداقل نسخه TLS 1.2 تنظیم شده، NSAllowsLocalNetworking=true به HTTP برای شبکه محلی اجازه می‌دهد (برای سرورهای توسعه مفید است). اپل اکیداً توصیه می‌کند NSAllowsArbitraryLoads را بدون NSExceptionDomains فعال نکنید — این باید یک استثنا باشد، نه یک قانون کلی.

TLS در Android: Network Security Config

Network Security Config — مکانیزم اندروید برای پیکربندی HTTPS و TLS بدون تغییر کد Java/Kotlin. پیکربندی در فایل XML network_security_config.xml تعریف می‌شود و در AndroidManifest از طریق ویژگی android:networkSecurityConfig متصل می‌شود. از پیکربندی گواهی‌های معتبر (user و system CA)، Certificate Pinning، غیرفعال کردن HTTP متن ساده، بازنویسی‌های debug و هدایت ترافیک پشتیبانی می‌کند.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-01-01">
            <pin digest="SHA-256">
                47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
            </pin>
        </pin-set>
    </domain-config>
</network-security-config>

Network Security Config برای اندروید. Base-config ترافیک متن ساده را ممنوع می‌کند و فقط به گواهی‌های سیستم CA اعتماد می‌کند (بدون گواهی کاربر — محافظت در برابر نصب گواهی‌های MitM توسط کاربر). Domain-config برای api.example.com شامل pin-set با اثر انگشت SHA-256 گواهی است. اگر گواهی سرور قبل از تاریخ انقضای مشخص شده تغییر کند، اتصال رد می‌شود — این شکل سخت‌گیرانه Certificate Pinning است.

Certificate Pinning و امنیت

Certificate Pinning — تکنیک تثبیت گواهی یا کلید عمومی سرور در کد برنامه است. در هر TLS Handshake، کلاینت گواهی سرور را با اثر انگشت از پیش ذخیره شده (هش SHA-256) مقایسه می‌کند. حتی اگر مهاجم یک گواهی CA معتبر به دست آورد یا مرکز صدور گواهی را به خطر بیندازد، نمی‌تواند حمله MitM انجام دهد — برنامه اثر انگشت خاص را بررسی می‌کند، نه زنجیره CA. این به ویژه برای برنامه‌های مالی و برنامه‌های دارای داده‌های حساس مهم است.

ریسک‌ها و جایگزین‌های Pinning

Certificate Pinning نیاز به احتیاط دارد: هنگام تغییر گواهی روی سرور، تمام نسخه‌های قدیمی برنامه قادر به اتصال نخواهند بود. توصیه می‌شود چند اثر انگشت ذخیره (اصلی + پشتیبان) نگهداری کنید، تاریخ انقضای pin-set را مشخص کنید و یک مکانیزم fallback از طریق تأیید استاندارد CA پیاده‌سازی کنید. جایگزین — Trust On First Use (TOFU)، زمانی که برنامه گواهی را در اولین اتصال ذخیره می‌کند و در صورت تغییر آن به کاربر هشدار می‌دهد. به گفته OWASP (2026)، فقدان Certificate Pinning در بین 3 آسیب‌پذیری برتر برنامه‌های موبایل (M3: Insecure Communication) قرار دارد.

پیاده‌سازی Pinning در Alamofire

در Alamofire 5+، Certificate Pinning از طریق ServerTrustManager با PinnedCertificatesTrustEvaluator (بررسی کل گواهی) یا PublicKeysTrustEvaluator (فقط کلید عمومی) پیکربندی می‌شود. کلید عمومی ترجیح داده می‌شود — با به‌روزرسانی گواهی در همان CA تغییر نمی‌کند. یک ServerTrustManager با دیکشنری [host: evaluator] ایجاد کنید، آن را به Session منتقل کنید و برای همه درخواست‌ها به APIهای محافظت شده استفاده کنید.