[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Tools for tracing TLS/SSL



Tony,

I tried the DNS lookup:
# nslookup aptrain.comneti.com
Using /etc/hosts on:  aptrain

looking up FILES
Name:    aptrain.comneti.com
Address:  56.0.0.15

# nslookup 56.0.0.15
Using /etc/hosts on:  aptrain

looking up FILES
Name:    aptrain.comneti.com
Address:  56.0.0.15

Looks it is working. Was ethereal useful for resolving your problems ?

thanks,
dinesh


Tony Earnshaw wrote:

> tor, 2002-09-05 kl. 00:17 skrev Dinesh Salegame:
>
> Look for comments below this "hunk"!
>
> ----------------------------
>
> > client
> > -----
> > ----------snip-----------------
> > TLS certificate verification: depth: 1, err: 0, subject: /C=US/ST=ILLINOIS/L=Lis
> > leCA/O=Comnet Int/OU=CA/CN=aptrain.comneti.com/Email=dvs@comneti.com, issuer: /C
> > =US/ST=ILLINOIS/L=LisleCA/O=Comnet Int/OU=CA/CN=aptrain.comneti.com/Email=dvs@co
> > mneti.com
> > TLS certificate verification: depth: 0, err: 0, subject: /C=US/ST=ILLINOIS/O=Com
> > net Int/OU=CE/CN=aptrain.comneti.com/Email=dvs@comneti.com, issuer: /C=US/ST=ILL
> > INOIS/L=LisleCA/O=Comnet Int/OU=CA/CN=aptrain.comneti.com/Email=dvs@comneti.com
> > TLS trace: SSL_connect:SSLv3 read server certificate A
> > tls_read: want=5, got=5
> >   0000:  16 03 01 00 04                                     .....
> > tls_read: want=4, got=4
> >   0000:  0e 00 00 00                                        ....
> > TLS trace: SSL_connect:SSLv3 read server done A
> > TLS trace: SSL_connect:SSLv3 write client key exchange A
> > TLS trace: SSL_connect:SSLv3 write change cipher spec A
> > TLS trace: SSL_connect:SSLv3 write finished A
> > tls_write: want=190, written=190
> >   0000:  16 03 01 00 86 10 00 00  82 00 80 71 48 4d 7e fb   ...........qHM~.
> >   0010:  b4 e7 08 b5 62 6e 57 fd  6a 9b 3b 00 e8 fc 8b f8   ....bnW.j.;.....
> >   0020:  15 c6 bd 83 55 9a a4 28  c8 91 7e 58 1d f7 2d ef   ....U..(..~X..-.
> >   0030:  53 61 e4 d5 70 a7 bb 24  17 5b e0 9d 6e fd 8d b1   Sa..p..$.[..n...
> >   0040:  32 fd 8a 05 0d 05 97 bc  e6 10 ee e9 86 69 c5 13   2............i..
> >   0050:  97 af d4 b3 a6 0a 07 47  f3 6a a0 7a e7 67 b3 c6   .......G.j.z.g..
> >   0060:  d9 4c 05 87 30 cc 3c 4b  53 b9 13 29 f7 91 7c c7   .L..0.<KS..)..|.
> >   0070:  e4 b3 f4 74 9e 32 49 18  da 22 06 b3 d5 ad 14 0d   ...t.2I.."......
> >   0080:  4d a2 d6 c8 2f 6a a5 48  b5 1c 82 14 03 01 00 01   M.../j.H........
> >   0090:  01 16 03 01 00 28 25 b7  85 ad 9a 5a ab 0a 2f e3   .....(%....Z../.
> >   00a0:  1c 47 eb da a6 27 94 7d  5c 8b 6c b1 6a 61 cb 7f   .G...'.}\.l.ja..
> >   00b0:  d2 41 8f 5a 86 2d c1 8f  6b a4 da 77 f6 ca         .A.Z.-..k..w..
> > TLS trace: SSL_connect:SSLv3 flush data
>
> -----------------------
>
> This is very interesting. I didn't know I could run ldapsearch with a
> '-d -1' option, but now I do. Had I realized this, it would have saved
> me hours of work and cut out the need for Ethereal and strace
> completely.
>
> I ran ldapsearch with my own ldaps bind, which works well for me, and in
> fact I use it for smtp aliases, auth and a lot else in practice.
>
> What *you* get is this (more comments below the "hunk"):
>
> ------------------------
>
> > TLS trace: SSL_connect:SSLv3 read server certificate A
> > tls_read: want=5 error=Connection reset by peer
> > TLS trace: SSL_connect:error in SSLv3 read finished A
> > TLS trace: SSL_connect:error in SSLv3 read finished A
> > TLS: can't connect.
> > ldap_perror
> > ldap_start_tls: Connect error (91)
>
> -------------------------
>
> What *I* get, at this point, it this:
>
> -------------------------
> TLS trace: SSL_connect:SSLv3 read server certificate A
> tls_read: want=5, got=5
>   0000:  16 03 01 00 04
> .....
> tls_read: want=4, got=4
>   0000:  0e 00 00 00
> ....
> TLS trace: SSL_connect:SSLv3 read server done A
> TLS trace: SSL_connect:SSLv3 write client key exchange A
> TLS trace: SSL_connect:SSLv3 write change cipher spec A
> TLS trace: SSL_connect:SSLv3 write finished A
> tls_write: want=190, written=190
> _______________________
>
> Then my debug goes on to give the desired result.
>
> So, the question is: "Why?"
>
> I have had a terrible time in getting my (only) test machine to
> recognize the FQDN of the machine on which it's running. In spite of the
> advice given on this list. This is because it's sometimes a standalone
> machine and sometimes connected to the Internet with a different FQDN/IP
> number.
>
> Your certificate is granted/signed for "CN=aptrain.comneti.com". Are you
> absolutely sure that you can do a succesful DNS lookup of
> aptrain.comneti.com and get a valid IP number, then do a reverse lookup
> of that IP number and resolve it back to aptrain.comneti.com?
>
> That's what messed things up for me, for a long time, and even stops me
> implementing Kerberos. (B.T.W. I *know* I can implement workarounds for
> this, and even got them working, but that messes up so many
> applications, that it's just not worth the hassle).
>
> Best,
>
> Tony
>
> --
>
> Tony Earnshaw
>
> The usefulness of RTFM is vastly overrated.
>
> e-post:         tonni@billy.demon.nl
> www:            http://www.billy.demon.nl
> gpg public key: http://www.billy.demon.nl/tonni.armor
>
> Telefoon:       (+31) (0)172 530428
> Mobiel:         (+31) (0)6 51153356
>
> GPG Fingerprint = 3924 6BF8 A755 DE1A 4AD6 FA2B F7D7 6051 3BE7 B981
> 3BE7B981
>
>   ------------------------------------------------------------------------
>                        Name: signature.asc
>    signature.asc       Type: application/pgp-signature
>                 Description: Dette er en digitalt signert meldingsdel