TLS ay tumatakbo sa loob ng control channel, hindi sa buong tunnel

Ang makita ang salitang TLS sa paglalarawan ng VPN at maghinuha na mauunawaan ng web proxy ang traffic ay karaniwang shortcut. Sa loob ng protocol na ito, nagpapalitan ang mga peer ng sarili nilang packet, at tumatakbo ang TLS bilang bahagi ng isang channel sa palitan na iyon. Ang payload na mahalaga sa user ay naglalakbay sa ibang format ng mensahe, at iyon ang dahilan kung bakit hindi kailanman tumutugma ang dalawa sa isang ordinaryong session ng HTTPS.

Una ang envelope

Bawat packet ng tunnel ay nagsisimula sa sariling header ng protocol: isang uri ng mensahe, isang identifier ng key at, sa transport na byte stream, isang prefix ng haba na nagmamarka kung saan nagtatapos ang packet. Ang mambabasa na hindi nag-a-parse ng envelope na iyon ay hindi malalaman kung saan nagsisimula ang susunod na field.

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

Ang sketch na iyon ay isang mapa at hindi isang talahanayan ng byte, dahil ang eksaktong mga field ay nakadepende sa uri ng mensahe, bagaman ang unang octet ay palaging pinagsama ang opcode at identifier ng key. Ang paghula ng uri ng mensahe mula sa numero ng port ay siyang dahilan kung bakit nagwawang mali ang mga decoder sa kanilang nakikita. Ang pagkakasunod-sunod ang mahalaga para sa diagnosis: transport, pagkatapos ang envelope ng protocol, pagkatapos ang isa sa dalawang uri ng trabaho. Basahin ang envelope bago bumuo ng anumang opinyon tungkol sa susunod. Ang decoder na nagsisimula sa maling lugar ay gumagawa ng kumpiyansang kalokohan.

Ang layer ng pagiging maaasahan ay kabilang sa protocol

Kailangan ng mga control message ang maayos at kumpirmadong paghahatid, at ibinibigay ito ng protocol mismo sa pamamagitan ng mga kumpirmasyon at muling pagpapadala. Ang kumpirmasyon ay maaaring dumating bilang sariling mensahe o sumama sa isa pang control message, na nagpapaganda ng hitsura ng mga trace na hindi pantay para sa sinumang umaasa sa isang malinis na palitan.

Ang bentahe ay nakakakuha ang TLS handshake ng maaasahang carrier kahit na ang panlabas na transport ay UDP. Ang halaga ay maaaring ang isang datagram ay naglalaman lamang ng bahagi ng usapang iyon, kaya ang pagtrato dito bilang isang standalone na TLS record ay gumagawa ng kalokohan. Dapat mangyari ang reassembly sa layer ng protocol. Iyon ang dahilan kung bakit ang nahuling packet ay bihirang mukhang kumpletong hakbang ng handshake.

Ang paglipat ng panlabas na transport sa TCP ay hindi nag-aalis ng layer na ito. Ang maaasahang transport ay nangangahulugan ng mas kaunting muling pagpapadala sa antas ng protocol, hindi na mawala ang framing o maging HTTP ang traffic.

Iba ang format na ginagamit ng mga data packet

Kapag umiiral ang session, dumarating ang kapaki-pakinabang na payload bilang mga data message na nagdadala ng panloob na IP packet o Ethernet frame. Protektado ang mga ito ng sarili nilang key at sariling pagproseso, at hindi sila TLS application record sa anumang kahulugan na tatanggapin ng isang TLS library.

Ang paghihiwalay na iyon ay nakikita sa configuration: may magkahiwalay na setting ng cipher ang control channel at data channel, kaya ang log line na nagngangalan ng isa ay walang sinasabi tungkol sa isa pa. Ang pagbasa ng malakas na control cipher bilang patunay ng malakas na data cipher ay karaniwang error sa pag-uulat.

Ilayo rin ang kaugnay na maling akala sa paliwanag. Ang TLS ay hindi isang public-key channel na nakaupo sa tabi ng symmetric data channel, dahil ang TLS mismo ay pinoprotektahan ang mga record nito nang symmetric kapag naitatag na ang mga key. Ang tunay na pagkakaiba ay papel at format ng packet, hindi kung anong uri ng cryptography ang ginagamit ng bawat panig.

Bakit hindi makatulong ang isang HTTPS proxy

Ang proxy na nagtatapos ng TLS ay umaasa sa isang stream ng TLS record at pagkatapos ay isang application protocol sa loob nito. Ang control channel ng protocol na ito ay dinadala sa loob ng sarili nitong framing na may layer ng pagiging maaasahan sa paligid, kaya ang nagtatapos na proxy ay binabasa ang framing na iyon bilang sirang input.

Ang transparent na forwarder na nagpapalusot ng byte o datagram nang hindi ito binibigyang kahulugan ay maaaring gumana, basta hindi nito muling isinusulat o muling binubuo ang stream. Ang tanong na dapat itanong tungkol sa anumang intermediary ay kung ipinapasa nito ang aktwal na transport at framing, hindi kung sumusuporta ito ng TLS saanman. Itanong iyon bago magpalipas ng isang gabi sa mga patakaran ng proxy. Karamihan ng kabiguan dito ay arkitektural at hindi nawawalang setting.

Tamang pagbasa ng isang trace

Asahan muna ang isang control exchange, pagkatapos ang mas maraming bilang ng data message, pareho silang nagbabahagi ng isang transport. Kung natapos ang control phase at natigil ang data phase, ang depekto ay tungkol sa mga key, routing o pag-filter ng data path at hindi sa handshake. Humuli ng ilang data message at tingnan kung umaalis sila sa client. Ang nag-iisang obserbasyon na iyon ay hinahati ang paghahanap sa dalawa.

Ang makasaysayang paglalarawan ng mga paraan ng key sa dokumentasyon ng protocol ay hindi nangangahulugang sinusuportahan pa ng isang release ang bawat lumang format. Tingnan ang bersyon na pinapatakbo mo bago bumuo ng inaasahan sa isang talatang naglalarawan kung paano dating gumagana ang mga bagay.