728x90

근래에 제공되는 대부분의 서비스는 SSL 혹은 TLS 를 이용하여 보안된 채널로 통신이 수행되도록 하는 것이 일반적입니다. 하물며 개인이 만드는 토이 프로젝트부터 대학교에서 과제로 제출하는 웹 사이트도 HTTPS 를 사용하지 않는 경우를 찾아보기 힘듭니다. 네, 물론 이 와중에서 Non-secure 로 버티는 곳들도 <당연히> 있긴 합니다. 

예전에는 HTTPS 를 이용하기 위해 인증서를 구매해야 했고, 보통 년단위의 갱신을 하다보니 비용 부담이 있었습니다. 하지만, 3개월마다 주기적으로 인증서를 업데이트 받는 조건으로 도메인 단위 인증서 (Domain Validation) 를 무료로 발급해주는 렛츠인크립트 Let's Encrypt 의 대중화 이후, 인증서 구매 비용도 단지 핑계가 된지 오래입니다. 


하지만, 이런 인증서 구매와 별개로 서버측에 SSL 설정을 구성하고 적용하는 것은 생각보다 까다롭게 생각하는 경우가 많습니다. 보통 한번 설정해 두면 수정하지 않아서 보안 사고의 원인이 되기도 하고, 설정을 잘못하는 바람에 특정한 단말기들이 서비스에 접근하지 못하는 장애를 겪기도 합니다. 원체 그 파급력이 크다보니 <그리 어려운 일이 아님에도 불구하고> 인증서 교체에 대해서 전문가를 찾는 경우가 종종 생깁니다.

이러한 엔지니어들의 고충을 잘 알고 있는 곳이 모질라 재단이기 때문일까요? 모질라에서 제공하는 SSL 설정 생성기는 이 모든 두려움으로부터...는 아니겠지만, 기본적인 설정 실수로 장애가 발생하는 것을 막아줄 수 있는 여러분의 친구, 좋은 도구가 될 수 있을 것 같습니다. 

다양하다! 

일단 이 도구가 커버해주는 서버측 소프트웨어의 범주가 무척 넓습니다. 널리 사용되는 아파치나 nginx 에서부터 AWS 의 ALB, ELB 도 포함이 되어 있습니다. HAProxy 와 Go 기반으로 서버측 엔드포인트를 만들때 쓸 수 있는 옵션들도 제공하고 있어 왠만한 서버측 도구의 SSL 설정에 활용도가 높아 보입니다. 

가운데 위치한 Mozilla Configuration 은 SSL/TLS 의 어떤 버전을 지원할 것인가에 따라 선택 가능한 항목입니다. 이 항목의 변경은 설정 생성시에 추가되는 Cipher Suite 의 종류에 영향을 주는 부분입니다. SSL/TLS 버전이 상위로 갈 수록 취약한 암호화 알고리즘을 사용할 수 없게 됩니다. 하지만, 오래된 사용자들은 SSL/TLS 의 상위 버전 자체를 사용할 수 없는 경우도 있기 때문에, 사용자 분포에 따라 취약한 알고리즘을 써야 하는 경우도 있을 겁니다.

가장 오른쪽에는 각 서버 어플리케이션의 버전에 따라 달라진 부분을 반영하기 위해 버전 정보를 기입할 수 있는 입력창이 위치해 있습니다. HSTS 와 OCSP Stapling 을 사용할 것인지에 따라 옵션을 선택할 수 있게 되어 있는 것도 눈에 띕니다. 

# generated 2021-02-08, Mozilla Guideline v5.6, nginx 1.17.7, OpenSSL 1.1.1d, modern configuration
# https://ssl-config.mozilla.org/#server=nginx&version=1.17.7&config=modern&openssl=1.1.1d&guideline=5.6
server {
    listen 80 default_server;
    listen [::]:80 default_server;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions
    ssl_session_tickets off;

    # modern configuration
    ssl_protocols TLSv1.3;
    ssl_prefer_server_ciphers off;

    # HSTS (ngx_http_headers_module is required) (63072000 seconds)
    add_header Strict-Transport-Security "max-age=63072000" always;

    # OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;

    # verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

    # replace with the IP address of your resolver
    resolver 127.0.0.1;
}

 

TLS 1.3 을 기준으로 NGINX 를 위한 설정을 생성해 보았습니다. HTTP 로 인입된 경우 HTTPS 로 스킴을 바꾸도록 301 리디렉션 하는 서버 컨텍스트가 앞에 위치해 있고, 443 포트로 HTTP/2.0 을 지원하는 엔드포인트를 열고 있습니다. 센스있게 IPv6 를 위한 포트 바인딩도 함께 추가되어 있네요!

그 외의 지시자들은 일름에서 유추할 수 있는 것처럼 프로토콜 버전의 지정, 인증서 파일의 위치, 세션 티켓 사용을 위한 옵션들이 지정되어 있습니다. 서버측의 prefer_server_ciphers 가 off 로 생성된 부분은 그 의도가 있을텐데 (아마도 NGINX 에서 TLS 1.3 사용시 기본 Cipher Suite 의 영향?) 자세한 건 문서를 좀 살펴봐야 할 것 같네요.


우리가 코드를 수정하거나 서버의 설정을 변경할 때 늘 하는 말이 있습니다. <지금 니가 무슨짓을 하는지 모른다면, 아무것도 하지 말아라> 라는 말이 바로 그것입니다. 각 설정이나 코드가 존재하는 것은 다 이유가 있어서 입니다. (예, 정말 가끔 이유 없이 존재하는게 없진 않습니다만...) 자동 생성된 설정을 참고하고 사용하는 것은 좋지만, 추가된 설정 항목들이 "왜" 들어갔는지에 대해서는 한번쯤 문서를 찾아보고 고개를 끄덕인 다음 Ctrl-C, V 하는 아름다운 자세를 견지하시기 바랍니다!

 

 

728x90
728x90

웹 컨텐츠 전송을 위한 프로토콜의 대세가 h2 혹은 http/2 로 자리잡아 가면서 맥(Mac)의 쉘에서도 http/2를 테스트 해야하시는 분들이 많이 늘었을 것으로 생각됩니다. 알려진 내용에 따르면 curl 의 7.34.1 버전 이후에는 --http2 옵션을 통해 http2 로 서버와 통신을 하도록 강제할 수 있지만 환경에 따라서 안되는 경우가 많습니다. curl 은 http/2 를 지원하기 위해 nghttp2 라이브러리를 이용하고 있기 때문에 우선은 nghttp2 를 설치해야 합니다.




nghttp2 가 설치되면 이를 이용해서 curl 을 다시 build 하거나 설치해야 합니다. 홈브루(Homebrew)를 이용하면 간단하게 새로운 버전으로 빌드를 하면서 설치할 수 있으니 아래의 커맨드를 참고해서 설치를 진행하도록 합시다. 아래와 같이 설치한 후 brew info curl 명령을 통해 nghttp2 에 초록색 체크박스가 잘 들어왔다면 일단 설치는 제대로 잘 된거라 봐도 되겠습니다.





그런데 여기까지 하고나서도 curl 을 --http2 옵션으로 실행했을 때 지원하지 않는 프로토콜이라고 에러가 떨어진다면 심볼릭 링크를 한번 교체해줄 필요가 있습니다. 환경 설정에 따라, 사용자 계정에 따라 sudo 를 통해서 권한 상승을 해야 할 필요도 있으니 상황에 따라 적절한 옵션으로 심볼릭 링크를 교체해 주시면 되겠습니다. 




여기까지 해서 마무리가 잘 되었다면 curl --http2 옵션으로 http2 가 활성화된 사이트들, 예를 들어서 아카마이의 https://http2.akamai.com 이라던가 구글 메인 페이지 (https://www.google.com) 쪽으로 요청을 던져볼 수 있게 되셨을 겁니다. 일단 개인적으로 여기까지 해서 문제는 없었습니다만 다른 문제를 겪는 분이 계시다면 댓글로 남겨주시면 한번 살펴보도록 하겠습니다!



- NoPD -




728x90
728x90

크롬 브라우저가 새로운 버전(v45) 으로 업데이트 되면서 성능 개선에 대한 이야기가 많이 나오고 있습니다. 그런데 성능 개선과 별도로 일부 서비스에서는 이슈가 발생하기 시작해서 살짝 살펴보았습니다. 개인적으로 경험한 웹 사이트는 SK텔레콤의 포털인 T World 에서 로그인이 제대로 되지 않는 현상이었고 이는 현재 진행형으로 오류가 발생하고 있습니다. 아마도 서비스 개발팀 쪽에서는 인지하고 있을 것 같은데, 조치가 서버단에서 이루어져야 하는 관계로 시간이 소요되는 것으로 보입니다.


구글 Chromium 그룹에서 이야기 되는 내용에 따르면, 1) 크롬은 여전히 v45 에서 TLS v1.0 을 지원하고 있으니 TLS 버전 이슈는 아님, 2) 다만 크롬이 접속하려는 서버가 TLS Handshake 하는 과정에 이슈가 있을 경우, 기존에는 크롬이 Workaround 해주었지만, 3) v45 부터는 더이상 해당 Workaround 를 지원하지 않아서 발생하는 문제다 정도입니다. 구체적으로 어떤 웹 서버의 특정 버전이 이슈가 있는 것인지는 명확하게 정리된 내용을 찾지 못했습니다만 조치를 위해서는 서버측의 TLS Handshake 에 대한 보완이 필요한 것으로 추정됩니다.




SK텔레콤의 T world 의 경우 대표 도메인에서 로그인 시에는 별도이 도메인으로 이동하여 인증처리를 하고 있는데요, 해당 도메인이 TLS Handshake 상의 버그를 가지고 있는 것으로 보입니다. curl 로 서버의 종류를 판별해 보려고 했으나 잘 되지 않아 말씀드리긴 애매합니다. 여튼, 서비스를 운영하시는 분들중 특히 TLS 를 이용하여 HTTPS 통신을 할 때, 서버가 문제 없는지 크롬 v45 이상으로 확인해 보실 것을 권고해 드립니다.




[ ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION 관련 참고글 ]

https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/cuHipbsCYSI




728x90
728x90
요즘 웹 업계가 난리입니다. 사실상 표준처럼 사용되고 있는 오픈소스 라이브러리인 OpenSSL 에서 취약점이 발견되면서 SSL 터널링과 관계 없이 사용자의 민감한 정보가 노출될 수 있는 문제가 확인되었기 때문입니다. OpenSSL 라이브러리에 대한 패치와 기존에 발급된 인증서 갱신도 중요하지만 Heartbleed 가 왜 이리 큰 이슈가 되는지 아는 것도 중요해 보입니다.

워낙 관련된 문서들이 많이 나왔고 테크 블로그나 IT 전문 매체에서도 잘 다루어 준 덕분에 이해하기 어렵지 않지만 누군가에게 이걸 다시 설명하라고 하면 구차하고 잡다한 이야기를 늘어놓게 되지요. 간단하게 정리된 웹 사이트가 있어서 소개해 드리면서 해당 사이트가 그림으로 이해하기 쉽게 그려둔 그림을 공유해 봅니다. 이해가 아주 깔끔하게 되네요!

출처 : Forumsys (http://www.forumsys.com/api-security/how-to-fix-openssl-heartbleed-security-flaw/)

 
평상시 사용자들이 브라우저로 TLS/SSL (쉽게 말해 HTTPS 요청이라고 생각하시면 됩니다) 터널링을 맺고 나면 OpenSSL 라이브러리는 생성된 세션이 유효함을 확인하기 위해 5바이트의 HELLO 메세지를 전송하는 Heartbeat (심장박동?) 를 전달하게 됩니다. 클라이언트 (보통 브라우저겠죠) 와 서버는 지속적으로 이 행위(?)를 반복하며 채널을 유지합니다.

출처 : Forumsys (http://www.forumsys.com/api-security/how-to-fix-openssl-heartbleed-security-flaw/)


그런데 이번에 발견된 OpenSSL 의 문제점은 Heartbeat 를 5바이트 이상으로 전송하더라도 이에 대해서 서버가 같은 바이트 크기만큼 메모리의 정보를 읽어서 응답하는 데에 있습니다. 악의적인 사용자가 서버의 메모리에 저장된 특정한 주소의 정보들을 쉽게 추출해낼 수 있는 방법이 생긴 것이지요. 이의 해결을 위해서는 OpenSSL 라이브러리를 갱신하고 발급된 인증서를 재발급 받는 등의 절차가 필요합니다. 보다 자세한 내용은 원문을 참고하시기 바랍니다!





728x90

+ Recent posts