Preface
Not long ago, I published a post about TLS protocol configuration that I have drilled through. After verification by a third-party partner, there are unsafe Suites for this TLS protocol and we need to solve them quickly, so we will start to work on this article! Third-party partners are demanding on platform security, and we have issued more than a dozen consecutive releases to deal with them. In this process, I have a better understanding of security, specifically in terms of technical solutions and cryptographic blind spots. Here's a look at two areas that may not be fully in-depth, at least that should be enough for us as developers
.NET Core Cipher Configuration
Without the rigorous requirements of the project, I would definitely not be able to do research and practice in this area. This document takes.NET 5 as an example, but for.NET Core 3 or 3.1, the results of protocol suites scanned by tools are slightly different, but do not affect our configuration of the security suite. We use OpenSSL to generate self-signed certificates. I will publish an article explaining 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 secure in combination with TLS protocol 1.0 or 1.1, so TLS protocol needs to use 1.2+. Here we use version 1.2 as above code. Next we deploy it on Linux, install nmap, and scan through the nmap tool (you can know what nmap is)
One thing to note about specifying port numbers and enumerating their support for TLS Suites through nmap scans is that we may have scanned command results from most articles without any results at all. In fact, nmap is only valid for specific port scans (e.g. 443, etc.) such as using the following commands
nmap --script ssl-enum-ciphers localhost -p 8000
For other ports, use the following commands to scan
nmap --script +ssl-enum-ciphers localhost -p 8000
Finally, we scanned the following results:
AES-CBC mode has some known security vulnerabilities in SSL or TLS, such as BEAST attack, Lucky 13 attack, etc. Although TLS1.1, TLS1.2 are not affected by BEAST attack, Lucky 13 (affecting TLS1.1/1.2) attack is also repaired in well-known cryptographic algorithm libraries such as Openssl, these vulnerabilities all expose that CBC mode is prone to introduce security vulnerabilities when implementing SSL/TLS protocol. CBC mode encryption suites are also explicitly blacklisted in HTTP/2
The above is the default behavior of.NET 5 TLS 1.2, but third-party regulations prohibit the use of AES-CBC even if the scanned package has strength A, and give its supported security suites
In the above configuration, the HTTPS overload method is enabled by reading files through paths and using passwords, as follows
public static ListenOptions UseHttps(this ListenOptions listenOptions, string fileName, string password, Action<HttpsConnectionAdapterOptions> configureOptions);
Finally, you can configure the connection with the following properties
public Action<ConnectionContext, SslServerAuthenticationOptions> OnAuthenticate { get; set; }
Inside the second class parameter, there is a configuration for the suite, as follows (I also searched for github half a day to do so)
So ultimately we configure the following security suites to support (many of them are unheard of, not to mention, 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>() { 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); }; }); }); });
Cough, so far we're happy. Is that the happy end? When you come to a new point, you must first look at the explanation. After another operation, it is not easy. It takes time and effort to do nothing. Finally, you will find the crux of the problem. This is what I have only recently experienced deeply.
From my initial understanding, it should be.NET Core 3.0+ to start supporting OpenSSL suites, and the version must be 1.1.1+, but Windows is not supported, only Linux or OSX! At the same time, the default protocol for versions below.NET Core 3.1 is 1.1 or 1.2, but the default protocol for.NET 5 changed to 1.3, and its support suite configuration is also associated with OpenSSL configuration. See the link " https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0>
When touching a point of knowledge (such as TLS) I think it's necessary to look a little bit at whether a later version will change this, assuming we don't know if the default change for.NET 5+ is 1.3. After the version upgrade, if third-party docking used TLS 1.2 before, the data docking will break down and the business will be affected. As far as I'm concerned, I can't handle ~~based on the above, if so In the Windows development environment, it is necessary to judge the operating system based on the corresponding
if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX) || RuntimeInformation.IsOSPlatform(OSPlatform.Linux)) { ...... }
Ultimately, our scan results are as follows, the AES-CBC unsafe suite has been removed to meet the security requirements completely
Foundations of Cryptography
The cipher suite uses roughly four algorithms: symmetric encryption, asymmetric key exchange, digital signature algorithm (DSA), and optional hash-based message authentication code (HMAC).
To put it plainly, cryptography suites are a set of algorithms that enable HTTPS and TLS and work together to make transmission more secure
We know that the algorithms are public, the only difference is that they depend on the key, only the docking party knows it, so as to protect the encrypted ciphertext from prying, so let's break up the above algorithms
Asymmetric Encryption Algorithms, that is, one party owns a public key and the other party owns a private key, which is negotiated as an encryption suite when browsers and servers start shaking hands via TLS, and the rest of HTTPS can be used using an agreed cipher Suite
The three main algorithms used when shaking hands through 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 algorithms, in other words, are single keys that are known to both parties. They are faster to compute than asymmetric encryption algorithms, but they are not suitable as Web certificates because browsers and servers do not know or trust each other at all and therefore cannot share keys. However, after the initial handshake protocol is in place, It is appropriate to use symmetric encryption algorithms again 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)
Cha ChaCha20: Alias Salsa20
Password strength is a measure of security. How secure is encrypted text when attacked? The strength of the algorithm is related to the length of the key, so longer keys are more powerful. Key lengths are represented as bits, and the commonly used values are 128 and 256. Symmetric algorithms are identified by their acronyms and their key lengths, such as AES128 or AES256.
With all this talk, it seems like you know a few algorithm names. If you leave this article and really leave a little impression behind you, then we will combine the configured cipher suite to make a practical understanding. We will take the first cipher suite of the above configuration to illustrate, and the rest will be the same, as follows
TlsCipherSuite.TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
The TlsCipherSuite above is an enumeration, so let's just look at the enumeration and remove TLS and DHE_RSA_WITH_AES_128_GCM_SHA256
We then combine the asymmetric and symmetric encryption algorithms described above to separate them into DHE, RSA, AES-128-GCM
As a result of the final split, HTTPS actually uses a pair of algorithms instead of a single one, one asymmetric encryption DHE and RSA for the initial TLS handshake, and the other symmetric encryption algorithm AES-128-GCM for encryption and decryption during data transmission! Using symmetric and asymmetric encryption algorithms for HTTPS can result in multiple combinations
However, simply choosing a pair of asymmetric/symmetric algorithms is not sufficient to fully recognize the cipher suite, so you also need to specify rules to ensure authentication and integrity. For example, certificates are issued through the LetsEncrypt Certificate Authority. A deeper level of cryptography is no longer expanded here, and I will explore it here
The Password Suite configured in.NET Core matches the suite supported by OpenSSL as part of the following screenshot:
So the question is, we have configured a number of Suites above. As a result, three supported suites are scanned when the tool is scanned. Which one do browsers and servers choose for the first TLS handshake? So let's go ahead and see if the Web certificate finds any clues by visiting it, and state in advance that the following is part of my personal speculation, and that in theory it's not clear if it's as I said.
By looking at the certificate backstepping, we created a self-signed certificate through OpenSSL using the RSA plus sha256 algorithm, and then looking at the following figure shows the final suite used
Combining the two indicates that the OpenSSL configuration corresponding to the cipher suite used is ECDHE-RSA-AES128-GCM-SHA256, the first of the three suites supported by the nmap tool scan
ECDHE-RSA-AES128-GCM-SHA256 concludes that for the above certificates and security checks, since it is sha256RSA, the last Password Suite is SHA256. If so, can I say for myself? If we delete the SHA256 suite, are pages not supported and Web pages inaccessible?
After these modifications and nmap scanning, the results are as follows:
It doesn't seem to have anything to do with all the algorithms on the certificate, but eventually I get back to my self-creating certificate command
openssl genrsa -out ca-key.key 3072
Can only match to RSA asymmetric encryption algorithm used, OpenSSL can specify encryption method
But when I specify aes128 or other bits, the pattern is actually CBC, not GCM
Final check to see if GCM is supported
openssl aes-256-gcm
OpenSSL actually supports GCM, but it can't use the command line to operate for specific reasons that are officially explained. After analyzing this much, it seems useless, and at present it is generally certain whether browser and server are needed to support the Password Suite for handshake negotiation
For example, you can set whether TLS 1.3 is enabled in Google Browser
So far, we have generally known that HTTPS uses a set of algorithms, asymmetric encryption during handshake and symmetric encryption during data transmission. Throughout the period, guess is to combine the generated certificates, then traverse the configuration suite to shake hands, and then transfer data after a successful shake
Roughly describe the handshake and data transfer process as follows:
Clients send messages to servers. I use ECDHE-RSA-AES128-GCM-SHA256 in TLS 1.2 and other suites. Can you handle them? The server replies to the client with the message that ECDHE-RSA-AES128-GCM-SHA256 can process and issue the public key certificate to the client. The client replies to the server that the certificate is legal. The client generates the key 6p7vUjFz, which is then encrypted using the server's public key certificate, notifying the server that the specified key is the shared key for later data transmission.
When customizing the suites supported by the configuration, it is important to note that TLS 1.2 and TLS should not be specified together 1.3
summary
Ah, I have reached the summary again. It seems that there is nothing to sum up. The specific related knowledge or experience has been explained in this article. We will see you again in the next section.