0

I'm getting error "The client and server cannot communicate, because they do not possess a common algorithm" when I try to fetch the xml data from the link https://ssi.gouv.fr/uploads/tl-fr.xml from my .NET framework 4.8 C# code. Here's the code:

        static void Main(string[] args)
        {
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls13;
            string link = "https://ssi.gouv.fr/uploads/tl-fr.xml";
            XmlDocument xmlDocument = null;
            HttpWebRequest httpWebRequest = null;
            httpWebRequest = WebRequest.Create(link) as HttpWebRequest;
            string xml = new StreamReader(httpWebRequest.GetResponse().GetResponseStream()).ReadToEnd();
            xmlDocument = new XmlDocument();
            xmlDocument.LoadXml(xml);
            /// ...

        }

I'm running this code on my Windows 10 machine, which has .NET Framework 4.8 installed.

Also, the app.config file for this application look like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.8"/>
    </startup>
</configuration>

Note: If you go to https://www.ssllabs.com/ssltest and try to test the server ssi.gouv.fr to which the above code tries to connect, you'll see that the server supports only TLS 1.3 protocol, but that should not be a problem (i think), since I can fetch the xml file with the Chrome browser on that same machine, so the TLS 1.3 is obviously working on my Windows 10. But, nonetheless, the code above cannot connect.

So, What should I do to correct this error?

(I tried to omit the line ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls13; hoping that will somehow fixes it, but then I just get a different error: Authentication failed because the remote party has closed the transport stream.)

UPDATE: I capture the network snapshot with Wireshark and it seems the client (ie my C# .NET Framework code) never sends TLS "Client hello" message at all:

No. Time    Source  Destination Protocol    Length  Info
144 7.604359    192.168.5.25    80.247.12.150   TCP 66  49924 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
145 7.636332    80.247.12.150   192.168.5.25    TCP 66  443 → 49924 [SYN, ACK] Seq=0 Ack=1 Win=62720 Len=0 MSS=1452 SACK_PERM WS=128
146 7.636485    192.168.5.25    80.247.12.150   TCP 54  49924 → 443 [ACK] Seq=1 Ack=1 Win=132096 Len=0
147 7.648440    192.168.5.25    80.247.12.150   TCP 54  49924 → 443 [FIN, ACK] Seq=1 Ack=1 Win=132096 Len=0
149 7.678320    80.247.12.150   192.168.5.25    TCP 54  443 → 49924 [FIN, ACK] Seq=1 Ack=2 Win=62720 Len=0
150 7.678400    192.168.5.25    80.247.12.150   TCP 54  49924 → 443 [ACK] Seq=2 Ack=2 Win=132096 Len=0

Interestingly, on the same machine, when I make request with Python3, with 'requests' library, It connects without a problem and correctly fetch the xml document:

>> r = requests.get("https://ssi.gouv.fr/uploads/tl-fr.xml", verify=False)

With python, wireshark capture looks entirely right:

No. Time    Source  Destination Protocol    Length  Info
159 4.522116    192.168.5.25    80.247.12.150   TCP 66  50494 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
160 4.552163    80.247.12.150   192.168.5.25    TCP 66  443 → 50494 [SYN, ACK] Seq=0 Ack=1 Win=62720 Len=0 MSS=1452 SACK_PERM WS=128
161 4.552224    192.168.5.25    80.247.12.150   TCP 54  50494 → 443 [ACK] Seq=1 Ack=1 Win=132096 Len=0
162 4.607799    192.168.5.25    80.247.12.150   TLSv1.3 571 Client Hello
163 4.638201    80.247.12.150   192.168.5.25    TCP 54  443 → 50494 [ACK] Seq=1 Ack=518 Win=62208 Len=0
164 4.638201    80.247.12.150   192.168.5.25    TLSv1.3 153 Hello Retry Request, Change Cipher Spec
165 4.639889    192.168.5.25    80.247.12.150   TLSv1.3 577 Change Cipher Spec, Client Hello
166 4.670279    80.247.12.150   192.168.5.25    TCP 54  443 → 50494 [ACK] Seq=100 Ack=1041 Win=61696 Len=0
167 4.673711    80.247.12.150   192.168.5.25    TLSv1.3 1506    Server Hello, Application Data
168 4.673711    80.247.12.150   192.168.5.25    TLSv1.3 1360    Application Data, Application Data, Application Data
169 4.673765    192.168.5.25    80.247.12.150   TCP 54  50494 → 443 [ACK] Seq=1041 Ack=2858 Win=132096 Len=0
170 4.676046    192.168.5.25    80.247.12.150   TLSv1.3 128 Application Data
171 4.676768    192.168.5.25    80.247.12.150   TLSv1.3 235 Application Data
172 4.705903    80.247.12.150   192.168.5.25    TCP 54  443 → 50494 [ACK] Seq=2858 Ack=1115 Win=61696 Len=0
173 4.705903    80.247.12.150   192.168.5.25    TLSv1.3 133 Application Data
174 4.705903    80.247.12.150   192.168.5.25    TLSv1.3 133 Application Data
etc...

So, what's the damn problem here, why connecting from .NET Framework 4.8 doesn't work, but from Python and Chrome browser does???

UPDATE 2: I just added registry settings for the client like described here: how to enable TLS 1.3 in windows 10 Now i get different error: "The request was aborted: Could not create SSL/TLS secure channel." Also, wireshark capture now looks something better, but stil can't connect:

No. Time    Source  Destination Protocol    Length  Info
34  7.218616    192.168.5.25    80.247.12.150   TCP 66  51576 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
35  7.248684    80.247.12.150   192.168.5.25    TCP 66  443 → 51576 [SYN, ACK] Seq=0 Ack=1 Win=62720 Len=0 MSS=1452 SACK_PERM WS=128
36  7.248769    192.168.5.25    80.247.12.150   TCP 54  51576 → 443 [ACK] Seq=1 Ack=1 Win=132096 Len=0
37  7.255787    192.168.5.25    80.247.12.150   TLSv1.3 242 Client Hello
38  7.285955    80.247.12.150   192.168.5.25    TCP 54  443 → 51576 [ACK] Seq=1 Ack=189 Win=62592 Len=0
39  7.285955    80.247.12.150   192.168.5.25    TLSv1.3 121 Hello Retry Request, Change Cipher Spec
40  7.289652    192.168.5.25    80.247.12.150   TLSv1.3 307 Client Hello
41  7.320062    80.247.12.150   192.168.5.25    TCP 54  443 → 51576 [ACK] Seq=68 Ack=442 Win=62464 Len=0
42  7.322317    80.247.12.150   192.168.5.25    TLSv1.3 1506    Server Hello, Application Data
43  7.322317    80.247.12.150   192.168.5.25    TLSv1.3 1313    Application Data, Application Data, Application Data
44  7.322404    192.168.5.25    80.247.12.150   TCP 54  51576 → 443 [ACK] Seq=442 Ack=2779 Win=132096 Len=0
45  7.325886    192.168.5.25    80.247.12.150   TCP 54  51576 → 443 [RST, ACK] Seq=442 Ack=2779 Win=0 Len=0

But at least, there is Client Hello message, which I previously didn't have. What should I do now?

UPDATE 3: I got it work right! After I added the above-mentioned registry settings, the line

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls13

had to be removed and then everything worked.

Connecting via HttpClient and via the old WebRequest works, no difference. But interestingly, it won't work when

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls13 is specified. I don't know why, it's really weird!

xenax
  • 39
  • 5
  • yes, @Charlieface, I already tried with HttpClient, but that doesn't work either. :( – xenax May 09 '23 at 13:46
  • 1
    Usw Wireshark to track the Server Hello and Client Hello, and please show us what the offered ciphers are on each side. – Charlieface May 09 '23 at 14:19
  • @Charlieface: I'm sorry, I'm afraid I don't know how to use Wireshark. Does somebody tried to run the snippet above with .NET Framework 4.8 on Windows 10? Did you get the same error as I do? – xenax May 09 '23 at 14:29
  • I managed to make the Wireshark snapshot. It never makes to "Client Hello" (see updated post above) – xenax May 09 '23 at 15:40
  • Hmm that's weird. *"that should not be a problem (i think), since I can fetch the xml file with the Chrome browser"* Chrome is not relevant, because Chrome uses its own TLS libraries. Which exact build number of Windows and .NET are you using? – Charlieface May 09 '23 at 15:57
  • The windows version is: Windows 10, Version 22H2 (OS Build 19045.2846). I don't know how to find the build number of .NET framework, but it's the .NET 4.8 (and I tried .NET 4.8.1 on another computer, but with te same bad result) – xenax May 09 '23 at 16:07
  • Double check TLS 1.3 is enabled in the registry https://stackoverflow.com/a/59210166/14868997 – Charlieface May 09 '23 at 16:09
  • I just did, look UPDATE 2 in original post! – xenax May 09 '23 at 16:31
  • OK good we're getting somewhere. Can you show the inner values from the Hello's specifically the Cipher list – Charlieface May 09 '23 at 16:32

1 Answers1

0

It seems explicitly specifying ServicePointManager.SecurityProtocol is causing problems. Possibly there is another enum value that it's supposed to be which it doesn't match, even though SSLlabs reports it as TLS 1.3.

Given that it's recommended to rely on the operating system, you should remove that line completely. This would for example allow you to use the unreleased TLS 1.4 for example, if it ever became available.

You also need to enable various registry settings, see how to enable TLS 1.3 in windows 10

Charlieface
  • 52,284
  • 6
  • 19
  • 43