[Red Hat JIRA] (ELY-2064) Elytron Quarkus integration not supporting key cloning
by Galder Zamarreño (Jira)
Galder Zamarreño created ELY-2064:
-------------------------------------
Summary: Elytron Quarkus integration not supporting key cloning
Key: ELY-2064
URL: https://issues.redhat.com/browse/ELY-2064
Project: WildFly Elytron
Issue Type: Enhancement
Reporter: Galder Zamarreño
Assignee: Darran Lofthouse
Elytron Quarkus integration does not support key cloning, which causes Infinispan native server to not be buildable. See [https://github.com/infinispan/infinispan-quarkus/issues/44|here] for details.
From an Elytron perspective, a way to solve this would be to have a substitution that looks something like this, where MethodHandle uses are replaced by standard reflection:
{code:java}
package org.example.elytron.graal;
import com.oracle.svm.core.annotate.Substitute;
import com.oracle.svm.core.annotate.TargetClass;
import java.lang.reflect.Constructor;
import java.lang.reflect.Method;
import java.lang.reflect.UndeclaredThrowableException;
import java.security.Key;
import java.security.PrivilegedAction;
import java.util.function.UnaryOperator;
import static java.security.AccessController.doPrivileged;
@TargetClass(className = "org.wildfly.security.key.KeyUtil$KeyClonerCreator")
final class Target_org_wildfly_security_key_KeyUtil_KeyClonerCreator
{
@Substitute
private UnaryOperator<Key> checkForCloneMethod(final Class<?> declType, final Class<?> returnType)
{
System.out.printf("Call checkForCloneMethod(%s,%s)%n", declType, returnType);
final Method method = doPrivileged(new PrivilegedAction<Method>()
{
@Override
public Method run()
{
try
{
final var cloneMethod = declType.getDeclaredMethod("clone");
if (cloneMethod.getReturnType() == returnType)
return cloneMethod;
return null;
}
catch (NoSuchMethodException e)
{
return null;
}
}
});
if (method == null)
return null;
return new UnaryOperator<Key>()
{
@Override
public Key apply(Key key)
{
try
{
return (Key) method.invoke(key);
}
catch (RuntimeException | Error e)
{
throw e;
}
catch (Throwable throwable)
{
throw new UndeclaredThrowableException(throwable);
}
}
};
}
@Substitute
private UnaryOperator<Key> checkForCopyCtor(final Class<?> declType, final Class<?> paramType)
{
System.out.printf("Call checkForCopyCtor(%s,%s)%n", declType, paramType);
final Constructor<?> constructor = doPrivileged(new PrivilegedAction<Constructor<?>>()
{
@Override
public Constructor<?> run()
{
try
{
return declType.getDeclaredConstructor(paramType);
}
catch (NoSuchMethodException e)
{
System.out.printf("Copy ctor in %s for parameter %s not found%n", declType, paramType);
return null;
}
}
});
if (constructor == null)
return null;
return new UnaryOperator<Key>()
{
@Override
public Key apply(Key key)
{
try
{
return (Key) constructor.newInstance(key);
}
catch (RuntimeException | Error e)
{
throw e;
}
catch (Throwable throwable)
{
throw new UndeclaredThrowableException(throwable);
}
}
};
}
} {code}
These substitutions alone are not enough, there are also needs to be some reflection registrations for the keys for which this is expected to work. As example:
{code:java}
package org.example.elytron.graal;
import com.oracle.svm.core.annotate.AutomaticFeature;
import org.example.elytron.Main;
import org.graalvm.nativeimage.hosted.Feature;
import org.graalvm.nativeimage.hosted.RuntimeReflection;
import javax.crypto.SecretKey;
import java.lang.reflect.UndeclaredThrowableException;
@AutomaticFeature
public class RuntimeReflectionRegistrations implements Feature
{
public void beforeAnalysis(BeforeAnalysisAccess access)
{
try
{
RuntimeReflection.register(Main.CopyConstructorSecretKey.class.getDeclaredConstructor(SecretKey.class));
RuntimeReflection.register(Main.CopyConstructorSecretKey.class.getDeclaredMethod("destroy"));
RuntimeReflection.register(Main.CloneMethodSecretKey.class.getDeclaredMethod("clone"));
RuntimeReflection.register(Main.CloneMethodSecretKey.class.getDeclaredMethod("destroy"));
}
catch (NoSuchMethodException e)
{
throw new UndeclaredThrowableException(e);
}
}
} {code}
[This main class|https://github.com/galderz/mendrugo/blob/master/elytron-cloning/src... these substitutions which have been verified to work with a couple of custom designed secret keys that fall within the expected substitution.
The Elytron and Infinispan teams should work together to figure out which keys require support from the reflection calls above.
All the code above can be found in [this sample project.|https://github.com/galderz/mendrugo/tree/master/elytron-cloning]
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14256) Clean up set of installations provisioned in testsuite/layers when -Dts.ee9 is used
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-14256?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-14256:
------------------------------------
Description: The testsuite/layers pom uses the provisioning.phase.preview.excluded property to disable some provisioning executions when -Dts.ee9 is used. Basically it should disable all that require the wildfly-servlet feature pack (as they are off-topic), all that require the test-feature-pack (as it's not based on wildfly-preview) and all that require layers that have been dropped from WildFly Preview (e.g. legacy security stuff). There are a few cases where this isn't handled correctly; fix them. (was: The testsuite/layers pom uses the provisioning.phase.preview.excluded property to disable some provisioning executions when -Dts.ee9 is used. Basically it should disable all that require the wildfly-servlet feature pack (as they are off-topic) and all that require the test-feature-pack (as it's not based on wildfly-preview.). There are a few cases where this isn't handled correctly; fix them.)
> Clean up set of installations provisioned in testsuite/layers when -Dts.ee9 is used
> -----------------------------------------------------------------------------------
>
> Key: WFLY-14256
> URL: https://issues.redhat.com/browse/WFLY-14256
> Project: WildFly
> Issue Type: Task
> Components: Build System, Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> The testsuite/layers pom uses the provisioning.phase.preview.excluded property to disable some provisioning executions when -Dts.ee9 is used. Basically it should disable all that require the wildfly-servlet feature pack (as they are off-topic), all that require the test-feature-pack (as it's not based on wildfly-preview) and all that require layers that have been dropped from WildFly Preview (e.g. legacy security stuff). There are a few cases where this isn't handled correctly; fix them.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14259) URL.openStream fails handshake on WildFly
by Dominik Lepczyński (Jira)
[ https://issues.redhat.com/browse/WFLY-14259?page=com.atlassian.jira.plugi... ]
Dominik Lepczyński closed WFLY-14259.
-------------------------------------
Resolution: Explained
> URL.openStream fails handshake on WildFly
> -----------------------------------------
>
> Key: WFLY-14259
> URL: https://issues.redhat.com/browse/WFLY-14259
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 20.0.0.Final, 20.0.1.Final
> Reporter: Dominik Lepczyński
> Priority: Major
>
> There's a problem connecting using TLS v1.3 using JSSE (URL.openStream). Connection works on the same JDK and machine in a standalone Java program. Only when the code is executed on WildFly the server_name extension is going AWOL from ClientHello message, and the connection fails with handshake_failure. It seems to be a bug in WildFly, because it happens only when running on WildFly with the rest of the code identical.
> Tested on WildFly 20.0.0.Final and 20.0.1.Final using AdoptOpenJDK 11.0.9.1_1.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14259) URL.openStream fails handshake on WildFly
by Dominik Lepczyński (Jira)
[ https://issues.redhat.com/browse/WFLY-14259?page=com.atlassian.jira.plugi... ]
Dominik Lepczyński commented on WFLY-14259:
-------------------------------------------
I think I've found the issue. WildFly is launched with -Djsse.enableSNIExtension=false and that's why it fails to connect. After all these years running on WildFly I don't remember the source of the suggestion to disable SNI. Probably comes from times before JDK fully supported TLS v.1.3.
Case closed.
> URL.openStream fails handshake on WildFly
> -----------------------------------------
>
> Key: WFLY-14259
> URL: https://issues.redhat.com/browse/WFLY-14259
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 20.0.0.Final, 20.0.1.Final
> Reporter: Dominik Lepczyński
> Priority: Major
>
> There's a problem connecting using TLS v1.3 using JSSE (URL.openStream). Connection works on the same JDK and machine in a standalone Java program. Only when the code is executed on WildFly the server_name extension is going AWOL from ClientHello message, and the connection fails with handshake_failure. It seems to be a bug in WildFly, because it happens only when running on WildFly with the rest of the code identical.
> Tested on WildFly 20.0.0.Final and 20.0.1.Final using AdoptOpenJDK 11.0.9.1_1.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14259) URL.openStream fails handshake on WildFly
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFLY-14259?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFLY-14259:
-------------------------------
Affects Version/s: 20.0.1.Final
20.0.0.Final
> URL.openStream fails handshake on WildFly
> -----------------------------------------
>
> Key: WFLY-14259
> URL: https://issues.redhat.com/browse/WFLY-14259
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 20.0.0.Final, 20.0.1.Final
> Reporter: Dominik Lepczyński
> Priority: Major
>
> There's a problem connecting using TLS v1.3 using JSSE (URL.openStream). Connection works on the same JDK and machine in a standalone Java program. Only when the code is executed on WildFly the server_name extension is going AWOL from ClientHello message, and the connection fails with handshake_failure. It seems to be a bug in WildFly, because it happens only when running on WildFly with the rest of the code identical.
> Tested on WildFly 20.0.0.Final and 20.0.1.Final using AdoptOpenJDK 11.0.9.1_1.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14259) URL.openStream fails handshake on WildFly
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFLY-14259?page=com.atlassian.jira.plugi... ]
Jeff Mesnil edited comment on WFLY-14259 at 1/4/21 10:37 AM:
-------------------------------------------------------------
[~d.lepczynski] thanks for the report, do you have a reproducer test we can use to verify the issue?
Are you still facing the issue with the latest WildFly release (21.0.2.Final)?
was (Author: jmesnil):
[~d.lepczynski] thanks for the report, do you have a reproducer test we can use to verify the issue?
> URL.openStream fails handshake on WildFly
> -----------------------------------------
>
> Key: WFLY-14259
> URL: https://issues.redhat.com/browse/WFLY-14259
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 20.0.0.Final, 20.0.1.Final
> Reporter: Dominik Lepczyński
> Priority: Major
>
> There's a problem connecting using TLS v1.3 using JSSE (URL.openStream). Connection works on the same JDK and machine in a standalone Java program. Only when the code is executed on WildFly the server_name extension is going AWOL from ClientHello message, and the connection fails with handshake_failure. It seems to be a bug in WildFly, because it happens only when running on WildFly with the rest of the code identical.
> Tested on WildFly 20.0.0.Final and 20.0.1.Final using AdoptOpenJDK 11.0.9.1_1.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14259) URL.openStream fails handshake on WildFly
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFLY-14259?page=com.atlassian.jira.plugi... ]
Jeff Mesnil moved WFCORE-5235 to WFLY-14259:
--------------------------------------------
Key: WFLY-14259 (was: WFCORE-5235)
Project: WildFly (was: WildFly Core)
> URL.openStream fails handshake on WildFly
> -----------------------------------------
>
> Key: WFLY-14259
> URL: https://issues.redhat.com/browse/WFLY-14259
> Project: WildFly
> Issue Type: Bug
> Reporter: Dominik Lepczyński
> Priority: Major
>
> There's a problem connecting using TLS v1.3 using JSSE (URL.openStream). Connection works on the same JDK and machine in a standalone Java program. Only when the code is executed on WildFly the server_name extension is going AWOL from ClientHello message, and the connection fails with handshake_failure. It seems to be a bug in WildFly, because it happens only when running on WildFly with the rest of the code identical.
> Tested on WildFly 20.0.0.Final and 20.0.1.Final using AdoptOpenJDK 11.0.9.1_1.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14259) URL.openStream fails handshake on WildFly
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFLY-14259?page=com.atlassian.jira.plugi... ]
Jeff Mesnil commented on WFLY-14259:
------------------------------------
[~fjuma] When we have a reproducer, could you please have a look?
> URL.openStream fails handshake on WildFly
> -----------------------------------------
>
> Key: WFLY-14259
> URL: https://issues.redhat.com/browse/WFLY-14259
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Dominik Lepczyński
> Priority: Major
>
> There's a problem connecting using TLS v1.3 using JSSE (URL.openStream). Connection works on the same JDK and machine in a standalone Java program. Only when the code is executed on WildFly the server_name extension is going AWOL from ClientHello message, and the connection fails with handshake_failure. It seems to be a bug in WildFly, because it happens only when running on WildFly with the rest of the code identical.
> Tested on WildFly 20.0.0.Final and 20.0.1.Final using AdoptOpenJDK 11.0.9.1_1.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFLY-14259) URL.openStream fails handshake on WildFly
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-14259?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFLY-14259:
------------------------------------
Component/s: Security
> URL.openStream fails handshake on WildFly
> -----------------------------------------
>
> Key: WFLY-14259
> URL: https://issues.redhat.com/browse/WFLY-14259
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Dominik Lepczyński
> Priority: Major
>
> There's a problem connecting using TLS v1.3 using JSSE (URL.openStream). Connection works on the same JDK and machine in a standalone Java program. Only when the code is executed on WildFly the server_name extension is going AWOL from ClientHello message, and the connection fails with handshake_failure. It seems to be a bug in WildFly, because it happens only when running on WildFly with the rest of the code identical.
> Tested on WildFly 20.0.0.Final and 20.0.1.Final using AdoptOpenJDK 11.0.9.1_1.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (WFCORE-5235) URL.openStream fails handshake on WildFly
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-5235?page=com.atlassian.jira.plug... ]
Jeff Mesnil commented on WFCORE-5235:
-------------------------------------
[~d.lepczynski] thanks for the report, do you have a reproducer test we can use to verify the issue?
> URL.openStream fails handshake on WildFly
> -----------------------------------------
>
> Key: WFCORE-5235
> URL: https://issues.redhat.com/browse/WFCORE-5235
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Dominik Lepczyński
> Priority: Major
>
> There's a problem connecting using TLS v1.3 using JSSE (URL.openStream). Connection works on the same JDK and machine in a standalone Java program. Only when the code is executed on WildFly the server_name extension is going AWOL from ClientHello message, and the connection fails with handshake_failure. It seems to be a bug in WildFly, because it happens only when running on WildFly with the rest of the code identical.
> Tested on WildFly 20.0.0.Final and 20.0.1.Final using AdoptOpenJDK 11.0.9.1_1.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months