SSL/TLS: mahahalagang konsepto at protokol sa programming

Ano ang SSL/TLS?

SSL (Secure Sockets Layer) at TLS (Transport Layer Security) — mga cryptographic protocol na ginagarantiyahan ang ligtas na pagpapadala ng data sa network. SSL, na binuo ng Netscape noong 1990s, ay idineklarang luma na pagkatapos ng bersyon 3.0 dahil sa mga kahinaan ng POODLE at BEAST. TLS, ang kahalili nito, ay dumaan sa mga bersyon 1.0, 1.1, 1.2, at 1.3 — kasalukuyang TLS 1.2 at TLS 1.3 lamang ang itinuturing na napapanahon. Lahat ng modernong mobile platform ay nangangailangan ng paggamit ng TLS para sa mga koneksyon sa network, at sinusuri ito ng App Store at Google Play sa yugto ng pagsusuri.

Bakit kailangan ng TLS ang mga mobile app

Kung walang TLS, ang trapiko sa pagitan ng app at server ay ipinapadala bilang plain text — kahit sino sa parehong Wi-Fi network ay maaaring humarang ng mga username, password, token, at personal na data ng mga user gamit ang Wireshark o tcpdump. Nire-encrypt ng TLS ang lahat ng ipinadalang data (encryption sa antas ng transport) at bini-verify ang pagiging tunay ng server sa pamamagitan ng chain ng X.509 certificates. Ayon sa IETF (2018), ang TLS 1.3 ay gumagamit lamang ng mga modernong AEAD cipher (AES-GCM, ChaCha20-Poly1305), hindi kasama ang mga lumang algorithm tulad ng RC4 at 3DES.

HTTPS at TLS

HTTPS (HTTP Secure) — ay HTTP sa pamamagitan ng TLS. Kapag ang isang mobile app ay gumawa ng kahilingan sa pamamagitan ng https://, una itong nagtatag ng TLS connection sa server, pagkatapos ay nagpapadala ng HTTP headers at body ng kahilingan sa pamamagitan ng naka-encrypt na channel. Kung walang HTTPS, walang seryosong API ang dapat gumana — ito ang pangunahing kalinisan sa seguridad. Ayon sa OWASP (2026), ang mga hindi secure na koneksyon ay nasa top 3 na kahinaan ng mga mobile app.

Paano gumagana ang TLS Handshake

TLS Handshake — proseso ng pagtatag ng secure na koneksyon sa pagitan ng client at server. Ang mga partido ay nagkakasundo sa bersyon ng protocol, pumipili ng cipher suite, nagpapalitan ng mga key sa pamamagitan ng asymmetric cryptography, at nagbe-verify ng mga certificate. Sa TLS 1.2, ang handshake ay nangangailangan ng 2 Round Trip Time (2 RTT): client → server na may ClientHello, server → client na may ServerHello at Certificate, pagkatapos ay ang mga huling mensaheng Finished. Binabawasan ng TLS 1.3 ang prosesong ito sa 1 RTT.

Mga detalyadong yugto ng TLS 1.2 handshake

Unang yugto: ClientHello — ipinapadala ng client ang mga suportadong TLS version, listahan ng cipher suite, at random na numero. Tumutugon ang server ng ServerHello, pumipili ng bersyon at cipher suite, ipinapadala ang X.509 certificate nito (Certificate) at ang ServerHelloDone na mensahe. Bini-verify ng client ang certificate sa pamamagitan ng chain ng mga pinagkakatiwalaang certification authority (CA), bumubuo ng pre-master secret, ine-encrypt ito gamit ang pampublikong key mula sa certificate, at ipinapadala ito sa server sa ClientKeyExchange. Pagkatapos nito, ang parehong partido ay bumubuo ng session key at nagpapalitan ng ChangeCipherSpec at Finished na mga mensahe. Mula sa sandaling ito, lahat ng data ay symmetrically naka-encrypt.

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

Halimbawa ng paghawak ng URLAuthenticationChallenge sa iOS sa pamamagitan ng URLSessionDelegate. Ang pamamaraang ito ay tinatawag sa bawat TLS Handshake, na nagpapahintulot sa app na i-customize ang pag-verify ng server certificate. Para sa produksyon, magdagdag ng pag-verify ng certificate sa pamamagitan ng SecTrustEvaluateWithError at ihambing sa dating naka-save na fingerprint — pagkatapos lamang nito tawagan ang useCredential.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, 2018) — ang unang malaking update ng protocol sa loob ng 10 taon. Mga pangunahing pagpapahusay: handshake binawasan sa 1 RTT (0 RTT para sa muling pagkonekta), inalis ang mga lumang cipher suite (RSA key exchange, CBC-mode), mandatoryong forward secrecy (PFS), at proteksyon laban sa downgrade attacks sa pamamagitan ng signed transcript. Ayon sa Qualys SSL Labs (2026), nagbibigay ang TLS 1.3 ng proteksyon kahit na nakompromiso ang pangmatagalang server key dahil sa PFS.

0-RTT (Zero Round Trip Time) — feature ng TLS 1.3 na nagpapahintulot sa client na magpadala ng data kaagad kasama ng ClientHello kapag muling kumokonekta sa pamamagitan ng PSK (Pre-Shared Key). Pinapabilis nito ang pag-load ng mga susunod na screen sa mga mobile app, lalo na sa madalas na pag-request sa parehong server. Gayunpaman, ang data ng 0-RTT ay hindi protektado mula sa replay attacks — maaari itong maharang at maipadala muli. Gamitin lamang ang 0-RTT para sa mga idempotent na kahilingan (GET, PUT) nang walang side effect.

TLS sa iOS: App Transport Security

App Transport Security (ATS) — mekanismo ng Apple na nangangailangan ng HTTPS connections na may TLS 1.2 o mas mataas, naka-enable bilang default mula iOS 9. Hinaharangan ng ATS ang lahat ng HTTP connections at HTTPS na may TLS na mas mababa sa 1.2. Maaaring i-configure ng developer ang mga exception sa Info.plist sa pamamagitan ng NSAppTransportSecurity para sa mga partikular na domain, ngunit inirerekomenda ng Apple na bawasan ang mga exception at gamitin ang HTTPS sa lahat ng dako. Ang paglabag sa mga kinakailangan ng ATS ay dahilan para tanggihan ang app sa review ng 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>

Configuration ng ATS sa Info.plist. Ang NSAllowsArbitraryLoads ay nakatakda sa false — lahat ng koneksyon ay dapat gumamit ng HTTPS. Para sa domain na cdn.example.com, nakatakda ang minimum na TLS 1.2 na bersyon, ang NSAllowsLocalNetworking=true ay nagpapahintulot ng HTTP para sa lokal na network (kapaki-pakinabang para sa dev server). Mahigpit na inirerekomenda ng Apple na huwag paganahin ang NSAllowsArbitraryLoads nang walang NSExceptionDomains — ito ay dapat na isang exception, hindi isang pangkalahatang tuntunin.

TLS sa Android: Network Security Config

Network Security Config — mekanismo ng Android para i-configure ang HTTPS at TLS nang hindi binabago ang Java/Kotlin code. Ang configuration ay tinukoy sa XML file na network_security_config.xml at ikinonekta sa AndroidManifest sa pamamagitan ng attribute na android:networkSecurityConfig. Sinusuportahan ang configuration ng mga pinagkakatiwalaang certificate (user at system CA), Certificate Pinning, pag-disable ng cleartext HTTP, debug override, at pag-redirect ng trapiko.

<!-- 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 para sa Android. Ipinagbabawal ng Base-config ang cleartext traffic at pinagkakatiwalaan lamang ang system CA certificates (walang user certificate — proteksyon laban sa pag-install ng MitM certificate ng user). Ang Domain-config para sa api.example.com ay naglalaman ng pin-set na may SHA-256 fingerprint ng certificate. Kung magbago ang server certificate bago ang tinukoy na petsa ng expiration, tatanggihan ang koneksyon — ito ay isang mahigpit na anyo ng Certificate Pinning.

Certificate Pinning at seguridad

Certificate Pinning — technique ng pag-fix ng certificate o pampublikong key ng server sa code ng app. Sa bawat TLS Handshake, inihahambing ng client ang server certificate sa dating naka-save na fingerprint (SHA-256 hash). Kahit na makakuha ang attacker ng pinagkakatiwalaang CA certificate o makompromiso ang certification authority, hindi siya maaaring magsagawa ng MitM attack — sinusuri ng app ang partikular na fingerprint, hindi ang CA chain. Ito ay lalong mahalaga para sa mga financial app at app na may sensitibong data.

Mga panganib at alternatibo ng Pinning

Certificate Pinning ay nangangailangan ng pag-iingat: kapag nagbago ang certificate sa server, hindi na makakakonekta ang lahat ng lumang bersyon ng app. Inirerekomenda na mag-imbak ng maraming backup fingerprint (pangunahin + backup), tukuyin ang petsa ng expiration ng pin-set, at ipatupad ang fallback mechanism sa pamamagitan ng standard CA verification. Alternatibo — Trust On First Use (TOFU), kapag naaalala ng app ang certificate sa unang koneksyon at nagbabala sa user kapag nagbago ito. Ayon sa OWASP (2026), ang kawalan ng Certificate Pinning ay nasa top 3 na kahinaan ng mga mobile app (M3: Insecure Communication).

Pagpapatupad ng Pinning sa Alamofire

Sa Alamofire 5+, ang Certificate Pinning ay naka-configure sa pamamagitan ng ServerTrustManager na may PinnedCertificatesTrustEvaluator (pagsusuri ng buong certificate) o PublicKeysTrustEvaluator (pampublikong key lamang). Mas gusto ang pampublikong key — hindi ito nagbabago kapag na-update ang certificate sa parehong CA. Gumawa ng ServerTrustManager na may diksyunaryong [host: evaluator], ipasa ito sa Session, at gamitin para sa lahat ng kahilingan sa mga protektadong API.