ca md too weak: സർട്ടിഫിക്കറ്റ് വീണ്ടും ഇഷ്യൂ ചെയ്യണോ ലെവൽ താഴ്ത്തണോ?

OpenVPN ക്ലയന്റ് കഴിഞ്ഞ മാസം പ്രവർത്തിച്ചിരുന്നു, ഇപ്പോൾ സ്റ്റാർട്ടപ്പിൽ ഇതോടെ പരാജയപ്പെടുന്നു: ca md too weak, ഒപ്പം ഡിസ്കിലെ പ്രൊഫൈൽ പ്രവർത്തിച്ചിരുന്നതിന്റെ ബൈറ്റ്-ബൈറ്റ് പകർപ്പാണ്. സന്ദേശം സർട്ടിഫിക്കറ്റ് അധികാരിയുടെ സർട്ടിഫിക്കറ്റിലെ ഒപ്പിനെക്കുറിച്ചാണ്, ഡാറ്റാ സൈഫർ, auth ഡൈജസ്റ്റ് അല്ലെങ്കിൽ അക്കൗണ്ട് പാസ്വേഡ് എന്നിവയെക്കുറിച്ചല്ല. പരിഹാരം പുതിയ ഐഡന്റിറ്റി മെറ്റീരിയലോ പുതിയ ചെയിനോ ബോധപൂർവമായ പോളിസി മാറ്റമോ എന്ന് മൂന്ന് വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു. അവ ക്രമത്തിൽ ചെയ്യുക, ഹോസ്റ്റിലെ എല്ലാ TLS കണക്ഷനുകളും ദുർബലമാക്കി ടണൽ തിരികെ കൊണ്ടുവരുന്ന സാധാരണ ഫലം ഒഴിവാക്കാം.

പിശക് യഥാർത്ഥത്തിൽ എന്തിനെ സൂചിപ്പിക്കുന്നു

OpenSSL ഒരു ചെയിൻ നിർമ്മിക്കുമ്പോൾ ഈ വെരിഫിക്കേഷൻ പിശക് ഉയർത്തുന്നു, CA ആയി പ്രവർത്തിക്കുന്ന സർട്ടിഫിക്കറ്റിൽ ലൈബ്രറിയുടെ സെക്യൂരിറ്റി ലെവൽ ഇനി സ്വീകരിക്കാത്ത ഒപ്പ് ഡൈജസ്റ്റ് ഉള്ളപ്പോൾ. MD5 സ്വതവേയുള്ള ലെവലിൽ നിരസിക്കപ്പെടുന്നു, SHA-1 ലെവൽ ഉയർത്തിയാൽ നിരസിക്കപ്പെടുന്നു. ഇവിടെ ലീഫ് സർട്ടിഫിക്കറ്റിലെ ഡൈജസ്റ്റിനെക്കാൾ പ്രധാനം അതിൽ ഒപ്പിടുന്ന ഇഷ്യൂവറിലെ ഡൈജസ്റ്റാണ്. അതേ പോളിസി, ഇഷ്യൂ ചെയ്ത ദിവസം പൂർണ്ണമായി സാധാരണമായിരുന്ന ഒരു റൂട്ടിനെയും നിരസിച്ചേക്കാം.

അതുകൊണ്ടാണ് auth അല്ലെങ്കിൽ data-ciphers എഡിറ്റ് ചെയ്യുന്നത് ഈ പരാജയത്തിന് ഒന്നും ചെയ്യാത്തത്. ആ സെറ്റിംഗുകൾ ഹാൻഡ്ഷേക്കിന് ശേഷം പാക്കറ്റുകൾ എങ്ങനെ സംരക്ഷിക്കപ്പെടുന്നു എന്ന് നിയന്ത്രിക്കുന്നു, നിരസിക്കപ്പെട്ട വസ്തു ടണൽ നിലവിൽ വരുന്നതിന് മുൻപ് പരിശോധിക്കുന്ന ഐഡന്റിറ്റി ഡോക്യുമെന്റാണ്. ഒരു സർട്ടിഫിക്കറ്റ് അതിന്റെ സാധുതാ കാലയളവിനുള്ളിൽ സുഖമായി ഇരിക്കുകയും ലൈബ്രറി സ്വീകരിക്കാത്ത ഒപ്പ് വഹിക്കുകയും ചെയ്യാം.

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

ഒന്നാം വ്യവസ്ഥ: നിരസിക്കപ്പെട്ട വസ്തു റൂട്ടാണോ?

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

സംയോജിത CA ഫയലുകളിൽ പലപ്പോഴും നിരവധി ബ്ലോക്കുകൾ ഉണ്ടാകും, അതിനാൽ ആദ്യത്തേതാണ് കുറ്റക്കാരൻ എന്ന് കരുതാതെ യഥാർത്ഥത്തിൽ ലോഡ് ചെയ്യുന്ന ബ്ലോക്ക് കണ്ടെത്തുക. കമാൻഡ് openssl x509 -in ca.pem -noout -subject -issuer -text ഒരു സമയം ഒരു സർട്ടിഫിക്കറ്റ് വിവരിക്കുന്നു, അതായത് ബണ്ടിലിൽ കൂടുതൽ ഉണ്ടെങ്കിൽ ആദ്യം അത് വിഭജിക്കണം. പ്രിന്റ് ചെയ്ത ഒപ്പ് അൽഗോരിതം, റൂട്ട് സൃഷ്ടിച്ച കാലഘട്ടത്തിൽ നിന്ന് നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന ഡൈജസ്റ്റുമായി താരതമ്യം ചെയ്യുക.

ദുർബലമായ റൂട്ടിന് കീഴിൽ SHA-256 ഉപയോഗിച്ച് ഒപ്പിട്ട ലീഫും പരാജയപ്പെടുന്നു, കാരണം ചെയിൻ പരിശോധന മുകളിലോളം നടക്കുന്നു. ആ ക്രമമാണ് അടുത്ത വ്യവസ്ഥയെ പ്രധാനമാക്കുന്നത്.

രണ്ടാം വ്യവസ്ഥ: ഇഷ്യൂവറിനെ നിയന്ത്രിക്കുന്നത് നിങ്ങളാണോ?

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

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

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

മൂന്നാം വ്യവസ്ഥ: ലെവൽ താഴ്ത്തുന്നത് മറ്റെന്ത് സ്വീകരിക്കുന്നു

സെക്യൂരിറ്റി ലെവൽ താഴ്ത്തുന്നതോ OpenVPN-ന്റെ പഴയ സർട്ടിഫിക്കറ്റ് പ്രൊഫൈൽ തിരഞ്ഞെടുക്കുന്നതോ ക്ലയന്റിനെ പഴയ ഡൈജസ്റ്റ് വീണ്ടും സ്വീകരിക്കാൻ പ്രേരിപ്പിക്കുന്നു. അത് അതേ ലൈബ്രറിയിലെ മറ്റ് പരിശോധനകളും അയഞ്ഞമാക്കുന്നു, ആ പ്രോസസ് ഉണ്ടാക്കുന്ന ഓരോ കണക്ഷനുമായി.

ഒരു പ്രൊഫൈലിൽ മാത്രമായി പരിമിതപ്പെടുത്തി അവസാന തീയതി ഉള്ളിടത്തോളം, ലബോറട്ടറിയിലോ പകരം മെറ്റീരിയൽ തയ്യാറാക്കുന്ന സമയത്ത് ഒരു ചെറിയ പാലമായോ ഇത് ന്യായീകരിക്കാവുന്നതാണ്. പങ്കിട്ട ഹോസ്റ്റിലെ സ്ഥിരമായ ക്രമീകരണമായി അത് അവിടത്തെ ഓരോ TLS ക്ലയന്റും വിശ്വസിക്കുന്നത് നിശബ്ദമായി വിശാലമാക്കുന്നു.

ഉത്തരവാദിയും നീക്കം ചെയ്യാനുള്ള ഘട്ടവും ചേർത്ത് ഒഴിവ് രേഖപ്പെടുത്തുക. ആറു മാസത്തിന് ശേഷം രേഖപ്പെടുത്താത്ത ലെവൽ മാറ്റം ഒരു തെറ്റിൽ നിന്ന് വേർതിരിച്ചറിയാനാവില്ല, അടുത്ത എൻജിനീയർ അത് ഒരിക്കൽ ഒരു തീരുമാനമായിരുന്നു എന്ന് അറിയില്ല.

തീരുമാനം, ഒരു നിയമമായി എഴുതുമ്പോൾ

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

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