Keamanan Lapisan Transportasi: Perbedaan antara revisi
Konten dihapus Konten ditambahkan
Masih banyak dan saya sudah capek |
|||
Baris 132:
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.<ref>{{Cite web|url=https://www.computing.co.uk/news/2285984/google-updates-ssl-certificates-to-2048bit-encryption|title=Google updates SSL certificates to 2048-bit encryption|date=2013-07-31|website=www.computing.co.uk|language=en|access-date=2020-05-30}}</ref>
== 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 [[TLS oportunistik|STARTTLS]]) dilakukan sebelum protokol aplikasi dapat dimulai. Dalam fitur [[Hosting virtual|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.<ref>{{Cite web|url=https://ssl.comodo.com/wildcard-ssl-certificates|title=Wildcard SSL Certificates {{!}} What is a Wildcard Certificate?|website=ComodoCA Official Site|language=en|access-date=2020-05-31}}</ref> 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.
== Standar ==
| |||