നീളമുള്ള SOCKS ചെയിൻ അടുത്ത ഹോപ്പ് സ്വയമേവ മറയ്ക്കുന്നില്ല

ചെയിൻ ഓരോ കണക്ഷനും ആരാണ് തുറക്കുന്നത് എന്ന് മാറ്റുന്നു. പട്ടികയിൽ മറ്റൊരു SOCKS വിലാസം ചേർക്കുന്നത് കൊണ്ട് മാത്രം എൻക്രിപ്ഷൻ കൂട്ടിച്ചേർക്കുന്നില്ല.

ഈ ചെയിൻ സ്വയം നിർമ്മിക്കുന്ന ഒരു ക്ലയന്റ് പരിഗണിക്കുക:

application → SOCKS A → SOCKS B → website

ആദ്യം A-യോട് B-യുമായി ബന്ധിപ്പിക്കാൻ ആവശ്യപ്പെടുന്നു. ആ സ്ട്രീം വഴി പിന്നീട് B-യുമായി വെബ്സൈറ്റിലേക്കുള്ള കണക്ഷനെക്കുറിച്ച് ചർച്ച ചെയ്യാം. ക്ലയന്റിൽ നിന്ന് A-യിലേക്കുള്ള ഗതാഗതം രണ്ട് ചർച്ചകളും എൻക്രിപ്ഷൻ ഇല്ലാതെ കൊണ്ടുപോകുന്നെങ്കിൽ, ആ ലിങ്കിലുള്ള മതിയായ പ്രാപ്തിയുള്ള നിരീക്ഷകന് ക്ലയന്റ് അയച്ച സെറ്റപ്പ് ബൈറ്റുകൾ വായിക്കാം. പുറത്തുള്ള TCP ലക്ഷ്യസ്ഥാനം നിരീക്ഷകന്റെ ഏക സാധ്യമായ തെളിവല്ല.

ചെയിനിനെ സംരക്ഷിത ആപ്ലിക്കേഷൻ കൈമാറ്റത്തിൽ നിന്ന് വേർതിരിക്കുക

TLS സെഷൻ ആരംഭിച്ചതിന് ശേഷം HTTPS-ന് വെബ്സൈറ്റിന്റെ ആപ്ലിക്കേഷൻ ഉള്ളടക്കം സംരക്ഷിക്കാനാകും. മുൻപത്തെ SOCKS സെറ്റപ്പ് സന്ദേശങ്ങളെ അത് പിന്നോട്ട് എൻക്രിപ്റ്റ് ചെയ്യുന്നില്ല. SOCKS5-ന്റെ ഉപയോക്തൃനാമം/പാസ്വേഡ് പ്രാമാണീകരണവും എൻക്രിപ്റ്റ് ചെയ്ത ഗതാഗതമല്ല.

ക്ലയന്റും ആദ്യ ഹോപ്പും തമ്മിലുള്ള എൻക്രിപ്റ്റ് ചെയ്ത ക്രമീകരണം ആ ലിങ്കിലെ ദൃശ്യത മാറ്റുന്നു. അതിന് ഇപ്പോഴും ഒരു ഓപ്പറേറ്ററും ഡീക്രിപ്റ്റ് ചെയ്ത സ്ട്രീം കൈവശം വയ്ക്കുന്ന മറ്റൊരു അന്ത്യബിന്ദുവും ഉണ്ട്. ചെയിൻ കണ്ടെത്താനാകില്ല എന്ന് അവകാശപ്പെടുന്നതിന് പകരം ആ വിശ്വാസാതിർത്തി വിവരിക്കുക.

സെർവറിൽ ക്രമീകരിച്ച മാതൃ റൂട്ട് മറ്റൊരു ടോപ്പോളജിയാണ്. A ആന്തരികമായി B തിരഞ്ഞെടുക്കുന്നെങ്കിൽ, ക്ലയന്റ് അതിന്റെ ആദ്യ കണക്ഷനിൽ ഇടനിലക്കാരുടെ പൂർണ്ണ പട്ടിക അയച്ചിരിക്കണമെന്നില്ല. ഓരോ ചെയിനും ഓരോ ഹോപ്പും ഒരേ രീതിയിൽ വെളിപ്പെടുത്തുന്നു എന്ന് അവകാശപ്പെടരുത്.

ഉപയോഗപ്രദമായ സ്വകാര്യതാ വിലയിരുത്തലിന് നിരീക്ഷകനെയും ലിങ്കിനെയും പ്രോക്സി ചർച്ചയെയും TLS അതിർത്തികളെയും പേരെടുത്ത് പറയുക. B-യുടെ പുറത്തുകടക്കൽ നിരീക്ഷിക്കുന്ന വെബ്സൈറ്റും ക്ലയന്റിന്റെ ആദ്യ കണക്ഷൻ കാണുന്ന ആക്സസ്-നെറ്റ്വർക്ക് നിരീക്ഷകനും വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. ഹോപ്പുകൾ എണ്ണുന്നത് മാത്രം രണ്ടിനും ഉത്തരം നൽകുന്നില്ല.