CVE-2026-2673

Sorun özeti: Bir OpenSSL TLS 1.3 sunucusu, anahtar değişim grubu yapılandırması 'DEFAULT' anahtar sözcüğünü kullanarak varsayılanı içerdiğinde, beklenen tercih edilen anahtar değişim grubunu müzakere edemeyebilir. Etki özeti: Daha az tercih edilen bir anahtar değişim grubu, daha tercih edilen bir grup hem istemci hem de sunucu tarafından desteklense bile, bu grup istemcinin ilk öngörülen keyshare'ları arasında yer almıyorsa kullanılabilir. Bu durum, istemci kullanımlarını sunucu tarafından özellikle talep edilene kadar ertelemeyi seçerse, yeni hibrit kuantum sonrası gruplarda bazen söz konusu olacaktır. Bir OpenSSL TLS 1.3 sunucusunun yapılandırması, yerleşik varsayılan grup listesini kendi yapılandırmasına eklemek için 'DEFAULT' anahtar sözcüğünü kullanıyorsa, belki belirli öğeler ekleyerek veya kaldırarak, bir uygulama kusuru 'DEFAULT' listesinin 'tuple' yapısını kaybetmesine neden olur ve sunucu tarafından desteklenen tüm gruplar tek bir yeterince güvenli 'tuple' olarak ele alınır; sunucu, daha tercih edilen bir tuple'daki bir grup karşılıklı olarak desteklense bile bir Hello Retry Request (HRR) göndermez. Sonuç olarak, istemcinin yapılandırması yalnızca 'klasik' gruplarla sonuçlanırsa (örneğin istemcinin ilk keyshare tahmininde yalnızca 'X25519' bulunuyorsa), istemci ve sunucu 'X25519MLKEM768' gibi karşılıklı olarak desteklenen bir kuantum sonrası anahtar anlaşma grubunu müzakere edemeyebilir. OpenSSL 3.5 ve sonrası, TLS sunucularında en tercih edilen TLS 1.3 anahtar anlaşma grubunu seçmek için yeni bir sözdizimini destekler. Eski sözdiziminde tek bir 'düz' grup listesi vardı ve desteklenen tüm gruplar yeterince güvenli olarak ele alınıyordu. İstemci tarafından öngörülen keyshare'lardan herhangi biri sunucu tarafından destekleniyorsa, bunlar arasında en tercih edileni seçiliyordu; istemci tarafından desteklenen ancak öngörülen keyshare'lar listesinde yer almayan diğer gruplar dahil edilseydi daha tercih edilebilir olsa bile. Yeni sözdizimi, grupları kabaca eşdeğer güvenlikteki ayrı 'tuple'lara böler. Her tuple içinde, istemcinin öngörülen keyshare'ları arasında yer alan en tercih edilen grup seçilir; ancak istemci daha tercih edilen bir tuple'dan bir grubu destekliyor ancak buna karşılık gelen hiçbir keyshare öngörmemişse, sunucu istemciden ClientHello'yu en tercih edilen karşılıklı olarak desteklenen grupla yeniden denemesini ister (bir Hello Retry Request veya HRR düzenleyerek). Yukarıdakiler, sunucunun yapılandırması yerleşik varsayılan grup listesini kullandığında veya çeşitli istenen grupları ve grup 'tuple'larını doğrudan tanımlayarak kendi listesini açıkça tanımladığında beklendiği gibi çalışır. Hiçbir OpenSSL FIPS modülü bu sorundan etkilenmez; söz konusu kod FIPS sınırının dışında yer alır. OpenSSL 3.6 ve 3.5 bu soruna karşı savunmasızdır. OpenSSL 3.6 kullanıcıları, yayımlandığında OpenSSL 3.6.2'ye yükseltmelidir. OpenSSL 3.5 kullanıcıları, yayımlandığında OpenSSL 3.5.6'ya yükseltmelidir. OpenSSL 3.4, 3.3, 3.0, 1.0.2 ve 1.1.1 bu sorundan etkilenmez.