HTTPS மற்றும் SSL என்றால் என்ன? பாதுகாப்பான இணையதளங்கள் எப்படி வேலை செய்கின்றன, எளிமையாக

HTTPS என்பது HTTP-யின் பாதுகாப்பான வடிவம்; உலாவிகள் இணையதளங்களுடன் பேசப் பயன்படுத்தும் நெறிமுறை இது. ஒவ்வொரு கோரிக்கையையும் பதிலையும் TLS (Transport Layer Security) மூலம் குறியாக்கம் செய்யப்பட்ட இணைப்பில் சுற்றி அனுப்புகிறது; எனவே பார்வையாளருக்கும் இணையதளத்துக்கும் இடையில் இருப்பவர்களால் அனுப்பப்படுவதைப் படிக்கவோ மாற்றவோ முடியாது. SSL என்பது அதே யோசனையின் பழைய பெயர் — TLS மாற்றிய முதல் நெறிமுறை — அதனால்தான் மக்கள் இன்னும் “SSL certificate” என்கிறார்கள்.

AI மூலம் கட்டும்போது HTTPS ஏன் முக்கியம்

நீங்கள் வெளியிடும் எந்த ஆப்பும் HTTPS மூலம் வழங்கப்பட வேண்டும். இது நல்ல பழக்கம் மட்டுமல்ல:

உலாவிகள் எதிர்பார்க்கின்றன. வெறும் HTTP-ல் உள்ள தளங்களுக்கு “Not secure” என்ற குறி போடப்படும்; இருப்பிட அணுகல், கேமரா, மைக்ரோஃபோன், ஆஃப்லைன் ஆப்களுக்கான service workers போன்ற சில உலாவி அம்சங்கள் பொதுவாக பாதுகாப்பான (HTTPS) பக்கங்களில் மட்டுமே வேலை செய்யும்.
உள்நுழைவுகளும் படிவங்களும். HTTPS இல்லாவிட்டால், கடவுச்சொற்களும் session cookies-களும் படிவத் தரவும் படிக்கக்கூடிய உரையாக பயணிக்கும். அதே கஃபே Wi-Fi-ல் இருக்கும் எவரும் அவற்றைப் பிடிக்க வாய்ப்பிருக்கிறது.
பணம் செலுத்துதலும் மூன்றாம் தரப்புகளும். பணம் செலுத்தும் வழங்குநர்கள், OAuth உள்நுழைவு, பல APIs ஆகியவை HTTPS redirect மற்றும் callback URLs-ஐக் கேட்கின்றன.
நம்பிக்கையும் தேடலும். பார்வையாளர்கள் எச்சரிக்கையைக் கவனிப்பார்கள்; HTTPS-ஐ தரவரிசைக் குறியீடாகக் கருதுவதாக Google கூறியுள்ளது.

நல்ல செய்தி: பெரும்பாலான நவீன ஹோஸ்டிங் தளங்களில் HTTPS தானாக அமைக்கப்படுகிறது. தனிப்பயன் டொமைனிலோ mixed-content எச்சரிக்கையிலோ பிரச்சினை வரும்போது சரிசெய்ய, அதன் பகுதிகளைப் புரிந்துகொள்வதே உங்களுக்கு முக்கியமாகத் தேவை.

அன்றாட உதாரணம்

வெறும் HTTP-ல் தரவு அனுப்புவது ஒரு அஞ்சல் அட்டையில் எழுதி அனுப்புவது போன்றது: அதைக் கையாளும் ஒவ்வொரு தபால் ஊழியரும் படிக்கலாம்; செய்தியையும் மாற்றலாம்.

HTTPS என்பது முத்திரையிட்ட, மாற்றம் கண்டுபிடிக்கக்கூடிய உறையில் அனுப்புவது போன்றது — அதற்கு முன்பு பெறுநரின் அதிகாரப்பூர்வ அடையாள அட்டையையும் சரிபார்த்தல். சான்றிதழ் அந்த அடையாள அட்டை; நம்பகமான அதிகாரி (certificate authority) வழங்கியது; அந்த இணையதளம் உண்மையில் அந்த டொமைனின் கட்டுப்பாட்டில் உள்ளது என்று சரிபார்த்தவர். குறியாக்கம் என்பது முத்திரையிட்ட உறை. அடையாள அட்டை நீங்கள் சரியான முகவரிக்கு எழுதுகிறீர்கள் என்று நிரூபிக்கிறது; உறை உள்ளடக்கத்தை தனிப்பட்டதாக வைத்திருக்கிறது.

HTTPS எளிமையாக எப்படி வேலை செய்கிறது

உலாவி https://shop.example.com ஐத் திறக்கும்போது:

வணக்கம். உலாவி இணைகிறது; தனக்கு ஆதரவான குறியாக்க முறைகளைச் சொல்கிறது.
சான்றிதழ். சர்வர் தனது சான்றிதழை அனுப்புகிறது; அதில் “இந்த key shop.example.com-க்கு சொந்தமானது” என்றும், அது ஒரு certificate authority-ஆல் கையொப்பமிடப்பட்டது என்றும் இருக்கும்.
சரிபார்த்தல். உலாவி ஏற்கெனவே நம்பும் அதிகாரிகளுக்கு எதிராக கையொப்பத்தைச் சரிபார்க்கிறது, சான்றிதழ் காலாவதியாகவில்லை என்றும், டொமைன் பொருந்துகிறது என்றும் பார்க்கிறது.
Keys. உலாவியும் சர்வரும் இந்த அமர்வுக்கான புதிய ரகசிய key-ஐ ஒப்புக்கொள்கின்றன; அதை ஒருபோதும் வெளிப்படையாக அனுப்புவதில்லை.
குறியாக்கம் செய்யப்பட்ட உரையாடல். இப்போது அனைத்து கோரிக்கைகளும் பதில்களும் — பக்கங்கள், படிவத் தரவு, cookies — குறியாக்கம் செய்யப்பட்டுப் பயணிக்கின்றன.

இந்த TLS handshake சில மில்லிவினாடிகளில் நடக்கிறது; தானாகவே நடக்கும். பார்வையாளருக்கு padlock ஐகான் மட்டுமே தெரியும் (சில உலாவிகளில், நடுநிலையான தளத் தகவல் ஐகான்).

HTTPS எதைப் பாதுகாக்கிறது, எதைப் பாதுகாக்காது

பாதுகாக்கிறது	பாதுகாக்காது
உலாவிக்கும் சர்வருக்கும் இடையே பயணிக்கும் தரவு	தரவு உங்கள் சர்வரிலோ தரவுத்தளத்திலோ வந்த பிறகு
பொது Wi-Fi-ல் ஒட்டுக்கேட்பதற்கு எதிராக	தீங்கிழைக்கும் அல்லது மோசடி இணையதளத்துக்கு எதிராக
வழியில் பக்கங்கள் மாற்றப்படுவதற்கு எதிராக	உங்கள் ஆப்பின் பிழைகளுக்கு எதிராக, எ.கா. அனுமதிச் சரிபார்ப்புகள் இல்லாமை
அனுப்பப்படும்போது cookies மற்றும் கடவுச்சொற்கள்	பலவீனமான கடவுச்சொற்களுக்கும் கசிந்த API keys-களுக்கும் எதிராக

HTTPS கோரிக்கைகளின் உள்ளடக்கத்தை குறியாக்கம் செய்கிறது; பக்கப் பாதையும் query string-உம் சேர்த்து. ஆனால் நீங்கள் செல்லும் டொமைன் பெயர் வழியிலுள்ள நெட்வொர்க்குகளுக்கு பொதுவாக இன்னும் தெரியும். URL-களில் தனிப்பட்ட தரவை ஒருபோதும் வைக்காமல் இருப்பதற்கு இதுவும் ஒரு காரணம் — அவை logs-லும் உலாவி வரலாற்றிலும் முடிந்துவிடும்.

நடைமுறை உதாரணம்: தனிப்பயன் டொமைனை இணைத்தல்

நீங்கள் ஒரு முன்பதிவு ஆப்பை வெளியிட்டு அதை book.myyogastudio.com-ல் வைக்க விரும்புகிறீர்கள் என்று வைத்துக்கொள்ளுங்கள்:

book.myyogastudio.com உங்கள் ஹோஸ்ட்டைச் சுட்டிக்காட்டும் ஒரு DNS record-ஐச் சேர்க்கிறீர்கள். பார்க்க டொமைன்களும் DNS-உம் எப்படி வேலை செய்கின்றன.
அந்தப் பெயர் தன் கட்டுப்பாட்டில் உள்ளது என்று ஹோஸ்ட் ஒரு certificate authority-க்கு நிரூபிக்கிறது — பொதுவாக அந்த டொமைனில் ஒரு challenge-க்கு பதில் அளிப்பதன் மூலம் — சான்றிதழைப் பெறுகிறது.
ஹோஸ்ட் அதை நிறுவி, காலாவதியாகும் முன் தானாகவே புதுப்பிக்கிறது. சான்றிதழ்கள் வேண்டுமென்றே குறுகிய ஆயுள் கொண்டவை; அதனால் தானியங்கி புதுப்பித்தல் முக்கியம்.
http://book.myyogastudio.com-க்கு வருபவர்கள் https://-க்கு திருப்பி விடப்படுகின்றனர்.

படி 1 தவறாக இருந்தால் — record வேறு இடத்தைச் சுட்டினாலோ, இடையில் ஒரு proxy இருந்தாலோ — படி 2 தோல்வியடையலாம்; பார்வையாளர்களுக்கு சான்றிதழ் பிழை தெரியும். தனிப்பயன் டொமைனை இணைக்கும்போது மக்கள் சந்திக்கும் மிகவும் பொதுவான HTTPS பிரச்சினை இதுதான்.

முக்கிய சொற்கள்

சொல்	பொருள்
TLS	Transport Layer Security; HTTPS-ன் பின்னுள்ள குறியாக்க நெறிமுறை.
SSL	Secure Sockets Layer; TLS-ன் காலாவதியான முன்னோடி. பெயர் மட்டும் நிலைத்திருக்கிறது.
Certificate	ஒரு டொமைனை ஒரு public key-உடன் இணைக்கும், கையொப்பமிடப்பட்ட கோப்பு.
Certificate authority (CA)	சான்றிதழ்களை வழங்க உலாவிகள் நம்பும் அமைப்பு; எடுத்துக்காட்டு Let's Encrypt.
Domain validation (DV)	டொமைனின் கட்டுப்பாட்டை நிரூபிக்கும் சான்றிதழ் — கிட்டத்தட்ட எல்லா தளங்களும் பயன்படுத்துவது.
Wildcard certificate	`*.example.com` போல, ஒரு நிலை ஆழம் வரையிலான அனைத்து subdomains-களையும் உள்ளடக்கும்.
Mixed content	HTTPS பக்கம் சில வளங்களை வெறும் HTTP மூலம் ஏற்றுவது. உலாவிகள் அதைத் தடுக்கும் அல்லது எச்சரிக்கும்.
HSTS	அன்றிலிருந்து உங்கள் தளத்துக்கு எப்போதும் HTTPS-ஐப் பயன்படுத்தும்படி உலாவிக்குச் சொல்லும் header.
Port 443	HTTPS-க்கான நிலையான port (HTTP port 80-ஐப் பயன்படுத்துகிறது).

பொதுவான தவறான புரிதல்கள்

“Padlock இருந்தால் தளம் நம்பகமானது.” அது இணைப்பு தனிப்பட்டது என்றும் டொமைன் பொருந்துகிறது என்றும்தான் காட்டுகிறது. மோசடிக்காரர்களும் சான்றிதழ்கள் பெறுகிறார்கள்.
“HTTPS பணம் செலுத்தும் பக்கங்களுக்கு மட்டுமே தேவை.” உள்நுழைவு, படிவம் அல்லது cookie உள்ள எந்தப் பக்கத்துக்கும் அது தேவை — கிட்டத்தட்ட ஒவ்வொரு ஆப்பும் அப்படித்தான். எல்லா இடத்திலும் பயன்படுத்துங்கள்.
“சான்றிதழ்கள் விலை உயர்ந்தவை.” இலவச, நம்பகமான சான்றிதழ்கள் வழக்கமானவை; பெரும்பாலான ஹோஸ்ட்கள் அவற்றை உங்களுக்காக நிர்வகிக்கின்றன.
“HTTPS என் ஆப்பைப் பாதுகாப்பாக்குகிறது.” அது இணைப்பைப் பாதுகாக்கிறது. உங்கள் ஆப்புக்கு இன்னும் சர்வர் பக்க அனுமதிச் சரிபார்ப்புகளும், பாதுகாப்பான ரகசிய கையாளுதலும், உள்ளீட்டு சரிபார்ப்பும் தேவை. AI-ல் கட்டிய ஆப்களுக்கான பாதுகாப்புப் பட்டியலைப் பாருங்கள்.
“HTTPS தளங்களை மெதுவாக்கும்.” நவீன TLS மிகக் குறைந்த கூடுதல் சுமையே சேர்க்கிறது; தளங்களை வேகமாக்கும் HTTP/2 போன்ற அம்சங்களுக்கு உலாவிகளில் பொதுவாக HTTPS தேவை.

பொதுவான HTTPS பிரச்சினைகளைச் சரிசெய்தல்

அறிகுறி	சாத்தியமான காரணம்
“Your connection is not private”	சான்றிதழ் இந்த சரியான டொமைனை உள்ளடக்கவில்லை, காலாவதியாகிவிட்டது, அல்லது இன்னும் வழங்கப்படவில்லை
`www.` உடன் வேலை செய்கிறது, வெறும் டொமைனில் இல்லை (அல்லது தலைகீழாக)	ஒரு பெயருக்கு மட்டுமே DNS மற்றும் சான்றிதழ் உள்ளது
சில பக்கங்களில் padlock இல்லை, “Not secure”	Mixed content: `http://` வழியாக ஏற்றப்பட்ட ஒரு படம், script அல்லது font
டொமைனை இணைத்த உடனேயே சான்றிதழ் பிழை	DNS இன்னும் பரவிக்கொண்டிருக்கிறது, அல்லது முன்னால் உள்ள ஒரு proxy சான்றிதழ் சரிபார்ப்பைத் தடுக்கிறது

உங்கள் AI பில்டரிடம் என்ன கேட்க வேண்டும்

“ஒவ்வொரு படமும், script-உம், font-உம் HTTPS வழியாகவோ relative URL மூலமாகவோ ஏற்றப்படுவதை உறுதி செய்யுங்கள் — http:// இணைப்புகள் இல்லை.”
“HTTP போக்குவரத்து அனைத்தையும் HTTPS-க்கு redirect செய்யுங்கள்.”
“Session cookies-களை Secure மற்றும் HttpOnly flags-உடன் அமையுங்கள்.”
“ஒவ்வொரு OAuth, பணம் செலுத்துதல், webhook callback URL-க்கும் https:// பயன்படுத்துங்கள்.”
“என் தனிப்பயன் டொமைன் சான்றிதழ் பிழை காட்டுகிறது — ஹோஸ்ட் எந்த DNS record-ஐ எதிர்பார்க்கிறது?”

Mythex-ல் HTTPS

Mythex-ல் தனிப்பயன் டொமைனை இணைக்கும்போது (இது Pro அம்சம்), Mythex காட்டும் slug.mythex.ai இலக்கை நோக்கிய ஒரு CNAME record-ஐச் சேர்க்கிறீர்கள், Verify கிளிக் செய்கிறீர்கள்; Mythex டொமைனுக்கான HTTPS-ஐ தானாக வழங்குகிறது. மிகவும் பொதுவான இரண்டு தடைகளை ஆவணங்கள் விளக்குகின்றன: உங்கள் DNS Cloudflare-ல் இருந்தால், Mythex சான்றிதழ் வழங்க முடியும்படி record-ஐ proxied-க்குப் பதிலாக “DNS only” (சாம்பல் மேகம்) என்று அமையுங்கள்; HTTPS முழுமையாக அமைவதற்கு முன்பே DNS சரிபார்க்கப்படலாம், எனவே சில நிமிடங்கள் காத்திருந்து மீண்டும் Verify செய்யுங்கள். ஆவணங்களில் custom domains பார்க்கலாம்; எங்கள் வழிகாட்டி: தனிப்பயன் டொமைனை இணைப்பது எப்படி.

கேள்விகள்

HTTP மற்றும் HTTPS இடையே என்ன வித்தியாசம்?

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

SSL மற்றும் TLS ஒன்றா?

TLS என்பது SSL-க்கு நவீன வாரிசு. SSL-ன் அனைத்து பதிப்புகளும் காலாவதியானவை, பாதுகாப்பற்றவை; இன்று பாதுகாப்பான இணையதளங்கள் TLS-ஐப் பயன்படுத்துகின்றன. பழக்கத்தால் மக்கள் இன்னும் “SSL certificate” என்று சொன்னாலும், அந்தச் சான்றிதழ்கள் TLS-உடன்தான் பயன்படுத்தப்படுகின்றன.

Padlock இருந்தால் இணையதளம் பாதுகாப்பானது என்று பொருளா?

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

SSL சான்றிதழுக்கு நான் பணம் செலுத்த வேண்டுமா?

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

என் தளம் “Not Secure” என்று ஏன் காட்டுகிறது?

பொதுவான காரணங்கள்: தளத்தை https:// என்பதற்குப் பதிலாக http:// மூலம் திறப்பது; காலாவதியான அல்லது அந்த சரியான டொமைனை உள்ளடக்காத சான்றிதழ்; அல்லது ஒரு பக்கம் படங்களையோ scripts-களையோ வெறும் http:// மூலம் ஏற்றுவது (mixed content).