Ĉe SOCKS5, aŭtentigo estas intertraktata antaŭ ol la kliento sendas sian celpeton. Tio igas fruan fiaskon de akreditaĵoj malsama okazaĵo ol fiasko de FTP, HTTPS aŭ alia aplikaĵo malantaŭ la prokurilo.

La saluto de la kliento listigas la aŭtentigmetodojn, kiujn ĝi subtenas. La servilo elektas unu metodon el tiu listo kaj resendas la elekton. Valoro 0xff signifas, ke neniu proponita metodo estas akceptebla, kaj la konekto devas fermiĝi. La kliento ne simple provas ĉiun metodon ĉe la servila flanko post kiam pasvorto malsukcesas.

Kion regas la ordo de Dante

Dante 1.4.x nomas la protokolnivelan agordon socksmethod. Ĝia dokumentaro diras, ke metodoj estas listigitaj en ordo de prefero. Por politiko, kiu permesas ambaŭ metodojn, ĉi tiu deklaracio preferas uzantnomon/pasvorton kiam la kliento proponas ĝin:

socksmethod: username none

Inversigi la liston preferas neaŭtentigitan aliron kiam ambaŭ metodoj estas proponitaj:

socksmethod: none username

Ĉi tiuj estas alternativaj metoddeklaracioj, ne kompleta servila agordo. Aŭskultaj interfacoj, permesitaj klientoj, celreguloj kaj iuj ajn regulspecifaj aŭtentiglimigoj ankoraŭ gravas.

Permesi none havas konkretan sekvon: kliento proponanta nur nenian aŭtentigon povas esti akceptita laŭ la aplikeblaj reguloj. Meti username unue ne igas liston enhavantan none postulon, ke ĉiuj provizu pasvorton.

Unue elektu la postulon

Se ĉiu permesita kliento devas aŭtentigi per uzantnomo/pasvorto, agordu tiun postulon konsekvence en la tutmondaj kaj aplikeblaj reguloj anstataŭ aldoni none kiel ĝeneralan kongruecan riparon. Se anonima aliro estas intenca por limigita klienta grupo, faru la grupon kaj ĝiajn permesitajn celojn eksplicitaj.

Dante ankaŭ havas clientmethod, kiu koncernas kontrolojn faratajn kiam la TCP-kliento konektiĝas, antaŭ SOCKS-intertraktado. Ĝi estas aparta tavolo de la metodoj interŝanĝataj en la SOCKS5-saluto. Agordaj fragmentoj uzantaj pli malnovan ŝlosilvorton method devus esti legitaj laŭ la manlibro de la instalita versio de Dante.

Kiam du klientoj kondutas malsame, komparu kion ĉiu proponas, kion Dante elektas, kaj ĉu la subintertraktado de la elektita metodo sukcesas. Poste inspektu la SOCKS-celan respondon. Ĉi tiu sinsekvo identigas mankan akreditaĵan retroalvokon sen atribui ĉiun fiaskon al FTP aŭ blinde ŝanĝi la aŭtentigpolitikon de la servilo.

Finfine, SOCKS5-a aŭtentigo per uzantnomo/pasvorto ne ĉifras la pasvortinterŝanĝon. Uzu taŭge protektitan transporton aŭ reton kiam tiuj akreditaĵoj bezonas konfidencon.

Rilataj artikoloj