Mutually authenticated TLS sessions
Andy
DRC
without some fairly deep modifications to the VeNCrypt extensions, and
possibly even some deep modifications to the RFB authentication protocol
itself (which would necessitate a new version of that protocol.)
What are you ultimately trying to achieve with this?
On 7/22/19 8:00 AM, Andy wrote:
> Is it possible to configure it so that the client and the server can
> authenticate via x509 certificates?
>
> Currently i have it set up so that the Client validates the servers
> cert, and then the server validates the client with a password file.
> What I would like to do would be set the client up with its own cert and
> password signed by the same CA instead of using the password file
>
> /home/csof/ca/certs/localhost.cert.pem -x509key
> /home/csof/ca/certs/localhost.key.pem -rfbauth /home/csof/ca/t.file
>
> *
> *Client *
Andy
DRC
It really sounds like you're going down the road of trying to
reinvent SSH. Can you just use SSH tunneling instead? In
TurboVNC 3.0, the Session Manager feature implements automatic
authentication + encryption, which seems to be what you're
trying to achieve, but it uses SSH in order to do so, not
VeNCrypt. It basically opens an SSH connection to the server,
starts a new TurboVNC Server session or generates a new one-time
password (OTP) for an existing session by way of that SSH
connection, transmits the OTP to the viewer through the SSH
connection, then re-uses the SSH connection to tunnel the RFB
connection. I don't know how to achieve the same thing with
VeNCrypt, because in VeNCrypt, the encryption layer
is fully initialized prior to authentication. What you
basically want is a separate X.509 certificate to be used for
encryption vs. authentication (which I guess would be an
X509X509 security type, using VeNCrypt terminology.) It's
technically feasible. It would involve setting up the
encryption layer, then transmitting the client certificate
through that layer to the server for authentication. However,
that functionality doesn't exist in any current VeNCrypt
implementations, nor do I know of any other remote desktop
software that does that.
Take a look at OTP authentication and see if that might
solve some problems for you. Depending on how you are
starting the TurboVNC Server session, it may be possible for
you to transmit the OTP securely to the viewer, much like the
next-gen TurboVNC Session Manager will do.
--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/turbovnc-users/4c9ae163-ed29-4d43-b5fa-a1af8498e2e8%40googlegroups.com.
DRC
https://gist.github.com/dcommander/fc608434735026dd8215
It also occurs to me that you might be able to set up a separate fake CA
for every user. Then the CA file would effectively become the client
certificate.
>> https://groups.google.com/d/msgid/turbovnc-users/4c9ae163-ed29-4d43-b5fa-a1af8498e2e8%40googlegroups.com
>