취약한 암호화 알고리즘 사용 (SSLv3 사용)

Use of Broken Cryptographic Algorithm (SSLv3)

설명

이 취약점은 Go 애플리케이션에서 TLS 설정 시, 이미 보안 취약점이 다수 알려진 SSLv3 프로토콜 버전을 사용하는 경우 발생합니다. SSLv3는 프로토콜 설계상의 문제(예: POODLE 공격)로 인해 기밀성·무결성을 보장하지 못합니다. 공격자는 SSLv3를 강제로 사용하도록(다운그레이드) 유도한 뒤, 암호화된 트래픽 일부를 평문으로 복구하거나 세션 정보를 탈취할 수 있습니다.

잠재적 영향

  • 민감 정보 노출 (Sensitive Data Exposure): SSLv3는 여러 알려진 공격(예: POODLE)에 취약하여, 공격자가 네트워크 트래픽을 중간에서 가로채고 복호화해 로그인 정보나 세션 쿠키, 개인 정보를 탈취할 수 있습니다.

  • 암호 통신 무력화 (암호화 강도 약화): 안전한 TLS 버전이 있음에도 SSLv3를 허용하면, 공격자가 프로토콜 다운그레이드를 유도해 전체 통신의 보안 수준을 낮추고, 이후 다른 암호 공격을 결합해 통신 보호를 사실상 무력화할 수 있습니다.

  • 규제 및 컴플라이언스 위반 (보안 규정 미준수): PCI-DSS, ISO 27001 등 많은 보안 규정은 안전하지 않은 프로토콜 사용을 금지합니다. SSLv3 사용은 이러한 규정을 위반해 감사 실패, 인증 취소, 법적·계약상의 불이익으로 이어질 수 있습니다.

해결 방법

  • SSLv3 비활성화: tls.Config에서 MinVersion을 최소 TLS 1.2 이상(가능하면 tls.VersionTLS13)으로 설정해 SSLv3를 전면 비활성화합니다.

  • 안전한 TLS 버전 강제: 서버·클라이언트 양쪽 모두 TLS 1.2/1.3만 허용하고, 다운그레이드 공격을 막기 위해 설정을 통일합니다.

  • 라이브러리/런타임 업데이트: 최신 Go 버전과 crypto/tls 패키지를 사용해 기본 보안 설정과 암호 스위트 목록을 최신 상태로 유지합니다.

  • 설정 검증 및 테스트: 보안 스캐너(예: nmap, sslyze)나 온라인 TLS 테스트 도구를 사용해 SSLv3와 다른 약한 프로토콜이 실제로 비활성화되어 있는지 주기적으로 확인합니다.

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

취약한 코드

안전한 코드

설명:

  • 취약한 코드: non_compliant 코드에서는 tls.Config.MinVersion을 tls.VersionSSL30으로 설정하여 SSLv3를 허용하고 있습니다. SSLv3는 이미 여러 공개된 취약점(예: POODLE)으로 인해 더 이상 안전한 프로토콜로 인정되지 않습니다. 이 설정이 있으면, 클라이언트와 서버 간 협상 과정에서 공격자가 프로토콜 다운그레이드를 유도해 SSLv3로 통신하게 만들 수 있고, 그 후 암호화 트래픽을 복호화하거나 세션 정보를 탈취할 위험이 있습니다.

  • 안전한 코드: compliant 코드에서는 MinVersion을 tls.VersionTLS12로 설정하여 SSLv3, TLS 1.0, TLS 1.1 등 구버전 프로토콜을 전부 비활성화했습니다. 이렇게 하면 클라이언트와 서버가 최소 TLS 1.2 이상으로만 통신하게 되어, 알려진 구식 프로토콜 취약점(POODLE 등)을 이용한 공격을 원천 차단할 수 있습니다. 또한 TLS 1.2/1.3는 현대적인 암호 스위트와 보다 강한 보안 기능을 제공하므로 민감 정보 보호와 규제 준수 측면에서도 안전합니다.

참조

Last updated