SSL Revocation Mekanizmasına Endişeli Bir Bakış

SSL Revocation Mekanizması Sıkıntılı!

HTTPS için kullandığımız sertifikalar herkese açıktır ve sitemize bağlanan herkese göndeririz. Ancak başkalarının bizim sertifikamızı kullanmasını engelleyen şey bizim özel anahtarımıza (private key) sahip olmamalıdır.

Eğer özel anahtarımız bir şekilde ele geçilirse artık sertifikamız başkaları tarafından da kullanılabilir.

Bu benim başıma gelmez diyorsanız Heartbleed’i hatırlatmakta fayda var. OpenSSL kütüphanesinde çıkan basit bir hata sonucu saldırgan sizin özel anahtarınızı çalabiliyordu.

Ayrıca böylesi bir saldırının hedefi olmak her zaman kullanıcı kaynaklı sebeplerden ötürü değil, bazen bizatihi yazılımın ya da protokolün kendisinden de kaynaklı olabilir. Uzun lafın kısası özel anahtar bir çok sebepten dolayı çalınmış veya ifşa olmuş olabilir. Böyle bir durumla karşılaştığımızda sertifikamızı iptal ettirmemiz gerekir. Nitekim 2014 yılındaki Heartbleed zafiyetinden ötürü CloudFlare managed sertifikalarını revoke etmiş idi.

Revocation

Sertifikamızın iptali gereken durumda CA (Certificate Authority) ile iletişime geçmeliyiz. Söz konusu sertifikanın sahipliğini kanıtladıktan sonra CA sertifikamızı iptal edildi olarak işaretleyecektir. Fakat bu durumdan tarayıcı da haberdar edilmeli. Tarayıcıyı haberdar etmek için kullanılan CRL ve OCSP adında 2 mekanizma bulunuyor.

CRL - Certificate Revocation Lists

CA’nın iptal edildi olarak işaretlediği tüm sertifikaların yer aldığı listeye CRL deniyor. İstemci, CRL ile bağlantı kurabilir ve bir kopyasını indirilebilir. Bu listeyi elinde bulunduran tarayıcı, sağlanan sertifikanın bu listede olup olmadığını kontrol edebilir. Sertifika bu listede yer alıyorsa kullanıcıya uyarı mesajı gösterir. Sertifika listede yoksa tarayıcı bağlantıya devam edebilir.

Buradaki problem ise CRL tüm iptal edilmiş sertifikaları içerdiği için boyutlarının ufak olmamasıdır. Diğer bir sorun ise istemci CRL’nin güncel kopyasına sahip değilse ilk bağlantı sırasında işlemin daha yavaş olacağıdır. Bu mekanizma çok mükemmel gözükmüyor öyle değil mi? Bir de OCSP’ye bakalım.

OCSP - Online Certificate Status Protocol

CRL’de tüm listeyi alıyorduk fakat OCSP’de sadece bir sertifikanın durumunu öğrenmek için talepte bulunuyoruz. Doğal olarak OCSP performans olarak CRL’den daha iyi fakat bunun için bir bedel ödüyoruz. Bu bedel maalesef gizliliğimiz oluyor :) Çünkü siz OCSP isteği gönderdiğinizde aslında CA’ya şunu sormuş oluyorsunuz:

example.com sertifikası geçerli mi?

Sonuç olarak bir nevi, gezinim geçmişinizi üçüncü bir taraf ile paylaşmış oluyorsunuz. Bunu yapmamızın temelinde HTTPS ile daha fazla güvenlik ve gizlilik sağlamak amacı var. Bu biraz ironik değil mi? Binlerce, hatta Let's Encrypt gibi milyonlarca sertifika imzalamış bir otorite düşünelim. Böyle bir CA sertifika imzalamayı tekeline aldığında, doğrudan doğruya kullanıcıların gezinimlerini elde edebilir. Bir nevi otorite eliyle pasif atağa imkan veren bir yöntem.

Buraya kadar CRL ve OCSP’den bahsettik. Bu iki mekanizma sayesinde istemci sertifikanın iptal edilmiş olduğunu anlayabiliyor. Daha iyi anlaşılması açısından aşağıdaki görsele bakalım:

Tarayıcı sertifikayı aldıktan sonra CRL veya OCSP servislerinden birine ulaşacak ve sertifikanın durumunu sorgulayacaktır. Fakat aşağıdaki görseldeki gibi CA’ya ulaşılamıyorsa?

CA altyapısı kötü bir gün geçiriyorsa yukarıdaki gibi bir tablo karşımıza çıkacak. Bu durumda tarayıcının yalnızca iki seçeneği var. Hard-fail ve Soft-fail. Hard-fail seçeneğinde sertifikanın durumunu tespit edemediği için sertifikayı kabul etmeyecek. Buradaki handikap şu, sırf CA'ya ulaşılamadığından geçerli bir sertifika için bir hata gösterilecek. Kimi bu durumu False Positive (Yanlış Bulgu) kategorisinde değerlendirse de, kimi de böylesi hataların, yani sürekli hatalar vasıtası ile kullanıcıdan girdi talep etmenin bir tür Security Warning Fatigue (Güvenlik İhtar Yorgunluğu) yol açacağını söylüyor. Böylesi durumlarda hata mesajlarını kapatmaya aşina olmuş bir kullanıcı, daha sonra daha kritik bir hata mesajı için de aynı refleksi gösterebiliyor.

Bir diğer mekanizma olan Soft-fail seçeneğinde ise browser revocation durumunu tespit edemediği sertifikayı kabul edecek. Soft-fail'de de CA'ya ulaşamaması ya da beklenen süre içerisinde cevap alamaması etkili oluyor. Aşağı tükürsen sakal yukarı tükürsen bıyık dediğimiz hadise tam olarak bu sanırım :) Çünkü sertifikanın durumunu kontrol edemediğinde kabul etmemesi demek; CA altyapısı çalışmadığı zaman sizin sitenizde çalışmayacak demektir. Eğer durumunu kontrol edemediği sertifikayı kabul ederse de bu sefer kullanıcılar risk altında olabilir demektir.

Aslına bakarsanız Google Chrome 2012 yılından beri sertifika revocation durumunu online olarak kontrol etmiyor. Scott Helme’e göre yakında Firefox’da bu davranışa katılacak. Çünkü, yukarıda bahsettiğimiz gibi; eğer tarayıcı CA altyapısına ulaşamaz ise veya cevabın dönmesi çok uzun zaman alırsa sertifikayı kontrol etmeden kabul etme yoluna gidebilir. Bunu MITM saldırısı yapan bir saldırgan aşağıdaki şekilde taklit edebilir:

Sonuç

Scott Helme, SSL Revocation mekanizmasının şu an tam olarak güvenli bir şekilde gerçekleştirmenin mümkün olmadığını söylüyor. Şu an net çözüm yok fakat alabileceğimiz bazı önlemler var. Örneğin sertifika süresini olabildiğince kısa periyotlarda alıp olası bir durumda kötüye kullanımdan, zamanın daha dar olmasından dolayı daha az etkilenebilirsiniz. Örneğin Let's Encrypt sertifikaları 90 günlük bir periyodda imzalıyor.

Ayrıca Scott Helme bu konu ile ilgili örnekte hazırlamış: revoked.scotthelme.co.uk eğer bu örneği açarken uyarı ile karşılaşıyorsanız tarayıcınız OCSP mekanizmasını kullanıyor demektir.

ocsp.int-x3.letsencrypt.org adresini ağınızda engellerseniz (host dosyanızdan 127.0.0.1’e atayarak da bu işlemi yapabilirsiniz) revoke edilmiş sertifikaya sahip olmasına rağmen sitenin yüklendiğini görebilirsiniz.

Daha fazla bilgi ve detay için Scott Helme’in blog yazısını okumanızı tavsiye ediyoruz: https://scotthelme.co.uk/revocation-is-broken/

Web Uygulamalarında Sıklıkla Yapılan 5 Güvenlik Hatası!

Pek çoğu bilindik ve apaçık bir hata olsa da, güvenlik uzmanı Ivan Novikov, son 5 yılda karşılaştığı güvenlik yanlışlarını bir blog postta derledi.

Apache'den Nginx'e Geçişte Konfigürasyon Dosyaları

.htaccess ve .htpasswd gibi Apache tarafından kullanılan güvenlik dosyalarının, Nginx için bir anlam ifade etmeyeceğini unutmamak gerekiyor. Sunucu tarafından yorumlanamayan tüm diğer dosyalar gibi bu saydıklarımız da olduğu gibi istemciye yollanacak, böylece konfigürasyon ayarlarının ifşasına yol açacaktır.

CDN Implementasyonları

Kaynak kod ifşasına sebebiyet veren bu yanlışlık sebebi CDN davranışlarının yeterince hesap edilmemesinden kaynaklanıyor. CDN'de barındırılan imaj ve diğer kaynaklar gibi, burada barındırılan script kodları da statik içerik olarak değerlendirilecek ve istemciye doğrudan yollanacaktır.

Örneğin: www.example.com/something.php kodu CDN sunucusu tarafından YORUMLANMAKSIZIN, dosya içeriği gönderilecektir.

Host Based Authentication Bypass

Referer, X-Forwarded-For, X-Real-IP gibi istek headerları üzerinden yapılacak kimlik ve yetki doğrulamaları bizleri hataya düşürebilir. Tüm bu istek headerları, saldırgan tarafından değiştirilebilir ve manipüle edilebilir headerlardır.

Örneğin, bir saldırgan pekala, istek yerel makineden kaynaklanıyormuşçasına ilgili headerları manipüle edebilir.

curl -X 'X-Forwarded-For: 127.0.0.1' http://i-protected-by-host-based-auth.com/

Virtual Host Abusing

Diğer headerlar gibi Host headerı da attacker tarafından set edilebilir.

curl -X 'HOST: staging.intranet' http://i-like-virt-hosts/

Crossdomain.xml Dosyası

Same Origin Policy dökümanında ayrıntıları ile paylaştığımız gibi, browserların origin konseptinin dışına çıkmak, pek çok uygulamada mümkün.

<allow-access-from domain="*" secure="false" />

Örneğin, wildcard ile farklı originlerden gelecek tüm isteklere izin veren bir crossdomain.xml dosyası vasıtası ile, saldırgan kendi sitesinde host ettiği bir Flash dosyası üzerinden, hedef siteye istek yapabilir. Üstelik browserlar, bu isteğe, hedef siteye ait geçerli Cookieleri de eklerler. Böylece saldırgan browserdaki cookieler ile istek yapıp, sonucu okuyabilir.

Ivan Novikov'un yazısı için:
https://medium.com/@d0znpp/top-5-stupid-security-mistakes-in-web-apps-2f26f52ebfaa