Malĝusta VPN-provo: kiu klaso de akreditaĵo transiris la limon?
Malsukcesa provo eble sendis nenion, aŭ transdonis pasvorton al tiu, kiu respondis. Klasifiku la artefakton antaŭ ol decidi, kion revoki.
Vi konektiĝis al malĝusta VPN, kaj la kliento raportis fiaskon. Ĉu tio gravis dependas de tio, kio pasis laŭ la lineo antaŭ la fiasko, kaj la vorto mem ne diras tion al vi. Iuj manpremoj entute ne portas sekreton, dum aliaj transdonas pasvorton al ĉiu, kiu respondis al la adreso. Konstatu, kiu el la du kazoj okazis, antaŭ ol vi revokos ion ajn.
Haltu kaj konservu la pruvojn
Konservu la klientan protokolon, la elektitan profilon, la adreson, kiun vi tajpis, kaj la proksimuman tempon. Notu ilin ie ekster la kliento, ĉar redakto de profilo aŭ reinstalo detruas la rikordon, kiun vi bezonos. Haltigu ĉiun pluan provon ĝis la finpunkto estos konfirmita laŭ vojo, kiun vi kontrolas.
Neniam afiŝu neredaktitan profilon aŭ protokolon en publikan forumon dum vi demandas, ĉu la provo estis sekura. Tiuj dokumentoj ofte enhavas vojon al privata ŝlosilo, internan gastigantan nomon aŭ ĵetonon, do redaktu unue kaj kunhavigu kun la administranto, kiu posedas la finpunkton.
Kio povas transiri la limon
Plej multa konfuzo venas de tio, ke ĉiu fiasko traktatas kiel unu speco de evento. Kvar malsamaj aferoj povas atingi la alian flankon: publika atestilo, subskribo pruvanta, ke ŝlosilo estis uzita, pasvorto aŭ unufoja kodo, kaj dosiero, kiun vi mem elektis. Ĉiu havas sian propran sekvon kaj sian propran riparon. Klasifiki la artefakton estas la paŝo, kiu decidas ĉion postan.
La atestila kazo estas la plej milda, ĉar tio, kio vojaĝas, estas publika laŭdezajne kaj ĝiaj identigaj kampoj jam videblas al ĉiu, kiu konektiĝas. Subskribo super defio diras, ke la ŝlosilo estis uzita, ne ke ĝi estis sendita. Pasvorto estas la kontraŭa kazo: kiu ajn ricevas ĝin, povas provi ĝin aliloke, kaj servo konstruita por kontroli pasvortojn estas la celata ricevanto de ĝuste tiu valoro.
Pruvo de ŝlosilo ne estas alŝuto de ŝlosilo
Moderna TLS tenas tiujn du ideojn apartaj intence. RFC 8446 priskribas la mesaĝon CertificateVerify, en kiu la kliento subskribas defion per la privata ŝlosilo kongrua kun sia atestilo. La subskribo pruvas posedon sen porti la ŝlosilon, tial atestile aŭtentikigita provo ne estas aŭtomate ŝlosila kompromito.
Tiu trankviligo havas limon, kiun indas mencii. La pruvo montras, ke la ŝlosilo partoprenis en tiu interŝanĝo, kaj ĝi diras nenion pri tio, kion loka programo sur la maŝino eble jam legis. Ĝi ankaŭ diras nenion pri tio, kiom malproksimen nekonata provo efektive iris, tial la protokolo ankoraŭ pli gravas ol la teorio.
Pasvortoj sekvas tute alian fidmodelon. Koncentrilo agordita kun ekstera kontrolilo povas plusendi la prezentitan valoron, do ricevi ĝin estas la celata funkcio, kaj malĝusta celo estas reala elmontro anstataŭ teoria.
Rekonstruu la provon el la protokolo
Kvar faktoj rekonstruas la provon: la adreso, kun kiu efektive kontaktiĝis, ĉu la identeco de la servilo estis validigita, kiu aŭtentikiga metodo elektiĝis, kaj kie la procezo haltis. Ĉiu aperas en klienta protokolo, kaj ĉiu ekskludas alian version. Eraro pri itineroj aŭ asignita adreso diras nenion pri tio, kio jam estis sur la lineo, ĉar la aŭtentikigo eble finiĝis antaŭ ol la tunela agordo fiaskis.
Eltiru tiujn faktojn el la propra protokolo de la kliento, ne el memoro. Mallarĝa filtrilo tenas la eligon sufiĉe mallonga por redakti kaj kunhavigi:
grep -n -i -E 'verify|authentication|certificate|error|timeout' client.log | tail -30Ne anstataŭigu la gastigantan nomon per io ajn el ĉi tio. Konata nomo, nuna DNS-respondo kaj atestila averto montrata de la programaro priskribas la nunon, ne la antaŭan konekton. Ankaŭ pasvorta invito ne estas pruvo, ke io estis sendita, ĉar la kliento eble fiaskis antaŭ ol ĝin sendi.
Decidu, poste agu
La decido sekvas el la artefakto, ne el tio, kiom alarme la fiasko aspektis. Legu la kvar vicojn kontraŭ la faktoj, kiujn vi rekonstruis:
| Decision | Evidence that puts you here | Evidence that rules it out |
|---|---|---|
| Change the password now | A password was submitted and a server reply arrived | The log stops before any submission |
| Review active sessions | A one-time code was accepted by the wrong endpoint | The code was never sent, or was rejected before use |
| Revoke and reissue | The file you selected contained key material, not just settings | The upload was a profile with no embedded key |
| No further action | The attempt ended before any authentication value was offered | You later find an earlier attempt you had forgotten |
Se pasvorto atingis neintencitan servon, ŝanĝu ĝin per la kontoadministra kanalo kaj kontrolu, kie alie ĝi estis reuzita. Sendata unufoja kodo fermas tiun vojon, sed sesio kreita per ĝi ne, do petu la identecadministranton revizii sesiojn. Se ŝlosildosiero efektive alŝutiĝis, sekvu la revokprocezon de la eldonanta organizo anstataŭ atendi pruvon de misuzo.
Poste notu la limigitan rezulton: kio estis sendita, kio restas nekonata, kaj kiu akreditaĵo bezonas agon. Ĝuste tiu rikordo estos petata de posta revizio, kaj ĝi pli utilas ol ajna el la du komfortaj konkludoj.