스프링(Java21)에서 DB 연결에 실패한 이유, TLS 협상 실패 원인 파해치기

현재 진행 중인 프로젝트는 Spring Boot 3.x / Java 21 기반으로 운영되고 있으며, 고객사 설비에 있는 레거시 DB(MS-SQL)에 연결을 시도하는 과정에서 문제를 마주했다.

 

문제가 생긴 DB는 애플리케이션의 메인 데이터베이스가 아니라, 시스템의 일부 기능에서 특정 데이터를 조회할 때 일시적으로만 접속하는 외부 설비 DB였다. 

 

 

문제가 되는 코드와 에러 로그는 다음과 같다. 

Connection conn = DriverManager.getConnection(url, props);

 

Caused by: javax.net.ssl.SSLHandshakeException: (protocol_version) The server selected protocol version TLS10 
is not accepted by client preferences [TLS13, TLS12]

"encrypt" 속성이 "true"(으)로 설정되고 "trustServerCertificate" 속성이 "true"(으)로 설정되었지만 
드라이버가 SSL(Secure Sockets Layer) 암호화를 사용하여 SQL Server에 대한 
보안 연결을 설정할 수 없습니다. 오류: (protocol_version) The server selected protocol 
version TLS10 is not accepted by client preferences [TLS13, TLS12]. 
ClientConnectionId:3221cd32-88b8-4f41-96fa-222c5f8081a0

 

 

 

에러 로그를 살펴보면 단순한 JDBC 오류나 계정 문제처럼 보이지 않는다.

"The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]"

서버(MSSQL)는 TLS 1.0을 사용하려고 하는데 클라이언트(Java 21)는 TLS 1.2와 TLS 1.3만 허용한다는 뜻이다.

 

이는 DB와 애플리케이션 간의 TLS Handshake 단계에서 협상이 성립하지 않았다는 의미다.

 

그렇다면 TLS Handshake는 뭐길래, 왜 협상에 실패한걸까?

 

 

 

 

 

 

 

 

 

TLS 핸드셰이크란

TLS(Transport Layer Security) 핸드셰이크는클라이언트와 서버가 안전한 통신을 시작하기 위해 서로 정보를 교환하고 암호화 방식을 합의하는 과정이다.

 

 

즉, 서로

• 어떤 TLS 버전을 사용할지
• 어떤 암호화 알고리즘을 사용할지
• 서버가 신뢰할 수 있는 주체인지
• 어떻게 세션 키를 생성할지

등을 협상하여 암호화된 통신 채널을 만드는 절차다. 핸드셰이크가 성공하면 이후의 데이터(쿼리, 패킷)는 모두 암호화된 상태로 전송되며, 핸드셰이크가 실패하면 연결 자체를 성립시킬 수 없다.이번 문제처럼 클라이언트와 서버가 지원하는 TLS 버전이 다르면 핸드셰이크가 초기 단계에서 바로 중단된다.

 

 

 

TLS 핸드셰이크는 상황에 따라 약간의 변형이 있지만, 가장 일반적인 흐름은 다음과 같다.

 

1. ClientHello

클라이언트(Java 애플리케이션)가 서버(DB)에 보내는 첫 메시지다.
여기에는 다음 정보가 포함된다.

• 클라이언트가 지원하는 TLS 버전 목록 (ex: TLS1.3, TLS1.2)
• 지원하는 암호 제품군
• "클라이언트 무작위" 라고 하는 무작위 바이트 문자열

즉, “내가 사용할 수 있는 TLS 옵션은 이거야. 여기서 하나 골라줘.” 라는 메시지이다.

 

2. ServerHello

서버(MSSQL)가 ClientHello에 대한 응답으로 보내는 메시지다.

포함되는 정보는 다음과 같다.

• 서버가 선택한 TLS 버전
• 서버가 선택한 암호 제품군
• "서버 무작위" 라고 하는 무작위 바이트 문자열

이 메시지는 “그럼 우리 이 방식으로 통신하자.”라는 의미다. 여기서 협상 가능한 공통 버전이 없으므로 협상이 즉시 깨진다.

 

3. 서버 인증 (Certificate)

서버는 SSL/TLS 인증서를 클라이언트에게 전송한다. 클라이언트는 이를 CA(인증서 발급 기관)를 통해 검증한다.

이 과정은 클라이언트가 연결하고 있는 서버가 정말 신뢰할 수 있는 서버인지 확인하기 위함이다. (중간자 공격 방지)

 

 

 

4. 예비 마스터 암호

클라이언트가 "예비 마스터 암호"라고 하는 무작위 바이트 문자열을 하나 더 전송한다. 예비 마스터 암호는 공개 키로 암호화되어 있으며, 서버가 개인 키로만 해독할 수 있다.

 

즉, 서버만 읽을 수 있는 비밀 데이터를 공유하는 과정이다. 

 

 

5. 세션 키 생성

클라이언트와 서버가 모두 클라이언트 무작위, 서버 무작위, 예비 마스터 암호를 이용해 세션 키를 생성한다. 모두 같은 결과가 나와야 한다.

 

이 키는 실제 데이터(쿼리, 패킷)를 암호화하는 데 사용된다.

 

 

6. 준비 완료 메시지 교환

양쪽이 새로 생성된 세션 키로 암호화한 “Finished” 메시지를 주고받는다. 이 메시지가 정상적으로 오가는 순간, 양쪽이 동일한 세션키를 갖고 있음을 확인한다.

 

 

 

7. 이후 모든 통신은 대칭키 암호화로 진행

핸드셰이크가 완료되면 이후의 실제 데이터는 모두 세션키 기반 대칭키 암호화로 통신한다.

 

이제 모든 데이터는 안전하게 오가며, 서버 인증·대칭키 생성 등 초기 절차는 완료된 상태가 된다.

 

 

 

 

 

 

 

 

TLS 디버깅으로 확인한 실패 원인

문제를 정확히 확인하기 위해 JVM TLS 디버깅 옵션을 활성화해 핸드셰이크 메시지를 확인해보았다. 

 

디버깅 로그 중 일부만 가져왔다.

// ClientHello
javax.net.ssl|DEBUG|10|main|2025-11-19 09:54:15.815 KST|ClientHello.java:638|Produced ClientHello handshake message (
"ClientHello": {
  "client version"      : "TLSv1.2",
  "random"              : "7873D62EDDA41CB6A64B675438E25EE74CB13A7913AC9DA352C7A916B25D3917",
  "session id"          : "B03D93EACCCC2B6E05A289013EFFE55C51554EFB4D59683FB35CFABBECD63497",
  "cipher suites"       : "[TLS_AES_256_GCM_SHA384(0x1302), TLS_AES_128_GCM_SHA256(0x1301), TLS_CHACHA20_POLY1305_SHA256(0x1303), TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256(0xCCA9), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256(0xCCA8), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256(0xCCAA), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]",
  "compression methods" : "00",
  "extensions"          : [
    "status_request (5)": {
      "certificate status type": ocsp
      "OCSP status request": {
        "responder_id": <empty>
        "request extensions": {
          <empty>
        }
      }
    },
    "supported_groups (10)": {
      "named groups": [x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]
    },
    "ec_point_formats (11)": {
      "formats": [uncompressed]
    },
    "status_request_v2 (17)": {
      "cert status request": {
        "certificate status type": ocsp_multi
        "OCSP status request": {
          "responder_id": <empty>
          "request extensions": {
            <empty>
          }
        }
      }
    },
    "extended_master_secret (23)": {
      <empty>
    },
    "session_ticket (35)": {
      <empty>
    },
    "signature_algorithms (13)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, ed25519, ed448, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
    },
    "supported_versions (43)": {
      "versions": [TLSv1.3, TLSv1.2]
    },
    "psk_key_exchange_modes (45)": {
      "ke_modes": [psk_dhe_ke]
    },
    "signature_algorithms_cert (50)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_secp521r1_sha512, ed25519, ed448, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
    },
    "key_share (51)": {
      "client_shares": [  
        {
          "named group": x25519
          "key_exchange": {
            0000: DF 98 1D 9F D8 91 B6 D5   20 13 F8 9F FD 3B FC B8  ........ ....;..
            0010: 73 84 08 DF 79 97 19 CC   E2 D8 95 3D C6 D9 8B 5A  s...y......=...Z
          }
        },
        {
          "named group": secp256r1
          "key_exchange": {
            0000: 04 B0 ED F5 A3 CC 3B 83   D1 03 FA 8D FB B7 18 63  ......;........c
            0010: DB 53 99 BE 8C 34 17 7C   4F 20 92 1F 4C A5 EC 2E  .S...4..O ..L...
            0020: 72 DB DA 28 8E 43 16 64   7F AC 76 22 2C 1C 2A 5D  r..(.C.d..v",.*]
            0030: 6F 7C B7 FA 16 B6 2E 6E   86 F1 BD E3 03 7A 98 42  o......n.....z.B
            0040: 35 
          }
        },
      ]
    }
  ]
}
)

// ServerHello
javax.net.ssl|DEBUG|10|main|2025-11-19 09:54:15.818 KST|ServerHello.java:878|Consuming ServerHello handshake message (
"ServerHello": {
  "server version"      : "TLSv1",
  "random"              : "691D1537A4E341DA6FA84374F85AE0B8FE61F53A3D29CAEC73563AAE56062CA2",
  "session id"          : "280A00007D19AC786D99DA77E77B849113DA77011E8BB4FB1973DE5D959F7AC6",
  "cipher suite"        : "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014)",
  "compression methods" : "00",
  "extensions"          : [
    "extended_master_secret (23)": {
      <empty>
    },
    "renegotiation_info (65,281)": {
      "renegotiated connection": [<no renegotiated connection>]
    }
  ]
}
)

 

 

CLIENT HELLO

ClientHello 메시지에는 클라이언트가 “내가 지원하는 TLS 버전은 이거야”라고 알려주는 정보가 포함된다.

로그를 보면 Java 21은 이렇게 말한다.

"supported_versions (43)": {
  "versions": [TLSv1.3, TLSv1.2]
}

 

 

SERVER HELLO

반면 MSSQL 2008의 ServerHello는 MSSQL 2008은 TLS 1.0만 지원한다는 메시지를 응답한다.

"server version" : "TLSv1"

 

 

 

 

 

 

 

 

 

 

해결 방안

서버와 클라이언트 사이에 서로 요구하는 TLS 버전이 다르기 때문에 이것만 맞춰주면 된다. 

 

• 서버 쪽을 올려서(TLS1.2 이상 지원하도록) 맞춰준다.
  • MSSQL 버전 업, OS 패치, TLS 설정 조정 등
  • 보안적으로도 가장 바람직한 해법
• 클라이언트 쪽에서 TLS1.0도 다시 허용해준다.
  • JDK 보안 정책을 완화

 

 

고객사 설비를 업그레이드 할 수는 없는 상황이었기에 임의적으로 클라이언트쪽에서 TLS 1.0을 허용하는 방법을 택했다. 

 

Java 에서는 기본적으로 java.security 파일에 아래와 같은 설정이 들어가있다. 

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, DTLSv1.0, ...

 

 

여기서 TLSv1을 제거했고 컨테이너 기반으로 애플리케이션을 구동하고 있기 때문에 Dockerfile에 아래 명령어를 추가해주었다. 

RUN sed -i 's|^jdk.tls.disabledAlgorithms=.*|jdk.tls.disabledAlgorithms=SSLv3, DTLSv1.0, RC4, DES, MD5withRSA, DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, ECDH|' /opt/java/openjdk/conf/security/java.security

 

이렇게 무사히(?) 고객사의 프레거시DB에 잘 연결할 수 있었다. 

 

 

 

하지만

TLSv1은 이미 취약한 프로토콜로 분류된다고 한다. 이미 여러 각종 가이드라인에 "사용하지 말 것"이라고 권장되고 있다. 

 

 

현재 진행 중인 프로젝트가 배포될 곳은 내부망이기 때문에 상대적으로 안전하기 때문에 이런 선택을 했다. 또한 해당 TLS 1.0 연결은 특정 설비 DB에 접근하는 순간에만 발생하는 일회성 연결이기 때문에 리스크가 비교적 제한적이라고 판단했다.