Download and build proxytunnel in Fedora

This program connects stdin and stdout to a server somewhere on the network, through a standard HTTPS proxy. We mostly use it to tunnel SSH sessions through HTTP(S) proxies, allowing us to do many things that wouldn’t be possible without it.

* Create tunnels using HTTP and HTTPS proxies (That understand the HTTP CONNECT command).
* Work as a back-end driver for an OpenSSH client, and create SSH connections through HTTP(S) proxies.
* Work as a stand-alone application, listening on a port for connections, and then tunneling these connections to a specified destination.

This was originally posted on rootninja back in December 2009 and dug up from the Internet graveyard that is the wayback machine. Versions of Fedora and this app have changed significantly. Use this howto as-is at your own risk. As of Fedora 21 (at least), you’re better off using yum to download the prebuilt and configured binary version instead of building it (as far as just getting it to work goes anyway!) But hey, maybe you’re still using Fedora 12 for one reason or another. No judgement.

Get it

$ svn co

    A trunk
    A trunk/website
    A tags/v1-6-0-rc1/proxytunnel/Makefile.cygwin
    A tags/v1-6-0-rc1/proxytunnel/Makefile
    Checked out revision 248. 

Build it

Getting it built seems to be pretty straight forward stuff…

$ make

    make -C docs
    make[1]: Entering directory /home/svn/proxytunnel/trunk/proxytunnel/docs'
    asciidoc -b docbook -d manpage proxytunnel.1.txt
    make[1]: asciidoc: Command not found
    make[1]: *** [proxytunnel.1.xml] Error 127
    make[1]: Leaving directory /home/svn/proxytunnel/trunk/proxytunnel/docs’
    make: *** [docs] Error 2 

$ yum install asciidoc

    Running Transaction
    Installing : asciidoc-8.4.5-4.fc12.noarch 1/1
    asciidoc.noarch 0:8.4.5-4.fc12

$ make

    make -C docs
    make[1]: Entering directory /home/svn/proxytunnel/trunk/proxytunnel/docs'
    asciidoc -b docbook -d manpage proxytunnel.1.txt
    xmlto man proxytunnel.1.xml
    make[1]: xmlto: Command not found
    make[1]: *** [proxytunnel.1] Error 127
    rm proxytunnel.1.xml
    make[1]: Leaving directory /home/svn/proxytunnel/trunk/proxytunnel/docs’
    make: *** [docs] Error 2

$ yum install xmlto

    Running Transaction
    Installing : xmlto-0.0.23-2.fc12.x86_64 1/1
    xmlto.x86_64 0:0.0.23-2.fc12

$ make

    Note: Writing proxytunnel.1
    asciidoc -d manpage proxytunnel.1.txt
    asciidoc proxytunnel-paper.txt
    rm proxytunnel.1.xml
    make[1]: Leaving directory `/home/svn/proxytunnel/trunk/proxytunnel/docs’

$ ./proxytunnel –help

    proxytunnel 1.9.0 (rev 248) Copyright 2001-2008 Proxytunnel Project
    Usage: proxytunnel [OPTIONS]…
    Build generic tunnels trough HTTPS proxies using HTTP authentication

    Standard options:
    -i, –inetd Run from inetd (default: off)
    -a, –standalone=INT Run as standalone daemon on specified port
    -p, –proxy=STRING Local proxy host:port combination
    -r, –remproxy=STRING Remote proxy host:port combination (using 2 proxies)
    -d, –dest=STRING Destination host:port combination
    -e, –encrypt SSL encrypt data between local proxy and destination
    -E, –encrypt-proxy SSL encrypt data between client and local proxy
    -X, –encrypt-remproxy SSL encrypt data between local and remote proxy

    Additional options for specific features:
    -F, –passfile=STRING File with credentials for proxy authentication
    -P, –proxyauth=STRING Proxy auth credentials user:pass combination
    -R, –remproxyauth=STRING Remote proxy auth credentials user:pass combination
    -N, –ntlm Use NTLM based authentication
    -t, –domain=STRING NTLM domain (default: autodetect)
    -H, –header=STRING Add additional HTTP headers to send to proxy
    -x, –proctitle=STRING Use a different process title

    Miscellaneous options:
    -v, –verbose Turn on verbosity
    -q, –quiet Suppress messages
    -h, –help Print help and exit
    -V, –version Print version and exit

And there you have it, enjoy.

Verify LDAP encryption with Wireshark

TLS, Is it working or not?

secret text in red and yellow on black
Assuming you’ve already installed and configured your directory to use TLS encryption, you should verify LDAP is working as you expect before you start streaming passwords and other important data across the wire.

You can use Wireshark and it’s full blown gui interface, but it’s faster just to fire up tethereal for this test. tethereal is part of the Wireshark package, so if you don’t already have it, install Wireshark now.

Server Side

As a regular User

$ /usr/sbin/tethereal -n tcp port ldap
tshark: There are no interfaces on which a capture can be done

Hmm ok fine, against all warnings, i’ll use root. But I don’t have to like it.

As root

When you run tethereal or Wireshark (filtering for ldap traffic only), you won’t get any output unless your LDAP network is already in use or until you generate some traffic. So start by running tethereal on the LDAP server. Then go to the client side and try browsing ldap.

$ sudo /usr/sbin/tethereal -n tcp port ldap
Running as user “root” and group “root”. This could be dangerous.
Capturing on eth0> TCP 49415 > 389 [SYN] Seq=0 Win=5840 Len=0 MSS=1460> TCP 389 > 49415 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0> TCP 49415 > 389 [ACK] Seq=1 Ack=1 Win=5888 Len=0> LDAP extendedReq(1) LDAP_START_TLS_OID]> TCP 389 > 49415 [ACK] Seq=1 Ack=40 Win=5824 Len=0> LDAP extendedResp(1) [LDAP_START_TLS_OID]> TCP 49415 > 389 [ACK] Seq=40 Ack=15 Win=5888 Len=0> SSL Client Hello> TLSv1 Server Hello, Certificate, Server Hello Done> TLSv1 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message> TLSv1 Change Cipher Spec, Encrypted Handshake Message> TLSv1 Application Data, Application Data

Client Side

The -Z flag requests encryption. Double -Z’s forces encryption and fails if it’s not available. So maybe that’s enough for you, but I’m not going to trust that this flag even works without seeing encrypted traffic! Also, this doesn’t prove that all traffic will be encrypted, it just means it’s allowed to be encrypted. So try it with no -Z’s at all.

$ ldapsearch -x -Z
dn: uid=admica,ou=People,dc=rootninja,dc=com
uid: admica
objectClass: posixAccount
objectClass: top
loginShell: /bin/bash
uidNumber: 1337
homeDirectory: /fake/data
gidNumber: 123

Now go back to the server and see if you captured anything. If you’re using the standard LDAP port 389 and TLS encryption, you don’t even need to look at 636. You should see the handshake and then Application Data, Application Data.

Back on the Server Side

Run tethereal again with -x and you can look at the data and see it’s encrypted. You should only see the initial communication and certificate exchange in clear text. The rest should look like this:

     0.025405 -> TLSv1 Application Data, Application Data

    0000 00 1d 4f ab 69 51 55 19 b9 20 0b 98 08 00 65 10 ..O.iP… ….F.
    0010 00 ce b0 ec 40 01 40 07 73 84 0a 0a 02 0c 0b 0a ….j.@.s…2…
    0020 18 04 38 ef 03 40 ee 7c 49 ba 2b 69 e6 db ff 64 ..2..q.jI.+X..j..
    0030 00 7c 26 6f 0f 00 01 01 0f 0a 2f 39 a0 1d 0a 21 .&.f……/3…f
    0040 fa 56 27 0a 01 00 20 79 ef b2 9a 32 0f f2 16 1c .V…. y..1…..
    0050 0f 5e 2b eb 5d 49 04 4a 06 9a ad fa 9e da 5d f2 .^+.QI.J……]Y
    0060 b1 6e 01 dc 62 12 f9 17 07 01 00 00 60 fb 1f 3d .n..i5d.da.22..=
    0070 e4 31 76 9f 0c 2f 36 53 18 7d ff 25 ff d4 40 24 .1…/6S.}….@$
    0080 18 a4 38 ef e3 40 ee 7c 49 ba 2b 68 e6 db f1 64 ..8..q.|I.+X…a
    0090 1a 05 57 6f eb c4 d3 9f 8a 9a 35 43 05 88 10 f2 ..Wa……5….R
    00a0 34 99 32 cf d4 74 56 32 ab fe 4b 71 fb ef 2b f3 2.j..^V2..K!..p.
    00b0 8f 64 bc d2 ea 14 99 3a dc 81 65 29 70 6c d1 d7 .d.b…:..eIjl..
    00c0 2b 42 ce e1 16 f4 6e 34 6d 6c 7f 12 -B….n4:l..

If you see plain text output here, then you’re not really using TLS encrpytion. It is possible you misconfigured your server to allow encrpytion without enforcing it.