Kursus MIT "Keamanan Sistem Komputer". Kuliah 14: "SSL dan HTTPS", bagian 1

Institut Teknologi Massachusetts. Kursus Kuliah # 6.858. "Keamanan sistem komputer." Nikolai Zeldovich, James Mickens. Tahun 2014

Keamanan Sistem Komputer adalah kursus tentang pengembangan dan implementasi sistem komputer yang aman. Ceramah mencakup model ancaman, serangan yang membahayakan keamanan, dan teknik keamanan berdasarkan pada karya ilmiah terbaru. Topik meliputi keamanan sistem operasi (OS), fitur, manajemen aliran informasi, keamanan bahasa, protokol jaringan, keamanan perangkat keras, dan keamanan aplikasi web.

Kuliah 1: “Pendahuluan: model ancaman” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 2: "Kontrol serangan hacker" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 3: “Buffer Overflows: Exploits and Protection” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 4: “Pemisahan Hak Istimewa” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 5: "Dari mana sistem keamanan berasal?" Bagian 1 / Bagian 2
Kuliah 6: “Peluang” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 7: “Kotak Pasir Klien Asli” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 8: “Model Keamanan Jaringan” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 9: "Keamanan Aplikasi Web" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 10: “Eksekusi simbolik” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 11: “Bahasa Pemrograman Web / Web” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 12: Keamanan Jaringan Bagian 1 / Bagian 2 / Bagian 3
Kuliah 13: "Protokol Jaringan" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 14: "SSL dan HTTPS" Bagian 1 / Bagian 2 / Bagian 3

Sekarang kita akan melihat bagaimana protokol kriptografi digunakan untuk melindungi koneksi jaringan di Internet dan bagaimana mereka umumnya berinteraksi dengan faktor-faktor jaringan. Sebelum kita masuk ke perincian, saya ingin mengingatkan Anda bahwa akan ada ujian pada hari Rabu, tetapi tidak di audiens ini, tetapi di Walker, di lantai 3, selama waktu kuliah reguler.



Jadi, hari ini kita akan berbicara tentang bagaimana Internet menggunakan kriptografi untuk melindungi koneksi jaringan, dan mempertimbangkan dua topik yang berkaitan erat.

Yang pertama adalah bagaimana mengamankan koneksi kriptografis pada skala yang lebih besar daripada sistem Kerberos, yang kita bahas dalam kuliah terakhir, melindungi. Yang kedua adalah bagaimana mengintegrasikan perlindungan kriptografi ini, yang disediakan di tingkat jaringan, ke dalam seluruh aplikasi, dan bagaimana browser web menjamin penggunaan perlindungan yang disediakan oleh protokol kriptografi. Topik-topik ini saling berkaitan erat, sehingga ternyata perlindungan komunikasi jaringan cukup mudah diberikan, karena kriptografi selalu berfungsi. Tetapi mengintegrasikannya ke dalam browser adalah tugas yang jauh lebih sulit daripada membangun sistem di sekitar kriptografi.

Sebelum kita menyelami diskusi ini, saya ingin mengingatkan Anda tentang elemen dasar kriptografi yang akan kita gunakan.

Dalam kuliah terakhir kami tentang Kerberos, kami menggunakan kriptografi simetris, atau
enkripsi dan dekripsi. Artinya adalah Anda memiliki kunci rahasia K dan dua fungsi. Jadi, Anda dapat mengambil sebagian data, sebut saja P, ini adalah teks biasa yang dapat Anda terapkan fungsi enkripsi, dan ini adalah fungsi dari beberapa tombol K. Dan jika Anda mengenkripsi teks biasa ini, Anda akan mendapatkan teks yang dienkripsi C. Demikian pula, kami memiliki ada fungsi dekripsi D yang menggunakan kunci K yang sama, akibatnya teks C yang dienkripsi akan berubah menjadi teks biasa P. Ini adalah primitif di sekitar mana Kerberos dibangun.



Tetapi ternyata ada primitif lain yang akan berguna untuk diskusi hari ini, dan yang disebut enkripsi dan dekripsi asimetris. Idenya di sini adalah untuk memiliki kunci berbeda untuk enkripsi dan dekripsi. Mari kita lihat mengapa ini sangat berguna.

Di sini ada fungsi E, yang dapat mengenkripsi satu set pesan tertentu P dengan kunci publik pk tertentu, sebagai hasilnya, untuk mendapatkan teks terenkripsi C. Untuk mendekripsinya dengan fungsi D, Anda hanya perlu menentukan sk kunci rahasia yang sesuai dan mendapatkan teks sumber P.



Kenyamanan enkripsi asimetris adalah Anda dapat mempublikasikan kunci publik di Internet dan orang-orang dapat mengenkripsi pesan untuk Anda, tetapi Anda memerlukan kunci rahasia untuk mendekripsi pesan mereka. Hari ini kita akan melihat bagaimana ini digunakan dalam protokol. Dalam praktiknya, Anda akan sering menggunakan kriptografi kunci publik dengan cara yang sedikit berbeda. Misalnya, alih-alih mengenkripsi dan mendekripsi pesan, Anda mungkin perlu menandatangani atau memverifikasi pesan.

Ternyata pada level implementasi ini adalah operasi terkait, tetapi pada level aplikasi API mereka mungkin terlihat sedikit berbeda. Misalnya, Anda dapat menandatangani pesan M dengan sk kunci rahasia Anda dan mendapatkan beberapa tanda tangan S. Kemudian Anda dapat memverifikasi pesan ini dengan pk kunci publik yang sesuai dan sebagai hasilnya mendapatkan panji logis yang memberi tahu apakah tanda tangan S benar untuk pesan M.



Berikut adalah beberapa jaminan yang relatif intuitif yang menyediakan fitur-fitur ini. Jika, misalnya, Anda menerima tanda tangan ini dan diverifikasi dengan benar, itu berarti harus dibuat oleh seseorang dengan kunci rahasia yang benar. Apakah itu jelas?

Kemudian mari kita coba mencari cara untuk melindungi koneksi jaringan pada skala yang lebih besar daripada Kerberos. Di Kerberos, kami memiliki model yang cukup sederhana, di mana semua pengguna dan server menggunakan semacam koneksi dengan objek KDC, yang memiliki tabel pengguna, layanan, dan kunci mereka yang raksasa ini. Setiap kali pengguna ingin berbicara dengan beberapa server, ia harus meminta KDC untuk membuat tiket yang ia butuhkan berdasarkan tabel raksasa ini.



Jadi ini sepertinya model yang cukup sederhana. Jadi mengapa kita membutuhkan sesuatu yang lain? Mengapa Kerberos tidak cukup baik untuk bekerja dengan situs? Mengapa Internet tidak menggunakan Kerberos secara eksklusif untuk mengamankan semua koneksi?

Anda menjawab dengan benar - karena hanya KDC yang harus memercayai semua orang, dan ini buruk. Anda mungkin memiliki masalah jika Anda menganggap bahwa mesin tertentu benar-benar aman.

Mungkin orang-orang di MIT bersedia mempercayai seseorang di jaringan lokal yang dikelola oleh KDC, tetapi tidak semua orang di Internet.

Dan jawaban siswa kedua juga benar - sangat sulit untuk mengelola sejumlah besar kunci. Bahkan, bisa sangat sulit untuk membangun satu KDC yang dapat mengelola satu miliar kunci atau sepuluh miliar kunci untuk semua orang di dunia. Komplikasi lain menggunakan Kerberos untuk seluruh Internet adalah bahwa semua pengguna harus memiliki kunci, atau harus diketahui oleh KDC. Anda bahkan tidak dapat menggunakan Kerberos di institut kami untuk terhubung ke beberapa server jika Anda tidak memiliki akun di basis data Kerberos. Sementara untuk seluruh Internet cukup masuk akal untuk mengharapkan bahwa ketika Anda pergi ke komputer, ia tidak tahu siapa Anda, tetapi itu akan memungkinkan Anda untuk pergi ke situs web Amazon, yang dilindungi oleh kriptografi.



Hah?

Ada beberapa hal lain yang Anda harapkan dari protokol kriptografi, dan kami akan melihat bagaimana mereka muncul di SSL. Tetapi ide utamanya adalah bahwa solusi ini sama untuk Kerberos, dan untuk SSL atau TLS. Anda benar ketika Anda menyebutkan bahwa protokol Kerberos asli yang kita baca dalam materi kuliah dikembangkan sejak lama. Dan jika kita ingin menggunakannya untuk Internet modern, maka mereka perlu mengubah sesuatu. Apa pemikiran lain yang Anda miliki, mengapa kita tidak menggunakan Kerberos?

Benar, ada masalah penskalaan saat memulihkan akses, dan mungkin saat mendaftarkan pengguna baru, karena Anda harus secara pribadi pergi ke beberapa kantor akun dan mendapatkan akun di sana. Apa lagi

Mahasiswa: Server Kerberos harus selalu online.

Profesor: ya, ini masalah lain. Kami telah membuat daftar beberapa jenis masalah manajemen, tetapi pada tingkat protokol, KDC harus selalu online, karena sebenarnya berfungsi sebagai perantara untuk semua interaksi Anda dengan layanan. Ini berarti bahwa setiap kali Anda mengunjungi situs web baru, Anda perlu berbicara dengan KDC. Pertama, itu akan menjadi hambatan dalam hal kinerja. Seperti jenis skalabilitas lainnya, prinsip ini akan mengarah pada skalabilitas kinerja, sementara prinsip-prinsip yang tercantum di atas hanya mengarah pada skalabilitas manajemen.



Jadi, bagaimana kita bisa menyelesaikan masalah ini menggunakan prinsip-prinsip ini? Idenya adalah menggunakan enkripsi kunci untuk berhenti menggunakan KDC.

Pertama mari kita cari tahu apakah Anda dapat membuat koneksi yang aman jika Anda hanya tahu beberapa kunci publik dari sisi lain. Dan kemudian kita akan melihat bagaimana kita menghubungkan versi kunci publik KDC ke otentikasi para pihak dalam protokol ini. Jika Anda tidak ingin menggunakan KDC, maka Anda dapat melakukan hal berikut dengan kriptografi kunci publik: entah bagaimana mengetahui kunci publik mitra di sisi lain koneksi. Jadi, di Kerberos, jika saya ingin terhubung ke server file, saya hanya tahu kunci publik dari server file dari suatu tempat. Sebagai mahasiswa baru, saya mendapatkan cetakan yang mengatakan bahwa kunci publik server file adalah ini dan itu, dan saya dapat menggunakannya untuk terhubung.

Anda bisa mengenkripsi pesan untuk kunci publik dari server file yang ingin Anda sambungkan. Tetapi ternyata dalam praktiknya, operasi dengan kunci publik ini cukup lambat. Mereka beberapa urutan besarnya lebih lambat daripada kunci enkripsi simetris. Jadi dalam praktiknya, Anda biasanya selalu ingin meninggalkan penggunaan enkripsi publik.

Jadi, protokol tipikal mungkin terlihat seperti ini. Anda memiliki A dan B, mereka ingin berkomunikasi, dan A tahu kunci publik B. Pada saat yang sama, A menghasilkan semacam kunci sesi S, hanya memilih nomor acak untuk itu. Kemudian A akan mengirim kunci sesi S B, jadi sepertinya Kerberos. Kita akan mengenkripsi kunci sesi S untuk B.

Jika Anda ingat, di Kerberos, untuk melakukan ini, kami memerlukan KDC karena A tidak tahu kunci untuk B atau dia tidak diizinkan mengetahuinya, karena itu adalah rahasia yang hanya bisa diketahui B. Tetapi dengan kunci publik, Anda dapat melakukan ini segera, cukup mengenkripsi rahasia dengan kunci publik Bspk ini, dan mengirim pesan B. Sekarang B dapat mendekripsi pesan ini dan berkata: Saya perlu menggunakan kunci rahasia ini. Sekarang kami memiliki saluran komunikasi di mana semua pesan dienkripsi dengan kunci rahasia S.



Jadi ada beberapa fitur yang berguna dalam protokol ini. Pertama, kami menyingkirkan kebutuhan untuk memiliki KDC online dan menghasilkan kunci sesi untuk kami. Kami hanya dapat memastikan kerahasiaan informasi yang ditransmisikan jika salah satu pihak pada koneksi menghasilkannya dan kemudian mengenkripsinya untuk pihak lain tanpa menggunakan KDC.

Hal baik lainnya adalah keyakinan bahwa hanya B yang dapat membaca pesan yang dikirim dari A ke B, karena hanya B yang dapat mendekripsi pesan ini. Oleh karena itu, B harus memiliki kunci pribadi yang sesuai S.

Siswa: apakah penting siapa yang memberikan kunci ini - pengguna atau server?

Profesor: mungkin. Saya pikir itu tergantung pada properti yang Anda inginkan dari protokol ini. Oleh karena itu, bagaimana jika A membuat kesalahan atau menggunakan keacakan yang salah, server yang mengirim kembali data berpikir: "Oh, sekarang ini adalah satu-satunya data yang A akan melihat." Ini mungkin tidak sepenuhnya benar, jadi Anda harus memikirkannya. Ada beberapa masalah lain dengan protokol ini.

Siswa: Dapatkah seorang penyerang menggunakan kunci untuk mengirim pesan berulang?

Profesor: ya, masalahnya mungkin saya hanya bisa mengirim pesan-pesan ini lagi, dan kelihatannya seperti A mengirim pesan B lagi, dan seterusnya.

Oleh karena itu, biasanya solusi untuk masalah ini adalah bahwa kedua sisi koneksi terlibat dalam menghasilkan S dan ini memastikan bahwa kunci yang kami gunakan adalah "segar". Karena di sini, dalam gambar, sebenarnya B tidak menghasilkan apa-apa, sehingga pesan protokol ini terlihat sama setiap waktu.

Biasanya terjadi bahwa satu sisi memilih nomor acak seperti S, dan kemudian sisi lain, B, juga memilih nomor acak, biasanya disebut nonce. Ada dua angka dan kunci yang tidak benar-benar dipilih hanya oleh satu sisi, ini adalah hash yang dipilih kedua belah pihak untuk interaksi bersama. Selain hash, Anda dapat menggunakan protokol Diffie-Hellman, yang kami periksa di kuliah terakhir, berkat itu Anda mendapatkan privasi terlebih dahulu. Ini lebih rumit dari sekadar menghitung dua angka acak yang telah memilih kedua sisi ini. Tapi kemudian Anda akan mendapatkan properti yang bagus seperti kunci rahasia bersama asli, menghilangkan kebutuhan untuk mentransfer kunci dekripsi saat mengirim data terenkripsi.

Dengan demikian, serangan berulang dapat dihindari sebagai berikut. B menghasilkan nonce dan kemudian menetapkan kunci rahasia nyata S ', yang digunakan untuk hash kunci rahasia S dengan nonce ini. Dan, tentu saja, B harus mengirim kembali ke A untuk mencari tahu apa yang terjadi ketika mereka berdua menyetujui kunci tersebut.



Masalah lain adalah bahwa tidak ada otentikasi nyata A. A tahu siapa B, atau setidaknya tahu siapa yang bisa mendekripsi data. Tapi B tidak tahu siapa yang ada di sisi lain, baik itu semacam lawan yang menyamar sebagai orang lain, atau orang lain. Bagaimana ini bisa diperbaiki di dunia kunci publik?

Ada beberapa cara untuk melakukan ini. Satu kemungkinan adalah menandatangani pesan ini pada awalnya, karena kami memiliki prinsip Tanda yang baik ini. Jadi kami mungkin bisa menandatangani ini dengan kunci rahasia. Tanda ini hanya menyediakan tanda tangan, tetapi mungkin Anda menugaskannya, dan Anda juga memberikan pesan ini.

Maka B harus tahu bahwa A adalah kunci publik untuk memverifikasi tanda tangan. Tetapi jika B tahu bahwa A adalah kunci publik, maka B akan cukup yakin bahwa A adalah orang yang mengirim pesan ini.



Hal lain yang bisa Anda lakukan adalah percaya pada enkripsi. Jadi, mungkin B dapat mengirim kembali ke A, mengenkripsinya dengan kunci publik yang disediakan oleh A. Dan kemudian hanya A yang dapat mendekripsi, bukan, dan menghasilkan kunci sesi akhir S '. Jadi ada beberapa trik yang bisa Anda lakukan. Ini adalah cara kerja sertifikat klien di browser Internet saat ini.

Dengan demikian, A memiliki kunci rahasia, dan karena itu, ketika Anda menerima sertifikat MIT pribadi, peramban Anda membuat kunci rahasia yang berumur panjang dan menerima sertifikat untuk itu. Dan setiap kali Anda mengirim permintaan ke server web, Anda membuktikan fakta bahwa Anda mengetahui kunci rahasia sertifikat pengguna Anda, dan kemudian mengatur kunci rahasia S untuk sisa koneksi.

Ini adalah masalah yang cukup mudah diperbaiki di tingkat protokol. Namun, dasar dari semua hal di atas adalah bahwa semua pihak saling mengetahui kunci publik satu sama lain. Bagaimana Anda bisa mengetahui kunci publik seseorang? Misalkan saya ingin terhubung ke situs web, saya memiliki URL yang ingin saya hubungkan, atau nama host, bagaimana saya bisa mengetahui kunci publik yang cocok dengan itu?

Demikian pula, jika saya terhubung ke server MIT untuk melihat nilai saya, bagaimana server tahu apa kunci publik saya harus membedakannya dari kunci publik siswa MIT lain?

Ini adalah masalah utama yang ditangani oleh KDC. Faktanya, KDC memecahkan dua masalah bagi kami. Pertama, ia membuat pesan (Ebspk (S)), membuat kunci sesi dan mengenkripsinya untuk server. Kami sekarang telah memperbaikinya dengan membuat kriptografi kunci publik. Tetapi kami juga harus mencocokkan nama string utama dengan kunci kriptografi Kerberos yang diberikan kepada kami sebelumnya.

Ada protokol TLC untuk hal-hal seperti itu di dunia HTTPS. Artinya adalah bahwa kita akan terus bergantung pada aspek-aspek tertentu dari proses yang mendukung tabel raksasa ini yang memetakan nama-nama peserta proses ke kunci kriptografi. Rencananya adalah kita akan memiliki sesuatu yang disebut otoritas sertifikasi, yang ditunjukkan oleh huruf CA dalam semua jenis literatur tentang keamanan jaringan. CA ini juga secara logis mendukung tabel, di satu bagian di mana nama semua peserta ditampilkan, dan di bagian lain - kunci publik yang sesuai. Perbedaan utama antara pusat ini dan Kerberos adalah CA ini tidak harus online untuk semua transaksi.
Di Kerberos, untuk terhubung dengan seseorang atau menemukan kunci orang lain, Anda perlu berbicara dengan KDC. Sebaliknya, di dunia CA, mereka melakukan ini.



Jika Anda memiliki semacam nama nama di sini dan tombol kunci yang sesuai di bagian lain tabel, maka otoritas sertifikasi akan cukup menandatangani pesan bahwa ada baris tertentu dalam tabel ini. Dengan demikian, otoritas sertifikasi harus memiliki kunci privat dan publiknya sendiri di sini. Dia akan menggunakan kunci rahasia untuk menemukan pesan untuk pengguna lain di sistem yang bisa Anda andalkan.

Jadi jika Anda memiliki catatan "nama + kunci" di database CA, maka CA akan membuat pesan bahwa nama ini cocok dengan kunci publik ini dan menandatangani pesan ini dengan kunci privat CA-nya.



Ini memungkinkan Anda untuk melakukan hal-hal yang sangat mirip dengan apa yang dilakukan Kerberos, tetapi pada saat yang sama kami menyingkirkan kebutuhan untuk menemukan CA online untuk semua transaksi. Dan, itu sebenarnya akan jauh lebih scalable. Inilah yang biasa disebut sertifikat. Skalabilitas dijamin oleh fakta bahwa untuk klien atau siapa pun yang menggunakan sistem ini, sertifikat yang diberikan dari satu sumber tidak kalah dengan sertifikat dari sumber lain. Itu ditandatangani oleh kunci rahasia otoritas sertifikasi. Jadi Anda dapat memverifikasi keasliannya tanpa benar-benar harus menghubungi otoritas sertifikasi atau pihak lain yang tercantum di sini.

Itu berfungsi seperti itu. Server yang ingin Anda bicarakan menyimpan sertifikat yang semula diterima dari otoritas sertifikasi. Dan setiap kali Anda terhubung ke sana, server memberi tahu Anda: “Oke, ini sertifikat saya. Itu ditandatangani oleh CA ini. Anda dapat memverifikasi tanda tangan dan pastikan itu adalah kunci publik saya dan itu adalah nama saya. "

Di sisi lain, hal yang sama terjadi dengan sertifikat klien. Ketika pengguna terhubung ke server web, sertifikat kliennya menunjukkan bahwa kunci publik Anda cocok dengan kunci rahasia yang awalnya dibuat di browser. Dengan demikian, saat terhubung ke server, Anda akan memberikan sertifikat yang ditandatangani oleh otoritas sertifikasi MIT, yang menunjukkan bahwa nama pengguna Anda sesuai dengan kunci publik ini. , , , , Athena.

: , ?

: , , – , ? - , , , , . - , . . , VeriSign. US Postal Service CA, , . , CA , KDC.

, , Kerberos. , , KDC. , KDC, , . , , . CA , KDS.

: ?

: , . , , KDC, . , . , , . , , , . Kerberos, . Kerberos , . , , . , , . , .

, . , , CA - , . , amazon.com, amazon.com. CA, . , , , .



. , CA , , , , - , . , , . - , amazon.com, , - .

, -, , , , . , . «» , , .

, . -, CRL, ertificate Revocation List. . , - , . , , , : «, , , - . , ».

, , , CRL, , web-, CRL. , - , , . , , , , , .

, . , . , . , . , CRL, - .

, ? , . , CRL .

, , , Kerberos, KDC. CA , . , « SSL », OCSP. CA KDC. , , , , , , - . , OCSP, : «, . , »? , CRL . , , . , , .

26:30 mnt.

Kursus MIT "Keamanan Sistem Komputer". Kuliah 14: "SSL dan HTTPS", bagian 2


Versi lengkap dari kursus ini tersedia di sini .

Terima kasih telah tinggal bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikannya kepada teman-teman Anda, diskon 30% untuk pengguna Habr pada analog unik dari server entry-level yang kami buat untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps dari $ 20 atau bagaimana membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps hingga Desember secara gratis ketika membayar untuk jangka waktu enam bulan, Anda dapat memesan di sini .

Dell R730xd 2 kali lebih murah? Hanya kami yang memiliki 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV dari $ 249 di Belanda dan Amerika Serikat! Baca tentang Cara Membangun Infrastruktur Bldg. kelas menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?