TTNet uzerinden metroethernet hizmeti aliyoruz, herhangi bir engelleme, baglanti sorunu vs. cikmadi. Video izlenebiliyor, en azindan simdilik.
-- A.Gurcan OZTURK Sent with Airmail From: Mustafa Aldemir Mustafa Aldemir Reply: Linux'la ilgili sınırsız tartışma ve haberleşme listesidir linux-sohbet@liste.linux.org.tr Date: 4 Mar 2014 at 09:14:55 am To: Linux'la ilgili sınırsız tartışma ve haberleşme listesidir linux-sohbet@liste.linux.org.tr Subject: [Linux-sohbet] Re: Sansüre karşı önlemler Merhaba, bu URL engelleme işi fiili olarak da başladı sanırım. Biraz önce bir arkadaşımın paylaştığı bir Youtube videosunu (http://youtube.com/watch?v=m1nCVWjASk0 ) izlemek istedim. Evdeki ADSL'e bağlı laptop ve telefonumda tarayıcıyla girmek istediğimde "This webpage is not available" hatası alıyorum. Evdeki 2 bilgisayarda da wget yaptığımda "Connection reset by peer" diyor, başına "www" eklemek farketmiyor. mustafa@ev:~$ wget http://youtube.com/watch?v=m1nCVWjASk0 --2014-03-04 08:55:11-- http://youtube.com/watch?v=m1nCVWjASk0 Resolving youtube.com (youtube.com)... 64.15.117.24, 64.15.117.23, 64.15.117.27, ... Connecting to youtube.com (youtube.com)|64.15.117.24|:80... connected. HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying. Aynı sayfayı ktunnel ve Google Translate ile görebiliyorum. Telefonumda wifi'ı kapatıp 3G'ye geçtiğimde görebiliyorum. Veya Almanya'daki sunucuda wget ile çekebiliyorum. "http"yi "https" ile değiştirdiğimde kendi bilgisayarımda da görebildim. Sonuç olarak, URL bazlı engelleme başlamış görünüyor. Ama (en azından şimdilik) https trafiğini kapsamıyor. Siz de deneyip sonucu bildirirseniz sevinirim. sevgiler... Mustafa From: Mehmet Gürevin <mehmetgure...@gmail.com> To: Linux'la ilgili sınırsız tartışma ve haberleşme listesidir <linux-sohbet@liste.linux.org.tr> Cc: linux-soh...@postaci.linux.org.tr Sent: Friday, February 28, 2014 12:45 PM Subject: [Linux-sohbet] Re: Sansüre karşı önlemler Kavramları biraz daha açmak adına; Bir şirket veya kurum, kendi kullanıcılarına self-signed sertifikaları ile HTTPS sunuyorsa bu durumdan kullanıcılar haberdar olur. Yani burada kullanıcı aslında iletişiminin SSL koruması altında olmadığını bilir, en azından ideal dünyada bilmesi gerekir. Bu konuda kurum ve firmaları iletişim özgürlüğünü engellediği için ne yazık ki suçlayamıyoruz zira adamlar hizmeti ben veriyorum, özel işlerin için kullanamazsın, benim işim için kullandığın hizmeti istersem izleyebilirim, bak bunu da sana haber veriyorum(tarayıcılarının güvenilir CA listesine eklemeleri için sertifika vermeleri mesela.) diyor. Bu işlem haber vermeksizin yapılıyorsa(örneğin kullıcılara önceden sertifika yüklenmiş istemciler sağlanıyor ve bilgi verilmiyorsa) bilgi verilmeksizin şirket telefonlarının kaydedilmesi, ofis alanlarının kamera ile izlenmesi gibi durumlardan bir farklılık arz etmeyecektir, hukuk sistemimizde bunun bir karşılığı olur mu emin değilim. Kullanıcılar için büyük tehlike, güvenilir kök sertifika(lar) ile imzalanmış HTTPS trafiğinin izlenebilmesi. Ankara Büyükşehir Belediyesi / EGO / TürkTrust örneğinde olduğu gibi, bir devlet kurumsal olarak, insanların farkına varmasının mümkün olmayacağı şekilde HTTPS trafiğini izlemeye kalkarsa (misal İran) bunu yapabilmesinin iki yolu var. (Embedded olarak yapılabilecek atakları es geçelim, örneğin Intel işlemcilerin AES komut seti, kapalı SSL kütüphaneleri vs.) 1. İnsanların güvendiği kök sertifikalarından birisine sahip olmak. (örneğin bu kök sertifikardan birisi ülkemizde TürkTrust -TSK ortaklığında, bakanlar kurulu kararı olmaksızın ticari sicile Türk ünvanı ile kaydolabilmiş güvenlik sicili lekeli bir firma -'da mevcut.) 2. Kendi sertifikanı insanların güvenilir listesine sokmak. (Trojan, virüs, zararlı içerikten çocukları korumak için devletin dağıttığı koruma yazılımı vs. ile gayet mümkün) Elbette engelleme yapabilmek için izlemek şart değil. Ancak doğru düzgün bir kripto ile kriptolanmış bir trafiğin paketleri izlenerek içeriğinin tahmin edilmesi yöntemi çok maliyetli ve başarımı verimsiz bir yöntem olacaktır, zira kriptolojik özetlerde, bloklarda zaman kaymasından faydalanır ve bu durum paket içeriklerinin sürekli değişmesine sebep olur. Sonuç olarak "dinlenmek istemiyorsanız konuşmayın", "yasa dışı bir iş yapmıyorsanız dinlenmekten korkmayın" titrinde bir yönetime sahip ülkenin sade vatandaşı olarak, iletişim protokollerinin takip edilmeyi gerçekten zorlaştıracak (crypt+p2p ağları vs.) kadar karmaşık hale gelene veya yasaların iletişim özgürlüğümü güvence altına inanandığım zamana kadar "varsayılan olarak güvensiz bölge" de çalışacağım. 28 Şubat 2014 10:12 tarihinde Kayra Otaner <ota...@gmail.com> yazdı: Merhabalar, Bu dediginiz durum TR'de su anda tum ulke genelinde olmasa da bir cok kurumda zaten yasaniyor. Universitelerden ozel kurumlara kadar bir cok firma kendi networklerine kurduklari "HTTPS Inspector" diye anilan proxy'leri kullanarak HTTPS tabanli requestlerden GET URL satirina karsi URL filtering yapabiliyor. Altyapilarinda CA kullanan bu tool'lardan OS olana ornek Untangled, proprietarypropriety olana ornek Cisco IronPort. Untangled, Eyluk 2013'de bu ozelligi sunmaya basladi (15 gun denemeyel, sonra ucretli olarak) : http://wiki.untangle.com/index.php/HTTPS_Inspector "When a client makes an HTTPS request, the Inspector first initiates a secure SSL connection with the external server on behalf of the client. While this session is being established, the inspector captures information about the server SSL certificate. Once the server session is active, the Inspector uses the details from the server certificate to create a new certificate that will be used to encrypt the session between the inspector and the client. This certificate is generated or loaded on the fly, and is created using the same subject details contained in the actual server certificate. The certificate is then signed by the internal CA on the Untangle server, and is used to establish a secure connection between the inspector and the client. Creating the certificate this way is necessary to eliminate security warnings on the client, but it does require a few extra steps to properly configure the client computers and devices on your network" Iron Port : http://www.cisco.com/c/dam/en/us/td/docs/security/wsa/wsa8-0/WSA_8-0-0_UserGuide.pdf Sayfa 187, baslik "Create Decryption Policies to Control HTTPS Traffic" CA'yi bypass etme yontemi : "You can also upload an intermediate certificate that has been signed by a root certificate authority. When the Web Proxy mimics the server certificate, it sends the uploaded certificate along with the mimicked certificate to the client application. That way, as long as the intermediate certificate is signed by a root certificate authority that the client application trusts, the application will trust the mimicked server certificate, too." Ticari firmalar, buyuk kurumlar zaten kullanicilarinin banka erisim bilgilerini, youtube videolarini vb diledikleri gibi bu ticari urunlerle dinleyebiliyorlar ve bunun onunde yasal engel yok. Turkiye geneline yayilirsa durum cok degismeyecektir maalesef. Bir diger yontem de, known media provider'larin media serv ettikleri IP/URL'lere olan HTTPS'i blocklamak. Bu da zaten kullanilan bir yontem, ve vimeo, youtube vs gibi provider'larin HTTPS yoksa HTTP'ye failback yap turu durumlari var. Konuyu daha genis incelemek isteyenlerin LI ya da Lawful Interception ile ilgili, ozellikle DPI (Deep Package Inspection) ile ilgili makalelere goz atmalarini oneriririm. Su anda halen gelistirildigini bildigim bir yontemle, IP flow'unun karakteristiklerine bakilarak, (pps/byte/frames etc) icerigin ne fuzzy logic'le kestirebilme yapilabiliyor. Yani NetFlow seviyesined bir bilgiye bakarak, youtube.com'da hangi video seyredildigini kestirebilmek mumkun ancak bunu seyredilirken bloklamak mumkun degil. Her iki urunle ilgili eger POC projesi ya da detayli isterseniz benimle temasa geceblirsiniz. Iyi calismalar Kayra Otaner 2014-02-26 1:35 GMT+02:00 Samed YILDIRIM <yildiri...@itu.edu.tr>: Yanlış yazmışım. Gidilmek istenen adres bilgisi internet paketlerinde 4. katmandan sonra (OSI Katmanları) yer alan bir veridir. URL bazlı engelleme veri paketlerinin 7. katman üzerinden inceleme yapılarak mümkün olabilir. Https'de ise şifreleme 7. katmanda gerçekleşir. Siz bir web sitesine erişimi SSL ile şifrelediğinizde veri paketlerindeki URL bilgisini de şifrelemiş oluyorsunuz. Veri paketindeki şifreli içerik çözümlenmeden erişilmek istenen URL tespit edilemez ve buna bağlı bir filtreleme gerçekleştirilemez. Bir de şu var. Arkadaşın önceki e-postalarda bahsettiği proxy cihazı ile SSL trafiğinin arasına girmek de mümkün ancak bu kadarını yapmalarına güvenlik nedeniyle özellikle internet üzerinden satış yapan firmalar, bankalar vs. kolay kolay müsade etmezler. Orada büyük oyuncular devreye gireceği için bu kadar kolay el kol oynatamazlar... İyi Çalışmalar Samed YILDIRIM On 02/26/2014 01:31 AM, Samed YILDIRIM wrote: Gidilmek istenen adres bilgisi internet paketlerinde 4. katmandan sonra (OSI Katmanları) yer alan bir veridir. URL bazlı engelleme veri paketlerinin 7. katman üzerinden inceleme yapılarak mümkün olabilir. Https'de ise şifreleme 7. katmanda gerçekleşir. Siz bir web sitesine erişimi SSL ile şifrelediğinizde veri paketlerindeki URL bilgisini de şifrelemiş oluyorsunuz. Veri paketindeki şifreli içerik çözümlenmeden erişilmek istenen URL tespit edilemez ve buna bağlı bir şifreleme gerçekleştirilemez. İyi Çalışmalar Samed YILDIRIM On 02/26/2014 01:21 AM, guvenatbakan . wrote: URL bazlı engellemenin https ile aşılmasındaki teknik durum nedir? 26 Şubat 2014 01:18 tarihinde Samed YILDIRIM <yildiri...@itu.edu.tr> yazdı: Merhabalar, URL bazlı engelleme https ile aşılabilir, IP bazlı bir engelleme yapıldığında maalesef bu da pek mümkün değil. İyi Çalışmalar Samed YILDIRIM On 02/25/2014 10:46 PM, Mustafa Aldemir wrote: teşekkürler. aslında benim tartışmak istediğim, kullanıcının sansürü aşma yöntemlerinden daha çok sunucu tarafında yapılabilecek bir şey olup olmadığı. sevgiler... Mustafa From: guvenatbakan . <guvenatba...@gmail.com> To: Linux'la ilgili sınırsız tartışma ve haberleşme listesidir <linux-sohbet@liste.linux.org.tr> Sent: Tuesday, February 25, 2014 8:12 PM Subject: [Linux-sohbet] Re: Sansüre karşı önlemler Gozetimin nasil yapilabilecegi uzerine bir ongoru: https://network23.org/kame/2014/02/22/suriyeden-turkiyeye-internet-sansuru/ Gozetime karsi teknik onlemler: http://kemgozleresis.org.tr Bu linkler yardimci olabilir. On Feb 25, 2014 5:58 PM, "Mustafa Aldemir" <m_alde...@yahoo.com> wrote: Merhaba, sanırım herkes yeni çıkan yasayla internette uygulanmak istenen sansürün farkındadır. Yeni yasa mahkeme kararı olmadan engellemeler yapılabilmesine (ki zaten yapılıyordu) ek olarak servis sağlayıcılara trafiğin de kaydedilmesi zorunluluğu getiriyor. En son dün gece ortaya çıkan kasetlerle bu yasanın gerekçesini daha da net görmüş olduk. Elbette bilinçli bir kullanıcı olarak VPN, tünel, proxy vs. yöntemlerle engellemeleri aşmak mümkün ama bunları uygulayabilecek teknik bilgisi olan insanların sayısı sınırlıdır diye tahmin ediyorum. Peki, sunucu tarafında bu engellemelere karşı ne gibi bir önlem alınabilir? URL ve IP bazlı engellemeden bahsediliyor. Bu engellemeler teknik olarak nasıl uygulanacak, bilgisi olan var mı? sevgiler... Mustafa _______________________________________________ Linux-sohbet mailing list Linux-sohbet@liste.linux.org.tr https://liste.linux.org.tr/mailman/listinfo/linux-sohbet Liste kurallari: http://liste.linux.org.tr/kurallar.php
_______________________________________________ Linux-sohbet mailing list Linux-sohbet@liste.linux.org.tr https://liste.linux.org.tr/mailman/listinfo/linux-sohbet Liste kurallari: http://liste.linux.org.tr/kurallar.php
