TLS sabitleme ve VPN erişimi farklı soruları yanıtlar

Özel bir mobil uygulamayı VPN’in arkasına koyun, makul bir insan hâlâ sertifika sabitlemeye ihtiyacı var mı diye sorar. Soru iki eşdeğer denetim arasında bir seçim gibi kulağa gelir, oysa gerçekte iki farklı kapı hakkında bir sorudur. VPN bu cihazın yolu kullanıp kullanamayacağına karar verir; uygulama ise ulaşılan sunucunun beklenen sunucu olup olmadığına karar verir. İkisini ayrı ayrı yanıtlayın, tasarım daha basit hâle gelir.

İki kapı, iki soru

Ağa kabul istemciyle ilgilidir: bu cihaz kayıtlı mı, kimlik bilgisi geçerli mi ve ilke bu yola izin veriyor mu? Uygulama güveni sunucuyla ilgilidir: bağlantı, uygulamanın kabul ettiği bir kimliğe sahip hizmete ulaştı mı? Bu yanıtlar farklı sistemlerden gelir, farklı nedenlerle başarısız olur ve farklı ekipler tarafından düzeltilir. VPN el sıkışması başarılı olabilir, ama uygulama eşin arkasındaki süresi geçmiş bir sertifikayla konuşuyor olabilir. Kusursuz sabitlenmiş bir uygulamaya yine de kimse ulaşamayabilir, çünkü cihaz hiçbir zaman ağa girmemiştir.

İkisi toplanır. Birini bırakmak bir denetimi kaldırır; diğerini eklemek onun yerini almaz.

Bir sabitleme gerçekte neyi sınırlar

Sabitleme, uygulamanın kabul edeceği sunucu kimlikleri kümesini daraltır; genellikle bir deponun kefil olacağı her zincire güvenmek yerine bir açık anahtarı ya da sertifika karmasını adlandırır. Bu, olağan doğrulamanın üzerine konan bir kısıttır, onun yerine geçen bir şey değildir. Olağan doğrulama bir zincirin baştan güvenilir olup olmadığını yanıtlar; sabitleme ise bunun bu uygulamanın beklediği zincir olup olmadığını yanıtlar. İlk adımı atlayan bir uygulama güvenlik değil, yalnızca yenilik kazanmıştır.

Sabitlenen nesne platformlar arasında farklıdır, bu yüzden kelimenin kendisi çok az şey söyler. Bir ürünün güven deposundan karma kopyalayıp bunu mobil uygulamada aynı şey saymak yaygın ve sessiz bir hatadır.

Platformda sabitleme bir yapılandırmadır, ilke değildir

Android sabitlemeyi ağ güvenliği yapılandırmasıyla sunar; burada bir sabitleme kümesi açık anahtar özetlerini tutar ve zincirde bunlardan en az biri bulunmalıdır. O dosya uygulama başınadır ve bilinçli bir derleme değişikliği gerektirir. iOS’un eşdeğer bir bildirim mekanizması yoktur, bu yüzden orada sabitleme uygulamanın kendi güven değerlendirme kodunda yaşar.

Mekanizma farklı olduğu için gereksinim platform başına yazılmalıdır. Platformu adlandırmadan sertifikayı sabitleyin diyen bir ilke uygulanabilir değildir.

Rotasyon sabitlemenin hayatta kalıp kalmayacağına karar verir

Zor kısım ilk sürüm değil, ondan sonraki sertifika yenilemesidir. Katı bir güven ilkesi, meşru bir yeni anahtarı bir saldırganınki kadar kararlılıkla reddeder.

İki mekanizma rotasyonu atlatılabilir kılar: ihtiyaç duyulmadan önce güvenilen bir yedek sabitleme ve sabitleme kümesinde bir son kullanma tarihi, böylece uygulama kilitlenmek yerine yürürlük sona erer. İkisi de ilke kararıdır ve özellikle son kullanma tarihi, zararsız bir zamanlayıcı değil, bilinçli bir güvenlik azaltmasıdır. Uygulamanın derlemesini, TLS bitiş noktasını ve sertifika yenilemesini kimin yönettiğini adlandırın ve bunları tek bir değişiklik sürecinde birleştirin. Bunlar üç farklı ekipse, sabitleme eninde sonunda kimsenin planlamadığı bir kesintiye yol açar.

Kayıp bir cihaz üçüncü sorundur

Bir VPN kimlik bilgisini iptal etmek bir uygulama oturumunu zorunlu olarak bitirmez ve sunucu sabitlemesi başkasının elindeki bir telefona hiçbir şey yapmaz. Cihaz kilidi, kimlik bilgisi saklama, oturum ömrü ve uzaktan iptal, ayrı sahipleri olan ayrı kararlardır. Bunları sabitleme tartışmasına katlamak, hiçbirinin tasarlanmayacağını garanti eder.

Gördüğünüz tek ilişki yerine dört ilişkiyi test edin: amaçlanan sunucu ve işlem, reddedilmesi gereken bir hesap, reddedilmesi gereken bir sunucu kimliği ve planlanan rotasyon. Çalışan bir VPN yalnızca birincisini alıştırır. Her testin neyi kanıtladığını yazın, çünkü bir sonraki kişi yeşil bir tünelin dördünün de geçtiği anlamına geldiğini varsayacaktır.