Squid இன் HTTPS தடுப்புப் பக்கத்தை உலாவிகள் ஏன் மறைக்கலாம்

ப்ராக்ஸியின் தனிப்பயன் தடுப்புப் பக்கம் HTTP தளத்திற்குத் தோன்றும். HTTPS தளத்திற்கு, உலாவி அதற்குப் பதிலாக சுரங்கப்பாதை பிழையைக் காட்டுகிறது. HTML வார்ப்புருவை மீண்டும் மாற்றுவது எதையும் மாற்றாமல் இருக்கலாம்.

வெளிப்படையான HTTP ப்ராக்ஸியுடன், HTTPS வருகை பொதுவாக CONNECT உடன் தொடங்குகிறது. உலாவி ப்ராக்ஸியை ஒரு ஹோஸ்ட் மற்றும் போர்ட்டுக்கு சுரங்கப்பாதை திறக்கச் சொல்கிறது. Squid அந்தக் கோரிக்கையை நிராகரித்தால், தளத்தின் TLS அமர்வு ஒருபோதும் தொடங்காது.

நிராகரிப்பில் HTTP நிலை மற்றும் பதில் உள்ளடக்கம் இருக்கலாம். உலாவியின் பிழைப் பக்கத்திலிருந்து சுயாதீனமாக அந்தத் தோல்வியடைந்த CONNECT பதிலை curl மூலம் ஆய்வு செய்யலாம். இதற்கு உலாவி வழங்கிய HTML ஐ இலக்கின் வலைப்பக்கமாக வழங்க வேண்டியதில்லை. உலாவி CONNECT பிழையின் உடலை நீக்கிவிட்டு அதன் சொந்த ப்ராக்ஸி பிழை இடைமுகத்தைப் பயன்படுத்தலாம்; சரியான வழங்குதல் கிளையண்டைப் பொறுத்தது.

Squid இன் நிராகரிப்பில் ஏற்கனவே நோக்கமிடப்பட்ட deny_info உடல் இருந்தால், அதன் உரை, பாணித்தாள் அல்லது கோப்பு அனுமதிகளைத் திருத்துவது உலாவி எந்தப் பதில் நிலையைக் கையாள்கிறது என்பதை மாற்றாது. CONNECT நிராகரிக்கப்பட்டதா மற்றும் ஏன் என்பதை உறுதிப்படுத்த நிராகரிப்பு நிலையையும் அணுகல் பதிவையும் கிடைக்கச் செய்யுங்கள். பொதுவான உலாவிப் பக்கம் கொள்கை விவரங்களை மறைக்கலாம், ஆனால் ப்ராக்ஸி விதியைச் சரியாகச் செயல்படுத்துகிறது.

இடைமறிக்கப்பட்ட HTTPS இணைப்புக்குள் தடுப்புப் பக்கத்தை வழங்குவது மற்றொரு கட்டமைப்பு, இதில் TLS முடித்தல், கிளையண்ட் நம்பிக்கை மற்றும் சான்றிதழ் கையாளுதல் அடங்கும். deny_info திருத்துவதன் மூலம் இது இயக்கப்படுவதில்லை, மேலும் தனிப்பயன் வார்ப்புரு தடுக்கப்பட்ட தளத்தைப் போல நடிப்பதற்கு எந்த அதிகாரத்தையும் வழங்காது. தேவைப்பட்டால் மட்டுமே அந்த வடிவமைப்பைத் தேர்ந்தெடுக்கவும்; இல்லையெனில் கிளையண்டில் கிடைக்கும் பிழை அறிக்கை மற்றும் ப்ராக்ஸியின் இயக்கப் பதிவுகளைப் பயன்படுத்தவும்.