İnternetin dev bir boru hattı gibi işlediği kişisel verilerin miktarı göz önüne alındığında, şifrelemeyi hafife almamız veya göz ardı etmemiz mümkün değildir. Modern tarayıcılar, kullanıcılarınızın verilerinin aktarım sırasında güvende olmasını sağlamak için kullanabileceğiniz çeşitli mekanizmalar sunar. Güvenli çerezler ve Katı Aktarım Güvenliği bunlardan en önemlileridir. Bu sertifikalar, bağlantılarını HTTPS'ye yükselterek kullanıcılarınızı sorunsuz bir şekilde korumanıza olanak tanır ve kullanıcı verilerinin hiçbir zaman açık olarak gönderilmeyeceğinin garantisini verir.
Bu konu neden önemli? Şunu göz önünde bulundurun:
Bir web sayfasını şifrelenmemiş bir HTTP bağlantısı üzerinden yayınlamak, sokakta posta ofisine doğru yürüyen ilk kişiye mühürlenmemiş bir zarf vermekle hemen hemen aynıdır. Şanslıysanız paketi teslimat noktasına kadar kendisi götürebilir veya doğru yönde giden bir sonraki kişiye verebilir. Bu kişi de aynısını yapabilir ve bu böyle devam eder.
Bu anlık zincirdeki yabancıların çoğu güvenilirdir ve açık mektubunuzu asla göz atmaz veya değiştirmez. Ancak mektup ne kadar çok el değiştirirse gönderdiğiniz mektuba tam erişimi olan kullanıcıların sayısı da o kadar artar. Sonunda, mektubunuzun amaçlanan alıcısı postayla bir şey alırsa da bu şeyin, ilk başta teslim ettiğiniz şeyle aynı olup olmadığı belirsizdir. Belki de bu zarfı kapatmalıydınız…
Aracılar
İyi veya kötü, internetin büyük bir kısmı yabancıların güvenilirliğine dayanır. Sunucular doğrudan birbirine bağlı değildir ancak devasa bir telefon oyunu oynar gibi istekleri ve yanıtları yönlendiriciden yönlendiriciye iletir.
Bu atlamaları traceroute ile görebilirsiniz. Bilgisayarımdan HTML5Rocks'a giden rota şu şekilde görünür:
$ traceroute html5rocks.com
traceroute to html5rocks.com (173.194.71.102), 30 hops max, 60 byte packets
1 router1-lon.linode.com (212.111.33.229) 0.453 ms
2 212.111.33.233 (212.111.33.233) 1.067 ms
3 217.20.44.194 (217.20.44.194) 0.704 ms
4 google1.lonap.net (193.203.5.136) 0.804 ms
5 209.85.255.76 (209.85.255.76) 0.925 ms
6 209.85.253.94 (209.85.253.94) 1.226 ms
7 209.85.240.28 (209.85.240.28) 48.714 ms
8 216.239.47.12 (216.239.47.12) 22.575 ms
9 209.85.241.193 (209.85.241.193) 36.033 ms
10 72.14.233.180 (72.14.233.180) 43.222 ms
11 72.14.233.170 (72.14.233.170) 43.242 ms
12 *
13 lb-in-f102.1e100.net (173.194.71.102) 44.523 ms
13 atlama aslında kötü değil. Ancak HTTP üzerinden istek gönderiyorsam bu ara yönlendiricilerden her biri isteklerime ve sunucuların yanıtlarına tam erişime sahiptir. Tüm veriler şifrelenmemiş düz metin olarak aktarılır. Bu aracılardan herhangi biri aracı olarak hareket ederek verilerimi okuyabilir veya hatta aktarma sırasında verileri değiştirebilir.
Daha da kötüsü, bu tür müdahaleler neredeyse tespit edilemez. Alınan verilerin _tam olarak_ gönderilen veriler olduğundan emin olmanızı sağlayacak bir mekanizma olmadığından, kötü amaçlı olarak değiştirilmiş bir HTTP yanıtı tam olarak geçerli bir yanıt gibi görünür. Eğlenmek için internetimi altüst etmeye karar veren biri olursa pek şansım olmaz.
Bu güvenli bir hat mı?
Açık metin HTTP'den güvenli bir HTTPS bağlantısına geçmek, aracılara karşı en iyi savunmanızı sağlar. HTTPS bağlantıları, herhangi bir veri gönderilmeden önce kanalın tamamını uçtan uca şifreler. Bu sayede, siz ile hedefiniz arasındaki makinelerin aktarılan verileri okuması veya değiştirmesi imkansız hale gelir.
HTTPS'nin sağladığı güvenlik, ortak ve özel kriptografik anahtar kavramına dayanır. Ayrıntıların ayrıntılı bir şekilde tartışılması (ne mutlu ki) bu makalenin kapsamının çok ötesindedir ancak temel önerme oldukça basittir: Belirli bir ortak anahtarla şifrelenmiş verilerin şifresi yalnızca ilgili özel anahtarla çözülebilir. Bir tarayıcı güvenli bir kanal oluşturmak için HTTPS el sıkışmasını başlattığında sunucu, tarayıcının kimliğini doğrulamak için gerekli tüm bilgileri sağlayan bir sertifika sağlar. Bu sertifika, sunucunun uygun özel anahtara sahip olup olmadığını kontrol eder. Bu noktadan sonraki tüm iletişimler, isteklerin kimliği doğrulanmış sunucuya gönderildiğini ve yanıtların bu sunucudan alındığını kanıtlayacak şekilde şifrelenir.
Bu nedenle HTTPS, konuştuğunuzu düşündüğünüz sunucuda konuştuğunuz ve başka hiç kimsenin dinlemediği veya kabloda değişiklik yapmadığı konusunda size bir güvence verir. Bu tür bir şifreleme, web'de güvenliğin mutlak bir ön koşuludur. Uygulamanız şu anda HTTPS üzerinden yayınlanmıyorsa saldırıya açıktır. Sorunu çözün. Ars Technica'nın sertifika alma ve yükleme (ücretsiz) ile ilgili mükemmel bir kılavuzu var. Teknik ayrıntılar için bu kılavuzu incelemenizi öneririm. Yapılandırma, sağlayıcıdan sağlayıcıya ve sunucudan sunucuya farklılık gösterir ancak sertifika isteği süreci her yerde aynıdır.
Varsayılan olarak güvenli
Sertifika isteyip yükledikten sonra kullanıcılarınızın bu yoğun çalışmanızdan yararlanmasını sağlayın: HTTP yönlendirme özelliğini kullanarak mevcut kullanıcılarınızı HTTPS bağlantılarına şeffaf bir şekilde taşıyın ve çerezlerin yalnızca güvenli bağlantılar üzerinden yayınlandığından emin olun.
Lütfen bu taraftan
Kullanıcı http://example.com/ adresini ziyaret ettiğinde, uygun bir Location üstbilgisiyle 301 Moved
Permanently yanıt göndererek kullanıcıyı https://example.com/ adresine yönlendirin:
$ curl -I http://mkw.st/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.3.7
...
Keep-Alive: timeout=20
Location: https://mkw.st/
Bu tür yönlendirmeleri Apache veya Nginx gibi sunucularda kolayca ayarlayabilirsiniz.
Örneğin, http://example.com/
https://example.com/ adresine yönlendiren bir Nginx yapılandırması şöyle görünür:
server {
listen [YOUR IP ADDRESS HERE]:80;
server_name example.com www.example.com;
location "/" {
rewrite ^(.*) https://www.example.com$1 permanent;
}
}
Çerez kutusunu kilitle
Çerezler, kullanıcılara durum bilgisi olmayan HTTP protokolü üzerinden sorunsuz bir oturum açma deneyimi sunmamızı sağlar. Oturum kimlikleri gibi hassas bilgiler de dahil olmak üzere çerezlerde depolanan veriler her istekle birlikte gönderilir. Bu sayede sunucu, o anda hangi kullanıcıya yanıt verdiğini anlayabilir. Kullanıcıların sitemize HTTPS üzerinden ulaşmasını sağladıktan sonra, çerezlerde depolanan hassas verilerin yalnızca güvenli bir bağlantı üzerinden aktarıldığından ve hiçbir zaman açık metin olarak gönderilmediğinden de emin olmalıyız.
Çerez ayarlama genellikle aşağıdaki gibi görünen bir HTTP üst bilgisi içerir:
set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT
Tek bir anahtar kelime ekleyerek tarayıcıya, oturumları güvence altına almak için çerezin kullanımını kısıtlama talimatı verebilirsiniz:
Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure
secure anahtar kelimesiyle ayarlanan çerezler hiçbir zaman HTTP üzerinden gönderilmez.
Açık pencereyi kapatma
HTTPS'ye şeffaf yönlendirme, kullanıcılarınızın sitenizde geçirdiği sürenin büyük bir kısmında güvenli bir bağlantı kullanacağı anlamına gelir. Ancak bu, saldırı için küçük bir fırsat penceresi bırakır: İlk HTTP bağlantısı tamamen açıktır ve SSL stripping ile ilgili saldırılara karşı savunmasızdır. Ortadaki adam, ilk HTTP isteğine tam erişime sahip olduğundan sizinle sunucu arasında proxy görevi görebilir ve sunucunun niyetinden bağımsız olarak sizi güvenli olmayan bir HTTP bağlantısında tutabilir.
Tarayıcıdan HTTP Strict Transport Security (HSTS)'yi zorunlu kılmasını isteyerek bu tür saldırıların riskini azaltabilirsiniz. Strict-Transport-Security HTTP üstbilgisinin gönderilmesi, tarayıcıya HTTP'den HTTPS'ye yönlendirmeyi ağa hiç dokunmadan istemci tarafında yapmasını söyler (bu, performans açısından da mükemmeldir; en iyi istek, göndermeniz gerekmeyen istektir):
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
Bu üstbilgiyi destekleyen tarayıcılar (şu anda Firefox, Chrome ve Opera: caniuse'da ayrıntılar) söz konusu sitenin yalnızca HTTPS erişimi istediğini not eder. Bu, kullanıcı siteye nasıl gelirse gelsin siteyi HTTPS üzerinden ziyaret edeceği anlamına gelir. Tarayıcıya http://example.com/ yazsa bile hiçbir HTTP bağlantısı oluşturmadan HTTPS'ye yönlendirilir. Daha da iyisi, tarayıcı geçersiz bir sertifika algılarsa (muhtemelen sunucunuzun kimliğini taklit etmeye çalışıyorsa) kullanıcıların HTTP üzerinden devam etmesine izin verilmez. Bu, ya hep ya hiç durumudur ve mükemmeldir.
Tarayıcı, sunucunun HSTS durumunun geçerlilik süresini max-age saniye sonra (bu örnekte yaklaşık bir ay) sona erdirecek. Bu değeri makul derecede yüksek bir değere ayarlayın.
Başlığa includeSubDomains yönergesini ekleyerek bir kaynağın tüm alt alanlarının korunmasını da sağlayabilirsiniz:
$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000
Güvenli bir şekilde devam edin
Gönderdiğiniz verilerin amaçlanan alıcıya eksiksiz ulaşacağından emin olmanın tek yolu HTTPS'dir. Siteleriniz ve uygulamalarınız için hemen güvenli bağlantılar oluşturmalısınız. Oldukça basit bir işlemdir ve müşterilerinizin verilerinin güvende kalmasına yardımcı olur. Şifrelenmiş bir kanal oluşturduktan sonra, 301 HTTP yanıtı göndererek kullanıcıları sitenize nasıl geldiklerinden bağımsız olarak bu güvenli bağlantıya şeffaf bir şekilde yönlendirmeniz gerekir. Ardından, çerezleri ayarlarken secure anahtar kelimesini ekleyerek tüm kullanıcılarınızın hassas oturum bilgilerinin yalnızca bu güvenli bağlantıyı kullandığından emin olun.
Tüm bunları yaptıktan sonra, kullanıcılarınızın yanlışlıkla otobüsten atlamamasını sağlayın: Tarayıcılarının Strict-Transport-Security başlığı göndererek doğru işlemi yapmasını sağlayarak onları koruyun.
HTTPS'yi ayarlamak çok fazla iş gerektirmez ve siteniz ile kullanıcılarınız için büyük avantajlar sağlar. Bu çabaya değer.
Kaynaklar
- StartSSL, alan doğrulamalı ücretsiz sertifikalar sunar. Ücretsiz bir şeyden daha iyisi olamaz. Elbette daha yüksek doğrulama sınıflarına geçmek hem mümkün hem de makul fiyatlıdır.
- SSL Sunucu Testi: Sunucularınız için HTTPS'yi ayarladıktan sonra, SSL Labs'in sunucu testini çalıştırarak doğru şekilde ayarladığınızı doğrulayın. Gerçekten hazır olup olmadığınızı gösteren ayrıntılı bir rapor alırsınız.
- Ars Technica'nın "SSL/TLS ile web sunucunuzu güvence altına alma" başlıklı makalesini inceleyerek sunucu oluşturma hakkında daha fazla bilgi edinebilirsiniz.
Strict-Transport-Securityüst bilgisiyle ilgili ihtiyaç duyabileceğiniz tüm teknik bilgiler için HTTP Strict Transport Security spesifikasyonunu (RFC6797) gözden geçirmeniz önerilir.- Ne yaptığınızı gerçekten anladıktan sonra, sitenize yalnızca belirli bir sertifika grubu aracılığıyla erişilebileceğini duyurabilirsiniz. IETF'de,
Public-Key-Pinsbaşlığı aracılığıyla tam da bunu yapmanıza olanak tanıyacak bazı çalışmalar devam ediyor. Henüz erken aşamalarda olsa da bu çalışmalar ilgi çekici ve takip etmeye değer.