സർവർ സർട്ടിഫിക്കറ്റ് ചെയിൻ ക്ലയന്റിന്റെ ട്രസ്റ്റ് സ്റ്റോർ അതിക്രമിക്കാൻ കഴിയുമോ?

ചെയിൻ പൂർണ്ണമായ സൈറ്റിൽ ബ്രൗസർ സർട്ടിഫിക്കറ്റ് മുന്നറിയിപ്പ് കാണിക്കുന്നു, ആദ്യ പ്രവണത സർവർ ശരിയാക്കാനാണ്. സാധാരണയായി സർവർ ചെയ്യേണ്ടത് കൃത്യമായി അവതരിപ്പിക്കുന്നു. ഏത് ആങ്കറുകൾ സ്വീകരിക്കണമെന്ന് ക്ലയന്റ് തീരുമാനിക്കുന്നു, ഇടനില സർട്ടിഫിക്കറ്റുകളുടെ ഏത് ക്രമീകരണത്തിനും കണക്ഷന്റെ മറ്റേ അറ്റത്തുനിന്ന് ആ തീരുമാനം മാറ്റാൻ കഴിയില്ല. സർട്ടിഫിക്കറ്റ് പ്രശ്നമായി തോന്നുന്നതിന്റെ ഭൂരിഭാഗവും ഈ അതിർത്തി വിശദീകരിക്കുന്നു.

സാധുത പരിശോധന ക്ലയന്റിൽ, ക്ലയന്റിന്റെ ആങ്കറുകളോടെ നടക്കുന്നു

പാത്ത് സാധുത പരിശോധന അവതരിപ്പിച്ച സർട്ടിഫിക്കറ്റുകൾ എടുത്ത്, സാധുതാ സംവിധാനത്തിന് ഇപ്പോൾ തന്നെയുള്ള ഒരു വിശ്വാസ ആങ്കർ വരെ ചെയിൻ നിർമ്മിക്കുന്നു. RFC 5280 ആ മാതൃക വിവരിക്കുന്നു, ആങ്കർ തിരഞ്ഞെടുപ്പ് സർവറിലല്ല, പ്രാദേശിക നിർവഹണത്തിലാണ് വയ്ക്കുന്നത്. ഒരു ആപ്ലിക്കേഷന് അതിന് മേലെ സ്വന്തം നയം ചേർക്കാം: പിൻ ചെയ്ത കീ, ഒരു എന്റർപ്രൈസ് ട്രസ്റ്റ് സ്റ്റോർ, അല്ലെങ്കിൽ കൂടുതൽ കർശനമായ ഐഡന്റിറ്റി പരിശോധന. സർവർ അയയ്ക്കുന്ന സർട്ടിഫിക്കറ്റ് പട്ടിക ആ പ്രക്രിയയ്ക്ക് നൽകുന്ന തെളിവാണ്, അതിന് ഒരിക്കലും നിർദ്ദേശമല്ല.

അതിനാൽ പൂർണ്ണമായ ചെയിൻ സർവറിന് ഭാഗങ്ങൾ ഉണ്ടെന്ന് തെളിയിക്കുന്നു. ക്ലയന്റ് അവ സ്വീകരിക്കുമെന്ന് തെളിയിക്കുന്നില്ല.

സർവർ യഥാർത്ഥത്തിൽ എന്ത് അയയ്ക്കുന്നുവെന്ന് കാണാൻ, ഇത് പ്രവർത്തിപ്പിക്കുക openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts ഒപ്പം ഔട്ട്പുട്ടിലെ സർട്ടിഫിക്കറ്റുകൾ എണ്ണുക. അവിടെ അപൂർണ്ണമായ ചെയിൻ സർവർ ഭാഗത്തെ പരിഹാരമാണ്. പൂർണ്ണമായ ചെയിൻ ചോദ്യം ക്ലയന്റിലേക്കും അതിന്റെ ആങ്കറുകളിലേക്കും മാറ്റുന്നു, അവിടെ സർവറിന് വോട്ടില്ല.

TLS പരിശോധന യഥാർത്ഥത്തിൽ മാറ്റുന്നത്

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

ക്രമീകരണം ബോധപൂർവവും പ്രാദേശികവുമാണ്. യഥാർത്ഥ സർവറിന്റെ ചെയിനിൽ ഒന്നും മാനേജുചെയ്യാത്ത ബ്രൗസറിനെ പകരം ഐഡന്റിറ്റി സ്വീകരിക്കാൻ നിർബന്ധിക്കാൻ കഴിയില്ല, അതിൽ ഒന്നും മാനേജുചെയ്യുന്ന ഉപകരണത്തെ അത് ചെയ്യുന്നതിൽ നിന്ന് തടയുന്നില്ല.

VPN അവസാനിപ്പിക്കുന്നത് HTTPS ഡീക്രിപ്ഷനല്ല

VPN പാളി ക്ലയന്റിനും ഗേറ്റ്വേയ്ക്കും ഇടയിൽ പാക്കറ്റുകൾ കൊണ്ടുപോകുന്നു. അത് നീക്കം ചെയ്യുന്നതോ അതിന്റെ കോൺഫിഗറേഷൻ വായിക്കുന്നതോ ഉള്ളിലെ HTTPS പേലോഡ് വെളിപ്പെടുത്തുന്നില്ല.

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

നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഘടകത്തിൽ പ്രതീക്ഷകൾ നിശ്ചയിക്കുക

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

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

ഫലം ശുദ്ധമായ ക്ലയന്റ് പ്രൊഫൈലിൽ പരിശോധിക്കുക, ഇതിനകം ഒഴിവാക്കൽ ചേർത്ത മെഷീനിൽ അല്ല. പുതിയ ഉപകരണം എന്ത് അനുഭവിക്കുമെന്ന് കാണിക്കുന്ന ഏക പരിശോധന അതാണ്.