Hello Chuck,
I have tested on Tomcat 10.1.40 with Native
Library 1.3.1 running on JDK 21.0.7+6. The result is exactly the
same as described before. The connector below works well with client
authentication, until I add the caCertificatePath attribute. There
are no error messages in the logs.
James,
On 5/9/25 1:49 PM, James H. H. Lampert wrote:
On 5/9/25 10:21 AM, Christopher Schultz wrote:
. . .
A lot of this comes from the fact that Tomcat is written in Java which
does not use null-terminated strings. A null byte in a string in Java
is not special in any way, and so it can't be u
Alex,
On 5/9/25 2:11 PM, My Subs wrote:
I have tested on Tomcat 10.1.40 with Native
Library 1.3.1 running on JDK 21.0.7+6. The result is exactly the
same as described before. The connector below works well with client
authentication, until I add the caCertificatePath attribute. There
are no e
Ladies and Gentlemen:
One of the customers whose Tomcat installation we manage brought up the
possible threat of null byte injection.
Is there anything within Tomcat itself that can mitigate this?
Or is it purely something I need to take up with our webapp people?
--
JHHL
--
On Thu, May 8, 2025 at 6:04 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Jakub,
>
> On 5/7/25 3:26 PM, Jakub Królikowski wrote:
> > On Sat, Apr 29, 2017 at 12:01 PM Mark Thomas wrote:
> >
> >> On 28/04/17 17:00, Matt Cosentino wrote:
> >>> Yes, it's other folders within WEB-INF
James,
On 5/9/25 11:43 AM, James H. H. Lampert wrote:
One of the customers whose Tomcat installation we manage brought up the
possible threat of null byte injection.
Is there anything within Tomcat itself that can mitigate this?
Or is it purely something I need to take up with our webapp peop
On 5/9/25 10:21 AM, Christopher Schultz wrote:
. . .
A lot of this comes from the fact that Tomcat is written in Java which
does not use null-terminated strings. A null byte in a string in Java is
not special in any way, and so it can't be used to prematurely terminate
a string that should othe
On 5/9/25 11:37 AM, Christopher Schultz wrote:
So you can either have the C programmers review all their code (which
I would encourage) and/or you could have your Java programmers ensure
nothing potentially-nasty gets passed into the C code. Belt and
suspenders.
I *am* "the C programmers," and