Mengapa tidak menggunakan HTTPS untuk semuanya?

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.

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.

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

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".

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.

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.

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.

https lebih haus sumber daya daripada http normal.

Ini menuntut lebih banyak dari server dan klien.

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

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.

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?

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.

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.

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.

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.

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.