맨위로가기

HTTPS

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

HTTPS는 넷스케이프 커뮤니케이션스가 개발한 웹 브라우저용 보안 프로토콜로, HTTP를 TLS/SSL 암호화 계층을 통해 보호한다. HTTPS는 안전한 채널을 생성하여 엿보기와 중간자 공격으로부터 보호하며, 웹 서버의 인증을 통해 보안을 강화한다. 웹 브라우저는 HTTPS 웹사이트의 보안 상태에 따라 동작을 변경하며, 서버는 공개 키 인증서를 통해 HTTPS 연결을 설정한다. HTTPS는 통신 암호화, 변조 방지, SEO 이점 등의 장점을 가지지만, 도입 비용, 혼합 콘텐츠 문제, 브라우저 호환성 등의 단점도 존재한다.

더 읽어볼만한 페이지

  • URI 스킴 - 텔넷
    텔넷은 1973년에 정의된 7비트 ASCII 문자 세트를 사용하는 네트워크 프로토콜로, 클라이언트-서버 방식으로 작동하며 TCP 포트 23 또는 2323을 사용하며, 보안 취약성으로 인해 SSH로 대체되고 있다.
  • URI 스킴 - HTTP 리퍼러
    HTTP 리퍼러는 웹 페이지 방문 시 링크를 따라온 이전 페이지 URL을 나타내는 HTTP 요청 헤더 필드로서, 웹사이트는 이를 통해 유입 경로를 분석하고 추적에 활용하지만 개인 정보 보호 문제와 철자 오류가 존재한다.
  • HTTP - HTTP 쿠키
    HTTP 쿠키는 웹 서버가 사용자 브라우저에 저장하는 작은 텍스트 파일로, 웹 사이트가 방문 기록, 로그인 정보 등을 기억하여 HTTP의 상태 비저장성을 보완하고 세션 관리, 개인 설정, 사용자 추적 등에 활용되지만 개인 정보 보호 및 보안 문제에 대한 논란이 있다.
  • HTTP - 웹 캐시
    웹 캐시는 웹 서버와 클라이언트 사이에서 웹 요청 응답을 저장하고 재사용하여 웹 페이지 로딩 속도를 개선하는 기술로, HTTP 프로토콜을 통해 제어되며, 디지털 밀레니엄 저작권법과 한국의 인터넷 환경에서 중요한 역할을 한다.
  • 암호 프로토콜 - IPsec
    IPsec은 IP 네트워크에서 보안 통신을 제공하기 위한 프로토콜 스위트로서, 전송 모드와 터널 모드를 지원하며, AH, ESP 등의 프로토콜을 사용하여 데이터 무결성, 인증, 기밀성을 제공하고, IKE 프로토콜을 통해 보안 연결을 설정 및 키를 교환하는 개방형 표준이다.
  • 암호 프로토콜 - 전송 계층 보안
    전송 계층 보안(TLS)은 클라이언트-서버 간 통신에서 도청, 간섭, 위조를 막기 위해 설계된 암호화 프로토콜이며, 종단 간 인증, 통신 기밀성을 제공하고, 다양한 프로토콜에 적용되어 HTTPS를 보호하는 데 주로 사용된다.
HTTPS
개요
유형통신 프로토콜
하위 유형응용 계층 프로토콜
기반HTTP
보안전송 계층 보안 (TLS) 또는 보안 소켓 레이어 (SSL)
포트443
상세 정보
설명HTTP 통신 프로토콜의 확장, TLS 암호화 지원
개발인터넷 기술 특별위원회(IETF)
RFCRFC 2818
사용웹사이트 보안 강화
기타
특징웹 서버와 브라우저 간의 통신 암호화
데이터 무결성 보장
사용자 인증
중요성개인 정보 보호
금융 거래 보안
웹 사이트 신뢰도 향상
필요성개인 정보 보호법, 정보통신망 이용촉진 및 정보보호 등에 관한 법률 등 관련 법규 준수

2. 역사

넷스케이프 커뮤니케이션스가 1994년 넷스케이프 내비게이터 웹 브라우저를 위해 HTTPS를 개발했다.[80] 원래 HTTPS는 보안 소켓 계층(SSL) 프로토콜과 함께 사용되었다. SSL이 전송 계층 보안(TLS)으로 발전했을 때 2000년 5월 HTTPS는 공식적으로 RFC 2818에 규정되었다.

3. 작동 원리

HTTPS 스키마와 WWW 도메인 이름 레이블로 시작하는 URL


HTTPS는 넷스케이프 커뮤니케이션스가 1994년에 넷스케이프 내비게이터 웹 브라우저를 위해 개발하였다.[80] HTTPS는 ''HTTPS'' URI 스키마를 사용하며, HTTP 스키마와 동일한 구문을 갖는다. 하지만 HTTPS는 브라우저에 트래픽 보호를 위해 전송 계층 보안(TLS) 또는 보안 소켓 계층(SSL) 암호화 계층을 사용하도록 신호를 보낸다. SSL/TLS는 통신의 한쪽만 인증되더라도 어느 정도의 보호를 제공하며, 일반적으로 웹 서버만 인증된다.

HTTPS는 안전하지 않은 네트워크를 통해 안전한 채널을 생성한다. 적절한 암호화 모음 사용 및 서버 인증서 확인 및 신뢰가 전제된다면, 엿보는 자와 중간자 공격으로부터 합리적인 보호를 보장한다.

HTTPS는 TLS 위에 HTTP를 덧붙여 HTTP 프로토콜 전체를 암호화한다. (요청 URL, 쿼리 매개변수, 헤더, 쿠키 등) 웹사이트 주소와 포트 번호는 TCP/IP 프로토콜의 필수적인 부분이므로 HTTPS는 이러한 정보의 공개를 막을 수 없다. 엿보는 자는 웹 서버의 IP 주소와 포트 번호, 때로는 도메인 이름, 전송된 데이터의 양과 통신 시간을 추론할 수 있지만, 통신 내용은 추론할 수 없다.[4]

HTTPS는 표준 HTTP와 달리, SSL/TLS 또는 QUIC과 같은 프로토콜을 사용하여 서버 인증, 통신 내용 암호화, 무결성 검증 등을 수행한다. 이를 통해 스푸핑, 중간자 공격, 도청 등의 공격을 방지할 수 있으며, 웰노운 포트 번호로 443이 사용된다.

HTTPS에 의한 보안 강도는 웹 서버 및 브라우저에서 사용되는 SSL/TLS 구현의 정확성과 사용하는 암호 알고리즘에 의존한다(TLS 참조).

프록시 서버를 통해 인터넷에 액세스하는 경우, HTTPS의 SSL/TLS 통신 시 프록시 서버를 터널링해야 할 필요가 있는 경우가 있는데, 이때 '''CONNECT 메서드'''를 사용한다.

HTTPS의 장점은 다음과 같다.

  • 통신 암호화를 통해 변조나 도청과 같은 공격을 방지할 수 있다. 통신 최적화도 변조의 일종이므로, 마찬가지로 방지할 수 있다.
  • HTTP/2나 HTTP/3 지원으로 브라우저 표시 속도가 빨라진다.
  • SEO에 유리하다. 검색 엔진 최대 기업인 구글이 HTTPS 도입을 추진하여 자사 검색 서비스에서 HTTPS를 사용하는 웹사이트를 우대한다고 발표했기 때문이다.[56][57]


HTTPS URI 스키마의 URL을 대상으로 하는 통신에 사용되는 프로토콜은 다음과 같다.

  • HTTP Over TLS: HTTP/1.0, HTTP/1.1, HTTP/2 중 하나를 TLS 연결 상에서 사용한다.
  • HTTP/3: HTTP/3은 하위 계층으로 QUIC을 사용하는 프로토콜이며, QUIC에 의해 암호화 통신이 이루어진다.


HTTPS의 사양이 처음으로 표준화된 것은 HTTP Over TLS이다. TLS 상에서의 HTTP 통신에 대해 호스트 이름 검증(인증서의 주제 대체 이름(subjectAltName) 또는 일반 이름(Common Name)이 연결 중인 URL의 호스트 이름 또는 IP 주소와 일치하는지 여부 판단) 및 https URI 스키마 등의 규정이 명문화되었다. 이후 HTTP 본체에 통합되었고[61], 각 HTTP 버전에도 다음과 같이 규정이 이전되었다.

  • TLS 연결 상에서의 HTTP/1.1 통신은 HTTP/1.1에 규정되어 있다(9.7. TLS 연결 시작, 9.8. TLS 연결 종료).
  • TLS 연결 상에서의 HTTP/2 통신은 HTTP/2에 규정되어 있다(3.2. "https" URI에 대한 HTTP/2 시작).


그 외 HTTPS와 관련된 사양은 다음과 같다.

  • X.509(PKIX)에서는 인증서에 대한 요구 사항이 규정되어 있다. 특히 HTTPS에 고유한 것으로는 다음이 있다(4.2.1.12. 확장 키 용도).
  • 서버 인증서를 나타내는 확장 키 용도: TLS WWW 서버 인증(OID 1.3.6.1.5.5.7.3.1).
  • 클라이언트 인증서를 나타내는 확장 키 용도: TLS WWW 클라이언트 인증(OID 1.3.6.1.5.5.7.3.2).
  • 응용 계층 프로토콜 협상을 사용하는 경우, 프로토콜 ID로 http/1.1, h2, h3을 사용한다.
  • HTTP/2에서는 TLS에 대한 추가 요구 사항을 부과하고 있다.
  • TLS 1.2 미만 사용 금지 및 TLS 1.2~1.3에 대한 요구 사항


웹 브라우저에서 공개적으로 신뢰할 수 있는 인증서를 발급하는 인증 기관에 대한 요구 사항으로, CA/Browser Forum이 Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates를 정하고 있다.[63]

3. 1. 웹 브라우저의 HTTPS 웹사이트 신뢰 방법

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

"이상적인 세계에서는 모든 웹 요청이 HTTPS로 기본 설정될 수 있다"고 언급한 전자 프런티어 재단은 모질라 파이어폭스, 구글 크롬, 크로미엄 및 안드로이드용 HTTPS Everywhere라는 추가 기능을 제공하여 수백 개의 자주 사용되는 웹사이트에 대해 HTTPS를 기본적으로 사용하도록 한다.[19][20]

웹 브라우저가 HTTPS 콘텐츠만 로드하도록 강제하는 기능은 파이어폭스 버전 83부터 지원되었다.[21] 구글 크롬은 버전 94부터 브라우저 설정에서 토글하면 "항상 안전한 연결 사용"이 가능하다.[22][23]

3. 2. HTTPS의 중요성

HTTPS는 안전하지 않은 네트워크와 조작될 수 있는 네트워크에서 특히 중요하다. 공용 Wi-Fi 액세스 포인트와 같은 안전하지 않은 네트워크에서는 동일한 로컬 네트워크의 모든 사용자가 패킷 스니핑을 통해 HTTPS로 보호되지 않는 중요한 정보를 발견할 수 있다. 또한 일부 무료 및 유료 WLAN 네트워크는 다른 웹사이트에 자체 광고를 게재하기 위해 패킷 삽입에 참여하여 웹페이지를 조작하는 것으로 관찰되었는데, 이는 웹페이지에 악성 코드를 삽입하고 사용자의 개인 정보를 훔치는 등 여러 가지 악의적인 방식으로 악용될 수 있다.[7]

HTTPS는 Tor 네트워크를 통한 연결에도 중요하다. 그렇지 않으면 악의적인 Tor 노드가 안전하지 않은 방식으로 통과하는 내용을 손상시키거나 변경하고 연결에 악성 코드를 삽입할 수 있기 때문이다. 이는 전자 프런티어 재단과 토 프로젝트가 HTTPS Everywhere의 개발을 시작한 이유 중 하나이며,[4] Tor Browser에 포함되어 있다.[8]

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

HTTPS를 배포하면 페이지 로드 시간, 크기 및 대기 시간을 줄이도록 설계된 새로운 HTTP 버전인 HTTP/2 및 HTTP/3(및 이전 버전인 SPDY 및 QUIC)를 사용할 수 있다.

특히 SSL 스트리핑과 같은 중간자 공격으로부터 사용자를 보호하기 위해 HTTPS와 함께 HTTP Strict Transport Security(HSTS)를 사용하는 것이 좋다.[13][14]

4. 서버 설정

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

4. 1. 인증서 획득

여러 인증 기관이 다양한 유형의 유료 SSL/TLS 인증서(Extended Validation Certificate 포함)를 제공한다.

렛츠 인크립트(Let's Encrypt)[27]는 2016년 4월에 출시된 무료 자동화 서비스로, 웹사이트에 기본 SSL/TLS 인증서를 제공한다.[28] 전자프런티어재단(Electronic Frontier Foundation)에 따르면, 렛츠 인크립트는 HTTP에서 HTTPS로의 전환을 "명령어 하나를 입력하거나 버튼 하나를 클릭하는 것만큼 쉽게" 만들 것이라고 한다.[29] 대부분의 웹 호스트 및 클라우드 제공업체는 현재 렛츠 인크립트를 활용하여 고객에게 무료 인증서를 제공하고 있다.

4. 2. 클라이언트 인증을 통한 접근 제어

시스템은 웹 서버에 대한 접근을 승인된 사용자로 제한하기 위해 클라이언트 인증에도 사용될 수 있다. 이를 위해 사이트 관리자는 일반적으로 각 사용자에 대한 인증서를 생성하며, 사용자는 이 인증서를 자신의 브라우저에 로드한다. 일반적으로 인증서에는 승인된 사용자의 이름과 이메일 주소가 포함되며, 사용자의 신원을 확인하기 위해 서버에서 각 연결 시 자동으로 확인되므로 암호가 필요 없을 수도 있다.[64]

4. 3. 비밀 (개인) 키 손상 시

완벽 순방향 보안(PFS)은 중요한 속성이다. HTTPS 세션을 설정하는 데 사용되는 장기 비대칭 비밀 키 중 하나를 소유하더라도, 나중에 대화를 해독하기 위한 단기 세션 키를 쉽게 유도할 수 없다. 디피-헬먼 키 교환(DHE) 및 타원 곡선 디피-헬먼 키 교환(ECDHE)은 이러한 속성을 갖는 것으로 알려져 있다.[26] 2013년 당시 Firefox, Opera 및 Chromium 브라우저 세션의 30%만이 이를 사용했으며, 애플 사파리와 마이크로소프트 인터넷 익스플로러 세션의 경우 거의 0%였다.[26] 2018년 8월에 발표된 TLS 1.3은 순방향 보안이 없는 암호에 대한 지원을 중단했다. 2019년 2월 기준으로 조사된 웹 서버의 96.6%가 어떤 형태의 순방향 보안을 지원하며, 52.1%는 대부분의 브라우저에서 순방향 보안을 사용한다.[30] 2023년 7월 기준으로 조사된 웹 서버의 99.6%가 어떤 형태의 순방향 보안을 지원하며, 75.2%는 대부분의 브라우저에서 순방향 보안을 사용한다.[31]

5. 브라우저 통합

대부분의 웹 브라우저는 잘못된 인증서를 받으면 경고를 표시한다. 예전 브라우저는 잘못된 인증서를 가진 사이트에 연결할 때 사용자에게 계속할지 묻는 대화 상자를 표시했다. 최신 브라우저는 전체 창에 경고를 표시한다. 또한 최신 브라우저는 주소 표시줄에 사이트의 보안 정보를 눈에 띄게 표시한다. 확장 검증 인증서는 인증서 정보에 법인을 표시한다. 대부분의 브라우저는 암호화된 콘텐츠와 암호화되지 않은 콘텐츠가 혼합된 사이트를 방문할 때도 사용자에게 경고를 표시한다.

"이상적인 세계에서는 모든 웹 요청이 HTTPS로 기본 설정될 수 있다"고 언급한 전자 프런티어 재단은 모질라 파이어폭스, 구글 크롬, 크로미엄 및 안드로이드용 HTTPS Everywhere라는 추가 기능을 제공하여 수백 개의 자주 사용되는 웹사이트에 대해 HTTPS를 기본적으로 사용하도록 한다.[19][20]

웹 브라우저가 HTTPS 콘텐츠만 로드하도록 강제하는 기능은 파이어폭스 버전 83부터 지원되었다.[21] 구글 크롬은 버전 94부터 브라우저 설정에서 토글하면 "항상 안전한 연결 사용"이 가능하다.[22][23]

6. 보안

HTTPS의 보안은 기반이 되는 TLS의 보안과 같다. TLS는 일반적으로 장기적인 공개 키와 개인 키를 사용하여 단기적인 세션 키를 생성하며, 이 키는 클라이언트와 서버 간의 데이터 흐름을 암호화하는 데 사용된다. X.509 인증서는 서버(그리고 때때로 클라이언트도)를 인증하는 데 사용된다. 결과적으로, 인증 기관과 공개 키 인증서는 인증서와 소유자 간의 관계를 확인하고 인증서의 유효성을 생성, 서명 및 관리하는 데 필요하다. 이는 신뢰의 웹을 통해 신원을 확인하는 것보다 더 유익할 수 있지만, 2013년 대규모 감시 정보 공개는 인증 기관을 중간자 공격을 허용하는 잠재적인 취약점으로 주목하게 만들었다.[24][25] 이러한 맥락에서 중요한 속성은 포워드 시크릿이며, 이는 장기적인 비밀 키 또는 암호가 향후 손상될 경우 과거에 기록된 암호화된 통신을 검색하고 해독할 수 없도록 보장한다. 모든 웹 서버가 포워드 시크릿을 제공하는 것은 아니다.[26]

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

7. 한계

SSL/TLS 암호화는 '단순' 모드와 '상호' 모드의 두 가지 모드로 구성될 수 있다. 단순 모드에서는 서버만 인증을 수행하고, 상호 모드에서는 사용자 인증을 위해 사용자가 웹 브라우저에 개인 클라이언트 인증서를 설치해야 한다.[38]

SSL/TLS는 웹 크롤러에 의한 사이트 색인 생성을 방지하지 않는다. 어떤 경우에는 가로채인 요청/응답 크기만 알아도 암호화된 리소스의 URI를 추론할 수 있다.[39] 이를 통해 공격자는 평문(공개적으로 사용 가능한 정적 콘텐츠)과 암호화된 텍스트(정적 콘텐츠의 암호화된 버전)에 액세스할 수 있어 암호화 공격이 가능해진다.

TLS는 HTTP보다 낮은 프로토콜 수준에서 작동하며 상위 프로토콜에 대한 지식이 없다. 따라서 TLS 서버는 특정 주소와 포트 조합에 대해 하나의 인증서만 엄격하게 제시할 수 있다.[40] 과거에는 이로 인해 HTTPS에서 네임 기반 가상 호스팅을 사용하는 것이 실현 가능하지 않았다. 서버 이름 표시(SNI)라는 솔루션이 있지만, 이전 브라우저는 이 확장 기능을 지원하지 않는다. SNI 지원은 파이어폭스 2, 오페라 8, 애플 사파리 2.1, 구글 크롬 6 및 윈도우 비스타의 인터넷 익스플로러 7부터 제공된다.[41][42][43]

2009년 블랙햇 컨퍼런스에서 SSL 스트리핑이라는 정교한 유형의 메신저 공격이 발표되었다. 이러한 유형의 공격은 HTTPS 링크를 HTTP 링크로 변경하여 HTTPS에서 제공하는 보안을 무력화한다. 많은 인터넷 사용자가 브라우저 인터페이스에 "https"를 실제로 입력하지 않는다는 점을 이용하며, 사용자는 링크를 클릭하여 안전한 사이트에 접근하므로 실제로 HTTP를 사용하고 있지만 HTTPS를 사용하고 있다고 생각하게 된다. 그런 다음 공격자는 클라이언트와 명확하게 통신한다.[44] 이는 HTTP에서 HTTP Strict Transport Security라는 대응책 개발을 촉진했다.

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

구글, 야후!, 아마존을 포함한 대부분의 최신 웹사이트에서 HTTPS를 사용한다는 사실은 많은 사용자가 공용 Wi-Fi 핫스팟에 액세스하려고 할 때 문제를 일으킨다. 사용자가 HTTPS 리소스를 열려고 하면 캡티브 포털 Wi-Fi 핫스팟 로그인 페이지가 로드되지 않기 때문이다.[46] NeverSSL[47]과 같은 여러 웹사이트는 항상 HTTP를 통해 액세스할 수 있도록 보장한다.[48]

8. 통계

2018년 4월 기준, 알렉사 상위 1,000,000개 웹사이트 중 33.2%가 HTTPS를 기본으로 사용했으며, 파이어폭스 텔레메트리 측정 결과 페이지 로드의 70%가 HTTPS를 사용했다.[15][16] 2022년 12월 기준, 인터넷에서 가장 인기 있는 135,422개 웹사이트 중 58.4%가 HTTPS의 안전한 구현을 갖추고 있다.[17] 2016년부터 2017년에 걸쳐 HTTPS 점유율이 50%를 넘었다는 여러 조사 결과가 발표되었고,[66][67] 2018년 말, httparchive.org의 조사에 따르면 79.9%의 트래픽이라는 조사 보고가 있었다.[69][70][71]

9. 대한민국에서의 HTTPS 사용과 검열 논란

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

10. 유사 프로토콜

RFC 2660에서 정의하는 '''안전한 하이퍼텍스트 전송 프로토콜(S-HTTP)'''는 HTTPS 스키마에서 사용되는 HTTP over SSL/TLS와는 다른 프로토콜이다.[1] S-HTTP에 대응하는 URI 스키마는 shttp이다.[1] RFC 2817은 HTTP의 Upgrade 헤더를 사용하여 HTTP와 같은 TCP 80번 포트에서 HTTP over TLS 통신을 수행하는 방식을 규정한다.[1] RFC 8164는 http URL에 대한 통신에서 기회주의적 암호화를 제공한다.[1]

11. 통신 사양

HTTPS URI 스키마의 URL을 대상으로 하는 통신에 사용되는 프로토콜은 다음과 같다. HTTPS의 사양이 처음으로 표준화된 것은 RFC 2818 HTTP Over TLS이다. X.509(PKIX)에서는 인증서에 대한 요구 사항이 규정되어 있다. 응용 계층 프로토콜 협상을 사용하는 경우, 프로토콜 ID로 http/1.1, h2, h3을 사용한다. HTTP/2에서는 TLS에 대한 추가 요구 사항을 부과하고 있다. CA/Browser Forum은 공개적으로 신뢰할 수 있는 인증서를 발급하는 인증 기관에 대한 요구 사항을 정하고 있다.[63]

12. HTTPS 통신 절차

클라이언트가 HTTPS 서버에 TCP 연결을 수행하고, TLS 핸드셰이크를 시작한다. 또는 HTTP/3의 경우 QUIC를 이용한 TLS 핸드셰이크를 시작한다.


  • (선택) 이때, ALPN을 사용하여 프로토콜 협상을 수행한다. HTTP/1.1 또는 h2, h3을 사용한다.
  • TLS 핸드셰이크 중에 서버가 제시한 인증서 내용을 바탕으로, 클라이언트는 호스트 이름 검증을 수행한다. 이는 4.3.4. https Certificate Verification에 규정되어 있다.
  • 이후는 TLS 연결 상의 애플리케이션 데이터로 HTTP 통신을 수행한다. 또는 HTTP/3의 경우 QUIC 스트림으로 HTTP 통신을 수행한다.
  • HTTP 버전은 ALPN에서 결정된 것을 사용한다.
  • TLS에서 ALPN을 사용하지 않는 경우, HTTP/1.1 또는 HTTP/1.0을 사용한다.

13. 정보 보호에 대한 오해

HTTPS는 애플리케이션 계층의 HTTP를 보호하는 프로토콜로, 웹브라우저와 웹서버 간 통신을 암호화하여 도청 및 변조를 방지한다. 하지만, IPsec과 같이 네트워크 계층 자체를 보호하는 것은 아니다.[64]

HTTPS를 통해 정보를 받은 사이트는 최소한의 데이터만 안전하게 보관해야 하지만, 중요한 개인 정보가 사이트의 데이터베이스에 저장되지 않는다는 보장은 없다. 데이터베이스는 외부 공격의 표적이 되거나, 정보가 부당하게 유용 또는 유출될 수 있다.[64]

이처럼 통신이 완벽하게 보호되더라도 사용자가 기대하는 안전이 확보되지 않는 경우가 있다. 오늘날 인터넷에서는 피싱이 HTTPS를 통해 이루어지는 경우가 많다.[65]

14. 장단점

HTTPS는 HTTP에 SSL/TLS 암호화 계층을 추가하여 보안을 강화한 프로토콜이다. HTTPS를 사용하면 장점과 단점이 존재한다.

'''장점'''으로는, HTTPS는 안전하지 않은 네트워크에서도 안전한 채널을 생성하여 엿듣기나 중간자 공격과 같은 위협으로부터 통신을 보호한다.[4] HTTP/2, HTTP/3와 같은 새로운 HTTP 버전을 사용하여 페이지 로딩 속도를 높일 수 있다. 또한, 구글과 같은 검색 엔진에서 HTTPS를 사용하는 웹사이트를 우선적으로 노출시키기 때문에 SEO에도 유리하다.[56][57]

'''단점'''으로는, 암호화 및 복호화 과정으로 인해 클라이언트와 서버에 부하가 증가할 수 있지만, HTTP/2를 함께 사용하여 이러한 부하를 상쇄할 수 있다.[4] 유료 SSL 인증서 구매 및 정기적인 갱신에 비용이 발생할 수 있다. HTTPS를 지원하지 않는 일부 콘텐츠는 표시되지 않을 수 있으며, 오래된 웹 브라우저에서는 HTTPS 웹사이트를 열람하지 못할 수 있다.

14. 1. 장점

HTTPS는 안전하지 않은 네트워크를 통해 안전한 채널을 만들어, 적절한 암호화 모음이 사용되고 서버 인증서가 확인되고 신뢰할 수 있는 경우 엿보는 자와 중간자 공격으로부터 합리적인 보호를 보장한다.[4]

HTTPS는 TLS 위에 HTTP를 덧붙여서 기본 HTTP 프로토콜 전체를 암호화할 수 있다. 여기에는 요청의 URL, 쿼리 매개변수, 헤더 및 쿠키(사용자에 대한 식별 정보가 종종 포함됨)가 포함된다. 그러나 웹사이트 주소와 포트 번호는 기본 TCP/IP 프로토콜의 필수적인 부분이므로 HTTPS는 이러한 정보의 공개를 보호할 수 없다. 엿보는 자는 웹 서버의 IP 주소와 포트 번호, 때로는 사용자가 통신하는 도메인 이름과 전송된 데이터의 양과 통신 시간을 추론할 수 있지만, 통신 내용은 추론할 수 없다.[4]

웹 브라우저는 소프트웨어에 미리 설치된 인증 기관을 기반으로 HTTPS 웹사이트를 신뢰한다. 사용자는 다음 조건이 모두 충족되는 경우에만 웹사이트에 대한 HTTPS 연결을 신뢰해야 한다.

  • 사용자는 브라우저와 브라우저 자체를 얻는 방법을 호스팅하는 자신의 기기가 손상되지 않았다고 신뢰한다.
  • 사용자는 브라우저 소프트웨어가 올바르게 미리 설치된 인증 기관을 사용하여 HTTPS를 올바르게 구현한다고 신뢰한다.
  • 사용자는 인증 기관이 합법적인 웹사이트만 보증한다고 신뢰한다.
  • 웹사이트는 신뢰할 수 있는 기관에서 서명한 유효한 인증서를 제공한다.
  • 인증서는 웹사이트를 올바르게 식별한다.
  • 사용자는 프로토콜의 암호화 계층(SSL/TLS)이 엿보는 자에 대해 충분히 안전하다고 신뢰한다.


HTTPS는 안전하지 않은 네트워크와 조작될 수 있는 네트워크에서 특히 중요하다. 공용 Wi-Fi 액세스 포인트와 같은 안전하지 않은 네트워크에서는 동일한 로컬 네트워크의 모든 사용자가 패킷 스니핑을 통해 HTTPS로 보호되지 않는 중요한 정보를 발견할 수 있다. 또한 일부 무료 및 유료 WLAN 네트워크는 다른 웹사이트에 자체 광고를 게재하기 위해 패킷 삽입에 참여하여 웹페이지를 조작하는 것으로 관찰되었으며, 이는 악성 코드를 삽입하고 사용자의 개인 정보를 훔치는 등 악의적인 방식으로 악용될 수 있다.[7]

HTTPS는 Tor 네트워크를 통한 연결에도 중요하다. 악의적인 Tor 노드가 안전하지 않은 방식으로 통과하는 내용을 손상시키거나 변경하고 연결에 악성 코드를 삽입할 수 있기 때문이다.[4]

전 세계적인 대규모 감시와 범죄자의 개인 정보 절도에 대한 정보가 더 많이 공개됨에 따라 모든 웹사이트에서 HTTPS 보안을 사용하는 것이 점점 더 중요해지고 있다.[9][10]

HTTPS를 배포하면 페이지 로드 시간, 크기 및 대기 시간을 줄이도록 설계된 새로운 HTTP 버전인 HTTP/2 및 HTTP/3를 사용할 수 있다.

특히 SSL 스트리핑과 같은 중간자 공격으로부터 사용자를 보호하기 위해 HTTPS와 함께 HTTP Strict Transport Security(HSTS)를 사용하는 것이 좋다.[13][14]

HTTPS의 장점을 요약하면 다음과 같다.

  • 통신이 암호화되므로, 변조나 도청과 같은 공격을 방지할 수 있다. 통신 최적화도 변조의 일종이므로, 마찬가지로 방지할 수 있다.
  • HTTP/2나 HTTP/3 지원으로 브라우저 표시 속도가 빨라진다.
  • SEO에 유리하다. 검색 엔진 최대 기업인 구글이 HTTPS 도입을 추진하여 자사 검색 서비스에서 HTTPS를 사용하는 웹사이트를 우대한다고 발표했다.[56][57]

14. 2. 단점

HTTPS는 암호화 및 복호화 과정이 필요하므로 클라이언트와 서버 모두에 부하를 증가시킨다. 다만, HTTP/2를 함께 사용하면 이러한 부하를 속도 향상으로 상쇄할 수 있는 경우도 있다.[4] 또한, 오래된 웹 브라우저에서는 HTTPS를 사용하는 웹사이트를 열람하지 못할 수 있다.

HTTPS를 이용하기 위해서는 SSL 인증서가 필요한데, 무료 발급 서비스를 제외하면 도입에 비용이 발생한다. SSL 인증서는 정기적으로 (90일/1년 등) 갱신해야 한다.[4]

HTTPS를 지원하지 않는 도구, 광고, 블로그 파츠 등은 혼합 콘텐츠로 간주되어 표시되지 않는다.

참조

[1] 웹사이트 Secure your site with HTTPS https://support.goog[...] Google Inc. 2018-10-20
[2] 웹사이트 What is HTTPS? https://www.instants[...] Comodo CA Limited 2018-10-20
[3] 간행물 HTTP Semantics IETF 2022-06-01
[4] 웹사이트 HTTPS Everywhere FAQ https://www.eff.org/[...] 2018-10-20
[5] 웹사이트 Usage Statistics of Default protocol https for Websites, July 2019 https://w3techs.com/[...] 2019-07-20
[6] 웹사이트 Encrypting the Web https://www.eff.org/[...] 2019-11-19
[7] 웹사이트 Hotel Wifi JavaScript Injection https://justinsomnia[...] 2018-10-20
[8] 웹사이트 What is Tor Browser? https://www.torproje[...] 2012-05-30
[9] 웹사이트 Embracing HTTPS https://open.blogs.n[...] 2018-10-20
[10] 웹사이트 Fifteen Months After the NSA Revelations, Why Aren't More News Organizations Using HTTPS? https://freedom.pres[...] Freedom of the Press Foundation 2018-10-20
[11] 웹사이트 HTTPS as a ranking signal https://webmasters.g[...] Google Inc. 2018-10-20
[12] 웹사이트 Google I/O 2014 - HTTPS Everywhere https://www.youtube.[...] Google Developers 2018-10-20
[13] 웹사이트 How to Deploy HTTPS Correctly https://www.eff.org/[...] 2018-10-20
[14] 웹사이트 HTTP Strict Transport Security https://developer.mo[...] 2018-10-20
[15] 웹사이트 HTTPS usage statistics on top 1M websites https://statoperator[...] 2018-10-20
[16] 웹사이트 Let's Encrypt Stats https://letsencrypt.[...] 2018-10-20
[17] 웹사이트 Qualys SSL Labs - SSL Pulse https://www.ssllabs.[...] 2022-12-07
[18] 웹사이트 TLS 1.3: Slow adoption of stronger web encryption is empowering the bad guys https://www.helpnets[...] 2022-05-23
[19] 웹사이트 Encrypt the Web with the HTTPS Everywhere Firefox Extension https://www.eff.org/[...] 2018-10-20
[20] 웹사이트 HTTPS Everywhere. https://www.eff.org/[...] 2018-10-20
[21] 웹사이트 HTTPS-Only Mode in Firefox https://support.mozi[...] 2021-11-12
[22] 웹사이트 Manage Chrome safety and security - Android - Google Chrome Help https://support.goog[...] 2022-03-07
[23] 웹사이트 Hands on Chrome's HTTPS-First Mode https://techdows.com[...] 2022-03-07
[24] 잡지 Law Enforcement Appliance Subverts SSL https://www.wired.co[...] 2018-10-20
[25] 웹사이트 New Research Suggests That Governments May Fake SSL Certificates https://www.eff.org/[...] 2018-10-20
[26] 웹사이트 SSL: Intercepted today, decrypted tomorrow https://news.netcraf[...] 2018-10-20
[27] 웹사이트 Let's Encrypt Launched Today, Currently Protects 3.8 Million Domains https://news.softped[...] Softpedia News 2018-10-20
[28] 웹사이트 Let's Encrypt Effort Aims to Improve Internet Security https://www.eweek.co[...] Quinstreet Enterprise 2018-10-20
[29] 웹사이트 Launching in 2015: A Certificate Authority to Encrypt the Entire Web https://www.eff.org/[...] Electronic Frontier Foundation 2018-10-20
[30] 웹사이트 SSL Pulse https://www.ssllabs.[...] 2019-02-25
[31] 웹사이트 Qualys SSL Labs - SSL Pulse https://www.ssllabs.[...] 2023-09-04
[32] 웹사이트 Mozilla Firefox Privacy Policy https://www.mozilla.[...] Mozilla Foundation 2018-10-20
[33] 뉴스 Opera 8 launched on FTP https://news.softped[...] Softpedia 2018-10-20
[34] 웹사이트 HTTPS Security Improvements in Internet Explorer 7 https://docs.microso[...] 2021-10-24
[35] 웹사이트 Online Certificate Status Protocol – OCSP https://tools.ietf.o[...] Internet Engineering Task Force 2018-10-20
[36] 웹사이트 Baseline Requirements https://cabforum.org[...] CAB Forum 2021-11-01
[37] 논문 Revocation Statuses on the Internet 2021-03-30
[38] 웹사이트 Manage client certificates on Chrome devices – Chrome for business and education Help https://support.goog[...] 2018-10-20
[39] 웹사이트 The Pirate Bay un-SSL https://www.exploit-[...] 2018-10-20
[40] 웹사이트 SSL/TLS Strong Encryption: FAQ https://httpd.apache[...] 2018-10-20
[41] 웹사이트 Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2 https://blogs.msdn.m[...] Microsoft 2018-10-20
[42] 웹사이트 Server Name Indication (SNI) https://blog.ebrahim[...] 2018-10-20
[43] 웹사이트 Browser support for TLS server name indication https://bugzilla.moz[...] Mozilla Foundation 2018-10-20
[44] 웹사이트 sslstrip 0.9 https://moxie.org/so[...] 2018-10-20
[45] 논문 Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow https://www.microsof[...] IEEE Symposium on Security & Privacy 2010 2018-10-20
[46] 웹사이트 How to Force a Public Wi-Fi Network Login Page to Open https://zapier.com/b[...] 2018-10-20
[47] 웹사이트 NeverSSL http://neverssl.com
[48] 웹사이트 NeverSSL http://neverssl.com/ 2018-10-20
[49] 서적 Embedded Software: The Works https://books.google[...] Newnes 2018-10-20
[50] 웹사이트 A secure web is here to stay https://blog.chromiu[...] 2019-04-22
[51] 웹사이트 Webサイトに“常時SSL”の実装を――団体提唱の米国で機運高まる？ https://www.itmedia.[...] 2019-09-21
[52] 웹사이트 HTTP接続は「安全でない」と明示すべし――Googleが提案 - ITmedia エンタープライズ https://www.itmedia.[...] 2016-11-26
[53] 웹사이트 【翻訳】安全でない HTTP の廃止 - Mozilla Security Blog 日本語版 https://mozsec-jp.ha[...] 2016-11-26
[54] 웹사이트 Securing the Web https://www.w3.org/2[...] W3C 2016-11-26
[55] 웹사이트 今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景 https://employment.e[...] 2019-09-21
[56] 웹사이트 WebサイトのHTTPS対応、Google検索ランキングに反映 https://www.itmedia.[...] 2019-09-21
[57] 웹사이트 HTTPS をランキング シグナルに使用します https://webmaster-ja[...]
[58] 웹사이트 安全なコンテキスト - ウェブセキュリティ https://developer.mo[...] 2020-05-09
[59] 웹사이트 混在コンテンツ - Security https://developer.mo[...] 2020-05-09
[60] 웹사이트 混合コンテンツとは https://web.dev/arti[...] 2020-05-09
[61] 웹사이트 Bring RFC2818 into semantics · Issue #236 · httpwg/http-core https://github.com/h[...] 2022-07-03
[62] 웹사이트 Transport Layer Security (TLS) Extensions, TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs https://www.iana.org[...]
[63] 웹사이트 About the Baseline Requirements https://cabforum.org[...] 2021-02-12
[64] 웹사이트 欧米セキュリティ事情の新潮流 SSLでは不十分、クラウド時代の暗号化 https://xtech.nikkei[...] 2019-09-28
[65] 웹사이트 HTTPSが安全とは限らない {{!}} カスペルスキー公式ブログ https://blog.kaspers[...] 2022-09-29
[66] 웹사이트 Google、Chromeで半数以上がHTTPSを利用と発表 https://news.mynavi.[...] 2017-03-16
[67] 웹사이트 HTTPS、トラフィックの50%を突破 https://news.mynavi.[...] 2017-03-16
[68] 트윗
[69] 웹사이트 https://httparchive.[...]
[70] 웹사이트 https://letsencrypt.[...]
[71] 웹사이트 https://web.archive.[...]
[72] 웹사이트 中国大陸でネット検閲の中，HTTPSでGmailなどを安全に使えるのかどうか https://computer-tec[...] モバイル通信とIT技術をコツコツ勉強するブログ 2017-02-16
[73] 웹사이트 ロシアでWikipediaが禁止サイトのリストに加えられ閲覧不能に、原因は一体何だったのか？ https://gigazine.net[...] GIGAZINE 2017-02-16
[74] 웹사이트 韓国がアダルトサイトのブロックに使う技術、SNIの正体 https://xtech.nikkei[...] 日経クロステック（xTECH） 2020-07-19
[75] 웹인용 HTTP Over TLS https://tools.ietf.o[...] The Internet Engineering Task Force 2015-02-27
[76] 웹인용 HTTPS as a ranking signal https://googlewebmas[...] Google Inc. 2015-02-27
[77] 웹인용 Enabling HTTP Over SSL https://docs.adobe.c[...] Adobe Systems Incorporated 2015-02-27
[78] 웹인용 Secure your site with HTTPS https://support.goog[...] Google, Inc. 2015-02-27
[79] 웹인용 What is HTTPS? https://www.instants[...] Comodo CA Limited 2015-02-27
[80] 서적 Embedded software https://books.google[...] Newnes
[81] 웹인용 한글 인터넷 통계 koresight.com https://www.koresigh[...] 2017-03-01
[82] 뉴스 방통위, 해외 불법사이트 접속 전면 차단…감청·검열 논란 https://www.joongang[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com