OCSP vs CRL: ഓരോ റദ്ദാക്കൽ പരിശോധനയും യഥാർത്ഥത്തിൽ എങ്ങനെ പ്രവർത്തിക്കുന്നു
OCSP പ്രതികരണം ഒരു സർട്ടിഫിക്കറ്റിനുള്ള ഒപ്പിട്ട നിലയാണ്; CRL ഡൗൺലോഡ് ചെയ്യുന്ന ഒരു പട്ടികയാണ്. വിതരണം, കാഷിംഗ്, പരാജയ സമയത്തെ പെരുമാറ്റം എന്നിവയാണ് അവ വ്യത്യാസപ്പെടുന്ന സ്ഥലങ്ങൾ.
ഈ രണ്ട് റദ്ദാക്കൽ പരിശോധനകളിൽ ഒന്ന് ഒരു സർട്ടിഫിക്കറ്റിനെക്കുറിച്ചുള്ള ഒപ്പിട്ട ഉത്തരം നൽകുന്നു, മറ്റേത് നിങ്ങൾ പൂർണ്ണമായി ഡൗൺലോഡ് ചെയ്യുന്ന ഒപ്പിട്ട പട്ടിക നൽകുന്നു. രണ്ടും ഒരു ക്രെഡൻഷ്യൽ ഇപ്പോഴും വിശ്വസനീയമാണോ എന്ന് പരിശോധകനെ അറിയിക്കാനാണ്, രണ്ടും പരസ്പരം ഒട്ടും സാമ്യമില്ലാത്ത രീതിയിൽ പരാജയപ്പെടുന്നു. താഴെയുള്ള ക്രമം ഓപ്പറേറ്റർക്ക് ഉത്പാദനത്തിൽ യഥാർത്ഥത്തിൽ നേരിടേണ്ടി വരുന്നതിനെ പിന്തുടരുന്നു, വയറിലെ ബൈറ്റുകളിൽ തുടങ്ങി കണക്ഷൻ നിരസിക്കുന്ന ഗേറ്റ്വേയിൽ അവസാനിക്കുന്നു. ഒരു ഘട്ടം ഒഴിവാക്കുന്നതാണ്, വിന്യാസം കടലാസിൽ മാത്രം നിലനിൽക്കുന്ന റദ്ദാക്കൽ നയത്തോടെ അവസാനിക്കുന്ന വഴി.
ഘട്ടം 1: ഓരോ പരിശോധനയും എന്ത് നൽകുന്നു, എത്ര കാലം ഉപയോഗയോഗ്യമായി തുടരുന്നു
CRL എന്നത് ഒരു ഇഷ്യൂവർ റദ്ദാക്കിയ എല്ലാ സർട്ടിഫിക്കറ്റുകളെയും ഉൾക്കൊള്ളുന്ന ഒരു ഒപ്പിട്ട ഒബ്ജക്ടായി പ്രസിദ്ധീകരിക്കുന്നു, അതിനാൽ പരിശോധകൻ അത് ഒരിക്കൽ എടുത്ത് പട്ടികയുടെ nextUpdate കഴിയുന്നതുവരെ വീണ്ടും ഉപയോഗിക്കുന്നു. OCSP പ്രതികരണം കൂടുതൽ ഇടുങ്ങിയതാണ്: അത് കൃത്യമായി ഒരു സർട്ടിഫിക്കറ്റിന് ഉത്തരം നൽകുന്നു, thisUpdate, producedAt, സാധാരണയായി nextUpdate എന്നിവയും വഹിക്കുന്നു. ആ വ്യത്യാസമാണ് ബാക്കിയെല്ലാം നിർണ്ണയിക്കുന്നത്. കാഷ് ചെയ്ത CRL നിശബ്ദമായി പഴകുന്നു, കാരണം ഫയൽ ഇപ്പോഴും പാഴ്സ് ചെയ്യപ്പെടുന്നു, അതിന്റെ ഒപ്പും ഇപ്പോഴും പരിശോധിക്കപ്പെടുന്നു, എന്നാൽ കാലഹരണപ്പെട്ട OCSP പ്രതികരണം അതിന്റെ സമയ മുദ്രകൾ വായിക്കുന്ന നിമിഷം തന്നെ വ്യക്തമായി മൂല്യരഹിതമാണ്.
അതിനാൽ കാഷിംഗ് ആണ് ആദ്യം നിർണ്ണയിക്കേണ്ടത്: ഏത് ഘടകമാണ് പകർപ്പ് സൂക്ഷിക്കുന്നത്, ആ പകർപ്പ് ഏത് പരിധിക്ക് വിധേയമാണ്. ഗേറ്റ്വേയിൽ പരിധി nextUpdate മൈനസ് ഒരു സുരക്ഷാ മാർജിൻ ആയിരിക്കണം, ഒരിക്കലും ഒരു HTTP കാഷ് ഹെഡർ യാദൃച്ഛികമായി നിർദ്ദേശിക്കുന്നതല്ല. openssl crl -in issuer.crl -noout -lastupdate -nextupdate രണ്ട് തീയതികളും പ്രിന്റ് ചെയ്യുന്നു, കൂടാതെ nextUpdate ഇതിനകം ഭൂതകാലത്തിലുള്ള ഒരു പട്ടികയെ വെറും പഴയത് എന്നല്ല, കാണാത്തത് എന്ന് പരിഗണിക്കണം.
ഘട്ടം 2: സർട്ടിഫിക്കറ്റ് ക്ലയന്റിനെ എങ്ങോട്ട് നയിക്കുന്നു
ലീഫ് സർട്ടിഫിക്കറ്റ് സാധാരണയായി രണ്ട് സൂചനകൾ വഹിക്കുന്നു: ഒരു CRL വിതരണ പോയിന്റ് എക്സ്റ്റൻഷനും OCSP-ക്കുള്ള അതോറിറ്റി വിവര ആക്സസ് എൻട്രിയും. openssl x509 -in client.pem -noout -ext crlDistributionPoints ആദ്യത്തേത് പ്രിന്റ് ചെയ്യുന്നു, രണ്ടാമത്തേത് openssl x509 -in client.pem -noout -text ന്റെ AIA വിഭാഗത്തിന് കീഴിലാണ്. ഏത് എക്സ്റ്റൻഷനും ഒരു സൂചകമാണ്, ബാധ്യതയല്ല. റദ്ദാക്കൽ പരിശോധന ഒരിക്കലും നടപ്പാക്കാത്ത ഒരു ക്ലയന്റ്, ഒരു വർഷമായി മരിച്ച ഒരു പ്രതികരിയെ പേര് പറയുന്ന എക്സ്റ്റൻഷനുകളുള്ള ഒരു സർട്ടിഫിക്കറ്റുമായി നന്നായി ബന്ധിപ്പിക്കും.
വിതരണ പോയിന്റുകൾ പലപ്പോഴും ഒരു നെറ്റ്വർക്ക് സെഗ്മെന്റിനുള്ളിൽ മാത്രം റെസോൾവ് ചെയ്യുന്ന ഒരു ആന്തരിക ഹോസ്റ്റ് പേര് പറയുന്നു, ചില പഴയ ക്ലയന്റുകൾ ldap URL-കൾ പൂർണ്ണമായി നിരസിക്കുന്നു. ടണൽ അവസാനിപ്പിക്കുന്ന ഹോസ്റ്റിൽ നിന്ന് എത്തിച്ചേരാനുള്ള കഴിവ് പരിശോധിക്കുക, നിങ്ങളുടെ സ്വന്തം ലാപ്ടോപ്പിൽ നിന്നല്ല, കാരണം അതിന്റെ പരാജയം യഥാർത്ഥത്തിൽ പ്രധാനമാകുന്ന ഏക കാഴ്ചപ്പാട് അതാണ്.
ഘട്ടം 3: തടസ്സത്തിന് മുമ്പ് fail-closed അല്ലെങ്കിൽ fail-open തിരഞ്ഞെടുക്കുക
എത്തിച്ചേരാനാകാത്ത ഒരു പ്രതികരി അല്ലെങ്കിൽ കാലഹരണപ്പെട്ട പട്ടിക ഒരു തീരുമാനം അടിച്ചേൽപ്പിക്കുന്നു: കണക്ഷൻ നിരസിക്കുക, അല്ലെങ്കിൽ അത് സ്വീകരിച്ച് വിടവ് രേഖപ്പെടുത്തുക. OpenSSL-ന്റെ verify ഉപകമാൻഡ് കർശനമായ തിരഞ്ഞെടുപ്പ് വ്യക്തമാക്കുന്നു, കാരണം -crl_check ചേർത്താൽ ലഭ്യമല്ലാത്ത CRL unable to get certificate CRL ആയും പരാജയപ്പെട്ട പരിശോധനയായും മാറുന്നു. മിക്ക സ്റ്റാക്കുകളിലും സോഫ്റ്റ്-ഫെയിൽ ഒരു ഫ്ലാഗ് പോലുമല്ല, അത് പരിശോധനയുടെ അഭാവമാണ്, അതുകൊണ്ടാണ് അത് യാദൃച്ഛികമായി കയറ്റുമതി ചെയ്യപ്പെടുന്നത്.
ഒരു ക്ലയന്റിന് യഥാർത്ഥത്തിൽ എന്ത് പെരുമാറ്റമാണെന്ന് കാണാൻ പ്രതികരിയെ എടുത്തുമാറ്റി വീണ്ടും ബന്ധിപ്പിക്കുക. ടണൽ എങ്ങനെയും ഉയർന്നാൽ, ഒഴിവാക്കിയ പരിശോധന രേഖപ്പെടുത്തിയ ലോഗ് ലൈൻ കണ്ടെത്തുക, എന്നിട്ട് ഒരു സംഭവവേളയിൽ ആരെങ്കിലും ആ ലൈൻ വായിക്കുമോ എന്ന് ചോദിക്കുക. ഒരേ വിൽപ്പനക്കാരൻ പ്രോട്ടോക്കോൾ അനുസരിച്ച് വ്യത്യാസപ്പെടാം: ഒരേ മെഷീനിലെ IKEv2 ക്ലയന്റും OpenVPN ക്ലയന്റും ബന്ധമില്ലാത്ത കോൺഫിഗറേഷൻ ക്രമീകരണങ്ങൾ വായിക്കുന്നു.
ഘട്ടം 4: ട്രാഫിക് അനുവദിക്കുന്നിടത്ത് തന്നെ പരിശോധന പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുക
കണക്ഷൻ അവസാനിപ്പിക്കുന്ന അല്ലെങ്കിൽ അധികാരപ്പെടുത്തുന്ന പ്രോസസ് കണ്ടെത്തി, റദ്ദാക്കൽ പരിശോധന പ്രവർത്തനക്ഷമമാക്കുന്ന കോൺഫിഗറേഷൻ ലൈൻ അതിനോട് ചോദിക്കുക. ചെയിൻ സാധുതയുള്ളതാക്കുന്നുവെങ്കിലും റദ്ദാക്കലിനെക്കുറിച്ച് ഒരിക്കലും ചോദിക്കാത്ത ഗേറ്റ്വേ നിങ്ങളുടെ ഡോക്യുമെന്റേഷനിലുള്ളതിൽ നിന്ന് വ്യത്യസ്തമായ നയം പ്രയോഗിക്കുന്നു, സർട്ടിഫിക്കറ്റ് ചെയിനിന്റെ ഒരു സ്ക്രീൻഷോട്ടും അതിന് വിപരീതം തെളിയിക്കുന്നില്ല. OpenVPN ഈ ഓപ്ഷൻ crl-verify എന്ന് എഴുതുന്നു; strongSwan CRL, OCSP തിരച്ചിലുകൾ CA കോൺഫിഗറേഷന് കീഴിൽ സൂക്ഷിക്കുന്നു, അവിടെ crl_uris അല്ലെങ്കിൽ ocsp_uris സജ്ജമാക്കുന്നു. രണ്ടിലൊന്നിനെയും ചൂണ്ടിക്കാണിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, പരിശോധന ഇല്ലെന്ന് അനുമാനിക്കുക.
OCSP പ്രതികരണം സാധുവാകുന്നത് ഇഷ്യൂ ചെയ്യുന്ന CA അതിൽ ഒപ്പിട്ടാൽ മാത്രം, അല്ലെങ്കിൽ ആ CA നൽകിയ OCSPSigning വിപുലീകൃത കീ ഉപയോഗമുള്ള ഒരു പ്രതികരി ഒപ്പിട്ടാൽ മാത്രം, അതിനാൽ ബന്ധമില്ലാത്ത ഒരു സേവനത്തിൽ നിന്നുള്ള ഉത്തരം ഒന്നും തെളിയിക്കുന്നില്ല. നിങ്ങൾ തന്നെ പ്രതികരിയെ നടത്തുന്നുവെങ്കിൽ, അതിനെ കർശനമായ ആശ്രിതത്വമായി നിരീക്ഷിക്കുക, കാരണം ഒരു മരിച്ച സേവനം ഒരേസമയം ഓരോ fail-closed ക്ലയന്റിനും തടസ്സമായി മാറുന്നു.
ഘട്ടം 5: ബോധപൂർവ്വം ഒരു സർട്ടിഫിക്കറ്റ് റദ്ദാക്കുക
ഒരു പരീക്ഷണ സർട്ടിഫിക്കറ്റ് എടുത്ത്, ഉത്പാദനം ഉപയോഗിക്കുന്ന അതേ ചാനലിലൂടെ അത് റദ്ദാക്കി, പ്രതികരിയോട് നേരിട്ട് ചോദിക്കുക. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text റദ്ദാക്കൽ സമയത്തോടൊപ്പം Cert Status: revoked റിപ്പോർട്ട് ചെയ്യണം, good എന്ന ഉത്തരം അർത്ഥമാക്കുന്നത് നിങ്ങളുടെ റദ്ദാക്കൽ നിങ്ങളുടെ ക്ലയന്റുകൾ ചോദിക്കുന്ന പ്രതികരിയിൽ എത്തിയില്ല എന്നാണ്. തുടർന്ന് പട്ടിക വഴി അതേ തീരുമാനം കാണാൻ openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem പ്രവർത്തിപ്പിക്കുക. എക്സിറ്റ് കോഡിന് പകരം കാരണ സ്ട്രിംഗ് വായിക്കുക, കാരണം റദ്ദാക്കൽ നിരസിക്കലും ചെയിൻ പിശകും രണ്ടും പരാജയത്തിൽ അവസാനിക്കുന്നു.
യഥാർത്ഥത്തിൽ പ്രധാനമായ ഘട്ടം അവസാനത്തേതാണ്: യഥാർത്ഥ നിർവ്വഹണ പോയിന്റിനെതിരെ പഴയ പ്രൊഫൈലുമായി വീണ്ടും ബന്ധിപ്പിച്ച് നിരസിക്കൽ റദ്ദാക്കലിൽ നിന്നാണെന്ന് സ്ഥിരീകരിക്കുക. തുടർന്ന് പുതിയ, സാധുവായ ഒരു സർട്ടിഫിക്കറ്റുമായി വീണ്ടും ബന്ധിപ്പിച്ച് ലിസണർ മാത്രം തകർത്തതല്ലെന്ന് തെളിയിക്കുക. ക്ലയന്റിൽ പ്രൊഫൈൽ ഇല്ലാതാക്കുന്നത് സെർവറിന്റെ തീരുമാനത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല, ഒരിക്കലും ടണൽ അവസാനിപ്പിക്കാത്ത ഒരു മെഷീനിൽ openssl verify വിജയകരമായി പ്രവർത്തിപ്പിക്കുന്നതും അങ്ങനെ തന്നെ. RFC 6960 അനുയോജ്യമായ OCSP പ്രതികരണത്തിൽ എന്താണ് ഉള്ളതെന്ന് നിർവചിക്കുന്നു, ഈ പരീക്ഷണം വായിക്കുന്ന നില മൂല്യങ്ങൾ ഉൾപ്പെടെ.