이번 글에선 HTTPS가 무엇인지, HTTPS를 사용하는 이유는 무엇인지, 그리고 HTTPS의 전체적인 동작에 대해서 알아보려고 한다. 웹 보안을 이해하는 데 있어 중요한 개념이기 때문에 꽤 세세하게 다뤘다.
참고사항!
* 이 글을 제대로 이해하기 위해선 네트워크 레이어에 대한 약간의 배경지식이 필요합니다.
* 비전공자와 전공자 둘 다 도움이 될 수 있는 지식을 전달하고자 했습니다.
* 키 생성 알고리즘에 대해 자세히 설명하지 않습니다.
HTTPS는 HyperText Transfer Protocol Secure의 줄임말이다. 말에서 알 수 있듯 HTTP의 보안을 강화한 버전이다. HTTPS는 처음 발표된 것이 1994년인데, 약 30년이 지난 지금까지도 활용되고 있는 프로토콜이다. 일단 HTTPS를 설명하기 전에 HTTP가 과거에 어떤 문제점이 있었는지를 알아볼 필요가 있다. 다시 말하면 “HTTPS가 대체 왜 나오게 되었느냐” 이 말이다.
HTTP의 가장 큰 문제점: 패킷의 정보를 어렵지 않게 확인할 수 있다.
컴퓨터 네트워크에 대한 지식이 약간 있는 사람이라면 컴퓨터 네트워크는 대개 7 layers 혹은 5 layer로 나누어져 있다는 것을 알고 있을 것이다. HTTP도 applicatin layer에 속하는 프로토콜 중 하나이다. 데이터들은 레이어들을 거칠 때 마다, 해당 레이어에서 담당하는 정보가 추가된다. 그리고 패킷 형태로 데이터들이 전송된다.
문제는 이러한 패킷을 누군가가 가로채서 어렵지 않게 관찰하고 분석할 수 있다는 점이다. 따라서 HTTP의 패킷을 조사하면 제3자가 나의 민감한 정보를 가로채고 위변조할 수 있다는 문제점이 발생한다.
이렇게 말하면 잘 모를 수도 있으니, 예시를 가져왔다. 위에는 국토교통부 홈페이지를 들어갔을 때, wireshark라는 패킷분석기로 패킷을 살펴본 것이다. 국토교통부 홈페이지는 현재 HTTP프로토콜을 사용한다. 그 결과 클라이언트가 무엇을 요청했는지, 서버는 어떻게 응답했는지들을 모두 확인할 수 있다.
반면 TLS를 사용한 통신의 예시이다. 아직 무슨 일을 한건지 정확히 알 수는 없지만, 확실한 것은 아까와 달리 어떤 데이터를 주고 받았는지 알 수가 없다. 이는 뒤이어 설명할 예정이지만, 암호화 및 인증 과정을 거쳤기 때문이다.
결론적으로 HTTP의 문제점을 정리해보면 다음과 같다.
- 데이터가 암호화가 되어있지 않고 평문으로 되어있어서 제 3자가 패킷을 살펴볼 수 있다.
- 제 3자는 데이터를 악의적으로 위변조할 수 있다. 서로 데이터가 완전한지 확인하지를 않는다.
- 서로 신뢰성있는 상대인지도 확인하지도 않는다.
따라서, 이렇게 보안에 구멍이 뻥뻥 뚫려있는 HTTP를 보완하기 위해서 필요한 조건은 다음과 같다.
- 데이터를 클라이언트와 서버끼리만 확인할 수 있도록, 데이터를 암호화할 것.
- 서버의 신분을 확인할 수 있는 인증 과정을 거칠 것.
그럼 HTTPS는 어떻게 이 두 가지 조건을 만족시켰는지 차근차근 알아보자.
SSL(Secure Socket Layer)&TLS(Transport Layer Secure)
1994년에 넷스케이프는 HTTP를 보완하기 위해 SSL이라는 일종의 네트워크 레이어를 선보였다. 그리고 업데이트를 계속 이어가다가 1999년에 SSL를 계승하는 TLS를 발표했다. 현대의 HTTPS는 이 TLS를 기반으로 한 기술이다. SSL과 TLS는 사실상 동일한 원리로 동작하므로, 둘을 구별해서 따로 배울 필요는 없다.
TLS: HTTP와 TCP 사이에서 동작하는 보안 레이어.
TLS가 Transport Layer Secure를 의미하는 것에서 알 수 있듯이, TLS는 Transport Layer와 연관이 깊다. 웹은 Transport layer로 TCP를 사용하므로 TCP와 밀접한 연관이 있다는 것을 기억하자.
일반적으로 HTTP 통신은 TCP로 3-way handshake를 해서 연결을 만든 직후 바로 시작된다. 연결이 완성되면 그 위에서 바로 HTTP 통신을 한다. 반면 HTTPS는 HTTP와 TCP 사이에 TLS라는 보안 레이어를 거친 후에 HTTP통신을 하는 형태이다. 그래서 그 TLS가 어떻게 작동하냐고? 이제부터 설명 들어갑니다.
TLS에 대해 알기 위해선 일단 보안분야에 간단한 배경지식이 필요하다. 만약 아래의 핵심개념을 이미 알고 있다면 이 부분은 건너뛰어도 좋다.
TLS에서 알아야할 핵심 개념 1: 대칭키, 비대칭키(개인키 & 공개키)
대칭키: 암호화와 복호화에 사용되는 동일한 키.
- 데이터를 암호화할 때 4578이라는 key를 사용했으면, 복호화할 때도 4578이라는 key를 사용해야한다. 우리가 현관에서 사용하는 번호식 자물쇠와 동일한 방식이라고 생각하면 된다. 대칭키는 만들기 쉽고 빠르다는 장점이 있다. 하지만 키를 안전하게 전달하기 힘들다는 단점이 있다. 예를 들어 현관문 번호에 대해 말하는 것을 제 3자가 엿듣는다면 누구든 현관문을 딸 수 있다. 대표적인 알고리즘으로 DES, AES라는 것이 있다.
비대칭키: 암호화와 복호화에 사용되는 서로 다른 키.
- 개인키(private key)와 공개키(public key)를 합쳐 비대칭키라고 부른다. 비대칭키는 암호화키와 복호화키가 다르다. 대개 자신만 비밀스럽게 알고있는 개인키를 만들고, 그 개인키를 바탕으로 특정한 알고리즘을 이용하여 공개키를 만들고 나서 각각 암호화나 복호화에 사용한다. 대표적인 알고리즘으로 RSA가 있다.
- 비대칭키의 가장 큰 특징은 개인키로 암호화한 것은 공개키로만 복호화할 수 있고, 공개키로 암호화한 것은 개인키로만 복호화할 수 있다는 점이다. 그리고 이 점 덕분에 비대칭키만이 가지는 이점이 있다.
ex1) 철수가 영희에게 선물(데이터)을 보낸다고 하자. 철수가 영희의 공개키로 선물을 암호화해서 보냈다. 영희는 자신의 개인키로 이를 복호화함으로서 이것이 자신을 위한 선물임을 알아차릴 수 있다.
ex2) 이번엔 철수가 영희에게 자신의 개인키로 선물을 암호화해서 보냈다. 영희는 철수가 공개한 공개키로 이를 복호화했다. 영희는 이 선물이 철수가 보낸 것을 알 수 있다. 몰론 중간에 제 3자가 철수의 공개키로 선물을 열어볼 수 있긴 하지만, 그 출처를 속일 수는 없다.
즉 영희는 철수의 공개키로 선물이 복호화되는 것을 확인하면, 이 선물이 철수가 보낸 것임을 알 수 있다. 바로 이 부분이 중요하다! 여기서 디지털 서명의 컨셉을 이해할 수 있다.
TLS에서 알아야할 핵심 개념 2: 디지털 서명, CA, 그리고 인증서
디지털 서명(Digital Signature)
위의 두 번째 예시에서 본 것처럼, A가 자신의 개인키로 암호화한 것을 B가 복호화함으로서 B는 A의 신원을 확인할 수 있다. 이것이 디지털 서명이다. 위키피디아에선 디지털 서명을 다음과 같이 정의한다.
“디지털 서명(digital signature, digital 署名)은 네트워크에서 송신자의 신원을 증명하는 방법으로, 송신자가 자신의 비밀키로 암호화한 메시지를 수신자가 송신자의 공용 키로 해독하는 과정이다”.
*이건 여담이지만, 전자서명(Electronic Signature)이라는 말도 혼용해서 많이 쓰는데 엄밀히 따지면 다른 의미다. 디지털 서명이라는 말이 정확한 표현이긴 하다. 전자서명은 수기 서명을 태블릿이나 서명패드등으로 전자화한 것이다.
ex) 우리가 마트에서 물건을 사고나서 하는 서명이 전자서명이다.
CA(Certificate Authority)와 인증서
자 이제 TLS와 직접적으로 연관된 부분이 살살 등장한다. 우선 우리 같은 클라이언트의 입장에서 서버가 신뢰할 만한 대상인지 어떻게 알 수 있을까? 내 개인정보를 빼돌리는 서버일 수도 있고, 아니면 다른 보안적인 문제가 있는 서버일 수도 있다. 그래서 CA라는 몇몇 인증기관들이 이들의 신원을 관리한다. 서버 측에서 CA에 자신의 신원을 제출하면, CA가 이를 검증한 뒤에 자신의 전자서명이 들어간(즉 CA의 개인키로 암호화한 내용이 들어간) 인증서를 서버 측에 건네준다. 일종의 신분증인셈이다.
그리고 서버는 이 인증서를 클라이언트에게 전달해준다. 클라이언트의 웹브라우저에는 유명한 CA의 목록과 그 공개키를 가지고 있는데, 이것을 이용하여 인증서를 복호화해본다. 그리고 복호화가 정말로 완료되면 서버가 신뢰할 수 있는 대상임을 알 수 있게된다.
*만약 인증서에 구체적으로 어떤 내용이 들어갔는지 알고 싶다면 아래와 같이 해보길 바란다.
크롬 기준으로 좌측 상단을 보면 자물쇠 모양이 있다. “여기서 이 연결은 안전합니다.”를 클릭한다.
그 뒤 “인증서가 유효함”을 클릭한다.
그럼 인증서에 나타난 내용들을 모두 확인할 수 있다. 세부정보에 들어가면 더 많은 내용을 볼 수 있다.
인증서에는 CA의 정보, 서버의 암호화 방식, CA의 전자서명, 그리고 서버의 랜덤생성 데이터, 서버의 공개키 등등… 많은 내용이 들어가는 것을 확인할 수 있다.
TLS가 수행하는 일과 그 과정
배경지식을 알았으니 이제 실질적인 TLS 통신내용을 살펴보자. 클라이언트와 서버가 TCP에서 3-way handshake로 연결을 만들고 나면, TLS가 작동하기 시작한다.
*아래 이미지들에서 Extension 부분은 현재 알 필요가 없다.
- ClientHello
클라이언트가 서버에게 보내는 첫 메시지이다. ClientHello메세지에는 위와 같은 정보들이 담긴다. 모든 내용을 구체적으로 알 필요는 없다. 일단 클라이언트가 자신이 생성한 랜덤데이터, 그리고 사용가능한 암호화 & 압축 방식 목록 등을 서버에게 전달한다는 것이 중요하다.
ClientHello에 대한 응답으로 서버는 클라이언트에게 ServerHello, Certificate, ServerDone 메세지를 보낸다.
- ServerHello
서버가 클라이언트에게 보내는 메시지. 서버는 클라이언트의 "ClientHello" 메시지에서 자신이 사용할 암호화 & 압축 방식 목록 등을 확인한다. 그 후에 클라이언트에게 자신이 생성한 랜덤데이터, 세션 ID와 함께 선택화 암호화 & 압축 방식을 클라이언트에게 보낸다. 세션 ID를 어디에 활용하는 것인지는 이따가 설명하도록 하겠다. - Certificate
서버는 클라이언트에게 자신의 인증서를 보내고, 클라이언트는 이를 검증한다. 이 과정에서 클라이언트는 인증서를 발급한 CA (Certificate Authority)의 신뢰성을 확인한다. 인증서에는 앞서 언급했듯이, CA의 정보, 서버의 암호화 방식, CA의 전자서명, 그리고 서버의 랜덤생성 데이터, 서버의 공개키 등이 들어간다. - Server Key Exchange
인증서 안에 서버의 공개키가 없는 경우, 대신 이 메세지를 보낸다. 인증서 안에 공개키가 이미 있다면 이 과정이 생략된다. 공개키를 보내는 이유에 대해선 다음 과정에서 설명한다. - ServerDone
Certificate까지 전송을 했으면, ServerDone 메세지를 클라이언트에게 전송한다.
여기까지 완료하면 클라이언트와 서버는 서로의 신원을 확인할 수 있다. 이제 남은 것은 클라이언트와 서버간의 암호화된 통신을 할 준비를 하는 것이다.
위의 이미지는 이후 클라이언트가 서버에게 보내는 메세지이다.
- Client Key Exchange
이 단계에서 클라이언트는 서버에게 pre-master secret이란 것을 전달한다. 클라이언트는 자신의 랜덤 데이터와 인증서에 담겨있던 서버의 랜덤 데이터를 이용하여 pre master secret를 생성한다.
pre master secret?
pre master secret은 뒤에 세션 단계에서 데이터를 실제로 주고 받을 때, 데이터들을 암호화하기 위해서 사용되는 것이다. 클라이언트와 서버는 동일한 pre-master secret을 이용하여 master secret을 만들고, 그 master secret을 이용하여 session key라는 대칭키를 만든다. 그리고 session key로 데이터들을 암호화해서 사용한다. 이를 다시 정리하면 서버와 클라이언트는 동일한 pre-master secret로 동일한 session key를 생성해서 데이터 암호화에 사용한다는 것이다.
따라서 클라이언트의 입장에서 무엇보다 중요한 것은 pre-master secret을 안전하게 전송해내는 것이다. (그렇지 않다면 제 3자가 통신을 가로챌 수 있다.) 이를 위해서 pre-master secret을 서버의 공개키로 암호화하는 방법을 사용한다. 그렇다면 서버는 암호화된 것을 자신의 개인키로 복호화함으로서 pre-master secret을 확인할 수 있다. 그럼 서버의 공개키는 어디있을까?
이전 과정에서 서버가 보낸 인증서나 Server Key Exchange 메세지에서 확인할 수 있다.
Q: 인증서의 어디에서 서버의 공개키를 볼 수 있나요?
A: 인증서를 살펴보면 '대상의 공개키' 필드가 있다. 이 부분에 나타난 값이다.
- Change Cipher Spec
handshake에 의해 협상된 암호화 방식이 이제부터 적용됨을 알린다. “나 이제 암호화해서 통신한다?”는 의미. - Encrypted handshake message(finished)
handshake가 종료됨을 알린다.
그러면 서버가 클라이언트에게 위와 같은 메세지를 보내고 실제 통신이 이루어진다. 해당 내용은 바로 이전에 설명했으므로 생략하겠다.
이제부터 application layer에서 발생한 모든 데이터들이 Session key에 의해 암호화된다. HTTP는 TLS로 인해 암호화되므로 아까와 달리 패킷 스니퍼 같은 것으로도 그 내용을 알기가 힘들다.
* 전체 과정을 간단히 나타내면 이렇다.
<여담>
Q: 근데 통신 보안을 위해선 비대칭키만을 사용해도 괜찮았을텐데, 왜 굳이 pre-master secret이란 걸 만들어가면서 session key를 사용할까?
A: 비대칭키 방식은 대칭키에 비해 암호화,복호화 시 연산이 많이 필요하다. 다시 말하면 데이터 패킷들을 전송할 때 마다 개인키로 암호화, 공개키로 복호화… 이렇게 반복하는 일은 비용이 크다. 따라서 일정 시간마다 대칭키인 session key를 만들어서 사용한다.
이것으로 HTTPS(TLS)의 실행과정에 대한 전반적인 설명을 마친다.
'웹 엔지니어 면접 질문 > 컴퓨터 네트워크' 카테고리의 다른 글
| HTTP에서 GET과 POST의 차이점 (0) | 2023.04.05 |
|---|---|
| 브라우저에 google.com을 쓰면 일어나는 일 (0) | 2023.04.05 |
| DNS 동작 과정 (0) | 2023.04.04 |
