java - unable - Thread-6, RECV TLSv1 ALERT: fatal, handshake_failure

suncertpathbuilderexception unable to find valid certification

Question

lo que está mal con este código, se supone que confía en todos los hosts, pero no es así.

Funciona bien con, por ejemplo, google.com, pero no con un servicio API Gateway que se ejecuta localmente en mi máquina, ¿por qué?

SALIDA DE DEPURACIÓN DE SSL

desencadenar siembra de SecureRandom hecho seeding SecureRandom Ignorar conjunto de cifrado no compatible: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 ... Ignorar conjunto de cifrado no compatible: TLS_RSA_WITH_AES_128_CBC_SHA256 Permitir renegociación insegura: falso Permitir mensajes de hello heredados: true Es el primer apretón de manos: verdadero Es renegociación segura: falso Thread-6, setSoTimeout (0 ) llamado %% No hay sesión de cliente en caché *** ClientHello, TLSv1 RandomCookie: GMT: 1434280256 bytes = {216 ... 40} ID de sesión: {} Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, .... SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV] Compresión Métodos: {0} Extensión elliptic_curves, nombres de curva: {secp256r1 .. secp256k1} Extensión ec_point_formats, formatos: [descomprimido]

Thread-6, WRITE: TLSv1 Handshake, length = 163 Thread-6, READ: TLSv1 Alert, length = 2 Thread-6, RECV TLSv1 ALERT: fatal, handshake_failure Thread-6, llamado closeSocket () Thread-6, excepción de manejo: javax.net.ssl.SSLHandshakeException: **

Recibido alerta fatal: handshake_failure

**

import java.io.InputStreamReader;
import java.io.Reader;
import java.net.URL;
import java.net.URLConnection;
import javax.net.ssl.HostnameVerifier;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSession;
import javax.net.ssl.TrustManager;
import javax.net.ssl.X509TrustManager;
import java.security.cert.X509Certificate;
public class ConnectHttps {
public static void main(String[] args) throws Exception {
/*
* fix for
* Exception in thread "main" javax.net.ssl.SSLHandshakeException:
* sun.security.validator.ValidatorException:
* PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException:
* unable to find valid certification path to requested target
*/
TrustManager[] trustAllCerts = [
[ getAcceptedIssuers: { -> null },
checkClientTrusted: { X509Certificate[] certs, String authType -> },
checkServerTrusted: { X509Certificate[] certs, String authType -> } ] as X509TrustManager
]
SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
// Create all-trusting host name verifier
HostnameVerifier allHostsValid = new HostnameVerifier() {
public boolean verify(String hostname, SSLSession session) {
return true;
}
};
// Install the all-trusting host verifier
HttpsURLConnection.setDefaultHostnameVerifier(allHostsValid);
/*
* end of the fix
*/
//URL url = new URL("https://google.com"); //WORKS
URL url = new URL("https://localhost:8090"); // DOES NOT WORK, WHY?
URLConnection con = url.openConnection();
Reader reader = new InputStreamReader(con.getInputStream());
while (true) {
int ch = reader.read();
if (ch==-1) {
break;
}
System.out.print((char)ch);
}
}
}

Al ejecutar el código que se encuentra aquí, se muestra que TLSv1.2 no está habilitado en el lado del cliente:

Protocolos soportados: 5
SSLv2Hello
SSLv3
TLSv1
TLSv1.1
TLSv1.2

Protocolos habilitados: 2
SSLv3
TLSv1

Answer 1

.. se supone que confía en todos los hosts, pero no ...

.. RECV TLSv1 ALERT: fatal, handshake_failure Thread-6

Una alerta de falla de apretón de manos del servidor no está relacionada con la validación del certificado de los servidores en el cliente y, por lo tanto, no se puede detener al deshabilitar la validación del certificado. Muchas cosas pueden causar una falla de este tipo, como no hay cifras comunes, versión de protocolo no compatible, falta la extensión de SNI (solo se admite a partir de JDK7). Como el servidor emite el error, puede encontrar más detalles sobre el problema en los mensajes de registro de los servidores.

EDITAR: desde los registros del servidor, la causa del problema es visible:

error al manejar la conexión: error de error del protocolo SSL: 1408A0C1: rutinas SSL: SSL3_GET_CLIENT_HELLO: no hay cifrado compartido

Esto significa que no hay un cifrado común entre el cliente y el servidor.

Una causa típica de esto es una configuración incorrecta de los certificados en el servidor. Si no configura ningún certificado, el servidor podría requerir autenticación anónima con cifrados ADH, que generalmente no están habilitados en el lado del cliente. Sugiero que compruebe si puede conectarse con un navegador.

Otra configuración errónea común es deshabilitar todos los cifrados SSLv3 en el servidor en la creencia de que esto es necesario para deshabilitar el protocolo SSL3.0 (no lo es). Esto efectivamente deshabilita todas las cifras excepto algunas nuevas cifras introducidas con TLS 1.2. Los navegadores modernos todavía podrán conectarse, pero los antiguos no. Esta configuración incorrecta se puede ver en este caso (del comentario):

Desde el registro del servidor ,, cifras de interfaz: FIPS:! SSLv3:! ANULL ,,

!SSLv3 desactiva todos los cifrados disponibles para la versión SSL3.0 y superior . De hecho, esto deja solo los cifrados TLS1.2 porque no hay nuevos cifrados con TLS1.0 y TLS1.1. Como el cliente parece ser compatible con TLS1.0, no habrá cifrados compartidos:

... ESCRIBIR: TLSv1 Handshake

El uso de !SSLv3 en los !SSLv3 de cifrado generalmente se debe a una falta de comprensión de la diferencia entre la versión del protocolo y las cifras. Para deshabilitar SSLv3, solo debe configurar el protocolo en consecuencia, pero no las cifras.