HTTP/HTTPS: ano ito, mga protokol ng transmisyon ng data at TLS encryption

Ano ang HTTP at HTTPS?

HTTP (HyperText Transfer Protocol) — ay isang protokol ng layer ng aplikasyon ng modelo ng OSI, na idinisenyo para sa transmisyon ng mga hypertext na dokumento at iba pang data sa World Wide Web. Binuo ni Tim Berners-Lee noong 1989, ang HTTP ay dumaan sa ilang mga bersyon: mula sa HTTP/0.9 (mga GET na kahilingan lamang at HTML na tugon) hanggang sa modernong HTTP/2 at HTTP/3. Ang protokol ay gumagana sa iskema ng kahilingan-tugon: ang kliyente ay nagpapadala ng kahilingan sa server, pinoproseso ito ng server at nagbabalik ng tugon.

HTTPS (HTTP Secure) — ay isang extension ng protokol ng HTTP na nagdaragdag ng layer ng encryption sa pamamagitan ng TLS (Transport Layer Security). Ang HTTPS ay hindi isang hiwalay na protokol — ito ay kombinasyon ng HTTP at TLS. Ang data na ipinadala sa pamamagitan ng HTTPS ay na-e-encrypt sa panig ng kliyente at na-de-decrypt sa server, na ginagawang hindi maa-access para sa panghaharang at palsipikasyon. Ang HTTPS ay nagbibigay din ng autentikasyon ng server sa pamamagitan ng mga SSL/TLS certificate, na ginagarantiyahan na ang kliyente ay kumokonekta sa tunay na server, hindi sa isang umaatake.

Ang pangunahing pagkakaiba sa pagitan ng HTTP at HTTPS ay seguridad. Ang HTTP ay nagpapadala ng data sa bukas na anyo: anumang node ng network sa pagitan ng kliyente at server ay maaaring basahin ang nilalaman ng kahilingan o tugon. Ang HTTPS ay nag-e-encrypt ng lahat ng nilalaman, kabilang ang URL, mga header at katawan ng kahilingan, na nag-iiwan lamang ng IP address ng server at port ng koneksyon na nakikita. Para sa mga mobile application na gumagana sa pamamagitan ng pampublikong Wi-Fi network, ang HTTPS ay isang mandatoryong pangangailangan sa seguridad.

Paano gumagana ang HTTP

HTTP — ay isang protokol na walang estado (stateless) na gumagana sa ibabaw ng TCP/IP. Ang kliyente ay nagtatag ng TCP koneksyon sa server (karaniwang sa port 80 para sa HTTP o 443 para sa HTTPS), nagpapadala ng HTTP kahilingan, tumatanggap ng HTTP tugon, at nagsasara ng koneksyon (sa HTTP/1.1 ang koneksyon ay maaaring magamit muli). Bawat interaksyon sa pagitan ng kliyente at server ay binubuo ng isang kahilingan at tugon. Ang pagiging walang estado ay nangangahulugan na ang server ay hindi nag-iimbak ng impormasyon tungkol sa mga nakaraang kahilingan ng kliyente — bawat kahilingan ay pinoproseso nang independyente.

Ang proseso ng interaksyon ng HTTP ay kinabibilangan ng mga sumusunod na hakbang:

• Resolusyon ng DNS — ang browser o kliyente ay nagko-convert ng domain name sa IP address sa pamamagitan ng DNS
• Pagkakamay ng TCP — ang TCP koneksyon ay itinatag sa pamamagitan ng tatlong-hakbang na pagkakamay (SYN, SYN-ACK, ACK)
• Pagkakamay ng TLS — para sa HTTPS, isang naka-encrypt na koneksyon ang karagdagang itinatag (pagpapalitan ng mga certificate at key)
• Kahilingan ng HTTP — ang kliyente ay nagpapadala ng metodo, URL, mga header at opsiyonal na katawan ng kahilingan
• Tugon ng HTTP — ang server ay nagbabalik ng code ng katayuan, mga header at katawan ng tugon

Isang mahalagang katangian ng HTTP ay idempotency ng mga metodo. Ang GET, HEAD, PUT, DELETE at OPTIONS ay idempotent: ang paulit-ulit na pagpapatupad ng parehong kahilingan ay hindi nagbabago sa estado ng server pagkatapos ng unang pagpapatupad. Ang POST, PATCH at CONNECT ay hindi idempotent — bawat tawag ay maaaring lumikha ng baging mapagkukunan o magbago ng estado. Para sa mobile development, ang pag-unawa sa idempotency ay kritikal: sa muling pagpapadala ng kahilingan dahil sa error sa network, dapat malaman ng kliyente kung ligtas bang ulitin ang kahilingan.

HTTPS at TLS encryption

HTTPS ay gumagamit ng kriptographikong protokol na TLS (Transport Layer Security) para protektahan ang ipinadalang data. Ang TLS — ay kahalili ng SSL (Secure Sockets Layer), na binuo ng kumpanyang Netscape noong 1995. Ang mga bersyong SSL 2.0 at 3.0 ay itinuturing na luma at hindi ligtas; ang mga modernong bersyong TLS 1.2 (inilabas noong 2008) at TLS 1.3 (inilabas noong 2018) ay malawakang ginagamit. Ang TLS 1.3, lalo na, ay nagbabawas ng oras ng pagtatag ng koneksyon mula 2 round-trips hanggang 1, na makabuluhang nagpapabilis ng pag-load sa mga mobile device.

Ang proseso ng pagkakamay ng TLS (handshake) ay kinabibilangan ng mga sumusunod na yugto:

• Client Hello — ang kliyente ay nagpapadala ng listahan ng mga suportadong bersyon ng TLS at mga set ng cipher
• Server Hello — ang server ay pumipili ng bersyon ng TLS at set ng cipher, ipinapadala ang sarili nitong SSL/TLS certificate
• Beripikasyon ng certificate — sinusuri ng kliyente ang certificate ng server sa pamamagitan ng chain of trust hanggang sa root CA
• Pagpapalitan ng key — ang kliyente at server ay bumubuo ng isang magkabahaging lihim na key (session key)
• Switch Cipher — kinukumpirma ng parehong panig ang paglipat sa naka-encrypt na koneksyon

Ang beripikasyon ng SSL/TLS certificate — ay isang kritikal na yugto para sa seguridad. Sinusuri ng kliyente kung ang certificate: hindi pa nag-e-expire, nilagdaan ng isang pinagkakatiwalaang awtoridad ng sertipikasyon (CA), tumutugma sa domain sa URL, at hindi binawi (sa pamamagitan ng CRL o OCSP). Sa mga mobile application, inirerekomenda ang paggamit ng Certificate Pinning — pag-angkla sa isang tiyak na certificate o pampublikong key ng server. Ito ay pumipigil sa mga pag-atake ng MITM kahit na sa kaso ng kompromiso ng CA. Gayunpaman, ang pinning ay nangangailangan ng pag-iingat: kapag nagbago ang certificate, ang aplikasyon ay dapat munang ma-update.

Istraktura ng kahilingan at tugon ng HTTP

Ang kahilingan ng HTTP ay binubuo ng tatlong bahagi: ang panimulang linya (request line), mga header, at opsiyonal na katawan (body). Ang panimulang linya ay naglalaman ng metodo ng HTTP, URL ng kahilingan at bersyon ng HTTP. Ang mga header ay nagpapadala ng meta-impormasyon: uri ng nilalaman, mga token ng autentikasyon, mga setting ng cache. Ang katawan ay naroroon lamang sa mga metodong nagpapadala ng data (POST, PUT, PATCH) at wala sa GET at DELETE.

Halimbawa ng kahilingan ng HTTP sa REST API:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "Anna",
    "email": "anna@example.com"
}

Ang tugon ng HTTP ay may kahalintulad na istraktura: panimulang linya na may bersyon ng HTTP at code ng katayuan, mga header at katawan. Ang code ng katayuan — isang tatlong-digit na numero na tumutukoy sa resulta ng pagproseso ng kahilingan. Ang mga header ng tugon ay kinabibilangan ng Content-Type, Content-Length, Cache-Control, Set-Cookie at iba pa. Ang katawan ng tugon ay naglalaman ng hinihinging data sa format na tinukoy sa Content-Type (karaniwang JSON para sa API, HTML para sa mga web page, mga imahe para sa nilalamang media).

Ang mga header ay may mahalagang papel sa pagpapatakbo ng HTTP. Ang Content-Type at Accept ay namamahala sa format ng data. Ang Authorization ay nagpapadala ng mga token ng pag-access. Ang Cache-Control ay namamahala ng caching. Ang mga header ng CORS (Access-Control-Allow-Origin) ay kumokontrol ng pag-access mula sa ibang mga domain sa mga browser. Ang User-Agent ay tumutukoy sa aplikasyon ng kliyente. Para sa mga mobile application, ang mga header ng pamamahala ng cache ay lalong mahalaga — pinapababa nila ang dami ng ipinadalang data at pinapabuti ang paggana sa mahinang signal.

Mga code ng katayuan ng HTTP

Ang mga code ng katayuan ng HTTP ay pinapangkat sa limang klase, na ipinapahiwatig ng unang digit: 1xx (impormasyonal), 2xx (tagumpay), 3xx (pag-redirect), 4xx (error ng kliyente), 5xx (error ng server). Ang pag-unawa sa mga code na ito ay kinakailangan para sa tamang pagproseso ng mga tugon sa isang mobile application: ang 2xx ay nangangahulugang tagumpay at maaaring ipakita ang data, ang 4xx ay nagpapahiwatig ng problema sa kahilingan (dapat ipakita ang error sa gumagamit), ang 5xx — problema sa server (dapat ulitin ang kahilingan mamaya).

Para sa mga mobile application, ang paghawak ng code na 401 Unauthorized ay may espesyal na kahalagahan. Pagkatanggap ng code na ito, dapat subukan ng kliyente na i-refresh ang token ng pag-access sa pamamagitan ng Refresh Token at ulitin ang orihinal na kahilingan. Kung ang pag-refresh ng token ay nagbabalik din ng 401, ang gumagamit ay dapat i-redirect sa screen ng pag-login. Ang lohikang ito ay karaniwang ipinapatupad sa Interceptor (OkHttp) o sa layer ng middleware ng network client.

HTTP/1.1, HTTP/2 at HTTP/3

HTTP/1.1, na inilathala noong 1999, ay nananatiling malawakang ginagamit na bersyon ng protokol. Ang pangunahing kakulangan nito — head-of-line blocking: ang mga kahilingan sa parehong server ay isinasagawa nang sunud-sunod, bawat susunod ay naghihintay sa pagkumpleto ng nauna. Upang malampasan ang limitasyong ito, ang mga browser ay nagbubukas ng 6–8 na magkakatulad na TCP koneksyon sa parehong domain, na nagpapataas ng karga ng server at konsumo ng memorya. Ang HTTP/1.1 ay nagpapadala rin ng mga header sa hindi naka-encrypt na anyo at hindi sumusuporta sa server push.

HTTP/2 (2015) ay lumulutas sa problema ng pag-block sa pamamagitan ng multiplexing — maraming daloy ng data ang ipinapadala sa pamamagitan ng isang TCP koneksyon nang sabay-sabay. Ang server ay maaaring magpadala ng mga mapagkukunan sa kliyente bago pa ito hilingin ng kliyente (server push). Ang HTTP/2 ay nagko-compress din ng mga header sa pamamagitan ng HPACK, na nagbabawas ng dami ng ipinadalang data. Para sa mga mobile application, ang HTTP/2 ay lalong kapaki-pakinabang: isang koneksyon ang pumapalit sa marami, na nagbabawas ng oras ng pagkakamay ng TLS at konsumo ng baterya.

HTTP/3 (2022) — ang pinakabagong bersyon ng protokol, na gumagamit ng QUIC (Quick UDP Internet Connections) sa halip na TCP. Ang QUIC ay gumagana sa ibabaw ng UDP, na inaalis ang problema ng head-of-line blocking sa antas ng protokol ng transportasyon. Ang HTTP/3 ay nagbabawas ng oras ng pagtatag ng koneksyon sa 0 round-trips sa pinakamainam na kaso (sa mga paulit-ulit na koneksyon) at sa 1 round-trip sa unang koneksyon, na mas mabilis kaysa sa HTTP/2 na may 2–3 round-trips. Para sa mga mobile device, ang HTTP/3 ay lalong epektibo sa paglipat sa pagitan ng Wi-Fi at mobile network — ang koneksyon ay hindi napuputol dahil ang QUIC ay gumagamit ng ID ng koneksyon, hindi IP address.

HTTPS sa mobile development

Ang paggamit ng HTTPS sa mga mobile application — ay hindi rekomendasyon, kundi isang mandatoryong pangangailangan. Simula sa Android 9 (API 28) at iOS 9 (ATS — App Transport Security), lahat ng kahilingan sa network ay dapat gumamit ng HTTPS bilang default. Ang mga kahilingan ng HTTP ay hinaharangan ng sistema, at para payagan ang mga ito ay kinakailangan ng tahasang pagbubukod sa konpigurasyon ng aplikasyon. Tinatanggihan ng Google Play Store at App Store ang mga aplikasyon na nagpapadala ng kumpidensyal na data sa pamamagitan ng HTTP, kabilang ang mga password, token at personal na data.

Ang konpigurasyon ng HTTPS sa mobile application sa Android ay kinabibilangan ng:

<!-- AndroidManifest.xml — pahintulot para sa mga kahilingan sa network -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — konpigurasyon ng HTTPS -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Sa iOS, ang kahalintulad na konpigurasyon ay ginagawa sa pamamagitan ng Info.plist na may key na NSAppTransportSecurity. Para sa pag-debug ng HTTPS traffic sa mga mobile application, ginagamit ang mga proxy tool: Charles Proxy, Proxyman o mitmproxy. Kinakailangan nila ang pag-install ng pinagkakatiwalaang SSL certificate sa device. Sa mga production build, dapat i-off ang kakayahang mag-debug at suriin kung ang Certificate Pinning ay na-configure nang tama. Ang paggamit ng OkHttp sa Android kasama ang CertificatePinner o TrustManager sa iOS kasama ang SecTrustEvaluate — ay mga standard na diskarte para sa pagpapatupad ng pinning.

Isang mahalagang aspeto ng seguridad ng HTTPS sa mobile development — SSL Pinning. Kung walang pinning, ang aplikasyon ay nagtitiwala sa anumang certificate na nilagdaan ng isang kilalang CA. Kung ang CA ay nakompromiso, maaaring harangin ng isang umaatake ang trapiko ng aplikasyon. Ang pinning ay nag-aaplay ng aplikasyon sa isang tiyak na certificate o pampublikong key ng server. Kapag nagbago ang certificate sa server, kailangang maglabas ng update ng aplikasyon, kaya ang pinning ay pinaplano nang may reserba — nag-aangkla sa certificate ng nakatataas na CA o gumagamit ng ilang reserbang key.