preface

Previously, through tool scanning, the test partner found that the platform TLS SSL protocol supports TLS v1.1, which is not safe. The TLS SSL protocol should be at least v1.2 or above. It is thought that we have only supported v1.3, which should not be a problem of our platform. I still confidently explain that it has nothing to do with our platform and should be related to openssl's own configuration and support for v1.1, but this problem must be solved. With a skeptical attitude, is it a code problem? Therefore, we began to explore the road. This paper takes ASP.NET Core 3.1.20 as an example

Verify TLS SSL protocol issues

Because there are too many platform related configurations enabled to eliminate the impact, I wrote a clean web api separately. The code is as follows.

webBuilder.UseStartup<Startup>();
webBuilder.UseKestrel(options => 
{
    var sslCertPath = Path.Combine(AppContext.BaseDirectory, "ssl.pfx");

    options.Listen(IPAddress.Any, 5000,
        listenOption =>
        {
            listenOption.UseHttps(sslCertPath, "KSnRJkGPf@OVA8uDsY*D5EP4kd!AagLS84uNS~5@@u#dKrNxHC");
        });

    options.ConfigureHttpsDefaults(co =>
    {
      co.SslProtocols = SslProtocols.Tls13;
    });

});

Then we publish it to linux and run it, as follows:

Next, we scan the port with the help of nmap tool, as follows:

Wait patiently for a while. The final scan output is as follows. I was stunned

 . NET Core TLS SSL protocol is enabled by default to support v1.1 and v1.2. It is clearly set to support only v1.3. Isn't this the same as not set?

webBuilder.UseStartup<Startup>();
webBuilder.UseKestrel(options => 
{
    var sslCertPath = Path.Combine(AppContext.BaseDirectory, "ssl.pfx");

    options.ConfigureHttpsDefaults(co =>
    {
        co.SslProtocols = SslProtocols.Tls12;
    });

    options.Listen(IPAddress.Any, 5000,
        listenOption =>
        {
            listenOption.UseHttps(sslCertPath, "KSnRJkGPf@OVA8uDsY*D5EP4kd!AagLS84uNS~5@@u#dKrNxHC");
        });

});

That only means that there is a problem with the code. Since it has been set but has not taken effect, so, it means that there is a problem with the release order. What will happen if I put the above setting protocol before listening to HTTPS? As mentioned above, first of all, we configure that only v1.2 is supported. Will v1.1 be scanned?

So far, the TLS SSL protocol specification has been solved. It is normal to think about it. A connection must be established before listening to the port, so the protocol configuration must be specified before listening to the port. Here, we will further understand the principle and the whole process of protocol and port listening, Let's first look at the general implementation of HTTPS built-in by specifying SSL certificate path and password listening

There are multiple overloads listening to HTTPS. It seems that X509Certificate2 is used to load certificates, verify certificates, and so on

The built-in assignment class loads the certificate, and then applies various options in the following extension methods. The following notes are the options for connection by reference

Since we configured SSL v1.3 protocol to listen to HTTPS at the beginning, the default protocols 1.1 and 1.2 are used when executing here

At the same time, it should be noted that in. Net core version 3. X, the certificate password must be provided, but in this case, I check the source code. If I remember correctly, it should be in 5.x, and the certificate password can be empty

In fact, the monitoring HTTPS extension method provides the overload of the TLS SSL protocol used to connect. At that time, I didn't think so much about the configuration, because the previous configuration has been written, and the platform can turn on HTTP or HTTPS according to the actual situation, so I directly call the default HTTPS option configuration, and the result is careless

Of course, if it is clear that it must be HTTPS protocol, we can also modify it based on the default configuration, as follows:

webBuilder.UseStartup<Startup>();
webBuilder.UseKestrel(options =>
{
    var sslCertPath = Path.Combine(AppContext.BaseDirectory, "ssl.pfx");

    options.ConfigureHttpsDefaults(co =>
    {
        co.SslProtocols = SslProtocols.Tls13;
        co.ServerCertificate = new X509Certificate2(sslCertPath, "KSnRJkGPf@OVA8uDsY*D5EP4kd!AagLS84uNS~5@@u#dKrNxHC");
    });

    options.Listen(IPAddress.Any, 5000);

});

summary

There's nothing to summarize. I lost Jingzhou carelessly and covered my face... I once suspected that v1.3 was configured, but tool scanning supported 1.1 and 1.2. I thought that the problem was the openssl configuration support. I didn't think of a moment's negligence. If I didn't consider the connection process, the corresponding configuration sequence should also be consistent. NET Core provides a variety of configurations, but I just got stuck in the middle, I took advantage of my own loopholes. Learn more later and start writing more about the deployment and operation of. NET Core on Linux. OK, see you next time!