HttpClient.Builder.sslContext is not implement yet in Flupke

[AlexanderSchuetz97]

This Method would be normally used to install the "Trust Self Signed Certificates" Trust manager. Also this method is used to trust only certain certificates instead of trusting all of them. It is also used to use Client side Certificates.

Currently Flupke only has a "non interface" method in the HttpClient.Builder to trust all Self Signed Certificates.

[ptrd]

This is a bit problematic, because the SSLContext class has only a method to set the KeyManager / TrustManager, but none to get them. So this could only work if the SSLContext passed to the builder was created by Flupke in the first place, so it will never work with a SSLContext object provided by third-party code, e.g. generated code. We could make it work when we require who is using Flupke to write custom code, but I wonder if this would not defeat the purpose of your request.

Furthermore, various methods in SSLContext make no sense for HTTP3, e.g. createSSLEngine, getSocketFactory. Of course, they could all be implemented by returning null or throwing a NotSupportedException, but it all feels very clumsy.

[AlexanderSchuetz97]

I suppose there is a reason why you are not using the default TLS1.3 engine provided by the JDK. Unless you can make flupke work with the default TLS 1.3 engine provided by SSLContext.createSSLEngine then I see no clean solution. (This would probably also make a lot of security people happy as they will not be happy to have to audit yet another SSL Engine implementation, for me its not that big of a deal as I would not be the one that has to do that.)

I will continue under the assumption that it is impossible to use the default TLS 1.3 Engine. (I don't have that deep of an understanding of QUIC to know if it truely is impossible)

There are 2 options remaining both sub par:

Option 1: Implement a SSLContext wrapper that can be retrieved by SSLContext.getInstance("Flupke") or something similar This context pretty much does as you described and just throws Unsupported operation exception on everything except init.

Option 2: Provide 1 or 2 custom methods in the Http3ClientBuilder that allows me to provided a KeyManager[] and a TrustManager[] just as I would provide them for SSLContext#init

I prefer Option 2.

Also to clarify my request and provide more context: Don't worry about the code generator here. The generator makes no SSLContext/SSL stuff. Such things are always handled explicitly by the programmer (me). In production the code generated by the Code generator receives a HttpClient.Builder object and will create as many HttpClient instances as it needs to actually do the requests. The SSL stuff is configured inside the Builder. The main reason why I would prefer to have a clean interface is that I use very complex code to create the SSLContext from .pem/.cer/.pfx/.der/.jks/..... files as certificate file formats are a clusterfuck that I would very much prefer to not have to write this code twice. Giving me an option to set KeyManager[] and a TrustManager[] would already be a masssive step in the right direction. Just not perfect. I also very much agree that the Interfaces provided by the JDK are not that great, its just what we got so we should make the best of it.

Sincerely Alexander Schütz

[ptrd]

QUIC is not using TLS layer, it is only using the handshake messages. Therefore, it is in general quite hard to use an existing TLS layer in a QUIC implementation and in the case of the JDK and given its Tls-engine, this is fairly impossible. So indeed, i had a very good reason for not using the default TLS engine of the JDK ;-).

I like your Option 2, shouldn't be to hard to add.