Soru Aynı IP adresi ve aynı bağlantı noktasında birden çok SSL alanı var mı?


Bu bir Kanonik Soru Aynı IP'de birden çok SSL web sitesi barındırma hakkında.

Her SSL Sertifikasının kendi benzersiz IP Adresi / Bağlantı Noktası kombinasyonuna ihtiyaç duyduğu izlenimi altındaydım. Fakat Gönderdiğim bir önceki soruya cevap ver bu iddiayla çelişmektedir.

Bu Sorudaki bilgileri kullanarak, aynı IP adresi ve 443 numaralı bağlantı noktasında çalışmak için birden çok SSL sertifikası alabildim. Bu varsayımın neden yukarıda belirtilen varsayımları verdiğine ve başkaları tarafından her SSL etki alanı web sitesinin Aynı sunucu kendi IP / Port'unu gerektirir.

Yanlış bir şey yaptığımı şüpheliyim. Birden çok SSL Sertifikası bu şekilde kullanılabilir mi?


107
2018-02-04 22:36


Menşei


Bu Q gövdesi, birden fazla sertifikayı söylüyor ve cevaplar bunun için doğru. Ancak başlık birden fazla alan adı ve siz diyor bir sertifika ile birden fazla alan olabilir (ve hiçbir SNI), bkz. serverfault.com/questions/126072/... ve serverfault.com/questions/279722/... Ayrıca güvenlik çapraz. - dave_thompson_085


Cevaplar:


Ek HTTP'ye Özel RFC'ler dahil olmak üzere Apache ve SNI ile ilgili en güncel bilgiler için lütfen Apache Wiki


FYsI: "Tek bir IP üzerinde birden çok (farklı) SSL sertifikası" TLS Yükseltme büyüsü ile size getirilir. Daha yeni Apache sunucuları (2.2.x) ve oldukça yeni tarayıcılarla çalışır (başımın üst kısmındaki sürümleri bilmez).

RFC 2817 (HTTP / 1.1 içinde TLS'ye yükseltme), gory ayrıntılarına sahiptir, ancak temelde birçok insan için çalışır (çoğunluk değilse).
Eski funky davranışını openssl ile yeniden üretebilirsiniz. s_client komut (veya herhangi bir "eski yeterli" tarayıcı).

Eklemek için düzenle: görünüşte curl Burada neler olduğunu openssl'den daha iyi gösterebilir:


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



Bu çok yararlı - Teşekkürler! SSL yerine TLS için Apache'yi yapılandırma hakkında herhangi bir bilgi var mı? - Josh
Apache 2.2'nin sadece cypher listesinde etkinleştirilmiş TLS bitlerine sahip olması gerektiğini düşünüyorum. Bu iki site kadar hiçbir zaman "SSL'den TLS'ye Yükseltme" işleminin tamamını görmediğimi itiraf edeceğim. TLS dokümanlar konusundaki anlayışım, bu tür bir yükseltmeyi müzakere etmek için izin verilebilir (ama sıra dışı) bir durum olması. - voretaq7
Bunu ilk gördüğüm zaman ve hala çenemi yerden çekmeye çalışıyorum. - Josh
Tamam benim cevap sadece üç katına çıktı - Görünüşte curl hem SSLv3 hem de TLSv1 müzakereleri yapabilir, böylece başarısızlığı ve başarıyı gösterebilirim. Keşke sihir bölümünü göstermek için kullanışlı bir protokol hata ayıklayıcımı olsaydı. (Ayrıca, johnlai2004'ün sunucusunun SSLv2 bağlantılarını doğru bir şekilde reddettiğini bildiren test edilmiş ve mutluyuz :-) - voretaq7
Bu son derece yararlı ve umarım johnlai2004 cevabınızı kabul eder. Çok teşekkürler! - Josh


Evet, ama bazı uyarılar var.

Bu, Aktarım Katmanı Güvenliği'nin bir uzantısı olan Sunucu Adı Göstergesi ile gerçekleştirilir.

Sunucu Adı Göstergesi Nedir?

Sunucu Adı Belirtimi (RFC 6066; obsoleted RFC 4366, RFC 3546) bir uzantısıdır taşıma katmanı Güvenliği bu, istemciye sunucunun ulaşmaya çalıştığı ana bilgisayarın adını söylemesini sağlar.

SNI, TLS 1.0 ile uyumludur ve spesifikasyonlara göre daha yüksektir, ancak uygulamalar değişebilir (aşağıya bakınız). SSL ile kullanılamaz, dolayısıyla bir bağlantı TLS ile görüşülmelidir (bkz. RFC 4346 ek E) SNI kullanılacak. Bu genellikle desteklenen yazılımla otomatik olarak gerçekleşir.

SNI neden gereklidir?

Normalde HTTP bağlantıyı, tarayıcı kullanarak sunucuya ulaşmaya çalıştığı sunucunun sunucu adını bildirir. Host: başlığı. Bu, tek bir IP adresindeki bir web sunucusunun, yaygın olarak bilinen birden çok ana bilgisayar adı için içerik sunmasına izin verir. ad-tabanlı sanal barındırma.

Alternatif, servis edilecek her bir web ana makine adı için benzersiz IP adresleri atamaktır. Bu, yaygın olarak IP adreslerinin tükeneceği ve koruma önlemlerinin başladığı bilinmeden önce, web'in ilk günlerinde yapıldı ve SSL sanal ana bilgisayarlar için (SNI kullanılmadan) hala bu şekilde yapıldı.

Ana bilgisayar adını iletme yöntemi, önceden kurulmuş olan bağlantıyı gerektirdiğinden, SSL / TLS bağlantıları ile çalışmaz. Güvenli bağlantı kurulduktan sonra, web sunucusunun istemci için hangi hostname servisine gideceğini bilmesi gerekir çünkü web sunucusunun kendisi güvenli bağlantıyı kuruyor.

SNI, istemcinin host adını TLS anlaşmasının bir parçası olarak iletmesini sağlayarak bu sorunu çözmektedir, böylece sunucu bağlantıya hizmet vermek için hangi sanal sunucunun kullanılacağının zaten farkındadır. Sunucu daha sonra doğru sanal konak için sertifika ve yapılandırmayı kullanabilir.

Neden farklı IP adresleri kullanmıyorsunuz?

HTTP Host: başlık, IPv4 adreslerinin eksikliğinden dolayı, 1990'ların ortalarında bir sorun olarak kabul edilen, birden fazla Web sunucusunun tek bir IP adresinden sunulmasına izin verecek şekilde tanımlanmıştır. Paylaşılan web barındırma ortamlarında, yüzlerce benzersiz, ilgisiz Web sitesi, bu şekilde tek bir IP adresi kullanılarak adres alanını koruyarak sunulabilir.

Paylaşılan barındırma ortamları, IP adresi alanının en büyük tüketicisinin, IPv6 yolunda bir durak noktası önlemi olarak SNI gereksinimini yaratarak, güvenli IP adreslerinin benzersiz IP adreslerine sahip olması gerektiğine karar verdiler. Bugün, önemli bir gerekçe olmaksızın, genellikle dağıtım gecikmelerine neden olan, az sayıda 5 IP adresi (/ 29) elde etmek bazen zordur.

IPv6'nın ortaya çıkmasıyla, böyle bir adres koruma teknikleri artık gerekli değildir, çünkü tek bir ana bilgisayar, günümüzde tüm İnternet'in içerdiğinden daha fazla IPv6 adresi atayabilir, ancak teknikler muhtemelen eski IPv4 hizmetine erişmek için gelecekte de kullanılabilir. bağlantıları.

Uyarılar

Bazı işletim sistemi / tarayıcı kombinasyonları SNI'yı desteklemez (aşağıya bakınız), dolayısıyla SNI kullanımı tüm durumlar için uygun değildir. Bu tür sistem / tarayıcı kombinasyonlarını hedefleyen siteler, SNI'den geçmek zorunda kalacak ve her sanal konak için benzersiz IP adresleri kullanmaya devam edecektir.

Özellikle not, Windows XP'de Internet Explorer'ın hiçbir sürümü SNI'yi desteklemez. Bu kombinasyon, İnternet trafiğinin önemli bir kısmını (ancak Aralık 2012'de İnternet trafiğinin yaklaşık% 16'sı oranında sabit bir şekilde) temsil ettiğinden, bu kullanıcı popülasyonlarını hedefleyen bir site için SNI uygun değildir.

Destek

Yaygın olarak kullanılan yazılım paketlerinin çoğu, hepsi değil, SNI'yi destekler.

(Bu listeden çıkma mutlaka destek eksikliği anlamına gelmez, ne kadar yazabileceğimin bir sınırı olduğu veya bir aramayla bilgileri hızlıca bulamadığım anlamına gelir. Yazılım paketiniz listelenmemişse, arama onun adına artı sni destek varsa ve nasıl ayarlanacağını açıklamalıdır.)

Kütüphane Desteği

Çoğu paket SSL / TLS desteği sağlamak için harici bir kütüphaneye bağımlıdır.

  • GNU TLS
  • JSSE (Oracle Java) 7 veya üstü, sadece bir müşteri olarak
  • libcurl 7.18.1 veya daha yüksek
  • NSS 3.1.1 veya daha yüksek
  • OpenSSL 0.9.8j veya daha yüksek
    • Yapı bayrakları ile OpenSSL 0.9.8f veya üstü
  • Qt 4.8 veya daha yüksek

Sunucu Desteği

Popüler sunucu yazılımının en güncel sürümleri SNI'yi destekler. Kurulum yönergeleri çoğu için kullanılabilir:

Müşteri Desteği

Çoğu mevcut web tarayıcıları ve komut satırı kullanıcı aracıları SNI'yi destekler.

Masaüstü

  • Chrome 5 veya daha yüksek
    • Windows XP'de Chrome 6 veya üstü
  • Firefox 2 veya üstü
  • Windows Vista / Server 2008 veya daha yüksek bir sürümde çalışan Internet Explorer 7 veya üstü
    • Windows XP'deki Internet Explorer, IE sürümünden bağımsız olarak SNI'yı desteklemez
  • Konqueror 4.7 veya daha yüksek
  • Opera 8 veya üstü (TLS 1.1 işlevinin etkin olmasını gerektirebilir)
  • Windows Vista / Server 2008 veya üzeri Safari 3.0 veya Mac OS X 10.5.6 veya üstü

seyyar

  • 3.0 Honeycomb veya üzeri Android Browser
  • iOS 4 veya üzeri iOS Safari
  • Windows Phone 7 veya üstü

Komut satırı

  • cURL 7.18.1 veya daha yüksek
  • 1.14 veya daha yüksek bir değer (Dağılımlar bir yama SNI desteği için)

Destek yok

  • BlackBerry Tarayıcı
  • Windows XP'de Internet Explorer (herhangi bir sürüm)

(Not: Bu cevap için bazı bilgiler Vikipedi.)


96
2017-08-14 23:05



Çok daha iyi :-) Umarız, bu sonuçta, şu anda kabul edilmiş olandan daha yüksek bir puana sahip olabilir, ki bu, üstteki son düzenlemeden başka, ne yazık ki çoğunlukla yanlıştır. - Bruno
@Bruno Bunu kabul etmek için birkaç yüz kişi bulursanız kesinlikle şikayet etmeyeceğim. :) - Michael Hampton♦
En yeni BlackBerry Browser (10?), WebKit'in son bir sürümünü kullanıyor, dolayısıyla SNI'yı şimdi desteklemesi çok olası. - dave1010


Sorun:

Bir web istemcisi ve bir web sunucusu HTTPS üzerinden birbiriyle konuştuğunda, İlk Olması gereken şey güvenli el sıkışmadır.

İşte böyle bir el sıkışmasının basitleştirilmiş bir örneği:

tls handshake

Bu HTTP ve HTTPS olmasaydı, istemcinin göndereceği ilk şey şöyle olurdu:

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

Bu, tek bir IP adresi üzerinde birden fazla sanal konakçı oluşturdu, çünkü sunucu tam olarak istemciye erişmek istediği alanı, yani example.com'u biliyor.

HTTPS farklıdır. Daha önce söylediğim gibi, el sıkışma her şeyden önce gelir. Yukarıda gösterilen el sıkışmasının üçüncü aşamasına (Sertifika) bakarsanız, sunucunun el sıkışmalarının bir parçası olarak istemciye bir sertifika sunması gerekir, ancak istemcinin erişmeye çalıştığı etki alanı hakkında hiçbir ipucu yoktur. Sunucunun sahip olduğu tek seçenek, her defasında aynı sertifikayı varsayılan sertifikasını göndermektir.

Web sunucunuzda hala sanal konaklar kurabilirsiniz, ancak sunucu her zaman aynı sertifikayı her bir istemciye gönderir. Sunucunuzda hem example.com hem de example.org web sitelerini barındırmaya çalışırsanız, bir istemci bir HTTPS bağlantısı istediğinde, sunucu her zaman example.com için sertifika gönderir. Bir istemci, yerleşik bir HTTPS bağlantısı üzerinden example.org'u istediğinde, bu gerçekleşir:

enter image description here

Bu sorun, HTTPS üzerinden sunucunuzu IP adresi başına bir taneye yapabileceğiniz alan sayısını etkili bir şekilde sınırlar.

Çözüm:

Bu sorunu çözmenin en kolay yolu, istemcinin hangi etki alanına erişmek istediğini sunucuya bildirmesidir. el sıkışma sırasında. Bu şekilde sunucu doğru sertifikayı sunabilir.

Bu tam olarak ne SNIveya Sunucu Adı Belirtimi yapar.

SNI ile istemci, ilk mesajın bir parçası olarak erişmek istediği sunucu adını, yukarıdaki el sıkışma şemasındaki "Müşteri Merhaba" adımını gönderir.

Bazı eski web tarayıcıları SNI'yi desteklemez. Örneğin, Windows XP'de Internet Explorer'ın tek bir sürümü değil SNI desteği var. SNI sanal ana bilgisayarlarını kullanan bir sunucuda HTTPS üzerinden bir kaynağa erişirken, tarayıcının bir uyarı veya hata göstermesine neden olabilecek bir genel sertifika ile sunulur.

enter image description here

Problemin ve çözümün arkasındaki ilkeyi açıklamak için burada bazı şeyleri basitleştirdim. Daha teknik bir açıklama yapmak isterseniz wikipedia sayfa veya RFC 6066 iyi başlangıç ​​noktaları olarak hizmet edebilir. Ayrıca, SNI'yı destekleyen sunucular ve tarayıcıların güncel bir listesini de bulabilirsiniz. wikipedia


37
2017-08-14 19:13





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

İstemci tarayıcısı da SNI'yi desteklemelidir. İşte bazı tarayıcılar:

* 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





HTTPS üzerinde çalışmak için isim tabanlı sanal sunucular için sunucu adı göstergesi (RFC6066) TLS uzantısı gereklidir.

Uzantı yaygın bir şekilde uygulanıyor ve henüz güncel yazılımlarla ilgili herhangi bir sorunla karşılaşmam gerekiyor, ancak SNI'ya bağlıysanız, bazı istemcilerin (bunu desteklemeyen) varsayılan sitenize yönlendirilme şansı vardır.


6
2017-08-14 19:10



Falcon'un cevabına ek olarak IIS, aynı IP üzerinde çalışacak birden çok IIS sitesini almak için bazı özel değişiklikler gerektirir. Sunucu için yapılandırma dosyasını elle düzenlemeniz veya bağlayıcı değişiklikleri yapmak için bir CLI aracı kullanmanız gerekir, GUI aracı bunu yapamaz. IIS'de, üstbilgileri barındırmak için SSL sertifikaları atamak olarak adlandırılır. Apache'nin bir süredir sorunu yoktu. - Brent Pabst
Ah tamam, bu biraz temizler. Bir istemci (tarayıcı) bunu destekleyip desteklemediğini nasıl anlarsınız? Örneğin, MSIE6'yı kontrol etmek istersem, sanal bir XP makinesini kurmak zorunda kalmadan nasıl test edebilirim? - Luc
@Luc en.wikipedia.org/wiki/Server_Name_Indication#Support - cjc
@Falcon SNI, XP'de IE ile çalışmıyor; Hala Masaüstü İnternet kullanıcılarının yaklaşık dörtte birini oluşturmaktadır. Potansiyel ziyaretçilerin dörtte biri çalışmadığında "yaygın olarak uygulanan" demezdim. - Chris S
@MichaelHampton IE, SSL için yerel Windows kripto yığınını kullanır. XP, SNI'yi desteklemiyor, bununla birlikte, XP'nin çalışan herhangi bir IE sürümü de yoktur. IE sadece Vista ve yeni işletim sistemlerinde SNI'yı destekler. - Chris S