HTTPS와 SSL 인증서

컴퓨터(클라이언트)와 컴퓨터(서버)가 네트워크를 이용해서 

통신을 할 때는 3가지 단계로 진행된다.

악수 -> 전송(세션) -> 세션 종료

HTTPS에서 위 3가지 단계가 어떻게 이뤄지는지 정리해봤다.

■HTTP vs HTTPS

HTTP는 Hypertext Transfer Protocol의 약자다.

즉 Hypertextdls HTML을 전송하기 위한 통신 규약을 의미한다.

HTTP는 암호화를 하지 않은 채 데이터를 전송한다.

따라서 HTTP 방식으로 주고 받는 메시지(패킷)는 유출되기 쉽다.

---

HTTPS는 Hypertext Transfer Protocol over Secure Socket Layer의 약자다.

즉 보안이 강화된 HTTP라고 할 수 있다.

■HTTPS vs SSL

HTTPS와 SSL을 같은 의미로 이해하고 있는 경우가 많다.

이것은 맞기도, 틀리기도 하다.

마치 인터넷과 웹을 같은 의미로 이해하는 것과 같다.

(인터넷 위에서 돌아가는 서비스 중의 하나가 웹)

HTTPS는 SSL프로토콜 위에서 돌아가는 프로토콜이다.

■SSL과 TLS

넷스케이프가 발명한 SSL이 점차 폭넓게 사용되다가, 

표준화 기구인 IETF의 관리로 변경되면서 TLS라는 이름으로 바뀌었다.

TLS 1.0은 SSL 3.0을 계승한다.

(하지만 TLS라는 이름보다 SSL이라는 이름이 훨씬 많이 사용되고 있다.)

■SSL 디지털 인증서

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

클라이언트가 HTTPS 방식으로 서버에 접속하면 곧바로 서버는 클라이언트에게

이 인증서 정보를 전달한다. 클라이언트는 이 인증서 정보가 신뢰할 수 있는 것인지를

검증(handshake) 한 후에 다음 절차를 수행하게 된다. (본격적인 데이터 전송)

SSL과 SSL 디지털 인증서를 이용했을 때의 이점은 아래와 같다.

• 전송되는 데이터가 공격자에게 노출되는 것을 막을 수 있다.
  
  
• 클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버인지를 판단할 수 있다.
  
  
• 통신 내용의 악의적인 변경을 방지할 수 있다.
  

■SSL에서 사용하는 암호화의 종류

SSL의 핵심은 암호화다.

SSL은 두 가지 암호화 기법을 혼용해서 사용하고 있다.

바로 대칭키, 공개키 기법이다.

대칭키는 성능이 좋지만 보안이 취약하고

공개키는 보안이 좋지만 성능이 취약하다. 

그래서 혼용하여 사용된다.

■대칭키

남한과 북한이 축구 경기를 한다.

경기 도중, 남한팀의 감독은 전술을 바꾸기 위해 

크게 소리를 질러서 선수들에게 전술을 변경하도록 지시한다. 

그런데 전술을 너무 솔직하게 전달한 나머지 북한팀 감독에게까지 내용이 

들려버렸다. 북한팀 감독은 남한팀의 작전을 어떻게 이용할지 행복한 고민에 빠진다.

위 사례가 대칭키 방식의 통신과 같다고 할 수 있다.

두 팀 모두 한국어라는 공통어(대칭키)를 사용하기 때문에 

북한팀이 남한팀의 작전(데이터)을 쉽게 파악(복호화)하고 이용할 수 있다.

남한팀의 감독과 선수끼리는 빠르게 의사전달을 할 수 있었지만

같은 언어를 사용하는(대칭키 유출) 북한팀에게 도청당해버렸다.

■공개키

남한과 북한이 축구 경기를 한다.

경기 도중, 남한팀의 감독은 전술을 바꾸기 위해 손으로 특정 제스쳐를 취했다. 

북한이 같은 언어를 공유하기 때문에, 언어로 전술을 전달하면 누출될 우려가 있었다.

따라서 몸짓으로 선수들에게 의사를 전달하는 방법을 택했다. 

그리고 이 제스쳐는 경기 시작 전 선수들과 미리 맞춰놓은 신호였다.

북한팀 감독은 남한팀 감독이 이 제스쳐를 취하는 것을 보았지만 

그것이 무슨 뜻인지 몰랐기 때문에 남한팀의 전략을 알 수 없었다.

남한팀 선수들은 약속된 전략을 확인했고 그대로 실행에 옮겼다.

위 사례가 공개키 방식의 통신과 같다고 할 수 있다.

제스쳐(공개키)는 누구나 알아도 상관없다. 

제스쳐가 뜻하는 전략(비공개키)은 경기 전 미리 약속했던 

당사자들인 남한팀 감독과 선수들만 알고 있기 때문이다.

---

사실 엄밀히 말하면 위 사례로는 공개키를 완전히 설명하지는 못한다.

왜냐하면 위 사례의 전략(비공개키)는 그 자체로 목적이지만

공개키 방식에서의 비공개키는 목적을 위한 수단이다. 

단계가 하나 더 있는 것이다. 

자세히 정리해 보자면, 공개키 방식은 두개의 키를 갖는다.

A키로 암호화를 하면 B키로 복호화 할 수 있고

B키로 암호화하면 A키로 복호화 할 수 있는 방식이다.

A와 B 중 하나를 비공개키(개인키, 비밀키)로 지정하고, 나머지를 공개키로 지정한다.

비공개키는 자신(서버)만이 가지고 있고, 공개키를 타인(클라이언트)에게 제공한다.

공개키를 제공받은 클라이언트는 공개키를 이용해서 정보를 암호화한다.

암호화한 정보를 비공개키를 가지고 있는 서버에게 전송한다. 

비공개키를 소유하고 있는 서버는 이 비공개키를 이용해서 암호화된 정보를 복호화 한다.

공개키가 유출돼도 괜찮다. 비공개키를 알아야 복화화 할 수 있기 때문이다.

외부의 누군가가 공개키를 탈취해 암호화된 정보를 복호화해서 사용하는것은 

아무런 문제가 되지 않는다. 왜냐하면 오히려 이러한 특성을 통해 클라이언트에게 

'이 서버는 확실히 비공개키를 갖고있긴 하군' 하고 안심을 시켜줄 수 있다.

이를 '전자 서명' 이라고 한다. 

외부의 누군가가 공개키를 가지고 복호화를 해봤자 '서버가 비공개키를 갖고 있다'는 

것을 확인하는 것 이외에는 달리 할 것이 없다.

■SSL 인증서의 역할

SSL 인증서의 역할은 다소 복잡하다. 

따라서 인증서의 매커니즘을 이해하기 위해 몇 가지 지식들을 알고 있어야 한다. 

인증서의 기능은 크게 두가지다.

》 인증서를 통해, 클라이언트는 접속한 서버가 신뢰할 수 있는 서버임을 확인할 수 있다.

》 인증서를 통해, 클라이언트는 SSL 통신에 사용할 공개키를 얻을 수 있다.

■CA

SSL 인증서는 클라이언트가 접속한 서버가 의도한 서버가 맞는지를 보장하는 역할을 한다.

이러한 보장을 도와주는 민간 기업들이 있다. 

이 기업들을 CA(Certificate authority) 혹은 Root Certificate 이라고 부른다.

CA는 신뢰성이 엄격하게 공인된 기업들이다. 대표적인 기업들은 아래와 같다.

- Symantec (VeriSign, Thawte, Geotrust)

- Comodo 

- GoDaddy 

- GlobalSign 

(참조하는 글이 꽤 오래 전에 작성된 터라 (2013년) 현재(2020년)와는 차이가 있을 수 있다.)

SSL을 통해서 암호화된 통신을 제공하려는 서비스는 CA를 통해서 인증서를 구입해야 한다.

---

개인 개발 등의 사적인 목적을 위해서 SSL의 암호화 기능을 이용하려 한다면

자신이 직접 CA 역할을 할 수도 있다. 물론 이것은 공인된 인증서가 아니기 때문에

브라우저는 아래와 같은 경고를 출력한다

공인된 CA가 제공하는 인증서를 사용한다면 브라우저의 주소창은 아래와 같은 모습이 된다.

■SSL 인증서의 내용

SSL 인증서에는 다음과 같은 정보가 포함되어 있다.

1. 서비스의 정보(CA, 서비스 도메인 등)

2. 공개키(공개키의 내용, 암호화 방법 등)

1번은 접속한 서버가 의도한 서버가 맞는지에 대한 내용이고

2번은 서버와 통신을 할 때 사용할 공개키와 그 공개키의 암호화 방법들에 대한 내용이다.

(1, 2번의 내용들은 서버가 CA로부터 인증서를 구입할 때 등록하고 제출해야한다)

CA는 자신의 CA 비공개키를 이용해서 서버가 제출한 인증서 정보들을 암호화한다.

CA의 자신의 비공개키는 절대로 유출되어서는 안된다. 

(디지노타 라는 CA 회사가 비공개키가 유출되는 바람에 파산되기도 했다.)

■브라우저는 CA를 알고 있다.

클라이언트의 브라우저는 내부적으로 CA의 리스트를 미리 파악하고 있다.

브라우저의 소스코드 안에 CA의 리스트가 들어있다.

이 리스트에 포함되어야만 공인된 CA가 될 수 있는 것이다. 

CA의 리스트와 함께 각 CA의 공개키를 브라우저는 이미 알고 있다.

■SSL 인증서가 서비스를 보증하는 방법

1. 브라우저가 서버에 접속할 때 서버는 제일 먼저 인증서를 제공한다.

2. 브라우저는 이 인증서를 발급한 CA가 자신이 내장하여 소유중인 

CA 리스트에 포함돼 있는지 확인한다.

3. 포함되어 있으면 해당 CA의 공개키를 이용해서 인증서를 복호화한다.

CA의 공개키를 이용해서 인증서를 복호화할 수 있다는 것은 

이 인증서가 CA의 비공개키에 의해서 암호화 된 것이라고 할 수 있다. (전자 서명)

해당 CA의 비공개 키를 가지고 있는 CA는 해당 CA 밖에 없기 때문에

서버가 제공한 인증서가 CA에 의해서 발급된 것이라는 것을 의미한다.

CA에 의해서 발급된 인증서라는 것은 접속한 사이트가 

CA에 의해서 검토되었다는 것을 의미한다.

CA의 검토를 통과했다는 것은 해당 서비스가 신뢰할 수 있다는 것을 의미한다.

이것이 CA와 브라우저가 특정 서버를 인증하는 과정이다.

인증서를 이용해서 서비스를 보증을 완료했다! 

맨 위에서 언급했던 악수(handshake) 과정이 완료된 것이다.

이제 가장 중요한 작업인 데이터를 암호화해서 전달하는 과정이 남았다.

이 과정에서 인증서의 공개키를 계속해서 사용한다

■SSL의 동작 방법

SSL 인증서를 이용해 서버의 신뢰도를 확인하는 악수(handshake) 단계가 끝나면

본격적으로 데이터를 전송하는 단계가 시작된다.

SSL은 데이터를 암호화하여 전송하는 방법으로 공개키와 대칭키를 혼합하여 사용한다.

공개키 방식의 암호화는 안전하지만 매우 많은 컴퓨터 자원을 사용하고,

대칭키 방식의 암호화는 효율적이지만 보안의 문제가 발생하기 때문이다.

그래서 SSL은 혼합하는 방식으로 데이터를 암호화한다.

---

클라이언트와 서버가 주고 받는 실제 데이터는 대칭키 방식으로 암호화하고,

대칭키 방식으로 암호화된 실제 데이터를 복호화할 때 사용할 대칭키는 

공개키 방식으로 암호화해서 주고받는다.

- 실제 데이터 : 대칭키로 암호화

- 대칭키의 키 : 공개키로 암호화

아래에서 자세히 정리한다.

큰 그림을 그려보기 위해, 악수단계부터 다시 정리해보자

■1. 악수(handshake)

① 클라이언트가 서버에 접속한다.

이 단계를 Client Hello라고 한다.

이 단계가 주고 받는 정보는 아래와 같다

- 클라이언트 측에서 생성한 랜덤 데이터 :: 아래 3번 참조

- 클라이언트가 지원하는 암호화 방식들 :: 클라이언트와 서버가 지원하는

암호화 방식이 서로 다를 수 있다. 그렇기 때문에 상호간에 어떤 암호화 방식을

사용할 것인지에 대한 협상을 해야 한다. 이 협상을 위해서 클라이언트는 

자신이 사용할 수 있는 암호화 방식을 전송한다.

- 세션 아이디 :: 이미 SSL handshake를 했다면 비용과 시간을 절약하기 위해서

기존의 세션을 재활용하게 되는데, 이 때 사용할 연결에 대한 식별자를 전송한다.

② 서버는 Client Hello에 대한 응답으로 Server Hello를 하게 된다.

이 단계에서 주고 받는 정보는 아래와 같다.

- 서버 측에서 생성한 랜덤 데이터 :: 아래 3번 참조

- 서버가 선택한 클라이언트의 암호화 방식 :: 클라이언트가 전달한 암호화 방식 중에서

서버쪽에서도 사용할 수 있는 암호화 방식을 선택해서 클라이언트로 전달한다.

이로써 암호화 방식에 대한 협상이 종료된다. 

서버와 클라이언트는 이 암호화 방식을 이용해서 정보를 교환하게 된다.

- 인증서

③ 클라이언트는 서버의 인증서가 CA에 의해서 발급된 것인지를 

확인하기 위해 자신에게 내장된 CA 리스트를 확인한다. 

CA 리스트에 인증서가 없다면 사용자에게 경고 메세지를 출력한다. 

그리고 내장된 CA의 공개키를 이용해서 인증서를 복호화한다.

(복호화에 성공했다면 인증서는 CA의 개인키로 암호화된 문서임이

암시적으로 보증된 것이다.) 

클라이언트는 1번에서 자신이 생성한 랜덤 데이터와 

2번을 통해서 받은 서버의 랜덤 데이터를 조합해서 

pre master secret 이라는 키를 생성한다. 

이 키는 뒤에서 살펴볼 세션 단계에서 사용되는 데이터의 암호화에 사용된다.

이 때 사용될 암호화 기법은 대칭키이기 때문에 pre master secret 키는

제 3자에게 절대로 노출되어서는 안된다.

그렇다면 pre master secret 키를 어떻게 서버에게 전달할 것인가?

이 때 사용하는 방법이 바로 공개키 방식이다. 

② 단계에서 서버로부터 받은 인증서 내의 공개키로 pre master secret 키를 

암호화해서 서버로 전송한다. 서버는 이 암호화된 키를 자신의 비공개키로 안전하게 

복호화할 수 있다. 

④ 서버는 클라이언트가 전송한 pre master secret 키를 자신의 비공개키로 복호화한다.

이로써 서버와 클라이언트 모두 pre master secret 값을 공유하게 되었다.

그리고 서버와 클라이언트는 모두 일련의 과정을 거쳐서 

pre master secret 키를 master secret 키로 만든다. 

master secret 키는 session key를 생성하는데, 이 session key 값을 이용해서 

서버와 클라이언트는 데이터를 대칭키 방식으로 암호화한 후에 주고 받는다.

이렇게 해서 세션키를 클라이언트와 서버가 모두 공유하게 되었다.

클라이언트와 서버는 handshake 종료를 서로에게 알리고 

본격적으로 데이터를 대칭키 방식으로 암호화하여 전송한다.(세션 시작)

■2. 전송(세션)

세션은 실제로 서버와 클라이언트가 데이터를 주고 받는 단계이다.

이 단계에서 핵심은 '정보를 상대방에게 전송하기 전에 session key 값을 

이용해서 대칭키 방식으로 암호화 한다'는 점이다.

암호화된 정보는 상대방에게 전송될 것이고, 상대방도 session key 값을 

알고 있기 때문에 암호를 복호화할 수 있다.

■3. 전송(세션) 종료

데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려준다.

이 때 통신에서 사용한 대칭키인 session key를 폐기한다.

https://opentutorials.org/course/228/4894