Detailed process of configuring TLS cipher (Suite) for. Net core



Not long ago, I published an article on TLS protocol configuration, which was exploited by me. After verification by a third-party partner, there is an unsafe suite for this TLS protocol. We need to solve it quickly. Then we will continue to work on this article! The third-party partners have strict requirements for platform security. We have distributed the version for more than ten times. In this process, I have a further understanding of security. The specific understanding is in two aspects: technical solutions and blind spots in cryptography. Now let’s understand two aspects, which may not be fully in-depth. At least for us as developers, it should be basically enough

. net core cipher (Suite) configuration

If there were no strict requirements on the project, I would definitely not be able to carry out research and practice in this regard. This stationery is in English Net 5 as an example, just for Net core 3 or 3.1. The results of the protocol suite scanned by the tool are slightly different, but it does not affect our configuration of the security suite. We use OpenSSL to generate self signed certificates. Later, I will publish an article to explain OpenSSL self signed certificates, etc

webBuilder.ConfigureKestrel(serverOptions =>
    serverOptions.Listen(IPAddress.Any, 8000, listenOptions =>
        listenOptions.UseHttps("ssl.pfx", "123456", adapterOptions =>
          adapterOptions.SslProtocols = SslProtocols.Tls12;

HTTPS combined with TLS protocol 1.0 or 1.1 is not safe, so TLS protocol needs to use 1.2 +. Here, we use version 1.2 as the above code. Next, we deploy it on Linux, install nmap, and scan through nmap tool (as for what nmap is, you can learn by yourself)

Scan the specified port number through nmap and enumerate its support for TLS suite. It should be noted that we may search the command results of most articles. In fact, nmap is only effective for scanning the specified port (such as 443). For example, using the following commands has no effect

nmap –script ssl-enum-ciphers localhost -p 8000

For other ports, you can use the following command to scan

nmap –script +ssl-enum-ciphers localhost -p 8000

Finally, the scanning results are as follows:

Aes-cbc mode has some known security vulnerabilities in SSL or TLS, such as beast attack, Lucky 13 attack, etc 1、TLS1. 2 is not affected by beast attack, Lucky 13 (involving tls1.1 / 1.2) attack has also been repaired in well-known encryption algorithm libraries such as OpenSSL, but these vulnerabilities all leak out the CBC mode, which is easy to introduce security vulnerabilities in the implementation of SSL / TLS protocol, and HTTP / 2 also explicitly lists the CBC mode encryption suite as a blacklist

The above is in Net 5 TLS 1.2 is the default behavior, but the third party stipulates that aes-cbc is prohibited, even if the scanned suite strength is a and the security suite it supports is given

In the above configuration, the method of reading files through paths and enabling HTTPS overloading with passwords is as follows

public static ListenOptions UseHttps(this ListenOptions listenOptions, string fileName, string password, Action<HttpsConnectionAdapterOptions> configureOptions);

Finally, you can configure the connection. In this class, there are the following properties

public Action<ConnectionContext, SslServerAuthenticationOptions> OnAuthenticate { get; set; }

In the second class parameter, there is the configuration for the suite, as follows (I also found it in combination with GitHub for half a day)

Therefore, the final security packages we configured and supported are as follows (many packages, unheard of, never mind, will be summarized below):

webBuilder.ConfigureKestrel(serverOptions =>
  serverOptions.Listen(IPAddress.Any, 8000, listenOptions =>
    listenOptions.UseHttps("ssl.pfx", "123456", adapterOptions =>
      adapterOptions.SslProtocols = SslProtocols.Tls12;

      adapterOptions.OnAuthenticate = (connectionContext, authenticationOptions) =>
        var ciphers = new List<TlsCipherSuite>()

        authenticationOptions.EnabledSslProtocols = SslProtocols.Tls12;
        authenticationOptions.CipherSuitesPolicy = new CipherSuitesPolicy(ciphers);

Cough, so far, we are full of joy. Is it so happy that it’s over? When you come into contact with a new point, you must first look at the explanation. Don’t make it difficult to operate after a meal. It takes time and labor, but it’s all useless work. Finally, you can find the problem node. This is my profound experience recently

According to my preliminary understanding, it should be in Net core 3.0 + starts to support the configuration of OpenSSL suite, and the version must be 1.1.1 +, but it does not support windows, only Linux or OSX! At the same time Net core version 3.1 and below, the default protocol is 1.1 or 1.2, but in Net 5 default protocol is changed to 1.3, and its support suite configuration is also related to OpenSSL configuration. See link《

When I come into contact with a certain knowledge point (such as TLS), I think it’s necessary to take a look at whether there are changes in this aspect in the later version. Suppose we don’t know Net 5 + is changed to 1.3 by default. After the version upgrade, if the third-party docking previously used TLS 1.2, the data docking will be broken and the business will be affected. Just my personal suggestion, I can’t control others ~ ~ ~ based on the above, if you are in the windows development environment, you are bound to judge the operating system on the corresponding basis

if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX) || RuntimeInformation.IsOSPlatform(OSPlatform.Linux))

Finally, our scanning results are as follows. The aes-cbc unsafe kit has been removed and fully meets the safety requirements

Foundations of Cryptography

There are four algorithms used in the cipher Suite: symmetric encryption algorithm, asymmetric key exchange algorithm, digital signature algorithm (DSA) and optional hash based message authentication code (HMAC)

To put it bluntly, the cryptography suite is a set of algorithms. Only by opening HTTPS and TLS and using the cryptography suite together can the transmission be more secure

We know that all algorithms are public. The only difference is that the algorithm depends on the key. Only the docking parties know it, so as to protect the encrypted ciphertext from prying. Next, let’s split and explain the above algorithms

Asymmetric encryption algorithm, to put it bluntly, is that one party has the public key and the other party has the private key. It is negotiated between the browser and the server through TLS handshake at the beginning. It can be used as an encryption suite. As for the rest of HTTPS, it can be used with the agreed cipher suite

The three main algorithms used in the initial handshake through TLS are:

DHE: Diffie Hellman ephemeral (key exchange algorithm)

RSA: named after its inventor Rivest Shamir Adleman

Ecdhe: elliptic curve Diffie – Hellman

Symmetric algorithm, to put it bluntly, is a single key known by both parties. Compared with asymmetric encryption algorithm, its calculation speed is faster, but it is not suitable for web certificate. Because the browser and server do not know and completely distrust each other, they cannot share the key. However, after the initial handshake protocol, It is appropriate to use the symmetric encryption algorithm again, that is, to create a shared key for use during other periods of HTTPS communication

The four most common symmetric encryption algorithms are:

AES:Advanced Encryption Standard

AES-GCM:AES Galois/Counter

Aes-ccm: AES counter with cbc-mac

Cha20: also known as salsa20

Password strength is a security measure. How secure is the encrypted text when attacked? The strength of the algorithm is related to the length of the key, so the longer key is more powerful. The key length is expressed in digits, and the commonly used values are 128 and 256. Symmetric algorithms are identified by their acronyms and their key length, such as aes128 or aes256.

After talking so much, I seem to know the names of several algorithms. If I leave the content of this article and leave a little impression on my mind, then let’s make a practical understanding in combination with the configured cipher suite. Let’s take the first cipher suite of the above configuration to elaborate, and the rest are the same, as follows


The tlsciphersuite above is an enumeration. Let’s just look at the enumeration content. Remove TLS and the rest is DHE_ RSA_ WITH_ AES_ 128_ GCM_ SHA256

We combine the asymmetric and symmetric encryption algorithms described above to split them into DHE, RSA and aes-128-gcm

From the result of the final split, in fact, HTTPS uses a pair of algorithms rather than a single algorithm. One asymmetric encryption DHE and RSA are used for TLS handshake during the initial period, while the other symmetric encryption algorithm aes-128-gcm is used for encryption and decryption during data transmission! In this way, symmetric and asymmetric encryption algorithms are used for HTTPS to form a variety of combinations

However, simply selecting a pair of asymmetric / symmetric algorithms is not enough to fully identify the cipher suite, so you also need to specify rules to ensure authentication and integrity. For example, issue certificates through letsencrypt certification authority. The deeper cryptography will not be carried out here, and I will explore it here

The cryptographic suite configured in. Net core is consistent with the suite supported by OpenSSL, as shown in the screenshot below:

So here’s the problem. We have configured a variety of packages. As a result, three supported packages are scanned through the tool scanning. Which one should be selected when the browser and server shake hands with TLS for the first time? Then, let’s visit and check whether the web certificate can find any clues, and make a statement in advance: the following parts are my personal speculation, but it’s unknown whether it’s true in theory as I said

By looking at the certificate pushback, we use RSA plus sha256 algorithm to create self signed certificates through OpenSSL, and then look at the figure below to see the final suite used

Combined with these two, it can be explained that the corresponding OpenSSL configuration of the cipher suite used is: ecdhe-rsa-aes128-gcm-sha256, which corresponds to the first of the three suites scanned by nmap tool

Ecdhe-rsa-aes128-gcm-sha256 conclusion from the above certificate and security view, because it is sha256rsa, the last Password Suite is sha256. If so, can I justify it? If we delete the sha256 suite, will the page not be supported and the web page cannot be accessed?

After the above modifications and nmap scanning, the results are as follows:

It seems that it has nothing to do with the algorithm mentioned on the certificate. Finally, I returned to the command of self creating certificate

openssl genrsa -out ca-key.key 3072

It can only match the RSA asymmetric encryption algorithm used. OpenSSL can specify the encryption method

But when I specify aes128 or other bits, the mode is actually CBC rather than GCM

Finally, check whether GCM is supported

openssl aes-256-gcm

In fact, OpenSSL supports GCM, but you can’t use the command line to operate. The specific reason is officially explained. After analyzing so much, it seems useless. At present, we can roughly determine that the support of Password Suite still needs the browser and server to shake hands and negotiate

For example, you can set whether to enable TLS 1.3 in Google browser

So far, we generally know that HTTPS uses a set of algorithms. Asymmetric encryption algorithm is used during handshake and symmetric encryption algorithm is used during data transmission! During the whole period, the guess is to combine the generated certificate, then traverse the configuration suite to shake hands, and then carry out data transmission after the handshake is successful

The general handshake and data transmission process are briefly described as follows:

The client sends messages to the server. I use ecdhe-rsa-aes128-gcm-sha256 in TLS 1.2 and other packages. Can you handle it? The server replies the message to the client, ecdhe-rsa-aes128-gcm-sha256 can handle it, and then sends the public key certificate to the client. The client replies to the server that the certificate is legal. The client generates the key 6p7vujfz, then encrypts it with the public key certificate of the server, and notifies the server that the specified key, i.e. shared key, will be used for data transmission in the future

When customizing the supported suite, it should be noted that TLS 1.2 and tls1.2 should not be specified at the same time three

This is about Net core configuration TLS cipher (Suite) of the detailed process of the article introduced here, more related Net core configuration TLS cipher content, please search the previous articles of developeppaer or continue to browse the relevant articles below. I hope you can support developeppaer in the future!