പിശകോടെ അവസാനിക്കുന്ന ഒരു ഹാൻഡ്‌ഷേക്ക് സന്ദേശം നോക്കുന്നതുവരെ ആക്രമണമായി തോന്നും, മിക്കപ്പോഴും അത് ഗണിതമാണ്: പൊതുവായ നിർദ്ദേശമില്ല, കാലഹരണപ്പെട്ട സർട്ടിഫിക്കറ്റ്, അല്ലെങ്കിൽ ഒരിക്കലും എത്താത്ത പാക്കറ്റ്. ഡൗൺഗ്രേഡ് ആക്രമണം ഒരു നിർദ്ദിഷ്ട കാര്യമാണ്: എതിരാളി ഇരുവശങ്ങളെയും അവർ തിരഞ്ഞെടുത്തതിലും ദുർബലമായ പെരുമാറ്റത്തിലേക്ക് തള്ളുന്നു, അത് വ്യത്യസ്ത തെളിവുകൾ അവശേഷിപ്പിക്കുന്നു. ഓരോ പരാജയത്തെയും ദുരുദ്ദേശമായി കാണുന്നത് നിലവിലില്ലാത്ത ഇരയെ തിരയാൻ നിങ്ങളെ അയയ്ക്കുന്നു, യഥാർത്ഥ ഡൗൺഗ്രേഡിനെ കോൺഫിഗറേഷൻ പിശകായി കാണുന്നത് ദുർബല ഫലം അവിടെത്തന്നെ നിർത്തുന്നു. രണ്ട് പിശകുകളുടെയും വില വ്യത്യസ്തമാണ്, ഒന്ന് മാത്രമേ വിലകുറഞ്ഞതായി തിരുത്താനാകൂ.

ഡൗൺഗ്രേഡ് ആക്രമണം യഥാർത്ഥത്തിൽ എന്താണ് മാറ്റുന്നത്

ലക്ഷ്യം സൈഫർ തകർക്കലല്ല, കീ ഊഹിക്കലുമല്ല. ഇരുപക്ഷവും ആക്രമണകാരന് കൈകാര്യം ചെയ്യാവുന്ന പഴയ പതിപ്പിലോ ദുർബല അൽഗോരിതത്തിലോ എത്തുന്നതിന് ചർച്ചയെ സ്വാധീനിക്കുകയാണ് ലക്ഷ്യം, അല്ലെങ്കിൽ ഒരു പക്ഷം മറുപക്ഷം അത് മാത്രമേ പിന്തുണയ്ക്കുന്നുള്ളൂ എന്ന് വിശ്വസിക്കുന്നതിന്.

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

ചർച്ച തന്നെ പ്രാമാണീകരിക്കേണ്ടത് എന്തുകൊണ്ട്

TLS 1.3 ആ സംരക്ഷണം വ്യക്തമാക്കുന്നു. പുതിയ പതിപ്പ് വാഗ്ദാനം ചെയ്ത ക്ലയന്റിന് നിശബ്ദമായി പിന്നോട്ട് പോയ സർവറിനെ കണ്ടെത്താനാകും, കാരണം സർവറിന്റെ റാൻഡം മൂല്യം 1.2 അല്ലെങ്കിൽ താഴെ ചർച്ച ചെയ്യുമ്പോൾ സ്ഥിരമായ ഒരു മാതൃക വഹിക്കുന്നു, ക്ലയന്റ് അത് കണ്ടാൽ നിർത്തണം. മുഴുവൻ ട്രാൻസ്ക്രിപ്റ്റും അന്തിമ സന്ദേശങ്ങളാൽ ഉൾക്കൊള്ളുന്നു, അതിനാൽ ചർച്ചയിൽ എവിടെയെങ്കിലും മാറ്റം പിന്നീട് പരാജയപ്പെടും, നിശബ്ദമായി കടന്നുപോകില്ല.

പഴയ പ്രോട്ടോക്കോൾ പതിപ്പുകൾക്ക് ദുർബലമായ കഥകളായിരുന്നു, അതുകൊണ്ടാണ് ഫോൾബാക്ക് നിയമങ്ങൾ പ്രധാനമാകുന്നത്. ഒരേ കോൺഫിഗറേഷനിലെ TLS 1.0 എൻഡ്‌പോയിന്റ് ഡൗൺഗ്രേഡ് ആക്രമണമല്ല; നിങ്ങൾ അനുവദിക്കാൻ തിരഞ്ഞെടുത്ത അനുവദനീയമായ ഫലമാണത്. വ്യത്യാസം ദുർബല ഫലം സംരക്ഷിത തീരുമാനത്തിൽ നിന്നോ ഇടനിലക്കാരന് സ്വാധീനിക്കാവുന്ന അസംരക്ഷിത പാതയിൽ നിന്നോ വന്നോ എന്നതാണ്. അങ്ങനെ പറഞ്ഞാൽ മിക്ക സംഭവങ്ങളും കോൺഫിഗറേഷൻ ചോദ്യമായി മാറുന്നു.

IKEv2 വ്യത്യസ്തമായി പെരുമാറുന്നു, പക്ഷേ അതേ ആശയത്തിൽ നിൽക്കുന്നു. നിർദ്ദേശം പിന്നീട് ഇരുപക്ഷത്തെയും പ്രാമാണീകരിക്കുന്ന കൈമാറ്റത്തിൽ കൊണ്ടുപോകുന്നു, അതിനാൽ അൽഗോരിതങ്ങൾ തിരുത്തിയെഴുതുന്ന ഇടനില ഉപകരണം പ്രാമാണീകരണത്തെ വഴിനയിക്കുന്നതിനുപകരം തകർക്കുന്നു. OpenVPN-ന്റെ നിയന്ത്രണ ചാനൽ അതിന്റെ ചർച്ച TLS ഉപയോഗിച്ച് സംരക്ഷിച്ച്, പിന്നീട് ആ ചാനൽ ഡാറ്റ ചാനലിന്റെ സൈഫറുകൾ ഒപ്പുവയ്ക്കാൻ ഉപയോഗിക്കുന്നു, അതുകൊണ്ടാണ് നിയന്ത്രണ ചാനലിന്റെ ലോഗ് വരി രസകരമാകുന്നത്.

കോൺഫിഗർ ചെയ്ത അനുകൂലത ആക്രമണമല്ല

ഒരു അഡ്മിനിസ്ട്രേറ്റർക്ക് പ്രമാണീകരിച്ച ക്ലയന്റിനെ പിന്തുണയ്ക്കാൻ മനഃപൂർവം പഴയ തിരഞ്ഞെടുപ്പുകൾ അനുവദിക്കാം, ആ തീരുമാനം കോൺഫിഗറേഷനിൽ കാണാം. ആക്രമണകാരന് ആ കോൺഫിഗറേഷൻ സൃഷ്ടിക്കാനാകില്ല; വാഗ്ദാനത്തെ സ്വാധീനിക്കാൻ അനുവദിക്കുന്ന ഒരു പാത മാത്രമേ ഉപയോഗിക്കാനാകൂ.

അപകടകരമായ അറ്റകുറ്റപ്പണി വ്യത്യാസത്തിന്റെ തെളിവ് നീക്കുന്നതാണ്. എല്ലാ പഴയ ഓപ്ഷനും പ്രവർത്തനക്ഷമമാക്കുക, സർട്ടിഫിക്കറ്റ് പരിശോധന നിർത്തുക, അല്ലെങ്കിൽ പിശക് മായാൻ ഏതെങ്കിലും സൈഫർ സ്വീകരിക്കുക എന്നത് എൻഡ്‌പോയിന്റ് സമ്മതിക്കുന്ന പരിധി വികസിപ്പിക്കുകയും ദുർബല ഫലം റിപ്പോർട്ട് ചെയ്യുമായിരുന്ന പരിശോധനകൾ നീക്കുകയും ചെയ്യുന്നു.

ഒരു പഴയ ഓപ്ഷൻ നിലനിർത്തണമെങ്കിൽ, കാരണവും ക്ലയന്റും കോൺഫിഗറേഷൻ കുറിപ്പിൽ രേഖപ്പെടുത്തി, പിന്നീട് ആ ഓപ്ഷൻ ആവശ്യമുള്ള പ്രൊഫൈലിൽ മാത്രം പരിമിതപ്പെടുത്തുക. ഒരു ശ്രോതാവിൽ മാത്രം പരിമിതപ്പെടുത്തിയ അനുകൂലതാ ഒഴിവ് ഓഡിറ്റ് ചെയ്യാവുന്നതാണ്; ആഗോളമായി പ്രയോഗിച്ചത് ആരും തിരഞ്ഞെടുത്തതായി ഓർക്കാത്ത ദുർബല ഡിഫോൾട്ട് മാത്രമാണ്.

കാരണം പറയുന്നതിന് മുമ്പ് പരാജയം വായിക്കുക

ഏതെങ്കിലും മാറ്റത്തിന് മുമ്പ് കൃത്യമായ പിശക് സ്ട്രിംഗ്, ക്ലയന്റ്, സർവർ പതിപ്പുകൾ, സമയം എന്നിവ സൂക്ഷിക്കുക. പിന്നീട് വർഗ്ഗീകരിക്കുക: പക്ഷങ്ങൾ നിർദ്ദേശത്തിൽ യോജിച്ചില്ലേ, പാക്കറ്റ് പാത പരാജയപ്പെട്ടുവോ, അതല്ലെങ്കിൽ ഒരു പക്ഷം മുമ്പ് സ്വീകരിച്ചിരുന്ന ഒരു പാരാമീറ്റർ നിരസിച്ചുവോ?

നിർദ്ദേശത്തിന്റെ പൊരുത്തക്കേട് സാധാരണയായി കുറ്റക്കാരായ പതിപ്പുകളോ അൽഗോരിതങ്ങളോ പേരെടുത്ത് പറയുന്നു, ഓരോ തവണയും അതേ ബിന്ദുവിൽ പരാജയപ്പെടുന്നു. റൂട്ടിംഗ് അല്ലെങ്കിൽ MTU പ്രശ്നം നിലയ്ക്കുകയോ സമയം കഴിയുകയോ ചെയ്യുന്നു, ഇത് പലപ്പോഴും നെറ്റ്‌വർക്കിനനുസരിച്ച് മാറുന്നു. കാലഹരണപ്പെട്ട സർട്ടിഫിക്കറ്റ് ചർച്ചയുടെയല്ല, പരിശോധനയുടെ പിശക് നൽകുന്നു.

ഇവയൊന്നും ആക്രമണകാരന്റെ തെളിവല്ല. ആദ്യ പരാജയത്തിൽ ദുരുദ്ദേശപരമായ കാരണം ആരോപിക്കുന്നതാണ് തെറ്റ്, അത് നാളെ വീണ്ടും പരാജയപ്പെടുന്ന നിർണ്ണായക ബഗ് മറയ്ക്കുന്നു.

യഥാർത്ഥത്തിൽ എന്താണ് തിരഞ്ഞെടുത്തതെന്ന് സ്ഥിരീകരിക്കുക

ഏതെങ്കിലും തിരുത്തലിന് ശേഷം കണക്ഷൻ ഉയർന്നുവെന്ന് വിശ്വസിക്കുന്നതിനുപകരം ചർച്ച ചെയ്ത ഫലം വായിക്കുക. പരിശോധന നീക്കിയതിനാൽ വിജയിക്കുന്ന കണക്ഷനാണ് നിങ്ങൾ ഒഴിവാക്കാൻ ശ്രമിച്ച ഫലം. താഴെയുള്ള രണ്ട് കമാൻഡുകൾ TLS മുന്നിലുള്ള എൻഡ്‌പോയിന്റിന് തിരഞ്ഞെടുത്ത പതിപ്പും സൈഫറും, കൂടാതെ OpenVPN സർവർ ലോഗിലെ നിയന്ത്രണ ചാനൽ വരിയും കാണിക്കുന്നു.

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

ഫലം നിങ്ങൾ ഉദ്ദേശിച്ച കോൺഫിഗറേഷനുമായി താരതമ്യപ്പെടുത്തുക, ഇപ്പോൾ കണക്ട് ചെയ്യുന്നതുമായല്ല. തിരഞ്ഞെടുത്ത പതിപ്പ് അനുവദനീയമായ കുറഞ്ഞതിനേക്കാൾ പഴയതാണെങ്കിൽ, പ്രൊഫൈലോ ഫോൾബാക്ക് പട്ടികയോ നോക്കേണ്ട സ്ഥലമാണ്, ഉത്തരം ആ പട്ടിക തിരുത്തുകയാണ്, ആക്രമണം പ്രഖ്യാപിച്ച് ചുറ്റുമുള്ളതെല്ലാം വീണ്ടും നിർമ്മിക്കലല്ല.

അനുബന്ധ ലേഖനങ്ങൾ