CAA를 사용해야하는 이유
CA는 항상 도메인 검증 모든 SSL /TLS 인증서 요청이 승인됩니다 (일반적으로 해당 도메인을 사용하는 특정 사이트에 어떤 방식 으로든 연결되어 있는지 확인).
예를 들어, CA는 요청자에게 특별한 확인 파일을 제공 할 수 있습니다. 이 파일을 웹 사이트에 배치하면 요청자가 해당 사이트를 제어한다는 것을 증명할 수 있지만 합법성 그 통제의. 사이트를 제어하는 해커는 합법적 인 소유자로 가장 한 다음 SSL /TLS CA의 표준 검사를 통과 한 인증서이므로 것 본격적인. 그런 다음 돌아 서서 SSL /TLS 해당 사이트 또는 다른 곳에서 장난에 대한 인증서.
CAA는 도메인에 대한 인증서를 발급 할 수있는 CA를 정의하거나 인증서 발급을 완전히 제한하여 이러한 종류의 악용을 차단하는 데 도움이됩니다. 이는 하이재커가 입힐 수있는 피해를 제한합니다. 사이트를 제어하더라도 불량 SSL / 점수를 획득 할 수있는 옵션이 크게 줄어들 것입니다.TLS 증명서.
CAA 작동 방식
CAA는 DNS를 사용합니다
XNUMXD덴탈의 도메인 이름 시스템 (DNS)는 인터넷 인프라의 중요한 부분입니다. 모든 도메인의 소유자는 DNS 레코드를 유지합니다 (소위 존 파일) 도메인 이름이 사이트가 호스팅되는 IP 주소를 가리 키도록하고 google.com 대신 브라우저 창으로 216.58.194.46.
DNS 레코드는 일반적으로 "인터넷 전화 번호부"로 사용되지만 DNS는 도메인 이름에 다른 정보를 할당 할 수있는 다른 유형의 특수 레코드도 허용합니다.
CAA 레코드
CAA는 A라는 특별한 종류의 레코드를 사용합니다. 인증 기관 인증 리소스 레코드 (CAA 레코드). 이들은 DNS를 사용하여 게시되며 도메인 소유자는 단순히 다른 DNS 레코드와 함께 CAA 레코드를 추가합니다. CAA 레코드에는 태그 및 가치태그-값 쌍은 재산. 도 있습니다 플래그 이 속성이 얼마나 중요한지를 나타냅니다. 다음은 다음과 같습니다.
example.com. CAA 0 문제 "ssl.com"
여기 example.com 이 레코드가 적용되는 도메인이며 CAA는이 레코드의 종류를 알려줍니다. 그만큼 0 플래그입니다 (기본값은 XNUMX입니다. 이에 대해서는 아래에서 설명하겠습니다). 태그는 발행물 따옴표 안에있는 값은 SSL.com함께 속성을 구성합니다.
깃발
플래그는 현재 엄격하게 정의 된 두 개의 상태 만 있습니다. 0 (중요하지 않은) 1 (위독한). 위험 플래그는 CA에 해당 플래그를 알려줍니다 절대로 필요한 것 계속하려면 속성 태그를 완전히 이해해야합니다. RFC 6844는 사용자 정의 플래그 사용을 위해 다른 가능성을 열어 둡니다 (아래에서도 설명하겠습니다).
태그
RFC 6844는 다음 세 가지 공통 태그 사용을 정의합니다. 발행물, 야생 와 아이오데프. 플래그와 마찬가지로 다른 잠재적 인 사용자 정의 태그 유형을 허용합니다.
XNUMXD덴탈의 발행물 태그
XNUMXD덴탈의 발행물 tag는이 도메인에 대한 인증서를 발급 할 권한이있는 CA를 지정합니다. 예를 들어 도메인 example.com의 소유자는 다음 DNS 영역 파일을 사용하여 인증서 발급을 하나의 CA (여기서는 SSL.com)로 제한 할 수 있습니다.
example.com. CAA 0 문제 "ssl.com"
도메인 소유자는 도메인에 여러 영역 파일을 설정하도록 선택할 수 있습니다.
example.com. CAA 0 문제 "ssl.com"example.com. CAA 0 문제 "comodoca.com"
위 기록은 SSL /TLS 에 대한 인증서 발급 example.com 두 개의 CA (SSL.com 및 Comodo.com)에 연결합니다.
XNUMXD덴탈의 발행물 또한 레코드는 명명 된 CA가 지정된 도메인의 하위 도메인에 대한 인증서를 발급 할 수있는 권한을 부여합니다. 따라서 SSL.com을 허용하는 레코드는 인증서 발급을 허용합니다. example.com 같은 하위 도메인 www.example.com, mail.example.com 심지어 특수 와일드 카드 하위 도메인 * .example.com.
CAA 레코드를 사용하여 얽매다 인증서 발급도 –이 레코드는 CAA를 사용하는 인증 기관에 아니 SSL /TLS 인증서 발급 example.com 하위 도메인 어떤 CA :
example.com. CAA 0 문제 ";"
(이 예에서 세미콜론은 "여기에 아무것도 허용하지 마십시오"하지만 나중에 보여 드리 겠지만 맞춤 매개 변수를 정의하는데도 사용됩니다.)
표준 발급 태그는 다음 사용자가 수정하지 않는 한 CA가 와일드 카드에 대한 인증서를 발급하도록 허용합니다.
XNUMXD덴탈의 야생 태그
이 태그는 CA가 소유자의 도메인에 대해 와일드 카드 인증서를 발급 할 권한이 있음을 지정합니다 (예 : * .example.com).
와일드 카드는 특별한 종류의 포괄적 인 하위 도메인이며 와일드 카드 인증서를 발급 할 때는 특별한주의와주의가 필요합니다. 그만큼 야생 태그를 사용하면 도메인 소유자가 기본 도메인 또는 다른 하위 도메인과 별도로 와일드 카드에 대한 인증서를 발급 할 수있는 CA를 정의 할 수 있습니다. 야생 태그는 어떤 태그보다 우선합니다 발행물 태그. 그들은 같은 구문을 사용합니다 발행물 꼬리표. 몇 가지 예 :
example.com. CAA 0 문제 "ssl.com"example.com. CAA 0 issuewild ";"
위의 내용은 SSL.com이 example.com 모든 하위 도메인 외 와일드 카드 * .example.com. (SSL.com이나 다른 CA 모두에 대해 와일드 카드 인증서를 발급 할 수 없습니다. example.com.)
example.com. CAA 0 문제 ";" example.com. CAA 0 issuewild "ssl.com"
이 예는 금지합니다 모든 인증서를 발급 할 CA example.com 하위 도메인을 포함하지만 SSL.com이 와일드 카드 인증서 (및 만 와일드 카드 인증서) example.com.
XNUMXD덴탈의 아이오데프 태그
세 번째로 정의 된 태그는 아이오데프. 이 태그는 유효하지 않은 인증서 요청을 도메인 소유자에게보고하는 데 사용할 수 있으며 다음과 같습니다.
example.com. CAA 0 iodef "mailto : certissues@example.com"example.com. CAA 0 iodef "certissues.example.com"
최상위 레코드는 주소로 이메일 알림을 보내는 데 필요한 CA 정보를 제공합니다. certissues@example.com. 두 번째는 CA가 사건 메시지를 웹 서비스 (도메인 소유자가이 목적으로 설정 한)에 게시하도록 지시합니다. certissues.example.com. (CA 및 도메인 소유자가 작업을 설정 한 방법에 따라 이러한 방법 중 하나 또는 둘 다를 사용할 수 있습니다.)
아이오데프 게시물 메시지는 표준 형식을 사용합니다. 인시던트 개체 설명 교환 형식 또는 IODEF – 따라서 이름. (IODEF는 RFC 6546.)
CA 정의 플래그 및 태그
RFC 6844에 설명 된 CAA는 0 개의 플래그 상태 (1 및 XNUMX)와 XNUMX 개의 태그 (발행물, 야생 와 아이오데프). 그러나 CA가 인증서 발급 프로세스를 정의하기 위해 사용자 지정 태그 및 플래그를 생성 및 활용하기에 충분한 디자인을 유지합니다. 예를 들면 다음과 같습니다.
example.com. CAA 0 문제 "SSL.com; policy = ev"
이 기록은 표준을 사용합니다 발행물 이 도메인에 대한 인증서를 발행 할 때 CA가 EV (Extended Validation) 정책을 사용하도록 지시하는 추가 매개 변수가있는 태그.
example.com. CAA 128 pca "PCA = 12345"
도메인 소유자는이 레코드를 새로운 CA 정의와 함께 사용할 수 있습니다 pca 태그를 사용하여 고객이 우선 고객 계정을 가지고 있음을 표시하고 계정 번호를 매개 변수로 설정합니다. (플래그는 최대 255 개의 사용자 정의 값일 수 있습니다.) CA가 계정을 설정하는 방법에 따라 특정 청구 방법, 추가 계정 정의 확인 또는 기타 특수 처리가 가능합니다.
장점과 단점
플러스…
CAA를 사용하는 몇 가지 훌륭한 이유가 있습니다. 가장 중요한 주요 장점은 인증서 오발의 위험을 크게 줄이는 CAA의 능력입니다. 이를 통해 도메인, 비즈니스 및 온라인 신원을 보호 할 수 있습니다. 특정 CA의 소프트웨어에서 버그를 발견했을 수있는 잠재적 공격자는이를 악용하여 도메인에 대한 SSL 인증서를 발급 할 수 없습니다. 또한 iodef 태그를 사용하면 익스플로잇이 시도 된 경우 보고서를받을 수 있습니다.
CAA의 디자인은 보안을 강화하지만 리소스를보다 세부적으로 할당 할 수도 있습니다. 예를 들어 회사는 영업 및 마케팅 부서가 지정된 소스에서 sales.example.com에 대한 SSL 인증서를 구매하도록 허용 (또는 제한)하는 레코드를 설정할 수 있습니다.
또한 CAA는 뛰어난 유연성을 제공합니다. 도메인 소유자의 경우 자체 제어하에 있고 필요에 따라 변경할 수있는 DNS 리소스 레코드를 사용하므로 특정 CA에 연결되지 않으며 (도메인 이름에 대해 발급 레코드를 가진 CA가 둘 이상 허용 될 수 있음) . CA의 경우 사용자 지정 용도를 제외하고 CA / B 포럼 (CA 및 브라우저 보안 문제에 대한 표준을 설정하는 그룹)에서 새로 채택한 규칙을 통해 CAA 레코드를 유효성 검사 목적으로 사용하여이를 활용해야 할 또 다른 이유를 제공 할 수 있습니다.
… 그리고 마이너스
CAA의 가장 큰 문제는 모든 CA에서 채택되지 않았다는 것입니다. CA / B 포럼의 기본 요구 사항 (신뢰할 수있는 모든 CA가 충족하는)은 CA가 온라인 설명서에서 CAA를 지원하는 정도를 지정하도록 지시합니다. 그러나이 글을 쓰는 시점에서 CAA 사용은 추천필수는 아닙니다. CAA를 준수하지 않는 인증 기관은 여전히 대상이 될 수 있으며, CAA가 더 광범위하게 사용될 때까지 하이재커가 불량 인증서를 발행 할 의사가있는 비준수 CA를 찾을 수 있습니다.
관련된 단점은 CAA 레코드가있는 경우에도 사용자가 억지로 시키다 인증 기관에 의한 사용. CA는 해당 레코드에 대한 조치를 취하기 위해 RFC 6844를 준수해야하며 비준수 CA는 CAA 레코드에 선언 된 도메인 소유자의 명시 적 요청을 무시할 수 있습니다.
CAA는 도메인 소유자와 CA 모두가 올바르게 구성해야합니다. Let 's Encrypt (CAA 지원) 최근 코드베이스에 사소한 문제가보고되었습니다. 불행히도 CAA 규칙이 무시되고 XNUMX 개의 인증서가 잘못 발급되었습니다. 이들 중 어느 것도 악의적 인 예외가 아니 었습니다 (그리고 발견 후 몇 시간 내에 문제를 해결하고보고 한 Let 's Encrypt 팀에 찬사를 보냅니다). 그러나 이것은 준수 인증 기관이 절대로 필요한 것 CAA 구현 완벽하게.
또 다른 잠재적 인 문제는 CAA가 DNS에 의존하는 것입니다. 도메인 소유자가 이름 서비스를 보호하지 않는 한 이것은 공격의 벡터가 될 수 있습니다. RFC 6844는 도메인 이름 시스템 보안 확장 (DNSSEC)디지털 서명 된 DNS 레코드를 사용하여 데이터를 인증하고 DNS 스푸핑 위협에 대처합니다.
마지막으로 CAA가 제자리에 있고 올바르게 구현 된 경우에도 CAA 레코드만으로는 불법 인증서 발급을 완전히 방지 할 수 없습니다. CAA는 공격자의 옵션을 제한하는 유용하고 중요한 도구이지만 충분한 액세스 권한을 가진 하이재커 (예 : DNS 제어 또는 사회 공학을 통해)는이를 우회 할 수 있습니다.
결론
인증 기관 인증은보다 광범위한 보안 생태계의 일환으로 엄청난 잠재력을 가지고 있으며 CAA의 광범위한 채택 및 구현은 인증서의 잘못된 발급을 방지합니다. 불행히도 모든 인증 기관이 현재 CAA를 지원하는 것은 아니지만 모든 CA에 대해 더 강력하게 제안하거나 의무화하는 것에 대한 논의가 있습니다. CAA만으로는 모든 인증서 발급 문제를 막을 수는 없지만 올바른 방향으로 나아가는 것이 좋습니다. SSL.com에서는 CAA 레코드를 직접 사용하는 것이 좋습니다.
참고자료
- RFC6844 : DNS 인증 기관 인증 (CAA) 리소스 레코드
- RFC5070 : 인시던트 개체 설명 교환 형식
- RFC6546 : HTTP /를 통한 RID (Real-Network Defense) 메시지 전송TLS
- RFC4033 : DNS 보안 소개 및 요구 사항
- CA / B 포럼 투표 125 – CAA 기록
- DNS 인증 기관 인증에 관한 Wikipedia 항목
