CVE-2026-2673

Problemin xülasəsi: OpenSSL TLS 1.3 serveri, açar mübadiləsi qrupu konfiqurasiyasında 'DEFAULT' açar sözündən istifadə etdikdə, gözlənilən üstünlük verilmiş açar mübadiləsi qrupunu razılaşdıra bilməyə bilər. Təsirin xülasəsi: Həm klient, həm də server tərəfindən daha çox üstünlük verilən qrup dəstəkləndiyi halda belə, əgər həmin qrup klientin ilkin proqnozlaşdırılan keyshare-ləri arasında daxil edilməyibsə, daha az üstünlük verilən açar mübadiləsindən istifadə oluna bilər. Bu, yeni hibrid post-kvant qrupları ilə bağlı bəzi hallarda baş verə bilər, əgər klient onların istifadəsini server tərəfindən xüsusi tələb olunana qədər təxirə salmağı seçərsə. Əgər OpenSSL TLS 1.3 serverinin konfiqurasiyası daxili standart qrup siyahısını öz konfiqurasiyasına inteqrasiya etmək üçün 'DEFAULT' açar sözündən istifadə edirsə (məsələn, konkret elementlər əlavə etməklə və ya silməklə), tətbiq defekti səbəbindən 'DEFAULT' siyahısı öz 'tuple' strukturunu itirir və serverin dəstəklədiyi bütün qruplar tək bir kifayət qədər təhlükəsiz 'tuple' kimi qəbul edilir. Nəticədə, daha üstünlük verilən tuple-dakı qrup qarşılıqlı dəstəkləndiyi halda belə, server Hello Retry Request (HRR) göndərmir. Nəticə etibarilə, əgər klientin konfiqurasiyası yalnız 'klassik' qrupların (məsələn, klientin ilkin keyshare proqnozunda yalnız 'X25519'-un olması) seçilməsinə səbəb olursa, klient və server 'X25519MLKEM768' kimi qarşılıqlı dəstəklənən post-kvant açar razılaşdırma qrupunu razılaşdıra bilməyə bilərlər. OpenSSL 3.5 və daha yeni versiyalar TLS serverlərində ən üstünlük verilən TLS 1.3 açar razılaşdırma qrupunu seçmək üçün yeni sintaksisi dəstəkləyir. Köhnə sintaksis qrupların tək bir 'yastı' (flat) siyahısına malik idi və bütün dəstəklənən qrupları kifayət qədər təhlükəsiz hesab edirdi. Klient tərəfindən proqnozlaşdırılan keyshare-lərdən hər hansı biri server tərəfindən dəstəklənirdisə, bunlar arasından ən üstün olanı seçilirdi; hətta klient tərəfindən dəstəklənən lakin proqnozlaşdırılan keyshare-lər siyahısına daxil edilməyən digər qruplar daha üstün ola bildiyi halda belə. Yeni sintaksis qrupları təxminən eyni təhlükəsizlik səviyyəli ayrı-ayrı 'tuple'-lara bölür. Hər bir tuple daxilində klientin proqnozlaşdırılan keyshare-ləri arasında olan ən üstün qrup seçilir, lakin klient daha üstün bir tuple-dan qrupu dəstəkləyib, buna uyğun heç bir keyshare proqnozlaşdırmayıbsa, server klientdən ən üstün qarşılıqlı dəstəklənən qrup ilə ClientHello-nu yenidən cəhd etməyi (Hello Retry Request və ya HRR vasitəsilə) xahiş edir. Yuxarıda qeyd olunanlar, serverin konfiqurasiyası daxili standart qrup siyahısından istifadə etdikdə və ya müxtəlif arzulanan qrupları və qrup 'tuple'-larını birbaşa təyin etməklə öz siyahısını açıq şəkildə müəyyən etdikdə gözlənilən kimi işləyir. Heç bir OpenSSL FIPS modulu bu problemdən təsirlənməyib, söhbət gedən kod FIPS sərhədinin xaricində yerləşir. OpenSSL 3.6 və 3.5 versiyaları bu problemə qarşı həssasdır. OpenSSL 3.6 istifadəçiləri buraxıldığına görə OpenSSL 3.6.2 versiyasına yüksəltmə etməlidirlər. OpenSSL 3.5 istifadəçiləri buraxıldığına görə OpenSSL 3.5.6 versiyasına yüksəltmə etməlidirlər. OpenSSL 3.4, 3.3, 3.0, 1.0.2 və 1.1.1 versiyaları bu problemdən təsirlənməyib.