സ്വയം-ഒപ്പിട്ട VPN സർട്ടിഫിക്കറ്റ്: അതിന്റെ അർത്ഥം എന്താണ്, എന്തിനെ അത് വിശ്വസിക്കുന്നു

ഇവിടെ ഏറ്റവും കൂടുതൽ നാശം വരുത്തുന്നത് രണ്ട് വിശ്വാസങ്ങളാണ്: സ്വയം-ഒപ്പിട്ട VPN സർട്ടിഫിക്കറ്റ് എന്നാൽ ടണൽ എൻക്രിപ്റ്റ് ചെയ്തിട്ടില്ല എന്ന്, കൂടാതെ VPN ക്ലയന്റ് ആവശ്യപ്പെട്ടതെന്തും ഇൻസ്റ്റാൾ ചെയ്യുന്നത് VPN-നെ മാത്രം ബാധിക്കുന്നു എന്ന്. രണ്ടും യഥാർത്ഥ വിന്യാസവുമായി സമ്പർക്കത്തിൽ നിലനിൽക്കുന്നില്ല. സ്വയം-ഒപ്പിട്ട സർട്ടിഫിക്കറ്റ് ഒരു ഒപ്പ് ബന്ധം വിവരിക്കുന്നു, സുരക്ഷാ വിധിയല്ല, കൂടാതെ നിങ്ങൾ ചേർക്കുന്ന വിശ്വാസത്തിന്റെ പരിധി അത് ഏത് സ്റ്റോറിൽ എത്തുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. ഒരു ഹെൽപ്ഡെസ്ക് ഒരു മുന്നറിയിപ്പ് നിശ്ശബ്ദമാക്കാൻ Windows യന്ത്രത്തിലേക്ക് ഒരു ദാതാവിന്റെ റൂട്ട് ഇമ്പോർട്ട് ചെയ്ത്, പിന്നീട് ബന്ധമില്ലാത്ത ഒരു പോർട്ടലിനെക്കുറിച്ച് ബ്രൗസർ പരാതിപ്പെടുന്നത് എന്തുകൊണ്ട് നിർത്തി എന്ന് വിശദീകരിച്ച് ഒരു ഉച്ചയ്ക്ക് ശേഷം ചെലവഴിച്ചത് ഞാൻ കണ്ടിട്ടുണ്ട്. ഈ ചോദ്യത്തിന്റെ രണ്ട് പകുതികളും ഒരുമിച്ചാണ്, അതിനാൽ അവയെ ഒന്നായി കാണുക.

സർട്ടിഫിക്കറ്റ് ഒരു വിശ്വാസ സ്റ്റോർ അല്ല

സർവർ അവതരിപ്പിക്കുന്ന ഫയലിൽ ഒരു പൊതു കീ, വിഷയ നാമം, ഇഷ്യൂവർ നാമം, സാധുത തീയതികൾ, എക്സ്റ്റൻഷനുകൾ എന്നിവ ഉണ്ട്. സ്വയം-ഒപ്പിട്ടത് എന്നാൽ വിഷയവും ഇഷ്യൂവറും ഒരേ ഘടകമാണെന്നും ഒപ്പ് സർട്ടിഫിക്കറ്റിന്റെ സ്വന്തം കീ ഉപയോഗിച്ച് സ്ഥിരീകരിക്കുന്നു എന്നും അർത്ഥം. ആ നിർവചനത്തിൽ ബന്ധം ദുർബലമാണെന്ന് ഒന്നും പറയുന്നില്ല, ക്ലയന്റ് അത് സ്വീകരിക്കുമെന്നും ഒന്നും പറയുന്നില്ല.

സ്വീകാര്യത മറ്റൊരിടത്തുനിന്ന് വരുന്നു: നിങ്ങൾ ക്ലയന്റിനെ ചൂണ്ടുന്ന CA ഫയൽ, കൈകൊണ്ട് താരതമ്യം ചെയ്യുന്ന വിരലടയാളം, അല്ലെങ്കിൽ ക്ലയന്റ് വായിക്കുന്ന സ്റ്റോറിൽ ഇതിനകം ഇരിക്കുന്ന ഒരു റൂട്ട്. വിന്യാസം പൂർണ്ണമായും ആരോഗ്യകരമായിരിക്കാം, പക്ഷേ അതിന്റെ സർട്ടിഫിക്കറ്റ് എല്ലാ പൊതു പരീക്ഷണത്തിലും പരാജയപ്പെടും. openssl verify സിസ്റ്റം ബണ്ടിലിനെതിരെ അജ്ഞാത ഇഷ്യൂവറിനെ റിപ്പോർട്ട് ചെയ്യും, ആ റിപ്പോർട്ട് തകരാറല്ല, ശരിയാണ്.

OpenVPN-ന്റെ ca ഓപ്ഷൻ ആപ്പ്-പരിമിത വിശ്വാസത്തിന്റെ ഏറ്റവും വ്യക്തമായ കേസാണ്. ആ ഫയൽ ക്ലയന്റ് സ്വീകരിക്കുന്ന ആങ്കറുകൾ പേരിടുന്നു, ഒരു സ്വകാര്യ CA അല്ലെങ്കിൽ ചെറിയ വിന്യാസത്തിൽ സർവറിന്റെ സ്വന്തം സ്വയം-ഒപ്പിട്ട സർട്ടിഫിക്കറ്റ് അതിൽ ഉണ്ടാകാം. പതിപ്പ് 2.6, CA ഫയൽ വിതരണം ചെയ്യുന്നതിനുപകരം SHA-256 വിരലടയാളം പിൻ ചെയ്യാൻ --peer-fingerprint ഉം സ്വീകരിക്കുന്നു. WireGuard ഇനിയും അകലെയാണ്: അതിൽ സർട്ടിഫിക്കറ്റുകളേ ഇല്ല, ഓരോ പിയറിനും ഒരു സ്ഥിര പൊതു കീ മാത്രം, അതിനാൽ സ്വയം-ഒപ്പ് ചോദ്യം അതിന് ബാധകമല്ല.

വിശ്വാസം എവിടെ ഇൻസ്റ്റാൾ ചെയ്യുന്നു എന്നത് അത് ആര് പാരമ്പര്യമായി ലഭിക്കും എന്നത് നിർണ്ണയിക്കുന്നു

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

Debian അല്ലെങ്കിൽ Ubuntu-യിൽ, /usr/local/share/ca-certificates/ ഇൽ ഒരു ഫയൽ ഇടുന്നതും update-ca-certificates പ്രവർത്തിപ്പിക്കുന്നതും സിസ്റ്റം-വ്യാപക ബണ്ടിൽ മാറ്റുന്നു. Windows-ൽ, certutil -addstore -f Root മെഷീൻ സ്റ്റോറിലേക്ക് എഴുതുന്നു, ഉയർത്തിയ പ്രോംപ്റ്റ് ആവശ്യമാണ്, അതേസമയം -user ചേർക്കുന്നത് പകരം നിലവിലെ ഉപയോക്താവിന്റെ സ്റ്റോർ ലക്ഷ്യമിടുന്നു; രണ്ടും പരസ്പരം മാറ്റാനാവില്ല. Firefox സ്വന്തം NSS ഡാറ്റാബേസ് സൂക്ഷിക്കുന്നു, അതിനാൽ OS തലത്തിലുള്ള ഇമ്പോർട്ട് അവിടെ ഒരിക്കലും പ്രത്യക്ഷപ്പെടണമെന്നില്ല.

പരിധി പ്രധാനമാണ്, ഒരു അധികാരിക്ക് എന്ത് ചെയ്യാനാകും എന്നത് കൊണ്ട്. ഇഷ്യൂ ചെയ്യുന്ന CA-യ്ക്ക് ബന്ധമില്ലാത്ത പേരുകൾക്ക് ഒപ്പിടാനാകും, അതിനാൽ ആ സ്റ്റോറിനെ വിശ്വസിക്കുന്ന എന്തും ആ ഒപ്പുകൾ സ്വീകരിക്കും. ഒരു പിൻ ചെയ്ത ഇലയ്ക്ക് അത് ചെയ്യാനാവില്ല; അത് കൃത്യമായി ഒരു പിയർ ഐഡന്റിറ്റി പ്രാമാണീകരിക്കുന്നു. ലക്ഷ്യം ഒരു VPN കണക്ട് ചെയ്യുകയാണെങ്കിൽ, ആപ്പ്-പരിമിത CA അല്ലെങ്കിൽ പിൻ ചെയ്ത ഇല അവിടെ എത്തുന്നു, അതേസമയം യന്ത്രം മുഴുവൻ റൂട്ട് ലക്ഷണം ആവശ്യപ്പെടുന്നതിനേക്കാൾ വളരെ വലിയ വിട്ടുവീഴ്ചയാണ്.

നിങ്ങൾ ഇപ്പോഴും പൊതു CA ഇല്ലാതെ എൻക്രിപ്റ്റ് ചെയ്യുന്നു

TLS ഹാൻഡ്ഷേക്ക് സെഷൻ കീകൾ ഉരുത്തിരിയുന്നു, പിയർ സർട്ടിഫിക്കറ്റ് നിങ്ങൾ ഇതിനകം വിശ്വസിക്കുന്ന എന്തിലേക്കെങ്കിലും ചങ്ങലയായി ബന്ധപ്പെടുന്നുണ്ടോ എന്നത് പരിഗണിക്കാതെ. സ്വയം-ഒപ്പിട്ടത് സാധാരണ പാഠമല്ല, ട്രാഫിക് പറക്കുമ്പോൾ വായിക്കാമെന്നും അല്ല. അർത്ഥം, കീ താൻ ആവശ്യപ്പെട്ട സർവറിന്റേതാണെന്ന് വിശ്വസിക്കാൻ ക്ലയന്റിന് മുൻകൂട്ടി യാതൊരു കാരണവുമില്ല.

ആ വിടവിലാണ് യഥാർത്ഥ ആക്രമണങ്ങൾ കഴിയുന്നത്. ഏത് സർട്ടിഫിക്കറ്റും സ്വീകരിക്കാൻ കോൺഫിഗർ ചെയ്ത ക്ലയന്റ്, പ്രവർത്തനരഹിതമായ പരിശോധന ക്രമീകരണത്തിലൂടെയോ ഒരിക്കൽ അമർത്തി മറന്നുപോയ “എങ്കിലും വിശ്വസിക്കുക” ബട്ടണിലൂടെയോ, ഉത്തരം നൽകുന്ന ആർക്കും സന്തോഷത്തോടെ എൻക്രിപ്റ്റ് ചെയ്യും. തടസ്സപ്പെടുത്തൽ പ്രാമാണീകരണ ഘട്ടത്തിൽ, ആപ്പ് ഡാറ്റ നീങ്ങുന്നതിന് മുമ്പ് സംഭവിക്കുന്നു. ഐഡന്റിറ്റി പരിശോധനയില്ലാത്ത എൻക്രിപ്ഷൻ നിഷ്ക്രിയ നിരീക്ഷകനെ പുറത്ത് നിർത്തുന്നു, അതിൽ കൂടുതലൊന്നും ചെയ്യുന്നില്ല.

ഇഷ്യൂവറെ വിശ്വസിക്കുന്നത് പേരിന്റെ പരിശോധന ഒഴിവാക്കുന്നില്ല

ചെയിൻ പരിശോധന, പേര് പൊരുത്തം, സർട്ടിഫിക്കറ്റിന്റെ ഉദ്ദേശ്യം എന്നിവ വെവ്വേറെ തീരുമാനങ്ങളാണ്. ചെയിൻ സാധുവായിരിക്കേ പേര് തെറ്റാകാം, പേര് പൊരുത്തപ്പെടുമ്പോൾ സർട്ടിഫിക്കറ്റ് മറ്റൊരു റോളിനായി നൽകിയതാകാം. RFC 5280 ആ നിയന്ത്രണങ്ങൾ വഹിക്കുന്ന ഫീൽഡുകൾ നിർവചിക്കുന്നു, ക്ലയന്റ് അവ എത്ര കർശനമായി നടപ്പിലാക്കുന്നു എന്നത് ഓരോ ആപ്ലിക്കേഷന്റെയും കാര്യമാണ്.

OpenVPN വിഭജനം ദൃശ്യമാക്കുന്നു. verify-x509-name name, name-prefix അല്ലെങ്കിൽ subject പൊരുത്തത്തിലൂടെ പ്രതീക്ഷിത വിഷയം പിൻ ചെയ്യുന്നു. remote-cert-tls server പിയർ സർട്ടിഫിക്കറ്റ് സർവർ സർട്ടിഫിക്കറ്റായി ഉപയോഗിക്കാനാകണം എന്ന് ആവശ്യപ്പെടുന്നു, ഇത് ഇഷ്യൂവറെ വിശ്വസിച്ചാലും ക്ലയന്റ്-മാത്ര സർട്ടിഫിക്കറ്റ് നിരസിക്കുന്നു. രണ്ട് ക്രമീകരണങ്ങളിൽ ഒന്നും CA ഫയൽ അയക്കുന്നതിലൂടെ മാറ്റപ്പെടുന്നില്ല.

എന്തെങ്കിലും തീരുമാനിക്കുന്നതിന് മുമ്പ് സർട്ടിഫിക്കറ്റ് പരിശോധിക്കുക:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName അത് ആര് നൽകി, ഏത് പേരുകൾക്ക്, എപ്പോൾ വരെ എന്ന് കാണിക്കുന്നു.
• openssl verify -CAfile ca.crt server.crt അയക്കാൻ പോകുന്ന ചെയിൻ ഇലയെ യഥാർത്ഥത്തിൽ സാധുവാക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുന്നു.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error വെബ് പോർട്ടൽ പോലുള്ള TLS എൻഡ്പോയിന്റുകൾക്ക് പ്രവർത്തിക്കുന്നു; 1194-ലെ OpenVPN പ്രോട്ടോക്കോൾ സാധാരണ TLS സ്ട്രീം അല്ല, അതിനാൽ ആ പരീക്ഷണം അവിടെ ബാധകമല്ല.

കാലഹരണപ്പെട്ട തീയതി, നിങ്ങൾ ബന്ധിപ്പിക്കുന്ന പേരിന് subjectAltName ഇല്ലായ്മ, അല്ലെങ്കിൽ serverAuth ഉപയോഗം ഇല്ലായ്മ എന്നിവയുള്ള സർട്ടിഫിക്കറ്റ്, ആങ്കർ എത്ര ശ്രദ്ധയോടെ ഇൻസ്റ്റാൾ ചെയ്താലും പരാജയപ്പെടും.

ഒന്ന് സ്വീകരിക്കുന്നതിന് മുമ്പ് അഞ്ച് പരിശോധനകൾ

നിങ്ങൾ നന്നാക്കാൻ ശ്രമിക്കുന്ന കണക്ഷൻ അല്ലാത്ത ഒരു ചാനലിലൂടെ വിരലടയാളം താരതമ്യം ചെയ്യുക: ഒരു കൺസോൾ, നിങ്ങൾക്ക് ഇതിനകം ഉള്ള ഇൻസ്റ്റാളർ, ഒപ്പിട്ട കോൺഫിഗറേഷൻ ഫയൽ. സർവറിലെ openssl x509 -in server.crt -noout -fingerprint -sha256 ഉം ക്ലയന്റ് ലോഗിലെ അതേ മൂല്യവും ഒരു വസ്തുവിനെയാണ് നോക്കുന്നത് എന്ന് അറിയാൻ മതിയാകും.

അടുത്തതായി, എന്താണ് ഇൻസ്റ്റാൾ ചെയ്യുന്നതെന്ന് തീരുമാനിക്കുക: ഒരു ഇലയോ, കൂടുതൽ അടിക്കാനാകുന്ന അധികാരമോ. പിന്നെ അത് എവിടെ പോകുന്നു എന്ന് തീരുമാനിക്കുക, ആ സ്റ്റോർ വായിക്കുന്ന ആപ്ലിക്കേഷനുകൾ പേരിടുക. നീക്കം ചെയ്യാനുള്ള വഴി ഓർമ്മയിലുള്ളപ്പോൾ എഴുതിവയ്ക്കുക, കാരണം വിശ്വസിച്ച്-മുന്നോട്ട്-പോകുക എന്നതാണ് താൽക്കാലിക ഇമ്പോർട്ട് സ്ഥിരമാകുന്ന വഴി.

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

ഒരു മുന്നറിയിപ്പ് അഞ്ച് പരിശോധനകളെയും അതിജീവിച്ചാൽ, ഉപയോഗപ്രദമായ ചോദ്യം അതിനെ ഏത് ബട്ടൺ നിശ്ശബ്ദമാക്കുന്നു എന്നല്ല, മറിച്ച് ക്ലയന്റ് യഥാർത്ഥത്തിൽ ഏത് സ്റ്റോർ വായിക്കുന്നു, ആ റൂട്ട് എവിടെനിന്ന് വന്നു എന്നതാണ്. അതിന് ഉത്തരം നൽകുക, നിങ്ങൾ ചെയ്യാൻ പോകുന്ന ഇമ്പോർട്ട് പ്രതികരണത്തിന് പകരം തീരുമാനമാകും.