OpenVPN-ൽ dh none-നൊപ്പം RSA സർട്ടിഫിക്കറ്റിന് പ്രവർത്തിക്കാനാകുമോ?

RSA എന്ന് പറയുന്ന സർട്ടിഫിക്കറ്റിനൊപ്പം dh none എന്ന് പറയുന്ന ഒരു സെർവർ കോൺഫിഗറേഷൻ ഇതാ, കൂടെ അവയിലൊന്ന് തീർച്ചയായും തെറ്റായിരിക്കണം എന്ന ശല്യപ്പെടുത്തുന്ന സംശയവും. ഒന്നും തെറ്റല്ല. സർട്ടിഫിക്കറ്റ് ഒപ്പിടുകയും പ്രമാണീകരിക്കുകയും ചെയ്യുന്നു; കീ-എക്സ്ചേഞ്ച് ഒരു പങ്കിട്ട രഹസ്യം സ്ഥാപിക്കുന്നു. ഒരേ ഹാൻഡ്ഷേക്കിലെ രണ്ട് വ്യത്യസ്ത ജോലികളാണ് ഇവ, കൂടാതെ താൽക്കാലിക ദീർഘവൃത്ത-വക്ര കരാറുപയോഗിക്കുന്ന ഹാൻഡ്ഷേക്ക് പ്രമാണീകരിക്കാൻ TLS RSA സർട്ടിഫിക്കറ്റിനെ അനുവദിക്കുന്നു.

ആശയക്കുഴപ്പം സാധാരണയായി ഒരു മൈഗ്രേഷൻ ഗൈഡിനൊപ്പം വരുന്നു. DH പാരാമീറ്റർ ഫയൽ dh none ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കാൻ അത് പറയുന്നു, സർട്ടിഫിക്കറ്റ് ദീർഘവൃത്ത-വക്ര സർട്ടിഫിക്കറ്റല്ലെന്ന് വായനക്കാരൻ ശ്രദ്ധിക്കുന്നു, രണ്ട് വസ്തുതകളും വൈരുദ്ധ്യമായി കണക്കാക്കപ്പെടുന്നു.

രണ്ട് ക്രമീകരണങ്ങളും ബന്ധപ്പെട്ടതായി തോന്നുന്നതെന്തുകൊണ്ട്

OpenVPN-ന്റെ പഴയ കോൺഫിഗറേഷൻ DH പാരാമീറ്റർ ഫയൽ ആവശ്യപ്പെട്ടത്, പരിമിത-ക്ഷേത്ര Diffie-Hellman-ന് ഇരുവശവും യോജിക്കുന്ന ഡൊമെയിൻ പാരാമീറ്ററുകൾ വേണ്ടതിനാലാണ്. dh നിർദ്ദേശം ആ ഫയലിലേക്കാണ് ചൂണ്ടിയത്. ഒരു വിന്യാസം ECDH-ലേക്ക് മാറുമ്പോൾ, പാരാമീറ്ററുകൾ പകരം ഒരു പേരിട്ട വക്രത്തിൽ നിന്ന് വരുന്നു, ഫയൽ ഇനി ആവശ്യമില്ല, അതാണ് dh none വ്യക്തമാക്കുന്നത്.

സർട്ടിഫിക്കറ്റുകൾ വേറിട്ട ഒരു അച്ചുതണ്ടാണ്. സെർവറിന്റെ ഐഡന്റിറ്റി തെളിയിക്കുന്ന പൊതു കീയും ഒപ്പും അവ വഹിക്കുന്നു, ആ കീ സെഷൻ കീ എങ്ങനെ യോജിക്കുന്നു എന്നത് പരിഗണിക്കാതെ RSA അല്ലെങ്കിൽ ദീർഘവൃത്ത വക്രമാകാം. കീ കരാറിന് ECDHE-യും പ്രമാണീകരണത്തിന് RSA-യും ഉപയോഗിക്കുന്ന ഹാൻഡ്ഷേക്ക് സാധാരണവും വ്യാപകമായി വിന്യസിക്കപ്പെട്ടതുമാണ്.

നാമകരണം ഓവർലാപ്പ് വഷളാക്കുന്നു. ദീർഘവൃത്ത വക്രം ECDHE, ECDSA സ്യൂട്ട് നാമങ്ങളിൽ ഒരുപോലെ കാണപ്പെടുന്നു, അതിനാൽ വക്രം പരാമർശിക്കുന്ന ഏത് കണക്ഷനിലും വക്ര സർട്ടിഫിക്കറ്റ് ഉണ്ടായിരിക്കണമെന്ന് അനുമാനിക്കാൻ എളുപ്പമാണ്. അങ്ങനെയല്ല.

TLS 1.2 സ്യൂട്ട് നാമം ശരിയായി വായിക്കുന്നത്

ECDHE-RSA-AES256-GCM-SHA384 എടുക്കുക. ആദ്യ ടോക്കൺ കീ-എക്സ്ചേഞ്ച് കുടുംബമാണ്: താൽക്കാലിക ദീർഘവൃത്ത-വക്ര Diffie-Hellman. രണ്ടാമത്തേത് പ്രമാണീകരണ കുടുംബമാണ്: RSA. ബാക്കിയുള്ളത് റെക്കോർഡ് സംരക്ഷണവും ഹാൻഡ്ഷേക്കിൽ ഉപയോഗിക്കുന്ന ഹാഷും വിവരിക്കുന്നു.

ECDHE-ECDSA സ്യൂട്ട് അതേ കീ-എക്സ്ചേഞ്ച് കുടുംബം വേറെ പ്രമാണീകരണ രീതിയോടെ ഉപയോഗിക്കുന്നു, അതിനാൽ അതിന് ദീർഘവൃത്ത-വക്ര സർട്ടിഫിക്കറ്റ് വേണം. DHE-RSA സ്യൂട്ട് RSA പ്രമാണീകരണത്തോടെ പരിമിത-ക്ഷേത്ര താൽക്കാലിക Diffie-Hellman ഉപയോഗിക്കുന്നു, അതിന് യഥാർത്ഥത്തിൽ DH പാരാമീറ്ററുകൾ വേണം.

സ്യൂട്ട് നാമം ഇടത്തുനിന്ന് വലത്തോട്ട് വായിച്ച് ഓരോ ഭാഗവും അതിന്റെ ജോലിക്ക് നൽകുക. ടോക്കണുകൾ വേർതിരിഞ്ഞതിന് ശേഷം, ചോദ്യം «എന്റെ സർട്ടിഫിക്കറ്റ് dh none-മായി യോജിക്കുന്നുവോ» എന്നതിൽ നിന്ന് «എന്റെ സെർവർ DH ഫയൽ ആവശ്യമില്ലാത്ത കീ-എക്സ്ചേഞ്ചുള്ള സ്യൂട്ട് അനുവദിക്കുന്നുവോ» എന്നതിലേക്ക് മാറുന്നു.

dh none യഥാർത്ഥത്തിൽ എന്താണ് പ്രവർത്തനരഹിതമാക്കുന്നത്

dh none സെർവറിനോട് പരിമിത-ക്ഷേത്ര DH പാരാമീറ്റർ ഫയൽ ലോഡ് ചെയ്യരുതെന്ന് പറയുന്നു. അത് പ്രമാണീകരണം, സർട്ടിഫിക്കറ്റ് സാധുത പരിശോധന അല്ലെങ്കിൽ TLS തന്നെ പ്രവർത്തനരഹിതമാക്കുന്നില്ല. എന്നാൽ യോജിച്ച കീ-എക്സ്ചേഞ്ചിന് ആ പാരാമീറ്ററുകൾ ആവശ്യമില്ലാത്തതായിരിക്കണമെന്ന് അത് ആവശ്യപ്പെടുന്നു, പ്രായോഗികമായി ഇത് ECDHE സ്യൂട്ട് അല്ലെങ്കിൽ TLS 1.3 ഹാൻഡ്ഷേക്ക് എന്നാണ് അർത്ഥമാക്കുന്നത്.

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

ദീർഘവൃത്ത-വക്ര വശത്ത്, വക്രം സെർവറിന്റെ TLS കോൺഫിഗറേഷൻ തിരഞ്ഞെടുക്കുന്നു, OpenVPN പഴയ ശാഖകളിൽ അത് തിരഞ്ഞെടുക്കാനുള്ള ഓപ്ഷൻ നൽകുന്നു. TLS 1.3 ഗ്രൂപ്പ് ചർച്ച പ്രോട്ടോക്കോളിനുള്ളിൽ കൈകാര്യം ചെയ്യുന്നു, DH ഫയൽ ഒട്ടും പരിശോധിക്കുന്നില്ല.

dh none സ്വയം ഒരു സുരക്ഷാ ഇടിവല്ല. എക്സ്ചേഞ്ചിന്റെ ശക്തി അപ്പോൾ യഥാർത്ഥത്തിൽ യോജിക്കുന്ന വക്രത്തെയും സ്യൂട്ടിനെയും ആശ്രയിച്ചിരിക്കുന്നു, അതിനാൽ അടുത്ത ഘട്ടം കാണാത്ത ഫയലല്ല, കക്ഷികൾ എന്താണ് തിരഞ്ഞെടുത്തതെന്ന് നോക്കുന്നതാണ്.

തിരുത്തുന്നതിന് മുമ്പ് ചർച്ച ഉറപ്പാക്കുക

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

TLS 1.2-ഉം ECDHE-RSA സ്യൂട്ടും RSA സർട്ടിഫിക്കറ്റും കാണിക്കുന്നുവെങ്കിൽ, dh none പ്രതീക്ഷിക്കുന്നത് കൃത്യമായി അതാണ്, തിരുത്താൻ ഒന്നുമില്ല. DHE സ്യൂട്ടോ പൊതു സൈഫറില്ലാത്ത ഹാൻഡ്ഷേക്ക് പരാജയമോ കാണിക്കുന്നുവെങ്കിൽ, പരിഹാരം സൈഫർ നയത്തിലോ ക്ലയന്റ് കഴിവിലോ ആണ്, സർട്ടിഫിക്കറ്റിലല്ല.

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

ഹാൻഡ്ഷേക്ക് പരാജയം മറികടക്കാൻ സർട്ടിഫിക്കറ്റ് പരിശോധന ഓഫ് ചെയ്യരുത്. കക്ഷികൾക്ക് കീ-എക്സ്ചേഞ്ചിൽ യോജിക്കാനായില്ലെന്ന് പരാജയം പറയുന്നു, പരിശോധന ഓഫ് ചെയ്യുന്നത് കരാർ പരിഹരിക്കാതെ ഐഡന്റിറ്റി ഉറപ്പ് നീക്കം ചെയ്യുന്നു.

ചെക്ക് ലിസ്റ്റ്: സർട്ടിഫിക്കറ്റ് RSA ആണോ, ECDHE സ്യൂട്ട് അനുവദനീയമാണോ, ലോഗ് ആ സ്യൂട്ട് കാണിക്കുന്നുണ്ടോ, പിന്തുണയ്ക്കുന്ന ഏറ്റവും പഴയ ക്ലയന്റും അതിന് യോജിക്കുന്നുണ്ടോ? നാലും അതെയെങ്കിൽ, dh none തന്റെ ജോലി ചെയ്യുന്നു.