개요
가상 호스팅 에 여러 웹 사이트를 제공하는 관행입니다 같은 서버. 요즘은 표준이지만 HTTP 초기 (1.1 이전 버전)에서는 불가능했습니다.
원래 서버는 각 웹 사이트에 전용 포트가 할당 된 경우 동일한 컴퓨터 (예 : 동일한 IP 주소)에서 여러 웹 사이트 만 호스팅 할 수있었습니다. 브라우저는 기본적으로 포트로 설정되므로 이상적인 솔루션이 아닙니다. 80
사용자가 다른 것을 지정하지 않는 한 HTTP의 경우. 결과적으로 대부분의 웹 사이트 소유자는 사용자가 올바른 포트 번호를 기억하지 않고 다른 웹 사이트로 연결되는 위험을 피하기 위해 전용 서버를 선택했습니다.
그럼에도 불구하고 더 많은 사용자가 웹에 참여하고 더 많은 네트워크 장치가 온라인으로 나타나기 시작하면서 사용 가능한 IP 주소 수가 놀라운 속도로 감소하기 시작했습니다. 이 예상되는 고갈은 IPv4 주소 범위 소진, 업계를 주도하여 다양한 대책을 설계하고 구현했습니다. IPv6 (IPv4의 후계자) 우리가 필요로하는 것보다 더 많은 주소. 불행하게도, IPv6는 실행 가능한 솔루션이지만 채택 속도가 상당히 느 렸습니다. 에 따르면 Google의 IPv6 통계이 글을 쓰는 시점에서 인터넷 장치의 약 25 %만이 IPv6를 통해 배포되었습니다.
가상 호스팅은 또한 소진 문제에 대한 초기 완화로 구현되었으며 Host
HTTP 1.1의 헤더. HTTP 1.1을 통해 통신하는 브라우저는 이제 서버의 포트에 연결할 수 있습니다. 80
도메인 이름을 포함하십시오 (예 : www.ssl.com
)에서 방문하려는 웹 사이트의 Host
헤더. 서버가 동일한 포트에서 호스팅하는 사이트 수에 관계없이이 정보를 사용하여 올바른 웹 사이트를 식별하고 해당 컨텐츠를 반환 할 수 있습니다.
HTTPS 및 가상 호스팅
그러나 네트워크 취약성 및 웹 사용자에 대한 공격에 대한 수많은 보고서가 업계에 동기를 부여했습니다. 안전하지 않은 HTTP에서 더 안전한 대체 HTTPS로 이동하십시오.. 의 넓은 채용 HTTPS 전반적인 사용자 보안이 향상되었습니다. 그러나 추가 기능 향상으로 인해 웹 통신의 일반적인 복잡성도 증가했습니다.
원칙적으로 HTTPS는 브라우저와 서버 간의 HTTPS 통신이 암호화된다는 점을 제외하면 HTTP와 매우 유사합니다. 간단히 말해서 HTTPS를 사용하려면 서버가 공개적으로 신뢰할 수있는 기관에서 발급 한 유효한 SSL 인증서를 브라우저에 제공해야합니다. 인증 기관 (CA) 등 SSL.com. 그러면 브라우저는 인증서에 포함 된 공개 키를 사용하여 서버와 암호화 된 통신 채널을 구축. 또한 특정 도메인 이름에 대한 인증서가 발급되어 브라우저에서 사용자가 방문하려는 도메인과 일치하는지 확인합니다. 따라서 서버가 호스팅하는 웹 사이트 수에 관계없이 브라우저는 요청한 웹 사이트에 유효한 SSL 인증서를 찾을 것으로 예상합니다.
주의 깊은 독자는 이미 문제를 감지 할 수 있습니다. 브라우저는 암호화 된 채널을 설정하고 메시지를 전송하기 위해 올바른 웹 사이트의 인증서가 필요합니다. Host
헤더는 서버에 필요한 반면 Host
헤더를 사용하여 올바른 사이트의 인증서를 찾습니다. 이것은 전형적인 닭고기와 달걀 문제입니다.
보안 컨트롤이 브라우저가 브라우저를 전송하지 못하도록하기 때문에 HTTP 용으로 생각 된 가상 호스팅은 HTTPS에서 작동하지 않습니다. Host
정보를 서버로 전송합니다. 그럼에도 불구하고 IPv4 고갈 문제가 아직 해결되지 않았고 업계에서 클라우드 기술 (로드 밸런싱 및 다중 장애 조치 백엔드 서버가 필요함)의 채택이 계속 증가함에 따라 가상 호스팅은 여전히 필수입니다.
다중 도메인 인증서는 어떻습니까?
이 문제에 대한 제안 된 해결책은 다중 도메인 또는 SAN 인증서. 단일 SAN 인증서는 수백 개의 서로 다른 도메인 이름을 보호 할 수 있으며 브라우저는 SAN 인증서의 도메인 목록에서 방문하려는 도메인 이름을 찾으면 불평하지 않습니다. 암호화 된 채널이 구성된 후 브라우저는 Host
헤더를 서버에 추가하고 다른 경우와 마찬가지로 계속합니다. 이는 이미 존재하고 사용 가능한 기술을 활용하는 좋은 아이디어이지만 SAN 인증서의 보안을 보장하는 동일한 메커니즘으로 인해 잠재적으로 바람직하지 않은 몇 가지 부작용이 발생했습니다.
SAN 인증서는 동일한 엔터티 (개인, 회사 또는 조직)가 소유 한 여러 도메인을 보호하기위한 훌륭한 도구이지만 공유 호스팅에 사용하기에는 다소 비실용적입니다. 새 도메인을 인증서에 추가하거나 인증서에서 제거 할 준비가되면 CA에서 최신 도메인 목록을 가진 새 인증서를 발급하고 모든 도메인에 재배치해야합니다.
또한 SAN 인증서는 다음으로 만 발급 될 수 있습니다. OV (Organization Validated) 또는 EV (Extended Validated) if 모든 도메인은 동일한 조직에 속합니다. 이러한 검증 수준은 CA가 확인한 예상 인증서 소유자 정보의 양과 유형 그들에게 인증서를 발급하기 전에. 검증 수준이 높을수록 웹 사이트에 사용자가 더 많은 신뢰를 주며, 사용자 신뢰는 브랜드 인지도 및 전환율에 영향을 줄 수 있습니다.
마지막으로, 기업이 다른 비즈니스 또는 조직 (경쟁 업체와도)과 서버를 공유하는 것은 공유 웹 호스팅 환경에서 매우 일반적입니다. SAN 인증서의 도메인이 공개적으로 나열되어 있으므로 비즈니스 소유자는 동일한 인증서를 타사와 공유하기를 꺼려 할 수 있습니다.
SAN 인증서는 수많은 응용 프로그램을 포함하는 강력하고 다양한 도구이지만 이러한 문제로 인해 인터넷 표준을 관리하는 기관인 IETF가 가상으로 호스팅되는 HTTPS 웹 사이트의 특정 문제에 더 적합한 접근 방식을 찾도록 동기를 부여했습니다.
구조에 대한 서버 이름 표시
솔루션은 서버 이름 표시 (SNI) 확장 TLS 프로토콜 (암호화를 다루는 HTTPS 부분).
SNI를 사용하면 브라우저에서 브라우저가 연결하려는 도메인 이름을 지정할 수 있습니다. TLS 악수 (서버와의 초기 인증서 협상). 결과적으로 HTTPS 서버는 SNI 정보를 사용하여 연결을 설정하는 데 필요한 인증서 체인을 식별 할 수 있으므로 웹 사이트는 공유 IP 주소 및 포트에서 계속 호스트되는 동안 자체 SSL 인증서를 사용할 수 있습니다.
그 후, 암호화 된 통신 채널이 구성되면 브라우저는 웹 사이트의 도메인 이름을 Host
헤더를 클릭하고 평소처럼 계속합니다. 기본적으로 SNI는 HTTP와 동일한 기능을 수행합니다. Host
암호화 된 연결을 만드는 동안 헤더.
이 간단한 트릭을 통해 마침내 서버가 동일한 포트에서 여러 HTTPS 웹 사이트를 호스팅 할 수있었습니다. 그러나 대부분의 인터넷 기술과 마찬가지로 SNI에는 몇 가지 제한 사항이 있습니다.
SNI 지원 문제
SNI는 1999 년 초안이 처음 작성된 이후 상당히 성숙해졌지만이를 지원하지 않는 레거시 브라우저 (Windows XP의 IE)와 운영 체제 (Android 버전 <= 2.3)가 여전히 있습니다. SNI를 지원하는 브라우저 및 운영 체제의 전체 목록은 다음을 참조하십시오. 이 표.
최신 브라우저와 비교할 때 SNI를 지원하지 않는 브라우저 (및 이러한 상황이 발생하는 경우)의 시장 점유율은 미미하지만 브라우저가 SNI를 인식하지 않으면 기본 SSL 인증서로 돌아가 잠재적으로 일반적인 이름 불일치 오류.
Google과 같은 많은 회사는이를 지원하는 클라이언트를 위해 SNI를 구현하고 그렇지 않은 경우 SAN 인증서로 대체합니다. 당연히이 문제는 점점 더 많은 사용자와 비즈니스 소유자가 시스템을 최신 기술로 업그레이드함에 따라 줄어들 것으로 예상됩니다.
SNI 개인 정보 보호 문제
현재 안정 버전 TLS (버전 1.2)는 핸드 셰이크의 초기 부분과 확장 SNI 정보를 암호화되지 않은 상태로 전송합니다. 결과적으로 네트워크 공격자는 웹 통신 자체가 완전히 암호화 되었음에도 불구하고 사용자의 웹 기록을 발견 할 수 있습니다.
Amazon 또는 Google과 같은 다양한 클라우드 서비스 제공 업체는 다음과 같은 (더러운) 해결 방법을 허용했습니다. 도메인 경계. 도메인 프론 팅은 클라우드 공급자의 호스트 이름을 사용하여 SNI 정보를 난독 화하므로 웹 기록 공개를 방지 할 수 있습니다. TLS 협상 및 대상 사이트가 HTTP 헤더에 있습니다. 하지만이 방법은 더 이상 실행 가능하지 않습니다. Google과 Amazon이 공개적으로 도메인 전면 지원 비활성화 2018 년 XNUMX 월 현재 서비스에서.
다행히도보다 체계적인 솔루션이 제안되었습니다. 실험 초안 자세히 암호화 된 SNI (에스니) 최신 확장 TLS 버전, 1.3. ESNI는 SNI 정보를 암호화하여 모든 개인 정보 보호 문제를 완화합니다. 운수 나쁘게, TLS 1.3은 아직 업계에서 널리 채택되지 않았습니다. TLS 1.3은 사실상 사실상 네트워크 보안 프로토콜이되고있다. ESNI의 상태와 HTTPS 및 개인 정보 보호에 대한 향후 기사를 주시하십시오. TLS.
결론
요약하면 SNI를 사용하면 단일 서버에서 수백만 개의 HTTPS 웹 사이트를 호스팅 할 수 있습니다. 그러나 개별 사례에 따라 SAN 인증서가 더 효과적 일 수 있습니다. ESNI에 대한 잠재적 인 솔루션도 있지만 SNI에 대한 개인 정보 보호 문제는 여전히 존재합니다. 어쨌든 이러한 두 가지 방법 중 하나 또는 조합을 사용하면 최소한의 노력으로 모든 웹 사이트에 가상 호스팅을 쉽게 구현할 수 있습니다.
SNI에 대해 더 궁금한 점이 있거나 SAN과 SNI 중에서 선택하는 방법을 모르는 경우 항상 모든 고객의 질문에 기꺼이 답변 해드립니다. PKI 필요합니다. 우리에게 이메일을 드롭 support@ssl.com 전문가가 도와 드리겠습니다.