client and server cannot communicate, because they do not possess a common algorithm - SSLStream

Question

There are lot of similar questions already answered and none of the answers help my current scenario.

In the windows service we have TCPL SSL stream and client connecting to the stream.

I have created a .NET Client and am able to access the server successfully with Strict TLS 1.2 using IIS Crypto.

We are trying to access the server using Lantronix xport Pro and the below line throws exception

stream.AuthenticateAsServer(serverCertificate, false, SslProtocols.Ssl3| SslProtocols.Tls | SslProtocols.Tls11 | SslProtocols.Tls12, True);

Exception happens only if strict TLS 1.2 is enabled. If we have SSL3 protocol enabled everything works fine without any issues.

using WireShark i can see client sending TLS 1.2 request with below ciphers

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

As per MSDN above Ciphers are supporting TLS 1.2

Am not having any issue connecting from the .net Client which we created for testing purposes with strict TLS 1.2

Creating a self signed certificate using open ssl. server is running with windows server 2012 R2.

Am not sure on what options i should try for SSLstream specific to TLS 1.2 ?

Is there any thing specific i need to for other than .net client to communicate ?

Any suggestions on tracing this issue would be great

Update on the Lantrix Pro request

Frame 33845: 112 bytes on wire (896 bits), 112 bytes captured (896 bits) on interface 0
Ethernet II, Src: Pronet_c7:bb:29 (00:20:4a:c7:bb:29), Dst: Vmware_99:95:c7 (00:50:56:99:95:c7)
Internet Protocol Version 4, Src: 10.10.110.71, Dst: 10.10.110.10
Transmission Control Protocol, Src Port: 38182, Dst Port: 28000, Seq: 1, Ack: 1, Len: 58
Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 53
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 49
            Version: TLS 1.2 (0x0303)
            Random: 8a f5 6f 9e 92 65 43 c7 45 9b 57 ff dd a4 22 45 ...
                GMT Unix Time: Nov 16, 2043 20:38:22.000000000 Central Standard Time
                Random Bytes: 92 65 43 c7 45 9b 57 ff dd a4 22 45 12 16 cb 41 ...
            Session ID Length: 0
            Cipher Suites Length: 10
            Cipher Suites (5 suites)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 (0x0060)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
                Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)

This is practically the same as [this question](https://serverfault.com/questions/905452/an-tls-1-2-connection-request-was-received-from-a-remote-client-application-but). As I said there already this indicates that the Lantronix xport Pro does not support TLS 1.2. The documentation of the device claims only support for SSLv3. While you claim that the device supports TLS 1.2 (contrary to the documentation) you still did not provide proof of it in the form of a pcap. — Steffen Ullrich, Apr 03 '18 at 21:00
@Tharun I don't see any SSL handshake in this capture. NO handshaking means NO client hello means NOT possible to say you are using TLS 1.2 — Eugène Adell, Apr 03 '18 at 21:21
@EugèneAdell am seeing from the pcap i shared. Client hello generated from 10.10.110.71 — Peru, Apr 03 '18 at 21:51
why negative votes ? i shared the pcap and i can see the client hello generated with TLS 1.2 — Peru, Apr 03 '18 at 23:22
@SteffenUllrich i have updated the question with PCAP request of client hello — Peru, Apr 03 '18 at 23:36
@EugèneAdell i have updated the question with PCAP request of client hello — Peru, Apr 03 '18 at 23:36
@Tharun Please post the capture and give the packet number of this Client Hello. Then we can follow and see the server's answer. — Eugène Adell, Apr 04 '18 at 07:07
@EugèneAdell here we go https://drive.google.com/open?id=1ubkZ8LwMsBfPjb6gCXO8A9BwrdS_dCG6 packet number :: 33845 . Sorry am new to crypto and am trying to learn and fix this — Peru, Apr 04 '18 at 12:14
@SteffenUllrich i have updated pcap https://drive.google.com/open?id=1ubkZ8LwMsBfPjb6gCXO8A9BwrdS_dCG6 and also the packet number :: 33845 — Peru, Apr 04 '18 at 13:42
@Tharun: have you've verified that your specific server actually supports any of these ciphers? Probably the only secure one of these is TLS_RSA_WITH_AES_128_CBC_SHA. You could check for example with `openssl s_client -connect host:port -cipher "AES128-SHA"` and see if you get a successful handshake. If you do please also provide a pcap of this handshake for comparison with the failed handshake. — Steffen Ullrich, Apr 04 '18 at 15:12
@SteffenUllrich am using windows 2012 R2 and using Crypto i can see the cipher available in the server. here is the PCAP link https://drive.google.com/open?id=12i6yc2Xp2FabrvbveS4PDYuTZKgRyAAv File Name :: Cipher Issue.pcapng this is successful if i enable TLS 1.0 in server Packet number: 1595 and other one 6800Peruip.pcapng is the failure one with only TLS 1.2 packet number :: 33845 — Peru, Apr 04 '18 at 17:05
@SteffenUllrich Another file cipher issue_Openssl client.pcapng i executed your openssl command packetNumber: 2337. As i mentioned the server using TCP SSLStream and not http. please let me know if you have any questions — Peru, Apr 04 '18 at 17:12

score 4 · Accepted Answer · edited Oct 07 '21 at 08:57

4

TL;DR: the client is broken. It looks like the vendor barely added minimal TLS 1.2 support to an old product while keeping insecure ciphers and failing to add support for the currently used SHA-256 signed certificates.

The client does only send a very minimal TLS 1.2 handshake. It only contains 5 ciphers (where the 3 EXPORT ciphers are critically insecure, the 3DES cipher is slightly insecure but the AES128-SHA is acceptable). And, compared to other TLS successful 1.2 handshakes it does not contain the signature_algorithm TLS extension.

This extension is new to TLS 1.2. It is used to tell the server which signature algorithms are supported. If the extension is not provided it will default to SHA1 with RSA for the ciphers offered. To cite from the 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}.

But, the server provides a certificate with an RSA key but with SHA-256 as hash. Thus, this certificate will not match the accepted signature algorithms and the handshake fails. If the server instead allows TLS 1.1 or lower then the handshake will succeed since the signature_algorithm extension is ignored with these lower protocol versions and thus the server can send the SHA-256 signed certificate it has.

As can be seen from a capture with an openssl s_client in the provided pcaps the TLS 1.2 handshake works if the client provides the signature_algorithm extension and signals support for RSA and SHA-256.

edited Oct 07 '21 at 08:57

Community

1
1

answered Apr 04 '18 at 19:29

Steffen Ullrich

114,247
10
131
172

Thank you @SteffenUllrich for your detailed analysis. do you think it might be related to https://stackoverflow.com/questions/22825663/cipher-selection-for-sslstream-in-net-4-5 or how can i handle this from my .net code, SSL certificate creation steps as i have very little control over the client ? – Peru Apr 04 '18 at 19:40
sorry if the questions sound stupid am relatively new to this crytpo side. we are using open ssl to create self signed certificates. if we use any other hash to create certificates will the ciphers match ? – Peru Apr 04 '18 at 19:48
@Tharun: I don't think this is related. As for the certificate: these get created outside of the server application, for example bought from a public CA. But, SHA-1 certificates are deprecated for a while so no public CA will issue such a certificate. But, if the vendor claims to have support for TLS 1.2 then he should fix the problem. As for now your only choice is probably only to also allow TLS 1.1 and maybe TLS 1.0 which is still safe enough. – Steffen Ullrich Apr 04 '18 at 19:53
@Tharun: if you create self-signed certificates then you can simply use sha1 as hash algorithm to create the certificate. But maybe it would be better to keep the sha256 and instead accept TLS 1.1 too. – Steffen Ullrich Apr 04 '18 at 19:54
Thank you @SteffenUllrich for your detailed answers. – Peru Apr 04 '18 at 20:10
@SteffenUllrich i tried 2 things but both did not work. Enables TLS 1.1 also tried to create SHA1 self signed. It works only with TLS 1.0 and early. – Peru Apr 04 '18 at 22:48
@Tharun: hard to tell what is happening here. Did you made sure that the TLS 1.1 and SHA-1 tests did work with `openssl s_client` (like cmdline `-tls1_1`) and can you provide the pcaps auf successful s_client tests vs. unsuccessful tests with Lantrix Pro for the same server setup? – Steffen Ullrich Apr 05 '18 at 07:06
@SteffenUllrich i think am not understanding this enough. I tried openssl s_client -connect host:port -cipher "AES128-SHA" Negotiation happens with TLS 1.1. I tried openssl s_client -connect host:port -tls1_2 then negotiation fails. if i make server strict TLS1.2 openssl s_client -connect host:port -cipher "AES128-SHA" also fails. this happens only in TCP SSLStream 28000 port no. if i use openssl with port 443 all works fine. – Peru Apr 05 '18 at 15:42
@Tharun: I assume that on port 443 you have some web server while on port 28000 your special .net server - i.e. different servers with different settings. In this case I guess that there is some problem within your specific application too but I have not enough insight into your application and I have no way to reproduce your problem. – Steffen Ullrich Apr 05 '18 at 16:20

client and server cannot communicate, because they do not possess a common algorithm - SSLStream

Update on the Lantrix Pro request

1 Answers1

Linked