VPN kaj ĉifrado de fino al fino: kiu povas legi kion
VPN protektas la itineron, la mesaĝa aplikaĵo protektas la enhavon. Komparu la eliron, la relajson kaj la ricevanton antaŭ ol supozi, ke iu el ili kaŝas la mesaĝon.
Sekvu unu mesaĝon de telefono al amiko kaj ĝi pasas tra almenaŭ du malsamaj specoj de protekto. La VPN kovras la itineron inter la kliento kaj ĝia enirejo, la mesaĝa aplikaĵo kovras la enhavon inter la aparatoj de la partoprenantoj. Nek unu anstataŭas la alian, kaj la utila demando ne estas, kiu estas pli forta, sed kiu povas legi kion ĉe ĉiu paŝo. Pasu la vojon unufoje kaj la roloj fariĝas klaraj.
Du protektoj, du finoj
Ĉe la senda aparato la aplikaĵo ĉifras la mesaĝon per ŝlosiloj apartenantaj al la konversacio, poste transdonas la ĉifrotekston al la operaciumo. La VPN, se ĝi estas aktiva, envolvas ĉiun trafikon kongruan kun sia politiko kaj portas ĝin al enirejo. De tie la paketo vojaĝas laŭ la ordinara interreto al la serviloj de la aplikaĵo, kiuj plusendas ĝin al la ricevanto. Nur la aparato de la ricevanto tenas la ŝlosilon, kiu retransformas la ĉifrotekston en tekston.
Relajso sur tiu vojo povas vidi mesaĝon alveni kaj foriri sen legi ĝin, kaj ĝuste tiun econ ĉifrado de fino al fino devus provizi.
Kion la VPN-eliro povas kaj ne povas legi
VPN-enirejo malĉifras la tunelon, ne la enhavon de la aplikaĵo. Ĝi povas observi kiun servilon la kliento kontaktis, kiam kaj kiom da datumoj moviĝis, kaj poste plusendi la paketojn. Tio estas signifa aro da faktoj kaj multe pli malgranda aro ol la teksto de la mesaĝo. Ĉe ordinara HTTPS-ejo la TLS-konekto finiĝas ĉe la ejo, do la ejo povas legi kion oni sendis, eĉ se la VPN ne povas. La diferenco temas pri kie ĉiu tavolo finiĝas, ne pri tio, kiu produkto estas pli privata.
Ŝanĝu la celon al servo ĉifrita de fino al fino kaj la relajso en la mezo perdas la enhavon, dum la VPN ankoraŭ vidas la konekton-anŝablonon.
Ŝlosiloj apartenas al la konversacio, ne al la itinero
Enhavŝlosiloj estas interkonsentitaj inter la partoprenantoj kaj restas sur iliaj aparatoj; VPN ne partoprenas en tiu interŝanĝo. Aplikaĵoj ofte montras sekurecan numeron aŭ ŝlosilan fingrospuron, por ke ambaŭ flankoj komparu kion ili havas. Tiu komparo malkovras anstataŭigitan ŝlosilon en la mezo, kio estas valora kaj pli mallarĝa ol pruvi, kiu tajpas. Konfirmi la identecon de persono ankoraŭ bezonas kanalon ekster la aplikaĵo, ekzemple vokon aŭ personan kontrolon. La servila sertifikata kontrolo de VPN kontrolas tute alian finpunkton.
Ne legu konfirmitan sekurecan numeron kiel pruvon de kontoposedo. Ĝi estas pruvo pri ŝlosiloj, ne pri homoj.
Kopioj, metadatumoj kaj la alia aparato
Legebla enhavo ekzistas ĉe la finoj, do la finoj decidas kio okazos poste. Faru mallongan mapon de la lokoj, kie kopio povas surteriĝi, antaŭ ol decidi kiom helpas la tunelo.
| Point | Can it read the message | Why |
|---|---|---|
| Sending device | Yes | Content exists before encryption |
| VPN gateway | No | Terminates the tunnel, not the app keys |
| App relay | No, by design | Only ciphertext passes through |
| Recipient device | Yes | Holds the conversation keys |
| Cloud backup | Depends on the product | May store plaintext or an encrypted archive |
Legu la regulojn de la aplikaĵo pri savkopioj, ligitaj aparatoj, sciigoj kaj eksportoj, ĉar ĉiu el ili estas aparta kopio kun propra traktado. La reto ankoraŭ malkaŝas tempon kaj volumenon eĉ kiam la enhavo estas protektita, kaj VPN ŝanĝas kiun provizanton vidas la lokan konekton, ne ĉu tiaj metadatumoj ekzistas. Dosiero eksportita el protektita konversacio konservas la protekton, kiun donas ĝia formato, kaj la tunelo poste faras nenion por ĝi.
Elektu la protekton por tio, kion ĝi kovras: la aplikaĵon por enhavo kaj ŝlosiloj, la VPN por la itinero kaj la vido de la loka reto. Poste listigu la kopiojn kaj aparatojn, kiuj staras ekster ambaŭ.