[gnutls-help] GnuTLS based AES tunnel, SOCKS 5/4A support, TAP, 2

Mon Oct 14 08:26:42 CEST 2013

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,
How would i create GnuTLS based AES-encrypted port-forwarding
tunnels from Cmp1 to Cmp2 ?

Please first see/read the below four QUESTION sections/paragraphs
mentioned below.
For details you may read other paragraphs.

Cmp = Computer.
IP = IP-Address (ipv4).

Both/all side/hosts will use Linux, for example, Fedora (or other
distro), or Mac OS X.

Frontside --> GnuTLS tunnel --> Backend :
host1.example1.org -> GnuTLS tunnel -> host2.example2.org :
I want to create AES (256 bit) encrypted (port-forwarding) tunnel(s)
for following listening ports: 25 (SMTP), 53 (DNS), 80 (HTTP), 443
(HTTPS), 554 (RTSP), 587 (SUBMISSION), 993 (IMAPS), 5004 (RTP), 5005
(RTCP), 5060 (SIP), 5061 (SIPS), 5070, 6697 (IRC SSL), etc from
Cmp1's (host1.example1.org or it's Internet IP-Address), toward Cmp2
(host2.example2.org or it's Internet IP-Address), like shown in
above.  And then AGAIN traffic/packets will be forwarded toward the
Cmp2-side's 127.0.0.1 local loopback address.
So its also like this:
host1_IP -> gnutls tunnel -> host2_IP -> 127.0.0.1

Another, Frontside --> GnuTLS tunnel --> Backend :
host3.example1.org -> gnutls tunnel -> host4.example2.org :
Above mentioned system configuration will be applied on host3 and
host4, like shown in above line.
(host3_IP --> host4_IP).

host1 and host3 are used by users coming from internet side to
"example1.org". They do not know about host2 or host4 or about
"example2.org" (primary-backend).

host2, host4 : BackEnd Servers :
Actual server software will run from inside host2, and, host4.  The
example1.org domain-name's self-signed/own TLS cert's private-key
portion, (related to above mentioned ports and related network and
internet services), will reside/remain inside host2, and, host4
(primary-backend).  Services will run inside chroot jail or LXC
container inside host2 and host4.

BASICALLY, i'm using the host1 and host3 as traffic reflector (or as
front-side), and these are obtained from Hosting Service Provider
company(s).

And ultimate objective here is to keep my own self-signed various
certificate's and key's private/secret key portion (related to main
services) on my own server(s), which are host2 and host4 (primary
backend), i do not want to keep private/secret key on such remote
servers which may/can view/copy private/secret key portion.

Instead of using SSH tunnel (which uses openssl), i'm looking for a
solution based on GnuTLS based tunnel, because, it has such as these
extra features not available in openssl yet : DTLS, DANE/TLSA,
DNSSEC, etc. To me it seems, GnuTLS is able to do more/extra
authentications, so its more secured (against more attacks/exploits).

QUESTION (1) : So how can i create port-forwarding encrypted tunnel
(which is configured to support only: AES CBC/GCM, 256-bit, SHA512
MAC, TLS 1.2, etc) similar to SSH tunnel, by using GnuTLS, for
linking Computer1 with Computer2 ?  How to create related AES key
(PSK) or TLS certificate/cert/key (using GnuTLS) ?  If gnutls itself
do not have tools for such mentioned purposes, can someone pls
show/point-to very simple WORKING code snipets (preferably based on
C or C++ and/or perl) for client-side and server-side ?
TLS_ECDHE_ECDSA_AES_256_CBC_SHA384
TLS_ECDHE_PSK_AES_256_CBC_SHA384

host5 --> SOCKS5-proxy tunnel --> host6 :
I will also have other local host(s) with private domains, for
example: host5.example3.org which will be available only inside a
LAN, (in another remote secondary location's LAN based computers).
This host5 server computer will have to be configured to forward
above mentioned (service) ports from that LAN side host5_IP, toward
the remote destination host6.example4.org, via using a SOCKS5-proxy
tunnel.  SOCKS5-proxy is running inside host5's loopback interface
127.0.0.1:1080

Mentioned in above, those secondary locations (where i'm providing
services) will only allow traffic from their host5 into internet via
their own SOCKS proxy. Its their policy.  And their SOCKS tunnel
ends in their primary location's SOCKS server, then traffic is
finally allowed to go out into Internet, toward my server
host6.example4.org.  I guess, they are using such SOCKS related
tools/server : dante (BSD/CMU) (server), SS5 (GPL), sSocks (MIT),
Srelay (BSD), etc.

DNSSEC & DANE : All of those mentioned internet hosts and all hosts
inside LAN, are using full DNSSEC supported local DNS-Server.  All
internet domain-names are fully DNSSEC signed,  and, each service's
server software's TLS/SSL cert's hash-code is also declared for
public's usage, via TLSA/DANE DNS record, (for each TLS supported port).

PKIX Certificates :
My own Root-CA cert --> Intermediate DomainName cert --> Server or
Service cert :
Root-CA is self-signed by me(server operator), then --> Intermediate
Cert, for each of these domain-names: example1.org, example2.org,
etc, then --> under each domain-name, i have created different
service related cert for each different service port (or created
cert for same server-host for same-service, running on multiple
host).  Server or service which is using TLS cert, such cert's hash
code is declared on related port via TLSA/DANE dns record.

QUESTION (2) : So how can i create port-forwarding tunnels using
GnuTLS, that can connect with and go through SOCKS v5 or v4A proxy ?
 If TLS cert will be used for encryption, and if such cert's hash
was added into TLSA DNS, then, How can i indicate to such tunnel to
check for TLSA/DANE and use DANE+DNSSEC authenticated connection ?
If gnutls itself do not have tools for such mentioned purposes, can
someone pls show/point-to very simple working code snipets
(preferably based on C or C++ and/or perl) for client-side and
server-side ?

QUESTION (3) : how to create those gnutls port-forwarding tunnels
inside chroot jail or LXC container ?
Which portion of command-line will vary ?

TAP to TAP : (or TUN to TUN, if SIP not implemented)

eth0 <-> \					/ <-> eth0
	host7 <-> gnutls encrypted link <-> host8
tap0 <-> /					\ <-> tap0

I have created virtual/tap network interface (Network Layer 2
virtual device) using other tools, not OpenVPN. For example:
eth0(host7) has 192.168.10.10, so i have assigned a different subnet
based IP 192.168.11.110 to tap0(host7). I do not need that tap's IP
be one from that LAN's subnet, for using the tap interface as a
Server IP.  I do not want computer's local/internal traffic reaching
all other computers in that LAN side, server-related traffic only
need to goto Server's IP.  I do not want to bridge eth0 and tap0
either, to prevent server-related traffic going/spreading into all
other computers in that LAN.  And, eth0(host8) has 192.168.10.11, so
i have assigned 192.168.11.111 to tap0(host8).  (At later stage,
eth0 & tap0 will be bridged so that all others in LAN-side can also
use the server behind virtual/tap interface).

QUESTION (4) : How to link two virtual/TAP network interface located
inside two different computers (in two different location), using a
GnuTLS based bi-directional encrypted tunnel ? (not asking for
bridged network interfaces)

Like this:
tap0(host7) <-> host7 <-> gnutls tunnel <-> internet/LAN <->
gnutls-tunnel <-> host8 <-> tap0(host8).

Expecting such behavior, for example: a DNS-client software/app will
send traffic toward tap0(host7)_IP:port53, such traffic will travel
encryptedly through gnutls tap tunnel and will be decrypted at the
other side of the tap-link to tap0(host8)_IP:port53 tap network
interface:port, and on that other side a DNS-Server software is
listening on tap0(host8)_IP:port53, will receive DNS query from DNS
client side, and then DNS-Server will send DNS query-result back to
DNS client on tap0(host7) side, via tap link.  And at the same time,
another server software is listening on a specific port of
tap0(host7)_IP interface side, and a client software from
tap0(host8) side will connect with server in tap0(host7) side, to
use server's service.

So i think: all incoming traffic coming/connecting on different
ports in tap(host7) network interface will have to be multiplexed
and then (gnutls) encrypted, and then send through (gnutls)
encryption based tunnel, and on the other side of the tunnel,
encrypted traffic will be decrypted, and then those incoming traffic
will be de-multiplexed toward the same as origin port and connected
with same port of tap0(host8) interface, and ready for delivery to a
listening app/software, if one is running.  Same process will happen
for incoming traffic of tap(host8) interface, traffic will travel to
other side same port of tap0(host7) interface, other side.

Please show me few COMMAND-LINES and usage scenario related to my
topology/design.

And if gnutls cannot perform mentioned tasks/steps/functions, then
please show/point me to such tools (free, GPL/MIT/BSD, etc licensed
based), which can perform such functions.

I hope i mentioned related all info, so that this message's
responder(s) can answer easily.  And, instead of a full IP-Address
with numbers, pls use just Host_IP or something similar in your
shown command-lines, i guess that will be enough for understanding.

When i will understand basics of it better, then i can & want to
fine-tune each tunnel based on port or protocol/service type. For
example, using DTLS based tunnel for DNS and DNSSEC based packets
for port 53.  Using TCP based TLS tunnel for HTTPS, SMPTS, IMAPS,
etc.  Using SRTP optimized/based TLS tunnel for SIP Voip, etc.

I have already done most of these functionality using various other
alternative tools, some of which i have mentioned, and some i have
not, because i'm looking for a viable solution based on GnuTLS.

Such should help many users to use GnuTLS based encrypted tunnel,
and not always depend on SSH (or VPN) etc tunnels.  GnuTLS available
by-default in (almost) all Linux and (almost doing nothing or) used
for (very) limited cases ! Why is that ?

Many many thanks in advance,
- -- Bright Star.

References:
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
http://www.gnutls.org/
https://en.wikipedia.org/wiki/GnuTLS
http://www.gnutls.org/manual/gnutls.html
https://en.wikipedia.org/wiki/SOCKS
http://ss5.sourceforge.net/
http://sourceforge.net/projects/ssocks/
http://sourceforge.net/projects/socks-relay/
http://backreference.org/2010/03/26/tuntap-interface-tutorial/
VTun (Tun/Tap) : http://vtun.sourceforge.net/
http://vtun.sourceforge.net/tun/index.html
http://seravo.fi/2012/virtualized-bridged-networking-with-macvtap
http://virt.kernelnewbies.org/MacVTap
http://tuntaposx.sourceforge.net/
https://code.google.com/p/badvpn/wiki/tun2socks
http://support.microsoft.com/kb/839013
http://tinc-vpn.org/

My pub PGP-Key:

- -----BEGIN PGP PUBLIC KEY BLOCK-----

mQMuBFBuiDgRCAC1rfewUls1ynwYSMroPqGPNbnK6CdeFpisP0N6ZT/tGrHEg/2o
IC0WBSOqSMp50gE4muIOm7cz4suHRmDhqaeyvOQqHP2/7cWSpzQRgt5x94KMtuDs
hXohCAPmZMQIxgSYQQ1iWZQ9LlxWESRgudMgr2v0IZFgN8a5mL0yPqvJp2Nl+hMj
obk5qiRjEvHR8MIOtt212PIOkgW1EUEVRBCaf65cuHmWwV3criC2aYnQjb88WejP
6UpGgH7KNL6aeM5wK+f/9FwCaXZGuX+pgeSjudDPqW+O5C/A4XUtMW+iUf3SgjzG
2b4pIjrQgrGzeuvpNqv3W4svfMiwFs2QvrWHAQDuP7GJM+052JUvPO7PPqoKSD2k
5dCtBtvC92VVr+8NSQgAoK0uajEvJQwCUrT7N4fpXDmEEEKFF62lIjGLJHzpg7l9
ZwxN+N2L8sMVIT93GBpn0nCFhdYVL1VkzZdJ+vjZEuhSrUj/ya2WO2fJagjZnd0X
Y/SEEsoexm3aMBZSPeLQU+aQ7Nq3JZQ4xPVdP5YHGMJgGPtfKMqUfQ8XaqvYzbT4
M4ZROK3g51a6ggziaBFWWc7gpNgWo8KKbzWo/0ucyIdQAPqexmU7fE9GMwO0MOPe
fIfIZgucnEPd/9VY8tvwcVLfXpsGLQdrkOpMTuTng0RX0iZKJ6aMIwGNLjekejVP
3fEVy4R9Y1xHG/gR3xOkjtzMCT4fsYjqzKuZTDXV2AgAlHGdlfNyn4XcxirYbVsV
kr6I0IwfOucrjFh93Of98rO3Q1PYroVqoym7ES62+U4gWOrbqDC3uJyZ7TWAzztS
De+Chc78HMkP4+5WpW/Uf8of9M35eHIzuJxYUvaMg9k4idLU8mLe693iRlt7ty1c
dhiESe4wa/fgNL7QU6POYeUlDl6bv1GZhnTjYpbQPaWOmgsgHL37WVpjitIHPmB3
SRoUZFxBP2/XJzVEi0Qxt4T7t9x9d7/Yc4Siymi9sdASYvCSnNyqFSLGe/9uZrEz
lcbyFOmIQ17XBtQ2BLduTkcARpM3td7JjAbmrXvFJntr8RN1SXIOSMiKNoTNQsBC
PbQgQnJpZ2h0IFN0YXIgPGJyeThzdGFyQHlhaG9vLmNvbT6IgwQTEQgAKwIbIwUJ
A8G7eAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAlFWS74CGQEACgkQiDbbolds
EOxAYgEAgXIIGowFBnteQN2ATV+QC8aXiI31hi4nPZ/yBE7vXfYA/3QJjB87fzlr
7GqMyedZXXP/fEH34xtGtqLTF3CkstNriQIcBBMBAgAGBQJRfJxuAAoJEID2ikYf
WSP69mEP/1uYW29+0uUT/aB8Hyo39H6WZ6H8dDEnRO24jZW5Eoyp8m6mW3XrG6yn
hPfI/GiSuvVKy365P+aMHY5ERf3UOBdYaPYqGqzQGWl/uo8hxjP4VGFyL6BJGxnG
zulGjcy+WMYWQd5BvOL66Zia2vwAthsN3epY7HtvRzDQkYMtnYMKuEJo0Xa4Bf/v
dOSAt92fAo08ptwgaFZhK0ZWqpyE8fP70bVpeLKEt4512UipcuWd2mt9NPwmo+I3
giaCj5690VmwF8zKfPHXLFlKKHccNNcm6p+G1QCSa990jAHzprlaTIdtlHdCubzq
A6aQalIIE+qh5y4n01sI7M0RbVhoZif7LOlVpEZN0kaeXWybd24jB8tgHta79Zx9
mlHwtsHqPSXkE7kYveeP//6xOMyiiB0RYcteL6+GWpmVeULciI853R7m3pY9XuWW
1WX3X3nDb/UpUo1Y8R6nJ7dOLRZuhojxGh3X4hm860a8YxTP1dNN2EVmF8uMz73q
pVKIj3v6QMVhKIbWc30L0ZyQjgxqeDCNP/g2pfTMWPUlGLMp/1fcZHi/e/mpWVXh
M0vPCUZW1sE8BrBXQbxbJC04h1Jv3ke3RUnN1csfs4jLlFQ/tp/IhVtHxEBpZtDc
X/YbSZrmcw2Ed/BGljD0E6PJC8jhOWpiETEZXQLF72p1hJu1t5B3tCBCcmlnaHQg
U3RhciA8YnJ5OHN0YXJAZ21haWwuY29tPoiABBMRCAAoBQJRVks0AhsjBQkDwbt4
BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCINtuiV2wQ7CeCAQDKQ/aLmp//
eca5ps7xVEGIkq2m42m9bT8EMFvKFRECmgEA2m3W8oKMLextBe6Xw1WKfpgxJZjX
ob1YRRzujlDgmKSJAhwEEwECAAYFAlF8nG4ACgkQgPaKRh9ZI/qEcA/+JsLrQtfJ
lFF3ZMXHUd6a8JzXuAJMK4kDPxS/4sCm2oFAzzUopX8odsvdRvGtaquaTs6rEJEo
+7dh+RYn/JgJqd8llXlb1zQ9DyhcMSfqYFR0cC3V3GkU4cLhUvREv2zT3qOoOdhp
SXljhXqUkXgEHxfQtQ/xZig1FXEiqgn+7YNOHEnfE8DCVOOTwGWXCVel5TDZ0e3x
QllOywAsZ+6t4CM4OsZYIPrYBQ6KcO7X1NVzD7owYpLcBcFTAIhe1tgEFPsomF0k
GCGIerQnl7LF0boDRZMn/aY7zfPWuHEPPN92hVFfpC96GP7jHw7DDX9WikACIU2a
B3Muk5+GsuJWNUVD9j2DaUePRXENfuHq/5wOCQAmm3iLuchywPvERuY2HKwSkvii
eRbNfUMM45z+6uN7mCcrslB7tFikeFTyzU7FTLSfjItAy3525LltF6HU45bAIDub
UOjVP6C1QenmWJiS4D4/UKMcavUcfWegfW/3Tu9mLn5RPJT31kduOr43IcOHmpEk
W8Gjnd/qkELE0VV6qdPBJv1AZZtDv/zCzSPcbeurFRqdSh94GptOy/tGWondQdYy
AF9L1ih4qkPB+XIRqzskr4F/QWZlHGE5vKKPuEtiSSIqZVGCexr+oA3HsDLfjmE1
ygX/BcFId23rdhis5RrGfiflfsFzklDDlmO0JEJyaWdodCBTdGFyIDxicnk4c3Rh
ckBpbnZlbnRhdGkub3JnPoiABBMRCAAoBQJRfJ0GAhsjBQkDwbt4BgsJCAcDAgYV
CAIJCgsEFgIDAQIeAQIXgAAKCRCINtuiV2wQ7OqQAP0X6DDHwgmLZrkwurohtg5b
eZkjAkdXn/UjEhcSxJA9LAEA2BNUTFX/qhRW25bbQUhOr+5V7njvVOYm83qOtFsj
GNi5Ag0EUG6IOBAIAM96hYWIwIpBeQ/6NGzTOPYvMUde8Y3wwBLhWg4fmsGkpKwy
ZQT77EGv3m4wD35Byj5RZ1dB7AmsUe8dDyhkjPyzXGZW5Xt09/Fe5v3wpWCsCqwz
n88xgZX1XzYbhHgU4hj/HzZSMNUMYzr/nH3z995ecTGYU5S7Mqa0RKWOxQbo3nUy
/S1Vl9AjKDFBhdexH+d4ZJSfbADC58A9OodIGnz7AN8NmG153cbK/yg/Ob6DAqQE
FLzWF6TaLa4BBbPW/MoapRKgA/Ls1/aWTi0yPBQJkq6NAm9xHL0ZlHQXCw2x95Y0
9P01nLVxHUCnb9Hdsm4+Cas46riBDa6NfoGxTOcAAwUIAJ/N0crFf/Df6ArQ9/Qm
Ki9B0LPwvGfF7l7ityxW/LO6EPx0G4vFmhcR1wR75Jr4lR3tk+tubCNvL4hPJLMg
GLyZf1LpiNbSyPtbwb+ewAsiNgi1yDXmPWEOyMLRua6BTqJlOa+n0XtWyDCxnfGf
ytDbN56954UC1JqLhxuu7B1EKfKedlYZOt1ZU5lma1J08WleAEhTJIjuor4KqX0T
KluX0QApS36SB3cJSxh9uZ/gVcfWiLSII4KxVsvnTSgvQ5ed87k/z8neWDswyNMR
lSS1eDalvT6SsIsQ3Vw6GdJa1O4JKx13KjTvWilRH48/cC13YeldnaQJONZCqgJW
8GKIZwQYEQgADwUCUG6IOAIbDAUJA8G7eAAKCRCINtuiV2wQ7A+HAP94o2galwpb
85ptdDa2TYxPAKfJihPGzrUx6MGDJ6vDlAD+PAs2Ylb24EEmP8juhfmDzICV2G94
YKBOGQaTY+WFPo0=
=WaWd
- -----END PGP PUBLIC KEY BLOCK-----

Fingerprint: 12B7 7F2C 92BF 25C8 38C6 4D9C 8836 DBA2 576C 10EC.
My Key ID: 0x576C10EC.

-----BEGIN PGP SIGNATURE-----

iF4EAREKAAYFAlJbjqEACgkQiDbboldsEOyowwD+L6pqa75Esp8kPBwjC7sNihKS
Cu/Evbl5gCGB6umBJtgA/Auofx85URuSM/bnwb5INTZCPvkqoawcCdg5xFHvvd61
=X+fc
-----END PGP SIGNATURE-----