Uçtan uca şifreleme ek bir katmandır; TLS uyarılarını yok sayma veya değiştirilmiş koda güvenme izni değildir.
TLS ve uçtan uca şifreleme iki farklı sınır oluşturur. Bu sınırlar VPN ve proxy değerlendirmesinde de önemlidir. TLS genellikle cihazınız ile hizmet arasındaki bağlantıyı korur; doğru uygulanmış ve kimliği doğrulanmış uçtan uca şifreleme ise konuşma içeriğini alıcının cihazına kadar korur. TLS katmanını okumak, uçtan uca şifrelenmiş içeriği okumak anlamına gelmez; ancak bundan TLS güvenliğinin artık önemli olmadığı sonucu çıkarılmamalıdır.
Bir aracı güvenli bağlantıyı sonlandırabiliyorsa, aktarılan verileri görmenin yanı sıra yanıtları veya web uygulamasının kodunu da değiştirebilir. Bu nedenle «LVR1 ile TLS’yi aşmak» ifadesi bir mesajlaşma uygulamasının güvenliğini uygun biçimde tanımlamaz.
Bir kök sertifika incelemeyi nasıl mümkün kılar?
HTTPS bağlantısında cihaz, sunucunun sertifika zincirini ve ana makine adını denetler. Aracı, uygulamanın geçerli saydığı bir sertifika sunarsa iki ayrı bağlantı kurabilir: biri kullanıcıyla, diğeri gerçek sunucuyla. Bu durumda aracı, yalnızca paketlere bakarak şifreyi kırmış bir dinleyici değil, TLS bağlantılarından birinin son noktasıdır.
Herhangi bir sertifikayı yüklemek tek başına yeterli değildir; uygulamanın ona güvenmesi ve bağlantı denetimlerinin de başarılı olması gerekir. Android ağ güvenliği yapılandırması belgeleri, güven politikasının uygulamaya göre değişebileceğini açıklar. Android 7.0 ve üstünü hedefleyen uygulamalar, farklı yapılandırılmadıkça varsayılan olarak kullanıcının eklediği sertifikalara güvenmez.
Bu genel bir teknik mekanizmadır. Kanıt olmadan belirli bir operatör, ülke veya olay hakkında hüküm vermek için kullanılamaz. Kesinti veya filtreleme tek başına başarılı TLS incelemesinin kanıtı değildir.
TLS açılırsa neler görülebilir?
| Veri türü veya durum | TLS incelemesinin olası sonucu |
|---|---|
| Yalnızca HTTPS ile korunan içerik | Güvenilen aracı metni görebilir |
| Alıcının geçerli anahtarıyla önceden şifrelenmiş mesaj | Aracı genellikle mesaj metniyle değil şifreli metinle karşılaşır |
| Yönlendirme, oturum veya yardımcı istek verileri | Açığa çıkma düzeyi hizmetin biçimine ve tasarımına bağlıdır |
| Aynı yoldan gelen web sürümü kodu | Kod değişikliği uç nokta güvenliğini tehdit edebilir |
| Hizmet erişilemez olur veya trafik engellenir | Şifreleme tek başına bağlantı kurmaz |
E2EE’nin içerik koruması, alıcının anahtarının gerçekliğine ve her iki tarafın yazılımının bütünlüğüne de bağlıdır. Saldırgan ilk anahtarı değiştirirse veya mesajı şifrelemeden önce gören uygulama değiştirilirse, yalnızca AES ya da ML-KEM’in bulunması yeterli değildir.
Web sürümü neden sağlam TLS’ye ihtiyaç duyar?
Web uygulaması genellikle çalıştırılabilir kodu sunucudan alır. Bu kod kötü amaçlıysa şifrelemeden önce veya şifre çözmeden sonra içeriğe erişebilir. Uçtan uca şifreleme, kodun nasıl teslim edildiğinden ve çalıştırıldığından bağımsız değerlendirilemez.
Yüklü sürümde de paketin gerçekliği, güncellemeler ve işletim sisteminin bütünlüğü önemlidir. Paket imzası ve hash denetimi yararlıdır, ancak uygulamanın tam bir güvenlik testi değildir. Livara tehdit modeli de saldırgan hem dosyayı hem gösterilen hash’i değiştirirse, hash eşleşmesinin tek başına gerçekliği kanıtlamadığını belirtir.
Livara ne iddia ediyor?
Livara güvenlik belgelerine göre doğrudan mesajlar LVR1, uyumlu özel gruplar ise LGS1 kullanır. Belgeler, P-256 ile ML-KEM-768 birleşimini ve mesaj içeriğinin şifrelenmesini açıklar. Bunlar ürün iddialarıdır; bu makalede yapılmış bağımsız bir denetimin sonuçları değildir.
Aynı sayfa yönlendirme meta verilerinin tutulduğunu ve yayın kanallarının herkese açık olduğunu da belirtir. Dolayısıyla doğru sonuç «tüm bilgiler gizlenir» veya «ağda hiçbir güvene gerek yoktur» değildir. Sonuç, özel içeriğin korunmasının bağlantıdan, anahtar tesliminden, uygulama kodundan ve meta verilerden ayrı değerlendirilmesi gerektiğidir.
Sertifika uyarısıyla karşılaşınca ne yapmalıyız?
- Hassas bir sohbete devam etmek için tarayıcı veya uygulama uyarısını yok saymayın.
- Cihaz tarihini ve hizmetin tam adresini kontrol edin; her sertifika hatası mutlaka saldırı değildir.
- Cihaz kuruma aitse yönetim politikasını ve yüklü sertifikaları yetkili sorumluya sorun; yönetilen ayarları kendi başınıza değiştirmeyin.
- Yalnızca tanımadığınız bir mesaj istedi diye sertifika veya profil yüklemeyin.
- Hassas konuşmalarda anahtar parmak izini bağımsız bir yoldan muhatabınızla karşılaştırın; anahtar karşılaştırması TLS uyarısını gidermenin yerine geçmez.
Sık sorulan sorular
VPN bütün bu sorunları çözer mi?
Hayır. VPN trafiğin gözlendiği yolu değiştirebilir, ancak bulaşmış bir cihazı, kötü amaçlı güvenilen sertifikayı veya değiştirilmiş web kodunu otomatik olarak düzeltmez.
Parola göndermeden kimlik doğrulama yeterli mi?
Hayır. Kimlik doğrulama protokolü, oturum yönetimi ve mesaj şifrelemesi farklı işlevlere sahiptir. Sahte giriş sayfası veya kötü amaçlı kod, protokol çalışmadan önce kullanıcının girdisini doğrudan alabilir.
Pratik ilke: E2EE değerli bir katmandır; sertifikaları, uygulamanın gerçekliğini veya anahtar doğrulamasını önemsememe izni olarak görmeyin.
