SSL/TLS — что это, протоколы и принцип работы шифрования

Что такое SSL/TLS?

SSL (Secure Sockets Layer) — это протокол, разработанный компанией Netscape в 1995 году для защиты веб-трафика. Первая версия SSL 1.0 никогда не публиковалась, SSL 2.0 (1995) и SSL 3.0 (1996) использовались до начала 2000-х, но содержали критические уязвимости. На смену SSL пришёл TLS (Transport Layer Security) — улучшенная версия, стандартизированная IETF. TLS 1.0 (1999) был основан на SSL 3.0, а последующие версии TLS 1.1 (2006), TLS 1.2 (2008) и TLS 1.3 (2018) постепенно отходили от оригинальной архитектуры, добавляя новые алгоритмы шифрования и устраняя уязвимости. Сегодня SSL считается устаревшим, и все современные системы используют TLS, хотя по инерции оба протокола часто упоминаются вместе как SSL/TLS.

История создания протокола

История SSL/TLS началась с потребности в безопасной передаче данных в раннем вебе. В 1994 году компания Netscape разработала SSL 1.0 для своего браузера Navigator, но протокол никогда не был опубликован из-за серьёзных проблем безопасности. SSL 2.0 вышел в 1995 году и использовался на практике, однако содержал множество уязвимостей: отсутствие защиты от Man-in-the-Middle, слабые алгоритмы шифрования и уязвимость к truncation-атакам. SSL 3.0 (1996) исправил большинство проблем, но к 2014 году в нём была обнаружена уязвимость POODLE, после чего IETF официально объявила все версии SSL устаревшими. TLS 1.0–1.3 последовательно улучшали криптографическую стойкость, производительность и конфиденциальность, причём TLS 1.3 сократил handshake с двух round-trips до одного, что критически важно для мобильных приложений с нестабильным соединением.

Как работает SSL/TLS Handshake

Handshake — это процесс установки защищённого соединения между клиентом и сервером. Он состоит из нескольких последовательных шагов, в ходе которых стороны согласовывают версию протокола, выбирают алгоритмы шифрования, обмениваются ключами и аутентифицируют друг друга. В TLS 1.3 handshake занимает всего одно сетевое взаимодействие (1-RTT), в то время как в TLS 1.2 требовалось два (2-RTT).

Первым шагом клиент отправляет ClientHello — сообщение, содержащее список поддерживаемых версий TLS, набор шифров (cipher suites) и случайное число. Сервер отвечает ServerHello с выбранной версией и шифром, своим сертификатом X.509 и цифровой подписью. Клиент проверяет сертификат через цепочку центров сертификации (CA), генерирует сессионный ключ и отправляет его, зашифрованный открытым ключом сервера из сертификата. После подтверждения сервером начинается защищённая передача данных. Весь handshake выполняется за 1–3 миллисекунды на современных устройствах, что делает его незаметным для пользователя.

Сертификаты 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-запросы часто пропускаются для ускорения соединения — это компромисс между безопасностью и производительностью, который следует учитывать архитекторам.

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()