Ĉu VPN-protokolo povas montri retuman historion? Kion pruvas la pruvoj
Sesia protokolo, peto al solvilo kaj flua rikordo pruvas malsamajn aferojn. Elektu la demandon, kunligu identecon kaj tempon, kaj diru nur tion, kio estis montrita.
Du reviziaj demandoj sonas simile kaj postulas pruvojn de malsamaj specoj. Kiun sesion kontaktis ĉi tiu adreso, estas respondebla el konektaj kaj fluaj rikordoj. Kiun personon malfermis ĉi tiun paĝon, kutime ne, almenaŭ ne el tiuj rikordoj. Elekti kolektilon antaŭ ol elekti la demandon estas kiel reta teamo finas prezentante gastigantan nomon kiel retuman historion.
Komencu per la evento, kiun la revizio devas establi
Skribu la demandon kiel frazon kun subjekto, verbo kaj tempo. Nur tiu disciplino malkaŝas la breĉon inter sesia rikordo kaj paĝa vido. Sesia protokolo establas, ke identeco estis akceptita por intervalo, kun asignita adreso laŭ registrita politiko, kaj ĝi ne povas establi, kiun paĝon iu legis, ĉar ĝi neniam vidis la peton.
Nomu la observon antaŭ ol dizajni la kolektadon. Kampo nomita laŭ vizitita retejo, kiu fakte konservas solvitan nomon, estas estonta eraro anstataŭ oportuneco. Kampnomoj vivas pli longe ol la homoj, kiuj elektis ilin, do elektu tiujn, kiuj priskribas la pruvon anstataŭ la konkludon.
Kion ĉiu rikordo povas subteni kaj kion ne
Kvar specoj de rikordoj aperas en preskaŭ ĉiu revizia dizajno, kaj ĉiu respondas al malsama demando. Tenu ilin aparte en la raporto same kiel en la traktado, ĉar miksi ilin estas kiel defendebla trovo fariĝas hontiga.
| The question being asked | Record that can answer it | What that record proves | What still needs a join |
|---|---|---|---|
| Was this address contacted? | Flow record | The connection five-tuple and when it was seen | Which session held the address at that moment |
| Which account held that address? | Session log | Which identity authenticated and the tunnel address it received | Which device or person used that account |
| Was this name looked up? | Resolver query | That this resolver was asked for this name | Whether a page was fetched, and by whom |
| Was this page viewed? | Proxy or application transaction | The request and identity recorded inside that application's scope | Traffic outside that application's visibility |
| Who was the person? | None of the four on its own | An account in use, at best | A named human, whenever accounts are shared |
Legu la lastan kolumnon same atente kiel la mezuman. Flua rikordo priskribas adresojn kaj pordojn, kaj inversa serĉo de adreso ne rekonstruas la nomon, kiun uzis retumilo, ĉar unu adreso povas gastigi multajn nerilatajn retejojn. Peto al solvilo pruvas, ke demando estis farita, ne ke paĝo estis montrita. Ankaŭ gastiganta nomo videbla dum TLS-negocado ne estas la ĉifrita petvojo.
Ĉiu el tiuj estas reala observo, kaj neniu el ili estas la observo, kiun homoj supozas. Retumilo, kiu insistigas sian propran ĉifritan solvilon, staras ekster la observata amplekso, kaj analizo ne povas rekuperi tion, kion la protokolo neniam vidis. Tiu breĉo apartenas al la raporto kiel deklarita limo, ne kiel piednoto.
Antaŭaj serĉoj kaj kaŝmemoraj respondoj
Retumiloj solvas nomojn anticipe, foje tute sen ŝargi ion. Ili ankaŭ respondas el kaŝmemoro sen sendi novan peton al la solvilo, kiun vi observas, kio signifas, ke la foresto de peto ne estas la foresto de vizito. Ambaŭ kondutoj rompas la naivan ekvacion inter DNS-protokolo kaj retuma historio.
DNS super HTTPS aldonas duan limon: retumilo aŭ gastiga aplikaĵo kun propra solvilo neniam demandas ion ajn al la organiza registrilo. Precizaj transakcioj venas nur el la eventoj de la aplikaĵo mem aŭ el prokuro, kies protokoladon vi eksplicite subtenas. Ordinara HTTPS CONNECT-tunelo lasas la prokuron sen ajna vido al la paĝvojoj interne. Posedi la reton ne estas permeso silente anstataŭigi la fido-modelon de la aplikaĵo.
La adreso apartenas al sesio, ne al persono
Flua rikordo portanta adreson el la tunela gamo estas komenca punkto, ne respondo. Kunligu tiun adreson kaj tempostampon al la sesia asigno aktiva en tiu momento, ĉar tiu adreso povas esti realdonita al malsama sesio horon poste. Statika adresado estas unu maniero konservi tiun rilaton, kaj ne la sola.
Kie traduka paŝo kunfalas plurajn aparatojn en unu fontan adreson supre de la sensilo, la kunligo povas nomi nur la komunan kluzan sesion. Komuna konto aŭ atestilo uzata de pluraj homoj limigas atribuadon, kiel ajn kompleta la retaj datumoj aspektas. Ambaŭ apartenas al la raporto kiel limoj, ne kiel antaŭrimedoj por poste.
Registru la tempzonon, la horloĝan fonton, la observan punkton kaj ĉiun tradukan limon inter ili. Foresto meritas la saman zorgon kiel ĉeesto, ĉar mankanta rikordo povas signifi, ke flua ero malvalidiĝis, ke sensilo neniam vidis la paketon aŭ ke aplikaĵa protokolo estis malŝaltita.
Projektu por la deklarita celo, poste pruvu la traktadon
Post kiam la demando estas fiksita, difinu, kiuj kampoj necesas, kiu rajtas legi ilin kaj kiom longe ili estas konservataj. Kolekti pli ĉar stokado estas malmultekosta kreas respondecon, kiu supervivas la enketon. La privateca modelo en RFC 6973 kadras korelacion, malĝustan atribuadon kaj nenecesan kolektadon kiel dizajnajn problemojn, ne kiel postpensojn.
Gardu la mapadon kaj la rikordojn kiel unu objekton, ĉar ĉiu sola estas multe malpli sentema ol la paro. Poste validigu la dizajnon kontraŭ aktiveco, kiun vi rajtas generi kaj jam komprenas, per la plej malgranda peto, sur kiu la raporto dependos. Traktado, kiu ne povas reprodukti konatan eventon, ne reproduktos ankaŭ nekonatan. Raportu la eventon, kiun la pruvoj subtenas, per la vortoj, kiujn la pruvoj permesas, kaj lasu la leganton mem atingi la pli grandan konkludon.
Skribu la limojn apud la trovo: kio estis kunligita, kio tradukita kaj kiu protokolo restis silenta. Trovo, kiu deklaras siajn proprajn limojn, supervivas revizion, kiun memfida resumo ne supervivas. Tio estas la diferenco inter pruvo kaj rakonto pri pruvo.