SSL/TLS — ano ito, mga protocol at prinsipyo ng paggana ng encryption

Ano ang SSL/TLS?

SSL (Secure Sockets Layer) — ay isang protocol na binuo ng kumpanyang Netscape noong 1995 upang protektahan ang web traffic. Ang unang bersyon na SSL 1.0 ay hindi kailanman na-publish, ang SSL 2.0 (1995) at SSL 3.0 (1996) ay ginamit hanggang sa unang bahagi ng 2000s, ngunit naglalaman ng mga kritikal na kahinaan. Pumalit sa SSL ang TLS (Transport Layer Security) — isang pinahusay na bersyon na na-standardize ng IETF. Ang TLS 1.0 (1999) ay batay sa SSL 3.0, at ang mga sumunod na bersyon na TLS 1.1 (2006), TLS 1.2 (2008) at TLS 1.3 (2018) ay unti-unting lumayo mula sa orihinal na arkitektura, nagdagdag ng mga bagong algorithm sa pag-encrypt at nag-alis ng mga kahinaan. Ngayon, ang SSL ay itinuturing na luma na at lahat ng modernong sistema ay gumagamit ng TLS, bagaman dahil sa nakagawian, ang parehong protocol ay madalas na binabanggit nang magkasama bilang SSL/TLS.

Kasaysayan ng Paglikha ng Protocol

Ang kasaysayan ng SSL/TLS ay nagsimula sa pangangailangan para sa secure na paghahatid ng data sa unang bahagi ng web. Noong 1994, binuo ng Netscape ang SSL 1.0 para sa browser nitong Navigator, ngunit hindi kailanman na-publish ang protocol dahil sa malubhang problema sa seguridad. Ang SSL 2.0 ay inilabas noong 1995 at ginamit sa praktika, ngunit naglalaman ng maraming kahinaan: kakulangan ng proteksyon laban sa Man-in-the-Middle attacks, mahinang algorithm sa pag-encrypt, at kahinaan sa truncation attacks. Inayos ng SSL 3.0 (1996) ang karamihan sa mga problema, ngunit pagsapit ng 2014, natuklasan ang kahinaang POODLE, pagkatapos ay opisyal na idineklara ng IETF na luma na ang lahat ng bersyon ng SSL. Sunod-sunod na pinabuti ng TLS 1.0–1.3 ang cryptographic strength, performance, at confidentiality, kung saan binawasan ng TLS 1.3 ang handshake mula dalawang round-trip pababa sa isa, na kritikal para sa mga mobile app na may hindi matatag na koneksyon.

Paano Gumagana ang SSL/TLS Handshake

Handshake — ay ang proseso ng pagtatatag ng secure na koneksyon sa pagitan ng client at server. Binubuo ito ng ilang magkakasunod na hakbang kung saan ang mga partido ay sumasang-ayon sa bersyon ng protocol, pumipili ng mga algorithm sa pag-encrypt, nagpapalitan ng mga key, at nag-a-authenticate sa isa't isa. Sa TLS 1.3, ang handshake ay tumatagal lamang ng isang network interaction (1-RTT), samantalang sa TLS 1.2 ay kinakailangan ng dalawa (2-RTT).

Unang hakbang, ang client ay nagpapadala ng ClientHello — isang mensahe na naglalaman ng listahan ng mga sinusuportahang TLS version, cipher suites, at random number. Tumugon ang server ng ServerHello na may napiling bersyon at cipher, X.509 certificate nito, at digital signature. Vini-verify ng client ang certificate sa pamamagitan ng chain ng Certificate Authorities (CA), bumubuo ng session key, at ipinapadala ito na naka-encrypt gamit ang public key ng server mula sa certificate. Pagkatapos ng kumpirmasyon ng server, magsisimula ang secure na paghahatid ng data. Ang buong handshake ay ginagawa sa loob ng 1–3 millisecond sa mga modernong device, na ginagawa itong hindi nakikita para sa user.

X.509 Certificates at Chain of Trust

Ang pundasyon ng TLS authentication ay ang public key infrastructure (PKI) na binuo sa mga certificate sa X.509 na format. Ang bawat certificate ay naglalaman ng: domain name (Common Name o Subject Alternative Name), public key ng server, pangalan ng issuer (Certificate Authority), validity period, at digital signature ng CA. Vini-verify ng client ang server certificate sa pamamagitan ng chain of trust: mula sa server certificate hanggang sa root CA, na ang certificate ay naka-embed sa operating system. Sa mga Android device, ang mga root certificate ay naka-imbak sa system store na ina-update sa pamamagitan ng Google Play Services; sa iOS — sa pamamagitan ng iOS Updates. Kapag may nasirang link sa chain (expired certificate, hindi tugmang domain, hindi kilalang CA), puputulin ng client ang koneksyon. Para sa mga self-signed certificate (ginagamit sa development), kinakailangan ang tahasang pagtitiwala — sa Android sa pamamagitan ng Network Security Config, sa iOS sa pamamagitan ng NSExceptionDomains sa Info.plist. Ang proseso ng validation ng certificate chain ay kasama rin ang pagsusuri ng revocation status sa pamamagitan ng CRL (Certificate Revocation List) o OCSP (Online Certificate Status Protocol), bagaman sa mga mobile device ang OCSP requests ay madalas na nilalaktawan upang pabilisin ang koneksyon — ito ay isang kompromiso sa pagitan ng seguridad at performance na dapat isaalang-alang ng mga arkitekto.

SSL vs TLS: Mga Pangunahing Pagkakaiba

Bagaman ang mga terminong SSL at TLS ay madalas na ginagamit nang magkapalit, may mga pangunahing teknikal na pagkakaiba sa pagitan ng mga ito na nakakaapekto sa seguridad at performance ng mga mobile app.

Ang pangunahing pagkakaiba ng TLS 1.3 mula sa mga nauna — ang sapilitang paggamit ng Perfect Forward Secrecy (PFS) sa pamamagitan ng ECDHE protocol. Nangangahulugan ito na kahit makuha ng attacker ang private key ng server, hindi nito made-decrypt ang dating naharang na trapiko. Para sa mga mobile app, kung saan ang pag-hack ng server ay isang tunay na banta, ang TLS 1.3 na may PFS ay isang sapilitang kinakailangan sa seguridad.

Mga Kilalang Kahinaan ng Mga Lumang Bersyon

Ang mga lumang bersyon ng SSL at TLS ay may dokumentadong mga kahinaan na ginagawang hindi angkop ang mga ito para sa paggamit sa produksyon. Inaatake ng POODLE (CVE-2014-3566) ang SSL 3.0 sa pamamagitan ng padding oracle, na nagpapahintulot sa pag-decrypt ng session cookie sa 256 na kahilingan. Ginagamit ng BEAST (CVE-2011-3389) ang kahinaan ng TLS 1.0 sa CBC mode sa pamamagitan ng predictable IV. Ang Heartbleed (CVE-2014-0160) — ay hindi kahinaan ng protocol, kundi isang bug sa implementasyon ng OpenSSL na nagpapahintulot sa pagbabasa ng memory ng server: ayon sa Netcraft, noong 2014 mahigit 500 libong server ang vulnerable. Simula sa Android 10 (API 29) at iOS 13, lahat ng nabanggit na protocol ay naka-disable sa antas ng system. Gayunpaman, dapat suriin ng mga developer ang configuration ng server sa pamamagitan ng SSL Labs Test (qualys.com) bago ilunsad ang app upang matiyak na walang lumang cipher suites at suportado ang TLS 1.3.

Paano Pinoprotektahan ng SSL/TLS ang Data sa Mga Mobile App

Sa mga mobile app, pinoprotektahan ng TLS ang data sa tatlong antas: encryption ng nilalaman (walang makakabasa ng data maliban sa server), pagsusuri ng integridad (hindi mababago ang data habang nasa biyahe), at pag-authenticate ng server (sigurado ang client na ito ay kumokonekta sa tamang server). Ang pag-authenticate ay lubhang kritikal: kung wala ito, maaaring palitan ng attacker ang server sa pamamagitan ng DNS-spoofing o pekeng Wi-Fi access point.

Ayon sa pag-aaral ng Google Play Protect (2024), 76% ng Android apps ay gumagamit ng TLS nang tama na may pagsusuri ng certificate. Ang natitirang 24% ay nagkakamali: dinidiskonekta ang pagsusuri ng certificate para sa pag-test (at nakakalimutang i-on sa produksyon), gumagamit ng self-signed certificate nang walang validation, o pinapayagan ang mga lumang protocol na SSL 3.0 at TLS 1.0. Ang Apple App Transport Security (ATS) sa iOS ay nag-aatas ng TLS 1.2 kahit mula noong 2017, at simula sa iOS 15 ay default na gumagamit ng TLS 1.3 para sa lahat ng network request. Para sa karagdagang proteksyon, inirerekomenda rin ang pagpapatupad ng Certificate Pinning — pag-pin sa partikular na certificate ng server.

Pagpapatupad ng SSL/TLS sa Mga Mobile App

Tingnan natin ang halimbawa ng pag-configure ng secure na HTTPS connection sa Android gamit ang OkHttp — isa sa mga pinakasikat na library para sa pagtatrabaho sa network. Kasama sa tamang configuration ang sapilitang paggamit ng TLS 1.3 at pagsusuri ng certificate.

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

Sa halimbawang ito, nililimitahan namin ang set ng mga sinusuportahang TLS na bersyon sa mga protocol 1.3 at 1.2 lamang, hindi kasama ang mga lumang TLS 1.0/1.1. Ang cipher suites ay pinipili mula sa mga modernong algorithm na may AEAD mode at sapilitang Perfect Forward Secrecy. Sinusuri ng HostnameVerifier ang pagtutugma ng host name sa certificate. Para sa iOS, ang katulad na configuration ay ginagawa sa pamamagitan ng URLSession configuration na may parameter na tlsMinimumSupportedProtocolVersion, kung saan tinutukoy ang .TLSv13. Bukod pa rito, sa iOS ay maaaring itakda ang tlsMaximumSupportedProtocolVersion upang limitahan ang upper bound ng mga bersyon — ito ay kapaki-pakinabang para sa compatibility sa mga lumang server na hindi pa lumilipat sa TLS 1.3. Ang ganitong configuration ay ginagarantiyahan ang pinakamataas na antas ng seguridad habang nagpapadala ng data sa mobile app.