Bu doküman SSL’ in web ve masaüstü uygulamalarinda kullaniminin güvenligine deginmektedir ve SSL/TLS ile ilgili kriptografik sorunlar bu dokümanin disindadir. Doküman soru-cevap formatinda yazildi, özellikle yazilim gelistiren kisilerin ve güvenlik ile ilgili kisilerin ilgisini çekebilir.
Asagidaki listenin bir çogu SSL kullanan yazilimlarda yapilan genel hatalardir. Burada yapilan önerilerin bir çogu özellikle e-bankacilik, e-ticaret gibi kritik uygulamalar önemlidir.
HTTPS üzerinden üye girisi yapildiktan sonra uygulamayi HTTP üzerinden çalistirmak güvenli mi?
Hayir. Üye girisi boyunca ve üye girisinden sonraki tüm ekranlar HTTPS üzerinden olmalidir.
Bunun bir çok nedeni var:
-
Üye girisinden sonraki sayfalar kisisel bilgi içeriyor olabilir;
-
Uygulama sizi hatirlamak için bir çesit oturum cookie (session cookie)’ si kullanacaktir. Bu data URL üzerinde olabilir ya da cookie olarak HTTP Header’ lari ile transfer ediliyor olabilir. Bunun bir önemi yok, her sekilde saldirgan bu bilgiyi görebilecektir. Bunu görebilen bir saldirgan o kullanici olarak uygulamaya giris yapabilir.
Eger uygulama özel bir Oturum Çalma (Session Hijacking) sistemi kullaniyorsa, “HTTP Only” cookie kullaniyorsa ya da IP kisitlamasi, NTLM oturumu gerektiriyorsa saldirgan XSS Tunnel’ gibi bir uygulama kullanarak bunlari asabilir.
-
Saldirgan web sitesinden gelen cevaplari degistirebilir, bu durumda web sitesi farkli gözükecektir. Bu sayfalara sahte bir login sayfasi koyabilir ya da bir cevaplara JavaScript kodu ekleyerek, sifre, kullanici adi vs. gibi bilgileri çalabilir.
Bu hata Google Gmail tarafindan yapilmisti,hala da Gmail HTTP üzerinden çalisiyor ve kullanicisi HTTPS’ e zorlamiyor.
Üye Giris Formunu HTTP adresine koyup Formun hedefini HTTPS yapmak güvenli midir?
Hayir, feci bir fikir. Bu genel bir hata ve Godaddy gibi firmalar hala bunu yapmaktadir.
-
Saldirgan web sunucusundan gelen cevaplari degistirebilir ve bu cevaplara JavaScript kodu ekleyebilir. Bu kod sayesinde kullanici adi ve sifre henüz HTTPS üzerinden gönderilmeden bunlari çalabilir. Bu noktada MITM (Ortadaki Adam) olasiliklari çok fazla ve bir çok baska sey yapilabilir.
-
Bu siteyi phising saldirilarina daha da açik hale getirecektir. Çünkü kullanicilar formu her zaman HTTP üzerinden gönderdiklerinden bir phising saldirisi bu web sitesini hedef aldiginda da sitenini HTTPS üzerinden olmamasi bir sorun olusturmayacaktir. Bu özellikle DNS zehirleme destekli yapilan phising saldirilari için ölümcüldür. Unutmayin ki kullaniciya güvenli olmayi ögretmek sizin isiniz. Kullaniciya login ekranlarinda SSL oldugundan emin olmalarini ve bu SSL’ in sizin kurumunuza ait oldugunu gözlemlemelerini hatirlatmalisiniz. Bu sayede phising saldirilarinin önüne geçebilirsiniz.
-
Üye girisi bir URL adresi üzerinden olmalidir, bu adres ve formun gidecegi adreste HTTPS olmalidir.
Bir Web Sitesini SSL üzerinden çalistirmanin en iyi yolu nedir?
Web sitesine HTTP üzerinden erisimi tamamen kapatin, yönlendirme ya da linkleme bile yapmayin. Bu sayede kullanicilariniz siteye hiç bir zaman o adresten ulasmayacaklarini bilecekler. Bir phising saldirisnda da o adreste bir link veya üye giris formu görürlerse bir seyin yanlis oldugunu anlayacaklardir (umariz!). Buna karsi kullanicilarinizi uyardiniz degil mi?
Kullanicilarinin MITM saldirilarina karsi korumanin en iyi yollarindan biri onlari bu konuda egitmektir.
SSL ve Cookie’ ler?
SSL kullaniyorsaniz cooki’ leri her zaman “secure” olarak belirtmelisiniz. (mark as secure). Bu tarayicinizin bu cookie’ leri sadece SSL üzerinden gönderecegi anlamina gelir.
Sizin siteniz normalde HTTP üzerinden çalismiyor olsa bile saldirgan kurbanin tarayicisina baska HTTP baglantilardan gelen istekleri degistirip sizin sitenize kurbanin HTTP üzerinden istek yapmasini saglayabilir. Sizin HTTP servisiniz (port 80 genelde) açik olmasa bile bir önemi yok çünkü MITM noktasinda saldirgan her türlü istegi görebilir ve gerekirse cevaplayabilir.
Bu tip saldirilari önlemek için buna dikkat etmeniz çok önemlidir.
Web üzerinden olmayan uygulamalarda SSL’ i nasil implemente etmeliyim?
Uygulamaniz geçersiz sertifikalara güvenmemeli! Eger uygulamaniz sertifikalari kontrol etmiyor ve her türlü sertifikayi kabul ediyorsa o zaman SSL kullanmaniz neredeyse anlamsizlasiyor çünkü uygulamaniz her türlü MITM saldirisina karsi açik olacaktir. Uygulamanin özelliklerine göre bu saldirilar sayesinde saldirgan kurbanin sisteminde istedigi kodu çalistirabilir.
Bu sorun özellikle özel gelistirilmis yazilimlarda bulunmakta. Genelde gelistiriciler test ortamlarinda gerçek bir sunucu ile çalismadiklarindan sertifika kontrolüne kapatiyorlar ve ugulamayi da daha sonra o sekidle dagitiyorlar.
Normal sartlar altinda bir çok SSL API’ i sertifikayi kontrol edecek ve geçerli degilse hata verecektir.
Web Uygulamalari harici uygulamalarda SSL kullanmali miyim?
Evet, kullanmalisiniz. Uygulamanin özelliklerine göre bunu yapmamaniz basit saldirganin kullanicinin sisteminde kod çalistirabilmesine izin verebilir.
Özellikle asagidaki iki özellik buna neden olabilir:
-
Otomatik güncelleme
Saldirgan download edilen dosyalari degistirebilir. Burada download dosyasi ve uygulamanin davranislarina bir dizi degisik saldirigi teknigi bulunmaktadir.
-
HTML bilgiyi Internet Explorer gibi bir controller ile local-zone altinda render etmek. Unutmayin ki SSL kullanmayan her uygulamada Cross-site Scripting açigi bulunmaktadir.
Firefox’ ta bu açik vardi. Diger bir örnek ise bir Vista Gadget’ in da tespit edilmisti.
Offline olarak kullanilacak bir Siparis Formunu HTTP üzerinden yayinlayabilir miyim?
Hayir!, bunun güvenli olacagini düsünebilirsiniz çünkü doldurulan data hiç bir zaman sunucuya gönderilmeyecek dolayisiyla bir saldirgan bunu göremeyecektir. Ama yanlis düsünüyorsunuz.
Daha öncede de anlattigimiz gibi bir saldirgan bu formun içerisine JavaScript kodu koyabilir ve kullanici formu göndersede göndermesede bu formun içerisindekileri çalabilir.
Ayni nedenden dolayi kritik PDF formlarini da HTTP üzerinden yayinlamak iyi bir fikir degil. Çünkü saldirgan formu degistirebilir, mesela formun gönderilecegi adresi baska bir adrese çevirerek kullanici bilgilerini toplayabilir.
Her türlü kisisel bilgi girilmesi gerektiren form HTTPS üzerinden yayinlanmalidir.
SSL’ de Zayif cipher’ lari desteklemeli miyim?
Hayir, desteklememelisiniz. Bu tip zayif cipher’ lari desteklemenin ana nedeni eski tarayicilari desteklemektir. Eski tarayicilarin bir çogunda çok ciddi açiklar oldugundan, bu tip tarayicilari tamamen kabul etmemek daha iyi bir fikirdir. Çünkü bu kullanicilarin sistemlerinin zaten çesitli enfekte olmus olma ihtimali çok büyüktür.
Mesela Paypal resmi olarak artik eski tarayicilari desteklemedigini belirtti.
Zayif Cipher’ lara izin verip daha sonradan onlarin uygulamaya erismesini yasaklayabilir miyim?
Hayir, bu genelde uygulamada olan kötü fikirlerden biri. Mesela kullanici siteye giriyor ve site ona zayif cipher desteginden dolayi tarayicisini degistirmesini ve tekrar gelmesini söylüyor.
Bu cipher’ lar “zayif” olarak adlandiriliyorlar çünkü kabul edilibilir bir vakitte kirilabilirler, bu da iletisimin okunmasina izin verir.
Bunu yapmak tehlikeli çünkü bu ilk SSL baglantisinda kullanicinin tarayicisi tüm cookileri gönderecektir (SSL olarak isaretlenmis cookie’ lerde dahil olmak üzere).
Bu saldiri özellikle sunucu SSLv2 kullaniyorsa önemlidir, bu sayede saldirgan baglantiyi daha düsük bir cipher’ a zorlayabilir, bu durumda hali hazir SSL cookie’ leri olan bir kullanici zayif cipher’ lar ile ayni sisteme baglanmis olacaktir. Bu noktada sonra saldirgan topladigi bu paketleri kirabilir ve kullanicinin cookie’ lerine erisebilir.
ActiveX Güvenligi ve SSL
Eger web uygulamanzi özel bir ActiveX gerektiriyorsa ve eger bu ActiveX uygulamasi normalde tehlikeli olabilecek bir sey (kod çalistirma, dosya okuma, sistem bilgisi vs.) yapiyorsa ActiveX’ inizi kendi domain adresinize kitlemelesiniz. Yani o ActiveX sadece sizin domaininiz üzerinden ulasilabiliyor olmali. Bu sayede baska bir site onu çagirip bu islemleri yapamaz.
Eger ActiveX’ inizi domainize kitlediyseniz ama HTTP / HTTPS ayrimi yapmadiysaniz saldirgan HTTP üzerindeki cevaplari adegistirerek bu ActiveX’ i istedigi sekilde çagirabilir.
ActiveX’ inizi sadece HTTPS üzerinden ve sadece sizin domaininizde çalisacak olarak kodlamalisiniz.
Download, Hash Imzalari ve SSL
Bir çok web sitesi dosya download’ lari ile MD5, SHA1 gibi hashlerde sunuyor. Bu sistemi dosya’ nin bozulup bozulmadigi kontrol etmek için gayet iyi bir yöntem ancak HTTP üzerinden bunu yapmak güvenlik açisindan hiç bir sey saglamiyor.
Saldirgan MITM saldirisinda dosyalari degistirebildigi gibi HTTP cevaplarini degistirip bu imzalari da yeni degistirilen dosyanin imzasi ile eslestirebilir.
Internet Explorer Güvenli Bölge (trusted zone) Gerektiren Uygulamalar ve SSL
Bazi web uygulamalari Internet Explorer’ un ayarlarindan o sitenin “Güvenilir” listesine eklenmesini gerektiriyor, bu sayede normalde mümkün olmayan ActiveX yükleme, sistemden dosya okuma vs. gibi islemleri yapabiliyorlar.
Eger bu islem gerçekten gerekmiyorsa bunu yapmayin. Eger gerekliyse bu islem sadece HTTPS üzerinden olan siteler için yapilmali. Kullanici olarakda hiç bir HTTP sitesini bu listeye eklememelisiniz.
Bunun neden HTTP istekleri degistirilebilir ve saldirgan “Güvenilir Site” haklari ile sisteminizde kod çalistirabilir. (IE 7 varsayilan olarak IE 6 gibi kod çalistirmaya varsayilan olarak izin vermiyor ancak gene de bir çok eksta atak mümkün)
3. Parti Tarayici Eklentileri ve SSL
HTTP.1.1 RFC 2616 tarayicilarin HTTP Referrer’ lari SSL üzerinden yapilan baglantilar için gönderilmemesi gerektigini açikça ifade etmektedir.
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
Bunun nedenleri:
-
URL’ lerdeki SessionID’ leri HTTP üzerinden transfer edilmesi – Kritik
-
URL adreslerinde arama kelimesi gibi bilgilerin sizmasi,
-
Gizli URL adreslerinin sizmasi.
Diigo Toolbar gibi bazi 3. parti yazilimlar HTTPS adreslerini de kendi sunucularina HTTP üzerinden gönderiyorlar, bu da tabii ki yukaridaki sorunlara neden oluyor. Gelistirici olarak bu hataya düsmemeniz ve kullanici olarak kullandiginiz eklentilerin neler yaptigina dikkat etmeniz gerekli.
HTTP ve HTTPS (Mixed Content) ayni sayfada olmasi neden kötüdür?
Tarayicilar bazen ayni sayfada HTTP ve HTTPS baglantisi var diye sizi uyarir. Bunun nedeni HTTPS sitelerinde HTTP üzerinden gelen bir Flash ya da Javascript dosyasinin olmasidir.
Bu durumda saldirgan bu disaridan gelen dosya içerigini degistirebilir ve JavaScript ile HTTPS üzerindeki sayfadan bilgi çalabilir ve oturuma erisebilir.
Bu yüzden tarayicinizin lafini dinlemeli ve ayni zamanda gelistirici olarak HTTPS üzerinden yayinlanan sayfalarinizda HTTP üzerinden flash,javascript vs. gibi disaridan kaynaklar çagirmamalisiniz.
SSL Sertifika hatasi veren sitelere güvenmeli miyim?
Kisa cevap : Hayir, güvenmemelisiniz. Uzun cevap için devam edin.
Bu hatanin bir kaç neden olabilir:
-
SSL Sertifikasi sizin sisteminizin güvenmedigi biri tarafindan imzlanmistir
-
SSL Sertifikasinin kullanim süresi dolmustur
-
SSL Sertifikasi degismistir
-
Biri MITM saldirisi yapiyordur, dolayisiyla size imza hatasi gözüküyordur
-
Sayfadaki içerigin bir kismi HTTP üzerinden geliyordur
Bu durumlarin hepsi kötü, ve kesin olarka ne yaptiginizi detayli sekilde bilmiyorsaniz hayir güvenmemelisiniz.
SSL Neden Gereklidir?
Internette iletisim bilgisayarlar üzerinden yapilir, dolayisiyla bir websitesini ziyaret ederken gönderdiginiz istek ve web sitesinden gelen cevap bir dizi system üzerinden geçer. Bu aradaki tüm sistemler bu istegi ve cevabi görebilir. Bu noktada SSL devreye girer ve bu bilgilerin aradaki sistemler tarafindan görülmesini engeller. SSL’ in ayni zamanda kimlik dogrulama özelligi vardir, bu konunun detaylari için “SSL Sadece Kimlik Dogrulama mi yapar?” ve “SSL Sadece Sifreleme mi Yapar?” sorularina göz atabilirsiniz.
SSL sadece üye girisi gerektiren sitelere için midir?
Hayir, Eger kullanici ve site arasindaki bilginin kisisel oldugunu düsünüyrosaniz o zaman SSL kullanmalisiniz.
Su özelliklerin bir çogu SSL üzerinden olmalidir:
Arama sayfalari biraz paranoyakça gözükebilir ama adresinizi (google maps), hastaliklariniz ile ilgili aramalarinizin, aradiginiz isimlerin ve ürünlerin herkes tarafindan gözükmesini ister miydiniz?
SSL sadece Sifreleme mi?
Hayir, SSL kimlik tanimlama ile de ilgilidir. Bir SSL sertifikasini bilinen bir CA’ den alarak kim oldugunuzu kullanicilara kanitlayabilirsiniz. Ziyaretçilerde sertifikayi kontrol ederek CA tarafindan onaylanmis bu bilgileri görebilir.
Bu çok güvenli bir yöntem degil, çünkü yanlis bilgi ile sertifika almak o kadar zor bir is degil.
Ek olarak SSL ziyaretçinini kendini sunucuya tanitmasinda da kullnilabilir ki bu yukaridakinden farkli olarak kesin bir tanimlamadir.
HTTP’ yi iptal etmeli miyim?
Eger yapabilirseniz Evet, Bu yapabileceginiz en iyi seylerden biri. 80/HTTP portunu tamamen kapatmak kullanicilarinizi bir çok phising saldirisindan koruyacak ve sizi bir dizi SSL hatasi yapmaktan koruyacaktir.
