On Mon, Feb 02, 2009 at 05:39:48PM -0800, Brian Hatch wrote:
Very close to Mon, Feb 2, 2009 at 3:06 PM, C.J. Adams-Collier cjac@colliertech.org communicated:
That almost works, too! I think google only does TLS (5222) though.
Have you tried? I'm pretty sure I've used pidgin against 5223 in the past.
Thanks again for the help. This mostly works :) I can't seem to get finch to connect to stunnel using ssl, but disabling it, forcing auth in the clear and connecting to 5222 works like a charm.
In an attempt to resolve the SSL issue, I re-compiled the debian finch package from experimental (had to fix a busted debian/control) and forced gnutls instead of nss, which gave a bit better SSL debug message. I started stunnel with this config using the attached key pair:
client = yes sslVersion = SSLv3
foreground = yes cert = /etc/stunnel/stunnel.pem debug = 7
[gtalk] accept = localhost:5223 connect = talk.google.com:5223
In the Finch UI, I:
* checked the box for "Require SSL/TLS" * checked the box for "Force old (port 5223) SSL" * set the "Connect port" to 5223 * Set the "Connect server" to localhost
When I activated the account, finch logged:
(16:10:14) proxy: Connecting to localhost:5223. (16:10:14) gnutls: Starting handshake with localhost (16:10:14) gnutls: Handshake failed. Error A record packet with illegal version was received.
stunnel logged:
2009.02.04 16:14:11 LOG7[29122:140132194187616]: Connection from 127.0.0.1:52675 permitted by libwrap 2009.02.04 16:14:11 LOG5[29122:140132194187616]: gtalk connected from 127.0.0.1:52675 2009.02.04 16:14:11 LOG7[29122:140132194187616]: FD 7 in non-blocking mode 2009.02.04 16:14:11 LOG7[29122:140132194187616]: gtalk connecting 216.239.51.125:5223 2009.02.04 16:14:11 LOG7[29122:140132194187616]: connect_wait: waiting 10 seconds 2009.02.04 16:14:11 LOG7[29122:140132194191056]: Cleaning up the signal pipe 2009.02.04 16:14:11 LOG6[29122:140132194191056]: Child process 29316 finished with code 0 2009.02.04 16:14:11 LOG7[29122:140132194187616]: connect_wait: connected 2009.02.04 16:14:11 LOG7[29122:140132194187616]: Remote FD=7 initialized 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL state (connect): before/connect initialization 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL state (connect): SSLv3 write client hello A 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL state (connect): SSLv3 read server hello A 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL state (connect): SSLv3 read server certificate A 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL state (connect): SSLv3 read server key exchange A 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL state (connect): SSLv3 read server done A 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL state (connect): SSLv3 write client key exchange A 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL state (connect): SSLv3 write change cipher spec A 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL state (connect): SSLv3 write finished A 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL state (connect): SSLv3 flush data 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL state (connect): SSLv3 read finished A 2009.02.04 16:14:11 LOG7[29122:140132194187616]: 5 items in the session cache 2009.02.04 16:14:11 LOG7[29122:140132194187616]: 5 client connects (SSL_connect()) 2009.02.04 16:14:11 LOG7[29122:140132194187616]: 5 client connects that finished 2009.02.04 16:14:11 LOG7[29122:140132194187616]: 0 client renegotiations requested 2009.02.04 16:14:11 LOG7[29122:140132194187616]: 0 server connects (SSL_accept()) 2009.02.04 16:14:11 LOG7[29122:140132194187616]: 0 server connects that finished 2009.02.04 16:14:11 LOG7[29122:140132194187616]: 0 server renegotiations requested 2009.02.04 16:14:11 LOG7[29122:140132194187616]: 0 session cache hits 2009.02.04 16:14:11 LOG7[29122:140132194187616]: 0 session cache misses 2009.02.04 16:14:11 LOG7[29122:140132194187616]: 0 session cache timeouts 2009.02.04 16:14:11 LOG6[29122:140132194187616]: SSL connected: new session negotiated 2009.02.04 16:14:11 LOG6[29122:140132194187616]: Negotiated ciphers: DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL alert (read): warning: close notify 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL closed on SSL_read 2009.02.04 16:14:11 LOG7[29122:140132194187616]: Socket write shutdown 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL write shutdown 2009.02.04 16:14:11 LOG7[29122:140132194187616]: SSL alert (write): warning: close notify 2009.02.04 16:14:11 LOG6[29122:140132194187616]: SSL_shutdown successfully sent close_notify 2009.02.04 16:14:11 LOG5[29122:140132194187616]: Connection closed: 66 bytes sent to SSL, 258 bytes sent to socket 2009.02.04 16:14:11 LOG7[29122:140132194187616]: gtalk finished (0 left)
(it looks like the connection to google was established, but the connection from finch failed)
I took a capture of the session:
$ sudo tcpdump -s 0 -i lo port 5223 -w jabber_ssl.pcap
and used wireshark to take a look at the packets. Instructions for decoding SSL are here (search for "RSA keys list"):
My RSA keys list value was like:
127.0.0.1,5223,xmpp,C:\blahblahblah\stunnel.pem
The version field in frame 4 (finch -> stunnel) is TLSv1 rather than the SSLv3 I would have expected, since I checked the "Force old (port 5223) SSL" box.
But, as I said, disabling SSL entirely and enabling auth over clear makes this particular problem go away. Sounds like it's a finch bug anyhow. :)
Any further thoughts other than "ask the pidgin folks"?
Was there a silent "yet" at the end of your "doesn't support" comment above?
One could always submit a patch. The relevant RFC is http://www.xmpp.org/rfcs/rfc3920.html. XMPP STARTTLS is a bit more involved than the protocols currently supported, what with all that annoying XML. Here's a bit of perl code I use in something else to negotiate up to SSL in case anyone wants to work from it. Pretend $tcp is the socket in question:
if (not $domain) { $domain = $host; } print $tcp <<EOM; <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='$domain' version='1.0'>EOM my $response;
# Set record separator to the > character, skip to # the end of the features list. # Can you say "really lame way to parse xml"? $old_separator = FileHandle->input_record_separator('>'); while (<$tcp>) { s/\n//g; $response .= $_; if ($response =~ m#</stream:features>#i) { last; } } print $tcp <<EOM; <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>EOM $response = ''; while (<$tcp>) { s/\n//g; $response .= $_; if ($response =~ m#<proceed[^>]+/>|</proceed>#ix) { last; } }
# Now, start SSL/TLS transaction.
Cool beans. I'll see if I can put something together in C. Looks like no regexen are currently being used:
$ grep -r 'regcomp' stunnel-4.26/src | wc -l 0
Is this to increase platform compatability? Any problem with adding dependence on the POSIX regcomp/regexec from regex.h?
$ dpkg -S /usr/include/regex.h libc6-dev: /usr/include/regex.h
Lastly, the real question is 'why do you want to do this - does your client not already support SSL/TLS' ?
I'll try to answer this without blowing any NDAs :) The project I'm doing requires some packet captures of various communication media, and I need to be able to see into the payload by either using the WireShark trick above or by removing the SSL entirely.
Cheers,
C.J.
-- Brian Hatch "Make sure we get enough cab vouchers. Systems and We don't want anybody dead." Security Engineer "Anybody?" http://www.ifokr.org/bri/ --John and Bob