SSL Pinning: същност, механизъм и защита от MITM атаки

Какво е SSL Pinning?

SSL Pinning — механизъм за сигурност, при който мобилно или уеб приложение запомня доверен сертификат или публичен ключ на сървъра и отказва всякакви връзки, чийто сертификат не съвпада с запазения. В стандартната HTTPS схема клиентът проверява сертификата чрез веригата на доверие до кореновия CA — всеки CA може да подпише сертификат за всеки домейн. SSL Pinning премахва тази слабост: вместо да се доверява на стотици CA, приложението се доверява само на един конкретен сертификат.

Проблемът на стандартната проверка е, че всеки от стотиците коренови CA може да издаде валиден сертификат за вашия домейн — случайно или под принуда. Нападател, получил достъп до корпоративен прокси със собствен коренов сертификат, може да извърши MITM атака без предупреждение от браузъра. SSL Pinning затваря тази уязвимост: дори ако CA издаде подменен сертификат, приложението ще го отхвърли, тъй като отпечатъкът не съвпада с записания.

В мобилните приложения SSL Pinning е особено важен, тъй като устройствата често работят в незащитени мрежи — обществен Wi-Fi, корпоративни проксита с инспекция на трафика, заразени точки за достъп. Според Verizon Mobile Security Index (2025), над 60% от изтичанията на данни в мобилните приложения са свързани с прихващане на трафик на транспортно ниво.

Защо е необходим SSL Pinning в мобилната разработка

Мобилните приложения предават чувствителни данни — токени за удостоверяване, платежна информация, лични данни на потребителите. Без допълнителна защита, HTTPS може да бъде компрометиран чрез подмяна на кореновия сертификат на устройството — например след инсталиране на корпоративен профил или зловредно приложение. SSL Pinning гарантира, че дори ако на устройството е инсталиран подменен коренов CA, приложението ще продължи да проверява сертификата според собствения си бял списък.

Как работи SSL Pinning?

Процесът на SSL Pinning се състои от три етапа: получаване на отпечатък, проверка при свързване и обработка на грешка. На етапа на разработка инженерът получава SHA-256 отпечатък на сертификата на сървъра (openssl x509 -fingerprint -sha256) и го вгражда в кода на приложението или конфигурационния файл. При всяка HTTPS заявка приложението изчислява отпечатъка на получения сертификат и го сравнява със запазения — ако стойностите не съвпадат, връзката се прекъсва.

Първи етап — pinning на етапа на изграждане: разработчикът предварително знае сертификатите на сървъра и вгражда техните хешове. Втори етап — pinning при първата връзка (trust on first use, TOFU): приложението запомня сертификата при първата заявка и го използва за проверка на всички последващи. TOFU е удобен за динамични среди, но е уязвим при първата атака — ако първата връзка вече е прихваната, подмененият сертификат ще бъде приет като доверен.

Критичен детайл — резервни отпечатъци (backup pins). Сертификатите имат срок на валидност и при тяхната смяна неактуализираното приложение губи връзка със сървъра. Инженерите добавят 2–3 допълнителни отпечатъка — например отпечатък на резервния сертификат и отпечатък на кореновия CA. Ако основният сертификат се промени, приложението проверява според backup pins и връзката продължава да работи.

# Получаване на SHA-256 отпечатък на сертификата
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | \
  openssl x509 -pubkey -noout | \
  openssl pkey -pubin -outform der | \
  openssl dgst -sha256 -binary | \
  base64

Видове SSL Pinning

Съществуват два основни подхода за реализация на pinning: свързване към целия сертификат (certificate pinning) и свързване към публичния ключ (public key pinning). Всеки подход има своите силни страни и ограничения, които влияят на сигурността и леснотата на поддръжка.

Certificate Pinning

Свързване към сертификат — най-строгият метод. Приложението съхранява копие на доверения сертификат или неговия SHA-256 отпечатък и го сравнява със сертификата на сървъра при всяка HTTPS връзка. Този метод осигурява максимална сигурност, но създава проблеми при ротация — сертификатите обикновено важат 1–2 години, след което се изисква принудително актуализиране на приложението. Препоръчва се за критични системи с контролиран цикъл на актуализация.

Public Key Pinning

Фиксация на публичния ключ — по-гъвкав подход. Вместо целия сертификат, приложението запомня само публичния RSA или ECDSA ключ на сървъра. Ключът може да остане непроменен при преиздаване на сертификата, ако компанията използва същата ключова двойка. Това намалява честотата на актуализации на приложението. Въпреки това, ако ключът бъде компрометиран, ще се изисква каскадна подмяна при всички клиенти.

SSL Pinning на iOS

На платформата Apple SSL Pinning се реализира чрез делегат на URLSession. Разработчикът създава клас, който имплементира протокола URLSessionDelegate, и презаписва метода didReceive challenge, където ръчно проверява сертификата на сървъра срещу запазените отпечатъци. Алтернативен подход — използване на Alamofire с ServerTrustManager, който опростява конфигурацията.

class SSLPinningDelegate: NSObject, URLSessionDelegate {
    let pinnedHash = "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg="

    func urlSession(_ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {

        guard let serverTrust = challenge.protectionSpace.serverTrust
            else { return completionHandler(.cancelAuthenticationChallenge, nil) }

        if validate(serverTrust, pinnedHash) {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

В примера делегатът получава заявка за удостоверяване от URLSession, извлича serverTrust от challenge и сравнява SHA-256 отпечатъка на сертификата със запазения. Ако отпечатъкът съвпада — връзката продължава, в противен случай challenge се отхвърля. За производствена среда си струва да добавите проверка на няколко backup pins и регистриране на грешки за мониторинг.

Network Security Config на iOS

От iOS 14 нататък Apple добави вградена поддръжка за Certificate Pinning чрез Info.plist. Разработчикът посочва доверени сертификати в ключа NSAppTransportSecurity с подречник NSPinnedDomains. Този подход не изисква писане на код, но е по-малко гъвкав — не можете динамично да променяте pin-овете или да регистрирате грешки при проверка.

SSL Pinning на Android

На Android съществуват три основни начина за реализация на SSL Pinning: чрез CertificatePinner на библиотеката OkHttp, чрез Network Security Config в XML и чрез персонализирана проверка в HttpsURLConnection. OkHttp — най-популярният и препоръчителен подход, използван в Retrofit и други HTTP клиенти.

val certificatePinner = CertificatePinner.Builder()
    .add("api.example.com",
        "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=")
    .add("api.example.com",
        "sha256/FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=")  // резервен pin
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

В конфигурацията на OkHttp разработчикът посочва домейна и един или повече SHA-256 отпечатъка. При първия отпечатък OkHttp сравнява сертификата на сървъра с посочените pin-ове. Ако няма съвпадение, клиентът хвърля SSLPeerUnverifiedException. Резервният pin е задължителен — без него при смяна на сертификата API заявките веднага ще започнат да се провалят.

Network Security Configuration на Android

Android поддържа декларативен Certificate Pinning чрез XML конфигурация от API 24. Файлът res/xml/network_security_config.xml съдържа списък с домейни и техните отпечатъци. Този метод е удобен за статични конфигурации, но не позволява реализация на TOFU или персонализирана логика за проверка с регистриране на аномалии.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">
                Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=</pin>
            <pin digest="SHA-256">
                FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Предимства и недостатъци на SSL Pinning

SSL Pinning значително повишава сигурността на мобилното приложение, но въвежда оперативна сложност. Основното предимство — защита от MITM атаки дори при компрометиране на коренови CA. Приложението се доверява само на сертификати, изрично посочени от разработчика, а не на цялата инфраструктура на публични центрове за сертификация. Това е особено критично за финансови приложения, месинджъри и приложения с чувствителни данни.

Основният недостатък — сложността на ротация на сертификати. Ако сертификат изтече или бъде отменен, потребителите без актуализация на приложението губят връзка. Решава се чрез резервни pin-ове и механизъм за постепенна актуализация: новото приложение познава стария и новия сертификат, а след пълното актуализиране на потребителите старият pin се премахва от кода. Препоръчва се минимум 2 резервни pin-а — един за текущия сертификат, един за бъдещия.

Друг компромис — невъзможността да се използват публични проксита за отстраняване на грешки в трафика (Charles Proxy, Burp Suite) без изключване на pinning. Това затруднява отстраняването на грешки на мрежови заявки на етапа на разработка. Решение — условна компилация: в debug компилацията pinning е изключен, в release — включен. OWASP препоръчва използване на флага BuildConfig.DEBUG за превключване.