Her Tor kullanıcısının aktarıcı olmasını zorunlu kılmak, ağın tüm kullanıcılarımızı idare edecek şekilde ölçeklendirilmesine yardımcı olur ve bir Tor aktarıcısı işletmek anonimliğinize yardımcı olabilir.
Ancak, birçok Tor kullanıcısı iyi bir aktarıcı olamaz. Örneğin, bazı Tor istemcileri kısıtlayıcı güvenlik duvarlarının arkasından çalışır, modem üzerinden bağlanır veya trafiği aktarabileceği bir konumda değildir.
Bu istemcilere hizmet sunmak, herkes için etkin anonimlik sağlamanın önemli bir parçasıdır. Çünkü birçok Tor kullanıcısı bu veya benzeri kısıtlamalara tabidir ve bu istemcileri katmak anonimlik kümesinin boyutunu artırır.
Gene de Tor kullanıcılarını aktarıcı işletmeye teşvik etmek istiyoruz. Bunun için gerçekten yapmak istediğimiz şey bir aktarıcı kurma ve işletme sürecini basitleştirmek.
Son birkaç yılda kolay yapılandırma konusunda çok ilerleme kaydettik. Tor, erişilebilir olup olmadığını ve ne kadar bant genişliği sunabileceğini otomatik olarak algılamakta iyidir.
Yine de bunu yapmadan önce çözmemiz gereken dört konu var:
İlk olarak, izin verilecek doğru bant genişliğini otomatik olarak öngörmede daha da iyi olmamız gerekiyor.
UDP taşıyıcısına geçmek buradaki en basit yanıt olabilir. Ne yazık ki hiç de basit bir yanıt değil.
İkinci olarak, hem ağın (tüm Tor aktarıcılarının tüm Tor aktarıcıları ile bağlantı kurma gerekliliğini nasıl kaldırırız) hem de dizinin (tüm Tor kullanıcılarının tüm Tor aktarıcıları hakkında bilgi sahibi olması gerekliliğini nasıl kaldırırız) ölçeklenebilirliği üzerinde çalışmamız gerekiyor.
Bunun gibi değişikliklerin potansiyel ve gerçek anonimlik üzerinde büyük etkisi olabilir.
Ayrıntılı bilgi almak için zorluklar belgesinin 5. bölümüne bakabilirsiniz.
UDP taşımacılığı burada da yardımcı olacaktır.
Üçüncüsü, siz kendi anonimleştirilmiş trafiğinizi başlatırken bir saldırganın aktarıcınız üzerinden trafik göndermesine izin vermenin risklerini daha iyi anlamamız gerekiyor.
Üç farklı araştırma makale, aday aktarıcılar aracılığıyla aktarılan trafiği ve devre etkinken trafikteki düşüşlere bakarak bir devredeki aktarıcıları tanımlamanın yollarını açıklıyor.
Bu tıkanma saldırıları, Tor bağlamında aktarıcılar hiçbir zaman istemci olmadığı sürece o kadar korkutucu olmaz.
Ancak, daha fazla istemcide aktarıcı işlevinin (köprü aktarıcıları veya normal aktarıcılar olarak) sağlanmasını teşvik etmeye çalışıyorsak, bu tehdidi daha iyi anlamamız ve nasıl azaltılacağını öğrenmemiz gerekir.
Dördüncüsü, insanları trafiği başkaları için aktarmaya ve/veya çıkış noktaları olmaya özendirmek için bir tür teşvik planına gerek duyabiliriz.
Tor teşvikleriyle ilgili güncel düşüncelerimiz.
Lütfen bu konularda bize yardımcı olun!
Aktarıcı işletmecilerinin, site tarafından kapsanabilecek tüm IP adres alanını öğrenmelerini istemek (ve ardından bu IP adreslerini kullanan diğer siteleri de engellemek) yerine, çıkış ilkelerinde reject www.slashdot.org gibi şeyler söylemelerine izin vermek güzel olurdu.
Ancak bununla ilgili iki sorun var.
İlk olarak, kullanıcılar yine de bu engellemeleri aşabilir.
Örneğin, Tor ağından çıktıklarında sunucu adı yerine IP adresini isteyebilirler.
Bu, işletmecilerin yine de söz konusu hedefler için tüm IP adreslerini öğrenmesi gerektiği anlamına gelir.
İkinci sorun, bunun uzak saldırganların keyfi siteleri sansürlemelerine izin vermesidir.
Örneğin, bir Tor işletmecisi, www1.slashdot.org sitesini engelliyorsa. Ardından bir saldırgan Tor aktarıcısının DNS kayıtlarını zehirlerse veya sunucu adını büyük bir haber sitesinin IP adresini çözümleyecek şekilde değiştirirse, bu Tor aktarıcısı haber sitesini engelliyor olur.
Hayır, yolu seçmesi için ağa güvenemezsiniz.
Kötü niyetli aktarıcılar, sizi gizli anlaşma yapan arkadaşları aracılığıyla yöneltebilir.
Bu durum, bir düşmana tüm trafiğinizi uçtan uca izleme yeteneği verir.
Bu yaklaşım, birkaç nedenle kullanışlı olacaktır:
Tor VoIP gibi yeni iletişim kurallarını daha iyi işleyebilecektir.
Uygulamaları socks üzerinden geçirme gereksinimini tümüyle çözebilir.
Çıkış aktarıcıları tüm çıkış bağlantıları için çok sayıda dosya tanımlayıcısı ayırmaya gerek duymaz.
Bu yönde ilerliyoruz. Bazı zor sorunlar şunlardır:
IP paketleri, işletim sistemi özelliklerini ortaya çıkarır.
TCP parmak izi saldırıları gibi şeyleri durdurmak için hala IP düzeyinde paket normalleştirmesi yapmamız gerekecek.
Aygıt parmak izi saldırılarıyla birlikte TCP yığınlarının çeşitliliği ve karmaşıklığı göz önüne alındığında, en iyi seçeneğimiz kendi kullanıcı alanı TCP yığınımızı göndermek gibi görünüyor.
Uygulama düzeyindeki akışların yine de temizlenmesi gerekir.
Hala Torbutton gibi kullanıcı tarafı uygulamalara gerek duyacağız.
Böylece yalnızca paketleri yakalayıp IP katmanında anonim hale getirmek yetmeyecek.
Yine de bazı iletişim kuralları bilgi sızdıracaktır.
Örneğin, DNS isteklerini kullanıcının hizmet sağlayıcısındaki DNS sunucusu yerine bağlantı kurulamayan bir DNS sunucusuna teslim edilecek şekilde yeniden yazmalıyız. Bunun için de, aktardığımız iletişim kurallarını anlamalıyız.
DTLS (veri şeması TLS) temelde herhangi bir kullanıcıya sahip değildir ve IPsec kesinlikle büyüktür.
Bir taşıma yöntemi seçtikten sonra, düşmelere, yeniden göndermelere vb. izin verdiğimiz için etiketleme saldırıları ve diğer olası anonimlik ve bütünlük sorunlarından kaçınmak için yeni bir uçtan uca Tor iletişim kuralı tasarlamamız gerekiyor.
Rastgele IP paketleri için çıkış ilkeleri, güvenli bir izinsiz giriş algılama sistemi (IDS) oluşturmak anlamına gelir.
Nokta işletmecilerimiz bize, Tor işletmeye istekli olmalarının ana nedenlerinden birinin çıkış ilkeleri olduğunu söylüyor.
Çıkış ilkelerini işlemek için bir izinsiz giriş algılama sistemi eklemek, Tor güvenlik karmaşıklığını artıracak ve tüm izinsiz giriş algılama sistemi ve karşı izinsiz giriş algılama sistemleri ile ilgil makalelerde kanıtlandığı gibi büyük olasılıkla çalışmayacaktır.
Birçok olası kötüye kullanım sorunu, yalnızca geçerli TCP akışlarının (hatalı biçimlendirilmiş paketler ve IP selleri ile birlikte rastgele IP adresinin aksine) Tor tarafından taşınması gerçeğiyle çözülür.
IP paketlerini aktarabildiğimiz için çıkış ilkeleri daha da önemli hale geliyor.
Ayrıca, istemcilerin hangi noktaların paketlerinin çıkmasına izin vereceğini öngörebilmeleri için Tor dizininde çıkış ilkelerini kompakt bir şekilde tanımlamamız gerekiyor.
Ayrıca istemcilerin çıkış noktalarını seçmeden önce bir oturumda göndermek isteyecekleri tüm paketleri öngörmesi gerekir!
Tor içi ad alanlarının yeniden tasarlanması gerekir.
Onion hizmeti ".onion" adreslerini, Tor istemcisine gönderilirken tutarak destekliyoruz.
Bunu IP düzeyinde yapmak, Tor ile yerel DNS çözümleyici arasında daha karmaşık bir arabirim gerektirecektir.
