Eric Rescorla wrote:
>
> "Paul L. Allen" <[EMAIL PROTECTED]> writes:
> > JSSE stores keys and certificates in its own private format managed
> > by a thing called "keytool". In the JSSE documentation, no mention
> > is ever made of a CA. Keys and certs are always generated as needed
> > by keytool. To get my client its certificate, I had the Cylink CA
> > generate a cert, downloaded it into my Netscape browser, exported that
> > to a PKCS12 file, converted that to PEM and then to DER using the
> > openssl x509 command, and then imported it into a JSSE keystore file
> > using the keytool. A similar operation converted the CA's root
> > certificate into a "truststore" file for use by JSSE.
> >
> > I've watched my Java client connecting to my OpenSSL server using
> > ssldump. I can see the server's cert going over to the client. The
> > client does not send its own cert over to the server, and the server
> > confirms that it has not got a cert from the client. The client
> > sends its first line of application data to the server and ssldump
> > successfully decrypts it. The server receives binary garbage, and
> > things unravel from there.
> What do you mean by "the server receives binary garbage"?
The client sends 60 bytes (including the newline) of printable ASCII
using BIO_puts(). The server does a matching BIO_gets(), which hangs
apparently waiting for a newline. I kill the client. The server's
BIO_gets() returns 90 bytes of non-printable binary.
> > Perhaps the client is unhappy with its cert or the CA cert, but
> > these certs (in PEM format) work fine with a test client coded in
> > C. The client and server appear to be successfully negotiating a
> > connection, but data coming out the server end is garbled. The fact
> > that ssldump successfully decrypts data going over the connection
> > suggests that the JSSE side is doing the right thing. But then, why
> > is the JSSE side refusing to send its certificate? Puzzles, puzzles!
> Well, one question is: is the server asking for the client's
> certificate. Does ssldump show a CertificateRequest message
> from the server? In either case, this shouldn't cause
> bad decryption but just a handshake error.
>
> Perhaps an ssldump trace would be helpful to post.
If I'm interpreting the trace right, the server is sending a
CertificateRequest message. Ssldump does successfully decrypt
the line of application data. A typescript of the ssldump session
is attached.
> It's relatively hard to debug JSSE problems because you can't
> debug the code itself. Are you committed to JSSE or have you
> considered PureTLS?
The guy who wrote the Java code probably picked JSSE because it was
included with the JDK. I'll ask him if he's aware of PureTLS.
Thanks for your thoughts.
Paul Allen
--
Boeing Phantom Works \ Paul L. Allen, (425) 865-3297
Math & Computing Technology \ [EMAIL PROTECTED]
POB 3707 M/S 7L-40, Seattle, WA 98124-2207 \ Prototype Systems Group
Script started on Mon Aug 26 11:01:24 2002
]0;paula@bluesky:~/projects/policy_language/policy_parser[paula@bluesky
policy_parser]$ ssldump -d -N -i lo -k server.pem port 4434
Enter PEM pass phrase:
New TCP connection #1: bluesky.rt.cs.boeing.com(34735) <->
bluesky.rt.cs.boeing.com(4434)
1 1 0.0800 (0.0800) C>S SSLv2 compatible client hello
Version 3.1
cipher suites
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
SSL2_CK_RC4
TLS_RSA_WITH_DES_CBC_SHA
SSL2_CK_DES
TLS_RSA_WITH_3DES_EDE_CBC_SHA
SSL2_CK_3DES
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
SSL2_CK_RC4_EXPORT40
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
1 2 0.1000 (0.0200) S>C Handshake
ServerHello
Version 3.1
session_id[32]=
1c f6 89 06 3c 92 37 55 de 33 65 0f b6 7d 55 99
f0 02 b7 62 3a 62 4c 07 40 76 ca af ed f2 e4 e2
cipherSuite TLS_RSA_WITH_RC4_128_SHA
compressionMethod NULL
1 3 0.1000 (0.0000) S>C Handshake
Certificate
Subject
C=US
ST=WA
L=Bellevue
O=Phantom Works
OU=mct
CN=webtest.i2net.phantomworks.org
[EMAIL PROTECTED]
Issuer
C=US
ST=WA
L=Bellevue
O=Phantom Works
CN=CA Server
Serial 27 94
Extensions
Extension: 2.16.840.113901.100.2.6
Extension: 2.16.840.113901.100.2.8
Extension: 2.16.840.113901.100.2.7
Extension: 2.16.840.113901.100.2.1
Extension: 2.16.840.113901.100.2.3
Extension: 2.16.840.113901.100.2.4
Extension: X509v3 Subject Key Identifier
Extension: X509v3 Authority Key Identifier
Extension: X509v3 Issuer Alternative Name
Extension: X509v3 Key Usage
Critical
Extension: X509v3 Basic Constraints
Subject
C=US
ST=WA
L=Bellevue
O=Phantom Works
CN=CA Server
Issuer
C=US
ST=WA
L=Bellevue
O=Phantom Works
CN=CA Server
Serial 27 11
Extensions
Extension: 2.16.840.113901.100.2.6
Extension: 2.16.840.113901.100.2.7
Extension: 2.16.840.113901.100.2.1
Extension: 2.16.840.113901.100.2.3
Extension: 2.16.840.113901.100.2.4
Extension: X509v3 Subject Key Identifier
Extension: X509v3 Subject Alternative Name
Extension: X509v3 Key Usage
Critical
Extension: X509v3 Basic Constraints
Critical
1 4 0.1000 (0.0000) S>C Handshake
CertificateRequest
certificate_types rsa_sign
certificate_types dss_sign
ServerHelloDone
1 5 0.3800 (0.2800) C>S Handshake
Certificate
ClientKeyExchange
1 6 0.4800 (0.1000) C>S ChangeCipherSpec
1 7 0.5000 (0.0200) C>S Handshake
Finished
1 8 0.5000 (0.0000) S>C ChangeCipherSpec
1 9 0.5000 (0.0000) S>C Handshake
Finished
1 10 0.6000 (0.1000) C>S application_data
---------------------------------------------------------------
(system:user name="Joe Admin" issuer="boeing.com" serial=12345)
---------------------------------------------------------------
1 77.3100 (76.7100) C>S TCP FIN
1 11 77.3100 (0.0000) S>C Alert
level warning
value close_notify
]0;paula@bluesky:~/projects/policy_language/policy_parser[paula@bluesky
policy_parser]$ exit
Script done on Mon Aug 26 11:05:35 2002
