Adding more options to the SSL configuration

[user5100]

Is your feature request related to a problem? Please describe.
Hi all, I would need to have more parameterization of the SSL context than it is currently available. Basically I would need the server to also use a trustStore, to enable/disable mutual authentication between client and server, and to define other additional options, including setting a custom cipher suite.

Describe the solution you'd like
The solution I would need should allow the following options to be added to the ssl configuration:

• Add an option to directly pass objects of type javax.net.ssl.keyManagerFactory and javax.net.ssl.trustManagerFactory (both for both client and server contexts)
• Add an option to allow the creation and parameterization of a javax.net.ssl.SSLEngine, so as to indicate enabled cipher suites, enabled ssl protocols, client authentication, etc...
• Allow the SSL context to be changed during application execution (although I do not know if it is already possible to do this)

Describe alternatives you've considered
none

Additional context
Thank you for the support

[jdegoes]

We need to think of a way to do this in such a fashion as to minimize the imprint of the JVM in the public API, for Scala Native, etc.

[LannyRipple]

Could also use this feature. My company has implemented a custom KeyStore to be update-aware of short-term credentials injected into K8S pods. No telling what else they are doing under the hood but we're supposed to use it to initialize a KeyManagerFactory for SSLContext initialization. We'd like zio-http instead of our current akka-http but this is a showstopper short of forking zio-http for an in-house workaround.

[jdegoes]

@LannyRipple How would you like to specify this? KeyManagerFactory and SSLContext are not Netty-specific so could be used in ZIO HTTP.

[jdegoes]

/bounty $250

[algora-pbc]

💎 $250 bounty • ZIO

Steps to solve:

1. Start working: Comment /attempt #2039 with your implementation plan
2. Submit work: Create a pull request including /claim #2039 in the PR body to claim the bounty
3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to zio/zio-http!

Add a bounty • Share on socials

Attempt	Started (GMT+0)	Solution
🟢 @varshith257		#3139

[LannyRipple]

I'm a bit at a loss there. We aren't using Scala Native and such so for us it's just adding to ClientSSLConfig and modifying ClientSSLConverter to do the needful and not worrying that our zio-http would be leaking JVM types. Sadly there's no way my team will agree to us maintaining a fork (I don't blame them).

Looking at my company's example code (SSL/PKI newbie here) it looks like we need

keyStoreInstanceName: String
keyStoreInputStreamtoLoad: => InputStream
// keyManagerFactoryAlgorithm -- going with default for now
// sslContextInstanceVersion: String -- going with latest.  suspect this doesn't change much

Looks like the exact same pattern for TrustStoreFactory which you would want for mTLS setup. The following certainly leaks JVM intent but I think stays away from JVM specifics until you would be down at the Netty/Jetty/Other-JVM-Lib level.

ClientSSLConfig.FromJavaxNetSsl.builder()
  .keyStoreFactoryInfo(keyStoreInstanceName, keyStoreInputStreamThunk)
  .trustStoreFactoryInfo(trustStoreInstanceName, trustStoreInputStreamThunk)
  .build()

Or maybe the InputStreams are just the paths and Netty handles the reads at SslContext creation.

[asr2003]

/attempt #2039

[algora-pbc]

@asr2003: We appreciate your enthusiasm but since you already have 3 active bounty attempts, we're going to keep this open for other contributors to attempt. 🫡

[algora-pbc]

💡 @varshith257 submitted a pull request that claims the bounty. You can visit your bounty board to reward.

[algora-pbc]

🎉🎈 @varshith257 has been awarded $250! 🎈🎊

• Share on socials
• Give feedback

[constantinos-p]

Hi, I see the requirement says: for both client and server contexts
Was the server side "symmetrical" SSLConfig implemented?
Similarly to @LannyRipple my company is also moving from akka to zio.

Using akka http we could create the SslConfig and pass it to the akka server which is pretty standard (shown below).
Are you guys planning to support these on server side? I could open an MR myself if you want.

def fromConfig(config: KeystoreConfiguration): SSLContext = {
    val ks = KeyStore.getInstance(config.`type`)

    val keyStream = (config.file, config.binary) match {
      case (_, Some(binary)) =>
        new ByteArrayInputStream(Base64.getDecoder.decode(binary.getBytes(StandardCharsets.UTF_8)))
      case (Some(filePath), None) => new FileInputStream(filePath)
      case _ => throw new IllegalArgumentException("Either file or binary must be provided for SSL keystore")
    }

    ks.load(keyStream, config.password.toCharArray)

    val kmf = KeyManagerFactory.getInstance("SunX509")
    kmf.init(ks, config.password.toCharArray)

    val tmf = TrustManagerFactory.getInstance("SunX509")
    tmf.init(ks)

    val sslContext: SSLContext = SSLContext.getInstance("TLSv1.2")
    sslContext.init(
      kmf.getKeyManagers,
      tmf.getTrustManagers,
      new SecureRandom
    )

    sslContext
  }