HTTPS를 통해 Application Load Balancer에 연결할 때 SSL/TLS 협상 오류가 발생하는 원인과, 오류를 발생시킨 클라이언트 IP를 식별하는 방법은 무엇인가요?

Short description

클라이언트 TLS 협상 오류는 클라이언트에서 시작된 TLS 연결이 로드 밸런서와 세션을 설정하는데 실패할 때 발생합니다. 이 오류는 다음과 같은 경우에 발생할 수 있습니다:

• 클라이언트가 로드 밸런서의 보안 정책에서 지원하지 않는 암호 또는 프로토콜을 사용하는 경우
• 클라이언트가 서버 인증서 검증에 실패한 경우

이러한 오류가 발생하면 ALB의 ClientTLSNegotiationErrorCount 지표가 증가합니다.

Summary

1. ALB 연결 로그 확인
   • tls_verify_status의 오류 코드 확인
   • TLS 보안 정책이 지원하는 프로토콜과 암호
2. 클라이언트 측 패킷 데이터 캡처
3. 기타 로그 비교
   • VPC 흐름 로그와 ALB 액세스 로그 비교
   • ALB 연결 로그와 ALB 액세스 로그 비교

Resolution

1. ALB 연결 로그 확인

1) tls_verify_status의 오류 코드 확인

ALB 연결 로그가 활성화되어 있고 로드 밸런서가 클라이언트와 연결을 설정할 수 없는 경우, 연결 로그의 tls_verify_status에 연결 실패 코드가 기록됩니다. 다음 오류 코드들은 SSL/TLS 협상 실패의 가능한 원인을 나타냅니다:

• ClientCertUntrusted: 클라이언트 인증서를 신뢰할 수 없음
• ClientCertNotYetValid: 클라이언트 인증서가 아직 유효하지 않음
• ClientCertTypeUnsupported: 클라이언트 인증서 유형이 지원되지 않음

특히 tls_verify_status에는 다음과 같은 값들이 있어 추가 해석이 필요합니다:

• -: 요청이 HTTPS 리스너를 사용하지 않는 경우 이 값이 표시됨
• Failed:UnmappedConnectionError: 런타임 연결이 제대로 매핑되지 않았을 때 발생, mTLS(상호 TLS)가 아닌 시나리오에서 TLS 협상 실패가 발생할 때 기록됨

** 참고: 로드 밸런서는 최선의 노력으로 요청을 기록합니다. ALB 로그는 모든 요청을 완벽하게 기록하기 위한 용도가 아니라 요청 특성을 이해하는 데 사용하는 것이 좋습니다.

2) TLS 보안 정책이 지원하는 프로토콜과 암호

각 TLS 보안 정책은 특정 프로토콜과 암호를 지원합니다. 클라이언트의 요청이 이러한 지원 구성과 일치하지 않으면 SSL/TLS 협상 오류가 발생할 수 있습니다. 현재 AWS 관리 콘솔을 통해 생성된 리스너에는 ELBSecurityPolicy-TLS13-1-2-2021-06 정책이 할당됩니다. 이 정책은 다음을 지원합니다:

지원되는 프로토콜:

TLS 1.3
TLS 1.2

지원되는 암호:

TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384

클라이언트가 사용하는 프로토콜 및 암호를, ALB 리스너의 보안 정책이 지원하는 프로토콜 및 암호와 비교하시어 일치하지 않는 경우 ClientTLSNegotiationErrorCount가 발생한 것으로 유추할 수 있습니다.

2. 클라이언트 측 패킷 캡처

정확한 문제 해결을 위해서는 클아이언트 측 패킷을 캡처하는 것이 TLS 협상에 실패한 이유와 영향을 받은 클라이언트 IP 주소를 확인하는 가장 효과적인 방법입니다. tcpdump 또는 Wireshark와 같은 패킷 캡처 도구를 사용하면 협상 과정에서 사용된 정확한 암호 및 프로토콜을 식별할 수 있습니다. 또한 OpenSSL을 사용하여 서버가 지원하는 암호화 방식과 프로토콜을 수동으로 확인할 수 있습니다:

$ openssl s_client -connect <ALB-Domain>:443 -tls1_2

<ALB-Domain>에 ALB 도메인 이름을 입력하여 TLS 1.2 지원 여부를 확인하십시오.

3. 기타 로그 비교

1) VPC 흐름 로그와 ALB 액세스 로그 비교

ALB 노드의 ENI(Elastic Network Interface)에서 VPC 흐름 로그를 활성화하고 ALB 액세스 로그와 비교할 수 있습니다.

• SSL/TLS 협상 오류가 발생하면 클라이언트 IP가 VPC 흐름 로그에는 나타나지만 ALB 액세스 로그에는 나타나지 않습니다.
• 이는 ALB가 요청을 받았지만 SSL/TLS 협상 실패로 인해 연결을 완료하지 못했음을 나타냅니다.

2) ALB 연결 로그와 ALB 액세스 로그 비교

클라이언트가 성공적으로 연결을 설정하면, conn_trace_id 필드가 연결 로그와 액세스 로그를 연결합니다.

• SSL/TLS 협상 오류가 발생하면 ALB 연결 로그와 ALB 액세스 로그의 conn_trace_id를 비교하십시오.
• ALB 연결 로그는 존재하지만 ALB 액세스 로그에 해당 항목이 없는 경우, 이는 유효한 요청이 처리되기 처리되기 전에 핸드셰이크가 실패했음을 나타냅니다.

Conclusion & Recommendations

• 클라이언트의 TLS 구성이 ALB의 보안 정책과 호환되는지 확인합니다.
• 자세한 협상 실패를 파악하기 위해 ALB 연결 로그를 활성화합니다.
• OpenSSL 또는 패킷 캡처 도구를 사용하여 클라이언트 측 문제를 진단합니다.
• VPC 흐름 로그와 ALB 액세스 로그를 비교하여 클라이언트가 ALB에 도달했지만 연결 설정에 실패했는지 확인하세요.

이러한 단계들을 따르면, SSL/TLS 협상 오류의 원인을 파악하고 영향을 받은 클라이언트 IP를 효과적으로 식별할 수 있습니다.

Related Information

[1] CloudWatch metrics for your Application Load Balancer - Application Load Balancer metrics
[2] Connection logs for your Application Load Balancer - Error reason codes
[3] Security policies for your Application Load Balancer
[4] re:Post - How do I identify and resolve client connection issues when I use mTLS with the Application Load Balancer?
[5] re:Post - How do I troubleshoot client SSL/TLS negotiation errors when I connect to an Application Load Balancer that uses HTTPS?
[6] re:Post - Why do I get a client SSL/TLS negotiation error when I try to connect to my load balancer?