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
