VPN-ന്റെ ഉള്ളിൽ OAuth: ഏത് ഘട്ടങ്ങൾക്ക് ഇപ്പോഴും TLS വേണം

സ്വകാര്യ റൂട്ടിംഗ് ആരാണ് സർവറിൽ എത്തുന്നത് എന്ന് തീരുമാനിക്കുന്നു; OAuth-ന്റെ കൈമാറ്റ നിയമങ്ങൾ ഓരോ സന്ദേശവും എങ്ങനെ സഞ്ചരിക്കുന്നു എന്ന് തീരുമാനിക്കുന്നു. ബ്രൗസർ, അനുമതി സർവർ, ടോക്കൺ എന്റ്പോയിന്റ്, റിസോഴ്സ് സർവർ എന്നിവയെല്ലാം ഒരേ VPN-ന് പിന്നിൽ ആകാം, എന്നിട്ടും വ്യത്യസ്ത ഘട്ടങ്ങളിലൂടെ സന്ദേശങ്ങൾ കൈമാറാം. ഓരോ ഘട്ടത്തിനും സ്വന്തം കൈമാറ്റ ആവശ്യകതയുണ്ട്, VPN അവയിൽ ഒന്നും അയച്ചുകൊടുക്കുന്നില്ല. VPN-ന്റെ അതിരും പ്രോട്ടോക്കോളിന്റെ അതിരും രണ്ട് വ്യത്യസ്ത വരകളാണ്.

നെറ്റ്വർക്ക് വിശ്വസനീയമാണോ എന്ന് ചോദിക്കുന്നത് നിർത്തി, ഏത് കൈമാറ്റം ഏത് അതിർവരമ്പ് കടക്കുന്നു എന്ന് ചോദിക്കാൻ തുടങ്ങിയാൽ തീരുമാനം എളുപ്പമാണ്.

നെറ്റ്വർക്ക് അനുസരിച്ചല്ല, ഘട്ടം അനുസരിച്ച് തീരുമാനിക്കുക

എന്റ്പോയിന്റുകൾ വെവ്വേറെ എഴുതുക: അനുമതി എന്റ്പോയിന്റ്, ടോക്കൺ എന്റ്പോയിന്റ്, റീഡയറക്ട് URI, റിസോഴ്സ് സർവറിന്റെ URL, TLS അവസാനിക്കുന്ന ബിന്ദു, VPN ഗേറ്റ്വേ. തുടർന്ന് ഓരോ അഭ്യർത്ഥനയും ഏത് കക്ഷി തുടങ്ങുന്നു, പ്രതികരണം എവിടെ പോകുന്നു എന്ന് അടയാളപ്പെടുത്തുക.

ഗേറ്റ്വേയിൽ അവസാനിക്കുന്ന VPN ആ ഗേറ്റ്വേ വരെയുള്ള ഭാഗം എൻക്രിപ്റ്റ് ചെയ്യുന്നു. അഭ്യർത്ഥന അതിന് പിന്നിൽ സാധാരണ HTTP ആയി തുടരാം, മുൻ ഭാഗം എൻക്രിപ്റ്റ് ചെയ്തതുകൊണ്ട് ആ ശേഷിക്കുന്ന ഘട്ടം HTTPS ആയി മാറിയിട്ടില്ല. ആ തുടർച്ചയാണ് പ്രോട്ടോക്കോളിന് പ്രധാനമായ ഘട്ടം. ആദ്യ ചാട്ടം എൻക്രിപ്റ്റ് ചെയ്യുന്നത് രണ്ടാം ചാട്ടത്തെ സുരക്ഷിതമാക്കുന്നില്ല.

കൈമാറ്റം സേവന ഐഡന്റിറ്റി പരിശോധനയും വഹിക്കുന്നു. ബ്രൗസർ ആപ്ലിക്കേഷന്റെ URL-നുള്ള സർട്ടിഫിക്കറ്റ് സാധൂകരിക്കുന്നു; VPN ആ പരിശോധന ബ്രൗസറിന്റെ പേരിൽ നടത്തുന്നില്ല, സാധൂകരിക്കാത്ത എന്റ്പോയിന്റിനെ സ്വീകാര്യമാക്കുന്നുമില്ല. ക്ലയന്റ് വിളിക്കുന്നു എന്ന് കരുതുന്ന എന്റ്പോയിന്റിനെ സർട്ടിഫിക്കറ്റ് പേരിടുന്നു. ഗേറ്റ്വേയിലേക്കുള്ള ടണൽ ആ എന്റ്പോയിന്റിനെ പുനർനാമകരണം ചെയ്യുന്നില്ല, സാധൂകരിക്കുന്നുമില്ല.

അനുമതി പ്രതികരണവും റീഡയറക്ട് URI-യും

OAuth-ന്റെ നിലവിലെ മികച്ച സുരക്ഷാ സമ്പ്രദായം എൻക്രിപ്റ്റ് ചെയ്യാത്ത കണക്ഷനുകളിലൂടെ അനുമതി പ്രതികരണങ്ങൾ അയക്കുന്നത് വിലക്കുന്നു. ഇതിൽ അനുമതി കോഡോ ടോക്കണുകളോ ക്ലയന്റിലേക്ക് തിരികെ കൊണ്ടുപോകുന്ന റീഡയറക്ടും ഉൾപ്പെടുന്നു, പ്രാരംഭ അഭ്യർത്ഥന മാത്രമല്ല.

അതേ മാർഗ്ഗനിർദ്ദേശം നിർദ്ദിഷ്ട നേറ്റീവ് ക്ലയന്റ് ലൂപ്പ്ബാക്ക് കേസ് ഒഴികെ HTTP റീഡയറക്ട് URI-കൾ അനുവദിക്കുന്നില്ല. ആന്തരിക ഹോസ്റ്റ്നാമം പുതിയ ഒഴിവാക്കൽ സൃഷ്ടിക്കുന്നില്ല, VPN-നുള്ളിൽ മാത്രം പരിഹരിക്കുന്ന DNS നാമം സ്കീം അങ്ങനെ പറയുന്നുവെങ്കിൽ ഇപ്പോഴും HTTP URL ആണ്. രജിസ്റ്റർ ചെയ്ത URI-യിലെ സ്കീം പരിശോധിക്കുക, ഹോസ്റ്റ്നാമം മാത്രമല്ല.

കൃത്യമായ HTTPS റീഡയറക്ട് URI അനുമതി സർവറിൽ രജിസ്റ്റർ ചെയ്ത് ക്ലയന്റിൽ സർട്ടിഫിക്കറ്റ് സാധൂകരണം ഓണായി നിർത്തുക. HTTPS ആവശ്യകത അടിച്ചമർത്തുന്ന വികസന ഷോർട്ട്കട്ട്, അത് അനുകരിക്കേണ്ട പ്രൊഡക്ഷൻ കോൺഫിഗറേഷനിൽ നിന്ന് വ്യത്യസ്തമായി പെരുമാറുന്ന ഒഴുക്ക് സൃഷ്ടിക്കുന്നു.

ടോക്കൺ എന്റ്പോയിന്റും ബെയറർ ടോക്കൺ അഭ്യർത്ഥനകളും

ടോക്കൺ അഭ്യർത്ഥന പ്രവേശനത്തിന് കൈമാറാവുന്ന ക്രെഡൻഷ്യലുകളോ കോഡോ വഹിക്കുന്നു. സംരക്ഷിക്കാത്ത ഘട്ടത്തിലൂടെ അത് അയക്കുന്നത്, ചുറ്റുമുള്ള നെറ്റ്വർക്ക് സ്വകാര്യമാണെങ്കിലും, റിസോഴ്സ് സർവർ പിന്നീട് വിശ്വസിക്കുന്ന വസ്തുതകൾ വെളിപ്പെടുത്തുന്നു. അഭ്യർത്ഥന വായിക്കാൻ കഴിയുന്ന പ്രോക്സിക്ക് അത് വഹിക്കുന്ന ക്രെഡൻഷ്യലും വായിക്കാം.

ബെയറർ ടോക്കൺ ഉപയോഗിക്കുന്ന റിസോഴ്സ് അഭ്യർത്ഥനകൾക്ക്, ആ സ്പെസിഫിക്കേഷനിൽ TLS നടപ്പാക്കാനും ഉപയോഗിക്കാനും RFC 6750 നിർബന്ധമാക്കുന്നു. ഓഫീസ് സബ്നെറ്റിനെ വിശ്വസനീയം എന്ന് വിളിക്കുന്നത് പ്ലെയിൻടെക്സ്റ്റ് ബെയറർ വിന്യാസത്തിന് ആവശ്യമായ പൊതു പ്രോട്ടോക്കോൾ ഒഴിവാക്കലല്ല.

രണ്ട് ഘട്ടങ്ങൾക്കും പ്രമാണീകരിച്ച സുരക്ഷിത എന്റ്പോയിന്റ് URL-കൾ ഉപയോഗിക്കുക. ഒരു ലൈബ്രറി HTTP ടോക്കൺ എന്റ്പോയിന്റ് വിളിക്കാൻ വിസമ്മതിക്കുന്നുവെങ്കിൽ, ആ വിസമ്മതം സ്പെസിഫിക്കേഷൻ പ്രവർത്തിക്കുന്നതാണ്, ഒഴിവാക്കേണ്ട കോൺഫിഗറേഷൻ തകരാറല്ല. ആ URL റൺടൈമിൽ കണ്ടെത്തുന്നതിന് പകരം ക്ലയന്റ് കോൺഫിഗറേഷനിൽ രേഖപ്പെടുത്തുക.

TLS എവിടെ അവസാനിക്കുന്നു, അത് എന്ത് ബാക്കിയാക്കുന്നു

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

പാതയിൽ മറ്റെവിടെയോ ഉള്ള VPN ആ ഉത്തരവാദിത്വങ്ങൾ പരിഹരിക്കുന്നില്ല. ബ്രൗസർ കാണുന്ന ആപ്ലിക്കേഷൻ URL ഫ്രണ്ട്എൻഡ് അവതരിപ്പിക്കുന്ന സർട്ടിഫിക്കറ്റുമായി ഒത്തുപോകുന്നുണ്ടോ എന്നും അത് പറയുന്നില്ല.

ആന്തരിക വിന്യാസത്തിന്, അവസാനിക്കുന്ന ബിന്ദുവും അത് അവതരിപ്പിക്കുന്ന ഐഡന്റിറ്റിയും രേഖപ്പെടുത്തുക. മറ്റൊരു പേരിനുള്ള സർട്ടിഫിക്കറ്റ് ഉപയോഗിച്ച് TLS അവസാനിപ്പിക്കുന്ന ഫ്രണ്ട്എൻഡ്, ഓപ്പറേറ്റർമാർ പലപ്പോഴും ശരിയാക്കുന്നതിന് പകരം അടിച്ചമർത്തുന്ന ബ്രൗസർ മുന്നറിയിപ്പ് സൃഷ്ടിക്കുന്നു.

നേറ്റീവ് ലൂപ്പ്ബാക്ക് ഒഴിവാക്കൽ ഇടുങ്ങിയതാണ്

ലൂപ്പ്ബാക്ക് റീഡയറക്ട് ഒഴിവാക്കൽ ഉപയോക്താവിന്റെ സ്വന്തം ഉപകരണത്തിലെ കോൾബാക്കിനെക്കുറിച്ചാണ്, അവിടെ ക്ലയന്റും ബ്രൗസറും ആ ഉപകരണം പങ്കിടുന്നു. ആ ക്രമീകരണം ഒരു ഉപകരണത്തിലെ കോൾബാക്കിനുള്ളതാണ്, ഓഫീസ് സബ്നെറ്റിന് HTTP വഴി സാധാരണ അനുമതി സർവറോ ടോക്കൺ വഹിക്കുന്ന API-യോ നൽകാൻ അത് അനുവാദം നൽകുന്നില്ല.

ഒഴിവാക്കൽ അത് വിവരിക്കുന്ന ക്ലയന്റ് തരത്തിലും കോൾബാക്കിലും പരിമിതമായി നിർത്തുക. അത് ഒരു വെബ് ആപ്ലിക്കേഷനിലോ പങ്കിട്ട ആന്തരിക സേവനത്തിലോ മറ്റൊരു ഹോസ്റ്റിലെ റീഡയറക്ട് URI-യിലോ പ്രയോഗിക്കുന്നത് വിന്യാസത്തെ മാറ്റുന്നു, ഒഴിവാക്കലിനെയല്ല.

ഓരോ അതിരിലും യഥാർത്ഥ ഒഴുക്ക് പരീക്ഷിച്ച് ക്ലയന്റ് തരവുമായി താരതമ്യം ചെയ്യുക. പ്രവർത്തിക്കുന്ന റീഡയറക്ട്, ടോക്കൺ വഹിച്ച ഓരോ ഘട്ടവും ആവശ്യമായ സംരക്ഷണം ഉപയോഗിച്ചോ എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, പച്ച VPN ഐക്കൺ അടുത്ത അഭ്യർത്ഥനയുടെ സ്കീമിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.