HTTPS란?

면접에서도 자주 물어보고 개발자라면 필히 알아야 되는 지식인 HTTPS에 대하여 알아보겠습니다.

 

 

 

 

 

HTTP로 전송 시 문제점

 

HTTP는 암호화되지 않은 평문으로 데이터를 전송하기 때문에 보안상 여러 가지 문제가 발생할 수 있습니다. 정상적인 사용자에게는 데이터를 빠르고 간편하게 전송할 수 있는 장점이 있지만, 비정상적인 사용자가 요청을 가로챌 경우 중요한 정보가 유출될 위험이 있습니다. 이로 인해 데이터가 탈취되거나 변조되는 문제가 발생할 가능성이 큽니다.

 

이러한 상황을 방지하기 위해 데이터를 암호화하여 비정상적 사용자가 http 요청을 가로챈다고 하더라도 데이터를 읽을 수 없게 하는 것이 HTTPS의 등장 배경이라고 할 수 있습니다.

---

HTTPS의 동작 원리와 SSL/TLS

 

HTTPS는 기본 골격이나 사용 목적 등은 HTTP와 거의 동일하지만, 데이터를 주고 받는 과정에 ‘보안’ 요소가 추가되었다는 것이 가장 큰 차이점입니다. HTTPS를 사용하면 서버와 클라이언트 사이의 모든 통신 내용이 암호화가 적용 됩니다.

 

 

 

 

HTTP를 보내게 되면 HTTP / TCP/ IP 이러한 전송 계층이 되지만 HTTPS를 보내게 되면 HTTP와 TCP 사이에 SSL/TLS를 넣게 되어집니다. 이렇게 되면 시간 지연이 발생하게 됩니다. 그럼에도 불구하고 왜 사용을 하며 특징은 무엇인지 알아보겠습니다.

 

HTTPS는 TCP/IP 위에서 작동하므로, TCP 연결을 설정하기 위해 3-Way Handshake가 먼저 수행됩니다. 이후 TLS Handshake가 시작되며, 클라이언트와 서버가 서로 신뢰를 확인하고 데이터를 암호화할 방식을 협상합니다.

 

HTTPS는 SSL/TLS라는 통신 프로토콜을 기반으로 작동하며 SSL은 초기 버전이며 현재는 TLS가 사용되고 있습니다. TLS는 데이터를 암호화하여 제3자가 내용을 읽지 못하게 하고, 데이터 변조 여부를 확인하며, 통신 상대를 인증하는 기능을 제공합니다. 자세히 살펴보시죠.

---

 

SSL/TLS의 핵심 기능

 

 

데이터 기밀성 (대칭키 암호화/ 비대칭키 암호화): 데이터를 어떻게 암호화 할 것인가?

 

HTTP로 데이터를 평문으로 전송하면 도청이나 위변조의 위험이 있기 때문에 HTTPS가 등장했습니다. HTTPS는 데이터를 암호화하고 서버를 인증하는 과정을 통해 이러한 문제를 해결합니다. 이 과정에서 사용하는 키 방식은 크게 두 가지로 나뉩니다.

 

대칭키: 하나의 키로 데이터를 암호화하고 복호화하는 방식으로, 처리 속도가 빠르다는 장점이 있습니다.

 

비대칭키: 공개키와 개인키라는 두 개의 키를 사용하며, 공개키로 암호화된 데이터는 개인키로만 복호화할 수 있습니다. 디지털 서명의 경우, 개인키로 서명하고 공개키로 이를 검증합니다.

 

HTTPS 통신 과정에서는 대칭키와 비대칭키 암호화 방식을 조합하여 사용합니다. 먼저 비대칭키 암호화를 통해 대칭키를 안전하게 공유한 뒤, 실제 데이터 전송에는 대칭키 암호화를 사용해 빠르고 효율적으로 처리합니다.

---

 

데이터 무결성(암호화 해시 함수): 데이터가 조작되지 않았음을 어떻게 알 수 있는가?

 

 

SSL/TLS는 암호화 해시 함수를 사용하여 데이터의 무결성을 보장하는 작업을 합니다. 암호화 해시 함수는 데이터를 입력받아 고정된 길이의 "해시 값"을 출력하는 함수입니다. 동일한 데이터를 입력하면 항상 동일한 해시 값을 반환하며, 데이터가 조금이라도 바뀌면 완전히 다른 해시 값이 생성됩니다.

 

만일 메시지 a와 메시지 b를 보내게 된다고 가정할 시 암호화 해시 함수를 거치게 되면 둘의 해시 값이 달라지게 되므로 둘이 다른 메시지라는 것을 알게 됩니다.

 

정리하자면 클라이언트와 서버가 서로 동일한 암호화 해시 함수를 갖고 있을 때, 클라이언트가 메시지를 암호화 해시 함수를 통해 만들어진 해시 값과 메시지를 서버에게 보내게 됩니다.

 

서버는 자신이 가지고 있었던 해시함수를 통해 보내져온 메시지를 해싱하여 서로의 해시 값을 비교하여서 메시지 값이 변조되지 않았다는 것을 알 수 있습니다.

 

---

통신 상대 인증(상대를 확인하지 않는다면 비정상적인 서버를 구분할 수 없다): 통신 상대를 신뢰할 수 있는가?

 

 

만약에 위의 가정 자체가 정상적인 서버라는 가정하에 이루어진 것인데, 만일 암호화 해시 함수도 정상적인 키도 가진 비정상적인 서버였다면 말이 달라지게 됩니다.

 

클라이언트는 해시 함수를 통해 검증도 하고 암호화를 통해 또 검증을 하니 무사히 안정적으로 데이터가 오고가는 것처럼 느끼겠지만 사실은 아니라는 것이죠 이러한 문제를 해결하기 위해 인증 기관이라는 개념을 도입하게 됩니다.

 

프로세스는 대략 다음과 같습니다:

 

1. [서버]는 서버 정보를 [인증기관]에게 보내게 됩니다.

 

2. [인증 기관]은 이 서버 정보를 서명하여 서버 인증서를 만든 후 [서버]에게 서버 인증서를 보내게 됩니다.

 

3. [서버]는 [클라이언트]에게 서버인증서를 보내게 되고 해당 서버 인증서에는 서버 정보가 있으므로 [클라이언트]가 서버 인증서의 서버 정보를 검증한 뒤 [인증기관]을 통해서 이 서버가 정상적인 서버냐 아니냐를 판가름 할 수 있게 됩니다.

 

하지만 비정상적인 [서버]가 비정상적인 [인증 기관]을 임의로 만들어서 클라이언트를 속일려고 할 수 있습니다. 하지만 인증서는 인증체인을 통해서 서로의 인증을 해주고 있기 때문에 [인증기관]을 임의로 만들어도 정상적인 [서버]라고 인식할 수 없게 합니다.

 

 

인증 체인은 인증서와 중간 인증서와 루트 인증서 구조로 띄우고 있으며 해당 인증서가 정상적인 인증서인가를 판가름 하는 중간 인증서와 해당 중간 인증서가 정상적인 중간 인증서인가를 판단하는 루트 인증서로 이루어져있기 때문입니다.

 

---

 

HTTPS 통신 흐름

 

 

 

[서버]에서 서버 정보와 서버 공개키를 가지고 인증기관에게 보내게 됩니다.

 

[인증기관]은 서버 정보와 서버 공개키를 받아서 지니고 있는  인증 기관의 개인키로 데이터를 디지털 서명화하게 됩니다.

 

서명 된 결과를 SSL 인증서라고 하며 이 인증서를 [서버]에게 보내게 됩니다.

 

동시에 [인증 기관]은 클라이언트 [브라우저]에게 인증 기관의 공개키를 보내게 됩니다.

 

 

 

 

[클라이언트]가 [서버]에게 요청을 보내게 되면 정상적인 서버는 SSL 인증서를 보내게 됩니다.

 

SSL 인증서는 인증 기관의 개인키로 암호화가 되어있지만 [클라이언트]는 인증기관의 공개키를 가지고 있어 검증을 진행하여 서버 정보와 서버 공개키를 얻고 정상적인 서버인지를 판단합니다.

 

검증된 사이트라고 맞다고 생각하면 [클라이언트]는 클라이언트 대칭키를 만들게 되며 서버의 공개키로 클라이언트 대칭키를 암호화 하여 [서버]에게 보내게 됩니다

 

서버는 서버의 개인키를 가지고 있기 때문에 암호화된 서버의 공개키를 복호화하여 클라이언트의 대칭키를 얻습니다.

 

이제 서버와 클라이언트가 서로가 같은 클라이언트의 대칭키를 가지고 있기 때문에 서로의 메시지를 암호화 하고 복호화 할 수 있게 됩니다.