[스터디] 우리는 어떻게 다양한 사이트를 여행 다닐 수 있을까 - (3) HTTPS 프로토콜의 핵심, SSL 인증서

Seungrok Yoon (Lethe)·2021년 8월 25일
2

스터디 

목록 보기
3/6

[오늘의 주제] HTTPS 프로토콜의 핵심, SSL 인증서

1. HTTPS 와 HTTP의 가장 큰 차이는 보안!

HTTP 통신에서는 값이 평문으로 전송이 된다. 이는 내가 서버로 전송하는 모든 정보들이 네트워크 상에서 중간에 제3자에 의해서 감청 및 위/변조될 수 있음을 의미한다. 이것은 HTTP의 치명적인 보안상 단점이다. 만약 온라인 쇼핑 사이트에서 물건을 사서 결제를 할 때, 내 민감한 금융정보가 유출될 수도 있다면, 그 사이트를 마음놓고 이용할 소비자는 아무도 없을 것이다. 금융정보가 아니더라도, 인터넷 사이트 로그인을 위한 비밀번호조차 평문으로 전송되어 유출될 경우에는 문제가 심각해 질 수 있다.

이러한 HTTP의 보안상의 문제점을 보완하는 버전으로서 HTTPS(Hypertext Transfer Protocol Secure)가 등장하게 되었다. HTTPS는 기존 TCP/IP 프로토콜과 HTTP 사이에, 암호화 레이어를 추가하여 보안을 강화한 HTTP 프로토콜로서, SSL/TLS 레이어 프로토콜을 통해 클라이언트와 서버 간의 모든 통신을 암호화 한다. 좀 더 정확히 이야기하자면 HTTP Header는 암호화하지 않고, HTTP Body 부분에 들어가는 콘텐츠만을 암호화 한다. 이를 위해 HTTPS는 추가적인 인증 절차를 요구하며, 복호화 없이 HTTPS의 정보를 중간에서 볼 수 있는 방법은 아직까지 존재하지 않기 때문에, 보안이 굉장히 뛰어나다고 말할 수 있다.

즉 HTTPS = HTTP + SSL!

SSL(Secure Sockets Layer)을 적용하기 위해서는 SSL/TLS인증서(SSL인증서)와 CA(Certificate Authority)가 필요하다. CA는, SSL인증서를 기준으로 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 확인해주는 공인된 회사들을 의미한다. 노턴라이프록, 코모도와 같은 회사들이 CA로서의 역할을 수행하고 있다.

브라우저는 CA의 리스트를 가지고 있고, 이들의 공개키를 가지고 있다. SSL인증서는 제 3자인 CA로부터 서버와 클라이언트의 인증을 하는데 사용된다. SSL인증서를 활용한 인증 과정은 조금 이따가 설명 하도록 하겠다.


이미지출처

2. SSL인증서를 이해해보자~!

SSL인증서 동작 원리를 온전히 이해하기 위해서는 암호화 방식을 이해할 필요가 있다.

먼저 가장 단순한 (1)대칭키 암호화 방식, 그 다음 대칭키 암호화 방식의 단점을 획기적으로 개선한 (2)공개키 암호화 방식, 그리고 (3)마지막으로 제 3자(CA, Certificate Authority)의 개입으로 이루어지는 SSL 인증서를 이용한 HTTPS 통신과정(공개키+대칭키 혼합 사용)에 대한 설명을 진행하겠다.

(1)대칭키 암호화 방식이란?

대칭키 방식의 단점

  • 암호를 주고 받는 사람들 사이에 대칭키를 전달하는 것이 어렵다.
  • 다수의 클라이언트와 통신할 시에는 다수의 대칭키를 관리해야 하는 어려움이 있다.
    -> 이에 공개키 방식이 등장.

(2)비대칭키 암호화 방식으로 더 안전한 통신을! (공개키 암호화 방식)

A(공개키)로 암호화(encryption) 한 정보는 B(개인키)로 복호화(decryption)가 가능! 그 반대도 가능!

공개키 방식은 두개의 키를 갖게 되는데 A키로 암호화를 하면 B키로 복호화 할 수 있고, B키로 암호화하면 A키로 복호화 할 수 있는 방식이다. 이 방식에 착안해서 두개의 키 중 하나를 서버만 가지고 있어 외부에 노출시키지 않는 비공개키(private key, 개인키, 비밀키라고도 부른다)로,

나머지 하나는 외부의 타인에게 제공하는 공개키(public key)로 지정한다.

공개키를 제공 받은 클라이언트는 공개키를 이용해서 정보(평문)를 암호화한다. 그리고 이 암호화한 정보를 비공개키를 가지고 있는 서버에 전송한다.

아까 말했듯이, 비공개키의 소유자인 서버는 공개키로 암호화된 정보를 복호화하여 원래 정보가 무엇이었는지 알 수 있다. 공개키로 암호화한 정보는 공개키로 복호화 할 수 없고, 개인키로 암호화한 정보는 개인키로 복호화 할 수 없기 때문에, 공개키가 유출되어도 개인키를 모른다면 공개키로 암호화한 내용은 알 수 없기에 안전하다.

이 방식은 두 가지 효과를 일으킨다.

  • 데이터의 안전함을 보장(클라이언트에서 공개키로 암호화하여 서버에게 전달 시):
    공개키로 암호화된 정보는 오로지 개인키를 지닌 서버만이 복호화 할 수 있기 때문에, 클라이언트 측에서 민감한 정보를 서버 측에 전달하더라도 안전하다.
  • 데이터 제공자(서버)의 신원을 보장.(서버에서 개인키로 암호화하여 공개키로 클라이언트에게 정보를 전달 시): 서버 쪽에서 암호화한 정보는 곧 공개키로 복호화가 될 수 있다. 이 말은, 역으로 말해, 공개키로 복호화가 될 수 있는 암호화된 정보를 만든 개인키를 지닌 서비스 제공자가 클라이언트임을 보장하는 것과 같다. 이러한 것을 전자 서명이라고 부르고,이를 통해 클라이언트 측에서는 올바른 서비스 제공자에게 요청을 보냈음을 확인해 줄 수 있다. 대표적인 공개키 알고리즘으로는 RSA, Elgamal 등이 있다.

공개키 방식을 이용한 SSL 인증서!

SSL 인증서란 클라이언트와 서버간의 통신을 제 3자가 보증화 해주는 전자화된 문서이다.

인증서의 목표는 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버인지를 판단하고 SSL 통신에 사용될 공개키를 클라이언트에게 전달하는 것이다. 위에서 언급한대로 SSL인증서에는 두가지 내용이 들어가는데 첫번째는 서비스의 정보(CA, 도메인) 두번째는 서버측 공개키이다.
https://hanjungv.github.io/2017-11-07-1_CS_SSL/

클라이언트(브라우저)-SSL인증서(CA)-서버

클라이언트의 요청이 있고 나서, 서버는 SSL 인증서를 제공한다. 이 인증서에는 (1)서버측의 공개키(서버측은 사전에 HTTPS 통신을 지원하기 위해 CA회사에게서 SSL 인증서를 구매한다)와 공개키의 암호화 방법,(2) 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등등)를 담고있다. 이 인증서는 CA의 개인키로 암호화가 되어 있는 상태이다.

브라우저는 이 인증서를 발급한 CA가 자신의 CA리스트에 있는지 확인한다.

만약 CA가 브라우저의 리스트에 존재한다면, CA의 해당 공개키를 이용해서 인증서를 복호화한다. 복호화가 된다면 이 인증서는 CA의 비공개키에 의해 암호화 되었다는 것을 알 수 있다.

(3) HTTPS 는 공개키 암호화 방식과 대칭키 암호화 방식을 혼합해서 사용한다!

HTTPS 에서도 HTTP 에서 처럼 서버와 클라이언트 사이에 핸드쉐이크를 진행한다.
그리고 이 핸드쉐이크 과정에서 사실 HTTPS는 비대칭키와 대칭키 암호화 방식을 혼합해서 사용한다!

혼합하여 사용하는 이유는, 공개키 방식은 대칭키 방식에 비해서 속도가 매우 느려서, 전자 서명이나 간단한 메시지 암호화 등에는 사용할 수 있지만 실시간 암호화 통신에서는 사용할 수가 없다

그러면 이제 HTTPS Handshake가 어떤 과정을 거쳐 진행되는지, 아래 이미지와 설명으로 살펴보자.

  • (1) client Hello: SSL로 암호화된 페이지를 요청하게 된다. (일반적으로 https://가 사용된다). 또한 client에서 SSL버전 정보와 지원하는 암호화 방식, 무작위 바이트 문자열(이후에 사용하게 되는 중요한 데이터)이 포함 되어 전달 된다. 이미 SSL handshake를 했었다면 세션을 재사용 할 수 있다.

  • (2)server Hello: 지원하는 암호화 방식 중 서버에서 어떤것을 사용할 지, 세션 ID, 서버측에서 생성한 무작위 바이트 문자열을 전송합니다. 클라이언트에서 인증서를 요구하게 되면 SSL 인증서를 전송하게 됩니다.

  • (3)인증서를 받게 되면 위에서 언급했던 방식(브라우저가 CA를 검색)로 신뢰할 수 있는 사이트 인지 판단하게 됩니다.이 과정을 통해 클라이언트는 공개키를 얻게 됩니다.
    ------------------------------공개키 방식으로 암호화 ----------------------------

  • (4)이후 클라이언트는 자신이 만든 무작위 바이트 문자열과 서버쪽에서 전송된 무작위 바이트 문자열을 조합하여 pre master secret키를 생성합니다. 이 키는 이후 데이터를 주고 받을 때 대칭키 방식을 사용할 때 사용하게 됩니다. 이 pre master secret키를 서버로 전송할 때 인증서에서 받았던 키를 이용하여 공개키 방식 암호화를 하게 됩니다. 그리고 서버쪽으로 전송하게 됩니다.

  • (5)서버쪽에서는 수신한 pre master secret키를 비밀키를 이용하여 복호화 하여 얻게된다.
    ----------------------------공개키 방식으로 복호화 ----------------------------
    -------------------------대칭키 방식으로 암호화/복호화 통신 -------------------

  • (6)server client 둘 다 일련의 과정을 거쳐 pre master secret키를 master key로 만들게 되고 이 master key를 이용하여 session key를 만들게 된다. 이후 데이터를 주고 받을 떄 session key를 대칭키 방식으로 이용하여 통신하게 됩니다.

  • (7)통신이 끝나면 세션키를 폐기합니다.
    참조1 참조2

3.생각해보기!

사용자 입장에서의 HTTPS의 장/단점.

  • HTTPS는 네트워크 상에서 열람, 수정이 불가능하므로 인터넷을 이용하는데 안전하다.
  • 그렇지만 HTTPS는 추가적인 인증 작업을 수행해야 하는 까닭에, HTTP보다 상대적으로 느리다.

공급자 입장에서의 HTTPS 장/단점

  • HTTP로 민감한 정보를 다룰 때는 항상 변조, 해킹 가능성을 생각해야 하기 때문에, HTTPS를 사용함으로써 보안에 대한 리스크를 줄일 수 있다.

  • HTTPS는 설치 및 인증서를 유지하는데 추가 비용이 든다.

  • HTTP는 HTTPS보다 트래픽이 적게 발생한다. 다시 말해 HTTP는 상대적으로 적은 비용으로 유지 가능하다.

4.참조

profile
안녕하세요 개발자 윤승록입니다. 내 성장을 가시적으로 기록하기 위해 블로그를 운영중입니다.

0개의 댓글