OpenVPN tls-ciphersuites ile tls-version-min: her biri neyi zorunlu kılar

Çoğu OpenVPN TLS tartışmasında üç farklı gerçek tek satıra sıkıştırılır: istemci derlemenizin ne yapabildiği, profilin neye izin verdiği ve oturumun gerçekte neyi müzakere ettiği. Kısa bir TLS 1.3 paket listesi ortadaki soruyu yalnızca yarım yanıtlar ve protokol sürümünün alt sınırı hakkında hiçbir şey söylemez. Aşağıdaki kontrolleri sırayla yapın ve ilk tutmayanda durun, çünkü sonraki her kontrol öncekilerin çözüldüğünü varsayar.

Herhangi bir listeyi okumadan önce derlemeyi kontrol edin

Bir yapılandırma yönergesi, protokol desteği olmayan bir ikili dosyaya bunu ekleyemez. Derlenen kripto kitaplığını adlandıran sürüm başlığıyla başlayın:

openvpn --version

OpenSSL'e bağlı 2.6 derlemesi hem tls-cipher hem de tls-ciphersuites değerini kabul eder. mbed TLS ile derlemede TLS 1.3 paket seçimi hiç yoktur ve 2.6 kılavuzu tls-ciphersuites değerini OpenSSL seçeneği olarak işaretler. Sunucu başka bir arka uçla yeniden derlenirse aynı profil, tek bir yapılandırma satırı değişmeden davranışını değiştirebilir.

Burada bulunduğunuz sürece openvpn --show-tls komutunu çalıştırın ve çıktıyı saklayın. Daha sonra karşılaştıracağınız envanter odur ve biri profilleri düzenlemeye başlamadan önce onu yakalamak ucuzdur.

Başlığı ve listeyi sohbet penceresine değil, değişiklik biletine yazın. İki kişi bir istemcinin altı hafta sonra bir paket sunup sunamayacağını tartıştığında, yakalanan çıktı bunu tek satırda çözer.

Sürüm sınırlarını şifre listelerinden ayrı tutun

2.6 kılavuzunda bunlar bir değil, üç denetimdir:

• tls-cipher TLS 1.2 ve daha eski sürümler için şifre politikasını belirler ve OpenSSL'in şifre listesine aktarılır;
• tls-ciphersuites TLS 1.3 paketlerini seçer;
• tls-version-min ve tls-version-max bağlantının kullanabileceği protokol sürümlerini sınırlar.

Bu nedenle özenle budanmış bir TLS 1.3 paket listesi, eski bir sürümün hâlâ izinli olduğunu kanıtlamaz. Gereksinim «yalnızca TLS 1.3» ise bunu sürüm alt sınırı taşır ve paket listesi yalnızca o sınır içindeki seçenekleri daraltır:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Bu çift iki iş yapar. Satırlardan birini silmek diğerini düşündüğünüzden daha az zorunlu kılar ve tüm bu kontrolün var olma nedeni tam olarak bu arızadır.

Veri kanalı dördüncü denetimdir. data-ciphers tünelin içindeki simetrik şifreyi müzakere eder ve sonucu denetim kanalının TLS sürümü hakkında hiçbir şey söylemez. Oturum özetinde AES-256-GCM görmek hiçbir yönde TLS 1.3 kanıtı değildir.

show-tls çıktısını yerel bir envanter olarak okuyun

--show-tls bu ikili dosyanın bağlı olduğu kripto kitaplığının desteklediği paketleri tercih sırasına göre listeler. Bu, ağ geçidinden gelen bir rapor değildir. Kılavuz listenin yerel kitaplıktan geldiğini açıkça söyler; yani OpenSSL 3.x'li bir dizüstü ile daha eski derlemeli bir yönlendirici aynı sunucuyla konuşurken farklı listeler yazdırır.

İstemcinin A, B ve C paketlerini desteklediğini ve bir oturumun B'yi seçtiğini varsayalım. Bu, sunucunun A veya C'ye izin verip vermediğini ya da B'nin tek izinli seçenek olup olmadığını kanıtlamaz. Üç satırı ayrı tutun; kafa karıştıran TLS başlıklarının çoğu kendiliğinden çözülür.

Envanteri saklamak yine de değerlidir. Bir oturum başarısız olduğunda, kitaplık listesiyle profil listesini karşılaştırmak istemcinin sunucunun istediğini sunma şansı olup olmadığını gösterir. Ayrıca bir arka uç değişikliğinin eski istemcilerin güvendiği havuzdan TLS_CHACHA20_POLY1305_SHA256 değerini sessizce çıkarıp çıkarmadığını da gösterir — herkesin hiçbir şey fark etmediği sırada birkaç kullanıcının bağlanamaması olarak görünen türden bir gerileme.

Ağ geçidine yanıtlayabileceği bir soru sorun

Hizmeti siz yönetiyorsanız, diskteki bir dosya yerine çalışan örneğin etkin yapılandırmasını inceleyin. OpenVPN başka bir --config yoluyla başlatılmış, include çekiyor veya düzenlemeden sonra yeniden başlatılmamış olabilir. İstemcilerin karşılaştığı şey, çalışan daemonun politikasıdır.

Hizmeti siz yönetmiyorsanız, operatörden desteklenen istemci gereksinimlerini veya kapsamı belirli bir kabul testini isteyin. Reddedilen bir deneme otomatik olarak reddedilmiş bir paket değildir: sürüm alt sınırı, remote-cert-tls gibi sertifika kimlik denetimleri veya tls-auth ile tls-crypt arasındaki uyumsuzluk, paket seçimi önemli hale gelmeden önce alışverişi bitirebilir. İstemci listesini değiştirmeden önce sunucunun hatasını okuyun, çünkü «handshake failed» dört farklı nedeni kapsar ve bunlardan yalnızca biri şifre uyumsuzluğudur.

openssl s_client komutunu VPN portuna yöneltmek de soruyu yeniden üretmez. Denetim kanalı OpenVPN'in kendi çerçevelemesi içinde çalışır, bu nedenle ham bir TLS sondası başka bir şey bekleyen bir portta farklı bir protokolü test eder. Ondan çıkarılan her sonuç sonda hakkındadır, tünel hakkında değil.

İki sonucu kaydedin ve ayrı tutun

Yeni izin verilen bir oturum, protokol sürümünü ve seçilen şifreyi adlandıran bir denetim kanalı satırı ile tünel şifresini adlandıran ayrı bir veri kanalı satırı üretir. İkisini de istemci sürümü ve profil adıyla birlikte yakalayın ve hangi sunucu örneğinin yanıt verdiğini not edin:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

Sonra bu iki satırı bellekten değil, o dosyadan okuyun. Kanıt olan çifttir; tek başına paket adı bir tercihtir ve sürüm sınırı sunucunun neyi reddettiğine dair ayrı bir ifadedir.

Kontrolleri bu sırayla yapın. Derlemeyi ve arka ucu --version ile doğrulayın. Herhangi bir şeyi değiştirmeden önce --show-tls çıktısını yakalayın. Gerekli sürüm alt sınırını paket listesinden ayrı belirtin. Çalışan örneğin etkin politikasını sahibiyle doğrulayın. İzin verilen bir oturumu ve plan izin veriyorsa eski sürümle reddedilen bir denemeyi gözlemleyin. Denetim kanalı ve veri kanalı sonuçlarını ayrı bulgular olarak kaydedin.

Gerekli bir istemci yeni bir alt sınırı karşılayamıyorsa, dağıtım bitmiş görünsün diye ilgisiz bir kabul kuralını sessizce düşürmek yerine o geçiş veya istisna kararını açıkça verin.