TLS 인증서 (2) - 신뢰할 수 있는 인증서

지난 1편에서는, 공격자의 network packet 스니핑을 방지하기 위해 비대칭 키인 public key(lock) 과 private key 를 사용한 안전한 통신 방식에 대해서 알아 보았다.

이번에는 공격자가 중간에 packet 을 가로채는 걸 넘어서, 아예 실제 존재하는 웹서버와 매우 유사한 가짜 웹 서버를 만든 다면 어떻게 될까? 기존 웹서버가 인증을 처리하는 방식을 그대로 구현한 뒤에, 사용자의 요청이 다른 루트를 타게 조작하여 요청이 가짜 웹서버로 가게 될 경우, 사용자는 기존 인증 방식을 그대로 이용하여 가짜 웹 서버에 인증처리를 진행할 수 있다.

공격자의 가짜 web 서버

사용자 입장에서는 브라우저를 열었을 때의 화면과 인증 처리 등의 진행 방식이 실제 웹 사이트와 모두 동일하게 보이므로 화면에서는 사용자가 접속한 웹서버가 가짜 웹서버인지 알기가 어렵다.

---

인증기관과 인증서 서명 요청

위와 같은 경우를 방지하기 위해, 사용자가 서버로부터 받은 키를 보고 그 키가 '악의적 공격자의 키가 아닌' 정품 키인지를  확인할 수 있는 방법이 필요하다.

서버에서 키를 보낼 때 키 값 만을 보내는 것이 아니라, 키 값이 포함되어 있는 '인증서'를 보내게 된다.

이 인증서는 실제 인증서와 형식이 유사하지만 디지털 형식으로 되어 있는데 그 안에는 다음과 같은 많은 값들이 포함되어 있다.

(1) 인증서를 발행한 주체(기관 등)의 이름
(2) 인증서 소유자의 공개 키 (당연히 비밀 키는 소유자가 가지고 있다)
(3) 인증서의 유효 기간
(4) 고유한 UID
(5) 사용된 알고리즘
(6) 사용할 도메인 이름 : CN(Common Name)
(7) 대체 가능한 도메인 이름 : SAN (Subject Alternative Name)
(8) 인증서에 대한 서명
(9) 서명을 포함한 인증서의 기타 모든 값들을 해시화한 값

 

위와 같이 특정 키 값이 공인된 키 값임을 '인증' 하기 위하여 인증서를 발행한 기관 등의 이름을 적게 된다.

이 인증서에서 가장 중요한 부분은 인증서를 발급한 주체와 서명이다. 인증서의 서명은 인증서를 생성한 사람이 직접 서명(Self-signed) 할 수도 있고, 신뢰할 수 있는 누군가에 의해 서명될 수도 있다. 사용자, 웹서버 뿐만 아니라 공격자 또한 인증서를 만들 수 있으며 만약 인증서에 서명한 사람이 공격자이거나 신뢰할수 없는 사람(기관)이라면 그 인증서와 키 값은 신뢰할 수 없다고 판단할 수 있다. 

바꿔 말하면 인증서에 서명한 사람이 누구인지를 통하여 인증서를 신뢰할 수 있게 되는데, 여기에서 인증기관 또는 CA(Certificate Authority)이 등장한다. 인증기관이란 인증서에 서명할 수 있도록 공인되고 널리 알려진 기관들이며 Symantec(Verisign), DigiCert, Geotrust, Comodo, GlobalSign 와 같은 기관들이 대표적이다.

인증기관들은 자신들이 자체 서명(Self-signed)한 인증서를 사용하며 다른 인증서를 서명해준다. 즉, 신뢰할 수 있는 인증서가 다른 인증서를 서명해주는 형식이다.

사용자는 인증서를 생성한 후에 이러한 서명을 위와같은 인증기관에 요청할수 있는데 이러한 인증서 서명 요청을 CSR(Certificate Signing Request) 이라고 부른다. 

사용자의 인증서 서명 요청에 대하여 인증기관(CA)은, 인증기관이 가지고 있는 public & private key pair 중 개인키(private) 를 이용하여 서명을 한다. 인증기관의 public key 는 이미 공개되어 브라우저 등에 내장되어 있으므로, 인증기관이 서명한 인증서를 받은 사용자는 (이미 공개된) 인증기관의 public key를 이용하여 신뢰성을 확인할 수 있다.

---

인증서 체인 (Chain of Trust)

인증서 체인이란, 인증서를 서명한 인증서가 다시 다른 인증서를 서명하는 구조이다. 위 내용에서 보면 CA 가 인증서를 서명하여 주는데, 실제로는 1개 CA 에 의해 모든 인증서가 서명 될 경우 CA 가 위험에 노출될 경우 서명한 모든 인증서가 위험해질 수 있으므로, 중간에 다른 인증서를 두게 된다. 이렇게 중간에 두게 되어 '중간 인증서(Intermediate Certificate)' 라고 하며 물론 CA가 서명한 인증서이므로 신뢰할 수 있다고 판단한다. 즉, 

"상위 계층의 인증서가 신뢰할 수 있는 기관이라면, 그 인증서로 서명한 인증서 또한 신뢰할 수 있다 : Chain of Trust"

이 중간에 두게 되는 인증서를 '중간 인증서(Intermediate Certificate)' 라고 한다. 이를 그림으로 표현하면 다음과 같다.

기존의 CA 가 최상위 인증기관이 되며, CA 가 다른 인증서를 서명하기 위해 자체 서명한 인증서는 최상위 인증서(Root CA)로 표현한다. 보통 위와 같이 1개의 중간 인증 기관을 두어, 실제로 사용자가 웹서버와 통신하는 인증서와 최상위 인증서 사이에 중간 인증서를 사용하는 3계층 구조가 된다.

CA 및 중간 인증기관의 공개키는 브라우저가 이미 가지고 있으므로, 사용자는 웹서버의 인증서를 최초 받은 후에, 중간 인증기관의 공개키를 이용하여 인증서의 무결성을 확인한다. 그리고 최상위 인증기관(CA)의 공개키를 이용하여 중간 인증기관의 인증서 무결성을 확인한다. 이렇게 웹서버가 가지고 있는 인증서의 무결성을 확인하면, 이제 신뢰할 수 있는 기관으로 웹서버를 인식하고 위의 비대칭 통신을 통하여 안전한 통신을 수행하게 된다.

---

PKI (Public Key Infrastructure)

TLS 인증서와 관련된 1,2편의 내용들로, 네트워크를 통해 전송하려는 메시지를 암호화하려는 이유와 방법에 대하여 살펴보았다. 간단하게 정리하면 다음과 같다.

1. 최초 서버 관리자는 서버 자체의 SSH 연결을 보호하기 위해 한 쌍의 키(public, private)를 생성
2. 서버의 무결성을 확보하기 위해 인증서를 생성하고, CA 에 인증서 서명 요청을 전달
3. CA 는 자신의 개인 키를 사용하여 인증서를 서명하고 다시 웹서버로 전송
4. 서버는 서명된 인증서로 웹 어플리케이션을 구성하고, 사용자가 액세스 할 때마다 공개키와 함께 인증서를 전송
5. 사용자는 CA 의 공개키를 사용하여 서버 인증서의 무결성을 확인하고 앞으로 통신에 사용할 대칭키를 생성
6. 대칭키는 서버 공개 키를 사용하여 암호화 한 후에 서버에 전달
7. 서버는 개인 키를 사용하여 복호화 후에 대칭키를 확보
8. 이제 사용자와 서버는 대칭키를 사용하여 안전한 통ㅇ신을 수행

그러나 실제로 사용자가 웹 서버와 통신을 수행하면서 위와 같은 내용들을 직접 수행하진 않는다. 브라우저에서 모두 자동으로 수행해기 때문이며, 이렇게 CA와 서버의 구성, 디지털 인증서의 생성과 배포 및 유지 관리 등의 프로세스를 포함하는  전체 인프라를 공개 키 인프라(Public Key Infrastructure) 또는 PKI라고 한다.