[stunnel-users] stunnel tls wrapper/proxy for xmpp

Tue Feb 3 02:39:48 CET 2009

Very close to Mon, Feb 2, 2009 at 3:06 PM, C.J. Adams-Collier
<cjac at 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' ?

-- 
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