어떻게 이 공개키가 진짜 그 사람 걸까, 인증서

가짜 공개키가 끼어들 수 있다

지금까지는 받은 공개키를 그냥 믿고 썼다. 당연히 그 사람 것이라고 여긴 셈이다. 그런데 나와 상대 사이에 누군가 끼어 있다면 이야기가 달라져요. 그 사람이 진짜 공개키 대신 자기 공개키를 슬쩍 건네면, 나는 아무것도 모른 채 그것으로 비밀을 잠그고 그 사람은 자기 개인키로 그 비밀을 열어 본다. 열어 본 뒤 진짜 공개키로 다시 잠가 넘기면 양쪽 모두 눈치채지 못한다.
공개키라는 도구에는 아무 흠이 없다. 흔들리는 것은 그 공개키가 누구 것이냐는 한 가지이고, 키 교환 강에서 남겨 둔 숙제도 바로 이것이었어요.

보낼 공개키를 골라 누르면, 진짜가 그대로 도착할 때는 안전하고 중간에서 가짜로 바뀌면 비밀이 엉뚱한 손에서 열린다는 것이 보인다.

두 경우를 나란히 놓으면 차이가 분명하다. 진짜가 오면 아무 일도 없지만, 가짜가 와도 내 쪽 화면에는 공개키 하나가 도착했다는 사실만 보여요. 공개키는 긴 숫자일 뿐 이름표가 붙어 있지 않아서, 그것만 봐서는 주인을 가릴 수 없다.
그래서 필요한 것은 이 공개키가 정말 그 사람 것이라고 믿을 만하게 보증해 주는 누군가다. 그 보증을 서는 쪽이 다음에 나와요.

믿을 만한 기관이 보증한다

여기서 모두가 믿기로 한 기관이 등장한다. 인증기관, 줄여서 CA라고 부르는 곳이에요. 사이트는 자기 공개키와 도메인 이름을 CA에 내고, CA는 신청한 쪽이 정말 그 도메인을 관리하는지 확인한다.
확인이 끝나면 CA는 공개키와 도메인 이름, 발급한 곳, 유효 기간을 한 문서에 담고 자기 개인키로 서명한다. 지난 강의 그 위조할 수 없는 서명이다. 이렇게 CA의 서명이 붙은 문서가 인증서이고, 공개키에 믿을 만한 신분증이 붙은 셈이에요.

발급 단계를 차례로 누르면 사이트가 공개키를 내고, CA가 확인한 뒤 서명해서 한 장의 인증서로 묶는 과정이 이어져요.

이제 공개키가 홀로 떠다니지 않는다. CA의 서명이 그 뒤를 받치고 있다. 이 서명은 CA의 개인키로만 만들 수 있으니 누구도 흉내 내지 못한다. 그래서 인증서를 받은 사람은 CA의 공개키로 서명을 확인해 보고, 서명이 맞으면 거기 적힌 공개키가 적힌 도메인의 것이라고 믿을 수 있어요.
인증서에는 유효 기간도 있어서, 기간이 지난 인증서는 더 이상 보증으로 쳐 주지 않는다. 그런데 질문이 하나 남는다. 그 CA의 공개키는 또 무엇을 근거로 믿는가?

브라우저의 신뢰 목록, PKI

CA를 믿는 근거는 생각보다 단순하다. 운영체제와 브라우저에는 믿을 만하다고 미리 심사한 루트 CA들의 인증서 목록이 처음부터 들어 있어요. 이 목록이 믿음의 출발점이에요.
다만 루트 CA가 모든 사이트에 직접 서명하지는 않는다. 루트 CA의 개인키는 보통 네트워크에서 떼어 깊이 보관하고, 일상적인 발급은 루트가 보증해 준 중간 CA가 맡는다. 그래서 브라우저는 사이트 인증서에서 출발해 서명한 CA를 한 칸씩 거슬러 올라가고, 신뢰 목록의 루트에 닿으면 검증을 마친다. 보증이 보증으로 이어지는 이 구조 전체를 공개키 기반구조, 줄여서 PKI라고 부른다.

사슬을 한 칸씩 따라 올라가자. 사이트 인증서에서 출발해 중간 CA를 거쳐 신뢰 목록의 루트 CA에 닿으면 검증이 끝난다.

사슬 끝에서 브라우저가 미리 믿고 있던 루트 CA를 만났다. 루트의 인증서는 자기가 자기에게 서명한 것이라, 그 믿음은 목록에 들어 있다는 사실에서 나온다. 거기까지 사슬이 끊기지 않고 이어지면 맨 아래 사이트의 공개키까지 믿을 수 있게 돼요.
나는 그 사이트를 직접 몰라도, 내가 믿는 루트가 중간 CA를 보증했고 중간 CA가 사이트를 보증했으니 믿는 거예요. 그렇다면 실제 인증서가 들어왔을 때 통과와 경고는 무엇으로 갈릴까?

진짜 인증서는 통과, 가짜는 경고

브라우저는 인증서를 받으면 몇 가지를 차례로 따진다. 사슬이 신뢰 목록의 루트까지 이어지는지, 사슬 위의 서명이 모두 맞는지, 인증서에 적힌 도메인이 지금 접속한 주소와 같은지, 유효 기간이 지나지 않았는지를 본다.
모두 맞으면 통과하고 주소창에 자물쇠 표시가 뜬다. 하나라도 어긋나면 브라우저가 큼직한 경고 화면을 띄워 접속을 멈춰요. 가짜 공개키를 걸러 내는 문지기가 바로 이 검증이다.

두 인증서를 하나씩 검증해 보자. 신뢰 목록에 닿는 진짜는 통과하고, 믿을 수 없는 곳이 서명한 가짜는 경고가 뜬다.

진짜는 조용히 통과했고 가짜는 곧바로 경고에 막혔다. 웹을 쓰다가 이런 경고 화면을 만나면 그냥 넘기지 말아야 한다는 뜻이에요. 그 사이트의 공개키가 믿을 만하게 보증되지 않았다는 알림이기 때문이다.
한편 사이트의 개인키가 새어 나가면 인증서가 아직 유효해도 위험해진다. 그래서 CA는 그런 인증서를 폐기할 수 있고, 폐기 정보를 확인하는 장치도 마련되어 있어요. 이제 인증서가 무엇을 지키는지 정리해 보자.

정리

한데 모으면 이렇다. 공개키를 안전하게 쓰려면 그것이 정말 그 사람이나 그 사이트의 것이라고 믿을 수 있어야 한다. 중간에서 가짜 공개키를 건네는 공격이 있기 때문이다. 그래서 믿을 만한 기관인 CA가 확인한 뒤 공개키와 도메인 이름, 유효 기간을 한 문서에 담아 서명해 주는데, 이 문서가 인증서예요.
브라우저는 루트 CA 목록을 미리 갖고 있어서, 인증서의 서명을 사슬처럼 거슬러 올라가 그 목록에 닿는지 확인한다. 이렇게 이어진 신뢰의 그물 전체가 PKI다.

핵심 네 가지를 차례로 눌러 되짚는다. 가짜 공개키의 위험, CA의 서명과 보증, 루트까지 이어지는 사슬, 통과와 경고예요.

이제 처음 보는 공개키를 무엇을 근거로 믿는지 알게 됐다. 혼자 떠다니는 공개키는 누구 것인지 알 수 없지만, CA의 보증이 붙은 인증서는 믿을 만하다. 매일 보는 주소창의 자물쇠 뒤에 바로 이 인증서와 신뢰의 사슬이 있어요.
잠금, 서명, 신원 보증이라는 조각이 모두 모였다. 다음 강에서는 이 조각들이 사이트에 접속하는 순간 HTTPS라는 연결 안에서 어떻게 함께 움직이는지 본다.