AES-256 neden bir VPN şifreleme paketini tanımlamaz
Bir paket dört rolü yerine getirir: toplu şifreleme, bütünlük, anahtar kurulumu ve karşı tarafın kimlik doğrulaması. Bir şifre adı bunlardan yalnızca birini, tek bir katmanda kapsar.
Bir VPN hangi şifrelemeyi kullanıyor diye sorun, yanıt genellikle tek bir kelimeyle gelir: AES-256, ya da ChaCha20, ya da belki WireGuard. Bu yanıt tek bir katmanın tek bir bileşenini adlandırır, oysa bağlantıyı gerçekte koruyan şey dört farklı rolü yerine getiren bir algoritma kümesidir. Bileşeni düzenle karıştırmak bu konuşmalardaki en yaygın hatadır ve çözülemeyen karşılaştırmalar üretir.
Tek bir bağlantı içinde dört iş
Toplu şifreleme, veri kanalı için açık metni şifreli metne çevirir ve anahtarı iletilmek yerine türetilir. Bütünlük koruması değişikliği saptar; tek bir yapı ikisini birden yapsa bile bu ayrı bir iştir. Anahtar kurulumu ortak trafik malzemesini üretir ve karşı tarafın kimlik doğrulaması diğer uçta kimin olduğuna karar verir. Bunlardan biri eksikse bağlantı güvenli değildir, kalan parça ne kadar güçlü olursa olsun.
Bazı tasarımlar iki rolü birleştirir. AES-GCM ve ChaCha20-Poly1305 kimliği doğrulanmış şifreleme yapılarıdır, bu yüzden gizlilik ve bütünlük birlikte gelir; AES-CBC öyle değildir ve kendi anahtarına sahip ayrı bir ileti kimlik doğrulama kodu gerektirir. Bu yüzden bir öneriyi bağımsız sayılar torbası olarak okumak, çift olarak tasarlanmış olanları yanlış okur.
Roller farklı katmanlarda da bulunur, bu yüzden aynı sözcük iki üründe farklı anlamlara gelebilir. ESP içindeki blok şifre ile TLS içindeki blok şifre, farklı gereksinimleri olan farklı müzakerelerde aynı ilkel öğedir. Bu yüzden bir ilkel öğeyi kipi ve katmanı olmadan anmak hiçbir şey anmamaktan daha kötü olabilir.
Bir şifre adı neden neredeyse hiçbir şey söylemez
AES-256 ifadesini bir an ciddiye alın: bir blok şifre ve bir anahtar boyutu belirtir. Çalışma kipi, bütünlük sağlanıp sağlanmadığı, anahtarların nasıl kurulduğu veya karşı tarafın nasıl doğrulandığı hakkında hiçbir şey söylemez. İki ürün de AES-256 reklamı yapıp geri kalan her şeyde farklı olabilir; biri onu kimliği doğrulanmamış bir kiple eşleştirirken diğeri modern anahtar değişimiyle AEAD kipi kullanır.
TLS 1.3 bu ayrımı standarda taşıdı; bu, eski sözlüğü öğrenen herkes için yararlı bir düzeltmedir. Şifre paketleri yalnızca AEAD ve hash adını verir, anahtar değişim grupları ve imza algoritmaları ise ayrı parametreler olarak müzakere edilir. Bu yüzden bir TLS 1.3 paket adı, bir TLS 1.2 paket adıyla eşit koşullarda karşılaştırılamaz, ikisi de bir yapılandırma dosyasının aynı alanında görünse bile. İki dizgiyi doğrudan karşılaştıran denetçi, protokolün desteklemediği bir sonuca varır. Görüşülen grubu ve imza parametrelerini de okuyun, yoksa karşılaştırma eksik kalır.
WireGuard karşıt yolu seçer ve müzakereyi neredeyse tamamen kaldırır: protokol sabit bir algoritma kümesi belirler, bu yüzden iki uygulama ya birlikte çalışır ya çalışmaz. Bu meşru bir tasarım seçimidir ve WireGuard ın hangi paketi müzakere ettiği sorusunun karşılaştırmaya değer bir yanıtı olmadığı anlamına da gelir. Denetliyorsanız, belirtimi bir kez okuyun ve ardından müzakere yerine çevresindeki anahtar yönetimini denetleyin.
Sözlüğü katman belirler
Bir IPsec kurulumu iki kez müzakere eder: denetim kanalı için bir IKE önerisi ve veri için bir ESP dönüşümü, ve ikisi meşru olarak farklı olabilir. İlkini okuyup ikincisini tanımladığını varsaymak denetim sırasında yaygın bir karışıklık kaynağıdır, çünkü yapılandırma dosyası ikisinden de söz eder ve ilginç olan ikincisidir.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
Bir kitaplıkta bulunan bir ad, başka bir veri yolu için otomatik olarak uygulanmaz. Bu yüzden ürünümüzün AES-256 yı desteklediği iddiası kulağa geldiğinden zayıftır ve bu yüzden birlikte çalışabilirlik sorunu genellikle her iki tarafta tüm eski algoritmaları etkinleştirmek yerine sürdürülen kesişimi bulmakla çözülür.
TLS 1.3 belirtimi bu ayrımın yayımlanmış en açık örneğidir, çünkü paketi bir çift olarak tanımlar ve geri kalanı kendi müzakere sürecine taşır. Bu biçim tanıdık hale geldiğinde, IPsec önerisi ve WireGuard ın tek sabit kümesi aynı fikrin varyantları olarak okunur.
Müzakere edilen sonucu okuyun, sonra durun
Yapılandırılmış bir öneri iki tarafın ne seçtiğinin kanıtı değildir. Canlı oturum yanıtı taşır ve her yaygın uygulama bunu paket yakalamadan bildirebilir.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showÇıktıda sunulan listeyi değil seçilen algoritmaları okuyun. Yanıt politikanın amaçladığından zayıfsa düzeltme bir taraftaki öneri yapılandırmasındadır ve modern uygulamalarda uyumsuzluk genellikle sessiz bir düşürme değil başarısız bir müzakere olarak görünür.
Sonra paketin neyi kapsamadığını hatırlayın. Yollar, uygulama izinleri, günlükleme ve saklama kendi incelemesi olan ayrı kararlardır ve uyumlu bir kriptografik düzenleme bunlar hakkında hiçbir şey söylemez. Şifre tartışması buna değer, ancak çoğu insanın gerçekte sorduğundan daha dar bir soruyu yanıtlar.
Sözlüğü kesin tutun ve sav kısalır. Paket bir katmandaki roller kümesidir, şifre tek bir bileşendir ve müzakere edilen sonuç gerçekte sahip olduğunuz bağlantıyı tanımlayan tek şeydir. Karşılaştırmadaki geri kalan her şey süslemedir.