TLS/SSL 악수는 상대적으로 복잡한 과정으로 아리운 환경에서 제품, 안전 등 특성을 결합하면 TLS/SSL 악수 과정의 불확실성을 더욱 높일 수 있다.본고는 각종 악수가 실패한 장면을 총결하고자 한다.

한 번의 TLS/SSL 악수 과정

본고는 TLS/SSL 기초 지식을 상세하게 소개하지 않으며, 관련 소개는 문장을 참고할 수 있습니다.다음 세 장의 그림에서는 세 가지 TLS/SSL 악수의 전 과정을 설명합니다.
서버 검증의 완전 악수(Full Handshake with Mutual Authentication)는 인터넷의 대부분 HTTPS 데이터에 사용되는 검증 모델이다.인증서가 서버에 있고 클라이언트는 인증서를 통해 서버가 신뢰할 수 있는지 확인합니다.
양방향 검증을 위한 완벽한 악수(Full Handshake with Server Authentication)
이것은 클라이언트의 안전성에 대한 요구가 있는 검증 모델이다.클라이언트가 서버를 검증해야 하는 것 외에 서버가 클라이언트에 대해서도 검증을 해야 하기 때문에 양방향 검증이 필요하다.위의 절차에 비해 클라이언트가 서버에 인증서를 전송하는 과정이 많다.
간단한 악수(Abbreviated Handshake)
완전한 악수는 2개의 RTT가 필요하고 많은 정보를 상호작용해야 한다. 회화 복용 장면에서 악수를 1개의 RTT로 간소화할 수 있다.절차는 다음과 같습니다.

일반 TLS/SSL 악수 실패

TLS/SSL 버전 불일치

TLS 1.2 버전이 2008년에 발표된 이래로 대부분의 HTTPS 데이터는 TLS 1.2에 달려 있다.서버는 보안을 고려하여 일반적으로 비교적 높은 버전의 TLS만 지원합니다. 예를 들어 TLS1.0 이상만 지원합니다.그러나 일부 버전이 비교적 오래된 운영체제와 브라우저가 존재한다. 만약 이 클라이언트들이 낮은 버전의 TLS/SSL로 서버에 악수를 한다면 서버가 지원하지 않기 때문에 직접 실패할 것이다.
예를 들어 타오바오 네트워크는 TLS 1.0 및 상기 버전만 지원하고 Openssl로 SSL 3 버전의 악수를 시작하면handshake failure가 나타납니다.

# openssl s_client -connect www.taobao.com:443 -ssl3 -msg
CONNECTED(00000003)
>>> ??? [length 0005]
    16 03 00 00 8f
>>> SSL 3.0 Handshake [length 008f], ClientHello
    01 00 00 8b 03 00 2a a0 d3 c5 10 b0 0a c0 0b ea
    fc e7 49 8f d1 66 cd 2a 51 c1 ab f4 ab b7 63 e1
    a7 3e e0 d7 14 9b 00 00 64 c0 14 c0 0a 00 39 00
    38 00 37 00 36 00 88 00 87 00 86 00 85 c0 0f c0
    05 00 35 00 84 c0 13 c0 09 00 33 00 32 00 31 00
    30 00 9a 00 99 00 98 00 97 00 45 00 44 00 43 00
    42 c0 0e c0 04 00 2f 00 96 00 41 c0 12 c0 08 00
    16 00 13 00 10 00 0d c0 0d c0 03 00 0a 00 07 c0
    11 c0 07 c0 0c c0 02 00 05 00 04 00 ff 01 00
<<< ??? [length 0005]
    15 03 00 00 02
<<< SSL 3.0 Alert [length 0002], fatal handshake_failure
    02 28
140191222585232:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1493:SSL alert number 40
140191222585232:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:659:
---
no peer certificate available
---
No client certificate CA names sent

TLS/SSL cipher suite 불일치

악수하는 두 개의 클라이언트 헬로와 서버 헬로 가방 중 중요한 임무는 cipher를 협상하는 것이다.클라이언트는 ClientHello에서 지원하는 모든 cipher suite를 가져옵니다. 서버는 ClientHello의 cipher suite를 받은 후 자신이 지원하는 cipher suite와 일일이 일치하며 일치하는 것이 없으면 악수에 실패합니다.
서버는 안전성을 고려하여 일반적으로 안전성이 높은 cipher만 지원하기 때문에 클라이언트가 보낸 ciphersuite의 안전성이 비교적 낮을 때 악수에 실패할 수 있습니다.
예를 들어 Openssl로 타오바오망에 악수를 하면 클라이언트의 ClientHello 중 안전성이 낮은 DHE-RSA-AES128-SHA256cipher만 있고 handshakefailure가 나타납니다.

# openssl s_client -connect www.taobao.com:443 -cipher DHE-RSA-AES128-SHA256 -msg
CONNECTED(00000003)
>>> TLS 1.2  [length 0005]
    16 03 01 00 5e
>>> TLS 1.2 Handshake [length 005e], ClientHello
    01 00 00 5a 03 03 4a d3 f5 53 f0 f3 e2 8f a8 a3
    4a 26 81 91 84 fb fd cf 80 13 21 c6 42 d3 c4 2b
    a7 70 de 4c e0 48 00 00 04 00 67 00 ff 01 00 00
    2d 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02 06
    03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03
    02 03 03 02 01 02 02 02 03 00 0f 00 01 01
<<< TLS 1.2  [length 0005]
    15 03 03 00 02
<<< TLS 1.2 Alert [length 0002], fatal handshake_failure
    02 28
139737777813392:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent

TLS/SSL 악수 Warning

악수 과정에서 클라이언트가 서버 인증서를 검증하고 검증이 유행하지 않으면 Warning이 나타납니다.브라우저는 무시를 선택할 수 있으며,curl을 사용하거나 -k 파라미터를 사용하여 무시할 수 있습니다.엄밀히 말하면 Failure는 아니다. 여기는 Warning으로 분류되어 상세한 토론을 하지 않는다.예를 들어 다음과 같은 몇 가지 비교적 흔히 볼 수 있는 상황:

액세스한 도메인 이름은 서버 인증서의 CN(Common Name) 및 SAN(Subject Alternative Name)에 없습니다

서버 인증서가 취소되어 인증이 통과되지 않았습니다

로컬 시스템의 시간이 정확하지 않기 때문에 인증서의 유효기간을 검증할 때 오판이 발생한다

클라우드 방패로 인해 TLS/SSL 악수 실패

아리운에 들어가는 유량은 구름방패를 통과하는데 다른 안전 설비와 유사하며 구름방패는 유량 특징에 따라 일정한 동작을 취한다.

현상

다음은 하나의 예이다.클라이언트가 아리운의 공용 네트워크 IP 주소인 TLS/SSL에 액세스하여 악수하지 못했습니다.클라이언트의 클러치에는 다음과 같은 현상이 표시됩니다.
앞의 TCP는 세 번의 악수와 일부 데이터 상호작용(특정 프로토콜과 관련이 있으며, 정상적인 상황은 TCP가 세 번의 악수를 한 후에 TLS/SSL 악수를 직접 시작하는 것)을 볼 수 있습니다.그러나 TLS/SSL 악수 상호작용 프로세스를 시작하자 클라이언트가 첫 번째 메시지를 보냈고 바로 TCP RESET를 받았다.이것은 위에서 언급한 일반적인 악수 실패와 매우 다르다. TCP RESET 메시지는 보통 장치나 호스트 프로토콜 창고에서 자발적으로 발송되고 일정한 장면에 부합되거나 일정한 네트워크 관리의 의미가 있다.

근본 원인

구름방패는 방문한 목적의 도메인 이름에 따라 관련 동작을 실행합니다.클라우드 방패는 TCP가 연결될 때 원본 IP 차단을 하지 않고 클라이언트 헬로의 SNI(Servername Indication) 도메인 이름 정보를 추출하여 등록 여부를 판단하여 차단을 하고 TCP RESET로 돌아갑니다.
SNI는 클라이언트 Hello의 확장 필드로 액세스할 대상 도메인 이름이 있으며 동일한 IP에서 여러 HTTPS 사이트를 호스팅하는 서버에서 클라이언트가 액세스하는 대상 도메인 이름을 알 수 있도록 하여 해당 인증서를 사용하여 상호작용을 할 수 있습니다.ClientHello 메시지 위치:

클라이언트 인증서 문제로 인해 TLS/SSL 악수 실패

양방향 검증 장면에서 클라이언트가 서버 인증서를 검증해야 할 뿐만 아니라 서버도 클라이언트 인증서를 검증해야 한다.서버가 클라이언트 인증서를 검증하는 과정에서 클라이언트 인증서의 안전성이 낮기 때문에Fatal Alert가 직접 발생하여 악수가 직접 중단될 수 있습니다.

현상

다음은 모바일 앱 액세스 서버의 예입니다.72번 메시지는 Bad Certificate의 Fatal Alert를 보고했습니다. 상하문에서 볼 때 여기는 클라이언트가 서버 측에 Certificate, Client Key Exchange 등의 메시지를 보낸 후 서버가 클라이언트에게 되돌아오는 오류입니다.
모바일 앱에서 다음과 같은 오류가 발생했습니다.
SSL handshake aborted: ssl=0x7c1bbf6e88: Failure in SSL library, usually a protocol error
error:10000412:SSL routines:OPENSSL_internal:SSLV3_ALERT_BAD_CERTIFICATE (external/boringssl/src/ssl/tls_record.cc:592 0x7c6c627e48:0x00000001)

근본 원인

양방향 인증을 할 때 Openssl은 클라이언트 인증서의 안전성이 너무 낮다고 판단하여 TLS/SSL의 악수를 중단합니다.

SNI를 추출하지 못해 TLS/SSL 악수 실패

일부 장면에서는 클라이언트 Hello의 SNI 필드를 가져와 필요한 조건으로 삼아야 한다. 예를 들어 NGINX stream으로 HTTPS 데이터에 대해 4층 에이전트를 할 때.클라이언트 클라이언트 Hello에서 SNI를 휴대하지 않으면 에이전트를 통해 악수를 하는 데 실패할 수 있습니다.

현상

위의 악수 실패와 마찬가지로 클라이언트가 ClientHello를 보낸 후 프록시 서버 FIN에 의해 떨어진다. 유일하게 다른 것은 이곳의 ClientHello가 SNI 필드를 가지고 있지 않다는 것이다.

근본 원인

NGINX stream을 정방향 에이전트로 사용할 때, NGXIN 서버는 클라이언트가 접근하고자 하는 목적의 도메인 이름을 가져와야 합니다.이용ngx_stream_ssl_preread_모듈 모듈은 복호화되지 않은 상태에서 클라이언트 헬로 메시지에서 SNI를 받아야만 에이전트의 정상적인 기능을 실현할 수 있습니다.자세한 내용은 문장을 참고하십시오.

총결산

위에서 많은 악수 실패 장면을 정리했는데 재미있는 현상은 실패의 원인은 각기 다를 수 있지만 가방을 잡는 결과는 대부분 일치한다. 즉, 클라이언트가 보낸 TLS/SSL 악수 가방이 서버 FIN/RST에 의해 떨어진다는 것이다.이런 문제에 대한 조사와 분석에 있어 클러치 분석은 단지 하나의 단서일 뿐이다. 더욱 관건적인 것은 TLS/SSL 악수 전체 과정의 세부 사항과 현재 장면의 네트워크 체인, 예를 들어 체인에 안전 장치, 에이전트가 있는지, 양방향 검증을 사용하는지, Keyless 등을 이해해야 한다.
본문 저자: 회지
원문을 읽다
본고는 운서 지역사회의 오리지널 내용으로 허락 없이 전재할 수 없다.