동일한 IP 주소와 동일한 포트에 여러 SSL 도메인이 있습니까?


109

이것은 동일한 IP에서 여러 SSL 웹 사이트를 호스팅 하는 것에 대한 정식 질문 입니다.

각 SSL 인증서에는 고유 한 IP 주소 / 포트 조합이 필요하다는 인상을 받았습니다. 그러나 내가 게시 한 이전 질문에 대한 대답 은이 주장과 상충됩니다.

이 질문의 정보를 사용하여 동일한 IP 주소와 포트 443에서 작동하는 여러 SSL 인증서를 얻을 수있었습니다. 위의 가정을 감안할 때 왜 이것이 작동하고 다른 사람들이 각 SSL 도메인 웹 사이트의 동일한 서버에는 자체 IP / 포트가 필요합니다.

내가 잘못한 것이 의심 스럽다. 이 방법으로 여러 SSL 인증서를 사용할 수 있습니까?


이 Q 본문에는 여러 인증서가 있으며 그에 대한 답변이 맞습니다. 그러나 제목은 여러 도메인을 말하며 하나의 인증서로 SNI가없는 여러 도메인을 가질 수 있습니다. serverfault.com/questions/126072/…serverfault.com/questions/279722/… 도 참조하십시오 .
dave_thompson_085

답변:


68

추가 HTTP 특정 RFC를 포함하여 Apache 및 SNI에 대한 최신 정보는 Apache Wiki 를 참조하십시오.


FYsI : "하나의 IP에 여러 (서로 다른) SSL 인증서"는 TLS 업그레이드의 마법에 의해 제공됩니다. 최신 Apache 서버 (2.2.x) 및 합리적으로 최신 브라우저 (내 머리 위에있는 버전을 모름)와 함께 작동합니다.

RFC 2817 (HTTP / 1.1 내에서 TLS로 업그레이드)에는 세부적인 내용이 있지만 기본적으로 많은 사람들에게 적용됩니다.
openssl의 s_client명령 (또는 "충분히 오래된"브라우저)을 사용 하여 오래된 펑키 동작을 재현 할 수 있습니다 .

추가 편집 : 분명히 curlopenssl보다 더 나은 상황을 보여줄 수 있습니다.


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.

2
매우 유용합니다-감사합니다! SSL 대신 TLS 용 Apache를 구성하는 방법에 대한 정보가 있습니까?
Josh

2
Apache 2.2는 Cypher 목록에서 TLS 비트를 활성화해야한다고 생각합니다. 그래도이 두 사이트까지 전체 "SSL에서 TLS로 업그레이드"비트가 작동하는 것을 본 적이 없다는 것을 인정합니다. TLS 문서에 대한 나의 이해는 이런 종류의 업그레이드를 협상하는 것이 허용되는 (그러나 이례적인) 상황이라는 것입니다.
voretaq7

이것은 내가 처음으로 본 적이 있는데 여전히 턱을 바닥에서 빼내려고 노력하고 있습니다.
Josh

1
내 대답은 길이가 세 배로 늘었습니다. curl은 SSLv3 및 TLSv1 협상을 모두 수행하여 실패 및 성공을 보여줄 수 있습니다. 마술 부분을 보여주기에 편리한 프로토콜 디버거가 있었으면 좋겠다. (또한 johnlai2004의 서버가 SSLv2 연결을 올바르게 거부한다는 사실을 테스트하여 기쁘게 생각합니다 :-)
voretaq7

이는 매우 도움이되며 johnlai2004가 귀하의 답변을 수락하기를 바랍니다. 고마워요!
Josh

97

예, 그러나 몇 가지주의 사항이 있습니다.

이는 전송 계층 보안의 확장 인 서버 이름 표시를 통해 수행됩니다.

서버 이름 표시 란 무엇입니까?

서버 이름 표시 ( RFC 6066 ; 더 이상 사용되지 않는 RFC 4366 , RFC 3546 )는 전송 계층 보안 의 확장으로 , 클라이언트가 서버에 연결하려는 호스트 이름을 알려줄 수 있습니다.

SNI는 사양에 따라 TLS 1.0 이상과 호환되지만 구현 방법은 다를 수 있습니다 (아래 참조). SSL과 함께 사용할 수 없으므로 SNI를 사용 하려면 연결에서 TLS를 협상해야합니다 ( RFC 4346 부록 E 참조 ). 이것은 일반적으로 지원되는 소프트웨어에서 자동으로 발생합니다.

SNI가 필요한 이유는 무엇입니까?

일반 HTTP 연결에서 브라우저는 Host:헤더를 사용하여 도달하려는 서버의 호스트 이름을 서버에 알려줍니다 . 이를 통해 단일 IP 주소의 웹 서버가 일반적으로 이름 기반 가상 호스팅 이라고하는 여러 호스트 이름의 컨텐츠를 제공 할 수 있습니다 .

대안은 제공 할 각 웹 호스트 이름에 고유 한 IP 주소를 할당하는 것입니다. 이는 IP 주소가 소진되고 보존 조치가 시작되었다는 사실이 널리 알려지기 전에 웹 초기에 일반적으로 수행되었으며 SSL 가상 호스트 (SNI를 사용하지 않음)에 대해서는 여전히 이런 방식으로 수행됩니다.

호스트 이름을 전송하는이 방법에는 연결이 이미 설정되어 있어야하므로 SSL / TLS 연결에서는 작동하지 않습니다. 보안 연결이 설정 될 때 웹 서버 자체가 보안 연결을 설정하고 있기 때문에 웹 서버는 클라이언트에 제공 할 호스트 이름을 알고 있어야합니다.

SNI는 클라이언트가 TLS 협상의 일부로 호스트 이름을 전송하도록하여이 문제를 해결하므로 서버는 연결을 서비스하는 데 어떤 가상 호스트를 사용해야하는지 이미 알고 있습니다. 그런 다음 서버는 올바른 가상 호스트에 대한 인증서 및 구성을 사용할 수 있습니다.

다른 IP 주소를 사용하지 않는 이유는 무엇입니까?

HTTP Host:헤더는 IPv4 주소가 부족하여 단일 IP 주소에서 둘 이상의 웹 호스트를 제공 할 수 있도록 정의되었으며, 1990 년대 중반 초기에 문제로 인식되었습니다. 공유 웹 호스팅 환경에서 주소 공간을 절약하면서 단일 IP 주소를 사용하여 수백 개의 고유 한 관련없는 웹 사이트를 제공 할 수 있습니다.

공유 호스팅 환경은 IP 주소 공간의 가장 큰 소비자가 보안 웹 사이트에 고유 한 IP 주소를 가져야하므로 IPv6로가는 길을 막는 수단으로 SNI가 필요하다는 것을 알게되었습니다. 오늘날 상당한 정당화없이 5 개의 IP 주소 (/ 29)를 얻기가 어려워 배포 지연이 발생하는 경우가 있습니다.

IPv6의 출현으로 단일 호스트는 오늘날 전체 인터넷에 포함 된 것보다 더 많은 IPv6 주소를 할당 할 수 있기 때문에 이러한 주소 보존 기술은 더 이상 필요하지 않지만이 기술은 여전히 ​​미래의 IPv4 서비스에 사용될 것입니다. 사이.

경고

일부 운영 체제 / 브라우저 조합은 SNI를 지원하지 않으므로 (아래 참조) SNI를 사용하는 것이 모든 상황에 적합하지는 않습니다. 이러한 시스템 / 브라우저 조합을 대상으로하는 사이트는 SNI를 포기하고 각 가상 호스트에 대해 고유 한 IP 주소를 계속 사용해야합니다.

특히 Windows XP의 Internet Explorer 버전은 SNI를 지원하지 않습니다. 이 조합은 여전히 ​​인터넷 트래픽의 상당 부분 (하지만 꾸준히 감소하고 있습니다 (NetMarketShare에 따르면 2012 년 12 월 인터넷 트래픽의 약 16 %))을 나타내므로 SNI는 이러한 사용자 인구를 대상으로하는 사이트에 적합하지 않습니다.

지원하다

일반적으로 사용되는 소프트웨어 패키지는 아니지만 대부분이 SNI를 지원합니다.

(이 목록에서 누락되었다고해서 반드시 지원이 부족하다는 것은 아닙니다. 입력 할 수있는 수량에 제한이 있거나 검색에서 정보를 빨리 찾을 수 없다는 것을 의미합니다. 소프트웨어 패키지가 표시되지 않으면 검색 이름 플러스 sni는 지원이 존재하는지와 설정 방법을 공개해야합니다.)

도서관 지원

대부분의 패키지는 SSL / TLS 지원을 제공하기 위해 외부 라이브러리에 의존합니다.

  • GNU TLS
  • 클라이언트로만 JSSE (Oracle Java) 7 이상
  • libcurl 7.18.1 이상
  • NSS 3.1.1 이상
  • OpenSSL 0.9.8j 이상
    • 구성 플래그가있는 OpenSSL 0.9.8f 이상
  • Qt 4.8 이상

서버 지원

널리 사용되는 서버 소프트웨어의 최신 버전은 SNI를 지원합니다. 다음과 같은 대부분의 설정 지침이 제공됩니다.

고객 지원

대부분의 최신 웹 브라우저 및 명령 줄 사용자 에이전트는 SNI를 지원합니다.

데스크탑

  • 크롬 5 이상
    • Windows XP의 Chrome 6 이상
  • Firefox 2 이상
  • Windows Vista / Server 2008 이상에서 실행되는 Internet Explorer 7 이상
    • Windows XP의 Internet Explorer는 IE 버전에 관계없이 SNI를 지원하지 않습니다
  • Konqueror 4.7 이상
  • Opera 8 이상 (TLS 1.1이 작동하도록 설정해야 할 수 있음)
  • Windows Vista / Server 2008 이상 또는 Mac OS X 10.5.6 이상에서 Safari 3.0

변하기 쉬운

  • 3.0 Honeycomb 이상의 Android 브라우저
  • iOS 4 이상의 iOS Safari
  • Windows Phone 7 이상

커맨드 라인

  • cURL 7.18.1 이상
  • wget 1.14 이상 (분포가 SNI 지원용 패치 를 백 포트했을 수 있음 )

지원 없음

  • BlackBerry 브라우저
  • Windows XP의 Internet Explorer (모든 버전)

(참고 :이 답변에 대한 일부 정보는 Wikipedia 에서 얻었습니다 .)


1
훨씬 더 나은 :-) 바라건대, 이것은 결국 현재 승인 된 것보다 더 높은 점수를 얻을 수 있습니다.
Bruno

1
@Bruno 난 당신이 그것을 찬성하는 몇 백명을 찾으면 확실히 불평하지 않습니다. :)
Michael Hampton

최신 BlackBerry Browser (10?)는 최신 버전의 WebKit을 사용하므로 현재 SNI를 지원할 가능성이 높습니다.
dave1010

37

문제 :

웹 클라이언트와 웹 서버가 HTTPS를 통해 서로 대화 할 때 가장 먼저 해야 할 일은 안전한 핸드 셰이크입니다.

다음은 그러한 핸드 셰이크의 간단한 예입니다.

tls 핸드 셰이크

이것이 HTTPS가 아닌 HTTP 인 경우 클라이언트가 가장 먼저 보낸 것은 다음과 같습니다.

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

이는 서버가 클라이언트가 액세스하려는 도메인 (예 : example.com)을 정확히 알고 있기 때문에 단일 IP 주소에 여러 개의 가상 호스트를 가능하게했습니다.

HTTPS가 다릅니다. 앞서 말했듯이 악수는 다른 모든 것보다 낫습니다. 위에서 설명한 핸드 셰이크 (인증서)의 세 번째 단계를 보면 서버는 핸드 셰이크의 일부로 클라이언트에 인증서를 제시해야하지만 클라이언트가 액세스하려는 도메인 이름을 알 수는 없습니다. 서버가 가질 수있는 유일한 옵션은 매번 동일한 인증서, 기본 인증서를 보내는 것입니다.

여전히 웹 서버에서 가상 호스트를 설정할 수 있지만 서버는 항상 동일한 인증서를 각 클라이언트에 보냅니다. 서버에서 example.com 및 example.org 웹 사이트를 모두 호스트하려고하면 클라이언트가 HTTPS 연결을 요청할 때 서버는 항상 example.com에 대한 인증서를 보냅니다. 따라서 클라이언트가 설정된 HTTPS 연결을 통해 example.org를 요청하면 다음이 발생합니다.

여기에 이미지 설명을 입력하십시오

이 문제로 인해 HTTPS를 통해 서버에서 할 수있는 도메인의 수를 IP 주소 당 하나로 제한 할 수 있습니다.

해결책:

이 문제를 해결하는 가장 쉬운 방법은 클라이언트가 핸드 셰이크 중에 액세스하려는 도메인을 서버에 알리는 것 입니다. 이렇게하면 서버가 올바른 인증서를 제공 할 수 있습니다.

이것이 바로 SNI 또는 서버 이름 표시의 기능입니다.

SNI를 사용하면 클라이언트는 첫 번째 메시지의 일부로 액세스하려는 서버 이름 (위의 핸드 셰이크 다이어그램의 "Client Hello"단계)을 보냅니다.

일부 구형 웹 브라우저는 SNI를 지원하지 않습니다. 예를 들어, Windows XP에는 SNI를 지원 하는 단일 버전의 Internet Explorer가 없습니다 . SNI 가상 호스트를 사용하는 서버에서 HTTPS를 통해 리소스에 액세스하면 일반 인증서가 제공되어 브라우저에 경고 또는 오류가 표시 될 수 있습니다.

여기에 이미지 설명을 입력하십시오

나는 문제와 해결책의 기본 원리를 설명하기 위해 여기에서 단순화했습니다. 보다 기술적 인 설명이 필요하면 wikipedia 페이지 또는 RFC 6066 이 좋은 출발점이 될 수 있습니다. 또한 위키 백과에서 SNI를 지원하는 최신 서버 및 브라우저 목록을 찾을 수 있습니다.



6

이름 기반 가상 호스트가 HTTPS를 통해 작동하려면 서버 이름 표시 (RFC6066) TLS 확장이 필요합니다.

확장 기능은 널리 구현되어 있지만 현재 소프트웨어에 문제가 발생하지 않았지만 SNI에 의존하는 경우 일부 클라이언트 (지원하지 않는 클라이언트)가 기본 사이트로 라우팅 될 가능성이 있습니다.


Falcon의 답변 외에도 IIS는 여러 IP 사이트가 동일한 IP를 통해 작동하도록 특별한 변경이 필요합니다. 서버의 구성 파일을 수동으로 편집하거나 CLI 도구를 사용하여 바인딩을 변경해야합니다. GUI 도구는이를 수행 할 수 없습니다. IIS에서는 호스트 헤더에 SSL 인증서를 할당하는 것을 말합니다. 아파치는 한동안 문제가 없었습니다.
브렌트

아 괜찮아요. 클라이언트 (브라우저)가이를 지원하는지 어떻게 알 수 있습니까? 예를 들어 MSIE6을 확인하려면 가상 XP 시스템을 설치하지 않고 어떻게 테스트 할 수 있습니까?
Luc


1
@Falcon SNI는 XP의 IE에서 작동하지 않습니다. 여전히 데스크톱 인터넷 사용자의 거의 4 분의 1을 차지합니다. 잠재적 인 방문자의 4 분의 1이 일하지 않을 때 나는 그것을 "넓게 구현 된"것으로 부르지 않을 것입니다.
Chris S

1
@MichaelHampton IE는 SSL에 기본 Windows 암호화 스택을 사용합니다. XP는 SNI를 지원하지 않으므로 XP를 실행하는 모든 IE 버전도 지원하지 않습니다. IE는 Vista 및 최신 OS에서만 SNI를 지원합니다.
Chris S
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.