At the moment the AnsiC stack is unable to negotiate forward secrecy.
This can be checked with this command (assuming port 443 is TLS):

openssl s_client -cipher "EECDH" -connect localhost:443

We should make sure that that is at least possible to use forward secrecy
before we make that a requirement.

To enable EECDH support I need to select a curve in the server SSL context.
That is not enabled by default.

diff --git a/platforms/win32/opcua_p_socket_internal.c b/platforms/win32/opcua_p_socket_internal.c
index 672146e..a0b5b33 100644
--- a/platforms/win32/opcua_p_socket_internal.c
+++ b/platforms/win32/opcua_p_socket_internal.c
@@ -576,6 +576,7 @@ OpcUa_StatusCode OpcUa_SocketManager_InternalCreateServer(
{
OpcUa_StatusCode uStatus = OpcUa_Good;
OpcUa_InternalSocket* pInternalSocket = OpcUa_Null;

• EC_KEY* ecdh;

  *a_ppSocket = OpcUa_Null;

@@ -607,6 +608,14 @@ OpcUa_StatusCode OpcUa_SocketManager_InternalCreateServer(
TLSv1_server_method());
OpcUa_GotoErrorIfBad(uStatus);

• / Enable Perfect Forward Secrecy, using EECDH. /
• ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
• if(ecdh != OpcUa_Null)
• {
• SSL_set_tmp_ecdh(pInternalSocket->pSSLConnection, ecdh);
• EC_KEY_free(ecdh);
• }

•  /* store for inheritance */
   if(a_pServerCertificate != OpcUa_Null)
   {

PS: openssl offers many different choices for the elliptic curve to use,
which one would be the best here?

Well, and as it looks for me, we are currently using TLSv1.0 only,
because we make explicit use of TLSv1_server_method / TLSv1_client_method

That means that we cannot connect to a client that uses TLSv1_1_client_method
or TLSv1_2_client_method. (like firefox uses only TLSv1_2)

I think for upward compatibility, it would be much better to use
SSLv23_server_method and SSLv23_client_method

together with something like this of course:
SSL_CTX_set_options( a_pSocket->pSSLContext, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);

This would enable us to negotiate between TLSv1.0, 1.1 and 1.2, and use
the hightest supported protocol version.

my comments above were referring to the 334 version of the Ansi C stack.

At that time the situation was a bit worse, as it refused to negotiate
anything but tls1.0.

The current Ansi C stack in the GIT has a slightly different status:

It negotiates between TLS 1.2, 1.1 and 1.0.

I wanted to disable TLS 1.0 but that will break interoperability with
at least .NET 3.5, so we had to keep that protocol in the moment.

The stack supports EECDH, but that is disabled at the moment due to the
patent situation.

And it also supports DHE, but it needs a DH Parameter file to be able to
generate ephemeral dh keys.

In order to enable DHE, the application must set the
pCertificateStoreCfg->PkiType to OpcUa_OpenSSL_PKI
and set the bit OPCUA_P_PKI_OPENSSL_OVERRIDE_IS_DHPARAM_FILE
in pCertificateStoreCfg->Flags, and then pass the file name of the
DHPARAM file, in pCertificateStoreCfg->Override.

A dhparam file can be generated by the following openssl command:

openssl dhparam -outform PEM -out "$DHPARAM_FILE_LOCATION" 2048

This takes a while.

We already have a profile for PFS.
We will not add ECC at this time.

not to fix