[stunnel-users] TLS "translation" & 2-way auth

Wed Nov 15 15:54:14 CET 2017

I do this to connect between networks, especially for insecure protocols 
such as RDP

[relay-in]
accept = myaddress:2222
connect=127.1.1.1:22222
client=yes

[relay-out]
accept=127.1.1.1:22222
connect=remoteaddress:1234
client=no

Here 127.1.1.1 can be any address in the 127.0.0.0/8 subnet.  The port 
for relay-in is arbitrary. I pick an arbitrary point greater than 1000 
to connect relay-in to relay-out.  The port for relay-out is whatever is 
required by the application.

A single stunnel instance will support a number of such connections.

Carter

On 11/15/2017 7:36 AM, Peter Pentchev wrote:
> On Wed, Nov 15, 2017 at 08:57:10AM -0300, Igor Gatis wrote:
>> It would be nice to know whether it is actually possible to achieve this
>> with stunnel. If not, is there any other tool I could use or combine?
> It is possible to achieve this with stunnel running on server B with
> two service definitions: one that runs in server mode, accepts a TLS
> connection from server A, and forwards it to a local TCP port where
> the second stunnel service definition runs in client mode and
> establishes a TLS tunnel to server C.
>
> I can try to come up with some configuration examples later; right now
> I cannot really do any testing.
>
> Best regards,
> Peter
>
>> On Nov 13, 2017 08:58, "Igor Gatis" <igorgatis at gmail.com> wrote:
>>
>> Yep, that's exactly what I'm seeking for help here.
>>
>> If we can abstract the 2-way bit for a second, I'd call this a "certificate
>> transcription" TLS tunnel.
>>
>> On Thu, Nov 9, 2017 at 5:19 PM, Vincent Deschenes <vdeschenes at stelvio.com>
>> wrote:
>>
>>> Ho,
>>>
>>> But that does not account for the A ->[TLS] ->B part.
>>>
>>> I believe that my sample will listen for unencrypted connection only.
>>>
>>>
>>>
>>>
>>>
>>> *From:* stunnel-users [mailto:stunnel-users-bounces at stunnel.org] *On
>>> Behalf Of *Vincent Deschenes
>>> *Sent:* Thursday, 9 November 2017 3:16 PM
>>> *To:* Igor Gatis <igorgatis at gmail.com>; stunnel-users at stunnel.org
>>> *Subject:* Re: [stunnel-users] TLS "translation" & 2-way auth
>>>
>>>
>>>
>>> You need to have a section in your config file which listen for requests
>>> but also have the “client = yes” option with a cert and key like this:
>>>
>>>
>>>
>>> [http_a_to_c]
>>>
>>> client = yes
>>>
>>> accept = port_number_to_listen_on_server_b
>>>
>>> connect = server_c_address:443
>>>
>>> cert = certificate.crt
>>>
>>> key = private.key
>>>
>>>
>>>
>>>
>>>
>>> cert and key are the certificate and private key server B uses to identify
>>> itself on server C.
>>>
>>> You could also add more options to specify a trustore to specify which
>>> cert coming from server C server B will trust, otherwise server B will
>>> simply allow the connection.
>>>
>>>
>>>
>>> Good Luck
>>>
>>>
>>>
>>>
>>>
>>> *From:* stunnel-users [mailto:stunnel-users-bounces at stunnel.org
>>> <stunnel-users-bounces at stunnel.org>] *On Behalf Of *Igor Gatis
>>> *Sent:* Thursday, 9 November 2017 1:14 PM
>>> *To:* stunnel-users at stunnel.org
>>> *Subject:* [stunnel-users] TLS "translation" & 2-way auth
>>>
>>>
>>>
>>> Consider scenario below:
>>>
>>>
>>>
>>> Server A   ==TLS==> Server B  ==TLS+2WayAuth==> Server C
>>>
>>>
>>>
>>> Server A needs to connect to Server C through Server B which runs Stunnel.
>>> Server C requires 2-way authentication. I have full control over Server A
>>> and Server B and Server C belongs to a third-party.
>>>
>>>
>>>
>>> What does Stunnel config should look like?
>>>
>>>
>>>
>> _______________________________________________
>> stunnel-users mailing list
>> stunnel-users at stunnel.org
>> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>
>
>
> _______________________________________________
> stunnel-users mailing list
> stunnel-users at stunnel.org
> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20171115/10985e8b/attachment.html>