SSL / TLS는 놀라울만큼 간단한 기술입니다. 배포하기 쉬우며, 안 될 때를 제외하면 그냥 쉽게 작동합니다. 가장 큰 문제는 암호화가 보통 올바르게 배포되기 쉽지 않다는 점입니다. TLS가 적절한 보안을 보장하려면, 시스템 관리자와 개발자는 반드시 올바른 서버 설정과 앱 배포에 노력을 기울여야만 합니다.

2009년, TLS가 어떻게 쓰이는지, TLS 도구와 문서를 어떻게 개선할지를 알기 위해서 우리는 SSL Labs에서 일하기 시작했습니다. 그 결과 몇 가지 목표에 달성했는데, TLS 사용에 대한 전세계적인 통계와 온라인 평가 도구를 만들었으나, 문서 부족은 여전히 눈에 띕니다. 이 문서는 그 문제의 해법을 위한 첫 걸음입니다.

우리 목표는 안전한 사이트와 웹 애플리케이션을 배포하는데, 관리자와 프로그래머가 가능한 최소의 시간을 들이도록 명확하고 간결한 설명서를 제공하는 것입니다. 명확함을 추구하고자, 우리는 완성도를 희생하고, 특정 추가 주제도 건너뜁니다. 실질적이고 따라하기 쉬운데 요점을 두었습니다. 더 자세한 정보를 원하시는 분께는, 6장에서 유용한 정보를 제공합니다.

yeon.me TLS

1 개인키와 인증서

TLS에서  모든 보안은 서버의 암호화된 신원에서 시작합니다. 익명의 공격을 가하는 공격자들을 방지하는데 강력한 개인키가 필요합니다. 동시에 중요한 것은, 특정 호스트 이름을 나타내며 개인키를 승인하는, 유효하고 강력한 인증서를 갖는 것입니다. 이 두 가지 퍼즐 조각 없이는, 다른 어떤 것도 안전할 수 없습니다.

1.1 2048비트 개인키의 사용

대부분의 웹사이트에서, 2048 RSA 키로 제공되는 보안성으로 충분합니다. RSA 공개키 알고리즘은 폭넓게 지원되며, 이 유형의 키는 안전한 기본 선택입니다. 2048비트의 키에서는 112비트의 보안성을 제공합니다. 이보다 더 안전하려면, RSA 키는 규모 조절에 적당하지 않습니다. 128비트의 보안성을 얻으려면, 3072비트의 RSA 키가 필요한데, 이는 눈에 띄게 느립니다. ECDSA 키는 더 나은 보안성과 속도를 제공합니다. 적은 수의 오래된 클라이언트는 ECDSA를 지원하지 않지만, 요즘 클라이언트는 잘 지원합니다. 설정에 귀찮음을 느끼지만 않는다면, RSA과 ECDSA를 동시에 배포하는 것이 최적의 선택입니다.

1.2 개인키 보호

개인키를 중요한 구성 요소로 생각하고, 실제로 최소한의 인원에게만 공개하도록 하십시오. 아래 정책이 권장됩니다:

  • 충분히 불확정 요소를 갖춘, 신뢰할 수 있는 컴퓨터에서 개인키를 생성하십시오. 일부 CA는 당신을 위한 개인키를 스스로 만들어주는데, 그런 곳은 과감히 건너뛰십시오.
  • 백업 시스템에 저장될 때, 처음부터 키를 암호로 보호하십시오. 개인키 암호는 생성시 큰 도움이 되지 않는데, 대부분의 공격자들은 프로세스 메모리에서 키를 얻기 때문입니다. 서버 손상의 경우에도 개인 키를 보호 할 수있는 하드웨어 장치 (하드웨어 보안 모듈 또는 HSM이라고 함)가 있지만 비용이 많이 들고 엄격한 보안 요구 사항이있는 조직에만 적합합니다.
  • 새로운 발급 후에는, 낡은 인증서를 폐지하고, 새로운 키를 생성합니다.
  • 인증서를 매년 갱신하고, 자동화할 수 있다면 더 자주 하십시오. 대부분의 사이트는 손상된 인증서를 확증적으로 폐지할 수 없다고 가정해야 합니다.1 따라서 더 짧은 인증서 유효 기간이 실제로 더 안전합니다.
  • 공개키를 똑같이 유지하고 싶은 게 아니라면, 새 인증서를 만들 때마다 새로운 개인키를 만들어야만 합니다.

1.3 충분한 호스트 이름 보장

여러분의 인증서가 사이트에 쓰이는 모든 이름을 아우르도록 만드세요. 올바르지 않은 인증서라는 경고를 사용자들이 보지 못하게 하는 것이 목적입니다. 이는 사용자들을 혼란스럽게 만들고, 신뢰도를 떨어뜨립니다.

단 하나의 도메인 이름만 사용하길 기대한다고 해도, 사용자들이 사이트에 어떻게 도착하고, 어떻게 링크할지 모르고, 이를 제어할 방법이 없습니다. 대부분의 경우, 인증서는 www의 유무에 무관하게 작동해야 합니다 (예: example.com과 www.example.com에 모두 작동해야 합니다). 서버를 안전하게 만드는 가장 중요한 법칙으로, DNS 이름이 모두 올바르게 설정되어 서버를 가리키고 있어야 합니다.

와일드카드 인증서는 그 용도가 있지만, 그렇다고 거대한 그룹, 특히 팀이나 부서를 넘나들면서 키를 공개한다는 것은 피하세요. 다시 말해서, 소수의 사람들이 개인키를 알 수 있게 하는 것이 더 낫습니다. 또한 하나 이상의 웹 사이트나 서버에서 인증서를 공유하는 것은, 취약점을 공유한다는 점을 알아두세요 (심지어 개인키가 다르더라도).

1.4 믿을 수 있는 CA에서 인증서 얻기

인증 사업과 보안에서 철저하고 믿을만한 인증 기관(Certification Authority, CA)을 선택합니다. CA를 선택할 때는 다음 요소를 고려해보세요:

보안 상태 모든 CA는 일반적인 심사를 수행하지만, 일부는 다른 곳보다 더 철저합니다. 이것만 보고서 어느 게 낫다고 평가할 수는 없습니다. 그러나 이런 선택은 그들의 보안 이력, 더 나아가 보안 수준 타협에 대한 태도, 기존의 실수에서의 개선점을 나타낸다는 점에서 중요합니다.

사업 중점 CA의 사업 상당 부분을 구성하는 활동은 무언가 잘못되었을 때 모든 게 엉망이 될 수 있고, 그러면 인증서 부문을 게을리하고 수익을 좇아 다른 사업을 할 수 있습니다.

제공되는 서비스 최소한, CA는 인증서 폐기 목록(CRL)과 온라인 인증 상태 프로토콜(OCSP) 폐기 방법을 견고한 네트워크와 성능을 갖고 제공해야 합니다. 많은 사이트는 도메인 보증 인증서로 만족스러워하지만, 확장된 보증(EV) 인증서가 필요할지 생각해봐야 합니다. 어떤 경우든지, 공개키 알고리즘을 선택해야 합니다. 오늘날 대부분의 웹 사이트는 RSA를 사용하지만, ECDSA는 성능 이점 덕분에 미래에는 더욱 중요해질 것입니다.

인증 관리 옵션 많은 수의 인증서를 갖고 있고, 복잡한 환경에서 운용중이라면, 모두 관리하기 좋은 도구를 제공하는 CA를 선택하세요.

지원 필요한 순간에 기술 지원을 해줄 수 있는 CA를 선택하세요.

참고

되도록 배포하기 최소한 일주일 전에 인증서를 발급받으십시오. 이런 행동은 (1) 올바르지 않은 시계로 맞춰진 컴퓨터에서 인증서 경고가 발생하지 않도록 하며, 새 인증서를 OCSP 응답자에게 유효하다고 전파하는데 더 많은 시간이 필요한 CA에서 폐지 확인 실패를 방지할 수 있습니다. 시간이 지나면 이와 같은 ‘워밍업’ 시간을 1~3개월로 연장하십시오. 유사하게, 인증서를 교체하기 위해 인증서가 만료되길 기다리지 마십시오. 시계가 올바르지 않은 사람들을 위해서 몇 개월 정도의 거리를 두세요.

1.5 강력한 인증서 서명 알고리즘 사용

인증서 보안성은 (1) 인증서를 서명하는데 쓰인 개인키의 강도와 (2) 서명에 사용된 해시 함수의 강도에 달려 있습니다. 최근까지, 대부분의 인증서는 SHA1 해시 함수에 의존해왔으나, 이는 이제 안전하지 않은 것으로 드러났습니다. 따라서 우리는 SHA256으로 이동하고 있습니다. 2016년 1월 기준으로, 공개 CA에서 SHA1 인증서를 얻을 수 없습니다. 이미 존재하는 SHA1 인증서는 (일부 브라우저에서 경고가 뜨지만) 계속 작동하지만, 그것도 2016년까지만입니다.

2 구성

올바른 TLS 서버 구성이라면, 당신은 귀하의 자격 증명이 안전한 보안 프리미티브만을 쓰면서 취약점을 해결한 사용자에게 정상적으로 나타난다는 것을 알 수 있습니다.

2.1 완전한 인증 체인 사용

대부분의 배포에서, 서버 인증서 하나만으로는 불충분합니다. 신뢰 체인을 완성하려면 둘 이상의 인증서가 필요합니다. 서버를 공개할 때, 올바른 인증서를 쓰면서 필요한 중간 인증서를 쓰지 않은 경우 문제가 발생합니다. 이 상황을 피하려면, CA에서 제공된 모든 인증서를 사용해야 합니다.

올바르지 않은 인증서 체인은 서버 인증서를 부정확하게 렌더하게 되고, 브라우저의 경고 발생으로 이어집니다. 이런 경우, 브라우저에 따라 이런 현상이 나타나기도 하고 그렇지 않기도 하기 때문에, 문제를 진단하기가 어렵습니다. 모든 브라우저는 인증서를 캐시에 두고 지속적으로 재사용하려고 합니다.

2.2 안전한 프로토콜 사용

SSL/TLS 계열에는 SSL v2, SSL v3, TLS v1.0, TLS v1.1, TLS v1.2 다섯 가지 프로토콜이 있습니다.

SSL v2는 안전하지 않으며 사용해서는 안 됩니다. 이 프로토콜 버전은 RSA 키 공격에 쓰일 수 있고, 완전히 다른 서버에서 같은 이름을 사용할 수도(DROWN 공격) 있어서 최악입니다.

  • SSL v3은 HTTP에서 안전하지 않고(POODLE 공격) 다른 프로토콜과 같이 쓰일 때 약합니다. 역시 낡았으며 사용해서는 안 됩니다.
  • TLS v1.0은 역시 낡았으며 더 이상 사용해서는 안 됩니다. 그러나 실제로는 여전히 필요합니다. 주요 취약점(BEAST)은 최신 브라우저에서 해결되었지만, 다른 문제는 여전합니다.
  • TLS v1.1과 v1.2는 알려진 보안 이슈가 없지만, v1.2만 최신 암호화 알고리즘을 제공합니다.

최신 인증된 암호화(AEAD라고도 함)를 제공하는 유일한 버전이 TLS v1.2이므로, 이쪽이 주요 프로토콜이 되어야 합니다. 만약 오늘날 TLS v1.2를 지원하지 않는다면, 보안의 허점이라 할 수 있습니다.

오래된 클라이언트를 지원하기 위해서, TLS v1.0과 TLS v1.1도 지원해야 합니다. 그러나 근시일 내에 TLS v1.0을 퇴출시킬 계획을 세우셔야 합니다. 예를 들어, PCI DSS 표준은 신용카드를 받는 모든 사이트는 2018년 6월까지 TLS v1.0 지원을 제거해야 한다고 합니다.

모든 낡은 보안 취약점을 제거하고 미래에 안전한 통신을 보호하기 위해 개선하고자, TLS v1.3을 만드는 작업은 진행중입니다.

2.3 안전한 암호화 스위트(cipher suite) 사용

통신을 안전하게 하려면, 제일 먼저 원하는 곳에 바로 직결되어 (다른 사람이 엿듣지 않고) 통신하고 있는지 확인해야 합니다. SSL과 TLS에서, 암호화 스위트는 보안 통신이 이루어지는 방식을 결정합니다. 다양성을 통해 보안성을 얻는다는 생각을 가진 사람들에 의해 다양한 조각을 통해 만들어집니다. 하나가 약하거나 안전하지 않은 것으로 드러나면, 다른 것으로 바꿀 수 있습니다.

강력한 인증과 키 교환, 순방향 비밀성(forward secrecy), 최소 128비트의 암호화를 제공하는 AEAD 스위트를 주로 사용해야 합니다. 다른 약한 스위트는 여전히 지원되겠지만, 오래된 클라이언트가 더 나은 걸 지원하지 못할 때만 쓰입니다.

여기 있는 오래된 보안 프리미티브는 피해야 합니다:

  • 디피 헬만 키 교환(ADH) 스위트는 인증을 제공하지 않습니다.
  • NULL 암호화 스위트는 암호화를 제공하지 않습니다.
  • 수출 등급 암호화 스위트는 연결할 때 안전하지 않지만, 더 강한 스위트를 선호하는 서버에 대해 사용될 수도 있습니다. (FREAK 공격)
  • 약한 보안을 사용하는 스위트(주로 40 ~ 56비트)는 깨지기 쉬운 암호화를 사용합니다.
  • RC4는 안전하지 않습니다.
  • 3DES 느리고 약합니다.

처음 사용할 때 RSA와 ECDSA 양쪽으로 설계된 다음 스위트 설정을 사용하세요:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

경고

이러한 변경 사항을 실제로 적용할 때, TLS 구성을 사전 환경에서 우선 테스트해보길 권합니다.위 목록은 일반적인 경우이며, 모든 시스템(특히 낡은 것)을 지원하지 않습니다. 테스트가 중요한 이유입니다.

위 예시 구성은 표준 TLS 스위트 이름들입니다. 일부 플랫폼은 비표준 이름을 사용합니다. 여러분의 플랫폼에 대한 문서를 참고하세요. 예를 들어 다음 스위트 이름은 OpenSSL에서 쓰입니다:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256

2.4 가장 좋은 암호화 스위트 선택

SSL v3와 최신 프로토콜 버전에서, 클라이언트는 자신이 지원하는 암호화 스위트 목록을 전송하고, 서버는 연결에 그 중 하나를 사용하게 됩니다. 그러나 모든 서버가 이렇게 하지는 않는데, 일부는 그냥 클라이언트의 목록에서 첫 번째만 씁니다. 서버가 능동적으로 암호화 스위트 중에 가장 적절한 것을 선택하는 것이 가장 좋은 보안을 얻는데 결정적인 요소입니다.

2.5 순방향 비밀성(Forward Secrecy) 사용

순방향 비밀성(종종 Perfect를 붙여서 PFS라고도 불림)은 서버의 개인키에 의존적이지 않은 암호화 통신을 가능케 하는 프로토콜 기능입니다. 순방향 비밀성을 제공하지 않는 암호화 스위트에서, 누군가 서버의 개인키를 복구해내어 이전에 기록된 모든 암호화 통신을 복호화할 수 있습니다. 최신 웹 브라우저에서 순방향 비밀성을 활성화하려면  ECDHE를 지원하고 더 선호해야 합니다. 더 많은 클라이언트를 지원하기 위해서, DHE 스위트도 ECDHE의 차선책으로 사용할 수 있습니다. RSA 키 교환은 정말 필요한 경우가 아니면 피하세요. 2.3 섹션에 적힌 기본 구성은 순방향 비밀성을 제공하는 것만을 포함하고 있습니다.

2.6 강력한 키 교환 사용

공개 사이트는 흔히 DHE와 ECDHE 중에서 키 교환을 선택할 수 있습니다. 다른 키 교환 알고리즘도 있지만, 보통 여러 가지로 안전하지 않습니다. RSA 키 교환은 여전히 많이 쓰이지만, 순방향 비밀성을 제공하지 않습니다.

2015년, 연구자들은 DHE에 대한 새로운 공격을 발견했습니다. 로그잼 공격(Logjam attack)이라고 알려진 것입니다. 연구자들은 낮은 강도의 DH 키 교환(768비트 등)은 쉽게 깨질 수 있으며, 알려진 1024비트 DH 그룹 역시 주정부 기관에 의해 깨질 수 있다는 사실을 밝혀냈습니다. 안전하게 유지하려면, DHE를 배포할 때, 최소 2048비트의 보안을 구성해야 합니다. 오래된 클라이언트 (Java 6 등)는 이를 지원하지 못할 것입니다. 성능상 이유로, 대부분의 서버는 더욱 강하면서도 빠른 ECDHE를 선호합니다. secp256r1로 명명된 곡선(타원곡선 암호, EC)(P-256로도 알려져 있음)이 이 경우에 좋은 선택입니다.

2.7 알려진 문제 해결 방법

SSL과 TLS는 지난 몇 년간 몇몇 심각한 공격을 받아왔지만, 최신 버전의 소프트웨어를 쓰고 있으며 이 가이드만 잘 따라한다면 여러분은 걱정할 필요가 없습니다. (그렇지 않으면, SSL Labs에서 테스트해보시길 권합니다) 그러나 완벽히 안전한 것은 없으므로, 보안 소식에 귀를 기울이는 것이 좋습니다. 제조사 패치가 나오면 바로 적용하시고, 그렇지 않으면 해결을 위한 대안을 찾아야 합니다.

3 성능

이 문서의 중점은 바로 보안이지만, 성능에도 중점을 두어야 합니다. 성능 요건을 만족하지 못하면서 안전한 서비스는 의심할 여지 없이 거부당할 것입니다. 올바른 구성 아래에서, TLS는 꽤 빠릅니다. (HTTP/2와 같은) 최신 프로토콜은 평문 통신보다 더 빠를 것입니다.

3.1 지나친 보안을 피하기

핸드쉐이크는 보안 연결을 설정하는데 쓰이는데, 개인 키 크기에 의해 난이도가 좌우됩니다. 너무 짧은 키는 안전하지 않고, 너무 긴 키는 “지나치게” 보안이 높고 느립니다. 대부분의 웹 사이트에서, 2048비트보다 큰 RSA키와 256비트보다 강력한 ECDSA 키는 CPU 자원을 낭비하며, 사용자 경험을 해칠 수 있습니다. 동시에, 임시 키 교환을 DHE에서 2048비트, ECDHE에서 256비트보다 높이는 것은 성능상의 이점이 거의 없습니다. 128비트 초과한 암호화의 사용은 명확한 장점이 없습니다.

3.2 세션 재개 사용

세션 재개란, 비용이 큰 암호화 과정을 저장해두고 재사용 기간을 늘릴 수 있도록 하는 성능 최적화 기술입니다. 해제되어 있거나, 기능하지 않는 세션 재개 체계로 인해 눈에 띄는 성능 저하를 겪을 수 있습니다.

3.3 WAN 최적화와 HTTP/2 사용

오늘날, TLS의 오버헤드는 CPU 집약적인 암호화 과정이 아니라, 네트워크 지원에서 나타납니다. TLS 핸드쉐이크는 TCP 핸드쉐이크가 끝난 다음에 시작하며, 더 많은 패킷과 서버의 자원을 소비합니다. 이러한 지연을 최소화하는 가장 좋은 방법은 새로운 연결을 만드는 것입니다. 다시 말해, 연결을 오랫동안 열어두는 것입니다(keep-alive). HTTP/2를 포함한 최신 프로토콜 지원을 포함하는 것이나 (보통 CDN을 통한) WAN 최적화와 같은 기술이 좋은 결과를 가져옵니다.

3.4 공개 컨텐츠 캐시

TLS를 통한 통신을 할 때, 브라우저는 모든 통신이 최신 정보에 민감하다고 봅니다. 특정 메모리를 메모리에 캐시하지만, 한 번 브라우저를 닫으면 모든 내용을 잃어버립니다. 성능을 높이고 일부 자원에 대한 긴 시간 캐시를 허용하려면, (이미지와 같은) 공개 자원을 공개로 설정하십시오.

3.5 OCSP 스테이플링 사용

OCSP 스테이플링이란, 서버에서 직접, TLS 핸드쉐이크의 부분으로 폐찌 정보를 전달하는 OCSP 프로토콜의 확장입니다. 그 결과로, 클라이언트는 유효성 검증을 위해 OCSP 서버와 통신하는 TLS 연결 시간을 크게 줄이게 됩니다. OCSP 스테이플링은 중요한 최적화 기술이지만, 모든 웹 서버가 견고한 OCSP 스테이플링을 구현하지 않았다는 점을 알아두세요. 느리거나 신뢰하기 어려운 OCSP 대리자가 같이 구성되어 있다면, 웹 서버가 성능 문제를 일으킬 수 있습니다. 최상의 결과를 위해 가용성에 영향을 주는지, 실패시 조건을 꼭 시험해보세요.

3.6 빠른 보안 프리미티브 사용

위의 추천 암호화 스위트 구성은 최고의 보안을 제공할 뿐만 아니라, 최상의 성능도 제공합니다. 가능하면, 하드웨어 가속 AES를 지원하는 CPU를 사용하고, 더 나은 성능 향상을 보려면(대부분의 사이트에는 불필요) ECDSA 키를 사용하는 것을 고려해보세요.

4 HTTP 및 애플리케이션 보안

HTTP 프로토콜을 포함하여, 연관된 웹 애플리케이션은 SSL이 탄생한 이래로 빠르게 발전해왔습니다. 그 결과, 플랫폼은 이제 암호화를 파괴하기에 이르렀습니다. 이 장에서, 그런 기능들을 알아보고, 안전하게 사용하는 방법을 알아보겠습니다.

4.1 모두 암호화하기

암호화가 선택 사항이라는 점이 오늘날 가장 큰 보안 문제입니다. 다음과 같은 문제들을 마주하게 됩니다.

  • 사이트에 필요한 TLS가 없음
  • TLS를 갖고 있으나 강제하지 않음
  • TLS와 보안되지 않은 내용이 섞여 있는, 종종 같은 페이지에서조차 섞여 있는 사이트
  • TLS를 무효화시키는 프로그래밍 오류

비록 여러분이 문제를 알아차리고나서 이런 많은 문제가 나아진다고는 해도, 신뢰할 수 있도록 사이트를 보호하는 유일한 방법은 바로 예외 없이 암호화를 강제하는 것입니다.

4.2 혼합된 컨텐츠를 없애기

혼합된 컨텐츠는 TLS를 거치지 않는 자원(JavaScript 파일, 이미지, CSS 파일 등)을 포함하면서 TLS를 통해 전송되는 것입니다. 그런 페이지는 안전하지 않습니다. 활성화된 중간자 공격(MITM)의 공격자는 예를 들어 보호되지 않은 JavaScript 자원에 올라타서, 모든 사용자 세션을 조작합니다. 심지어 위 문서 내용을 잘 따라해서 모든 웹 사이트를 암호화했더라도, 여전히 제 3자 사이트에서 암호화되지 않은 자원을 일부 받고 있을 수 있습니다.

4.3 제 3자 신뢰를 이해하고 승인하기

웹 사이트는 다른 서버에서 다운로드된 JavaScript 코드를 통해 활성화된 제 3자 서비스를 주로 사용합니다. 좋은 예시가 바로 Google Analytics인데, 이는 웹에서 중요한 역할을 차지하고 있습니다. 이러한 제 3자 코드의 포함은 잠재적으로 여러분의 웹 사이트에 대한 완전한 제어권을 부여하는, 암시적 신뢰 연결을 만듭니다.

제 3자는 수상하지 않을 수 있지만, 그런 서비스는 목표물이 되기 쉽습니다. 이유는 단순합니다: 대형 제공 업체가 공격에 당하면, 공격자는 자동으로 그 서비스에 의존한 모든 사이트의 권한도 얻게 됩니다.

4.2절의 내용을 따르신다면, 적어도 제 3자 링크는 암호화되고 따라서 중간자 공격에서 안전합니다. 그러나, 여러분은 그 이상을 준비하셔야 합니다. 어떤 서비스를 사용하고 지울지를 알고, 더 안전한 대체 서비스로 바꾸거나, 계속 사용하는데 대한 위험을 받아들입니다. 서브리소스 통합(SRI)이라고 불리는 새로운 기술이 제 3자 자원에 의한 잠재적 노출을 줄여줄 것입니다.

4.4 안전한 쿠키

웹 사이트가 TLS를 요구하면, 안전을 위해 쿠키도 생성될 때 안전하다고 명시됩니다. 쿠키의 보안 실패는 100% 암호화된 웹 사이트에서조차, 뛰어난 트릭을 통해 중간자 공격을 위한 정보를 노출하게 됩니다. 최상의 결과를 위해서, 암호의 검증 통합을 추가하거나, 쿠키를 암호화하는 것을 고려해보세요.

4.5 안전한 HTTP 압축

2012 CRIME 공격은 TLS 압축이 안전하게 구현되지 않았다는 것을 보여줍니다. 유일한 해결책은 TLS 압축을 같이 끄는 것입니다. 이듬해에는 두 가지 추가 공격 방식이 뒤따랐습니다. TIME과 BREACH는 HTTP 압축을 사용하는 HTTP 응답 본문의 비밀에 집중했습니다. TLS 압축과 달리, HTTP 압축은 필요하며 끌 수 없습니다. 따라서 이러한 공격을 해결하려면, 응용 프로그램 코드를 변경해야 합니다.

TIME과 BREACH 공격은 행하기 어렵지만, 누군가 사용할 동기만 있다면, 충격은 사이트간 요청 위조(CSRF) 공격과 거의 유사할 것입니다.

4.6 HTTP 엄격한 전송 보안(HSTS)으로 배포

HTTP 엄격한 전송 보안(HSTS)은 TLS의 안전망입니다.  이 기능은 구성 문제 및 구현 오류가 발생해도 보안을 손상시키지 않도록 설계되었습니다. HSTS 보호를 활성화하려면, 웹 사이트 응답 헤더에 추가하셔야 합니다. 그 다음, HSTS 지원 브라우저(현재 모든 최신 브라우저)를 쓰게 합니다.

HSTS의 목표는 단순합니다. 활성화 후, 모든 평문 링크를 안전한 것으로 자동 변환합니다. 덤으로, 인증서 경고를 무시할 수 없게 합니다. (인증서 경고는 중간자 공격이 발생중임을 나타냅니다. 연구에 따르면 대부분의 유저는 이 경고를 클릭하고 무시하기 때문에, 허용하지 않는 것이 가장 낫습니다)

HSTS에 대한 지워 추가는 웹 사이트의 TLS 보안에 대한 가장 중요한 개선 사항 중 하나입니다. 새로운 사이트는 HSTS 하에 디자인되어야 하며, 그걸 지원하기 위해 변환된 오래된 사이트도 가능한 경우 언제든지 활성화해야 합니다. 최고의 보안을 위해, 최신 브라우저의 HSTS 구성에 여러분의 사이트를 내장시켜서, 첫 연결시부터 암호화를 하게 만드는 HSTS 프리로드 사용을 고려해보세요.

다음 구성은 메인 호스트 이름, 서브 도메인을 같이 1년간 HSTS를 활성화시키는 예시입니다.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

4.7 배포 내용 보안 정책

내용 보안 정책(CSP)는 웹 사이트가 브라우저 동작을 제한할 수 있는 보안 작용입니다. 비록 원래 도메인간 스크립팅(XSS)을 나타내기 위한 것이었지만, CSP는 계속해서 진보하고 있고, TLS 계층을 개선하는데 유용한 기능을 지원합니다. 특히, HSTS가 역할을 못하는 제 3자 웹 사이트에 섞인 컨텐츠를 제한하는데 쓸 수 있습니다.

혼합된 제 3자 내용을 방지하고자 CSP를 배포하려면, 다음 구성을 사용하세요.

Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval';
                         connect-src https: wss:

참고

이는 CSP를 배포하는 가장 좋은 방법이 아닙니다.혼합된 컨텐츠를 제외하고 깨지지 않게 하는 예시를 제공하기 위해, 기본 보안 기능을 일부 껐습니다. 시간이 지남에 따라 CSP에 대해 자세히 알게 되면, 정책을 변경하여 다시 가져와야 합니다.

4.8 민감한 내용을 캐시에 담지 마세요

모든 민감한 내용은 의도된 당사자에게만 전달되어야하며, 모든 장치에 따라 적절하게 처리되어야 합니다. 프록시가 암호화된 트래픽을 보지 못하고, 사용자 사이에 공유할 수 없지만, 앱 배포 플랫폼에 기반한 클라우드의 사용이 늘고 있으며, 이는 무엇이 공개고 아닌지를 명확히 하는데 신중해야 하는 이유가 됩니다.

4.9 다른 위협 고려

TLS는 보안의 한 측면, 즉 사용자와 사용자 간의 통신 기밀성 및 무결성만을 처리하도록 설계되었지만 처리해야할 다른 많은 위협들이 있습니다. 대부분의 경우, 이는 웹 사이트가 다른 취약점이 없다는 것을 말합니다.

5 확인

많은 구성 매개변수가 트윅 대상이지만, 어떤 차이를 갖게 되어 무슨 영향을 주는지, 정확히 알기는 어렵습니다. 게다가, 변화는 갑작스럽게 생깁니다. 소프트웨어 업그레이드는 자동으로 변경 사항을 도입할 수 있습니다. 따라서, 처음에는 포괄적인 SSL/TLS 평가 도구를 사용하여 구성을 확인하여 안전한 것으로 시작하는지, 그 다음엔 주기적으로 보안이 유지되는지 확인하는 것이 좋습니다. 공개 웹 사이트에 대해서 우리는 무료 SSL Labs 서버 테스트를 권합니다.

6 추가 주제

다음 추가 주제는 우리 가이드 범위를 벗어납니다. SSL/TLS과 공개 키 기반(PKI)에 대한 깊은 이해를 필요로 하며, 전문가에 의해 여전히 논쟁중인 부분입니다.

6.1 공개 키 고정 (Public Key Pinning)

공개 키 고정은 웹 사이트 운영자에게 자신의 웹 사이트에 대한 인증서를 발급할 수 있는 CA를 제한하는 수단을 제공하도록 설계되었습니다. 이 기능은 Google에 의해 당분간 배포되고(Chrome에 하드코드되어 있음) 공격을 방지하고 사람들에게 알리는데 유용하다는 점을 입증받았습니다. 2014년 Firefox도 하드코드된 고정 지원을 추가했습니다. 표준 HTTP 공개 키 고정 확장이 이제 가능합니다. 공개 키 고정은 PKI의 커다란 취약점(아무 CA나 아무 웹 사이트에 인증서를 발급할 수 있다는 점)을 해결하지만, 대가가 있습니다. 배포에 상당한 노력과 전문 지식이 필요하며, 사이트 제어 권한을 잃을 우려가 있습니다 (잘못된 구성을 고정한 경우). 사기성 인증서를 통해 현실적으로 공격당할 수 있는 사이트를 관리하는 경우에만 주로 고정을 고려해야 합니다.

6.2 DNSSEC과 DANE

도메인 네임 시스템 보안 확장(DNSSEC)는 도메인 네임 시스템과 통합을 추가하는 기술입니다. 오늘날 능동적인 네트워크 공격자는 쉽게 아무 DNS 요청이나 가로채서, 임의의 응답을 위조할 수 있습니다. DNSSEC를 사용하면 모든 응답을 DNS 루트로 다시 암호화하여 추적할 수 있습니다. 네임 엔티티의 DNS 기반 인증(DANE)은 DNSSEC 위에 만드는 구분된 표준으로, DNS와 TLS 사이 연결을 제공합니다. DANE은 기존의 CA 기반 PKI 환경의 보안을 강화하거나 이를 우회하는데 사용될 수 있습니다.

모든 사람이 DNSSEC가 인터넷의 좋은 방향이라는데 동의하지는 않지만, 이에 대한 지원은 개선되고 있습니다. 브라우저는 아직 DNSSEC나 DANE (대신 HSTS나 HPKP를 선호) 모두 지원하지 않지만, 이메일 전달의 보안을 향상시키는데 사용하기 시작한다는 징후가 있습니다.

출처: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices

Footnotes

  1. 즉, 손을 떠난 인증서가 오용될 가능성이 있고 revoke가 어렵기 때문에, 이상 상황에 대비하여 인증서는 짧게 잡아야 한다는 말입니다.