태그 Archives: HTTP Public Key Pinning

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

 

MITM Attack (Man In The Middle attack)

SSL을 운용을 하면 서버 및 클라이언트 간의 통신을 암호화 한다.

다만 암호화 전송을 하는 값을 가로 채서 암호환 된 값을 해석없이 그대로 재 전송 하여 이용할수 있는 해킹 기법을 막기 위해
홈페이지에 HTTP Strict Transport Security / HTTP Public Key Pinning 을 선언해야 한다.
https://ko.wikipedia.org/wiki/중간자_공격 에 대략적인 공격 방식에 대한 설명이 있다.

예시를 들어서 설명을 한다면..

  1. 공격자가 A은행 에서 B은행으로 돈을 보낸다.
  2. 이때 공격자는 A은행에서 B은행으로 전송하는 데이터를 스니핑한다.
  3. 공격자는 암호화된 데이터를 해석하지 않은채로 http 를 이용하여 B은행으로 재 전송을 한다.
  4. HSTS, HPKP 선언이없을경우  B은행의 서버는 정상전송값과 공격자 신호를 구분 없이 계좌에 돈이 쌓인다.
  5. 공격자는 돈을 인출하여 유유히 사라진다.

 

A. HSTS (HTTP Strict Transport Security)

HSTS 선언을 하는 경우 사이트는 HTTPS 로 강제 고정이 되기 때문에 외부 HTTP 를 연동하여 서비스 되는 부분이 있을경우
해당 연결이 끊어질 수 있다. 기본적으로 forced HTTPS 가 적용된 사이트에서는 HTTP 컨텐츠를 불러올 수 없다.
아울러 인증서가 만료되는경우 이 HSTS설정 때문에 접속이 아예 불가능할 수 있다.

HSTS 는 몇번 언급을 한적이 있는데 Header SET 을 통해 선언 하며 forced HTTPS 가 적용된 사이트는 속도상 이점이 생긴다. – 선언된 Header 에 의해서 접속한 도메인은 HTTPS 통신만 사용한다는 선언이다.

.htaccess 혹은 웹서버의 가상호스트 에 선언하면 된다.

 

B. HPKP (HTTP Public Key Pinning)

HPKP는 인증서의 pin을 공개함으로서 통신에 사용된 인증서가 pin과 비교함으로서 위조된 인증서를 구분할 수 있다.
즉 선언을 할때 pin 코드는 인증서에서 추출해야 함으로 인증서가 교체되는 경우 pin 역시 교체를 해야한다.

첫번째 pin-sha256 의 경우 HTTPS 통신에 사용된 인증서의 pin 코드 이다.
두번째 pin-sha256는 서버에서 생성한 csr을 가지고 생성하는 코드 이며 백업 pin 코드 이다.

인증서(crt파일) 에서 pin 을 확인하는 방법이다.

CSR파일에서 pin 을 확인 하는 방법이다. (백업키 생성을 위해 쓴다.)

 

Let’s encrypt 를 이용했을때 약 2개월 단위로 인증서가 교체가 된다…. 즉 HPKP pin 역시 2개월 단위로 변경…을 해야 한다.
물론 백업키는 변경할 필요가 없겠지만…

이건 아무래도 귀찬기 때문에 스크립트 만들어야 겠다 ‘ㅅ’a