Berapa overhead yang dikenakan SSL?

168

Saya tahu tidak ada satu jawaban yang sulit dan cepat, tetapi adakah ~~perkiraan~~ perkiraan ~~urutan~~ umum untuk biaya overhead enkripsi SSL dibandingkan komunikasi soket yang tidak dienkripsi? Saya hanya berbicara tentang pemrosesan comm dan waktu kawat, tidak termasuk pemrosesan tingkat aplikasi.

Memperbarui

Ada pertanyaan tentang HTTPS versus HTTP , tapi saya tertarik melihat lebih rendah di tumpukan.

(Saya menggantikan frase "urutan besarnya" kebingungan menghindari; saya menggunakan itu sebagai jargon resmi bukan dalam arti CompSci resmi Tentu saja jika saya. Telah bersungguh-sungguh secara resmi, sebagai geek benar saya akan berpikir biner daripada desimal! ;-)

Memperbarui

Per permintaan dalam komentar, anggap kita sedang berbicara tentang pesan berukuran baik (kisaran 1k-10k) melalui koneksi persisten. Jadi pengaturan koneksi dan overhead paket bukan masalah yang signifikan.

— joel.neely
sumber

Anda dapat melihat pertanyaan serupa ini .

— Darin Dimitrov

Bisakah Anda menandai lebih sedikit aplikasi Anda? Misalnya, apakah itu membuat banyak koneksi berumur pendek? Saat terhubung, seberapa besar pesan individu cenderung? (Misalnya, mungkin Anda menyiram setiap tombol tekan dengan Telnet melalui terowongan SSL, atau mungkin Anda sedang menyalin file log 1 Tb.)

— erickson

Jawaban:

178

Urutan besarnya: nol.

Dengan kata lain, Anda tidak akan melihat throughput Anda dipotong setengah, atau apa pun seperti itu, ketika Anda menambahkan TLS. Jawaban untuk pertanyaan "duplikat" sangat berfokus pada kinerja aplikasi, dan bagaimana perbandingannya dengan overhead SSL. Pertanyaan ini khusus mengecualikan pemrosesan aplikasi, dan berupaya membandingkan non-SSL dengan SSL saja. Meskipun masuk akal untuk mengambil pandangan global tentang kinerja ketika mengoptimalkan, bukan itu yang ditanyakan oleh pertanyaan ini.

Overhead utama SSL adalah jabat tangan. Di situlah kriptografi asimetris yang mahal terjadi. Setelah negosiasi, cipher simetris yang relatif efisien digunakan. Itu sebabnya sangat membantu untuk mengaktifkan sesi SSL untuk layanan HTTPS Anda, di mana banyak koneksi dilakukan. Untuk koneksi yang berumur panjang, "efek akhir" ini tidak begitu penting, dan sesi tidak begitu berguna.

Inilah anekdot yang menarik. Saat Google beralih Gmail untuk menggunakan HTTPS, tidak diperlukan sumber daya tambahan; tidak ada perangkat keras jaringan, tidak ada host baru. Itu hanya meningkatkan beban CPU sekitar 1%.

— erickson
sumber

Bagaimana Anda "mengaktifkan sesi SSL untuk layanan HTTPS Anda"? Apa sumber yang bagus untuk belajar tentang ini?

— Justin Vincent

Mengaktifkan sesi SSL khusus untuk server. Baca manual untuk server Anda.

— erickson

@ Bart van Heukelom - Tetap-hidup akan membantu menjaga soket (dan koneksi SSL) terbuka lebih lama, yang membantu. Tetapi sesi SSL menyebabkan parameter kriptografi yang dinegosiasikan menjadi "diingat" dari soket ke soket. Jadi HTTP keep-live akan berguna untuk memuat satu halaman web dengan konten yang direferensikan, tetapi setelah beberapa detik, koneksi itu akan ditutup. Tiga menit kemudian, katakanlah, ketika halaman lain diambil, sesi SSL memungkinkan koneksi SSL dibangun kembali tanpa mengulangi jabat tangan penuh. Secara khusus, pertukaran kunci lambat dengan kunci publik kripto dapat dilewati.

— erickson

@ Tony, apakah Anda punya contoh dunia nyata di mana TLS menambahkan lebih dari beberapa persen overhead? Jawaban saya adalah pertanyaan umum. Jika Anda memiliki pandangan berbeda, silakan bagikan.

— erickson

@Tony Saya telah melihat soket polos mengungguli soket SSL dengan faktor 42 dalam hal ruang saat menulis satu byte pada suatu waktu, yang merupakan kasus terburuk. Belum pernah melihat 250x. Saya melakukan percobaan ekstensif melalui internet dengan 1700 titik data di mana hasil umumnya adalah bahwa soket plaintext tidak lebih baik dari tiga kali lebih cepat dari SSL, menggunakan pemrograman tidak lebih canggih dari buffering dan flushing. JSSE, mungkin Java 5 diberi tanggal percobaan.

— Marquis of Lorne

I second @erickson: Denda kecepatan transfer data murni dapat diabaikan. CPU modern mencapai throughput crypto / AES beberapa ratus MBit / s. Jadi kecuali Anda menggunakan sistem sumber daya terbatas (ponsel) TLS / SSL cukup cepat untuk menyimpan data.

Namun perlu diingat bahwa enkripsi membuat caching dan load balancing jauh lebih sulit. Ini mungkin menghasilkan penalti performa yang sangat besar.

Tetapi pengaturan koneksi benar-benar menjadi penghenti acara bagi banyak aplikasi. Pada bandwidth rendah, kehilangan paket tinggi, koneksi latensi tinggi (perangkat seluler di pedesaan) bolak-balik tambahan yang diperlukan oleh TLS mungkin membuat sesuatu lambat menjadi sesuatu yang tidak dapat digunakan.

Misalnya, kami harus menghapus persyaratan enkripsi untuk akses ke beberapa aplikasi web internal kami - aplikasi yang tidak dapat digunakan jika digunakan dari Cina.

— maks
sumber

Dengan 4 tahun terakhir: Cina mungkin juga secara sengaja mengacaukan semua lalu lintas SSL / TLS.

— Maks

China menyensor internet dan mencoba mengendus lalu lintas semua orang bukanlah berita baru. Dengan 4 tahun melihat ke belakang, Anda akan berpikir itu adalah NSA MITMing dalam perjalanan ke situs Anda.

— Eugene Beresovsky

Kuncinya dengan koneksi yang rapuh adalah, mengatur enkripsi sekali, dan kemudian menghindari negosiasi ulang kecuali benar-benar diperlukan, dan memungkinkan kedua belah pihak untuk mengubah alamat IP mereka setiap saat tanpa berkedip mata. (OpenVPN mendukung ini.) TI membantu memungkinkan fragmentasi, karena MTU bisa sangat tidak dapat diandalkan dan benar-benar tidak jujur.

— Evi1M4chine

Dengan asumsi Anda tidak menghitung pengaturan koneksi (seperti yang Anda tunjukkan dalam pembaruan Anda), itu sangat tergantung pada sandi yang dipilih. Overhead jaringan (dalam hal bandwidth) akan diabaikan. Overhead CPU akan didominasi oleh kriptografi. Di Core i5 ponsel saya, saya dapat mengenkripsi sekitar 250 MB per detik dengan RC4 pada satu inti. ~~(RC4 adalah apa yang harus Anda pilih untuk kinerja maksimum.)~~ AES lebih lambat, memberikan "hanya" sekitar 50 MB / s. Jadi, jika Anda memilih cipher yang benar, Anda tidak akan berhasil membuat satu core saat ini sibuk dengan overhead crypto bahkan jika Anda memiliki jalur 1 Gbit yang sepenuhnya digunakan. [ Sunting : RC4 tidak boleh digunakan karena tidak lagi aman. Namun, dukungan perangkat keras AES sekarang ada di banyak CPU, yang membuat enkripsi AES sangat cepat pada platform semacam itu.]

Namun, pembentukan koneksi berbeda. Bergantung pada implementasinya (mis. Dukungan untuk TLS start palsu), itu akan menambah pulang-pergi, yang dapat menyebabkan keterlambatan yang nyata. Selain itu, crypto yang mahal terjadi pada koneksi pertama (CPU yang disebutkan di atas hanya dapat menerima 14 koneksi per core per detik jika Anda dengan bodohnya menggunakan kunci 4096-bit dan 100 jika Anda menggunakan kunci 2048-bit). Pada koneksi berikutnya, sesi sebelumnya sering digunakan kembali, menghindari crypto yang mahal.

Jadi, untuk meringkas:

Transfer pada koneksi yang dibuat:

Keterlambatan: hampir tidak ada
CPU: dapat diabaikan
Bandwidth: dapat diabaikan

Pembentukan koneksi pertama:

Penundaan: perjalanan bolak-balik tambahan
Bandwidth: beberapa kilobyte (sertifikat)
CPU pada klien: sedang
CPU di server: tinggi

Perusahaan koneksi selanjutnya:

Penundaan: perjalanan pulang-pergi tambahan (tidak yakin apakah satu atau beberapa, mungkin tergantung pada implementasi)
Bandwidth: dapat diabaikan
CPU: hampir tidak ada

— Jan Schejbal
sumber

Catatan penting: Tidak seorang pun harus menggunakan RC4 lagi. Protokol harus dianggap rusak dan transmisi RC4 harus dilihat setara dengan transmisi tidak terenkripsi setidaknya untuk keselamatan dari organisasi mata-mata. Saat ini, sesuatu seperti chacha20-poly1305 sangat direkomendasikan untuk enkripsi massal karena independensinya dari organisasi tersebut.

— Evi1M4chine