https 동작 원리에 대하여

[ 인증서 발급 과정 ]

1. CA 기관으로부터 SSL 인증서 발급

인증된 CA 기관으로부터 SSL 인증서를 발급 받습니다.

(Let's Encrypt, Thawte SSL 등)

 

발급된 인증서에는 다음과 같은 정보가 있습니다.

- 발급대상 (예. example.com)

- 발급대상의 공개키 (예. 발급자로부터 인증받은 example.com 의 공개키)

- 발급자 (example.com 의 인증서를 발행한 인증기관(CA))

이러한 인증서의 주요 정보를 모아 SHA256 등의

해쉬 알고리즘을 이용하여 해쉬합니다.

이렇게 해서 나온 해쉬값을 인증서의 

Finger Print (지문) 이라고 합니다.

 

 

2. 인증서의 발급자 서명(디지털 서명)

인증서 발급자인 인증기관(CA)은 CA에서 소유한 private key(비밀키)로 

인증서의 Finger Print(지문)을 암호화 한 후, 그 결과값을

발급자 서명(디지털 서명, Digital Signing)으로 등록합니다.

 

즉, 인증서의 서명은 인증서의 주요 정보들을 해쉬한 값을

CA기관이 소유한 private key로 지문을 암호화한 값인 것입니다. 

 

이 때, Apache나 Nginx 등에 private key를 지정해주는 옵션이 있는데

이 때 지정해주는 private key와 CA기관 소유의 private key 는 다른 key 입니다.

 

최종적으로 인증서는 아래와 같은 내용들을 포함하게 됩니다.

- 발급대상 (예. example.com)

- 발급대상의 공개키 (예. 발급자로부터 인증받은 example.com 의 공개키)

- 발급자 (example.com 의 인증서를 발행한 인증기관(CA))

- 지문 (인증서의 주요 정보를 모아 SHA256 등의 해쉬 알고리즘으로 해쉬한 값)

- 발급자의 서명 (인증서의 해쉬된 지문을 CA기관이 소유한 private key로 암호화한 값) 

 

 

 

[ 인증서 반영 후 클라이언트, 서버 통신 과정 ]

1. 클라이언트(브라우저) -> 서버

클라이언트에서 서버로 요청을 보낼 때,

아래 데이터를 담아 요청을 보냅니다.

- 클라이언트(브라우저)에서 생성한 랜덤데이터

- 클라이언트(브라우저)에서 지원하는 암호화 알고리즘 목록

 

2. 서버 -> 클라이언트(브라우저)

서버는 요청온 클라이언트한테 아래 데이터를 담아 응답합니다.

- 서버에서 생성한 랜덤데이터

- 클라이언트에서 보낸 암호화 알고리즘 목록 중

  서버에서 사용할 암호화 알고리즘

- 인증서

 ㄴ 서비스 정보 (서버의 private key로 암호화 된 상태)

 ㄴ public key (CA기관에서 발급받은 공개키)

 

3. 클라이언트(브라우저) - 인증서 CA 기관 체크

클라이언트(브라우저)는 믿을 수 있다고 판단한

CA 목록을 가지고 있는데, 이 목록 중에서 서버로부터 받은

인증서의 발급기관(CA)이 존재하는지 체크합니다.

 

 

 

4. 클라이언트(브라우저) - 실제 CA 기관에서 발급한 인증서인지 체크

브라우저의 CA 목록에 인증서의 CA가 존재한다면,

해당 인증서가 정말 해당 CA 기관에서

발급된 인증서가 맞는지 확인 절차를 진행합니다.

앞서 인증서에는 다음과 같은 정보가 존재한다고 하였습니다.

- 발급대상 (예. example.com)

- 발급대상의 공개키 (예. 발급자로부터 인증받은 example.com 의 공개키)

- 발급자 (example.com 의 인증서를 발행한 인증기관(CA))

- 지문 (인증서의 주요 정보를 모아 SHA256 등의 해쉬 알고리즘으로 해쉬한 값)

- 발급자의 서명 (인증서의 해쉬된 지문을 CA기관이 소유한 private key로 암호화한 값) 

 

브라우저에는 이미 몇 몇 인증된 CA 기관으로부터 발행된 공개키가 

내장되어 있는 상태입니다. (번들키라고도 합니다.) 즉, 인증서의 디지털 서명 값이

이미 인증된 CA 기관으로부터 받은 공개키로 복호화가 된다면

그 인증서는 인증된 CA 기관으로부터 발급된 인증서라는 것이 증명되는 셈입니다.

(RSA 알고리즘에 의해 private key로 암호화 한 것은 public key로만 복호화 되고

public key로 암호화 한 것은 private key로만 복호화 되기 때문)

 

그렇기 때문에 브라우저에 이미 내장된 공개키로

인증서 서명 값을 복호화 시도하고 복호화 성공하면

해당 인증서는 신뢰할 수 있는 인증서가 되는 것입니다.

 

5. 클라이언트(브라우저) -> 서버

인증서의 신뢰성을 체크하였다면, 이제 통신에 사용할 Key를

클라이언트와 서버는 서로 공유하고자 합니다.

클라이언트는 자신이 생성했던 random 값과 서버로부터

응답받았던 random 값을 합쳐 세션키를 생성 후,

인증서의 public key로(브라우저 내장 public key 아님!) 서버와 합의된

암호화 알고리즘으로 암호화 한 후 서버에 전송합니다.

 

6. 서버 - session key 획득

클라이언트로부터 받은 암호화된 세션키를

자신의 private key로(CA기관이 소유한 private key 아님!) 복호화합니다.

 

7. 클라이언트(브라우저) <-> 서버 : 세션키 공유

클라이언트(브라우저)와 서버는 공유된 세션키를 이용해 대칭키 방식으로

데이터를 암호화/복호화 하여 통신합니다.

 

8. 통신 종료

통신이 끝나면 클라이언트와 서버에서 사용하던 세션키는 폐기합니다.

 

 

 

 

 

-- 본 글은 아래 내용과 각종 커뮤니티의 질문, 답변을 바탕으로 제가 재정리한 글입니다. 그렇기 때문에 잘못된 부분이 있을 수 있습니다.

-- 잘못된 부분이 있다면 댓글로 짚어주시면 감사하겠습니다. 

 

출처 : velog.io/@moonyoung/HTTPS%EC%9D%98-%EC%9B%90%EB%A6%AC

HTTPS의 원리

출처 : rsec.kr/?p=426

RSA 인증서 (Certification) 와 전자서명 (Digital Sign)의 원리

출처 : m.blog.naver.com/alice_k106/221468341565

154. [Security] SSL과 인증서 구조 이해하기 : CA (Certificate Authority) 를 중심으로