Jabat tangan SSH dengan kata-kata sederhana.

Secure Shell (SSH) adalah protokol lapisan transport yang banyak digunakan untuk mengamankan koneksi antara klien dan server. Ini adalah protokol dasar dalam program Teleport kami untuk akses yang aman ke infrastruktur. Di bawah ini adalah deskripsi yang relatif singkat tentang jabat tangan yang terjadi sebelum membuat saluran aman antara klien dan server dan sebelum memulai enkripsi penuh lalu lintas.

Berbagi versi

Jabat tangan dimulai dengan fakta bahwa kedua belah pihak saling mengirim string dengan nomor versi. Tidak ada hal yang sangat menarik terjadi di bagian jabat tangan ini, tetapi harus dicatat bahwa sebagian besar klien dan server yang relatif modern hanya mendukung SSH 2.0 karena kekurangan desain pada versi 1.0.

Pertukaran kunci

Dalam proses pertukaran kunci (kadang-kadang disebut KEX), para pihak bertukar informasi yang tersedia untuk umum dan mendapatkan rahasia yang dibagikan oleh klien dan server. Rahasia ini tidak dapat ditemukan atau diperoleh dari informasi yang tersedia untuk umum.

Inisialisasi Pertukaran Kunci

Pertukaran kunci dimulai dengan fakta bahwa kedua pihak saling mengirim pesan SSH_MSG_KEX_INIT dengan daftar primitif kriptografi yang didukung dan urutan pilihan mereka.

Primitif kriptografi harus menetapkan blok bangunan yang akan digunakan untuk pertukaran kunci, dan kemudian enkripsi data lengkap. Tabel di bawah ini mencantumkan primitif kriptografi yang didukung Teleport.

Teleport primitif kriptografi default

Inisialisasi Protokol Diffie-Hellman pada Kurva Elliptic

Karena kedua belah pihak menggunakan algoritma yang sama untuk memilih primitif kriptografi dari daftar yang didukung, setelah inisialisasi, Anda dapat segera mulai bertukar kunci. Teleport hanya mendukung protokol Elliptic Curie Diffie-Hellman (ECDH), jadi pertukaran kunci dimulai dengan klien membuat pasangan kunci sementara (kunci publik pribadi dan terkait) dan mengirimkan server kunci publiknya dalam pesan SSH_MSG_KEX_ECDH_INIT .

Patut ditekankan bahwa pasangan kunci ini bersifat sementara: hanya digunakan untuk pertukaran kunci, dan kemudian akan dihapus. Ini membuatnya sangat sulit untuk melakukan kelas serangan di mana penyerang secara pasif mencatat lalu lintas terenkripsi dengan harapan mencuri kunci pribadi di masa depan (seperti yang disediakan oleh hukum Yarovaya - kira-kira Trans.). Sangat sulit untuk mencuri sesuatu yang sudah tidak ada. Properti ini disebut kerahasiaan maju.

Fig. 1. Menghasilkan pesan inisialisasi pertukaran kunci

Tanggapan Diffie-Hellman pada kurva elips

Server menunggu pesan SSH_MSG_KEX_ECDH_INIT , dan setelah diterima, server ini menghasilkan pasangan kunci sementara yang singkat. Menggunakan kunci publik klien dan pasangan kunci sendiri, server dapat menghasilkan K. rahasia bersama

Kemudian server menghasilkan sesuatu yang disebut pertukaran hash H dan menandatanganinya, menghasilkan hash HS yang ditandatangani (lebih lanjut pada Gambar. 3). Hash pertukaran dan tanda tangannya melayani beberapa tujuan:

• Karena pertukaran hash termasuk rahasia bersama, itu membuktikan bahwa pihak lain mampu membuat rahasia bersama.
  
• Siklus hash / verifikasi hash dan tanda tangan pertukaran memungkinkan klien untuk memverifikasi bahwa server memiliki kunci pribadi host, dan oleh karena itu klien terhubung ke server yang benar (jika klien dapat mempercayai kunci publik yang sesuai, lebih lanjut tentang ini nanti).
  
• Dengan menandatangani hash alih-alih menandatangani data input, ukuran data yang ditandatangani berkurang secara signifikan dan mengarah ke jabat tangan yang lebih cepat.

Hash pertukaran dihasilkan dengan mengambil hash (SHA256, SHA384 atau SHA512, tergantung pada algoritma pertukaran kunci) dari bidang berikut:

• Magic M Versi klien, versi server, pesan klien SSH_MSG_KEXINIT , pesan server SSH_MSG_KEXINIT .
  
• Kunci publik (atau sertifikat) dari HPub server HPub . Nilai ini (dan kunci privat HPriv yang sesuai) biasanya dihasilkan selama inisialisasi proses, dan bukan untuk setiap jabat tangan.
  
• Kunci Publik Klien
  
• Kunci Publik Server B
  
• Rahasia Bersama K

Dengan informasi ini, server dapat membuat pesan SSH_MSG_KEX_ECDH_REPLY menggunakan kunci publik singkat dari server B , kunci publik dari host server HPub , dan tanda tangan pada hash pertukaran HS . Lihat gbr. 4 untuk lebih jelasnya.


Fig. 2. Generasi pertukaran hash H

Segera setelah klien menerima SSH_MSG_KEX_ECDH_REPLY dari server, ia memiliki semua yang diperlukan untuk menghitung K rahasia dan pertukaran hash H

Di bagian terakhir dari pertukaran kunci, klien mengambil kunci publik host (atau sertifikat) dari SSH_MSG_KEX_ECDH_REPLY dan memverifikasi tanda tangan hash pertukaran HS mengkonfirmasikan kepemilikan kunci pribadi dari host. Untuk mencegah serangan tipe “man in the middle” (MitM), setelah memeriksa tanda tangan, kunci publik (atau sertifikat) host diperiksa terhadap database lokal host yang dikenal; jika kunci ini (atau sertifikat) tidak dipercaya, koneksi terputus.

  Keaslian host 10.10.10.10 (10.10.10.10) 'tidak dapat ditetapkan.
 Sidik jari kunci ECDSA adalah SHA256: pnPn3SxExHtVGNdzbV0cRzUrtNhqZv + Pwdq / qGQPZO3.
 Anda yakin ingin terus terhubung (ya / tidak)? 

Klien SSH menawarkan untuk menambahkan kunci host ke database lokal dari host yang dikenal. Untuk OpenSSH, ini biasanya ~/.ssh/known_hosts

Pesan seperti itu berarti bahwa kunci yang disajikan tidak ada dalam basis data lokal Anda dari host yang dikenal. Cara yang baik untuk menghindari pesan tersebut adalah dengan menggunakan sertifikat SSH (yang Teleport tidak secara default), bukan kunci, yang memungkinkan Anda untuk hanya menyimpan sertifikat otoritas sertifikasi di database lokal dari host yang dikenal, dan kemudian memeriksa semua host yang ditandatangani oleh CA ini.


Fig. 3. Menghasilkan Respon Pertukaran Kunci ECDH

Kunci baru

Sebelum memulai enkripsi data massal, peringatan terakhir tetap ada. Kedua belah pihak harus membuat enam kunci: dua untuk enkripsi, dua vektor inisialisasi (IV) dan dua untuk integritas. Anda mungkin bertanya, mengapa ada begitu banyak kunci tambahan? Bukankah K cukup rahasia? Tidak cukup.

Pertama, mengapa kita perlu kunci terpisah untuk enkripsi, integritas, dan IV. Salah satu alasan terkait dengan perkembangan historis protokol seperti TLS dan SSH, yaitu, negosiasi primitif kriptografi. Dalam beberapa primitif kriptografi yang dipilih, penggunaan kembali kunci tidak menjadi masalah. Tetapi, sebagaimana dijelaskan oleh Henryk Hellstrom dengan benar, jika primitif dipilih secara tidak benar (misalnya, AES-256-CBC untuk enkripsi dan AES-256-CBC-MAC untuk otentikasi), konsekuensinya dapat menjadi bencana. Perlu dicatat bahwa pengembang protokol secara bertahap meninggalkan fleksibilitas tersebut untuk membuat protokol lebih sederhana dan lebih aman.

Selanjutnya, mengapa kunci dari masing-masing jenis digunakan.

Kunci enkripsi memastikan kerahasiaan data dan digunakan dengan sandi simetris untuk mengenkripsi dan mendekripsi pesan.

Kunci integritas biasanya digunakan dengan Message Authentication Code (MAC) untuk memastikan keaslian ciphertext. Dengan tidak adanya pemeriksaan integritas, penyerang dapat memodifikasi ciphertext yang dikirim melalui saluran terbuka dan Anda akan mendekripsi pesan palsu. Skema ini biasa disebut Encrypt-then-MAC .

Harus dicatat bahwa cipher AEAD modern (enkripsi terotentikasi dengan data terlampir, ketika bagian dari pesan dienkripsi, sebagian tetap terbuka dan seluruh pesan diautentikasi) seperti aes128-gcm@openssh.com dan chacha20-poly1305@openssh.com tidak benar-benar menggunakan kunci turunan integritas untuk MAC, dan melakukan otentikasi dalam strukturnya.

Inisialisasi vektor (IV) biasanya angka acak yang digunakan sebagai input untuk simetris cipher. Tujuan mereka adalah untuk memastikan bahwa pesan yang sama, dienkripsi dua kali, tidak mengarah pada ciphertext yang sama. Kebutuhan akan prosedur semacam itu ditunjukkan dengan sempurna oleh gambar penguin Tux yang terkenal , yang dienkripsi dalam mode buku kode elektronik (ECB).


Dari kiri ke kanan. (1) Hapus teks sebagai gambar. (2) Kriptogram yang diperoleh dengan enkripsi dalam mode ECB. (3) Kriptogram yang diperoleh dengan enkripsi dalam mode selain ECB. Gambar adalah urutan piksel pseudo-acak

Menggunakan (dan meretas) vektor IV adalah topik yang menarik, yang ditulis oleh Filippo Walsord .

Akhirnya, mengapa kunci berpasangan? Seperti yang dicatat oleh Thomas Pornin , jika hanya satu kunci integritas yang digunakan, penyerang dapat mereproduksi catatan yang dikirimkan kepadanya kepada klien, dan ia akan menganggapnya sah. Dengan kunci integritas berpasangan (di server dan klien), klien akan memeriksa integritas ciphertext dan trik ini tidak akan berfungsi.

Sekarang dengan pemahaman mengapa kunci-kunci ini diperlukan, mari kita lihat bagaimana mereka dihasilkan sesuai dengan RFC :

• Mulai vektor IV dari klien ke server: HASH(K || H || «A» || session_id)
  
• Mulai vektor IV dari server ke klien: HASH(K || H || «B» || session_id)
  
• Kunci enkripsi dari klien ke server: HASH(K || H || «C» || session_id)
  
• Kunci enkripsi dari server ke klien: HASH(K || H || «D» || session_id)
  
• Kunci kendali integritas dari klien ke server: HASH(K || H || «E» || session_id)
  
• Kunci kontrol integritas dari server ke klien: HASH(K || H || «F» || session_id)

Di sini algoritma hash SHA digunakan {256, 384 atau 512} tergantung pada algoritma pertukaran kunci, dan simbol || menyiratkan penggabungan, yaitu traksi.

Segera setelah nilai-nilai ini dihitung, kedua belah pihak mengirim SSH_MSG_NEWKEYS untuk memberi tahu pihak lain bahwa pertukaran kunci telah selesai dan semua komunikasi di masa depan harus dilakukan menggunakan kunci baru yang dibuat di atas.


Fig. 4:. Vektor awal generasi IV. Generasi untuk kunci lain terjadi sesuai dengan skema yang sama, jika kita mengganti A dan B dengan C, D, E dan F, masing-masing

Kesimpulan

Pada tahap ini, kedua belah pihak sepakat tentang primitif kriptografi, bertukar rahasia dan menghasilkan materi kunci untuk primitif yang dipilih. Sekarang saluran aman dapat dibuat antara klien dan server, yang akan memastikan kerahasiaan dan integritas.

Inilah bagaimana jabat tangan SSH membuat koneksi aman antara klien dan server.