Just noticed that netty-tcnative-boringssl doesn't support AIX(tried on AIX and confirmed by netty-tcnative's dev). Which got my ass burning and eager to find the alternative solution for HTTP2 with native openssl lib as sooner as possible.
Since I need to run it on Java8 which doesn't have HTTP2, so they must have native support of it. Does anyone know Apache HTTP Client 5 or OkHTTP have native openssl(boringSSL) builtin, or addon lib that could make them running without using JDK's SSL provider?
Related
I'd like to use java.net.http.HttpClient instead of curl to perform the http examples list here:
https://docs.docker.com/engine/api/sdk/examples/
Is there a way to do this?
The JDK does not support Unix Domain Socket connections yet (JEP 380 will add this feature). But regardless of that it appears java.net.http.HttpClient only supports URIs (but not SocketAddress) as destination, therefore it would not work anyways.
There are however libraries which offer this functionality:
junixsocket (relevant issue)
Reactor Netty
Netty: How do I connect to a UNIX domain socket running an HTTP server using Netty?
unix-socket-factory (for Apache HttpClient)
However, since your goal is to connect to Docker, it would be easiest to use one of the available Java Docker clients.
previously I've used grpc C-core for .net 2.x and it was working fine, with groc running on .net core 2.2 on server side and C#, Java grpc clients, using pem files for TLS.
Now I've noticed that the new grpc-dptnet no longer supports pem files. Does that mean everything breaks? no more backwards compatibility? I was looking forward to use the new worker service in .net core 3 to rewrite my grpc windows service, without the front end knowing it, so front end continues to use pem files for TLS. But it seems to be impossible now.
So can someone please advice me..
How many types of pfx files are there? client pfx, server pfx? or just one client pfx?
How does Java grpc client make use of the pfx file to connect to grpc server, esp when server is done in grpc-dotnet and not the C core grpc.
is there a difference between the pfx cert used by IIS and the one used by grpc server? will it cause a conflict if client side pfx is used on IIS with developer SSL cert.. for the case when asp.net web appp is also running grpc service.. esp when on the same port.. then what would happen?
How do I detect disconnect for grpc? previously with grpc-C-core, I would call Connect first, then wait for connection change status.. now with httpClient, I don't think this is possible.. or am I wrong?
I'm finding the new grpc-dotnet far more confusing and difficult to understand than the original grpc C core for .net. At least that was clear how to config ports, certs (generating pem files using openssl was very easy and all that matters was the CN field). Now with the pfx file format, I'm really confused.. so please bear with me if I sound stupid..
I use Apache Tomcat and I configure it for HTTPS connection (at the moment using a self signed certificate).
I wondering if I should set other in my java code (I use Spring) or Tomcat provides connection encrypted for all the data. For example if I use FTP, download end send file etc...
Maybe is a stupid question but it is important use https for my connection.
Thanks, best regards
OpenShift swiftly addressed the SSL 'Poodle' vulnerability around October 16th 2014. Since then the e-commerce provider I work with can no longer establish a secure HTTPS connection with my OpenShift PHP application. I suspect this is, at least in part, because SSL3 is no longer an available protocol.
The error logged at the e-commerce provider end is:
javax.net.ssl.SSLException
java.lang.RuntimeException: Could not generate DH keypair
Here's what I've tried and discovered so far:
The online SSL testing tool at https://www.ssllabs.com/ssltest/ indicates my SSL Certificate is installed correctly (installed via the OpenShift WebConsole), and it receives an 'A' grade. HTTPS works fine when connecting to my OpenShift PHP application in a normal web browser. In general the SSL Certificate & installation itself seems fine.
As a test, I have tried using OpenShift's shared SSL Certificate instead of my own, with exactly the same result.
Java 7
The remote e-commerce platform that is attempting to connect to my OpenShift PHP app via HTTPS uses Java 7. Tech support thinks the issue is that their Java 7 system doesn't support cipher key lengths > 1024 bits. Unfortunately they're not in a position to upgrade their system to Java 8 at present, so their hands are a bit tied.
Handshake Simulation
The ssllabs analysis of my SSL Certficate includes a useful Handshake Simulation test with various clients. This actually shows a Java 7 simulation connecting OK using TLS1.0, however the Java 6 simulation fails with a 'Client does not support DH parameters > 1024 bits' error - roughly echoing what e-commerce tech support is seeing reported by their Java 7 based system.
How might I solve this? To narrow the question down a little:
Is there a simple adjustment my e-commerce provider could make at their end to enable HTTPS connections to OpenShift applications, without them having to upgrade Java or make significant changes that could impact others? e.g. An option to accept DH parameters > 1024 bits.
Is there anything I can adjust at my end (perhaps an OpenShift or PHP setting) to enable their Java 7 based system to establish a HTTPS connection with my OpenShift application successfully? e.g. An option instructing OpenShift to provide DH parameters <= 1024 bits.
Restarting your application should resolve the issue as it will pick up the latest JDK that should contain the latest fixes for this issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1035818
https://bugzilla.redhat.com/show_bug.cgi?id=1080125
My apllication is deployed on Tomcat 6 with Java 6, I want to restrict the SSL protocol to use only TLSv1.1. According to Java 6 documentation JCE isn't supporting TLSv1.1 while Java 7 does.
Upgrade my Java version isn't acceptable. There is any providers that implements TLSv1.1 protocol that I can integrate to my java?
Since it's production system I am looking for quick and safe fix. I thought to front end my application server with apache web server at the same host(which supports TLSv1.1 through openssl) and use him as a proxy server. Unfortunately my physical resources are low.
Any other ideas are welcome.
Thanks.
Front it with a system that does the SSL and does get security updates. You can run apache using the connector - if you still trust this - or setup a Java application (a newer version of Tomcat?) to act as an SSL proxy (connecting to port 80 of your server, if this is acceptable to you).