Ang HTTPS proxy ay nangangahulugang dalawang TLS na koneksyon, hindi isa
Ang proxy hop at ang website ay magkahiwalay na ugnayang TLS na may magkahiwalay na pagtitiwala. Basahin kung aling endpoint ang nabigo bago baguhin ang anumang setting ng sertipiko.
Inilalarawan ng katawagang HTTPS proxy ang transportasyon sa pagitan ng iyong client at ng proxy, at wala nang iba. Hindi nito sinasabi na ang website sa likod nito ay naka-encrypt ng parehong koneksyon, at hindi nito sinasabi na kayang basahin ng proxy ang pahina. Kapag pinaghiwalay mo ang dalawang koneksyon, hindi na misteryoso ang mga error sa sertipiko at nagiging malinaw ang paghahambing sa isang VPN.
Dalawang pares ng endpoint, dalawang beripikasyon
Sa karaniwang tunnel mode may dalawang ugnayang TLS. Ang una ay mula sa iyong client patungo sa proxy at nagpapatunay sa proxy. Ang pangalawa ay mula sa iyong client patungo sa website sa loob ng tunnel, at nagpapatunay sa website. Nabigo sila nang hiwalay at naka-configure sila nang hiwalay.
May magkahiwalay silang desisyon sa pagtitiwala, magkahiwalay na certificate chain at magkahiwalay na mensahe ng pagkabigo. Ang proxy na gumagamit ng organizational CA at pampublikong website na gumagamit ng pampublikong chain ay lehitimong maaaring mangailangan ng ibang configuration ng beripikasyon, at hindi iyon maling configuration.
Ituring silang dalawang koneksyon na nagkataong nagbabahagi ng isang socket, dahil ganoon nga sila.
Ano ang aktwal na tinutunnel ng CONNECT
Nagpapadala ang client ng CONNECT request na nagtatala ng host at port, at binubuksan ng proxy ang isang TCP connection patungo sa target na iyon. Pagkatapos sumagot ng proxy, ang mga byte na sumusunod ay ipinapasa nang walang interpretasyon, kaya ang TLS handshake ng website ay dumadaan sa proxy nang hindi nagagalaw. Kaya natututuhan ng proxy ang pangalan ng destinasyon at ang metadata ng koneksyon, at hindi ito tumatanggap ng na-decrypt na mga pahina mula sa ganitong kaayusan.
Ang pagkakaibang iyon ang buong argumento sa seguridad ng tunnel mode, at ito rin ang hangganan nito.
Ang HTTP proxy na walang TLS sa proxy hop ay nagdadala pa rin ng HTTPS website sa pamamagitan ng CONNECT. Ang palitan ng client at proxy ay hayag habang ang koneksyon sa website ay hindi, at tinatago ng pagtawag sa buong bagay na HTTPS proxy ang pagkakaibang iyon.
Aling sertipiko ang nabigo
Kapag nabigo ang beripikasyon, basahin ang endpoint na pinangalanan sa error bago baguhin ang anumang setting ng pagtitiwala. Magkamukha ang dalawang pagkabigo sa terminal at tumuturo sa lubos na magkaibang lunas, kaya ang unang tanong ay laging aling koneksyon ang tinanggihan.
Pinaghihiwalay ng curl ang mga opsyon dahil mismo dito. Ang proxy CA file ang nagko-configure ng beripikasyon ng proxy, habang ang CA file ang nagko-configure ng beripikasyon ng server, at ang umiiral na pag-uugali ng trust store ay nakadepende rin sa kung paano itinayo ang curl.
curl -v --proxy https://proxy.example.net:443 \
--proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/Ang pagsugpo sa isang pagsusuri ay hindi pagkukumpuni. Wala itong pinapatunayan tungkol sa alinmang endpoint.
Iba ang kaayusan ng inspeksyon
Ang TLS inspection ay hindi tunneling. Ang intermediary na nagsusuri ay tinatapos ang ugnayang pantitiwala na nakaharap sa website at nagpapakita ng sarili nitong sertipiko sa client, kaya ang client ang nagbeberipika sa intermediary sa halip na sa site. Maaaring lehitimo iyon sa ilalim ng inaprubahang disenyo, at materyal na ibang pag-aangkin ito kaysa sa byte-by-byte na pagpapasa. Huwag ipagpalagay na bawat proxy ay nagsusuri, at huwag ipagpalagay na ang naka-encrypt na proxy hop ay nag-aalis nito.
Ang organizational CA sa iyong trust store ay palatandaan lamang kung aling kaayusan ang kinalalagyan mo, hindi patunay. Itanong ang disenyo sa halip na hinuha ito mula sa certificate chain.
Magkaibang sagot ang ibinibigay ng dalawang kaayusang iyon sa tanong kung sino ang makakabasa ng pahina.
Ihambing ang proxy at VPN sa parehong apat na linya
Nagiging kapaki-pakinabang lamang ang paghahambing kapag ang parehong deployment ay inilarawan sa parehong paraan.
| Line | What to state |
|---|---|
| Protected segments | Which hops are encrypted, and between which endpoints |
| Verified identities | What each end proves, and against which trust anchor |
| Trusted intermediaries | Who can read or alter traffic by design |
| Traffic included | Which processes and destinations the policy actually covers |
Ang proxy na naka-configure para sa isang request ay sumasaklaw lamang sa request na iyon. Hindi nito ipinapadala ang bawat proseso sa device sa pamamagitan nito, at ang halimbawang command ay eksaktong ganoon kanipis. Ang saklaw ng VPN ay nakadepende sa routing at application policy nito, na kailangan ding suriin sa halip na ipagpalagay. Wala sa dalawang opsyon ang sumasaklaw sa lahat dahil lang na-install ito.
Isulat ang apat na linya para sa bawat opsyon at kadalasang nalulutas na mag-isa ang argumento. Ang kapaki-pakinabang na paghahambing ay hindi kung aling label ang mas mukhang naka-encrypt. Ito ay kung aling mga segment ang protektado, sino ang beripikado sa kanilang mga dulo, aling mga intermediary ang pinagkakatiwalaan mo, at anong trapiko ang aktwal na saklaw ng policy.