[모의 면접 CS 스터디] HTTPS

HTTPS란

HTTPS란 HyperText Transfer Protocol(HTTP) Security란 약자에서부터 알 수 있듯이  기본적으로 HTTP와 동일하지만 암호화 과정을 더 추가한 것이라고 볼 수 있다.

 

HTTP와 HTTPS는 무엇이 다른가? 

HTTP는 클라이언트와 서버가 메시지를 주고 받을 때 그 내용을 암호화 하지 않는데, 둘 사이에 보안적으로 민감한 정보, 이를테면 웹사이트의 아이디와 비밀번호 등이 전달되었을 때 다른 사람이 쉽게 그 내용을 파악하거나 변조할 수 있다.

 

그러므로 이러한 문제를 예방하고자 등장한 것이 SSL(Socket Security Layer)이란 암호화 프로토콜이고, SSL의 최신 버전을 TLS(Transport Layer Security)라고 부른다. HTTPS란 기본적으로 어플리케이션 계층에선 이전처럼 HTTP를 사용하되 전송 계층에 TLS 암호화 프로토콜을 추가한 것이라 볼 수 있다.

 

 

HTTPS의 암호화 방식

그럼 HTTPS는 구체적으로 어떤 방법을 이용해서 데이터를 암호화 하는 것일까 서버와 클라이언트는 서로 세션 키(session key)라는 것을 이용해서 각각 메시지를 암호화 하여 상대방에게 보내고 키를 통해 복호화한다. HTTPS의 암호화 방식을 이해하기 위해선 먼저 대칭키 암호화 방식과 비대칭키 암호화 방식에 대해 살펴볼 필요가 있다.

 

대칭키 암호화 방식과 비대칭키 암호화 방식

 

1) 대칭키 암호화

 

대칭키 암호화란 암호화와 복호화에 사용되는 키가 동일한 방식을 뜻한다.  

이를테면 A라는 데이터를 클라이언트의 대칭키로 암호화면 서버가 그 암호화된 데이터를 다시 대칭키로 복호화하여 원래의 데이터를 볼 수 있게 되는 것이다. 다만 키가 노출되면 암호화든 복호화를 자유자재로 할 수 있기 때문에 키가 외부에 노출되지 않는 것이 매우 중요하다.

 

그렇다면 서버와 클라이언트 모두 동일한 키를 가지기 위해선 키 교환 과정을 거쳐야 하는데, 이 과정에서 대칭키를 안전하게 교환하는 방법은 무엇일까?  여기에는 여러 방법이 있을 수 있겠지만 HTTPS에서는 비대칭키 방식을 이용해서 키 교환을 한다. 

 

2) 비대칭키 암호화

 

비대칭키 암호화 방식이란 암호화와 복호화에 사용되는 키가 다른 것을 의미한다. 더 정확히 말해서 키 A, B가 있을 때 A로 데이터를 암호화하면 B로 복호화할 수 있고 반대 B로 데이터를 암호화하면 A로 복호화 가능하다. 

이러한 특성 덕분에 A가 다른 사람들에게 노출된다고 해도 A로 암호화한 데이터는 B로만 복호화할 수 있기 때문에 키 교환 이 간편하다는 장점이 있다. 

 

  

-키 교환 방식 ex)

 

1) A가 비밀키와 공캐키를 생성하여 자신의 공개키를 B에게 보낸다.

2) B는 A의 공개키를 받고 비밀키와 공캐키를 생성하여 다시 A에게 자신의 공개키를 보낸다.

따라서

A가 가지는 키: A의 비밀키, B의 공개키

B가 가지는 키: B의 비밀키, A의 공개키

 

이렇게 하면 한 쪽이 상대방의 공개키로 정보를 암호화하여 보내고, 다른 한쪽은 자신의 비밀키를 이용해서 그 내용을 복호화하면 된다.

 

비밀키와 공개키는 서로 데이터를 암호화, 복호화 할 수 있기 때문에 반대로 비밀키로 데이터를 암호화-> 공개키로 복호화 하는 방식도 가능하다. 데이터의 암호화를 공개되지 않은 비밀키로 하기 때문에(암호화를 아무나 할 수 없기 때문에) 해당 데이터를 보낸 주체가 유효한지 판단하는 데에 사용된다. 

 

비대칭키 방식은 위와 같이 키 교환 과정에서 다른 사람에게 키가 노출되도 보안적인 부담이 없다는 장점이 있다. 

다만 대칭키 방식에 비해 암호화키 생성 과정이 복잡하고, 암호화, 복호화 속도가 느리다는 문제가 있다.

따라서 HTTPS에서는 처음 대칭키를 교환할 때 보안을 위해 이 방식을 사용하고 이후에는 주로 대칭키 방식을 사용한다.  

 

SSL/TLS Handshake

SSL 혹은 TLS 핸드 셰이크란 HTTPS에서 TCP 3-way-handshake를 통해 서버와 클라이언트 간의 연결이 설정된 이후에 암호화 방식 결정, 데이터 암호화를 위한 키 교환 등을 통해 데이터를 암호화하는 데에 필요한 것을 합의해나가는 과정이다. 

 

 

핸드 셰이크 동작과정

 

1) Client Hello

 

클라이언트는 서버에게 다음과 같은 정보를 전달한다.

 

• 자신이 사용하는 TLS 버전 
• 적용 가능한 암호화 방식(ciper suite)
• 세션 id

 

2) Server Hello

 

서버는 클라이언트가 보여준 TLS 버전과 암호화 방식을 보고 암호화 과정을 어떻게 진행할지 결정하고 이를 클라이언트에게 통보한다. 따라서 지금부터는 TLS의 핸드 셰이크 동작 과정은 버전 및 암호화 방식에 따라 조금씩 차이가 있다고 한다. 여기서는 필자가 생각하기에 좀 더 단순해 보이는 과정을 선택했다. 

 

3) Certificate

 

서버는 다음과 같은 정보를 클라이언트에게 보낸다.

 

• SSL 인증서( CA에서 발급한 전자서명과 서버의 인증서 내용 등이 포함됨)
• 서버의 공개키(보통 인증서에 포함됨, 포함되지 않을 경우 바로 Server Key Exchange 과정에서 전송)

 

여기서 SSL 인증서는 CA( Certificate Authorize)라는 제 3의 인증기관으로부터 발급되는데 이는 해당 서버가 유효함을 인증하는 데에 사용된다. 

좀 더 자세하게 말하자면 SSL 인증서 내에는 전자서명이 있는데 이는 인증서의 내용을 해쉬함수를 통해 암호화한 뒤 CA에서 발급한 비밀키로 암호화된 것이다. 클라이언트는 여러 CA에서 공개키 목록을 가지고 있어서 여기서 공개키를 찾은 뒤 복호화하여 서버의 인증서의 해쉬값과 같으면 유효하다는 판단을 내린다. (해쉬함수는 인풋과 아웃풋의 규칙성이 없기 때문에 공격자 입장에서는 평문과 동일한 해쉬값을 가지는 인증서 내용을 만드는 것이 불가능에 가깝다.)

 

 

4) Server Hello Done

 

서버가 행동을 마쳤음을 전달함

 

5) Client Key Exchange

 

여기서 드디어 둘 사이의 데이터 암호화 때 사용될 대칭키(session key)를 클라이언트가 생성한다. 이를 서버가 전달한 공캐키로 암호화하여 서버에게 보낸다.

 

6) ChangeCipherSpec / Finished

 

둘 사이의 핸드 셰이크 과정이 완료되었음을 전달한다.

 

 

 

참고자료

안전한 웹을 위해 HTTPS 이해하기: ①HTTPS의 작동 원리 | 요즘IT 

HTTPS 통신 원리 쉽게 이해하기 (Feat. SSL Handshake, SSL 인증서) 

SSL, TLS, HTTPS Explained - YouTube

Chatgpt