Re: TLS "translation" & 2-way auth
Peter Pentchev <[email protected]>
| Newsgroups | gmane.network.stunnel.user |
|---|---|
| Message-ID | <[email protected]> |
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 -- -- Peter Pentchev [email protected] [email protected] [email protected] PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 _______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAloMNMQACgkQZR7vsCUn 3xPmqBAAhkJeyRXDd2OHZ0/DniKO3vGex51Bore93FYcpmcprV0RKMnzitQiLtSO 6nTAi/Br/qTBoJyYP/0PhC/Dmypzjc4wGvRT/NrOBNf/rP1pHcB3bIR1YvbZE/24 FRZ1Ys0/TdkakcxslpxI5TmqgCm3Jvcb7O66WPj9mEAMvXwck6RdlL+bokiGb3Yv wEoen9JNUwQPeSD2ilB5jfapyZ1NpAd4/Yud2GyGqh9G4MTF5JjTPocRaSOCcCHi p1tYEq4ZrXqMMK1bqOPaCGLykP1cdkqMCPAuWt6wk+uhhaX4NtYFI7B3FhivTxMp 0rLdmpIeBJ+vSiO+IsONPEkRwGtz5mgJsH2qOcAYU3V0oAIWKHex9Qa0j+gDTK5d 7RrJSh0KEf+sXPBmb+MD58vvMUo2x7J4l8kNkG7mr3RrR0Qo3XlTzi76zdzTeqBA jmWhJFAok6Wo8h4H+/xIiIlUkAdgh2VZRlmGgGewWhhgPPh8IJNALHa0n+LPHxC5 tbViIBUIYkJ6EP+3GQ3V/camiC5uC5amIgj6MM0fENNju3F5Qakn+3Xay5iy6TPo m1A+TPTy3MrLcJaFBmtsZwDtpnmewhCv7XwckpauLFkMZB6nwnlI0HKkcdCmCcQS uExmSRol+SgzuwBmDMdathnDZtXe0VKzHKmREcpVllZUb9y2i+k= =HNPU -----END PGP SIGNATURE-----