🚩 HTTP와 HTTPS의 차이
🏁 HTTP(HyperText Transfer Protocol)란?
개념
HTTP⭐란 HyperText Transfer Protocol의 약자로 웹 상에서 웹 서버 및 웹브라우저 상호 간의 데이터 전송을 위한 응용계층 프로토콜을 의미합니다.
과거에는 WWW(World Wide Web) 상의 하이퍼텍스트 형태의 문서를 전달하는데 주로 이용되었습니다.
현재에는 이미지, 비디오, 음성 등 거의 모든 형식의 데이터를 전송할 수 있습니다.
아래에서 간단하게 HTTP 프로토콜에 대한 설명 이후, HTTPS가 왜 탄생되었는지 기술하겠습니다.
특징
앞서 설명드린 것처럼 HTTP는 기본적으로 통신 규약입니다. 사용자가 클라이언트, 즉 브라우저 등으로 서버에 요청을 보냅니다. 클라이언트의 요청을 받은 서버는 특정 자원에 대한 정보를 제공하거나 작업을 처리하게 됩니다.
1. CRUD
HTTP 요청 메서드는 CRUD로 대표되는 작업을 처리합니다. 생성은 POST, 조회는 GET, 수정은 PUT/PATCH, 삭제는 DELETE라는 이름의 HTTP 메서드를 사용합니다.
이외에도 다양한 메서드가 있지만 주제를 벗어나기 때문에 여기서는 다루지 않겠습니다.
2. 요청 헤더와 응답 헤더
위 사진처럼 HTTP 요청 메시지와 응답 메시지는 일정한 형식을 갖추어 데이터를 통신하게 됩니다.
컴퓨터 상호 간 이해할 수 있는 형식인 셈입니다.
3. 무상태성, 비연결성
HTTP 통신은 클라이언트와 서버로 나누어진 구조로 설계되어 있습니다.
클라이언트가 특정 작업을 요청하면 서버는 요청에 대해 응답합니다.
이러한 구조로 인해 HTTP는 ❶무상태성(Stateless)과 ❷비연결성(Connectionless)이라는 대표적 특징을 가지게 됩니다.
- 무상태성(Stateless) : 클라이언트와 서버 사이에 상태를 유지하지 않는 것입니다. 스케일 아웃 등의 서버 확장성이 높지만 클라이언트가 추가적인 데이터를 전송하는 등 메모리상 단점이 있습니다.
- 비연결성(Connectionless) : 서버와 클라이언트의 연결을 지속하지 않습니다. 클라이언트가 서버에 요청하고 응답을 받으면 바로 TCP/IP 연결을 끊어 연결을 유지하지 않음으로써 서버의 자원을 효율적으로 관리하고 수 많은 클라이언트 요청에 대응할 수 있게 합니다.
HTTP는 위와 같은 특징을 가지고 있으며, 1991년 0.9버전이 출시된 이래로 지속적인 발전을 거듭하여 2019년 3.0 버전이 출시되었습니다.
여기까지의 설명만 보면 HTTP는 웹에서 데이터를 송수신 하기에 충분한 통신 규약이자, 기술인 것 같습니다.
그러나 HTTP 사이트는 몇 가지 약점이 있습니다.
한계
1. 중간자 공격에 취약함
데이터가 평문으로 전송되기 때문에 중간에 해킹자가 스누핑을 성공한다면 민감한 정보를 그대로 탈취당할 수 있습니다.
2. 신뢰할 수 있는 사이트인지 보증하지 못함
만약 목적 사이트가 프로토콜로 HTTP를 사용한다면 신뢰할 수 있는 사이트인지에 대한 별도의 인증 절차가 없습니다. 사용자가 미인증된 피싱 사이트에 입장하더라도 신뢰할 수 있는 사이트인지 여부를 검증할 수 없기 때문에 쾌적한 사용자 경험을 제공하지 못합니다.
현재 통용되는 크롬 등 브라우저에서는 정보 도용에 대한 알림이 발생합니다.
🏁 HTTPS
HTTPS는 HyperText Transfer Protocol Secure의 약자입니다.
HTTPS는 애플리케이션 계층과 전송 계층 사이에 신뢰할 수 있는 중간 계층인 SSL/TSL이 포함된 HTTP 요청입니다.
한마디로 웹 통신 프로토콜 HTTP에 보안이 강화된 버전입니다.
HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 데이터를 암호화 합니다.
특징
1. SSL/TLS 프로토콜을 통한 데이터 암호화
HTTPS 프로토콜은 결국 HTTP와 보안 프로토콜 SSL/TLS의 결합입니다. (사실 TLS는 SSL의 보안상 취약점을 극복한 버전이라 최신 웹 사이트들은 TLS 프로토콜을 사용하고 있습니다. 그러나 관습적으로 이 TLS를 SSL이라고 부르기도 합니다. 현 포스팅에서는 병기하도록 하겠습니다.)
SSL/TLS 프로토콜을 사용하게 되면 데이터를 송수신할 때 암호화되어 중간자가 패킷 탈취에 성공하더라도 이를 해석할 수 없습니다.
2. CA가 신뢰할 수 있는 사이트임을 보증
SSL/TLS 인증서를 발급하는 CA(인증 기관)가 되려면 운영 체제, 브라우저 또는 모바일 디바이스 회사에서 정한 특정 요건을 충족하고 루트 인증 기관으로 리스팅되도록 신청해야 합니다.
신뢰할 수 있는 인증 기관이 SSL/TLS 인증서를 발급하기 때문에 사용자는 현재 사이트가 신뢰할 수 있는 사이트임을 확인할 수 있습니다.
크롬 등 브라우저는 이를 쉽게 확인할 수 있습니다. HTTPS 프로토콜을 사용하는 사이트에서는 주의 요함이라는 문구가 아닌 자물쇠 형태의 아이콘을 확인할 수 있습니다.
절차
다음으로 ❶SSL/TLS 인증서 발급 절차와 ❷SSL/TLS 인증 과정(TLS 핸드셰이크)에 대해 설명드리겠습니다.
일반적인 상황에서의 흐름 개요를 설명드린 것으로 CA나 사이트에 따라 세부 사항이 다를 수 있습니다.
① CA(인증 기관)로 부터 SSL/TLS 인증서 발급 받는 절차
-
사이트와 CA를 주체로 SSL/TLS 인증서 발급을 설명드리겠습니다.
-
사이트는 인증받을 기관(CA)에 사이트 정보와 공개키를 제공합니다. 공개키는 누구나 획득할 수 있는 키로 보통 데이터의 암호화에 사용됩니다.
-
CA는 사이트 정보를 면밀히 검토합니다. 신뢰할 수 있는 사이트인지 검증된다면 인증기관의 비밀키(개인키)로 서명합니다. 이 때 서명이란, 개인키로 인증서를 암호화하는 것을 의미합니다.
-
CA는 생성된 인증서를 사이트에 전달합니다.
-
그리고 브라우저에 CA의 공개키를 전달합니다. CA의 공개키는 추후 사이트가 보유하고 있는 서명된 인증서를 복호화 할 때 사용합니다.
-
브라우저는 CA의 공개키를 가지고 있으며, 사이트는 SSL/TLS 인증서를 가지고 있다면 SSL/TLS 통신을 위한 준비가 끝난 것입니다.
2. SSL/TLS 인증 과정 (TLS 핸드셰이크)
-
브라우저에서 HTTPS 프로토콜을 이용하는 사이트에 접속을 요청합니다.
-
사이트는 인증(서명)된 SSL/TLS 인증서를 브라우저에 전달합니다.
-
브라우저는 CA 공개키를 보유하고 있었죠? 이 CA 공개키를 이용해 사이트가 전송한 인증서를 복호화하여 검토합니다. 이 절차가 성공하면 신뢰할 수 있는 사이트라는 뜻이겠죠.
-
복호화에 성공하면 브라우저는 해당 사이트의 정보와 공개키를 얻을 수 있습니다.
-
이제 사이트의 공개키로 사용자의 대칭키를 암호화하여 사이트에 전달합니다.
-
서버는 보유하고 있던 개인키로 사용자의 대칭키를 복호화 합니다. 서버의 개인키는 공개키로 암호화된 데이터를 복호화할 수 있는 유일한 키입니다.
- 이제 대칭키를 이용해서 암호화된 데이터를 송수신합니다.
💡SSL/TLS 통신에서는 서로의 신원을 인증할 때 비대칭키 암호화 방식을 이용합니다. 비대칭키 암호화 방식이 정보 보안에 유리한 방식이기 때문입니다. 그러나 비대칭키 암호화는 엄청난 컴퓨팅 리소스를 소모합니다. 따라서 신원이 인증되고 나면, 데이터를 송수신할 때는 대칭키 암호화 방식을 사용하여 빠른 속도로 데이터를 송수신하며 복호화합니다.
따라서, ⭐SSL/TLS 통신은 비대칭키 암호화 방식와 대칭키 암호화 방식을 복합적으로 이용하는 프로토콜이라고 볼 수 있습니다.
HTTP vs HTTPS 표 비교
출처 : https://aws.amazon.com/ko/compare/the-difference-between-https-and-http/
레퍼런스
