Re: SSL - NES / DOMINO
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
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 : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 Name: snoop.jsp snoop.jspType: unspecified type (application/octet-stream) Encoding: quoted-printable -- Andy Armstrong, Tagish
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 : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 snoop.jsp
Re: SSL - NES / DOMINO
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
