TLS നിയന്ത്രണ ചാനലിനുള്ളിലൂടെ സഞ്ചരിക്കുന്നു, മുഴുവൻ ടണലിലൂടെയല്ല

VPN വിവരണത്തിൽ TLS എന്ന വാക്ക് കണ്ട് വെബ് പ്രോക്സി ഈ ട്രാഫിക് മനസ്സിലാക്കുമെന്ന് അനുമാനിക്കുന്നത് സാധാരണ എളുപ്പവഴിയാണ്. ഈ പ്രോട്ടോക്കോളിനുള്ളിൽ പിയർമാർ അവരുടെ സ്വന്തം പാക്കറ്റുകൾ കൈമാറുന്നു, TLS ആ കൈമാറ്റത്തിലെ ഒരു ചാനലിന്റെ ഭാഗമായി പ്രവർത്തിക്കുന്നു. ഉപയോക്താവിന് പ്രധാനമായ പേലോഡ് വേറെ സന്ദേശ ഫോർമാറ്റിലാണ് സഞ്ചരിക്കുന്നത്, അതുകൊണ്ട് രണ്ടും സാധാരണ HTTPS സെഷനുമായി ഒരിക്കലും ഒത്തുപോകുന്നില്ല.

ആവരണം ആദ്യം വരുന്നു

ഓരോ ടണൽ പാക്കറ്റും പ്രോട്ടോക്കോളിന്റെ സ്വന്തം ഹെഡറിൽ തുടങ്ങുന്നു: സന്ദേശ തരം, കീ ഐഡന്റിഫയർ, ബൈറ്റ്-സ്ട്രീം ഗതാഗതത്തിൽ പാക്കറ്റ് എവിടെ അവസാനിക്കുന്നു എന്ന് അടയാളപ്പെടുത്തുന്ന നീള പ്രിഫിക്സ്. ആ ആവരണം വിശകലനം ചെയ്യാത്ത വായനക്കാരന് അടുത്ത ഫീൽഡ് എവിടെ തുടങ്ങുന്നു എന്ന് അറിയാൻ കഴിയില്ല.

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

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

വിശ്വാസ്യതാ പാളി പ്രോട്ടോക്കോളിന്റേതാണ്

നിയന്ത്രണ സന്ദേശങ്ങൾക്ക് ക്രമബദ്ധവും സ്ഥിരീകരിച്ചതുമായ വിതരണം ആവശ്യമാണ്, പ്രോട്ടോക്കോൾ അത് സ്വയം സ്ഥിരീകരണങ്ങളും വീണ്ടും അയയ്ക്കലുകളും കൊണ്ട് നൽകുന്നു. ഒരു സ്ഥിരീകരണം സ്വന്തം സന്ദേശമായി വരാം അല്ലെങ്കിൽ മറ്റൊരു നിയന്ത്രണ സന്ദേശത്തോടൊപ്പം യാത്ര ചെയ്യാം, ഇത് ഒരു വൃത്തിയുള്ള കൈമാറ്റം പ്രതീക്ഷിക്കുന്നവർക്ക് ട്രെയ്സുകൾ ക്രമരഹിതമായി തോന്നിപ്പിക്കുന്നു.

നേട്ടം എന്നത് പുറം ഗതാഗതം UDP ആണെങ്കിലും TLS ഹാൻഡ്ഷേക്കിന് വിശ്വസനീയമായ വാഹകൻ ലഭിക്കുന്നു എന്നതാണ്. വില എന്നത് ഒരു ഡാറ്റാഗ്രാമിൽ ആ സംഭാഷണത്തിന്റെ ഒരു ഭാഗം മാത്രം അടങ്ങിയിരിക്കാം എന്നതാണ്, അതിനാൽ അതിനെ സ്വതന്ത്ര TLS റെക്കോർഡായി കണക്കാക്കുന്നത് നിരർത്ഥകത സൃഷ്ടിക്കുന്നു. പുനഃസംയോജനം പ്രോട്ടോക്കോൾ പാളിയിൽ നടക്കണം. അതുകൊണ്ടാണ് പിടിച്ചെടുത്ത പാക്കറ്റ് പൂർണ്ണ ഹാൻഡ്ഷേക്ക് ഘട്ടം പോലെ അപൂർവമായി കാണപ്പെടുന്നത്.

പുറം ഗതാഗതം TCP ലേക്ക് മാറ്റുന്നത് ഈ പാളി നീക്കം ചെയ്യുന്നില്ല. വിശ്വസനീയമായ ഗതാഗതം എന്നാൽ പ്രോട്ടോക്കോൾ തലത്തിൽ കുറവ് വീണ്ടും അയയ്ക്കലുകൾ എന്നാണ്, ഫ്രെയിമിംഗ് അപ്രത്യക്ഷമാകുന്നു അല്ലെങ്കിൽ ട്രാഫിക് HTTP ആകുന്നു എന്നല്ല.

ഡാറ്റ പാക്കറ്റുകൾ വേറെ ഫോർമാറ്റ് ഉപയോഗിക്കുന്നു

സെഷൻ നിലവിലുള്ളപ്പോൾ, ഉപയോഗപ്രദമായ പേലോഡ് ആന്തരിക IP പാക്കറ്റുകളോ Ethernet ഫ്രെയിമുകളോ വഹിക്കുന്ന ഡാറ്റ സന്ദേശങ്ങളായി വരുന്നു. അവ സ്വന്തം കീകളും സ്വന്തം പ്രോസസ്സിംഗും കൊണ്ട് സംരക്ഷിക്കപ്പെടുന്നു, TLS ലൈബ്രറി സ്വീകരിക്കുന്ന ഏതെങ്കിലും അർത്ഥത്തിൽ അവ TLS ആപ്ലിക്കേഷൻ റെക്കോർഡുകളല്ല.

ആ വേർപാട് കോൺഫിഗറേഷനിൽ കാണാം: നിയന്ത്രണ ചാനലിനും ഡാറ്റ ചാനലിനും വെവ്വേറെ സൈഫർ ക്രമീകരണങ്ങളുണ്ട്, അതിനാൽ ഒന്നിനെ പേരിടുന്ന ലോഗ് വരി മറ്റതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ശക്തമായ നിയന്ത്രണ സൈഫർ ശക്തമായ ഡാറ്റ സൈഫറിന്റെ തെളിവായി വായിക്കുന്നത് സാധാരണ റിപ്പോർട്ടിംഗ് പിശകാണ്.

ബന്ധപ്പെട്ട തെറ്റിദ്ധാരണയും വിശദീകരണത്തിൽ നിന്ന് മാറ്റി നിർത്തുക. TLS സമമിത ഡാറ്റ ചാനലിന് അരികിൽ ഇരിക്കുന്ന പൊതു കീ ചാനലല്ല, കാരണം കീകൾ സ്ഥാപിച്ചതിന് ശേഷം TLS തന്നെ അതിന്റെ റെക്കോർഡുകൾ സമമിതമായി സംരക്ഷിക്കുന്നു. യഥാർത്ഥ വ്യത്യാസം പങ്കും പാക്കറ്റ് ഫോർമാറ്റുമാണ്, ഓരോ വശവും ഏത് തരം ക്രിപ്റ്റോഗ്രഫി ഉപയോഗിക്കുന്നു എന്നല്ല.

HTTPS പ്രോക്സിക്ക് സഹായിക്കാൻ കഴിയാത്തത് എന്തുകൊണ്ട്

TLS അവസാനിപ്പിക്കുന്ന പ്രോക്സി TLS റെക്കോർഡ് സ്ട്രീമും പിന്നെ അതിനുള്ളിൽ ഒരു ആപ്ലിക്കേഷൻ പ്രോട്ടോക്കോളും പ്രതീക്ഷിക്കുന്നു. ഈ പ്രോട്ടോക്കോളിന്റെ നിയന്ത്രണ ചാനൽ അതിന്റെ സ്വന്തം ഫ്രെയിമിംഗിനുള്ളിൽ, ചുറ്റും ഒരു വിശ്വാസ്യതാ പാളിയോടെ വഹിക്കപ്പെടുന്നു, അതിനാൽ അവസാനിപ്പിക്കുന്ന പ്രോക്സി ആ ഫ്രെയിമിംഗിനെ കേടായ ഇൻപുട്ടായി വായിക്കുന്നു.

ബൈറ്റുകളോ ഡാറ്റാഗ്രാമുകളോ വ്യാഖ്യാനിക്കാതെ കടത്തിവിടുന്ന സുതാര്യ ഫോർവേഡർ സ്ട്രീം വീണ്ടും എഴുതുകയോ പുനഃസംയോജിപ്പിക്കുകയോ ചെയ്യുന്നില്ലെങ്കിൽ പ്രവർത്തിക്കാം. ഏതൊരു മധ്യവർത്തിയെക്കുറിച്ചും ചോദിക്കേണ്ട ചോദ്യം അവർ യഥാർത്ഥ ഗതാഗതവും ഫ്രെയിമിംഗും കൈമാറുന്നുണ്ടോ എന്നാണ്, എവിടെയെങ്കിലും TLS പിന്തുണയ്ക്കുന്നുണ്ടോ എന്നല്ല. പ്രോക്സി നിയമങ്ങളിൽ ഒരു വൈകുന്നേരം ചെലവഴിക്കുന്നതിന് മുമ്പ് അത് ചോദിക്കുക. ഇവിടെയുള്ള മിക്ക പരാജയങ്ങളും വാസ്തുവിദ്യാപരമാണ്, കാണാത്ത ക്രമീകരണമല്ല.

ഒരു ട്രെയ്സ് ശരിയായി വായിക്കുക

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

കീ-രീതികളുടെ ചരിത്രപരമായ വിവരണങ്ങൾ പ്രോട്ടോക്കോൾ ഡോക്യുമെന്റേഷനിൽ ഒരു നിർദ്ദിഷ്ട പതിപ്പ് ഇപ്പോഴും എല്ലാ പഴയ ഫോർമാറ്റുകളും പിന്തുണയ്ക്കുന്നു എന്ന് അർത്ഥമാക്കുന്നില്ല. നിങ്ങൾ പ്രവർത്തിപ്പിക്കുന്ന പതിപ്പ് പരിശോധിക്കുക, പിന്നെ കാര്യങ്ങൾ മുമ്പ് എങ്ങനെ പ്രവർത്തിച്ചു എന്ന് വിവരിക്കുന്ന ഖണ്ഡികയിൽ പ്രതീക്ഷ കെട്ടിപ്പടുക്കുക.