디지털 인증서와 인증 기관: 인터넷 신뢰의 기초

당신이 은행 웹사이트에 접속할 때, 브라우저는 그 웹사이트가 정말 당신이 생각하는 그 은행인지 어떻게 알 수 있을까요? 누군가 당신의 트래픽을 가로채서 가짜 은행 웹사이트로 리다이렉트할 수도 있습니다. 하지만 당신의 브라우저는 이를 감지합니다. 그 이유는 디지털 인증서와 인증 기관이라는 시스템 덕분입니다. 이 글에서는 이 시스템이 어떻게 작동하는지, 그리고 왜 완벽하지는 않지만 상당히 잘 작동하는지 설명합니다.

인증서란 무엇이고, 왜 필요한가

디지털 인증서는 기본적으로 신원을 증명하는 문서입니다. 여권이나 운전면허증처럼, 인증서는 "이 공개 키(public key)는 example.com에 속한다"라고 선언합니다. 공개 키는 암호화에서 중요한 역할을 하는 긴 숫자 문자열입니다. HTTPS 연결 시, 웹사이트는 자신의 공개 키를 당신에게 보냅니다. 당신의 브라우저는 그 공개 키가 정말 그 웹사이트의 것인지 확인해야 합니다. 이것이 인증서의 역할입니다.

인증서 없다면 어떻게 될까요? 누군가 "나는 example.com이고 이것이 내 공개 키다"라고 선언할 수 있습니다. 당신의 브라우저는 이를 확인할 방법이 없습니다. 이런 상황을 중간자 공격(man-in-the-middle attack)이라고 부릅니다. 공격자가 당신과 웹사이트 사이에 앉아서 양쪽과 통신하는 척 할 수 있습니다.

인증 기관: 신뢰의 중개자

그렇다면 누가 "이 공개 키는 정말 example.com의 것이다"라고 보증할까요? 인증 기관(Certificate Authority, CA)이 그 역할을 합니다. CA는 신뢰할 수 있는 제3자 조직입니다. 웹사이트가 CA에 "저는 example.com입니다. 제 신원을 증명합니다"라고 요청하면, CA는 그 주장을 검증합니다. 그 다음 CA는 디지털 서명으로 인증서에 서명합니다.

디지털 서명이란 무엇일까요? 봉인된 편지를 생각해보세요. 편지에 서명하고 봉인하면, 누군가 그 편지를 열었거나 내용을 바꿨는지 쉽게 알 수 있습니다. 디지털 서명도 비슷합니다. CA의 서명은 인증서가 CA에 의해 승인되었고, 이후 누군가에 의해 변조되지 않았음을 증명합니다.

당신의 브라우저는 CA의 공개 키를 이미 가지고 있습니다. 브라우저는 웹사이트로부터 받은 인증서를 받으면, CA의 공개 키를 사용해서 그 서명이 유효한지 확인합니다. 서명이 유효하면, 그 인증서는 CA에 의해 승인된 것이고, 따라서 신뢰할 수 있습니다.

신뢰의 연쇄와 루트 인증 기관

그런데 한 가지 질문이 남습니다: 당신의 브라우저는 CA의 공개 키를 어디서 얻을까요? CA도 인증서가 필요합니다. 하지만 그 인증서는 누가 서명할까요? 다른 CA일까요?

네, 맞습니다. CA들도 계층적으로 조직됩니다. 일반적인 구조는 다음과 같습니다:

루트 CA(Root Certificate Authority): 이것이 체인의 맨 위입니다. 루트 CA의 인증서는 자신이 서명합니다. 이를 자체 서명(self-signed) 인증서라고 부릅니다. 당신의 브라우저는 루트 CA의 인증서를 미리 설치하고 있습니다. 이 인증서들을 신뢰의 앵커(trust anchor)라고 부릅니다.

중간 CA(Intermediate Certificate Authority): 루트 CA는 중간 CA의 인증서에 서명합니다. 중간 CA는 실제 웹사이트 인증서에 서명할 수 있습니다. 이 구조는 루트 CA의 개인 키 보호를 강화합니다.

리프 인증서(Leaf Certificate): 이것이 웹사이트의 실제 인증서입니다. 중간 CA에 의해 서명됩니다.

당신의 브라우저가 웹사이트의 인증서를 받으면, 다음을 확인합니다:

1. 인증서의 서명이 중간 CA의 공개 키로 유효한가?
2. 중간 CA의 서명이 루트 CA의 공개 키로 유효한가?
3. 루트 CA의 서명이 자신의 저장소에 있는 신뢰할 수 있는 루트 인증서와 일치하는가?

이 모든 단계가 성공하면, 체인이 신뢰할 수 있는 루트까지 연결되므로 인증서가 유효합니다.

CA가 손상되면 어떻게 될까

이 시스템은 CA가 정직하게 행동한다는 가정에 의존합니다. 하지만 역사적으로 이것이 항상 그렇지 않았습니다.

2011년, DigiNotar라는 네덜란드 CA가 해킹당했습니다. 공격자들은 이 CA의 개인 키를 얻었고, 구글, 야후, 스카이프 같은 주요 서비스에 대한 가짜 인증서를 발급했습니다. 이제 공격자들은 이러한 서비스로의 트래픽을 가로챌 수 있었습니다. 당신의 브라우저는 그 가짜 인증서가 유효하다고 생각했습니다. 왜냐하면 DigiNotar가 서명했기 때문입니다.

DigiNotar 사건은 신뢰 시스템의 근본적인 약점을 드러냈습니다. 모든 CA가 동등하게 신뢰된다면, 한 CA가 손상되면 시스템 전체가 위험해집니다.

인증서 투명성과 신뢰의 재구성

DigiNotar 이후, 업계는 인증서 투명성(Certificate Transparency, CT) 로그를 도입했습니다. CT 로그는 공개적으로 모든 발급된 인증서를 기록합니다. 누구나 이 로그를 검색할 수 있습니다.

이제 Google이나 다른 대형 조직이 자신의 도메인에 대한 의심스러운 인증서가 발급되었는지 모니터링할 수 있습니다. 만약 누군가가 example.com에 대한 가짜 인증서를 발급받으면, example.com의 소유자가 이를 감지할 수 있습니다. 이는 완벽한 방어는 아니지만, 대규모 공격이 장기간 눈에 띄지 않기가 더 어렵게 만들었습니다.

브라우저와 운영 체제가 신뢰를 결정한다

최종적으로 어느 CA를 신뢰할지 결정하는 것은 당신의 브라우저와 운영 체제입니다. 브라우저는 신뢰할 수 있는 루트 CA 목록을 유지관리합니다. 정부나 CA는 당신이 특정 인증서를 신뢰하도록 강제할 수 없습니다. (물론 정부는 당신의 장치에 악의적인 루트 인증서를 설치할 수는 있지만, 이는 다른 문제입니다.)

이것이 왜 중요할까요? 정부가 특정 도메인에 대한 감시를 목표로 가짜 인증서를 발급받고 싶어 한다고 가정해봅시다. 만약 이를 위해 CA를 강제할 수 있다면, 그들은 할 수 있을 것입니다. 하지만 이는 이제 훨씬 더 어렵습니다. 모든 주요 브라우저가 공격적인 인증서 투명성 검증을 실시하고 있고, 한 번 드러나면 브라우저는 그 CA를 제거할 수 있기 때문입니다.

핵심은 이것입니다: HTTPS 보안은 기술 자체가 아니라 신뢰 모델에 의존합니다. 이 모델은 완벽하지 않습니다. 정부, CA, 그리고 브라우저 개발자들 사이의 권력 관계에 영향을 받습니다. 하지만 지난 10년 동안, 그 균형은 일반 사용자와 개별 조직에 더 유리하게 기울었습니다.

CA 시스템과 인증서 투명성을 이해하면, "왜 내 브라우저가 어떤 사이트는 안전하다고 하고 다른 사이트는 경고할까"라는 질문의 답을 알 수 있습니다. 다음으로는 HTTPS 자체의 작동 방식, 또는 당신의 장치가 실제로 어떤 인증서를 신뢰하도록 설정되었는지 확인하는 방법을 탐색해보세요.