Let’s encrypt – ACMEv1 지원 종료

Let’s encrypt 에서 API (ACMEv1) 을 종료할 계획을 발표 했다.

오늘 관련 메일을 수신 받았고 내용을 확인해 봤을때 아래와 같다.

2019년 11월 – 신규 어카운트 사용 불가 (기 등록 계정[메일주소]은 사용 가능)

2020년 6월 – 신규 도메인 발급 불가 (기존 도메인 renew 만 가능)

2021년 초 – 지원 종료 (사용 불가)

https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430

 

간단히 말해서 ACMEv2 주소를 ACMEv1 대신 사용하면 된다.

ACMEv2 의 경우 2018년 3월에 공개가 되었으며 STAR(*) 인증서 발급을 지원한다.

 

기본적으로 certbot 의 경우 실행시 자동으로 업데이트를 한다. (renew 에서도)

그러므로 API 주소만 단순히 ACMEv2 을 사용하면 동일 하게 사용할 수 있다.

( https://acme-v01.api.letsencrypt.org/directory –> https://acme-v02.api.letsencrypt.org/directory )

 

인증서 만료일은 아래와 같이 certbot-auto 명령어와 openssl 명령어로 확인할 수 있다.

 

테스트 결과 renrwal 폴더 안의 conf 파일의 기존 ACMEv1 주소를 ACMEv2 으로 변경하면 정상적으로 갱신이 가능하다.

아울러서 v2 의 경우 다중의 end point 를 통해 http 인증을 진행 한다. 기존에 1개의 아이피 에서 인증을 진행했지만 8 곳 에서 http 인증을 진행하는것으로 확인 되었다 ‘ㅅ’a

물론 이 end point 의 경우 유동 적일 수 있다.

 

인증서 취소 & 인증서 삭제

 

 

MDS / Zombie Load 취약점

Intel CPU 에서 또다른 취약점인 MDS 취약점이 공개 되었다.

심각도는 impotant 이며 CVE-2018-11091, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130 항목이다.

KISA 공지 사항: https://www.boho.or.kr/data/secNoticeView.do?bulletin_writing_sequence=35030

 

CPU 캐쉬내 데이터는 적재한 프로세스가 아닌 다른 프로세스에서 엑세스 할 수 있는 취약점이다.

 

중요도가 높다보니 취약점 패지가 이미 배포 되어 yum 업데이트만으로 해결이 가능하다.

업데이트 항목이 kernel 과 intel-microcode 다 보니 재부팅이 필요 하다.

 

음 AWS 서비스의 경우 아래와 같이 안내 되어 있다.

https://aws.amazon.com/ko/security/security-bulletins/AWS-2019-004/

AWS has designed and implemented its infrastructure with protections against these types of bugs, and has also deployed additional protections for MDS

All EC2 host infrastructure has been updated with these new protections, and no customer action is required at the infrastructure level

 

뭐 AWS 인프라 레벨에서 MDS 취약점을 처리 하였으니 유져가 EC2 호스트에서 별도로 조취할 필요가 없다고 한다 🙂

랄라~

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

 

brotli_module 활성화

httpd 에서 2.4.26 버전 이상에서 지원하는 데이터 압축 모듈이다.

deflate_module 의 경우 gzip 압축을 이용하여 데이터 전송을 하고 brotli_module 의 경우 br 으로 압축하여 전송한다.

 

brotli 압축 기술은 구글에서 공개한 압축기술중 속도 위주의 압축기술이다. (gzip 보다 압축률이 20–26% 더 좋다고 한다.)

https://opensource.googleblog.com/2015/09/introducing-brotli-new-compression.html

 

아파치에 mod_brotli 설치는 아래 github 내용을따라 설치할 수 있다.

https://github.com/google/brotli

 

설치가 된 이후에는 아래와 같이 defate 및 brotli 설정을 한다. (https://www.unixadm.org/needful-things/brotli)

설정은 브라우져 지원 여부에 따라 brotli 으로 전송하거나, gzip 전송을 선택하여 전송하게 되며

둘다 지원 못하는 브라우져의 경우 압축되지 않고 전송한다.

apache 2.4.27 버전 이상에서 Segmentation fault 오류가 발생.

apache 2.4.26 이하 버전에서 Important 취약점인 CVE-2017-9788, CVE-2017-9789 가 존재 하기 때문에

apache 버전을 최신화 한뒤에 apache error_log 에서 간헐적인 접속 끊김 증상이 확인이 되었다.

Segmentation fault, memory corrupted – core dump 에 의한 apache child 프로세스의 강제 exit 가 된다.

 

이와 같은 경우 메인 프로세스는 살아 있는 상태에서 child 가 죽는 현상이다 보니 실제 apache 는 설정에 따라

부족한 child 프로세스를 다시 생성하기 때문에 발생하고 있지만 모르고 있을 수 있다. – apache – error_log 를 꼭 점검해봐야 한다.

 

내용 추적이 되지 않아 한동안 고생을 하다가 이 에러가 특정한 상황에서만 발생하는것을 확인하였다.

조건1. https 프로토콜 사용

조건2. http/2 사용

조건3. mpm_worker 혹은 mpm_event 사용 (event 에서 더 심하게 발생함.)

조건4. mod_php 사용

 

기존에 apache 2.4.27 부터 worker 가 기본 mpm 이 되었고,

어떤 버전인지 부터는 모르지만 최신 버전의 2.4.38 버전은 event mpm 이 기본값으로 설정이 된다.

이를 prefork 방식으로 변경해서 운영을 해도 되지만 이럴 경우 http/2 는 지원이 되지 않는다.

 

기본이 event mpm 일 경우 권장 되는 운영 환경은 apache 2.4 –  fcgi_proxy – php-fpm 구조이다.

다만 php-fpm 의 경우 tomcat 처럼 별도의 WAS 환경이기 때문에 익숙치 않고 설정법을 새롭게 배워야 하는 단점이 존재 한다.

 

변경을 하는것은 맞는 방향이겠지만 이는 충분한 시간이 주어져야 한다는 단점이 존재한다.

하지만 서버는 당장에 문제가 발생하고 있기 때문에..

 

때문에 임시 방편으로 아래와 같은 설정(H2MaxWorkers)을 추가 하여 오류를 방지 하고 시간을 벌도록 한다. ‘ㅅ’a

H2MaxWorkers 설정을 1로 할경우 mpm_worker 의 경우 속도 저하가 체감이 될정도 이기 때문에 mpm_event 로 운영을 하도록 한다.

 

mpm 설정은 ……./httpd/conf.modules.d/00-mpm.conf 에 존재 한다.

 

현재 apache 의 mpm 은 아래 명령어로 확인할 수 있다.