[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Tools for tracing TLS/SSL
Tony,
My apologies, the nslookup is looking at the /etc/hosts file ... let me fix that :-(
dinesh
Dinesh Salegame wrote:
> 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