-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Alex,
On 12/5/19 18:05, Alex Scheel wrote: > ----- Original Message ----- >> From: "Christopher Schultz" <ch...@christopherschultz.net> To: >> users@tomcat.apache.org Sent: Thursday, December 5, 2019 5:05:42 >> PM Subject: Re: Tomcat - No Fork for debugging? >> > Alex, > > On 12/5/19 15:18, Alex Scheel wrote: >>>> Hi all, >>>> >>>> I've tried searching to no avail. >>>> >>>> I'm working on a(nother) SSL adapter. However, I've had some >>>> issues with it. There's a native component and I'm trying to >>>> tease apart its relationship with why the client won't >>>> handshake. The stack traces aren't overly helpful and I'd >>>> love to attach gdb to this and set a few specific environment >>>> variables. >>>> >>>> Query: >>>> >>>> Does Tomcat have a mode where it won't fork to a different >>>> user and will run with a limited number of threads? That'd >>>> greatly improve my ability to debug. Something similar to >>>> `radiusd -X` or `sshd -d`? > > You can accomplish this in two steps: > > 1. Change your <Connector> to have an <Executor> with only a > single thread, or set maxThreads="1" on the <Connector> if you > aren't separately configuring an <Executor> > > 2. From the command line, run: > > $ bin/catalina.sh run > >> I think that behaves better. Thanks! No problem. > This will run Tomcat directly in the terminal window (or, on > Windows, open a second terminal window where it will run). > > You can see stdout in that terminal, and you can press CTRL-C to > kill the process. > >>>> Rationale: >>>> >>>> NSS has support for logging calls to its PKCS#11 interface to >>>> a file, based on the presence of environment variables. When >>>> I set these environment variables and directly call the JVM >>>> to start Tomcat: >>>> >>>> # java -classpath $CLASSPATH $FLAGS >>>> org.apache.catalina.startup.Bootstrap start >>>> >>>> I see it logging calls when the JDK starts up, but when I hit >>>> it with wget on the TLS port, the resulting PKCS#11 calls >>>> aren't logged. When launching in gdb, I get an error about >>>> /sbin/nologin doesn't understand the -c option, which to me >>>> says that Bootstrap is trying to fork and create a new shell >>>> (I'm running as root in a VM and it wants to launch as the >>>> tomcat user), dropping my environmental variables I want. >>>> >>>> Ideally (for debugging) I'd like to simplify this. Is there a >>>> more direct entry route I can use perhaps? > > Is there a JSSE wrapper for NSS? You can just plug-in the crypto > provider for the SSLContext instead of writing your own connector. > Wait. You said "adapter". What kind of "adapter" are you writing? > >> Ah sorry, my terminology was loose there. I'm writing another >> org.apache.tomcat.util.net.SSLImplementation implementation. >> Heh. > >> I'm the maintainer of JSS, a NSS wrapper in Java. This is mostly >> utilized by the Dogtag project. > >> I also co-maintain TomcatJSS, a JSS adapter for Tomcat < 8.5. >> When used with Tomcat >= 8.5, it uses JSSE's SSLEngine but >> initializes JSS based on configuration in server.xml and use it >> for the keystore. Mostly this is because we've not yet gotten >> around to adding a SSLEngine to JSS (but will likely finish that >> work soon -- JSS was started at Netscape back in the late 90s and >> predated the SSLEngine being added to JVM interfaces in JDK >> version 5). RHEL 7 still ships with Tomcat 7, but RHEL 8 only >> has Tomcat 9, so the hard requirement for a SSLEngine is new. >> We're getting there :) > >> With FIPS certification requirements though, we can't use JSSE >> (since it isn't FIPS certified). I was pretty sure Java's crypto implementation was FIPS certified. I haven't looked in a while, but a quick good search turned up: https://www2.cs.duke.edu/csed/java/jdk1.7/technotes/guides/security/jsse /FIPS.html and https://docs.oracle.com/javase/6/docs/technotes/guides/security/enhancem ents.html That last one suggests that Oracle Java already contains a JSSE provider which uses NSS. DO I misunderstad? >> OpenJDK supports NSS via the Sun-PKCS11 provider and has a >> SSLEngine implementation under the SunJSSE provider. It has some >> restrictions on it that means it can't be used from Tomcat's >> JSSE adapter just by swapping out the provider name (for one, >> wrapping the KeyManager like Tomcat does isn't allowed). Hmm. Maybe there's a better way to do it, then, and you don't have to write so much code. What's the problem with wrapping a KeyManager? >> I was trying to see if the JDK's SSLEngine would work for us. On >> RHEL, we FIPS certify our shipped NSS release so the JDK's >> Sun-PKCS11-NSS-FIPS provider is FIPS certified transitively >> (since it does no crypto... :). Since I'm not a Tomcat developer >> (and am more familiar with TomcatJSS), I stubbed out a new >> SSLImplementation that uses SunJSSE so I could bypass the parts >> of the Tomcat JSSEImplementation that don't work with the JDK >> SunJSSE provider. That sounds like it would work, but also sound like a huge amount of plumbing. What can you tell me about the way Tomcat uses the JSSE API that precludes FIPS support from the existing tools -- including your own JSS? >> However, currently on RHEL the SunJSSE provider is a bit broken, >> so this FIPSImplementation isn't really useful. If you're >> interested, I'd like to get Tomcat to a place where it supports >> FIPS mode JDK without the need for a separate implementation, but >> first I need a working FIPS-mode JDK (currently it doesn't >> handshake)... ...and we're probably going the route of finishing >> JSS anyways. Hmm. Is your goal to get a working JSSE+FIPS implementation specifically with JSS or do you just want to get FIPS working with Tomcat? The OpenSSL provider can be put into FIPS mode, provided that it was build with FIPS support of course. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3qawcACgkQHPApP6U8 pFg1RBAAi1ANc0Bcf9rlZ/QnjWe4QAg3mA/lftAMjI6/l2QIwbIDf7Pt66a/0e2H h/Vzv8xK15+HWovknzrvZrIbHX7duisLeYNV4nV6QCjYeCviiw8ZPTKvrOUcdnfC pvYDyZ+K/lTr2dCSVV94trbzYkexgS5cPS6T4zdZuhszMH8Z6dY/lUj6kl4R9eQt 6meWPzlXljCOxPamJC2XsgM1dmxwz4MCoI46sj6qPvqNPrpglKEZqPytMl3EXZT1 UmEYTglYZLixZL9D56WSzF89FyGKKWyYueqRfaI/iM04tupn7baT+k8SVDroRM4g I7dkIlJUO/t0WpxIEPHRul7dW+R4I/Dr6miAkm/vhKtVMV5n0gsQL5md7G/eOTls 9QJcBZktkzdtvznyBNniMZ3+QFFXZkftuOzB+l3VUwqJ6K0OvtFxMqiy7ET/ZvVA ZOyGKnrmIF+JXne+hOAm5Dj80R1DMQl8oITSY3mc/bRPWo96mdfFlc9SYs8ZiDDG uaxocXWA8zKRrQNQdVkmHmlB2Tr6i4Nz4MulXlhz7FHLXD2J30mrJuaBBYdmS8qk XTlkhflpOsr9hB7GoMkjWcTNjm+mZtcvpLR9p1VJgd5ewounl4d16Az6IphtSyqV wXU3KDJ889TSTLlYJoK/s/FCCFsSCM6E3ER9rVbwJsUXEu7C0ow= =pu3l -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
