it-swarm-id.com

Apa pro dan kontra dari SSL lebar situs (https)?

Apa pro dan kontra mengenkripsi semua lalu lintas HTTP untuk seluruh situs melalui SSL, yang bertentangan dengan SSL hanya pada halaman login?

80
Olivier Lalonde

Karena sebagian besar jawaban lain di sini berurusan dengan kelemahan SSL di seluruh situs (terutama masalah kinerja - namun ini dapat dengan mudah dikurangi dengan melepas terminasi SSL, baik ke kotak proxy SSL, atau kartu SSL), saya akan tunjukkan beberapa masalah dengan hanya memiliki halaman login lebih dari SSL, kemudian beralih ke non-SSL:

  • Sisa situs tidak diamankan (meskipun ini jelas, terkadang fokusnya terlalu banyak hanya pada kata sandi pengguna).
  • ID sesi pengguna harus ditransmisikan secara jelas, memungkinkannya dicegat dan digunakan, dan dengan demikian memungkinkan orang jahat menyamar sebagai pengguna Anda. (Ini sebagian besar tentang Firesheep hubbub tentang).
  • Karena poin sebelumnya, cookie sesi Anda tidak dapat ditandai dengan atribut secure, yang berarti cookie tersebut dapat diambil dengan cara tambahan.
  • Saya telah melihat situs-situs dengan login-only-SSL, dan tentu saja lalai untuk memasukkan dalam halaman Lupa kata sandi, halaman Ubah kata sandi, dan bahkan halaman Pendaftaran ...
  • Peralihan dari SSL ke non-SSL seringkali rumit, dapat memerlukan konfigurasi yang rumit pada server web Anda, dan dalam banyak kasus akan muncul pesan menakutkan bagi pengguna Anda.
  • Jika HANYA halaman login, dan f.e. ada tautan ke halaman login dari halaman beranda situs Anda - apa yang menjamin bahwa seseorang tidak akan melakukan spoof/memodifikasi/memotong situs Anda, dan mengarahkannya ke halaman login yang berbeda?
  • Lalu ada kasus di mana halaman login itu sendiri bukan SSL, tetapi hanya [~ # ~] kirimkan [~ # ~] adalah - karena itu satu-satunya waktu kata sandi dikirim, jadi itu harus aman, kan? Tetapi sebenarnya yang menghapus dari pengguna kemampuan untuk memastikan sebelumnya bahwa kata sandi dikirim ke situs yang benar, sampai terlambat. (E.g. Bank of America, dan banyak lainnya).
61
AviD

"Server overhead" meningkat sebagai "penipu" yang signifikan adalah mitos umum. Insinyur Google perhatikan bahwa ketika beralih gmail ke 100% SSL mereka tidak menggunakan perangkat keras tambahan, dan bahwa SSL menyumbang kurang dari 1% peningkatan beban CPU dan 2% dalam lalu lintas jaringan. Stack Overflow juga memiliki beberapa pertanyaan yang berhubungan dengan ini: Berapa overhead yang dikenakan SSL? dan HTTP vs kinerja HTTPS .

47
user502

Dari entri blog zscaler Mengapa web belum beralih ke SSL saja?

"Dengan masalah sidejacking session disorot sekali lagi oleh Firesheep, banyak orang bertanya kepada saya mengapa lebih banyak situs web, atau setidaknya pemain utama (Google, Facebook, Amazon, dll.) Tidak mengaktifkan SSL secara default untuk semua komunikasi. Memang , enkripsi adalah satu-satunya cara untuk memastikan bahwa sesi pengguna tidak dapat dengan mudah terendus pada jaringan nirkabel terbuka.

Ini kedengarannya mudah - cukup tambahkan s setelah http di URL! Sebenarnya tidak semudah itu. Inilah beberapa tantangannya. "

Ringkasan tantangan (kontra):

  • "overhead server"
  • "peningkatan latensi"
  • "tantangan untuk CDN"
  • "sertifikat wildcard tidak cukup"
  • "HTTP/HTTPS campuran: masalah ayam & telur"
  • "Peringatan itu menakutkan!"
25
Tate Hansen

Ars Technica memiliki artikel yang bagus menjelaskan beberapa tantangan dalam penempatan SSL.

Satu yang besar: sebagian besar jaringan iklan tidak menyediakan cara apa pun untuk menayangkan iklan melalui SSL. Selain itu, jika Anda menyematkan iklan (dikirim melalui HTTP) di halaman utama yang dikirim melalui HTTPS, browser akan mengeluarkan peringatan konten campuran yang menakutkan, yang tidak ingin Anda tundukkan kepada pengguna Anda. Jadi, situs yang didukung iklan kemungkinan akan merasa sangat sulit untuk beralih ke SSL di seluruh dunia.

Artikel ini juga menguraikan beberapa tantangan lain, seperti widget pihak ketiga, analitik, video tertanam, dll.

19
D.W.

OK, ini pertanyaan kuno, jadi jawaban saya mungkin akan merana di sini di bagian bawah. Namun, saya punya sesuatu untuk ditambahkan ke sisi 'kontra'.

HTTPS Latency:

Memiliki latensi HTTP klien-ke-server yang rendah sangat penting untuk membuat situs web yang memuat cepat dan responsif . Dan waktu pemuatan halaman cepat meningkatkan kebahagiaan pengguna akhir .

TCP/IP sendiri memiliki TCP 3-way handshake yang terkenal, yaitu pengaturan koneksi awal untuk HTTP polos di atas TCP membutuhkan 3 paket. Ketika SSL/TLS sedang digunakan, pengaturan koneksi lebih terlibat, yang berarti latensi untuk koneksi HTTPS baru tidak dapat dihindari lebih tinggi daripada HTTP plaintext.

Perhatikan bahwa dampak ini dapat dikurangi (tetapi tidak dihilangkan) dengan menggunakan kembali koneksi HTTPS berkali-kali, mis. Menggunakan koneksi persisten, dan lainnya optimasi kinerja seperti SSL False Start .

Memodelkan persis berapa banyak HTTPS yang memperlambat pemuatan halaman adalah rumit, karena semua browser modern mengunduh objek HTTP secara paralel bila memungkinkan. Meski begitu, waktu pemasangan koneksi awal yang lebih tinggi signifikan dan tidak dapat dihindari dengan teknologi saat ini; sehingga peningkatan latensi koneksi baru merupakan pertimbangan penting.

15
Jesper M

Kelemahan yang terlewatkan dalam jawaban lain di atas adalah ketergantungan besar pada jaringan distribusi konten (misalnya Akamai) - banyak halaman web dalam penggunaan saat ini mengambil konten dari berbagai domain sehingga browser harus memiliki sertifikat untuk masing-masing atau peringatan akan muncul. Dan tentu saja, jika penyerang menggunakan platform CDN yang sudah dimiliki oleh browser, mereka mungkin tidak mendapatkan peringatan ketika mereka seharusnya.

Masalah rumit dengan cara aplikasi dan konten saat ini dikirimkan.

12
Rory Alsop

Pro jelas meningkatkan keamanan. Kontra dapat berupa koneksi yang relatif lebih lambat, penggunaan CPU yang lebih intensif, diperlukan manajemen sertifikat yang akurat, beberapa biaya untuk sertifikat (jika Anda tidak menggunakan sertifikat yang ditandatangani sendiri). Namun belakangan ini ada praktik penyebaran untuk menggunakan https dan kontra itu menjadi latar belakang karena bermanfaat bagi pengguna akhir dan peningkatan kepercayaan kepada perusahaan yang menyediakan layanan.

7
anonymous

Jawaban lain menyatakan "masalah ayam/telur" karena peringatan konten campuran yang membuat migrasi HTTP-> HTTPS menjadi sulit. Ini adalah masalah, tapi saya pikir itu tidak sesulit yang mereka bayangkan.

Konten campuran dapat diatasi menggunakan RL relatif protokol dan pemindai yang sama yang harus Anda gunakan untuk menemukan masalah XSS.

RFC 3986 bagian 4.2 menggunakan istilah referensi jalur jaringan:

Referensi relatif yang dimulai dengan dua karakter garis miring disebut referensi jalur jaringan

Pertama-tama memindai halaman Anda sampai Anda menemukan semua kegunaan http://example.com/ dalam tautan, gambar, dan aset situs lainnya yang sama-asli dan menggantinya dengan URL relatif protokol (//example.com/...). Ini memungkinkan Anda mendapatkan HTML yang sama tanpa peduli apakah Anda melayani halaman melalui HTTP atau HTTPS dan menempatkan Anda pada posisi yang jauh lebih baik untuk mengembalikan jika terjadi kesalahan di kemudian hari dalam migrasi Anda.

Kemudian siapkan HTTP-> HTTPS redirect permanen sehingga URL yang ada di situs di luar kendali Anda terus bekerja dan mulai melayani melalui HTTPS. Menggunakan redirect permanen dengan header cache yang agresif akan membantu mesin pencari mentransfer peringkat halaman dan mempercepat situs untuk pengunjung yang kembali.

Anda tentu saja harus menjaga scanner Anda mencari konten campuran sehingga Anda menangkap regresi.

5
Mike Samuel

Saya tahu ini adalah pertanyaan lama/utas, tetapi saya hanya ingin menunjukkan PRO besar untuk melakukan sisi-sisi SSL.

SPDY

Menggunakan mod_spdy di Apache membutuhkan SSL.

Jika Anda belum menggunakan SPDY, selesaikan! Baik Chrome dan Firefox mendukung protokol, juga Opera).

Itu adalah sekitar setengah dari pengguna Anda yang akan dapat memanfaatkan SPDY.

4
Spock

Kelemahan lain (disentuh oleh orang lain) adalah kurangnya caching yang jelas akan mempengaruhi kecepatan. Juga, beberapa variabel server tidak tersedia - seperti HTTP_FORWARDED_FOR saya pikir.

3
Nev Stokes

Semua poin bagus yang disebutkan di sini, bagaimanapun, saya salah biaya con! Dan berdasarkan biaya saya tidak bermaksud hanya membeli sertifikat, tetapi memiliki infrastruktur yang tepat untuk mengelola sertifikat, pencabutan, modul kripto khusus untuk mengurangi beban CPU server web, dll.

3
Henri

Manfaat menjaga seluruh situs terenkripsi:

  • anda tidak akan mengecewakan pengunjung yang peduli dengan privasi dengan mengirimkan plaintext setelah login.
  • lebih sedikit risiko untuk kesalahan saat mengarahkan/menghubungkan antara http dan https bagian situs.

Con:?

Baca testimonial dari google dan lainnya. Tidak harus mahal untuk 100% https.

3
MattBianco

Jika situs web dikelola oleh CMS yang dapat digunakan oleh pengguna non-teknis untuk mengedit halaman, mereka mungkin mengedit HTML untuk memasukkan referensi ke sumber daya di luar situs, seperti gambar, melalui HTTP. Saya telah membangun situs belanja yang hanya menggunakan SSL jika diperlukan, dan mengalihkan halaman lain kembali ke HTTP, karena jika tidak, Anda akan mendapat peringatan konten campuran karena semua gambar di luar situs yang telah ditempel pemilik ke situs.

2
TRiG