OpenSSL support

[dmlloyd]

This was a card but now it's an issue too. ;)

We need OpenSSL integration for the native image target. Here are the requirements:

• Replace any/all usages of the JCA with libssl and/or libcrypto direct C calls
  • This should be done by implementing each crypto primitive with an implementation class; then we should swap out calls to e.g. MessageDigest.getInstance("SHA-256") with our own e.g. new OpenSslSHA256MessageDigest(); this is probably best accomplished using a Feature with a node plugin that swaps the invocation sites
  • Unknown algorithms should be translated to throw new NoSuchAlgorithmException()
• Support dynamic run-time linking of OpenSSL implementation
  • This is done via dlsym and CFunctionPointer objects

Acceptance criteria:

• JSSE/JCA functions correctly :)
• Run time image size is not significantly increased

[dmlloyd]

Also consider libnss

[dmlloyd]

One reason to look at libnss (possibly first) is that it has a binary compatibility contract that is superior to OpenSSL (guaranteed backwards compatibility forever).

[gsmet]

@dmlloyd so there's no SSL support in GraalVM that we need to implement it ourselves?

[dmlloyd]

There is support for SSL, but it requires JNI (5MB+ penalty) and it requires you to bundle JDK libraries with your native application (or have them be accessible some other way).

[gsmet]

@cescoffier Is this really a first public release item? It seems like some significant work and, while I agree reducing the size of the image is a good thing, it doesn't strike me as something we cannot postpone? Maybe I'm missing something?

[cescoffier]

It’s more a question of perception but supporting ssl is generally a must-have if we want to be taken seriously. The ‘managed at the edge’ answer is not very good.

Now should it be OpenSSL or something different I don’t know. But I agree it’s a lot of work.

Sent from my iPhone

On 10 Jan 2019, at 07:26, Guillaume Smet notifications@github.com wrote:

@cescoffier Is this really a first public release item? It seems like some significant work and, while I agree reducing the size of the image is a good thing, it doesn't strike me as something we cannot postpone? Maybe I'm missing something?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[gsmet]

@cescoffier well, I understood from this message from @FroMage https://github.com/jbossas/protean-shamrock/issues/454#issuecomment-452696702 that SSL already works.

@FroMage you confirm it works in native image already?

[cescoffier]

I believe this is only if Netty is used as server, when we will have the abstraction layer yes, I should be ok.

[gsmet]

For reference: https://github.com/oracle/graal/blob/master/substratevm/JCA-SECURITY-SERVICES.md#native-implementations .

[dmlloyd]

It does work but as I said it adds the JNI penalty plus it relies on a shared library from the JDK to be available to the application, which is not an ideal situation.

[FroMage]

Yeah, it's not ideal, but it works ATM.

[cescoffier]

Ok, I've opened: https://github.com/jbossas/protean-shamrock/issues/468. If we have some kind of a guide explaining how to set up the server to use a certificate and accept SSL connection, we are fine.

PS: Removing the first release label, the other issue has it.