Pengantar
Hosting Virtual adalah praktik melayani beberapa situs web di Internet server yang sama. Meskipun ini adalah norma saat ini, ini tidak mungkin pada hari-hari awal HTTP (versi sebelum 1.1).
Awalnya, server hanya dapat meng-host beberapa situs web pada mesin yang sama (yaitu di bawah alamat IP yang sama) asalkan masing-masing situs web diberikan port khusus. Ini bukan solusi yang ideal karena browser default untuk port 80 untuk HTTP, kecuali jika pengguna menentukan yang berbeda. Akibatnya, sebagian besar pemilik situs web memilih server khusus untuk menghindari risiko pengguna tidak mengingat nomor port yang benar dan berakhir di situs web yang berbeda.
Namun demikian, karena semakin banyak pengguna yang bergabung dengan Web dan lebih banyak perangkat jaringan mulai muncul secara online, jumlah alamat IP yang tersedia mulai berkurang pada tingkat yang mengkhawatirkan. Penipisan yang diantisipasi ini, dikenal sebagai Kelelahan rentang alamat IPv4, telah mendorong industri untuk merancang dan mengimplementasikan berbagai tindakan balasan, seperti IPv6 (Penerus IPv4), yang dapat mendukung lebih banyak alamat daripada yang pernah kita butuhkan. Sayangnya, meskipun IPv6 adalah solusi yang layak, adopsinya cukup lambat. Berdasarkan Statistik IPv6 Google, pada saat penulisan ini, hanya sekitar 25% perangkat Internet yang digunakan melalui IPv6.
Virtual hosting juga diimplementasikan sebagai mitigasi awal untuk masalah kelelahan, dengan diperkenalkannya Host header di HTTP 1.1. Browser yang berkomunikasi melalui HTTP 1.1 sekarang dapat terhubung ke port server 80 dan sertakan nama domain (mis www.ssl.com) dari situs web yang ingin mereka kunjungi di Host tajuk. Terlepas dari berapa banyak situs yang dihosting oleh server pada port yang sama, ia dapat menggunakan informasi ini untuk mengidentifikasi situs web yang benar dan mengembalikan kontennya.
HTTPS dan Hosting Virtual
Banyak laporan yang dipublikasikan tentang kerentanan jaringan dan serangan terhadap pengguna web, telah memotivasi industri untuk mulai menjauh dari HTTP tidak aman, ke HTTPS alternatif yang lebih aman. Adopsi yang luas dari HTTPS telah meningkatkan keamanan pengguna secara keseluruhan. Namun, peningkatan tambahannya juga meningkatkan kompleksitas umum komunikasi web.
Pada prinsipnya, HTTPS sangat mirip dengan HTTP, dengan pengecualian bahwa komunikasi HTTPS antara browser dan server dienkripsi. Singkatnya, HTTPS membutuhkan server untuk menyediakan browser dengan sertifikat SSL valid yang dikeluarkan oleh tepercaya publik otoritas sertifikat (CA), seperti SSL.com. Browser kemudian dapat menggunakan kunci publik yang terkandung dalam sertifikat untuk membuat saluran komunikasi terenkripsi dengan server. Selain itu, sertifikat dikeluarkan untuk nama domain tertentu, yang browser periksa untuk kecocokan dengan domain yang ingin dikunjungi pengguna. Jadi, tidak peduli berapa banyak situs web yang dihosting server, browser berharap menemukan sertifikat SSL yang valid untuk situs web yang mereka minta.
Pembaca yang penuh perhatian mungkin sudah merasakan masalahnya: browser memerlukan sertifikat situs web yang benar untuk membuat saluran terenkripsi dan mengirim Host header, sedangkan server membutuhkan Host header untuk menemukan sertifikat situs yang benar. Ini adalah masalah ayam-dan-telur klasik.
Jelas bahwa hosting virtual seperti yang dikandung untuk HTTP tidak berfungsi untuk HTTPS, karena kontrol keamanan mencegah browser mengirim Host informasi ke server. Meskipun demikian, dengan masalah kelelahan IPv4 yang masih belum terselesaikan, dan adopsi teknologi cloud yang terus meningkat di industri (yang membutuhkan penyeimbangan beban dan beberapa server backend fail-over), hosting virtual masih merupakan kebutuhan.
Bagaimana dengan Sertifikat Multi-Domain?
Solusi yang diusulkan untuk masalah ini adalah penggunaan multi-domain atau Sertifikat SAN. Satu sertifikat SAN dapat mengamankan ratusan nama domain yang berbeda, dan browser tidak akan mengeluh jika mereka menemukan nama domain yang mereka coba kunjungi di dalam daftar domain sertifikat SAN. Setelah saluran terenkripsi dikonfigurasi, browser dapat mengirim file Host header ke server dan lanjutkan seperti dalam kasus lainnya. Ini adalah ide bagus yang menggunakan teknologi yang sudah ada dan tersedia, tetapi mekanisme yang sama yang memastikan keamanan sertifikat SAN juga telah memperkenalkan beberapa efek samping yang mungkin tidak diinginkan:
Sertifikat SAN adalah alat bagus untuk mengamankan beberapa domain yang dimiliki oleh entitas yang sama (orang, perusahaan atau organisasi), tetapi mereka agak tidak praktis untuk digunakan dalam hosting bersama; setiap kali domain baru siap ditambahkan atau dihapus dari sertifikat, sertifikat baru dengan daftar domain terbaru harus dikeluarkan oleh CA, dan digunakan kembali di semua domain.
Selain itu, sertifikat SAN hanya dapat diterbitkan sebagai Organisasi Divalidasi (OV) atau Diperpanjang Divalidasi (EV) if semua domain milik organisasi yang sama. Level validasi ini merujuk pada jumlah dan jenis informasi calon pemilik sertifikat yang diverifikasi oleh CA sebelum menerbitkan sertifikat. Telah ditunjukkan bahwa semakin tinggi tingkat validasinya, semakin banyak kepercayaan yang diberikan pengguna di situs web, dan kepercayaan pengguna dapat memengaruhi pengakuan merek dan tingkat konversi.
Akhirnya, sangat umum di lingkungan web hosting bersama untuk perusahaan untuk berbagi server dengan bisnis atau organisasi lain (bahkan dengan pesaingnya). Karena domain dalam sertifikat SAN terdaftar secara publik, pemilik bisnis mungkin enggan berbagi sertifikat yang sama dengan perusahaan pihak ketiga.
Meskipun sertifikat SAN adalah alat yang kuat dan serba guna dengan aplikasi yang tak terhitung jumlahnya, masalah ini telah memotivasi IETF - badan pengelola standar Internet - untuk mencari pendekatan yang lebih sesuai untuk masalah spesifik situs web HTTPS yang dihosting secara virtual.
Indikasi Nama Server untuk Penyelamatan
Solusinya diimplementasikan dalam bentuk Indikasi Nama Server (SNIekstensi dari TLS protokol (bagian dari HTTPS yang berkaitan dengan enkripsi).
SNI memungkinkan peramban untuk menentukan nama domain yang ingin mereka sambungkan selama TLS jabatan (negosiasi sertifikat awal dengan server). Sebagai akibatnya, situs web dapat menggunakan sertifikat SSL mereka sendiri sementara masih di-host pada alamat dan port IP bersama, karena server HTTPS dapat menggunakan informasi SNI untuk mengidentifikasi rantai sertifikat yang sesuai yang diperlukan untuk membangun koneksi.
Setelah itu, ketika saluran komunikasi terenkripsi telah dikonfigurasi, browser dapat melanjutkan untuk memasukkan nama domain dari situs web dalam Host header dan lanjutkan seperti biasa. Pada dasarnya, SNI menjalankan fungsi yang sama dengan HTTP Host header selama pembuatan koneksi terenkripsi.
Trik sederhana ini akhirnya memungkinkan server untuk menghosting beberapa situs web HTTPS di port yang sama. Namun, seperti kebanyakan teknologi Internet, SNI memiliki beberapa batasan.
Masalah Dukungan SNI
Meskipun SNI sudah cukup matang sejak pertama kali dibuat pada tahun 1999, masih ada beberapa browser lawas (IE pada Windows XP) dan sistem operasi (versi Android <= 2.3) yang tidak mendukungnya. Untuk daftar lengkap browser dan sistem operasi yang mendukung SNI, silakan lihat meja ini.
Meskipun pangsa pasar browser yang tidak mendukung SNI (dan dengan perluasan kejadian ini terjadi) sangat kecil jika dibandingkan dengan browser modern, jika browser tidak mengenali SNI, ia akan kembali ke sertifikat SSL default, dan berpotensi menghasilkan kesalahan nama umum ketidakcocokan.
Banyak perusahaan, seperti Google, menerapkan SNI untuk klien yang mendukungnya, dan kembali ke sertifikat SAN untuk kasus yang jarang terjadi. Secara alami, masalah ini diperkirakan akan berkurang karena semakin banyak pengguna dan pemilik bisnis meningkatkan sistem mereka ke teknologi modern.
Masalah Privasi SNI
Versi stabil saat ini TLS (versi 1.2) mengirimkan bagian awal jabat tangan, dan dengan ekstensi informasi SNI, tidak dienkripsi. Akibatnya, penyerang jaringan dapat menemukan riwayat web pengguna, meskipun komunikasi web itu sendiri dienkripsi sepenuhnya.
Berbagai penyedia layanan cloud, seperti Amazon atau Google, telah mengizinkan solusi (kotor) yang dikenal sebagai tampilan domain. Penerapan domain dapat mencegah pengungkapan riwayat web karena mengaburkan informasi SNI dengan menggunakan nama host penyedia cloud di TLS negosiasi dan situs target di header HTTP. Namun, metode ini tidak dapat digunakan lagi, karena Google dan Amazon telah secara terbuka menyatakannya dukungan yang dinonaktifkan untuk tampilan domain dalam layanan mereka pada April 2018.
Untungnya, solusi yang lebih sistemik telah diusulkan sebagai konsep eksperimental merinci SNI terenkripsi (ESNI) ekstensi untuk yang terbaru TLS versi, 1.3. ESNI mengenkripsi informasi SNI, sehingga mengurangi semua masalah privasi. Sayangnya, TLS 1.3 belum diadopsi secara luas oleh industri, meskipun TLS 1.3 perlahan-lahan menjadi protokol keamanan jaringan de facto. Perhatikan artikel mendatang dari kami tentang status ESNI dan privasi HTTPS dan TLS.
Kesimpulan
Singkatnya, dengan SNI Anda dapat meng-host jutaan situs web HTTPS di satu server. Namun, tergantung pada masing-masing kasus Anda, sertifikat SAN mungkin berfungsi lebih baik untuk Anda. Kekhawatiran privasi tentang SNI masih ada, meskipun ada juga solusi potensial dengan ESNI. Bagaimanapun, dengan menggunakan satu atau kombinasi dari kedua metode ini, Anda dapat dengan mudah mengimplementasikan hosting virtual untuk semua situs web Anda dengan upaya minimal.
Jika Anda memiliki pertanyaan lebih lanjut tentang SNI atau tidak tahu bagaimana memilih antara SAN dan SNI, kami selalu dengan senang hati menjawab semua pertanyaan pelanggan kami tentang mereka. PKI kebutuhan. Kirimkan email kepada kami di support@ssl.com dan seorang ahli akan membantu Anda.
