Uso de un almacén de claves personalizado con WebSocketClientFactory de Jetty

Tengo un proyecto de Java que se conecta a un servidor CometD a través de un transporte seguro de WebSocket que utiliza un certificado autofirmado. Estoy configurando el WebSocketClientFactory de la siguiente manera:Uso de un almacén de claves personalizado con WebSocketClientFactory de Jetty

wssFactory.getSslContextFactory().setKeyStorePath("/path/to/my/custom.jks"); 
wssFactory.getSslContextFactory().setKeyStorePassword("mypass");

Y luego crear mi BayeuxClient así:

BayeuxClient client = new BayeuxClient(
     "wss://myserver.com/cometd", 
     WebSocketTransport.create(clientOptions, wssFactory));

De hecho, cuando este se carga primero, las cosas parecen estar configurado correctamente:

[DEBUG] 2012-08-07 12:58:05,786 : starting [email protected] 
[DEBUG] 2012-08-07 12:58:05,786 : starting qtp2005556553{8<=0<=0/254,-1} 
[DEBUG] 2012-08-07 12:58:05,788 : STARTED qtp2005556553{8<=7<=8/254,0} 
[DEBUG] 2012-08-07 12:58:05,788 : starting org.eclipse[email protected]50c8c3b8 
[DEBUG] 2012-08-07 12:58:05,795 : STARTED org.eclipse[email protected]50c8c3b8 
[DEBUG] 2012-08-07 12:58:05,795 : Starting Thread[qtp2005556553-33 Selector0,5,main] on [email protected] 
[DEBUG] 2012-08-07 12:58:05,797 : starting [email protected](/Users/apetresc/Downloads/infrastructure.jks,null) 
[INFO ] 2012-08-07 12:58:05,981 : Enabled Protocols [SSLv2Hello, SSLv3, TLSv1] of [SSLv2Hello, SSLv3, TLSv1] 
[DEBUG] 2012-08-07 12:58:05,981 : Enabled Ciphers [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_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, TLS_EMPTY_RENEGOTIATION_INFO_SCSV] of [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_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, TLS_EMPTY_RENEGOTIATION_INFO_SCSV, SSL_RSA_WITH_NULL_MD5, SSL_RSA_WITH_NULL_SHA, SSL_DH_anon_WITH_RC4_128_MD5, TLS_DH_anon_WITH_AES_128_CBC_SHA, TLS_DH_anon_WITH_AES_256_CBC_SHA, SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_WITH_DES_CBC_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, TLS_KRB5_WITH_RC4_128_SHA, TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_MD5, TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5] 
[DEBUG] 2012-08-07 12:58:05,981 : STARTED [email protected](/Users/apetresc/Downloads/infrastructure.jks,/Users/apetresc/Downloads/infrastructure.jks) 
[DEBUG] 2012-08-07 12:58:05,981 : STARTED [email protected]

Y, de hecho, en realidad utilizando el BayeuxClient funciona. Sin embargo, funcionaría incluso si no especificara un almacén de claves en absoluto; simplemente lo trata como un certificado sin firmar. Y, de hecho, que parece ser lo que está sucediendo, a juzgar por los registros de errores me siguen dando cada pocos segundos:

[DEBUG] 2012-08-07 13:20:37,348 : State update: CONNECTED -> CONNECTED 
[DEBUG] 2012-08-07 13:20:37,348 : Connecting, transport [email protected] 
[DEBUG] 2012-08-07 13:20:37,348 : [Session-1, SSL_NULL_WITH_NULL_NULL] [email protected] SSL NOT_HANDSHAKING i/o/u=0/0/0 ishut=false oshut=false {WebSocketClientConnection [email protected] state=START buffer= [email protected] closed=false buffer=-1} NOT_HANDSHAKING filled=0/0 flushed=0/0 
[DEBUG] 2012-08-07 13:20:37,348 : Sending messages [{id=50, connectionType=websocket, channel=/meta/connect, clientId=2u16ol79fcq7hqe1wu52pr0ws4aw}] 
[DEBUG] 2012-08-07 13:20:37,348 : Registering WebSocketExchange {id=50, connectionType=websocket, channel=/meta/connect, clientId=2u16ol79fcq7hqe1wu52pr0ws4aw} 
[DEBUG] 2012-08-07 13:20:37,348 : [Session-1, SSL_NULL_WITH_NULL_NULL] [email protected] SSL NOT_HANDSHAKING i/o/u=0/0/0 ishut=false oshut=false {WebSocketClientConnection [email protected] state=OPCODE buffer= [email protected] closed=false buffer=-1} NOT_HANDSHAKING filled=0/0 flushed=0/0 
[DEBUG] 2012-08-07 13:20:37,348 : Sending messages [{"id":"50","connectionType":"websocket","channel":"/meta/connect","clientId":"2u16ol79fcq7hqe1wu52pr0ws4aw"}] 
[DEBUG] 2012-08-07 13:20:37,348 : [Session-1, SSL_NULL_WITH_NULL_NULL] [email protected] SSL NOT_HANDSHAKING i/o/u=0/0/0 ishut=false oshut=false {WebSocketClientConnection [email protected] state=OPCODE buffer= [email protected] closed=false buffer=116} NOT_HANDSHAKING filled=0/0 flushed=0/0 
[DEBUG] 2012-08-07 13:20:37,349 : [Session-1, SSL_NULL_WITH_NULL_NULL] [email protected] SSL NOT_HANDSHAKING i/o/u=0/0/0 ishut=false oshut=false {WebSocketClientConnection [email protected] state=OPCODE buffer=null [email protected] closed=false buffer=116} NOT_HANDSHAKING filled=0/0 flushed=0/0 
[DEBUG] 2012-08-07 13:20:37,349 : [Session-1, SSL_NULL_WITH_NULL_NULL] wrap OK NOT_HANDSHAKING consumed=116 produced=137 
[DEBUG] 2012-08-07 13:20:37,349 : [Session-1, SSL_NULL_WITH_NULL_NULL] [email protected] SSL NOT_HANDSHAKING i/o/u=0/0/0 ishut=false oshut=false {WebSocketClientConnection [email protected] state=OPCODE buffer=null [email protected] closed=false buffer=0} NOT_HANDSHAKING filled=0/0 flushed=137/0 
[DEBUG] 2012-08-07 13:20:37,349 : [Session-1, SSL_NULL_WITH_NULL_NULL] [email protected] SSL NOT_HANDSHAKING i/o/u=0/0/0 ishut=false oshut=false {WebSocketClientConnection [email protected] state=OPCODE buffer=null [email protected] closed=false buffer=0} NOT_HANDSHAKING filled=0/0 flushed=0/0 
[DEBUG] 2012-08-07 13:20:37,349 : [Session-1, SSL_NULL_WITH_NULL_NULL] handle [email protected] SSL NOT_HANDSHAKING i/o/u=0/0/0 ishut=false oshut=false {WebSocketClientConnection [email protected] state=OPCODE buffer=null [email protected] closed=false buffer=-1} progress=false

Para mí esto implica que el CometD apretón de manos está terminando, pero el SSL apretón de manos no es. Sin embargo, no puedo entender por qué es este el caso; un enfoque análogo funciona para mis llamadas HTTPS. Solo el WSS me está dando dolor de cabeza.

También vale la pena mencionar que puedo reproducir esto en diferentes entornos, incluida una aplicación de Android y desde un contenedor de servlet de Jetty.

¿Alguien ha utilizado con éxito WSS con un certificado autofirmado? ¿Te importa arrojar algo de luz sobre lo que estoy haciendo mal?

Fuente

2012-08-07 Adrian Petrescu

Como resumen, ¿alguien encuentra el código de error 'SSL_NULL_WITH_NULL_NULL' tan hilarantemente desinformativo como yo?:) –

'SSL_NULL_WITH_NULL_NULL' se refiere casi con certeza a la suite de cifrado nulo, que no proporciona ninguna autenticación o cifrado (y que nunca debería estar habilitado ...). – Bruno

@ Bruno: ¿Puedes ampliar eso? A juzgar por la salida de registro, mi suite de cifrado es * cualquier cosa * pero NULL (parece tener docenas de entradas). –

En el segundo bloque de código no aparece ningún "error". Esa es la salida normal para un SslContextFactory sin configurar, que proporciona el conjunto de cifrado nulo y un verificador de certificado que siempre aprueba. Vea también aquí para más información SslContextFactoryconfiguration.

De los registros lo tienes trabajando en ambos casos.

Para una respuesta más genérica a su pregunta, cuando utiliza certificados autofirmados, puede configurar el SslContextFactory con un almacén de confianza, para que la verificación del certificado pueda usarlo para verificar el certificado autofirmado.

Aparte de eso, me parece que ha configurado su código correctamente.

Fuente

2012-08-07 19:04:18 sbordet

No sé mucho sobre WebSocketClientFactory, pero por lo que yo entiendo, es para la configuración del lado del cliente, donde esencialmente está tratando de conectarse a un servidor configurado con un certificado autofirmado, una copia del cual se almacena en su archivo custom.jks en el cliente.

Lo que necesita para aceptar un certificado autofirmado en el lado del cliente no es establecer su almacén de claves (que se utiliza para la autenticación de certificado de cliente desde este lado), sino establecer su almacén de confianza.

Intente reemplazar setKeyStore* con setTrustStore*.

Fuente

2012-08-07 19:18:15 Bruno

Uso de un almacén de claves personalizado con WebSocketClientFactory de Jetty

Respuesta

Cuestiones relacionadas