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><guvenatba...@gmail.com> >>> *To:* Linux'la ilgili sınırsız tartışma ve haberleşme listesidir >>> <linux-sohbet@liste.linux.org.tr> <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 >>> >>> >>> >>> >>> _______________________________________________ >>> Linux-sohbet mailing >>> listlinux-soh...@liste.linux.org.trhttps://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 >>> >>> >> >> >> _______________________________________________ >> Linux-sohbet mailing >> listlinux-soh...@liste.linux.org.trhttps://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 >> >> > > _______________________________________________ > 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
