Używanie niestandardowego magazynu kluczy za pomocą komponentu Jetty WebSocketClientFactory

Question

Mam projekt Java, który łączy się z serwerem CometD za pośrednictwem bezpiecznego transportu WebSocket, który używa samopodpisanego certyfikatu. Mam konfiguracji WebSocketClientFactory w następujący sposób:

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

a następnie utworzyć mój BayeuxClient tak:

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

Rzeczywiście, gdy ten pierwszy zostanie załadowany, wszystko wydaje się być poprawnie skonfigurowane:

[DEBUG] 2012-08-07 12:58:05,786 : starting org.eclipse.jetty.websocket.WebSocketClientFactory@75cfa3d2 
[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.jetty.websocket.WebSocketClientFactory$WebSocketClientSelector@50c8c3b8 
[DEBUG] 2012-08-07 12:58:05,795 : STARTED org.eclipse.jetty.websocket.WebSocketClientFactory$WebSocketClientSelector@50c8c3b8 
[DEBUG] 2012-08-07 12:58:05,795 : Starting Thread[qtp2005556553-33 Selector0,5,main] on org.eclipse.jetty.io.nio.SelectorManager$1@346fe350 
[DEBUG] 2012-08-07 12:58:05,797 : starting SslContextFactory@4240eca3(/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 SslContextFactory@4240eca3(/Users/apetresc/Downloads/infrastructure.jks,/Users/apetresc/Downloads/infrastructure.jks) 
[DEBUG] 2012-08-07 12:58:05,981 : STARTED org.eclipse.jetty.websocket.WebSocketClientFactory@75cfa3d2 

I rzeczywiście, faktycznie używając BayeuxClient prace. Jednak działałoby to nawet wtedy, gdy w ogóle nie określiłbym magazynu kluczy - po prostu traktuje go jako niepodpisany certyfikat. I rzeczywiście, że wydaje się być to, co się dzieje, sądząc po dzienników błędów ciśgle co kilka sekund:

[DEBUG] 2012-08-07 13:20:37,348 : State update: CONNECTED -> CONNECTED 
[DEBUG] 2012-08-07 13:20:37,348 : Connecting, transport org.cometd.websocket.client.WebSocketTransport@53ddbcb1 
[DEBUG] 2012-08-07 13:20:37,348 : [Session-1, SSL_NULL_WITH_NULL_NULL] SslConnection@79c190a2 SSL NOT_HANDSHAKING i/o/u=0/0/0 ishut=false oshut=false {WebSocketClientConnection p=WebSocketParserRFC6455@5266db4e state=START buffer= g=WebSocketGeneratorRFC6455@5ec80825 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] SslConnection@79c190a2 SSL NOT_HANDSHAKING i/o/u=0/0/0 ishut=false oshut=false {WebSocketClientConnection p=WebSocketParserRFC6455@5266db4e state=OPCODE buffer= g=WebSocketGeneratorRFC6455@5ec80825 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] SslConnection@79c190a2 SSL NOT_HANDSHAKING i/o/u=0/0/0 ishut=false oshut=false {WebSocketClientConnection p=WebSocketParserRFC6455@5266db4e state=OPCODE buffer= g=WebSocketGeneratorRFC6455@5ec80825 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] SslConnection@79c190a2 SSL NOT_HANDSHAKING i/o/u=0/0/0 ishut=false oshut=false {WebSocketClientConnection p=WebSocketParserRFC6455@5266db4e state=OPCODE buffer=null g=WebSocketGeneratorRFC6455@5ec80825 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] SslConnection@79c190a2 SSL NOT_HANDSHAKING i/o/u=0/0/0 ishut=false oshut=false {WebSocketClientConnection p=WebSocketParserRFC6455@5266db4e state=OPCODE buffer=null g=WebSocketGeneratorRFC6455@5ec80825 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] SslConnection@79c190a2 SSL NOT_HANDSHAKING i/o/u=0/0/0 ishut=false oshut=false {WebSocketClientConnection p=WebSocketParserRFC6455@5266db4e state=OPCODE buffer=null g=WebSocketGeneratorRFC6455@5ec80825 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 SslConnection@79c190a2 SSL NOT_HANDSHAKING i/o/u=0/0/0 ishut=false oshut=false {WebSocketClientConnection p=WebSocketParserRFC6455@5266db4e state=OPCODE buffer=null g=WebSocketGeneratorRFC6455@5ec80825 closed=false buffer=-1} progress=false 

Dla mnie oznacza to, że CometD uzgadniania kończy, ale SSL handshake nie jest. Nie wiem, dlaczego tak się dzieje; analogiczne podejście działa dla moich połączeń HTTPS. Tylko WSS sprawia mi ból głowy.

Warto również wspomnieć, że mogę to odtworzyć w różnych środowiskach, w tym w aplikacji na Androida i w kontenerze serwletów Jetty.

Czy ktoś z powodzeniem użył WSS z samopodpisanym certyfikatem? Chcesz rzucić trochę światła na to, co robię źle?

Answer 1

W drugim bloku kodu nie otrzymujesz żadnego "błędu". Jest to normalne wyjście dla nieskonfigurowanego SslContextFactory, które zapewnia zestaw zerowego zestawu algorytmów szyfrowania i zawsze zatwierdzający weryfikator certyfikatu. Zobacz również tutaj w celu uzyskania dalszych SslContextFactoryconfiguration.

Z logów, które masz działa w obu przypadkach.

Aby uzyskać bardziej ogólną odpowiedź na swoje pytanie, podczas korzystania z certyfikatów samopodpisanych można skonfigurować usługę SslContextFactory w magazynie zaufanych certyfikatów, aby weryfikacja certyfikatu mogła go wykorzystać do zweryfikowania certyfikatu z podpisem własnym.

Poza tym wydaje mi się, że poprawnie skonfigurowałeś swój kod.

Answer 2

Nie wiem zbyt wiele na temat WebSocketClientFactory, ale z tego co rozumiem, dotyczy to konfiguracji po stronie klienta, w której zasadniczo próbujesz połączyć się z serwerem skonfigurowanym za pomocą certyfikatu z podpisem własnym, którego kopię jest przechowywany w pliku custom.jks na kliencie.

To, czego potrzebujesz do zaakceptowania certyfikatu z podpisem własnym po stronie klienta, to nie ustawiać jego magazynu kluczy (który jest używany do uwierzytelniania certyfikatów klienta z tej strony), ale ustawić jego magazyn zaufanych certyfikatów.

Spróbuj wymienić setKeyStore* na setTrustStore*.