SSL 인증서에 대해 알아보자

SSL/TLS 인증서란?

HTTP통신에 있어 암호화 연결(HTTPS)을 가능하게 하는 제 3의 기관 신뢰기간이 인증한 디지털 인증서입니다.

TLS와 SSL 모두 HTTPS 암호화를 위한 프로토콜로서 사용되며, TLS를 사용할때에도 일반적으로 SSL이라고 말하곤합니다.

추가로 인증서를 통한 암호화는 HTTPS의 보안계층에서 이뤄집니다.

인증서의 구성요소

인증서는 기본적으로 아래 5가지의 정보를 포함합니다.

 

• 인증서 소유자의 공개 키 (HTTPS 통신 연결수립을 위한 공개키입니다)
• 인증서의 유효 기간, 
• 고유한 UID
• 인증서 소유자
• 인증서 서명 (클라이언트가 서명을 통해 신뢰할 수 있는 인증서인지 확인합니다)

인증서 종류

Root CA

인증기관 중 최상위 발급기관입니다.

Root CA에서 서명한 인증서는 무조건 신뢰 할 수 있습니다.

인증서의 개인키는 Root 인증기관이, 공개키는 모든 브라우저와 운영체제에 기본적으로 포함되어 있습니다.

Root CA는 최상위 기관이기에 자신을 인증해줄 기관이 없어 Self-signed  즉 스스로 서명을 하게됩니다.

Intermediate CA (ICA)

Root CA 아래 위치하는 발급 기관에서 발급한 인증서입니다.

ICA가 인증서 발급을 요청하면 상위 인증기관은 전송된 서버정보와 공개키를 합쳐 해시값을 생성 후 자신(Root CA)의 개인키로 암호화 하여 ICA의 서명을 생성합니다.

추가로 클라이언트는 인증서에 포함된 정보와 공개키를 해시값으로 변환 후 인증서의 공개키로 복호화된 인증서의 서명과 비교하여 무결성을 판단합니다. 

개인인증서 (End-Entity CA)

개인이 인증서를 발급받아서 사용하는 인증서입니다.

ICA를 상위기관으로 가지기에 ICA의 인증 및 서명을 받아 발급됩니다.

리눅스에 존재하는 OpenSSL 을 통해서 개발 및 테스트 용도로 사설인증서를 발급받아 사용 할 수 있습니다.

인증서 체인

RootCA, ICA, 개인인증서는 계층구조로 되어있습니다.

결국 개인인증서의 서명 또한 ICA의 서명을 거쳐 최상위 인증기관의 인증서 Root CA의 서명까지 보증하게 됩니다.

이를 인증서 체인이라고 합니다.

 

SSL/TLS 프로토콜의 구조

출처 [정보통신기술용어해설]

HandShake Protocol

클라이언트와 서버간의 연결 수립을 위한 프로토콜입니다.

ChangeCipherSpec Protocol

핸드셰이크가 완료되고 실제 암호화 통신되기 전 암호화 키를 변경하기위한 프로토콜입니다.

Alert Protocol

SSL/TLS 프로토콜 시작부터 종료시까지 항상 사용될 수 있는 프로토콜입니다.

클라리언트나 서버에서 오류 코드 및 경고 코드를 전송합니다.

Record Protocol

실제 데이터를 암호화하고 전송하는 프로토콜입니다.

상위 계층에서 생성된 데이터를 일정 크기의 블록으로 분할하고, 적절한 크기로 재조립합니다.

HMAC(Hash-based Message Authentication Code)의 기법을 사용하여 데이터의 무결성을 검증하는 코드를 데이터에 추가하고 하위 계층으로 전달합니다.

인증서를 통한 HTTPS 연결 수립과정 (SSL/TLS 핸드셰이크)

출처 cloudfare

위 노란색 박스는 TCP HandShake 로 연결 수립 후 SSL HandShake로 인증서를 통해 SSL 연결수립을 진행하는 과정입니다.

1.  ClientHello

SSL 연결 수립 시 최초로 전송하는 패킷입니다.

클라이언트가 지원하는 TLS 버전, 공개키 교환 알고리즘, 대칭 암호화 알고리즘, 메세지 무결성을 증명하기 위한 해시 함수 및 메세지 코드 (MAC)알고리즘 (SHA-256) 그리고 무작위 바이트 문자열 조합 여러개가 Cipher Suite에 담겨 서버로 전송됩니다.

2.  ServerHello

클라이언트가 보냈던 여러 chiper suite 중에서 하나를 선택하여, Chipher Suite에 담아 다시 클라이언트에게 알려줍니다.

추가로 세션정보, 서버에서 생성한 무작위 문자열 바이트를 전송합니다.

ServerHello의 응답에 따라 암호화 통신에 사용할 키 교환 방법이 정해집니다.

3.  Certificate

서버가 클라이언트에게 SSL 인증서를 전달합니다.

클라이언트는 인증서 내부에 존재하는 공개키를 사용하여 서명을 복호화 하여 인증서가 유효한지 확인하고

전달받은 인증서의 내용과 공개키를 해시값으로 변환 후 복호화된 인증서의 서명과 비교하여 서명의 무결성 또한 확인합니다.

 

추가로 서버의 공개키가 SSL인증서에 없다면 서버가 공개키를 직접 전달하게되는데 이 과정을 ServerKeyExchange 라고 합니다.

PSK 핸드셰이크, 익명 핸드셰이크, 빈 핸드셰이크 방식에 따라 Certificate단계가 생략 될 수 있습니다.

4.  ServerHelloDone

위에 Certificate 작업이 끝나면 서버는 핸드셰이크가 끝났음을 알리기 위해 ServerHelloDone 메세지를 보냅니다.

5.  ClientKeyExchange

클라이언트는 암호화에 사용할 대칭 키를 랜덤한 값으로 생성 후 전달받은 인증서의 공개키로 암호화 하여 서버에게 전달합니다. 

이 대칭키로 SSL HandShake이후 HTTPS 통신에서 전달될 데이터들을 암호화 하게됩니다.

6. ChangeChipherSpec

암호화에 사용할 키를 ClientKeyExchage단계에서 생성한 공개키로 변경하는 작업입니다.

서버와 클라이언트 모두 수행후 클라이언트는 서버에게, 서버는 클라이언트에게 알려주는 작업입니다.

해당 패킷을 받으면 암호화 설정이 모두 완료되었다고 판단하여 Finished 패킷을 보내 HandShake를 종료합니다.