[java] 치명적 경보 수신 : SSLHandshakeException을 통한 handshake_failure

여러 가지 이유로 핸드 셰이크 실패가 발생했을 수 있습니다.

• 클라이언트와 서버에서 호환되지 않는 암호 스위트를 사용 중입니다. 이를 위해서는 클라이언트가 서버에서 지원하는 암호 제품군을 사용 (또는 활성화)해야합니다.
• 호환되지 않는 SSL 버전이 사용 중입니다 (서버는 TLS v1 만 허용하고 클라이언트는 SSL v3 만 사용할 수 있음). 클라이언트는 SSL / TLS 프로토콜의 호환 가능한 버전을 사용해야합니다.
• 서버 인증서의 불완전한 신뢰 경로. 클라이언트가 서버의 인증서를 신뢰하지 않을 수 있습니다. 일반적으로 더 자세한 오류가 발생하지만 가능합니다. 일반적으로 수정은 서버의 CA 인증서를 클라이언트의 신뢰 저장소로 가져 오는 것입니다.
• 인증서는 다른 도메인에 대해 발급됩니다. 다시 말하지만, 더 자세한 메시지가 나왔을 것입니다. 그러나 이것이 원인 인 경우 여기에 수정 사항을 설명하겠습니다. 이 경우 해결 방법은 서버가 올바른 인증서를 사용하도록 서버를 얻는 것입니다.

기본 장애를 정확히 파악할 수 없으므로 -Djavax.net.debug=allSSL 연결을 디버깅 할 수 있도록 플래그를 설정 하는 것이 좋습니다 . 디버그가 켜져 있으면 핸드 셰이크의 어떤 활동이 실패했는지를 정확히 알 수 있습니다.

최신 정보

현재 사용 가능한 세부 사항을 기반으로, 문제점은 서버에 발행 된 인증서와 루트 CA 사이의 불완전한 인증서 신뢰 경로로 인한 것으로 보입니다. 대부분의 경우 루트 CA의 인증서가 신뢰 저장소에 없기 때문에 인증서 신뢰 경로가 존재하지 않기 때문입니다. 인증서는 본질적으로 클라이언트에 의해 신뢰되지 않습니다. 브라우저는 경고를 표시하여 사용자가이를 무시할 수 있지만 SSL 클라이언트 ( HttpsURLConnection 클래스 또는 Apache HttpComponents Client 와 같은 HTTP 클라이언트 라이브러리와 같은)의 경우도 마찬가지 입니다.

이러한 클라이언트 클래스 / 라이브러리 대부분은 인증서 유효성 검증을 위해 JVM이 사용하는 신뢰 저장소에 의존합니다. 대부분의 경우 이것은 cacertsJRE_HOME / lib / security 디렉토리 의 파일입니다. JVM 시스템 특성을 사용하여 신뢰 저장소의 위치를 ​​지정한 경우 javax.net.ssl.trustStore해당 경로의 저장소는 일반적으로 클라이언트 라이브러리가 사용하는 위치입니다. 확실치 않은 경우 Merchant클래스를 살펴보고 연결에 사용중인 클래스 / 라이브러리를 찾으십시오 .

CA를 발급하는 서버의 인증서를이 신뢰 저장소에 추가하면 문제를 해결해야합니다. 이 목적으로 도구 를 얻는 것에 대한 관련 질문에 대한 내 대답을 참조 할 수 있지만 Java keytool 유틸리티 는이 목적으로 충분합니다.

경고 : 신뢰 저장소는 기본적으로 신뢰하는 모든 CA의 목록입니다. 신뢰할 수없는 CA에 속하지 않는 인증서를 넣은 경우 개인 키를 사용할 수 있으면 해당 엔터티에서 발급 한 인증서가있는 사이트에 대한 SSL / TLS 연결을 해독 할 수 있습니다.

업데이트 # 2 : JSSE 추적의 출력 이해

JVM이 사용하는 키 저장소 및 신뢰 저장소는 일반적으로 다음과 같이 다소 처음에 나열됩니다.

keyStore is :
keyStore type is : jks
keyStore provider is :
init keystore
init keymanager of type SunX509
trustStore is: C:\Java\jdk1.6.0_21\jre\lib\security\cacerts
trustStore type is : jks
trustStore provider is : 

잘못된 신뢰 저장소를 사용하는 경우 서버 인증서를 올바른 인증서로 다시 가져 오거나 나열된 인증서를 사용하도록 서버를 다시 구성해야합니다 (여러 JVM이있는 경우 권장되지 않음). 필요).

신뢰 인증서 목록에 필요한 인증서가 포함되어 있는지 확인하려면 다음과 같이 시작하는 섹션이 있습니다.

adding as trusted cert:
  Subject: CN=blah, O=blah, C=blah
  Issuer:  CN=biggerblah, O=biggerblah, C=biggerblah
  Algorithm: RSA; Serial number: yadda
  Valid from SomeDate until SomeDate

서버의 CA가 주체인지 확인해야합니다.

핸드 셰이크 프로세스에는 몇 가지 중요한 항목이 있습니다 (세부 사항을 이해하려면 SSL을 알아야합니다). 그러나 현재 문제점을 디버깅하기 위해 handshake_failure가 일반적으로 ServerHello에보고되어 있으면 충분합니다.

1. ClientHello

연결이 초기화 될 때 일련의 항목이보고됩니다. SSL / TLS 연결 설정에서 클라이언트가 보낸 첫 번째 메시지는 일반적으로 로그에 다음과 같이보고되는 ClientHello 메시지입니다.

*** ClientHello, TLSv1
RandomCookie:  GMT: 1291302508 bytes = { some byte array }
Session ID:  {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]
Compression Methods:  { 0 }
***

사용 된 암호 제품군에 유의하십시오. 이 동의해야 할 수 있습니다 동일한 규칙이 은행의 라이브러리에 의해 사용될 수를 들어, merchant.properties 파일의 항목으로. 사용 된 규칙이 다르면 암호 스위트가 호환되지 않는 경우 ServerHello가 상태를 표시하므로 걱정할 필요가 없습니다.

2. ServerHello

서버는 ServerHello로 응답하여 연결 설정을 진행할 수 있는지 여부를 나타냅니다. 로그의 항목은 일반적으로 다음 유형입니다.

*** ServerHello, TLSv1
RandomCookie:  GMT: 1291302499 bytes = { some byte array}
Cipher Suite: SSL_RSA_WITH_RC4_128_SHA
Compression Method: 0
***

선택한 암호 스위트에 유의하십시오. 이것은 서버와 클라이언트 모두에서 사용할 수있는 최상의 제품군입니다. 오류가있는 경우 일반적으로 암호 스위트가 지정되지 않습니다. 서버의 인증서 (및 선택적으로 전체 체인)는 서버에 의해 전송되며 다음 항목에서 찾을 수 있습니다.

*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: CN=server, O=server's org, L=server's location, ST =Server's state, C=Server's country
  Signature Algorithm: SHA1withRSA, OID = some identifer

.... the rest of the certificate
***

인증서 확인에 성공하면 다음과 유사한 항목이 표시됩니다.

Found trusted certificate:
[
[
  Version: V1
  Subject: OU=Server's CA, O="Server's CA's company name", C=CA's country
  Signature Algorithm: SHA1withRSA, OID = some identifier

핸드 셰이크는 일반적으로이 단계에서 완료되기 때문에 위 단계 중 하나가 실패하여 handshake_failure가 발생합니다 (실제로는 아니지만 핸드 셰이크의 후속 단계는 일반적으로 핸드 셰이크 실패를 유발하지 않음). 어떤 단계가 실패했는지 파악하고 해당 메시지를 질문에 대한 업데이트로 게시해야합니다 (이미 메시지를 이해하고 해결하기 위해 수행 할 작업을 알고 있지 않은 경우).

답변

java -Dhttps.protocols=TLSv1.2,TLSv1.1,TLSv1 

*** CertificateRequest
Cert Types: RSA
Cert Authorities:
<CN=blah, OU=blah, O=blah, L=blah, ST=blah, C=blah>
<CN=yadda, DC=yadda, DC=yadda>
<CN=moreblah, OU=moreblah, O=moreblah, C=moreblah>
<CN=moreyada, OU=moreyada, O=moreyada, C=moreyada>
... the rest of the request
*** ServerHelloDone

*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: EMAILADDRESS=client's email, CN=client, OU=client's ou, O=client's Org, L=client's location, ST=client's state, C=client's Country
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5
  ... the rest of the certificate
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
... key exchange info 

*** CertificateVerify
... payload of verify check

*** Finished
verify_data:  { 345, ... }

import javax.net.ssl.SSLSocket;
import javax.net.ssl.SSLSocketFactory;
import java.io.*;

import java.util.Arrays;

/** Establish a SSL connection to a host and port, writes a byte and
 * prints the response. See
 * http://confluence.atlassian.com/display/JIRA/Connecting+to+SSL+services
 */
public class SSLRC4Poke {
    public static void main(String[] args) {
        String[] cyphers;
        if (args.length < 2) {
            System.out.println("Usage: "+SSLRC4Poke.class.getName()+" <host> <port> enable");
            System.exit(1);
        }
        try {
            SSLSocketFactory sslsocketfactory = (SSLSocketFactory) SSLSocketFactory.getDefault();
            SSLSocket sslsocket = (SSLSocket) sslsocketfactory.createSocket(args[0], Integer.parseInt(args[1]));

            cyphers = sslsocketfactory.getSupportedCipherSuites();
            if (args.length ==3){
                sslsocket.setEnabledCipherSuites(new String[]{
                    "SSL_DH_anon_EXPORT_WITH_RC4_40_MD5",
                    "SSL_DH_anon_WITH_RC4_128_MD5",
                    "SSL_RSA_EXPORT_WITH_RC4_40_MD5",
                    "SSL_RSA_WITH_RC4_128_MD5",
                    "SSL_RSA_WITH_RC4_128_SHA",
                    "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA",
                    "TLS_ECDHE_RSA_WITH_RC4_128_SHA",
                    "TLS_ECDH_ECDSA_WITH_RC4_128_SHA",
                    "TLS_ECDH_RSA_WITH_RC4_128_SHA",
                    "TLS_ECDH_anon_WITH_RC4_128_SHA",
                    "TLS_KRB5_EXPORT_WITH_RC4_40_MD5",
                    "TLS_KRB5_EXPORT_WITH_RC4_40_SHA",
                    "TLS_KRB5_WITH_RC4_128_MD5",
                    "TLS_KRB5_WITH_RC4_128_SHA"
                });
            }

            InputStream in = sslsocket.getInputStream();
            OutputStream out = sslsocket.getOutputStream();

            // Write a test byte to get a reaction :)
            out.write(1);

            while (in.available() > 0) {
                System.out.print(in.read());
            }
            System.out.println("Successfully connected");

        } catch (Exception exception) {
            exception.printStackTrace();
        }
    }
}