tls-crypt ആഗ്രഹിക്കുന്ന കീ openssl rand എന്തുകൊണ്ട് സൃഷ്ടിക്കാനാകുന്നില്ല

OpenSSL ഇതിനകം ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ട്, ഹോസ്റ്റിന് എൻട്രോപ്പി ഉണ്ട്, അതുപയോഗിച്ച് കീ സൃഷ്ടിക്കുന്നത് വ്യക്തമായ ഒരു കുറുക്കുവഴിയായി തോന്നുന്നു. ഔട്ട്പുട്ട് ക്രമരഹിതവും രഹസ്യവും പൂർണ്ണമായി ഉപയോഗശൂന്യവുമായിരിക്കും, പരാജയം കീ ഫോർമാറ്റ് പരാമർശിക്കുന്ന എന്തിനും പകരം കൺട്രോൾ-ചാനൽ പിശകായി വരും. ഈ തെറ്റായ വഴിതിരിവാണ് ചെലവേറിയ ഭാഗം, കാരണം അത് ആളുകളെ അവരുടെ സൈഫറുകൾ പരിശോധിക്കാൻ അയയ്ക്കുന്നു. VPN വായിക്കുന്നത് ഒരു പ്രത്യേക ഫയൽ ഘടനയാണ്, അനിയന്ത്രിത ബൈറ്റ് ബ്ലോക്കല്ല, ഈ സവിശേഷതയുടെ ഒരു രൂപം സർവറിന് പുറത്ത് ഒട്ടും നിർമ്മിക്കാനാകില്ല.

ഡിസ്കിലെ ഫയൽ യഥാർത്ഥത്തിൽ എന്തായിരിക്കണം

OpenVPN ന്റെ സ്റ്റാറ്റിക് കീ ഫയൽ ടെക്സ്റ്റാണ്. അത് എന്താണെന്ന് പ്രഖ്യാപിക്കുന്ന ഒരു കമന്റ് വരിയിൽ തുടങ്ങുന്നു, സ്ഥിരമായ വീതിയുള്ള വരികളിൽ ഹെക്സ് ഡാറ്റ വഹിക്കുന്നു, ആകെ 256 ബൈറ്റ് കീ മെറ്റീരിയൽ അടങ്ങിയിരിക്കുന്നു. OpenVPN അതിനെ കൺട്രോൾ ചാനലിന്റെ പങ്കിട്ട രഹസ്യമായി വായിക്കുന്നു, സർട്ടിഫിക്കറ്റായി അല്ല, പാസ്ഫ്രെയ്സായി അല്ല, TLS ലൈബ്രറി തിരിച്ചറിയുന്ന എന്തായും അല്ല.

അതേ ഒബ്ജക്ട് തരം കൺട്രോൾ ചാനലിന്റെ രണ്ട് സവിശേഷതകൾക്കും സേവനം നൽകുന്നു. tls-auth ഉപയോഗിച്ച്, ഒരു വശത്തിന്റെ പാക്കറ്റുകൾ അതിലേക്ക് തിരികെ പ്രതിഫലിക്കാതിരിക്കാൻ ഓരോ പിയറിനും ഒരു ദിശ കൂടി വേണം. tls-crypt ഉപയോഗിച്ച്, ഒരു പങ്കിട്ട രഹസ്യം ഇരു ദിശകളിലും കൺട്രോൾ ചാനൽ എൻക്രിപ്റ്റ് ചെയ്ത് പ്രാമാണീകരിക്കുന്നു, അത് ഹാൻഡ്ഷേക്ക് മറയ്ക്കുകയും അതേ സമയം സംരക്ഷിക്കുകയും ചെയ്യുന്നു.

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

ഒരെണ്ണം നിർമ്മിക്കാനുള്ള പിന്തുണയുള്ള മാർഗം

അത് ഉപയോഗിക്കുന്ന ഉപകരണം ഉപയോഗിച്ച് ലളിതമായ സ്റ്റാറ്റിക് കീ സൃഷ്ടിക്കുക, തുടർന്ന് ഇരു അറ്റങ്ങളിൽ നിന്നും അതിലേക്ക് റഫർ ചെയ്യുക:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

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

രണ്ടാം തലമുറയ്ക്ക് ഒരു ബാഹ്യ ജനറേറ്ററിനും കണ്ടുപിടിക്കാനാകാത്ത ഘടന കൂട്ടിച്ചേർക്കുന്നു. സർവർ കീ ഒരിക്കൽ സൃഷ്ടിക്കപ്പെടുന്നു, ഓരോ ക്ലയൻറും അതിൽ നിന്ന് ഉരുത്തിരിഞ്ഞ ഒരു പൊതിഞ്ഞ കീ സ്വീകരിക്കുന്നു:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

ക്ലയൻറിന് ലഭിക്കുന്നത് സർവറിന്റെ സ്വന്തം കീയുടെ പകർപ്പല്ല. സർവർ മാത്രം തുറക്കാനാകുന്ന മെറ്റാഡാറ്റ വഹിക്കുന്ന ഒരു പൊതിഞ്ഞ ഒബ്ജക്ടാണ് അത്, ഈ പൊതിയലാണ് ഒരു ഉപകരണത്തിന്റെ ഫയൽ മറ്റേതെങ്കിലും ഉപകരണത്തെ സ്പർശിക്കാതെ റദ്ദാക്കാൻ കഴിയുന്നതിന് കാരണം. സർവർ കീ സർവറിൽ സൂക്ഷിക്കുക, അതിനെ ആ ഉപകരണാധിഷ്ഠിത വിശ്വാസത്തിന്റെ വേരായി കണക്കാക്കുക.

കൈകൊണ്ട് നിർമ്മിച്ച ബൈറ്റുകൾ എവിടെ തകരുന്നു

ശരിയായ ഹെഡറിന് കീഴിൽ 256 ക്രമരഹിത ബൈറ്റുകൾ ഹെക്സായി അച്ചടിച്ചാൽ സൈദ്ധാന്തികമായി ലോഡ് ചെയ്യാവുന്ന സ്റ്റാറ്റിക് കീ ഫയൽ ലഭിക്കും. അത് ഇപ്പോഴും മോശം ആശയമാണ്. ഓരോ ഫോർമാറ്റിംഗ് വിശദാംശവും ലോഡ് സമയത്ത് പരാജയപ്പെടുന്ന, അല്ലെങ്കിൽ അതിലും മോശമായി, പ്രാമാണീകരണ പരാജയമായി മാത്രം പ്രകടമാകുന്ന വ്യത്യസ്ത മൂല്യങ്ങളോടെ രണ്ട് പിയറുകളെ വിടുന്ന മെറ്റീരിയൽ നിർമ്മിക്കാനുള്ള അവസരമായി മാറുന്നു.

v2 രൂപത്തിൽ സമാനമായ ഒന്നും സാധ്യമല്ല. പൊതിഞ്ഞ ക്ലയൻറ് കീ സർവർ കീ പ്രക്രിയയുടെ ഔട്ട്പുട്ടായി മാത്രം നിലനിൽക്കുന്നു, അത് തുറക്കാൻ വേണ്ട മെറ്റീരിയൽ സർവർ സൂക്ഷിക്കുന്നു. ക്രമരഹിത ബ്ലോക്ക് നിരസിക്കപ്പെടുകയോ ഡീക്രിപ്റ്റ് ചെയ്യാൻ കഴിയാതിരിക്കുകയോ ചെയ്യും, രണ്ട് സന്ദേശങ്ങളിൽ ഒന്നും ക്രമരഹിതത്വം പരാമർശിക്കില്ല.

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

എല്ലാവരെയും പുറത്ത് പൂട്ടാതെ തിരിക്കുക

ഒരു പങ്കിട്ട രഹസ്യം തിരിക്കുന്നത് സാങ്കേതികമല്ല, ഏകോപനത്തിന്റെ വ്യായാമമാണ്. സർവർ മുമ്പത്തേത് പിൻവലിക്കുന്നതിന് മുമ്പ് ഓരോ ക്ലയൻറിന്റെയും കൈവശം പകരം ഫയൽ ഉണ്ടായിരിക്കണം, പഴയ മൂല്യം ഇപ്പോഴും വഹിക്കുന്ന ഏത് യന്ത്രവും ആ നിമിഷത്തിൽ പരാജയപ്പെടും. ജോലിദിവസത്തിന്റെ നടുവിൽ ആ തിരിക്കൽ ആരംഭിക്കരുത്.

v2 ക്രമീകരണത്തിൽ, തിരിക്കൽ ഉപകരണം തോറും ആണ്: ഒരു യന്ത്രത്തിന് പുതിയ പൊതിഞ്ഞ കീ നൽകുക, പഴയത് ആ യന്ത്രത്തിന് മാത്രം വിരമിക്കുക. ഓരോ ക്ലയൻറും അതിനെ പിന്തുണയ്ക്കുന്ന റിലീസിലാകുമ്പോൾ മാറാനുള്ള പ്രധാന വാദം ഇതാണ്.

ഫയൽ അനുമതികൾ അതേ സംഭാഷണത്തിൽ പെടുന്നു. കീ സേവനം പ്രവർത്തിപ്പിക്കുന്ന അക്കൗണ്ടിന് മാത്രം വായിക്കാനാകണം, അത് സംരക്ഷിക്കുന്ന പ്രൊഫൈലുകളുള്ള അതേ റിപ്പോസിറ്ററിയിൽ അത് ജീവിക്കരുത്. OpenVPN 2.6 റഫറൻസ് സൃഷ്ടിക്കുന്ന രൂപങ്ങളും കീ-മെറ്റീരിയൽ വിഭാഗങ്ങളും രേഖപ്പെടുത്തുന്നു, ഇത് ഫോറം പോസ്റ്റിൽ നിന്ന് പകർത്തിയ കമാൻഡിനേക്കാൾ നല്ല ഉറവിടമാണ്.