VPN-ന് പിന്നിലെ കാഷിംഗ്: HTTPS ഇപ്പോഴും മറയ്ക്കുന്നത്

VPN സെർവറിന് അരികിൽ ഒരു കാഷ് ടണലിന് പിന്നിലുള്ള എല്ലാവർക്കും സൗജന്യ ബാൻഡ്വിഡ്ത്ത് പോലെ തോന്നും. അതല്ല, കാരണം ആ പോയിന്റിലൂടെ കടക്കുന്ന ബൈറ്റുകൾ ബ്രൗസറും വെബ്സൈറ്റും അറ്റങ്ങളായുള്ള TLS സെഷൻ കൊണ്ട് സംരക്ഷിക്കപ്പെട്ടിരിക്കുന്നു. VPN ഗേറ്റ്വേ സ്വന്തം പുറം എൻക്രിപ്ഷൻ മാത്രം നീക്കുന്നു, ആപ്പിന്റേതല്ല. ഹാർഡ്വെയർ ചേർക്കുന്നതിന് മുമ്പ് ഏത് ആവർത്തിച്ചുവരുന്ന വസ്തു വീണ്ടും ഉപയോഗിക്കണമെന്ന് തീരുമാനിക്കുക.

TLS സെഷൻ ബ്രൗസറിന്റേതാണ്

സാധാരണ HTTPS-ൽ ബ്രൗസർ സൈറ്റുമായി കീകൾ ചർച്ച ചെയ്യുന്നു, ഹാൻഡ്ഷേക്കിന് ശേഷമുള്ള ഓരോ റെക്കോർഡും ആ അറ്റങ്ങളുടെ ജോടിക്കായി എൻക്രിപ്റ്റ് ചെയ്യുന്നു. VPN ഗേറ്റ്വേ താൻ സൃഷ്ടിച്ച ടണൽ ഡീക്രിപ്റ്റ് ചെയ്ത് പിന്നീട് അതാര്യമായ TLS റെക്കോർഡുകൾ കൈമാറുന്നു. ലക്ഷ്യങ്ങൾ, സമയം, അളവ് എന്നിവ കാണാം, അഭ്യർത്ഥനാ വരിയോ പ്രതികരണത്തിന്റെ ഉള്ളടക്കമോ അല്ല. ഏതൊരു കാഷും ഈ അതിരുമായി ജീവിക്കണം.

അത് തകർക്കുന്ന ഏത് രൂപകൽപ്പനയും TLS ഇടപെടൽ രൂപകൽപ്പനയാണ്, സർട്ടിഫിക്കറ്റ് വിശ്വാസത്തിലും ഉപകരണ മാനേജ്മെന്റിലും അതിന്റേതായ പ്രത്യാഘാതങ്ങളോടെ.

CONNECT ഒരു ടണലാണ്, കാഷ് അല്ല

വ്യക്തമായ ഫോർവേഡ് പ്രോക്സി സാധാരണയായി HTTP CONNECT അഭ്യർത്ഥന സ്വീകരിച്ച് ഇരു ദിശകളിലേക്കും ബൈറ്റുകൾ കൈമാറുന്നു. കൈമാറ്റം എന്നതാണ് പ്രധാന വാക്ക്: പ്രോക്സി എൻക്രിപ്റ്റ് ചെയ്ത സംഭാഷണം വിശകലനം ചെയ്യുന്നില്ല.

curl -sSI -x http://proxy.example:3128 https://example.com/

പ്രതികരണ ഹെഡറുകൾ പ്രോക്സിയുടെ ടണൽ കൈകാര്യം ചെയ്യലിൽ നിന്നാണ് വരുന്നത്, പേജിന്റെ കാഷ് ചെയ്ത പകർപ്പിൽ നിന്നല്ല. വിജയകരമായ CONNECT അർത്ഥമാക്കുന്നത് പാത പ്രവർത്തിക്കുന്നു എന്നാണ്, വീണ്ടും ഉപയോഗിക്കാൻ എന്തെങ്കിലും സംഭരിച്ചു എന്നല്ല. പോർട്ട് 443 ഒരു കാഷിലേക്ക് തിരിക്കുന്നത് അതിനെ TLS സംസാരിക്കാൻ പഠിപ്പിക്കുന്നുമില്ല, കാരണം കാഷിംഗിന് വായിക്കാവുന്ന സന്ദേശങ്ങൾ വേണം. ക്ലയന്റ് കോൺഫിഗറേഷൻ പിന്തുണയുള്ള വ്യക്തമായ പ്രോക്സി ക്രമീകരണം ഉപയോഗിക്കണം, വിശദീകരിക്കാത്ത റീഡയറക്ടല്ല.

നിങ്ങൾ നടത്തുന്നത് കാഷ് ചെയ്യുക, ബ്രൗസ് ചെയ്യുന്നതല്ല

ഉള്ളടക്കം നിങ്ങളുടേതാണെങ്കിൽ, റിവേഴ്സ് പ്രോക്സിക്ക് TLS അവസാനിപ്പിച്ച് അംഗീകരിച്ച പ്രതികരണങ്ങൾ ബോധപൂർവം സംഭരിക്കാം. അത് പാക്കേജ് ശേഖരത്തിന്റേതാണെങ്കിൽ, പ്രോജക്ട് പിന്തുണയ്ക്കുന്ന മിറർ ഉപയോഗിക്കുക.

nginx -T | grep -n "proxy_cache"
curl -sSI https://mirror.example/pkg/index.json | grep -i -E "cache-control|age"

ആദ്യ കമാൻഡ് കാഷ് മേഖല ക്രമീകരിച്ചിട്ടുണ്ടോ എവിടെ ബാധകമാണോ എന്ന് കാണിക്കുന്നു, രണ്ടാമത്തേത് ഒരു വസ്തുവിനായി ഉറവിടത്തിന്റെ സ്വന്തം കാഷിംഗ് നിർദ്ദേശങ്ങൾ കാണിക്കുന്നു. പങ്കിട്ട കാഷ് പുതുമ, കാഷ് നിയന്ത്രണങ്ങൾ, പ്രാതിനിധ്യങ്ങളെ വേർതിരിക്കുന്ന അഭ്യർത്ഥനാ ഗുണങ്ങൾ എന്നിവ മാനിക്കണം; private കൂടാതെ no-store വ്യത്യസ്ത കാര്യങ്ങളാണ് അർത്ഥമാക്കുന്നത്, ഹിറ്റ് നിരക്ക് ഉയർത്താൻ ഒന്നും നീക്കം ചെയ്യരുത്. HTTP കാഷിംഗ് നിയമങ്ങൾ പ്രാമാണീകരിച്ച അഭ്യർത്ഥനകൾക്കുള്ള പ്രതികരണങ്ങൾ സംഭരിക്കുന്നതും പരിമിതപ്പെടുത്തുന്നു, അവിടെത്തന്നെയാണ് വ്യക്തിഗത പേജ് ഡാറ്റ വെളിപ്പെടുത്തലാകുന്നത്. പ്രോക്സിയെ തുറന്ന റിലേയായി വെളിപ്പെടുത്തുന്നതിന് പകരം അംഗീകരിച്ച ക്ലയന്റുകളിൽ പരിമിതപ്പെടുത്തുക.

ഹിറ്റ് അളക്കുക, സ്റ്റോപ്പ്വാച്ചല്ല

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

ജോലിഭാരം, കാഷ് കീ, വീണ്ടും ഉപയോഗം അനുവദിച്ച നയം എന്നിവ രേഖപ്പെടുത്തുക. കാഷ് എന്നത് ഒപ്റ്റിമൈസേഷന്റെ വേഷത്തിലുള്ള ഡാറ്റ പങ്കിടൽ തീരുമാനമാണ്.