OpenVPN ലോഗ്: നിയന്ത്രണ ചാനലിന്റെ സൈഫർ vs ഡാറ്റാ ചാനലിന്റെ സൈഫർ

DHE-RSA-AES256-SHA എന്ന് പേര് പറയുന്ന ലോഗ് വരി മുഴുവൻ കണക്ഷന്റെ സാരാംശമല്ല. ഇത് നിയന്ത്രണ ചാനലിനെ സംരക്ഷിക്കുന്ന TLS ഹാൻഡ്ഷെയ്ക്കിന്റെ ഭാഗമാണ്, ടണലിനുള്ളിലെ ട്രാഫിക് തികച്ചും വ്യത്യസ്തമായി എൻക്രിപ്റ്റ് ചെയ്തിരിക്കാം. ഇതിനെ VPN-ന്റെ ഡാറ്റാ സൈഫർ എന്ന് അവതരിപ്പിക്കുന്നത് ഒഴിവാക്കേണ്ട തെറ്റാണ്.

രണ്ട് ഫലങ്ങൾ പ്രധാനമാണ്, അവ വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. ഒന്ന് നിയന്ത്രണ ചാനലിനായി സമ്മതിച്ച TLS സ്യൂട്ട് ആണ്; മറ്റൊന്ന് ടണൽ വഹിക്കുന്ന പാക്കറ്റുകളുടെ ഡാറ്റാ സൈഫർ ആണ്.

രണ്ട് ഫലങ്ങൾ, രണ്ട് ചോദ്യങ്ങൾ

നിയന്ത്രണ ചാനൽ ഹാൻഡ്ഷെയ്ക്കും സഹജീവികൾക്കിടയിലെ മാനേജ്മെന്റ് സന്ദേശങ്ങളും വഹിക്കുന്നു. അതിന്റെ സൈഫർ TLS സ്റ്റാക്ക് തിരഞ്ഞെടുക്കുന്നു, അതിനാൽ പേര് TLS സമ്പ്രദായങ്ങൾ പിന്തുടരുന്നു. ഡാറ്റാ ചാനൽ ഉപയോക്തൃ ട്രാഫിക് വഹിക്കുന്നു, അത് OpenVPN-ന്റെ സ്വന്തം സൈഫർ ചർച്ചകൾ കോൺഫിഗർ ചെയ്യുന്നു.

രണ്ട് വരികളിൽ ഏതെങ്കിലും വായിക്കുന്നതിന് മുമ്പ് നിങ്ങൾ ഏത് ചോദ്യത്തിന് ഉത്തരം നൽകുന്നുവെന്ന് തീരുമാനിക്കുക. ടണൽ എൻക്രിപ്റ്റ് ചെയ്തിട്ടുണ്ടോ എന്നതും ഹാൻഡ്ഷെയ്ക്ക് ശക്തമാണോ എന്നതും ഒരേ ചോദ്യമല്ല.

രണ്ട് വരികളും കാണിക്കുന്ന ലോഗ് ഭാഗം ഉപയോഗപ്രദമാണ്. നിയന്ത്രണ വരി TLS പതിപ്പിനും സ്യൂട്ടിനും വായിക്കുക, ഡാറ്റാ വരി പേലോഡിനെ യഥാർത്ഥത്തിൽ സംരക്ഷിക്കുന്ന അൽഗോരിതത്തിനും വായിക്കുക.

TLS സ്യൂട്ടിന്റെ പേര് അതിന്റെ സ്വന്തം സന്ദർഭത്തിൽ മനസ്സിലാക്കുക

OpenSSL ശൈലിയിലുള്ള ചരിത്രപരമായ പേരിൽ, ഉദാഹരണത്തിന് DHE-RSA-AES256-SHA, ഓരോ ഘടകവും വ്യത്യസ്ത തീരുമാനം വിവരിക്കുന്നു. DHE എന്നത് അൽപകാലിക Diffie-Hellman കീ ഉടമ്പടിയാണ്, RSA പ്രാമാണീകരണ രീതിയാണ്, AES256 TLS റെക്കോർഡുകൾക്കുള്ള CBC മോഡിലെ AES-256 ആണ്, SHA SHA-1 അടിസ്ഥാനമാക്കിയുള്ള റെക്കോർഡ് MAC ആണ്.

അവസാന ഘടകം സർട്ടിഫിക്കറ്റിന്റെ വിരലടയാളമല്ല, അതിനെ അങ്ങനെ വായിക്കുന്നത് സാധാരണ തെറ്റാണ്. പേര് സ്വയം പ്രോട്ടോക്കോൾ പതിപ്പും പറയുന്നില്ല, കാരണം TLS 1.3 തികച്ചും വ്യത്യസ്തമായ നാമകരണ പദ്ധതി ഉപയോഗിക്കുന്നു. TLS_AES_256_GCM_SHA384 ആ പുതിയ രൂപം പിന്തുടരുന്നു, അതിൽ അവസാന ഹാഷ് സ്യൂട്ടിന്റെ ഘടനയുടെ ഭാഗമാണ്, MAC തിരഞ്ഞെടുപ്പല്ല. ഘടകാധിഷ്ഠിത വായന പഴയ നാമകരണ ശൈലിയിൽ മാത്രം പ്രയോഗിക്കുക.

OpenSSL സ്യൂട്ട് റഫറൻസ് ഏതെങ്കിലും ഘടകം പരിചിതമല്ലെങ്കിൽ ഈ പേരുകളെ അവയുടെ നിർവചനങ്ങളുമായി ബന്ധിപ്പിക്കുന്നു.

വഹിക്കുന്ന ട്രാഫിക്കിനായി ഡാറ്റാ ചാനലിന്റെ ഫലം വായിക്കുക

വഹിക്കുന്ന ട്രാഫിക്കിനായി അതേ സെഷന്റെ ഡാറ്റാ ചാനൽ വരി വായിക്കുക. കോൺഫിഗറേഷനിലെ data-ciphers പട്ടിക അനുവദനീയമായ ഒരു കൂട്ടമാണ്, ഒരു നിർദ്ദിഷ്ട അൽഗോരിതം സമ്മതിച്ചതിന്റെ തെളിവല്ല. ലോഗ് തിരഞ്ഞെടുപ്പ് രേഖപ്പെടുത്തുന്നു; കോൺഫിഗറേഷൻ മെനു പട്ടികപ്പെടുത്തുന്നു.

AES-GCM പോലുള്ള AEAD സൈഫർ അതിന്റെ സ്വന്തം സമഗ്രതാ പരിശോധന കൊണ്ടുവരുന്നു, അതിനാൽ വേറെ ഡാറ്റാ ചാനൽ HMAC ആ പാതയുടെ ഭാഗമല്ല.

auth നിർദ്ദേശം TLS, സർട്ടിഫിക്കറ്റുകൾ അല്ലെങ്കിൽ ഡാറ്റാ സൈഫർ അപ്ഗ്രേഡ് ചെയ്യുന്നില്ല. ഇത് പ്രോട്ടോക്കോളിന്റെ ഇപ്പോഴും ഒന്ന് ഉപയോഗിക്കുന്ന ഭാഗങ്ങൾക്ക് ഒരു ഡൈജസ്റ്റ് തിരഞ്ഞെടുക്കുന്നു, AEAD ഡാറ്റാ സൈഫറിനൊപ്പം കോൺഫിഗർ ചെയ്യാൻ വേറെ ഡാറ്റാ HMAC ഇല്ല.

ഐഡന്റിറ്റി പരിശോധനകൾ സൈഫറിന്റെ ഫലത്തിന് പുറത്ത് നിർത്തുക

സർട്ടിഫിക്കറ്റിന്റെ ഒപ്പ് അൽഗോരിതം, വിശ്വാസ ശൃംഖലയുടെ സാധുതാ പരിശോധന, സഹജീവിയുടെ പേരിന്റെ പരിശോധന എന്നിവ സൈഫർ പേര് ഒന്നും പറയാത്ത മൂന്ന് കൂടുതൽ സവിശേഷതകളാണ്. കാലഹരണപ്പെട്ട സർട്ടിഫിക്കറ്റ് പരാജയപ്പെടുന്നു, സ്യൂട്ട് എത്ര ശക്തമായാലും. പൊരുത്തപ്പെടാത്ത സെർവർ പേര് അതേ രീതിയിൽ പരാജയപ്പെടുന്നു. പ്രൊഫൈലിലെ ഡൈജസ്റ്റ് ക്രമീകരണം ശരിയാക്കുന്നത് രണ്ടിലൊന്നും ശരിയാക്കുന്നില്ല.

ഈ പരിശോധനകൾ അവലോകന കുറിപ്പുകളിൽ സൈഫറിന്റെ ഫലത്തിന് അരികിൽ സൂക്ഷിക്കുക, അതിൽ ലയിപ്പിക്കരുത്.

നിലവിലെ സെഷന്റെ സമ്മതിച്ച ഫലങ്ങൾ രേഖപ്പെടുത്തുക

നിലവിലെ കണക്ഷന്റെ ഫലങ്ങൾ എടുത്ത് അവയോടൊപ്പം ക്ലയന്റ്, സെർവർ പതിപ്പുകൾ രേഖപ്പെടുത്തുക. കൂട്ടിച്ചേർക്കൽ മാത്രമുള്ള ലോഗിൽ പഴയ സെഷന്റെ വരി ഉണ്ടാകാം, അതിനെ നിലവിലേതായി ഉദ്ധരിക്കുന്നത് ശരിയാക്കിയ പ്രശ്നം തുടരുന്നതായി തോന്നുന്ന വഴിയാണ്.

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