SSL/TLS: кључни појмови и протоколи у програмирању

Шта је SSL/TLS?

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