OpenSSL 4.1.0 கொண்டுவரும் DTLS 1.3 மற்றும் GREASE: மேம்படுத்துவதற்கு முன் எவற்றைச் சோதிக்க வேண்டும்

புதிய OpenSSL வெளியீடு என்பது எப்போதுமே ஒரு சாதாரண லைப்ரரி மாற்றாகவே தோன்றும். ஆனால் OpenSSL 4.1.0-க்கு அதைவிட கூடுதல் கவனம் தேவைப்படுகிறது, ஏனெனில் இதன் முக்கிய அம்சமான DTLS 1.3, நெட்வொர்க் சரியாக இயங்காதபோது மட்டுமே வெளிப்படும் நான்கு அறியப்பட்ட சிக்கல்களுடன் வருகிறது.

நவம்பர் 2, 2026 நிலவரப்படி, இணையத்தின் பெரும்பான்மையான மறைகுறியாக்கப்பட்ட இணைப்புகளைப் பாதுகாக்கும் டூல்கிட்டின் புதிய அம்சம் நிறைந்த வெளியீடாக OpenSSL 4.1.0 உள்ளது. இது DTLS 1.3, GREASE, வேகமான post-quantum மற்றும் AES code path-கள் மற்றும் பல build மாற்றங்களைச் சேர்க்கிறது. OpenSSL-ஐப் பயன்படுத்தி மென்பொருளை வழங்கும் எந்தவொரு குழுவிற்கும், இப்போது எழும் கேள்விகள் நடைமுறை சார்ந்தவை: இந்த புதிய வெளியீட்டைப் பின்பற்றுவது பயனுள்ளதா, மற்றும் ஆவணப்படுத்தப்பட்ட அதன் வரம்புகளுடன் பயன்பாடுகள் சரியாகச் செயல்படுமா?

எளிய வார்த்தைகளில் சொல்வதானால் DTLS 1.3 என்றால் என்ன

மறைகுறியாக்கப்பட்ட பெரும்பாலான வலைப் போக்குவரத்து TLS-ஐப் பயன்படுத்துகிறது, இது TCP-இன் மேல் இயங்குகிறது. TCP என்பது நம்பகமான ஒரு போக்குவரத்து அடுக்கு: இது தொலைந்துபோன பாக்கெட்டுகளை மீண்டும் அனுப்பி, அவற்றை வரிசைப்படி வழங்குகிறது.

DTLS (Datagram Transport Layer Security) என்பது இதுபோன்ற எந்த உத்தரவாதத்தையும் வழங்காத UDP-இன் மேல் அதே பாதுகாப்புப் பணியைச் செய்கிறது. இதில் பாக்கெட்டுகள் தாமதமாக வரலாம், வரிசை மாறி வரலாம் அல்லது வராமலே போகலாம். வீடியோ அழைப்புகள், VPN-கள், கேமிங் போக்குவரத்து மற்றும் பல IoT சாதனங்கள் விரைவானவை என்பதால் UDP-ஐ நம்பியுள்ளன; DTLS தான் அவற்றை தனிப்பட்டதாகவும் பாதுகாப்பாகவும் வைத்திருக்கிறது.

DTLS 1.3 ஆனது RFC 9147-இல் வரையறுக்கப்பட்டு, TLS 1.3-இன் அடிப்படையில் கட்டமைக்கப்பட்டுள்ளது. இது UDP-இன் டேட்டாகிராம் தன்மையைத் தக்கவைத்துக்கொண்டே ஒட்டுக் கேட்பது, தரவை மாற்றுவது மற்றும் போலிச் செய்திகளுக்கு எதிராகப் பாதுகாக்கிறது. குறிப்பாக வரிசைப்படுத்துதல் மற்றும் ரீப்ளே பாதுகாப்பு ஆகியவற்றில், இதன் உத்தரவாதங்கள் TLS-லிருந்து எங்கு வேறுபடுகின்றன என்பதை விவரக்குறிப்பு கவனமாகக் குறிப்பிடுகிறது. எனவே உங்கள் பயன்பாடு சில விஷயங்களைத் தானே கையாள வேண்டியிருக்கும்.

முக்கியமான பாடம்: சிக்கலற்ற ஒரு சோதனை ஆய்வக நெட்வொர்க்கில் சரியாக வேலை செய்யும் ஒரு DTLS இணைப்பு எதையும் நிரூபித்துவிடாது. பாக்கெட்டுகள் தொலைவது, பதில்கள் தாமதமாவது, மறுபரிமாற்றங்கள் (retransmissions) மற்றும் எதிர்முனையில் வேறு ஒரு செயலாக்கத்துடன் தொடர்புகொள்வது ஆகியவையே கடினமான சோதனைச் சூழல்களாகும்.

அறியப்பட்ட நான்கு DTLS சிக்கல்கள்

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

Key update-கள் session-ticket மறுபரிமாற்றத்தை நிறுத்தக்கூடும் (சிக்கல் #32878)

DTLS 1.3 handshake-க்குப் பிறகு, சேவையகம் session ticket-களை அனுப்பக்கூடும். இவை கிளையன்ட் பின்னர் விரைவாக மீண்டும் இணைக்க உதவுகின்றன. ஒரு key update நடக்கும்போது, எதிர்முனை சாதனம் (peer) அந்த டிக்கெட்டுகளை இன்னும் உறுதிப்படுத்தவில்லை (acknowledge) என்றால், OpenSSL அவற்றை அழித்து அவற்றின் retransmission timer-ஐ நிறுத்திவிடக்கூடும்.

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

நிரந்தர receive தோல்விகள் தற்காலிகமானவை போலத் தோன்றக்கூடும் (சிக்கல் #33277)

OpenSSL-இன் DTLS listener மூலம் உருவாக்கப்படும் இணைப்புகளில், ஒரு நிரந்தர receive தோல்வியானது இவ்வாறு தெரிவிக்கப்படலாம்: SSL_ERROR_WANT_READ. இந்தக் குறியீடு பொதுவாக "இன்னும் எதுவும் வரவில்லை, மீண்டும் முயற்சிக்கவும்" என்பதையே குறிக்கும். இதை நம்பும் ஒரு பயன்பாடு, செயலிழந்த இணைப்பில் காலவரையின்றி காத்திருக்கக்கூடும். Polling மற்றும் பிந்தைய accept அழைப்புகளும் இந்தத் தோல்வியடைந்த நிலையை மறைத்துவிடக்கூடும்.

இந்த reproducer-இல் DTLS 1.2-உம் அடங்கும்; எனவே இது DTLS 1.3 பயனர்களுக்கு மட்டுமல்லாமல், இந்த listener-ஐப் பயன்படுத்தும் அனைவருக்கும் பொருந்தும்.

தற்காலிக write தோல்விகள் ஆபத்தானவையாகத் தோன்றக்கூடும் (சிக்கல் #33278)

இது அதன் நேர் எதிர் நிலையாகும். Listener மூலம் ஏற்றுக்கொள்ளப்பட்ட ஒரு nonblocking இணைப்பில், சாதாரணமாக மீண்டும் முயற்சிக்கப்பட வேண்டிய ஒரு write செயல்பாடு வழங்கக்கூடிய பிழைக் குறியீடு: SSL_ERROR_SYSCALL என்பதற்குப் பதிலாக SSL_ERROR_WANT_WRITE. இதை முனையப் பிழையாகக் (fatal) கருதும் ஒரு பயன்பாடு, இன்னும் சரியாகவே இருக்கும் ஓர் இணைப்பை மூடிவிடக்கூடும்.

வேறு ஒரு API வழியில் உருவாக்கப்பட்ட DTLS சேவையகம் சரியான retry குறியீட்டைத் திருப்பியளித்ததாக அந்த அறிக்கை தெரிவிக்கிறது. இந்தச் சிக்கல் listener சார்ந்த இணைப்புகளுடன் தொடர்புடையது மற்றும் இது DTLS 1.3-க்கு மட்டும் வரையறுக்கப்பட்டதல்ல.

சரியான acknowledgement-களும் handshake-களை முறித்துவிடக்கூடும் (சிக்கல் #33242)

ஒரு கிளையன்ட் சேவையகத்தின் முதல் தொகுதி handshake செய்திகளில் ஒரு பகுதியை மட்டுமே பெறும்போது, அது வந்து சேர்ந்த பதிவுகளுக்கு acknowledgement அனுப்பக்கூடும். OpenSSL 4.1.0 ஒரு சேவையகமாக செயல்படும்போது, அந்த acknowledgement-க்கு ஓர் unexpected_message எச்சரிக்கையுடன் (alert) பதிலளித்து handshake-ஐ முடித்துவிடக்கூடும்.

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

GREASE: புரோட்டோகாலை நெகிழ்வுத்தன்மையுடன் வைத்திருத்தல்

GREASE என்பது Generate Random Extensions And Sustain Extensibility என்பதைக் குறிக்கிறது; இது RFC 8701-இல் விவரிக்கப்பட்டுள்ளது.

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

GREASE வேண்டுமென்றே ஒதுக்கப்பட்ட, அர்த்தமற்ற மதிப்புகளை அனுப்புகிறது. சரியான ஒரு முனை சாதனம் (peer) அவற்றைப் புறக்கணிக்கும். குறைபாடுள்ள சாதனம், பல ஆண்டுகளுக்குப் பிறகு ஒரு உண்மையான புதிய நீட்டிப்பு (extension) இந்த சகிப்புத்தன்மையை நம்பியிருக்கும்போது தோல்வியடைவதற்குப் பதிலாக, சோதனையின் போதே ஆரம்பத்திலேயே தோல்வியடையும். ஆபரேட்டர்களுக்கு, இதன் முக்கிய நோக்கம் நீண்ட கால இணக்கத்தன்மையே ஆகும். உங்கள் endpoints, load balancers மற்றும் ஆய்வு சாதனங்கள், குறிப்பாகப் பழைய சாதனங்கள், இவற்றைச் சமாளிக்கின்றனவா என்பதைச் சரிபார்க்கவும்.

வேகமான மறைகுறியாக்கவியல் மற்றும் build மாற்றங்கள்

இந்த வெளியீடு செயல்திறன் மேம்பாடுகளையும் கொண்டுவருகிறது:

• ppc64le-இல் ML-DSA மற்றும் ML-KEM உகப்பாக்கங்கள் (இவை post-quantum கையொப்பம் மற்றும் key-exchange அல்காரிதங்கள் ஆகும்).
• AVX-512-முடுக்கப்பட்ட SHAKE உட்பட, x86_64-இல் ML-DSA மேம்பாடுகள்.
• AES-CBC டிக்ரிப்ஷனுக்கான AVX-512 மற்றும் VAES உகப்பாக்கங்கள்.
• ஒரு புதிய IKEv2 key-derivation function மற்றும் ஆரம்பக்கட்ட Elbrus2000 கட்டமைப்பு ஆதரவு.

கவனிக்க வேண்டிய build மாற்றங்கள்:

• புதிய MSVC 2013 இலக்குகள் (targets).
• Windows-on-Itanium மற்றும் Windows CE இலக்குகள் நீக்கப்பட்டன.
• அந்த no-ecdsa மற்றும் no-ecdh ஆகிய தேர்வுகள் நீக்கப்பட்டன. அவை அந்தச் செயலாக்கங்களை ஒருபோதும் உண்மையில் முடக்கவில்லை என்று இத்திட்டம் விளக்குகிறது. Elliptic-curve ஆதரவை முடக்க, இதனைப் பயன்படுத்தவும்: no-ec.
• அந்த tsget பயன்பாடானது தற்போது இதனைச் சார்ந்துள்ளது: Net::Curl::Easy.

வேகமான ஒரு அடிப்படை அம்சம் (primitive), பயன்பாடும் வேகமாக இருக்கும் என்று பொருள்படாது. வெறும் மைக்ரோ-பெஞ்ச்மார்க்குகளை மட்டும் பார்க்காமல், யதார்த்தமான இணைப்பு முறைகள் மற்றும் பணிச்சுமைகளுடன் அளவிடவும்.

ஆதரவுத் தேதிகள் முடிவை வடிவமைக்கின்றன

OpenSSL திட்டம் இந்த அப்ஸ்ட்ரீம் ஆதரவுத் தேதிகளைப் பட்டியலிடுகிறது:

தொடர்	ஆதரவு வரை
OpenSSL 4.1	நவம்பர் 2027
OpenSSL 4.0	14 மே 2027
OpenSSL 3.6	1 நவம்பர் 2026
OpenSSL 3.5 LTS	8 ஏப்ரல் 2030

எனவே இந்தப் புதிய வெளியீடு, 3.5 LTS-ஐ விட மிகக் குறுகிய காலப் பராமரிப்பையே கொண்டுள்ளது. 3.6-இன் ஆதரவு ஏறக்குறைய இப்போதே முடிவடைகிறது என்பதைக் கவனத்தில் கொள்ளவும். மேலும், உங்கள் இயங்குதளம் அல்லது தயாரிப்பு விற்பனையாளர் எதை ஆதரிக்கிறார் என்பதையும் சரிபார்க்கவும்; ஏனெனில் தொகுக்கப்பட்ட (packaged) OpenSSL பெரும்பாலும் விற்பனையாளரின் அட்டவணையைப் பின்பற்றுமே தவிர, அப்ஸ்ட்ரீம் திட்டத்தின் அட்டவணையை அல்ல.

OpenSSL 4.1.0-ஐப் பாதுகாப்பாக மதிப்பீடு செய்வது எப்படி

படி 1: இது உங்களுக்குத் தேவையா என்பதைத் தீர்மானிக்கவும்

DTLS 1.3-ஐப் பயன்படுத்தக்கூடிய பயன்பாடுகள், DTLS listener-ஐப் பயன்படுத்தும் பயன்பாடுகள் மற்றும் நீண்ட கால ஆதரவு தேவைப்படும் பயன்பாடுகளைப் பட்டியலிடுங்கள். புதிய அம்சங்கள் எவையும் தேவைப்படவில்லை என்றால், 3.5 LTS-இலேயே தொடர்வது ஒரு விவேகமான தேர்வாகும்.

படி 2: நீங்கள் எந்த build-ஐச் சோதிக்கிறீர்கள் என்பதை உறுதிப்படுத்தவும்

சோதனை build-ஐ ஒரு தனிமைப்படுத்தப்பட்ட சூழலில் இயக்கவும், ஒருபோதும் நேரடியாக தயாரிப்புச் சூழலில் இயக்க வேண்டாம்; மேலும் அதன் பதிப்பு மற்றும் build தேர்வுகளை உறுதிப்படுத்தவும்:

openssl version -a

படி 3: தெளிவான நெட்வொர்க்கில் மட்டுமல்லாமல், பாக்கெட் இழப்பு சூழலிலும் சோதிக்கவும்

ஒரு Linux சோதனை கணினியில், loopback இடைமுகத்தில் நீங்கள் செயற்கையான இழப்பு மற்றும் தாமதத்தை இதைக் கொண்டு சேர்க்கலாம்: netem, பின்னர் உங்கள் DTLS கிளையன்ட் மற்றும் சேவையகத்தை அதற்கு எதிராக இயக்கிவிட்டு, அந்த விதியை நீக்கலாம்:

sudo tc qdisc add dev lo root netem loss 5% delay 50ms
# run your DTLS client/server tests here
sudo tc qdisc del dev lo root

முதல் இணைப்பைப் போலவே handshake-க்குப் பிந்தைய நடத்தையையும் (session tickets, key updates) கண்காணிக்கவும்.

படி 4: பிற செயலாக்கங்களுக்கு எதிராகவும் சோதிக்கவும்

சிக்கல் #33242 ஆனது OpenSSL-க்கு-OpenSSL சோதனைகளில் வெளிப்படாது என்பதால், பாக்கெட் இழப்பின் கீழ் உங்கள் சேவையகத்துடன் குறைந்தபட்சம் ஒரு OpenSSL அல்லாத DTLS கிளையன்ட்டையாவது இணைத்துப் பார்க்கவும்.

படி 5: உங்கள் பிழை கையாளுதலைச் சரிபார்க்கவும்

நீங்கள் DTLS listener-ஐப் பயன்படுத்துகிறீர்கள் என்றால், உங்கள் நிரல் குறியீடு பின்வருவனவற்றை எவ்வாறு கையாள்கிறது என்பதை மதிப்பாய்வு செய்யவும்: SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE மற்றும் SSL_ERROR_SYSCALL. ஒருபோதும் வெற்றியடையாத "மீண்டும் முயற்சிக்கவும்" என்ற நிலை ஓர் இணைப்பை எப்போதும் முடக்கிவிடாமல் இருக்க, timeout-களைச் சேர்க்கவும்.

படி 6: உள்ளபடியே பெஞ்ச்மார்க் செய்து மீண்டும் பில்ட் செய்யவும்

உங்கள் உண்மையான வன்பொருளில் உங்கள் உண்மையான பணிச்சுமையை பெஞ்ச்மார்க் செய்யுங்கள். உங்கள் build pipeline-ஐ மீண்டும் இயக்கி, no-ec போன்ற தேர்வுகள் நீங்கள் எதிர்பார்க்கும் கட்டமைப்பை உருவாக்குகின்றன என்பதை உறுதிப்படுத்தவும்.

முடிவுரை

OpenSSL 4.1.0 என்பது ஒரு குறிப்பிடத்தக்க அம்சம் நிறைந்த வெளியீடாகும். DTLS 1.3 மற்றும் GREASE ஆகியவை டேட்டாகிராம் பாதுகாப்பு மற்றும் எதிர்கால இணக்கத்தன்மையை வலுப்படுத்துகின்றன; மேலும் புதிய உகப்பாக்கங்கள் ஆதரிக்கப்படும் வன்பொருளில் post-quantum மற்றும் AES பணிகளை விரைவுபடுத்தக்கூடும். ஆனால் ஒரு புதிய லைப்ரரியை மாற்றிவிட்டு பயன்பாடு துவங்குவதைப் பார்ப்பது மட்டுமே இதனை ஏற்பதாகாது. அறியப்பட்ட நான்கு DTLS சிக்கல்கள் உங்களுக்குத் தெளிவான சோதனைச் சூழல்களைத் தருகின்றன, ஆதரவுக் காலம் குறுகியது, மேலும் உண்மையான உறுதிப்பாடு என்பது இயங்குதன்மை (interoperability), தோல்வி மீட்பு மற்றும் பணிச்சுமை சோதனைகளிலிருந்தே கிடைக்கிறது.

நன்மைகள்

• DTLS 1.3 ஆனது TLS 1.3 காலப் பாதுகாப்பை UDP போக்குவரத்திற்குக் கொண்டுவருகிறது.
• எதிர்கால நீட்டிப்புகளை முறிக்கும் முன் பலவீனமான பியர்களைக் (peers) கண்டறிய GREASE உதவுகிறது.
• ஆதரிக்கப்படும் CPU-களில் வேகமான ML-DSA, ML-KEM மற்றும் AES-CBC code path-கள்.
• தூய்மையான build தேர்வுகள்: தவறாக வழிநடத்தக்கூடிய no-ecdsa மற்றும் no-ecdh கொடிகள் (flags) நீக்கப்பட்டுவிட்டன.
• அறியப்பட்ட சிக்கல்கள் reproducers உடன் வெளிப்படையாக ஆவணப்படுத்தப்பட்டுள்ளன.

குறைபாடுகள்

• 3.5 LTS-ஐ விட மிக விரைவாக, நவம்பர் 2027-இல் ஆதரவு முடிவடைகிறது.
• அறியப்பட்ட நான்கு DTLS சிக்கல்கள் மறுபரிமாற்றம், பிழை அறிவிப்பு மற்றும் handshake-களை பாதிக்கின்றன.
• இரண்டு listener சிக்கல்கள் DTLS 1.2 பயனர்களையும் பாதிக்கின்றன.
• Build மாற்றங்கள் தற்போதைய ஸ்கிரிப்டுகள் அல்லது இலக்குகளைப் பாதிக்கக்கூடும்.
• செயல்திறன் ஆதாயங்கள் குறிப்பிட்ட வன்பொருளைச் சார்ந்துள்ளன, மேலும் அவை பயன்பாட்டு நிலையை அடையாமல் போகலாம்.

எச்சரிக்கை

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

அடிக்கடி கேட்கப்படும் கேள்விகள்

• OpenSSL 4.1.0-இல் புதிதாக என்ன உள்ளது? — இது DTLS 1.3, GREASE, ML-DSA, ML-KEM மற்றும் AES-CBC உகப்பாக்கங்கள், ஒரு IKEv2 key-derivation function மற்றும் பல build மாற்றங்களைச் சேர்க்கிறது.
• DTLS 1.3 என்றால் என்ன? — இது RFC 9147-இல் வரையறுக்கப்பட்ட TLS 1.3-இன் டேட்டாகிராம் பதிப்பாகும்; இது UDP வழியிலான போக்குவரத்தை மறைகுறியாக்கிப் பாதுகாக்கிறது.
• அறியப்பட்ட நான்கு DTLS சிக்கல்களும் பாதுகாப்புப் பாதிப்புகளா? — இந்த அறிவிப்பு அவற்றை இணைப்பு நடத்தை மற்றும் நம்பகத்தன்மை சார்ந்த சிக்கல்களாக விவரிக்கிறதே தவிர, தீவிரமான பாதிப்புகளாக அல்ல; மேலும் எந்தவொரு தீவிர அச்சுறுத்தலும் பயன்படுத்தப்பட்டதாகத் தெரிவிக்கவில்லை.
• அறியப்பட்ட சிக்கல்கள் DTLS 1.2-ஐப் பாதிக்கிறதா? — ஆம், இரண்டு listener பிழை அறிவிப்புச் சிக்கல்கள் (#33277 மற்றும் #33278) DTLS 1.3-க்கு மட்டும் வரையறுக்கப்பட்டவை அல்ல.
• TLS-இல் GREASE என்ன செய்கிறது? — தெரியாத நீட்டிப்புகளைத் தவறாக நிராகரிக்கும் பியர்களை (peers) ஆரம்பத்திலேயே கண்டறியும் வகையில் இது ஒதுக்கப்பட்ட சீரற்ற மதிப்புகளை அனுப்புகிறது; இதன் மூலம் புரோட்டோகால் நீட்டிப்புத் திறனுடன் நிலைத்திருக்க உதவுகிறது.
• OpenSSL 4.1 எவ்வளவு காலம் ஆதரிக்கப்படுகிறது? — அப்ஸ்ட்ரீம் ஆதரவு நவம்பர் 2027 வரை இருக்கும்; அதே நேரத்தில் OpenSSL 3.5 LTS ஆனது 8 ஏப்ரல் 2030 வரை ஆதரிக்கப்படுகிறது.
• நான் OpenSSL 3.5 LTS-இலிருந்து 4.1-க்கு மேம்படுத்த வேண்டுமா? — அதன் புதிய அம்சங்கள் உங்களுக்குத் தேவைப்பட்டு, அவற்றை உங்களால் நன்றாகச் சோதிக்க முடிந்தால் மட்டுமே மேம்படுத்தவும்; இல்லையெனில் 3.5 LTS மிக நீண்ட ஆதரவுக் காலத்தை வழங்குகிறது.
• OpenSSL build-இல் elliptic-curve ஆதரவை எவ்வாறு முடக்குவது? — no-ec தேர்வைப் பயன்படுத்தவும்; நீக்கப்பட்ட no-ecdsa மற்றும் no-ecdh ஆகிய தேர்வுகள் உண்மையில் அந்தச் செயலாக்கங்களை ஒருபோதும் முடக்கவில்லை.

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

#OpenSSL #DTLS13 #TLS #Cryptography #PostQuantum #NetworkSecurity #CyberSecurity #DevSecOps #UDP #InfoSec