SSL/TLS: ключови понятия и протоколи в програмирането

Какво е SSL/TLS?

SSL (Secure Sockets Layer) и TLS (Transport Layer Security) — криптографски протоколи, осигуряващи сигурно предаване на данни по мрежата. SSL, разработен от Netscape през 90-те години, беше обявен за остарял след версия 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 ръкостискането

TLS ръкостискане — процес на установяване на сигурна връзка между клиент и сървър. Страните договарят версията на протокола, избират криптографски набор (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 ръкостискане, позволявайки на приложението да провери персонализирано сертификата на сървъра. За продуктивна употреба добавете проверка на сертификата чрез SecTrustEvaluateWithError и сравнете с предварително запазения отпечатък — едва след това извикайте useCredential.

TLS 1.2 срещу TLS 1.3

TLS 1.3 (RFC 8446, 2018) — първата голяма актуализация на протокола от 10 години. Основни подобрения: ръкостискането е намалено до 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, изключване на некриптиран 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 забранява некриптиран трафик и се доверява само на системни CA сертификати (без потребителски — защита срещу инсталиране на MitM сертификати от потребителя). Domain-config за api.example.com съдържа pin-set с SHA-256 отпечатък на сертификата. Ако сървърният сертификат се промени преди посочената дата на изтичане, връзката ще бъде отхвърлена — това е строга форма на Certificate Pinning.

Certificate Pinning и сигурност

Certificate Pinning — техника за фиксиране на сертификата или публичния ключ на сървъра в кода на приложението. При всяко TLS ръкостискане клиентът сравнява сървърния сертификат с предварително запазения отпечатък (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-та.