Problemas de SSL con S3/AWS con la API de Java: "el nombre de host en el certificado no coincide"

Question

Amazon "actualizó" la seguridad de SSL en su AWS Java SDK en la versión 1.3.21. Esto rompió el acceso a cualquier segmento S3 que tenga períodos en su nombre cuando se usa la API Java AWS de Amazon. Estoy usando la versión 1.3.21.1 que está vigente hasta el 5/Oct/2012. He proporcionado algunas soluciones en mi respuesta a continuación, pero estoy buscando soluciones adicionales a este problema.

Si obtiene este error, verá algo como el siguiente mensaje en sus excepciones/registros. En este ejemplo, el nombre del cubo es foo.example.com.

INFO: Unable to execute HTTP request: hostname in certificate didn't match: 
     <foo.example.com.s3.amazonaws.com> != <*.s3.amazonaws.com> 
     OR <*.s3.amazonaws.com> OR <s3.amazonaws.com> 
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:220) 
at org.apache.http.conn.ssl.StrictHostnameVerifier.verify(StrictHostnameVerifier.java:61) 
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:149) 
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:130) 
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:390) 

Se puede ver la documentación de este problema en el foro de discusión AWS S3:

https://forums.aws.amazon.com/thread.jspa?messageID=387508&#387508

respuesta de Amazon para el problema es el siguiente.

Deberíamos poder solucionarlo utilizando el método de estilo de ruta anterior de direccionamiento de grupos (en lugar del direccionamiento de estilo de host virtual más nuevo) para los depósitos con este patrón de nombres. Empezaremos con la corrección y aseguraremos que nuestras pruebas de integración interna tengan casos de prueba para nombres de depósitos que contengan puntos.

¿Alguna solución alternativa u otras soluciones? Gracias por cualquier comentario.

Answer 1

Amazon lanzó la versión 1.3.22 que resuelve este problema. Verifiqué que nuestro código ahora funciona. Para citar sus notas de la versión:

Ahora se pueden volver a tratar correctamente los espacios cuyo nombre contenga puntos a través de HTTPS.

Hay un par de soluciones que puedo ver, además de esperar a que Amazon publique una nueva API.

1. Obviamente, podría retroceder a la versión 1.3.20 del AWS Java SDK. Lamentablemente, necesitaba algunas de las características en 1.3.21.

2. Puede reemplazar el org.apache.http.conn.ssl.StrictHostnameVerifier en el classpath. Este es un truco , sin embargo, que eliminará todas las comprobaciones SSL de las conexiones http de Apache, creo. Aquí está el código que funcionó para mí: http://pastebin.com/bvFELdJE

3. Terminé descargando y construyendo mi propio paquete desde el contenedor fuente de AWS. Apliqué el siguiente parche aproximado a la fuente HttpClientFactory.

   =================================================================== 
   --- src/main/java/com/amazonaws/http/HttpClientFactory.java  (thirdparty/aws)  (revision 20105) 
   +++ src/main/java/com/amazonaws/http/HttpClientFactory.java  (thirdparty/aws) (working copy) 
   @@ -93,7 +93,7 @@ 
   
            SSLSocketFactory sf = new SSLSocketFactory(
              SSLContext.getDefault(), 
   -        SSLSocketFactory.STRICT_HOSTNAME_VERIFIER); 
   +        SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER); 
   

4. La solución correcta es cambiar a partir de nombres de dominio de manipulación para el manejo basado camino cubo.

Por cierto, la siguiente parece que podría funcionar, pero no lo hace .El cliente solicita específicamente AWS el verificador STRICT y no utiliza la opción por defecto:

SSLSocketFactory.getSystemSocketFactory().setHostnameVerifier(
    SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER); 

Answer 2

Resulta que Amazon "mejorado" la seguridad SSL en S3 a finales de septiembre de 2012. Esto rompió el acceso a cualquier cubos S3 que tienen períodos en su nombre cuando se utiliza la API de AWS Java de Amazon.

Esto es incorrecto. La coincidencia de comodines SSL de S3 ha sido la misma que cuando se lanzó S3 en 2006. Lo más probable es que el equipo AWS Java SDK haya habilitado una validación más estricta de los certificados SSL (buena), pero terminó rompiendo nombres compartidos que han estado en conflicto con el SSL de S3 cert (malo).

La respuesta correcta es que es necesario utilizar ruta de estilo abordar en lugar de de estilo DNS direccionamiento. Esa es la única forma segura de de resolver el problema con la coincidencia de comodines en el certificado SSL. Al deshabilitar la verificación, se abre hasta Ataques Man-In-The-Middle.

Lo que no sé actualmente es si el Java SDK proporciona esto como una opción configurable. Si es así, esa es tu respuesta. De lo contrario, parece que el equipo de Java SDK dijo "agregaremos esta característica y luego agregaremos pruebas de integración para asegurarnos de que todo funcione".