Neden her şey için HTTPS kullanmıyorsunuz?

Bir sunucu kuruyorsam ve SSL sertifikalarına sahip olsaydım, neden sadece satın alma / oturum açma yerine tüm site için HTTPS kullanmayayım? Sadece tüm siteyi şifrelemek ve kullanıcıyı tamamen korumak daha mantıklı olur diye düşünüyorum. Her şey olacağı için neyin güvence altına alınması gerektiğine karar vermek gibi sorunları önler ve bu gerçekten kullanıcı için bir rahatsızlık oluşturmaz.

Sitenin bir kısmı için zaten bir HTTPS kullanıyor olsaydım, neden onu tüm site için kullanmak istemeyeyim?

Bu alakalı bir sorudur: https neden sadece giriş için kullanılıyor? ama cevaplar tatmin edici değil. Cevaplar, sitenin tamamına https uygulayamadığınızı varsayar.

Birkaç neden düşünebilirim.

• Bazı tarayıcılar SSL'yi desteklemeyebilir.
• SSL performansı biraz düşürebilir. Kullanıcılar büyük, genel dosyalar indiriyorsa, bunları her seferinde şifrelemek için bir sistem yükü olabilir.

Diğer nedenlere ek olarak (özellikle performansla ilgili), HTTPS kullanırken IP adresi * başına yalnızca tek bir alan adı barındırabilirsiniz.

Tek bir sunucu, HTTP'de birden çok etki alanını destekleyebilir çünkü Sunucu HTTP başlığı, sunucunun hangi etki alanıyla yanıt vereceğini bilmesini sağlar.

HTTPS ile, sunucunun sertifikasını istemciye ilk TLS el sıkışması sırasında (ki bu HTTP başlamadan önce) sunması gerekir. Bu, Sunucu başlığının henüz gönderilmediği anlamına gelir, bu nedenle sunucunun hangi etki alanının talep edildiğini ve hangi sertifikayla (www.foo.com veya www.bar.com) yanıt vereceğini bilmesinin bir yolu yoktur.

* Dipnot: Teknik olarak, farklı bağlantı noktalarında barındırıyorsanız birden fazla etki alanını barındırabilirsiniz, ancak bu genellikle bir seçenek değildir. Ayrıca, SSL sertifikanızda bir joker karakter varsa, birden fazla alan adı barındırabilirsiniz. Örneğin, * .example.com sertifikasıyla hem foo.example.com hem de bar.example.com'u barındırabilirsiniz.

SSL / TLS neredeyse yeterince sık kullanılmaz. HTTPS, tüm oturum için kullanılmalıdır , hiçbir noktada bir Oturum Kimliği HTTP üzerinden gönderilemez. Oturum açmak için yalnızca https kullanıyorsanız, 2010 için OWASP ilk 10 "A3: Bozuk Kimlik Doğrulama ve Oturum Yönetimi" ni açıkça ihlal etmiş olursunuz .

Neden her bir salyangoz posta gönderisini, kurcalamaya karşı korumalı, opak bir zarf içinde Kayıtlı Posta ile göndermiyorsunuz? Postaneden biri her zaman onun kişisel velayetini alırdı, bu yüzden hiç kimsenin postanızı gözetlemediğinden emin olabilirsiniz. Açıkçası, cevap şu ki, bazı postalar masrafa değer olsa da çoğu postanın değeri yoktur. Kimsenin "Hapisten çıktığına sevindim!" Joe Amca'ya kartpostal.

Şifreleme ücretsiz değildir ve her zaman yardımcı olmaz.

Bir oturum (alışveriş, bankacılık vb.) HTTPS kullanılarak sona erecekse, tüm oturum HTTPS'yi mümkün olduğunca erken yapmamak için iyi bir neden yoktur.

Benim fikrim HTTPS'nin yalnızca kaçınılmaz olarak gerekli olduğunda kullanılması gerektiğidir, çünkü istek veya yanıtın ara sıra gözetlemeden korunması gerekir. Örnek olarak, Yahoo! anasayfa. Giriş yapmış olsanız bile, etkileşiminizin çoğu HTTP üzerinden olacaktır. HTTPS üzerinden kimlik doğrulaması yaparsınız ve kimliğinizi kanıtlayan çerezler alırsınız, böylece haberleri okumak için HTTPS'ye ihtiyacınız olmaz.

Sistem yükünün ötesinde en büyük nedeni isme dayalı sanal barındırmayı bozmasıdır. SSL ile tek site - tek IP adresi. Bu oldukça pahalıdır ve yönetimi daha zordur.

Yüksek gecikmeli bağlantılar için ilk TLS el sıkışması, sertifika zincirini doğrulamak (herhangi bir ara sertifika göndermek dahil), şifre paketleri üzerinde anlaşmak ve bir oturum oluşturmak için ek gidiş-dönüşler gerektirir. Bir oturum kurulduktan sonra, sonraki istekler, gidiş dönüş sayısını azaltmak için oturumu önbelleğe almayı kullanabilir, ancak bu en iyi durumda bile, normal bir HTTP bağlantısının gerektirdiğinden daha fazla gidiş dönüş vardır. Şifreleme işlemleri ücretsiz gidiş-dönüş olsa bile, özellikle site http ardışık düzeninden yararlanmıyorsa, daha yavaş ağ bağlantılarında oldukça fark edilebilir ve farkedilebilir. Ağın iyi bağlanmış bir bölümündeki geniş bant kullanıcıları için bu bir sorun değildir. Uluslararası olarak iş yapıyorsanız, https talep etmek, kolayca fark edilir gecikmelere neden olabilir.

Potansiyel olarak önemli ölçüde daha fazla bellek ve tabii ki veri şifreleme işlemleri gerektiren oturum durumunun sunucu bakımı gibi ek hususlar vardır. Herhangi bir küçük sitenin ne sunucu kapasitesi ne de bugünün donanımının maliyeti konusunda endişelenmesi gerekmez. Herhangi bir büyük site, benzer işlevsellik sağlamak için kolayca CPU / w AES yükünü veya eklenti kartlarını karşılayabilir.

Zaman geçtikçe ve donanım ve ağın yetenekleri geliştikçe, tüm bu sorunlar giderek daha fazla sorun olmaktan çıkıyor. Çoğu durumda, bugün somut bir fark olduğundan şüpheliyim.

Https trafiğinde idari kısıtlamalar gibi operasyonel hususlar olabilir (ara içerik filtrelerini düşünün… vb.) Muhtemelen bazı kurumsal veya resmi düzenlemeler olabilir. Bazı kurumsal ortamlar, bilgi sızıntısını önlemek için çevredeki verilerin şifresinin çözülmesini gerektirir ... sıcak nokta ile etkileşim ve https işlemlerinde mesaj enjekte etme yeteneğine sahip olmayan benzer web tabanlı erişim sistemleri. Günün sonunda, benim görüşüme göre, varsayılan olarak https kullanılmama nedenleri oldukça küçük olacaktır.

https, normal http'den daha fazla kaynak açtır.

Hem sunuculardan hem de istemcilerden daha fazlasını talep eder.

Oturumun tamamı şifrelenmişse, proxy düzeyinde görüntüler ve js gibi statik kaynaklar için önbelleğe almayı kullanamazsınız, örneğin ISP.

HTTPS'yi her yerde kullanmalısınız, ancak aşağıdakileri kaybedeceksiniz:

1. İHLAL ve SUÇ saldırıları nedeniyle kesinlikle SSL Sıkıştırma veya SSL üzerinden HTTP Sıkıştırma kullanmamalısınız. Dolayısıyla, yanıtınız oturum veya csrf tanımlayıcıları içeriyorsa sıkıştırma yapılmaz. Statik kaynaklarınızı (resimler, js, css) çerezsiz bir alana yerleştirerek ve orada sıkıştırma kullanarak bunu hafifletebilirsiniz. Ayrıca HTML küçültmeyi de kullanabilirsiniz.

2. Tüm tarayıcılarda (eski android, blackberry 6 vb.) Çalışmayan SNI kullanılmadığı sürece bir SSL sertifikası, tek IP adresi.

3. Sayfalarınızda SSL üzerinden gelmeyen herhangi bir harici içeriği barındırmamalısınız.

4. Tarayıcı bir HTTP sayfasına gittiğinde giden HTTP Referer başlığını kaybedersiniz, bu sizin için sorun olabilir veya olmayabilir.

Bunun bariz nedeni performanstır: tüm verilerin aktarımdan önce sunucu tarafından şifrelenmesi ve ardından alıcı tarafından şifresinin çözülmesi gerekir, bu da hassas veri yoksa zaman kaybıdır. Ayrıca sitenizin ne kadarının önbelleğe alınacağını da etkileyebilir.

Ayrıca, tüm adreslerin https://tanıdık değil de kullanması son kullanıcılar için kafa karıştırıcı olabilir http://. Ayrıca şu yanıta bakın:

Bir js dosyası eklerken neden her zaman https kullanılmıyor?

https, sunucunun istemci isteklerini ve yanıtlarını şifrelemesini ve şifresini çözmesini gerektirir. Sunucu çok sayıda istemciye hizmet veriyorsa performans etkisi artacaktır. Bu nedenle, mevcut https uygulamalarının çoğu yalnızca parola kimlik doğrulamasıyla sınırlıdır. Ancak artan bilgi işlem gücüyle bu durum değişebilir, çünkü tüm Gmail site için SSL kullanmaktadır.

WhirlWind'in yanıtına ek olarak, SSL sertifikalarının maliyetini ve uygulanabilirliğini, erişim sorunlarını (olası olmasa da bir istemcinin SSL portu üzerinden iletişim kuramaması mümkündür) vb.

SSL kullanmak garantili bir güvenlik örtüsü değildir. Bu tür bir korumanın, sihirli bir mermiye güvenmeye çalışmak yerine, uygulamanın mimarisine dahil edilmesi gerekir.

Şirketimizdeki bir projede, SSL mesajlarının kapladığı bant genişliğinin düz mesajlardan önemli ölçüde daha fazla olduğunu buldukları söylendi. Sanırım birisi bana bunun 12 kat fazla veri olduğunu söyledi. Bunu kendim doğrulamadım ve kulağa çok yüksek geliyor, ancak her sayfaya bir tür başlık eklenmişse ve çoğu sayfada az miktarda içerik varsa, bu o kadar uzak olmayabilir.

Bununla birlikte, http ile https arasında gidip gelme ve hangi sayfaların olduğunu takip etme zahmeti bana çok fazla çaba gibi geliyor. Sadece bir kez onları karıştıran bir site kurmaya çalıştım ve Javascript tarafından oluşturulan açılır pencereler gibi karmaşık şeylere yanlış protokol eklenmesi gibi karmaşık şeylere takılıp kaldığımızda planı terk ettik. Sonunda tüm siteyi https'yi daha az sorun haline getirdik. Sanırım, sadece bir giriş ekranınız ve korunması gereken bir ödeme ekranınız olduğu ve basit sayfalar olduğu durumlarda, karıştırıp eşleştirmek çok önemli olmaz.

İstemcinin şifresini çözme yükü hakkında fazla endişelenmem. Normalde müşteri, verinin kabloyu işlemek için gerekenden çok daha fazla veri tel üzerinden gelmesini bekler. Kullanıcılar rutin olarak gigabit / sn internet bağlantılarına sahip olana kadar, istemci işlem gücü muhtemelen oldukça önemsizdir. Sayfaları şifrelemek için sunucu tarafından talep edilen CPU gücü farklı bir sorundur. Yüzlerce veya binlerce kullanıcıya yetişememe gibi sorunlar olabilir.

Bir başka küçük nokta (belki birisi doğrulayabilir), Bir kullanıcı bir metin kutusu gibi bir form öğesine veri yazarsa ve daha sonra herhangi bir nedenle sayfayı yenilerse veya sunucu bir saniye için çökerse, kullanıcının girdiği veriler kaybolur HTTPS, ancak HTTP kullanılarak korunur.

Not: Bunun tarayıcıya özgü olup olmadığından emin değilim, ancak kesinlikle Firefox tarayıcımda oluyor.

IIS 8.0 ile Windows Server 2012 artık, IIS'deki birden çok SSL Web Uygulamasının tek bir IP Adresinde barındırılmasına izin veren Sunucu Adı Göstergesi olan SNI'yi sunmaktadır.