[Web 기초] HTTPS의 동작 원리 (feat. 와이어샤크)

 

오늘은 HTTPS의 개념과 어떻게 동작하는지 정리해보았습니다.

 

HTTP의 보안처리가 된 버전이 HTTPS인것은 다들 아실것입니다.
그리고 요즘은 HTTPS는 웹의 기본스펙이라고 봐도 문제가 없다고 생각됩니다.

 

API를 사용하려고하여도 HTTPS가 안되어있으면 API를 신청, 사용할 수 없는 경우도 있으며

UX에도 영향을 끼친다고 생각합니다.

 

예를들어 은행사이트에 접속하였는데 아래와 같은 이미지가 주소창에 있다면 사용자에게 좋은 경험을 제공하지 못할 것 입니다.

HTTPS는 무엇인가?

 

HTTPS는 HyperText Transfer Protocol Secure의 약자이며 HTTP의 보안 버전입니다.

 

HTTPS는 TCP 위에 SSL/TLS 층을 추가하여 암호화, 인증 그리고 무결성 보장을 통해 더 안전하게 만들어주는 프로토콜입니다.

위 그림에 나오는 프로토콜에대해서 잘 모르신다면 mysterico.tistory.com/29?category=938083 이 게시물을 참조하시면 도움이 될 것 입니다.

 

본격적으로 HTTPS의 동작방식을 알아보기전에 먼저 3가지 개념을 먼저 알고 가셔야합니다. 

 

1. 대칭키

 

암호화에 쓰이는 키와 복호화에 쓰이는 키가 동일한 기법입니다.

 

 

만약 클라이언트와 서버가 대칭키 방식으로 통신을 한다면 클라이언트도 키를 가지고 있어야합니다.

클라이언트에게 키를 전달하기도 위험하며 클라이언트의 소스코드는 누구든지 열어볼 수 있으므로 가지고 있기도 굉장히 위험합니다.

즉, 원거리에서 대칭키를 안전하게 전달하는 것이 매우 어렵습니다.

 

2. 공개키 (비대칭키)

 

공개키와 개인키(비밀키)라는 2가지 키를 사용하는 기법입니다.

 

공개키는 말그대로 누구나 획득할 수 있는 공개된 키를 뜻합니다. 정보를 보내는쪽(클라이언트)은 이 키를 가지고 데이터를 암호화해서 전송합니다.

 

개인키(비밀키)는 공개키로 암호화된 데이터를 복호화 할 수 있는 키로써 자신(서버)만이 가지고 있는 키입니다.

 

 

이 방법은 안전하게 데이터를 주고받을 수 있게 만들어주지만 속도가 느리다는 단점이있습니다.

 

3.  인증서와 CA(Certificate authority)

 

SSL을 적용하기 위해서는 인증서라는 것이 필요합니다.

 

인증서의 내용은 크게 2가지로 구분할 수 있습니다.

1. 서비스의 정보 (CA, 도메인 등등)
2. 서버 측의 공개키 (공개키의 내용, 공개키의 암호화 방식)

이 인증서를 발급해주는 기업을 CA라고 합니다. 인증서가 보안에 관련된 것인 만큼 이 CA는 영향력있고 신뢰할수 있는 기업에서만 가능합니다.

 

그리고 우리의 브라우저는 CA리스트를 미리 가지고 있습니다. CA목록에 있는 기업을 공인된 CA라고 하며 목록에 없는 기업을 사설CA라고 하며 이를 통해 인증서를 발급받으면 아래와 같은 경험을 하실 수 있습니다.

이 상태는 https는 적용이 되어있지만 사용자에게 좋은UX를 제공하지 못하므로 개발 이나 사내 백오피스가 아니라면 지양하는것이 좋을것 같습니다.

 

 

HTTPS 통신과정 및 원리

먼저 간단하게 들여다보면 동작방식은 앞서 말씀드린 대칭키와 공개키(비대칭키) 방식을 전부 사용하는 하이브리드 방식입니다.

데이터 전송을 위해 대칭키 방식을 사용하며 대칭키를 안전하게 전달하기 위해 공개키 방식을 사용합니다.

 

아래 그림을 보면서 더 자세하게 설명해보겠습니다.

 

 

1. Client Hello

 

브라우저 마다 지원하는 암호화 알고리즘과 TLS 버전이 다르므로 해당 정보를 전송하며, 난수 값을 생성하여 전송합니다.

와이어샤크 패킷 이미지

 

2. Server Hello

 

사용할 TSL 버전, 사용할 암호화 알고리즘, 난수값을 전송합니다.

와이어샤크 패킷 이미지

 

3. Certificate

 

CA로 부터 발급받은 인증서를 전송합니다.

와이어샤크 패킷 이미지

 

4. Server Key Exchange

 

키 교환에 필요한 정보를 제공합니다. 만약 필요하지 않으면 이 과정은 생략이 가능한데, 예를 들어 키교환 알고리즘을 Diffie-Hellman으로 사용한다면 소수, 원시근 등이 필요하므로 이것을 전송합니다

출처: https://reakwon.tistory.com/106

와이어샤크 패킷 이미지

 

5. Certificate Request

 

서버가 클라이언트를 인증해야할때 인증서를 요구하는 단계입니다. 요청하지 않을수도 있습니다.

 

6. Server Hello Done

 

7. Client Key Exchange, Change Cipher Spec

 

pre-master-key 라는 것을 전송합니다. 이 키는 1,2 단계에서 생성한 난수를 조합하여 생성하게되며 대칭키로 사용하게될 예정입니다. 그러므로 안전한 전송을 위해서 공개키 방식을 사용하여 전송합니다.

와이어샤크 패킷 이미지

 

8.  Change Cipher Spec

 

클라이언트로 부터 전송받은 pre-master-key를 정상적으로 복호화 후 master-key(대칭키)로 승격 후 보안 파라미터를 적용하거나 변경될때 보내는 알림입니다.

와이어샤크 패킷 이미지

 

위 과정을 통해서 공개키 방식으로 대칭키를 안전하게 설정하여 데이터를 송, 수신하게됩니다.

 

각각의 방식의 장점을 사용하여 단점을 보완하여 만든것이 HTTPS 입니다.