OpenSSL 4.1.0 DTLS 1.3, GREASE എന്നിവ അവതരിപ്പിക്കുന്നു: അപ്‌ഗ്രേഡ് ചെയ്യുന്നതിന് മുൻപ് എന്തൊക്കെ പരിശോധിക്കണം

ഒരു പുതിയ OpenSSL റിലീസ് സാധാരണയായി ഒരു ലളിതമായ ലൈബ്രറി മാറ്റം പോലെയാണ് തോന്നാറുള്ളത്. എന്നാൽ OpenSSL 4.1.0-ന് അതിനേക്കാൾ കൂടുതൽ ശ്രദ്ധ ആവശ്യമാണ്, കാരണം ഇതിന്റെ പ്രധാന സവിശേഷതയായ DTLS 1.3 എത്തുന്നത് നെറ്റ്‌വർക്കിൽ തടസ്സങ്ങൾ ഉണ്ടാകുമ്പോൾ മാത്രം ദൃശ്യമാകുന്ന അറിയപ്പെടുന്ന നാല് പ്രശ്നങ്ങളോടെയാണ്.

2026 നവംബർ 2 വരെയുള്ള വിവരമനുസരിച്ച്, ഇന്റർനെറ്റിന്റെ എൻക്രിപ്റ്റ് ചെയ്ത കണക്ഷനുകളിൽ വലിയൊരു പങ്കും സുരക്ഷിതമാക്കുന്ന ടൂൾകിറ്റിന്റെ ഏറ്റവും പുതിയ ഫീച്ചർ റിലീസാണ് OpenSSL 4.1.0. ഇത് DTLS 1.3, GREASE, വേഗതയേറിയ post-quantum, AES കോഡ് പാതകൾ, കൂടാതെ നിരവധി ബിൽഡ് മാറ്റങ്ങൾ എന്നിവ ചേർക്കുന്നു. OpenSSL ഉപയോഗിച്ച് സോഫ്റ്റ്‌വെയർ നിർമ്മിക്കുന്ന ഏതൊരു ടീമിനും ഇപ്പോൾ മുന്നിലുള്ളത് പ്രായോഗികമായ ചോദ്യങ്ങളാണ്: ഈ പുതിയ റിലീസ് സ്വീകരിക്കാൻ തക്ക മൂല്യമുള്ളതാണോ, ഒപ്പം രേഖപ്പെടുത്തിയിട്ടുള്ള പരിമിതികൾക്കൊപ്പം ആപ്ലിക്കേഷനുകൾ ശരിയായി പ്രവർത്തിക്കുമോ?

ലളിതമായ വാക്കുകളിൽ എന്താണ് DTLS 1.3

എൻക്രിപ്റ്റ് ചെയ്ത മിക്ക വെബ് ട്രാഫിക്കും TCP-യിൽ പ്രവർത്തിക്കുന്ന TLS ആണ് ഉപയോഗിക്കുന്നത്. TCP ഒരു വിശ്വസനീയമായ ട്രാൻസ്പോർട്ട് ആണ്: ഇത് നഷ്ടപ്പെട്ട പാക്കറ്റുകൾ വീണ്ടും അയയ്ക്കുകയും ക്രമത്തിൽ എത്തിക്കുകയും ചെയ്യുന്നു.

ഇത്തരം ഉറപ്പുകളൊന്നും നൽകാത്ത ട്രാൻസ്പോർട്ടായ UDP-യിൽ ഇതേ സുരക്ഷാ ദൗത്യം DTLS (Datagram Transport Layer Security) നിർവ്വഹിക്കുന്നു. ഇതിൽ പാക്കറ്റുകൾ വൈകിയോ, ക്രമം തെറ്റിയോ, അല്ലെങ്കിൽ ഒട്ടും വരാതെയോ ഇരിക്കാം. വേഗതയുള്ളതായതിനാൽ വീഡിയോ കോളുകൾ, VPN-കൾ, ഗെയിം ട്രാഫിക്, നിരവധി IoT ഉപകരണങ്ങൾ എന്നിവ UDP-യെ ആശ്രയിക്കുന്നു, അവയുടെ സ്വകാര്യത നിലനിർത്തുന്നത് DTLS വഴിയാണ്.

DTLS 1.3 എന്നത് RFC 9147-ൽ നിർവ്വചിച്ചിട്ടുള്ളതും TLS 1.3-ൽ നിർമ്മിച്ചിട്ടുള്ളതുമാണ്. UDP-യുടെ ഡാറ്റാഗ്രാം സ്വഭാവം നിലനിർത്തിക്കൊണ്ടുതന്നെ ഇത് ചോർത്തലുകൾ, കൃത്രിമം കാണിക്കൽ, വ്യാജ സന്ദേശങ്ങൾ എന്നിവയിൽ നിന്ന് സംരക്ഷിക്കുന്നു. പ്രത്യേകിച്ച് ഓർഡറിംഗും റീപ്ലേ പരിരക്ഷയും സംബന്ധിച്ച് ഇതിന്റെ ഉറപ്പുകൾ TLS-ൽ നിന്ന് എവിടെയൊക്കെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു എന്ന് സ്പെസിഫിക്കേഷൻ വ്യക്തമായി പറയുന്നുണ്ട്. അതിനാൽ നിങ്ങളുടെ ആപ്ലിക്കേഷൻ തന്നെ ചില കാര്യങ്ങൾ കൈകാര്യം ചെയ്യേണ്ടതുണ്ട്.

പ്രധാന പാഠം ഇതാണ്: തടസ്സങ്ങളില്ലാത്ത ഒരു ലാബ് നെറ്റ്‌വർക്കിൽ പ്രവർത്തിക്കുന്ന ഒരു DTLS കണക്ഷൻ വളരെ കുറഞ്ഞ കാര്യങ്ങൾ മാത്രമേ തെളിയിക്കുന്നുള്ളൂ. നഷ്ടപ്പെട്ട പാക്കറ്റുകൾ, വൈകിയെത്തുന്ന മറുപടികൾ, പുനഃസംപ്രേഷണങ്ങൾ (retransmissions), മറുവശത്തുള്ള മറ്റൊരു ഇംപ്ലിമെന്റേഷനുമായി സംവദിക്കുന്നത് എന്നിവയാണ് സങ്കീർണ്ണമായ സാഹചര്യങ്ങൾ.

അറിയപ്പെടുന്ന നാല് DTLS പ്രശ്നങ്ങൾ

റിലീസ് കുറിപ്പുകളിൽ അറിയപ്പെടുന്ന നാല് പ്രശ്നങ്ങൾ പട്ടികപ്പെടുത്തിയിട്ടുണ്ട്. അവ കണക്ഷന്റെ പ്രവർത്തനത്തെയും വിശ്വാസ്യതയെയും ബാധിക്കുന്നു. പ്രഖ്യാപനത്തിൽ ഇവയെ ഗുരുതരമായ സുരക്ഷാ വീഴ്ചകളായി (critical vulnerabilities) വിശേഷിപ്പിച്ചിട്ടില്ല, കൂടാതെ ഇത് ദുരുപയോഗം ചെയ്യുന്നതായും റിപ്പോർട്ട് ചെയ്തിട്ടില്ല. എന്നിരുന്നാലും, ഓരോന്നും മുൻകൂട്ടി തയ്യാറാക്കിയ ഒരു ടെസ്റ്റ് കേസ് ആണ്.

കീ അപ്‌ഡേറ്റുകൾക്ക് സെഷൻ-ടിക്കറ്റ് പുനഃസംപ്രേഷണം തടയാൻ കഴിയും (issue #32878)

ഒരു DTLS 1.3 ഹാൻഡ്‌ഷെയ്ക്കിന് ശേഷം, സെർവർ സെഷൻ ടിക്കറ്റുകൾ അയച്ചേക്കാം. പിന്നീട് വേഗത്തിൽ വീണ്ടും കണക്റ്റുചെയ്യാൻ ഇത് ഒരു ക്ലയന്റിനെ അനുവദിക്കുന്നു. ഒരു കീ അപ്‌ഡേറ്റ് നടക്കുമ്പോൾ പിയർ ആ ടിക്കറ്റുകൾ ഇതുവരെ അക്‌നോളജ് ചെയ്തിട്ടില്ലെങ്കിൽ, OpenSSL-ന് അവ നീക്കം ചെയ്യാനും അവയുടെ റീട്രാൻസ്മിഷൻ ടൈമർ നിർത്താനും കഴിയും.

കീ അപ്‌ഡേറ്റ് എന്നത് ഒരു പ്രത്യേക വിനിമയമാണ്. ടിക്കറ്റുകൾ എത്തിച്ചേർന്നു എന്ന് ഇത് തെളിയിക്കുന്നില്ല. ഒരു ടിക്കറ്റ് നഷ്ടപ്പെട്ടാൽ, അത് ഒരിക്കലും വീണ്ടും അയച്ചേക്കില്ല. അക്‌നോളജ്‌മെന്റില്ലാതെ ടിക്കറ്റുകൾ നീക്കം ചെയ്യുന്നത് കാണിക്കുന്ന ഒരു റീപ്രൊഡ്യൂസർ ഈ പ്രശ്ന റിപ്പോർട്ടിൽ ഉൾപ്പെടുന്നു.

സ്ഥിരമായ റിസീവ് പരാജയങ്ങൾ താൽക്കാലികമായി തോന്നാം (issue #33277)

OpenSSL-ന്റെ DTLS ലിസണർ വഴി നിർമ്മിച്ച കണക്ഷനുകളിൽ, ഒരു സ്ഥിരമായ റിസീവ് പരാജയം ഇതായി റിപ്പോർട്ട് ചെയ്യപ്പെടാം SSL_ERROR_WANT_READ. ആ കോഡ് സാധാരണയായി "ഇതുവരെ ഒന്നുമില്ല, വീണ്ടും ശ്രമിക്കുക" എന്നാണ് അർത്ഥമാക്കുന്നത്. ഇതിനെ ആശ്രയിക്കുന്ന ഒരു ആപ്ലിക്കേഷൻ നിർജീവമായ കണക്ഷനിൽ അനന്തമായി കാത്തിരുന്നേക്കാം. പോളിംഗും പിന്നീടുള്ള accept കോളുകളും ഈ പരാജയപ്പെട്ട അവസ്ഥയെ മറച്ചുവെച്ചേക്കാം.

റീപ്രൊഡ്യൂസറിൽ DTLS 1.2 ഉൾപ്പെടുന്നു, അതിനാൽ ഇത് DTLS 1.3 ഉപയോക്താക്കൾക്ക് മാത്രമല്ല, ലിസണർ ഉപയോഗിക്കുന്ന ആർക്കും ബാധകമാണ്.

താൽക്കാലിക റൈറ്റ് പരാജയങ്ങൾ ഗുരുതരമായി തോന്നാം (issue #33278)

ഇത് ഇതിന്റെ വിപരീത പ്രതിഫലനമാണ്. ലിസണർ വഴി സ്വീകരിച്ച നോൺ-ബ്ലോക്കിംഗ് കണക്ഷനിൽ, വീണ്ടും ശ്രമിക്കേണ്ട ഒരു റൈറ്റിന് ഇതായി മറുപടി ലഭിക്കാം SSL_ERROR_SYSCALL ഇതിന് പകരമായി SSL_ERROR_WANT_WRITE. അത് ഗുരുതരമായ പിശകായി കാണുന്ന ഒരു ആപ്ലിക്കേഷൻ ഇപ്പോഴും പ്രവർത്തനക്ഷമമായ ഒരു കണക്ഷൻ ക്ലോസ് ചെയ്തേക്കാം.

മറ്റൊരു API പാത വഴി നിർമ്മിച്ച ഒരു DTLS സെർവർ ശരിയായ റീട്രൈ കോഡ് നൽകിയതായി റിപ്പോർട്ടിൽ കണ്ടെത്തി. ഈ പ്രശ്നം ലിസണർ അടിസ്ഥാനമാക്കിയുള്ള കണക്ഷനുകളുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, മാത്രമല്ല ഇത് DTLS 1.3-ൽ മാത്രം ഒതുങ്ങുന്നതുമല്ല.

സാധുവായ അക്‌നോളജ്‌മെന്റുകൾ ഹാൻഡ്‌ഷെയ്ക്കുകൾ റദ്ദാക്കിയേക്കാം (issue #33242)

സെർവറിന്റെ ആദ്യ ബാച്ച് ഹാൻഡ്‌ഷേക്ക് സന്ദേശങ്ങളുടെ ഒരു ഭാഗം മാത്രം ഒരു ക്ലയന്റിന് ലഭിക്കുമ്പോൾ, എത്തിച്ചേർന്ന റെക്കോർഡുകൾ അത് അക്‌നോളജ് ചെയ്തേക്കാം. ഒരു സെർവർ എന്ന നിലയിൽ OpenSSL 4.1.0 ആ അക്‌നോളജ്‌മെന്റിന് മറുപടിയായി ഒരു unexpected_message അലേർട്ട് നൽകുകയും ഹാൻഡ്‌ഷേക്ക് അവസാനിപ്പിക്കുകയും ചെയ്തേക്കാം.

ഇതിലെ ചതിക്കുഴി ഇതാണ്: OpenSSL ക്ലയന്റ് ആ അക്‌നോളജ്‌മെന്റുകൾ കൈകാര്യം ചെയ്യുന്ന രീതി കാരണം OpenSSL-ടു-OpenSSL ടെസ്റ്റുകളിൽ ഇത് സംഭവിക്കുന്നില്ല. ഒരു വിന്യാസത്തിന് എല്ലാ ആഭ്യന്തര പരിശോധനകളിലും വിജയിക്കാനാകും, എന്നിട്ടും പാക്കറ്റ് നഷ്ടമുള്ള ഒരു നെറ്റ്‌വർക്കിൽ മറ്റൊരു ക്ലയന്റ് ലൈബ്രറി ഉപയോഗിക്കുമ്പോൾ പരാജയപ്പെടാം.

GREASE: പ്രോട്ടോക്കോളിന്റെ വഴക്കം നിലനിർത്തുന്നു

RFC 8701-ൽ വിവരിച്ചിട്ടുള്ള Generate Random Extensions And Sustain Extensibility എന്നതിന്റെ ചുരുക്കരൂപമാണ് GREASE.

TLS ഓരോ വശത്തെയും തങ്ങൾ പിന്തുണയ്ക്കുന്ന കാര്യങ്ങൾ പരസ്പരം അറിയിക്കാൻ അനുവദിക്കുന്നു, കൂടാതെ മറുവശം തങ്ങൾക്ക് മനസ്സിലാകുന്ന ഓപ്ഷനുകൾ തിരഞ്ഞെടുക്കുന്നു. സോഫ്റ്റ്‌വെയർ തിരിച്ചറിയാത്ത മൂല്യങ്ങളെ അവഗണിക്കുകയാണെങ്കിൽ മാത്രമേ ഇത് ശരിയായി പ്രവർത്തിക്കൂ. എന്നാൽ ചില ഇംപ്ലിമെന്റേഷനുകൾ പരിചയമില്ലാത്ത എന്തിനെയും നിരസിക്കുന്നു, ഇത് പിന്നീട് പ്രോട്ടോക്കോളിലേക്ക് പുതിയ സവിശേഷതകൾ ചേർക്കുന്നത് ബുദ്ധിമുട്ടാക്കുന്നു.

GREASE മനഃപൂർവ്വം റിസർവ് ചെയ്ത, അർത്ഥമില്ലാത്ത മൂല്യങ്ങൾ അയയ്ക്കുന്നു. ശരിയായ ഒരു പിയർ അവയെ അവഗണിക്കുന്നു. എന്നാൽ തകരാറുള്ള ഒരു പിയർ, വർഷങ്ങൾക്ക് ശേഷം ഒരു യഥാർത്ഥ പുതിയ എക്സ്റ്റൻഷൻ അത്തരം സഹിഷ്ണുതയെ ആശ്രയിക്കുമ്പോൾ പരാജയപ്പെടുന്നതിന് പകരം, ടെസ്റ്റിംഗ് ഘട്ടത്തിൽ തന്നെ തുടക്കത്തിലേ പരാജയപ്പെടുന്നു. ഓപ്പറേറ്റർമാരെ സംബന്ധിച്ചിടത്തോളം ദീർഘകാല അനുയോജ്യതയാണ് ഇതിന്റെ ലക്ഷ്യം. നിങ്ങളുടെ എൻഡ്‌പോയിന്റുകൾ, ലോഡ് ബാലൻസറുകൾ, ഇൻസ്പെക്ഷൻ ഉപകരണങ്ങൾ എന്നിവ, പ്രത്യേകിച്ച് പഴയവ, ഇത് കൈകാര്യം ചെയ്യുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക.

വേഗതയേറിയ ക്രിപ്റ്റോഗ്രാഫിയും ബിൽഡ് മാറ്റങ്ങളും

ഈ റിലീസ് പ്രകടനപരമായ മെച്ചപ്പെടുത്തലുകളും കൊണ്ടുവരുന്നു:

• ppc64le-ലെ ML-DSA, ML-KEM ഒപ്റ്റിമൈസേഷനുകൾ (ഇവ post-quantum സിഗ്നേച്ചർ, കീ-എക്‌സ്‌ചേഞ്ച് അൽഗോരിതങ്ങളാണ്).
• AVX-512-accelerated SHAKE ഉൾപ്പെടെ x86_64-ലെ ML-DSA മെച്ചപ്പെടുത്തലുകൾ.
• AES-CBC ഡീക്രിപ്ഷനുള്ള AVX-512, VAES ഒപ്റ്റിമൈസേഷനുകൾ.
• ഒരു പുതിയ IKEv2 കീ-ഡെറിവേഷൻ ഫംഗ്ഷനും പ്രാരംഭ Elbrus2000 ആർക്കിടെക്ചർ പിന്തുണയും.

ശ്രദ്ധിക്കേണ്ട ബിൽഡ് മാറ്റങ്ങൾ:

• പുതിയ MSVC 2013 ടാർഗെറ്റുകൾ.
• Windows-on-Itanium, Windows CE ടാർഗെറ്റുകൾ നീക്കംചെയ്‌തു.
• ഈ no-ecdsa ഒപ്പം no-ecdh ഓപ്ഷനുകൾ നീക്കംചെയ്‌തു. പ്രോജക്റ്റ് വിശദീകരിക്കുന്നത് അനുസരിച്ച് അവ ഒരിക്കലും യഥാർത്ഥത്തിൽ ആ ഇംപ്ലിമെന്റേഷനുകളെ പ്രവർത്തനരഹിതമാക്കിയിരുന്നില്ല. എലിപ്റ്റിക്-കർവ് പിന്തുണ പ്രവർത്തനരഹിതമാക്കാൻ, ഇത് ഉപയോഗിക്കുക: no-ec.
• ഈ tsget യൂട്ടിലിറ്റി ഇപ്പോൾ ആശ്രയിക്കുന്നത് ഇതിനെയാണ്: Net::Curl::Easy.

വേഗതയേറിയ ഒരു പ്രിമിറ്റീവ് എന്നാൽ വേഗതയേറിയ ഒരു ആപ്ലിക്കേഷൻ എന്നർത്ഥമില്ല. മൈക്രോ-ബെഞ്ച്മാർക്കുകൾ മാത്രമല്ല, റിയലിസ്റ്റിക് കണക്ഷൻ പാറ്റേണുകളും വർക്ക്ലോഡുകളും ഉപയോഗിച്ച് അളക്കുക.

സപ്പോർട്ട് തീയതികളാണ് തീരുമാനം നിർണ്ണയിക്കുന്നത്

OpenSSL പ്രോജക്റ്റ് ഈ അപ്‌സ്ട്രീം സപ്പോർട്ട് തീയതികൾ പട്ടികപ്പെടുത്തുന്നു:

പരമ്പര (Series)	ഇതുവരെ പിന്തുണ ലഭ്യമാണ്
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-ന്റെ പിന്തുണ ഇപ്പോൾ അവസാനിക്കുകയാണെന്ന കാര്യം ശ്രദ്ധിക്കുക. കൂടാതെ നിങ്ങളുടെ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം അല്ലെങ്കിൽ പ്രൊഡക്റ്റ് വെണ്ടർ എന്താണ് പിന്തുണയ്ക്കുന്നതെന്നും പരിശോധിക്കുക, കാരണം പാക്കേജ് ചെയ്ത OpenSSL പലപ്പോഴും അപ്‌സ്ട്രീമിന്റേതല്ല, മറിച്ച് വെണ്ടറുടെ ഷെഡ്യൂളാണ് പിന്തുടരുന്നത്.

OpenSSL 4.1.0 എങ്ങനെ സുരക്ഷിതമായി വിലയിരുത്താം

ഘട്ടം 1: നിങ്ങൾക്ക് ഇത് ആവശ്യമുണ്ടോ എന്ന് തീരുമാനിക്കുക

DTLS 1.3 ഉപയോഗിക്കുന്ന ആപ്ലിക്കേഷനുകൾ, DTLS ലിസണർ ഉപയോഗിക്കുന്നവ, ദീർഘകാല സപ്പോർട്ട് ആവശ്യമുള്ളവ എന്നിവ പട്ടികപ്പെടുത്തുക. പുതിയ ഫീച്ചറുകൾ ആവശ്യമില്ലെങ്കിൽ, 3.5 LTS-ൽ തുടരുന്നത് ന്യായമായ ഒരു തിരഞ്ഞെടുപ്പാണ്.

ഘട്ടം 2: നിങ്ങൾ ഏത് ബിൽഡാണ് പരിശോധിക്കുന്നതെന്ന് സ്ഥിരീകരിക്കുക

ടെസ്റ്റ് ബിൽഡ് പ്രൊഡക്ഷനിൽ നേരിട്ട് പ്രവർത്തിപ്പിക്കാതെ ഒരു ഐസൊലേറ്റഡ് എൻവയോൺമെന്റിൽ പ്രവർത്തിപ്പിക്കുക, കൂടാതെ അതിന്റെ പതിപ്പും ബിൽഡ് ഓപ്ഷനുകളും സ്ഥിരീകരിക്കുക:

openssl version -a

ഘട്ടം 3: ക്ലീൻ നെറ്റ്‌വർക്കിൽ മാത്രമല്ല, പാക്കറ്റ് നഷ്ടം ഉള്ളപ്പോഴും പരിശോധിക്കുക

ഒരു Linux ടെസ്റ്റ് മെഷീനിൽ, ലൂപ്പ്ബാക്ക് ഇന്റർഫേസിലേക്ക് കൃത്രിമമായി പാക്കറ്റ് നഷ്ടവും ഡിലേയും ചേർക്കാൻ ഇത് ഉപയോഗിക്കാം: 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

ആദ്യ കണക്ഷനൊപ്പം തന്നെ പോസ്റ്റ്-ഹാൻഡ്‌ഷേക്ക് പ്രവർത്തനങ്ങളും (സെഷൻ ടിക്കറ്റുകൾ, കീ അപ്‌ഡേറ്റുകൾ) നിരീക്ഷിക്കുക.

ഘട്ടം 4: മറ്റ് ഇംപ്ലിമെന്റേഷനുകളുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക

OpenSSL-ടു-OpenSSL ടെസ്റ്റുകളിൽ issue #33242 പ്രത്യക്ഷപ്പെടാത്തതിനാൽ, പാക്കറ്റ് നഷ്ടമുള്ള സാഹചര്യത്തിൽ OpenSSL അല്ലാത്ത ഒരു DTLS ക്ലയന്റെങ്കിലും നിങ്ങളുടെ സെർവറിലേക്ക് കണക്റ്റുചെയ്യുക.

ഘട്ടം 5: നിങ്ങളുടെ എറർ ഹാൻഡ്‌ലിംഗ് പരിശോധിക്കുക

നിങ്ങൾ DTLS ലിസണർ ഉപയോഗിക്കുകയാണെങ്കിൽ, നിങ്ങളുടെ കോഡ് ഇതിനോട് എങ്ങനെ പ്രതികരിക്കുന്നു എന്ന് അവലോകനം ചെയ്യുക: SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE ഒപ്പം SSL_ERROR_SYSCALL. ഒരിക്കലും വിജയിക്കാത്ത "try again" കാരണം ഒരു കണക്ഷൻ ശാശ്വതമായി കുടുങ്ങിപ്പോകാതിരിക്കാൻ ടൈംഔട്ടുകൾ ചേർക്കുക.

ഘട്ടം 6: ബെഞ്ച്മാർക്ക് ചെയ്യുകയും കൃത്യമായി വീണ്ടും ബിൽഡ് ചെയ്യുകയും ചെയ്യുക

നിങ്ങളുടെ യഥാർത്ഥ ഹാർഡ്‌വെയറിൽ യഥാർത്ഥ വർക്ക്ലോഡ് ബെഞ്ച്മാർക്ക് ചെയ്യുക. നിങ്ങളുടെ ബിൽഡ് പൈപ്പ്‌ലൈൻ വീണ്ടും റൺ ചെയ്യുകയും ഇതുപോലുള്ള ഓപ്ഷനുകൾ: no-ec നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന കോൺഫിഗറേഷൻ നൽകുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കുകയും ചെയ്യുക.

ഉപസംഹാരം

OpenSSL 4.1.0 അർത്ഥവത്തായ ഒരു ഫീച്ചർ റിലീസാണ്. DTLS 1.3, GREASE എന്നിവ ഡാറ്റാഗ്രാം സുരക്ഷയെയും ഭാവി അനുയോജ്യതയെയും ശക്തിപ്പെടുത്തുന്നു, കൂടാതെ പുതിയ ഒപ്റ്റിമൈസേഷനുകൾ പിന്തുണയ്ക്കുന്ന ഹാർഡ്‌വെയറുകളിൽ post-quantum, AES പ്രവർത്തനങ്ങളെ വേഗത്തിലാക്കിയേക്കാം. എന്നാൽ ഇത് സ്വീകരിക്കുക എന്നത് ഒരു പുതിയ ലൈബ്രറി ഉൾപ്പെടുത്തി ആപ്പ് ആരംഭിക്കുന്നത് കാണുന്നതിലും ഉപരിയാണ്. അറിയപ്പെടുന്ന നാല് DTLS പ്രശ്നങ്ങൾ നിങ്ങൾക്ക് വ്യക്തമായ ടെസ്റ്റ് കേസുകൾ നൽകുന്നു, സപ്പോർട്ട് കാലാവധി കുറവാണ്, കൂടാതെ ഇന്ററോപ്പറബിലിറ്റി, പരാജയ വീണ്ടെടുക്കൽ (failure-recovery), വർക്ക്ലോഡ് പരിശോധന എന്നിവയിൽ നിന്നാണ് യഥാർത്ഥ തെളിവ് ലഭിക്കുന്നത്.

മേന്മകൾ

• DTLS 1.3 UDP ട്രാഫിക്കിലേക്ക് TLS 1.3-തലത്തിലുള്ള സംരക്ഷണം എത്തിക്കുന്നു.
• ഭാവിയിലെ എക്സ്റ്റൻഷനുകൾ തകരാറിലാകുന്നതിന് മുൻപ് തന്നെ ദുർബലമായ പിയറുകളെ കണ്ടെത്താൻ GREASE സഹായിക്കുന്നു.
• പിന്തുണയുള്ള CPU-കളിൽ വേഗതയേറിയ ML-DSA, ML-KEM, AES-CBC കോഡ് പാതകൾ.
• കൂടുതൽ വ്യക്തമായ ബിൽഡ് ഓപ്ഷനുകൾ: തെറ്റിദ്ധരിപ്പിക്കുന്ന no-ecdsa കൂടാതെ no-ecdh ഫ്ലാഗുകൾ ഒഴിവാക്കി.
• അറിയപ്പെടുന്ന പ്രശ്നങ്ങൾ റീപ്രൊഡ്യൂസറുകൾ സഹിതം തുറന്നു രേഖപ്പെടുത്തിയിട്ടുണ്ട്.

പോരായ്മകൾ

• പിന്തുണ 2027 നവംബറിൽ അവസാനിക്കുന്നു, ഇത് 3.5 LTS-നേക്കാൾ വളരെ നേരത്തെയാണ്.
• അറിയപ്പെടുന്ന നാല് DTLS പ്രശ്നങ്ങൾ പുനഃസംപ്രേഷണം, എറർ റിപ്പോർട്ടിംഗ്, ഹാൻഡ്‌ഷെയ്ക്കുകൾ എന്നിവയെ ബാധിക്കുന്നു.
• രണ്ട് ലിസണർ പ്രശ്നങ്ങൾ DTLS 1.2 ഉപയോക്താക്കളെയും ബാധിക്കുന്നു.
• ബിൽഡ് മാറ്റങ്ങൾ നിലവിലുള്ള സ്ക്രിപ്റ്റുകളെയോ ടാർഗെറ്റുകളെയോ തകരാറിലാക്കിയേക്കാം.
• പ്രകടന മെച്ചപ്പെടുത്തലുകൾ നിർദ്ദിഷ്ട ഹാർഡ്‌വെയറിനെ ആശ്രയിച്ചിരിക്കുന്നു, മാത്രമല്ല അവ ആപ്ലിക്കേഷൻ തലത്തിലേക്ക് എത്തിയേക്കണമെന്നില്ല.

മുന്നറിയിപ്പ്

ഈ ലേഖനം വിദ്യാഭ്യാസ ആവശ്യങ്ങൾക്കുള്ളതാണ് ഒപ്പം പൊതുവായി വിവരിച്ചിട്ടുള്ള OpenSSL 4.1.0 റിലീസ് സംഗ്രഹിക്കുന്നു; ഇത് ഔദ്യോഗിക OpenSSL ഡോക്യുമെന്റേഷൻ അല്ല. നൽകിയിരിക്കുന്ന കമാൻഡുകൾ ഒരു ഐസൊലേറ്റഡ് ടെസ്റ്റ് മെഷീനുള്ള ഉദാഹരണങ്ങളാണ്, അവ നിങ്ങളുടെ സ്വന്തം എൻവയോൺമെന്റ്, ഇന്റർഫേസ് നാമങ്ങൾ, ടെസ്റ്റ് പ്രോഗ്രാമുകൾ എന്നിവയ്ക്കനുസരിച്ച് മാറ്റിയെടുക്കണം. പ്രശ്നങ്ങളുടെ വിശദാംശങ്ങളും സപ്പോർട്ട് തീയതികളും മാറിയേക്കാം, അതിനാൽ ഇതിനെ ആശ്രയിക്കുന്നതിന് മുൻപ് ഔദ്യോഗിക OpenSSL റിലീസ് കുറിപ്പുകൾ, ഇഷ്യൂ ട്രാക്കർ, നിങ്ങളുടെ വെണ്ടറുടെ അറിയിപ്പുകൾ എന്നിവയുമായി ഓരോ അവകാശവാദവും ഒത്തുനോക്കി സ്ഥിരീകരിക്കുക.

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

• OpenSSL 4.1.0-ൽ എന്തൊക്കെയാണ് പുതിയതായി ഉള്ളത്? — ഇത് DTLS 1.3, GREASE, ML-DSA, ML-KEM, AES-CBC ഒപ്റ്റിമൈസേഷനുകൾ, ഒരു IKEv2 കീ-ഡെറിവേഷൻ ഫംഗ്ഷൻ, കൂടാതെ നിരവധി ബിൽഡ് മാറ്റങ്ങൾ എന്നിവ ചേർക്കുന്നു.
• എന്താണ് DTLS 1.3? — RFC 9147-ൽ നിർവ്വചിച്ചിട്ടുള്ള TLS 1.3-ന്റെ ഡാറ്റാഗ്രാം പതിപ്പാണിത്, ഇത് UDP വഴിയുള്ള ട്രാഫിക് എൻക്രിപ്റ്റ് ചെയ്യുകയും സംരക്ഷിക്കുകയും ചെയ്യുന്നു.
• അറിയപ്പെടുന്ന നാല് DTLS പ്രശ്നങ്ങൾ സുരക്ഷാ വീഴ്ചകളാണോ (security vulnerabilities)? — പ്രഖ്യാപനത്തിൽ ഇവയെ ഗുരുതരമായ സുരക്ഷാ വീഴ്ചകളായല്ല, മറിച്ച് കണക്ഷന്റെ പ്രവർത്തനത്തെയും വിശ്വാസ്യതയെയും ബാധിക്കുന്ന പ്രശ്നങ്ങളായാണ് വിവരിച്ചിരിക്കുന്നത്, കൂടാതെ സജീവമായ ദുരുപയോഗങ്ങളൊന്നും റിപ്പോർട്ട് ചെയ്തിട്ടുമില്ല.
• അറിയപ്പെടുന്ന ഈ പ്രശ്നങ്ങൾ DTLS 1.2-നെ ബാധിക്കുമോ? — അതെ, രണ്ട് ലിസണർ എറർ റിപ്പോർട്ടിംഗ് പ്രശ്നങ്ങളും (#33277, #33278) DTLS 1.3-ൽ മാത്രം ഒതുങ്ങുന്നതല്ല.
• TLS-ൽ GREASE എന്താണ് ചെയ്യുന്നത്? — അജ്ഞാതമായ എക്സ്റ്റൻഷനുകളെ തെറ്റായി നിരസിക്കുന്ന പിയറുകളെ തുടക്കത്തിലേ കണ്ടെത്താനായി ഇത് റിസർവ് ചെയ്ത റാൻഡം മൂല്യങ്ങൾ അയയ്ക്കുന്നു, ഇത് പ്രോട്ടോക്കോളിന്റെ വിപുലീകരണ ശേഷി നിലനിർത്തുന്നു.
• OpenSSL 4.1-ന് എത്ര കാലം പിന്തുണ ലഭിക്കും? — അപ്‌സ്ട്രീം പിന്തുണ 2027 നവംബർ വരെ മാത്രമേ ഉള്ളൂ, അതേസമയം OpenSSL 3.5 LTS-ന് 2030 ഏപ്രിൽ 8 വരെ പിന്തുണയുണ്ട്.
• ഞാൻ OpenSSL 3.5 LTS-ൽ നിന്ന് 4.1-ലേക്ക് അപ്‌ഗ്രേഡ് ചെയ്യണമോ? — നിങ്ങൾക്ക് ഇതിന്റെ പുതിയ ഫീച്ചറുകൾ ആവശ്യമുണ്ടെങ്കിൽ, അവ കൃത്യമായി പരിശോധിക്കാൻ സാധിക്കുമെങ്കിൽ മാത്രം; അല്ലാത്തപക്ഷം 3.5 LTS വളരെ നീണ്ട സപ്പോർട്ട് കാലാവധി നൽകുന്നു.
• ഒരു OpenSSL ബിൽഡിൽ എലിപ്റ്റിക്-കർവ് പിന്തുണ എങ്ങനെ പ്രവർത്തനരഹിതമാക്കാം? — ഇത് ഉപയോഗിക്കുക: no-ec ഓപ്ഷൻ; നീക്കംചെയ്‌ത no-ecdsa കൂടാതെ no-ecdh ഓപ്ഷനുകൾ യഥാർത്ഥത്തിൽ ആ ഇംപ്ലിമെന്റേഷനുകളെ ഒരിക്കലും പ്രവർത്തനരഹിതമാക്കിയിരുന്നില്ല.

ടാഗുകൾ

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