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.