Re: [stunnel-users] stunnel tls wrapper/proxy for xmpp
On Mon, Feb 02, 2009 at 02:20:18PM -0800, Brian Hatch wrote:
Roughly around 2009-02-02 13:31 -0800, C.J. Adams-Collier broached:
I'm new here, and I didn't see anything relating to this after a quick glance at the archives. I'd like to start a stunnel connection connected to the google talk server and then connect finch up to that so that I can tap the clear xmpp session using tcpdump. Can one of you help me?
5222 requires starttls for xmpp, which stunnel doesn't support.
5223 is wrapped ssl and would work for you.
Thanks Brian, That almost works, too! I think google only does TLS (5222) though. 23:01:03.594856 IP colliertech.org.35052 > od-in-f83.google.com.5223: S 2704797155:2704797155(0) win 5840 <mss 1460,sackOK,timestamp 133784958 0,nop,wscale 1> 23:01:06.591987 IP colliertech.org.35052 > od-in-f83.google.com.5223: S 2704797155:2704797155(0) win 5840 <mss 1460,sackOK,timestamp 133785708 0,nop,wscale 1> Was there a silent "yet" at the end of your "doesn't support" comment above? :) Do you need beta testers for this new feature? Cheers, C.J.
-- Brian Hatch Error 23 occurred when Systems and attempting to report Security Engineer error 23. http://www.ifokr.org/bri/
Every message PGP signed
Any possibility of getting X-Forwarded-For incorporated into the baseline?
Tom Shaw wrote:
Any possibility of getting
X-Forwarded-For
incorporated into the baseline?
I reviewed some patches for this functionality, and they were vulnerable to buffer overflows resulting in remote code execution. They also didn't support keep-alive-mechanism of HTTP/1.1. Some day I'm could add this functionality. The functionality is on my TODO list, anyway: http://stunnel.mirt.net/?page=todo_sdf Best regards, Mike
Thanks Brian,
That almost works, too! I think google only does TLS (5222) though.
23:01:03.594856 IP colliertech.org.35052 > od-in-f83.google.com.5223: S 2704797155:2704797155(0) win 5840 <mss 1460,sackOK,timestamp 133784958 0,nop,wscale 1> 23:01:06.591987 IP colliertech.org.35052 > od-in-f83.google.com.5223: S 2704797155:2704797155(0) win 5840 <mss 1460,sackOK,timestamp 133785708 0,nop,wscale 1>
Was there a silent "yet" at the end of your "doesn't support" comment above? :) Do you need beta testers for this new feature?
Cheers,
C.J.
Oh, and also... this is backward... I want to have the client side clear and the server side ciphered. ie, stunnel acts as a proxy, encrypting the contents before sending them. This sounds like it may be out of scope for this tool though, eh?
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' ? -- 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
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"): 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
On Wed, Feb 04, 2009 at 08:58:38AM -0800, C.J. Adams-Collier wrote: <snip/>
Any further thoughts other than "ask the pidgin folks"?
I talked with the pidgin folks a bit. They recommended that I give socat a try, and it seemed to work. One of the folks had this to say: 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. Maybe it's because I was using the "client" setting in the config file? In any case, if I want to capture a session using STARTTLS, It looks like I'll need to make that patch. Cheers, C.J.
In the neighborhood of Wed, Feb 4, 2009 at 11:49 AM, C.J. Adams-Collier <cjac@colliertech.org> 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/
participants (4)
-
Brian Hatch -
C.J. Adams-Collier -
Michal Trojnara -
Tom Shaw