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-trip обиколки на една, което е критично за мобилни приложения с нестабилна връзка.

Как работи 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 заявките често се пропускат за ускоряване на връзката — това е компромис между сигурност и производителност, който архитектите трябва да вземат предвид.

SSL срещу TLS: ключови разлики

Въпреки че термините SSL и TLS често се използват като синоними, между тях съществуват принципни технически разлики, които влияят на сигурността и производителността на мобилните приложения.

Основната разлика на TLS 1.3 от предшествениците — задължителното използване на Perfect Forward Secrecy (PFS) чрез протокола ECDHE. Това означава, че дори ако нападател получи достъп до частния ключ на сървъра, той няма да може да дешифрира предварително прихванатия трафик. За мобилни приложения, където хакването на сървъра е реална заплаха, TLS 1.3 с PFS е задължително изискване за сигурност.

Известни уязвимости на старите версии

Остарелите версии на SSL и TLS имат документирани уязвимости, които ги правят неподходящи за продукционна употреба. POODLE (CVE-2014-3566) атакува SSL 3.0 чрез padding oracle, позволявайки дешифриране на сесийната бисквитка за 256 заявки. BEAST (CVE-2011-3389) експлоатира уязвимостта на TLS 1.0 в CBC режим чрез предвидим IV. Heartbleed (CVE-2014-0160) — не е уязвимост на протокола, а грешка в имплементацията на OpenSSL, позволяваща четене на сървърната памет: според Netcraft през 2014 г. над 500 хиляди сървъра са били уязвими. От Android 10 (API 29) и iOS 13 нататък всички изброени протоколи са деактивирани на системно ниво. Въпреки това, разработчиците трябва да проверят конфигурацията на сървъра чрез SSL Labs Test (qualys.com) преди стартиране на приложението, за да се уверят, че няма остарели cipher suites и че TLS 1.3 се поддържа.

Как SSL/TLS защитава данните в мобилните приложения

В мобилните приложения TLS защитава данните на три нива: криптиране на съдържанието (никой освен сървъра не може да чете данните), проверка на целостта (данните не могат да бъдат променени по пътя) и удостоверяване на сървъра (клиентът е сигурен, че се свързва с правилния сървър). Удостоверяването е особено критично: без него нападател може да подмени сървъра чрез DNS-spoofing или фалшива Wi-Fi точка за достъп.

Според изследване на Google Play Protect (2024) 76% от Android приложенията използват TLS правилно с проверка на сертификати. Останалите 24% допускат грешки: изключват проверката на сертификати за тестване (и забравят да я включат в продукция), използват самоподписани сертификати без валидиране или разрешават остарели протоколи SSL 3.0 и TLS 1.0. Apple App Transport Security (ATS) в iOS изисква най-малко TLS 1.2 от 2017 г., а от iOS 15 използва по подразбиране TLS 1.3 за всички мрежови заявки. За допълнителна защита се препоръчва и внедряване на Certificate Pinning — привързване към конкретен сървърен сертификат.

Имплементация на SSL/TLS в мобилни приложения

Нека разгледаме пример за конфигуриране на защитена HTTPS връзка в Android с помощта на OkHttp — една от най-популярните библиотеки за работа с мрежа. Правилната конфигурация включва принудително използване на TLS 1.3 и проверка на сертификати.

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

В този пример ограничаваме набора от поддържани TLS версии само до протоколи 1.3 и 1.2, като изключваме остарелите TLS 1.0/1.1. Cipher suites се избират от съвременни алгоритми с AEAD режим и задължителна Perfect Forward Secrecy. HostnameVerifier проверява съответствието на името на хоста със сертификата. За iOS аналогична конфигурация се извършва чрез конфигуриране на URLSession с параметъра tlsMinimumSupportedProtocolVersion, където се посочва .TLSv13. Допълнително в iOS може да се зададе tlsMaximumSupportedProtocolVersion за ограничаване на горната граница на версиите — това е полезно за съвместимост с по-стари сървъри, които все още не са преминали към TLS 1.3. Такава конфигурация гарантира максимално ниво на сигурност при предаване на данни в мобилното приложение.