서론 및 배경

OpenSSL 1.1.1이 긴 시간동안 pre버전으로 빌드되다, 최근 1.1.1a로 정식 릴리즈되었습니다. TLS v1.3 또한 draft 버전으로 릴리즈 되다가, 28버전을 마지막으로 정식 표준이 제정되었습니다.

기존 TLS v1.2은 handshaking을 위해 2번의 round trip이 필요했던 반면, TLS v1.3에서는 1번의 rount trip으로 연결 수립이 가능해졌습니다.

뿐만 아니라, 취약했던 SHA-1과 DES, 3DES 및 MD5, RC4, AES-CBC와 같은 암호화 알고리즘이 Support Cipher Suite에서 제외됐습니다.

따라서 1.3은 전반적으로 성능도 높이고, 보안수준도 높이는 결과로 딜레마가 없는 개선안으로 볼 수 있습니다.

유지보수 차원에서 TLS v1.3적용이 필요했고, 이는 OpenSSl 1.1.1이상의 버전을 요구합니다. 이 과정을 정리해보고자 합니다.

본론

1) 소스 컴파일

https://www.openssl.org/source/

openssl 소스페이지에서 빌드할 최신 버전 소스를 다운받습니다.

tar -xvzf 파일명

...

cd 폴더명


...

./config

필요한 경우 –prefix or –openssldir 로 명시적 패스를 지정해줍니다.

보통 일반적으로 make이후 make install할 경우 헤더, 라이브러리와 바이너리 등이 /usr/include/, /usr/local/lib, /usr/local/bin 등으로 설치되는데, 이를 방지하고 명확한 prefix를 주고자 할때 사용할 수 있습니다. (추후 openssl에 의존되는 응용을 컴파일할때 편리해집니다)

Configuration이 끝나면 아래 명령어로 컴파일 및 설치합니다.

make -j n
make install -j n

제대로 설치가 됐다면 다음과 같은 명령어를 입력했을 때, 컴파일 한 버전이 나와야합니다.

openssl
version

만약 버전이 일치하지 않는다면 binary가 참조하고있는 path에 설치되지 않았을 수 있습니다.

config에서 prefix옵션을 주었다면 해당 경로로 들어가 openssl binary를 찾고, 링크를 걸어줍니다.

ln -s "openssl prefix 경로" /usr/local/bin/openssl
혹은
ln -s "openssl prefix 경로" /usr/bin/openssl

openssl을 구동했을 때  can’t open config file: /usr/local/ssl/openssl.cnf 과 같은 오류를 만날 경우

export OPENSSL_CONF=openssl설치 패스

을 입력후 다시 테스트합니다. 오류를 만나지 않을 경우, 전역 혹은 각 계정 shell profile에 기록하여, 터미널 연결시 자동으로 패스를 등록하도록 합니다.

CentOS7에서는 패키지 관리자로 openssl을 설치했을 경우 대게 1.0.2k버전의 openssl이 설치되어 있습니다.

따라서 해당 버전의 패키지를 지워 reference conflict가 일어나지 않도록 해줍니다.

rpm -qa | grep openssl

rpm -e 패키지명

마지막으로 openssl 라이브러리가 제대로 인식되고 있는지 확인합니다.

ldd /usr/bin/openssl

첫째, 다음과 같이 config에 지정한대로 path가 나오는지

둘째, 해당 path로 이동하여 파일생성(최종수정)시점이 컴파일 타임과 일치하는지 확인해줍니다.

만약 첫째사항이 일치하지 않는다면 ldconfig path에 등록해주도록 합니다.

vim /etc/ld.so.conf.d/openssl.conf

...

/usr/local/ssl # (자신이 설정한 prefix. 지정값이 없다면 /usr/local/lib)


...

ldconfig

이후 다시 정상적으로 참조하는지 확인합니다.

2) 인증서 재 발급

이 과정은 불필요 할 수 있으나, Key Length를 2048에서 4096으로 늘리기 위해 새로 인증서를 발급받았습니다.

3) OpenSSL 관련 응용 재 컴파일 및 설치

현재 필자의 Web Deployment Server로 nginx를 사용하고 있는데, 웹 서버이기 때문에 SSL/TLS 인증에 필요한 라이브러리가 필요합니다.

다시 말하면 현재 nginx는 이전버전의 OpenSSL를 참조하여 컴파일 되었다는 뜻입니다.

따라서 nginx도 새로운 버전의 OpenSSL을 참조하여 컴파일 및 설치 해줍니다.

(만약을 위해 nginx폴더를 통째로 백업해둡니다)

위와 같이 새로운 OpenSSL 라이브러리를 참고하고 있다면 정상적으로 설치가 된 것입니다.

이전글: Nginx 소스 설치 configure및 make 참고

추가적으로 필자처럼 openssl 컴파일시 prefix옵션을 주지않을 경우, 다른 응용에서 라이브러리를 참조하지 못할 수 있습니다.

php가 대표적인데,  1.0.2나 1.0.1에서는 libcrypto.so.1.0, libssl.so.1.0인 1.0버전의 라이브러리를 참조하기 때문에 단순히 –with-libdir 인수로는 해결되지 않습니다.

두가지 해결방법이 있는데,

첫째, 새롭게 링크해준다.

libssl.so와 libcrypto.so가 1.1을 참조할 수 있도록 새롭게 심볼릭 링크를 만들어줍니다.

가장 간단하지만 해결되지 않을 수 있습니다.

둘째, configure파일을 수정합니다.

오류를 뿜는 코드를 configure파일 내에서 검색하여, 관련 라인을 수정해줍니다.

php의 경우 OPENSSL_INCDIR과 OPENSSL_LIBDIR 변수가 있고 이 경로를 참조했을 때 찾는 파일(evh.h, libssl.a 와 같이)이 없을 경우 오류를 뿜습니다.

따라서 명시적으로 PATH를 지정해줍니다.

OPENSSL_INCDIR=/usr/include/openssl
OPENSSL_LIBDIR=/usr/local/lib

이후 다시 컴파일을 한다면, 정상적으로 컴파일이 진행됩니다.

4) TLS v1.3설정하기

nginx를 운영하고 있기 때문에, nginx 설정파일을 수정해줍니다. (하는 김에 취약함으로 소문난 cipher들을 suite 지원대상에서 제거합니다)

vim /path/to/nginx/nginx.conf


...


server {
    listen 443 ssl http2;
    ...
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECD    HE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384';
    ...
}

위 이미지를 보면 현재 TLS v1.3을 모든 버전의 브라우저에서 지원하는것이 아니기 때문에 호환성 문제가 발생할 수 있습니다.

deprecate된 1.0과 1.1만을 제외하고 1.2를 지원 프로토콜로 남겨두어 이전 버전과의 호환성 문제를 해결합니다.

이 사항은 반드시 주석으로 남겨두고 추후,  보안조치대상으로 적용할 수 있도록 합니다.

결론

TLS v1.3 제정과 OpenSSL 1.1.1이 정식버전으로 릴리즈 되면서 각 웹 서버들은 TLS v1.3을 정식으로 사용할 수 있게 되었습니다.

현재 SNI감청으로 인한 차단 계획을 발표하면서, 사용자들은 DNS over HTTPS 기술 적용을 희망하고 있습니다. TLS v1.2의 취약점들을 개선하며 약 10년만에 업데이트 된 TLS v1.3기술은 DNS over HTTPS와 더불어 더욱 강력한 보안으로 중간자 공격 혹은 중간자 감청에 대응할 수 있을 것으로 보입니다. Google, Cloudflare에서도 이 기술 사용을 권장하고 있습니다.

따라서 각 서버 엔지니어들은 적극적으로 기술 도입을 해야합니다. 하지만 아직까지는 클라이언트와의 호환성을 위해 TLS v1.2를 지원목록으로 남겨둘 필요가 있습니다.