Pertanyaan Beberapa domain SSL pada alamat IP yang sama dan port yang sama?


Ini adalah sebuah Pertanyaan Kanonis tentang Hosting beberapa situs SSL di IP yang sama.

Saya mendapat kesan bahwa setiap Sertifikat SSL memerlukan kombinasi IP Address / Port yang unik. Tetapi Jawaban atas pertanyaan sebelumnya yang saya posting bertentangan dengan klaim ini.

Menggunakan informasi dari Pertanyaan itu, saya bisa mendapatkan beberapa sertifikat SSL untuk bekerja pada alamat IP yang sama dan pada port 443. Saya sangat bingung mengapa ini bekerja dengan asumsi di atas dan diperkuat oleh yang lain bahwa setiap situs web domain SSL pada server yang sama membutuhkan IP / Port sendiri.

Saya curiga bahwa saya melakukan kesalahan. Dapatkah beberapa Sertifikat SSL digunakan dengan cara ini?


107
2018-02-04 22:36




Tubuh Q ini mengatakan beberapa sertifikat dan jawabannya benar untuk itu. Namun judulnya mengatakan beberapa domain dan Anda dapat memiliki banyak domain dengan satu sertifikat (dan tidak ada SNI), lihat serverfault.com/questions/126072/… dan serverfault.com/questions/279722/… juga menyeberang di security.SX. - dave_thompson_085


Jawaban:


Untuk informasi terkini tentang Apache dan SNI, termasuk tambahan RFC HTTP-Spesifik, silakan merujuk ke Wiki Apache


FYsI: "Beberapa sertifikat SSL (berbeda) pada satu IP" dibawa kepada Anda oleh keajaiban Peningkatan TLS. Ia bekerja dengan server Apache yang lebih baru (2.2.x) dan browser yang cukup baru (tidak tahu versi dari atas kepala saya).

RFC 2817 (upgrade ke TLS dalam HTTP / 1.1) memiliki detail yang mengerikan, tetapi pada dasarnya ini bekerja untuk banyak orang (jika bukan mayoritas).
Anda dapat mereproduksi perilaku funky lama dengan openssl's s_client perintah (atau browser "cukup lama") sekalipun.

Edit untuk menambahkan: rupanya curl dapat menunjukkan kepada Anda apa yang terjadi di sini lebih baik daripada openssl:


SSLv3

mikeg@flexo% curl -v -v -v -3 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: serialNumber=wq8O9mhOSp9fY9JcmaJUrFNWWrANURzJ; C=CA; 
              O=staging.bossystem.org; OU=GT07932874;
              OU=See www.rapidssl.com/resources/cps (c)10;
              OU=Domain Control Validated - RapidSSL(R);
              CN=staging.bossystem.org
*    start date: 2010-02-03 18:53:53 GMT
*    expire date: 2011-02-06 13:21:08 GMT
* SSL: certificate subject name 'staging.bossystem.org'
       does not match target host name 'www.yummyskin.com'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'staging.bossystem.org'
does not match target host name 'www.yummyskin.com'

TLSv1

mikeg@flexo% curl -v -v -v -1 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: C=CA; O=www.yummyskin.com; OU=GT13670640;
              OU=See www.rapidssl.com/resources/cps (c)09;
              OU=Domain Control Validated - RapidSSL(R);
              CN=www.yummyskin.com
*    start date: 2009-04-24 15:48:15 GMT
*    expire date: 2010-04-25 15:48:15 GMT
*    common name: www.yummyskin.com (matched)
*    issuer: C=US; O=Equifax Secure Inc.; CN=Equifax Secure Global eBusiness CA-1
*    SSL certificate verify ok.

68
2018-02-04 23:46



Itu sangat berguna - Terima kasih! Ada info tentang cara mengonfigurasi Apache untuk TLS dan bukannya SSL? - Josh
Saya pikir Apache 2.2 hanya perlu memiliki bit TLS diaktifkan dalam daftar nol. Saya akui bahwa saya tidak pernah melihat keseluruhan "Peningkatan dari SSL ke TLS" sedikit beraksi sampai dua situs ini. Pemahaman saya tentang dokumen TLS adalah bahwa ini adalah situasi yang diperbolehkan (tetapi tidak biasa) untuk menegosiasikan peningkatan semacam ini ... - voretaq7
Ini pertama kalinya aku melihatnya juga dan aku masih berusaha menarik rahangku dari lantai ... - Josh
OK jawaban saya hanya tiga kali lipat panjangnya - Ternyata curl dapat melakukan negosiasi SSLv3 dan TLSv1 sehingga saya dapat menunjukkan kegagalan & keberhasilan. Saya harap saya memiliki protokol debugger berguna untuk menunjukkan bagian ajaib sekalipun. (Juga diuji dan senang melaporkan bahwa server johnlai2004 dengan benar menolak koneksi SSLv2 :-) - voretaq7
Itu sangat membantu dan saya harap johnlai2004 menerima jawaban Anda. Terima kasih banyak! - Josh


Ya, tetapi ada beberapa peringatan.

Ini dilakukan melalui Indikasi Nama Server, ekstensi untuk Transport Layer Security.

Apa itu Indikasi Nama Server?

Indikasi Nama Server (RFC 6066; usang RFC 4366, RFC 3546) adalah ekstensi untuk Keamanan Lapisan Transportasi yang memungkinkan klien untuk memberi tahu server nama host yang coba diraihnya.

SNI kompatibel dengan TLS 1.0 dan lebih tinggi sesuai spesifikasi, tetapi implementasinya dapat bervariasi (lihat di bawah). Tidak dapat digunakan dengan SSL, jadi koneksi harus menegosiasikan TLS (lihat Apendiks RFC 4346 E) agar SNI bisa digunakan. Ini biasanya terjadi secara otomatis dengan perangkat lunak yang didukung.

Mengapa SNI dibutuhkan?

Secara normal HTTP koneksi, browser menginformasikan server dari nama host server yang mencoba menjangkau menggunakan Host: tajuk. Ini memungkinkan server web pada satu alamat IP untuk melayani konten untuk beberapa nama host, yang umumnya dikenal sebagai virtual hosting berbasis nama.

Alternatifnya adalah menetapkan alamat IP unik untuk setiap nama host web yang akan disajikan. Hal ini biasa dilakukan pada hari-hari awal web, sebelum diketahui secara luas bahwa alamat IP akan habis dan tindakan konservasi dimulai, dan masih dilakukan dengan cara ini untuk host virtual SSL (tidak menggunakan SNI).

Karena metode pemancaran nama host ini membutuhkan koneksi yang sudah ditetapkan, itu tidak bekerja dengan koneksi SSL / TLS. Pada saat koneksi aman diatur, server web harus sudah tahu hostname mana yang akan ditayangkan ke klien, karena server web itu sendiri sedang menyiapkan koneksi aman.

SNI memecahkan masalah ini dengan meminta klien mengirimkan nama host sebagai bagian dari negosiasi TLS, sehingga server sudah mengetahui host virtual mana yang harus digunakan untuk melayani koneksi. Server kemudian dapat menggunakan sertifikat dan konfigurasi untuk virtual host yang benar.

Mengapa tidak menggunakan alamat IP yang berbeda?

HTTP Host: header didefinisikan untuk memungkinkan lebih dari satu host Web untuk dilayani dari satu alamat IP karena kekurangan alamat IPv4, diakui sebagai masalah pada awal pertengahan 1990-an. Dalam lingkungan web hosting bersama, ratusan situs Web unik dan tidak terkait dapat dilayani menggunakan satu alamat IP dengan cara ini, menghemat ruang alamat.

Shared hosting lingkungan kemudian menemukan bahwa konsumen terbesar ruang alamat IP adalah kebutuhan untuk situs web yang aman untuk memiliki alamat IP yang unik, menciptakan kebutuhan untuk SNI sebagai ukuran stop-gap dalam perjalanan ke IPv6. Hari ini kadang-kadang sulit untuk mendapatkan sedikitnya 5 alamat IP (/ 29) tanpa pembenaran yang signifikan, sering mengakibatkan penundaan penyebaran.

Dengan munculnya IPv6, teknik-teknik konservasi alamat semacam ini tidak lagi diperlukan, karena satu host dapat memiliki lebih banyak alamat IPv6 yang ditugaskan kepadanya daripada seluruh Internet yang ada saat ini, tetapi teknik-teknik ini mungkin masih akan digunakan jauh ke masa depan untuk melayani warisan IPv4 koneksi.

Peringatan

Beberapa kombinasi sistem operasi / browser tidak mendukung SNI (lihat di bawah), jadi menggunakan SNI tidak sesuai untuk semua situasi. Situs yang menargetkan kombinasi sistem / browser semacam itu harus meninggalkan SNI dan terus menggunakan alamat IP unik untuk setiap host virtual.

Dari catatan khusus, tidak ada versi Internet Explorer pada Windows XP yang mendukung SNI. Karena kombinasi ini masih merepresentasikan penurunan yang signifikan (namun terus menurun; sekitar 16% lalu lintas Internet pada Desember 2012 menurut NetMarketShare) dari lalu lintas Internet, SNI tidak akan sesuai untuk situs yang menargetkan populasi pengguna ini.

Mendukung

Banyak, tetapi tidak semua, paket perangkat lunak yang umum digunakan mendukung SNI.

(Kelalaian dari daftar ini tidak selalu berarti kurangnya dukungan; itu berarti ada batasan untuk berapa banyak saya bisa mengetik, atau saya tidak dapat dengan cepat menemukan informasi dalam pencarian. Jika paket perangkat lunak Anda tidak terdaftar, mencari untuk nama plus sni harus mengungkapkan jika ada dukungan dan cara mengaturnya.)

Dukungan Perpustakaan

Kebanyakan paket bergantung pada pustaka eksternal untuk menyediakan dukungan SSL / TLS.

  • GNU TLS
  • JSSE (Oracle Java) 7 atau lebih tinggi, hanya sebagai klien
  • libcurl 7.18.1 atau lebih tinggi
  • NSS 3.1.1 atau lebih tinggi
  • OpenSSL 0.9.8j atau lebih tinggi
    • OpenSSL 0.9.8f atau lebih tinggi, dengan mengonfigurasi bendera
  • Q8 4.8 atau lebih tinggi

Dukungan Server

Kebanyakan versi perangkat lunak server populer saat ini mendukung SNI. Instruksi pengaturan tersedia untuk sebagian besar dari ini:

Dukungan Klien

Sebagian besar peramban web dan agen pengguna baris perintah saat ini mendukung SNI.

Desktop

  • Chrome 5 atau lebih tinggi
    • Chrome 6 atau lebih tinggi pada Windows XP
  • Firefox 2 atau lebih tinggi
  • Internet Explorer 7 atau lebih tinggi, berjalan di Windows Vista / Server 2008 atau lebih tinggi
    • Internet Explorer pada Windows XP tidak mendukung SNI terlepas dari versi IE
  • Konqueror 4.7 atau lebih tinggi
  • Opera 8 atau lebih tinggi (mungkin memerlukan TLS 1.1 diaktifkan untuk berfungsi)
  • Safari 3.0 pada Windows Vista / Server 2008 atau lebih tinggi, atau Mac OS X 10.5.6 atau lebih tinggi

Seluler

  • Browser Android di 3.0 Honeycomb atau lebih tinggi
  • Safari iOS di iOS 4 atau lebih tinggi
  • Windows Phone 7 atau lebih tinggi

Garis komando

  • cURL 7.18.1 atau lebih tinggi
  • wget 1.14 atau lebih tinggi (Distribusi mungkin telah didukung a tambalan untuk dukungan SNI)

Tidak ada dukungan

  • Browser BlackBerry
  • Internet Explorer (versi apa saja) di Windows XP

(Catatan: Beberapa informasi untuk jawaban ini diperoleh dari Wikipedia.)


96
2017-08-14 23:05



Jauh lebih baik :-) Mudah-mudahan, ini mungkin akhirnya mendapatkan skor yang lebih tinggi daripada yang saat ini diterima, yang, terlepas dari edit terakhir di atas, sayangnya sebagian besar tidak benar. - Bruno
@Bruno Saya pasti tidak akan mengeluh jika Anda menemukan beberapa ratus orang untuk memberi suara. :) - Michael Hampton♦
Browser BlackBerry terbaru (10?) Menggunakan WebKit versi terbaru, jadi kemungkinan besar itu mendukung SNI sekarang. - dave1010


Masalah:

Ketika klien web dan server web berbicara satu sama lain melalui HTTPS, sangat pertama Hal yang perlu terjadi adalah jabat tangan yang aman.

Berikut ini contoh sederhana dari jabat tangan seperti itu:

tls handshake

Jika ini adalah HTTP dan bukan HTTPS, hal pertama yang akan dikirim klien adalah sesuatu seperti ini:

GET /index.html HTTP/1.1
Host: example.com

Ini membuat beberapa virtual host pada satu alamat IP mungkin, karena server tahu persis apa domain klien ingin mengakses, yaitu example.com.

HTTPS berbeda. Seperti yang saya katakan sebelumnya, jabat tangan itu datang sebelum yang lainnya. Jika Anda melihat langkah ketiga dari jabat tangan yang diilustrasikan di atas (Sertifikat), server harus memberikan sertifikat kepada klien sebagai bagian dari jabat tangan, tetapi tidak tahu apa nama domain yang coba diakses oleh klien. Satu-satunya opsi yang dimiliki server adalah mengirim sertifikat yang sama setiap waktu, sertifikat defaultnya.

Anda masih bisa mengatur virtual host di server web Anda, tetapi server akan selalu mengirim sertifikat yang sama ke setiap klien. Jika Anda mencoba menghosting situs web example.com dan example.org di server Anda, server akan selalu mengirim sertifikat untuk example.com ketika klien meminta koneksi HTTPS. Jadi ketika klien meminta example.org melalui koneksi HTTPS yang sudah ada, ini akan terjadi:

enter image description here

Masalah ini secara efektif membatasi jumlah domain yang Anda dapat server melalui HTTPS ke satu per alamat IP.

Solusinya:

Cara termudah untuk menyelesaikan masalah ini adalah agar klien memberi tahu server domain mana yang ingin diakses selama jabat tangan. Dengan cara ini server dapat menyajikan sertifikat yang benar.

Inilah tepatnya apa SNI, atau Indikasi Nama Server tidak.

Dengan SNI, klien mengirimkan nama server yang ingin diakses sebagai bagian dari pesan pertama, langkah "Klien Hello" dalam diagram jabat tangan di atas.

Beberapa peramban web yang lebih lama tidak mendukung SNI. Misalnya, pada Windows XP di sana bukan versi tunggal Internet Explorer yang memiliki dukungan untuk SNI. Saat mengakses sumber daya melalui HTTPS di server yang menggunakan virtual host SNI, Anda akan diberikan sertifikat generik, yang dapat menyebabkan browser menampilkan peringatan atau kesalahan.

enter image description here

Saya telah menyederhanakan hal-hal di sini hanya untuk menjelaskan prinsip di balik masalah dan solusinya. Jika Anda menginginkan penjelasan yang lebih teknis, maka wikipedia halaman atau RFC 6066 mungkin berfungsi sebagai titik awal yang baik. Anda juga dapat menemukan daftar server dan browser terbaru yang mendukung SNI wikipedia


37
2017-08-14 19:13





http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Browser klien juga harus mendukung SNI. Berikut beberapa browser yang melakukan:

* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (with TLS 1.1 enabled)
* Internet Explorer 7.0 or later (on Vista, not XP)
* Google Chrome
* Safari 3.2.1 on Mac OS X 10.5.6 

16
2018-02-05 00:46





Indikasi nama server (RFC6066) Ekstensi TLS diperlukan untuk vhost berbasis nama untuk bekerja di atas HTTPS.

Perpanjangan ini diterapkan secara luas dan saya belum menemukan masalah dengan perangkat lunak saat ini, tetapi ada kemungkinan bahwa beberapa klien (yang tidak mendukungnya) akan dialihkan ke situs default Anda jika Anda bergantung pada SNI.


6
2017-08-14 19:10



Selain jawaban Falcon, IIS juga memerlukan beberapa perubahan khusus untuk mendapatkan beberapa situs IIS untuk bekerja di atas IP yang sama. Anda harus secara manual mengedit file konfigurasi untuk server atau menggunakan alat CLI untuk membuat perubahan yang mengikat, alat GUI tidak dapat melakukannya. Di IIS itu disebut sebagai menetapkan sertifikat SSL ke tajuk host. Apache tidak memiliki masalah untuk sementara waktu. - Brent Pabst
Ah oke, itu bersihkan beberapa. Bagaimana Anda bisa tahu apakah klien (browser) mendukung ini? Sebagai contoh jika saya ingin memeriksa MSIE6, bagaimana saya bisa menguji itu tanpa harus menginstal mesin XP virtual atau lebih? - Luc
@Luc en.wikipedia.org/wiki/Server_Name_Indication#Support - cjc
@Falcon SNI tidak berfungsi dengan IE di XP; yang masih menyumbang hampir seperempat pengguna Internet Desktop. Saya tidak akan menyebutnya "diterapkan secara luas" ketika seperempat pengunjung potensial tidak berfungsi. - Chris S
@MichaelHampton IE menggunakan stack crypto asli Windows untuk SSL. XP tidak mendukung SNI, karenanya versi IE apa pun yang menjalankan XP juga tidak. IE hanya mendukung SNI di Vista dan OS yang lebih baru. - Chris S