SSL/TLS: المفاهيم الأساسية والبروتوكولات في التطوير

ما هو SSL/TLS؟

SSL (طبقة المقابس الآمنة) و TLS (أمان طبقة النقل) هما بروتوكولان تشفيران يضمنان نقل البيانات بشكل آمن عبر الشبكة. SSL، الذي طورته Netscape في التسعينيات، يُعتبر قديمًا بعد الإصدار 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 الآمن) هو HTTP فوق TLS. عندما يقوم تطبيق محمول بطلب عبر https://، يقوم أولاً بإنشاء اتصال TLS مع الخادم، ثم ينقل رؤوس HTTP وجسم الطلب عبر القناة المشفرة. بدون HTTPS، لا يجب أن تعمل أي واجهة برمجة تطبيقات جادة — هذه هي النظافة الأساسية للأمان. وفقًا لـ OWASP (2026)، فإن الاتصالات غير الآمنة تدخل ضمن أفضل 3 ثغرات في التطبيقات المحمولة.

كيف تعمل مصافحة TLS

مصافحة TLS هي عملية إنشاء اتصال آمن بين العميل والخادم. يتفاوض الطرفان على إصدار البروتوكول، ويختاران مجموعة التشفير (cipher suite)، ويتبادلان المفاتيح عبر التشفير غير المتماثل، ويتحققان من الشهادات. في TLS 1.2، تتطلب المصافحة جولتي اتصال (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، مما يسمح للتطبيق بالتحقق المخصص من شهادة الخادم. للاستخدام في الإنتاج، أضف التحقق من الشهادة عبر SecTrustEvaluateWithError وقارنها ببصمة محفوظة مسبقًا — فقط بعد ذلك قم باستدعاء useCredential.

TLS 1.2 مقابل TLS 1.3

TLS 1.3 (RFC 8446, 2018) هو أول تحديث رئيسي للبروتوكول منذ 10 سنوات. التحسينات الرئيسية: تقليل المصافحة إلى 1 RTT (0 RTT للاتصالات المتكررة)، إزالة مجموعات التشفير القديمة (تبادل مفاتيح RSA، وضع CBC)، السرية التامة للأمام (PFS) الإجبارية، والحماية من هجمات خفض المستوى عبر signed transcript. وفقًا لـ Qualys SSL Labs (2026)، يوفر TLS 1.3 الحماية حتى عند اختراق مفتاح الخادم طويل الأمد بفضل PFS.

0-RTT (زمن الرحلة الصفرية) هي ميزة في TLS 1.3 تسمح للعميل بإرسال البيانات فورًا مع ClientHello أثناء الاتصال المتكرر عبر PSK (المفتاح المشترك مسبقًا). هذا يسرع تحميل الشاشات اللاحقة في التطبيقات المحمولة، خاصة عند الطلبات المتكررة لنفس الخادم. ومع ذلك، فإن بيانات 0-RTT ليست محمية ضد هجمات إعادة التشغيل (replay attacks) — يمكن اعتراضها وإعادة إرسالها. استخدم 0-RTT فقط للطلبات غير المؤثرة (GET, PUT) بدون آثار جانبية.

TLS على iOS: App Transport Security

App Transport Security (ATS) هي آلية Apple التي تتطلب اتصالات HTTPS مع TLS 1.2 أو أعلى، مُفعّلة افتراضيًا منذ iOS 9. يحظر ATS جميع اتصالات HTTP و HTTPS مع TLS أقل من 1.2. يمكن للمطور تكوين استثناءات في Info.plist عبر NSAppTransportSecurity لنطاقات محددة، لكن Apple توصي بتقليل الاستثناءات واستخدام 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 للشبكة المحلية (مفيد لخوادم التطوير). توصي Apple بشدة بعدم تفعيل NSAllowsArbitraryLoads بدون NSExceptionDomains — يجب أن يكون هذا استثناءً وليس قاعدة عامة.

TLS على Android: Network Security Config

Network Security Config هي آلية Android لتكوين HTTPS و TLS دون تغيير كود Java/Kotlin. يتم تحديد التكوين في ملف network_security_config.xml ويتم توصيله في AndroidManifest عبر السمة android:networkSecurityConfig. يدعم تكوين الشهادات الموثوقة (CA للمستخدم والنظام)، و Certificate Pinning، وتعطيل HTTP بنص واضح، وتجاوزات التصحيح، وإعادة توجيه حركة المرور.

<!-- 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 لنظام Android. يقوم base-config بحظر حركة المرور بنص واضح ويثق فقط بشهادات CA النظام (بدون شهادات المستخدم — حماية من تثبيت شهادات MitM من قبل المستخدمين). يحتوي domain-config لـ api.example.com على pin-set مع بصمة SHA-256 للشهادة. إذا تغيرت شهادة الخادم قبل تاريخ انتهاء الصلاحية المحدد، سيتم رفض الاتصال — هذا شكل صارم من Certificate Pinning.

Certificate Pinning والأمان

Certificate Pinning هي تقنية تثبيت الشهادة أو المفتاح العام للخادم في كود التطبيق. خلال كل مصافحة TLS، يقارن العميل شهادة الخادم مع بصمة محفوظة مسبقًا (hash SHA-256). حتى إذا حصل المهاجم على شهادة CA موثوقة أو اخترق مركز التصديق، لا يمكنه تنفيذ هجوم MitM — يتحقق التطبيق من البصمة المحددة، وليس سلسلة CA. هذا مهم بشكل خاص للتطبيقات المالية والتطبيقات التي تتعامل مع بيانات حساسة.

المخاطر والبدائل للتثبيت (Pinning)

Certificate Pinning يتطلب الحذر: عندما تتغير شهادة الخادم، ستتوقف جميع الإصدارات القديمة من التطبيق عن الاتصال. يُوصى بتخزين عدة بصمات احتياطية (أساسية + احتياطية)، وتحديد تاريخ انتهاء صلاحية pin-set، وتنفيذ آلية احتياطية عبر التحقق القياسي من CA. البديل هو الثقة عند أول استخدام (TOFU)، حيث يتذكر التطبيق الشهادة عند أول اتصال ويحذر المستخدم عند تغييرها. وفقًا لـ OWASP (2026)، فإن غياب Certificate Pinning يدخل ضمن أفضل 3 ثغرات في التطبيقات المحمولة (M3: اتصال غير آمن).

تنفيذ Pinning في Alamofire

في Alamofire 5+، يتم تكوين Certificate Pinning عبر ServerTrustManager مع PinnedCertificatesTrustEvaluator (التحقق من الشهادة بالكامل) أو PublicKeysTrustEvaluator (المفتاح العام فقط). المفتاح العام مفضل — لا يتغير عند تجديد الشهادة مع نفس CA. قم بإنشاء ServerTrustManager مع قاموس [host: evaluator]، مرره إلى Session، واستخدمه لجميع الطلبات إلى واجهات برمجة التطبيقات المحمية.