HTTPS Basic kimlik doğrulaması ile IPsec: her biri neyi korur

Geliştirici araçlarını açın, dahili uygulamayı yükleyin ve sayfa oluşturulmadan önce bir isteğin dört kontrol noktasından nasıl geçtiğini izleyin. Önce ad çözümlenir, sonra bir TCP bağlantısı açılır, ardından bir TLS el sıkışması sunucunun kim olduğunu belirler ve ancak ondan sonra uygulama sizin kim olduğunuzu sorar. Bunları ayrı olaylar olarak ele alın, çünkü her biri farklı kanıtlarla başarısız olur ve her biri farklı bir ekibin sorumluluğundadır. Olaylardaki karışıklığın çoğu, 401'i bir tünel sorunu olarak ya da tünel sorununu kötü bir parola olarak okumaktan kaynaklanır.

Birinci kontrol noktası: konuşmayı amaçladığınız sunucu bu mu

TLS el sıkışması bu soruyu herhangi bir kimlik bilgisi gönderilmeden önce yanıtlar. İstemciniz sertifika zincirini bir güven deposuna göre doğrular ve sertifikadaki adın yazdığınız ana bilgisayarla eşleşip eşleşmediğini kontrol eder. Bu başarısız olursa tarayıcı bir sertifika hatası gösterir ve Authorization başlığını hiç göndermez. Bu nedenle parola istemi, sunucunun gerçek olduğunun kanıtı değildir; uygulamanın yanıt verdiğinin kanıtıdır.

İlk sınır burada ortaya çıkar. TLS bağlantıyı sonlandığı noktaya kadar korur. Bir yük dengeleyici TLS'i sonlandırıp uygulamaya düz HTTP iletirse, şifrelenmiş bölüm dengeleyicide sona erer ve kimlik bilgileri yalnızca o ilk adımda korunur.

İkinci kontrol noktası: bir 401 alışverişinde gerçekte ne taşınır

HTTP Basic kimlik doğrulaması, kullanıcı tanımlayıcısını ve parolayı bir başlıkta gönderir, RFC 7617 içinde açıklandığı gibi Base64 ile kodlanmış olarak. Authorization: Basic dXNlcjpwYXNz bunun biçimidir; kodlama isteği okuyabilen herkes tarafından geri çevrilebilir, bu nedenle tüm gizlilik alttaki taşıma katmanından gelir. curl -v hem WWW-Authenticate: Basic meydan okumasını hem de geri gönderdiğiniz başlığı gösterir.

O başlık uygulamaya kimin sorduğunu söyler. Ağa kimin bağlanabileceğini söylemez ve kendi başına hiçbir şeyi şifrelemez. Uygulama yine de kimlik bilgisini bir depoya karşı kontrol etmeli ve o hesabın ne yapabileceğine karar vermelidir; bu yetkilendirmedir ve kimlik doğrulamadan sonra gerçekleşir.

IPsec tüneli o yolun neresinde durur

Şimdi tarayıcıdan dışa doğru yürüyün. Ağ geçidi ile ağ geçidi arasındaki bir IPsec tüneli, iki güvenlik ağ geçidi arasındaki seçilmiş trafiği korur, dizüstü bilgisayarınız ile uygulama süreci arasındakini değil. Tünel modundaki ESP özgün paketi sarar, ağ geçitleri onu şifreler ve doğrular, iç adresler korunur böylece karşı taraf isteği uygulamaya yönlendirebilir.

Seçim, insanları tökezleten kısımdır. Politikaya dayalı tüneller, hangi paketlerin tünele gireceğine karar vermek için genellikle erişim denetim listeleri olarak ifade edilen trafik seçicileri kullanır. Rotaya dayalı tüneller ise bunun yerine sanal bir arayüz ve yönlendirme tablosu kullanır. Linux'ta ip xfrm policy seçicileri gösterir ve ip xfrm state kurulmuş güvenlik ilişkilerini gösterir; bir güvenlik duvarı cihazında eşdeğeri tünelin SA tablosu artı bir paket izleyicidir.

Sonucu açıkça söylemek gerekir. Bir paket tamamen sağlıklı bir tünelin içinde oturup yine de uygulamanın reddettiği bir HTTPS isteği taşıyabilir ve geçerli kimlik bilgileri, yönlendirme izin veriyorsa tünelsiz bir yoldan da gelebilir.

Hatayı onu bildiren katmanda okuyun

401, uygulamanın kimlik bilgisini kabul etmediği anlamına gelir. 403, kimliği kabul edip işlemi reddettiği anlamına gelir. TLS hatası, istemcinin sunucuyu kabul etmediği anlamına gelir. Rota olmaması veya politika uyuşmazlığı, paketin uzak ağ geçidine hiç ulaşmadığı anlamına gelir. Dört farklı başarısızlık, dört farklı sahip, ve hiçbiri giriş formuna bakarak teşhis edilmez.

Her katmanın ürettiği kanıtları kullanın: durum ve başlıklar için tarayıcının ağ paneli, sertifika zinciri için openssl s_client -connect host:443, tünel trafiği için ağ geçidinin SA sayaçları ve günlükleri, hesap kararı için uygulama günlüğü. İki katman aynı anda hata bildirdiğinde önce alttakini düzeltin, çünkü ölü bir tünel bir kimlik doğrulama hatasını kolayca maskeleyebilir ve tersi de geçerlidir.

Bir hizmeti uçtan uca haritalayın

Sorun giderdiğiniz hizmet için beş satır yazın: tünelin hangi tarafları bağladığı, seçicilerin hangi alt ağlara ve bağlantı noktalarına izin verdiği, TLS'in nerede sonlandığı ve sertifikanın hangi kimliği beyan ettiği, hangi uygulama hesabının ve rolünün kullanıldığı ve her katmanın nerede günlük tuttuğu. Bunları tek bir sayfada tutun, çünkü haritanın amacı bir katmanın sorumluluğunun nerede bitip sonrakinin nerede başladığını göstermektir.

Ardından her katman için bir olumsuz durumu test edin. Yanlış bir parola kullanın ve zaman aşımı değil 401 aldığınızı doğrulayın. Seçicilerin dışındaki bir alt ağdan bağlanın ve paketin tünellenmediğini doğrulayın. Yanlış ad için bir sertifika sunun ve istemcinin kimlik bilgilerini göndermeden önce reddettiğini doğrulayın. Bu üç sonuç size tasarım hakkında herhangi bir kutu diyagramından daha fazlasını söyler.

Son olarak, her ilişkinin hangi korumaya ihtiyacı olduğuna bilinçli olarak karar verin. TLS üzerinden Basic kimlik doğrulaması, bir ağ geçidinin arkasındaki küçük bir dahili araç için makul bir uyumdur; kullanıcı başına yetkilendirmenin ya da TLS uç noktasının ötesindeki trafiği korumanın yerine geçmez. Tünel yolu korur, sertifika adımı korur ve 401 hesabı korur, ve bunlardan yalnızca sonuncusu kim olduğunuzu bilir.