Kendinden imzalı VPN sertifikası: ne anlama gelir ve neye güvenir
Kendinden imzalı bir VPN sertifikası trafiği şifrelemeye devam eder. Değişen şey, ona güvenmesini kime söylediğiniz, bu güveni hangi deponun aldığı ve hangi kontrollerin kaldığıdır.
Burada en çok zararı iki inanç verir: kendinden imzalı bir VPN sertifikasının tünelin şifrelenmediği anlamına geldiği ve VPN istemcisinin istediği her şeyi kurmanın yalnızca VPN'i etkilediği. İkisi de gerçek bir dağıtımla temasta ayakta kalmaz. Kendinden imzalı bir sertifika bir imza ilişkisini tanımlar, güvenlik hükmünü değil, ve eklediğiniz güvenin erişimi hangi depoya düştüğüne bağlıdır. Bir yardım masasının tek bir uyarıyı susturmak için sağlayıcı kökünü bir Windows makinesine aktardığını, sonra tarayıcının ilgisiz bir portal hakkında şikâyet etmeyi neden bıraktığını anlatmakla bir öğleden sonra geçirdiğini gördüm. Bu sorunun iki yarısı birbirine aittir, bu yüzden onları tek olarak ele alın.
Sertifika bir güven deposu değildir
Sunucunun sunduğu dosya bir açık anahtar, bir konu adı, bir veren adı, geçerlilik tarihleri ve uzantılar taşır. Kendinden imzalı, konu ile verenin aynı varlık olduğu ve imzanın sertifikanın kendi anahtarıyla doğrulandığı anlamına gelir. Bu tanımda hiçbir şey bağlantının zayıf olduğunu söylemez ve hiçbir şey istemcinin onu kabul edeceğini söylemez.
Kabul başka bir yerden gelir: istemciyi yönlendirdiğiniz bir CA dosyası, elle karşılaştırdığınız bir parmak izi veya istemcinin okuduğu bir depoda zaten duran bir kök. Bir dağıtım tamamen sağlıklı olabilirken sertifikası her genel testte kalırdı. openssl verify sistem paketine karşı bilinmeyen bir veren bildirir ve bu bildirim kusur değil, doğrudur.
OpenVPN'in ca seçeneği uygulamaya sınırlı güvenin en açık örneğidir. O dosya istemcinin kabul edeceği çapaları adlandırır ve tek bir özel CA ya da küçük bir dağıtımda sunucunun kendi kendinden imzalı sertifikasını içerebilir. Sürüm 2.6, CA dosyası dağıtmak yerine SHA-256 parmak izini sabitlemek için --peer-fingerprint seçeneğini de kabul eder. WireGuard daha da dışarıdadır: hiç sertifikası yoktur, yalnızca her eş için statik bir açık anahtar vardır, bu yüzden kendinden imzalama sorusu ona uymaz.
Güveni nereye kurduğunuz, onu kimin miras alacağını belirler
Aynı sertifikayı üç yere koyun ve üç farklı patlama yarıçapı elde edin. Yalnızca VPN istemcisinin okuduğu bir demet o istemciyi etkiler. İşletim sistemi deposundaki bir kök, o depoya başvuran her programı etkiler. Kendi güven veritabanına sahip bir tarayıcı ikisini de yok sayabilir, bu yüzden çalışıyor görünen bir içe aktarımın ardından bile bir uyarı kalabilir.
Debian veya Ubuntu'da bir dosyayı /usr/local/share/ca-certificates/ içine bırakmak ve update-ca-certificates çalıştırmak sistem genelindeki demeti değiştirir. Windows'ta certutil -addstore -f Root makine deposuna yazar ve yükseltilmiş bir istem gerektirir, oysa -user eklemek onun yerine geçerli kullanıcının deposunu hedefler; ikisi değiştirilemez. Firefox kendi NSS veritabanını tutar, bu yüzden işletim sistemi düzeyinde bir içe aktarım orada hiç görünmeyebilir.
Kapsam önemlidir çünkü bir otoritenin ne yapabileceğine bağlıdır. Veren CA, ilişkisi olmayan adlara imza atabilir, bu yüzden o depoya güvenen her şey bu imzaları kabul eder. Tek bir sabitlenmiş yaprak bunu yapamaz; tam olarak bir eş kimliğini doğrular. Amaç bir VPN'i bağlamaksa, uygulamaya sınırlı bir CA veya sabitlenmiş bir yaprak buna ulaşır, oysa makine genelinde bir kök semptomun gerektirdiğinden çok daha büyük bir tavizdir.
Hâlâ genel bir CA olmadan şifreliyorsunuz
TLS el sıkışması, eş sertifikası zaten güvendiğiniz bir şeye zincirlensin ya da zincirlenmesin oturum anahtarlarını türetir. Kendinden imzalı düz metin anlamına gelmez ve trafiğin uçuş sırasında okunabildiği anlamına da gelmez. Anlamı, istemcinin anahtarın istediği sunucuya ait olduğuna inanmak için önsel bir nedeni olmamasıdır.
Gerçek saldırılar tam o boşlukta yaşar. Herhangi bir sertifikayı kabul etmek üzere yapılandırılmış bir istemci, ister devre dışı bir doğrulama ayarıyla ister bir kez basılıp unutulmuş bir “yine de güven” düğmesiyle olsun, yanıt veren herkese seve seve şifreleme yapar. Araya girme, kimlik doğrulama adımında, uygulama verileri hareket etmeden önce gerçekleşir. Kimlik kontrolü olmayan şifreleme pasif bir gözlemciyi dışarıda tutar ve fazla bir şey yapmaz.
Verene güvenmek ad kontrolünü atlamaz
Zincir doğrulama, ad eşleştirme ve sertifikanın amacı ayrı kararlardır. Zincir geçerliyken ad yanlış olabilir ve ad eşleşirken sertifika başka bir rol için verilmiş olabilir. RFC 5280 bu kısıtları taşıyan alanları tanımlar ve bir istemcinin bunları ne kadar sıkı uyguladığı her uygulamanın meselesidir.
OpenVPN ayrımı görünür kılar. verify-x509-name beklenen konuyu name, name-prefix veya subject eşleştirmesiyle sabitler. remote-cert-tls server eş sertifikasının sunucu sertifikası olarak kullanılabilir olmasını gerektirir, bu da veren güvenilir olsa bile yalnızca istemci sertifikasını reddeder. İki ayarın hiçbiri bir CA dosyası göndermekle değiştirilmez.
Herhangi bir şeye karar vermeden önce sertifikayı inceleyin:
openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltNamekimin, hangi adlar için ve ne zamana kadar verdiğini gösterir.openssl verify -CAfile ca.crt server.crtgöndermeyi planladığınız zincirin yaprağı gerçekten doğrulayıp doğrulamadığını kontrol eder.openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_errorweb portalı gibi TLS uç noktaları için çalışır; 1194 üzerindeki OpenVPN protokolü düz bir TLS akışı değildir, bu yüzden o test orada geçerli değildir.
Süresi geçmiş tarihli, bağlandığınız ad için subjectAltName içermeyen veya serverAuth kullanımı olmayan bir sertifika, çapa ne kadar dikkatle kurulmuş olursa olsun başarısız olur.
Birini kabul etmeden önce beş kontrol
Parmak izini, düzeltmeye çalıştığınız bağlantı olmayan bir kanaldan karşılaştırın: bir konsol, zaten sahip olduğunuz bir yükleyici, imzalı bir yapılandırma dosyası. Sunucudaki openssl x509 -in server.crt -noout -fingerprint -sha256 ve istemci günlüğündeki aynı değer, tek bir nesneye baktığınızı bilmek için yeterlidir.
Ardından ne kurduğunuza karar verin: bir yaprak mı, yoksa daha fazlasını basabilecek bir otorite mi. Sonra nereye gittiğine karar verin ve o depoyu okuyan uygulamaları adlandırın. Kaldırma yolunu hâlâ hatırlarken yazın, çünkü güven-ve-devam-et, geçici bir içe aktarımın kalıcı hale gelme yoludur.
Son olarak değişikliği planlayın. Sabitlenmiş bir sertifika veya parmak izi, sertifika döndüğünde aynı güvenilir kanaldan güncellenmelidir ve özel bir CA'nın kendi verme ve iptal yaşam döngüsü vardır. Özel anahtar sızarsa, aynı sertifikanın bir kopyasına yeniden güvenmek hiçbir şeyi onarmaz; kimliğin değiştirilmesi gerekir.
Bir uyarı beş kontrolün hepsinden sağ çıkarsa, yararlı soru onu hangi düğmenin susturduğu değil, istemcinin gerçekte hangi depoyu okuduğu ve o kökün nereden geldiğidir. Buna yanıt verin, ve yapmak üzere olduğunuz içe aktarım bir tepki yerine karar haline gelir.