Quantcast
Channel: Active questions tagged https - Stack Overflow
Viewing all articles
Browse latest Browse all 1506

URLConnectionHTTPConduit ignores TLSClientParameters

$
0
0

I use apache cxf (URLConnectionHTTPConduit) to integrate with other server. I faced error: Connection reset. It happend when server chooses ciphers from UNSUPPORTED_CIPHERS. So decided to exclude them using TLSClientParameters. It works totally fine, when I run it on my PC (windows). But in kuber (ubuntu 22) my server keeps offering them in its hello handshake.

javax.net.ssl|DEBUG|57|http-nio-8080-exec-9|2024-06-26 16:59:35.666 MSK|null:-1|Ignore, context unavailable extension: cookiejavax.net.ssl|DEBUG|57|http-nio-8080-exec-9|2024-06-26 16:59:35.670 MSK|null:-1|Ignore, context unavailable extension: renegotiation_infojavax.net.ssl|DEBUG|57|http-nio-8080-exec-9|2024-06-26 16:59:35.670 MSK|null:-1|Found resumable session. Preparing PSK message.javax.net.ssl|DEBUG|57|http-nio-8080-exec-9|2024-06-26 16:59:35.673 MSK|null:-1|Produced ClientHello handshake message ("ClientHello": {"client version"      : "TLSv1.2","random"              : "FB6713406EDE47D401B464CD31FC7B7BB9BFA43A32F654F20B53EB7CEC9AEE1B","session id"          : "8B224BD2E306A46ECFA55DE3C00601CCBF1DB48EF812D715A3ABEF5119BFD3CA","cipher suites"       : "[TLS_AES_256_GCM_SHA384(0x1302), TLS_AES_128_GCM_SHA256(0x1301), TLS_CHACHA20_POLY1305_SHA256(0x1303), TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256(0xCCA9), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256(0xCCA8), TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256(0xCCAA), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]","compression methods" : "00","extensions"          : ["server_name (0)": {      type=host_name (0), value=<host>    },"status_request (5)": {"certificate status type": ocsp"OCSP status request": {"responder_id": <empty>"request extensions": {<empty>        }      }    },"supported_groups (10)": {"versions": [x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]    },"ec_point_formats (11)": {"formats": [uncompressed]    },"status_request_v2 (17)": {"cert status request": {"certificate status type": ocsp_multi"OCSP status request": {"responder_id": <empty>"request extensions": {<empty>          }        }      }    },

Part of my code:

public class JaxWsEmailTimeoutProxyFactoryBean extends JaxWsProxyFactoryBean {    private static final Set<String> UNSUPPORTED_CIPHERS = Set.of("TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384","TLS_AES_256_GCM_SHA384","TLS_AES_128_GCM_SHA256","TLS_CHACHA20_POLY1305_SHA256"    );    @Override    public synchronized Object create() {        Object result = super.create();        Client clientProxy = ClientProxy.getClient(result);        HTTPConduit conduit = (HTTPConduit) clientProxy.getConduit();        HTTPClientPolicy policy = new HTTPClientPolicy();        policy.setConnectionTimeout(connectionTimeout);        policy.setReceiveTimeout(receiveTimeout);        policy.setAllowChunking(true);        conduit.setClient(policy);        final TLSClientParameters tlsParams = new TLSClientParameters();        tlsParams.setDisableCNCheck(true);        tlsParams.setSecureSocketProtocol("TLSv1.2");        SSLServerSocketFactory ssf = (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();        List<String> supportedCiphers = Arrays.stream(ssf.getSupportedCipherSuites())                    .filter(cipher -> !UNSUPPORTED_CIPHERS.contains(cipher))                    .toList();        log.warn("Supported ciphers: " + String.join(",", supportedCiphers));        tlsParams.setCipherSuites(supportedCiphers);        conduit.setTlsClientParameters(tlsParams);        return result;    }

I'm using java 17 and org.apache.cxf:cxf-core:4.0.3

As workaround I used JVM option -Djdk.tls.client.cipherSuites= with list of supported ciphers. But I don't want to keep it hardcoded. Do you have any idea why TLSClientParameters isn't applied to connections?


Viewing all articles
Browse latest Browse all 1506

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>