목차
위의 목차를 클릭하면 해당 글로 자동 이동 합니다.
HTTP의 등장 배경
HTTP를 알기 위해서는, 처음 웹이 만들어졌을 때로 돌아가보아야 합니다. 웹은 1989년에 팀 버너스 리 (Tim Bernrs-Lee)가 제안한 정보 공유 시스템으로, 인터넷을 기반으로하여 전 세계 사람들이 쉽게 정보를 공유하기 위한 목적으로 만들어졌습니다.
팀 버너스 리가 1980년대 유럽 입자 물리 연구소(CERN)에서 일하면서 수많은 연구자들이 각기 다른 시스템에 데이터를 저장하고 있어 정보의 접근성과 연결성이 낮다는 불편함을 겪게 됩니다. 연구자들이 서로의 연구 데이터를 쉽게 공유하여 원활한 협력이 이루어질 수 있도록 하기 위해 모든 정보를 하나의 네트워크에서 연결할 수 있는 시스템의 필요성을 느낍니다. 초기의 웹은 이러한 불편함을 해소하고자 탄생합니다.
초기의 웹은 HTTP 프로토콜과 HTML 언어를 중십으로 이루어졌으며, 이는 지금 우리가 사용하는 웹의 핵심 기술로 자리 잡았습니다. 웹의 작동 방식을 더 자세히 알아봅시다!
- 하이퍼텍스트 (HyperText)
하이퍼텍스트는 문서 내에서 다른 문서나 정보를 가리키는 링크를 포함한 텍스트입니다. 이를 활용하여 사용자가 하나의 문서에서 클릭을 통해 다른 문서로 이동할 수 있도록 합니다. 이러한 하이퍼텍스트 문서를 작성하는데 HTML 언어를 활용하여 문서의 구조와 링크를 정의합니다. HTML 의 a 태그와 href 속성을 사용하여 하이퍼텍스트 링크가 만들어집니다.
- HTTP (Hypertext Tranfer Protocol)
HTTP는 웹 상에서 데이터를 주고받기 위한 프로토콜(통신 규약)입니다. 웹 브라우저(클라이언트)가 서버에 요청을 보내면, 서버가 해당 요청에 따라 HTML 문서를 반환하는 방식으로 통신이 이루어집니다. 초기의 HTTP는 아래와 같이 매우 단순한 구조로 작동하였으나, 웹의 인기가 급증하고 사용자들의 요구사항을 모두 충족하기에는 기존의 통신 방식은 부족했습니다. 웹 벤더들은 HTTP에 기능을 추가하였고, 당시에 명시된 규칙이 없었기에 혼란을 일으키게 됩니다. 단순하게 클라이언트는 영어로 요청을하고, 서버는 한국말로 대답하는 혼잡한 상황이었습니다. HTTP WG(Working Group) 조직에서 많은 사용자의 요구사항을 반영한 HTTP 통신 규약을 표준화하여 발표한 것이 HTTP/1.0 입니다. HTTP/0.9 에서 HTTP/3 (현재) 까지의 변천사에도 큰 변화들이 있기에, 이는 다른 게시글에서 별도로 다루어 보겠습니다.
<!-- 요청 -->
GET /mypage.html
<!-- 응답 -->
<html>
A very simple HTML page
</html>HTTP/0.9 (초기의 HTTP 구조)
- URL (Uniform Resource Locator)
URL은 인터넷 상의 자원을 식별하는 표준화된 주소 형식이며 이를 통해 사용자는 특정 웹 페이지나 리소스에 접근할 수 있습니다. 컴퓨터는 IP 주소로 통신을 하나, 이러한 숫자의 나열을 사람들이 기억하고 입력하기 쉽도록 변경한 것이라고 볼 수 있습니다. 예로, 구글의 IP 주소인 8.8.8.8로 통신하는 것이 아닌 www.google.com 이라는 주소 체계를 만든 것입니다.
- 클라이언트-서버 모델
사용자가 웹 브라우저(클라이언트)를 통해 특정 웹 페이지를 요청하면, 웹 서버가 해당 요청을 처리하고 결과로 HTML 문서를 클라이언트에 보내는 방식입니다.
HTTP와 HTTPS란 무엇인가?
위에서 알아본 바와 같이, HTTP는 인터넷에서 클라이언트와 서버 간 데이터를 주고 받는 통신 규약입니다. 그렇다면 HTTPS와는 어떤 다른점이 있을까?
HTTPS (Hypertext Tranfer Protocol Secure) : 보안 강화를 위해 암호화된 데이터 전송 방식으로, SSL/TLS 프로토콜을 사용하여 암호화 합니다.
HTTP는 암호화 되지 않은 텍스트 그대로 데이터를 전송합니다. 이는 제 3자가 통신을 가로채서 데이터를 읽을 수 있다는 취약점이 있습니다. HTTPS는 SSL/TLS 기술을 결합하여 보안을 강화한 통신 방식입니다. 이는 인증서를 통해 클라이언트와 서버가 서로 신뢰할 수 있는 존재임을 증명한 후 데이터를 교환합니다. HTTP와 HTTPS는 가장 큰 차이점은 SSL/TLS 보안 프로토콜의 사용 여부로 나뉩니다.
SSL/TLS 핸드셰이크
그렇다면 HTTPS는 SSL/TLS 프토로콜을 사용하여 어떻게 데이터를 주고 받을까요? 아래 다이어그램으로 SSL/TLS 핸드셰이크를 통해 어떻게 데이터가 암호화 되는지를 볼 수 있습니다. 이를 이해하기 위한 주요 키워드는 pre-master secret, server's public key, 그리고 session key 입니다.
클라이언트가 서버에 연결을 시작하면, 서버와 클라이언트는 각각 SSL/TLS 인증서를 교환하며 서로의 신뢰성을 확인합니다. 만약 인증서 검증이 실패하거나 신뢰할 수 없는 경우, 암호화 세션이 시작되지 않으며, pre-master secret이 생성되지 않습니다.
Pre-master secret 을 설명하기 앞서 서버의 공개 키 (public key)를 먼저 알고 가야 합니다. 서버의 공개 키는 서버가 미리 설정해둔 암호화 키로, 누구나 사용이 가능합니다. 공개 키는 데이터를 암호화는데 사용되며, 오직 서버만 비밀 키로 데이터를 해독할 수 있습니다.
클라이언트는 Pre-master secret을 랜덤하게 생성하는데, 클라이언트와 서버가 세션 키를 만드는 데 사용하는 중요한 데이터입니다. 여기에는 구체적인 정보나 신원 인증 데이터가 포함되어있지 않고, 순전히 암호화 통신을 위한 비밀 값으로의 역할을 합니다. 즉, 클라이언트가 만든 ✨비밀 코드✨이죠. 클라이언트는 서버의 공개 키를 사용하여 비밀 코드를 암호화 합니다.
서버는 클라이언트가 전송한 ✨비밀 코드✨를 해독합니다. 클라이언트와 서버는 pre-master secret을 사용해 각각 세션 키를 생성하며, 세션 키는 양쪽 모두에서 동일하게 생성 됩니다. 이는 클라이언트와 서버가 공동으로 사용할 자물쇠이자 키의 역할을 합니다.
이후 클라이언트는 세션 키로 요청을 암호화 해서 서버에 보냅니다. 서버는 세션 키로 요청을 복호화 하고, 데이터 처리 후 응답을 암호화하여 클라이언트에게 보냅니다. 클라이언트는 응답을 복호화 하여 내용을 확인하는 방식으로 통신을 이어 나갑니다.
▶︎ 서버와 클라이언트가 어떻게 동일한 세션 키를 생성할 수 있을까?..
이는 Pre-master secret와 양쪽 모두가 알고 있는 값(예: 랜덤 난수, 암호화 알고리즘 등)을 기반으로 키 생성 함수를 동일하게 사용하기 때문입니다. 구체적으로는, 클라이언트가 생성한 Pre-master secret을 서버로 보내고, 클라이언트와 서버는 이를 이용해 공통의 세션 키를 생성하는 알고리즘을 사용합니다. 이러한 알고리즘은 각자 다른 기기에서 실행되더라도, 같은 입력값이 들어가면 항상 동일한 결과값(세션 키)을 출력하도록 설계되어 있습니다. 따라서 클라이언트와 서버는 서로의 통신을 안전하게 하기 위해 동일한 세션 키를 생성해 데이터를 암호화하고 복호화할 수 있습니다.
<HTTPS 통신 만화>
How HTTPS Works
🙀 A cat explains how HTTPS works...in a comic! 😻
howhttps.works
HSTS와 보안
HSTS는 서버에서 HTTP 응답 헤더에 **Strict-Transport-Security**라는 헤더를 포함하여 클라이언트에게 전달함으로써 작동합니다. 이 헤더는 클라이언트에게 지정된 기간 동안 해당 도메인에 대한 모든 요청을 HTTPS로만 보내도록 명시합니다
<header>
Strict-Transport-Security: max-age=31536000; includeSubDomains
</header>
- max-age=31536000: 이 값은 HSTS 정책이 유효한 기간을 초(Seconds) 단위로 설정합니다. 위의 경우 31536000초는 1년 동안 해당 도메인에 HTTP 접속을 하지 않도록 설정한 것입니다.
- includeSubDomains: 이 옵션은 서브 도메인도 HSTS 정책을 따르도록 합니다. 예를 들어, example.com의 서브 도메인인 www.example.com이나 shop.example.com도 HSTS 정책을 적용받습니다.
HSTS는 보안 강화를 위해 설계된 정책으로 아래와 같은 보안 이점을 제공합니다.
특히 HSTS는 중간자 공격을 예방하는데 큰 기여를 합니다. 중간자 공격(MiTM : Man-in-The-Middle)은 HTTP 환경에서 발생하기 쉬운데, 그 이유는 HTTP는 암호화되지 않은 평문 데이터를 주고받기 때문에 공격자가 데이터를 쉽게 열람하거나 수정할 수 있기 때문입니다. 이때 HSTS는 아래와 같은 방법으로 이를 예방합니다.
- HTTP로 다운그레이드 공격 방지 : http로 접속할 경우, 자동으로 https로 리다이렉트 합니다. 아마 해커 분들이라면, http로만 작동하는 페이지를 접속하려 할때, https로 리다이렉트 되어 에러가 발생한 경험이 있으시죠? 이제 그 이유를 알게 되었네요!
- HSTS 정책 캐싱 : HSTS는 한 번 서버에서 클라이언트로 전송되면, 클라이언트는 이를 캐싱하여 이후에도 계속 적용을 합니다. 즉, HTTP로의 접속을 강제할 기회를 차단한다고 이해할 수 있습니다. 위의 헤더 내용을 기반으로, 특정 도메인 (서브 도메인 포함)에서 받은 HSTS가 내 브라우저 캐시에 어느 기간 동안 저장 되는지 알 수 있습니다. 다만, 이는 사용자가 한 번도 접속하지 않은 도메인에는 HSTS가 적용되지 않습니다. (서버에서 받은 적이 없기 때문이죠!)
- HSTS Preload 리스트 : 브라우저에 미리 등록된 도메인 목록으로, 이 리스트에 등록된 도메인은 사용자가 한 번도 방문하지 않았더라도 브라우저가 처음부터 HTTPS로만 연결을 시도하게 합니다.
Chrome HSTS Preload 사이트
HSTS Preload List Submission
<!-- We un-hide the form using inline JS so that (when JS is enabled) it shows in the normal rendering order as if it was never hidden. --> Submitting entries to the HSTS preload list via this site requires JavaScript. This form is used to submit domains f
hstspreload.org
결론
HTTP와 HTTPS의 웹 통신에서 중요한 역할을 하지만, 서로 다른 보안 수준과 그 차이의 이유에 대해 자세히 알아보았습니다. HTTP는 암호화되지 않아 중간자 공격 등 다양한 보안 위협에 취약하지만, HTTPS는 SSL/TLS 프로토콜을 통해 통신을 암호화하여 이러한 위험을 줄입니다.
특히 SSL/TLS 핸드셰이크 과정에서 큰 차이를 보였는데 이는 클라이언트와 서버는 서로를 인증하고, Pre-master secret을 바탕으로 세션 키를 생성해 안전한 암호화 통신을 시작합니다. 이 과정은 데이터의 기밀성과 무결성을 보장하며, 악의적인 공격자로부터 정보를 보호합니다.
**HSTS(HTTP Strict Transport Security)**는 보안성을 더욱 강화해, HTTP로의 접속을 자동으로 HTTPS로 강제 전환하고, 중간자 공격과 같은 위협을 차단합니다. HSTS는 브라우저에 HTTPS 사용을 기억시켜 불필요한 리다이렉션을 제거해 성능도 최적화합니다.
결국, HTTPS와 HSTS는 웹 보안을 강화하고 사용자에게 안전한 통신 환경을 제공하며, SSL/TLS 핸드셰이크는 그 기반이 되어 신뢰성 있는 연결을 보장합니다. 이러한 기술들은 현대 웹에서 필수적인 요소로, 웹사이트 운영자는 반드시 도입해야 합니다.
'Study Log > Web 개발' 카테고리의 다른 글
| [webDev] SSL/TLS 프로토콜 (1) | 2024.09.22 |
|---|