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