Bu sayfa, Cloud Translation API ile çevrilmiştir.

HTTPS ve HTTP Strict taşıma güvenliği ile kötü amaçlı aracıları şaşırttı

Mike West

İnternet olan kocaman tüplerden akan kişisel veri miktarı düşünüldüğünde, şifrelemeyi görmezden gelebileceğimiz veya dikkate almamız gereken bir şey değil. Modern tarayıcılar, kullanıcılarınızın verilerinin aktarım sırasında güvende olduğundan emin olmak için kullanabileceğiniz çeşitli mekanizmalar sunar: güvenli çerezler ve Strict Transport Security, en önemli iki mekanizmadır. Bu çerezler, kullanıcılarınızı sorunsuz bir şekilde korumanıza, bağlantılarını HTTPS'ye yükseltmenize ve kullanıcı verilerinin hiçbir zaman açık bir şekilde gönderilmeyeceğini garanti etmenize olanak tanır.

Bu konu neden önemli? Şunu göz önünde bulundurun:

Bir web sayfasını şifrelenmemiş bir HTTP bağlantısı üzerinden teslim etmek, sokakta gördüğünüz ve postaneye doğru yürüyormuş gibi görünen ilk kişiye mühürsüz bir zarf vermekle aşağı yukarı aynı şeydir. Şansınız varsa bunu kendisi yapabilir ya da doğru yolda olduğunu gördüğü bir sonraki kişiye devredebilir. Bu kişi de aynısını yapabilir ve bu böyle devam eder.

Bu doğaçlama zincirdeki yabancıların çoğu güvenilir ve açık mektubunuza asla göz atmaz ya da onu değiştirmez. Ancak, mektubun el değiştirme sayısı ne kadar fazlaysa, gönderdiğiniz e-postaya tam erişimi olan kişilerin sayısı da o kadar fazla olur. Sonunda, mektubunuzun gönderildiği alıcıya postayla bir şey gönderilebilir. Ancak bir şeyin aynı olup olmadığı daha en başta açık bir sorudur. Belki de o zarfı mühürlemeliydin...

Aracılar

İster iyi ister kötü olsun, internetin büyük bir kısmı yabancıların güvenilirliğine güveniyor. Sunucular birbirine doğrudan bağlı değildir, ancak devasa bir Telefon oyununda istekleri ve yanıtları yönlendiriciden yönlendiriciye iletir.

Bu atlamaları, traceroute ile çalışırken görebilirsiniz. Bilgisayarımdan HTML5Rocks'a giden güzergah ş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 gerçekten kötü değil. Ancak istekleri HTTP aracılığıyla gönderiyorsam bu ara yönlendiricilerin her biri, isteklerime ve sunucuların yanıtlarına tam erişime sahip olur. Tüm veriler şifrelenmemiş düz metin olarak aktarılır ve bu aracılardan herhangi biri Ortadaki Adam görevi görebilir, verilerimi okuyabilir, hatta aktarım sırasında manipüle edebilir.

Daha da kötüsü, bu tür müdahaleler neredeyse algılanamaz. Kötü niyetli şekilde değiştirilmiş HTTP yanıtı, tamamen geçerli bir yanıt gibi görünür. Çünkü, alınan verilerin tam olarak _tam olarak gönderilmelerini sağlayacak bir mekanizma yoktur. Birisi gülmek için İnternet'imi baştan aşağı değiştirmeye karar verirse neden daha çok ya da şanssız sayılırım.

Bu güvenli bir hat mı?

Düz metin HTTP'den güvenli 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 da, siz ve hedefiniz arasındaki makinelerin geçiş hâlindeki verileri okumasını veya değiştirmesini imkansız hale getirir.

Chrome'un Çok Amaçlı Adres Çubuğu, bağlantıların durumu hakkında birçok ayrıntı verir.

HTTPS'nin sağladığı güvenlik, genel ve özel şifreleme anahtarları kavramına dayanır. Ayrıntıların ayrıntılı bir tartışması (neyse ki) bu makalenin kapsamı dışında olsa da temel düşünce oldukça basit: Belirli bir ortak anahtarla şifrelenen verilerin şifresi yalnızca ilgili özel anahtarla çözülebilir. Tarayıcı güvenli bir kanal oluşturmak üzere bir HTTPS el sıkışması başlattığında, sunucu, uygun özel anahtara sahip olup olmadığını kontrol ederek tarayıcının kimliğini doğrulamak için gereken tüm bilgileri tarayıcıya veren bir sertifika sağlar. Bu noktadan itibaren tüm iletişimler, isteklerin ve yanıtların kimliği doğrulanmış sunucuya iletildiğini kanıtlayacak şekilde şifrelenir.

Bu nedenle HTTPS, konuştuğunuz sunucuyla konuştuğunuzda ve başka hiç kimsenin kabloyu dinlemediğinden veya bağlantıda değişiklik yapmadığından emin olmanızı sağlar. Bu şifreleme türü, web'de güvenlik için mutlak bir ön koşuldur. Uygulamanız şu anda HTTPS üzerinden teslim edilmiyorsa saldırıya karşı savunmasızdır. Sorunu çözün. Ars Technica'da sertifika alma ve yükleme ile ilgili (ücretsiz) harika bir kılavuz bulunmaktadır. Bu rehberi inceleyerek teknik ayrıntılara göz atmanızı öneririz. 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üklemenizin ardından kullanıcılarınızın çabalarınızın karşılığını aldığından emin olun: HTTP yönlendirmesi sayesinde 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 iletildiğinden emin olun.

Bu şekilde lütfen

Bir kullanıcı http://example.com/ adresini ziyaret ettiğinde, uygun bir Location başlığıyla 301 Moved Permanently yanıtı göndererek onu https://example.com/ uygulamasına 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önlendirmeyi Apache veya Nginx gibi sunucularda kolayca ayarlayabilirsiniz. Örneğin, http://example.com/ bölgesinden https://example.com/ hedefine yönlendirme yapan bir Nginx yapılandırması aşağıdaki gibi 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;
    }
}

Kurabiye kavanozunu kilitle

Çerezler bize durum bilgisiz HTTP protokolü üzerinden kullanıcılara sorunsuz giriş yapma deneyimi sunma olanağı tanır. Oturum kimlikleri gibi hassas bilgiler de dahil olmak üzere çerezlerde depolanan veriler her istekle birlikte gönderilir. Böylece sunucunun o anda hangi kullanıcıya yanıt verdiğini anlamasını sağlar. Kullanıcıların sitemize HTTPS üzerinden eriştiğini doğruladıktan sonra, çerezlerde depolanan hassas verilerin yalnızca güvenli bir bağlantı üzerinden aktarıldığından ve hiçbir zaman açık bir şekilde gönderilmediğinden emin olmamız gerekir.

Çerez oluşturmak genellikle şuna benzer bir HTTP üstbilgisi içerir:

set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT

Tek bir anahtar kelimeyi ele alarak tarayıcıya çerez kullanımını güvenli oturumlar için kısıtlama talimatı verebilirsiniz:

Set-Cookie: KEY=VALUE; path=/; expires=Sat, 01-Jan-2022 00:00:00 GMT; secure

Güvenli anahtar kelime ile 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çirdikleri zamanların büyük çoğunluğunda güvenli bir bağlantı kullanacakları anlamına gelir. Bununla birlikte, saldırı için küçük bir fırsat penceresi bırakır: İlk HTTP bağlantısı geniş açıktır, SSL çıkarma ve ilgili saldırılara karşı savunmasızdır. Ortadaki bir kişinin ilk HTTP isteğine tam erişimi olduğu göz önünde bulundurulduğunda, bu kişi siz ve sunucu arasında bir proxy görevi görebilir ve sunucunun amaçlarından bağımsız olarak sizi güvenli olmayan bir HTTP bağlantısında tutar.

Tarayıcıdan HTTP Katı Taşıma Güvenliği'ni (HSTS) zorunlu kılmasını isteyerek bu saldırı sınıfının riskini azaltabilirsiniz. Strict-Transport-Security HTTP üst bilgisini gönderdiğinizde, tarayıcıya, ağa hiç dokunmadan HTTP'den HTTPS'ye yönlendirmenin istemci tarafında yapması talimatı verilir (bu, performans açısından da çok iyidir. En iyi istek, sizin yapmanız gerekmeyen istektir):

$ curl -I https://mkw.st/
HTTP/1.1 200 OK
Server: nginx/1.3.7
...
Strict-Transport-Security: max-age=2592000

Bu başlığı destekleyen tarayıcılar (şu anda Firefox, Chrome ve Opera: caniuse'nin ayrıntıları var), bu sitenin yalnızca HTTPS erişimi istediğini, yani bir kullanıcı siteye nasıl gelirse gelsin HTTPS üzerinden ziyaret edeceğini not eder. Tarayıcıya http://example.com/ yazsa bile, hiçbir HTTP bağlantısı kurmadan HTTPS'yi kullanacak. Daha da iyisi, tarayıcı geçersiz bir sertifika algılarsa (muhtemelen sunucunuzun kimliğini taklit etmeye çalışıyor olabilir) kullanıcıların HTTP üzerinden devam etmesine izin verilmez; bu tamamen ya da hiçbir şey olmayabilir.

Tarayıcının, sunucunun HSTS durumu max-age saniye sonra (bu örnekte yaklaşık bir ay) sona erecektir. Bunu makul ölçüde yüksek bir değere ayarlayın.

Başlığa includeSubDomains yönergesini ekleyerek 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 yola çıkın

HTTPS'yi kullanarak, gönderdiğiniz verilerin hedeflenen alıcıya dokunulmadan ulaştığından uzaktan bile emin olabilirsiniz. Bugünden siteleriniz ve uygulamalarınız için güvenli bağlantılar kurmanız gerekiyor. Oldukça basit olan bu işlem, müşterilerinizin verilerini güvende tutmanıza yardımcı olur. Şifrelenmiş bir kanalınız olduğunda, sitenize nasıl geldiklerinden bağımsız olarak bir 301 HTTP yanıtı göndererek kullanıcıları şeffaf bir şekilde bu güvenli bağlantıya yönlendirmeniz gerekir. Ardından, çerezleri ayarlarken güvenli 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 kazara otobüsten düşmediğinden emin olun: Bir Strict-Transport-Security başlığı göndererek tarayıcılarının doğru şeyi yaptığından emin olarak kullanıcıları koruyun.

HTTPS'yi ayarlamak çok kolay değildir ve hem siteniz hem de kullanıcıları için birçok avantaj sağlar. Gösterilen çabaya değer.

Kaynaklar

StartSSL, alan doğrulaması yapılmış ücretsiz sertifikalar sunar. Bedavadan daha iyi olamazsınız. Daha üst düzey doğrulama aşamalarına geçmek elbette hem mümkün hem de makul bir maliyetle yapılır.
SSL Sunucu Testi: Sunucularınız için HTTPS'yi ayarladıktan sonra, HTTPS'yi SSL Labs sunucu testinden çalıştırarak doğru şekilde yaptığınızdan emin olun. İşletmenizin gerçekten hazır olup olmadığını gösteren güzel ayrıntılı bir rapor alırsınız.
Ars Technica'nın kısa süre önce yayınladığı "Web Sunucunuzu SSL/TLS ile Güvenli Hale Getirme" başlıklı son makalesi, sunucu kurulumuyla ilgili ayrıntılar için daha fazla arka plan ayrıntısı olarak okunmaya değer.
HTTP Strict Transport Security spesifikasyonu (RFC6797), Strict-Transport-Security başlığı hakkında isteyebileceğiniz tüm teknik bilgilere hızlıca göz atmaya değer.
Ne yaptığınızı gerçekten anladıktan sonra uygulayabileceğiniz bir sonraki adım, sitenize yalnızca belirli bir sertifika grubu aracılığıyla erişilebileceğini belirtmek olabilir. IETF'de, Public-Key-Pins başlığı üzerinden bunu yapmanızı sağlayacak bazı çalışmalar devam etmektedir. Bu çalışmalar henüz yolun başındadır, ama ilginç ve takip edilmeye değer.