TLS 1.3 ഇപ്പോഴും സർവർ നാമം സാധാരണ ടെക്സ്റ്റിൽ അയയ്ക്കുന്നു

ഒരു ലിസണറെ TLS 1.3 ലേക്ക് അപ്ഗ്രേഡ് ചെയ്യുന്നത് നിരീക്ഷകന് എന്ത് വായിക്കാം എന്നത് മാറ്റുന്നു, പക്ഷേ പതിപ്പ് നമ്പർ സൂചിപ്പിക്കുന്നത്രയല്ല. ClientHello ഇപ്പോഴും ഏതെങ്കിലും എൻക്രിപ്ഷനെക്കുറിച്ച് ചർച്ചയ്ക്ക് മുൻപേ യാത്ര ചെയ്യുന്നു, സാധാരണ കണക്ഷനിൽ ആവശ്യപ്പെട്ട സർവർ നാമം അവിടെ സാധാരണ ടെക്സ്റ്റിൽ നിലകൊള്ളുന്നു. Encrypted Client Hello അത് മറയ്ക്കുന്ന സംവിധാനമാണ്, ഇത് സ്വന്തം മുൻവ്യവസ്ഥകളുള്ള പ്രത്യേക വിന്യാസമാണ്. രണ്ട് സ്വഭാവങ്ങളിൽ ഏതെങ്കിലും അനുമാനിക്കുന്ന നയം എഴുതുന്നതിന് മുൻപ് ഈ നാല് ഘട്ടങ്ങൾ ചെയ്യുക.

ഹസ്തദാനം യഥാർത്ഥത്തിൽ എന്ത് വെളിപ്പെടുത്തുന്നു

TLS 1.3 സർവറിന്റെ സർട്ടിഫിക്കറ്റും ServerHello കഴിഞ്ഞ് വരുന്ന ഭൂരിഭാഗം ഹസ്തദാനവും എൻക്രിപ്റ്റ് ചെയ്യുന്നു. ക്ലയന്റ് ആദ്യം അയയ്ക്കുന്നതെല്ലാം ആ സംരക്ഷണത്തിന് പുറത്താണ്, കാരണം കീകൾ ഇനിയും ഇല്ല. സർവർ നാമ സൂചന ആ ആദ്യ യാത്രയുടെ ഭാഗമാണ്, അതിനാൽ നിഷ്ക്രിയ നിരീക്ഷകന് ഒന്നും തകർക്കാതെ അത് ഇപ്പോഴും വായിക്കാം.

ECH സ്പെസിഫിക്കേഷൻ, RFC 9849, സഹകരിക്കുന്ന സർവറിനായി ആന്തരിക ClientHello എൻക്രിപ്റ്റ് ചെയ്ത് ഇത് മാറ്റുന്നു. ബാഹ്യ ഹസ്തദാനം നിലനിൽക്കുന്നു, നെറ്റ്വർക്കിന് കാണാവുന്ന പൊതു നാമം വഹിക്കുന്നു, അതിനാൽ വിന്യാസത്തിന് ഇപ്പോഴും ഇടനിലക്കാർക്ക് അർത്ഥമുള്ള ബാഹ്യ ഐഡന്റിറ്റി ആവശ്യമാണ്. ആ ബാഹ്യ നാമമാണ് കണക്ഷൻ അജ്ഞാതമാകുമെന്ന് പ്രതീക്ഷിക്കുമ്പോൾ ആളുകൾ വിട്ടുപോകുന്ന ഭാഗം. ഇത് ഒരു ആവരണ നാമമാണ്, മറഞ്ഞ നാമമല്ല, മറ്റേതെങ്കിലും പോലെ ഇത് പരിഹരിക്കപ്പെടുകയും സാക്ഷ്യപ്പെടുത്തുകയും വേണം.

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

അനുമാനിക്കുന്നതിന് പകരം ഒരു ClientHello വായിക്കുക

ServerHello ലെ പതിപ്പ് ക്ലയന്റ് എന്ത് അയച്ചു എന്ന് പറയുന്നില്ല. ആദ്യ യാത്ര നേരിട്ട് നോക്കുക, നിങ്ങൾക്ക് പ്രധാനമായ നിരീക്ഷകനെ പ്രതിനിധീകരിക്കുന്ന സ്ഥാനത്ത് നിന്ന്.

openssl s_client -connect app.plant.example:443 -servername app.plant.example -tls1_3 </dev/null> 2>/dev/null | head -20
sudo tcpdump -ni eth0 -c 40 'tcp port 443' -w /tmp/tls.pcap
tshark -r /tmp/tls.pcap -Y 'tls.handshake.extensions_server_name' -T fields -e tls.handshake.extensions_server_name

ആദ്യ കമാൻഡ് ഒരു ഹസ്തദാനം നടത്തി സമ്മതിച്ച പാരാമീറ്ററുകൾ കാണിക്കുന്നു, അവയിൽ പ്രോട്ടോക്കോൾ പതിപ്പും നിങ്ങൾ ആവശ്യപ്പെട്ട നാമവും ഉൾപ്പെടുന്നു. രണ്ടാമത്തേത് യഥാർത്ഥ കണക്ഷന്റെ ആദ്യ പാക്കറ്റുകൾ പിടിച്ചെടുക്കുന്നു, മൂന്നാമത്തേത് ആ ക്യാപ്ചറിൽ നിന്ന് SNI ഫീൽഡ് വേർതിരിച്ചെടുക്കുന്നു. ഫീൽഡ് നിറഞ്ഞിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾ അനുകരിച്ച നിരീക്ഷകന് അത് വായിക്കാം.

രണ്ടും ഒത്തുപോകാത്തപ്പോൾ ക്ലയന്റ് വശത്തും പാതയിലും വെവ്വേറെ പിടിച്ചെടുക്കുക, കാരണം പ്രാദേശിക ക്യാപ്ചർ middlebox പിന്നീട് വീണ്ടും എഴുതുന്ന അല്ലെങ്കിൽ ഉപേക്ഷിക്കുന്ന ഒരു നാമം കാണിച്ചേക്കാം. സ്വയം TLS അവസാനിപ്പിക്കാത്ത ഹോസ്റ്റിൽ നിന്നും പിടിച്ചെടുക്കുക, കാരണം അവസാനിപ്പിക്കുന്ന പ്രോക്സി സാധാരണ ടെക്സ്റ്റ് അതിന്റെ രൂപകൽപ്പന പ്രകാരം കാണുന്നു, നെറ്റ്വർക്ക് എന്ത് കാണുന്നു എന്ന് ഒന്നും തെളിയിക്കുന്നില്ല.

ECH എക്സ്റ്റൻഷനെ ഒരു അവകാശവാദമായി കാണുക, തെളിവായല്ല

ClientHello യിൽ ECH എക്സ്റ്റൻഷൻ കാണുന്നത് കണക്ഷൻ ECH ഉപയോഗിച്ചു എന്ന് അർത്ഥമാക്കുന്നില്ല. ക്ലയന്റുകൾക്ക് ഉപയോഗയോഗ്യമായ കോൺഫിഗറേഷൻ ഇല്ലാത്തപ്പോൾ GREASE ECH അയയ്ക്കുന്നു, അവരുടെ ഹസ്തദാനങ്ങൾ ഒരേപോലെ കാണപ്പെടാൻ വേണ്ടി. എക്സ്റ്റൻഷൻ ഉണ്ട്, ആന്തരിക hello ഒരു ഇരയാണ്, യഥാർത്ഥ നാമം ഇപ്പോഴും വായിക്കാവുന്നതാണ്.

dig +short HTTPS app.plant.example
openssl s_client -connect app.plant.example:443 -tls1_3 -status </dev/null> 2>/dev/null | grep -i -E 'ech|status_request'

ആദ്യ കമാൻഡ് ഉറവിടം ECH കോൺഫിഗറേഷൻ പാരാമീറ്ററുള്ള HTTPS വിഭവ രേഖ പ്രസിദ്ധീകരിക്കുന്നുണ്ടോ എന്ന് കാണിക്കുന്നു, അങ്ങനെയാണ് ക്ലയന്റുകൾ കീ പഠിക്കുന്നത്. രണ്ടാമത്തേത് ഹസ്തദാനത്തിന്റെ സ്ഥിതി വിവരങ്ങൾ തിരയുന്നു, എന്നിരുന്നാലും ക്ലയന്റിന്റെ വിജയ സന്ദേശമാണ് ശക്തമായ തെളിവ്. സ്വീകാര്യതയാണ് പ്രധാനം: ഒത്തുപോകുന്ന കീ ഇല്ലാത്ത സർവറിന് ആന്തരിക hello ഡീക്രിപ്റ്റ് ചെയ്യാനാവില്ല, കണക്ഷൻ പിന്നോട്ട് പോകുന്നു.

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

നിരീക്ഷകന്റെ പരിധി നയത്തിൽ എഴുതുക

ഒരു നിയന്ത്രണത്തിന് എന്തിനെ ആശ്രയിക്കാം എന്ന് തീരുമാനിക്കുന്നതിന് മുൻപ് നിരീക്ഷകൻ എവിടെ ഇരിക്കുന്നു, ആ ബിന്ദുവിൽ എന്ത് ദൃശ്യമാണ് എന്ന് വ്യക്തമാക്കുക. ബ്രൗസറിന്റെ സൈറ്റിലേക്കുള്ള കണക്ഷൻ, ബാഹ്യ VPN ഗതാഗതം, TLS അവസാനിപ്പിക്കുന്ന പ്രോക്സി — ഓരോന്നും വ്യത്യസ്ത വസ്തുതാസമുച്ചയം വെളിപ്പെടുത്തുന്നു, ഒരു സ്ഥാനത്തിനായി എഴുതിയ നിയമം മറ്റൊന്നിലേക്ക് അപൂർവ്വമായി വ്യക്തമായി കൈമാറ്റം ചെയ്യപ്പെടുന്നു.

ഒരു നിയന്ത്രണം SNI വായനയെ ആശ്രയിക്കുന്നുവെങ്കിൽ, ECH ലഭ്യമാകുമ്പോഴും ഇല്ലാത്തപ്പോഴും വിന്യസിച്ച ക്ലയന്റുകൾ എങ്ങനെ പെരുമാറുന്നു എന്ന് പരീക്ഷിക്കുക. തുടർന്ന് അനുയോജ്യതയുടെ അനന്തരഫലം രേഖപ്പെടുത്തുക, കാരണം നിശബ്ദമായി പൊരുത്തം നിർത്തുന്ന ഫിൽട്ടർ ഒരിക്കലും വിന്യസിക്കാത്തതിനേക്കാൾ മോശമാണ്.

അവസാനം, അനിശ്ചിതത്വം രേഖയിൽ സൂക്ഷിക്കുക. പഴയ സർവ്വവ്യാപി അവകാശവാദം പുതിയത് കൊണ്ട് മാറ്റിസ്ഥാപിക്കുന്നത് അതേ വിടവ് മറ്റൊരു പ്രോട്ടോക്കോൾ നാമത്തിന് കീഴിൽ അവശേഷിപ്പിക്കുന്നു, അടുത്ത അവലോകനക്കാരൻ അത് അതേ ദൃഢതയോടെ വിശ്വസിക്കും.