HTTPS 동작 과정

이 글은 HTTPS 원리에 대해서 여러 글을 보고 이슈에 대해 추측해서 정리한 주관적인 글이다. 때문에 잘못된 정보가 있을 수 있다. 

 

HTTPS란

HTTPS는 Hyper Text Transfer Protocol을 의미하는 HTTP에 Over Secure Socket Layer가 추가된 프로토콜을 말한다.

즉, 통신할때 보안이 적용된 계층(Layer)위에 HTTP가 동작하는 프로토콜을 의미한다. 

 

보안 계층은 SSL(Secure Socket Layer)과 TLS(Transport Layer Security)를 의미하는데 SSL은 넷스케이프에 의해 개발되어 넓게 사용되다가 관리 기구가 바뀐이후로 TLS로 이름이 바뀌었기 때문에 원리를 이해하는데 있어서는 SSL과 TLS를 같은 개념으로 인지해도 무방하다.

 

 

 

 

SSL/TLS은 OSI의 7계층에 어떤 계층에 속해있는것이 아닌, 전송계층과 응용계층 사이에 독립적인 계층을 구성한다. 

 

 

HTTPS는 이 SSL에서 데이터를 암호화해서 전송하고 복호화하기 때문에 HTTP에 비해 안전한 프로토콜이다. 그래서 대부분의 사이트들은 HTTPS를 적용하고 있고, 브라우저도 HTTPS가 적용된 사이트를 우선적으로 사용하길 권장한다.

 

SSL

SSL의 역할은 크게 2가지라고 생각한다.

 

1. 보안을 위한 데이터 암/복호화

2. 신뢰할 수 있는 사이트 인증

 

이를 이해하기 위해선 먼저 SSL에서 사용하는 암호화 방식과 SSL 인증서에 대해서 알아두어야 한다.

 

암호화

SSL에서 사용하는 암호화 방식은 2가지로 키를 이용해 암/복호화하는 방법이다. 개인적으로는 키는 어떠한 알고리즘을 의미하는거라고 생각한다.

 

대칭키

클라이언트와 서버가 대칭되는 같은 키를 가지고 있어 암호화와 복호화가 같은 키로 이루어지는 방식을 말한다.

 

암/복호화 알고리즘이 간단해서 상대적으로 속도가 빠르고 부하가 적다는 장점이 있지만,

하나의 키로 암/복호화가 이루어지기 때문에 키를 전달하는데 있어서 보안 이슈가 생길수 있는 단점이 있다.

 

공개키 (비대칭키)

공개키와 대칭키의 가장 큰 차이점은 공개키는 키가 2개라는 점이다.

A키와 B키로 이루어져있다고 가정했을때,

A키로 암호화를 하면 B키로 복호화를 할 수 있고, B키로 암호화를 하면 A키로 복호화를 할 수 있는 방식이 공개키 방식이다.

두 키가 짝을 이루기 때문에 보통 클라이언트에 전달하는 키를 공개키, 서버가 갖고있는 키를 개인키라고 많이 부른다. 

 

클라이언트에 전송하는 공개키로 암호화된 데이터는 서버의 개인키로만 복호화가 가능하기 때문에, 제 3자로 부터 키를 해킹당해도 데이터를 숨길 수 있는 장점이 있지만,

대칭키에 비해 상대적으로 속도가 느리다는 단점이 있다.

 

인증서

https에 관련된 인증서는 다양하게 있을 것 같지만 나는 3가지만 알고있다. 

모든 인증서가 그런건지는 사실 잘 모르지만, 내가 찾아봤던 여러 인증서들은 모두 공개키를 담고 있었다.

 

1. 루트(Certificate Authority) 인증서

CA라고 불리는 최상위 인증 기관에서 발행한 인증서로 CA 공개키를 담고 있다.

 

서버로부터 전달받은 SSL인증서가 신뢰할 수 있는지 인증하는 기능을 하며, 루트 인증서에 있는 CA 공개키를 사용해 해당 SSL 인증서를 복호화 한다고 한다.

 

윈도우의 인증서 관리나 브라우저 설정에 보안탭에서 인증서 관리를 보면 리스트를 확인할 수 있다.

 

SSL 인증서를 발급해준 CA가 리스트에 없는 경우에 신뢰할 수 없는 사이트라고 나오게 된다.

 

 

아래는 참고

---

윈도우의 인증서 관리에 되어있는 설정과 브라우저 설정의 인증서 관리에 되어있는 설정이 다르다.

https에 대해서 검색해보면 브라우저는 루트 인증서를 갖고있다는 말이 많이 나오는데, 혹시 브라우저가 가지고 있는 이 인증서 관리의 인증서 리스트가 윈도우 인증서 관리의 인증서 리스트와 다르진 않을까 해서 테스트를 해봤다.

윈도우 인증서 관리의 인증서 중에 하나를 지웠는데, 브라우저 인증서 관리에서도 동일하게 삭제되는 것을 확인했고

이로 인해 둘은 설정값만 다를 뿐 로컬 어딘가에 인증서가 저장된 디렉토리가 있을것으로 추측된다. 또한 그 인증서들은 윈도우의 cryptographic 서비스에 의해 관리된다고 한다.

---

 

2. SSL 인증서

클라이언트와 서버간 핸드쉐이킹으로 불리는 탐색 시 서버가 발급받아 클라이언트로 전달하는 SSL 인증서다.

서버가 가지고 있는 개인키와 짝을 이루는 공개키를 담고있으며 접속한 웹페이지가 신뢰할 수 있는 사이트인지 인증하는 기능을 한다.

 

뒤에서 설명하겠지만, SSL 인증서의 공개키가 서버로 전달할 대칭키를 암호화한다.

 

3. 중간 인증서

앞에서 SSL인증서가 신뢰성 있는지에 대해 루트 인증서가 인증을 한다고 했지만 이는 맞는 경우도 있고 조금은 틀린 경우도 있는데 SSL 인증서와 루트 인증서 사이에 중간 인증서가 존재하는 경우가 있기 때문이다.

 

내가 알기로 CA로 바로 인증을 받는 인증서들도 있겠지만 대부분은 이렇게 중간 인증서가 존재한다고 한다. 중간 인증서가 루트 인증서와 SSL 인증서 사이의 중개자 역할을 함으로, 더 높은 신뢰성과 데이터의 안전을 얻을 수 있다고 한다.

 

네이버의 SSL 인증서

인증서의 인증경로를 보면 중간 인증서를 확인할 수 있다.

캡처된 인증서 이미지의 중간에 빨갛게 밑줄쳐진게 중간 인증서다.

 

 

SSL 동작 과정

SSL 동작 과정은 대략 크게 아래 맥락이라고 생각한다.

 

- 서버가 클라이언트에게 SSL 인증서 전달

- 클라이언트가 대칭키 생성 및 SSL 인증서의 공개키로 암호화, 서버로 전달

- 서버는 가지고 있던 개인키로 전달받은 대칭키 복호화

- 대칭키로 통신

 

HTTPS 사이트들의 SSL 동작은

대칭키의 단점인 해킹 가능성을 대칭키를 공개키 방식으로 암호화 함으로써 보완하고,

대칭키를 통해 데이터를 암/복호화하여 속도를 높이는 하이드리드 방식을 사용하고있다.

 

 

 

HTTPS 동작을 검색하면 흔하게 나오는 이미지다. 이미지에 나와있는 과정 중 1번 ~ 6번 과정에 대해서 주관적으로 정리하려한다.

 

클라이언트가 서버에 접속하면서

 

1. 클라이언트가 랜덤 데이터(A)를 생성해 서버에 전달한다.

 

2. 서버는 응답으로 랜덤 데이터(B)를 생성해 SSL 인증서(공개키 포함)와 함께 클라이언트로 전달한다.

 

3. 클라이언트는 SSL 인증서의 CA 인증서(혹은 중간인증서)를 확인해 SSL에 대한 인증을 한다. CA인증서(혹은 중간 인증서)는 클라이언트 로컬에서 cryptographic services에 의해 관리되고 브라우저는 해당 인증서들에 대해 이미 설정되어있다.

 

SSL 인증서에 대한 인증이되어 신뢰할 수 있다고 판단되면, 랜덤 데이터 A와 B를 조합해 *대칭키(진)을 생성한다. 

 

* 대칭키(진)은 대칭키가 되기 직전이라고 가정

 

4. 대칭키(진)을 서버에 전송하는데 그냥 전달하기엔 위험 부담이 있기때문에 SSL 인증서에 있던 공개키로 암호화하여 서버에 전달한다.

 

5. 공개키로 암호화된 대칭키(진)을 서버가 전달받은 후 개인키로 복호화한다.

 

6. 클라이언트와 서버가 대칭키(진)을 대칭키로 생성한다.