SSL과 인증서 구조

1. 인증서 체인

ROOT, Intermediate(중간인증서), Leaf(서버 인증서) 3단계로 구성된 구성을 인증서 체인(Certificate chain)이라고 한다. 이 3개의 인증서 체인은 하위 구조의 인증서를 서명하고 상위 구조의 인증서를 참고하는 방식으로 만들어집니다. 즉 인증서 체인은 SSL 인증서(서버 인증서)에서 시작하여 ROOT 인증서로 끝나는 인증서 목록으로 구성됩니다.

3개의 인증서 체인

 

브라우저로 접속한 사이트에 인증서를 확인하고 싶다면 아래와 같이 진행하면 됩니다. (예시: Chrome 브라우저)

① URL 창에 표시된 자물쇠 아이콘 클릭

② 보안 연결(HTTPS)이 사용되었습니다. 항목 클릭

③ 인증서 유효함 우측 아이콘 클릭

④ 인증서 팝업에서 인증경로 탭 클릭(인증 경로에서 가장 상단부터 루트인증서, 중간 인증서, SSL 인증서로 표시)

 

Chrome - 인증서 확인

 

 

1) ROOT 인증서

CA(Certificate Authority)에서 자체 서명한 인증서로 공개키 기반의 암호화를 사용합니다. 모든 유효한 SSL 인증서는 업계에서 보안 리더로 알려진 신뢰할 수 있는 CA가 발행한 루트 CA 인증서 아래 체인에 위치합니다.

루트 CA 인증서는 웹 브라우저의 특정 저장소에 포함되어 있고 일부 운영체제에서는 사전 설치되어 있기 때문에 다운로드할 필요가 없습니다. 루트 인증서를 발급한 기관이 신뢰할 수 있는 루트 CA 목록에 없을 경우에는 브라우저에서 “인증서 자체는 신뢰할 수 있는 인증서가 아니다”라는 경고가 표시됩니다.

어떤 ROOT CA가 브라우저에서 유효한 지는 아래와 같이 확인이 가능합니다.(예시: Chrome 브라우저)

설정 → 개인 정보 보호 및 보안 → 보안 → 인증서 관리 → 인증서 팝업에서 신뢰할 수 있는 루트 인정기관 탭 클릭

설정 -> 개인 정보 보호 및 보안 -> 보안

 

인증서 관리 -> 신뢰할 수 있는 루트 인증 기관

 

2) 중간 인증서

루트 인증서와 SSL 인증서 사이에 구분을 만들어 위험을 완화하도록 설계된 인증서입니다. 루트 인증서가 가장 많은 권한을 갖고 보호되어야 하기 때문에 루트 인증서가 손상될 경우를 대비합니다.

 

3) SSL 인증서

SSL 인증서는 HTTPS 통신을 통해 웹사이트의 콘텐츠가 브라우저에 전송되는 동안 사이트에서 주고받는 모든 데이터를 암호화합니다. 암호화는 대칭키 암호화 방식과 공개키 암호화 방식을 사용합니다. SSL 인증서를 통해 클라이언트(브라우저)와 서버 간 통신을 보안화하고 통신 과정에서 발생할 수 있는 스니핑(데이터 엿보기), 피싱(유사 사이트), 데이터 변조 등의 해킹을 방지할 수 있습니다.

 

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

1) 대칭키

암호를 만드는 행위인 암호화를 할 때 사용하는 일종의 비밀번호를 키(Key)라고 합니다. 이 키에 따라서 암호화된 결과가 달라지기 때문에 키를 모르면 암호를 푸는 행위인 복호화를 할 수 없습니다. 대칭키는 동일한 키로 암호화화 복호화를 같이 할 수 있는 암호화 기법을 의미합니다. 단점으로는 대칭키의 경우 암호를 주고받는 사람들 사이에 대칭키를 전달하는 것이 어려울뿐더러 대칭키가 유출되면 공격자는 암호를 복호화할 수 있기 때문에 위험합니다.

 

2) 공개키

공개키 방식은 두개의 키를 갖게 되는데 A키로 암호화를 하면 B키로 복호화를 할 수 있고, B키로 암호화하면 A 키로 복호화할 수 있는 방식입니다. 이 방식에 착안해서 두 개의 키 중 하나를 비공개키(private key, 개인키, 비밀키라고도 부른다)로 하고, 나머지를 공개키(public key)로 지정합니다. 비공개키는 자신만이 가지고 있고, 공개키를 타인에게 제공합니다. 공개키를 제공받은 타인은 공개키를 이용해서 정보를 암호화하고 이 정보를 비공개키를 가지고 있는 사람에게 전송하면 비공개키 소유자는 이 키로 복호화를 진행합니다. 이 과정에서 공개키가 유출되더라도 비공개키를 모르면 정보를 복호화할 수 없기 때문에 안전합니다.

암,복호화 과정

 

이 방식은 이렇게 응용할 수도 있습니다. 비공개키의 소유자는 비공개키를 이용해서 정보를 암호화 한 후에 공개키와 함께 암호화된 정보를 전송합니다. 정보와 공개키를 획득한 사람은 공개키를 이용해서 암호화된 정보를 복호화합니다. 이 과정에서 공개키가 유출된다면 공격자에 의해 데이터가 복호화될 수 있는 위험이 있습니다.

암호화된 정보 전달 과정

 

이러한 위험에도 불구하고 비공개키를 이용해서 암호화를 하는 이유는 무엇일까요? 그것은 이것이 데이터를 보호하는 목적이 아니기 때문입니다. 암호화된 데이터를 공개키를 가지고 복호화할 수 있다는 것은 그 데이터가 공개키와 쌍을 이루는 비공개키에 의해서 암호화되었다는 것을 의미합니다. 즉 공개키가 데이터를 제공한 사람의 신원을 보장해 주게 되는 것이다. 이러한 것을 전자 서명이라고 합니다.

 

3. SSL 인증서의 내용

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

1) 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등)

2) 서버 측 공개키 (공개키의 내용, 공개키의 암호화 방법)

 

인증서의 내용은 위와 같이 크게 2가지로 구분할 수 있습니다.

1번은 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지에 대한 내용을 담고 있습니다.

 

2번은 서버와 통신을 할 때 사용할 공개키와 그 공개키의 암호화 방법들의 정보를 담고 있습니다.

 

서비스의 도메인, 공개키와 같은 정보는 서비스가 CA로부터 인증서를 구입할 때 제출해야 됩니다.

 

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

웹브라우저가 서버에 접속할 때 서버는 제일 먼저 인증서를 제공합니다. 브라우저는 이 인증서를 발급한 CA가 자신이 내장한 CA의 리스트에 있는지 확인합니다.

 

확인 결과 서버를 통해서 다운받은 인증서가 내장된 CA리스트에 포함되어 있다면 해당 CA의 공개키를 이용해서 인증서를 복호화합니다.

 

CA의 공개키를 이용해서 인증서를 복호화할 수 있다는 것은 이 인증서가 CA의 비공개키에 의해서 암호화된 것을 의미합니다. 해당 CA의 비공개 키를 가지고 있는 CA는 해당 CA 밖에는 없기 때문에 서버가 제공한 인증서가 CA에 의해서 발급된 것이라는 것을 증명합니다.

 

5. SSL 동작방법

SSL은 암호화된 데이터를 전송하기 위해서 공개키와 대칭키를 혼합해서 사용합니다. 즉 클라이언트와 서버가 주고 받는 실제 정보는 대칭키 방식으로 암호화하고, 대칭키 방식으로 암호화된 실제 정보를 복호화할 때 사용할 대칭키는 공개키 방식으로 암호화해서 클라이언트와 서버가 주고받습니다. 이와 관련된 내용을 순서대로 정리하면 아래 내용과 같습니다.

 

1) Handshake

SSL 방식을 이용해서 통신을 하는 브라우저와 서버는 Handshake를 하는데, 이때 SSL 인증서를 주고 받습니다. 이 과정에서 공개키 방식만 사용하지 않고 대칭키 방식도 같이 사용합니다. 보안상 뛰어난 공개키만 사용하지 않는 이유는 무엇일까요?

 

공개키는 이상적인 통신 방법입니다. 복호화를 할 때 사용하는 키가 서로 다르기 때문에 메시지를 전송하는 쪽이 공개키로 데이터를 암호화하고, 수신받는 쪽이 비공개키로 데이터를 복호화하면 되기 때문입니다.

 

그런데 SSL에서는 이 방식을 사용하지 않습니다. 왜냐하면 공개키 방식의 암호화는 매우 많은 컴퓨터 자원을 사용하기 때문입니다.

 

반면에 암호화와 복호화에 사용되는 키가 동일한 대칭키 방식은 적은 컴퓨터 자원으로 암호화를 수행할 수 있기 때문에 효율적이지만 수신 측과 송신 측이 동일한 키를 공유해야 하는 문제가 발생합니다. 그래서 SSL은 공개키와 대칭키의 장점을 혼합한 방법을 사용합니다.

 

① 클라이언트가 서버에 접속합니다. 이 단계를 Client Hello라고 합니다. 이 단계에서 주고 받는 정보는 아래와 같습니다.

1. 클라이언트 측에서 생성한 랜덤 데이터

2. 클라이언트가 지원하는 암호화 방식들 클라이언트와 서버가 지원하는 암호화 방식이 서로 다를 수 있기 때문에 상호간에 어떤 암호화 방식을 사용할 것인지에 대한 협상을 해야합니다. 이 협상을 위해서 클라이언트 측에서는 자신이 사용할 수 있는 암호화 방식을 전송합니다.

3. 세션 아이디 이미 SSL 핸드쉐이킹을 했다면 비용과 시간을 절약하기 위해서 기존의 세션을 재활용하게 되는데 이 때 사용할 연결에 대한 식별자를 서버 측으로 전송합니다.

 

② 서버는 Client Hello에 대한 응답으로 Server Hello를 하게 됩니다. 이 단계에서 주고 받는 정보는 아래와 같습니다.

1. 서버 측에서 생성한 랜덤 데이터

2. 서버가 선택한 클라이언트의 암호화 방식 클라이언트가 전달할 암호화 방식 중에서 서버 쪽에서도 사용할 수 있는 암호화 방식을 선택해서 클라이언트로 전달한다. 이로써 암호화 방식에 대한 협상이 종료되고 서버와 클라이언트는 이 암호화 방식을 이용해서 정보를 교환하게 된다.

3. 인증서

 

③ 클라이언트는 서버의 인증서가 CA에 의해서 발급된 것인지를 확인하기 위해서 클라이언트에 내장된 CA 리스트를 확인합니다. CA 리스트에 인증서가 없다면 사용자에게 경고 메시지를 출력합니다. 인증서가 CA에 의해서 발급된 것인지를 확인하기 위해서 클라이언트에 내장된 CA의 공개키를 이용해서 인증서를 복호화합니다. 복호화에 성공했다면 인증서는 CA의 개인키로 암호화된 문서임이 암시적으로 보증된 것입니다.

 

④ 클라이언트는 서버로부터 전달받은 랜덤 데이터와 클라이언트가 생성한 랜덤 데이터를 조합해서 pre master secret라는 키를 생성합니다. 이 키는 세션 단계에서 데이터를 주고받을 때 암호화하기 위해서 사용됩니다. 이때 사용할 암호화 기법은 대칭키이기 때문에 pre master secret 값은 제 3자에게 절대로 노출되어서는 안 됩니다.

 

⑤ 서버의 공개키로 pre master secret 값을 암호화해서 서버로 전송하면 서버는 자신의 비공개키로 안전하게 복호화할 수 있습니다. 공개키는 서버로부터 받은 인증서 안에 들어있습니다.

 

⑥ 서버는 클라이언트가 전송한 pre master secret 값을 자신의 비공개키로 복호화합니다. 이후 서버와 클라이언트는 모두 일련의 과정을 거쳐서 pre master secret 값을 master secret 값으로 만듭니다. master secret는 session key를 생성하는데 이 session key 값을 이용해서 서버와 클라이언트는 대칭키 방식으로 암호화한 후에 주고 받습니다.

 

⑦ 클라이언트와 서버는 핸드셰이크 단계의 종료를 서로에게 알립니다.

 

2) 세션

세션은 실제로 서버와 클라이언트가 데이터를 주고받는 단계입니다. 이 단계에서 핵심은 정보를 상대방에게 전송하기 전에 session key 값을 이용해서 대칭키 방식으로 암호화한다는 점입니다. 암호화된 정보는 상대방에게 전송될 것이고, 상대방도 session key 값을 알고 있기에 복호화할 수 있습니다.

 

3) 세션종료

데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려줍니다. 이때 통신에서 사용한 대칭키인 session key를 폐기합니다.

 

 

 

출처

HTTPS와 SSL 인증서 - 생활코딩

ROOT CA 인증서는 무엇인가?