[Bug 67926] PEMFile prints unidentifiable string representation of ASN.1 OIDs
https://bz.apache.org/bugzilla/show_bug.cgi?id=67926 --- Comment #5 from Michael Osipov --- (In reply to Mark Thomas from comment #4) > +1 - we are already using that class in the SPNEGO authenticator I'll try prepare a PR for this. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 67927] TLSCertificateReloadListener triggers race condition (?) in OpenSSL code which causes the JVM to die
https://bz.apache.org/bugzilla/show_bug.cgi?id=67927 --- Comment #11 from Michael Osipov --- (In reply to Mark Thomas from comment #10) > We need to allow in-progress usage of the old SSLContext to continue while > new requests get the new SSLContext. We don't want new requests to have to > wait for a long running request using the old SSLContext to complete. > > I agree we need some locking to make sure the 'current' SSLContext is > updated in a thread-safe manner but I wouldn't classify that as pausing all > requests. That looks to be in place on the Java side. Makes totally sense. Keeping at most two handles. > It is rather hacky but I often find, if I can reproduce the issue, a few > printf statements in the Native code can be very helpful. Had the same idea. Where you able to reproduce it already? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 67628] OpenSSLCipherConfigurationParser#parse() produces misleading false positive cipher warnings
https://bz.apache.org/bugzilla/show_bug.cgi?id=67628 --- Comment #4 from Michael Osipov --- (In reply to Mark Thomas from comment #3) > I think this is a documentation issue. > > The intention was to: > - allow OpenSSL notation to be used with JSSE > - track ciphers and behaviour of latest OpenSSL development branch > - have consistent (as possible) behaviour between JSSE and OpenSSL for the > same cipher definition This makes sense and I totally understand that. > It does this by converting the notation to a list of ciphers and then > passing that to JSSE or OpenSSL. > > That behaviour changes if you use a different version of OpenSSL is > something that I think is good to highlight. > > We could better document this by: > - adding most of the above (not necessarily exactly in that form) to the > docs for ciphers > - amend the log message to note that this is expected if you run on older > JDKs and/or older OpenSSL and reference the cipher docs I think we can do better by supplying "ciphers" to an SSL handle instead of decrypting it on our own and then match. This would reduce the false positive. If SunJSSE/OpenJSSE is used then this remain the same. The mismatch for me does not happen because it matches the latest OpenSSL dev branch, but the comparison is not faire because sources are incorrect. Though, improving docs for people to better understand the warning is always good. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 67793] FORM authenticator does not remember original max inactive interval in all use-cases
https://bz.apache.org/bugzilla/show_bug.cgi?id=67793 --- Comment #1 from Channa --- Hi All, We are also facing same issue, it is same as mail sent to mailing list "us...@tomcat.apache.org" with subject "Tomcat 9.0.75 ignoring session timeout configured in tomcat conf web.xml" Details Below == Tomcat Version : 9.0.75 Operating System: Windows and Linux Bits: 64 Tomcat 9.0.75 not honoring session timeout configured in tomcat/conf/web.xml for FORM Authentication and it is effecting customers. == 30 // 30 minutes = Verified the Tomcat source code - FormAuthenticator overriding above configured session timeout setting (30 minutes) with value (120 seconds) - As per FormAuthenticator.Java, this change/issue started from Tomcat Version : 9.0.74 for FORM Authentication and it overwrites the original session-timeout value - This issue/behavior not observed in 9.0.73 Verified the Tomcat documentation - Verified the tomcat changelog, there is a fix/change went in Tomcat 9.0.74 below related to FORM Based Authentication Session @ https://tomcat.apache.org/tomcat-9.0-doc/changelog.html, looks which is causing this issue. -- Harden the FORM authentication process against DoS attacks by using a reduced session timeout if the FORM authentication process creates a session. The duration of this timeout is configured by the authenticationSessionTimeout attribute of the FORM authenticator. (markt) - Could you please fix this bug and help. Thanks Channa -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 67793] FORM authenticator does not remember original max inactive interval in all use-cases
https://bz.apache.org/bugzilla/show_bug.cgi?id=67793 --- Comment #2 from Mircea Butmalai --- Hi Channa, Yes it is the same issue and the proposed code correction (or any equivalent form) actually solves your problem too. The proposed code correction actually preserves the added functionality documented as "Harden the FORM authentication process against DoS attacks" and solves the problem of honoring the session timeout configuration from web.xml. I am also waiting that proposed code correction (or any equivalent form) to reach all maintained branches of Tomcat (8.5.x, 9.0.x, 10.1.x and main = 11.x) that have this problem. Thanks, Mircea -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 67934] APR connectors will fail to load when tcnative-1 and tcnative-2 are installed in parallel
https://bz.apache.org/bugzilla/show_bug.cgi?id=67934 Michael Osipov changed: What|Removed |Added CC||micha...@apache.org -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 67934] New: APR connectors will fail to load when tcnative-1 and tcnative-2 are installed in parallel
https://bz.apache.org/bugzilla/show_bug.cgi?id=67934
Bug ID: 67934
Summary: APR connectors will fail to load when tcnative-1 and
tcnative-2 are installed in parallel
Product: Tomcat 9
Version: 9.0.x
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Connectors
Assignee: dev@tomcat.apache.org
Reporter: micha...@apache.org
Target Milestone: -
Note: This applies to both 8.5.x and 9.0.x.
Since tcnative 1.x and 2.x can be installed side by side:
> root@deblndw011x:/tmp/local/lib
> # ll
> total 19576
> drwxr-xr-x 2 osipovmi wheel 512 2023-10-12 17:24 engines-3/
> -rw-r--r-- 1 osipovmi wheel 8917782 2023-10-12 17:24 libcrypto.a
> lrwxr-xr-x 1 osipovmi wheel 14 2023-10-12 17:24 libcrypto.so@ ->
> libcrypto.so.3
> -rwxr-xr-x 1 osipovmi wheel 5050168 2023-10-12 17:24 libcrypto.so.3*
> -rw-r--r-- 1 osipovmi wheel 1328044 2023-10-12 17:24 libssl.a
> lrwxr-xr-x 1 osipovmi wheel 11 2023-10-12 17:24 libssl.so@ ->
> libssl.so.3
> -rwxr-xr-x 1 osipovmi wheel 783496 2023-10-12 17:24 libssl.so.3*
> -rw-r--r-- 1 osipovmi wheel 1701660 2023-10-27 12:57 libtcnative-1.a
> -rwxr-xr-x 1 osipovmi wheel 1052 2023-10-27 12:57 libtcnative-1.la*
> lrwxr-xr-x 1 osipovmi wheel 23 2023-10-27 12:57 libtcnative-1.so@ ->
> libtcnative-1.so.0.2.40
> lrwxr-xr-x 1 osipovmi wheel 23 2023-10-27 12:57 libtcnative-1.so.0@
> -> libtcnative-1.so.0.2.40
> -rwxr-xr-x 1 osipovmi wheel 975800 2023-10-27 12:57
> libtcnative-1.so.0.2.40*
> -rw-r--r-- 1 osipovmi wheel 567160 2023-10-27 10:39 libtcnative-2.a
> -rwxr-xr-x 1 osipovmi wheel 1050 2023-10-27 10:39 libtcnative-2.la*
> lrwxr-xr-x 1 osipovmi wheel 22 2023-10-27 10:39 libtcnative-2.so@ ->
> libtcnative-2.so.0.0.7
> lrwxr-xr-x 1 osipovmi wheel 22 2023-10-27 10:39 libtcnative-2.so.0@
> -> libtcnative-2.so.0.0.7
> -rwxr-xr-x 1 osipovmi wheel 361312 2023-10-27 10:39
> libtcnative-2.so.0.0.7*
> drwxr-xr-x 2 osipovmi wheel 512 2023-10-12 17:24 ossl-modules/
> drwxr-xr-x 2 osipovmi wheel 512 2023-10-12 17:24 pkgconfig/
or on Windows:
> PS C:\Temp\apache-tomcat-9.0.83-dev\bin> gci -include *.dll
> PS C:\Temp\apache-tomcat-9.0.83-dev\bin> gci -Path *.dll
>
> Directory: C:\Temp\apache-tomcat-9.0.83-dev\bin
>
> Mode LastWriteTime Length Name
> - --
> -a--- 2023-09-2814:253577344 tcnative-1.dll
> -a--- 2023-09-2716:243424256 tcnative-2.dll
Now let's start Tomcat 9 with APR connector configured. Library.java will use:
> private static final String [] NAMES = {"tcnative-2", "libtcnative-2",
> "tcnative-1", "libtcnative-1"};
Result:
> 27-Oct-2023 13:11:18.029 INFORMATION [main]
> org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler
> ["https-openssl-apr-30001"]
> 27-Oct-2023 13:11:18.033 SCHWERWIEGEND [main]
> org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
> initialize component [Connector["https-openssl-apr-30001"]]
> java.lang.UnsatisfiedLinkError:
> org.apache.tomcat.jni.Address.info(Ljava/lang/String;IIIJ)J
> at org.apache.tomcat.jni.Address.info(Native Method)
> at
> org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:361)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1326)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1339)
> at
> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:654)
> at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:75)
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1009)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:554)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1039)
> at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
> at
> org.apache.catalina.startup.Catalina.load(Catalina.java:724)
> at
> org.apache.catalina.startup.Catalina.load(Catalina.java:746)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method
(tomcat) branch main updated: Fix resolver count
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new becb942dec Fix resolver count
becb942dec is described below
commit becb942decea57fb37073f2e4cee164199e754c5
Author: remm
AuthorDate: Fri Oct 27 13:36:37 2023 +0200
Fix resolver count
---
test/org/apache/jasper/el/TestJasperELResolver.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/org/apache/jasper/el/TestJasperELResolver.java
b/test/org/apache/jasper/el/TestJasperELResolver.java
index ca15a25055..3d93d11f55 100644
--- a/test/org/apache/jasper/el/TestJasperELResolver.java
+++ b/test/org/apache/jasper/el/TestJasperELResolver.java
@@ -33,7 +33,7 @@ import org.apache.jasper.runtime.JspRuntimeLibrary;
public class TestJasperELResolver {
-private static final int STANDARD_RESOLVERS_COUNT = 11;
+private static final int STANDARD_RESOLVERS_COUNT = 12;
@Test
public void testConstructorNone() throws Exception {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch main updated: Using cleanups here to improve safety
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new fd0d1d0273 Using cleanups here to improve safety
fd0d1d0273 is described below
commit fd0d1d0273040e49129c81d07bb28472f6e027f8
Author: remm
AuthorDate: Fri Oct 27 14:32:37 2023 +0200
Using cleanups here to improve safety
Otherwise, the segments are still alive after the actual free operation.
This way the check will fail before the actual deallocation.
---
.../util/net/openssl/panama/OpenSSLContext.java| 27 +-
.../util/net/openssl/panama/OpenSSLEngine.java | 24 +++
2 files changed, 31 insertions(+), 20 deletions(-)
diff --git a/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
b/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
index ac1561639f..1820db64ad 100644
--- a/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
+++ b/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
@@ -43,6 +43,7 @@ import java.util.Base64;
import java.util.Iterator;
import java.util.List;
import java.util.concurrent.ConcurrentHashMap;
+import java.util.function.Consumer;
import javax.net.ssl.KeyManager;
import javax.net.ssl.SSLEngine;
@@ -1461,9 +1462,20 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
this.negotiableProtocols = negotiableProtocols;
// Use another arena to avoid keeping a reference through segments
// This also allows making further accesses to the main pointers
safer
-this.sslCtx = sslCtx.reinterpret(ValueLayout.ADDRESS.byteSize(),
stateArena, null);
+this.sslCtx = sslCtx.reinterpret(ValueLayout.ADDRESS.byteSize(),
stateArena,
+new Consumer() {
+@Override
+public void accept(MemorySegment t) {
+SSL_CTX_free(t);
+}});
if (!MemorySegment.NULL.equals(confCtx)) {
-this.confCtx =
confCtx.reinterpret(ValueLayout.ADDRESS.byteSize(), stateArena, null);
+this.confCtx =
confCtx.reinterpret(ValueLayout.ADDRESS.byteSize(), stateArena,
+new Consumer() {
+@Override
+public void accept(MemorySegment t) {
+SSL_CONF_CTX_free(t);
+}
+});
} else {
this.confCtx = null;
}
@@ -1471,15 +1483,8 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
@Override
public void run() {
-try {
-states.remove(Long.valueOf(sslCtx.address()));
-SSL_CTX_free(sslCtx);
-if (confCtx != null) {
-SSL_CONF_CTX_free(confCtx);
-}
-} finally {
-stateArena.close();
-}
+states.remove(Long.valueOf(sslCtx.address()));
+stateArena.close();
}
}
}
diff --git a/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
b/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
index 4ef4f41c12..bd23503956 100644
--- a/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
+++ b/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
@@ -47,6 +47,7 @@ import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;
+import java.util.function.Consumer;
import javax.net.ssl.SSLEngine;
import javax.net.ssl.SSLEngineResult;
@@ -1740,19 +1741,24 @@ public final class OpenSSLEngine extends SSLEngine
implements SSLUtil.ProtocolIn
this.noOcspCheck = noOcspCheck;
// Use another arena to avoid keeping a reference through segments
// This also allows making further accesses to the main pointers
safer
-this.ssl = ssl.reinterpret(ValueLayout.ADDRESS.byteSize(),
stateArena, null);
-this.networkBIO =
networkBIO.reinterpret(ValueLayout.ADDRESS.byteSize(), stateArena, null);
+this.ssl = ssl.reinterpret(ValueLayout.ADDRESS.byteSize(),
stateArena,
+new Consumer() {
+@Override
+public void accept(MemorySegment t) {
+SSL_free(t);
+}});
+this.networkBIO =
networkBIO.reinterpret(ValueLayout.ADDRESS.byteSize(), stateArena,
+new Consumer() {
+@Override
+public void accept(MemorySegment t) {
+BIO_free(t);
+}});
}
@Override
public void run() {
-
(tomcat) branch 10.1.x updated: Using cleanups here to improve safety
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.1.x by this push:
new 7ed0893eb5 Using cleanups here to improve safety
7ed0893eb5 is described below
commit 7ed0893eb50cd87a4db32dd3246b288d112062ab
Author: remm
AuthorDate: Fri Oct 27 14:39:08 2023 +0200
Using cleanups here to improve safety
Otherwise, the segments are still alive after the actual free operation.
This way the check will fail before the actual deallocation.
---
.../util/net/openssl/panama/OpenSSLContext.java| 27 +-
.../util/net/openssl/panama/OpenSSLEngine.java | 24 +++
2 files changed, 31 insertions(+), 20 deletions(-)
diff --git
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
index 65de58247e..81100fc323 100644
---
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
+++
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
@@ -43,6 +43,7 @@ import java.util.Base64;
import java.util.Iterator;
import java.util.List;
import java.util.concurrent.ConcurrentHashMap;
+import java.util.function.Consumer;
import javax.net.ssl.KeyManager;
import javax.net.ssl.SSLEngine;
@@ -1458,9 +1459,20 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
this.negotiableProtocols = negotiableProtocols;
// Use another arena to avoid keeping a reference through segments
// This also allows making further accesses to the main pointers
safer
-this.sslCtx = sslCtx.reinterpret(ValueLayout.ADDRESS.byteSize(),
stateArena, null);
+this.sslCtx = sslCtx.reinterpret(ValueLayout.ADDRESS.byteSize(),
stateArena,
+new Consumer() {
+@Override
+public void accept(MemorySegment t) {
+SSL_CTX_free(t);
+}});
if (!MemorySegment.NULL.equals(confCtx)) {
-this.confCtx =
confCtx.reinterpret(ValueLayout.ADDRESS.byteSize(), stateArena, null);
+this.confCtx =
confCtx.reinterpret(ValueLayout.ADDRESS.byteSize(), stateArena,
+new Consumer() {
+@Override
+public void accept(MemorySegment t) {
+SSL_CONF_CTX_free(t);
+}
+});
} else {
this.confCtx = null;
}
@@ -1468,15 +1480,8 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
@Override
public void run() {
-try {
-states.remove(Long.valueOf(sslCtx.address()));
-SSL_CTX_free(sslCtx);
-if (confCtx != null) {
-SSL_CONF_CTX_free(confCtx);
-}
-} finally {
-stateArena.close();
-}
+states.remove(Long.valueOf(sslCtx.address()));
+stateArena.close();
}
}
}
diff --git
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
index 4ef4f41c12..bd23503956 100644
---
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
+++
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
@@ -47,6 +47,7 @@ import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;
+import java.util.function.Consumer;
import javax.net.ssl.SSLEngine;
import javax.net.ssl.SSLEngineResult;
@@ -1740,19 +1741,24 @@ public final class OpenSSLEngine extends SSLEngine
implements SSLUtil.ProtocolIn
this.noOcspCheck = noOcspCheck;
// Use another arena to avoid keeping a reference through segments
// This also allows making further accesses to the main pointers
safer
-this.ssl = ssl.reinterpret(ValueLayout.ADDRESS.byteSize(),
stateArena, null);
-this.networkBIO =
networkBIO.reinterpret(ValueLayout.ADDRESS.byteSize(), stateArena, null);
+this.ssl = ssl.reinterpret(ValueLayout.ADDRESS.byteSize(),
stateArena,
+new Consumer() {
+@Override
+public void accept(MemorySegment t) {
+SSL_free(t);
+}});
+this.networkBIO =
networkBIO.reinterpret(ValueLayout.A
(tomcat) branch 9.0.x updated: Using cleanups here to improve safety
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new ed195d2ff8 Using cleanups here to improve safety
ed195d2ff8 is described below
commit ed195d2ff831857bc583b7dbdecaab1fc19ca7fc
Author: remm
AuthorDate: Fri Oct 27 14:39:08 2023 +0200
Using cleanups here to improve safety
Otherwise, the segments are still alive after the actual free operation.
This way the check will fail before the actual deallocation.
---
.../util/net/openssl/panama/OpenSSLContext.java| 27 +-
.../util/net/openssl/panama/OpenSSLEngine.java | 24 +++
2 files changed, 31 insertions(+), 20 deletions(-)
diff --git
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
index 65de58247e..81100fc323 100644
---
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
+++
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLContext.java
@@ -43,6 +43,7 @@ import java.util.Base64;
import java.util.Iterator;
import java.util.List;
import java.util.concurrent.ConcurrentHashMap;
+import java.util.function.Consumer;
import javax.net.ssl.KeyManager;
import javax.net.ssl.SSLEngine;
@@ -1458,9 +1459,20 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
this.negotiableProtocols = negotiableProtocols;
// Use another arena to avoid keeping a reference through segments
// This also allows making further accesses to the main pointers
safer
-this.sslCtx = sslCtx.reinterpret(ValueLayout.ADDRESS.byteSize(),
stateArena, null);
+this.sslCtx = sslCtx.reinterpret(ValueLayout.ADDRESS.byteSize(),
stateArena,
+new Consumer() {
+@Override
+public void accept(MemorySegment t) {
+SSL_CTX_free(t);
+}});
if (!MemorySegment.NULL.equals(confCtx)) {
-this.confCtx =
confCtx.reinterpret(ValueLayout.ADDRESS.byteSize(), stateArena, null);
+this.confCtx =
confCtx.reinterpret(ValueLayout.ADDRESS.byteSize(), stateArena,
+new Consumer() {
+@Override
+public void accept(MemorySegment t) {
+SSL_CONF_CTX_free(t);
+}
+});
} else {
this.confCtx = null;
}
@@ -1468,15 +1480,8 @@ public class OpenSSLContext implements
org.apache.tomcat.util.net.SSLContext {
@Override
public void run() {
-try {
-states.remove(Long.valueOf(sslCtx.address()));
-SSL_CTX_free(sslCtx);
-if (confCtx != null) {
-SSL_CONF_CTX_free(confCtx);
-}
-} finally {
-stateArena.close();
-}
+states.remove(Long.valueOf(sslCtx.address()));
+stateArena.close();
}
}
}
diff --git
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
index 4ef4f41c12..bd23503956 100644
---
a/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
+++
b/modules/openssl-foreign/src/main/java/org/apache/tomcat/util/net/openssl/panama/OpenSSLEngine.java
@@ -47,6 +47,7 @@ import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;
+import java.util.function.Consumer;
import javax.net.ssl.SSLEngine;
import javax.net.ssl.SSLEngineResult;
@@ -1740,19 +1741,24 @@ public final class OpenSSLEngine extends SSLEngine
implements SSLUtil.ProtocolIn
this.noOcspCheck = noOcspCheck;
// Use another arena to avoid keeping a reference through segments
// This also allows making further accesses to the main pointers
safer
-this.ssl = ssl.reinterpret(ValueLayout.ADDRESS.byteSize(),
stateArena, null);
-this.networkBIO =
networkBIO.reinterpret(ValueLayout.ADDRESS.byteSize(), stateArena, null);
+this.ssl = ssl.reinterpret(ValueLayout.ADDRESS.byteSize(),
stateArena,
+new Consumer() {
+@Override
+public void accept(MemorySegment t) {
+SSL_free(t);
+}});
+this.networkBIO =
networkBIO.reinterpret(ValueLayout.ADD
Re: [tomcat] branch main updated: Add support to EL for Records
On Wed, Oct 25, 2023 at 4:25 PM wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> markt pushed a commit to branch main
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/main by this push:
> new b7186591a7 Add support to EL for Records
> b7186591a7 is described below
>
> commit b7186591a7364d6493b8ad093432cfbf2c52b1c0
> Author: Mark Thomas
> AuthorDate: Mon Oct 9 15:40:12 2023 -0300
>
> Add support to EL for Records
> + * @return Always {@null}
javadoc does not like this, are we allowed to fix it ?
Rémy
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch main updated: Add support to EL for Records
27 Oct 2023 14:30:25 Rémy Maucherat :
On Wed, Oct 25, 2023 at 4:25 PM wrote:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new b7186591a7 Add support to EL for Records
b7186591a7 is described below
commit b7186591a7364d6493b8ad093432cfbf2c52b1c0
Author: Mark Thomas
AuthorDate: Mon Oct 9 15:40:12 2023 -0300
Add support to EL for Records
+ * @return Always {@null}
javadoc does not like this, are we allowed to fix it ?
Absolutely. I just missed out the code.
Mark
Rémy
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: (tomcat) branch main updated: Fix resolver count
27 Oct 2023 12:37:00 r...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new becb942dec Fix resolver count
becb942dec is described below
commit becb942decea57fb37073f2e4cee164199e754c5
Author: remm
AuthorDate: Fri Oct 27 13:36:37 2023 +0200
Fix resolver count
Thanks for fixing this. I thought I had this locally. I need to double
check what got committed.
Mark
---
test/org/apache/jasper/el/TestJasperELResolver.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/org/apache/jasper/el/TestJasperELResolver.java
b/test/org/apache/jasper/el/TestJasperELResolver.java
index ca15a25055..3d93d11f55 100644
--- a/test/org/apache/jasper/el/TestJasperELResolver.java
+++ b/test/org/apache/jasper/el/TestJasperELResolver.java
@@ -33,7 +33,7 @@ import org.apache.jasper.runtime.JspRuntimeLibrary;
public class TestJasperELResolver {
- private static final int STANDARD_RESOLVERS_COUNT = 11;
+ private static final int STANDARD_RESOLVERS_COUNT = 12;
@Test
public void testConstructorNone() throws Exception {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat-native) branch main updated: Remove an unreachable if condition around CRLs in sslcontext.c
This is an automated email from the ASF dual-hosted git repository.
michaelo pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat-native.git
The following commit(s) were added to refs/heads/main by this push:
new ac6f59b81 Remove an unreachable if condition around CRLs in
sslcontext.c
ac6f59b81 is described below
commit ac6f59b8162c52bc6fe1add64d38af9da9dd9c02
Author: Michael Osipov
AuthorDate: Fri Oct 27 12:52:19 2023 +0200
Remove an unreachable if condition around CRLs in sslcontext.c
SSL_CTX_get_cert_store() will never return NULL because it is initialized at
context creation time with X509_STORE_new() and unless we have set it
explicitly
to NULL with SSL_CTX_set_cert_store().
---
native/src/sslcontext.c | 7 +++
xdocs/miscellaneous/changelog.xml | 3 +++
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/native/src/sslcontext.c b/native/src/sslcontext.c
index b52258914..34669ff70 100644
--- a/native/src/sslcontext.c
+++ b/native/src/sslcontext.c
@@ -611,10 +611,9 @@ TCN_IMPLEMENT_CALL(jboolean, SSLContext,
setCARevocation)(TCN_STDARGS, jlong ctx
return JNI_FALSE;
}
-if (!c->crl) {
-if ((c->crl = SSL_CTX_get_cert_store(c->ctx)) == NULL)
-goto cleanup;
-}
+if (!c->crl)
+c->crl = SSL_CTX_get_cert_store(c->ctx);
+
if (J2S(file)) {
lookup = X509_STORE_add_lookup(c->crl, X509_LOOKUP_file());
if (lookup == NULL) {
diff --git a/xdocs/miscellaneous/changelog.xml
b/xdocs/miscellaneous/changelog.xml
index c5ea8ce09..ffd0e10f5 100644
--- a/xdocs/miscellaneous/changelog.xml
+++ b/xdocs/miscellaneous/changelog.xml
@@ -56,6 +56,9 @@
Add Ant version (1.10.2) requirement identical to Tomcat. (michaelo)
+
+ Remove an unreachable if condition around CRLs in sslcontext.c.
(michaelo)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat-native) branch 1.2.x updated: Remove an unreachable if condition around CRLs in sslcontext.c
This is an automated email from the ASF dual-hosted git repository.
michaelo pushed a commit to branch 1.2.x
in repository https://gitbox.apache.org/repos/asf/tomcat-native.git
The following commit(s) were added to refs/heads/1.2.x by this push:
new de660b456 Remove an unreachable if condition around CRLs in
sslcontext.c
de660b456 is described below
commit de660b456ec6efdbc03e5c1e7324449756764481
Author: Michael Osipov
AuthorDate: Fri Oct 27 12:52:19 2023 +0200
Remove an unreachable if condition around CRLs in sslcontext.c
SSL_CTX_get_cert_store() will never return NULL because it is initialized at
context creation time with X509_STORE_new() and unless we have set it
explicitly
to NULL with SSL_CTX_set_cert_store().
---
native/src/sslcontext.c | 7 +++
xdocs/miscellaneous/changelog.xml | 3 +++
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/native/src/sslcontext.c b/native/src/sslcontext.c
index 2cde86087..646577e72 100644
--- a/native/src/sslcontext.c
+++ b/native/src/sslcontext.c
@@ -718,10 +718,9 @@ TCN_IMPLEMENT_CALL(jboolean, SSLContext,
setCARevocation)(TCN_STDARGS, jlong ctx
return JNI_FALSE;
}
-if (!c->crl) {
-if ((c->crl = SSL_CTX_get_cert_store(c->ctx)) == NULL)
-goto cleanup;
-}
+if (!c->crl)
+c->crl = SSL_CTX_get_cert_store(c->ctx);
+
if (J2S(file)) {
lookup = X509_STORE_add_lookup(c->crl, X509_LOOKUP_file());
if (lookup == NULL) {
diff --git a/xdocs/miscellaneous/changelog.xml
b/xdocs/miscellaneous/changelog.xml
index 5e3f2ae8f..a7462ec00 100644
--- a/xdocs/miscellaneous/changelog.xml
+++ b/xdocs/miscellaneous/changelog.xml
@@ -41,6 +41,9 @@
Fix version set in DLL header on Windows. (michaelo)
+
+ Remove an unreachable if condition around CRLs in sslcontext.c.
(michaelo)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 67793] FORM authenticator does not remember original max inactive interval in all use-cases
https://bz.apache.org/bugzilla/show_bug.cgi?id=67793 Mircea Butmalai changed: What|Removed |Added CC|mircea.butma...@radcom.ro | -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 67938] New: Tomcat mishandles large client hello messages
https://bz.apache.org/bugzilla/show_bug.cgi?id=67938 Bug ID: 67938 Summary: Tomcat mishandles large client hello messages Product: Tomcat 10 Version: 10.1.15 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Connectors Assignee: dev@tomcat.apache.org Reporter: aogb...@redhat.com Target Milestone: -- A java client application running previously with java 11 began seeing handshake failures with Tomcat 10.1 when the client app moved to java 17. OpenJDK engineers reviewed and based on the evidence gathered so far and after a static code analysis, we think that there is a problem in how Apache Tomcat handles TLS handshakes containing large Client Hello packets. We know that versions 10.1.9 to 10.1.15 are affected, but have not looked into other major releases. What follows is a high-level overview of the events that are happening, in our understanding, when the failure manifests: 1) The TLS client sends a Client Hello packet to resume a TLS 1.3 session. The packet is so large (26,660 bytes) that it has to be split into 2 TLS record messages. This splitting occurs at the TLS level, above any possible TCP fragmentation. The first TLS record has a length of 16,372 bytes and the second a length of 10,298 bytes (5 bytes of each TLS record are for the header, and the rest accounts for the Client Hello payload). 2) The method org.apache.tomcat.util.SecureNioChannel::handshake handles the incoming connection, on the TLS server side [1]. In particular, org.apache.tomcat.util.SecureNioChannel::processSNI is called first to peek at the incoming data and check, for example, if the SNI TLS extension is present [2]. 3) The most relevant outcomes of the org.apache.tomcat.util.SecureNioChannel::processSNI call are: 3.1) The SNI TLS extension is not present. This was probably decided here [3] because the Client Hello didn't fit into a single TLS record. SNI was not present anyways. 3.2) A new SSLEngine instance is created for the incoming connection. 3.3) The netInBuffer ByteBuffer is filled with bytes from the first TLS record sent by the client, and might include some but not all the bytes from the second TLS record. This is because netInBuffer is initialized to a default size of 16,921 bytes, and both TLS records total 26,670 bytes. netInBuffer is expanded to sslEngine.getSession().getPacketBufferSize() after a read from the network [4] but in practice, because there was no data passed to the SSLEngine yet, this is probably 16,709 bytes (max record size, taken from SSLRecord.maxRecordSize). Expanding to a smaller length has no effect. As a result, netInBuffer has a likely size of 16,921 bytes and is completely full of data. 3.4) netInBuffer is assumed to be in a write-ready state at this point, which means that position is set to the end of the filled data, limit is set to capacity, and more bytes can be appended. However, if it's completely full as assumed in #3.3, position would then be equal to limit (which is, in turn, equal to capacity) and more bytes cannot be appended. 4) When returning from org.apache.tomcat.util.SecureNioChannel::processSNI to org.apache.tomcat.util.SecureNioChannel::handshake, the field sniComplete is set to true reflecting that no further calls to ::processSNI are needed for this connection. Execution moves to org.apache.tomcat.util.SecureNioChannel::handshakeUnwrap because the initial state for a SSLEngine is NEED_UNWRAP [5]. 5) Once in org.apache.tomcat.util.SecureNioChannel::handshakeUnwrap, the "netInBuffer.position() == netInBuffer.limit()" condition evaluates to true [6] and the ByteBuffer::clear method is called on netInBuffer. Position is set to 0 and limit to capacity. As a result, any write to netInBuffer will overwrite unprocessed data. This unprocessed data is the first TLS record and part of the second TLS record, depending on how much is written. 6) More bytes are read into netInBuffer here [7]. Bytes read are probably the remainder of the second TLS record —we know that it's after the TLS record header and that it's at least 5 bytes long—, and the overwrite occurs as anticipated in #5. Data in netInBuffer is now corrupt. 7) The netInBuffer buffer is flipped to a read-ready state [8]. Thus, limit is set to the last position after the overwrite and position is set to 0. 8) netInBuffer is passed to the SSLEngine for unwrapping. The SSLEngine finds data at the beginning of the buffer that does not correspond to the beginning of a TLS record, and fails throwing the exception shown in the server log. We think that this error may not show up consistently due to network/OS timing conditions. Different JDK releases, server configurations and TLS protocol versions may also affect the length of the Client Hello message and have an impact on reproducibility. The reason why Client Hello messages for resumption are lar
[Bug 67938] Tomcat mishandles large client hello messages
https://bz.apache.org/bugzilla/show_bug.cgi?id=67938 --- Comment #1 from Aaron Ogburn --- A backport (https://bugs.openjdk.org/browse/JDK-8318950) is being pursued to reduce the message size from a client in such a case on OpenJDK 17. But a Tomcat level fix may still be required in the end for a large message in some other scenario. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 67938] Tomcat mishandles large client hello messages
https://bz.apache.org/bugzilla/show_bug.cgi?id=67938 --- Comment #2 from Aaron Ogburn --- Source code references pertaining to the above: [1] - https://github.com/apache/tomcat/blob/10.1.9/java/org/apache/tomcat/util/net/SecureNioChannel.java#L147 [2] - https://github.com/apache/tomcat/blob/10.1.9/java/org/apache/tomcat/util/net/SecureNioChannel.java#L248 [3] - https://github.com/apache/tomcat/blob/10.1.9/java/org/apache/tomcat/util/net/TLSClientHelloExtractor.java#L112 [4] - https://github.com/apache/tomcat/blob/10.1.9/java/org/apache/tomcat/util/net/SecureNioChannel.java#L322 [5] - https://github.com/apache/tomcat/blob/10.1.9/java/org/apache/tomcat/util/net/SecureNioChannel.java#L460 [6] - https://github.com/apache/tomcat/blob/10.1.9/java/org/apache/tomcat/util/net/SecureNioChannel.java#L462 [7] - https://github.com/apache/tomcat/blob/10.1.9/java/org/apache/tomcat/util/net/SecureNioChannel.java#L468 [8] - https://github.com/apache/tomcat/blob/10.1.9/java/org/apache/tomcat/util/net/SecureNioChannel.java#L478 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 67938] Tomcat mishandles large client hello messages
https://bz.apache.org/bugzilla/show_bug.cgi?id=67938 --- Comment #3 from Aaron Ogburn --- Credit and thanks to Francisco Ferrari and Martin Balao from the OpenJDK engineering team for their analysis leading to this report. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
