안전한 TLS 인증서 배치를 위해 피해야 할 보편적인 실수 5가지

TLS(Transport Layer Security) 인증서는 균형잡힌 보안 아침 식사를 위해 필수적인 부분이지만, 수백 만 개의 조직들이 여전히 설탕을 첨가한 시리얼을 먹으면서 밥이라고 부르고 있다. 
 

ⓒ Getty Images Bank 

TLS 인증서를 안전하게 구성하고 배치하는 것이 쉽다고 생각할 수도 있지만 센시스(Censys)나 쇼단(Shodan)을 보면 잘 알아야 하는 조직들을 포함해 안전하지 TLS 인증서가 엄청나게 많다는 것을 알 수 있다.

TLS 인증서는 웹 트래픽, 이메일, DNS를 포함하는 점차 많은 기타 서비스의 비밀성(Confidentiality)과 무결성(Integrity)을 보호한다. X.509 시스템은 근본적으로 망가져 있다고 비판할 수도 있지만, 하루 아침에 모든 보안을 마법처럼 강화할 수 있는 만병통치약은 아니더라도 여전히 무시할 수 없는 중요하고 단순한 완화책이다. TLS를 건강하게 유지시킬 수 있는 5가지 요령에 대해 살펴보자.

1. 더 긴 TLS 키를 사용하라

RSA 소수를 1024비트처럼 작게 인수화하는 문제는 해결됐다. 즉, 공격자는 공개된 공개 키(public key)를 다운로드하고 개인 키(private key)에 무차별 대입 공격(brute-force)을 적용한 후 트래픽을 복호화할 수 있으며, 심지어 서버를 가장할 수도 있다. 

해결책은 더 긴 TLS 키를 사용하는 것이다. 
2048비트 키가 현재 업계 표준이며 그것보다 짧은 것을 사용해서는 안 된다. 엄청나게 빠른 성능 요건이 없는 웹사이트라도 3072비트나 4096비트 RSA를 적용할 수 있다. RSA 키 길이를 늘리면 약간의 성능 하락이 발생하지만 사용자는 거의 눈치챌 수 없다.

최소한의 RSA 키 길이를 확보하는 것이 TLS 인증서 보안에 필수적이긴 하지만 TLS를 공격할 수 있는 방법은 많다. 때문에 키의 길이는 방어의 시작에 불과하다.

2. 가능하면 TLS 1과 TLS 1.1을 없애라

극단적인 편견을 갖고 비난해야 하는 SSL v2 및 SSL v3와 마찬가지로 TLS v1은 더 이상 용인할 수 있는 사례로 간주되지 않는다. 심지어 PCI DSS(Payment Card Industry Data Security Standard)는 지난 해 PCI를 준수하는 웹 사이트에서 TLS v1 지원을 제거하도록 요구했으며 TLS v1.1도 비활성화하도록 촉구했다.

PCI 측은 "SSL과 초기 TLS에는 심각한 취약점이 많으며 아직까지 해결되지 않았기 때문에 조직들은 유출 위험에 처하게 된다. 광범위한 POODLE(Padding Oracle On Downloaded Legacy Encryption) 및 BEAST(Browser Exploit Against SSL/TLS) 익스플로잇 공격은 공격자들이 SSL과 초기 TLS의 약점을 이용해 조직을 해킹하는 방법에 대한 몇 가지 예에 불과하다"고 전했다. 

보안 종사자들은 PCI DSS가 첨단의 보안 조언은 아니지만 최소한의 컴플라이언스 기준이라는 것은 알고 있다. 기업이 여러 오래된 장치를 지원해야 하는 경우가 아니라면 조만간 TLS v1 및 TLS v1.1의 지원을 없애는 것이 좋다.

TLS 1.3 지원은 여전히 새롭지만 더욱 강력한 보안과 성능 개선을 제공한다. 새로운 사양은 2018년 8월에야 확정되었으며 아직 도입이 느리다. TLS 1.3은 알려진 피해가 없고 고객이 이 새로운 프로토콜을 지원하지 않는 경우 TLS 1.2로 다운그레이드 할 것이다.

3. 가능한 경우 오래된 암호 모음에 대한 지원을 없애라

짧은 시간 안에 많은 다운그레이드 공격이 이뤄졌다. POODLE, FREAK, 로그잼(LogJam) 외에도 많은 것들이 있다. 오래된 장치를 지원하기 위해 많은 TLS 이행에서 해외로 판매하는 암호화의 강도를 제한하기 위해 미 NSA(National Security Agency)가 의도적으로 설정한 1990년대의 소위 "암호화 내보내기(export encryption)"를 지원했다. 

웹 서버를 클라이언트로 가장해 오래되고 망가진 암호 모음(cipher suites)을 지원하는 것이 최근까지도 전반적으로 효과가 있었으며 여전히 수백 개의 웹사이트에서 효과가 있는 것으로 센시스의 연구 결과가 나타났다.

안전한 암호만 활성화하고 더 약한 암호를 허용해야 하는 경우에는 모든 사용자에 대한 잠재적인 비밀성 및 무결성 상실과 비교해 사용자 일부가 얻는 가용성의 이점을 고려해야 한다.

현재 TLS 인증서가 지원하는 암호 모음 목록과 안전하다고 여겨지는 것들에 대한 분석은 퀄리스 SSL 랩스(Qualys SSL Labs) 온라인 테스트에서 확인할 수 있다.

4. 더 짧은 유효성 시간을 사용하라

올바르게 구성되고 배치된 TLS 인증서를 해킹하는 가장 쉬운 방법은 서버를 해킹하여 개인 키를 훔치는 것이다. 정기적인 키 순환은 키 도난 시에도 최악의 상황을 막아주고 피해를 해킹의 최대 범위로 국소화한다. 

전문가들은 최대 60~90일을 추천하며 렛츠 인크립트(Let's Encrypt)는 최대 90일을 강요한다. 하지만 업계 표준에서는 여전히 최대 2년(825일)의 키 유효성 기간을 허용하고 있으며, 이것도 그나마 2018년에 최대 3년에서 단축된 것이다. 

그렇게 하지 말자. 현 시점에서는 정기적인 30일 키 순환을 추천해도 그리 이상하지 않다. 공격자가 일관성을 유지하거나 정기적으로 서버를 해킹해 새 키를 훔치도록 하면 잡을 가능성이 높아진다. 가장 위험한 위협 활동자로부터 방어하는 것은 불가능할 수 있지만 공격자의 상황을 가능한 한 어렵게 만들 수 있다면 그렇게 해야 한다.

5. 다중 장치에서의 와일드카드 인증서를 지양하라

웹 서버, 이메일 서버, 복사기, 프린터, 기타 무작위 IoT 장치를 포함해 수십 개의 장치에 하나의 개인 키를 배치하면 서버를 해킹하여 TLS 키를 훔치기가 더 쉬워진다. 공격면이 너무 크기 때문에 공격자는 가장 약한 장치를 찾아 웹 서버 대신에 복사기를 해킹하면 된다.

개인 키의 사본이 많을수록 공격자가 키를 훔치고 모든 것을 복호화 하기가 더 쉬워진다. 따라서 그렇게 하지 말자. 가능하면 개인 키는 장치마다 고유해야 한다.
자신의 조직은 안전하다고 생각하는가? 영국의 정보기관인 GCHQ도 와일드카드 TLS를 배치하는 실수를 범했다.

부실한 TLS 배치 활동을 통해 새로운 먹이감을 찾는 공격자뿐만 아니라 매주 모든 IPv4 범위를 스캔하는 규제 당국 및 사이버보안 보험 업체들은 조직에 대해 많은 것을 알아낼 수 있다. TLS 인증서를 제대로 배치하지 못한다면 나머지 인프라는 어떻겠는가? 많은 사람이 보고 있으며, 이 가운데 일부는 그렇게 우호적이지 않다.

원문보기: 
http://www.itworld.co.kr/t/62082/IT%20%EA%B4%80%EB%A6%AC/125649#csidx12dfc656c981acd9bb98f5baefb370d