취약하거나 위험한 암호 알고리즘/프로토콜 사용

Use of a Broken or Risky Cryptographic Algorithm

설명

이 취약점은 TLS 설정에서 MinVersion을 지정하지 않거나, 너무 낮은 버전(TLS 1.0/1.1/SSLv3 등)을 허용할 때 발생합니다. TLS(전송 계층 보안)는 HTTPS 등에서 데이터 기밀성과 무결성을 보장하지만, 오래된 버전은 알려진 취약점(예: POODLE, BEAST, RC4 약점 등)으로 인해 공격자가 통신 내용을 복호화하거나 변조할 수 있습니다. tls.Config에서 최소 버전을 명시하지 않으면, 런타임 기본값이나 잘못된 설정으로 인해 약한 프로토콜이 활성화될 수 있고, 공격자는 이 약한 프로토콜로 다운그레이드 공격을 시도해 암호화된 통신 내용을 가로채거나(Session Hijacking), 조작된 패킷을 주입할 수 있습니다.

잠재적 영향

  • 민감 정보 노출: HTTPS 통신에 포함된 계정 정보, 세션 쿠키, 개인 정보 등이 공격자에게 평문 또는 부분 평문 형태로 노출될 수 있습니다.

  • 통신 내용 변조: 공격자가 중간자(Man-in-the-Middle) 위치에서 요청/응답을 바꿔치기하여 다운로드 파일, 결제 정보, 설정값 등을 조작할 수 있습니다.

  • 암호 강도 저하: 최신 TLS 1.3에서 제공하는 강한 암호 스위트, Forward Secrecy 등의 보안 이점을 활용하지 못하고, 취약한 Cipher/프로토콜에 의존하게 됩니다.

해결 방법

  • TLS 최소 버전 명시: Go 애플리케이션에서 crypto/tlstls.Config를 사용할 때 반드시 MinVersion: tls.VersionTLS13와 같이 최소 버전을 명시합니다. 일반적인 웹 서비스는 TLS 1.3을 기본으로 하고, 하위 버전은 비활성화하는 것이 권장됩니다.

  • 레거시 지원 최소화: 오래된 브라우저(예: IE 10)를 꼭 지원해야 하는 특수 상황이 아니라면, TLS 1.0/1.1 및 SSLv3는 사용하지 않습니다. 부득이하게 사용할 경우, 해당 경로를 별도 서비스/도메인으로 분리하고, 추가 모니터링 및 위험 고지를 고려합니다.

  • 보안 가이드라인 준수: 기업/조직의 보안 정책, 브라우저/플랫폼 지원 현황, 최신 보안 권고(예: OWASP, 각 언어 런타임 릴리즈 노트)를 참고해 주기적으로 TLS 설정을 점검합니다.

  • 테스트 및 검증: sslscan, nmap --script ssl-enum-ciphers, 온라인 TLS 검사 도구 등을 사용해 서버가 허용하는 프로토콜과 암호 스위트를 정기적으로 점검합니다.

취약한 코드 및 안전한 코드 예시

취약한 코드

안전한 코드

설명:

  • 취약한 코드: 위 코드에서는 tls.Config를 생성하면서 MinVersion을 설정하지 않았습니다. 이렇게 되면:

  • 어떤 TLS 버전이 실제로 사용될지 코드만 보고 확실히 알 수 없고,

  • 런타임 기본값 변경, 잘못된 시스템 설정 등에 의해 TLS 1.0/1.1 같은 취약한 프로토콜이 허용될 수 있습니다. 그 결과, 공격자는 다운그레이드 공격을 통해 의도보다 약한 TLS 버전으로 통신을 강제하고, 알려진 취약점을 이용해 통신 내용을 탈취하거나 변조할 가능성이 생깁니다.

  • 안전한 코드: 수정된 코드에서는 tls.ConfigMinVersion: tls.VersionTLS13를 명확히 지정했습니다. 이를 통해:

  • 서버가 TLS 1.3 미만의 프로토콜(SSLv3, TLS 1.0/1.1/1.2 등)을 협상하지 않게 되어, 다운그레이드 공격 가능성이 크게 줄어듭니다.

  • 애플리케이션이 항상 강한 암호 스위트와 최신 프로토콜 기능(예: 향상된 핸드셰이크, 성능 및 보안 개선)을 사용하게 됩니다. 즉, 최소 프로토콜 버전을 코드 레벨에서 강제함으로써, 잘못된 기본 설정이나 환경 변화로 인한 암호 강도 저하를 예방할 수 있습니다.

참조

Last updated