In an SSL handshake, is it possible to have reversed roles?

Question

I have a php ssl client, and a C++ Qt ssl server, and I need the client to be authenticated rather than the server.

The reason is that the C++ Qt ssl server actually runs on a desktop application, and i don't want to provide the desktop application with a private key for security reasons and also because the server does not need to authenticated it self.

So I had the client provided with certificate and private key, while the server has only the certificate that authenticates the client.

however in the above scenario I get and ssl error from the server side, the handshake fails for lack of shared ciphers.

If i provide the server with its own local private key and certificate the handshake is done successfully.

below some php code to set up ssl:

/* $local_cert_path is a file containing a complete certificate
 * verification chain and the private key
 */
if (! is_file($local_cert_path))
{
    throw new Exception(sprintf('cannot find certificate path: %s', $local_cert_path));
}
$this->ctx = stream_context_create();
stream_context_set_option($this->ctx, 'ssl', 'verify_peer', FALSE);
stream_context_set_option($this->ctx, 'ssl', 'allow_self_signed', TRUE);
stream_context_set_option($this->ctx, 'ssl', 'local_cert', $local_cert_path);

and C++ (Qt):

QList<QSslCertificate> certs = cacerts(); 
socket->setCaCertificates(certs); // loading the CA
// socket->setLocalCertificate(":/res/cert.pem", QSsl::Pem);
// socket->setPrivateKey(":/res/key.pem");
socket->setPeerVerifyMode(QSslSocket::VerifyPeer);
socket->setProtocol(QSsl::TlsV1);

If I provide the server with its own local private key and certificate (uncommenting the two lines above) then the handshake works.

Answer 1

In general, yes, SSL allows this - the client validates any certificate presented by the server, and the server mandates use of client authentication, so the client must authenticate using its certificate. On the other hand your SSL library can be not flexible enough to do this.

Answer 2

Verifying the identity of the SSL/TLS server is necessary to prevent MITM attacks. Even if you use client-certificate authentication (a.k.a. mutual authentication), the client needs to check the identity of the server (typically by checking it trusts its X.509 certificate and that it matches the intended server identity in the certificate). For this, the TLS server needs to be configured with such a certificate (and its associated private key). Without this, the client could very well authenticate using a client-certificate indeed, except that it wouldn't know what it authenticates to (thus potentially leading to MITM attacks).

This being said, in your case, the TLS server needs not be the TCP server. Indeed, TLS tends to be used on top of TCP. In most cases, the TCP client is also the TLS client and, just once the client has established the TCP connection, it also sends a TLS ClientHello over it, starting its role as a TLS client.

You may be able to make the TCP server behave as a TLS server, by making the servre initiate the TLS handshake sending a ClientHello. Indeed, the TLS Glossary defines client as:

The application entity that initiates a TLS connection to a server. This may or may not imply that the client initiated the underlying transport connection. The primary operational difference between the server and client is that the server is generally authenticated, while the client is only optionally authenticated.

I've tried it in Java and it works fine. In Java, the role of which is the client and which is the server is only fixed once the handshake has taken place. Before that, you can still change the role of the SSLSocket using setUseClientMode, although an SSLServerSocket (obtained from an SSLServerSocketFactory will be in server mode, an SSLSocket converted from a plain Socket (resulting from an accept on the server side) can be used as a client TLS socket and vice versa.

TLS allows for this, but I don't know whether it's possible with the framework you're using.

Turning a plain TCP socket into a TLS socket is typically what's done for protocols that upgrade the socket via mechanisms such as STARTTLS (available in SMTP, IMAP and LDAP, for example).

You would need to make a plain TCP connection from your "real" client to your "real" server, turn the TCP client socket into a TLS socket and set it in server mode, turn your TCP server socket into a TLS socket, set it in client mode and initiate the handshake.