HTTP와 HTTPS - 2
지난 HTTPS 1편에 이어서 오늘은 서버가 CA에게 인증서를 요청하는 과정부터 SSL, TLS까지 알아보겠습니다.
서버가 CA에게 인증서를 요청하는 과정
이전편에서 설명드렸듯이 서버가 HTTPS 프로토콜을 사용하기 위해서는 CA로부터 인증서를 발급받아야 합니다.
인증서를 발급받기 위해 서버는 일정 비용을 지불하고 CSR(Certificate Signing Request)이라고 불리는 요청서를 제출해야 합니다
CSR의 내부에는 도메인, 회사 이름과 부서, 회사가 속한 국가와 주, 시의 이름 그리고 회사 이메일주소가 포함되며 서버가 생성한 공개키를 포함하여 제출하게 됩니다.
CA는 전달받은 CSR을 참고해서 해당 서버가 정상적인 서버인지 검증하는 과정을 거치며 검증이 완료되었다면 서버로부터 전달받은 공개키를 포함한 인증서를 서버에게 전달합니다.
인증서의 내부에는 다음과 같은 정보가 포함됩니다.
· 인증받은 도메인명과 서브도메인
· 서버의 회사 이름과 위치(국가, 주, 시)
· 인증서를 발급한 CA의 업체명
· CA의 디지털 서명
· 인증서 발급일 및 만료일
· 서버의 공개키
서버는 CA로부터 받은 인증서를 보관하고 있다가 클라이언트에게 요청이 오면 자신이 정상적인 서버임을 증명하기 위해 인증서를 전달하며 클라이언트는 자신의 브라우저에 등록된 CA 리스트와 공개키를 확인하여 인증서를 검증합니다.
CA리스트는 브라우저의 설정을 통해 확인할 수 있습니다.
크롬의 경우 설정 -> 개인정보 및 보안 탭 -> 보안 -> 인증서 관리 경로를 통해 확인할 수 있습니다.
여기서 주목해야할 점이 전편에서 비밀키로 암호화하는 예시에 대해서 설명하지 않았었는데
바로 CA가 인증서를 발급하는 부분이 비밀키로 암호화하는 대표적인 예입니다.
CA는 서버에게 인증서를 전달할 때 자신의 비밀키로 암호화하여 전달합니다.
그래서 클라이언트는 인증서를 검증할 때 브라우저 내부의 공개키로 복호화를 통해 검증하는데
공개키는 브라우저 내부에 들어있으므로 누구나 인증서를 열어볼 수 있겠죠?
하지만 CA의 공개키로 복호화가 가능하다는것은 해당 비밀키로 암호화를 했다는 뜻이며
이는 해당 인증서가 CA로부터 생성되어 암호화된 정상적인 인증서임을 뜻합니다.
만약 해커가 중간에 인증서를 탈취해 임의로 수정해 암호화했더라도 CA의 비밀키는 없을것이기 때문에 공개키로는 풀리지 않으므로 탈취해 조작한다고 한들 의미가 없습니다.
따라서 비대칭키의 개인키로 암호화하는 경우는 위처럼 데이터는 유출되어도 상관없지만 데이터를 누가 작성했는지가 중요할 때 사용됩니다.
지금까지는 이해하기 쉽도록 CA가 마치 한 곳인것처럼 설명했지만 사실 CA는 두 종류로 나누어집니다.
CA의 종류와 인증서 체이닝
CA는 Root CA와 Intermediate CA(ICA)로 나누어집니다.
Root CA는 최상위 CA로 이들은 자신의 하위에 위치한 ICA의 인증서에 서명을 하고
ICA는 RootCA의 서명을 토대로 자신의 서명을 추가해 서버가 구매하는 인증서에 서명을 하게됩니다.
따라서 인증서를 생성하거나 검증할 때 아래 사진과 같은 체이닝 형태를 띄게 되며
이를 Certificate chain(= Chain of trust)이라고 합니다.
그럼 이렇게 CA를 나눈 이유는 무엇일까요?
Root CA는 최상위 기관으로서 무조건적인 신뢰를 받습니다.
인증서 내부에는 CA의 서명이 포함되어있다고 설명드렸었는데 만약 Root CA의 비밀키가 유출되거나 인증서가 오발행 되었다면 해당 Root CA의 인증서를 사용하는 모든 사용자의 통신은 노출 될 위험이 생깁니다.
하지만 Root CA 아래의 ICA를 위치시켜 ICA가 인증서 발행을 담당하게 되면 ICA의 비밀키가 유출되거나 인증서가 오발행되는 사고가 발생하더라도 Root CA에서 해당 ICA의 인증서만 무효화 처리하면 피해를 최소화할 수 있기 때문에 이런 방식을 사용합니다.
그래서 Certificate chain 과정은 혹시 모를 사고에 대비해 서버의 인증서는 ICA의 공개키로 검증하고,
ICA의 인증서는 Root CA의 공개키를 이용해 검증하며 Root CA는 자신의 상위 CA가 없기 때문에 자신의 대칭키를 통해 스스로 검증합니다.
만약 이 과정에서 한번이라도 복호화가 불가능하여 체이닝 과정이 끊길 경우 해당 인증서는 신뢰하지 않는 인증서로 판단되어 브라우저에서 경고창을 띄우거나 접속 자체를 막을 수 있습니다.
인증서의 인증 경로 탭을 보면 Root CA - ICA - 서버 인증서 순서로 되어있는 모습을 볼 수 있습니다.
또한 ICA는 CA업체나 인증서의 종류에 따라 여러개가 존재 할 수 있습니다.
위 인증서의 경우 3개의 ICA를 거칩니다.
지금까지 설명드렸던 인증서를 통한 보안 기법은 HTTPS 프로토콜에서 자체적으로 수행하는게 아니라
SSL 또는 TLS라는 보안 프로토콜을 사용하는것입니다.
그래서 디지털 인증서를 SSL인증서 혹은 TLS인증서라고도 부릅니다.
즉, HTTPS프로토콜은 데이터 전송시 보안을 위해 암호화 통신을 하는데
암호화 및 인증서 검증을 위해 SSL 또는 TLS 보안 프로토콜을 사용한다 라고 정리할 수 있습니다.
그럼 또 이 둘의 차이점에 대해서 알아봐야겠죠?
SSL (Secure Sockets Layer)
HTTPS의 풀네임은 "HTTP over Secure Sockets Layer"입니다.
여기서 등장하는 "Secure Sockets Layer"가 바로 이 SSL을 뜻합니다.
SSL은 인터넷 보안 프로토콜로 클라이언트와 서버의 통신 과정에서 주고받는 데이터에 대해
도청, 간섭, 위조등을 방지하기 위해 Netscape사가 1995년에 개발하였으며 다음과 같은 3가지 목적을 가지고 있습니다.
- 암호화를 통해 통신 내용이 공격자에게 노출되는 것을 막는다.
- 인증서를 통해 클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버인지 판단한다.
- SSL 통신에 사용 할 공개키를 클라이언트에게 제공한다.
목적에서 알 수 있듯이 SSL은 인증서를 통해 서버를 검증하고 데이터를 암호화 및 복호화하는 과정을 전부 담당하고 있습니다.
TLS (Transport Layer Security)
TLS도 SSL과 같은 암호화 프로토콜로 웹 뿐만 아니라 이메일, 메신저, VoIP에도 사용됩니다.
사실 TLS는 1999년에 위에서 설명한 SSL의 소유권이 Netscape에서 국제 표준화 기구인 IETF로 이관되면서 당시 3.0버전이었던 SSL을 TLS의 1.0버전으로 만들고 정식명칙을 TLS로 채택하였습니다.
이 후 SSL은 더이상 업데이트 되지 않았고 TLS만 업데이트가 진행되고 있습니다.
현재 TLS의 가장 최근 버전은 2018년에 발표된 1.3버전으로 초기의 TLS는 SSL과 거의 같다고 할 수 있지만 현재는 업데이트로 인해 많은 차이가 생겼습니다.
그리고 TLS 인증서에도 단점이 있는데 일반적인 인증서는 도메인과 도메인 소유자(신청자)가 일치하는지만을 심사하기 때문에 HTTPS를 사용하는 피싱사이트가 만들어질 수 있습니다.
따라서 보안을 강화하기 위해 인증서의 등급을 3개로 세분화하고 등급은 심사항목에 따라 나눠지도록 하였습니다.
-
DV (Domain Validation)
가장 일반적인 인증서로 발급 시 도메인과 도메인 소유자만을 심사합니다. -
OV (Organization Validation)
DV보다 조금 더 까다로운 인증서로 DV에서 회사에 대해 추가적으로 심사합니다. -
EV (Extended Validation)
가장 보안이 강한 인증서로 검증과정이 매우 까다롭고 회사뿐만 아니라 조직까지 검증합니다.
현재 이용하는 사이트의 인증서 등급이 궁금하다면 아래 사진과 같이 비교할 수 있습니다.
자물쇠를 클릭했을 때 회사명이 표시된다면 EV 인증서이며
회사명이 없다면 인증서의 자세히탭을 통해 OV와 DV를 구분할 수 있습니다.
주체에 회사명과 위치가 포함되어 있다면 OV, CN만 있다면 DV입니다.
TLS Handshake
마지막으로 통신하기전 클라이언트와 서버가 서로를 검증하는 과정에 대해 조금 더 자세히 다시 살펴보려고 합니다.
클라이언트와 서버가 본격적으로 통신을 시작하기 전 우리가 처음 만난 사람과 악수를 하듯이 클라이언트와 서버도 처음 만나 서로를 검증하는 이 과정을 TLS Handshake라고 합니다.
이 과정은 두 장치를 확인하고 데이터의 무결성을 위해 데이터에 디지털 서명을 함으로써 데이터가 의도된대로 전달될 수 있도록 하는 목적을 가집니다.
핸드 셰이크 과정은 아래와 같은 순서로 진행됩니다.
- Client Hello
클라이언트에서 생성한 랜덤 데이터, 클라이언트가 지원하는 암호화 방식(=Cipher Suite),
SSL/TLS 버전을 서버에게 보냅니다.
- Server Hello
클라이언트로부터 받은 정보를 바탕으로 서버는 자신이 생성한 랜덤 데이터, 선택한 클라이언트의 암호화방식, 인증서를 전송합니다.
(암호화 방식은 클라이언트와 서버에서 지원가능한 방식 중 가장 안전한 방식으로 선택합니다.)
- 인증서 검증
클라이언트는 서버로부터 받은 인증서를 브라우저의 CA목록에서 확인하여 없다면 경고 메세지를 띄우고, 인증서가 있다면 브라우저에 내장된 해당 CA의 공개키를 이용해 인증서를 복호화합니다.
- 검증이 완료 된 후 클라이언트에서 "pre master secret"이라는 임시 키를 생성하며 서버로부터 받은 공개키를 통해 암호화한 후 서버에게 전송합니다.
(인증서 내부에 있던 서버의 공개키를 이용해 암호화하기 때문에 비밀키를 가진 서버만이 복호화가 가능합니다.)
- 서버는 클라이언트로부터 전달받은 pre master secret을 복호화합니다.
- 클라이언트와 서버는 주고 받은 랜덤 데이터들과 pre master secret을 조합하여 대칭키(세션키)를 생성합니다.
이는 같은 데이터를 이용해 조합하므로 같은 결과가 나오게 됩니다.
- Client is ready
만들어진 세션키로 암호화하여 서버에게 완료되었다는 메세지를 보냅니다.
- Server is ready
클라이언트의 완료 메세지를 확인한 서버또한 클라이언트에게 완료되었다는 메세지를 복호화하여 보냅니다.
- 핸드 셰이크과정이 종료되고 대칭키를 사용한 실제 통신이 시작됩니다.
