태그 Archives: CAA

CAA 설정

SSL 암호화 를 적용을 하게 되면 공격자가 데이터를 직접 열어보거나 변조가 어렵다.

다만 Man In Middle Attack 만 가능할 뿐이다.

 

MIMT 공격은 중간에 패킷을 가로채서 endpoint으로 재전송을 할수 있겠다.

이는 프로그래밍 단에서 한번만 작동을 하도록 하면 되기 때문에 큰 문제가 되기 어렵다.

 

다만 다른 CA (인증서 발급 기관) 에서 같은 도메인을 가지고 인증서를 발급했다면 패킷을 변조하여 전송이 가능하다.

즉 클라이언트 A 가  인증업체D 에서 발급 받은 인증서로 운영 되는 B 회사의 서버에 접속하려고 할때

공격자 C 가 다른 인증서 발급 업체인 E 에서 발급 받아 패킷을 가로채서 서비스 하거나, 변조해서 엔드포인트로 전송을 할수 있다.

aaaaaaaaaaaaaaaaaaaaaaaa

때문에 이러한 공격에 대비하기 위해 HTTP Public Key Pinning (HPKP) 혹은 Certification Authority Authorization (CAA)

를 설정 하여 막을 수 있다.

 

이는 브라우져 에서도 지원해야 막을 수 있기 때문에 꼭 막힌다는 보장이 되지는 않다.

chrome 의 경우 현재 HPKP 를 지원한다.

다만 HPKP 의 경우 인증서에서 pin을 생성하고 그것을 http header 에 추가 하여 진행하기 때문에 인증서가 교체 될 경우 문제가 발생할 소지가 높다.

물론 백업 키를 생성하여 추가 등록을 한다지만 아슬아슬한게 사실이다 ‘ㅅ’a

 

CAA 의 경우 각 CA 들이 CAA 검증 이후 인증서 발급을 하도록 결의 했고 실행하고 있다.

때문에 CAA를 등록하는 것만으로 자신의 도메인의 인증서를 다른 업체를 통해서 재발급이 어렵다고 본다. ‘ㅅ’a

(물론 자신의 경우엔 인증서 발급업체의 변경을 고려 할때 1~2일전에 미리 CAA 값을 추가 해두어야 하겠다.)

 

CAA 레코드는 아래와 같이 설정한다. (let’s encrypt 일 경우)

CAA 의 맨 마지막에 지정되는 벤더 값은 각 인증서 발급업체에서 안내 되고 있다.

issue 의 경우 해당 도메인의 발급 권한을 지정한 회사(letsencrtpt.org)에 부여(0)한다.

issuewild 의 경우 해당 도메인 및 하위(서브) 도메인의 발급 권한을 지정한 회사(letsencrtpt.org)에 부여(0)한다.

 

AWS ROUTE53 서비스에서는 하나의 레코드 세트에 여러줄을 입력 한다.

2019-04-08_154055_001