R: PKCS#8 encryption algorithm unrecognized
> I got the Object ID and version straight out of the Certificate using > Keystore Explorer. I'm not sure why there is a difference. Keystore Explorer uses Bouncy Castle (https://www.bouncycastle.org/) as provider for JCE. If your JRE/JDK does not provide some algorithm you could use Bouncy Castle as well. Regards, Roberto - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
R: Tomcat Instance unable to connect to DB with TCPS
Hello, it seems you have changed the default Java trust store, so you also need to provide its password. You should provide more info about your requirements: - server authentication only or client authentication too (mTLS in Oracle documentation)? - which version of ucp/ojdbc are you using (Oracle adds features over time)? In my experience if you only need server authentication and you are using driver version 11.2 or later, the only configuration required is: - change protocol and port in the URL or tnsnames.ora file - add the certificate of root (issuer) CA to Java trust store If you are using a Java version provided by RedHat then adding the certificate is simply as copying the certificate file to /usr/share/pki/ca-trust-source/anchors/ and run update-ca-trust [1]. If client authentication (mTLS) is required then you must prepare a wallet and add extra jars to your deployment [2]. Roberto [1] https://access.redhat.com/documentation/it-it/red_hat_enterprise_linux/7/html/security_guide/sec-shared-system-certificates [2] https://docs.oracle.com/en/database/oracle/oracle-database/19/jjdbc/client-side-security.html#GUID-2BD2F189-A58C-4A85-8524-CFD9BB9AC575 -Messaggio originale- Da: Mark Thomas Inviato: venerdì 9 febbraio 2024 10:09 A: users@tomcat.apache.org Oggetto: Re: Tomcat Instance unable to connect to DB with TCPS CAUTION - This e-mail originates outside of Dedalus. Be vigilant with content, links and attachments! On 09/02/2024 02:54, Kebret, Michael wrote: > Tomcat version 9.0.83 running on Linux redhat 7 java 11.0.20. > > When changing the protocol from TCP to TCPS in Catalina.properties and in > server.xml we have attribute truststorePassword= (tested with both cleartext > and encrypted) password connection is refused to the DB and get the below > exceptions. It isn't clear what configuration you are using. Please provide both the non-TLS and TLS configurations. > However, when we add -Djavax.net.ssl.trustStorePassword=cleartext to > setenv.sh the connection is made successfully. Wanted to see if anyone > has faced something similar or have any suggestions on how I can get > TCPS working without having to use -D option in setenv.sh My reading of [1] is that the property name is "javax.net.ssl.trustStorePassword" whether it is set as a connection property or as a system property. You seem to be using a connection property of "truststorePassword" which is a Tomcat property for HTTPS connections. Mark [1] https://www.oracle.com/docs/tech/wp-oracle-jdbc-thin-ssl.pdf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
R: HSTS on 401 / error pages
If you have a fronting reverse proxy/load balancer (HAProxy, NGINX, Apache) you can use them to set HSTS and let Tomcat set the other security headers. If your application is running in a container (Kubernetes, Openshift, OKD), they all have the option to add HSTS in Ingress/Route. Again, the other security options are left to Tomcat. We had the same issue and that's how we passed the pen-test. Roberto -Messaggio originale- Da: Peter Kreuser Inviato: venerdì 15 settembre 2023 21:34 A: Tomcat Users List Oggetto: Re: HSTS on 401 / error pages CAUTION - This e-mail originates outside of Dedalus. Be vigilant with content, links and attachments! d) !!! BTW: HSTS needs to be evaluated only once and then sticks in the browser! So unless the 401 is the first page ever, this change would not be really necessary. Peter > Am 15.09.2023 um 17:58 schrieb Thomas Hoffmann (Speed4Trade GmbH) > : > > Hello Christ, > >> -Ursprüngliche Nachricht- >> Von: Christopher Schultz >> Gesendet: Freitag, 15. September 2023 17:15 >> An: users@tomcat.apache.org >> Betreff: Re: AW: HSTS on 401 / error pages >> >> Thomas, >> >>> On 9/14/23 10:03, Thomas Hoffmann (Speed4Trade GmbH) wrote: >>> Hello Chris, >>> -Ursprüngliche Nachricht- Von: Christopher Schultz Gesendet: Donnerstag, 14. September 2023 15:26 An: users@tomcat.apache.org Betreff: Re: HSTS on 401 / error pages Thomas, Please start a new thread next time. >>> >>> Sorry, I thought removing all content and subject is sufficient. >>> Maybe the message-id header is used internally(?) >> >> Absolutely. That's what "reply" does on a mailing list... >> >>> On 9/14/23 02:20, Thomas Hoffmann (Speed4Trade GmbH) wrote: > Hello everyone, > > I would like to get your opinion about the > HttpHeaderSecurityFilter in Tomcat. > I configured HSTS in Tomcat and it works well. > When I do a pen-test with burpsuite it complains that HSTS header > is missing on 401 responses. > I couldn’t find much information about whether HSTS makes sense > for error pages. > > It seems that Tomcat doesn’t send HSTS on 401 pages but > burpsuite expects the header. > Are there any pros and cons about sending HSTS on 401 response? You should always return an HSTS header. How have you configured your HttpHeaderSecurityFilter? What is causing the 401 response? Which application is responding with that status? -chris >>> >>> Here are the requested details: >>> >>> SecurityFilter is set in the web.xml of the application: >>> >>>httpHeaderSecurity >>>> class>org.apache.catalina.filters.HttpHeaderSecurityFilter> class>ass> >>>true >>> >>> hstsEnabled >>> true >>> >>> ... >>> >>> Further down in the web.xml is a constraint: >>> >>> >>> xxx >>> /* >>> >>> >>> >>> yyy >>> >>> >>> >>> CONFIDENTIAL >>> >>> >>> >>> >>> There is no frontend-server, tomcat is directly accessed from the browser. >>> It seems that burpsuite didn’t send authentication in the first >>> place and this >> resulted in 401. >>> >>> If I use curl https:/// I get similar result: >>> < HTTP/1.1 401 >>> < WWW-Authenticate: Negotiate >>> < Content-Type: text/html;charset=utf-8 < Content-Language: de < >>> Content-Length: 439 < Date: Thu, 14 Sep 2023 13:58:10 GMT >>> >>> When providing credentials to curl, the following headers are also included: >>> < Strict-Transport-Security: max-age=31536000;includeSubDomains >>> < X-Frame-Options: DENY >>> < X-Content-Type-Options: nosniff >>> < X-XSS-Protection: 1; mode=block >>> >>> I hope this information helps. >> >> Authentication is checked before any filters run, because >> authentication is performed by a Valve, all of which run before any Filters >> run. >> >> I'm not sure there is a way around this without >> >> a. Using a fronting server of some kind b. Getting a change of some >> kind made to Tomcat c. Hacking this yourself >> >> (b) is probably the best option, though I'm not sure what the best >> form of server-support for this would be. >> >> Making HttpHeaderSecurity available in a Valve-packaging would do the >> trick, but maybe this makes sense to add at a more fundamental level to >> Tomcat. >> The problem is that HSTS is only one of many security-related headers >> and maybe it's potential lifetime isn't that long. My guess is that >> sometime in the near future, TLS will simply be required for all web >> traffic. If we bake that kind of thing into core-Tomcat, it becomes >> something we will need to un- bake in the future, and chefs can tell >> you that un-baking things rarely works out well. >> >> -chris >> >> - >
R: Subclassing JNDIRealm to return a custom Principal
I was aware of your PR and it's good news. Our Principal implementation differs from the PR: - attribute values are strings and some specific conversion are performed (e.g. converting objectGUID to canonical UUID) - has other fields/methods we use for OAuth (JASPIC) authentication I think that some refactoring could make it easier to subclass Tomcat realms to return a custom Principal. -Messaggio originale- Da: Carsten Klein Inviato: lunedì 21 giugno 2021 19:37 A: users@tomcat.apache.org Oggetto: Re: Subclassing JNDIRealm to return a custom Principal Roberto, On 21.06.2021 18:31, Roberto Benedetti wrote: > Hello, > in our product we subclassed JNDIRealm to return a custom Principal with > attributes retrieved from Active Directory (bug 65391 is going to add support > for that). > We overrode authenticate(DirContext, String, String) to retrieve the > attributes and return the custom Principal. > In Tomcat 9.0.39 the method has changed to authenticate(JNDIConnection, > String, String) and we cannot override it to retrieve the attributes because > JNDIConnection.context is not visible to subclasses. > Is there a work-around for that? Couldn't that new feature be an alternative for running your own implementation of the JNDIRealm? https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Ftomcat%2Fpull%2F428data=04%7C01%7Croberto.benedetti%40dedalus.eu%7C75de31b2d3dd4e0ef4ff08d934db3436%7C95c3bdfa4a9db595ff68329945ef%7C0%7C0%7C637598938341356824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=GivsLeZtrxqqEAdzokvlOrppKRvAam%2BoXYrCKlfHYB4%3Dreserved=0 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Subclassing JNDIRealm to return a custom Principal
Hello, in our product we subclassed JNDIRealm to return a custom Principal with attributes retrieved from Active Directory (bug 65391 is going to add support for that). We overrode authenticate(DirContext, String, String) to retrieve the attributes and return the custom Principal. In Tomcat 9.0.39 the method has changed to authenticate(JNDIConnection, String, String) and we cannot override it to retrieve the attributes because JNDIConnection.context is not visible to subclasses. Is there a work-around for that? Thanks, Roberto - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
JASPIC and classloaders
Hello,
I'm developing a ServerAuthModule implementation to use a 3rd party identity
provider with our web applications. Tomcat version is 9.0.35.
The implementation depends on some libraries already packaged with the web
applications.
To avoid conflicts I tried to configure server.loader in catalina.properties
with a directory containing the ServerAuthModule implementation and the
dependencies, but it does not work because classes are not found.
It seems that authenticators and JASPIC classes are loaded by the common
classloader and not the server (catalina) classloader.
Can anyone confirm this?
Is removing those dependencies from web applications and put them in
${tomcat.home}/lib, the only solution?
Roberto
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
detecting oracle connection failures
hi everyone, I'm having problems trying to combine Oracle and Tomcat: if I define a DB connection to a MySQL or Postgres resource, everything works fine and DB failures are properly detected. conversely, if I define an Oracle DataSource, apparently RDBMS or network problems are not detected and my application keeps waiting ad libitum, ignoring the maxWait parameter. my conf: Context Resource name=jdbc/myoracle auth=Container type=javax.sql.DataSource driverClassName=oracle.jdbc.OracleDriver url=jdbc:oracle:thin:@host:port:sid username=username password= maxActive=2 maxIdle=2 maxWait=2000/ !-- WatchedResourceWEB-INF/web.xml/WatchedResource -- /Context my environment: - apache-tomcat-6.0.20 - jdk-1.6.0_14 - ojdbc6.jar (2111220 bytes) is it a driver-specific issue? I couldn't find out any useful (i.e. pastable) hint. is tomcat+oracle such a rare combination? thanks in advance, roberto - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
