Coba jelasin Algoritma dari Keamanan Lapisan Transportasi dong

Pertukaran kunci atau perjanjian kunci

Sebelum klien dan server dapat mulai bertukar informasi yang dilindungi oleh TLS, mereka harus secara aman bertukar atau menyetujui kunci enkripsi dan cipher untuk digunakan saat mengenkripsi data. Di antara metode yang digunakan untuk pertukaran kunci / perjanjian adalah: kunci publik dan pribadi yang dihasilkan dengan RSA (dilambangkan TLS_RSA dalam protokol jabat tangan TLS), Diffie-Hellman (TLS_DH), ephemeral Diffie–Hellman (TLS_DHE), kurva elips Diffie-Hellman ( TLS_ECDH), kurva-elips epiferal Diffie-Hellman (TLS_ECDHE), Diffie-Hellman anonim (TLS_DH_anon), pre-shared key (TLS_PSK) dan Secure Remote Password (TLS_SRP).

Metode perjanjian kunci TLS_DH_anon dan TLS_ECDH_anon tidak mengotentikasi server atau pengguna dan karenanya jarang digunakan karena mereka rentan terhadap serangan man-in-the-middle. Hanya TLS_DHE dan TLS_ECDHE yang memberikan kerahasiaan ke depan.

Sertifikat kunci publik yang digunakan selama pertukaran / perjanjian juga bervariasi dalam ukuran kunci enkripsi publik / swasta yang digunakan selama pertukaran dan karenanya ketahanan keamanan yang diberikan. Pada Juli 2013, Google mengumumkan bahwa mereka tidak akan lagi menggunakan kunci publik 1024-bit dan akan beralih ke kunci 2048-bit untuk meningkatkan keamanan enkripsi TLS yang diberikannya kepada penggunanya karena kekuatan enkripsi terkait langsung dengan ukuran kunci.

Dukungan untuk server virtual berbasis nama

Dari sudut pandang protokol aplikasi, TLS milik lapisan bawah, meskipun model TCP / IP terlalu kasar untuk menunjukkannya. Ini berarti bahwa jabat tangan TLS biasanya (kecuali dalam kasus STARTTLS) dilakukan sebelum protokol aplikasi dapat dimulai. Dalam fitur server virtual berbasis nama yang disediakan oleh lapisan aplikasi, semua server virtual yang dihosting bersama berbagi sertifikat yang sama karena server harus memilih dan mengirim sertifikat segera setelah pesan ClientHello. Ini adalah masalah besar di lingkungan hosting karena itu berarti berbagi sertifikat yang sama di antara semua pelanggan atau menggunakan alamat IP yang berbeda untuk masing-masing pelanggan.

Ada dua solusi yang diketahui disediakan oleh X.509:

Jika semua server virtual milik domain yang sama, sertifikat wildcard dapat digunakan. Selain pemilihan nama host longgar yang mungkin menjadi masalah atau tidak, tidak ada kesepakatan umum tentang cara mencocokkan sertifikat wildcard. Berbagai aturan diterapkan tergantung pada protokol aplikasi atau perangkat lunak yang digunakan.

Tambahkan setiap nama host virtual di ekstensi subjectAltName. Masalah utama adalah bahwa sertifikat perlu diterbitkan kembali setiap kali server virtual baru ditambahkan.

Untuk memberikan nama server, Ekstensi RFC 4366 Transport Layer Security (TLS) memungkinkan klien untuk menyertakan ekstensi Indikasi Nama Server (SNI) dalam pesan ClientHello yang diperluas. Ekstensi ini mengisyaratkan ke server dengan segera nama yang ingin disambungkan klien, sehingga server dapat memilih sertifikat yang sesuai untuk dikirim ke klien.