ഒരു അധിക പുതിയ വരി CONNECT-ന് ശേഷം TLS തകർക്കാം

CONNECT 200 തിരികെ നൽകുകയും TLS ഉടൻ ഡീകോഡ് ചെയ്യാൻ കഴിയാതിരിക്കുകയും ചെയ്യുമ്പോൾ, സർട്ടിഫിക്കറ്റുകളോ സൈഫറുകളോ മാറ്റുന്നതിന് മുമ്പ് കണക്ടറിലെ അതിർത്തി ബൈറ്റുകൾ പരിശോധിക്കുക.

സൃഷ്ടിച്ച അധികാര മൂല്യം ഇതിനകം ഒരു പുതിയ വരിയിൽ അവസാനിക്കാം. മറ്റൊരു വരി-അവസാനം ചേർക്കുന്നത് HTTP ഹെഡറുകൾ നേരത്തെ അവസാനിപ്പിക്കാം, ഉദ്ദേശിച്ച Host ഫീൽഡോ മറ്റ് സാധാരണ ടെക്സ്റ്റോ അഭ്യർത്ഥനയുടെ പിന്നിൽ വിട്ടേക്കാം.

ഏറ്റവും ചെറിയ HTTP/1.1 CONNECT അഭ്യർത്ഥന വരികൾക്കിടയിൽ CRLF-ഉം അവസാനം ശൂന്യ വരിയും ഉപയോഗിക്കുന്നു:

b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"

ഏതെങ്കിലും അധികാര ഫീൽഡ് ആ അവസാന ശൂന്യ വരിക്ക് മുമ്പ് വയ്ക്കുക, ഉള്ളിൽ വരി-വിരാമം ഇല്ലാതെ. Python-ൽ "\n" ഒരു പുതിയ വരിയെ പ്രതിനിധീകരിക്കുന്നു; ബാക്ക്സ്ലാഷും n അക്ഷരവും ഉള്ള റോ സ്ട്രിംഗ് അല്ല. നീക്കം ചെയ്യാൻ ശ്രമിക്കുന്നതിന് മുമ്പ് എൻകോഡിംഗ് സഹായി ഏത് ബൈറ്റുകൾ സൃഷ്ടിക്കുന്നുവെന്ന് പരിശോധിക്കുക—പഴയ സഹായികൾ വരി-വിരാമങ്ങൾ ചേർത്തേക്കാം.

CONNECT വിജയിച്ചാൽ, ആ ബാക്കി ബൈറ്റുകൾ തുരങ്ക പ്രോട്ടോക്കോളിന്റേതാണ്. വഴിതെറ്റിയ സാധാരണ ടെക്സ്റ്റ് TLS പ്രതീക്ഷിക്കുന്ന ഒരു സഹപ്രവർത്തകനിലേക്ക് എത്താം. വിജയകരമായ നില തെറ്റായ അഭ്യർത്ഥനയ്ക്ക് ശേഷം ഇതിനകം ക്യൂവിൽ നിൽക്കുന്ന ബൈറ്റുകൾ നന്നാക്കാൻ കഴിയില്ല.

സ്വീകരണ അതിർത്തിയും പരിശോധിക്കുക. സോക്കറ്റ് TLS-ന് കൈമാറുന്നതിന് മുമ്പ് പൂർണ്ണ പ്രോക്സി പ്രതികരണം വായിക്കുക, ഭാഗിക വായനകൾ കൈകാര്യം ചെയ്യുക, ഹെഡറുകൾക്കപ്പുറം വായിച്ചതെല്ലാം സൂക്ഷിക്കുക. ഒരു സോക്കറ്റ് വായനയിൽ ഒരു പൂർണ്ണ സന്ദേശം ഉണ്ടായിരിക്കണമെന്നില്ല.

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