You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by GOMEZ Henri <hg...@slib.fr> on 2001/06/07 22:34:07 UTC
SSL - NES / DOMINO
Hi,
I take a look at NES and the SSL vars are not handled
by this connector.
Idem for DOMINO where some vars are grabbed but not used.
Who know how to get the SSL vars (the following come from apache+mod_ssl) :
SSL_CLIENT_CERT => The client certificat (if user auth used)
SSL_CIPHER => cipher used (ie RC4-MD5)
SSL_SESSION_ID => SSL session ID, a big number unique big SSL
SESSION
SSL_CIPHER_USEKEYSIZE => #bits used in clt<->srv exchange ie: 128
Here is was I got in TC 3.3-M3 (using initial AJP14), with attached
snoop.jsp against Apache 1.3.20/mod_ssl 2.8.4
Request Information
JSP Request Method: GET
Request URI: /examples/jsp/snp/snoop.jsp
Request Protocol: HTTP/1.0
Servlet path: /jsp/snp/snoop.jsp
Path info: null
Path translated: null
Query string: null
Content length: -1
Content type: null
Server name: localhost
Server port: 443
Remote user: null
Remote address: 127.0.0.1
Remote host: localhost
Authorization scheme: null
SSL Client Certificate: null
SSL Cypher Suite: RC4-MD5
SSL Session Id:
9A9F153F57A505AA3FAB648223929413BC035ACE89FF2735138456F7B38B2CAB
SSL Key Size: 128
The browser you are using is Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686)
-
Henri Gomez ___[_]____
EMAIL : hgomez@slib.fr (. .)
PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: SSL - NES / DOMINO
Posted by Andy Armstrong <an...@tagish.com>.
Andy Armstrong wrote:
[snip]
> I've now had a look at the 3.3 source for ajp13 and I think I understand
> the problem. Look at this:
>
> if(s->ssl_cert_len) {
> if(0 != jk_b_append_byte(msg, SC_A_SSL_CERT) ||
> 0 != jk_b_append_string(msg, s->ssl_cert)) {
> jk_log(l, JK_LOG_ERROR,
> "Error ajp13_marshal_into_msgb - Error appending the
> SSL certificates\n");
>
> return JK_FALSE;
> }
> }
>
> I've been assuming that ssl_cert_len and ssl_cert are independent
> variables, and specifically that it's possible, and desirable, to know
> the length of the cert without actually having the cert. However, the
> ajp13 code assumes that if you know the length of the cert you also have
> the cert. If ssl_cert_len != 0 then it assumes that ssl_cert != NULL and
> attempts to send it.
>
> Is this correct? Is it never useful to know the cert's length without
> having the cert itself?
I've now found where Domino stashes the cert/cert length and am now
passing them through to Tomcat. I'll make a new release tomorrow when
I've had a chance to test against an NT Domino server.
Incidentally, is it the case that the SSL Cert contains, in effect,
arbitrary binary data? If so the code I quoted above from ajp13 seems to
be flawed in that it uses jk_b_append_string() (which expects a null
terminated string) to append the cert to the message. If there happens
to be a zero byte in the cert it will be truncated at that point.
--
Andy Armstrong, Tagish
Re: SSL - NES / DOMINO
Posted by Andy Armstrong <an...@tagish.com>.
Andy Armstrong wrote:
[snip]
> There's a bug in the current release of the Domino connector that means
> that it doesn't properly recognise SSL requests, which means it doesn't
> is_ssl in the jk_ws_service structure. I've fixed this now, but I don't
> seem to be able to recover values for ssl_cert, ssl_cipher or
> ssl_session from Domino. I also find that if I these fields are set as
> follows
>
> s->is_ssl = 1; /* i.e. it is an SSL request... */
> s->ssl_cert_len = 128;
> s->ssl_cert = NULL; /* ...but we don't have these values */
> s->ssl_cipher = NULL;
> s->ssl_session = NULL;
>
> I'm getting a null pointer exception in Ajp13ConnectorRequest.java at
> this code:
> case SC_A_SSL_CERT :
> isSSL = true;
> ---> attributes.put("javax.servlet.request.X509Certificate",
> msg.getString());
> break;
>
> It seems that msg.getString() is probably returning a null. This may be
> because I'm working with Tomcat 3.2.1 tonight, so I'm just grabbing a
> copy of 3.3 to see if that problem has been fixed.
I've now had a look at the 3.3 source for ajp13 and I think I understand
the problem. Look at this:
if(s->ssl_cert_len) {
if(0 != jk_b_append_byte(msg, SC_A_SSL_CERT) ||
0 != jk_b_append_string(msg, s->ssl_cert)) {
jk_log(l, JK_LOG_ERROR,
"Error ajp13_marshal_into_msgb - Error appending the
SSL certificates\n");
return JK_FALSE;
}
}
I've been assuming that ssl_cert_len and ssl_cert are independent
variables, and specifically that it's possible, and desirable, to know
the length of the cert without actually having the cert. However, the
ajp13 code assumes that if you know the length of the cert you also have
the cert. If ssl_cert_len != 0 then it assumes that ssl_cert != NULL and
attempts to send it.
Is this correct? Is it never useful to know the cert's length without
having the cert itself?
--
Andy Armstrong, Tagish
Re: SSL - NES / DOMINO
Posted by Andy Armstrong <an...@tagish.com>.
Hi Henri,
GOMEZ Henri wrote:
>
> Hi,
>
> I take a look at NES and the SSL vars are not handled
> by this connector.
>
> Idem for DOMINO where some vars are grabbed but not used.
>
> Who know how to get the SSL vars (the following come from apache+mod_ssl) :
>
> SSL_CLIENT_CERT => The client certificat (if user auth used)
> SSL_CIPHER => cipher used (ie RC4-MD5)
> SSL_SESSION_ID => SSL session ID, a big number unique big SSL
> SESSION
> SSL_CIPHER_USEKEYSIZE => #bits used in clt<->srv exchange ie: 128
There's a bug in the current release of the Domino connector that means
that it doesn't properly recognise SSL requests, which means it doesn't
is_ssl in the jk_ws_service structure. I've fixed this now, but I don't
seem to be able to recover values for ssl_cert, ssl_cipher or
ssl_session from Domino. I also find that if I these fields are set as
follows
s->is_ssl = 1; /* i.e. it is an SSL request... */
s->ssl_cert_len = 128;
s->ssl_cert = NULL; /* ...but we don't have these values */
s->ssl_cipher = NULL;
s->ssl_session = NULL;
I'm getting a null pointer exception in Ajp13ConnectorRequest.java at
this code:
case SC_A_SSL_CERT :
isSSL = true;
---> attributes.put("javax.servlet.request.X509Certificate",
msg.getString());
break;
It seems that msg.getString() is probably returning a null. This may be
because I'm working with Tomcat 3.2.1 tonight, so I'm just grabbing a
copy of 3.3 to see if that problem has been fixed.
Once I've solved this little problem I'll make a new release which
understands SSL.
> Here is was I got in TC 3.3-M3 (using initial AJP14), with attached
> snoop.jsp against Apache 1.3.20/mod_ssl 2.8.4
>
> Request Information
>
> JSP Request Method: GET
> Request URI: /examples/jsp/snp/snoop.jsp
> Request Protocol: HTTP/1.0
> Servlet path: /jsp/snp/snoop.jsp
> Path info: null
> Path translated: null
> Query string: null
> Content length: -1
> Content type: null
> Server name: localhost
> Server port: 443
> Remote user: null
> Remote address: 127.0.0.1
> Remote host: localhost
> Authorization scheme: null
>
> SSL Client Certificate: null
> SSL Cypher Suite: RC4-MD5
> SSL Session Id:
> 9A9F153F57A505AA3FAB648223929413BC035ACE89FF2735138456F7B38B2CAB
> SSL Key Size: 128
>
> The browser you are using is Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686)
>
> -
> Henri Gomez ___[_]____
> EMAIL : hgomez@slib.fr (. .)
> PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
> ------------------------------------------------------------------------
> Name: snoop.jsp
> snoop.jsp Type: unspecified type (application/octet-stream)
> Encoding: quoted-printable
--
Andy Armstrong, Tagish