Shulou(Shulou.com)06/02 Report--

This article introduces the knowledge of "how to configure TLS Cipher with .NET Core". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

.net Core Cipher (suite) configuration

Without the stringent requirements of the project, I would definitely not be able to carry out research and practice in this area. This stationery takes .NET 5 as an example, but there is a slight difference in the results of the protocol suite scanned by .NET Core 3 or 3.1 through the tool, but it does not affect our configuration of the security suite. We use OpenSSL to generate self-signed certificates. I will publish an article on OpenSSL self-signed certificates and so on.

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

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

Use nmap scan to specify port number and enumerate its support for TLS suites. We may find out that the command results of most articles have no result at all. In fact, nmap is only valid for specified port scanning (such as 443, etc.). For example, using the following command has no effect.

Nmap-- script ssl-enum-ciphers localhost-p 8000

If it is another port, you can scan it using the following command

Nmap-- script + ssl-enum-ciphers localhost-p 8000

In the end, the result of our scan is as follows:

There are some known security loopholes in AES-CBC mode in SSL or TLS, such as BEAST attack, Lucky 13 attack and so on. Although TLS1.1 and TLS1.2 are not affected by BEAST attack, and Lucky 13 (impact involves TLS1.1/1.2) attack has also been repaired in well-known encryption algorithm libraries such as Openssl, these vulnerabilities reveal that CBC mode is easy to introduce security vulnerabilities in the implementation of SSL/TLS protocol. HTTP/2 also explicitly blacklists the CBC mode cipher suite.

The above is the default behavior in .NET 5 TLS 1.2, but the use of AES-CBC is prohibited by a third party, even if the scanned suite strength is An and the security suite it supports is given.

In the above configuration to read the file through the path and use the password to enable HTTPS overloading, the following

Public static ListenOptions UseHttps (this ListenOptions listenOptions, string fileName, string password, Action configureOptions)

Finally, you can configure for the connection, with the following properties in this class

Public Action OnAuthenticate {get; set;}

In the second class parameter, there is a configuration for the suite, as follows (it took me a long time to find it in combination with github)

So in the end, the security suites supported by our configuration are as follows (many packages are unheard of, it doesn't matter, which 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.TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TlsCipherSuite.TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TlsCipherSuite.TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TlsCipherSuite.TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TlsCipherSuite.TLS_PSK_WITH_AES_128_GCM_SHA256, TlsCipherSuite.TLS_PSK_WITH_AES_256_GCM_SHA384, TlsCipherSuite.TLS_DHE_PSK_WITH_AES_128_GCM_SHA256, TlsCipherSuite.TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, TlsCipherSuite.TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256, TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TlsCipherSuite.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TlsCipherSuite.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TlsCipherSuite.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TlsCipherSuite.TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 TlsCipherSuite.TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256, TlsCipherSuite.TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384, TlsCipherSuite.TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256, TlsCipherSuite.TLS_DHE_RSA_WITH_AES_128_CCM, TlsCipherSuite.TLS_DHE_RSA_WITH_AES_256_CCM TlsCipherSuite.TLS_DHE_RSA_WITH_AES_128_CCM_8, TlsCipherSuite.TLS_DHE_RSA_WITH_AES_256_CCM_8, TlsCipherSuite.TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TlsCipherSuite.TLS_PSK_WITH_AES_128_CCM, TlsCipherSuite.TLS_PSK_WITH_AES_256_CCM, TlsCipherSuite.TLS_DHE_PSK_WITH_AES_128_CCM TlsCipherSuite.TLS_DHE_PSK_WITH_AES_256_CCM, TlsCipherSuite.TLS_PSK_WITH_AES_128_CCM_8, TlsCipherSuite.TLS_PSK_WITH_AES_256_CCM_8, TlsCipherSuite.TLS_PSK_DHE_WITH_AES_128_CCM_8, TlsCipherSuite.TLS_PSK_DHE_WITH_AES_256_CCM_8, TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_CCM TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_AES_256_CCM, TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8, TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256} AuthenticationOptions.EnabledSslProtocols = SslProtocols.Tls12; authenticationOptions.CipherSuitesPolicy = new CipherSuitesPolicy (ciphers);};});})

Ahem, so far, we are full of joy. Is this the happy end? When you come into contact with a new point, you must first take a look at the explanation. Don't use it after a meal of operation. It takes time and labor and is all futile. Finally, you find the crux of the problem. This is what I have experienced only recently.

According to my preliminary understanding, the suite for configuring OpenSSL should not be supported until .NET Core 3.0 +, and the version must be 1.1.1 packages, but Windows is not supported, only Linux or OSX is supported! At the same time, the default protocol is 1.1 or 1.2 in versions below .NET Core 3.1, but in .NET 5, the default protocol is changed to 1.3, and the support suite configuration is also associated with the OpenSSL configuration.

When you come into contact with a certain knowledge point (such as TLS), I think it is necessary to take a look at whether there is any change in the higher version. Suppose we do not know that the default change of .NET 5 + is 1.3. After the version upgrade, if the third-party interface previously used TLS 1.2, then the data docking will be broken and the business will be affected. I personally suggest that I don't care about the rest ~ ~ based on the above, in the Windows development environment, it is necessary to judge the operating system on the basis of correspondence.

If (RuntimeInformation.IsOSPlatform (OSPlatform.OSX) | | RuntimeInformation.IsOSPlatform (OSPlatform.Linux)) {.}

Finally, our scan results are as follows, and the AES-CBC unsafe package has been removed to fully meet the security requirements.

The basis of cryptography

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

To put it bluntly, a cryptographic suite is a set of algorithms. Opening HTTPS and TLS and using the cryptographic suite together can make the transmission more secure.

We know that the algorithms are public, the only difference is that the algorithm depends on the key, only the docking parties know, so as to protect the encrypted ciphertext from snooping, then let's break down and explain the above algorithms

The asymmetric encryption algorithm, which means that one party has the public key and the other has the private key, is used as a cipher suite when the browser and the server start out through the TLS handshake, while the rest of the HTTPS can be used with the agreed cipher suite.

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

DHE:Diffie-Hellman Ephemeral (key Exchange algorithm)

RSA: named after its inventor Rivest-Shamir-Adleman

ECDHE:Elliptic-curve Diffie-Hellman (Elliptic Curve Exchange: translated)

Symmetric algorithm, to put it bluntly, is a single key that both parties know. Compared with asymmetric encryption algorithm, it is faster to calculate, but it is not suitable as a Web certificate, because the browser and server do not know and do not trust each other, so they cannot share the key. However, after the initial handshake protocol, It is appropriate to use a symmetric encryption algorithm, 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 (password Block Link message Authentication Code)

ChaCha20: also known as Salsa20

Password strength is a security metric. How secure is 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 as digits, and the commonly used values are 128and 256. symmetric algorithms are identified by their acronyms and their key length, such as AES128 or AES256.

Having said such a lot, I seem to know several algorithm names. If we really only leave a little impression in the back of my mind without the content of this article, then we will practice our understanding with the configured cipher suite. We will explain it with the first cipher suite of the above configuration, and the rest are the same as follows.

TlsCipherSuite.TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

The above TlsCipherSuite is an enumeration. We only look at the contents of the enumeration. Remove the TLS and the rest is DHE_RSA_WITH_AES_128_GCM_SHA256.

If we combine the asymmetric and symmetric encryption algorithms described above, we will split them into DHE, RSA and AES-128-GCM.

Judging from the result of the final split, HTTPS actually uses a pair of algorithms instead of a single algorithm, one of the asymmetric encryption DHE and RSA is used for the initial TLS handshake, and the other symmetric encryption algorithm AES-128-GCM is used for encryption and decryption during data transmission! In this way, there are multiple combinations of symmetric and asymmetric encryption algorithms for HTTPS.

But simply selecting a pair of asymmetric / symmetric algorithms is not enough to fully recognize the cipher suite, so you also need to specify rules to ensure authentication and integrity. For example, through the LetsEncrypt certificate authority to issue certificates. The deeper cryptography is no longer unfolding here, and that's what I'm going to explore.

The cipher suite configured in .NET Core matches the suite supported by OpenSSL, as shown in the screenshot below:

So the question is, we configured a variety of packages above, and three supported packages were scanned through the tool scanning. when the browser and the server shook hands with TLS for the first time, which one should be chosen? So next, by visiting and checking whether the Web certificate can find any clues, we will declare in advance: the following parts are my personal conjecture, but I don't know whether it is true in theory.

By looking at the certificate push back, we use the RSA plus sha256 algorithm to create a self-signed certificate through OpenSSL, and then look at the following figure to see the final suite used

The combination of the two means that the cipher suite used corresponds to the OpenSSL configuration: ECDHE-RSA-AES128-GCM-SHA256, that is, the first of the three suites supported by the nmap tool.

ECDHE-RSA-AES128-GCM-SHA256 conclusion from the above certificate and security view, because it is sha256RSA, so the cipher suite is the last SHA256, if that is the case, can I justify myself? If we delete the SHA256 suite, does it mean that the page is not supported and the Web page cannot be accessed?

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

It seems to have nothing to do with the algorithm on the certificate, and finally came back to me through the self-create certificate command.

Openssl genrsa-out ca-key.key 3072

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 to see if GCM is supported

Openssl aes-256-gcm

In fact, OpenSSL supports GCM, but can not use the command line to operate, the specific reasons have been explained officially. After analyzing so much, it seems to be useless. At present, it is generally certain that the support of the cipher suite still requires the browser and the server to negotiate a handshake.

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

So far, we know roughly that HTTPS uses a set of algorithms, using asymmetric encryption algorithms during handshakes and symmetric encryption algorithms 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 process of handshake and data transmission is briefly described as follows:

The client sends messages to the server. I use ECDHE-RSA-AES128-GCM-SHA256 in TLS 1.2 and other suites. Can you handle it? The server replies the message to the client, which ECDHE-RSA-AES128-GCM-SHA256 can handle, and then issues the public key certificate to the client. The client replies to the server that the certificate is legal, and the client generates the key 6p7vUjFz and then encrypts it with the server's public key certificate, informing the server that the specified key is used for future data transmission, that is, the shared key.

When customizing the suites supported by the configuration, it is important to note that do not specify both TLS 1.2 and TLS1.3

This is the end of the content of "how to configure TLS Cipher in .NET Core". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.