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.
It certainly looks I can hit it w/ the following config:
output = /tmp/stunnel4.out pid = /tmp/stunnel4.pid debug = 7
[foo] client = yes accept = localhost:9111 connect = talk.google.com:5223
i2009.02.02 17:29:26 LOG7[2139:139691235383024]: RAND_status claims sufficient entropy for the PRNG 2009.02.02 17:29:26 LOG7[2139:139691235383024]: PRNG seeded successfully ...
2009.02.02 17:29:33 LOG7[2145:139691235481936]: foo permitted by libwrap from 127.0.0.1:42024 2009.02.02 17:29:33 LOG5[2145:139691235481936]: foo accepted connection from 127.0.0.1:42024 2009.02.02 17:29:33 LOG7[2145:139691235481936]: FD 14 in non-blocking mode 2009.02.02 17:29:33 LOG7[2145:139691235481936]: foo connecting 209.85.163.125:5223 2009.02.02 17:29:33 LOG7[2145:139691235481936]: connect_wait: waiting 10 seconds 2009.02.02 17:29:33 LOG7[2145:139691235481936]: connect_wait: connected 2009.02.02 17:29:33 LOG5[2145:139691235481936]: foo connected remote server from a.b.c.d:58907 2009.02.02 17:29:33 LOG7[2145:139691235481936]: Remote FD=14 initialized 2009.02.02 17:29:33 LOG7[2145:139691235481936]: SSL state (connect): before/connect initialization 2009.02.02 17:29:33 LOG7[2145:139691235481936]: SSL state (connect): SSLv3 write client hello A 2009.02.02 17:29:33 LOG7[2145:139691235481936]: SSL state (connect): SSLv3 read server hello A 2009.02.02 17:29:33 LOG7[2145:139691235481936]: SSL state (connect): SSLv3 read server certificate A 2009.02.02 17:29:33 LOG7[2145:139691235481936]: SSL state (connect): SSLv3 read server key exchange A ... 2009.02.02 17:29:33 LOG7[2145:139691235481936]: 1 items in the session cache 2009.02.02 17:29:33 LOG7[2145:139691235481936]: 1 client connects (SSL_connect()) ...
Also, you shouldn't use 'el-in-f125.google.com', you should use talk.google.com. Big sites that use DNS load balancing may hand out a CNAME for you, but you should always use the 'official' one, lest you end up going somewhere that's no longer being handed out when they want to make traffic move (e.g. move load, do maintenance, start new or close old datacenters, etc.)
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.
Lastly, the real question is 'why do you want to do this - does your client not already support SSL/TLS' ?