0

Am using a .net application where the client connects to our server using TCP SSL Stream. Application is using .net 4.5 and running as a windows service in Windows server 2012 R2.

We are using SHA256 certificate and Client is not able to negotiate with strict TLS 1.2. was getting "client and server cannot communicate, because they do not possess a common algorithm - SSLStream"

stream.AuthenticateAsServer(serverCertificate, false, SslProtocols.Tls12, True);

Thanks to Steffen Ullrich for this answer which helped me troubleshoot further.

When we use SHA1 Certificate Client is able to successfully negotiate with TLS 1.2

from RFC

If the client does not send the signature_algorithms extension, the server MUST do the following:

If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent the value {sha1,rsa}.

My client is supporting SHA256 but they are not sending signature algorithm as part of the TLS 1.2 request and server by default negotiates with SHA1 and not SHA256.

SHA256,SHA1 works fine with TLS 1.0
SHA1 works with strict TLS 1.2
SHA256 not working with strict TLS 1.2

So my question Is there a way i can make the server to negotiate using SHA256 also even if my client does not send signature algorithm?

Peru
  • 2,871
  • 5
  • 37
  • 66
  • I suspect the answer to "how do I make .NET actively violate the specs" is "you can't, and that's by design". The whole point of a negotiation is that client and server must agree on what they support -- if a client supports something but refuses to indicate that, there's nothing the server can do. How do you know the client supports SHA-256 anyway, without the client indicating it? If that's the information the vendor has given you, maybe can they also tell you how to make it respect the standards? – Jeroen Mostert Apr 16 '18 at 14:49
  • @JeroenMostert Completely agree. But just want to bring it up to you guys to know the view point to know if there is an possibility of specifying HashAlgorithm in the SSLstream class or any other way which i did not know? i was told they tested in Linux and works with SHA256 so i got confused – Peru Apr 16 '18 at 14:54
  • `SslStream` doesn't implement the negotiation itself; it delegates to the OS libraries (Schannel on Windows). If there's any way to tune it, it would be there, but I'm not sure there's any configuration that would allow this particular standards violation. If you want to try your luck, you could actually run your .NET code on .NET Core on Linux, where it's going to use OpenSSL. Who knows, maybe that works out of the box, if they say they've tested on Linux. – Jeroen Mostert Apr 16 '18 at 19:44
  • @JeroenMostert i tried to create a openssl server(Openssl s_server -tls1_2 ) in windows and the client is able to communicate using TLS 1.2. only my ssl stream is not able to validate it. i used the sample similar to here as well https://msdn.microsoft.com/en-us/library/system.net.security.sslstream%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396 – Peru Apr 16 '18 at 19:53
  • An OpenSSL server on Windows does *not* delegate to Schannel; it implements the negotiation itself. But you cannot make the .NET Framework's `SslStream` use OpenSSL, and it has no way to customize algorithm negotation (that I know of). What you could do is run an HAProxy (or similar) in front of your Windows Server, using OpenSSL or some other lib that supports the desired setup, and have that proxy communicate with your service using plain old HTTP. This is assuming your server doesn't care about HTTPS itself, and you don't mind maintaining a Linux server (virtual or otherwise). – Jeroen Mostert Apr 16 '18 at 20:16
  • Thank you @JeroenMostert. You can add this as your answer with little more details. that helps me with little more exploration as am very new to all this!! – Peru Apr 17 '18 at 13:14

0 Answers0