VPN மூலம் HTTPS ஐ எப்படி முதல் கோரிக்கையாக மாற்றுவது

ஒரு உலாவியானது http:// என்பதை முதலில் தட்டச்சு செய்து, ஒரு வழிமாற்றுக்குப் பிறகு https:// இல் இறங்கும், ஏற்கனவே ஒரு கோரிக்கையை தெளிவாக அனுப்பியுள்ளது, மேலும் VPN அதை மாற்றாது. சுரங்கப்பாதை கிளையண்டிலிருந்து வெளியேறும் முனைக்கு காலை பாதுகாக்கிறது; இது போக்குவரத்து அடுக்குக்கு மேலே எதையும் குறியாக்கம் செய்யாது, எனவே வெளியேறும் மற்றும் தோற்றத்திற்கு இடையே உள்ள பார்வையாளர் இன்னும் ப்ளைன்டெக்ஸ்ட் ஹாப்பைப் பார்க்கிறார். HTTPS ஐ முதல் கோரிக்கையாக மாற்றுவது கிளையன்ட் பக்க மாற்றமாகும், இது மூன்று பகுதிகளைக் கொண்டது: உண்மையான HTTPS முகவரி, உலாவியின் மேம்படுத்தல் முறை மற்றும் தளத்தின் சொந்தக் கொள்கை. கீழே உள்ள படிகள் நான் பயன்படுத்தும் ஆர்டர் ஆகும், ஒவ்வொன்றும் எடுத்ததா என்பதை உங்களுக்குச் சொல்லும் காசோலையுடன்.

படி 1: முதல் கோரிக்கை உண்மையில் என்ன என்பதை உறுதிப்படுத்தவும்

எதையும் மாற்றும் முன், உலாவி என்ன அனுப்புகிறது என்பதைப் பார்க்கவும். குளிர் தற்காலிக சேமிப்பிலிருந்து ரீலோட் செய்யப்பட்ட பக்கத்துடன் நெட்வொர்க் பேனலைத் திறந்து, முதல் வரிசையைப் படிக்கவும்: திட்டம் http மற்றும் நிலை 301 அல்லது 308 ஆக இருந்தால், அந்த வரிசைக்குப் பிறகு அனைத்தும் இரண்டாவது கோரிக்கையாகும். curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com உலாவிக்கு வெளியே அதே வரிசையை மீண்டும் உருவாக்குகிறது மற்றும் நீங்கள் முடித்த URL ஐ அச்சிடுகிறது.

இரண்டு முடிவுகள் சாத்தியம் மற்றும் அவற்றுக்கு வெவ்வேறு திருத்தங்கள் தேவை. தளம் அதே ஹோஸ்டில் HTTPS சேவையை வழங்கினால், HTTP படிவத்தை வெளியிடுவதை நிறுத்துவதே திருத்தம்: புக்மார்க், விக்கி இணைப்பு, டெஸ்க்டாப் ஷார்ட்கட் மற்றும் மின்னஞ்சல் டெம்ப்ளேட் ஆகியவற்றைப் புதுப்பிக்கவும். தளம் HTTPS சேவையை வழங்கவில்லை என்றால், எந்த உலாவி அமைப்பும் அதை உருவாக்காது, மேலும் நேர்மையான பதில் இலக்கு என்பது பிரச்சனை. விதிவிலக்குடன் இரண்டாவது வழக்கை எழுத வேண்டாம், ஏனெனில் கணக்குப் பக்கத்தில் உள்ள சான்றிதழ் விதிவிலக்கு போக்குவரத்து சிக்கலை நற்சான்றிதழ் சிக்கலாக மாற்றுகிறது. ஒரு அமைப்பைத் தொடுவதற்கு முன் நீங்கள் எந்த நிலையில் இருக்கிறீர்கள் என்பதை எழுதுங்கள்.

படி 2: உலாவியின் HTTPS-மட்டும் பயன்முறையை இயக்கவும்

மேம்படுத்தல் பயன்முறை இரண்டாவது பகுதியாகும், மேலும் முறைகள் ஒன்றுக்கொன்று மாற்ற முடியாது. அதை இயக்கும் முன் உங்களுடையது என்ன செய்கிறது என்பதைச் சரிபார்க்கவும்: அமைதியாக மேம்படுத்தவும், எச்சரிக்கையுடன் மேம்படுத்தவும் அல்லது ஏற்ற மறுக்கவும்.

ஃபயர்பாக்ஸில் கட்டுப்பாடுகள் about:config மற்றும் தனியுரிமை அமைப்புகள் பக்கத்தில் dom.security.https_only_mode உடன் சுவிட்ச் மற்றும் பேட்லாக் மெனுவிலிருந்து நிர்வகிக்கப்படும் ஒவ்வொரு தள விதிவிலக்குகளும் உள்ளன. Chrome மற்றும் Edge இல் எப்போதும் பாதுகாப்பான இணைப்புகளைப் பயன்படுத்து என்ற லேபிளிடப்பட்ட அமைப்புகள், தனியுரிமை மற்றும் பாதுகாப்பு, பாதுகாப்பு ஆகியவற்றின் கீழ் அதே யோசனை உள்ளது. எந்த லேபிளாக இருந்தாலும், போர்ட் 80 இல் மட்டும் பதிலளிக்கும் ஹோஸ்டுக்கு எதிரான நடத்தையைச் சரிபார்க்கவும், ஏனெனில் மேம்படுத்தப்படும் மற்றும் அமைதியாக பின்வாங்கும் பயன்முறையானது நீங்கள் இயக்கியதாக நீங்கள் நினைக்கும் பாதுகாப்பு அல்ல. Firefox HTTPS-மட்டும் ஆவணமாக்கம் அந்த உலாவிக்கான மேம்படுத்தல், எச்சரிக்கை மற்றும் விதிவிலக்கு நடத்தையை விவரிக்கிறது.

படி 3: முகவரிப் பட்டி மட்டுமல்ல, ஆதாரங்களையும் சரிசெய்யவும்

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

VPN இயக்கத்தில் இருப்பதால் கணக்குத் தளத்தில் சான்றிதழ் விதிவிலக்கைச் சேர்க்க வேண்டாம். விதிவிலக்கு காசோலையை செயலிழக்கச் செய்கிறது, இது VPN தடுக்கும் குறுக்கீட்டை சரியாகப் பிடிக்கும்.

மூன்றாம் பகுதி பக்கத்தின் உள்ளே உள்ளது, அதை மக்கள் தவறவிடுகிறார்கள். HTTPS மூலம் ஏற்றப்படும் ஒரு பக்கம் http URL இலிருந்து படங்கள், எழுத்துருக்கள் அல்லது ஸ்கிரிப்ட்களை இன்னும் இழுக்க முடியும், மேலும் உலாவி அவற்றைத் தடுக்கும் அல்லது முழுப் பக்கத்திற்கான பாதுகாப்பு குறிகாட்டியையும் தரமிறக்கும். நெட்வொர்க் பேனலில் தோல்வியுற்ற கோரிக்கைகளை சரிபார்த்து, முகவரிப் பட்டி ஒவ்வொரு கோரிக்கையையும் விவரிக்கிறது என்று கருதாமல், அவற்றின் உரிமையாளரிடம் ஆதாரக் குறிப்புகளைச் சரிசெய்யவும். நீங்கள் இயக்கும் தளத்தில், உலாவியில் மீண்டும் எழுதுவதற்குப் பதிலாக CMS அல்லது டெம்ப்ளேட்டில் சேமிக்கப்பட்ட URLகளை சரிசெய்வதாகும். உங்களால் மூலத்தை மாற்ற முடியாவிட்டால், கலப்பு உள்ளடக்கத்தை அறியப்பட்ட இடைவெளியாகப் பதிவுசெய்யவும், ஏனெனில் எளிய உரை ஆதாரங்களை இழுக்கும் பக்கத்தின் மீது பூட்டு ஒரு தவறான சமிக்ஞையாகும்.

படி 4: HSTS எதைச் சேர்க்கிறது, எதைச் சேர்க்காது

HSTS என்பது உலாவி விருப்பத்திற்குப் பதிலாக ஒரு தளக் கொள்கையாகும், மேலும் புதிய சுயவிவரத்தில் http:// என தட்டச்சு செய்ததில் பிழைத்திருக்கும் ஒரே வழிமுறை இதுவாகும். ஒரு உலாவி ஒரு ஹோஸ்டுக்கான Strict-Transport-Security என்ற தலைப்பைப் பார்த்தவுடன், அது https க்கு அனுப்பும் முன் கோரிக்கைகளை மீண்டும் எழுதும், இது உங்களுக்குத் தேவையான சொத்து ஆகும். உலாவி இதுவரை பார்வையிடாத ஹோஸ்டுக்கு இது எதுவும் செய்யாது, அதே பயன்பாட்டிற்கு சேவை செய்யும் வேறு ஹோஸ்ட்பெயருக்கு எதுவும் செய்யாது.

curl -sSI https://example.com | grep -i strict-transport-security மூலம் அசல் என்ன அனுப்புகிறது என்பதைச் சரிபார்க்கவும். விடுபட்ட தலைப்பு என்பது சேவையக மாற்றம் மற்றும் கிளையன்ட் நிறுவக்கூடிய ஒன்று அல்ல. அது இருந்தால், max-age மற்றும் includeSubDomains அமைக்கப்பட்டுள்ளதா என்பதைப் படிக்கவும், ஏனெனில் வருகைகளுக்கு இடையே ஒரு குறுகிய அதிகபட்ச வயது காலாவதியாகும் மற்றும் விடுபட்ட சப்டொமைன்கள் ஒவ்வொரு துணை டொமைனையும் பாதுகாப்பற்றதாக விட்டுவிடும். RFC 6797, ஒரு பயனர் முகவர் கொள்கையை எவ்வாறு பயன்படுத்துகிறார் மற்றும் அது எதைப் புறக்கணிக்கக்கூடும் என்பதை வரையறுக்கிறது. ப்ரீலோட் என்பது ஒரு தனி அர்ப்பணிப்பு, எனவே பட்டியலில் உள்ள டொமைன் இருப்பதாக யாருக்கும் உறுதியளிக்கும் முன் hstspreload.org API மூலம் நிலையைச் சரிபார்க்கவும்.

சரிபார்ப்பு மற்றும் திரும்பப்பெறுதல்

கிளையன்ட் அமைப்புகளுக்கு ரோல்பேக் மலிவானது மற்றும் HSTSக்கு விலை அதிகம். HTTPS-மட்டும் பயன்முறையை முடக்குவது முந்தைய நடத்தையை உடனடியாக மீட்டெடுக்கிறது; நீண்ட அதிகபட்ச வயது இல்லை, ஏற்கனவே அதைப் பெற்ற பார்வையாளர்கள் அது காலாவதியாகும் வரை மேம்படுத்திக் கொண்டே இருப்பார்கள்.

எனவே அது முடிந்தது என்று அழைப்பதற்கு முன், வரிசையைச் சரிபார்க்கவும். குளிர் தற்காலிக சேமிப்பில் இருந்து மீண்டும் ஏற்றவும் மற்றும் நெட்வொர்க் பேனலில் உள்ள முதல் கோரிக்கையான https என்பதை உறுதிப்படுத்தவும். பின் ஒரு துணை டொமைனைச் சரிபார்க்கவும், ஏனெனில் இதில் அடங்கும் சப்டொமைன்களில் இந்தக் கொள்கைகள் பொதுவாகக் கருதப்பட்டதை விட குறுகியதாக இருக்கும். பின்னர், மூன்றாம் தரப்பு சொத்துக்களை இழுக்கும் ஒரு பக்கத்தைச் சரிபார்க்கவும், ஏனெனில் கலவையான உள்ளடக்கம் மற்ற எல்லா பிழைத்திருத்தத்திலும் பிழைத்திருக்கும் தோல்வியாகும்.

அதற்குப் பிறகும் முதல் கோரிக்கை http ஆக இருந்தால், கிளையன்ட் மாறி இருக்காது: மக்கள் கிளிக் செய்யும் இணைப்பு. ஹோஸ்ட்பெயரின் http படிவத்திற்காக நீங்கள் கட்டுப்படுத்தும் இடங்களைத் தேடி, அவற்றைப் புதுப்பித்து, அதே குளிர்-கேச் ரீலோட் மூலம் மீண்டும் சோதிக்கவும். VPN கேள்வியை முழுவதும் தனித்தனியாக வைத்திருங்கள், ஏனெனில் கோரிக்கையைக் காணக்கூடிய சுரங்கப்பாதை மாறுகிறது மேலும் கோரிக்கை என்க்ரிப்ட் செய்யப்பட்டதா என்பதை ஒருபோதும் மாற்றாது. டிக்கெட்டில் வைக்க வேண்டிய வரி என்னவென்றால், முதல் கோரிக்கையே முக்கியமானது, மேலும் திருப்பி அனுப்புவது ஏற்கனவே அனுப்பப்பட்ட கோரிக்கைக்கான ரசீது மட்டுமே.