[stunnel-users] stunnel tls wrapper/proxy for xmpp
C.J. Adams-Collier
cjac at colliertech.org
Wed Feb 4 17:58:38 CET 2009
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>
More information about the stunnel-users
mailing list