SSTP ve SSL 3.0: etiket ile müzakere edilen sürüm

İki kişi aynı SSTP kurulumuna bakıp zıt sonuçlara varabilir. Biri ürün belgelerini okur, SSL harflerini görür ve tünelin yıllar önce kullanımdan kaldırılmış bir protokolü çalıştırdığını varsayar. Diğeri modern bir el sıkışmaya işaret eder ve sorunun kapandığı sonucuna varır. İkisi de müzakere edilen sürümden değil etiketlerden tartışıyor ve bunlardan yalnızca biri kanıt. Yapmaya değer karşılaştırma, adın vaat ettiği şey ile hizmetin gerçekte seçtiği şey arasındadır.

Aynı soruya iki cevap

Etiket argümanını söylemek kolaydır: SSTP güvenli soket tünelleme protokolü olarak tanımlanır, tarihsel ad SSL der, dolayısıyla bağlantı SSL 3.0 olmalıdır. Ayakta kalır çünkü ad gerçekten o soydan gelir ve çünkü bunu tekrarlayanların çoğu hiçbir zaman bir el sıkışmaya bakmamıştır. Ayrıca sonuç ihtiyatlı kulağa geldiği için ayakta kalır, sanki en kötüyü varsaymak güvenli seçimmiş gibi. En kötüyü varsaymak ile gerçek sürümü ölçmek farklı etkinliklerdir ve yalnızca biri bir şeyi değiştirir.

Kanıt argümanı daha dar bir soru sorar. Bu istemci ile bu sunucu bu uç noktada, bu anda hangi protokol sürümünde anlaştı? Cevap TLS'i sonlandıran hizmetten gelir, bir pazarlama sayfasından veya benzer adlı bir siteye ulaşan tarayıcıdan değil.

İki argüman neyi kanıtlayabildikleri bakımından farklıdır. Etiket eski bir kurulumu yamalanmış olandan ayıramaz ve el sıkışma aynı ana bilgisayardaki ilgisiz bir hizmetin ne yaptığını söyleyemez. İkincisini kullanın ve birincisini kullanmayı bırakın.

Hizmetin gerçekte seçtiği sürümü okuyun

Bileşenleri adlandırarak başlayın: istemci uygulaması, sunucu uygulaması, TLS uç noktası ve aralarında TLS'i sonlandırıp yeniden kuran her şey. TLS'i sonlandırıp arka uçla düz HTTP konuşan bir yük dengeleyici, hangi cihazın ilkesini okumanız gerektiğini değiştirir.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

Uç noktayı ve saati sonucun yanına kaydedin, çünkü ilkede sonradan yapılan bir değişiklik tarihsiz bir gözlemi işe yaramaz hale getirir. Sondalamayı önemsediğiniz kullanıcılarla aynı ağ yolundaki bir istemciden tekrarlayın, çünkü bir araya girme cihazı TLS'i kendi ayarlarıyla sonlandırabilir. İki konum uyuşmuyorsa önemli olan bileşeni buldunuz. Uyuşuyorsa slogan yerine kanıtınız var.

Kayıt alanını müzakerelerden ayırın

Bir alanda eski görünen sürüm numarası, SSL 3.0 oturumuyla aynı olgu değildir. RFC 7568 kayıt katmanı sürümünü ve müzakere edilen protokolü ayrı konular olarak ele alır ve kendinden emin yanlış cevaplar tam olarak bu ayrımdan doğar. Müzakere edilen protokolü okuyun, sonra şifrelemeyi ve ancak ondan sonra oturum hakkında bir sonuca varın.

Aynı belge protokolün kendisi konusunda nettir: SSL 3.0 kullanılmamalıdır ve ona müzakere veya geri dönüş yasaktır. Gerekçe, POODLE saldırısının sömürdüğü bozuk CBC yapısıdır ve bu protokolün özelliğidir, tek bir uygulamanın yapılandırması değil.

Bu yüzden „bu iş yükünün sömürülmesi muhtemelen zordur” SSL 3.0'ı etkin tutmak için bir argüman değildir. Gereklilik protokolü kaldırmaktır, tek bir gösteri hakkında tartışma kazanmak değil.

SSL 3.0'ı savunabileceğiniz bir ilkeyle devreden çıkarın

Windows'ta Schannel protokol ayarları Protocols anahtarı altında bulunur ve istemci ile sunucu rolü için ayrı okunur; bu nedenle bir yönü düzelten değişiklik diğerini dokunulmadan bırakabilir. Geçerli ayarlar ve yeniden başlatma gereksinimleri Microsoft tarafından belgelenmiştir ve aynı ana bilgisayardaki üçüncü taraf bir TLS kitaplığı bunları tamamen yok sayar.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

İlkeyi desteklenen yönetim yolundan değiştirin, sahip hizmetin yapılandırmasını yeniden aldığını doğrulayın ve onaylanmış bir geri dönüş yolu tutun. Başka bir ortamdan geniş bir kayıt defteri betiği yapıştırmak, tek bir hizmet düzeltmesinin makinedeki her TLS istemcisi için kesintiye dönüşme biçimidir. Yeniden başlatma kapsamı burada önemlidir: uygulanmış görünen bir ayar, onu yeniden yüklememiş bir hizmet tarafından hâlâ bellekte tutuluyor olabilir.

Hâlâ eski bir sürüm isteyen bir eşin güncellemeye veya geçiş planına ihtiyacı vardır. Eski protokolü sessizce geri getiren belgelenmemiş bir istisna uyumluluk stratejisi değildir ve bir sonraki denetimi atlatamaz.

Değişikliği yeni bağlantılarla kabul edin

İlke değişikliğinden sonra yeni oturumlarla test edin, çünkü değişiklikten önce kurulmuş bir bağlantı şu anda yürürlükte olan yapılandırma hakkında hiçbir şey kanıtlamaz. İzin verilen protokolün başarılı olduğunu ve yasak olanın yetkili doğrulama sürecinde başarısız olduğunu doğrulayın, ardından sertifika kimliğini ve güven denetimlerini tam olarak oldukları gibi bırakın.

El sıkışmanın neyi kapsamadığını unutmayın. SSTP, TLS katmanından sonra PPP kimlik doğrulaması taşır, bu yüzden modern bir protokol sürümü hangi kullanıcının yetkilendirildiği veya oturumun hangi kaynaklara erişebileceği hakkında hiçbir şey söylemez. Bunlar ayrı kanıtlara sahip ayrı denetimlerdir.

Sonucu hizmet, arka uç, izin verilen ilke ve gözlemlenen sürüm olarak yazın. Böyle bir kayıt güvenlik sorusunu kesin olarak yanıtlar; bunu ne etiket argümanı ne de zahmet argümanı asla yapmaz.