WSS ടണലിന്റെ എൻക്രിപ്ഷൻ ആപ്പിലല്ല, TLS ടെർമിനേറ്ററിൽ അവസാനിക്കുന്നു

സുരക്ഷിത WebSocket-നുള്ളിൽ വഹിക്കുന്ന ടണലിന് ക്ലയന്റ് അതിൽ ഇട്ടത്രയും എൻക്രിപ്ഷൻ മാത്രമേ ഉള്ളൂ, അതിൽ കൂടുതലില്ല. wss:// സ്കീം പറയുന്നത് TLS ഒരു ഹോപ്പിൽ ഒരു കണക്ഷനെ സംരക്ഷിക്കുന്നു എന്നാണ്. WebSocket സന്ദേശങ്ങൾക്കുള്ളിലെ ബൈറ്റുകൾ വെവ്വേറെ സംരക്ഷിക്കപ്പെടുന്നുണ്ടോ എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല, ഇടയിൽ എന്തെങ്കിലും TLS അവസാനിപ്പിക്കുമ്പോൾ നിങ്ങളുടെ ട്രാഫിക് ആർക്ക് വായിക്കാമെന്ന് തീരുമാനിക്കുന്നത് ഈ വ്യത്യാസമാണ്.

ഒന്നുപോലെ തോന്നുന്ന രണ്ട് പാളികൾ

സുരക്ഷിത WebSocket എന്നത് TLS-ആണ്, അതിന് മുകളിൽ WebSocket ഹാൻഡ്ഷേക്ക് നടക്കുന്നു, RFC 6455 അതിന്റെ കണക്ഷൻ, സുരക്ഷാ വിഭാഗങ്ങളിൽ വിവരിക്കുന്നതുപോലെ. TLS പാളി സർവറിനെ പ്രാമാണീകരിച്ച് സ്ട്രീം എൻക്രിപ്റ്റ് ചെയ്യുന്നു, പിന്നീട് WebSocket പാളി ആപ്ലിക്കേഷൻ അയക്കാൻ തീരുമാനിക്കുന്നത് ഫ്രെയിം ചെയ്യുന്നു.

ഇവ രണ്ട് സ്വതന്ത്ര തീരുമാനങ്ങളാണ്, മുഴുവൻ പാതയിലും ഒരു പൂട്ട് മാത്രം വരയ്ക്കുന്ന ഡയഗ്രം രണ്ടാമത്തേത് മറയ്ക്കുന്നു. TLS കണക്ഷൻ ആര് അവസാനിപ്പിക്കുന്നു എന്ന് ചോദിക്കുക. പിന്നീട് ക്ലയന്റ് ഓരോ സന്ദേശത്തിനുള്ളിലും എന്ത് ഇടുന്നു എന്ന് ചോദിക്കുക. വിന്യാസത്തെക്കുറിച്ചുള്ള ബാക്കിയെല്ലാം ഈ രണ്ട് ഉത്തരങ്ങളിൽ നിന്ന് വരുന്നു.

ഡിസൈൻ A: ഗതാഗതം മാത്രമാണ് എൻക്രിപ്ഷൻ

ലളിതമായ ഡിസൈനിൽ, ക്ലയന്റ് അസംസ്കൃത IP പാക്കറ്റുകൾ എടുത്ത് WebSocket സന്ദേശങ്ങളിൽ പൊതിയുന്നു. അകത്ത് ഒന്നും എൻക്രിപ്റ്റ് ചെയ്തിട്ടില്ല, അതിനാൽ TLS സെഷൻ കൈവശമുള്ള ഘടകം സാധാരണ ടെക്സ്റ്റ് പേലോഡുകൾ വായിക്കുന്നു. ആ ഘടകം നിങ്ങളുടെ സ്വന്തം ടണൽ സർവർ ആണെങ്കിൽ, അതാണ് ഉദ്ദേശിച്ച അവസാന പോയിന്റ്, ഡിസൈൻ സുസ്ഥിരമാണ്, കാരണം സർവർ എന്തായാലും ട്രാഫിക് കാണുമായിരുന്നു.

പാതയിൽ ഒരു പരിശോധന പ്രോക്സി ഇരുന്ന്, ക്ലയന്റ് വിശ്വസിക്കുന്ന സർട്ടിഫിക്കറ്റ് ഉപയോഗിച്ച് TLS അവസാനിപ്പിക്കുമ്പോൾ അത് മറ്റൊരു ക്രമീകരണമാകുന്നു. ആ പ്രോക്സിക്ക് ഇപ്പോൾ സർവറിന് ഉണ്ടായിരുന്ന അതേ സാധാരണ ടെക്സ്റ്റ് ഉണ്ട്, എത്ര WebSocket ഫ്രെയിമിംഗ് ചേർത്താലും അത് മാറുന്നില്ല. ക്ലയന്റിന്റെ വിശ്വാസ സംഭരണി ഈ ഫലം ടണൽ തുറക്കുന്നതിന് വളരെ മുൻപേ തീരുമാനിച്ചിരുന്നു, കാരണം ആ പേരിന് ആ സർട്ടിഫിക്കറ്റ് സ്വീകരിക്കാൻ അത് തിരഞ്ഞെടുത്തു. പ്രോക്സി അഭ്യർത്ഥിച്ച ഹോസ്റ്റും ഓരോ സന്ദേശത്തിന്റെയും വലിപ്പവും കാണുന്നു, അത് കൂടുതൽ ഒന്നും ഡീക്രിപ്റ്റ് ചെയ്യാതെ ഒരുപാട് പ്രവർത്തനങ്ങളുടെ വിരലടയാളം എടുക്കാൻ മതിയാകും.

ഡിസൈൻ B: പേലോഡ് സ്വന്തം കീകൾ വഹിക്കുന്നു

രണ്ടാമത്തെ ഡിസൈനിൽ, ക്ലയന്റ് തന്റെ പാക്കറ്റുകൾ സ്വന്തം പിയർ ഐഡന്റിറ്റിയും കീ കൈമാറ്റവുമുള്ള VPN പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് എൻക്രിപ്റ്റ് ചെയ്ത് പ്രാമാണീകരിക്കുന്നു, പിന്നീട് ഫലം WebSocket സന്ദേശങ്ങൾക്കുള്ളിൽ വഹിക്കുന്നു. ഇവിടെ പുറം TLS അവസാനിപ്പിക്കുന്നത് ട്രാഫിക്കല്ല, സൈഫർടെക്സ്റ്റ് വെളിപ്പെടുത്തുന്നു. സന്ദേശങ്ങളുടെ വലിപ്പവും സമയവും പ്രോക്സിക്ക് കാണാം, പേലോഡിൽ മറ്റൊന്നുമില്ല. ഇത് വളരെ ചെറിയ എക്സ്പോഷറാണ്, എന്നിട്ടും ഇത് ഒരു അവലോകനത്തിൽ പേരെടുത്ത് പറയേണ്ട മെറ്റാഡാറ്റയാണ്, കൈവീശി തള്ളേണ്ടതല്ല.

ആന്തരിക പ്രോട്ടോക്കോളിന്റെ സ്വന്തം എൻഡ്പോയിന്റുകൾ ഇപ്പോഴും സാധാരണ ടെക്സ്റ്റ് കാണുന്നു, അതാണ് ഈ ക്രമീകരണത്തിന്റെ ഉദ്ദേശ്യവും അതിന്റെ പരിധിയും. എൻഡ്പോയിന്റിലെ ഒരു ഘടകത്തിന് എൻക്രിപ്ഷന് മുൻപോ ഡീക്രിപ്ഷന് ശേഷമോ ഡാറ്റ വായിക്കാൻ അധികാരമുണ്ടെങ്കിൽ, അധിക പാളി അതിനെ നിയന്ത്രിക്കുന്നില്ല. കീകളും അവ കൈകാര്യം ചെയ്യുന്ന സോഫ്റ്റ്വെയറും പ്രധാനപ്പെട്ട അതിർത്തിയായി തുടരുന്നു.

VPN ലേബൽ, പരിചിതമായ ക്ലയന്റ് ഐക്കൺ അല്ലെങ്കിൽ മാർക്കറ്റിംഗ് പേജ് ഈ ഡിസൈൻ നിലനിൽക്കുന്നു എന്നതിന് തെളിവല്ല. പേലോഡ് ഫോർമാറ്റ് വായിക്കുന്നത് തെളിവാണ്.

സാധാരണ ടെക്സ്റ്റ് യഥാർത്ഥത്തിൽ എവിടെ പ്രത്യക്ഷപ്പെടുന്നു എന്ന് കണ്ടെത്തുക

URL സ്കീം നിങ്ങൾക്ക് ഒരു വസ്തുത നൽകുന്നു, ബാക്കി ഇന്റർഫേസുകളിൽ നിന്ന് എടുക്കുക. താഴെയുള്ള പരിശോധനകൾ ക്രമത്തിൽ നടത്തുക, കാരണം ഓരോന്നും അടുത്തതിനെ ചുരുക്കുന്നു:

ss -tnp | grep -E ':(443|8443)\b'
ip -br link show type tun
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
tcpdump -ni tun0 -c 5 -X

പുറം കണക്ഷനിൽ തുടങ്ങുക. TLS പോർട്ടിലേക്ക് ഒരു ദീർഘകാല TCP സെഷൻ ഉണ്ടായിരിക്കുന്നതാണ് WebSocket വാഹകന്റെ രൂപം, ബന്ധമില്ലാത്ത ഹോസ്റ്റിലേക്കുള്ള രണ്ടാം സെഷൻ കൂടുതൽ ആഴത്തിൽ നോക്കുന്നതിന് മുൻപ് വിശദീകരണം അർഹിക്കുന്നു. പിന്നീട് ക്ലയന്റിലെ ടണൽ ഇന്റർഫേസ് കണ്ടെത്തുക, കാരണം tun അല്ലെങ്കിൽ tap ഉപകരണം പറയുന്നത് ക്ലയന്റ് ഒരു ആപ്ലിക്കേഷൻ സ്ട്രീം പ്രോക്സി ചെയ്യുന്നതിന് പകരം IP പാക്കറ്റുകൾ കൈകാര്യം ചെയ്യുന്നു എന്നാണ്.

ടണൽ ഇന്റർഫേസിലെ ക്യാപ്ചർ സാധാരണയായി പേലോഡ് ചോദ്യം തീർക്കുന്നു. അവിടെ വായിക്കാവുന്ന ഹെഡറുകൾ ഉണ്ടെങ്കിൽ ആന്തരിക പാക്കറ്റുകൾ ഒരിക്കലും വെവ്വേറെ എൻക്രിപ്റ്റ് ചെയ്തിട്ടില്ല എന്നാണ്, ഉയർന്ന എൻട്രോപ്പി പേലോഡുകൾ എങ്കിൽ എൻക്രിപ്റ്റ് ചെയ്തിട്ടുണ്ട് എന്നാണ്. പുറം ഇന്റർഫേസിലും ക്യാപ്ചർ ആവർത്തിച്ച് രണ്ടും താരതമ്യം ചെയ്യുക: രണ്ടും ക്രമരഹിതമായി തോന്നുന്നുവെങ്കിൽ, ആന്തരിക പാളി പുറം പാളിക്ക് പിൻവലിക്കാനാകാത്ത ജോലി ചെയ്യുന്നു.

യഥാർത്ഥത്തിൽ നൽകിയ വിശ്വാസം അവലോകനം ചെയ്യുക

ഇൻസ്റ്റാൾ ചെയ്ത കോർപ്പറേറ്റ് റൂട്ട് സർട്ടിഫിക്കറ്റ് ക്ലയന്റിന്റെ വിശ്വാസ സംഭരണിയെക്കുറിച്ചുള്ള വസ്തുതയാണ്, ഏതെങ്കിലും പ്രോക്സി എന്ത് ലോഗ് ചെയ്യുന്നു അല്ലെങ്കിൽ പരിശോധിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള പ്രസ്താവനയല്ല. CA ഉള്ളതിൽ നിന്ന് സ്വഭാവം അനുമാനിക്കുന്നതിന് പകരം വിന്യസിച്ച നയവും യഥാർത്ഥ കണക്ഷൻ പാതയും സ്ഥാപിക്കുക.

നിയന്ത്രിത ഉപകരണങ്ങളിൽ, ഏത് ഘടകമാണ് TLS അവസാനിപ്പിക്കുന്നത്, ക്ലയന്റ് പിൻ ചെയ്ത സർട്ടിഫിക്കറ്റ് പരിശോധിക്കുന്നുണ്ടോ പൊതു സർട്ടിഫിക്കറ്റ്, പേലോഡ് ഫോർമാറ്റ് എന്ത് എന്ന് അഡ്മിനിസ്ട്രേറ്ററിനോട് ചോദിക്കുക. ആ മൂന്ന് ഉത്തരങ്ങൾ പിന്നീട് നിങ്ങൾക്ക് സമർത്ഥിക്കാനാകുന്ന ഒരു കണ്ടെത്തൽ നൽകുന്നു.

ഫലം ഒരു വിധിയല്ല, ഒരു അതിർത്തിയായി എഴുതുക. "TLS പരിശോധന പ്രോക്സിയിൽ അവസാനിക്കുന്നു, ആന്തരിക പേലോഡ് എൻഡ്പോയിന്റുകൾക്ക് മാത്രമുള്ള കീകൾ ഉപയോഗിച്ച് വെവ്വേറെ എൻക്രിപ്റ്റ് ചെയ്തിരിക്കുന്നു" എന്നത് വിതരണക്കാരൻ മാറിയാലും നിലനിൽക്കുന്ന പരിശോധിക്കാവുന്ന പ്രസ്താവനയാണ്. "WebSockets സുരക്ഷിതമാണ്" അല്ല.