Develop Reference

Apache HttpClient for Java Specific GET instead of CONNECT

Is there a way to specify the connection method when using a proxy?
I'm using the below code which sends an HTTP CONNECT. That is not supported by my load balancer. A GET request would terminate the TLS connection between the proxy and the website. The CONNECT method creates a TLS connection end to end between the end user and website. Essentially I need to inspect the traffic at the proxy.
HttpHost proxy = new HttpHost(proxyHost, proxyPort);
HttpClientBuilder clientBuilder = HttpClientBuilder.create();
clientBuilder
.setConnectionManager(connectionManager)
.setProxy(proxy)
.setDefaultRequestConfig(config);
Below is what the connection looks like:
Hypertext Transfer Protocol
CONNECT xyz.com:443 HTTP/1.1\r\n
Host: xyz.com\r\n
User-Agent: Apache-HttpClient/4.5.13 (Java/19.0.1)\r\n
\r\n

For HTTPS communications through a proxy, the client will use a CONNECT request to create a connection through the proxy to the remote trusted site.
With HTTPS, the client will only communicate with a server that it trusts. The trust usually requires that the server presents an X.509 certificate that is signed by a trusted authority (not self-signed), not expired, and has a subject that matches the site the client is trying to reach.
When communicating with a proxy, the proxy is typically unable to match that criteria. However, there are proxies that can match the above criteria by generating a new cert on the fly that has a matching subject to that expected by the client.
In that case, once the client has established a TLS connection with the proxy, the proxy can then decrypt the payload of the HTTPS traffic.
For the proxy to create a certificate trusted by the client, it must be signed by a CA (certificate authority) that is trusted by the client. Now, by default, the client will not trust the cert since it will not recognize the CA. However, you may modify the client by placing a cert for the CA on the client. Once the client trusts the CA, it will trust all of the certs generated by the proxy.
That being said, here's configuration for an HTTPS proxy (written by Cisco) that provides instructions for just that:
https://www.cisco.com/c/en/us/support/docs/unified-communications/jabber/212044-Configure-Charles-Proxy-to-Capture-HTTPS.html
The configuration action you'll need for Apache (if Apache supports this) will be similar - you'll need to get a cert from the Apache proxy to install on your client.
I'm currently searching the web for similar proxies. I'm essentially looking for a key word that describes this technique of enabling your HTTPS proxy to do man-in-the-middle attacks with a dynamically generated cert matching the request. If I find the terms, I'll update the post.
EDIT: Update for squid
I found an article about configuring squid for inspecting HTTPS traffic: https://scubarda.com/2020/03/23/configure-squid-proxy-for-ssl-tls-inspection-https-interception/
In the article, the author indicates that you would have to install the X.509 Cyber Saiyan certificate in your browser (client's) certificate/authorities section (but this is just for this specific configuration).
Some good keywords to search for now are HTTPS inspection...

If this is a temporary debug solution, you can use one of the Man In The Middle (MITM) proxies that are designed just for this:
Burp
Charles
Zap
Once installed somewhere, you'll just need to import the proxy CA cert into the server making the connections (each of the above proxies has a how-to guide for this), and set the proxy address to the MITM.

WireMock is not running in HTTPS mode

Here's my code:
wireMockServer = new WireMockServer(wireMockConfig().httpsPort(8443).keystorePath("/Users/me/keystore.jks").keystorePassword("password"));
wireMockServer.start();
The problem is that when I'm trying to connect I'm getting:
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
connection?
It seems that WireMock operates on HTTP mode rather than on HTTPS mode.
Why?

wiremock is running in https mode when you specify .httpsPort(8443). but the problem is, the library you are using to make https call is not trusting the ssl certificates.
There are multiple ways to do it. however you should make sure that you do this only in the testing environment but not in production.
Here are few resources to disable ssl check.
https://stackoverflow.com/a/21257694/3892213
https://stackoverflow.com/a/2703233/3892213

Consume Web service over ssl using XFire

My project use xfire as a web service client api. My project is in legacy Servlet/JSP. We used XFire eclipse plugin to generate client stub.
Web-service has Migrated to SLL (HTTPS). Is there any easy way to consume Webservice over SSL in XFire.
I found some code at http://docs.codehaus.org/display/XFIRE/HTTP+Transport.
I have some confusion there too. It motivates to use not-so-common-ssl which is in Alpha and I don't know if it is stable enough to be used in production.
// Technique similar to http://juliusdavies.ca/commons- ssl/TrustExample.java.html
HttpSecureProtocol protocolSocketFactory = new HttpSecureProtocol();
// "/thecertificate.cer" can be PEM or DER (raw ASN.1). Can even be several PEM certificates in one file.
TrustMaterial trustMaterial = new TrustMaterial(getClass().getResource("/thecertificate.cer"));
// We can use setTrustMaterial() instead of addTrustMaterial() if we want to remove
// HttpSecureProtocol's default trust of TrustMaterial.CACERTS.
protocolSocketFactory.addTrustMaterial(trustMaterial);
// Maybe we want to turn off CN validation (not recommended!):
protocolSocketFactory.setCheckHostname(false);
Protocol protocol = new Protocol("https", (ProtocolSocketFactory) protocolSocketFactory, 8443);
Protocol.registerProtocol("https", protocol);
Now above is a way to create a Protocol factory and getting it registered with Apache HTTPclient api. But id doesnot say what to do further with the generated stub.
Please feel free to ask more information if any.
We can't move to other web-service client api so that is not an option.

Managed to solve my own problem.
This is how I did it. XFire use Apache Http client internally so setting Security certifect detail on this Api will do the job. We will use no-yet-common-ssl.jar for this purpose.
First we will create org.apache.commons.ssl.TrustMaterial using commons and then set it in HttpSecureProtocol which is a child of javax.net.ssl.SSLSocketFactory.
Suppose XYZ.cer is the client certifect provided by service provider.
HttpSecureProtocol protocolSocketFactory = new HttpSecureProtocol();
protocolSocketFactory.addTrustMaterial(TrustMaterial.DEFAULT); //for trusting all the certifects in java trusted Store.
protocolSocketFactory.addTrustMaterial(new TrustMaterial(getClass().getResource("/XYZ.cer")));
Protocol protocol = new Protocol("https", (ProtocolSocketFactory)protocolSocketFactory, 443);
Protocol.registerProtocol("https", protocol);
If this is a web Application you can do this in ServletContextListener or in any part of code that executes when application boots.
Now you can use any ssl service using Xfire client stub. Any service which implement the above certifect.
Now why this work. Because XFire uses Apache Http Client as a connection api and we are telling Http client to use the above TrustManager when HTTPS is used.

How to avoid Diffie-Hellman for SSL connections with Java/Netty?

I am using Netty as backend in a Java-based Usenet client. The library is working fine, however, in some circumstances I can't connect to a remote server via SSL, because of exactly this error:
Java: Why does SSL handshake give 'Could not generate DH keypair' exception?
Unfortunately, it seems that for whatever reason this Java error still has not been fixed yet. And since the remote server is not under my control, I need a workaround here. One such "solution", according to the link above, is to avoid DH during SSL handshake at all (not very pretty, but maybe better than nothing).
However, I am no SSL expert, so I am not really sure how I can implement that within Netty; or better: within my solution that is based on Netty. By now I am creating connections as this:
// configure the Netty client
ClientBootstrap bootstrap = new ClientBootstrap(clSockChannelFactory);
// configure the pipeline factory
bootstrap.setPipelineFactory(channelPipelineFactory);
bootstrap.setOption("tcpNoDelay", true);
bootstrap.setOption("keepAlive", true);
bootstrap.setOption("child.receiveBufferSizePredictorFactory",
new AdaptiveReceiveBufferSizePredictorFactory());
// start the connection attempt
InetSocketAddress isa = new InetSocketAddress(serverAddress, port);
ChannelFuture future = bootstrap.connect(isa);
...
channel = future.getChannel();
...
Ok, that's fine, but where can I disable cipher suites before I connect the SSL socket, as desribed in the thread above?
Thanks in advance for all your help!
Kind regards, Matthias
PS: By the way, any ideas why this problem has not been addressed in Java yet?

I'm not familiar with Netty, but I would suggest following the approach in the secure chat example.
I'm not sure what default SSL/TLS keys/trust settings you have, but if you don't have a custom SSLContext, try SSLContext.getDefault().
Then, create an SSLEngine using SSLContext.createSSLEngine(). On this SSLEngine, you should be able to enable the cipher suites you want. Assuming you're using the Oracle JRE (or OpenJDK), you'll find the list of cipher suites in the Sun Provider documentation.
After this (this is the Netty-specific part), set an SslHandler using something like this (see Netty example):
pipeline.addLast("ssl", new SslHandler(engine));

New SSL listener port with different keystore/truststore in WebLogic

Is there any way to configure an additional SSL listener port on an existing WebLogic server that uses a different keystore and truststore configuration from the "main" SSL port?

I don't think you can use multiple keystores for the same server - Even if you're using custom key/trust stores, you should be able to consolidate everything (using import/export for keytool/ikeyman).
Under the Server -> Protocols -> Channels tab, you can define an additional port using your SSL protocol of choice (t3s/https/iiops/ldaps) but your issue should be resolved by using the earlier suggestion alone.