4.2. RHEL 9의 TLS에 대한 보안 고려 사항
RHEL 9에서 TLS 구성은 시스템 전체 암호화 정책 메커니즘을 사용하여 수행됩니다. 1.2 미만의 TLS 버전은 더 이상 지원되지 않습니다. DEFAULT,FUTURE, LEGACY 암호화 정책은 TLS 1.2 및 1.3만 허용합니다. 자세한 내용은 시스템 전체 암호화 정책 사용을 참조하십시오.
RHEL 9에 포함된 라이브러리에서 제공하는 기본 설정은 대부분의 배포에 충분히 안전합니다. TLS 구현에서는 가능한 경우 또는 기존 클라이언트 또는 서버의 연결을 방지할 수 없는 보안 알고리즘을 사용합니다. 보안 알고리즘 또는 프로토콜을 지원하지 않는 레거시 클라이언트나 서버가 연결되지 않거나 연결할 수 없는 엄격한 보안 요구 사항을 충족하는 환경에서 강화된 설정을 적용합니다.
TLS 구성을 강화하는 가장 간단한 방법은 update-crypto-policies --set FUTURE 명령을 사용하여 시스템 전체 암호화 정책 수준을 FUTURE로 전환하는 것입니다.
LEGACY 암호화 정책에 대해 비활성화된 알고리즘은 Red Hat의 RHEL 9 보안 비전을 준수하지 않으며 보안 속성을 신뢰할 수 없습니다. 다시 활성화하는 대신 이러한 알고리즘 사용에서 벗어나는 것이 좋습니다. 예를 들어 이전 하드웨어와의 상호 운용성을 위해 다시 활성화하기로 결정한 경우, 이를 안전하지 않은 것으로 처리하고 네트워크 상호 작용을 별도의 네트워크 세그먼트에 격리하는 등의 추가 보호 조치를 적용합니다. 공용 네트워크에서 사용하지 마십시오.
RHEL 시스템 전체 암호화 정책을 따르거나 설정에 맞는 사용자 지정 암호화 정책을 생성하기로 결정한 경우 사용자 정의 구성에서 선호하는 프로토콜, 암호화 제품군 및 키 길이에 다음 권장 사항을 사용하십시오.
4.2.1. 프로토콜
최신 버전의 TLS는 최상의 보안 메커니즘을 제공합니다. TLS 1.2는 LEGACY 암호화 정책을 사용하는 경우에도 최소 버전입니다. 암호화 정책을 비활성화하거나 사용자 지정 정책을 제공하면 이전 프로토콜 버전을 다시 활성화할 수 있지만 결과적으로 생성되는 구성은 지원되지 않습니다.
RHEL 9는 TLS 버전 1.3을 지원하지만 RHEL 9 구성 요소에서 이 프로토콜의 일부 기능을 완전히 지원하는 것은 아닙니다. 예를 들어 연결 대기 시간을 줄이는 0-RTT(round Trip Time) 기능은 Apache 웹 서버에서 아직 완전히 지원하지 않습니다.
FIPS 모드에서 실행되는 RHEL 9.2 이상 시스템은 모든 TLS 1.2 연결이 FIPS 140-3 표준의 필요에 따라 확장 마스터 보안(ECDSA) 확장(RFC 7627)을 사용해야 함을 강제합니다. 따라서 ECDSA 또는 TLS 1.3을 지원하지 않는 레거시 클라이언트는 FIPS 모드에서 실행되는 RHEL 9 서버에 연결할 수 없으며 FIPS 모드의 RHEL 9 클라이언트는 ECDSA 없이 TLS 1.2만 지원하는 서버에 연결할 수 없습니다. Red Hat Enterprise Linux 9.2에서 적용된 TLS 확장 "확장 마스터 시크릿"을 참조하십시오.
4.2.2. 암호화 제품군
보안이 강화된 최신 암호화 제품군을 안전하지 않은 이전 암호 제품군에 우선적으로 사용해야 합니다. 항상 암호화 또는 인증을 전혀 제공하지 않는 eNULL 및 aNULL 암호화 제품군 사용을 비활성화합니다. 가능한 경우 심각한 단점이 있는 RC4 또는 HMAC-MD5를 기반으로 하는 암호 제품군도 비활성화해야 합니다. 즉, 의도적으로 약해졌던 수출 암호 모음에도 동일하게 적용됩니다. 따라서 쉽게 중단할 수 있습니다.
즉시 안전하지 않지만 128비트 미만의 보안을 제공하는 암호화 제품군은 짧은 유효 기간 동안 고려해서는 안 됩니다. 128비트의 보안을 사용하는 알고리즘은 적어도 몇 년 동안 중단되지 않을 수 있으므로 강력하게 권장합니다. 3DES 암호화는 168비트 사용을 알리지만 실제로 112비트의 보안을 제공합니다.
항상 서버 키가 손상된 경우에도 암호화된 데이터의 기밀성을 보장하는 PFS(forward secrecy)를 지원하는 암호화 제품군을 선호합니다. 이 규칙은 빠른 RSA 키 교환을 제한하지만 ECDHE 및 DHE를 사용할 수 있습니다. 이 둘 중 ECDHE는 더 빠르고 선호되는 선택입니다.
또한 Oracle 공격에 취약하지 않으므로 CBC-GCM 이상의 AEAD 암호를 선호해야 합니다. 또한 대부분의 경우 AES-GCM은 특히 하드웨어에 AES용 암호화 가속기가 있는 경우 CBC 모드에서 AES보다 빠릅니다.
또한 ECDSA 인증서와 함께 ECDSA 키 교환을 사용할 때는 트랜잭션이 순수 RSA 키 교환보다 훨씬 빠릅니다. 레거시 클라이언트를 지원하기 위해 서버에 두 쌍의 인증서와 키(새 클라이언트용)와 RSA 키가 있는 키(기존 클라이언트의 경우)를 설치할 수 있습니다.
4.2.3. 공개 키 길이
RSA 키를 사용하는 경우 항상 적어도 SHA-256에 의해 서명된 3072 비트의 키 길이를 선호하며, 이는 실제 128비트의 보안에 충분히 큰 영향을 미칩니다.
시스템의 보안은 체인에서 가장 약한 링크만큼 강력합니다. 예를 들어 강력한 암호만으로는 좋은 보안이 보장되지 않습니다. 키와 인증서는 키에 서명하는 데 CA(인증 기관)에서 사용하는 해시 기능 및 키뿐만 아니라 중요합니다.
