Mengapa SSL / TLS tidak dibangun ke dalam Sistem Operasi modern?


15

Banyak protokol jaringan dasar yang membentuk infrastruktur Internet dibangun untuk sebagian besar Sistem Operasi utama. Sebagai contoh, TCP, UDP, dan DNS semuanya dibangun ke Linux, UNIX dan Windows, dan disediakan untuk programmer melalui API sistem tingkat rendah.

Tetapi ketika datang ke SSL atau TLS, kita harus beralih ke perpustakaan pihak ketiga seperti OpenSSL atau Mozilla NSS.

SSL adalah protokol yang relatif lama, dan pada dasarnya standar industri di mana-mana seperti TCP / IP, jadi mengapa tidak dibangun ke sebagian besar Sistem Operasi?


5
Apa perbedaan praktis antara 'built-in' dan 'bundled with'? Sejauh yang saya tahu, semua OS entah bagaimana datang dengan implementasi bundel dari SSL / TLS.
zneak

Perbedaannya adalah bahwa TCP dan DNS diimplementasikan dalam kode kernel. Tetapi SSL hanya tersedia melalui perpustakaan pihak ketiga. Meskipun biasanya masalah sepele untuk menginstal dukungan SSL, dan banyak OS bahkan datang dengan itu out-of-the-box, masih ada kelemahan praktis: Misalnya, jika saya menulis perpustakaan yang menggunakan implementasi SSL tertentu, (seperti OpenSSL, NSS, GnuTLS, dll) perangkat lunak saya sekarang memiliki ketergantungan yang harus dihadapi pengguna. Ini akan menjadi masalah jika SSL dibangun ke dalam OS. Maksud saya, ini tidak seperti saya khawatir jika ada pengguna saya yang perlu menginstal dukungan untuk TCP.
Channel72

3
Saya tidak berpikir memiliki built-in SSL akan menyelesaikan masalah yang Anda sebutkan. Sekarang, alih-alih bergantung pada perpustakaan tertentu, Anda akan bergantung pada sistem operasi tertentu.
zneak

1
Mengapa tidak ada perpustakaan jpeg? Pertanyaan efektif yang sama. Anda melihat lokasi tumpukan yang salah. Semua OS modern memiliki sesuatu yang dibundel untuk memberikan dukungan SSL. (MSFT memiliki .NET SDK, linux / solaris memiliki banyak, + ada yang lain)
iivel

3
apakah Anda benar-benar menginginkannya di kernel? Sepertinya sudah sangat ramai bagi saya.
Matthieu M.

Jawaban:


8

Saya pikir itu terutama tergantung pada apa yang Anda lihat sebagai "OS". Jika itu kernel, jawaban saya adalah: mengapa harus begitu? Saya mungkin salah, tetapi apakah DNS bukan bagian dari glibc pada sistem Linux, yang merupakan perpustakaan pihak ketiga?

Jika ini bukan tentang kernel atau ruang pengguna, hampir setiap OS / platform memiliki tumpukan SSL / TLS, beberapa mungkin memiliki lebih dari satu.

Bahkan bisa dilihat sebagai keuntungan. Jika tidak ada OpenSSL, Anda harus beradaptasi dengan API Windows, Mac dan Linux (dan ...). TLS tidak menjadi bagian dari OS memungkinkan untuk menulis aplikasi TLS lintas platform. Pilih saja perpustakaan TLS, yang mendukung platform target Anda.

Bagi saya, masalah sebenarnya dengan TLS adalah, Anda tidak bisa begitu saja "menyalakannya". Sebagai gantinya, Anda harus mengelola sekumpulan sertifikat tepercaya, daftar pencabutan sertifikat, sertifikat yang ditandatangani sendiri dan sebagainya. Semua ini membutuhkan banyak interaksi pengguna.

Sayangnya, keamanan tidak pernah datang secara gratis. Ini adalah upaya untuk pemrogram dan ketidaknyamanan bagi pengguna.


Sebagian besar pipa keamanan dapat terjadi tanpa interaksi pengguna. Ketidaknyamanan terjadi hanya ketika orang menggunakan sertifikat yang tidak dapat dipercaya.
zneak

1
Ini benar. Tetapi ada begitu banyak sertifikat yang ditandatangani sendiri di luar sana. IMO, seluruh model otoritas terpusat tidak berskala. Bagaimana memutuskan akar mana yang harus dipercaya? Tidak ada pengguna yang akan memutuskan ini. Mereka semua berharap para programmer memilih dengan bijak.
paztulio

Sertifikat tidak banyak tentang kepercayaan "nyata", mereka hanya melengkapi enkripsi. Apa gunanya saluran terenkripsi jika Anda berbicara dengan server jahat? Maksud sertifikat adalah untuk membuktikan bahwa Anda berkomunikasi dengan komputer yang tepat, dan untuk itu, sembarang sertifikat root yang Anda terima melalui cara aman sudah cukup untuk memvalidasi keaslian. Selebihnya, sertifikat tidak membuktikan apa-apa tentang niat seseorang, mereka hanya membuktikan itu orang sungguhan dan bukan tipuan.
zneak

6

Ada masalah hukum. Beberapa negara menempatkan kriptografi dalam kelompok yang sama dengan senjata. Menempatkan kode kriptografi di kernel kemudian membuat mengekspor salah satu kode kernel lebih sulit.


2

Ada manfaat nyata untuk membangun TCP ke dalam sistem operasi. TCP membutuhkan pengaturan waktu yang presisi dan respons yang cepat terhadap paket jaringan bahkan ketika tidak ada data aplikasi yang terlibat. Jika Anda mencoba menerapkan TCP di ruang pengguna di atas API IP generik, itu akan jauh lebih buruk. Tidak ada keuntungan serupa untuk mengintegrasikan SSL di kernel.

Di sisi lain, ada beberapa kelemahan. Sebagai contoh, SSL membutuhkan memanipulasi cincin kunci dan daftar sertifikat dan sejenisnya. Melakukan hal itu melalui kernel atau OS API akan tidak memenuhi syarat. Jadi, bahkan jika itu datang dengan sistem operasi, itu hanya akan menjadi perpustakaan (sama seperti di Windows). Pustaka-pustaka itu sudah tersedia, jadi pada akhirnya hanya perubahan dalam kemasan.


1

Ada beberapa alasan, tetapi mungkin yang paling menarik adalah kriptografi sangat, sangat sulit untuk benar-benar diperbaiki . Adalah tidak bijaksana untuk mengimplementasikannya sendiri kecuali Anda dapat mencurahkan sumber daya utama untuk memverifikasi bahwa itu benar dan kuat. Kebanyakan orang yang bekerja dengan perangkat lunak kriptografi tidak memiliki waktu, keahlian, atau keinginan untuk meredamnya; mereka mempercayai perpustakaan pihak ketiga sehingga pengembang mereka dapat menangani bagian pekerjaan itu, sementara pengembang aplikasi dapat kembali membuat apa yang mereka inginkan.

Pengembang OS tidak begitu berbeda. Kadang-kadang ada minat utama - misalnya, model bisnis Anda atau pengacara mengharuskan Anda untuk menjaga kode tertutup - dan sehingga Anda tidak punya banyak pilihan dalam masalah ini: jika Anda tidak dapat menemukan seseorang yang akan membiarkan Anda melakukannya apa yang harus Anda lakukan, maka Anda harus roll sendiri. Yang lain telah menyebutkan bagaimana Microsoft melakukan ini. Tetapi secara umum, pengembang OS yang dapat menggunakan perpustakaan pihak ketiga lebih suka melakukannya dengan cara yang sama, karena alasan yang sama seperti pengembang aplikasi.


0

Saya seorang pengembang windows jadi saya tidak dapat berbicara untuk OS lain, tetapi pada Windows mereka memiliki SSL bawaan untuk waktu yang sangat lama. Mereka menyebutnya SChannel dan meskipun didukung, itu adalah salah satu API yang lebih samar yang harus dipecahkan .


0

SSL adalah lapisan di atas protokol tingkat yang lebih rendah. Misalnya SSL berjalan di atas TCP (yang di atas IP).

Di mana OS berhenti?

Sangat mudah untuk berdebat bahwa OS menyediakan layanan dasar seperti jaringan sampai pada titik di mana klien OS "melakukan hal-hal". Dan hal-hal itu dapat menjadi apa pun yang Anda inginkan.

Sangat tidak mungkin bahwa SSL di kernel akan mengarah pada peningkatan kinerja yang besar, jadi mengapa repot-repot?

Kernel OS modern berjalan ke jutaan baris kode, menambahkan lebih banyak hanya menambah kompleksitas dan lebih banyak waktu debugging. Membiarkan hal-hal seperti hal-hal protokol lapisan yang lebih tinggi dari OS membuat pengembangan OS lebih mudah dan pada akhirnya membuat sedikit perbedaan pada fungsi atau kinerja aplikasi akhir. (Mungkin membuat pekerjaan pengembang untuk aplikasi akhir sedikit lebih menyakitkan.)


0

Ada beberapa dukungan Kernel untuk Crypto dan SSL. Ini masuk akal karena Kernel dapat lebih efisien berinteraksi dengan perangkat keras dan juga meyakinkan untuk melindungi kredensial dari aplikasi apa pun. Contoh yang bagus adalah kssl, proxy Kernel level-reverse-SSL di Solaris atau berbagai pustaka crypto di kernel (digunakan misalnya untuk VPN). Mesin crypto akselerasi perangkat keras yang khas juga memiliki modul kernel (dan dapat diakses melalui PKCS # 11 atau antarmuka crypto spesifik OS).

Beberapa alasan mengapa Anda tidak melihatnya lebih sering adalah karena beberapa protokol aplikasi tidak berlapis dengan benar (pikirkan STARTLS) atau memerlukan keputusan aplikasi saat berjabat tangan (pikirkan sertifikat klien dan pemeriksaan CRL) atau hanya dalam evolusi biasa.

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.