포스트

http? https? SSL?

공부 배경

컴퓨터 공학 박사 과정을 진행하고있는 친구를 만나 얘기하면서, 개발자로서 요즘에 어떤걸 공부하면 좋을지 물어봤다.
그에 대한 친구의 대답은 바로 보안이였다. 안그래도 요즘 디도스며 뭐며 인터넷 보안 문제를 듣곤했는데, 이참에 조금씩 이에 대한 공부를 해보면 좋을 것 같았다.
그래서 우선 자주 접한 https://에 대해서 공부해 보려고 한다. httpshttp에 보안을 추가한 것이라고만 대강 알고는 있었는데, 제대로 찾아보고 정리하면서 공부해보겠다.


image

http 란?

HTTP란 HyperText Transfer Protocol의 약자로, 서로다른 컴퓨터 시스템들 사이에서 통신을 주고받게 하는 가장 기본적인 프로토콜이다.
이는 주로 서버와 브라우저사이에서 데이터를 주고받을 때 가장 많이 사용된다.


https 란?

그렇다면 https란 무엇일까?
HyperText Transfer Protocol Secure
Secure 이라는 단어만 봐도 뭔가 보안과 연관되어있을 것 같다.
HTTP와 SSL을 결합한 프로토콜이다. HTTP는 웹에서 정보를 주고받기 위한 가장 기본적인 프로토콜이지만, 주고 받는 데이터가 암호화되어 있지 않기 때문에, 데이터를 주고받는 과정에서 관련 없는 제 3자가 이를 낚아채서 악용할 수도 있다. 이를 막기 위해 우리는 SSL이라는 프로토콜을 추가로 사용하여 암호화/복호화 작업을 한다.

그럼 SSL은 뭘까? 다음에서 알아보자.


SSL

SSL은 Secure Sockets Layer의 약자로, NetScape Communications Corporation 에서 웹 서버와 웹 브라우저간의 보안을 위해 만든 프로토콜이다.
SSL은 대칭키 방식비대칭키 방식(공개키/개인키)을 기반으로 사용한다.

자세한 이해에 앞서 대칭키 방식비대칭키 방식에 대해 알아야 할 것 같다.

대칭키 방식

image

대칭키 방식이란 데이터를 주는 쪽과 받는 쪽이 대칭으로 똑같은 키를 가지고 데이터의 암호화/복호화를 수행하는 방법이다. 서로 가진 같은 대칭키를 이용해 데이터를 암호화해서 전송을 하고, 암호화 한것과 똑같이 대칭키를 이용해 복호화를 통해 데이터를 받아 볼 수 있는 것이다. 이러면 대칭 키가 없는 제 3자는 암호화된 데이터를 읽을 수도, 이용할 수도 없다.

image

대칭키 방식은 서로 대칭키를 가지고 있다는 가정에서 암호화 복호화 과정이 쉽다는 장점이 있지만, 문제는 이 대칭키를 전달하는 과정에 있다. 대칭키를 공유하고 있기 위해서는 결국에 한쪽에서 이 키를 한번 전송해야 하는데, 중간에 이것을 제 3자가 낚아 챈다면 결국 보안에 문제가 될 수 있다.


비대칭키 방식(개인키/공유키)

image

비대칭키 방식이란 서로 다른 키(공개키와 개인키)로 데이터의 암호화/복호화를 수행하는 방법이다. 데이터를 전송하기 위해 암호화 할 시에는 공개키를 사용하고, 이를 받아 보기 위해 복호화 시에는 개인키를 사용하는 것이다.
image

공개키는 말 그대로 공개된 키이기 때문에 외부에 유출이 되어도 상관 없는 키이다. 암호화된 데이터의 복호화는 개인키로만 가능하기 때문에 공개키를 전송하는 과정에 문제가 없다. 하지만 이는 암호화/복호화 연산 시간이 더 소요된다. 즉, 비용이 크다는 단점이 있다.


SSL 정리

 대칭키 방식비대칭 키 방식
장점암호화/복호화가 쉬움키(공개키)를 공유하는 과정에 문제가 없음
단점키(대칭키)를 공유하는 과정에 문제가 발생할 수 있음암호화/복호화 비용이 크다.

따라서, SSL은 대칭키 방식과 비대칭키 방식을 적절히 혼합해서 사용한다.

SSL 통신 과정의 예를 살펴보자.


SSL 통신 과정

SSL은 비대칭키 방식으로 대칭키를 전달한다. 쉽게 말해서, 공유 과정에 문제가 없는 안전한 방법(비대칭키 방식)으로 키(대칭키)를 공유하여, 그 키로 빠르고 쉽게 데이터를 교환한다는 것이다. 이를 그림으로 살펴보자.

1. 우선, A에서 B로 접속 요청을 보낸다.
image


2. 그럼 B는 A에게 자신의 공개키를 보낸다.
image


3. A는 B의 공개키를 이용하여 대칭키를 암호화하고, 암호화된 대칭키를 B에게 보낸다.
image


4. B는 전달 받은, 자신의 공개키로 암호화된 대칭키공개키로 복호화한다.
image


5. A와 B는 이제 공유된 대칭키를 이용하여, 데이터를 빠르고 쉽고 안전하게 교환할 수 있게 되었다.
image


실제 인증된 사이트를 접속할 때는 어떻게 이루어 질까?

https가 실제로 구현되는 과정은 훨씬 더 복잡하다. 우선 데이터를 요청하는 측을 클라이언트, 데이터를 전송해주는 측을 서버라고 하는데, 서버는 대칭키를 공유하기 위한 공개키를 생성해야한다. 클라이언트에게 이 공개키가 정품인지 아닌지를 확인시켜주어야 하는데, 이때 이를 인증해주는 공인된 민간기업을 CA(Certificate Authority)라고 한다.

1. 우선 서버는 자신이 제공하는 사이트가 안전함을 확인 시켜주기 위한 인증서가 필요하기 때문에, 사이트 정보를 담은 데이터와 공개키를 CA(인증기관)에 전달한다.
image


2. CA에서는 사이트 정보를 확인하고, 그 데이터를 자신의 개인키로 암호화하여 일종의 인증서를 발급한다.
image


3. 그리고 CA는 자신의 공개키를 클라이언트에게 제공하는데, 이는 우리가 사용하는 브라우저(Chrome,Safari,Firefox,Edge 등)에 내장이 되어있다.

image


4. 이제 클라이언트와 서버가 데이터를 주고 받을 차례다. 아직 클라이언트는 서버가 제공하는 사이트를 신뢰하지 못한다. 그래서 일종의 탐색과정을 거치는데, 이를 HandShake라고 한다.
클라이언트는 무작위 데이터를 보내고, 서버도 무작위 데이터와 함께 인증서를 함께 보낸다.
image


5. 클라이언트는 브라우저에 내장된 CA의 공개키를 이용해 CA의 개인키로 암호화 되어있는 인증서를 복호화 할 수 있고, 복호화된 인증서는 서버의 공개키가 포함되어 있다.
image

만일 CA의 인증서가 없는 사이트의 경우에는 브라우저 주소창에는 이렇게 출력될 것이다.
image


6. 이제 클라이언트는 이전에 HandShake통해 얻은 두개의 무작위 데이터를 혼합하여 임시 키(Session Key / 세션키)를 만들고, 이를 인증서 복호화를 통해 얻은 서버의 공개키로 암호화 해서 서버로 보낸다.
image


7. 서버의 공개키로 암호화된 임시 키(세션키)는 서버의 개인키로 복호화 되고, 이제 임시 키는 클라이언트와 서버의 대칭키가 되어, 대칭키 방식으로 데이터를 주고 받게 되는 것이다.
image


정리

Http 보다 Https를 사용하는 이유

  1. 보안성 : 데이터 교환에 있어서 제 3자의 불법적 개입을 막는다.
  2. 접속한 사이트가 믿을 만한(인증된) 곳인지 알 수 있다.
  3. SEO(Search Engine Optimization) : 검색 엔진 최적화
    구글은 Https를 사용하는 웹사이트에 가산점을 부과하여, 검색 엔진에 더욱 빈번하게 노출되게 한다.(여러 사용자들이 우선적으로 볼 수 있도록 한다.)
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.