SSL Wrapped Over JUnixSocket

[SteveShell]

I am very pleased that the junixsocket implementation is rich and complete enough to support two-way SSL over the unix domain socket.

Use the client "connect()" socket and the server "accept()" socket to start the two way SSL handshake.

public SSLSocket wrapInSSL(Socket client, boolean clientMode) throws IOException {
	SSLSocket s = (SSLSocket)defaultSocketFactory.createSocket(client, null, false);
	s.setUseClientMode(clientMode);
	s.setWantClientAuth(false);
	s.setNeedClientAuth(false);
	if (!clientMode) {
		s.setNeedClientAuth(true);
	}
	return s;
}

[Hmm466]

Hello, could you please tell me how to build defaultSocketFactory and how to import pem local text?

[kohlschuetter]

@JordyH66 That's a very good question! I wondered this myself, and a few days later, since version 2.8.0 we now have junixsocket-ssl, which aims to simplify this mess. Make sure to add junixsocket-core and junixsocket-ssl to your project, as described here

Here is some demo code:
https://github.com/kohlschutter/junixsocket/tree/main/junixsocket-demo/src/main/java/org/newsclub/net/unix/demo/ssl

Some test cases can be found here:
https://github.com/kohlschutter/junixsocket/tree/main/junixsocket-ssl/src/test/java/org/newsclub/net/unix/ssl

[Hmm466]

Thank you very much for your reply. This library officially supports SSL Sockets. However, my recent research found that this is not our problem. I used it to connect to the iPhone and found that the Empty Issuer DN was not reported when importing the pem file. allowed in X509Certificates error, I found that this error must be injected from the jdk source level, but I am curious why python and Go can use this kind of certificate. There's something wrong with their design

[kohlschuetter]

When I implemented SSL support for junixsocket, I learned that practically every TLS implementation has their own subtle bugs and historical glitches, and I had to work around quite a few of them. This not only applies to Java code, but also boringssl, wolfssl, etc. for example.

One thing to keep in mind is that cryptography advances as time goes by. Some default that were considered secure have been improved by backwards-incompatible changes, for example Java bugs JDK-8202837, JDK-8267701.

Another thing I learned is that self-signed certificates (i.e., those without a certificate chain) are obviously treated very differently. For example, Java would happily accept expired certificates without warning. The same might apply to your "Empty Issuer DN" situation.

If you feel that you've found a bug in Java, you should definitely go ahead and report it. For example, I found JDK-8316703 and an incompatibility with IAIK-iSaSiLk. Reporting is worth the effort, especially since these are issues in sensitive code.