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

• Previous message (by thread): [stunnel-users] stunnel tls wrapper/proxy for xmpp
• Next message (by thread): [stunnel-users] stunnel tls wrapper/proxy for xmpp
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jabber_ssl.pcap
Type: application/cap
Size: 1102 bytes
Desc: not available
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20090204/7f5c04a5/attachment.bin>
-------------- next part --------------
-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQDX7Xq3WswPxxUzTL1S/wY5LJs+AenqGA8cqXADhDCWtGwc0xrK
HST94kVtuxAV52kYkjobLY9b0nBoPw8gJFu46gQRSXcjY+S9Az5x13dYimBTzn+z
7qUjIWq5TDscWzU75whLeEzj12/93WRzpsN/XmtRXMp4cJ+asWzBUT5E0QIDAQAB
AoGADvmANjEMz9dNqBYdVyEqjFKEnaNCVqK+gY1aoFPNjtYKXWFijTvCMf08NWTw
s6QtzK9vai0ZsROCCii9YsxCtAqiB6bODT+1hNdDUGbjF2mKzAYEQoB8vOn1gLi2
c1VH3K/AxYT1JZ12aaIVxEkXCVj0FRls1SlOWz1QBkMiIKUCQQDtMgN02bxyRRKH
sRho2k5GcTWyZBNzNXCIs6Zfxt6VSgyje6cmsvaqCvm98aAHc3tM1EAF8pPFmiVH
+qPUNQF/AkEA6QvT/lAB9ygcqr6KXiN490NZUYuERvvQL0AE/8OZ/komx8aywNz6
YSgCkvMsAVt7T4YqxROQvCvl+BqNgt9BrwJBAN3NevX19gZVGPLSZCUIn1G346Kh
ep6tRkJO3DGL4fBwgkkOBExn5ck04j0Aicjt8Erz37qwEAckEeCxPCngNzkCQQCN
RGVCgN9gIkmWWyBnRlt6j7HiE4+gs96T9dvR6pE7q1lsuo77CDkike1VhODFBd5u
62abxmtzFa02w2nKzmjzAkEAnyiCBI/LaAUQFUelTIlCNHcWfFEY9VG6WcNnuGaI
mHRhRhAH8kVEHJtbKMju1nc5p+S5qMBoNveaNb+YMmXAXQ==
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIID0TCCAzqgAwIBAgIJAPqeNybThP7kMA0GCSqGSIb3DQEBBQUAMIGiMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1NlYXR0bGUxHTAbBgNVBAoT
FENvbGxpZXIgVGVjaG5vbG9naWVzMRMwEQYDVQQLEwpPcGVyYXRpb25zMRswGQYD
VQQDExJDLkouIEFkYW1zLUNvbGxpZXIxIzAhBgkqhkiG9w0BCQEWFGNqYWNAY29s
bGllcnRlY2gub3JnMB4XDTA5MDIwMjE5MTg0M1oXDTEwMDIwMjE5MTg0M1owgaIx
CzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4GA1UEBxMHU2VhdHRsZTEdMBsG
A1UEChMUQ29sbGllciBUZWNobm9sb2dpZXMxEzARBgNVBAsTCk9wZXJhdGlvbnMx
GzAZBgNVBAMTEkMuSi4gQWRhbXMtQ29sbGllcjEjMCEGCSqGSIb3DQEJARYUY2ph
Y0Bjb2xsaWVydGVjaC5vcmcwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANft
erdazA/HFTNMvVL/Bjksmz4B6eoYDxypcAOEMJa0bBzTGsodJP3iRW27EBXnaRiS
Ohstj1vScGg/DyAkW7jqBBFJdyNj5L0DPnHXd1iKYFPOf7PupSMharlMOxxbNTvn
CEt4TOPXb/3dZHOmw39ea1Fcynhwn5qxbMFRPkTRAgMBAAGjggELMIIBBzAdBgNV
HQ4EFgQU0n1Cm0TpigAeY6mdZgKXgnomw1cwgdcGA1UdIwSBzzCBzIAU0n1Cm0Tp
igAeY6mdZgKXgnomw1ehgaikgaUwgaIxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJX
QTEQMA4GA1UEBxMHU2VhdHRsZTEdMBsGA1UEChMUQ29sbGllciBUZWNobm9sb2dp
ZXMxEzARBgNVBAsTCk9wZXJhdGlvbnMxGzAZBgNVBAMTEkMuSi4gQWRhbXMtQ29s
bGllcjEjMCEGCSqGSIb3DQEJARYUY2phY0Bjb2xsaWVydGVjaC5vcmeCCQD6njcm
04T+5DAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4GBAGV0yuJcpBKdM4rJ
KPTH4Jgo9znNFXBSdQ5Es3jT+JJTrkiRrAsPZ7MXsTuX0WSbfy1leYUdR6N6Y0j4
14nLcokA/AX18Fg19kDFUancPTV5wdkardU6Aujp0HLFtZv1k2fvwZHsoyMEgy7R
+MooQlS2B9PqFYtCzh4j7Hoed0ym
-----END CERTIFICATE-----
-----BEGIN DH PARAMETERS-----
MEYCQQDtiX7AHLrdntE2rBCHGZ/yYYUjmw0ZLXcABEZfNxApGpKoNrLrskVShjCZ
6JIDUfLMuZrviln/NXSzPJlv9yk7AgEC
-----END DH PARAMETERS-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20090204/7f5c04a5/attachment.sig>

• Previous message (by thread): [stunnel-users] stunnel tls wrapper/proxy for xmpp
• Next message (by thread): [stunnel-users] stunnel tls wrapper/proxy for xmpp
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]