Mengapa tidak menggunakan HTTPS untuk semuanya?


126

Jika saya membuat server, dan memiliki sertifikat SSL, mengapa saya tidak menggunakan HTTPS untuk seluruh situs, bukan hanya untuk pembelian / login? Saya pikir akan lebih masuk akal hanya untuk mengenkripsi seluruh situs, dan melindungi pengguna sepenuhnya. Ini akan mencegah masalah seperti memutuskan apa yang harus diamankan karena semuanya akan, dan itu sebenarnya bukan ketidaknyamanan bagi pengguna.

Jika saya sudah menggunakan HTTPS untuk bagian dari situs, mengapa saya tidak ingin menggunakannya untuk seluruh situs?

Ini adalah pertanyaan terkait: Mengapa https hanya digunakan untuk masuk? , tetapi jawabannya tidak memuaskan. Jawabannya mengasumsikan Anda belum dapat menerapkan https ke seluruh situs.


2
Saya heran bahwa perusahaan jasa keuangan masih menggunakan http.
Tom Hawtin - tackline

15
@ Tom Saya berharap beberapa situs yang mengirimi saya pesan phishing akan menggunakan https untuk situs palsu mereka, jadi saya tahu saya memberikan data saya ke phisher yang tepat.
WhirlWind

Terima kasih telah mengajukan pertanyaan ini. Saya berasumsi kinerja adalah yang alasan dan itu akan menjadi jauh lebih buruk dari http. Melihat jawabannya, sepertinya performanya tidak terlalu buruk, yang membuat saya terlalu heran.
sundar - Reinstate Monica

4
Saya pikir Anda memilih jawaban terburuk di halaman, dengan currenlty 11 turun suara. Jawaban yang Anda pilih sama sekali mengabaikan keamanan dan praktik terbaik.
Benteng

5
Pertanyaan ini benar-benar layak mendapatkan jawaban modern yang terdidik.
Old Badman Gray

Jawaban:


17

Saya bisa memikirkan beberapa alasan.

  • Beberapa browser mungkin tidak mendukung SSL.
  • SSL dapat menurunkan kinerja. Jika pengguna mengunduh file publik yang besar, mungkin ada beban sistem untuk mengenkripsi ini setiap kali.

137
Browser apa yang tidak mendukung SSL?
Malfist

6
Beberapa kompilasi lynx tidak akan mendukungnya. Jika Anda hanya mendukung browser yang lebih baru, Anda seharusnya baik-baik saja.
WhirlWind

5
Saya mencari melalui ini: iweb.tntech.edu/hexb/publications/https-STAR-03122003.pdf "Setelah server jenuh, kinerja sistem HTTPS mencapai sekitar 67% dari HTTP dalam hal throughput."
WhirlWind

16
Saya tidak t buy this explanation. 1) Donmenggunakan browser yang tidak mendukung SSL pada 2013. 2) bahkan google menggunakan SSL sekarang 3) dengan benar, Anda dapat mengarahkan lalu lintas http ke tautan https kanan.
jfyelle

4
Jawaban buruk, mengapa begitu manu upvotes? Peramban apa yang tidak mendukung ssl dan pengguna tidak harus ingat mengetik https, dapat ditangani dengan
arahan

25

Selain alasan lain (terutama terkait kinerja), Anda hanya dapat meng-host domain tunggal per alamat IP * saat menggunakan HTTPS.

Satu server dapat mendukung banyak domain dalam HTTP karena Server header HTTP memungkinkan server mengetahui domain mana yang akan ditanggapi.

Dengan HTTPS, server harus menawarkan sertifikatnya kepada klien selama jabat tangan TLS awal (yang sebelum HTTP dimulai). Ini berarti bahwa header Server belum dikirim sehingga tidak ada cara bagi server untuk mengetahui domain mana yang diminta dan sertifikat mana (www.foo.com, atau www.bar.com) untuk merespons.


* Catatan Kaki: Secara teknis, Anda dapat meng-host beberapa domain jika Anda meng-host-nya pada port yang berbeda, tetapi itu umumnya bukan opsi. Anda juga dapat meng-host beberapa domain jika sertifikat SSL Anda memiliki kartu liar. Misalnya, Anda dapat menghosting foo.example.com dan bar.example.com dengan sertifikat * .example.com


5
Tidakkah memiliki sertifikat SSL wildcard menyelesaikan masalah ini?
Rob

Catatan kaki bertentangan dengan jawabannya: / Anda dapat menggunakan sertifikat wildcard dan menghosting domain apa pun. en.wikipedia.org/wiki/Wildcard_certificate
lucascaro

23
Masalah ini telah lama diselesaikan oleh Indikasi Nama Server, yang didukung oleh semua browser utama saat ini. en.wikipedia.org/wiki/Server_Name_Indication
tia

@tia kecuali tidak semua server web mendukungnya
meffect

2
@ efek ... Tetapi banyak yang melakukannya, termasuk apache2, nginx, lighttpd, dan nodejs. Selain itu, pengembang dapat memilih proxy terbalik apa yang mereka gunakan untuk penerowongan HTTPS. Mengatakan "tidak ada klien yang mendukungnya" akan menjadi poin yang valid jika itu benar karena itu adalah sesuatu yang tidak dapat dikontrol oleh pengembang dan harus diperhitungkan. Namun, mengatakan "beberapa server tidak mendukungnya" sebagian besar tidak relevan, justru karena tidak perlu dipertanggungjawabkan. Terutama ketika semua server mainstream yang benar-benar memiliki dukungan.
Parthian Shot

13

SSL / TLS hampir tidak cukup sering digunakan. HTTPS harus digunakan untuk seluruh sesi , pada titik tidak dapat ID Sesi dikirim melalui HTTP. Jika Anda hanya menggunakan https untuk masuk maka Anda jelas-jelas melanggar The OWASP top 10 untuk 2010 "A3: Otentikasi Rusak dan Manajemen Sesi".


Ini mungkin asumsi yang terlalu luas. Tidak ada alasan keadaan sesi tidak dapat dikelola secara terpisah untuk http dan https melalui operasi login https tunggal. Tampaknya lebih banyak pekerjaan daripada nilainya dan mengundang bug yang terkait dengan keamanan tetapi tampaknya tidak secara otomatis merupakan pelanggaran yang jelas.
Einstein

@ Einstein tolong baca OWASP A3, sangat jelas. Ingatlah bahwa penyerang tidak memerlukan nama pengguna / kata sandi jika ia memiliki cookie dari sesi yang diautentikasi.
benteng

Situs menyediakan https / http campuran. Login https menyediakan token sesi keamanan rendah dan tinggi yang terpisah. Token keamanan rendah yang ditugaskan hanya untuk sesi http tidak akan berfungsi untuk operasi yang membutuhkan keamanan tinggi. Dari yang saya baca, OWASP A3 sebagian menerangi masalah dasar kemungkinan akses keamanan tinggi melalui transportasi keamanan rendah.
Einstein

@ Einstein Jadi Anda tidak setuju bahwa Session id digunakan untuk mengotentikasi browser web? Mempertimbangkan pola serangan ini, dalam serangan xss Anda mencoba untuk mendapatkan nilai document.cookiesehingga penyerang dapat menggunakan ini untuk mengotentikasi. Nilai ini juga dapat diperoleh dengan mengendus lalu lintas, yang https berhenti. Saya tidak yakin apa maksud Anda.
benteng

Dalam skenario Anda, id sesi untuk http tidak akan berguna bagi sumber daya yang dilindungi https jika suatu sistem membuat dua sesi terpisah untuk satu tindakan otentikasi untuk memungkinkan kedua protokol digunakan tanpa sesi https dan sumber daya terkait yang diekspos oleh cookie sesi http. Misalnya sesi http dapat digunakan untuk identifikasi akses ke sumber daya publik untuk tujuan pelaporan atau akses ke papan pesan publik tetapi mereka tidak akan valid untuk sumber daya yang aman.
Einstein

12

Mengapa tidak mengirim setiap surat siput ke dalam amplop buram-bukti tamper oleh Registered Mail? Seseorang dari Kantor Pos akan selalu memiliki hak asuh pribadi, jadi Anda bisa yakin bahwa tidak ada yang mengintip surat Anda. Jelas, jawabannya adalah bahwa sementara beberapa surat sepadan dengan biaya, sebagian besar surat tidak. Saya tidak peduli jika ada yang membaca tulisan saya, "Senang Anda keluar dari penjara!" kartu pos ke Paman Joe.

Enkripsi tidak gratis, dan itu tidak selalu membantu.

Jika sebuah sesi (seperti berbelanja, perbankan, dll.) Akan berakhir menggunakan HTTPS, tidak ada alasan kuat untuk tidak membuat seluruh sesi HTTPS sedini mungkin.

Pendapat saya adalah bahwa HTTPS harus digunakan hanya ketika diperlukan, baik karena permintaan atau tanggapan perlu dijaga dari pengintaian menengah. Sebagai contoh, lihat di Yahoo! beranda. Meskipun Anda masuk, sebagian besar interaksi Anda akan melalui HTTP. Anda mengautentikasi melalui HTTPS dan mendapatkan cookie yang membuktikan identitas Anda, sehingga Anda tidak perlu HTTPS untuk membaca berita.


LOL !!! Bagus! Aku yakin tukang pos nakal membuka amplop dengan "Senang Anda keluar dari penjara" akan panik celananya sedikit dan reseal dengan sempurna ..
Andrei Rinea

19
Jika biaya email terdaftar 1% lebih tinggi daripada 300% lebih, saya akan menggunakannya untuk semuanya.
solublefish

3
You authenticate over HTTPS and get cookies that prove your identity, so you don't need HTTPS to read news stories.Itu bukan cara yang tepat untuk menangani sesi auth. Cookie harus disetel dengan bendera SECURE. Tetapi mengabaikan nasihat keamanan yang mengerikan itu sebentar ... Analogi email Anda tidak benar-benar akurat karena beberapa alasan. Seseorang adalah bahwa Anda biasanya tidak dapat menyuntikkan eksploitasi ke dalam surat kembali, atau menyamar sebagai orang lain tanpa hukuman, atau memasukkan pesan "Sesi Anda Kedaluwarsa" ke dalam surat kembali sehingga mereka memasukkan kembali kredensial yang mereka gunakan untuk kedua Yahoo! dan bank mereka.
Parthian Shot

Penggunaan kembali kata sandi dan perbaikan sesi, antara lain, bukan masalah dalam surat siput.
Parthian Shot

Itu adalah poin yang bagus, tetapi Anda menerapkan analisis 2016 untuk diskusi pada 2010.
David M

12

Alasan terbesar, di luar beban sistem, adalah karena ia merusak hosting virtual berbasis nama. Dengan SSL, ini adalah satu situs - satu alamat IP. Ini cukup mahal, dan juga lebih sulit untuk dikelola.


1 Its the alasan mengapa Google App Engine tidak mendukung https pada domain kustom. Menunggu TLS-SNI untuk lebih banyak didukung.
Sripathi Krishnan

1
Anda bisa mendapatkan ini kembali dengan perangkat keras pemutusan SSL. Dan jika beban sistem adalah masalah (itu untuk banyak orang!) Maka perangkat keras SSL mungkin merupakan cara untuk melakukannya.
Jason

kecuali Anda dapat memiliki beberapa domain dalam sertifikat yang sama.
lucascaro


7
Downvoting karena informasi dalam posting sudah usang. SNI sekarang didukung oleh semua browser utama.
Martin Törnwall

5

Untuk tautan latensi tinggi, jabat tangan TLS awal memerlukan perjalanan bolak-balik tambahan untuk memvalidasi rantai sertifikat (termasuk mengirim sertifikat perantara), menyetujui suite sandi dan membuat sesi. Setelah sesi dibuat, permintaan selanjutnya dapat menggunakan cache sesi untuk mengurangi jumlah perjalanan bolak-balik tetapi bahkan dalam kasus terbaik ini masih ada lebih banyak perjalanan bolak-balik dari yang dibutuhkan koneksi HTTP normal. Bahkan jika operasi enkripsi adalah round-trip gratis tidak dan bisa sangat terlihat pada link jaringan yang lebih lambat terutama jika situs tidak memanfaatkan http pipelining. Untuk pengguna broadband dalam segmen jaringan yang terhubung dengan baik, ini bukan masalah. Jika Anda melakukan bisnis secara internasional, membuat ulang https dapat dengan mudah menyebabkan penundaan yang nyata.

Ada pertimbangan tambahan seperti pemeliharaan server pada sesi yang membutuhkan memori yang secara signifikan lebih besar dan tentu saja operasi enkripsi data. Setiap situs kecil praktis tidak perlu khawatir tentang kemampuan server yang diberikan vs biaya perangkat keras saat ini. Setiap situs besar akan dengan mudah mampu membayar CPU / w AES atau kartu tambahan untuk menyediakan fungsionalitas serupa.

Semua masalah ini menjadi semakin tidak menjadi masalah seiring berjalannya waktu dan kemampuan perangkat keras dan jaringan meningkat. Dalam kebanyakan kasus saya ragu ada perbedaan nyata saat ini.

Mungkin ada pertimbangan operasional seperti pembatasan administratif pada lalu lintas https (pikirkan filter konten menengah..set al) mungkin beberapa peraturan perusahaan atau pemerintah. Beberapa lingkungan perusahaan memerlukan dekripsi data pada batas untuk mencegah kebocoran informasi ... gangguan dengan hotspot dan sistem akses berbasis web serupa yang tidak mampu menyuntikkan pesan dalam transaksi https. Pada akhirnya, menurut saya alasan untuk tidak menggunakan https secara default cenderung sangat kecil.


4

https lebih haus sumber daya daripada http normal.

Ini menuntut lebih banyak dari server dan klien.


3

Jika seluruh sesi dienkripsi maka Anda tidak akan dapat menggunakan caching untuk sumber daya statis seperti gambar dan js pada tingkat proxy misalnya ISP.


Ya, kecuali untuk proxy yang mengakhiri SSL, atau jika Anda menggunakan CDN yang mendukung HTTPS.
Tembakan Parthian

3

Anda harus menggunakan HTTPS di mana-mana, tetapi Anda akan kehilangan yang berikut:

  1. Anda seharusnya tidak menggunakan Kompresi SSL atau Kompresi HTTP di atas SSL, karena serangan BREACH dan CRIME. Jadi tidak ada kompresi jika respons Anda berisi pengidentifikasi sesi atau csrf. Anda dapat mengurangi ini dengan meletakkan sumber daya statis Anda (gambar, js, css) pada domain tanpa cookie, dan menggunakan kompresi di sana. Anda juga dapat menggunakan minifikasi HTML.

  2. Satu sertifikat SSL, satu alamat IP, kecuali menggunakan SNI, yang tidak berfungsi pada semua browser (android lama, blackberry 6, dll).

  3. Anda tidak boleh meng-host konten eksternal apa pun pada halaman Anda yang tidak berasal dari SSL.

  4. Anda kehilangan tajuk HTTP Referer outbound ketika browser menuju ke halaman HTTP, yang mungkin atau mungkin tidak menjadi masalah bagi Anda.


0

Alasan yang jelas adalah kinerja: semua data harus dienkripsi oleh server sebelum pengiriman dan kemudian didekripsi oleh klien setelah diterima, yang merupakan pemborosan waktu jika tidak ada data sensitif. Ini juga dapat memengaruhi seberapa banyak situs Anda di-cache.

Ini juga berpotensi membingungkan bagi pengguna akhir jika semua alamat menggunakan https://daripada yang akrabhttp:// . Juga, lihat jawaban ini:

Mengapa tidak selalu menggunakan https saat menyertakan file js?


9
mengapa itu membingungkan pengguna? Berapa banyak yang benar-benar melihat protokol uri?
Malfist

Hari ini, 10 tahun kemudian, https lebih umum dan http akan membingungkan
madprops

0

https mengharuskan server untuk mengenkripsi dan mendekripsi permintaan dan respons klien. Dampak kinerja akan bertambah jika server melayani banyak klien. Itulah sebabnya sebagian besar implementasi https saat ini hanya terbatas pada otentikasi kata sandi. Tetapi dengan meningkatnya daya komputasi ini dapat berubah, setelah semua Gmail menggunakan SSL untuk seluruh situs.


0

Selain tanggapan WhirlWind, Anda harus mempertimbangkan biaya dan penerapan sertifikat SSL, masalah akses (mungkin, meskipun tidak mungkin, bahwa klien mungkin tidak dapat berkomunikasi melalui port SSL), dll.

Menggunakan SSL bukan jaminan keamanan. Jenis perlindungan ini perlu dibangun ke dalam arsitektur aplikasi, daripada mencoba mengandalkan beberapa peluru ajaib.


2
Karena pengguna telah melindungi bagian dari situs, biaya sertifikat kurang lebih dapat diperdebatkan.
futureelite7

2
@ futureelite7 poin bagus, tapi mungkin relevan dengan orang lain yang mungkin meneliti topik ini di masa depan.
3Dave

Eksklusifisme adalah musuh keamanan. Mayoritas kelemahan pada barang-barang saya sendiri, berakar pada beberapa fitur keliru yang diterima oleh saya sendiri atau pendahulu dalam rencana produk. Saya menemukan bahwa memulai fitur karena menyebabkan kerentanan keamanan tidak membuat Anda lebih populer daripada menolaknya. Popularitas TIDAK HARUS penting, tetapi sayangnya itu bisa dan memang bisa. Di sepatu Anda, saya akan bertanya pada diri sendiri seberapa besar saya benar-benar ingin berurusan dengan pengguna tanpa jaminan, atau apakah aplikasi ini bahkan cocok untuk pengguna yang tidak dapat menggunakan enkripsi (pikirkan: perbankan, politik, aktivisme).
Jason

0

Saya diberitahu bahwa pada satu proyek di perusahaan kami, mereka menemukan bahwa bandwidth yang diambil oleh pesan SSL secara signifikan lebih daripada untuk pesan biasa. Saya percaya seseorang mengatakan kepada saya itu adalah data yang mengejutkan sebanyak 12 kali lipat. Saya belum memverifikasi ini sendiri dan kedengarannya sangat tinggi, tetapi jika ada semacam header ditambahkan ke setiap halaman dan sebagian besar halaman memiliki sejumlah kecil konten, yang mungkin tidak terlalu jauh.

Yang mengatakan, kerumitan bolak-balik antara http dan https dan melacak halaman mana yang sepertinya terlalu banyak usaha untuk saya. Saya hanya pernah mencoba untuk membangun sebuah situs yang mencampurkan mereka dan kami akhirnya meninggalkan rencana ketika kami tersandung oleh hal-hal kompleks seperti jendela pop-up yang dibuat oleh Javascript mendapatkan protokol yang salah yang menyertainya dan hal-hal semacam itu. Kami akhirnya hanya membuat seluruh situs https sebagai lebih sedikit masalah. Saya kira dalam kasus-kasus sederhana di mana Anda hanya memiliki layar login dan layar pembayaran yang perlu dilindungi dan itu adalah halaman sederhana, itu bukan masalah besar untuk mencampur-aduk.

Saya tidak akan terlalu khawatir tentang beban pada klien untuk mendekripsi. Biasanya klien akan menghabiskan lebih banyak waktu menunggu data datang dari yang dibutuhkan untuk memprosesnya. Sampai pengguna secara rutin memiliki koneksi internet gigabit / detik, kekuatan pemrosesan klien mungkin sangat tidak relevan. Kekuatan CPU yang diminta oleh server untuk mengenkripsi halaman adalah masalah yang berbeda. Mungkin ada masalah karena tidak dapat mengimbangi ratusan atau ribuan pengguna.


1
Bandwidth ekstra kecil bahkan dalam kasus terburuk.
Presiden James K. Polk

0

Satu poin kecil lainnya (mungkin seseorang dapat memverifikasi), Jika pengguna mengetik data ke item formulir seperti kotak teks dan kemudian karena alasan tertentu me-refresh halaman atau server crash keluar untuk kedua, data yang dimasukkan pengguna hilang menggunakan HTTPS tetapi dipertahankan menggunakan HTTP.

Catatan: Saya tidak yakin apakah ini khusus untuk peramban tetapi itu pasti terjadi pada peramban Firefox saya.


0

windows Server 2012 dengan IIS 8.0 sekarang menawarkan SNI yang merupakan Indikasi Nama Server yang memungkinkan beberapa Aplikasi Web SSL di IIS untuk di-host pada satu Alamat IP.


1
Apa hubungannya dengan pertanyaan itu? Ini fitur yang menarik, tetapi saya tidak melihat relevansinya.
user1618143
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.