Apakah buruk untuk mengalihkan http ke https?

247

Saya baru saja menginstal Sertifikat SSL di server saya.

Kemudian mengatur redirect untuk semua lalu lintas di domain saya di Port 80 untuk mengarahkannya ke Port 443.

Dengan kata lain, semua http://example.comlalu lintas saya sekarang dialihkan ke https://example.comversi halaman yang sesuai.

Redirect dilakukan dalam file Apache Virtual Hosts saya dengan sesuatu seperti ini ...

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

Pertanyaan saya adalah, apakah ada kelemahan menggunakan SSL?

Karena ini bukan 301 Redirect, apakah saya akan kehilangan jus tautan / peringkat di mesin pencari dengan beralih ke https?

Saya menghargai bantuannya. Saya selalu ingin mengatur SSL di server, hanya untuk praktik melakukannya, dan akhirnya saya memutuskan untuk melakukannya malam ini. Tampaknya berfungsi dengan baik sejauh ini, tetapi saya tidak yakin apakah itu ide yang baik untuk menggunakan ini di setiap halaman. Situs saya bukan eCommerce dan tidak menangani data sensitif; itu terutama untuk penampilan dan sensasi menginstalnya untuk belajar.


MASALAH YANG DIPERBARUI

Anehnya Bing membuat tangkapan layar ini dari situs saya sekarang karena menggunakan HTTPS di mana-mana ...

masukkan deskripsi gambar di sini

JasonDavis
sumber
12
[WTF - Saya tidak dapat menambahkan jawaban (walaupun sepertinya saya memiliki cukup perwakilan).] Jawaban saya (sebagian) adalah bahwa TERKADANG ITU BURUK . Pertimbangkan untuk melewatkan COOKIE atau API Key dalam GET melalui HTTP. Jika situs Anda mengalihkan permintaan HTTP ke permintaan HTTPS, panggilan ini akan berfungsi, tetapi Kunci COOKIE atau API akan ditransmisikan dalam ruang terbuka yang terbuka. Beberapa API mematikan HTTP, pendekatan yang lebih kuat - tidak ada HTTP sama sekali sehingga Anda bahkan tidak bisa membuatnya berfungsi kecuali Anda menggunakan HTTPS. Contoh: "Semua permintaan API harus dilakukan melalui HTTPS. Panggilan yang dilakukan melalui HTTP biasa akan gagal" dari stripe.com/docs/api?lang=php#authentication
codingoutloud
8
@codingoutloud - alternatifnya adalah semuanya terjadi melalui HTTP tanpa HTTPS sama sekali. Bagaimana itu lebih baik?
Mark Henderson
3
@BenCrowell, itu karena captive portal terlihat banyak sekali seperti sslstripserangan redirect -gaya (mereka berdua permintaan man-in-the-middle membajak) sehingga HSTS -aware browser akan memblokir mereka berdua.
Jeffrey Hantin
3
Ketahuilah bahwa menggunakan https berarti semua yang Anda sertakan juga harus https atau mungkin tidak memuat - mis. memuat jquery using src="://example.com/jquery.js"- perhatikan kurangnya httpatau httpsjadi browser memuat yang sesuai. Saya mengalami mimpi buruk mencoba untuk mendapatkan beberapa barang Amazon yang tertanam untuk dimuat dengan benar karena API (dimuat melalui https) menghasilkan tautan http - artinya mereka tidak berfungsi dengan baik sampai saya menemukan parameter tidak berdokumen untuk beralih tautan https
Dasar
3
Jason; pembaruan Anda harus menjadi pertanyaan baru, mungkin di Webmaster karena tidak terkait (secara teknis) dengan pertanyaan awal Anda. Tapi mungkin style sheet Anda berasal dari domain yang tidak aman.
Mark Henderson

Jawaban:

316

The [R]bendera sendiri adalah 302pengalihan ( Moved Temporarily). Jika Anda benar-benar ingin orang menggunakan versi HTTPS situs Anda (petunjuk: Anda tahu), maka Anda harus menggunakan [R=301]untuk pengalihan permanen:

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

A 301menjaga semua pagerank google-fu dan susah payah Anda tetap utuh . Pastikan mod_rewritediaktifkan:

a2enmod rewrite

Untuk menjawab pertanyaan Anda:

Apakah buruk untuk mengalihkan http ke https?

Tidak. Ini sangat bagus.

Mark Henderson
sumber
3
Terima kasih atas informasinya, bos saya memberi tahu saya alasan ia hanya menjalankan https pada halaman tertentu di situsnya, adalah karena ia menggunakan lebih banyak sumber daya server untuk menjalankannya di setiap halaman. Apakah Anda tahu sesuatu tentang itu atau jika itu benar?
JasonDavis
9
@jasondavis Hanya jika Anda tidak menghabiskan beberapa menit untuk mengoptimalkannya .
Michael Hampton
10
"Ini menggunakan lebih banyak sumber daya server untuk menjalankannya di setiap halaman." CPU modern memiliki fitur akselerasi enkripsi yang membuat SSL hampir gratis. Jangan khawatir tentang overhead.
Adam Davis
41
@AdamDavis Algoritma crypto mungkin ringan, tetapi overhead jabat tangan masih ada. Juga, HTTPS mencegah proxy HTTP dari caching konten Anda. Dalam kebanyakan kasus, overhead HTTPS minimal dan bermanfaat, tetapi berhati-hatilah untuk menggeneralisasi secara berlebihan.
200_sukses
6
Membunuh caching bersama, yang berguna untuk beberapa pola penggunaan situs, dan sering melindungi sedikit (pentingkah orang tahu Anda mengunjungi situs, tetapi bukan perincian tentang apa yang Anda lakukan? Itulah satu-satunya situasi di mana SSL bermanfaat). Keuntungan utama SSL pada setiap sumber daya bukanlah bahwa Anda perlu "mengamankan" misalnya orang yang melihat "tentang kami", tetapi Anda tidak dapat menyelinap dan gagal menggunakannya dalam kasus di mana Anda seharusnya.
Jon Hanna
49

Sementara saya mendukung gagasan situs SSL saja, saya akan mengatakan satu kelemahan adalah biaya overhead tergantung pada desain situs Anda. Maksud saya misalnya jika Anda menyajikan banyak gambar individu dalam tag img, ini dapat menyebabkan situs Anda berjalan jauh lebih lambat. Saya akan menyarankan siapa pun yang menggunakan server SSL saja untuk memastikan mereka bekerja pada yang berikut ini.

  1. Periksa seluruh situs untuk tautan internal dan pastikan semuanya menggunakan HTTPS jika Anda menentukan nama domain Anda sendiri di tautan, sehingga Anda tidak menyebabkan pengalihan Anda sendiri.
  2. Perbarui <meta property="og:url"untuk menggunakan versi https domain Anda.
  3. Jika Anda menggunakan <base href=lagi perbarui untuk menggunakan HTTPS.
  4. Instal protokol SPDY jika memungkinkan
  5. Pastikan untuk menggunakan sprite Gambar CSS jika memungkinkan, untuk mengurangi jumlah permintaan.
  6. Perbarui peta situs Anda untuk menunjukkan status https, jadi laba-laba dari waktu ke waktu mempelajari perubahan ini.
  7. Ubah preferensi Mesin Pencari seperti Alat Webmaster Google untuk memilih HTTPS
  8. Bila mungkin, keluarkan media staksis apa pun ke server HTTPS CDN.

Jika hal di atas ditangani, maka saya ragu Anda akan memiliki banyak masalah.

TheBritishGeek
sumber
SPDY adalah saran yang bagus; bahkan ada tampaknya modul menambahkan dukungan SPDY untuk Apache 2.x .
Calrion
18
Menggunakan "//yourserver.com/some-uri" alih-alih " yourserver.com/some-uri " menyelesaikan masalah (1) karena browser akan memilih skema yang sesuai (http atau https) tergantung pada skema halaman yang dimuat dengan .
MauganRa
1
@ MauganRa Kecuali, tentu saja, itu adalah tautan dari halaman artikel http ke halaman login https, misalnya.
Mołot
4
Google melihat URL yang dikunjungi seseorang melalui Referertajuk. Misalnya situs ini menggunakan jQuery dari Google CDN dan browser saya mengirim permintaan ke Google setiap kali saya memuat ulang situs. Dengan demikian Referertajuk juga dikirimkan ke Google yang disetel ke URL situs ini. Jadi Google dapat melacak situs yang saya kunjungi selama waktu alamat IP saya tidak berubah (dan jika saya menggunakan layanan Google selama waktu ini, Google juga dapat menghubungkan informasi ini dengan akun Google saya).
Stephan Kulla
1
Untuk 1) Saya baru saja melakukan pencarian dan mengganti di http database MySQL saya ke https ... Saya menggunakan WordPress sehingga membuatnya mudah untuk memperbarui ratusan tautan
JasonDavis
38

Saya telah mengatur https maka Anda harus menggunakannya di mana-mana di situs. Anda akan menghindari risiko masalah konten campuran dan jika Anda memiliki alat yang diperlukan, mengapa tidak membuat seluruh situs aman?

Mengenai pengalihan dari http ke https jawabannya tidak sesederhana itu.

Mengarahkan ulang akan membuat lebih mudah bagi pengguna Anda, mereka cukup mengetik whateversite.com dan akan diarahkan ke https.

Tapi. Bagaimana jika pengguna terkadang berada di jaringan yang tidak aman (atau dekat dengan Troy Hunt dan Pineapple-nya )? Kemudian pengguna akan meminta http://whateversite.com karena kebiasaan lama. Itu adalah http. Itu bisa dikompromikan. Arahan ulang dapat mengarah ke https://whateversite.com.some.infrastructure.long.strange.url.hacker.org . Untuk pengguna biasa itu akan terlihat cukup sah. Tapi lalu lintas bisa dicegat.

Jadi kami memiliki dua persyaratan yang bersaing di sini: Agar ramah pengguna dan aman. Untungnya, ada obat yang disebut header HSTS . Dengan itu Anda dapat mengaktifkan pengalihan. Peramban akan pindah ke situs yang aman, tetapi berkat tajuk HSTS juga ingat. Ketika pengguna mengetik whateversite.com yang duduk di jaringan tidak aman itu, browser akan langsung masuk ke https, tanpa harus beralih melalui pengalihan melalui http. Kecuali Anda berurusan dengan data yang sangat sensitif, saya pikir itu adalah pertukaran yang adil antara keamanan dan kegunaan untuk sebagian besar situs. (Ketika saya baru-baru ini membuat aplikasi yang menangani rekam medis, saya membuka semua https tanpa arahan). Sayangnya Internet Explorer tidak memiliki dukungan untuk HSTS ( sumber), jadi jika audiens target Anda sebagian besar menggunakan IE dan datanya sensitif, Anda mungkin ingin menonaktifkan arahan ulang.

Jadi jika Anda tidak menargetkan pengguna IE, silakan dan gunakan redirect, tetapi aktifkan header HSTS juga.

Anders Abel
sumber
Lebih banyak orang perlu memperhatikan ini juga. Hal lain adalah bahwa orang menganggap mereka aman karena titik akhirnya adalah HTTPS, mengabaikan fakta bahwa semua informasi yang dikirim ke halaman dalam GET atau POST dalam teks biasa.
Velox
3
@Velox - Saya tidak berpikir implikasi dari "orang menganggap mereka aman karena titik akhirnya adalah HTTPS, mengabaikan fakta bahwa semua informasi yang dikirim ke halaman dalam GET atau POST dalam teks biasa" cukup akurat. Walaupun ada beberapa gotchas, GET params kueri tidak melakukan perjalanan dengan jelas selama transportasi melalui HTTPS. Lihat misalnya: stackoverflow.com/questions/323200/... Payload POST juga dilindungi, sementara juga tidak rentan terhadap pendataan dan header pengarah.
codingoutloud
@codingoutloud Itulah poin saya. Lebih dari HTTPS mereka dienkripsi, tetapi dalam permintaan awal ke halaman HTTP mereka tidak dienkripsi.
Velox
1
@Velox - Jika seluruh situs dialihkan ke HTTPS, maka tidak mungkin bahwa parameter GET akan dikirim sebelum HTTPS ditendang (dan semuanya akan tetap HTTPS setelah titik itu). Masih ada satu permintaan awal di mana cookie akan dikirim, yang dapat diperbaiki dengan HSTS ... dan jendela serangan kecil untuk SSLStrip, yang mungkin bisa dikalahkan oleh JavaScript, tapi itu adalah perlombaan senjata sendiri.
Brilliand
@Brilliand Fair point, tetapi titik lemah dalam keamanan membuat semuanya menjadi lemah. Selalu layak dipertimbangkan.
Velox
22

Tidak ada yang salah dengan ini, dan sebenarnya ini praktik terbaik (untuk situs yang harus dilayani melalui koneksi yang aman). Faktanya, apa yang Anda lakukan sangat mirip dengan konfigurasi yang saya gunakan:

<VirtualHost 10.2.3.40:80>
  ServerAdmin [email protected]
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

The 301kode status menunjukkan permanen redirect, menginstruksikan klien mampu menggunakan URL aman untuk koneksi masa depan (misalnya memperbarui bookmark).

Jika Anda hanya akan melayani situs melalui TLS / SSL, saya akan merekomendasikan arahan lebih lanjut untuk mengaktifkan HTTP Strict Transport Security (HSTS) di host virtual aman Anda :

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

Header ini menginstruksikan klien yang mampu (sebagian besar dari mereka hari ini, saya percaya) bahwa mereka hanya boleh menggunakan HTTPS dengan domain yang disediakan ( secure.example.com, dalam hal ini) untuk 1234detik berikutnya . The ; includeSubdomainsporsi opsional dan menunjukkan bahwa direktif berlaku tidak hanya untuk domain saat ini, tetapi setiap bawahnya (misalnya alpha.secure.example.com). Perhatikan bahwa header HSTS hanya diterima oleh browser saat disajikan melalui koneksi SSL / TLS!

Untuk menguji konfigurasi server Anda terhadap praktik terbaik saat ini, sumber daya gratis yang baik adalah layanan Uji Server SSL Qualys ; Saya akan bertujuan untuk mencetak setidaknya A- (Anda tidak bisa mendapatkan lebih dari itu dengan Apache 2.2 karena kurangnya dukungan untuk kriptografi kurva eliptik).

Calrion
sumber
Saya harus menambahkan, mengirimkan header Strict-Transport-Security: max-age=0akan meniadakan arahan sebelumnya; seperti biasa, ini harus dikirim melalui HTTPS untuk diterima, tetapi ini adalah cara praktis untuk membatalkan hal-hal jika Anda memutuskan Anda juga perlu menggunakan HTTP pada domain.
Calrion
5

Wow ! redirect HTTP ke HTTPS adalah hal yang sangat bagus dan saya tidak dapat melihat kekurangan untuk itu.

Pastikan klien Anda memiliki CA yang tepat untuk menghindari peringatan yang tidak ramah pengguna tentang sertifikat di browser.

Selain itu, cara Anda mengatur Apache untuk mengalihkan ke HTTPS tampaknya baik-baik saja.

KRFFR
sumber
5

Apakah buruk untuk mengalihkan http ke https?

Tidak, tidak sama sekali. Sebenarnya, itu hal yang baik untuk dilakukan!

Saat pengalihan:

Itu bisa lebih efisien, dengan sepenuhnya menghilangkan penulisan ulang . Inilah konfigurasi saya pada situasi yang sama ...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>
Pothi Kalimuthu
sumber
4

HTTPS tidak sepenuhnya aman. Tentu saja, biasanya memaksa HTTPS adalah hal yang baik. Ini mencegah penjahat normal melakukan hal buruk kepada pengguna Anda.

Tapi tolong ingat untuk memeriksa Anda Pengaturan SSL seperti pengaturan SSLCiphers. Nonaktifkan hal-hal seperti RC4 crypto, protokol SSLv2 dan SSLv3. Juga, Anda harus mencari tahu, apakah perpustakaan sistem crypto sistem Anda mendukung TLS1.2 (yang merupakan hal yang ingin Anda miliki;))

Aktifkan SSL, itu hal yang baik.

Tobias Mädel
sumber
Entropy tidak digunakan ( setidaknya jika Anda bertahan melawan penyerang berbasis Bumi daripada melakukan voodoo ). Entah Anda mulai dengan entropi yang tidak mencukupi, dan Anda tidak dapat melakukan apa pun yang membutuhkan keacakan, atau Anda mulai dengan entropi yang cukup, dan Anda tetap memiliki entropi yang memadai tidak peduli berapa banyak keacakan yang Anda hasilkan.
Gilles
Maaf, apa ? Ada sejumlah operasi di Linux yang menuntut entropi kuat yang diturunkan dari perangkat keras daripada entropi berbasis-PRNG yang mungkin cukup baik, dan itu memang dapat memblokir jika kedalaman pool rendah. Sangat mungkin untuk memulai dengan entropi yang cukup pada sistem Linux, tetapi dengan terlalu banyak menguras kumpulan, menyebabkan beberapa operasi untuk diblokir.
MadHatter
3

Secara pribadi saya semua untuk penggunaan SSL untuk mengamankan koneksi di web, namun saya merasa bahwa semua jawaban lain yang terlewatkan di sini adalah bahwa tidak setiap perangkat dan perangkat lunak yang mampu melakukan koneksi HTTP akan dapat menggunakan SSL, jadi saya akan mempertimbangkan menyediakan beberapa cara bagi pengguna untuk menghindarinya jika tidak didukung untuk mereka. Mungkin juga bahwa orang-orang di beberapa Negara di mana teknologi enkripsi ilegal maka tidak akan diizinkan untuk mengakses situs Anda. Saya akan mempertimbangkan untuk menambahkan halaman arahan yang tidak terenkripsi dengan tautan untuk memaksa versi situs yang tidak aman tetapi kecuali jika pengguna secara khusus memilih untuk melakukan seperti yang Anda katakan dan hanya meneruskannya ke versi HTTPS.

Vality
sumber
Masalah dengan solusi seperti memiliki halaman arahan HTTP biasa, bahkan jika dipisahkan dengan benar, adalah bahwa halaman ini dibiarkan terbuka untuk manipulasi. Yaitu, tidak ada jaminan aktual bahwa tautan untuk versi HTTPS dari situs disampaikan secara utuh kepada pengunjung.
Håkan Lindqvist
3

Berikut adalah beberapa masalah sapuan jari yang luas:

  • MITM / SSLSTRIP : Ini adalah peringatan besar. Jika Anda akan melayani situs Anda melalui HTTPS, maka nonaktifkan HTTP di situs . Jika tidak, Anda membiarkan pengguna Anda terbuka untuk berbagai serangan man-in-the-middle termasuk SSLSTRIP, yang akan mencegat permintaan dan melayani mereka secara diam-diam melalui HTTP, memasukkan skrip malware mereka sendiri ke dalam aliran. Jika pengguna tidak memperhatikan, maka mereka akan berpikir bahwa sesi mereka aman ketika sebenarnya tidak.

    • Masalah dengan ini, meskipun, adalah bahwa jika situs Anda adalah situs publik dan Anda hanya menonaktifkan HTTP, Anda mungkin kehilangan banyak pengunjung. Bahkan mungkin tidak terpikir oleh mereka untuk mencoba HTTPS jika situs tidak mau memuat dengan HTTP.
  • Jika situs Anda memerlukan login yang aman, maka seluruh sesi pengguna harus diamankan. Jangan mengautentikasi melalui HTTPS, lalu arahkan kembali pengguna ke HTTP. Jika ya, sekali lagi, Anda membuat pengguna Anda rentan terhadap serangan MITM. Pendekatan standar untuk otentikasi hari ini adalah untuk mengotentikasi sekali, lalu meneruskan token otentikasi bolak-balik (dalam cookie). Tetapi jika Anda mengautentikasi melalui HTTPS kemudian mengarahkan ulang ke HTTP, maka seorang man-in-the-middle dapat mencegat cookie itu dan menggunakan situs tersebut seolah-olah mereka adalah pengguna terautentikasi Anda, melewati keamanan Anda.

  • Masalah "kinerja" dengan HTTPS adalah untuk semua tujuan praktis terbatas pada jabat tangan yang terlibat dalam menciptakan koneksi baru. Lakukan apa yang Anda bisa untuk meminimalkan kebutuhan akan beberapa koneksi HTTPS dari URL dan Anda akan berada jauh di depan. Dan itu terus terang benar bahkan jika Anda menyajikan konten Anda melalui HTTP. Jika Anda membaca di SPDY, Anda akan menyadari bahwa semua yang dilakukannya diarahkan untuk melayani semua konten dari satu URL melalui satu koneksi. Ya, menggunakan HTTPS memengaruhi caching. Tapi berapa banyak situs web yang hanya statis, konten yang bisa di-cache hari ini? Anda cenderung mendapatkan lebih banyak uang dengan menggunakan caching di server web Anda untuk meminimalkan kueri basis data yang berlebihan, mengambil data yang tidak berubah berulang-ulang, dan mencegah jalur kode mahal dari mengeksekusi lebih sering daripada yang diperlukan.

Craig
sumber
Hal yang dapat Anda lakukan untuk benar-benar mengatasi sslstrip adalah menggunakan HSTS (lebih disukai dapatkan pengaturan HSTS Anda dimuat sebelumnya ). Apakah Anda menerima permintaan melalui HTTP biasa atau tidak sebenarnya tidak masalah dalam hal ini, MITM dapat menjawab lebih dari HTTP polos (mungkin proksi ke situs HTTPS Anda) bahkan jika Anda hanya menerima permintaan HTTPS.
Håkan Lindqvist
@ HåkanLindqvist Saya benar-benar mendapatkan downvote dari Anda? Apakah saya memberikan saran buruk atau saran yang baik sehubungan dengan tidak mengautentikasi melalui HTTPS kemudian beralih ke HTTP untuk sisa sesi? Apakah saya memberikan nasihat buruk sehubungan dengan mitos kinerja HTTPS? Juga, jika klien pada awalnya mencoba terhubung menggunakan HTTPS, MITM tidak dapat mencegat dan merespons tanpa memicu peringatan di browser, karena sertifikat mereka tidak akan cocok kecuali mereka memiliki sertifikat yang dicuri atau berhasil dipalsukan. Di sisi lain, jika situs menerima koneksi HTTP, intersepsi lebih mudah. Either way, HTTPS menaikkan standar.
Craig
..dan tentu saja saya setuju dengan sepenuh hati dengan menggunakan HSTS.
Craig
Masalah saya dengan jawabannya adalah item pertama dalam daftar yang mengklaim alamat sslstrip sementara sebenarnya tidak (berbicara tentang mitos). Apa yang saya coba sampaikan dalam komentar awal saya adalah bahwa jika Anda memiliki MITM aktif (yang pertama-tama Anda butuhkan untuk sslstrip), penyerang pada dasarnya dapat menjadi "situs" dari perspektif klien; itu adalah penyerang yang memutuskan apakah mereka ingin menerima koneksi HTTP sederhana dari klien, bagaimana server web Anda yang sebenarnya dalam hal itu tidak mempengaruhi apa yang dapat atau akan dilakukan penyerang.
Håkan Lindqvist
@ HåkanLindqvist Kecuali jika pengunjung sengaja mencoba untuk terhubung dengan HTTPS, penyerang tidak dapat memenuhi permintaan itu tanpa melemparkan bendera di browser, kecuali jika mereka berhasil mencuri sertifikat server atau entah bagaimana berhasil memalsukan sertifikat server, yang harus mereka tempa, lakukan untuk mengalihkan koneksi ke HTTP. HTTPS masih menaikkan bilah. Tentu saja jika pengunjung melakukan upaya koneksi awal melalui HTTP, semua taruhan benar-benar mati.
Craig
1

Secara teknis ini bukan jawaban untuk pertanyaan awal Anda, tetapi jika Anda menggunakan ekstensi Google Chrome HTTPSEverywhere (saya yakin ada ekstensi serupa di peramban lain), ekstensi itu secara otomatis mengalihkan situs dengan HTTP ke situs yang sama dengan HTTPS. Saya telah menggunakannya untuk sementara waktu, dan saya tidak punya masalah (kecuali mungkin memperlambat, tapi saya belum mengujinya). HTTPSEverywhere dapat diubah oleh aturan tertentu di sisi server, tetapi karena saya belum melakukan banyak hal di area itu, saya tidak yakin dengan detail yang tepat.

Kembali ke pertanyaan Anda yang sebenarnya, jika Anda menggunakan sesuatu seperti HTTPSEverywhere, bahkan ada lebih sedikit insentif untuk menggunakan HTTP-only, meskipun saya membayangkan sulit untuk membuat aturan yang benar ketika Anda membutuhkannya.

trysis
sumber
1

satu-satunya penarikan teknis ke HTTPS melalui HTTP adalah bahwa secara komputasi lebih mahal untuk memproses permintaan HTTPS daripada HTTP biasa

Namun mengingat bahwa sebagian besar server modern memiliki CPU bertenaga tinggi, dampak ini biasanya dapat diabaikan kecuali jika Anda berada pada tingkat lalu lintas yang sangat tinggi di mana Anda lebih cenderung menggunakan load balancers.

Dengan munculnya protokol seperti SPDY yang membutuhkan SSL / TLS untuk bekerja, ini sebenarnya melawan overhead komputasi yang disebutkan sebelumnya dengan memberikan peningkatan kinerja yang signifikan berkaitan dengan beberapa permintaan dan mendapatkan aset kepada klien lebih cepat secara keseluruhan.

anthonysomerset
sumber
Masalah dengan kinerja HTTPS adalah bahwa membangun koneksi baru lebih mahal karena ada lebih bolak-balik yang terlibat dan karena enkripsi / dekripsi asimetris jauh lebih mahal daripada enkripsi / dekripsi simetris. Setelah handshake koneksi membuat kunci enkripsi simetris bersama, overhead yang sedang berlangsung hampir tidak relevan (sangat kecil). Jika Anda membaca di SPDY, Anda akan melihat bahwa tujuan dari semua hal mewah yang dilakukannya pada dasarnya adalah untuk melayani semua konten dari URL melalui satu koneksi, mengurangi overhead jabat tangan koneksi.
Craig
1

Sangat bagus untuk mengarahkan ulang ke https, tetapi saya membacanya juga tergantung pada bagaimana Anda mengatur pengalihan tersebut.

Membuat server virtual khusus untuk mengalihkan permintaan http yang masuk ke koneksi https Anda seperti yang disarankan dalam jawaban di security.stackexchange.com terdengar sangat cerdas dan akan menutup beberapa ancaman keamanan tambahan. Konfigurasi di Apache akan terlihat seperti ini:

# 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>
Melayu
sumber