ഒരു പഴയ പീയർ TLS 1.0 നിർബന്ധമാക്കുമ്പോൾ: ഒഴിവാക്കലിനെ പരിമിതപ്പെടുത്തുക, ഹോസ്റ്റിനെയല്ല

ഒരു പഴയ ഉപകരണം പ്രത്യക്ഷപ്പെടുന്നു, കണക്ട് ചെയ്യാനാകുന്നില്ല, ഏറ്റവും വേഗതയുള്ളതായി തോന്നുന്ന പരിഹാരം കണക്ഷൻ വിജയിക്കുന്നതുവരെ മുഴുവൻ ഹോസ്റ്റും ദുർബലമാക്കുകയാണ്. ആ കൈമാറ്റം ആ നിമിഷത്തിൽ കാണാനാകില്ല, പ്രായോഗികമായി ശാശ്വതമാണ്, കാരണം ഒടുവിൽ പ്രവർത്തിക്കുന്ന പരിധി ആരും നീക്കുന്നില്ല. വളരെ വ്യത്യസ്തമായ രണ്ട് തകരാറുകളാണ് ഈ സമ്മർദ്ദം സൃഷ്ടിക്കുന്നത്, അവയിൽ ഒന്ന് മാത്രമാണ് സൈഫറുകളെക്കുറിച്ച്. ആദ്യം തകരാറ് തരംതിരിക്കുക, പിന്നീട് ഒഴിവാക്കൽ പടരാനാകാത്ത ഇടത്ത് വയ്ക്കുക.

നിർദ്ദേശം തിരുത്തുന്നതിന് മുൻപ് പരാജയത്തെ രണ്ടായി വിഭജിക്കുക

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

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

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

ദുർബലമായ പരിധിക്ക് രണ്ടാമത്തെ ലിസണർ ആണ് സത്യസന്ധമായ ഇടം

ഉപകരണം 2.5-ന് മുൻപുള്ള ഡാറ്റ ചാനലോടെ TLS 1.0 ൽ നിൽക്കുമ്പോൾ, സെർവർ നിയന്ത്രണ ചാനലിന്റെ താഴ്ന്ന പരിധിയും പഴയ ക്ലയന്റ് തിരിച്ചറിയുന്ന ഡാറ്റ സൈഫറും വാഗ്ദാനം ചെയ്യണം. ഫാൾബാക്ക് നിർദ്ദേശം കൃത്യമായി ആ പീയറിനുവേണ്ടിയാണ്, സൈഫർ പട്ടിക ആധുനിക ക്ലയന്റുകളെ ആധുനിക സ്യൂട്ടുകളിൽ നിർത്തുന്നു. രണ്ടു നിർദ്ദേശങ്ങളും ഉപയോക്താവിനോ കണക്ഷനോ അല്ല, ലിസണറിനാണ് സ്വന്തം, പിന്നീട് ഏതെങ്കിലും ഓരോ-ക്ലയന്റ് ഓപ്ഷൻ അവയെ ചുരുക്കുന്നുമില്ല. അതുകൊണ്ടാണ് പ്രധാന പോർട്ടിലെ ഒരു പഴയ ഉപകരണം ആ പോർട്ട് പങ്കിടുന്ന ഓരോ പീയറിനെക്കുറിച്ചുമുള്ള തീരുമാനമാകുന്നത്.

പ്ലാറ്റ്ഫോം അനുവദിക്കുന്നിടത്ത് പഴയ ലിസണർ വേറിട്ട പോർട്ടിൽ സ്വന്തം ഇൻസ്റ്റൻസായി പ്രവർത്തിപ്പിക്കുക, ആ പോർട്ട് ഉപകരണത്തിന്റെ വിലാസത്തിൽനിന്ന് മാത്രം അനുവദിക്കുക, പ്രധാന സേവനം വെറുതെ വിടുക. രണ്ടാമത്തെ ലിസണർ എന്തിനാണെന്ന് അതിന്റെ കോൺഫിഗറേഷൻ ഉള്ള ഫയലിൽ എഴുതിവയ്ക്കുക, അല്ലെങ്കിൽ ഭാവിയിലെ ക്ലീനപ്പ് അതിനെ അവശിഷ്ടമായി വായിക്കും. ദുർബലമായ പരിധി ഉപകരണം അവസാനിക്കുന്നിടത്ത് അവസാനിച്ചാൽ മാത്രമേ ഈ വിഭജനത്തിന് അർത്ഥമുള്ളൂ.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

പഴയ പ്രൊവൈഡർ സർട്ടിഫിക്കറ്റ് യഥാർത്ഥത്തിൽ തകർക്കുന്നത്

പരിശോധന പിശക് ഒരു കാണാത്ത റോൾ ബന്ധമാണ്: അതില്ലാതെ ക്ലയന്റ് വിശ്വസ്ത CA-യിലേക്ക് ചെയിൻ ചെയ്യുന്ന ഏത് സർട്ടിഫിക്കറ്റും സ്വീകരിക്കും, അത് സെർവറിനുവേണ്ടി നൽകിയതാണോ എന്ന് നോക്കാതെ. ആദ്യം സർട്ടിഫിക്കറ്റ് സെർവർ റോളിലേക്ക് ബന്ധിപ്പിക്കുക, ബന്ധം ട്യൂണിംഗ് നോബ് അല്ല, ആവശ്യകതയായി കാണുക. ആ ഘട്ടത്തിനുശേഷവും പരാജയപ്പെടുന്ന പ്രൊഫൈലിന് മാത്രമാണ് യഥാർത്ഥ സർട്ടിഫിക്കറ്റ് പ്രശ്നമുള്ളത്.

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

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

ബാനറല്ല, ചർച്ചയിലെത്തിയ മൂല്യങ്ങൾ വായിക്കുക

verbosity 4 ൽ ഇരു വശവും യോജിച്ച നിയന്ത്രണ ചാനലിന്റെ TLS പതിപ്പും സൈഫറും, സെഷന്റെ ഡാറ്റ സൈഫറും പ്രിന്റ് ചെയ്യുന്നു. ഇനിഷ്യലൈസേഷൻ ബാനറല്ല, ആ വരികൾ വായിക്കുക, കാരണം ബാനർ വിജയം അറിയിക്കുന്നു, അതിന്റെ നിബന്ധനകളല്ല. തുടർന്ന് ഒരു ആധുനിക ക്ലയന്റ് പ്രധാന ലിസണറിലേക്ക് വീണ്ടും ബന്ധിപ്പിച്ച് അത് ഇപ്പോഴും ആധുനിക സ്യൂട്ടിൽ എത്തുന്നുവെന്ന് സ്ഥിരീകരിക്കുക, കാരണം പങ്കിട്ട കോൺഫിഗറേഷനിലേക്ക് ചോർന്ന ഒഴിവാക്കൽ ആദ്യം ഇവിടെയാണ് പ്രത്യക്ഷപ്പെടുന്നത്. നിങ്ങൾ പകർത്തുന്ന മൂല്യങ്ങൾ അടുത്ത അവലോകനത്തിന്റെ അടിസ്ഥാനമാകും.

പഴയ ഉപകരണം ഒറ്റയ്ക്ക് പരീക്ഷിക്കുക: അത് കണക്ട് ചെയ്യണം, ലോഗുകളിൽ ദുർബലമായ പാരാമീറ്ററുകൾ കാണിക്കുന്ന ഏക സെഷനും അതായിരിക്കണം. രണ്ടാമത്തെ പീയറും പഴയ സ്യൂട്ട് ചർച്ച ചെയ്യുന്നുവെങ്കിൽ, ഒഴിവാക്കൽ ഉദ്ദേശിച്ചതിലും വിശാലമാണ്, ലിസണർ വിഭജനം യഥാർത്ഥത്തിൽ നടന്നിട്ടില്ല. നിഗമനം മാത്രമല്ല, രണ്ട് നിരീക്ഷണങ്ങളും രേഖപ്പെടുത്തുക.

ഓരോ ഒഴിവാക്കലിനും ഉടമയും തീയതിയും വേണം

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

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