4.13. TLS 설정 강화
TLS (Transport Layer Security)는 네트워크 통신을 보호하는 데 사용되는 암호화 프로토콜입니다. 기본 키 교환 프로토콜,인증 방법 및 암호화 알고리즘 을 구성하여 시스템 보안 설정을 강화할 때 지원되는 클라이언트의 범위를 넓히면 결과적으로 보안 수준이 낮아집니다. 반대로 엄격한 보안 설정은 클라이언트와의 호환성이 제한되어 일부 사용자가 시스템에서 잠길 수 있습니다. 가장 엄격한 사용 가능한 구성을 대상으로 하고 호환성을 위해 필요한 경우에만 완화해야 합니다.
Red Hat Enterprise Linux 7에 포함된 라이브러리에서 제공하는 기본 설정은 대부분의 배포에 충분히 안전합니다.
TLS 구현은 기존 클라이언트 또는 서버에서의 연결을 방지하지 못하는 동시에 보안 알고리즘을 사용합니다. 보안 알고리즘 또는 프로토콜을 지원하지 않거나 연결할 수 없는 기존 클라이언트 또는 서버를 지원하지 않는 엄격한 보안 요구 사항이 있는 환경에서 이 섹션에 설명된 강화된 설정을 적용합니다.
4.13.1. 사용할 알고리즘 선택
선택 및 구성해야 하는 여러 구성 요소가 있습니다. 다음 각각은 결과 구성의 견고성(및, 클라이언트의 지원 수준) 또는 솔루션이 시스템에 있는 컴퓨팅 요구 사항에 직접적인 영향을 미칩니다.
프로토콜 버전
최신 버전의
TLS 는 최상의 보안 메커니즘을 제공합니다. 이전 버전의 TLS (또는 SSL)에 대한 지원을 포함해야 하는 강력한 이유가 없는 경우 시스템에서 최신 버전의 TLS 를 사용하여 연결을 협상할 수 있습니다.
SSL 버전 2 또는 3을 사용한 협상은 허용하지 마십시오. 이러한 두 버전에는 심각한 보안 취약점이 있습니다. TLS 버전 1.0 이상을 사용하는 협상만 허용합니다. 현재 TLS, 1.2를 사용하는 것이 좋습니다.
참고
현재 모든
TLS 버전의 보안은 TLS 확장, 특정 암호(아래 참조) 및 기타 해결 방법에 따라 다릅니다. 모든 TLS 연결 피어는 보안 재협상 표시(RFC5746)를 구현해야 하며 압축을 지원하지 않아야 하며 CBC-mode 암호(Lucky Thirteen 공격)에 대한 타이밍 공격에 대한 완화 조치를 구현해야 합니다. TLS 1.0 클라이언트는 레코드 분할을 추가로 구현해야 합니다(BEAST 공격에 대한 해결 방법). TLS 1.2 에서는 알려진 문제가 없는 AES-GCM,AES-CCM 또는 Camellia-GCM 와 같은 관련 데이터 (AEAD) 모드 암호를 사용하여 인증된 암호화를 지원합니다. 언급된 모든 완화 조치는 Red Hat Enterprise Linux에 포함된 암호화 라이브러리에서 구현됩니다.
프로토콜 버전 및 권장 사용에 대한 간략한 개요는 표 4.6. “프로토콜 버전” 을 참조하십시오.
| 프로토콜 버전 | 사용 권장 사항 |
|---|---|
SSL v2 |
사용하지 마십시오. 심각한 보안 취약점이 있습니다.
|
SSL v3 |
사용하지 마십시오. 심각한 보안 취약점이 있습니다.
|
TLS 1.0 |
필요한 경우 상호 운용성을 목적으로 사용합니다. 상호 운용성을 보장하는 방식으로 완화할 수 없는 알려진 문제가 있어 완화 조치가 기본적으로 활성화되어 있지 않습니다. 최신 암호화 제품군을 지원하지 않습니다.
|
TLS 1.1 |
필요한 경우 상호 운용성을 목적으로 사용합니다. 알려진 문제는 없지만 Red Hat Enterprise Linux의 모든
TLS 구현에 포함된 프로토콜 수정에 의존합니다. 최신 암호화 제품군을 지원하지 않습니다.
|
TLS 1.2 |
권장 버전입니다. 최신
AEAD 암호화 제품군을 지원합니다.
|
Red Hat Enterprise Linux의 일부 구성 요소는
TLS 1.1 또는 1.2 를 지원하더라도 TLS 1.0 을 사용하도록 구성되어 있습니다. 이는 최신 버전의 TLS 를 지원하지 않을 수 있는 외부 서비스와 가장 높은 수준의 상호 운용성을 달성하기 위한 시도에 의해 촉진됩니다. 상호 운용성 요구 사항에 따라 사용 가능한 최고 버전의 TLS 를 활성화합니다.
중요
SSL v3 는 사용하지 않는 것이 좋습니다. 그러나 일반적인 사용을 위해 안전하지 않고 적합하지 않은 것으로 간주되는 경우에도 SSL v3 을 계속 활성화해야 하는 경우 4.8절. “stunnel 사용” 에서 암호화를 지원하지 않는 서비스를 사용하는 경우에도 stunnel 을 사용하여 통신을 안전하게 암호화하는 방법에 대한 지침은 에서 사용되지 않고 안전하지 않은 암호화 모드를 사용할 수 있는 경우에만 사용할 수 있는 방법에 대한 지침을 참조하십시오.
암호화 제품군
최신의 보안 암호 제품군은 안전하지 않은 오래 된 암호 제품군을 선호해야 합니다. 항상 암호화 또는 인증을 전혀 제공하지 않는 eNULL 및 aNULL 암호화 제품군 사용을 비활성화합니다. 가능한 경우 중요한 단점을 가진
RC4 또는 HMAC-md5 기반 암호화 제품군도 비활성화해야 합니다. 동일한 이름이 저용인 내보내기 암호 모음에 적용되고, 이는 의도적으로 설정되었기 때문에 쉽게 중단할 수 있습니다.
즉시 안전하지는 않지만 짧은 유용한 수명 동안 128 비트의 보안을 제공하는 암호화 제품군은 고려해서는 안 됩니다. 128비트의 보안을 사용하는 알고리즘은 적어도 몇 년 동안 분리할 수 없을 것으로 예상되므로 적극 권장됩니다.
3DES 암호가 168 비트의 사용을 알리는 반면, 실제로 112 비트의 보안을 제공합니다.
서버 키가 손상된 경우에도 암호화된 데이터의 기밀성(PFS) 을 지원하는 암호화 제품군에 항상 우선순위를 부여합니다. 이 규칙은 빠른
RSA 키 교환에서 제외되지만 ECDHE 와 DHE 를 사용할 수 있습니다. 두 가지 중에서 ECDHE 가 더 빠르므로 선호하는 선택이 더 빠릅니다.
또한
CBC-mode 암호를 패딩 또는acle 공격에 취약하지 않으므로 AEAD 암호(예: AES-GCM )에 우선순위를 부여해야 합니다. 또한 대부분의 경우 AES -GCM 는 특히 하드웨어에 AES 에 대한 암호화 가속기가 있는 경우 CBC 모드보다 빠릅니다.
ECDSA 인증서와 함께 ECDHE 키 교환을 사용하는 경우 트랜잭션이 순수 RSA 키 교환보다 훨씬 빠릅니다. 레거시 클라이언트에 대한 지원을 제공하기 위해 서버에 두 개의 인증서와 키 쌍을 설치할 수 있습니다. 하나는 ECDSA 키(새 클라이언트용)와 RSA 키(기존 키용)와 함께 설치합니다.
공개 키 길이
RSA 키를 사용하는 경우 항상 최소 SHA-256에서 서명된 최소 3072비트의 키 길이를 선호하며, 이 키 길이는 true 128비트의 보안에 충분히 큽니다.
주의
시스템의 보안은 체인에서 가장 약한 링크만큼 강력합니다. 예를 들어 강력한 암호만으로는 좋은 보안이 보장되지 않습니다. 키와 인증서는CA( 인증 기관 )에서 키에 서명하는 데 사용하는 해시 함수 및 키뿐만 아니라 중요합니다.
