[웹 기반기술 41] DNS - HTTPS와 인증서

도메인을 서버에 연결했다면 그 위를 오가는 통신을 안전하게 만드는 일이 남는다. 오늘날의 웹은 거의 예외 없이 보안 연결을 요구하며, 보안 연결이 아닌 사이트는 브라우저가 경고로 밀어낸다. 이 보안 연결의 바탕에는 인증서라는 신원 증명이 놓여 있다. 인증서가 없으면 통신을 암호로 감쌀 수 없고, 상대가 정말 그 도메인의 주인인지도 확인할 수 없다.

이번 편은 보안 연결과 인증서의 원리를 다룬다. 보안 연결이 지키려는 것이 무엇인지, 인증서가 어떤 신원 증명인지, 그 신뢰가 어떤 사슬을 따라 이어지는지, 안전한 연결이 맺어지는 순간 무슨 일이 벌어지는지, 그리고 실무에서 인증서를 다룰 때 무엇을 감각으로 익혀야 하는지를 차례로 짚는다. 인증서의 원리를 이해하면 자물쇠 표시 하나가 무엇을 보증하고 무엇을 보증하지 않는지가 분명해진다.

보안 연결이 지키는 것

보안 연결은 크게 세 가지를 지킨다. 첫째는 기밀성으로, 오가는 내용을 암호로 감싸 중간의 누구도 엿보지 못하게 하는 것이다. 둘째는 무결성으로, 전달되는 도중에 내용이 조작되면 그것을 알아챌 수 있게 하는 것이다. 셋째는 인증으로, 연결한 상대가 정말 그 도메인의 주인인지를 확인하는 것이다. 이 세 가지가 함께 갖추어져야 통신이 안전하다고 말할 수 있다.

암호화만으로는 안전이 완성되지 않는다. 내용을 아무리 튼튼하게 암호로 감싸도, 그 암호를 나눈 상대가 사실은 중간에서 가로챈 공격자라면 암호화는 오히려 공격자에게 내용을 안전하게 전달하는 꼴이 된다. 그래서 암호화보다 먼저 필요한 것이 상대의 신원 확인이다. 지금 암호를 나누는 상대가 진짜 그 도메인인지를 검증한 뒤에야 암호화가 의미를 가진다.

이 신원 확인의 문제를 인증서가 해결한다. 인증서는 어떤 도메인 이름이 어떤 공개 열쇠에 묶여 있음을 신뢰할 수 있는 제삼자가 보증한 문서다. 연결한 상대가 그 도메인의 인증서를 제시하고 그에 대응하는 비밀 열쇠를 실제로 쥐고 있음을 증명하면, 상대가 그 도메인의 주인임을 믿을 근거가 생긴다. 인증서는 이름과 열쇠를 잇는 공증된 다리다.

보안 연결이 중요한 이유는 사용자가 오가는 경로를 통제할 수 없기 때문이다. 요청은 여러 중계 지점을 거쳐 서버에 닿는데, 그 경로의 어느 지점이든 내용을 엿보거나 조작할 수 있다. 공용 통신망처럼 신뢰할 수 없는 경로에서는 이 위험이 특히 크다. 보안 연결은 경로가 아무리 신뢰할 수 없어도 양 끝단만 신뢰할 수 있으면 통신을 지켜 준다.

인증서라는 신분증

인증서는 사람의 신분증에 견줄 수 있다. 신분증에 이름과 사진이 담기고 발급 기관의 도장이 찍히듯, 인증서에는 도메인 이름과 공개 열쇠가 담기고 발급 기관의 서명이 붙는다. 이 서명이 인증서의 내용이 위조되지 않았음을 보증한다. 누구든 인증서를 만들 수는 있지만, 신뢰받는 기관의 서명이 없으면 그 인증서는 브라우저가 받아들이지 않는다.

인증서에는 유효 기간이 있다. 발급된 순간부터 정해진 기간까지만 유효하며, 그 기간이 지나면 인증서는 만료되어 더는 신뢰받지 못한다. 유효 기간을 두는 이유는, 열쇠가 유출되거나 상황이 바뀌었을 때 낡은 인증서가 무한히 통용되는 것을 막기 위해서다. 만료된 인증서를 제시하는 사이트에 브라우저가 경고를 내는 것은 이 원칙 때문이다.

인증서는 검증 수준에 따라 나뉜다. 가장 기본은 도메인의 소유만 확인하는 것으로, 그 도메인을 통제하는 사람이 발급을 요청했다는 사실만 보증한다. 더 높은 수준은 도메인 소유를 넘어 그 조직이 실재하는지까지 확인한다. 다만 오늘날 브라우저의 주소창은 이 수준의 차이를 거의 드러내지 않으므로, 대부분의 서비스에는 도메인 소유를 확인하는 기본 인증서로 충분하다.

하나의 인증서에 여러 이름을 담을 수도 있다. 여러 서브도메인이나 여러 도메인을 한 인증서에 함께 넣으면 하나의 인증서로 여러 이름을 보증할 수 있다. 특정 상위 도메인 아래의 모든 서브도메인을 포괄하는 방식도 있다. 어떤 이름들을 한 인증서에 묶을지는 관리 편의와 위험 분산 사이에서 정하는 설계의 문제다.

여러 이름을 한 인증서에 묶으면 관리는 편해지지만 위험은 한곳에 모인다. 그 인증서의 비밀 열쇠가 유출되면 묶인 모든 이름이 한꺼번에 위태로워지고, 인증서를 교체할 때도 묶인 서비스가 함께 영향을 받는다. 반대로 이름마다 인증서를 따로 두면 위험은 흩어지지만 관리할 인증서의 수가 늘어난다. 이 둘 사이의 균형은 서비스의 규모와 각 이름의 민감도에 따라 달라지며, 민감한 기능일수록 별도 인증서로 떼어 두는 편이 안전하다.

신뢰가 이어지는 사슬

브라우저가 인증서를 신뢰하는 근거는 서명의 사슬이다. 서버가 제시한 인증서에는 그것을 발급한 기관의 서명이 있고, 그 기관의 인증서에는 다시 상위 기관의 서명이 있다. 이 사슬을 거슬러 올라가면 브라우저가 처음부터 신뢰하기로 정해 둔 최상위 기관에 닿는다. 사슬의 끝이 이 신뢰의 뿌리에 이어지면, 브라우저는 서버의 인증서를 신뢰한다.

이 신뢰의 뿌리는 브라우저와 운영 체제에 미리 심어져 있다. 널리 검증된 최상위 기관들의 목록이 기기에 저장되어 있고, 이 목록에 든 기관이나 그 아래로 이어지는 서명만이 신뢰의 사슬을 완성할 수 있다. 목록에 없는 기관이 서명한 인증서는, 아무리 형식이 완벽해도 브라우저가 신뢰하지 않는다. 신뢰의 출발점이 이렇게 미리 정해져 있다는 점이 이 체계의 토대다.

서버는 자신의 인증서만이 아니라 사슬의 중간 인증서까지 함께 제시해야 한다. 브라우저가 신뢰의 뿌리까지 사슬을 이을 수 있으려면 중간 고리가 빠짐없이 전달되어야 하기 때문이다. 중간 인증서를 빠뜨리면, 서버 인증서 자체는 올바른데도 사슬이 끊겨 일부 브라우저에서 신뢰가 성립하지 않는다. 이 누락은 실무에서 자주 겪는 원인 모를 신뢰 오류의 배후다.

신뢰의 사슬은 어느 한 고리가 무너지면 그 아래 전체가 위태로워지는 구조다. 최상위 기관이나 중간 기관의 비밀 열쇠가 유출되면, 그 아래로 위조 인증서가 발급될 수 있다. 그래서 이 기관들은 열쇠를 극도로 엄격하게 보관하며, 문제가 생긴 인증서를 즉시 무효로 만드는 장치도 갖춘다. 신뢰의 사슬은 편리한 만큼 그 뿌리와 중간을 지키는 책임이 무겁다.

안전한 연결이 맺어지는 순간

안전한 연결은 실제 데이터를 주고받기 전에 짧은 준비 과정을 거친다. 이 과정에서 서버는 자신의 인증서를 제시하고, 브라우저는 그 인증서의 서명 사슬을 검증한다. 사슬이 신뢰의 뿌리에 닿고 인증서의 이름이 접속하려는 도메인과 일치하며 유효 기간이 지나지 않았다면, 브라우저는 이 서버를 신뢰하기로 한다. 이 검증이 통과해야 다음 단계로 넘어간다.

신원이 확인되면 양측은 앞으로 통신을 감쌀 열쇠를 안전하게 나눈다. 이때 인증서에 담긴 공개 열쇠가 쓰인다. 서버만이 대응하는 비밀 열쇠를 쥐고 있으므로, 공개 열쇠로 안전하게 전달된 정보는 오직 그 서버만 풀 수 있다. 이 성질을 이용해 양측은 엿보는 사람이 있어도 안전하게 공통의 열쇠에 합의한다. 이 합의가 이후 통신을 암호로 감싸는 바탕이 된다.

이름의 일치 검증은 특히 중요하다. 인증서가 신뢰받는 기관의 서명을 가졌더라도, 그 인증서에 담긴 이름이 접속하려는 도메인과 다르면 신뢰가 성립하지 않는다. 이 검증이 있기에 공격자가 다른 도메인의 유효한 인증서를 훔쳐 와도 그것으로 이 도메인을 사칭할 수 없다. 서명의 유효함과 이름의 일치는 함께 확인되어야 하는 두 조건이다.

이름 검증에는 인증서에 담긴 이름의 형태도 관여한다. 하나의 인증서가 여러 이름을 담을 수 있고 포괄 이름으로 서브도메인을 아우를 수도 있으므로, 브라우저는 접속한 도메인이 인증서에 담긴 이름들 중 하나와 맞는지를 규칙에 따라 대조한다. 포괄 이름은 한 단계의 서브도메인만 포괄하고 더 깊은 단계나 뿌리 이름은 포괄하지 않으므로, 인증서가 실제로 어느 이름까지 보증하는지를 정확히 알아야 한다. 이 대조 규칙을 오해하면 인증서는 유효한데도 이름이 맞지 않아 신뢰가 성립하지 않는 상황을 만난다.

이 준비 과정이 끝나면 이후의 모든 통신은 합의된 열쇠로 암호화되어 오간다. 중간의 누군가가 내용을 엿보아도 열쇠 없이는 풀 수 없고, 내용을 조작하면 무결성 검증에서 드러난다. 준비 과정은 매 연결의 시작에 잠깐의 부담을 더하지만, 그 대가로 이후 통신 전체의 안전을 확보한다. 이 짧은 준비가 보안 연결의 핵심이다.

인증서를 다루는 감각

실무에서 인증서를 다룰 때 가장 먼저 익혀야 할 감각은 만료를 놓치지 않는 것이다. 인증서가 만료되면 사이트 전체가 경고에 막혀 사실상 접속 불가 상태가 된다. 유효 기간이 짧아지는 추세이므로 갱신을 사람의 기억에 맡기는 것은 위험하며, 발급과 갱신을 자동으로 반복하는 체계를 갖추는 것이 정석이다. 이 자동화는 다음 편에서 자세히 다룬다.

두 번째 감각은 비밀 열쇠를 지키는 것이다. 인증서가 보증하는 신뢰는 결국 서버만이 대응하는 비밀 열쇠를 쥐고 있다는 전제 위에 서 있다. 이 열쇠가 유출되면 공격자가 그 도메인을 사칭할 수 있으므로, 비밀 열쇠는 접근을 엄격히 제한하고 외부로 새어 나가지 않게 관리해야 한다. 인증서 자체는 공개되어도 무방하지만 비밀 열쇠는 서버 안에 갇혀 있어야 한다.

세 번째 감각은 신뢰 오류의 원인을 나누어 진단하는 것이다. 브라우저가 신뢰 오류를 낼 때, 그것이 만료 때문인지, 이름 불일치 때문인지, 사슬 누락 때문인지, 아니면 신뢰받지 못하는 기관의 서명 때문인지를 구분해야 한다. 각 원인은 해결 방법이 다르므로, 오류 메시지가 가리키는 지점을 정확히 읽는 것이 빠른 해결의 열쇠다.

마지막 감각은 자물쇠 표시의 의미를 과신하지 않는 것이다. 주소창의 자물쇠는 연결이 암호화되었고 상대가 그 도메인의 주인임을 뜻할 뿐, 그 사이트가 선의를 가졌음을 보증하지는 않는다. 사기 사이트도 유효한 인증서를 갖출 수 있다. 인증서는 통신의 안전과 상대의 신원을 보증하는 것이지, 상대의 정직함까지 보증하는 것이 아니라는 점을 분명히 해 두어야 한다.

무효화라는 뒷문

인증서에는 유효 기간이 있지만, 기간이 남았더라도 문제가 생기면 그 전에 무효로 만들어야 할 때가 있다. 비밀 열쇠가 유출되었거나 잘못 발급된 인증서가 발견되면, 발급 기관은 그 인증서를 무효 목록에 올려 더는 신뢰받지 못하게 한다. 유효 기간이 자연스러운 만료를 담당한다면, 무효화는 만료 전에 신뢰를 강제로 거두는 뒷문이다.

문제는 브라우저가 이 무효 여부를 실시간으로 확인하기가 쉽지 않다는 데 있다. 무효 목록을 매번 조회하면 연결이 느려지고, 목록을 배포하는 서버가 응답하지 않으면 검증 자체가 막힌다. 그래서 무효 확인은 완벽하게 동작하지 못하는 경우가 많고, 이 약점이 짧은 유효 기간을 선호하게 만든 배경이 되었다. 인증서의 수명을 짧게 하면, 무효화가 제대로 전달되지 않더라도 문제가 오래 지속되지 않는다.

이 때문에 최근의 흐름은 인증서 수명을 점점 줄이는 방향으로 가고 있다. 수명이 짧으면 유출된 열쇠나 잘못된 인증서가 통용될 수 있는 창이 좁아지고, 무효화라는 불완전한 장치에 덜 의존하게 된다. 대신 짧은 수명은 잦은 갱신을 요구하므로, 갱신을 자동화하는 것이 필수가 된다. 무효화의 한계가 짧은 수명을 낳고, 짧은 수명이 자동 갱신을 낳는 흐름이다.

무효화의 존재는 신뢰가 한번 부여되면 끝나는 것이 아니라 언제든 거두어질 수 있는 것임을 보여 준다. 발급은 신뢰의 시작일 뿐이고, 그 신뢰는 문제가 드러나는 순간 철회되어야 한다. 이 철회의 통로가 있기에 인증서 체계는 사고에 대응할 여지를 갖는다. 이렇게 보안 연결이 지키는 것, 인증서의 성격, 신뢰의 사슬, 연결이 맺어지는 순간, 인증서를 다루는 감각, 그리고 무효화라는 뒷문까지 이해하면 자물쇠 하나의 의미가 또렷해진다. 다음 편은 이 인증서를 실제로 발급받고 갱신하는 과정을 다룬다.