In HTTPS-proxy betsjut twa TLS-ferbiningen, net ien
De proxyhop en de webside binne aparte TLS-relaasjes mei apart fertrouwen. Lês hokker einpunt mislearre foardat jo in sertifikaatynstelling feroarje.
It label HTTPS-proxy beskriuwt allinnich it ferfier tusken jo klant en de proxy, en neat mear. It seit net dat de webside dêrefter troch deselde ferbining fersifere wurdt, en it seit net dat de proxy de side lêze kin. Sadree't jo de twa ferbiningen skiede, hâlde sertifikaatflaters op mysterieus te wêzen en wurdt de ferliking mei in VPN konkreet.
Twa einpuntpearen, twa ferifikaasjes
Yn gewoane tunnelmodus binne der twa TLS-relaasjes. De earste rint fan jo klant nei de proxy en ferifiearret de proxy. De twadde rint fan jo klant nei de webside binnen de tunnel, en ferifiearret de webside. Se mislearje ûnôfhinklik en se wurde ûnôfhinklik konfigurearre.
Se hawwe aparte fertrouwensbesluten, aparte sertifikaatkeatlingen en aparte flaterberjochten. In proxy mei in organisaasje-CA en in iepenbiere webside mei in iepenbiere keatling kinne legitimen ferskillende ferifikaasjekonfiguraasje nedich hawwe, en dat is gjin ferkearde konfiguraasje.
Behannelje se as twa ferbiningen dy't tafallich ien socket diele, want dat binne se.
Wat CONNECT eins tunnellet
De klant stjoert in CONNECT-fersyk mei de host en poarte, en de proxy iepenet in TCP-ferbining nei dat doel. Nei't de proxy antwurde hat, wurde de folgjende bytes trochjûn sûnder ynterpretaasje, dêrom giet de TLS-hânskikking fan de webside ûnoantaaste troch de proxy. Sa leart de proxy de bestimmingsnamme en de ferbiningsmetadeta, en hy ûntfangt gjin ûntsifere siden út dy regeling.
Dat ûnderskie is it hiele feiligensargumint foar tunnelmodus, en it is ek syn grins.
In HTTP-proxy sûnder TLS op 'e proxyhop draacht noch altyd in HTTPS-webside troch CONNECT. De útwikseling klant-nei-proxy is iepen wylst de websideferbining dat net is, en it hiele spul in HTTPS-proxy neame ferberget dat ferskil.
Hokker sertifikaat mislearre
As ferifikaasje mislearret, lês it einpunt dat yn 'e flater neamd wurdt foardat jo in fertrouwensynstelling feroarje. De twa flaters lykje yn in terminal itselde en wize op folslein ferskillende reparaasjes, dêrom is de earste fraach altyd hokker ferbining wegere.
curl skiedt de opsjes krekt om dy reden. It CA-bestân fan 'e proxy konfigurearret de ferifikaasje fan 'e proxy, wylst it CA-bestân de ferifikaasje fan 'e tsjinner konfigurearret, en it gedrach fan 'e tapaslike fertrouwensopslach hinget ek ôf fan hoe't curl boud is.
curl -v --proxy https://proxy.example.net:443 \
--proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/In kontrôle ûnderdrukke is gjin reparaasje. It bewiist neat oer ien fan 'e beide einpunten.
Ynspeksje is in oare regeling
TLS-ynspeksje is gjin tunnelaasje. In ynspektearjende tuskenpersoan beëiniget de fertrouwensrelaasje nei de webside en presintearret syn eigen sertifikaat oan 'e klant, sadat de klant de tuskenpersoan ferifiearret ynstee fan 'e side. Dat kin legitime wêze ûnder in goedkarde ûntwerp, en it is in wêzentlik oar bewearing as it trochjaan byte foar byte. Nim net oan dat elke proxy ynspektearret, en nim net oan dat in fersifere proxyhop dat útslút.
In organisaasje-CA yn jo fertrouwensopslach is in oanwizing foar hokker regeling jo yn binne, gjin bewiis. Freegje om it ûntwerp ynstee fan it ôf te lieden út in sertifikaatkeatling.
Dy twa regelingen jouwe ferskillende antwurden op 'e fraach wa't de side lêze kin.
Fergelykje proxy en VPN op deselde fjouwer rigels
De ferliking wurdt pas brûkber as beide ynsetten op deselde wize beskreaun wurde.
| 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 |
In proxy konfigurearre foar ien fersyk dekt dat fersyk. Hy stjoert net elk proses op it apparaat troch himsels, en it foarbyldkommando is krekt sa smel. De dekking fan in VPN hinget ôf fan syn routing en tapassingsbelied, dat ek ynspektearre wurde moat ynstee fan oannommen. Gjin fan beide opsjes dekt alles allinnich om't it ynstallearre is.
Skriuw de fjouwer rigels foar elke opsje en it argumint lost himsels meastentiids op. De brûkbere ferliking is net hokker label mear fersifere klinkt. It is hokker segminten beskerme binne, wa't oan har einen ferifiearre wurdt, hokker tuskenpersoanen jo fertrouwe, en hokker ferkear it belied eins omfettet.