OpenVPN’de EC ve ED: Adlar Neden Bir Güç Merdiveni Değildir
EC, ED, ECDHE ve auth farklı soruları yanıtlar. Herhangi bir karşılaştırma veya düzenlemeden önce bir OpenVPN profilini adların üstlendiği işe göre sıralayın.
Bir profile ec, ed, ecdh, ecdsa, auth ve bir TLS şifre paketi listesini yan yana koyun; dosya altı kademeli bir güç kadranı gibi görünmeye başlar. Değildir. Her ad farklı bir soruyu yanıtlar ve yalnızca birinde farklılaşan iki profil mutlaka birbirinden güçlü ya da zayıf değildir. Adları yaptıkları işe göre sıralamak yaklaşık beş dakika sürer ve insanların çalışan bir yapılandırmada yaptığı hatalı düzenlemelerin çoğunu önler.
Aşağıdaki sıralama kafa karışıklığının kendisinden başlar, sonra bir profilin trafiğinizi gerçekte neyin koruduğuna karar veren kısımlarına doğru dışarı açılır. Her bölüm sırayla bir yanlış okumayı ele alır ve adın gerçekte neye bağlı olduğunu gösterir.
İki harf, iki farklı soru
En çok tartışmaya yol açan ikili EC ile ED’dir ve tartışma genellikle bunların tek bir soruya verilen rakip yanıtlar olduğunu varsayar. Hatta aynı eksende bile değildirler. EC bir matematik ailesini tanımlar: eliptik eğri kriptografisi; burada güvenlik büyük bir sonlu cisimde değil, bir eğri üzerinde ayrık logaritmanın zorluğundan gelir.
ED bu ailenin içindeki bir eğri biçimini tanımlar. Burulmuş Edwards eğrileri hız ve birkaç uygulama hatasına karşı dayanıklılık için seçilmiş bir gösterimdir ve insanların genellikle kastettiği ad Ed25519’dur. Eğri eliptik eğri kriptografisinin rakibi değildir; bir eliptik eğriyi yazmanın yollarından biridir. ED’yi “daha yeni, daha güçlü EC” diye okumak ilk yanlış dönemeçtir ve sonrasındaki her şey genellikle aynı yönde yanlış gider.
İmzalama ve anahtar değişimi ayrı işlerdir
Aile sorusu netleştiğinde geri kalan adlar birbirinin yerine asla geçmeyen iki sütuna ayrılır. Bir sütun imzalar, diğeri ortak bir sır üzerinde anlaşır.
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
EdDSA ile ECDSA ikisi de imzalar, ancak farklı anahtar biçimlerine sahip farklı şemalardır; bu yüzden birine düzenlenmiş bir sertifika diğeri olarak kullanılamaz. EdDSA küçük bir eğri kümesi için tanımlıdır; P-256 bunlardan biri değildir, bu yüzden bir P-256 sertifikası ECDSA ile doğrulanır ve asla Ed25519 ile doğrulanmaz.
Değişim sütununun EdDH diye bir karşılığı yoktur. Curve25519 anahtarı üzerinde geçici anlaşma X25519’dur ve bu, tıpkı P-256’da olduğu gibi, belirli bir eğriye sahip ECDH’dir. Ed25519 kesin olarak imza şemasını anlatır; bununla birlikte iki eğri ilişkili olduğu için ad değişim için de gevşek biçimde kullanılır: imzalamada kullanılan Edwards biçimi ile X25519 için kullanılan Montgomery biçimi aynı alt grubu tanımlar.
Bir EC profilinde neden dh dosyası yoktur
Bir dh dosyası sonlu cisim Diffie-Hellman için önceden üretilmiş parametreler içerir ve bu parametreler büyük bir asal ile bir üreticinin bir yerden gelmesi gerektiği için vardır. Eliptik eğri değişimi bunlara ihtiyaç duymaz: adlandırılmış eğri parametre kümesinin kendisidir ve iki taraf da onu zaten bilir. Bir EC profilinin bu yönergeyi atlayabilmesinin tek nedeni budur.
Modern görünen bir profilde hâlâ dh satırını üreten iki durum vardır. Birincisi gerçekten sonlu cisim grupları üzerinde anlaşan ikinci bir dinleyici ya da daha eski bir eştir. İkincisi RSA dönemi bir şablondan kopyalanıp hiç silinmemiş artık metindir. Değişim için bir eğri adlandırıp yine de 2048 bitlik bir dh dosyası yükleyen bir profil bunu yaptığı için daha güvenli olmaz; kullanılmayan bir kalıntıyı taşır.
TLS 1.3 anahtar değişimini addan çıkardı
TLS_AES_256_GCM_SHA384 ile TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 karşılaştırıldığında kısa ad bir düşüş gibi görünür. Bu bir yeniden adlandırmadır ve nedeni yapısaldır: TLS 1.3 statik RSA ile sonlu cisim Diffie-Hellman anahtar değişimini kaldırdı, bu yüzden geçici eliptik eğri değişimi geriye kalan tek PSK dışı seçenektir. Her pakette bunu adlandırmak aynı olguyu bir düzine kez tekrarlamak olurdu.
Sertifika tipi addan benzer bir nedenle kayboldu. 1.3’te sertifika anahtar anlaşmasını değil el sıkışma imzasını doğrular, dolayısıyla artık paketi seçmez. Yapılandırmada 1.3 için ayrı bir şifre listesinin bulunmasının nedeni de budur: paketler yeniden adlandırıldı ve yeniden düzenlendi, zayıflatılmadı.
Bir sonucu açıkça söylemek gerekir. ECDHE bir anahtar değişimi algoritmasıdır ve asla bir şifre değildir. “Eliptik” diye tanımlanan bir paket, iki eşin ortak bir anahtara nasıl vardığı hakkında bir şey söyler; yükü neyin şifrelediği hakkında ise hiçbir şey söylemez.
auth paketleri doğrular, yükleri değil
auth yönergesi paketleri doğrulayan HMAC özetini seçer ve tarihsel varsayılanı SHA1’dir. AEAD olmayan bir veri şifresiyle OpenVPN özeti şifreli metin üzerinde hesaplar ve sonuna ekler; dolgu manipülasyonunu pratiksiz kılan şey bu şifrele-sonra-MAC düzenidir.
Buradaki efsane, auth değerini SHA512’ye çıkarmanın tüneli sertleştirdiğidir. Bu, şifrelemenin gücünü artırmaz ve anlaşılan veri şifresi AES-256-GCM gibi bir AEAD kipiyse özet veri paketlerine hiç uygulanmaz. GCM etiketi onları zaten doğrular ve auth değeri kontrol kanalı HMAC’ine ve hâlâ kullanımda olan AEAD dışı şifrelere ayrılmıştır.
Yani yönerge önemlidir, ama dosyadaki konumunun ima ettiğinden daha dar bir yerde önemlidir. Gerçekte hangi şifrenin anlaşıldığını kontrol etmek, onun hiç uygulanıp uygulanmadığını söyler.
Profili sıraya göre değil sütuna göre okuyun
Üç soru katmanları temiz biçimde ayırır ve her biri anlaşılan oturumun farklı bir parçası tarafından yanıtlanır. Yükü hangi şifre korur? Her paket için hangi etiket ya da özet kefil olur ve kullanılan şifre buna gerçekten ihtiyaç duyar mı? El sıkışmayı kimin sertifikası kapattı ve kontrol kanalı ayrıca tls-auth ya da tls-crypt ile korunuyor mu?
EC ya da ED etiketinde hiçbir şey bu üçünden hiçbirini belirlemez ve tek başına bir paket adı da hiçbirini belirlemez. Anlaşılan sonuç tek kanıttır, öyleyse gücü sözcük dağarcığından çıkarmak yerine onu okuyun:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logİlk komut sertifikanızın gerçekte hangi imza şemasını kullandığını söyler ve ECDSA mı yoksa Ed25519 mu çalıştırdığınızı bilmenin tek güvenilir yolu budur. İkincisi istemcinin oturum için günlüğe yazdığı kontrol kanalı satırını, TLS sürümü ve üzerinde anlaşılan paket dâhil gösterir. Bir profil düzenlemesi bu iki çıktıdan biriyle gerekçelendirilemiyorsa, o büyük olasılıkla bir özellikte değil bir adda yapılan değişikliktir.