TLS കീ പങ്കിടലും ക്ലയന്റ് സർട്ടിഫിക്കറ്റും: ഏതാണ് ലോഗിൻ ചെയ്യുന്നത്?
കീ കരാറിനെ ക്ലയന്റ് പ്രാമാണീകരണത്തിൽ നിന്നും ആപ്ലിക്കേഷൻ ഐഡന്റിറ്റിയിൽ നിന്നും വേർതിരിക്കുക, കണക്ഷൻ യഥാർത്ഥത്തിൽ ഏതാണ് ഉപയോഗിച്ചതെന്ന് കാണിക്കുന്ന ഹാൻഡ്‌ഷേക്ക് സന്ദേശങ്ങൾ വായിക്കുക.
ഹാൻഡ്‌ഷേക്കിൽ ഒരു പൊതു കീ-കൈമാറ്റ മൂല്യം വഹിക്കുന്നത് ക്ലയന്റ് ലോഗിൻ ചെയ്യുന്ന അതേ സംഭവമല്ല. ഒന്ന് കണക്ഷനുള്ള ക്രിപ്റ്റോഗ്രാഫിക് അവസ്ഥ സ്ഥാപിക്കുന്നു; മറ്റൊന്ന് ക്ലയന്റ് ആരാണെന്ന് പറയുന്നു, സർവർ അത് ആവശ്യപ്പെടുകയും കൈമാറ്റം അതിനെ പിന്തുണയ്ക്കുകയും ചെയ്യുമ്പോൾ മാത്രമേ അത് സംഭവിക്കൂ. ആദ്യത്തേതിനെ രണ്ടാമത്തേതായി കാണുന്നത് VPN എന്ത് മറയ്ക്കുന്നു, എന്ത് മറയ്ക്കുന്നില്ല എന്നതിനെക്കുറിച്ച് തെറ്റായ നിഗമനങ്ങളിലേക്ക് നയിക്കുന്നു. സന്ദേശങ്ങൾ വായിക്കുക, എന്നിട്ട് നാല് ഗുണങ്ങളിൽ ഏതാണ് നിങ്ങൾ യഥാർത്ഥത്തിൽ നിരീക്ഷിച്ചതെന്ന് തീരുമാനിക്കുക.
ക്യാപ്ചറിൽ ഒരേപോലെ തോന്നുന്ന രണ്ട് വസ്തുക്കൾ
TLS 1.3 ക്ലയന്റിന് ഒരു സർട്ടിഫിക്കറ്റും അവതരിപ്പിക്കാതെ തന്നെ തന്റെ ആദ്യ ഫ്ലൈറ്റിൽ കീ-കൈമാറ്റ വസ്തുവക നൽകാനാകും. ആ സംഭാവന രൂപകൽപ്പനയാൽ തന്നെ പൊതുവാണ്, കാരണം പങ്കിട്ട രഹസ്യം കണ്ടെത്താൻ സർവറിന് അത് ആവശ്യമാണ്. ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് മറ്റൊരു സന്ദേശമാണ്, സർവർ ഒന്ന് ആവശ്യപ്പെട്ടതിനുശേഷം മാത്രമേ അയയ്ക്കാറുള്ളൂ. അത് സർവർ പിന്നീട് പരിശോധിക്കുന്ന ഐഡന്റിറ്റി വഹിക്കുന്നു, പരസ്പര പ്രാമാണീകരണം സൈഫർ സ്യൂട്ട് സൂചിപ്പിക്കുന്ന ഗുണമല്ല, സർവർ എടുക്കുന്ന തീരുമാനമാണ്. ആപ്ലിക്കേഷൻ ഐഡന്റിറ്റി തികച്ചും മൂന്നാമത്തെ കാര്യമാണ്: ലോഗിൻ ഫോം, ബെയറർ ടോക്കൺ, കുക്കി. അവയൊന്നും ഹാൻഡ്‌ഷേക്കിൽ പ്രത്യക്ഷപ്പെടുന്നില്ല, എല്ലാം നെറ്റ്‌വർക്ക് പാത മാറുമ്പോഴും നിലനിൽക്കുന്നു.
| Object in play | What it establishes |
|---|---|
| Key-exchange share | Cryptographic state for this connection |
| Server certificate | Which server the client reached |
| Client certificate | Client authentication, when requested |
| Application session | Account identity inside the application |
നാല് വരികൾ സ്വതന്ത്രമാണ്. ഒരു കണക്ഷന് ഒന്നും രണ്ടും വരികൾ ഉണ്ടാകാം, മൂന്നാമത്തേത് ഒഴിവാക്കാം, എന്നിട്ടും കുക്കി ഹെഡറിൽ നാലാമത്തേത് വഹിക്കാം.
പിടിച്ചെടുത്ത ഹാൻഡ്‌ഷേക്ക് എന്ത് തെളിയിക്കാനാകും എന്ന് തീരുമാനിക്കുക
ഹാൻഡ്‌ഷേക്കിൽ നിന്ന് മാത്രം നിരീക്ഷകൻ ചർച്ച ചെയ്ത പതിപ്പ്, സൈഫർ സ്യൂട്ട്, സർവറിന്റെ സർട്ടിഫിക്കറ്റ്, പൊതു കീ-കൈമാറ്റ മൂല്യങ്ങൾ എന്നിവ അറിയുന്നു. ഒരു ക്ലയന്റ് നിർവഹണത്തിന്റെ വിരലടയാളം എടുക്കാനും ഏത് സർവറുമായി ബന്ധപ്പെട്ടുവെന്ന് കാണാനും അത് മതി. അത് നൽകാത്തത് കണക്ഷൻ ഡീക്രിപ്റ്റ് ചെയ്യാൻ വേണ്ട സ്വകാര്യ അവസ്ഥയാണ്; അതിന്റെ രഹസ്യത പൊതു വിഹിതത്തിലല്ല, ക്ഷണികമായ കൈമാറ്റത്തിലാണ് നിൽക്കുന്നത്. അത് അക്കൗണ്ട് ഐഡന്റിറ്റിയും നൽകുന്നില്ല, അത് തുടക്കം മുതൽ ഹാൻഡ്‌ഷേക്കിൽ ഉണ്ടായിരുന്നില്ല.
അതിനാൽ സത്യസന്ധമായ നിഗമനം ഇടുങ്ങിയതാണ്: ഈ കൈമാറ്റത്തിൽ ഒരു ക്ലയന്റ് സർട്ടിഫിക്കറ്റും അവതരിപ്പിച്ചിട്ടില്ല. ക്ലയന്റ് ബന്ധിപ്പിക്കാവുന്ന ഒന്നും അയച്ചില്ല എന്നല്ല, സെഷന് ഒരു ഐഡന്റിഫയറും ഉണ്ടായിരുന്നില്ല എന്നത് തീർച്ചയായും അല്ല.
സൈഫറിന്റെ പേരല്ല, സന്ദേശങ്ങൾ വായിക്കുക
സൈഫർ സ്യൂട്ടിൽ നിന്ന് അനുമാനിക്കുന്നതിനുപകരം സർവറിനോട് എന്താണ് ആവശ്യപ്പെടുന്നതെന്ന് ചോദിക്കുക. സർട്ടിഫിക്കറ്റ് അഭ്യർത്ഥന ഉൾപ്പെടുന്ന TLS 1.3 ഹാൻഡ്‌ഷേക്ക് ട്രാൻസ്ക്രിപ്റ്റിൽ കാണാം, അതിന്റെ അഭാവവും അത്രതന്നെ കാണാം.
openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'പിന്നീട് ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ക്രമീകരിച്ച് ആവർത്തിച്ച് താരതമ്യം ചെയ്യുക. രണ്ടാം റണ്ണിൽ സർട്ടിഫിക്കറ്റ് അയയ്ക്കുന്നതും സ്വീകരിക്കുന്നതും കാണണം; ആദ്യത്തേതിൽ ഒന്നും കാണരുത്, അതാണ് ചർച്ചയുടെ കൃത്യമായ വ്യത്യാസം.
openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quietസാധാരണ ബ്രൗസിംഗ് കേസ് മാത്രം വേണമെങ്കിൽ, പ്രോട്ടോക്കോൾ പതിപ്പ്, പരിശോധനാ ഫലം, ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് വാഗ്ദാനം ചെയ്തോ എന്നിവ കാണാൻ ക്ലയന്റിന്റെ വിശദമായ ഔട്ട്‌പുട്ട് മതി. ഒരിക്കലും സർട്ടിഫിക്കറ്റ് അഭ്യർത്ഥന അയയ്ക്കാത്ത സർവറിന് ഒന്ന് ലഭിക്കാൻ കഴിയില്ല.
പുനരാരംഭം ഉത്തരം മാറ്റുന്നിടത്ത്
TLS 1.3 പുനരാരംഭം രഹസ്യ അവസ്ഥയുമായി ബന്ധിപ്പിച്ച ടിക്കറ്റുകൾ ഉപയോഗിക്കുന്നു, അതിനാൽ പിന്നീടുള്ള കണക്ഷന് പൂർണ്ണ സർട്ടിഫിക്കറ്റ് കൈമാറ്റമില്ലാതെ പൂർത്തിയാകാം. അത് നിരീക്ഷകൻ കാണുന്നത് കുറയ്ക്കുകയും ട്രാൻസ്ക്രിപ്റ്റ് തെളിയിക്കുന്നത് മാറ്റുകയും ചെയ്യുന്നു. ഇല്ലാതിരുന്നിടത്ത് അത് ഐഡന്റിറ്റി സൃഷ്ടിക്കുന്നില്ല. പുനരാരംഭിച്ച സെഷൻ ഇപ്പോഴും അതേ ആപ്ലിക്കേഷൻ സെഷനിൽ ഉൾപ്പെടുന്നു, ആ സെഷനിലെ ഏത് കുക്കിയോ ടോക്കണോ പ്രധാനപ്പെട്ട ഐഡന്റിഫയറായി തുടരുന്നു.
അതുകൊണ്ടാണ് "ക്ലയന്റ് സർട്ടിഫിക്കറ്റില്ല" എന്നിടത്ത് നിർത്തുന്ന സ്വകാര്യതാ അവലോകനം രസകരമായ ഭാഗം വിട്ടുപോകുന്നത്. ചോദിക്കേണ്ട ചോദ്യം ഏത് കക്ഷിക്കാണ് സ്ഥിരമായ ഐഡന്റിഫയർ ഉള്ളത് എന്നതാണ്, ഒരു ഹാൻഡ്‌ഷേക്കിൽ നിന്ന് ഏത് സന്ദേശം വിട്ടുപോയി എന്നതല്ല.
ഒരു വിധിയല്ല, നാല് ഗുണങ്ങൾ രേഖപ്പെടുത്തുക
കീ കരാർ, സർവർ പരിശോധന, ക്ലയന്റ് പ്രാമാണീകരണം, ആപ്ലിക്കേഷൻ ഐഡന്റിറ്റി എന്നിവ ഓരോന്നിന്റെയും തെളിവോടെ നാല് വേറിട്ട വരികളായി എഴുതുക. ഈ പട്ടിക പ്രോട്ടോക്കോൾ പതിപ്പ് മാറുമ്പോഴും നിലനിൽക്കുന്നു, സ്വകാര്യതയെക്കുറിച്ചുള്ള വാദം മറ്റൊരാൾക്ക് പരിശോധിക്കാനാകുന്നതാക്കുന്നു. പിന്നീട് നെറ്റ്‌വർക്ക് പാത എന്ത് നൽകുന്നു എന്ന് ചേർക്കുക. VPN ഒരു സേവനം കാണുന്ന ഉറവിട വിലാസം മാറ്റുന്നു; ആപ്ലിക്കേഷനിൽ ഇതിനകം ഉള്ള ലോഗിൻ, കുക്കി, ഉപകരണ വിരലടയാളം അത് നീക്കം ചെയ്യുന്നില്ല.
കണക്ഷന്റെ ചർച്ച ചെയ്ത പതിപ്പും സർട്ടിഫിക്കറ്റ് അഭ്യർത്ഥനയുടെ ഫലവും ഒരുമിച്ച് രേഖപ്പെടുത്തുക, കാരണം സ്വന്തം ക്യാപ്ചർ ഇല്ലാതെ നിങ്ങളുടെ നിഗമനം പുനർനിർമ്മിക്കാൻ അവലോകകന് ആ ജോഡിയാണ് വേണ്ടത്.