(Network) SSL 인증서

인증서의 역할

1. 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장
2. SSL 통신에 사용할 공개키를 클라이언트에게 제공

CA

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

• 이러한 역할을 보장하는 조직 : CA (Certificate Authority) - 상당히 신뢰할 수 있는 기관

사설 인증기관

사적인 서비스를 이용하면 굳이 CA를 통해 비용을 지불하지 않더라도 개인적으로 인증과정을 거칠 수 있다.

 

SSL 인증서의 내용

1. 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등등)
2. 서버 측 공개키 (공개키의 내용, 공개키의 암호화 방법)

브라우저는  CA에 대해 알고 있다.

• 브라우저는 인증기관에 대한 정보를 가지고 있다.  - 루트 인증기관에 대한 정보를 알고 있다.
• 브라우저가 업데이트될 때마다 해당 정보는 바뀌게 된다.

---

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

1. 웹 브라우저가 서버에 접속할 때 서버는 인증서를 제공
2. 브라우저는 해당 인증서를 자신이 가지고 있는 CA 리스트에 있는지를 확인
3. 해당 리스트에 포함되어 있다면 브라우저가 CA의 공개키를 가지고 있기 때문에 해당 인증서 내용을 복호화한다.

비밀키로 암 호한 정보를 공개키로 복호화할 수 있다는 것은 해당 정보에 대한 출처를 확인하는 역할이다.

(공인된 기관에서 인증된 것을 확인 가능)

 

---

SSL 동작방법

공개키를 전송하고 데이터 전송 시 해당 공개키로 암호화 해서 전송하고 전달받은 인스턴스는 비밀키로 복호화한다.

클라이언트와 서버의 통신에서 가장 이상적인 방법은 공개키 방식이지만 실제로 사용하지 않는다.
왜냐면 암호화 복호화하는 과정에서 성능 이슈가 존재하기 때문이다.

---

아래의 내용이 이 글의 전반적이 내용이다.

이를 천천히 살펴보도록 하자!

 

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

핸드 셰이크 -> 전송 -> 세션정보

---

HandShake

클라이언트와 서버 간의 통신에서도 인간과 인간 사이의 악수와 같은 행위가 일어난다.

 

단계별로 살펴보자!

 

• 1. 클라이언트가 서버에 접속한다. - 이 단계를 ClientHello라고 일컫는다.
  • 클라이언트 측에서 생성한 랜덤 데이터 전송
  • 클라이언트가 지원하는 암호화 방식들을 전송
    • 클라이언트와 서버가 사용하는 암호화 방식이 다를 수 있기 때문에 먼저 협상을 진행
    • 이 과정에서 클라이언트 측에서는 자신이 사용하는 암호화 방식을 전송한다.
• 2. 서버는 ClientHello에 대한 응답으로 ServerHello를 하게 된다.
  • 서버 측에서 생성한 랜덤 데이터를 클라이언트로 전송
  • 클라이언트가 전달한 암호화 방식 중 서버 자신도 사용할 수 있는 암호화 방식을 선택해서 클라이언트로 전달한다.
  • 인증서를 전송한다.
• 3. 클라이언트는 서버로부터 전송받은 인증서를 확인한다.
  • 해당 인증서가 CA에 의해 발급된 것인지를 확인하기 위해서  클라이언트에 내장된 CA리스트를 확인
  • 클라이언트는 CA에 대한 공개키를 이미 가지고 있다.
    • 이러한 공개키로 인증서를 복호화해서 CA의 개인키로 암호화된 문서임을 신뢰할 수 있다.
    • 인증서 내부에는 서버가 전송한 공개키가 담겨있다. (비밀키는 서버가 가지고 있다.)
  • 클라이언트는 서버의 랜덤 데이터와 자신의 랜덤 데이터를 조합하여 pre master secret 키를 생성한다.
    • 해당 키는 이전에 받은 공개키를 사용하여 암호화한다.
      • 공개키가 유출되더라도 복호화할 수 있는 비밀키는 서버만이 가지고 있으므로 안전하다.
• 4. 서버는 클라이언트가 전송한 pre master secret 값을 자신의 비밀키로 복호화한다.
  • 이로써 서버와 클라이언트가 모두 pre master secret 값을 공유하게 된다.
  • 서버와 클라이언트는 일련의 과정을 거쳐 해당 값을 master secret 값으로 만든다.
    • master secret 값은 세션 key를 생성하고 대칭키 방식으로 암호화 한 다음 서로 소통한다.
• 5. 클라이언트와 서버는 핸드 셰이크 단계의 종료를 서로에게 알린다.

세션

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

 

클라이언트와 서버가 통신할 때 이전에 서로 간에 생성해두었던 세션 key 값을 사용하여 대칭키 방식으로 암호화한다.

 

공개키를 쭈욱 사용하면 될 것을 왜 굳이 대칭키 방식으로 다시 한번 조합을 하는 것일까?

서론에서 언급하였듯이 공개키 방식은 컴퓨팅 파워를 너무 많이 잡아먹기 때문이다. 만약 공개키 방식만을 사용한다면 트래픽이 큰 서버는 비용이 많이 든다는 것을 예상할 수 있다.

 

정리하자면 공개키는 신뢰할 수 있는 암호화 기법이기 때문에 해당 방식으로 암호화를 진행하고 실제로 데이터를 주고받을 때는 대칭키를 이용해서 데이터를 주고받는 것이다.

---

References