OpenVPN denetim paketlerini izleme: TLS'ten önce tls-auth

tls-auth hatası genellikle el sıkışma sorunu olarak bildirilir, oysa hiç öyle olmamıştır. HMAC, herhangi bir TLS işlemesi başlamadan önce denetim paketinde denetlenir, bu nedenle uyuşmayan bir anahtar veya yön, sertifika sorununa benzeyen ve iki katman önce karara bağlanan bir hata üretir. Zarfı kendi başına bir nesne olarak ele almak tanıyı kısaltır: alanları okuyun, denetimin erken çalıştığını doğrulayın, sonra her iki ucun anlaşması gereken üç şeyi karşılaştırın.

Zarfı kurulduğu sırayla okuyun

Denetim paketi bir oturum tanımlayıcısı, isteğe bağlı tls-auth HMAC'i, yineleme ve onay bilgisi ve güvenilir bir mesaj tanımlayıcısı taşır, ardından mesaj türü yükü gelir. Mesaj bir el sıkışma mesajıysa, yük TLS şifreli metnidir. Bütün ilişki bundan ibarettir: TLS malzemesi zarfın zaten koruduğu bir mesajın içinde yolculuk eder. Bakın OpenVPN ağ protokolü başvurusu denetim kanalı alanlarını bu sırayla listeler.

Güvenilirlik katmanı kriptografiyle karıştırılması kolaydır. Onaylar, yeniden gönderim ve mesaj tanımlayıcısı, denetim mesajlarının güvenilmez bir taşıma üzerinde bir kez ve sırayla ulaşması için vardır. Bunlar kimlik doğrulama değildir ve doğru bir mesaj tanımlayıcısı paketi kimin gönderdiğine dair hiçbir şey kanıtlamaz.

Bu gruplamayı kavramsal tutun. Bayt sırası diyagramı değildir ve etiket hesaplamak için yeterli değildir, çünkü HMAC'e giren alanlar uygulamaya, sürüme ve kipe bağlıdır.

Denetimin el sıkışmadan önce çalıştığını gösterin

Paylaşılan anahtarı elinde tutan bir alıcı, el sıkışma durumu ayırmadan veya açık anahtar işi yapmadan HMAC'i doğrulayabilir ve sahte bir paketi hemen atabilir. Koruma ilk el sıkışma paketlerini de kapsar, bu yüzden yanlış anahtar geç bir kimlik doğrulama hatası olarak değil, başarısız bağlantı olarak görünür.

Daemon'un ayrıntı düzeyini artırın ve tun aygıtı yerine denetim kanalını izleyin:

openvpn --config /etc/openvpn/server.conf --verb 6

Aradığınız şey, herhangi bir TLS uyarısından önce paket düzeyinde bildirilen denetim kanalı HMAC doğrulama hatasıdır. Günlükteki bir TLS uyarısı, zarfın kabul edildiği ve hatanın içeri doğru kaydığı anlamına gelir; bu, farklı bir çözümü olan farklı bir incelemedir.

Yön işleme de burada yer alır. Statik bir anahtar dosyası tls-auth ile kullanıldığında, iki uç zıt anahtar yönleri alır ve protokol bu bölünmeyi, yakalanan bir paketin göndericisine geri yansıtılamaması için kullanır. Yönü ters çevirmek anahtarı aynı bırakır ve yine de her paket başarısız olur. Bir seferde bir ucu değiştirin, sonra çiftin birlikte yüklenmesi için iki daemonu da yeniden başlatın.

İki uçta anahtarı, yönü ve digest'i eşleştirin

Üç değer anlaşmalı ve yalnızca biri dosyadır. Statik anahtarın içeriği iki uçta aynı olmalı, yön ters olmalı ve HMAC için kullanılan digest eşleşmelidir. Anahtar malzemesine dokunmadan önce yapılandırmayı denetleyin, çünkü tek bir ters yön, bozuk bir dosyadan daha çok hatayı açıklar:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Paylaşılan sırrı düzenleyici yerine araçla üretin ve izinleri dar tutun:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Eski sürümler anahtar üretimi için biraz farklı bir seçenek sırası kabul ediyordu ve o sürümler için yazılmış profiller hâlâ dolaşımda. Üretilen dosya her iki durumda da aynı tür nesnedir, bu nedenle denetim, iki ucun aynı baytları tutup tutmadığıdır, onları hangi yazımın ürettiği değil.

tls-auth ile tls-crypt'i karıştırmayın. İkisi de denetim kanalını korur, ancak tls-crypt onu ayrıca şifreler ve el sıkışmayı gözlemcilerden saklar, ve yön bölünmesini kendi anahtar işleyişiyle değiştirir. Birini kullanan profil, diğeri için yapılandırılmış bir eşle çalışmaz ve hiçbir digest ayarı bu boşluğu kapatmaz.

Etiketi yalnızca gerçek biçimden yeniden üretin

Bayt düzeyinde birebir yeniden üretim, VPN çalıştırmaktan ayrı bir iştir ve yalnızca gerçek girdilerle çalışır: paketi oluşturan uygulama ve sürüm, seçilen digest, yön ve oturum tanımlayıcısı ile onay dizisi dahil gerçek baytlar. Alan listesinin metinsel sunumu o baytlar değildir.

Etiket uzunluğu digest'ten gelir, bu yüzden sabit uzunluk varsayımı biri onu değiştirdiği anda kırılır. Paketi uygulamanın yaptığı gibi hash'leyin, bir blog yazısındaki tablonun sunduğu gibi değil, ve elle türettiğiniz bir beklenti yerine aynı eşten alınan bir kayıtla karşılaştırın.

Bu alıştırmayı üretim profillerinden uzak tutun. Etiket yeniden üretmenin hiçbir yanı, bir dağıtımın korumayı etkinleştirmesi gerekip gerekmediğini söylemez.

Korumayı kaldırmadan bir uyuşmazlığı geri alın

Baştan çıkarıcı test, tls-auth'u silmek, bağlantının başarılı olduğunu görmek ve anahtarın yanlış olduğu sonucuna varmaktır. Bu yanıt size korumaya mal olur ve üç değerden hangisinin uyuşmadığını öğretmez. Bunun yerine sunucu tarafından onaylanmış eşleşen yapılandırmayı alın ve onunla karşılaştırın.

Değişikliği geri alınabilir olacak şekilde hazırlayın. Önceki sunucu yapılandırmasını ve anahtar dosyasını saklayın, düzeltilmiş çifti uygulayın, bir istemcinin el sıkışmayı tamamladığını doğrulayın ve ancak ondan sonra yedeği kaldırın. Değişiklikten sonra istemciler başarısız olursa, bir kesinti sırasında üçüncü bir varyant uydurmak yerine önceki dosyaları geri yükleyin. Geri yükleme, başlamadan önce zaten bildiğiniz tek bir komut olmalıdır.

Son olarak, geçilmiş bir denetimin ne anlama geldiğini hatırlayın. Eşin paylaşılan anahtarı tuttuğunu kanıtlar, sertifikasının veya hesabının yetkilendirildiğini değil, ve pazarlık edilen veri kanalı şifresi hakkında hiçbir şey söylemez. Yetkilendirme ve veri koruması daha sonra kurulur, bu yüzden temiz bir zarf denetimi bir başlangıç noktasıdır, hüküm değil.