이전 글에 이어서 Apache 웹 서버와 SSL/TLS 통신을 위한 설정에 대해 분석한 내용을 정리해 보겠다.
문제 상황
이전 글에서 자체 서명 인증서를 신뢰할 수 있도록 설정하는 과정에서 발생했던 문제를 해결했다
- 인증서 발급 시 CN 매핑이 제대로 이루어지지 않아 웹 브라우저에서 보안 경고 문구 발생
- x509 v3 extensions 옵션 사용에 대한 이해 및 적용
- Openssl에 의하면 최소 RootCA-MiddleCA-Server의 구조로 인증서를 사용해야 인증서 검증에 경고가 발생하지 않는다고 함
하지만 개발 중인 서버와 웹 서버 사이의 통신은 여전히 이루어지지 않았다.
TLS 통신 전 인증서 검증에서 문제가 발생했다고 생각했기에 인증서를 분석하고 인증서를 새로 발급했지만 여전히 통신이 이루어지지 않아 패킷부터 확인해 보고 어느 부분까지 통신이 이루어지고 거절되는지 알아보려고 생각했다.
Wireshark로 통신 패킷 확인하기

TLS Handshake과정을 살펴보면 Client 측에서 Hello를 보낸 후 곧바로 Handshake Failure를 반환하고 연결이 종료된다.
TLS Handshake과정은 다음을 참고했다.
https://www.cloudflare.com/ko-kr/learning/ssl/what-happens-in-a-tls-handshake
위 블로그를 참고하면 Client Hello 패킷에 담긴 내용은 다음과 같다.
메시지에는 클라이언트가 지원하는 TLS 버전, 지원되는 암호 제품군, 그리고 "클라이언트 무작위"라고 하는 무작위 바이트 문자열이 포함됩니다.
여기서 직접 웹 서버와 통신하려는 서버에서 설정해 준 것은 두 가지이다
- TLS 버전
- 지원되는 암호 제품군 (Cipher Suites)
이때 내가 놓치고 있었던 것이 Cipher Suites였음을 깨달을 수 있었다
지원되는 Cipher Suites를 매칭이 되게 설정한다

상대가 요청한 Cipher Suites set에 매칭이 되지 않아 TLS HandShake가 성공하지 못했고, 이를 설정해 주었다.
Openssl을 사용하고 있었기 때문에, OpenSSL에서 제공되는 암호 제품군이 무엇인지 먼저 확인했다.

하지만 Client 서버에서 요청으로 들어오는 암호 제품군은 OpenSSL에서 제공되는 암호 제품군이 아니었고 어떻게 처리할지 몰라 Cipher Suite Matching 방식에 대해 알아보았다
TLS 통신 시 Cipher Suite Matching
클라이언트에서 제공한 Cipher Suite를 서버에서 제공하지 못한 경우 Chang Cipher Spec 프로토콜을 통해 공통적으로 사용 가능한 Cipher Suite를 선택하도록 협상과정이 이루어지며, 협상에서 제안한 Cipher Suite 중에서 클라이언트에서 제안한 Cipher Suite와 호환 가능한 것을 선택
- TLS 프로토콜은 클라이언트와 서버가 서로 협상을 통해 공통적으로 사용 가능한 Cipher Suite를 선택
- 서버에서 지원하는 Cipher Suite 중에서 클라이언트에서 제안한 Cipher Suite와 호환 가능한 것을 선택
- 예를 들어, 클라이언트에서 제안한 Cipher Suite가 "TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8"이고, 서버에서 제공하는 Cipher Suite 중에서 호환 가능한 것이 "ECDHE-ECDSA-AES128-GCM-SHA256"이라면, 이 두 Cipher Suite를 이용하여 통신이 이루어질 수 있다

주의할 점
웹 서버에서 제공하는 Cipher Suites를 정의하게 되며
이 Cipher Suites에는 클라이언트에서 제공하는 Cipher Suite가 포함되어 있어야 한다
openssl 라이브러리를 사용하고 있고, 클라이언트에서 제공하는 Cipher Suite가 openssl에서 제공하지 않아 포함하지 않으면 Misatch 에러가 발생

정리
두 서버 간 TLS 통신의 문제점을 제대로 파악하지 못해 인증서부터 TLS 통신 과정까지 처음부터 따라가 보았고, 문서에 나오는 과정대로 통신이 되고 있는지 확인하면서 문제점을 찾을 수 있었다.
내가 의도한 대로 실패하는 부분을 보면서 맞춰나가는 게 과정을 완벽히 이해하는데 도움이 되는 것 같다.
실패하는 테스트 방식이 이렇게도 사용될 수 있는 건가 싶다
이젠 빠르게 인증서와 TLS 통신 서버를 구축할 수 있을 것 같다.
'트러블슈팅' 카테고리의 다른 글
3-cert-chain 인증서 만들기 (0) | 2023.04.18 |
---|---|
Tomcat 재기동 시 에러 (0) | 2023.02.01 |
Spring Security와 CORS 에러 대응 (0) | 2023.01.03 |
Spring Security 환경에서 테스트 통과하는 방법 (0) | 2022.11.24 |
Swagger에서 CORS에러 해결 (0) | 2022.11.13 |