- jabber.ru ve xmpp.ru, barındırma sağlayıcısı yolundaki trafiğin ele geçirilmesi ile Domain Validation sertifikasının izinsiz verilmesinin birleştiği bir MitM saldırısı yaşadı; web dışı TLS servislerindeki savunma boşluğu ortaya çıktı
- Certificate Transparency loglarının izlenmesi ve TLS açık anahtar yoklaması anormallikleri bulmaya yardımcı olur, ancak CT’ye kaydedilmemiş sertifikalar ve seçici MitM karşısında eksiksiz tespit zordur
- ACME-CAA (RFC 8657) DNSSEC ile birlikte dağıtıldığında, yalnızca belirli bir CA’daki belirli bir hesabın sertifika vermesine izin verilebilir; böylece saldırganın yalnızca aynı CA’yı kullanması yeterli olmaz
- Web tarayıcılarının aksine birçok web dışı istemci CT kanıtını (SCT) zorunlu tutmaz; CA/Browser Forum Baseline Requirements da tüm sertifikaların CT’ye kaydedilmesini zorunlu kılmaz
- Operatörler ACME-CAA, DNSSEC, CT izleme, Tor onion service ve yargı alanı dağıtımını değerlendirmeli; kullanıcılar ise uçtan uca şifreleme ve parmak izi doğrulamayı temel savunma hattı olarak görmelidir
Olayın temel yapısı
- jabber.ru ve xmpp.ru operatörleri, servisin man-in-the-middle saldırısına uğradığını açıkladı
- Saldırı iki unsurun birleşimi şeklindeydi
- Hetzner ve Linode, servis makinelerine giden trafiği ele geçirdi
- Saldırgan, ilgili servis için izinsiz bir Domain Validation sertifikası aldı
- Bunun Alman devleti tarafından koordine edilmiş ya da Almanya’nın bir veya daha fazla başka devletle birlikte koordine etmiş olma olasılığı yüksek değerlendiriliyor
- Başka olasılıklar da mevcut
- Hetzner ve Linode’un yasal zorlama olmadan yabancı bir gücün dinleme talebine gönüllü olarak yanıt vermiş olması
- Ancak bu durumda iki şirket için çok kötü bir değerlendirmeye yol açacağı ve yasa dışı olabileceği için olasılık düşük görülüyor
Tespit yöntemleri ve sınırlar
- İlk yöntem, Certificate Transparency (CT) loglarını izleyerek operatörün talep etmediği sertifika verilişlerini bulmaktır
- Bunu operatör adına yapan bazı servisler vardır
- Yalnızca talep edilmemiş sertifikaları iyi ayıklayıp bildiren araçların daha da iyileştirilebilecek yanı vardır
- İkinci yöntem, düzenli aralıklarla servise bağlanıp TLS sunucusunun açık anahtarının beklenen değerle eşleşip eşleşmediğini kontrol etmektir
-
CT izlemenin kaçırabileceği alanlar
- Meşru bir CA tarafından verilmiş sertifikalar bile mutlaka CT loglarına kaydedilmez
- CA/Browser Forum Baseline Requirements, CT loglamayı henüz CA’lar için zorunlu bir şart olarak belirlemiyor
- Web tarayıcıları, CT log kaydına dair kriptografik kanıtı olmayan sertifikaları reddettiği için CT loglama fiilen zorunlu hale gelir
- Web dışı istemci uygulamalarının çoğu, sertifikada CT kayıt kanıtı olup olmadığını kontrol etmez veya bunu şart koşmaz
- Saldırgan teorik olarak CT’ye kaydedilmemiş bir sertifika temin edebilir
-
Seçici MitM’in kaçınma olasılığı
- Servis yoklamasıyla MitM tespit edilmeye çalışılsa bile saldırgan, tespit amaçlı bağlantıları tanımlayıp bu bağlantılara MitM uygulamayabilir
- Kolayca tanımlanabilen durumlardan kaçınmak için en azından yoklamalar Tor üzerinden yapılmalıdır
- TLS yığını, TLV listeleme sırası gibi sinyallerle parmak izi çıkarılabilir olduğundan, gerçek XMPP istemcisi ile yoklama ajanını ayırt etme olasılığı vardır
- Saldırgan, bilinen yoklamaları kara listeyle dışlamak yerine yalnızca ilgilendiği belirli bir kişinin trafiğini beyaz listeye alıp MitM uygulayabilir
- Her iki tespit yöntemi de tam güvenilirlik sağlamaz
ACME-CAA ile azaltılabilecek risk
- TLS sertifikaları MitM saldırılarını engellemek için kullanılan bir mekanizmadır, ancak CA’nın alan adı kontrolünü doğruladığı Domain Validation modeli bizzat MitM’e açıktır
- Saldırgan, hedef siteye giden trafiğin bir kısmını değil tamamını ele geçirebiliyorsa risk büyür
- ACME-CAA (RFC 8657) belirli durumlarda bu sorunu hafifletebilir
- Temel fikir, DNS kayıtlarıyla belirli bir CA’daki belirli bir hesabın alan adı sertifikası verebileceğini belirtmektir
- Yalnızca aynı CA’yı kullanmak yeterli değildir
- İlgili CA’daki aynı hesaba erişim yetkisi gerekir
- Let's Encrypt’te, sertifika isteğinde kullanılan ACME özel anahtarına erişim gerekir
- Bilinen saldırı yöntemlerine göre, bu eklenti dağıtılmış olsaydı saldırının engellenebileceği değerlendiriliyor
-
Dağıtımda dikkat edilecekler
- ACME-CAA’nın düzgün çalışması için DNSSEC dağıtımı gerekir
- DNSSEC yoksa CA’nın DNS istekleri de ele geçirilebilir
- DNSSEC imzalama anahtarını ele geçiren kişi bu engeli aşabilir
- DNSSEC ile korunan DNS zone’u, imzalama anahtarını üçüncü tarafa vermeden işletilebilir
- Bu durumda DNS barındırma sağlayıcısının zone’u bozma yetkisi olmaz
- Bu yöntem en iyi dağıtım stratejisi olarak değerlendiriliyor
- Saldırgan, domain kayıt şirketine veya TLD kayıt operatörüne baskı yaparak domainde kayıtlı DNSSEC imzalama anahtarını değiştirmeye çalışabilir
- Bu işlemin fark edilme olasılığı vardır
- DNS önbellekleme özellikleri nedeniyle, tekrarlı yoklamaların anahtar değişikliğini tespit etmesini engellemek zor olabilir
- Saldırganın CA’nın kendisine baskı yaparak hatalı sertifika verdirmesi de mümkündür
- Üçüncü taraf CA kuralları ihlal eder veya hata yaparsa hâlâ savunmasız kalınır
- CA/Browser Forum Baseline Requirements, CA’ların DNSSEC’i kontrol etmesini gerektirir
- Ancak üçüncü taraf CA, CAA kaydında yetkilendirilmemiş olmasına rağmen sertifika verebilir
- CT loglama zorunlu olmadığı için böyle bir sertifika tespit edilmeyebilir
Daha yetenekli bir saldırganın izleyebileceği akış
- Bu olayın saldırganı, yasa dışı sertifikaların süresinin dolmasına izin verdiği için kusursuz bir saldırgan değildi
- Ucuz ve kolay şifreleme yaygınlaştıkça devlet düzeyindeki saldırıların daha sofistike ve daha sık hale gelmesi bekleniyor
- Daha yetenekli bir devlet düzeyi saldırgan şu akışı seçebilir
- CA’ların CT log kaydını zorunlu yapmamasından yararlanarak kaydedilmemiş sertifika ister
- Barındırma sağlayıcısına baskı yaparak hedef makineye giden tüm trafiğe MitM uygular
- TLS yığını parmak izi ve kaynak IP ile ilgi duyulan trafik ile tespit amaçlı trafiği sezgisel olarak ayırır
- MitM’i kullanarak CA’nın saldırganı hedef domainin meşru denetleyicisi olduğuna inandırır
- Domain ACME-CAA ve DNSSEC kullanıyorsa DNS barındırma sağlayıcısına, kayıt şirketine, TLD kayıt operatörüne ve CA’ya baskı yapmaya çalışabilir
Mevcut TLS altyapısındaki açıklar
-
Web dışı TLS istemcilerinde CT zorunluluğunun eksikliği
- Web tarayıcıları, CA sertifikasında CT log kaydının kriptografik kanıtının bulunmasını şart koşar
- Diğer TLS istemcilerinin çoğu CT kanıtını zorunlu tutmadığından kaydedilmemiş sertifikaları kabul edebilir
- Birçok XMPP istemcisinin de buna dahil olması muhtemeldir
- CT doğrulaması, OpenSSL’e linklemekle otomatik etkinleşen bir özellik değil; ayrı uygulama gerektirir
- Hassas iletişimde kullanılan yazılımlar CT zorunluluğu desteğini değerlendirmelidir
-
Sertifikaların CT’ye kaydedilme zorunluluğunun olmaması
- CA’ların uyması gereken sektör kuralları olan CA/Browser Forum Baseline Requirements, sertifikaların CT loglarına kaydedilmesini gerektirmez
- Tüm sertifikaların CT loglarına kaydedilmesini gerektiren bir yöne ihtiyaç olduğu düşünülüyor
- CT zorunluluğu yaygın olarak dağıtılırsa bu sorun teknik olarak anlamsız hale gelebilir
-
CT izleme servislerinin eksikliği
- Daha fazla CT izleme servisine ihtiyaç var
- Günümüzde başlıca CT uyarı servislerinden biri SSLMate's Cert Spotter
- Fiyatı, gönüllü temelli servisler gibi yapılar için yük olabilir
- CT izleme, yanlış pozitifleri azaltacak ve yalnızca anormal ya da izinsiz görünen sertifika verilişlerinde uyaracak şekilde tasarlanmalıdır
-
DNSSEC şeffaflığının olmaması
- Şu anda bir domaine ayarlanmış DNSSEC anahtar değişikliklerini tespit eden dağıtılmış bir kriptografik altyapı yok
- Domain kayıt şirketi ve TLD kayıt operatörü baskı ya da ihlal sonucu domainin DNSSEC anahtarını değiştirirse ACME-CAA koruması zayıflayabilir
- DNSSEC zone anahtar değişikliklerinin herkese açık şekilde görülebilmesini sağlayan bir şeffaflık çözümü arzu edilir
- Bu çözüm, zone’un tüm kayıtlarını değil yalnızca DS kayıtları gibi zone anahtar değişikliklerini kaydetse de yeterli olabilir
Servis operatörleri için öneriler
- Devlet düzeyi saldırıların hedefi olabilecek servisler için, savunmaları maliyet-etkinlik sırasına göre uygulayan bir yaklaşım önerilir
-
ACME-CAA ve DNSSEC
- ACME-CAA dağıtmak, saldırganın CA’yı kandırarak domain sertifikası almasını zorlaştırabilir
- Dağıtım kılavuzu için ACME-CAA dağıtım yazısına bakılabilir
- RFC’nin Security Considerations bölümü de önemli uyarılar içerir
- ACME-CAA dağıtılacaksa DNSSEC de birlikte dağıtılmalıdır
- Mümkünse imzalama anahtarlarını sağlayıcıya emanet etmeyi gerektirmeyen bir DNSSEC sağlayıcısı seçilmelidir
-
Proxy servisleri ve CT izleme
- Cloudflare gibi servisleri kullanmak, kendi kendinize zaten MitM uyguluyor olmanıza benzer bir durum olarak değerlendiriliyor
- CT log izleme servisine abone olunmalı veya loglar düzenli olarak doğrudan kontrol edilmelidir
- SSLMate's Cert Spotter ücretli otomatik izleme sunar
- Cert Spotter açık kaynaklıdır, bu nedenle kendi ortamınızda barındırmak da mümkündür
- crt.sh CT loglarında manuel arama sunar
-
Yargı alanı dağıtımı ve Tor onion service
- Domain kayıt şirketi, TLD kayıt operatörü, DNS barındırma, CA ve barındırma sağlayıcısını farklı ülkelerde tutan yargı alanı dağıtımı değerlendirilebilir
- Seçim yapılırken birbirleriyle işbirliği yapma olasılığı düşük ülkeler veya jeopolitik bloklar dikkate alınabilir
- Tor onion service sunmak, TLS ve CA gibi merkezi altyapıları baypas edebilir
- Tor onion service’te servis açık anahtarı adresin kendisidir
- Kullanıcı doğru onion adresini güvenilir bir kanaldan almalıdır
- Üçüncü taraflar kullanıcıyı yanlış onion adresine yönlendirebilir
-
Tor tabanlı otomatik yoklama
- Tor üzerinden otomatik yoklama tam bir çözüm değildir, ancak pratikte yaşanan acemice hataları yakalayabilir
- Tor kullanmak, yoklama olarak kolayca tanımlanmayı azaltabilir
- TLS parmak izi olasılığını düşürmek için istemci yazılımının yaygın kullanılan TLS kütüphanelerinden birini kullanması daha iyidir
- Mümkünse gerçek istemciyi kullanmak daha iyidir
- XMPP servisi söz konusuysa gerçek bir XMPP istemcisi kullanılabilir
- Başarılı olsa bile bu ancak ihlal sonrası tespit anlamına gelir; o noktada kullanıcılar zaten zarar görmüş olabilir
-
Diğer saldırı vektörleri ve en kötü varsayım
- MitM’i zorlaştırmak, saldırganın makinenin kendisini ele geçirme, özel anahtar çalma, hassas bilgi çalma gibi başka yolları kullanma olasılığını artırır
- Devlet düzeyi saldırganlar VM sağlayıcısına baskı yaparak hiper yönetici seviyesinde bellek dökümü aldırabilir
- Özel sunucular da saldırganın fiziksel erişimiyle ele geçirilebilir
- Operatörler kullanıcılara uçtan uca şifreleme önermeli ve servisin en iyi çabalara rağmen ihlal edildiğini varsaymalıdır
- Web uygulamasıyla sunulan “uçtan uca” şifrelemenin anlamlı bir koruma olmadığı değerlendiriliyor
CA’lar, istemci geliştiricileri ve kullanıcılar için gerekli adımlar
-
CA/Browser Forum
- Tüm sertifikaların CT loglarına kaydedilmesini zorunlu tutmalı veya buna yönelik bir öneri sunmalıdır
-
Uygulama istemcisi geliştiricileri
- TLS sertifikalarında Signed Certificate Timestamps (SCTs) olup olmadığını zorunlu kılan bir özellik eklemeli ve varsayılan olarak etkinleştirmelidir
- Kullanıcıların bu korumadan yararlandığını anlayabilmesi sağlanmalıdır
- CT kanıtını zorunlu tutmada bazı değişkenlikler bulunduğundan ilgili tartışmalar da dikkate alınmalıdır
- Yazılım, herkese açık denetime imkân tanıyacak şekilde açık kaynak olarak sunulmalıdır
- Tedarik zinciri riskleri ve geliştirici şirketin kendisinin yazılımı hukuken bozmak zorunda bırakılma ihtimali de dikkate alınmalıdır
- Linux dağıtım paket depoları gibi geliştiricinin doğrudan kontrol etmediği dağıtım kanalları zararı azaltmaya yardımcı olabilir
-
Son kullanıcılar
- Servis operatörü iyi niyetle çalışsa bile, en iyi çabalara rağmen servisin ihlal edilebileceği varsayılmalıdır
- Hayatınız servisin ihlal edilmemiş olmasına bağlıysa o servise güvenmemelisiniz
- XMPP’de OMEMO veya OTR gibi uçtan uca şifreleme teknolojileri kullanılmalıdır
- İletişim kurulan tarafın parmak izi her zaman doğrulanmalıdır
- Web tabanlı yazılımla uçtan uca şifreleme yapılmamalı ya da en azından bunun ihlal edilmiş olduğu varsayılmalıdır
- Servis sağlayıcı Tor onion service sunuyorsa kullanımı değerlendirilmeli, ancak onion adresi güvenilir bir kaynaktan alınmalıdır
-
CA’lar ve standart yazarları
- CA’lar ACME-CAA (RFC 8657) desteklemiyorsa uygulamayı değerlendirmelidir
- ACME tabanlı CA olmasalar bile ACME-CAA uygulayabilirler
- CA/Browser Forum kuralları CT’ye kaydedilmemeye izin verse bile CA’lar tüm sertifikaları CT’ye kaydetme politikası benimseyebilir
- Standart yazarları en azından DS kayıtları için DNSSEC şeffaflığı olasılığını yeniden değerlendirebilir
Confidential computing hakkında değerlendirme
- Barındırma sağlayıcısının makineyi ele geçirmesinden de endişe ediliyorsa mevcut confidential computing teknolojileri yeterli bir çözüm olarak değerlendirilmiyor
- Dağıtılması hiçbir şey yapmamaktan daha iyi olabilir, ancak güvenli olduğuna inanılmamalıdır
- AMD, Intel vb. dahil mevcut teknolojilerin, sistemi arka kapılayabilecek tedarikçi golden key’lerine dayandığı değerlendiriliyor
- Devlet düzeyi saldırgan tedarikçiye baskı yaparak anahtarı teslim ettirebilir; bu durumda yöntem çöker
- Golden key’e dayanmayan confidential computing yöntemleri mümkün olabilir, ancak mevcut yöntemler bu ölçüte ulaşmıyor
İlgili kaynaklar
- Mitigating the Hetzner/Linode XMPP.ru MitM interception incident, part 2: XMPP-specific mitigations: XMPP’ye özel azaltma önerileri
- Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service: asıl olay raporu
- ACME-CAA (RFC 8657)
- Let's Encrypt now supports ACME-CAA: closing the DV loophole
- Web-based cryptography is always snake oil
- Cloudflare considered harmful
1 yorum
Hacker News yorumları
https://notes.valdikss.org.ru/jabber.ru-mitm/ adresindeki saldırı özeti ilginç
Saldırgan, 18 Nisan 2023’ten itibaren Let’s Encrypt ile jabber.ru ve xmpp.ru için birden fazla SSL/TLS sertifikası çıkardı; 21 Temmuz’dan 19 Ekim’e kadar ise en azından XMPP STARTTLS 5222 portu üzerindeki istemci trafiğinin %100’üne ortadaki adam saldırısı uygulandığı doğrulandı
Daha sonra sertifika yenilemeyi başaramayınca jabber.ru’nun 5222 portunda süresi dolmuş bir sertifika sunmaya başladı; inceleme ve Hetzner/Linode ile iletişim başlatıldıktan hemen sonra saldırı durdu, ancak bazı Linode sunucularında ek bir yönlendirme sıçraması üzerinden pasif dinleme kalmıştı
Sunucunun kendisi hacklenmemiş gibi görünüyor; Hetzner ve Linode ağları XMPP hizmetinin IP’sini hedef alacak şekilde yeniden yapılandırılmışa benziyor
Ne ilgili sayfa ne de buradan bağlantı verilen sayfalar sertifika sabitlemeden söz ediyor; XMPP desteklemediği için mi bilmiyorum ama destekleseydi bu saldırı engellenemez miydi diye düşünüyorum
Ne yazık ki jabber.ru 2016 tarihli sunucu yazılımını kullanıyor; o eski sürüm bunu desteklemiyor
Günümüzde sertifika sabitleme, sertifika ömürleri kısa olduğu ve sık yenilendiği için çok sorunlu. Kullanıcıya her ay yeni sertifikayı kabul edip etmeyeceği sorulursa, saldırganın sertifikasında da pek düşünmeden “Accept” düğmesine basar
Kanal bağlama sertifikadan bağımsız çalışır ve TLS akışının beklenen tarafta sonlandırıldığını garanti eder
XMPP istemcilerinde CT/SCT desteğinin olmamasına odaklanılması tuhaf. Bu saldırıda Let’s Encrypt tarafından çıkarılmış ve CT günlüklerine de girmiş geçerli sertifikalar kullanıldığı için CT/SCT ile tespit edilemezdi
Katı CAA kayıtları olsaydı, başka bir sertifika otoritesinden sertifika çıkarılması gibi teorik bir durum SCT doğrulamasıyla yakalanabilirdi; ancak pratikte CAA da yoktu ve kanal bağlama gizlilik açısından daha dostça, üçüncü taraflara daha az bağımlı
Yani barındırılan HTTP üzerinden ACME protokolüne yanıt verebilmiş ya da DNS TXT kaydı yazabilmiş olmalı; bu da kurbanın zaten süreç sunucusu veya ad sunucuları üzerindeki denetimi kaybetmiş olduğu anlamına geliyor gibi görünüyor
Sertifika sabitlemenin ancak istemciyi kontrol edebildiğinizde mümkün olduğunu; izin verilecek sertifikayı doğrudan istemciye koyup web açık anahtar altyapısının tamamını devre dışı bırakma yöntemi olduğunu anlıyorum
Genel amaçlı istemcilerin bağlandığı bir durumda hangi sertifikanın kabul edilmesi gerektiğini bilmenin bir yolu yok; zaten web açık anahtar altyapısı tam da bunun için kullanılıyor
Elbette kendi istemcinizi sunsanız bile sorun yalnızca bir seviye yukarı taşınır; müşterinin özel istemciyi indirdiği yer ele geçirilip kötü amaçlı bir istemci dağıtılabilir
Bu listede en obvious savunma önlemi eksik. Kimlik doğrulama yöntemi olarak SCRAM-xxxxx-PLUS etkinleştirilmeli ve mümkünse zorunlu kılınmalı
PLUS varyantının fikri basit ama etkili: yalnızca salt ile doğrulamak yerine belirli TLS bağlantısına bağlayarak doğrular; böylece kimlik doğrulama yalnızca tek bir TLS bağlantısında geçerli olur
Buna kanal bağlama da denir
xmpp.ru ve jabber.ru’nun son kullanıcılarının kimler olduğunu merak ediyorum. Rus askerleri ya da casusları arasındaki trafiği yakalamaya mı çalışıyorlar? Kitlesel gözetimden hoşlanmıyorum ama neden özellikle Rus alan adlarının hedef alındığını da bilmiyorum.
Daha olası olan, carder ya da botnet operatörlerini yakalamaya yönelik bir senaryo. Jabber/XMPP, Rus tarafındaki o çevrelerde hâlâ epey popüler ve Krebs on Security gibi yazılarda da @exploit.in, @jabber.ru vb. çeşitli sunucuların göründüğü ekran görüntülerine ya da loglara sıkça rastlanıyor.
Yine de niyet ne olursa olsun, kitlesel gözetim çoğu zaman mide bulandırıcı bir şey.
İki sunucudaki suç amaçlı kullanım ile suç teşkil etmeyen kullanımın oranı tam olarak nedir bilmiyorum; ama Tor’da açıkça yasa dışı içeriklerle meşru kullanımın iç içe olması gibi, burada da tamamen sıradan konuşmaların epeyce bulunduğu kesin.
Bu yüzden, en başta iadesi bile zor olan, yargı alanı dışındaki rastgele siber suçluları izlemek için mahremiyetin ihlal edilmesini pek desteklemiyorum.
Hetzner’ın Lavabit gibi olmamak için işbirliği yapmak zorunda kalmış olabileceğini anlıyorum; ama sık sık tavsiye eden biri olarak, Hetzner’ın ortadaki adam saldırısını bilerek izin vermiş ya da buna yardım etmiş olması oldukça hayal kırıklığı olurdu. Bunun dışında onu en iyi hosting şirketlerinden biri olarak görüyorum.
Şeffaflığı iyi; çalışma süresi, güvenilirlik ve destek açısından çoğu bulut sağlayıcısından daha iyi; maliyeti de aşırı değil. Çevreci tasarımı ekonomik açıdan da akıllı bir tercihe dönüştürme çabaları da övgüye değer.
“Azalt > yeniden kullan > geri dönüştür” ilkesinde “azaltma”, KISS tasarımında görülüyor. Örneğin doğal ısı tahliyesine yardımcı olan yüksek ve eğimli çatılar[2], gerçek bir kasadan çok asgari yapısal destek ve hava akışı kapağına benzeyen sunucu kasaları, VRM·CPU·belleği tek bir fanla soğutmak için soketi 90 derece döndürülmüş standart anakart tasarımı[3] gibi şeyler.
“Yeniden kullanım” ise sunucu açık artırmalarında ortaya çıkıyor. Eski donanımı hurdaya ayırmak yerine Hollanda usulü açık artırma yöntemiyle kiralıyorlar; böylece hem yeni donanım maliyetinden hem de her nesilde yeniden üretimin çevresel maliyetinden kaçınıyorlar.
Avrupa dışında da dedicated server’ları olsaydı daha çok kullanmak isterdim.
[1]: “Yasal”ın kendisini tanımlamak da zor. Bir ülkenin gazetecisi başka bir ülkenin “yabancı ajanı”, bir ülkenin “özgürlük savaşçısı” başka bir ülkenin “teröristi”dir.
[2]: Der8auer: Over 200,000 Servers in One Place! Visiting Hetzner in Falkenstein - https://youtu.be/5eo8nz_niiM?t=259
[3]: Der8auer: Hetzner shows Special AM5 Board with 90° Rotated Socket - https://youtu.be/V2P8mjWRqpk
Yazıda “CT isteğe bağlıdır” deniyor ama nihayetinde buna XMPP istemcisinin karar vermesi gerekmez mi? Tarayıcılar artık fiilen bunu zorunlu tutarken, XMPP istemcilerinin CT istemesini engelleyen şey nedir merak ediyorum.
Tarayıcılarda çalışmayan sertifikalar veren hangi güven deposuna dayandıklarını da bilmiyorum.
Sorun şu ki CT isteme davranışı neredeyse hiçbir TLS kütüphanesinde varsayılan olarak açık değil. Bu yüzden XMPP istemcisi geliştiricisinin bunu bilerek açması gerekiyor ve şu anda çoğunun ya da tamamının bunu yapmadığını düşünüyorum. Elbette bu değişebilir.
Bu yazı XMPP’de OTR kullanılmasını öneriyor, ama ne yazık ki OTRv3 eski kriptografi kullanıyor ve OTRv4 henüz kesinleşmiş değil.
https://dustri.org/b/time-to-sunset-otr.html
“Kusursuz bir saldırgan ne yapardı?” sorusuna gelirsek, bilgisayara fiziksel erişim varsa bir tür veriyolu araya girme yöntemiyle cihazdan veri sızdırmak mümkün olabilir gibi geliyor.
Çevirmeli bağlantı ve düşük hızlı·yüksek gecikmeli genişbant döneminde bu mantıklıydı; ama bugün yüksek hızlı fiber ve peering noktalarına düşük gecikmeyle erişebilen pek çok yer var.
Veri merkezlerinden ve buluttan uzaklaştıkça internet altyapısının başta tasarlandığı gibi çalışması gerekir; bugün olduğu gibi ciddi arıza noktaları ve büyük güvenlik riski olan merkezi toplama noktalarından geçme ihtiyacı azalır.
CAA’ya baktım ama kullandığım DNS sağlayıcısı bu kaydı desteklemiyor. Neden daha yaygın olan TXT kaydı yerine yeni bir tip olması gerekiyordu, bunun bir nedeni var mı?
Bu da olmuyorsa destek istemeniz gerekir. CAA kaydı giderek daha çok kullanılan bir tip; bugün bunu desteklememek pek iyi bir hizmet göstergesi değil.
CAA tasarım tartışmalarını bilmiyorum, ama muhtemelen ilgili IETF e-posta listelerinde konuşulmuştur.
DNS sağlayıcılarının çeşitli RR tiplerini desteklemesi gerekir ve alan adı sahipleri NS kayıtlarıyla oy vermelidir.
CAA’yı destekleyen DNS sağlayıcılarının listesi https://github.com/StackExchange/dnscontrol/blob/master/docu... adresinde.
Gizli birincil sunucu kurup sağlayıcıyı yalnızca ikincil sunucu olarak bırakıp bırakamayacağınızı test etmeye değer. Linode’da bu kısıtı bu şekilde aşmıştım.
Kendi sertifika otoritenizi işletmek ve kök sertifikaları dikkatle seçmek seçeneği atlanmış.
Sağlayıcı ana makineye erişebildiği için işlemleri dışarıdan inceleyebilir ve kullanıcı bunu fark etmez
Örneğin çekirdek yükseltmesinden sonra bile hayatta kalacak ve kendini son derece iyi gizleyecek bir çekirdek modülü yerleştirmek gerekir. Yazıda ham bellek dökümü analizi de ele alınıyor
Devletler ya da onlara denk güçteki aktörlerin bu tür saldırılarına karşı temel teknik çözüm nedir? Serbestçe dağıtılabilen, ama yazarı dışında kimsenin sansürleyemediği, müdahale edemediği veya değiştiremediği yazılım gibi tuhaf bir hayali karşılamanın bir yolu var mı?
Mevcut internet altyapısı üzerinde düzgün tasarlanmış bir P2P sistemi yeterli bir yanıt olur mu, yoksa kablosuz çalışan, düşük bant genişlikli küresel bir mesh interneti ayrıca mı kurmak gerekir?
Freenet 2023’ün P2P uygulamaları için sürtünmesiz bir geliştirici deneyimine doğru evrilmesini umuyorum