TLS : Client Hello 단계에서 ciphersuite와 version 교환

TLS 연결 단계 중 client hello를 살펴 본다.

TLS연결은 Client Hello로부터 시작이 되고,

client는 자신이 사용할 수 있는 가장 높은 protocol 버전과 ciphersuite 리스트를 전송한다.

아래는 이와 관련 된 wireshark의 일부 내용(Client Hello)이다.

server는 client hello 메시지로부터 protocol을 선택(높은 것 부터 확인해서 서버에서 사용 가능한)하고

ciphersuite도 선택하게 된다. (선택하는 알고리듬 방식은 다양한 듯)

아래는 이와 관련 된 wireshark의 일부 내용(Sever Hello)이다.

정상적인 선택이 되지 않으면 연결을 종료하며, client는 TLS connect failed를 전달 받게 된다.

답답한 것은 복잡한 네트워크 환경에서 server로 접속이 안되면 정확히 어떠한 이유로 3 handshake가 실패했는지 알 수 없다는 점이다.

 - client는 FIN, ACK만 받고 종료가 되며, 이것을 TLS connect failed로 명시한다.

 - 사실 정확한 디버깅을 위해서는 server에서 직접 TLS 오류 메시지를 확인해야 한다.

관련해서 재미있는 이슈가 있었다.

TLS 테스트를 위해 아래 명령어를 수행하면 3 handshake가 실패했다.

# openssl s_client -starttls smtp -crlf -connect example.com:25 

하지만 아래 명령어는 성공했다.

# openssl s_client -starttls smtp -crlf -connect example.com:25 -cipher 'RC4-MD5'

이상한 점은 위에서 언급 된 내용을 기반으로 보면 첫 번째 예시는 모든 ciphersuite를 전송했을 텐데 연결(3 handshake)이 안되고, 두 번째는 케이스는 정상적으로 연결(3 handshake)이 된다는 것이다.

여기서 한 가지 알 수 있었던 점은 전송되는 ciphersuite의 순서(order)도 무시할 수 없다는 것이다.

example.com이 Windows 2003이라면 아래와 같은 이슈가 존재한다.

Windows 2003 TLS 64 ciphersuite limit

The Windows 2003 TLS stack (still used by a non-trivial number of

Microsoft Exchange SMTP servers) only looks at the first 64 elements

of the cipherlist.  If neither RC4-SHA nor RC4-MD5 are among these,

it sometimes chooses 3DES (for which it misimplements CBC padding)

and fails during data transfer, or if that is suppressed or also

too far down the list, just fails the handshake.

의역하면 윈도우 2003은 client hello 메시지 ciphersuite의 앞 쪽 64개만 확인하고 종료한다는 것.

위 테스트 첫 번째 케이스는 아이러니하게도 64번째 안에 들지 못했다.

두 번째 케이스는 cipher를 지정 한 것이니 당연히 64번째 안에 들었다.

OpenSSL의 버전이 올라가면서 보안 등급이 낮다는 이유로 버려지는 cipher(SSLv2 따위)가 많지만,

반대로 강화 되어 추가되는 cipher도 많다. 그리하여 client hello에 전달되는 ciphersuite의 개수도 많아지게 되고,

아직 구형(Win 2003같은)으로 운영중인 서버도 많은 상황에.. 위 이슈는 항상 인지하고 있어야겠다.