지금까지 도메인과 이름 조회, 인증서를 다루며 그 편리함과 유연함을 살폈다. 그러나 이 체계는 원래 신뢰할 수 있는 환경을 전제로 설계되어, 응답이 진짜인지를 검증하는 장치가 처음에는 없었다. 이름 조회의 응답을 중간에서 가로채 조작하면, 사용자는 가짜 주소를 진짜로 믿고 엉뚱한 서버로 향하게 된다. 이 근본적인 약점을 메우기 위한 보안 장치들이 뒤늦게 도입되었다.
이번 편은 이름 조회의 보안을 다룬다. 이름 조회에 어떤 근본적 신뢰 문제가 있는지, 응답에 서명을 붙이는 확장은 무엇인지, 그 서명이 신뢰의 사슬을 어떻게 잇는지, 도입에 어떤 비용과 위험이 따르는지, 인증서 발급을 통제하는 레코드는 무엇인지, 이름 조회 자체를 암호화하는 흐름은 어떠한지, 그리고 이 보안 장치들을 어떻게 바라보아야 하는지를 차례로 짚는다. 이로써 도메인과 이름 조회의 여정이 한 바퀴를 돈다.
이름 조회의 근본적 신뢰 문제
이름 조회의 응답은 오랫동안 진위를 검증할 수단 없이 오갔다. 사용자의 조회에 돌아오는 주소가 정말 그 도메인의 권위 있는 서버가 내놓은 것인지, 아니면 중간의 누군가가 조작한 것인지를 구분할 방법이 없었다. 그래서 응답을 가로채 가짜 주소로 바꾸면, 사용자는 그 가짜 주소를 의심 없이 믿고 공격자의 서버로 연결한다.
이 조작이 특히 위험한 이유는 그 위에 놓인 다른 보안 장치까지 무력화할 수 있기 때문이다. 사용자가 공격자의 서버로 유도되면, 그 서버가 사용자의 첫 요청을 가로채 보안 연결로 올라가는 안내를 지우거나 가짜 페이지를 내밀 수 있다. 이름 조회의 신뢰가 무너지면 그 위의 모든 것이 흔들리는 셈이다. 이름 조회는 웹 신뢰의 가장 아래 토대다.
중간에서 응답을 조작하는 것 외에, 캐시에 가짜 답을 심는 수법도 있다. 조회를 대신하는 캐시에 위조된 답을 미리 밀어 넣으면, 그 캐시를 쓰는 여러 사용자가 한꺼번에 가짜 주소를 받는다. 하나의 캐시를 오염시켜 다수를 속이는 이 수법은 이름 조회 보안의 오랜 위협이었다. 응답의 진위를 검증할 수 없다는 근본 약점이 이 모든 공격의 뿌리다.
이 약점을 메우는 방향은 두 가지다. 하나는 응답 자체에 서명을 붙여 그것이 진짜 권위 있는 서버에서 왔고 조작되지 않았음을 검증하게 하는 것이고, 다른 하나는 조회가 오가는 통로 자체를 암호로 감싸 중간에서 엿보거나 조작하지 못하게 하는 것이다. 이 두 방향은 서로 다른 문제를 풀며, 함께 쓰일 때 이름 조회가 온전히 안전해진다.
응답에 서명을 붙이는 확장
첫 번째 방향은 이름 조회의 응답에 암호적 서명을 붙이는 확장이다. 권위 있는 서버가 자신의 비밀 열쇠로 레코드에 서명을 만들어 응답에 함께 담고, 그에 대응하는 공개 열쇠를 조회로 얻을 수 있게 해 둔다. 조회하는 쪽은 이 서명을 공개 열쇠로 검증해, 응답이 정말 그 도메인의 권위 있는 서버에서 왔고 도중에 조작되지 않았음을 확인한다.
이 서명은 응답의 내용을 바꾸는 것이 아니라 진위를 증명하는 층을 덧붙이는 것이다. 서명이 검증되면 그 응답은 신뢰할 수 있고, 검증에 실패하면 조작된 것으로 보아 거부할 수 있다. 이로써 중간에서 응답을 조작하거나 캐시에 가짜 답을 심는 공격이 무력해진다. 조작된 응답은 서명 검증을 통과하지 못하기 때문이다. 진위 검증이 조작의 여지를 닫는다.
이 확장은 응답을 암호화하지는 않는다. 서명은 응답이 진짜임을 증명할 뿐, 응답의 내용을 감추지는 않으므로 중간에서 어떤 이름이 조회되는지는 여전히 보인다. 진위 검증과 내용 은폐는 다른 문제이며, 이 확장은 진위 검증만 담당한다. 내용을 감추는 일은 뒤에서 다룰 통로 암호화가 맡는다. 두 장치의 역할을 구분해야 각각의 한계를 이해할 수 있다.
서명 확장이 동작하려면 조회하는 쪽도 검증을 수행해야 한다. 서명이 응답에 담겨 있어도 조회하는 쪽이 그것을 검증하지 않으면 아무 효과가 없다. 그래서 이 확장의 효과는 권위 있는 서버가 서명을 붙이고, 조회를 대신하는 쪽이 그 서명을 검증하는 양쪽의 참여가 갖추어질 때 비로소 나타난다. 한쪽만 준비되어서는 보호가 성립하지 않는다.
서명이 신뢰의 사슬을 잇는 방식
서명의 신뢰는 인증서와 마찬가지로 사슬을 따라 이어진다. 어떤 도메인의 서명을 검증하려면 그 도메인의 공개 열쇠가 필요한데, 그 공개 열쇠가 진짜인지는 상위 계층이 보증한다. 상위 계층은 하위 도메인의 열쇠에 대한 정보를 서명해 두고, 그 상위의 열쇠는 다시 그 위가 보증한다. 이 사슬을 거슬러 오르면 모두가 신뢰하는 뿌리 열쇠에 닿는다.
이 사슬 덕분에 조회하는 쪽은 뿌리 열쇠 하나만 신뢰하면 그 아래 모든 도메인의 서명을 검증할 수 있다. 뿌리가 최상위 도메인의 열쇠를 보증하고, 최상위 도메인이 개별 도메인의 열쇠를 보증하는 식으로 신뢰가 아래로 흐른다. 위임의 계층 구조가 그대로 신뢰의 사슬이 되는 것이다. 이름 조회의 계층과 서명의 사슬이 같은 나무를 따라 이어진다.
이 사슬을 잇기 위해 상위 계층에 특별한 정보를 등록해야 한다. 하위 도메인의 열쇠에 대한 지문을 상위 계층에 올려 두면, 상위가 그것을 보증해 사슬이 연결된다. 이 등록을 빠뜨리면 서명은 붙어 있어도 사슬이 끊겨, 조회하는 쪽이 열쇠를 신뢰할 근거를 얻지 못한다. 서명을 도입할 때 이 상위 등록까지 마쳐야 검증이 성립한다.
사슬의 어느 고리가 어긋나면 그 아래 전체의 검증이 실패한다. 열쇠를 교체하면서 상위 등록을 함께 갱신하지 않거나, 서명이 만료되도록 방치하면 사슬이 끊긴다. 이때 검증을 수행하는 조회 환경에서는 그 도메인이 아예 응답하지 않는 것처럼 보인다. 서명 확장은 보안을 더하는 만큼, 사슬을 유지하는 관리의 책임도 함께 지운다. 이 관리의 무게가 도입을 신중하게 만드는 이유다.
도입의 비용과 위험
서명 확장은 강력하지만 도입에 만만치 않은 비용과 위험이 따른다. 열쇠를 만들어 관리하고, 주기적으로 교체하고, 서명을 갱신하고, 상위 등록을 유지하는 일이 모두 이 확장을 지탱하는 데 필요하다. 이 관리 중 하나라도 어긋나면 도메인이 검증 환경에서 통째로 응답하지 못하게 되므로, 보호를 얻는 대신 새로운 장애의 원인을 떠안는 셈이다.
가장 큰 위험은 열쇠와 서명의 수명 관리다. 서명에는 유효 기간이 있어 제때 갱신하지 않으면 만료되고, 열쇠를 교체할 때 절차를 어기면 사슬이 끊긴다. 이 관리를 사람의 손에 맡기면 실수가 따르므로, 서명 확장을 도입할 때는 열쇠 교체와 서명 갱신을 자동화하는 체계를 함께 갖추는 것이 사실상 필수다. 자동화 없는 도입은 스스로 위험을 키운다.
많은 이름 조회 서비스가 이 관리를 대신해 준다. 서비스가 열쇠 생성과 서명, 갱신, 교체를 자동으로 처리하고 소유자는 상위 등록만 하면 되는 방식이 널리 쓰인다. 이렇게 관리를 위임하면 도입의 부담이 크게 줄지만, 그 서비스가 열쇠를 안전하게 다루는지를 신뢰해야 한다. 편의와 통제 사이의 저울질이 여기서도 나타난다.
이 비용 때문에 서명 확장의 도입은 서비스의 성격에 따라 판단할 문제다. 조작될 경우 피해가 큰 민감한 서비스라면 관리 부담을 감수하고 도입할 가치가 있고, 그렇지 않은 서비스라면 다른 보안 장치로 충분할 수 있다. 모든 도메인이 반드시 이 확장을 갖추어야 하는 것은 아니며, 얻는 보호와 치르는 관리 비용을 견주어 결정할 일이다. 보안은 언제나 비용과의 균형이다.
발급을 통제하는 레코드
이름 조회 보안과 나란히 두어야 할 또 하나의 장치는 인증서 발급을 통제하는 레코드다. 앞서 인증서 편에서 다룬 것처럼, 도메인은 어떤 기관이 자신의 인증서를 발급할 수 있는지를 레코드로 명시할 수 있다. 이 레코드가 있으면 발급 기관은 발급 전에 그것을 조회해 자신이 허용되었는지를 확인하고, 허용되지 않았으면 발급을 거부한다.
이 통제가 필요한 이유는 인증서 발급이 도메인 검증만으로 이루어지기 때문이다. 검증 절차가 어딘가에서 뚫리면 공격자가 유효한 인증서를 손에 넣어 사칭에 쓸 수 있는데, 발급 가능한 기관을 미리 제한해 두면 그 위험을 좁힐 수 있다. 어느 기관을 통해서든 발급이 가능한 상태보다, 지정한 몇몇 기관으로 한정한 상태가 훨씬 안전하다.
이 레코드는 이름 조회 보안과 결합될 때 더 견고해진다. 발급 통제 레코드 자체도 조회로 전달되므로, 그 응답이 조작되면 통제가 무력해질 수 있다. 응답에 서명을 붙이는 확장이 함께 적용되어 있으면, 이 통제 레코드의 진위까지 검증되어 조작이 어려워진다. 두 장치가 서로를 보강하는 것이다. 이름 조회의 진위 검증이 그 위에 놓인 다른 정책들의 신뢰까지 떠받친다.
발급 내역을 사후에 감시하는 것도 이 통제를 보완한다. 발급된 인증서는 공개 기록에 남으므로, 자신의 도메인에 대해 지정하지 않은 인증서가 발급되었는지를 주기적으로 살피면 뒤늦게라도 이상을 잡아낸다. 발급을 막는 레코드가 사전 방어라면 발급 내역 감시는 사후 탐지이며, 둘을 함께 두면 인증서라는 민감한 통로를 앞뒤로 지킬 수 있다. 보안은 한 겹이 아니라 여러 겹으로 쌓을 때 튼튼하다.
이름 조회 자체를 암호화하기
두 번째 방향은 이름 조회가 오가는 통로 자체를 암호로 감싸는 것이다. 서명 확장이 응답의 진위를 검증하는 반면, 통로 암호화는 조회의 내용을 감춘다. 이 암호화가 없으면 중간의 누군가가 사용자가 어떤 이름을 조회하는지를 그대로 엿볼 수 있어, 방문하는 사이트의 목록이 노출된다. 통로 암호화는 이 엿보기를 막는다.
이 암호화는 사용자의 기기와 조회를 대신하는 서비스 사이의 구간을 감싼다. 이 구간이 암호화되면 중간에서 조회 내용을 볼 수 없고, 응답을 조작하기도 어려워진다. 그래서 통로 암호화는 내용 은폐와 함께 어느 정도의 조작 방지 효과도 준다. 다만 이것은 사용자와 조회 서비스 사이만 지키며, 그 서비스 너머의 구간까지 지키는 것은 아니다. 보호의 범위를 정확히 아는 것이 중요하다.
통로 암호화와 서명 확장은 서로를 대체하지 않는다. 통로 암호화는 내용을 감추지만 조회 서비스 자체가 정직한지는 보증하지 못하고, 서명 확장은 응답의 진위를 끝까지 검증하지만 내용을 감추지는 못한다. 두 장치는 다른 위협을 막으므로, 온전한 보안을 위해서는 둘을 함께 갖추는 것이 이상적이다. 하나로 모든 위협을 막을 수 있다고 여기는 것이 흔한 오해다.
통로 암호화가 확산되면서 조회 서비스의 선택이 새로운 신뢰의 문제로 떠올랐다. 조회를 특정 서비스에 암호화된 통로로 맡기면, 그 서비스는 사용자의 조회 내용을 모두 보게 된다. 중간의 엿보기를 막는 대신 그 서비스에게 조회 이력을 맡기는 셈이므로, 어느 조회 서비스를 신뢰할지가 중요해진다. 보안 장치는 위협을 옮길 뿐 없애지 못하는 경우가 있으며, 그 옮겨진 곳을 살피는 안목이 필요하다.
보안 장치를 바라보는 눈
이름 조회의 보안 장치들은 저마다 특정한 위협을 막지만, 어느 하나도 모든 위협을 홀로 막지는 못한다. 서명 확장은 진위를, 통로 암호화는 내용을, 발급 통제는 인증서의 오남용을 각각 맡는다. 이들을 함께 쌓을 때 이름 조회의 여러 약점이 겹겹이 메워진다. 보안은 하나의 완벽한 장치가 아니라 서로 다른 층의 방어가 겹쳐 이루는 것이다.
이 장치들을 도입할 때는 얻는 보호와 치르는 비용을 늘 견주어야 한다. 서명 확장은 강력하지만 관리 부담이 크고, 통로 암호화는 조회 서비스에 대한 신뢰를 요구한다. 모든 장치를 무조건 갖추는 것이 능사가 아니라, 서비스가 마주한 위협과 감당할 수 있는 관리 역량에 맞추어 고르는 것이 현실적인 판단이다. 과한 보안은 스스로 장애의 원인이 되기도 한다.
보안 장치를 도입한 뒤에는 그것이 실제로 동작하는지를 지속적으로 확인해야 한다. 서명이 제때 갱신되는지, 사슬이 끊기지 않았는지, 발급 통제가 유지되는지를 감시하지 않으면, 켜 두었다는 사실만으로 안심하다 어느 순간 보호가 비어 있음을 뒤늦게 안다. 보안은 한 번 설정하고 잊는 것이 아니라 살아 있는 상태로 지켜봐야 하는 것이다. 이는 인증서와 전자우편 인증에서도 반복된 원리다.
이렇게 이름 조회의 신뢰 문제, 응답 서명, 신뢰의 사슬, 도입의 비용, 발급 통제, 통로 암호화, 그리고 이들을 바라보는 눈까지 짚으며 도메인과 이름 조회의 여정을 마친다. 도메인이라는 이름에서 출발해 레코드와 위임, 전파, 인증서, 전자우편, 검색, 이전, 진단, 그리고 보안까지 한 바퀴를 돌았다. 도구와 서비스는 계속 바뀌지만, 이름이 주소로 이어지고 그 이름 위에 신뢰가 쌓이는 원리는 바뀌지 않는다. 그 원리를 손에 쥐고 있으면, 어떤 새로운 도구를 만나도 그 아래에서 무슨 일이 벌어지는지를 스스로 읽어 낼 수 있다.