Ano ang HTTPS at SSL? Paano Gumagana ang Ligtas na Website, Ipinaliwanag nang Simple

Ang HTTPS ang ligtas na bersyon ng HTTP, ang protocol na ginagamit ng browser para makipag-usap sa mga website. Binabalot nito ang bawat request at response sa naka-encrypt na koneksyon gamit ang TLS (Transport Layer Security), kaya walang makakabasa o makakapagbago ng ipinapadala sa pagitan ng bisita at ng website. Ang SSL ang mas lumang pangalan ng parehong ideya — ang orihinal na protocol na pinalitan ng TLS — kaya sinasabi pa rin ng mga tao ang “SSL certificate.”

Bakit mahalaga ang HTTPS kapag gumagawa ka ng app gamit ang AI

Dapat naka-HTTPS ang anumang app na ipina-publish mo. Hindi lang ito magandang gawi:

• Inaasahan ito ng mga browser. Ang mga site sa plain na HTTP ay nilalagyan ng label na “Not secure,” at ang ilang feature ng browser — gaya ng access sa lokasyon, camera at mikropono, at service worker para sa offline na app — kadalasang gumagana lang sa mga ligtas (HTTPS) na page.
• Mga login at form. Kapag walang HTTPS, ang password, session cookie, at datos ng form ay dumadaan sa nababasang teksto. Maaaring makuha ito ng sinumang nasa parehong Wi-Fi ng café.
• Mga bayad at third party. Kailangan ng mga payment provider, OAuth sign-in, at maraming API ang HTTPS na redirect at callback URL.
• Tiwala at search. Napapansin ng mga bisita ang babala, at sinabi ng Google na ginagamit nila ang HTTPS bilang signal sa ranking.

Maganda ang balita: sa karamihan ng modernong hosting platform, awtomatiko nang naka-set up ang HTTPS. Ang kailangan mo lang talaga ay maintindihan ang mga bahagi nito nang sapat para maayos kapag may sumablay sa custom domain o sa mixed-content na babala.

Halimbawang madaling maintindihan

Ang pagpapadala ng datos sa plain na HTTP ay parang pagpapadala ng postcard: nababasa ito ng bawat taong humahawak nito, at may makakapagbago pa ng mensahe.

Ang HTTPS ay parang pagpapadala ng nakasarang sobre na hindi puwedeng galawin nang hindi nahahalata — at una munang chine-check ang opisyal na ID ng tatanggap. Ang certificate ang ID na iyon, na inilabas ng pinagkakatiwalaang awtoridad (ang certificate authority) na nag-check na talagang kontrolado ng website ang domain. Ang encryption ang nakasarang sobre. Pinatutunayan ng ID na tamang address ang sinusulatan mo; pinananatiling pribado ng sobre ang laman.

Paano gumagana ang HTTPS, nang simple

Kapag nagbukas ang browser ng https://shop.example.com:

1. Hello. Kumokonekta ang browser at sinasabi kung anong paraan ng encryption ang suportado nito.
2. Certificate. Ipinapadala ng server ang certificate nito, na nagsasabing “ang key na ito ay pag-aari ng shop.example.com” at pinirmahan ng certificate authority.
3. Check. Chine-check ng browser ang pirma laban sa mga awtoridad na pinagkakatiwalaan na nito, tinitingnan kung hindi pa nag-e-expire ang certificate, at kung tumutugma ang domain.
4. Mga key. Nagkakasundo ang browser at server sa bagong lihim na key para sa sesyong ito, nang hindi ito naipapadala nang hayagan.
5. Naka-encrypt na usapan. Lahat ng request at response — mga page, datos ng form, cookie — ay naglalakbay na nang naka-encrypt.

Ang TLS handshake na ito ay tumatagal ng ilang milisegundo at awtomatikong nangyayari. Ang nakikita lang ng bisita ay ang padlock icon (o, sa ilang browser, isang neutral na site-info icon).

Ano ang pinoprotektahan at hindi pinoprotektahan ng HTTPS

Ini-encrypt ng HTTPS ang laman ng mga request, kasama ang path ng page at query string. Pero kadalasan nakikita pa rin ng mga network sa daan ang domain name na binibisita mo. Isa ito sa mga dahilan para hindi kailanman maglagay ng personal na datos sa URL — napupunta rin ang mga ito sa log at browser history.

Halimbawang sitwasyon: pagkonekta ng custom domain

Isipin mong nag-publish ka ng booking app at gusto mo itong nasa book.myyogastudio.com:

1. Maglalagay ka ng DNS record na tumuturo sa book.myyogastudio.com papunta sa host mo. Tingnan ang paano gumagana ang mga domain at DNS.
2. Pinapatunayan ng host sa isang certificate authority na kontrolado nito ang pangalang iyon — karaniwan sa pamamagitan ng pagsagot sa challenge sa domain na iyon — at tumatanggap ito ng certificate.
3. Ini-install ito ng host at awtomatikong nire-renew bago mag-expire. Sadyang maikli ang buhay ng mga certificate, kaya mahalaga ang awtomatikong pag-renew.
4. Ang mga bisitang pupunta sa http://book.myyogastudio.com ay ire-redirect sa https://.

Kapag mali ang hakbang 1 — tumuturo sa iba ang record, o may proxy sa gitna — maaaring pumalpak ang hakbang 2 at makakita ang mga bisita ng error sa certificate. Ito ang pinakakaraniwang problema sa HTTPS na nararanasan ng mga tao kapag nagkokonekta ng custom domain.

Mga pangunahing termino

Mga karaniwang maling akala

• “Ang padlock ay ibig sabihin mapagkakatiwalaan ang site.” Ibig sabihin nito pribado ang koneksyon at tumutugma ang domain. Nakakakuha rin ng certificate ang mga scammer.
• “Kailangan lang ng HTTPS sa mga payment page.” Anumang page na may login, form, o cookie ay nangangailangan nito — na halos bawat app. Gamitin ito saanman.
• “Mahal ang mga certificate.” Karaniwan na ang libre at pinagkakatiwalaang certificate, at karamihan ng host ang namamahala nito para sa iyo.
• “Gagawing ligtas ng HTTPS ang app ko.” Sinisiguro lang nito ang koneksyon. Kailangan pa rin ng app mo ng permission check sa server, ligtas na paghawak ng secret, at input validation. Tingnan ang security checklist para sa mga app na gawa sa AI.
• “Pinababagal ng HTTPS ang site.” Halos walang dagdag na bigat ang modernong TLS, at ang mga feature gaya ng HTTP/2 na nagpapabilis ng site ay kadalasang nangangailangan ng HTTPS sa mga browser.

Pag-ayos ng karaniwang problema sa HTTPS

Ano ang itanong sa AI builder mo

• “Siguraduhing bawat larawan, script, at font ay naglo-load sa HTTPS o sa relative na URL — walang http:// na link.”
• “I-redirect ang lahat ng HTTP traffic papuntang HTTPS.”
• “I-set ang session cookie na may Secure at HttpOnly na flag.”
• “Gumamit ng https:// para sa bawat OAuth, payment, at webhook callback URL.”
• “Nagpapakita ng error sa certificate ang custom domain ko — anong DNS record ang inaasahan ng host?”

HTTPS sa Mythex

Kapag nagkokonekta ka ng custom domain sa Mythex (feature ng Pro), magdaragdag ka ng CNAME record na tumuturo sa slug.mythex.ai na target na ipinapakita ng Mythex, i-click ang Verify, at awtomatikong maglalabas ang Mythex ng HTTPS para sa domain. Sakop ng docs ang dalawang pinakakaraniwang sagabal: kung nasa Cloudflare ang DNS mo, itakda ang record sa “DNS only” (grey cloud) sa halip na proxied, para makapaglabas ang Mythex ng certificate; at puwedeng mag-verify ang DNS bago pa ganap na ma-set up ang HTTPS, kaya maghintay ng ilang minuto at mag-verify ulit. Tingnan ang custom domains sa docs at ang aming gabay sa pagkonekta ng custom domain.

Mga tanong