HTTPS

**하이퍼텍스트 전송 프로토콜 보안**(Hypertext Transfer Protocol Secure, **HTTPS**)은 하이퍼텍스트 전송 프로토콜 (HTTP)의 확장이다. 이는 컴퓨터 망을 통해 안전한 통신을 위해 암호화를 사용하며, 인터넷에서 널리 사용된다. HTTPS에서 통신 프로토콜은 전송 계층 보안 (TLS) 또는 이전에 사용되던 SSL(Secure Sockets Layer)을 사용하여 암호화된다. 따라서 이 프로토콜은 **HTTP over TLS** 또는 **HTTP over SSL**이라고도 불린다.

HTTPS의 주요 동기는 액세스하는 웹사이트의 인증과 전송 중인 교환 데이터의 정보 프라이버시 및 데이터 무결성 보호이다. 이는 중간자 공격으로부터 보호하며, 클라이언트와 서버 간 통신의 양방향 블록 암호 운용 방식 암호화는 감청 및 변조로부터 통신을 보호한다. HTTPS의 인증 측면은 신뢰할 수 있는 제3자가 서버 측 디지털 인증서에 서명하도록 요구한다. 이는 역사적으로 비용이 많이 드는 작업이었으며, 따라서 완전히 인증된 HTTPS 연결은 일반적으로 월드 와이드 웹의 안전한 결제 거래 서비스 및 기타 안전한 기업 정보 시스템에서만 발견되었다. 2016년, 전자 프런티어 재단이 웹 브라우저 개발자들의 지원을 받아 시작한 캠페인으로 인해 이 프로토콜은 더욱 널리 보급되었다. HTTPS는 2018년부터 보안되지 않은 HTTP보다 웹 사용자들에게 더 자주 사용되어 왔는데, 주로 모든 유형의 웹사이트에서 페이지의 진정성을 보호하고, 계정을 안전하게 유지하며, 사용자 통신, 신원 및 웹 브라우징의 프라이버시를 보호하기 위함이다.

## 개요

[섬네일|HTTPS 스킴과 [월드 와이드 웹|WWW 도메인 이름 레이블로 시작하는 URL]]

통합 자원 식별자 (URI) 스킴 HTTPS는 HTTP 스킴과 동일한 사용 구문을 가진다. 그러나 HTTPS는 트래픽 보호를 위해 SSL/TLS의 추가 암호화 계층을 사용하도록 브라우저에 신호를 보낸다. SSL/TLS는 HTTP에 특히 적합한데, 통신 한쪽만 인증되어도 어느 정도 보호를 제공할 수 있기 때문이다. 이는 인터넷을 통한 HTTP 트랜잭션의 경우에 해당하며, 일반적으로 웹 서버만 인증된다 (클라이언트가 서버의 인증서를 검사하여).

HTTPS는 안전하지 않은 네트워크를 통해 안전한 채널을 생성한다. 이는 적절한 암호화 스위트가 사용되고 서버 인증서가 검증되고 신뢰되는 경우, 감청자 및 중간자 공격으로부터 합리적인 보호를 보장한다.

HTTPS는 HTTP를 TLS 위에 완전히 얹혀 사용하므로, 기본 HTTP 프로토콜 전체를 암호화할 수 있다. 여기에는 요청의 URL, 쿼리 매개변수, 헤더, 그리고 종종 사용자에 대한 식별 정보를 포함하는 쿠키가 포함된다. 그러나 웹사이트 주소와 포트 번호는 기본 TCP/IP 프로토콜의 필수적인 부분이므로, HTTPS는 이들의 공개를 보호할 수 없다. 실제로는 올바르게 구성된 웹 서버에서도 감청자는 웹 서버의 IP 주소와 포트 번호, 그리고 때로는 사용자가 통신하는 도메인 이름(예: www.example.org, 하지만 URL의 나머지는 아님)까지 추론할 수 있으며, 통신 내용은 알 수 없지만 전송된 데이터 양과 통신 지속 시간은 알 수 있다.

웹 브라우저는 소프트웨어에 사전 설치된 인증 기관을 기반으로 HTTPS 웹사이트를 신뢰하는 방법을 알고 있다. 인증 기관은 이러한 방식으로 웹 브라우저 제작자에게 유효한 인증서를 제공하도록 신뢰받는다. 따라서 사용자는 다음 모든 조건이 참인 경우에만 웹사이트에 대한 HTTPS 연결을 신뢰해야 한다.

* 사용자는 브라우저를 호스팅하는 장치와 브라우저 자체를 얻는 방법이 손상되지 않았다고 신뢰한다 (즉, 공급망 공격이 없다).
* 사용자는 브라우저 소프트웨어가 올바르게 사전 설치된 인증 기관과 함께 HTTPS를 올바르게 구현했다고 신뢰한다.
* 사용자는 인증 기관이 합법적인 웹사이트만 보증한다고 신뢰한다 (즉, 인증 기관이 손상되지 않았고 인증서의 오발행이 없다).
* 웹사이트는 유효한 인증서를 제공하며, 이는 신뢰할 수 있는 기관이 서명했음을 의미한다.
* 인증서는 웹사이트를 올바르게 식별한다 (예: 브라우저가 "https://example.com"을 방문할 때 수신된 인증서가 "example.com"에 대한 것이고 다른 엔티티에 대한 것이 아니다).
* 사용자는 프로토콜의 암호화 계층(SSL/TLS)이 감청자에 대해 충분히 안전하다고 신뢰한다.

HTTPS는 안전하지 않은 네트워크와 변조에 취약할 수 있는 네트워크에서 특히 중요하다. 공용 와이파이 액세스 포인트와 같은 안전하지 않은 네트워크는 동일한 로컬 네트워크의 누구든지 패킷 스니핑을 통해 HTTPS로 보호되지 않는 민감한 정보를 발견할 수 있도록 허용한다. 또한, 일부 무료 및 유료 무선랜 네트워크는 다른 웹사이트에 광고를 제공하기 위해 패킷 주입을 통해 웹페이지를 변조하는 것이 관찰되었다. 이러한 관행은 악성 소프트웨어를 웹페이지에 주입하고 사용자의 개인 정보를 훔치는 등 여러 가지 방식으로 악용될 수 있다.

HTTPS는 토르 네트워크를 통한 연결에서도 중요하다. 악성 토르 노드가 보안되지 않은 방식으로 통과하는 내용을 손상시키거나 변경하고 연결에 악성 소프트웨어를 주입할 수 있기 때문이다. 이것이 전자 프런티어 재단과 토르 프로젝트가 HTTPS 에브리웨어 개발을 시작한 이유 중 하나이며, 이는 토르 브라우저에 포함되어 있다.

글로벌 대중감시와 범죄자들의 개인 정보 절도에 대한 정보가 더 많이 공개됨에 따라, 사용되는 인터넷 연결 유형에 관계없이 모든 웹사이트에서 HTTPS 보안 사용이 점점 더 중요해지고 있다. 사용자가 방문하는 개별 페이지에 대한 메타데이터가 민감하지 않다고 간주될 수 있지만, 집계되면 사용자에 대해 많은 것을 드러내고 사용자의 프라이버시를 침해할 수 있다.

HTTPS를 배포하면 HTTP/2 및 HTTP/3 (그리고 그 전신인 SPDY 및 QUIC)를 사용할 수도 있으며, 이는 페이지 로드 시간, 크기 및 지연 시간을 줄이기 위해 설계된 새로운 HTTP 버전이다.

중간자 공격, 특히 SSL 스트리핑으로부터 사용자를 보호하기 위해 HTTPS와 함께 HTTP 스트릭트 트랜스포트 시큐리티 (HSTS)를 사용하는 것이 권장된다.

HTTPS는 RFC 2660에 명시된 거의 사용되지 않는 보안 하이퍼텍스트 전송 프로토콜 (S-HTTP)과 구별된다.

### 웹사이트에서의 사용
 기준으로 알렉사 상위 1,000,000개 웹사이트 중 33.2%가 HTTPS를 기본으로 사용하며 페이지 로드의 70% (Firefox Telemetry 기준)가 HTTPS를 사용한다.  기준으로 인터넷에서 가장 인기 있는 135,422개 웹사이트 중 58.4%가 HTTPS의 보안 구현을 사용하고 있다. 그러나 2018년에 TLS 1.3이 출시되었음에도 불구하고 채택률은 더딘 편이며, 여전히 많은 웹사이트가 이전 버전인 TLS 1.2 프로토콜을 사용하고 있다.

### 브라우저 통합

대부분의 웹 브라우저는 유효하지 않은 인증서를 받으면 경고를 표시한다. 이전 브라우저는 유효하지 않은 인증서를 가진 사이트에 연결할 때 사용자에게 계속할 것인지 묻는 대화 상자를 표시했다. 최신 브라우저는 전체 창에 걸쳐 경고를 표시한다. 최신 브라우저는 또한 주소창에 사이트의 보안 정보를 눈에 띄게 표시한다. 확장 유효성 검사 인증서는 인증서 정보에 법인명을 보여준다. 대부분의 브라우저는 암호화된 콘텐츠와 암호화되지 않은 콘텐츠가 혼합된 사이트를 방문할 때 사용자에게 경고를 표시하기도 한다. 또한, 많은 웹 필터는 금지된 웹사이트를 방문할 때 보안 경고를 반환한다.

전자 프런티어 재단은 "이상적인 세상에서는 모든 웹 요청이 HTTPS로 기본 설정될 수 있다"고 의견을 표명하며 모질라 파이어폭스, 구글 크롬, 크로미엄, 그리고 안드로이드용 HTTPS 에브리웨어라는 추가 기능을 제공해 수백 개의 자주 사용되는 웹사이트에 대해 HTTPS를 기본으로 활성화하고 있다.

버전 83부터 파이어폭스에서는 웹 브라우저가 HTTPS 콘텐츠만 로드하도록 강제하는 기능이 지원된다. 버전 94부터 구글 크롬은 브라우저 설정에서 전환할 경우 "항상 보안 연결 사용"이 가능하다.

## 보안

HTTPS의 보안은 기본이 되는 TLS의 보안에 달려 있는데, TLS는 일반적으로 장기 공개 및 개인 키를 사용하여 단기 세션 키를 생성하고, 이 키는 클라이언트와 서버 간의 데이터 흐름을 암호화하는 데 사용된다. X.509 인증서는 서버(때로는 클라이언트도)를 인증하는 데 사용된다. 결과적으로 인증 기관과 공개 키 인증서는 인증서와 그 소유자 간의 관계를 확인하고, 인증서의 유효성을 생성, 서명 및 관리하는 데 필요하다. 이는 웹 오브 트러스트를 통해 신원을 확인하는 것보다 더 유용할 수 있지만, 2013년 대중감시 폭로는 인증 기관이 중간자 공격을 허용하는 잠재적인 약점이라는 점에 주목하게 했다. 이 맥락에서 중요한 속성은 전방향 보안으로, 과거에 기록된 암호화된 통신이 미래에 장기 비밀 키나 암호가 손상될 경우에도 검색 및 해독되지 않도록 보장한다. 모든 웹 서버가 전방향 보안을 제공하는 것은 아니다.

HTTPS가 효과적이려면 사이트 전체가 HTTPS를 통해 호스팅되어야 한다. 만약 사이트의 일부 콘텐츠가 HTTP(예: 스크립트 또는 이미지)를 통해 로드되거나, 로그인 페이지와 같이 민감한 정보가 포함된 특정 페이지만 HTTPS를 통해 로드되고 나머지 사이트는 일반 HTTP를 통해 로드된다면, 사용자는 공격과 감시에 취약해진다. 또한, HTTPS를 통해 제공되는 사이트의 쿠키는 보안 속성이 활성화되어 있어야 한다. 민감한 정보가 있는 사이트에서 사용자와 세션은 HTTPS 대신 HTTP로 해당 사이트에 액세스할 때마다 노출된다.

## 기술적 특징

### HTTP와의 차이점
HTTPS URL은 "https://"로 시작하고 기본적으로 포트 443을 사용하는 반면, HTTP URL은 "http://"로 시작하고 기본적으로 포트 80을 사용한다.

HTTP는 암호화되지 않으므로 중간자 공격 및 감청 공격에 취약하여 공격자가 웹사이트 계정 및 민감한 정보에 접근하고 웹페이지를 수정하여 악성 소프트웨어 또는 광고를 주입할 수 있다. HTTPS는 이러한 공격에 저항하도록 설계되었으며 이러한 공격으로부터 안전하다고 간주된다 (SSL의 사용 중단된 버전을 사용하는 HTTPS 구현은 예외).

### 네트워크 계층
HTTP는 TCP/IP 모델의 가장 높은 계층인 응용 계층에서 작동하며, TLS 보안 프로토콜(동일 계층의 하위 계층으로 작동)도 마찬가지이다. TLS는 전송 전에 HTTP 메시지를 암호화하고 도착 시 메시지를 해독한다. 엄밀히 말하면 HTTPS는 별도의 프로토콜이 아니라 암호화된 SSL/TLS 연결을 통한 일반 HTTP 사용을 의미한다.

HTTPS는 HTTP 헤더 및 요청/응답 데이터를 포함한 모든 메시지 내용을 암호화한다. 아래 제한 사항 섹션에 설명된 가능한 CCA 암호화 공격을 제외하고, 공격자는 기껏해야 두 당사자 간에 연결이 이루어지고 있다는 사실과 도메인 이름 및 IP 주소만 알아낼 수 있어야 한다.

### 서버 설정
웹 서버가 HTTPS 연결을 수락하도록 준비하려면 관리자는 웹 서버용 공개 키 인증서를 생성해야 한다. 이 인증서는 웹 브라우저가 경고 없이 수락하도록 신뢰할 수 있는 인증 기관에 의해 서명되어야 한다. 이 기관은 인증서 소유자가 해당 인증서를 제시하는 웹 서버의 운영자임을 증명한다. 웹 브라우저는 일반적으로 주요 인증 기관의 서명 인증서 목록과 함께 배포되므로, 이들이 서명한 인증서를 확인할 수 있다.

#### 인증서 획득
여러 상업 인증 기관이 존재하며, 확장 유효성 검사 인증서를 포함한 여러 유형의 유료 SSL/TLS 인증서를 제공한다.

2016년 4월에 출시된 Let's Encrypt는 웹사이트에 기본 SSL/TLS 인증서를 제공하는 무료 자동화 서비스를 제공한다. 전자 프런티어 재단에 따르면 Let's Encrypt는 HTTP에서 HTTPS로의 전환을 "단일 명령 실행 또는 버튼 클릭만큼 쉽게" 만들 것이다. 대다수의 웹 호스트와 클라우드 제공업체는 이제 Let's Encrypt를 활용하여 고객에게 무료 인증서를 제공한다.

#### 액세스 제어로서의 사용
이 시스템은 인증을 통해 웹 서버에 대한 액세스를 승인된 사용자로 제한하는 데 사용될 수도 있다. 이를 위해 사이트 관리자는 일반적으로 각 사용자에게 인증서를 생성하며, 사용자는 이 인증서를 자신의 브라우저에 로드한다. 일반적으로 인증서에는 승인된 사용자의 이름과 이메일 주소가 포함되어 있으며, 서버는 각 연결에서 사용자 신원을 확인하기 위해 자동으로 확인하며, 잠재적으로 암호도 필요하지 않다.

#### 손상된 비밀(개인) 키의 경우
이 맥락에서 중요한 속성은 완벽 전방향 보안 (PFS)이다. HTTPS 세션을 설정하는 데 사용되는 장기 비대칭 비밀 키 중 하나를 소유하더라도, 나중에라도 단기 세션 키를 도출하여 대화를 해독하는 것을 더 쉽게 만들어서는 안 된다. 2013년 기준으로 디피-헬먼 키 교환 (DHE)과 타원곡선 디피-헬먼 키 교환 (ECDHE)만이 이 속성을 가진 것으로 알려진 유일한 스킴이다. 2013년에는 파이어폭스, 오페라, 크로미엄 브라우저 세션의 30%만이 이를 사용했으며, 애플의 사파리와 마이크로소프트 인터넷 익스플로러 세션은 거의 0%였다. 2018년 8월에 발표된 TLS 1.3은 전방향 보안이 없는 암호에 대한 지원을 중단했다.  기준으로 조사된 웹 서버의 96.6%가 특정 형태의 전방향 보안을 지원하며, 52.1%는 대부분의 브라우저와 함께 전방향 보안을 사용할 것이다.  기준으로 조사된 웹 서버의 99.6%가 특정 형태의 전방향 보안을 지원하며, 75.2%는 대부분의 브라우저와 함께 전방향 보안을 사용할 것이다.

##### 인증서 폐기

인증서는 만료되기 전에, 예를 들어 개인 키의 비밀이 손상되었기 때문에 폐기될 수 있다. 파이어폭스, 오페라, 윈도우 비스타의 인터넷 익스플로러와 같은 인기 브라우저의 최신 버전은 온라인 인증서 상태 프로토콜 (OCSP)을 구현하여 이러한 경우가 발생하지 않았는지 확인한다. 브라우저는 OCSP (온라인 인증서 상태 프로토콜)를 통해 인증서의 일련 번호를 인증 기관 또는 그 대리인에게 보내고, 기관은 인증서가 여전히 유효한지 여부를 브라우저에 알려준다. CA는 또한 이러한 인증서가 폐기되었음을 알리기 위해 CRL을 발행할 수도 있다. CRL은 더 이상 CA/브라우저 포럼에서 필수로 요구되지 않지만, 그럼에도 불구하고 CA에서 여전히 널리 사용된다. 인터넷상의 대부분의 폐기 상태는 인증서 만료 후 곧 사라진다.

### 제한 사항
SSL(Secure Sockets Layer) 및 TLS(Transport Layer Security) 암호화는 단순 모드와 상호 모드의 두 가지 모드로 구성할 수 있다. 단순 모드에서는 서버에서만 인증이 수행된다. 상호 모드에서는 사용자 인증을 위해 웹 브라우저에 개인 클라이언트 인증서를 설치해야 한다. 두 경우 모두 보호 수준은 소프트웨어의 구현 및 사용 중인 암호화 알고리즘의 정확성에 따라 달라진다.

SSL/TLS는 웹 크롤러에 의한 사이트 색인 생성을 방지하지 않으며, 경우에 따라서는 암호화된 자원의 URI가 가로챈 요청/응답 크기만으로도 추론될 수 있다. 이는 공격자가 평문 (공개적으로 사용 가능한 정적 콘텐츠) 및 암호문 (정적 콘텐츠의 암호화된 버전)에 액세스하여 암호화 공격을 가능하게 한다.

TLS는 HTTP보다 낮은 프로토콜 계층에서 작동하고 상위 계층 프로토콜을 알지 못하므로, TLS 서버는 특정 주소 및 포트 조합에 대해 하나의 인증서만 엄격하게 제시할 수 있다. 과거에는 이로 인해 HTTPS에서 이름 기반 가상 호스팅을 사용하는 것이 불가능했다. 서버 네임 인디케이션 (SNI)이라는 해결책이 존재하는데, 이는 연결을 암호화하기 전에 호스트 이름을 서버로 보내는 방식이지만, 구형 브라우저는 이 확장을 지원하지 않는다. SNI 지원은 파이어폭스 2, 오페라 8, 애플 사파리 2.1, 구글 크롬 6, 그리고 윈도우 비스타의 인터넷 익스플로러 7부터 제공된다.

2009년 블랙햇 브리핑에서 SSL 스트리핑이라는 정교한 유형의 중간자 공격이 발표되었다. 이 유형의 공격은  링크를  링크로 변경함으로써 HTTPS가 제공하는 보안을 무력화시킨다. 이는 소수의 인터넷 사용자만이 브라우저 인터페이스에 "https"를 직접 입력한다는 사실을 악용하며, 사용자는 링크를 클릭하여 보안 사이트에 접속하므로 사실은 HTTP를 사용하고 있음에도 HTTPS를 사용한다고 착각하게 만든다. 그러면 공격자는 클라이언트와 평문으로 통신하게 된다. 이로 인해 HTTP에 HTTP 스트릭트 트랜스포트 시큐리티라는 대응책이 개발되었다.

HTTPS는 다양한 트래픽 분석 공격에 취약한 것으로 나타났다. 트래픽 분석 공격은 트래픽의 타이밍과 크기 변화에 의존하여 암호화된 트래픽 자체에 대한 속성을 추론하는 부채널 공격의 한 유형이다. 트래픽 분석이 가능한 이유는 SSL/TLS 암호화가 트래픽 내용을 변경하지만, 트래픽의 크기와 타이밍에는 최소한의 영향을 미치기 때문이다. 2010년 5월, 마이크로소프트 리서치와 인디애나 대학교 연구원들의 연구 논문은 패킷 크기와 같은 부채널로부터 상세한 민감한 사용자 데이터를 추론할 수 있음을 발견했다. 연구원들은 의료, 세금, 투자, 웹 검색 분야의 여러 유명하고 최고 수준의 웹 애플리케이션에서 HTTPS 보호에도 불구하고, 감청자가 사용자의 질병/약물/수술, 가족 소득 및 투자 비밀을 추론할 수 있음을 밝혀냈다.

구글, 야후, 아마존을 포함한 대부분의 현대 웹사이트가 HTTPS를 사용한다는 사실은 많은 사용자들이 공용 와이파이 핫스팟에 접속하려 할 때 문제를 야기한다. 사용자가 HTTPS 자원을 열려고 하면 캡티브 포털 와이파이 핫스팟 로그인 페이지가 로드되지 않기 때문이다. NeverSSL과 같은 일부 웹사이트는 항상 HTTP로 액세스 가능하도록 보장한다.

## 역사

넷스케이프 커뮤니케이션즈는 1994년 자사의 넷스케이프 내비게이터 웹 브라우저를 위해 HTTPS를 개발했다. 원래 HTTPS는 SSL 프로토콜과 함께 사용되었다. 오리지널 SSL 프로토콜은 넷스케이프 커뮤니케이션즈의 수석 과학자 타헤르 엘가말이 개발했다. SSL이 전송 계층 보안 (TLS)으로 발전함에 따라, HTTPS는 2000년 5월 RFC 2818에 의해 공식적으로 명시되었다. 구글은 2018년 2월, 2018년 7월 이후로 크롬 브라우저가 HTTP 사이트를 "안전하지 않음"으로 표시할 것이라고 발표했다. 이러한 움직임은 월드 와이드 웹을 더욱 안전하게 만들기 위한 노력의 일환으로 웹사이트 소유자가 HTTPS를 구현하도록 장려하기 위함이었다.

## 통계

### 대한민국
2017년 3월 기준으로, HTTPS는 한국 전체 등록 도메인 중 3.06%가 사용하고 있다.

2019년 2월, 방송통신위원회는 대한민국 정부와 협력하여 불건전한 내용과 저작권 침해를 원천 차단하겠다는 명목으로 HTTPS를 통한 해외 사이트 접속을 막는 인터넷 검열 방안을 발표 및 실시하였다. 이 방식은 암호화의 인증 과정에서 주고받게 되는 SNI 패킷을 보고 웹사이트 접속을 차단하는 방식으로, 본래 방송통신심의위원회에서는 해당 위원회에서 지정한 '유해 사이트'에 국민들이 접속하지 못하도록 URL 접근을 특수한 사이트로 강제 우회시키고 있었는데, HTTPS를 통한 접속이 많아지면서 실용성이 없어지자 이같은 방안을 따르도록 국내 통신사들에 명령하였다.HTTPS는 암호화된 패킷을 전송한다는 점에서 우수한 보안성을 자랑해 HTTPS 내용을 읽고 차단하기 위해선 암호화되기 전 내용을 읽어 차단해야되며, 이런 원리를 이해해 도메인 네임 서버 우회 방식을 이용해 계속 사용하는 경우가 생겨났다. 하지만 일반 사용자는 이용하기에 어려움이 있어 VPN을 사용했지만, 최근엔 유니콘HTTPS 우회 프로그램 등이 출시되면서 국가 IP 주소 변경, 개인 접속 기록을 남기지 않는 경우가 아니라면 어플만으로 손쉽게 우회가 가능해졌다.

## 같이 보기
* 컴퓨터 보안

## 각주

## 외부 링크

* HTTP over TLS(RFC 2818)에 대한 기술 명세서

분류:HTTP
분류:암호 프로토콜
분류:전송 계층 보안
분류:URI 스킴
분류:1994년 개설된 인터넷 자산