서버 네임 인디케이션 - 위키백과, 우리 모두의 백과사전 서버 네임 인디케이션 위키백과, 우리 모두의 백과사전. 둘러보기로 가기 검색하러 가기 서버 네임 인디케이션 ( Server Name Indication, SNI ) 은 컴퓨터 네트워크 프로토콜인 TLS의 확장으로, 핸드셰이킹 과정 초기에 클라이언트가 어느 호스트명에 접속하려는지 서버에 알리는 역할을 한다. [ 1 ] 이를 이용하면 같은 IP 주소와 TCP 포트 번호를 가진 서버로 여러 개의 인증서를 사용할 수 있게 되고, 따라서 모든 사이트가 같은 인증서를 사용하지 않아도 동일한 아이피로 여러 HTTPS 웹사이트 ( 또는 TLS 상에서 돌아가는 다른 서비스 ) 를 운영할 수 있게 된다. 개념상으로는 HTTP / 1. 1의 이름 기반의 가상 호스팅과 동일하지만 이 경우엔 HTTPS 통신에 쓰인다는 차이가 있다. 원본 SNI 확장의 경우 원하는 호스트명 정보가 암호화되어 있지 않기 때문에 [ 2 ] 사용자가 어느 사이트에 통신을 요청하는지 감청할 수 있다는 문제점이 있다. [ 3 ] 목차 1 배경지식 2 SNI를 이용한 해결책 3 보안 측면 4 구현 5 문재인 정부의 인터넷 검열 논란 6 지원 7 각주 8 외부 링크 배경지식 [ 편집 ] 클라이언트에서 TLS 연결을 생성하려면 먼저 웹
명을 먼저 알 수 있게 되므로 해당 호스트명에 맞는 인증서를 선택해 전송할 수 있게 된다. 따라서 클라이언트와 서버가 모두 SNI를 지원할 경우 인증서 하나에 넣기에는 너무 많았던 도메인 네임들을 IP 하나로 모두 사용할 수 있게 된다. SNI는 2003년 6월 IETF의 인터넷 RFC에 RFC 3546 Transport Layer Security ( TLS ) Extension이란 제목으로 처음 추가되었다. 해당 표준의 최신 버전은 RFC 6066이다. 보안 측면 [ 편집 ] 접속하려는 호스트명 정보가 암호화되지 않기 때문에 사용자가 어떤 사이트에 접속하는지 타인이 엿볼 수 있으며, 이를 이용해 보안 회사에서 필터링 기술을 개발하거나 [ 6 ] [ 7 ] [ 8 ] 한국 등의 정부에서 통신 검열에 활용하기도 한다. [ 9 ] 한때 대안으로 도메인 프론팅 방식을 사용했으나 [ 10 ] 현재 구글과 AWS 모두 이를 금지했으므로 대안으로서의 효용성은 감소하였다. [ 11 ] 2018년 중반 현재, 도메인 감청을 방지하기 위해 암호화 SNI ( Encrypted SNI, ESNI ) 라는 이름의 업그레이드가 " 실험적 단계 " 로서 진행되고 있다. [ 12 ] [ 13 ] 구현 [ 편집 ] 2004년 EdelKey 프로젝트에서 Op
서로 다른 인증서를 가지고 있을 필요가 있다. 2005년 이래로 CAcert에서는 가상 서버에서 TLS를 사용하기 위한 방책을 만들기 위해 여러 실험을 진행했으나 [ 4 ] 대부분 결과가 만족스럽지 못하거나 방법이 비현실적이어서 실패로 끝났다. 예를 들면 subjectAltName 필드를 이용해 개개인이 인증서 하나에 자신이 소유한 도메인 여러 개를 모두 넣을 수 있는데 [ 5 ], 이렇게 만든 " 통합 통신 인증서 ( unified communications certificates ) " 에 도메인을 새로 넣거나 빼려면 매번 인증서를 재발급받아야 한다. 이름 기반 가상 호스팅의 경우 아이피 하나를 통해 서버 ( 통상적으로 웹 서버 ) 하나에서 여러 DNS 호스트명을 사용할 수 있게 해 주는데, 이 경우 클라이언트에서 프로토콜의 일부로써 보낸 호스트명을 이용한다 ( HTTP의 경우 host 헤더에 호스트명을 적어 보낸다 ). 그러나 HTTPS 통신에서는 TLS 핸드셰이크 시점에서 아직 서버가 HTTP 헤더를 읽을 수 없기 때문에 서버가 HTTP host 헤더를 읽어 어떤 인증서를 보낼지 선택하는 작업이 불가능하게 되고, 따라서 한 아이피당 한 인증서만을 사용해 거기 포함된 호스트명만을 사용할 수 있다. 실질적으로 이는
예 2015 얼랭 라이브러리 예 2013 Go 라이브러리 예 2011 펄 라이브러리 예 2012 PHP 라이브러리 예 2014 파이썬 라이브러리 예 2011 ( 파이썬 3 ), 2014 ( 파이썬 2. x ) 루비 라이브러리 예 2011 각주 [ 편집 ] ↑ " Server Name Indication ". Transport Layer Security ( TLS ) Extensions. IETF. p. 8. sec. 3. 1. RFC 3546.. ↑ " TLS Server Name Indication ". 《 Paul's Journal 》. ↑ 임민철 ( 2018년 5월 6일 ). " " HTTPS 적용된 불법사이트도 접속차단 " ". 《 ZDNET Korea 》. 2018년 5월 18일에 확인함. ↑ " CAcert VHostTaskForce ". 《 CAcert Wiki 》. 2009년 8월 22일에 원본 문서에서 보존된 문서. ↑ GoDaddy. " What is a Multiple Domain ( UCC ) SSL Certificate ". ↑ " Web Filter : SNI extension feature and HTTPS blocking ". 2019년 2월 20일에 확인함. ↑ " Sophos UTM : Understanding Sophos Web F
헤더를 읽어 어떤 인증서를 보낼지 선택하는 작업이 불가능하게 되고, 따라서 한 아이피당 한 인증서만을 사용해 거기 포함된 호스트명만을 사용할 수 있다. 실질적으로 이는 안전하고 효율적인 브라우징을 위해 HTTPS 서버가 IP당 사용할 수 있는 도메인 수가 매우 한정되어 있다는 것을 뜻한다. 그렇다고 각 사이트마다 IP를 배당하자니, 새 IP를 요청하려면 대륙별 인터넷 레지스트리의 승인도 받아야 하고 IPv4 주소 자체도 거의 고갈된 상태기 때문에 결국 호스팅 비용을 배가시키는 꼴이 된다. 결과적으로 많은 웹사이트들이 사실상 IPv4를 통한 보안 통신을 할 수 없는 상태에 이른다. IPv6 주소는 고갈되지 않았으므로 IPv6을 이용한 웹사이트는 이 문제의 영향을 받지 않는다. SNI를 이용한 해결책 [ 편집 ] SNI를 이용하면 TLS 핸드셰이크 과정에서 현재 접속하려는 가상 도메인의 호스트명을 서버로 전송해 이 문제를 해결할 수 있다. 이렇게 하면 서버에서 가상 도메인 호스트명을 먼저 알 수 있게 되므로 해당 호스트명에 맞는 인증서를 선택해 전송할 수 있게 된다. 따라서 클라이언트와 서버가 모두 SNI를 지원할 경우 인증서 하나에 넣기에는 너무 많았던 도메인 네임
] 목차 1 배경지식 2 SNI를 이용한 해결책 3 보안 측면 4 구현 5 문재인 정부의 인터넷 검열 논란 6 지원 7 각주 8 외부 링크 배경지식 [ 편집 ] 클라이언트에서 TLS 연결을 생성하려면 먼저 웹 서버로 디지털 인증서를 요청하게 된다. 서버가 인증서를 보내면 클라이언트는 이를 읽고 연결하려던 호스트명과 인증서에 적힌 이름이 일치하는지 확인한다. 일치하는 경우 정상적으로 연결 절차가 진행되나, 일치하지 않는 경우 누군가 중간자 공격을 시도하고 있다는 조짐이므로 경고문이 나타나거나 또는 연결이 중단된다. 그러나 일부 애플리케이션의 경우 경고를 무시하고 사용자가 연결을 강제 진행할 수 있도록 하기도 하는데, 해당 인증서 또는 연결을 신뢰할 수 있는 경우에만 진행해야 하며 결과에 대한 책임은 사용자가 지게 된다. 그러나 인증서 하나에 모든 호스트명을 다 구겨넣으려면 사전에 호스트명을 모두 알고 있어야 하는데 이는 때때로 어렵거나 또는 불가능한 일이다. 이 때문에 호스트명이 여러 개인 서버는 각각의 호스트명에 대응하는 ( 또는 몇몇 호스트명에 동시에 대응하는 ) 서로 다른 인증서를 가지고 있을 필요가 있다. 2005년 이래로 CAcert에서는 가상 서버에서 TLS를 사용하기 위한 방책을 만들기 위해 여러 실험을 진행했으나 [ 4 ] 대부분 결과가 만족
RFC 3546 ) vdehTLS와 SSL프로토콜과 기술 전송 계층 보안 / 보안 소켓 계층 ( TLS / SSL ) 데이터그램 전송 계층 보안 ( DTLS ) ( 영문판 ) 서버 네임 인디케이션 ( SNI ) Application - Layer Protocol Negotiation ( ALPN ) ( 영문판 ) DNS - based Authentication of Named Entities ( DANE ) ( 영문판 ) DNS Certification Authority Authorization ( CAA ) ( 영문판 ) HTTPS HTTP Strict Transport Security ( HSTS ) ( 영문판 ) HTTP Public Key Pinning ( HPKP ) ( 영문판 ) OCSP stapling ( 영문판 ) 완전 순방향 비밀성 ( 영문판 ) STARTTLS ( 영문판 ) 공개키 인프라 Automated Certificate Management Environment ( ACME ) ( 영문판 ) 인증 기관 ( CA ) CA / 브라우저 포럼 ( 영문판 ) 인증서 정책 ( 영문판 ) 인증서 폐기 목록 ( CRL ) Domain - validated certificate ( DV ) ( 영문판 ) Extended Validation Certificate ( EV ) ( 영문판 ) 온라인 인증서 상태 프로토콜 ( OCS
ter : SNI extension feature and HTTPS blocking ". 2019년 2월 20일에 확인함. ↑ " Sophos UTM : Understanding Sophos Web Filtering " ( 영어 ). 2019년 2월 20일에 확인함. ↑ Chrisment, Isabelle ; Goichot, Antoine ; Cholez, Thibault ; Shbair, Wazen M. ( 2015년 5월 11일 ). " Efficiently Bypassing SNI - based HTTPS Filtering " ( 영어 ) : 990 - 995. doi : 10. 1109 / INM. 2015. 7140423. ↑ " South Korea is Censoring the Internet by Snooping on SNI Traffic " ( 영어 ). 2019년 2월 20일에 확인함. ↑ Conditt, Jessica ( 2016년 12월 21일 ). " Encrypted chat app Signal circumvents government censorship ". 《 Engadget 》. 2019년 2월 13일에 확인함. ↑ Signal. " Amazon threatens to suspend Signal's AWS account
hip ". 《 Engadget 》. 2019년 2월 13일에 확인함. ↑ Signal. " Amazon threatens to suspend Signal's AWS account over censorship circumvention ". 2019년 2월 13일에 확인함. ↑ " ESNI : A Privacy - Protecting Upgrade to HTTPS ". 《 EFF DeepLinks Blog 》. ↑ Claburn, Thomas ( 2018년 7월 17일 ). " Don't panic about domain fronting, an SNI fix is getting hacked out ". 《 The Register 》. 2019년 2월 13일에 확인함. ↑ " EdelKey Project ". 2019년 2월 20일에 확인함. ↑ OpenSSL. " Changelog ". 2019년 2월 13일에 원본 문서에서 보존된 문서. 외부 링크 [ 편집 ] RFC 6066 ( obsoletes RFC 4366, which obsoleted RFC 3546 ) vdehTLS와 SSL프로토콜과 기술 전송 계층 보안 / 보안 소켓 계층 ( TLS / SSL ) 데이터그램 전송 계층 보안 ( DTLS ) ( 영문판 ) 서버 네임
Domain - validated certificate ( DV ) ( 영문판 ) Extended Validation Certificate ( EV ) ( 영문판 ) 온라인 인증서 상태 프로토콜 ( OCSP ) 공인인증서 공개 키 암호 방식 공개 키 기반 구조 ( PKI ) 루트 인증서 Self - signed certificate ( 영문판 ) 같이 보기 DNSSEC IPsec 시큐어 셸 ( SSH ) 역사 미국에서의 암호 기법 수출 규제 ( 영문판 ) 서버 게이트형 암호 기법 ( 영문판 ) 구현체 Bouncy Castle ( 영문판 ) BoringSSL ( 영문판 ) Botan cryptlib GnuTLS ( 영문판 ) JSSE ( 영문판 ) LibreSSL MatrixSSL ( 영문판 ) mbed TLS ( 영문판 ) NSS ( 영문판 ) OpenSSL RSA BSAFE ( 영문판 ) S2n ( 영문판 ) SChannel ( 영문판 ) SSLeay ( 영문판 ) stunnel ( 영문판 ) wolfSSL ( 영문판 ) 공증 인증서 투명성 ( 영문판 ) Convergence ( 영문판 ) HTTPS 에브리웨어 ( 영문판 ) Perspectives Project ( 영문판 ) 취약점이론
서버 네임 인디케이션(Server Name Indication, SNI)은 컴퓨터 네트워크 프로토콜인 TLS의 확장으로, 핸드셰이킹 과정 초기에 클라이언트가 어느 호스트명에 접속하려는지 서버에 알리는 역할을 한다. 이를 이용하면 같은 IP 주소와 TCP 포트 번호를 가진 서버로 여러 개의 인증서를 사용할 수 있게 되고, 따라서 모든 사이트가 같은 인증서를 사용하지 않아도 동일한 아이피로 여러 HTTPS 웹사이트(또는 TLS 상에서 돌아가는 다른 서비스)를 운영할 수 있게 된다. 개념상으로는 HTTP/1.1의 이름 기반의 가상 호스팅과 동일하지만 이 경우엔 HTTPS 통신에 쓰인다는 차이가 있다. 원본 SNI 확장의 경우 원하는 호스트명 정보가 암호화되어 있지 않기 때문에 사용자가 어느 사이트에 통신을 요청하는지 감청할 수 있다는 문제점이 있다.