പഴയ P12 OpenSSL 3-ൽ പരാജയപ്പെടുന്നു: തെറ്റായ പാസ്ഫ്രേസോ പഴയ സൈഫറോ?
OpenSSL 3 തുറക്കാൻ വിസമ്മതിക്കുന്ന പഴയ RC2 ബണ്ടിലിൽ നിന്ന് തെറ്റായി നൽകിയ പാസ്ഫ്രേസിനെ വേർതിരിച്ച്, കീ സംരക്ഷണം നീക്കാതെ ഫയൽ വീണ്ടും സീൽ ചെയ്യുക.
ഇറക്കുമതി ഡയലോഗ് പാസ്വേഡ് എടുത്ത് ഒരു നിമിഷം കറങ്ങി, ബണ്ടിൽ വായിക്കാൻ കഴിയില്ലെന്ന് പറയുന്നു. നിങ്ങൾ പാസ്ഫ്രേസ് തെറ്റായി നൽകിയതാണോ, അതോ ക്ലയന്റ് ഇനി നൽകാത്ത ഒരു സൈഫർ കൊണ്ട് ഫയൽ സീൽ ചെയ്തതാണോ എന്ന് ആ സന്ദേശത്തിൽ ഒന്നും പറയുന്നില്ല. ഇവ വ്യത്യസ്ത പരാജയങ്ങളും വ്യത്യസ്ത പരിഹാരങ്ങളുമാണ്, തെറ്റായ തിരഞ്ഞെടുപ്പ് ക്ലയന്റ് തരംതാഴ്ത്തലിലേക്ക് നയിച്ച് തീരുമാനം വെറുതെ നീട്ടുന്നു. ക്ലയന്റ് ഏത് ഘട്ടത്തിൽ നിൽക്കുന്നു എന്ന് നിരീക്ഷിക്കുന്നത് അവയെ ഏകദേശം ഒരു മിനിറ്റിൽ വേർതിരിക്കുന്നു.
ഡയലോഗും സർട്ടിഫിക്കറ്റ് പട്ടികയും തമ്മിൽ എന്ത് സംഭവിക്കുന്നു
.p12 ഫയൽ ഒരു കണ്ടെയ്നറാണ്, സർട്ടിഫിക്കറ്റല്ല. ഉള്ളിൽ ഒന്നോ അതിലധികമോ സർട്ടിഫിക്കറ്റ് ബാഗുകളും, നിങ്ങളുടെ പാസ്വേഡിൽ നിന്ന് ഉരുത്തിരിഞ്ഞ കീ കൊണ്ട് എൻക്രിപ്റ്റ് ചെയ്ത സ്വകാര്യ കീ ബാഗും, കൂടാതെ മുഴുവൻ ഫയലിനും മേൽ MAC എന്ന സമഗ്രതാ പരിശോധനയും ഉണ്ട്. അത് തുറക്കുക എന്നാൽ ആ MAC പരിശോധിക്കുക, കീ ബാഗ് ഡീക്രിപ്റ്റ് ചെയ്യുക, സർട്ടിഫിക്കറ്റിനെ പുറത്തുവരുന്ന കീയുമായി ഒത്തുനോക്കുക എന്നിവയാണ്.
പാസ്വേഡ് പ്രശ്നം MAC ഘട്ടത്തിൽ വരുന്നു. സൈഫർ പ്രശ്നം പിന്നീട്, കീ ബാഗ് തുറക്കേണ്ടിവരുമ്പോഴും അത് ചെയ്യുന്ന ബിൽഡിൽ ഫയലിൽ പേരിട്ട അൽഗോരിതത്തിന്റെ നിർവ്വഹണം ഇല്ലാത്തപ്പോഴും വരുന്നു.
രണ്ടാമത്തെ സാഹചര്യം ഇന്നത്തെ സിസ്റ്റങ്ങളിൽ സാധാരണമാണ്, കാരണം OpenSSL 3 പഴയ അൽഗോരിതങ്ങളുടെ ഒരു കൂട്ടത്തെ ഓപ്ഷണൽ legacy provider-ലേക്ക് മാറ്റി. OpenSSL 1.x എക്സ്പോർട്ട് ചെയ്ത ബണ്ടിലുകൾ സാധാരണയായി സർട്ടിഫിക്കറ്റുകൾ 40-ബിറ്റ് RC2 കൊണ്ടും സ്വകാര്യ കീയെ മൂന്ന് കീയുള്ള Triple DES കൊണ്ടും സീൽ ചെയ്തിരുന്നു. സ്ഥിരസ്ഥിതി OpenSSL 3 ബിൽഡ് ശരിയായ പാസ്വേഡോടെ MAC പരിശോധിച്ച് പിന്നീട് ബാഗിൽ പരാജയപ്പെടുന്നു, അതിനാൽ പാസ്വേഡ് ഒരിക്കലും തെറ്റായിരുന്നില്ല, വീണ്ടും ടൈപ്പ് ചെയ്യുന്നത് ഒന്നും മാറ്റുന്നുമില്ല.
കീ പുറത്തെഴുതാതെ കണ്ടെയ്നർ വായിക്കുക
നിങ്ങളുടെ മെഷീനിലെ OpenSSL ബിൽഡിനോട് ഫയൽ പാഴ്സ് ചെയ്ത് അത് എവിടെ വിട്ടുകളയുന്നു എന്ന് വായിക്കാൻ ആവശ്യപ്പെടുക. ഔട്ട്പുട്ട് ഫയലില്ലാത്ത പരിശോധന കീയെ ഡിസ്കിൽ എൻക്രിപ്റ്റ് ചെയ്ത് വിടുന്നു, പങ്കിട്ട ഹോസ്റ്റിൽ ഈ ഘട്ടം സുരക്ഷിതമായിരിക്കാനുള്ള ഏക കാരണം അതാണ്.
openssl pkcs12 -in vpn-identity.p12 -info -nooutശരിയായ പാസ്വേഡുള്ള പഴയ ബണ്ടിലിൽ ഇത് ബാഗ് ആട്രിബ്യൂട്ടുകൾ അച്ചടിച്ച് പിന്നീട് digital envelope routines::unsupported-നോടെ നിൽക്കുന്നു. തെറ്റായ പാസ്വേഡോടെ ഏതെങ്കിലും ബാഗ് വായിക്കുന്നതിന് മുൻപ് Mac verify error: invalid password? ലഭിക്കും. രണ്ട് സന്ദേശങ്ങളും വിപരീത ദിശകൾ കാണിക്കുന്നു, ക്ലയന്റ് മറച്ചുവെച്ചത് കൃത്യമായി ആ വിവരമാണ്.
പരാജയം പിന്തുണയ്ക്കാത്ത അൽഗോരിതമാണെങ്കിൽ, അതേ കമാൻഡ് -legacy ചേർത്ത് മറ്റൊന്നും മാറ്റാതെ വീണ്ടും പ്രവർത്തിപ്പിക്കുക. ആ ഫ്ലാഗ് legacy provider-നെ ആ ഒരു പ്രോസസ്സിന് മാത്രം ലോഡ് ചെയ്യുന്നു. അത് VPN ക്ലയന്റിനെ പഴയ ബണ്ടിലുകൾ പാഴ്സ് ചെയ്യാൻ നിർബന്ധിക്കുന്നില്ല, സിസ്റ്റം വ്യാപകമായ ക്രിപ്റ്റോ നയത്തെ തൊടുന്നില്ല, ഫയൽ ഇപ്പോഴും മാറ്റേണ്ടതിനാൽ ഇത് അറ്റകുറ്റപ്പണിയല്ല, ഒരു അളവെടുപ്പാണ്.
ഏത് പിശക് ഏത് ഘട്ടം
ഒരു ചെറിയ പട്ടിക മൂന്ന് ഫലങ്ങളെ വേർതിരിക്കുന്നു, ഡയലോഗ് എവിടെ പ്രത്യക്ഷപ്പെട്ടു എന്നതിനേക്കാൾ പ്രധാനം വാക്കുകളാണ്.
| Text you see | Stage | What it tells you |
|---|---|---|
Mac verify error: invalid password? | Integrity check | Passphrase or cached credential, not the cipher |
digital envelope routines::unsupported | Bag decrypt | Algorithm missing from the default provider |
not enough data / header too long | Container format | Wrong encoding, edited file, or truncated download |
not enough data അല്ലെങ്കിൽ header too long പോലുള്ള വാചകം ആദ്യ രണ്ട് കൂട്ടങ്ങളിൽ ഒന്നിലും പെടുന്നില്ല. അത് ഒരു ഫോർമാറ്റ് പ്രശ്നമാണ്: .pem എന്ന് പേരുമാറ്റിയ DER ഫയൽ, വരികളുടെ അവസാനം വീണ്ടും എഴുതിയ എഡിറ്ററാൽ കേടായ പകർപ്പ്, അല്ലെങ്കിൽ പൂർത്തിയാകാത്ത ഡൗൺലോഡ്. സൈഫറുകൾ നോക്കാൻ തുടങ്ങുന്നതിന് മുൻപ് ഇഷ്യൂ ചെയ്തയാൾ അയച്ച ചെക്സമ്മുമായി താരതമ്യം ചെയ്യുക.
Mac verify error-നെ പാസ്വേഡിനെക്കുറിച്ചുള്ള തെളിവായി മാത്രം കാണുക. നിങ്ങൾ ടൈപ്പ് ചെയ്തതിൽ നിന്ന് കണക്കാക്കിയ MAC സംഭരിച്ച മൂല്യവുമായി ഒത്തുപോകുന്നില്ല എന്നാണ് അർത്ഥം, ഇത് ടൈപ്പിംഗ് പിശക്, മുൻ ഇറക്കുമതിയിൽ നിന്ന് കാഷ് ചെയ്ത പാസ്വേഡ്, അല്ലെങ്കിൽ മറ്റൊരു പാസ്ഫ്രേസിൽ വീണ്ടും എക്സ്പോർട്ട് ചെയ്ത ഫയൽ എന്നിവയിൽ സംഭവിക്കുന്നു. ഉള്ളിലെ അൽഗോരിതങ്ങൾ പഴയതാണോ എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.
ക്ലയന്റിന് യഥാർത്ഥത്തിൽ തുറക്കാവുന്ന ബണ്ടിൽ നിർമ്മിക്കുക
legacy പാഴ്സർ ഫയൽ കേടില്ലെന്ന് ഉറപ്പിച്ചാൽ, ശാശ്വത പരിഹാരം ലക്ഷ്യ ക്ലയന്റ് പിന്തുണയ്ക്കുന്ന അൽഗോരിതങ്ങളുള്ള ഒരു പകരമാണ്: കീയ്ക്കും സർട്ടിഫിക്കറ്റ് ബാഗുകൾക്കും AES-256-CBC, ഉരുത്തിരിയൽക്ക് SHA-256 ഉള്ള PBKDF2, MAC-ന് SHA-256. നിങ്ങളുടെ PKI അഡ്മിൻ അതേ കീ മെറ്റീരിയലിൽ നിന്ന് അത് എക്സ്പോർട്ട് ചെയ്യാം, ഉള്ളിലെ സർട്ടിഫിക്കറ്റ് നിങ്ങളുടെ സർവറുകൾ ഇതിനകം വിശ്വസിക്കുന്നത് തന്നെയായിരിക്കും.
പ്രാദേശികമായി പരിവർത്തനം ചെയ്യേണ്ടിവന്നാൽ, ബാഗുകൾ ആദ്യം കളയുന്നതിന് പകരം വീണ്ടും സീൽ ചെയ്യാൻ pkcs12 ടൂളിനോട് ആവശ്യപ്പെടുക. രണ്ട് പാസ്ഫ്രേസുകളും ഒരു ഫയലിൽ നിന്ന് വായിച്ച് നിങ്ങളുടെ ഷെൽ ചരിത്രത്തിൽ നിന്ന് ഒഴിവാക്കുക.
openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
-keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
-passin file:old.pass -passout file:new.passവിജയകരമായ പരിവർത്തനം കാലഹരണം, കീ ഉപയോഗം, സ്വകാര്യ കീ ഒത്തുപോകൽ, അല്ലെങ്കിൽ സർവർ ഇഷ്യൂ ചെയ്യുന്ന ശൃംഖലയെ വിശ്വസിക്കുന്നുണ്ടോ എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. വീണ്ടും പാക്ക് ചെയ്യുന്നത് ഒരു കൈമാറ്റ മാറ്റമാണ്, പുതുക്കലല്ല, അവയിൽ ഓരോന്നിനും സ്വന്തം പരിശോധന ഇപ്പോഴും ആവശ്യമാണ്.
ക്ലയന്റ് ഫയൽ സ്വീകരിച്ചു എന്നതിന്റെ പേരിൽ സംരക്ഷണമില്ലാത്ത ഇടക്കാല കീ എഴുതുന്ന അല്ലെങ്കിൽ ഒഴിഞ്ഞ ഔട്ട്പുട്ട് പാസ്വേഡിടുന്ന ഏത് പാചകവും ഒഴിവാക്കുക. സംരക്ഷണം നീക്കിയ വായിക്കാവുന്ന ബണ്ടിൽ, നിങ്ങൾ തുടങ്ങിയ ഇറക്കുമതി പരാജയത്തേക്കാൾ മോശം ഫലമാണ്.
നിങ്ങൾ നിർമ്മിച്ച ഫയൽ ക്ലയന്റ് ഇറക്കുമതി ചെയ്തുവെന്ന് ഉറപ്പാക്കുക
ടെർമിനലിലെ വ്യക്തമായ പാഴ്സിംഗ് കണ്ടെയ്നർ സാധുവാണെന്ന് തെളിയിക്കുന്നു. ക്ലയന്റ് അത് തിരഞ്ഞെടുത്തു എന്ന് തെളിയിക്കുന്നില്ല, കാരണം അവശേഷിക്കുന്ന പ്രൊഫൈൽ പഴയ ഫയലിലേക്ക് തുടർന്നും ചൂണ്ടാം, ചില ക്ലയന്റുകൾ ഇറക്കുമതി ചെയ്ത ഐഡന്റിറ്റി നിങ്ങൾ തിരഞ്ഞെടുക്കാത്ത ഒരു പേരിൽ കാഷ് ചെയ്യുന്നു.
നിങ്ങൾ ഇറക്കുമതി ചെയ്യാൻ പോകുന്ന ഐഡന്റിറ്റി അച്ചടിച്ച് ക്ലയന്റിന്റെ സർട്ടിഫിക്കറ്റ് കാഴ്ചയിൽ കാണിക്കുന്നതുമായി താരതമ്യം ചെയ്യുക.
openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
| openssl x509 -noout -subject -dates -fingerprint -sha256ആദ്യം പഴയ പ്രൊഫൈൽ എൻട്രി നീക്കം ചെയ്ത് പിന്നീട് ഇറക്കുമതി ചെയ്യുക. ക്ലയന്റ് ലോഡ് ചെയ്ത വിഷയമോ വിരലടയാളമോ ലോഗ് ചെയ്യുന്നുണ്ടെങ്കിൽ അത് മുകളിലെ വരിയുമായി ഒത്തുനോക്കുക; അത് സൗഹൃദ നാമം മാത്രം കാണിച്ചാൽ പകരം കാലഹരണ തീയതി പരിശോധിക്കുക, കാരണം അതിനെ അതേ ഇഷ്യൂ ചെയ്തയാളുടെ മറ്റൊരു സർട്ടിഫിക്കറ്റുമായി കൂട്ടിക്കുഴയ്ക്കാൻ ബുദ്ധിമുട്ടാണ്.
PKCS12 റഫറൻസ് ഇവിടെ ഉപയോഗിച്ച provider, പാസ്ഫ്രേസ്, ഔട്ട്പുട്ട് ഓപ്ഷനുകൾ എന്നിവ പട്ടികപ്പെടുത്തുന്നു. legacy provider-നെ ക്ലയന്റ് പരിസ്ഥിതിയിൽ നിന്ന് പുറത്ത് നിർത്തുന്നതാണ് കാര്യം: അതുമായി അളക്കുക, അതില്ലാതെ കൈമാറുക, സ്വകാര്യ കീ ഡിസ്കിൽ സംരക്ഷിച്ച് വിടുക.