tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse JSSE14Support.java
Date Thu, 17 Apr 2003 14:33:28 GMT
billbarker@apache.org wrote:

> billbarker    2003/04/17 01:11:46
> 
>   Modified:    util/java/org/apache/tomcat/util/net/jsse
>   JSSE14Support.java Log:
>   Re-adding logging for client-cert errors (but from warn->debug).
>   
>   The this and the previous patch can be combined by simply lowering the
>   logging level on Http11Processor.
>   
>   I'm strongly -1 on passing untrusted-certs through.  It is easy enough
>   to add the CA to the keystore, and it is a major security hole to except
>   forged certs.

"Easy enough" ??? Maybe if you compare with getting a signed certificate. 

IMO validating the cert and accepting it is the job of whoever uses it.
Tomcat should just pass the cert. If cert-based auth is used, or if some
app just uses the cert to extract user info - this code can validate it.
And it should be able to validate it with it's own rules ( TrustManager ).

The common case is people generating self-signed certs and connecting to
tomcat. Having them to also import the cert in the JVM castore is not that 
easy - and hard to automate ( the JVM is most likely owned by root, tomcat
probably runs as a different user, and code to do this at runtime is not
trivial AFAIK ). 

The major security hole is using non-secure channels because SSL certs are
so difficult. It's bad enough that you can't connect easily do a SSL
connection to tomcat from java without either a FakeTrustManager and hacks
or a signed cert or importing the server cert on each client.


Costin


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message