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, дозволяючи додатку кастомно перевірити сертифікат сервера. Для production-використання додайте перевірку сертифіката через SecTrustEvaluateWithError та порівнюйте з попередньо збереженим відбитком — лише після цього викликайте useCredential.

TLS 1.2 проти TLS 1.3

TLS 1.3 (RFC 8446, 2018) — перше велике оновлення протоколу за 10 років. Основні покращення: handshake скорочено до 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, що дозволяє клієнту надсилати дані одразу разом із ClientHello при повторному з’єднанні через PSK (Pre-Shared Key). Це прискорює завантаження наступних екранів у мобільних додатках, особливо при частих запитах до одного сервера. Однак дані 0-RTT не захищені від replay-атак — їх можна перехопити та відправити повторно. Використовуйте 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 для локальної мережі (корисно для dev-серверів). Apple наполегливо рекомендує не вмикати NSAllowsArbitraryLoads без NSExceptionDomains — це має бути виняток, а не загальне правило.

TLS на Android: Network Security Config

Network Security Config — механізм Android для налаштування HTTPS та TLS без зміни коду Java/Kotlin. Конфігурація задається в XML-файлі network_security_config.xml і підключається в AndroidManifest через атрибут android:networkSecurityConfig. Підтримує налаштування довірених сертифікатів (user та system CA), Certificate Pinning, відключення cleartext 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 для Android. Base-config забороняє cleartext-трафік і довіряє лише системним CA-сертифікатам (без користувацьких — захист від встановлення MitM-сертифікатів користувачем). Domain-config для api.example.com містить pin-set з SHA-256 відбитком сертифіката. Якщо сертифікат сервера зміниться до вказаної дати expiration, з’єднання буде відхилено — це жорстка форма 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.