eMudhra CA சாவிப் பாதுகாப்பு மீறல், டொமைன் பாதுகாப்புக்கு HTTPS மட்டும் போதாது என்பதைக் காட்டுகிறது

போலி அடையாளத்துடன் செயல்படுபவருடனான இணைப்பையும் ஒரு வலைத்தளம் குறியாக்கம் செய்ய முடியும். மறுமுனையை யார் கட்டுப்படுத்துகிறார் என்பதை குறியாக்கம் மட்டும் உறுதிப்படுத்தாது.

eMudhra சம்பவம், டொமைன் உரிமையாளர்கள், நிறுவனர்கள், Web3 அணிகள் இந்த வேறுபாட்டை உடனடியாகப் புரிந்துகொள்ள வேண்டிய தேவையை ஏற்படுத்தியுள்ளது. 2026 அக்டோபர் 20 அன்று, இடைநிலை சான்றிதழ் ஆணையச் சாவிகளின் பாதுகாப்பு மீறப்பட்டதைத் தொடர்ந்து எடுத்த அவசர நடவடிக்கைகளை Google மற்றும் Mozilla வெளியிட்டன. பலவீனமான சாவி உருவாக்கம், போலி வலைத்தளச் சான்றிதழ்களை உருவாக்க வழி வகுத்தது. அந்தச் சாவிகளைத் தொடர்ந்து நம்பிய கிளையன்ட்கள் போலி அடையாள அபாயத்தை எதிர்கொண்டன. கோளாறையும் தடை நடவடிக்கையையும் Google விளக்குகிறது.

2026 அக்டோபர் 22 அன்று நிலவரத்தைச் சரிபார்த்தோம். விசாரணை தொடர்கிறது. சாவிகளின் பாதுகாப்பு மீறப்பட்டது உறுதியானதால் மட்டும், தாக்குதலாளர்கள் வாடிக்கையாளர் தரவுப் போக்குவரத்தை இடைமறித்தார்கள் என்று முடிவுசெய்ய முடியாது.

தனித்தனி வலைத்தளங்களுக்கும் மேலுள்ள கையொப்ப அதிகாரத்தின் அபாயத்தைச் சம்பவம் வெளிப்படுத்தியது

சான்றிதழ் ஆணையம், அல்லது CA, அடையாளங்களைப் பொது விசைகளுடன் இணைக்கும் டிஜிட்டல் சான்றிதழ்களை வழங்குகிறது. HTTPS சான்றிதழ், சேவையகம் எந்த டொமைன் பெயர்களுக்காகத் தனது அடையாளத்தை நிரூபிக்க முடியும் என்பதைக் குறிப்பிடுகிறது. சான்றிதழில் கையொப்பமிடும் முன், CA பொருந்தும் அடையாளத் தேவைகளைச் சரிபார்க்கிறது. உலாவி சான்றிதழ் சங்கிலியையும் தொடர்புடைய தனிப்பட்ட விசையை வைத்திருப்பதற்கான சேவையகத்தின் சான்றையும் சரிபார்க்கிறது. சான்றிதழ் மாதிரியை RFC 5280 விவரிக்கிறது.

மூல CA ஒரு நம்பிக்கை ஆதாரத்தை வழங்குகிறது. இடைநிலை CA, மூல CA-க்குக் கீழே ஒப்படைத்த கையொப்ப அதிகாரத்தைக் கொண்டுள்ளது. வலைத்தளச் சான்றிதழ்கள் பொதுவாக இடைநிலை CA-க்குக் கீழே இருக்கும். வலைத்தளச் சாவியின் பாதுகாப்பு மீறப்பட்டால், அந்தச் சான்றிதழின் அடையாளங்கள் ஆபத்துக்குள்ளாகும். இடைநிலைச் சாவியின் பாதுகாப்பு மீறப்பட்டால், ஒன்றுக்கொன்று தொடர்பில்லாத பல டொமைன்கள் ஆபத்துக்குள்ளாகலாம். சான்றிதழ் கட்டுப்பாடுகளும் கிளையன்ட் சரிபார்ப்புகளும் அபாயத்தின் அளவை நிர்ணயிக்கும்.

Mozilla-வின் சம்பவப் பதிவு எட்டு பாதிக்கப்பட்ட இடைநிலைச் சான்றிதழ்களைக் குறிப்பிடுகிறது: TLS-க்கு ஆறு, நிரல் கையொப்பத்திற்கு இரண்டு. Mozilla பலவீனமான தனிப்பட்ட விசைகளைத் தனியாக மீட்டெடுத்தது. அக்டோபர் 18 அன்று eMudhra சான்றிதழ்களைத் திரும்பப்பெற்றதாகக் குறித்தது. இந்த உண்மைகள் சாவி உருவாக்கக் கோளாறைக் காட்டுகின்றன. ஒவ்வொரு வாடிக்கையாளரின் தனிப்பட்ட விசையையும் யாரோ திருடிவிட்டார்கள் என்பதற்கான சான்றுகள் அல்ல.

அக்டோபர் 21 அறிக்கையில், 2025 ஏப்ரல் 30 சாவி உருவாக்கச் சடங்கின்போது நடந்த பொதியிடல்/பொதியவிழ்த்தல் படியே பலவீனமான சாவிகளுக்குக் காரணம் என்று eMudhra கூறியது. பாதிக்கப்பட்ட இடைநிலை ஆணையங்கள் இறுதி அமைப்புகளுக்கான சான்றிதழ்கள் எதையும் வழங்கவில்லை என்று eMudhra கூறியது. வெளியீட்டுக்கு முன் தவறாகப் பயன்படுத்தியதற்கான சான்று கிடைக்கவில்லை என்றும் நிறுவனம் தெரிவித்தது. துல்லியமான மூலக்காரண விசாரணை இன்னும் முடிவடையவில்லை என்றும் நிறுவனம் கூறியது. இந்த அறிக்கைகள் eMudhra-வின் கண்டறிதல்களை விவரிக்கின்றன. முந்தைய அனைத்து தரவுப் போக்குவரத்தைப் பற்றிய சுயாதீனமான உத்தரவாதத்தை இந்த அறிக்கைகள் வழங்கவில்லை.

உலாவிகளின் பாதுகாப்பு நடவடிக்கைகள் நடைமுறை அபாயத்தை மாற்றின

அக்டோபர் 17 அன்று CRLSet புதுப்பிப்பு வழியாக Chrome பாதிக்கப்பட்ட சாவிகளைத் தடுத்ததாக Google கூறுகிறது. தடை அமலுக்கு வரும் முன், பாதிக்கப்பட்ட ஆறு TLS இடைநிலை ஆணையங்களின் கீழான TLS சான்றிதழ்கள் எதுவும் CT-இல் தோன்றவில்லை என்றும் Google கூறுகிறது. எனவே, தொடர்புடைய CT தேவையை அமல்படுத்திய கிளையன்ட்களில் அந்த இடைநிலை ஆணையங்களின் போலிச் சான்றிதழ்கள் வேலை செய்திருக்க முடியாது. Google-இன் அறிவுரை Chrome-ஐயும் அந்தக் கிளையன்ட்களில் சேர்த்துள்ளது.

Mozilla அதே மாலை OneCRL தடையை விநியோகித்தது. OneCRL பாதுகாப்பைப் பெறாமல் போகக்கூடிய கட்டமைப்புகளுக்கு Firefox புதுப்பிப்புகளையும் Mozilla வெளியிட்டது. ஒரு உலாவிப் புதுப்பிப்பு, அதே சாதனத்திலுள்ள ஒவ்வொரு செயலிக்கும் அதே பாதுகாப்பு இருப்பதை நிரூபிக்காது. வெவ்வேறு செயலிகள் வெவ்வேறு சான்றிதழ் சரிபார்ப்பிகளைப் பயன்படுத்தலாம் என்று Cloudflare குறிப்பாக எச்சரிக்கிறது.

Google-இன் அக்டோபர் 20 அறிவுரை, Chrome Root Store-ஐப் பயன்படுத்தும் கிளையன்ட்களிலிருந்து emSign ECC Root CA - G3-ஐ 2026 அக்டோபர் 27, PDT அன்று அகற்றத் திட்டமிட்டுள்ளது. பாதிக்கப்பட்ட வலைத்தள இயக்குநர்கள் மற்றொரு நம்பகமான படிநிலைக்குச் சான்றிதழ்களை மாற்ற வேண்டும் என்று Google அறிவுறுத்துகிறது. உடனடி பாதுகாப்புத் தடைக்கும், பின்னர் மூல CA மீதான நம்பிக்கையை நீக்குவதால் ஏற்படும் சேவைத் தடைக்கும் இயக்குநர்கள் வேறுபாடு காண வேண்டும்.

இடைமறிக்கும் தாக்குதலாளருக்குத் தரவுப் போக்குவரத்துக்கான அணுகலும் ஏற்றுக்கொள்ளப்பட்ட அடையாளமும் தேவை

இடைமறிப்பு தாக்குதல், அல்லது MITM, தகவல் பரிமாறும் தரப்புகளுக்கு இடையே தாக்குதலாளரை அமர்த்துகிறது. பின்வருவது கற்பனையான தாக்குதல். eMudhra சம்பவத்தில் கண்டறிந்த தவறான பயன்பாடு அல்ல:

1. தீங்கிழைக்கும் DNS பதில்கள் அல்லது வேறொரு பிணைய இடைமறிப்பு முறை மூலம் தாக்குதலாளர் வருகையாளரைத் திசைதிருப்புகிறார்.
2. செல்ல வேண்டிய டொமைனுக்கான போலிச் சான்றிதழைத் தாக்குதலாளர் வழங்குகிறார்.
3. பாதுகாப்பற்ற கிளையன்ட் சான்றிதழை ஏற்றுக்கொண்டு தாக்குதலாளருடன் TLS இணைப்பை ஏற்படுத்துகிறது.
4. செயலித் தரவைப் படித்துக்கொண்டோ மாற்றிக்கொண்டோ, உண்மையான சேவைக்குத் தாக்குதலாளர் தரவுப் போக்குவரத்தை அனுப்ப முடியும்.

CA சாவி கைவசம் இருப்பதால் மட்டும் தரவுப் போக்குவரத்து தானாகத் திசைதிரும்பாது. முன்பு பதிவு செய்த அனைத்து அமர்வுகளின் குறியாக்கத்தையும் சான்றிதழ் மட்டும் நீக்காது. குறிப்பிட்ட முன்நிபந்தனைகளின்படி, TLS 1.3-இன் முன்னோக்கிய இரகசியத்தன்மை, நீண்டகால அடையாளச் சரிபார்ப்புச் சாவிகளின் பாதுகாப்பு பின்னர் மீறப்பட்டாலும் பழைய அமர்வுகளைப் பாதுகாக்கிறது. இந்த வேறுபாட்டை RFC 8446 விளக்குகிறது.

எங்கள் Fox-IT சம்பவ ஆய்வு, இதேபோன்ற முடிவுக்குச் செல்லும் வேறொரு வழியை ஆராய்கிறது: பதிவாளரின் அமைப்பில் ஊடுருவியதால் மோசடியாகச் சான்றிதழ் பெற முடிந்தது. எங்கள் MyEtherWallet சம்பவ ஆய்வு வழித்தடம் மற்றும் DNS கையாளுதலை ஆராய்கிறது. தரவுப் போக்குவரத்தின் திசையையும், இணைப்பின் மறுமுனை அடையாளச் சரிபார்ப்பையும் டொமைன் பாதுகாப்பு கையாள வேண்டும்.

CA சாவிகளைச் சரிசெய்யாமல் DNS பதில்களின் நம்பகத்தன்மையை DNSSEC சரிபார்க்கிறது

DNSSEC (டொமைன் பெயர் அமைப்பு பாதுகாப்பு நீட்டிப்புகள்), DNS தரவில் டிஜிட்டல் கையொப்பங்களைச் சேர்க்கிறது. சரிபார்க்கும் பெயர் தீர்வி நம்பிக்கைச் சங்கிலி வழியாகக் கையொப்பங்களைச் சரிபார்க்கிறது. சரியாகக் கையொப்பமிட்ட மண்டலமும் முழுமையான சரிபார்ப்புச் சங்கிலியும் இருந்தால், கண்டறியப்படாமல் போலி முகவரிப் பதிலைத் தாக்குதலாளர் மாற்றி வைக்க முடியாது. பாதுகாப்புகளையும் வரம்புகளையும் RFC 4033 வரையறுக்கிறது.

கிளையன்ட்கள் உள்ளூரிலேயே சரிபார்க்க வேண்டும். அல்லது, சரிபார்க்கும் பெயர் தீர்வியையும் அந்தத் தீர்விக்கான அடையாளம் சரிபார்த்த இணைப்பையும் கிளையன்ட்கள் நம்ப வேண்டும். இந்த இறுதிக்கட்டத் தேவையை RFC 4033 விவாதிக்கிறது.

இந்த நிபந்தனைகளுடன், கற்பனையான தாக்குதலிலுள்ள போலி DNS படியை DNSSEC தடுக்க முடியும். DNSSEC இடைநிலை CA-ஐத் திரும்பப்பெறாது, HTTPS சான்றிதழைச் சரிபார்க்காது, வலைத் தரவுப் போக்குவரத்தைக் குறியாக்கம் செய்யாது. வேறொரு வழியில் தரவுப் போக்குவரத்தை இடைமறிக்கும் தாக்குதலாளர், பாதிக்கப்படக்கூடிய கிளையன்டிடம் இன்னும் போலிச் சான்றிதழை வழங்க முடியும்.

கையொப்பமிடுதல் மட்டும் பதிவாளர் கணக்கையோ அதிகாரப்பூர்வ DNS கட்டுப்பாட்டுப் பலகையையோ பாதுகாக்காது. அங்கீகரிக்கப்பட்ட DNS மாற்றங்களைக் கட்டுப்படுத்தும் தாக்குதலாளர் தீங்கு தரும் பதிவுகளை வெளியிட முடியும். வழங்குநர் அந்தப் பதிவுகளில் கையொப்பமிடலாம். DNSSEC சரிபார்ப்புடன், கணக்குப் பாதுகாப்பு, மாற்றக் கண்காணிப்பு, தாய் மண்டலத்தில் சரியான DS பதிவு ஆகியவையும் இயக்குநர்களுக்குத் தேவை.

கிளையன்ட்கள் தொடர்பை அமல்படுத்தும்போது சேவைச் சாவியை கையொப்பமிட்ட DNS உடன் DANE இணைக்க முடியும்

DANE, TLSA பதிவுகள் வழியாக DNSSEC-ஐ TLS அடையாளச் சரிபார்ப்புடன் இணைக்கிறது. டொமைன் இயக்குநர் எதிர்பார்க்கும் சான்றிதழ், சாவி அல்லது நம்பிக்கை ஆதாரத்தைக் கையொப்பமிட்ட DNS-இல் வெளியிடுகிறார். ஆதரிக்கும் கிளையன்ட் DNSSEC-ஐச் சரிபார்த்து TLSA தொடர்பை அமல்படுத்துகிறது. அந்தத் தொடர்பை RFC 6698 குறிப்பிடுகிறது.

எடுத்துக்காட்டாக, DANE-EE பயன்பாடு சேவையை நேரடியாக அதன் பொது விசையுடன் இணைக்க முடியும். தொடர்பில்லாத CA சாவியால் உருவாக்கிய போலிச் சான்றிதழ் அந்த இணைப்புச் சரிபார்ப்பில் தோல்வியடையும். இந்தப் பலனுக்கு பாதுகாப்பான DNSSEC சரிபார்ப்பு, சரியான TLSA தரவு, கிளையன்டின் உண்மையான அமலாக்கம் ஆகியவை தேவை. சாவி மாற்றத்துடன் TLSA புதுப்பிப்புகளையும் ஒருங்கிணைக்க வேண்டும். செயல்பாட்டு வழிகாட்டுதலை RFC 7671 வழங்குகிறது.

TLSA பதிவுகளை வெளியிடுவதால் சாதாரண உலாவி வருகையாளர்களுக்குத் தானாகப் பாதுகாப்பு கிடைக்காது. Firefox-இன் DANE செயலாக்கக் கோரிக்கை இன்னும் நிராகரிக்கப்பட்ட நிலையிலேயே உள்ளது. குறிப்பிட்ட கிளையன்டில் ஆதரவு இருப்பதை இயக்குநர்கள் உறுதிசெய்ய வேண்டும். SMTP பரிமாற்றப் பாதுகாப்பில் DANE-க்கு ஒரு தரப்படுத்தப்பட்ட பயன்பாடு உள்ளது.

CAA மற்றும் CT சான்றிதழ்களுக்கு வெவ்வேறு கட்டுப்பாடுகளை வழங்குகின்றன

CAA, அனுமதிக்கப்பட்ட வழங்குநர்களை DNS-இல் வெளியிடுகிறது. வழங்கல் அனுமதியையும் கிளையன்ட் சான்றிதழ் சரிபார்ப்பையும் RFC 8659 வேறுபடுத்துகிறது. திருடிய அல்லது மீட்டெடுக்கக்கூடிய கையொப்பச் சாவி, போலிச் சான்றிதழ் உருவாக்குபவர் CAA சோதனைகளைப் புறக்கணிக்க வழி தருகிறது.

சான்றிதழ் வெளிப்படைத்தன்மை, அல்லது CT, சான்றிதழ் வழங்கலைப் பொதுத் தணிக்கைக்கு உட்படுத்துகிறது. கண்காணிப்பு எதிர்பாராத சான்றிதழ்களைக் கண்டறிய முடியும். தேவையான பதிவேட்டுச் சான்று இல்லாத சான்றிதழ்களைக் கிளையன்ட் அமலாக்கம் நிராகரிக்க முடியும். பதிவேட்டு முறையை RFC 9162 விவரிக்கிறது. CA சம்பவத்தின்போது அமலாக்கம் ஏன் முக்கியம் என்பதை மேலே உள்ள Google கண்டறிதல்கள் காட்டுகின்றன.

டொமைன் இயக்குநர்கள் கிளையன்ட் நம்பிக்கையையும் சான்றிதழ் சார்புகளையும் இப்போதே சரிபார்க்க வேண்டும்

• உலாவி, இயக்க முறைமை, இயக்கச் சூழல், CA தொகுப்புகளுக்கான தற்போதைய பாதுகாப்புப் புதுப்பிப்புகளை நிறுவுங்கள்.
• வலைத்தளங்கள், API-கள், கைப்பேசிச் செயலிகள், கொள்கலன்கள், TLS ஆய்வு நுழைவாயில்கள் ஆகியவற்றின் சான்றிதழ் சங்கிலிகளைப் பட்டியலிடுங்கள்.
• பாதிக்கப்பட்ட இடைநிலை ஆணையங்கள், மூல CA அகற்றல் குறித்த வழங்குநர் வழிகாட்டுதலைப் பின்பற்றுங்கள். மாற்றுச் சான்றிதழ் பாதைகளையும் கவனியுங்கள்.
• பொருந்தும் கிளையன்ட் காலக்கெடுவுக்கு முன் நம்பிக்கை நீக்கிய படிநிலையுடன் சங்கிலியாக இணையும் சான்றிதழ்களை மாற்றுங்கள்.
• சரிசெய்த பிறகு ஒவ்வொரு செயலியின் உண்மையான TLS சரிபார்ப்பியையும் சோதியுங்கள்.
• சான்றிதழ் சரிபார்ப்பை இயக்கியபடி வைத்திருங்கள். சான்றிதழ் பிழைகள் வந்தால் தொடராதீர்கள்.
• சரியான DS ஒப்படைப்புடன் DNSSEC-ஐ இயக்குங்கள். சரிபார்க்கும் பெயர் தீர்வைப் பயன்படுத்துங்கள்.
• CAA மூலம் அனுமதிக்கப்பட்ட வழங்குநர்களைக் கட்டுப்படுத்துங்கள், CT-ஐக் கண்காணியுங்கள், பதிவாளர் மற்றும் DNS கணக்குகளைப் பாதுகாத்திடுங்கள்.

VPN தரவுப் போக்குவரத்துப் பாதையை மாற்ற முடியும். சான்றிதழ் நம்பிக்கை குறித்த கிளையன்டின் முடிவுகளை VPN சரிசெய்யாது. HSTS, HTTPS-ஐக் கட்டாயப்படுத்துகிறது. ஆனால் ஏற்றுக்கொள்ளப்பட்ட போலி HTTPS அடையாளம் அந்தப் பாதுகாப்பையும் மீறுகிறது. HSTS பாதுகாப்பு வரம்புகளை RFC 6797 விவரிக்கிறது.

Namefi வாசகர்களுக்கு, டொமைன் உரிமை, DNS நிர்வாகம், TLS அடையாளச் சரிபார்ப்பு, பணப்பை அங்கீகாரம் ஆகியவற்றுக்குத் தனித்தனிக் கட்டுப்பாடுகள் தேவை. டொமைனை டோக்கனாக்குவது உலாவியின் CA நம்பிக்கையைத் தானாக மாற்றாது, DNSSEC-ஐயும் இயக்காது. எங்கள் டோக்கனாக்கிய டொமைன்களுக்கான DNS வழிகாட்டி செயல்பாட்டுத் தொடர்பை விளக்குகிறது. இடைமுகத்தை வழங்கும் டொமைனை Web3 அணி ஏன் பாதுகாக்க வேண்டும் என்பதை எங்கள் Curve Finance சம்பவ ஆய்வு காட்டுகிறது.

இந்த முதன்மை ஆதாரங்கள் சம்பவத்தையும் பாதுகாப்பு முறைகளையும் ஆவணப்படுத்துகின்றன

கீழே உள்ள அனைத்து ஆதாரங்களையும் 2026 அக்டோபர் 22 அன்று பெற்றோம். விசாரணை தொடரும்போது சம்பவ அறிக்கைகள் மாறலாம்.

• Google: Chrome மற்றும் Android நடவடிக்கை, 2026 அக்டோபர் 20. சீரற்றத்தன்மை, CT, தடை, மூல CA அகற்றல் பற்றிய பகுதிகள்.
• Mozilla: Firefox நடவடிக்கை, 2026 அக்டோபர் 20. OneCRL விநியோகம் மற்றும் கூடுதல் புதுப்பிப்புகள்.
• Mozilla பிழைப் பதிவு 2083449, விளக்கம் மற்றும் கருத்து 1. சான்றிதழ்களின் வரம்பு, சுயாதீன சாவி மீட்டெடுப்பு, திரும்பப்பெறல்.
• eMudhra சம்பவ அறிக்கை, புதுப்பிப்புகள் 2–4. நிறுவனத்தின் கண்டறிதல்கள் மற்றும் வாடிக்கையாளர் மாற்று வழிகள்.
• Cloudflare சம்பவ வழிகாட்டுதல், செயலிக்கேற்ற சரிபார்ப்பு வழிகாட்டுதல்.
• RFC 5280, சான்றிதழ் மற்றும் நம்பிக்கைப் பாதை மாதிரி.
• RFC 8446, TLS 1.3 முன்னோக்கிய இரகசியத்தன்மை.
• RFC 4033, DNSSEC சேவைகள், வரம்புகள், சரிபார்ப்பு.
• RFC 6698 மற்றும் RFC 7671, DANE தொடர்புகள் மற்றும் செயல்பாடுகள்.
• Mozilla பிழைப் பதிவு 1994924, Firefox DANE செயலாக்க நிலை.
• RFC 7672, SMTP-க்கான DANE.
• RFC 8659, CAA அனுமதிக்கும் சரிபார்ப்புக்கும் உள்ள வேறுபாடு.
• RFC 9162, CT பதிவு மற்றும் கண்காணிப்பு.
• RFC 6797, HSTS பாதுகாப்புக் கருத்துகள்.