HTTPS를 사용하여 Application Load Balancer에 연결할 때 클라이언트 SSL/TLS 협상 오류를 해결하려면 어떻게 해야 하나요?
HTTPS를 사용하여 Application Load Balancer에 연결할 때 발생하는 클라이언트 SSL/TLS(Secure Socket Layer/Transport Layer Security) 협상 오류를 해결하고 싶습니다.
간략한 설명
조정 오류는 클라이언트 TLS가 Application Load Balancer와 SSL 세션을 수립할 수 없을 때 발생합니다. 로드 밸런서의 보안 정책이 연결하는 클라이언트의 보안 프로토콜 또는 암호 집합을 지원하지 않기 때문에 이 오류가 발생합니다. 이 오류로 인해 clientTLSnegotiationErrorCount 지표가 증가합니다.
보안 연결을 설정하려면 클라이언트의 초기 SSL/TLS 핸드셰이크가 다음 요구 사항을 충족하는지 확인하십시오.
- Application Load Balancer의 보안 정책에서 지원하는 하나 이상의 암호 집합과 일치합니다.
- Application Load Balancer의 보안 정책에 지정된 SSL/TLS 프로토콜 버전이 있습니다.
해결 방법
ClientTLSNegotiationErrorCount 지표가 증가한 기간 동안 Application Load Balancer의 연결 로그를 검토합니다. 로그에는 클라이언트가 Application Load Balancer에 제공한 보안 프로토콜과 암호가 표시됩니다.
참고: 연결 로그가 활성화되었는지 확인하십시오. 또는 연결에 실패한 클라이언트에 액세스할 수 있는 경우 패킷을 캡처한 다음 Client Hello 패킷을 검토하십시오. 패킷 캡처 테스트에 관한 자세한 내용은 VPC의 EC2 Linux 또는 Windows 인스턴스와 인터넷 게이트웨이를 통한 온프레미스 호스트 간의 네트워크 성능 문제를 해결하려면 어떻게 해야 합니까?를 참조하십시오.
로드 밸런서의 보안 정책에서 지원하는 프로토콜 및 암호를 확인합니다.
Application Load Balancer는 사용자 지정 보안 정책을 지원하지 않습니다. 기본 보안 정책을 포함한 보안 정책에 대한 자세한 내용은 Application Load Balancer 보안 정책을 참조하십시오.
다음 두 가지 방법으로 Application Load Balancer에 연결된 보안 정책을 검토할 수 있습니다.
- Amazon Elastic Compute Cloud(Amazon EC2) 콘솔을 사용합니다.
- AWS Command Line Interface(AWS CLI) 및 describe-listeners 명령을 사용합니다.
참고: AWS CLI 섹션에서는 설정이 다음 사전 요구 사항을 충족한다고 가정합니다.
- AWS CLI는 Elastic Load Balancing Service에 대해 설명할 수 있는 적절한 IAM 권한이 있는 사용자로 구성됩니다.
- AWS Command Line Interface(AWS CLI) 명령 실행 시 오류가 발생하는 경우, AWS CLI 오류 문제 해결을 참고하십시오. 또한 최신 AWS CLI 버전을 사용하고 있는지 확인하십시오.
Amazon EC2 콘솔에서
보안 정책을 검토하려면 다음 단계를 완료하십시오.
- Amazon EC2 콘솔을 엽니다.
- 탐색 창의 로드 밸런싱에서 로드 밸런서를 선택합니다.
- 원하는 Application Load Balancer를 선택합니다. 그런 다음 리스너 및 규칙을 선택합니다.
- 표에서 보안 정책 열을 확장합니다. 지원되는 보안 프로토콜 및 암호 집합을 검토합니다.
AWS CLI에서
보안 정책을 검토하려면 다음 명령을 실행합니다.
-
Application Load Balancer의 Amazon 리소스 이름(ARN) 을 찾으려면 describe-load-balancers 명령을 실행합니다.
aws elbv2 describe-load-balancers --region your_region | grep 'LoadBalancerName\|LoadBalancerArn' -
Application Load Balancer의 보안 정책을 찾으려면 describe-listeners 명령을 실행합니다.
aws elbv2 describe-listeners --region your_region --load-balancer-arn your_loadbalancer_arn | grep 'SslPolicy'참고: your_region을 해당 리소스를 포함하는 리전으로 바꿉니다. your_loadbalancer_arn을 로드 밸런서의 ARN으로 바꿉니다.
연결 로그를 사용하여 클라이언트가 제공하는 보안 프로토콜 및 암호 집합을 결정합니다.
Amazon Simple Storage Service(Amazon S3) 콘솔을 사용하여 연결 로그의 압축을 풀고 연결 로그의 정보를 표시합니다. 그런 다음 추가 검토를 위해 파일을 다운로드합니다.
참고: bash 도구 zcat, awk 및 sed를 사용하여 연결 로그를 처리합니다.
bash 도구 awk는 로그 내에서 다음 필드 번호 또는 값을 구문 분석합니다.
($1) timestamp ($2) client_ip ($3) client_port ($4) listener_port ($5) tls_protocol ($6) tls_cipher ($7) tls_handshake_latency ($8) leaf_client_cert_subject ($9) leaf_client_cert_validity ($10) leaf_client_cert_serial_number ($11) tls_verify_status
다음 섹션에서는 연결 로그 처리에 사용할 수 있는 다양한 방법을 설명합니다.
연결 로그에 포함된 기간 식별
참고: 로그된 시간 값은 UTC로 표시됩니다.
zcat *.log.gz | gawk '{print substr($1,0,16)}'| sort | uniq | sed '1p;$!d' 2024-03-30T18:14 2024-03-30T19:04
**연결 로그에 있는 오류 식별 또는 비교 **
참고: tls_verify_status 필드는 주로 mTLS 연결에 사용됩니다. 하지만 필드를 사용하여 하나 이상의 프로토콜 또는 암호 집합 간의 불일치로 인해 실패한 TLS 연결 시도를 표시할 수 있습니다.
zcat *.log.gz | gawk '{print $11}' | sort | uniq -c | sort -r 1354 Failed:UnmappedConnectionError 176 Success
연결 오류가 가장 많이 발생하는 고유 클라이언트 식별
zcat *.log.gz | gawk '$11 ~ "Failed"' | gawk '{print $2}' | sort | uniq -c | sort -r 440 a.a.a.a 436 b.b.b.b 386 c.c.c.c 90 d.d.d.d 1 e.e.e.e 1 f.f.f.f
클라이언트가 사용하는 암호 집합 및 프로토콜 식별
프로토콜, 암호 집합 및 결과적 오류를 기록해 둡니다.
zcat *.log.gz | gawk '($11 ~ "Failed" && $6 != "-")' | gawk '{print $2,$5,$6,$11}' | sort | uniq -c | sort -r 40 a.a.a.a TLSv1.2 ECDHE-RSA-AES256-SHA Failed:UnmappedConnectionError 30 b.b.b.b TLSv1.2 ECDHE-RSA-AES256-SHA Failed:UnmappedConnectionError 15 c.c.c.c TLSv1.2 ECDHE-RSA-AES256-SHA Failed:UnmappedConnectionError 2 d.d.d.d TLSv1.2 ECDHE-RSA-AES256-SHA Failed:UnmappedConnectionError 2 e.e.e.e TLSv1.2 ECDHE-RSA-AES256-SHA Failed:UnmappedConnectionError 1 f.f.f.f TLSv1.2 ECDHE-RSA-AES256-SHA Failed:UnmappedConnectionError
패킷 캡처를 사용하여 클라이언트가 제공하는 보안 프로토콜 및 암호 집합을 결정합니다.
연결을 시작한 클라이언트에서 패킷을 캡처한 후 Application Load Balancer로 전송된 Client Hello 패킷을 검토합니다.
패킷 캡처에 Tshark 사용
참고: Tshark (터미널) 대신 Wireshark(GUI) 를 사용하여 패킷 캡처를 분석할 수도 있습니다.
Tshark 예시에서는 다음 정보를 사용합니다.
- 클라이언트 IP 주소: 192.168.150.100
- Application Load Balancer IP 주소: 10.10.10.10
- 대상 포트: 443
다음 단계를 완료합니다.
참고: your_file.pcapng를 파일 이름으로 바꿉니다.
-
클라이언트와 Application Load Balancer의 IP 주소 간 통신의 모든 패킷을 찾으려면 다음 명령을 실행합니다.
tshark -r your_file.pcapng '(ip.addr == 10.10.10.10 && tcp.port == 443)' 69 1.428028 192.168.150.100 → 10.10.10.10 TCP 66 61747 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1 70 1.481769 10.10.10.10 → 192.168.150.100 TCP 66 443 → 61747 [SYN, ACK] Seq=0 Ack=1 Win=26883 Len=0 MSS=1460 SACK_PERM=1 WS=256 71 1.481905 192.168.150.100 → 10.10.10.10 TCP 54 61747 → 443 [ACK] Seq=1 Ack=1 Win=131328 Len=0 72 1.490709 192.168.150.100 → 10.10.10.10 TLSv1 244 Client Hello 74 1.541926 10.10.10.10 → 192.168.150.100 TCP 56 443 → 61747 [ACK] Seq=1 Ack=191 Win=28160 Len=0 75 1.541926 10.10.10.10 → 192.168.150.100 TCP 56 [TCP Dup ACK 74#1] 443 → 61747 [ACK] Seq=1 Ack=191 Win=28160 Len=0 76 1.541926 10.10.10.10 → 192.168.150.100 TLSv1.2 61 Alert (Level: Warning, Description: Close Notify) 77 1.541926 10.10.10.10 → 192.168.150.100 TCP 56 443 → 61747 [FIN, ACK] Seq=8 Ack=191 Win=28160 Len=0 78 1.542087 192.168.150.100 → 10.10.10.10 TCP 54 61747 → 443 [ACK] Seq=191 Ack=9 Win=131328 Len=0 79 1.543501 192.168.150.100 → 10.10.10.10 TCP 54 61747 → 443 [FIN, ACK] Seq=191 Ack=9 Win=131328 Len=0 95 1.614454 10.10.10.10 → 192.168.150.100 TCP 56 443 → 61747 [ACK] Seq=9 Ack=192 Win=28160 Len앞의 출력에는 다음 정보가 표시됩니다.
클라이언트(192.168.15.100)는 Application Load Balancer(10.10.10.10)와의 연결을 시작합니다.
초기 TCP 핸드셰이크(SYN, SYN-ACK, ACK) 직후 Application Load Balancer의 ACK(패킷 72) 다음에 Client Hello가 표시됩니다.
그런 다음 Application Load Balancer에서 세션이 종료되어야 함을 알리기 위해 Close Notify를 전송합니다(패킷 76). -
Client Hello 패킷에 사용되는 SSL/TLS 프로토콜 및 암호 집합을 찾습니다. 이러한 패킷은 클라이언트 IP 주소(192.168.15.100) 와 로드 밸런서의 IP 주소(10.10.10.10) 간 통신에 사용됩니다.
통신에 대한 Client Hello 패킷(tls.handshake.type == 1)을 자체 PCAP 파일로 이동하려면 다음 명령을 실행합니다.
tshark -r your_file.pcapng -O -P -w ALB_Sessions.pcap '(ip.addr == 10.10.10.10 && tcp.port == 443) && (tls.handshake.type==1)' -
ALB_Sessions.pcap 파일에서 텍스트 파일로 암호 집합을 이동하려면 다음 명령을 실행합니다.
tshark -r ALB_Sessions.pcap -Y ssl.handshake.ciphersuites -Vx > TLS_outfile.txt -
파일을 연결하고 grep을 사용하여 Version: 필드를 검색하려면 다음 명령을 실행합니다. Client Hello 패킷에 사용된 TLS 버전을 검토합니다.
cat TLS_outfile.txt | grep "Version:" 0100 .... = Version: 4 Version: TLS 1.0 (0x0301) Version: TLS 1.2 (0x0303) -
파일을 연결하고 grep을 사용하여 Cipher Suite: 필드를 검색하려면 다음 연결을 사용합니다. Client Hello 패킷에 사용된 암호 집합을 검토합니다.
cat TLS_outfile.txt | grep "Cipher Suite:" Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) -
16진수 값을 원본 파일과 비교하려면 다음 명령을 실행합니다.
tshark -r your_file.pcapng -T fields -Y '(tls.handshake.type==1 && ip.addr == 10.10.10.10)' -e tls.handshake.version -e tls.handshake.ciphersuite 0x0303 0xc014,0x00ff명령은 file.pcapng 파일을 읽고 Application Load Balancer의 IP 주소(10.10.10.10)로 전송된 Client Hello 패킷에 대해 구문 분석합니다. 그런 다음 명령은 tls.handshake.version 및 tls.handshake.ciphersuites를 개별적인 열로 출력합니다. 출력을 비교하여 이 값이 TLS_outfile.txt 파일에 나타난 16진수 값인지 확인합니다.
패킷 캡처 분석
이 예에서 클라이언트가 제공한 유일한 암호 제품군은 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA였습니다. 이 정보는 IANA 이름 지정 스키마를 따르지만 Application Load Balancer는 OpenSSL 이름 지정 스키마를 사용합니다.
**참고:**이 표를 사용하여 IANA를 OpenSSL 명명 스키마로 변환할 수 있습니다. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA는 ECDHE-RSA-AES256-SHA와 같습니다.
로드 밸런서 보안 정책 업데이트
클라이언트가 지원하는 프로토콜 또는 암호를 수용하려면 다음 작업을 수행하십시오.
- Amazon EC2 콘솔을 엽니다.
- 탐색 창에서 로드 밸런서를 선택합니다.
- 로드 밸런서를 선택합니다.
- 리스너 및 규칙 탭에서 Protocol:Port 열의 텍스트를 선택하여 리스너의 세부 정보 페이지를 엽니다.
- 세부 정보 페이지에서 작업을 선택한 다음 리스너 편집을 선택합니다.
- 보안 리스너 설정 섹션의 보안 정책에서 새 보안 정책을 선택합니다.
- 변경 사항 저장을 선택합니다.
클라이언트의 지원되는 보안 프로토콜 및 암호 집합 업데이트
클라이언트가 지원하는 보안 프로토콜 및 암호 집합을 업데이트하려면 요청을 보내는 디바이스의 운영 체제 설명서를 참조하십시오.
관련 정보
HTTP를 통해 Application Load Balancer에 연결할 때 발생하는 연결 오류 문제를 해결하려면 어떻게 해야 합니까?
Application Load Balancer에서 mTL을 사용할 때 클라이언트 연결 문제를 식별하고 해결하려면 어떻게 해야 합니까?
관련 콘텐츠
- AWS 공식업데이트됨 3달 전
- AWS 공식업데이트됨 일 년 전
- AWS 공식업데이트됨 3년 전
