[네트워크] HTTPS, 보안 기능의 껍질을 덮어쓴 HTTP

Woonil·2025년 2월 25일

컴퓨터 네트워크

목록 보기

6/9

HTTPS를 한 마디로 표현하면 ‘보안 기능의 껍질을 덮어쓴 HTTP’라 할 수 있다.

HTTPS(HyperText Transfer Protocol Secure)는 새로운 애플리케이션 계층의 프로토콜이 아닌, HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer)/ TLS(Transport Layer Security)라는 프로토콜로 대체한 것이다.

HTTPS = HTTP + SSL(Secure Sockets Layer) or TLS

즉, HTTPS는 HTTP protocol의 암호화된 버전(클라이언트와 서버 간의 모든 커뮤니케이션을 암호화 하기 위해 SSL이나 TLS를 사용)으로 클라이언트가 민감한 정보를 서버와 안전하게 주고받도록 해준다.

장점
- 사용자가 사이트에 보내는 정보들을 제3자가 못 보게 한다.
- 접속한 사이트가 믿을 만한 곳인지를 알려준다.

🤔개념

왜 HTTPS를 사용하게 되었는가?

HTTP와 같이 암호화하지 않은 프로토콜의 문제점은 다음과 같다.

데이터 기밀성

HTTP 는 평문 통신이기 때문에 도청이 가능하다.

평문
암호 알고리즘의 입력 대상으로, 암호화되지 않은 정보

TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있기에 패킷을 수집하는 것만으로 도청할 수 있다. 평문으로 통신을 할 경우 메시지의 의미를 파악할 수 있기 때문에 암호화하여 통신할 필요가 생겼다.

통신 자체를 암호화: 서로 다른 프로토콜을 조합함(SSL or TLS + HTTP)으로써 HTTP 의 통신 내용을 암호화할 수 있다.
콘텐츠를 암호화: HTTP 메시지에 포함되는 콘텐츠만 암호화하며, 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요하다.

통신 상대 인증

통신 상대를 확인하지 않기 때문에 위장이 가능하다.

HTTP 에 의한 통신에는 상대가 누구인지 확인하는 처리는 없기 때문에 누구든지 요청을 보낼 수 있다. IP 주소나 포트 등에서 그 웹 서버에 액세스 제한이 없는 경우, 요청(request)이 오면 상대가 누구든지 무언가의 응답(response)를 반환한다.

문제점
- 요청을 보낸 곳의 웹 서버가 원래 의도한 응답을 보내야 하는 웹 서버인지 확인할 수 없다.
- 응답을 반환한 곳의 클라이언트가 원래 의도한 요청을 보낸 클라이언트인지를 확인할 수 없다.
- 통신하고 있는 상대가 접근이 허가된 상대인지를 확인할 수 없다.
- 어디에서 누가 요청했는지 확인할 수 없다.
- 의미없는 요청도 수신하므로, DoS 공격을 방지할 수 없다.

SSL or TLS는 상대를 확인하는 수단으로 증명서를 제공한다. 이는 제 3자 기관(CA)에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자의 개인 정보 누설 등의 위험성이 줄어들게 된다. 또한 클라이언트는 이 증명서로 본인 확인을 하고 웹 사이트 인증에서도 이용할 수 있다.

데이터 완전성

완전성(정보의 정확성)을 증명할 수 없기 때문에 변조가 가능하다.

즉, 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치하는 것을 보장할 수 없다. 중간자 공격이 일어나 요청이나 응답의 내용이 변조되더라도 이 사실을 알 수 없다.

중간자 공격(Man-in-the-Middle)
공격자가 도중에 요청이나 응답을 빼앗아 변조하는 공격

MD5, SHA-1 등의 해시값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만, 확실히 확인할 수 있는 것은 아니므로 인증이나 암호화, 그리고 다이제스트 기능을 제공하는 HTTPS를 사용해야 안전하다.

HTTPS는 왜 안전한가?

SSL(Secure Socket Layer)

HTTP는 원래 TCP와 직접 통신했지만, HTTPS에서 HTTP는 SSL 과 통신하고 SSL이 TCP 와 통신하게 된다. SSL을 사용한 HTTPS는 암호화와 증명서, 안전성 보호를 이용할 수 있다. 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다.

하이브리드 암호 시스템
공통키를 공개키 암호화 방식으로 교환한 다음에, 다음부터의 통신은 공통키 암호를 사용하는 방식

TLS(Transport Layer Security)라는 이름은 SSL이 표준화 되면서 바뀐 이름이다.

공개키가 가짜라면?

CA(Certificate Authority)

그렇다면 서로에게 공유되는 공개키가 진짜인지는 어떻게 확인할까? 사실 이를 증명할 방법은 없다. 대신 이 증명을 대신해주는 공인된 제3자가 존재한다면 그럴듯 해진다. 이 제3자의 역할을 하는 것이 CA(Certificate Authority)이며, 이는 서버가 보낸 공개키가 정품인지 인증해주는 공인된 민간기업이다.

크롬, IE, 파이어폭스 등 모든 브라우저의 프로그램에는 CA의 목록이 내장되어 있다.

서버의 CA 등록 과정
1. 서버는 인증 기관에 서버의 공개키와 사이트 정보를 전송한다.
2. 인증 기관은 사이트 검증 후, 인증 기관의 개인키로 서명한다. (디지털 서명)
3. 인증 기관은 사이트 인증서(SSL 인증서)를 서버에게 전송한다.
인증서가 포함하는 정보: 웹 사이트명과 호스트명, 웹 사이트의 공개키, 서명 기관의 이름, 서명 기관의 서명 등

HTTPS 통신 과정

SSL 통신 과정은 크게 SSL Handshake → Session → Session 종료 순으로 진행된다.

SSL Handshake

서버와 클라이언트 간 탐색 과정이 먼저 이루어진다.

클라이언트는 클라이언트가 생성한 랜덤 데이터와 클라이언트가 사용 가능한 암호화 알고리즘 후보들을 서버로 전송한다.
1-1. 만약 이전에 해당 서버와 SSL Handshake를 진행했다면, 기존의 세션을 재활용하기 위해 세션 키를 전송한다.
서버는 서버가 생성한 랜덤 데이터, 서버의 인증서 그리고 알고리즘 후보들 중 사용 가능한 알고리즘을 클라이언트로 전송한다.
클라이언트는 2의 인증서 진가 여부를 브라우저에 내장된 CA(Certificate Authority)의 정보를 통해 확인한다.
3-1. 인증서는 CA의 개인키로 암호화 돼있으므로, 클라이언트는 브라우저에 저장된 공개키로 복호화가 가능하다(비대칭키 사용). 만약, CA 리스트 중 해당된 인증서가 없다면 Not Secure 경고문구가 뜬다.
인증서로부터 사이트 정보와 서버의 공개키를 획득한다.
4의 공개키를 사용해 대칭키(pre master secret)를 암호화하여 서버에 전송한다.
서버는 자신의 개인키로 pre master secret를 복호화하여 얻어낸다.
클라이언트와 서버는 일련의 과정을 거쳐 pre master secret를 master secret으로 만들고, master secret으로 session key를 생성한다.

Session 생성 & Session 종료

Session(세션)은 실제로 클라이언트와 서버가 데이터를 주고 받는 단계이다.

데이터를 SSL Handshake 시 생성한 session key로 암호화(대칭키 방식)하여 전송한다.
암호화된 데이터를 받은 상대방은 동일한 session key를 사용해서 데이터를 복호화할 수 있다.

HTTPS는 완벽한가?

암호화 비용

평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구한다. 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대 당 처리할 수 있는 요청 수가 상대적으로 줄어들게 된다.

하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 이용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.