[보안] 안전한 HTTPS 환경 구축

• RSA 2,048 비트 수준의 개인키 사용 (또는 ECC 224 비트)

RSA 인증서 타입의 경우 2,048 비트, ECC 타입의 경우 224 비트 길이 수준을 권장합니다. 키 길이가 길어질 수록 보안은 강화되지만 웹 서버의 시스템 성능 또한 비례하여 저하되므로, 보안을 고려한 적절한 키 길이 선정이 중요 합니다. 과거 1024 비트 키 길이면 충분하다고 생각 했으나 최근의 CPU 성능을 감안하면 결국 수학적 계산을 이용하여 도출이 가능하기 때문에 위에 제시된 길이 보다 짧은 개인키를 사용해서는 안 됩니다.

 

• TLS 1.2, 1.3 만 활성화

HTTPS를 구현하는 암호화 프로토콜은 크게 SSL(SSL 2.0, 3.0)과 TLS(TLS 1.0, 1.1, 1.2, 1.3)로 구분 지을 수 있는데, 2011년 SSL 2.0, 2015년 SSL 3.0 지원 중단이 선언되고, TLS 1.0과 TLS 1.1 또한 2020년 상반기를 기준으로 지원 중단이 선언되었습니다. 이유는 POODLE 취약점, BEAST 취약점 사례와 같이 더 이상 안전 하지 않기 때문에 보안을 목적으로 HTTPS를 도입한다면 안전한 TLS1.2, TLS1.3을 사용 하라는 것입니다.

최신의 잘 알려진 브라우저들은 이미 취약한 SSL/TLS 버전을 지원하지 않거나 기본 비활성화 되어 있기 때문에 TLS 1.2 이상 프로토콜만 활성화하는 것이 일반적인 웹 서비스에 영향을 미치지 않습니다. 다만, 웹 사이트(또는 웹 어플리케이션 서비스)에 접속하는 클라이언트들이 오래된 단말기 이거나, 일반 브라우저가 아닌 소프트웨어, API, SDK 기반 어플리케이션 성격인 경우 TLS 1.2, TLS 1.3을 지원하지 않아 정상적인 통신이 이루어지지 않을 수 있습니다. 이 경우, 서비스 가용성을 위해 서버에서 TLS 1.0, TLS 1.1을 활성화하기 보다는 클라이언트 측에서 TLS 1.2 이상의 프로토콜을 사용할 수 있도록 수정하는 것이 바람직한 조치 방안입니다.

 

• 취약한 Cipher-Suite 목록 비활성화

“Anonymous Diffie-Hellman, eNull, RC4, 3DES” Cipher-Suite 비 활성화

PFS(또는 FS) Cipher-Suite인 ECDHE, DHE 상위 배치

 

SSL/TLS 협상에서 암호화 프로토콜 버전 외에 Cipher-Suite 라는 것이 존재하고 이 또한 보안 강도를 결정짓는 중요 요소입니다. 간단히 표현하면 클라이언트와 서버 간에 협상에 사용되는 암호화 알고리즘 세트로 정의할 수 있습니다.

 

클라이언트와 서버 간 협상 시, 사용할 Cipher-Suite 선정 우선권을 어느 측에서 가질 것인지에 대한 옵션이 존재합니다. 아무리 서버 측에서 보안 강도가 높은 Cipher-Suite들로 협상 유도하기 위해 상위에 강도 높은 Cipher-Suite 군을 배치하더라도, 우선권이 클라이언트에 있는 경우 의도와 다르게 암호화 강도가 낮은 Cipher-Suite로 협상이 이루어 질 수 있습니다.

시장 점유율이 가장 높은 웹 어플리케이션 서버와 암호화 라이브러리의 경우, apache는 SSLHonorCipherOrder, Nginx는 ssl_prefer_server_ciphers, OpenSSL은 SSL_OP_CIPHER_SERVER_PREFERENCE 라는 명칭으로 우선권 설정 옵션을 제공하며, PFS(또는 FS) Cipher-Suite인 ECDHE, DHE 타입의 Cipher-Suite로 클라이언트와 협상이 이루어 지도록 위 옵션 활성화를 권장 합니다.

PFS(Perfect Forward Secrecy)는, 공격자가 클라이언트와 서버 간의 암호화된 통신을 도감청 하거나 내용을 저장한 경우, 개인키가 노출되었다면 개인키를 이용하여 기존에 저장된 암호문을 모두 해독할 수 있습니다. (물론 개인키가 노출되지 않고 잘 관리된다면 암호문은 해독 불가 합니다.) 만약 PFS가 활성화된 Cipher-Suite로 클라이언트와 서버 간의 암호화 통신이 이루어졌다면 개인키가 노출되더라도 기존에 저장된 암호문을 해독할 수 없도록 하는 장치가 PFS입니다. 즉, 해당 통신(세션)의 주체인 단말 간에만 암호문을 해독할 수 있도록 하는 개념이라 볼 수 있습니다. 결국 PFS는 개인키가 노출되더라도 암호화 통신에 담긴 데이터의 보안성 보장을 위한 옵션입니다.

PFS와 관련하여 몇 가지 예를 들어보자면, IT 엔지니어 분들이 자주 사용하는 Wireshark에서, 녹화된 TCPDUMP에 RSA Cipher-Suite의 암호화 통신인 경우 개인키를 삽입하면 복호화 된 형태의 PLAIN 데이터를 확인할 수 있습니다. 하지만, PFS 성향인 DH나 ECDHE Cipher-Suite의 암호화 통신인 경우 개인키를 삽입하더라도 복호화가 불가 합니다.

현재 시장에 공급되는 SSL 가시성 솔루션들이 모두 세션에 직접개입 하는 Proxy로 배치 및 운영 되는 이유(기술적으로는 공개적인 MITM 으로도 표현) 이기도 합니다. 해당 통신(세션)의 주체만이 DH나 ECDHE Cipher-Suite에 대한 복호화가 가능 하기 때문입니다.

 

• HSTS(HTTP Strict Transport Security) 활성화

HSTS는 클라이언트의 브라우저에서 HTTPS 접속을 강제화 하여, 최초 접속 시부터 HTTPS 접속을 유도하는 기능입니다. 브라우저 종류에 따라 기본적으로 HSTS URL 목록을 내장(HSTS Preload)하는 경우가 있으며, 기본 내장 여부와는 무관하게 서버의 응답 헤더(Strict-Transport-Security)에 따라 브라우저는 해당 HSTS URL 목록들을 학습하고 관리합니다. 예를 들어 www.test.com 웹 사이트가 클라이언트 요청에 대한 응답에 “Strict-Transport-Security: max-age=31536000; includeSubDomains” 헤더를 포함하는 경우, 해당 브라우저는 1년간 *.test.com 으로 접속 시에는 HTTPS 연결을 강제화 하도록 학습합니다. “includeSubDomains” 은 HSTS 적용 도메인의 서브도메인까지 모두 적용 대상으로 확장함을 의미합니다.

HSTS의 주된 목적은 MITM 공격 대응입니다. 일반적으로 암호화된 세션은 중간에서 공격자가 해당 세션을 훔쳐보더라도 암호화되어 있기 때문에 데이터가 보호될 수 있습니다. 하지만 아래 그림과 같이 최초 요청이 HTTP로 접속되는 경우 SSL Strip이 가능 해집니다.

 

• Secure Cookie 활성화

쿠키는 오래전부터 사용되어 왔으며 오늘날 WEB의 필수 요소로 자기 매김하며 활용 영역은 점점 광범위해지고 있습니다. 모든 웹 서버(ASP, JSP, PHP 같이 특정 영역에 한정되지 않음)는 HTTP, HTTPS를 통해 클라이언트와 쿠키를 주고받을 수 있으며, 클라이언트에서도 쿠키에 접근하고 관리할 수 있습니다. 쿠키는 서버, 클라이언트 각 각에서 생성할 수 있으며 생성된 쿠키는 브라우저에 학습되고, 이후의 모든 요청에 쿠키를 포함하여 서버와 통신합니다. 물론 서버는 브라우저의 요청에 포함된 쿠키를 이해하고 식별하므로 서 해당 클라이언트에 대해 적절한 액션(응답)을 취합니다. 많은 웹 사이트는 쿠키에 사용자의 로그인 정보나 개인정보 등 민감정보를 포함하므로 공격자는 이런 쿠키를 탈취하기 위해 세션 하이재킹이나 XSS 등과 같은 공격을 수행합니다.

예를 들어보면, 모든 요청과 응답이 https로만 통신한다면 쿠키 정보 또한 암호화되어 있으므로 쿠키 노출로 인한 피해는 발생할 수 없습니다. 하지만, 예를 들어 웹 서버 응답페이지에는 여러 링크가 존재하는데 만약 개발자가 실수로 다음과 같이 http로 연결되도록 하드 코딩한 페이지(<img scr="http://www.test.com/images/top.jpg”>가 존재한다면, 브라우저는 해당 URL에 https가 아닌 http로 연결하게 됩니다. (기존 https 세션과는 별도의 http 세션을 추가로 연결) 즉, 쿠키 값이 네트워크 상에 모두 노출되는 상황이 전개되고 실제 사용자는 이를 사실상 인지하기 매우 어렵습니다. 

 

 

결론적으로, Secure Cookie는 네트워크를 직접 도감청하여 쿠키를 가로채는 행위를 방지하기 위해 웹 브라우저와 웹서버가 HTTPS로 통신하는 경우에 한해서만 브라우저(클라이언트)가 쿠키를 서버로 전송하는 옵션입니다.