DNS CAA레코드는 무엇일까?

jroh.kr 에 let’s encrypt 로 SSL인증서를 적용하고 난 후,  Qualy’s SSL Labs 에서 인증서 적용상태를 체크해 보았습니다. 확인해 보니 Server Key and Certificate #1 Phase 에서 아래와 같이 DNS CAA가 없다고 판명되었습니다.

DNS CAA? 이건 어디에 쓰는 물건인가요?

1. DNS CAA란 뭘까?

위키피디아를 찾아 보니 DNS CAA는 DNS Certification Authority Authorization (CAA) 라고 되어 있습니다. DNS CAA는 RFC6844 에 정의되어 있습니다. CAA 레코드를 만든 목적은 특정 도메인의 CA (Certificate Authority) 가 어디인지를 알려주기 위한 목적이 있습니다.

가령 jroh.kr 에서 사용하는 CA기관은 comodo나 kisa가 아니라 let’s encrypt 이라는 CA기관 이다 라는 것을 DNS 쿼리를 이용하여 알려주는 것이죠. 그렇다면 왜 굳이 특정도메인 (jroh.kr) 에 대한 CA기관 정보를 도메인 레코드 타입 CAA를 통해서 알려주어야 할까요?

2. Certificate Pinning과 구라 Google 인증서 사건

2011년 DigiNotar 라는 곳에서 google 인증서에 대한 가짜 구글인증서 발급 사건이 발생한 적이 있습니다. DigiNotar는 네덜런드에 있는 CA기관인며 Root CA인증기관인데, 이를 통하여 구라 Google 인증서가 발급되어 논란이 되었던 것이죠.

보시다시피 구글의 Root CA기관은 GeoTrust Global CA입니다. 해당 기관을 통해서 발행된 구글의 인증서만 실제 구글의 인증서로써 유효 할 수 있는 것입니다. 그런데 공격자가 DigiNotar 루트 인증기관을 이용하여  구글의 인증서를 구라로 발행한 것입니다.

일반적으로 구라로 발행한 인증서는 브라우저가 안전한 인증서로 허용해주지 않지만 DigiNotar에서 생성된 Google인증서는 공인된 DigiNotar의 Root CA기관에서 만들어졌기 때문에 문제가 되었습니다. 브라우저에 기등록되어 있는 DigiNotar Root CA인증서를 통하여 잘못 발행된 구글인증서가 유효하게 허용 되었던 것입니다.

이를 통하여 공격자가 발행한 구라이면서 유효한 구글인증서가 이란에서 유통되었고, 많은 이란 사람들이 약 2달간 구글접속에 해당 인증서를 사용하였다고 합니다. 아마 많은 사람들의 상기 인증서를 통하여 암호화 통신을 하면서 민감정보를 주고 받았을 것이며, Gmail, Google docs 등의 구글기반 서비스들이 탈탈~ 털렸을 것임은 자명한 일이지요.

이에 MS사는 윈도우 업데이트를 통하여 해당 Root CA 인증서를 삭제하여 조치하였고, 파이어폭스, 크롬도 업데이트를 통하여 해당 인증서를 삭제하여 조치하였다고 합니다.

Microsoft 보안 권고 2607712 (사기성 디지털 인증서로 인한 스푸핑 문제점) : https://technet.microsoft.com/library/security/2607712

Microsoft 보안 권고 2524375 (사기성 디지털 인증서로 인한 스푸핑 문제점) : https://technet.microsoft.com/library/security/2524375

이 사건이 발생하였을 때, 크롬 브라우저의 경우는 그 가치를 널리 알리게 되었는데, 그 이유는 Certificate Pinning (HPKP) 라는 기술이 크롬 브라우저에 적용되었기 때문입니다. 크롬브라우저의 경우 Certificate Pinning (HPKP) 를 통하여 google.com 의 공개키는 Google CA기관에서만 발행됨이 명시되어 있었으며, 이에 따라 DigiNotar에서 발행된 Google 의 구라인증서를 미리 찾아 경고해 주었기 때문입니다.

구글은 구글 사이트들에 대한 인증을 해줄 수 있는 기관을 Verisign, Google Internet Authority, Equifax, GeoTrust 이렇게 4개의 인증기관으로 한정지어 두고 있습니다. 그래서 DigiNotar가 비록 root CA로써 활동하고 있는 인증 기관이지만 여기서 발행된 *.google.com에 대한 인증서는 크롬 입장에서는 ‘이상하군’ 하고 경고를 날려 줄 수 있었던 것이죠.

3. DNS를 이용한 CA Pinning (DNS CAA Record)

위에서 보신 바와 같이 DigiNotar 사건에서 Certificate Pinning (HPKP) 기술을 통하여 공개키의 유효성 여부를 검증하는 로직이 매우 효과적임이 입증되었습니다. 하지만 이는 클라이언트 및 브라우저 레벨에서 사이트의 공개키 인증서를 검증하는 단계만을 제공하고 있는 한계가 있습니다.

만약 DigiNotar 사건이 발생하였을 때, 브라우저에 적용되어 있는 Certificate Pinning (HPKP) 과 같이 공인 인증기관 (CA)이 특정 사이트에 대해서만 인증서를 발급 할 수 있도록 강제화 되어 있었다면 어땠을까요? 아마 DigiNotar CA기관에서는 google.com에 대한 인증서를 발행 할 수 없음을 알고 공격자의 인증서 발급을 거부하지 않았을까요?

이와 같이 인증기관 (CA)에서 인증서를 발급시 인증서를 발급할 호스트에 대해서 지정된 CA기관이 맞는지 확인하는 값이 바로 DNS CAA레코드 입니다. 도메인 관리자가 자신이 소유한 도메인 (jroh.kr) 에 대하여 인증서를 발행할 권한이 있는 CA기관이 어디어디 인지를 DNS CAA 레코드를 이용하여 진행하는 것이라고 보면 됩니다.

예를 들어 jroh.kr 의 CAA레코드가 letsencrypt.org 이라고 가정해보면 CA기관들은 인증서 발급전 jroh.kr의 CAA레코드를 룩업 및 체크하여 자기자신이 jroh.kr의 CA기관이며 인증서를 발행할 권한이 있는지 DNS쿼리를 이용하여 확인하게 되겠죠.

여기서 Kisa나  Comodo 같은 인증기관이 인증서 발급을 시도 할 경우

1. jroh.kr의 CAA레코드를 조회 한 후
2. CAA 레코드가 letsencrypt CA기관임을 확인 받겠죠.
3. 따라서 자기자신이 인증서를 발행할 CA기관이 아님을 알고
4. 인증서 생성을 거부 할 겁니다.

만약 적법한 letsencrypt 인증기관이 jroh.kr의 인증서 발급을 시도 할 경우

1. jroh.kr 의 CAA레코드를 조회하고
2. 자신이 jroh.kr의 인증서를 발행할 권한이 있는 CA기관임을 확인하고
3. 인증서를 발행 할 겁니다.

google.com 같은 경우는 symantec.com과 pki.goog 의 CA인증기관만 인증서를 발급 할 수 있겠군요

4. CAA 레코드 설정하기

CAA 레코드 포맷은 아래와 같은 형식을 가집니다.

CAA <flags> <tag> <value>

issue tag

issue tag는 해당 도메인의 인증서를 발행 할 수 있는 CA 를 지정합니다. 예를 들어 아래의 경우 jroh.kr 은 letsencrypt.org, comodoca.com 에서만 인증서를 발행 할 수 있습니다.

example.com.  CAA 0 issue "comodoca.com"
example.com.  CAA 0 issue "letsencrypt.org"

issuewild tag

issuewild tag는 wildcard 인증서를 생성 할 수 있는 CA기관을 지정 할 때 사용됩니다. 예를 들어 아래와 같은 경우 letsencrypt.org 를 통하여 인증서 발행이 가능하고 comodoca.com 을 이용해서는 wildcard 인증서를 발행 할 수 있습니다.

issuewild tag의 경우 issue tag와 같이 설정될 경우 override 되어 적용됨으로 현재 letsencrypt 에서는 지원되지 않고 있습니다.

jroh.kr.  CAA 0 issue "letsencrypt.org"
jroh.kr.  CAA 0 issuewild "comodoca.com"

iodef tag

CAA 레코드에 대한 정책 위반 내역을 수신 할 email 어드레스를 등록해 줍니다.

jroh.kr.  CAA 0 iodef "mailto:ca@jroh.kr"

5. DNS CAA레코드 타입의 지원범위는?

아직 DNS CAA레코드는 모든 CA기관에서 지원하지는 않고 있습니다. 하여 낮은버젼의 dig 명령어는 dig caa google 명령어를 이용한다고 해도 CAA 레코드 값을 반환하지 않습니다. 하여 필자는 맥에서 brew install bind 를 통하여 dig 를 9.11.1-P2 버젼으로 업그레이드 한 이후에 caa레코드를 조회 할 수 있었습니다.

CAA 레코드 타입은 Bind 9.9.6 이상 버젼에서 지원하고 있으며, 9.9.6 미만의 버젼은 레코드 타입Type257 로 지정하여 사용 할 수 있습니다.

$ dig google.com type257

; <<>> DiG 9.8.3-P1 <<>> google.com type257
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64266
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.            IN  TYPE257

;; ANSWER SECTION:
google.com.     86399   IN  TYPE257 \# 19 0005697373756573796D616E7465632E636F6D

;; Query time: 51 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Dec 29 21:07:18 2016
;; MSG SIZE  rcvd: 59

현재 CAA레코드 타입은 공식 지원하는 범위는 아니지만 2017년 3월 CA/Browser 포럼에서 진행된 투표결과에 따라 CAA 레코드는 2017년 9월부터 모든 CA기관에서 체킹 하기로 결의 되었습니다.

6. 기타

CAA 레코드 타입을 적용 테스트 하기 위하여 dns도메인 위임사이트와 AWS의 Route53을 체크해 보았으나 현재 CAA레코드는 모두 지원하고 있지 않습니다. 하여 CAA를 테스트 하기 위해서는 높은 버젼의 Bind를 자체 설치/운영하고 테스트 하여야 하는데, 네임서버 변경하고 적용하고 시간이 너무 소요될 꺼 같아 진행하지는 못했습니다.

DNS 레코드 타입을 이용하여 CA기관을 지정하는 부분이 논의되어 적용되어가고 있다라는 것을 공부한 좋은시간으로 생각하고 그냥 마무리 하겠습니다. ssllab 점수는 다른부분을 공부하고 높여야 겠습니다~~

참고로 CAA Record를 원하는 조건에 따라 Generate 해줄수 있는 툴을 sslmate.com에서 제공하고 있습니다. 관련 툴을 확인해보는 것도 CAA레코드를 이해하는데 참고가 될 것으로 생각 됩니다. (https://sslmate.com/labs/caa/)

읽어주셔서 감사합니다~