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 [email protected] 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"):

http://wiki.wireshark.org/SSL

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

In the neighborhood of Wed, Feb 4, 2009 at 11:49 AM, C.J. Adams-Collier [email protected] mouthed:

19:39 < darkrain42> cj: Also, for the record, I think stunnel just isn't the thing you want to be using. What it seemed to be doing was opening a SSL connectoin to talk.google.com and then writing the raw data from your socket to the server (so Pidgin tries to open an SSL connection and the raw SSL handshake is written to talk.google.com)

Is this correct? I would have expected it to terminate the SSL connection with finch on one port and originate another SSL connection with talk.google.com on another. If I read what he's writing correctly, he's saying that the connection from finch is not terminated, but instead passed through unaltered.

Stunnel does SSL on one side, and cleartext on the other.

If you want to be able to sniff cleartext, while both finch and the jabber server are talking ssl, you need two stunnels:

finch ==ssl==> stunnel_server ==cleartext==> stunnel_client ==ssl==> jabberserver

then sniff on that cleartext loopback port.

Effectively, that makes a no-op - finch talks SSL to the jabber server. You can do that without using Stunnel. Stunnel is not a MITM attack vector. ;-)

-- Brian Hatch A small town that cannot Systems and support one lawyer can Security Engineer always support two. http://www.ifokr.org/bri/