Arama güvenliği için yalnızca “Şifreli mi?” diye sormayın; şifrelemenin nerede sonlandığını ve kaydın neleri değiştirdiğini sorun.
Sohbetin şifrelenmesi, sesin, görüntünün, ekran paylaşımının veya arama kaydının da aynı korumaya sahip olduğunu tek başına kanıtlamaz. Bir aramayı değerlendirirken medyanın hangi noktaya kadar şifreli kaldığını, anahtarın kimin elinde olduğunu ve kayıt gibi özelliklerin etkinleştirilmesinin neleri değiştirdiğini sormalısınız.
Bu rehber, güvenlik iddialarını incelenebilir katmanlara ayırır; bir protokolün adı veya kilit simgesi, bu soruların yanıtlarının yerini tutmaz.
Tek bir uygulamada üç farklı yol
| Yol | Veri örneği | Güvenlik sorusu |
|---|---|---|
| Saklanan mesajlar | Metin, fotoğraf, dosya ve sesli not | Cihazdaki, sunucudaki ve yedekteki kopyaları kim okuyabilir? |
| Canlı medya | Mikrofon sesi, video ve ekran paylaşımı | Şifreleme, karşı tarafın cihazında mı yoksa aracı bir sunucuda mı sonlanır? |
| Sinyalleşme | Arama daveti, yanıt ve bağlantıyı koordine eden bilgiler | Kontrol mesajlarını veya hedefin kimliğini kim değiştirebilir? |
Sohbette gönderilen bir sesli not bir dosyadır; sesli arama ise canlı bir akıştır. Bir ürün bu ikisi için farklı anahtarlar ve mekanizmalar kullanabilir. Ses kalitesinin iyi olması veya bir metin mesajının ulaşmaması da tek başına diğerinin güvenliği hakkında bir şey söylemez.
DTLS-SRTP neyi gösterir?
WebRTC'de SRTP medya akışını korur; DTLS-SRTP ise bunun için gerekli anahtar materyalini oluşturmanın bir yoludur. RFC 5764, DTLS-SRTP mekanizmasını; RFC 3711 ise medya paketlerinin korunmasını açıklar.
Ancak “WebRTC kullanıyoruz” demek, konferans sunucusunun medyanın şifresini çözüp çözmediğini tek başına açıklamaz. Şifrelemenin uç noktaları ve bunların kimlik doğrulaması açıkça belirtilmelidir. Kullanıcı ile sunucu arasında şifreli bir bağlantı kurulabilir, fakat sunucu işleme veya kayıt amacıyla şifresi çözülmüş içeriğe erişebilir. Bu durum, katılımcılar arasındaki E2EE ile aynı değildir.
RFC 8827'deki WebRTC güvenlik mimarisi, medya korumasının yanında web uygulamasına duyulan güvenin, sinyalleşme yolunun ve karşı tarafın kimliğinin de önemli olduğunu gösterir. Paketlerin şifreli olması, ürünün tüm bileşenlerinin güvenilir olduğu anlamına gelmez.
Sinyalleşme neden ayrı değerlendirilmelidir?
Sinyalleşme, kimin kiminle arama yapacağını ve bağlantının nasıl kurulacağını koordine eder. Bir uygulama kontrol mesajlarını koruyorsa bile, bu korumanın katılımcıların gerçek kimliklerine ve medya anahtarlarına nasıl bağlandığı incelenmelidir.
Belgeleri okurken üç soru yeterlidir:
- Davet, yanıt ve anahtar bilgileri değiştirilmeye karşı korunuyor mu?
- Kullanıcı, anahtarın aramak istediği kişiye ait olduğunu nasıl anlayabilir?
- Anahtar veya cihaz değiştiğinde hangi uyarı gösterilir?
Yönlendirme bilgileri, aramanın zamanı ve katılımcıları, E2EE kullanılan bir aramada bile hizmet tarafından bilinebilir. Mesajlaşma üst verileri açıklaması bu ayrımı ele alır.
Arama kaydı yeni bir güvenlik sınırıdır
“Şifreli arama” ifadesi, kaydedilmiş kopya hakkında eksiksiz bir yanıt vermez. Bir katılımcı, kendi cihazıyla ses veya görüntü kaydı alabilir. Sunucu tarafında kayıt da ayrıca belgelenmelidir: Sunucu, kayıt yapmak için okunabilir medyaya erişiyor mu? Dosyayı kim saklıyor? Ne zaman siliniyor?
Kayıt özelliğinin etkinleştirilmesi güvenlik modunu değiştiriyorsa, bu değişiklik katılımcılara açıkça gösterilmelidir. Hassas bir konuşmadan önce kayıt durumunu ve kişilerin rızasını kontrol edin; uygulamanın kendi kayıt göstergesinin kapalı olması, başka bir araçla kimsenin kayıt yapmadığını garanti etmez.
Livara'nın güncel belgeleri nasıl okunmalı?
Livara'nın güvenlik sayfası, doğrudan ve grup aramalarını E2EE olarak tanımlar, ancak isteğe bağlı sunucu tarafı kaydı istisna olarak belirtir: Görünür REC modunda aramanın koruması, aktarım şifrelemesine dönüşür. Bu, ürün belgelerinde yer alan bir iddiadır; bu makalenin yaptığı bir testin veya bağımsız denetimin sonucu değildir.
Eski metindeki tüm grup aramalarını “Android'de 2 ila 6 kişi” ile sınırlandırma ifadesi, güncel belgelerle uyumlu değildir ve bu rehbere temel oluşturmaz. İlgili kapasite, platform ve sürüm için güncel rehber ve uygulamanın gerçek davranışı incelenmelidir; bu makale bir kapasite testi sunmaz.
Ayrıca ML-KEM gibi sohbet algoritmalarının adının geçmesi, aynı algoritmanın arama medyasında da kullanıldığını tek başına kanıtlamaz. Bir aramanın kuantum sonrası koruma sağladığı iddiası için medya yoluna ve kimlik doğrulamaya özgü kanıtlar gerekir. Livara'nın tehdit modelini özellikler sayfasıyla birlikte okuyun; bağımsız bir testin yerine koymayın.
İki hizmeti karşılaştırmadan önce kısa kontrol listesi
Her “evet” yanıtı için sürüm adını ve kaynağı da not edin:
- İki kişilik aramalar, grup aramaları ve ekran paylaşımı ayrı ayrı açıklanmış mı?
- Sunucunun yalnızca paketleri mi aktardığı, yoksa medyanın şifresini de çözebildiği mi açıkça belirtilmiş?
- Katılımcının kimliği ve anahtarı doğrulanabiliyor mu?
- Cihaz değişikliği, katılımcı eklenmesi ve kaydın etkinleştirilmesi açıkça görülüyor mu?
- Web'deki ve uygulamadaki arama yolu aynı mı, yoksa farklı mı?
- Kayıt dosyalarının ve üst verilerin saklanması açıklanmış mı?
- Test veya denetim kanıtı aynı sürüm ve özellikle mi ilgili?
Yanıt belgelerde yoksa “bilinmiyor” yazın; yanıtın bulunmaması ne güvenliğin ne de dinlemenin kanıtıdır.
Sık sorulan sorular
E2EE arama, karşı tarafın kayıt yapmasını engeller mi?
Hayır. Yetkili alıcı okunabilir içeriğe erişir ve bunu yazılımla veya başka bir cihazla kaydedebilir.
Aktarım şifrelemesi kötü müdür?
Aktarım şifrelemesi, iletişim yolu üzerindeki dinlemeye karşı önemli bir koruma sağlar. Aradaki fark, uç noktayı oluşturan hizmetin şifresi çözülmüş içeriğe erişebilmesidir; buna kullanıcılar arasında E2EE denmemelidir.
Sohbette kuantum sonrası şifreleme kullanılması, aramayı da kuantum sonrası yapar mı?
Hayır. İddia aynı katman, algoritmalar ve uygulama sürümüyle ilgili olmalıdır. Sohbeti ve aramayı ayrı ayrı değerlendirin.
