Re: TLS "translation" & 2-way auth

Carter Browne <[email protected]>
Newsgroups gmane.network.stunnel.user
Message-ID <[email protected]>
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" <[email protected]> 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 <[email protected]>
>> 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:[email protected]] *On
>>> Behalf Of *Vincent Deschenes
>>> *Sent:* Thursday, 9 November 2017 3:16 PM
>>> *To:* Igor Gatis <[email protected]>; [email protected]
>>> *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:[email protected]
>>> <[email protected]>] *On Behalf Of *Igor Gatis
>>> *Sent:* Thursday, 9 November 2017 1:14 PM
>>> *To:* [email protected]
>>> *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
>> [email protected]
>> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>
>
>
> _______________________________________________
> stunnel-users mailing list
> [email protected]
> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

_______________________________________________
stunnel-users mailing list
[email protected]
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.