[Network] SSL 인증서

인증서의 역할

1. 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장한다.
2. SSL 통신에 사용할 공개키를 클라이언트에게 제공한다.
   • 추 후 클라이언트는 공개키를 통해 암호화 및 복호화를 진행하는 것이다.

 

 

CA

인증서의 역할은 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지 보장하는 역할을 한다. 이런 역할을 하는 민간 기업들이 있는데, 이런 기업들을 CA(Certificate authority) 혹은 root Certificate라고 부른다.

인증서의 핵심은 클라이언트가 접속한 서버가 신뢰할 수 있는 사이트인지를 알려주는 것이다. 이것을 보증해주는 기관(CA)들이 존재하는 것이다.

SSL을 통해서 암호화된 통신을 제공하려는 서비스는 CA를 통해서 인증서를 구입해야한다. CA는 서비스의 신뢰성을 다양한 방법으로 평가하게 되는 것이다.

SSL 인증서의 내용

SSL 인증서의 정보

1. 서비스의 정보(인증서를 발급한 CA, 서비스의 도메인)
   • 클라이언트가 접속하려는 서버가 정상적인 서버가 맞는지를 인증해주는 것을 말한다.
2. 서버 측 공개키(공개키의 내용, 공개키의 암호화 방법)
   • 서버와 클라이언트가 서로 암호화 기법으로 통신을 하기 위해서 필요한 정보를 말한다.

실제 인증서 정보

해당 인증서는 공인된 기관인 CA에 의뢰하여 받은 것으로서, CA에 의뢰하는 절차를 살펴보면,

1. 높은 수준의 인증서를 필요로할 때는 사업자 등록, 악의적으로 사용하지 않겠다라는 검증할 수 있는 서류들을 포함하여 전송.
2. 위 서류를 포함하여 자기가 생성한 공개키를 인증기관에 전송하게 됨.
3. 즉, 자신이 생성한 공개키와 자신의 서비스 정보를 같이 묶어 인증기관에 전송 시, 인증기관은 해당 정보를 심의 후 이슈가 없는지 확인
4. 그 후 기관은 인증서를 다시 해당 서비스에 제공
5. 그로인해 서비스를 진행하며 사용자들에게 받은 인증서를 제공하며 SSL을 이용하는 것.

 

 

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

브라우저들은 어떤 기관이 공인된 기관인지를 가지고 있고, 공인된 기관이 업데이트 될 때마다 브라우저 또한 반복적으로 업데이트 된다.

브라우저는 root 인증기관의 리스트를 알고 있는 것이다.

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

1. 웹 브라우저가 서버에 접속할 때 서버는 제일 먼저 인증서를 제공한다.
2. 브라우저는 해당 인증서를 발급한 CA가 자신이 내장한 CA의 리스트에 있는지 확인한다.
3. 확인 결과 인증서가 내장된 CA 리스트에 포함되어 있다면, 해당 CA의 공개키를 이용해 인증서를 복호화 한다.
   • 인증서가 복호화가 가능하다는 것은 해당 인증서는 공인된 기관(CA)의 비밀키에 의해서 암호화가 된 것을 의미하는 것이다.
4. CA의 검토를 통과했다는 것은 해당 서비스가 신뢰할 수 있다는 것을 의미한다.

 

 

SSL의 동작방법

SSL은 암호화된 데이터를 전송하기 위해서 공개키와 대칭키를 혼합해서 사용한다.

클라이언트와 서버가 주고 받는 실제 정보는 대칭키 방식으로 암호화하고, 대칭키 방식으로 암호화된 실제 정보를 복호화할 때 사용할 대칭키는 공개키 방식으로 암호화해서 클라이언트와 서버가 주고 받는다.

다시 말해서 서비스에 대한 정보를 대칭키 방식으로 암호화하고, 해당 정보를 복호화 하기 위해서는 대칭키가 필요한데, 이 대칭키는 공개키 방식으로 암호화해서 클라이언트와 서버가 주고 받는 것이다.

• 실제 데이터 : 대칭키
• 대칭키의 키 : 공개키

 

 

네트워크 통신 방법

컴퓨터와 컴퓨터가 네트워크를 이용해서 통신할 때는 내부적으로 3가지 단계를 가진다.

• 악수 -> 전송 -> 세션종료

 

 

악수(handshake)

실제 데이터를 주고 받기 전에 클라이언트와 서버는 일종의 인사인 Handshake를 한다. 이 과정을 통해, 서로 상대방이 존재하는지 확인할 수 있고, 상대방과 데이터를 주고 받기 위해서는 어떤 방법을 사용해야하는지를 파악하는 것이다.

SSL 방식 또한 Handshake를 사용하는데, 이 때 가장 중요한 것은 서버의 인증서를 클라이언트에게 전송하는 것이다.

SSL 방식의 Handshake 과정을 확인해보자.

1. 클라이언트가 서버에 접속한다. 이 단계를 Client Hello라고 한다.

   • 해당 단계에서 주고 받는 정보는 클라이언트 측에서 생성한 랜덤 데이터, 클라이언트가 지원하는 암호화 방식, 세션 아이디
   • 세션 아이디는 이미 Handshake를 했다면 비용과 시간을 절약하기 위해서 기존의 세션을 재활용하는 것이다.

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

   • 해당 단계에서 주고 받는 정보는 서버 측에서 생성한 랜덤 데이터, 서버가 선택한 클라이언트의 암호화 방식, 인증서
   • 클라이언트가 전달한 암호화 방식 중에서 서버가 사용할 수 있는 암호화 방식을 선택해 클라이언트에게 전달한다. 이런 협상이 종료되면 서버와 클라이언트는 암호화 방식을 사용해서 정보를 교환하는 것이다.

3. 클라이언트는 서버의 인증서가 어떤 CA에 의해서 발급된 것인지를 확인하기 위해 클라이언트 내에 있는 CA 리스트를 확인한다.

   • 해당 인증서가 CA에 의해서 발급된 것이면 클라이언트에 내장된 CA의 공개키를 이용해서 인증서를 복호화한다.
   • 복호화 성공 시 인증서는 CA의 개인키로 암호화된 문서임이 암시적으로 보증된 것이다. 이제 인증서를 전송한 서버를 믿을 수 있게 되는 것이다.
   • 인증서 안에는 서버가 생성한 공개키가 들어가 있으므로 클라이언트는 해당 공개키를 획득하게 되고, 그리고 서버는 해당 공개키의 비밀키를 가지고 있는 것이고, 서버는 해당 비밀키를 절대 노출해서는 안되는 것이다.
   • 또한, 클라이언트는 클라이언트 측과 서버 측에서 생성한 랜덤 데이터를 조합하여 pre master secret라는 키를 생성한다. 해당 키는 세션 단계에서 데이터를 주고 받을 때 암호화하기 위해서 사용될 것이다. 그리고 이 키를 서버에 전달하기 위해 클라이언트는 서버의 공개키로 pre master secret 값을 암호화해서 서버로 전송하면 서버는 자신의 비공개키로 안전하게 복호화할 수 있다.(인증서 안에 서버의 공개키가 들어 있으니!)
   4. 서버는 클라이언트가 전송한 pre master secret 값을 자신의 비공개키로 복호화한다.
      • 이로 인해 서버와 클라이언트가 모두 pre master secret 값을 공유하게 되고, 서버와 클라이언트는 pre master secret 값을 master secret 값으로 만들게 된다.
      • master secret는 session key를 생성하는데, session key 값을 이용해서 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화 한 후 주고 받는 것이다.
   5. 이로써 클라이언트와 서버는 Handshake 단계의 종료를 서로에게 알리는 것이다.

 

세션

실제로 서버와 클라이언트가 데이터를 주고 받는 단계이다. 이 단계의 핵심은 정보를 상대방에게 전달하기 전에 session key 값을 이용해서 대칭키 방식으로 암호화 한다는 것이다.

암호화된 정보는 상대방에게 전송될 것이고 상대방도 session key 값을 알고 이씩 때문에 암호를 복호화할 수 있는 것이다.

 

 

세션종료

데이터 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려주고 session key를 페기한다.

 

 

그냥 공개키를 사용하면 될 것을 왜 대칭키와 공개키를 조합해서 사용할까??

만약 공개키를 그대로 사용하게 되면 컴퓨팅 파워를 너무 잡아 먹어 많은 접속이 몰리는 서버에서는 매우 큰 비용을 지불해야한다. 반면 대칭키는 암호를 푸는 열쇠인 대칭키를 상대방에게 전송해야 하는데, 암호화가 되지 않은 인터넷을 통해 키를 전송하는 것은 위험하기 때문이다.!

결과적으로, 속도는 느리나(전 영역에 제공) 공개키 방식으로 대칭키를 암호화하고, 실제 데이터를 주고 받을 때에는 대칭키를 이용해서 데이터를 주고 받는 것이다.