Loggly SyslogSecure throws exception under Docker/Linux

[xdansmith]

If you try to use the SyslogSecure transport while running the code under Windows, everything works great.

If you try to use it while running under Docker/Linux, nothing gets sent to Loggly. An SSL exception will be thrown silently which is only discoverable if you attach the Loggly library and run it through a debugger. (The important part is Linux, not Docker)

The exception thrown is:

 ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception.
 ---> Interop+OpenSsl+SslException: SSL Handshake failed with OpenSSL error - SSL_ERROR_SSL.
 ---> Interop+Crypto+OpenSslCryptographicException: error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small
   --- End of inner exception stack trace ---

You can resolve this error a couple different ways;

1. Modify /etc/ssl/openssl.crt, by adding the following at the top of the file:

# System default
openssl_conf = default_conf

and this at the bottom:

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=1

This works by setting the CipherString to SECLEVEL 1 instead of the default which is SECLEVEL 2. The problem with this is it requires you modify the OS-level configuration for the container/server which means the library won't work out of the box.

2. The second way that works to resolve it, is by modifying the C# code in this library. This requires code that references methods present only in >= .Net 5.

in SyslogSecureTransport.cs, in the GetNetworkStream method, the following change resolves the issue, by making every TlsCipherSuite acceptable - which isn't ideal.

- await sslStream.AuthenticateAsClientAsync(Hostname).ConfigureAwait(false);
+ var sas = new SslClientAuthenticationOptions();
+ sas.TargetHost = Hostname;
+ sas.CipherSuitesPolicy = new CipherSuitesPolicy(Enum.GetValues<TlsCipherSuite>());
+
+ await sslStream.AuthenticateAsClientAsync(sas).ConfigureAwait(false);

Both methods will work to solve the issue, but neither are particularly elegant. It would be great to fix this inside the library, but it would need to take into account whether the library is targeting .Net5 and is running on Linux vs Windows, and be more precise on exactly what ciphers are needed.

I hope this info is helpful at least as a starting point to coming up with a solution that can be made part of this package. Happy to provide any additional info.