Http’i https’ye yönlendirmek kötü mü?


247

Sunucuma az önce bir SSL Sertifikası yükledim.

Ardından Port 80'deki alanımdaki tüm trafik için Port 443'e yönlendirmek üzere bir yönlendirme yaptı.

Başka bir deyişle, tüm http://example.comtrafiğim şimdi https://example.comsayfanın uygun sürümüne yönlendiriliyor .

Yönlendirme Apache Virtual Hosts dosyamda şöyle bir şeyle yapılır ...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

Sorum şu ki, SSL kullanmanın bir sakıncası var mı?

Bu bir 301 Yönlendirme olmadığından, arama motorlarına geçerek link suyunu / sıralamasını kaybeder miyim https?

Yardımın için minnettarım. Her zaman SSL'yi bir sunucuya kurmak istemişimdir, sadece bunu yapmak için, ve sonunda bu gece yapmaya karar verdim. Şu ana kadar iyi çalışıyor gibi görünüyor, ancak bunu her sayfada kullanmanın iyi bir fikir olup olmadığından emin değilim. Sitem e-Ticaret değil ve hassas verileri işlemiyor; Genelde görünüş ve öğrenme için kurmanın heyecanı.


GÜNCELLEME SAYISI

Garip Bing bu ekran görüntüsünü sitemden yaratıyor, şimdi her yerde HTTPS kullanıyor ...

görüntü tanımını buraya girin


12
[WTF -. (Yeterince temsilcisi var gibi görünüyor olsa da) cevabı ekleyemezsiniz] Cevabım (kısmen) olurdu Bazen KÖTÜ OLDUĞU . HTTP üzerinden bir GET'e bir COOKIE veya API Anahtarı iletmeyi düşünün. Siteniz HTTP isteklerini HTTPS isteklerine yönlendirirse, bu çağrılar çalışır, ancak COOKIE veya API Anahtarı açık alanda iletilir. Bazı API'ler HTTP'yi kapatır, daha sağlam bir yaklaşımdır - hiç HTTP yoktur, böylece HTTPS kullanmıyorsanız bile çalışmasını sağlayamazsınız. Örnek: "Tüm API istekleri HTTPS üzerinden yapılmalıdır. Düz HTTP üzerinden yapılan aramalar başarısız olur" stripe.com/docs/api?lang=php#authentication
codingoutloud

8
@codingoutloud - alternatif, her şeyin HTTPS içermeyen HTTP üzerinden gerçekleşmesidir. Bu nasıl daha iyi?
Mark Henderson

3
Bir nedeni @BenCrowell, işte tutsak portal bir gibi bir sürü kötü görünüyor sslstriptarzı yönlendirme saldırı (her ikisi de erkek-in-the-middle istek hijacks konum) böylece HSTS tarayıcılar ikisini de engeller-uyumlu.
Jeffrey Hantin,

3
örneğin yük jQuery kullanarak - https kullanarak da https olmalıdır dahil her şey demektir veya yüklemek olmayabilir unutmayın src="://example.com/jquery.js"- eksikliğini not httpveya httpsbu yüzden tarayıcı uygun olanı yükler. API (https aracılığıyla yüklenen) http bağlantıları ürettiğinde düzgün yüklenecek bazı gömülü Amazon malzemelerini almaya çalışırken bir kabus gördüm - yani https bağlantılarını değiştirmek için belgelenmemiş parametreyi bulana kadar düzgün çalışmadılar
Temel

3
Jason; güncellemeniz yeni bir soru olmalı, muhtemelen Webmaster'larda , asıl sorunuzla ilgisiz (teknik olarak). Ama muhtemelen stil sayfaların güvensiz bir alandan geliyor.
Mark Henderson

Yanıtlar:


316

[R]Kendi başına bayrak bir olan 302yönlendirme ( Moved Temporarily). İnsanların sitenizin HTTPS sürümünü kullanmasını gerçekten istiyorsanız (ipucu: siz yapın), [R=301]kalıcı bir yönlendirme için kullanıyor olmalısınız :

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

Bir 301google-fu ve zor kazanılan PageRanks tüm tutar bozulmamış . mod_rewriteEtkinleştirildiğinden emin olun :

a2enmod rewrite

Tam sorunuzu cevaplamak için:

Http’i https’ye yönlendirmek kötü mü?

Cehennem hayır. Çok iyi.


3
Bilgi için teşekkürler, patronum bana sadece sitesinin belirli sayfalarında https çalıştırmanın nedenini söylüyor, her sayfada çalıştırmak için daha fazla sunucu kaynağı kullanıyor. Bunun hakkında bir şey biliyor musun, yoksa bu doğru mu?
JasonDavis

9
@jasondavis Yalnızca en iyi duruma getirmek için birkaç dakika harcıyorsanız .
Michael Hampton

10
"Her sayfada çalıştırmak için çok daha fazla sunucu kaynağı kullanıyor." Modern CPU'larda SSL'yi neredeyse ücretsiz yapan şifreleme hızlandırma özellikleri bulunur. Tepegöz hakkında endişelenme.
Adam Davis,

41
@AdamDavis Kripto algoritması hafif olabilir, ancak el sıkışma ek yükü hala var. Ayrıca, HTTPS, HTTP proxy'lerinin içeriğinizi önbelleğe almasını önler. In çoğu durumlarda, HTTPS havai minimal ve değerli, fakat aşırı genelleme konusunda dikkatli olduğunu.
200_success

6
Bazı sitelerin kullanım düzenleri için faydalı olan paylaşılan önbelleklemeyi öldürür ve çoğu zaman çok az şey korur (insanların siteyi ziyaret ettiğinizi bilmesi önemlidir, ancak yaptığınız şeylerin ayrıntıları değil mi? SSL'nin yararlı olduğu tek durum budur). SSL'nin her kaynaktaki en büyük avantajı, "güvende olmanız" gerektiği gibi, örneğin "hakkımızda" olan kişilere bakmanız gerektiği, ancak kaydırmanız ve kullanmanız gereken bir durumda kullanmamanız anlamına gelmemesidir.
Jon Hanna,

49

Yalnızca SSL siteleri fikrini desteklerken, site tasarımınıza bağlı olarak bir dezavantajın genel gider olduğunu söyleyebilirim. Örneğin, img etiketlerinde çok sayıda ayrı görüntü sunuyorsanız, bu sitenizin daha yavaş çalışmasına neden olabilir. Aşağıdakileri üzerinde çalıştıklarından emin olmak için yalnızca SSL kullanan sunucuları tavsiye ederim.

  1. Sitenin tamamını dahili bağlantılar için kontrol edin ve bağlantılarda kendi etki alanı adınızı belirtirseniz hepsinin HTTPS kullandığından emin olun, böylece kendi yönlendirmelerinize neden olmazsınız.
  2. <meta property="og:url"Alan adınızın https sürümünü kullanarak sizi güncelleyin .
  3. <base href=HTTPS kullanmak için tekrar güncellemeyi kullanıyorsanız.
  4. Mümkünse SPDY protokolünü yükleyin
  5. İsteğin sayısını azaltmak için, mümkün olduğunda CSS Image sprite kullandığınızdan emin olun.
  6. Site haritalarınızı https durumunu belirtecek şekilde güncelleyin, böylece zamanla örümcekler bu değişikliği öğrenirler.
  7. HTTPS'yi tercih etmek için Google Web Yöneticisi Araçları gibi Arama Motoru tercihlerini değiştirin
  8. Mümkün olduğunda, herhangi bir statik ortamı HTTPS CDN sunucularına boşaltın.

Yukarıdakilere değinilirse, o zaman birçok sorun yaşayacağınızdan şüpheliyim.


SPDY iyi bir öneri; Apache 2.x'e SPDY desteği ekleyen bir modül bile var .
Calrion

18
Kullanma "//yourserver.com/some-uri" yerine " yourserver.com/some-uri " sayfa ile yüklendi şema bağlı (http veya https) sorun (1) tarayıcı, uygun şema seçecektir çünkü giderir .
MauganRa,

1
@MauganRa Tabii ki, örneğin, http makale sayfasından https giriş sayfasına bağlantı.
Mołot

4
Google, birisinin Refererbaşlık aracılığıyla ziyaret ettiği URL’yi görüyor . Örneğin, bu site Google’ın CDN’sinden jQuery kullanıyor ve sitemi her yeniden yüklediğimde tarayıcım Google’a bir istek gönderiyor. Böylece RefererGoogle’a bu sitenin URL’sine ayarlanan bir başlık gönderilir. Böylece Google, IP adresimin değişmediği süre boyunca ziyaret ettiğim siteleri izleyebilir (ve bu süre zarfında bir Google hizmeti kullanırsam, Google bu bilgileri Google hesabıma da bağlayabilir).
Stephan Kulla,

1
1) Sadece bir arama yaptım ve MySQL veritabanımı değiştirdim, http: https ... WordPress kullanıyorum bu yüzden yüzlerce bağlantıyı güncellemeyi çok kolaylaştırdım
JasonDavis

38

Ben https kurdum o zaman sitede her yerde kullanmanız gerekir. Karma içerik sorunları riskinden kaçınacaksınız ve gerekli araçlara sahipseniz neden tüm siteyi güvenli hale getirmiyorsunuz?

Http'den https'ye yönlendirmeye gelince cevap o kadar basit değil.

Yönlendirme, kullanıcılarınız için çok daha kolay hale getirecek, sadece whateversite.com yazarak https’e yönlendirilecekler.

Fakat. Kullanıcı bazen güvenli olmayan bir ağdaysa (veya Troy Hunt ve Ananasına yakınsa )? Ardından kullanıcı http: //whateversite.com’u eski alışkanlık dışı bırakmayı talep edecektir . Bu http. Bu tehlikeye girebilir. Yönlendirme https://whateversite.com.some.infrastructure.long.strange.url.hacker.org adresini işaret edebilir . Sıradan bir kullanıcı için oldukça yasal görünüyor. Ancak trafik engellenebilir.

Bu yüzden burada iki rakip şartımız var: Kullanıcı dostu ve güvende olmak. Neyse ki, HSTS başlığı olarak adlandırılan bir çare var . Bununla beraber yönlendirmeyi etkinleştirebilirsiniz. Tarayıcı güvenli siteye taşınır, ancak HSTS başlığı sayesinde de bunu hatırlarsınız. Kullanıcı, güvensiz ağda oturan whateversite.com'da yazdığında, tarayıcı http üzerinden yönlendirmeye geçmeden hemen https'ye gidecektir. Çok hassas verilerle ilgilenmiyorsanız, bunun çoğu site için güvenlik ve kullanılabilirlik arasında adil bir denge olduğunu düşünüyorum. (Geçenlerde tıbbi kayıtları ele alan bir uygulama kurduğumda, yeniden yönlendirmeden tüm https'ye gittim). Ne yazık ki Internet Explorer'ın HSTS desteği yok ( kaynak), bu nedenle hedef kitleniz çoğunlukla IE kullanıyorsa ve veriler hassassa yönlendirmeleri devre dışı bırakmak isteyebilirsiniz.

Dolayısıyla, IE kullanıcılarını hedeflemiyorsanız, devam edin ve yönlendirmeyi kullanın, ancak HSTS başlığını da etkinleştirin.


Daha fazla insanın buna da dikkat etmesi gerekiyor. Başka bir şey de insanların güvenli olduklarını varsaymalarıdır çünkü son nokta HTTPS'dir, sayfaya GET veya POST olarak gönderilen tüm bilgilerin düz metin halinde olduğu gerçeğini göz ardı eder.
Velox

3
@Velox - "İnsanlar güvende olduklarını varsayıyorlar çünkü son nokta HTTPS, çünkü sayfaya GET veya POST sayfalarında gönderilen tüm bilgilerin düz metin olduğunu" görmezden geliyorlar. Bazı kazanımlar olsa da, GET sorgu paraşütleri HTTPS üzerinden aktarım sırasında net bir şekilde seyahat etmiyor. Örneğin bakınız: stackoverflow.com/questions/323200/… POST yükleri de korunurken, aynı zamanda günlüğe kaydetme ve yönlendiren başlıklara da savunmasız.
Ocak'ta saat

@codingoutloud Bu benim amacım. HTTPS üzerinden şifrelenir, ancak ilk istek üzerine HTTP sayfasına girmediler.
Velox

1
@Velox - Sitenin tamamı HTTPS'ye yönlendiriliyorsa, HTTPS başlamadan önce herhangi bir GET parametresinin gönderilmesi olası değildir (ve bu noktadan sonra her şey HTTPS'de kalır). HSTS ile düzeltilebilecek çerezlerin gönderileceği ilk istek hala var ... ve muhtemelen JavaScript tarafından yenilmiş olabilecek SSLStrip için küçük bir saldırı penceresi.
Brilliand,

@Brilliand Adil nokta, ancak güvenlik açısından zayıf bir nokta her şeyi zayıflatıyor. Her zaman dikkate değer.
Velox

22

Bunda yanlış bir şey yok ve aslında en iyi yöntem ( güvenli bir bağlantı üzerinden sunulması gereken siteler için ). Aslında, yaptığınız şey kullandığım yapılandırmaya oldukça benzer:

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

301Durum kodu bir işaret kalıcı (örn imi güncellemek) gelecekteki bağlantıları için güvenli URL kullanmak yetenekli müşterilerine talimat, yönlendirme.

Siteye yalnızca TLS / SSL üzerinden hizmet verecek olursanız, güvenli sanal sunucunuzda HTTP Sıkı Aktarım Güvenliği'ni (HSTS) etkinleştirmek için bir yönerge öneririm :

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

Bu başlık, yetenekli müşterilere (bugünlerde çoğu, inanıyorum) , sonraki alan için yalnızca sağlanan alanla HTTPS kullanmaları gerektiğini ( secure.example.combu durumda) bildirir 1234. ; includeSubdomainsKısmıdır opsiyonel ve direktif sadece geçerli etki değil uygulandığını gösterir, ancak bu (örn altında herhangi bir alpha.secure.example.com). HSTS başlığının yalnızca bir SSL / TLS bağlantısı üzerinden servis yapıldığında tarayıcılar tarafından kabul edildiğini unutmayın !

Sunucu yapılandırmanızı mevcut en iyi uygulamalara karşı test etmek için iyi bir ücretsiz kaynak Qualys’in SSL Sunucu Testi hizmetidir; En az bir A - puanı almayı hedefliyordum (eliptik eğri şifrelemesi için destek eksikliği nedeniyle Apache 2.2 ile bundan daha fazlasını elde edemezsiniz).


Strict-Transport-Security: max-age=0Eklemeliyim ki , başlığın gönderilmesi önceki herhangi bir yönergeyi reddedecektir; Her zaman olduğu gibi, kabul edilmek üzere HTTPS üzerinden gönderilmesi gerekir , ancak etki alanında HTTP kullanmanız gerektiğine karar verirseniz, şeyleri iptal etmenin kullanışlı bir yoludur.
Calrion

5

Vaov ! HTTP'yi HTTPS'ye yönlendirmek çok iyi bir şey ve bunun için dezavantajları göremiyorum.

Tarayıcıdaki sertifika hakkında kullanıcı dostu olmayan uyarılardan kaçınmak için müşterilerinizin doğru CA'ya sahip olduklarından emin olun.

Ayrıca, Apache'yi HTTPS'ye yönlendirmek için kurulum şekliniz tamam görünüyor.


5

Http’i https’ye yönlendirmek kötü mü?

Hayır, hiç de değil. Aslında, yapılması gereken iyi bir şey!

Yönlendirmelerde:

Yeniden yazmaları tamamen ortadan kaldırarak daha verimli olabilir . İşte benim benzer bir durum için benim yapılandırma.

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

4

HTTPS tam olarak kusursuz değildir. Elbette normalde HTTPS'yi zorlamak iyi bir şeydir. Normal suçluların kullanıcılarınıza kötü bir şey yapmasını önler.

Fakat lütfen SSLCiphers ayarı gibi SSL Ayarlarını kontrol etmeyi unutmayın. RC4 şifrelemesi, SSLv2 ve SSLv3 protokolü gibi şeyleri devre dışı bırakın. Ayrıca, sisteminizin kripto sistemi kütüphanelerinin TLS1.2'yi destekleyip desteklemediğini öğrenmelisiniz (sahip olmak istediğiniz şey budur).

SSL'yi aç, iyi bir şey.


Entropi alışmaz ( en azından voodoo yapmak yerine, Dünya kökenli saldırganlara karşı savunuyorsanız ). Ya yetersiz entropi ile başlarsınız ve rastlantısallık gerektiren hiçbir şey yapamazsınız, ya da yeterli entropi ile başlarsınız ve ne kadar rastgele olursanız olun, yeterli entropiye sahip olursunuz.
Gilles

Pardon, ne ? Linux'ta PRNG tabanlı muhtemelen yeterince iyi bir entropi yerine donanım kaynaklı güçlü entropi konusunda ısrar eden ve havuz derinliği düşükse bunlar gerçekten engelleyebilecek bir dizi işlem var. Bir Linux sisteminde yeterli entropi ile başlamak kesinlikle mümkündür, ancak havuzu boşaltmak için aşırı kullanmakla, bazı işlemlerin engellenmesine neden olabilir.
MadHatter

3

Şahsen, web’deki bağlantıları güvenli hale getirmek için SSL’nin kullanımı konusunda hepim var, ancak buradaki tüm cevapların kaçırdığı bir noktanın, HTTP bağlantısı yapabilen her cihaz ve yazılım parçasının SSL kullanamayacağı anlamına geldiğini hissediyorum. bu nedenle, eğer desteklenmiyorsa, kullanıcılardan kaçınmaları için bir yol sağlamayı düşünürdüm. Ayrıca, şifreleme teknolojisinin yasa dışı olduğu bazı ülkelerdeki kişilerin sitenize erişmesine izin verilmemesi de mümkündür. Sitenin güvensiz sürümünü zorlamak için bir bağlantı içeren şifrelenmemiş bir açılış sayfası eklemeyi düşünürdüm, ancak bir kullanıcı özellikle sizin söylediğiniz gibi yapmayı seçmezse ve bunları yalnızca HTTPS sürümüne iletmezse.


Düzgün bir HTTP açılış sayfasına sahip olmak gibi çözümler ile ilgili bir sorun, uygun şekilde ayrılmış olsa bile, bu sayfanın manipülasyona açık kalmasıdır. Yani, sitenin HTTPS versiyonu için olan linkin ziyaretçilere eksiksiz bir şekilde iletileceği konusunda hiçbir garanti yoktur.
Håkan Lindqvist

3

İşte geniş kapsamlı fırça darbesi sorunlarından bazıları:

  • MITM / SSLSTRIP : Bu çok büyük bir uyarıdır . Sitenizi HTTPS üzerinden sunacaksanız, sitedeki HTTP'yi devre dışı bırakın . Aksi takdirde, kullanıcılarınızı, istekleri engelleyecek ve sessizce HTTP üzerinden hizmet edecek olan SSLSTRIP dahil olmak üzere çeşitli orta düzey saldırılara açık bırakacaksınız. Kullanıcı fark etmezse , oturumun gerçekte olmadığında güvenli olduğunu düşünürler .

    • Bununla birlikte, bununla birlikte, siteniz herkese açık bir site ise ve HTTP'yi yanlış bir şekilde devre dışı bırakırsanız, çok fazla ziyaretçiyi kaybedebilirsiniz. Site HTTP ile yüklenmezse büyük olasılıkla HTTPS denemeleri bile gerçekleşmeyecek .
  • Siteniz güvenli bir oturum açmaya ihtiyaç duyuyorsa, tüm kullanıcı oturumu güvenli olmalıdır. HTTPS üzerinden kimlik doğrulaması yapmayın, ardından kullanıcıyı tekrar HTTP'ye yönlendirin. Bunu yaparsanız, yine kullanıcılarınızı MITM saldırılarına karşı savunmasız bırakıyorsunuz. Bugünlerde kimlik doğrulaması için standart yaklaşım, bir kez kimlik doğrulaması yapmak, sonra bir kimlik doğrulama belirtecini ileri geri (bir çerez içinde) iletmektir. Ancak HTTPS üzerinden kimliğinizi doğrularsanız ve ardından HTTP'ye yönlendirirseniz, ortadaki bir adam bu çekiğe müdahale edebilir ve siteyi kimliği doğrulanmış kullanıcınızmış gibi kullanabilir, güvenliğinizi atlayabilir.

  • HTTPS ile "performans" sorunları, tümüyle pratik bir amaç için, yeni bir bağlantı kurmaya dahil olan el sıkışma ile sınırlıdır. Bir URL’den birden çok HTTPS bağlantısına olan ihtiyacı en aza indirmek için elinizden geleni yapın; Ve açıkçası bu, içeriğinizi HTTP üzerinden sunsanız bile geçerlidir. SPDY'yi okursanız, yaptığı her şeyin tek bir URL’deki tüm içeriği tek bir bağlantı üzerinden sunmaya yönelik olduğunu fark edersiniz. Evet, HTTPS kullanmak önbelleklemeyi etkiler. Fakat kaç web sitesi bugünlerde sadece statik, önbelleklenebilir bir içeriktir? Gereksiz veritabanı sorgularını tekrar tekrar değiştirmeden tekrar tekrar almak ve pahalı kod yollarının gereğinden fazla çalıştırılmasını önlemek için web sunucunuzda önbelleğe alma özelliğini kullanarak paranızın karşılığını daha fazla alabilirsiniz.


Aslında sslstrip ile ilgili olarak yapabileceğiniz şey HSTS'yi kullanmaktır ( HSTS ayarlarınızı önceden yüklenmiş olarak almak ). Düz HTTP üzerinden istekleri kabul edip etmemeniz veya bu konuda gerçekten önemli olmamanız bile, bir MITM, yalnızca HTTPS isteklerini kabul etseniz bile, düz HTTP üzerinden yanıt verebilir (muhtemelen HTTPS sitenize proksiye).
Håkan Lindqvist

@ HåkanLindqvist Gerçekten senden bir oy kullandım? HTTPS üzerinde kimlik doğrulaması yapmama ve ardından oturumun geri kalanında HTTP'ye geçme konusunda kötü tavsiyeler veya iyi tavsiyeler verdim mi? HTTPS performans efsaneleri hakkında kötü danışmanlık verdim mi? Ayrıca, istemci başlangıçta HTTPS kullanarak bağlanmaya çalışırsa, MITM tarayıcıda bir uyarı tetiklemeden müdahale edemez ve yanıt veremez; çünkü certleri, çalınan veya başarılı bir sahte cürufu olmadıkça eşleşmez. Öte yandan, site bir HTTP bağlantısı kabul ederse, ele geçirme daha kolaydır. Her iki durumda da, HTTPS çıtayı yükseltiyor.
Craig

..ve tabii ki HSTS kullanmaya gönülden katılıyorum.
Craig

Cevabımla ilgili sorunum, listede yer almayan (efsanelerden bahseden) sslstrip'e değinmeyi iddia eden ilk öğe. İlk yorumumda elde etmeye çalıştığım şey, eğer aktif bir MITM'iniz varsa (ilk başta sslstrip için ihtiyacınız olan şey), saldırganın esasen müşteri perspektifinden "site" olabileceği; istemciden düz HTTP bağlantıları kabul etmek isteyip istemediklerine karar veren saldırgan, gerçek web sunucunuzun bu konuda nasıl davrandığı, saldırganın yapabileceklerini veya yapabileceklerini etkilemez.
Håkan Lindqvist

@ HåkanLindqvist Ziyaretçi, kasıtlı olarak HTTPS ile bağlantı kurmaya çalışıyorsa, saldırganın, bir sunucu sertifikası çalmayı başaramadıklarını veya bir şekilde başarılı bir şekilde takmadıklarını belirlemedikleri sürece, tarayıcıya bayrak atmadan bu isteğini yerine getirememesi dışında Bağlantıyı HTTP'ye geçirmek için yapın. HTTPS hala çıtayı yükseltiyor. Tabi ki ziyaretçi HTTP üzerinden ilk bağlantı girişimini yaparsa, tüm bahisler tamamen kapalıdır.
Craig,

1

Bu, teknik olarak orijinal sorunuza bir cevap değildir, ancak HTTPSEverywhere Google Chrome uzantısını kullanırsanız (diğer tarayıcılarda benzer uzantılar olduğundan eminim), uzantı, HTTP içeren siteleri otomatik olarak HTTPS ile aynı siteye yönlendirir. Bir süredir kullanıyorum ve herhangi bir sorun yaşamadım (yavaşlama dışında, ama test etmedim). HTTPSEverywhere, sunucu tarafında belirli kurallarla değiştirilebilir, ancak bu alanda fazla bir şey yapmadığımdan, ayrıntılardan tam olarak emin değilim.

Asıl sorunuza geri dönersek, HTTPSEverywhere gibi bir şey kullanırsanız, sadece HTTP kullanmak için daha az teşvik vardır, ancak ihtiyaç duyduğunuzda doğru kuralları belirlemenin zor olduğunu hayal ediyorum.


1

HTTP üzerinden HTTPS'ye geri dönmenin tek teknik yolu, HTTPS isteklerini işlemenin düz HTTP'den daha hesaplamalı olarak daha pahalı olmasıdır.

Bununla birlikte, modern sunucuların çoğunun yüksek güçlü CPU'ları olduğu göz önüne alındığında, bu etki, zaten yük dengeleyicilerini kullanmanın muhtemel olduğundan daha fazla trafik seviyelerinde olmadığınız sürece genellikle ihmal edilebilir

SSL / TLS'nin çalışmasını gerektiren SPDY gibi protokollerin ortaya çıkması ile birlikte, bu, yukarıda belirtilen hesaplama ek yükünü, çoklu taleplerde önemli performans iyileştirmeleri sağlayarak ve müşteriye varlıkları genel olarak daha hızlı elde ederek karşılar.


HTTPS performansı ile ilgili sorun, yeni bir bağlantı kurmanın daha pahalı olmasıdır çünkü daha fazla gidiş dönüş vardır ve asimetrik şifreleme / şifre çözme işlemi simetrik şifreleme / şifre çözme işleminden çok daha pahalıdır. Bağlantı anlaşması paylaşılan bir simetrik şifreleme anahtarı oluşturduğunda, devam eden ek yük neredeyse alakasızdır (çok küçük). SPDY'yi okursanız, yaptığı tüm süslü şeylerin amacının, esas olarak bir URL’deki tüm içeriği tek bir bağlantı üzerinden sunmak ve bağlantı anlaşmasının genel giderini hafifletmek olduğunu görürsünüz.
Craig,

1

Https'ye yönlendirmek çok iyidir, ancak okudum, yönlendirmeyi nasıl düzenlediğinize de bağlı.

Security.stackexchange.com adresindeki cevapta önerildiği şekilde, gelen http isteklerini https bağlantınıza yönlendirmek için özel bir sanal sunucu yapmak çok akıllıdır ve bazı ek güvenlik tehditlerini kapatacaktır. Apache'deki bir konfigürasyon şuna benzer:

# Virtual host for rerouting
<VirtualHost *:80>
    ServerName www.example.com
    Redirect permanent / https://www.example.com/
</VirtualHost>

# Virtual host for secure hosting on https
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"

    ...site settings...

</VirtualHost>
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.