In-depth HTTP/3 (2) | Not-so-boring SSL

Text｜Zeng Ke (flower name: Yi Si)

Senior Engineer of Ant Group\
Responsible for the construction of the access layer of Ant Group The main direction is the design and optimization of high-performance security network protocols

This article is 10924 words, read 20 minutes

PART. 1 Introduction

From the previous article "In-depth HTTP/3 (1) | Looking at the evolution of the protocol from the establishment and closure of QUIC links" , we learned from the brief introduction to QUIC that the optimization of QUIC is largely an optimization based on the TLS process , which also shows the importance of TLS to QUIC, so today we will talk about QUIC-TLS. In order to express as little ambiguity as possible, we first standardize the meaning of each term in the article.

Since the two terms SSL and TLS have been mentioned in this article, we might as well briefly review the development history of security protocols, which can not only help us clarify the relationship between the two terms, but also help us to understand the evolution of this technology. There is a brief concept.

The SSL (Secure Sockets Layer) protocol itself is a set of protocols designed by Netscape in 1994 to ensure the security of data transmission on the Internet. This protocol was widely used on major browsers at that time, but the security of the first few versions of the SSL protocol was very worrying. The initial changes were very frequent. From 1994 to 1995, three major versions were iterated continuously, while Now everyone is most familiar with SSLv3.0. Unfortunately, SSLv3.0 has not escaped the doom of change. Due to the iteration of hardware computing power, a large number of encryption algorithms widely used in SSLv3.0 are no longer safe, and the protocol interaction process is also insecure. In 1999, the IETF formally participated in the design and development of security protocols, and launched the first version of the TLS (Transport Layer Security) protocol, TLS1. .1, and released TLS1.2 again in 2008. Both versions are aimed at improving the security of some details in the handshake interaction process. In fact, the handshake process has not changed much.

Until 2013, when Google launched gquic, it also launched its designed secure interaction process quic-crypto. quic-crypto was a major innovation in the interaction process and became the predecessor of TLS1.3. TLS1.3 should be called TLS2.0 in a sense, because its innovation is very strong, of course, this also leads to a very long standardization process. The standardization of TLS1.3 has lasted for 4 years, and it was not until 2018. Formally become an RFC. TLS 1.3 itself has also become the basis of IETF-QUIC's secure interaction technology, so this timeline is also mixed with the design process of QUIC-TLS. Let's briefly explain:

Figure 1. A brief history of TLS development

Of course, the evolution of DTLS and other related security technologies is also integrated in this timeline. Due to space limitations, it is not listed here for the time being. Having said so much nonsense, let's now formally standardize our nouns:

[SSL, TLS] : In this article, they all refer to secure transmission protocols, and subsequent articles will only use TLS as a synonym for related technologies

[QUIC-crypto] : The handshake process used in Google quic, which is not specifically analyzed in this article

[QUIC-TLS] : This article refers to the secure interaction process used by IETF-QUIC, that is, the standardized process in RFC9001, which is also the focus of this detailed description

[PTO] : The full name is Probe Timeout, which is defined in RFC9002, and is left for the next article to analyze it in detail. In this article, it is understood as the time set by a communication end for the timeout retransmission of the message.

[DTLS] : The full name is Datagram Transport Layer Security, that is, the message-oriented TLS protocol. Due to space limitations, this article does not analyze it in detail, and there are many designs similar to QUIC-TLS in DTLS. Interested Students can refer to RFC9147

"make infrastructure boring" is Google's slogan, and BoringSSL, an open source product, is their action in the field of secure communication. Since the title of the article is called "SSL that is not so Boring", in addition to rubbing against the famous BoringSSL and OpenSSL In addition to the popularity of the SSL open source project, I also want to create a little suspense for the article: Boring often means that the related technologies are simple and easy to use to the point of outrageous, and what problems did QUIC encounter to make the relatively mature TLS protocol use it? No more Boring?

This article will also focus on this topic in the future, and take a look at the interesting points in the design of QUIC-TLS .

PART. 2 A brief look at TLS

In line with the idea of from the shallower to the deeper, before we start to introduce QUIC-TLS, let's analyze TLS first, which is also very helpful for our understanding of QUIC-TLS later.

The TLS protocol solves several philosophical questions to some extent:

Who are you? How do you prove that you are you?

Of course, the answers to these questions are not enough to guarantee overall security...

1. We also need a technology to ensure that the middleman cannot obtain our data , which is the "symmetric encryption technology" that we are relatively familiar with, such as AES, SM4 and other encryption technologies;

2. In order that encrypted data can also prove the identity of the communication end , we introduced the "AEAD encryption is the authentication mode" ;

3. In order to negotiate this symmetric encryption key , TLS introduces "asymmetric key exchange technology" , typically such as ECDHE, RSA and other key exchange algorithms;

4. In order to unify identity management and effectively carry identities , TLS introduces "digital certificate technology" , including the entire pki public key system and the X509 digital certificate standard;

5. In order to keep the data from being tampered with , TLS introduces "digital signature technology" , typically such as ECDSA, RSA and other signature algorithms;

6. For the independence of encryption keys at each stage and the simplicity of the signature process , TLS introduces the "Hash algorithm" , typically such as the SHA series of algorithms.

The various mechanisms mentioned above are abstracted into two-part protocols in the entire TLS protocol:

The first layer is the Handshake protocol , which is responsible for the interaction and identity authentication of the core key; the second layer is the Record protocol , which is responsible for data security, integrity and credible proof of the data after the handshake is completed, and the Handshake protocol is located on top of the Record protocol. This also forms such a protocol stack.

Figure 2. Simplified TLS protocol stack

In short, the data in the Handshake process also relies on the Record layer for data encryption, and the key encrypted by the Record layer is obtained by interaction with the Handshake layer. This seems to be a logical deadlock, but it is actually accomplished through a layer-by-layer progressive state machine. Aside from the cumbersome TLS state machine itself, this process can basically be described by the following diagram:

Figure 3. TLS key status update flowchart

As for the data transmitted in plaintext in the initial stage of TLS, it does not violate this process. We can understand it as a key with an empty value corresponding to the initial stage of TLS. From the above figure, we can also see that the implementation of the two-phase switching corresponding to the dotted line must have a strict sequence. If the order is out of order, one end cannot complete the parsing of the data, so the TLS protocol is very dependent on the underlying transmission. protocol to ensure the orderly arrival of data, and this is one of the biggest reasons why the design of TLS is different from DTLS and QUIC-TLS. With this part of the knowledge reserve, let's look at the TLS handshake (taking the 0-RTT interaction scenario of TLS1.3 as an example) , it will be much clearer:

Figure 4. TLS handshake flowchart

It can be seen that the switching of the encryption state corresponding to the plaintext "()", "{}", "[]" is basically the same as the process of the above figure, and typical marking data such as EndOfEarlyData is used to notify The key state of the peer is switched, and this understanding is very useful for us to understand the design of QUIC-TLS later.

At the end of this chapter, we give a brief summary of TLS:

Figure 5. TLS summary

In terms of usage, TLS provides a layer of security abstraction, allowing the application layer to directly read and write through a simple SSL_read/SSL_write (take OpenSSL/BoringSSL as an example) read and write interface, so that it can directly use the ability of secure communication, and completely No need to pay attention to the details of the TLS handshake, state transitions.

From this point of view, using TLS is enough for Boring, and in terms of security requirements, QUIC-TLS and TLS are the same, and there should be no big difference, so what makes QUIC-TLS so complicated?

PART. 3 In-depth QUIC-TLS differences

In our last article, we have analyzed QUIC connection establishment. In order to ensure the efficiency of QUIC connection establishment, QUIC combines orderliness and security. And we know that TLS itself is a protocol designed based on TCP, and there is a strict layering between the two, and the TCP protocol ensures that all data are successfully transmitted and transmitted to the opposite side in an orderly manner, so TLS does not need to consider loss. Packing and out-of-order problems. QUIC-TLS needs to consider the two together. Looking back at the previous article, we know that QUIC introduced the pkt number and the offset mechanism of each frame in order to start the orderly transmission of the first packet without negotiation, and the two Each flag starts from 0, and then TLS is used to ensure its security. Careful readers may have discovered the circular dependency of the logic.

Figure 6. Protocol dependencies for TLS

In order to break this endless loop, QUIC-TLS must split the interaction at the security level into finer-grained splits to achieve both safe and reliable transmission. Therefore, in RFC9001, we can see that the QUIC protocol stack seems to be It looks like this:

Figure 6. QUIC-TLS protocol stack

This diagram is somewhat similar to the previous TLS protocol stack, but not so similar. We already know that the layer-by-layer effect of the protocol stack is that the packets generated by the upper-layer protocol will be stuffed into the next-layer protocol in the form of payload. The QUIC Packet Protection protocol is used as a protocol to protect data security, so its responsibilities are related to TLS. Record is similar, and the QUIC Transport protocol (guaranteeing reliable and orderly transmission of QUIC) is similar to TCP. It can be seen that the lower part of the QUIC protocol stack is completely opposite to the TLS+TCP protocol stack, which means The design of QUIC-TLS at the bottom must be different from the design of TLS. Let's disassemble it in depth.

1. Packet-based encryption strategy

We already know that the function of the Record layer relies on the symmetric encryption algorithm to ensure security, and uses the AEAD encryption mode to ensure the credibility of the data. Take a typical example algorithm AES-128-GCM as an example, AES-128 means symmetric encryption The algorithm is AES-128, GCM and its corresponding AEAD algorithm, AES-128-GCM encryption has four inputs:

(1) Plaintext to be encrypted; \
(2) Encrypted key key; \
(3) Encrypted random number Nonce; \
(4) Certified Associated Data.

The decryption is basically the same, just replace the plaintext with the encrypted ciphertext. For the value of Nonce, in TLS, since it does not need to consider the orderly transmission of data, Nonce is implemented by the client and server maintaining a technical device for each Record message, that is, Nonce starts from 0, and each time a pair is received. The Record message of the end is incremented by 1.

For QUIC-TLS, the secure transmission of data through encryption algorithms cannot escape this set of mechanisms. However, for QUIC-TLS, since security and order have been integrated, every time we receive a message, we need to decrypt it first to know whether the message is out of order, so we can't maintain the counter to achieve self-service. How to add this function of Nonce?

We happen to see that there is a monotonically self-increasing value such as packet number (note that the function of packet number is not intended to be a Nonce, and its specific function will be left to the packet loss detection part of QUIC for further analysis) , which is very suitable as a Nonce. But the packet number itself needs to be encrypted, how to deal with this? The solution is not complicated, that is, the packet number is encrypted using a weaker encryption mode, that is, the simplest ECB mode. Taking AES-128-ECB as an example, this mode only requires two inputs for encryption/decryption:

(1) plaintext to be encrypted/ciphertext to be decrypted; (2) encrypted key.

Looking back at the previous diagram about the state transition of TLS, as long as we can continuously update the key according to this state transition, we can follow the following process to unlock the pkt number, and further decrypt it to obtain the handshake/application layer. information. (Note that steps 3 and 4 are not necessarily in strict order, because QUIC's packet loss detection depends not only on the pkt number, but also on some special control frames. For this part, we will leave it to QUIC later. Share it in related articles on packet loss detection.)

Figure 7. Packet processing for QUIC-TLS

Knowing this step, we also understand why QUIC chooses to use QUIC packet as the basic unit at the security level. Of course, there are multiple states during a QUIC-TLS handshake process, that is, there are multiple keys with different encryptions. In order to make the interaction process of QUIC clearer, QUIC also defines 6 different types of Packets, which are used to correspond to 6 types. State, that is, 6 encrypted keys.

Figure 8. Packet encryption levels for QUIC-TLS

The Initial part corresponds to the part of the plaintext transmission in the TLS process. Although this part of the data is encrypted in name, the encrypted key is a value written in the RFC and known to everyone. It is equivalent to clear text transmission. This approach cannot be said to be superfluous, because it does increase the attacker's attack cost to some extent, but it does not guarantee the security of the ClientHello data. To this end, QUIC-V2 is also preparing to introduce security technologies such as Encrypted-ClientHello to protect this part of the data, which we will share later.

This packet encryption mode, which distinguishes the pkt type, allows the data to have a clearer state transition identification. Let's look back at the state transition diagram of TLS, and we can find that every time the notification peer switches from key1 to key2, it must first send a notification message encrypted with key1 (ie, ChangeCipherSpec in TLS) , and then go to Send key2 encrypted data, so as to theoretically ensure that the peer can successfully process the notification message and complete the key state change. In QUIC-TLS, the pkt type of the package becomes such an explicit indicator to notify the state transfer. For example, if the peer starts to respond to the Handshake package, it means that the state is to be transferred to the Handshake state, which also makes QUIC-TLS no longer requires explicit notification mechanisms such as ChangeCipherSpec and EndofEarlyData, and this is very helpful for out-of-order processing of the handshake process. With this reserve knowledge, let's take a closer look at the details of the QUIC-TLS handshake, and it will be easier to grasp its essence.

2. Lack of strict layering, resulting in stricter 0-RTT usage restrictions

The prototype of the 0-RTT function came from QUIC-crypto and was formally standardized in TLS1.3. It has also become a very attractive point for TLS1.3 users, but the use conditions of this function are very strict.

First of all, 0-RTT relies on the success of TLS session multiplexing, which means that there must be an interactive confirmation mechanism for its use process, otherwise the client will send 0-RTT data in the initial stage, but it cannot be confirmed by the server. , then this is a waste of resources;

Secondly, the 0-RTT data itself involves the conversion of the key state, so it is necessary to design a corresponding state conversion mechanism (and the aforementioned EndOfEarlyData) ;

Finally, 0-RTT data itself is insecure, because it cannot avoid replay attacks at all, and can only rely on the application layer protocol to ensure idempotency.

For the first question, there is not much difference between QUIC-TLS and TLS1.3. Both of them indicate whether 0-RTT data is received through the extension in the server's response. We have also analyzed the second question before. QUIC-TLS relies on the explicit encryption level of the packet, and does not require the mechanism of EndOfEarlyData to notify the key state that a transition is required. But when it comes to question 3, the situation to be considered will be much more complicated. Let’s start from the QUIC level. We know that QUIC carries application layer data through STREAM type frames, but in addition to carrying data, QUIC also provides such as RESET_STREAM , STOP_SENDING This type of control frame is used to control the transmission of application layer data, and these are not safe for playback.

So from the perspective of QUIC , unless you know how your application layer protocol operates QUIC's stream, and have a clear ability to ensure the replay safety of these behaviors, you can use this ability, otherwise simply put it on the shelf, This is also clearly suggested in RFC9001.

And let's look at it from the perspective of HTTP/3 . As we mentioned in the previous article, HTTP/3 is not QUIC+HTTP/2, but the abstraction of the HTTP/2 middle stream is handed over to QUIC , and then control these streams in HTTP/3. From this point of view, HTTP/3 natively meets the requirements for the use of 0-RTT capabilities in QUIC-TLS, but we still have many issues to consider, because QUIC itself is a link and the stream on the link has many possibilities Protocol for configuration parameters. When the client starts to transmit application layer data, it often means that the underlying transmission conditions have been negotiated (and due to the binding relationship between HTTP/3 and QUIC, these transmission parameters also contain some semantics of HTTP/3) , When the client transmits 0-RTT data, we cannot obtain these parameters through negotiation, but can only continue to transmit through the previous link parameters, so for the clustered QUIC scenario, ensure the consistency of the machine configuration in the cluster and the compatibility of changes Sexuality is also a major issue that QUIC users need to pay attention to.

3. QUIC-TLS handshake, increased complexity brought by out-of-order

Let's first look at the interaction diagram for QUIC-TLS in RFC9001:

Figure 9. QUIC-TLS handshake interaction

Just from this handshake protocol diagram, if we first simply:

(1) Treat the Init message as ClientHello/ServerHello;

(2) The 0-RTT message corresponds to the 0-RTT data of TLS;

(3) HandShake data corresponds to ServerFinish/ClientFinish.

Then this handshake process does not seem to be any different from TLS. In fact, it is true only from the perspective of the handshake principle. However, when we introduce out-of-order considerations, the complexity of the problem will be much higher. As we have analyzed earlier, TLS is a layer that relies on the orderly transmission of TCP to ensure the state (or the current encryption and decryption keys) . The layers are progressive, and because the data is strictly ordered, TLS only needs to maintain the current key. When it comes to QUIC-TLS, the problem is no longer so simple. We can divide it into two typical cases to discuss:

1. The next stage of the package arrives ahead of schedule

Although this problem has commonalities in the QUIC-TLS handshake process, it should be viewed in stages. Each stage also has its own problem characteristics. At present, there are several possibilities to trigger this problem:

• The client's 0-RTT message arrives earlier than the Init message
• Server's Handshake message arrives earlier than Init message
• Server's 1-RTT message arrives earlier than Server's Handshake message
• The client's 1-RTT message The client's Handshake message arrives

For the first case, the solution is actually very simple, because ClientHello itself is not very big, and we will only send 1 0-RTT message in the first packet (because we don’t know whether the server will receive 0-RTT message or not , so try it first) , we can solve the problem of out-of-order at the root by aggregating QUIC packets in a UDP packet and sending (this is allowed and recommended by the standard) .

However, the follow-up problem is more complicated. In case 2, since the certificate of the server may be relatively large, the Handshake package of the server will also be large, and the Init of the aggregation server alone cannot meet the requirements. Just imagine, if the client chooses the all-cache strategy for the out-of-order situation, the attacker in the middle can directly consume the client's cache by continuously sending HandShake packets.

And the ingeniousness of QUIC is also here. The coupling of the protocol layer can make other layers of security mechanisms also available at the current level. Remember the prevention of amplification attacks mentioned in the previous article? Before the client handshake is completed, the server is not allowed to send more than 3 times of data until it receives a response from the client. The client can use this as a sign to deal with this scenario. Of course, at the implementation level, most implementers will still choose to directly discard such out-of-order packets, because maintaining such a cache queue is itself a complicated matter. In this regard, the RFC also has corresponding suggestions. The server implements a limited number of retransmissions of the data during the handshake process before the end of the PTO to speed up the completion of the handshake.

Cases 3 and 4 In principle, the problems faced by case 2 do not seem to be very different, but the details involved still require case by case discussion:

First of all, in real application scenarios, situation 3 often does not exist, and why it does not exist depends on the problem of situation 4. Only from the TLS interaction diagram, the client's 1-RTT data arrives earlier than the client Handshake message, and the server actually has a 1-RTT key at this time, which can complete the decryption of the data.

But consider these two cases:

(1) In the scenario of two-way authentication , the client Handshake carries the client's identity data. The server should not respond to the data of the user layer before the authentication is completed, and it should not send 1-RTT before the handshake is completed. The data;

(2) In the 0-RTT scenario , first of all, we know that the response corresponding to the 0-RTT data is carried by the 1-RTT message, but the 0-RTT data itself can only rely on the idempotence of the application layer due to security issues to achieve protection against replay attacks. Before the handshake is unsuccessful, the server cannot confirm whether all 0-RTT data has been received, and the application layer cannot confirm whether the data is a replay attack without the full amount of data, so the server cannot directly respond before the handshake is completed. 0-RTT message.

In general, for the consideration of the application level, Case 4 has more explicit restrictions. RFC9001 directly stipulates that the server should not process 1-RTT packets before the handshake is completed, but how to realize the cache at the UDP level itself , it is left to the implementer to consider according to their own network conditions.

2. Receive the packet from the previous encryption stage

Just now we discussed how to deal with the new state data, so now let's look at how to maintain the old state. From the experience of TLS, it seems intuitively that we do not need to maintain the previously encrypted state data, and QUIC-TLS and TLS are similar, if one end of the communication successfully enters the next handshake phase, it also means that it has All the necessary handshake messages are received, so if it retransmits the data from the previous stage, the data is either a retransmission or an attack, and it seems that there is no need to deal with it?

It's true that maintaining keys from the previous stage is wasteful if you only look at the handshake, but not necessarily when you take the 0-RTT feature into account. For the client, under normal circumstances, the 0-RTT data should be sent earlier than the client's Handshake message, but due to the uncontrollability of the intermediate network equipment, the 0-RTT data may arrive later than the 1-RTT data. If The server can maintain the encryption state of 0-RTT, so the retransmission of these out-of-order packets can be avoided. As we have discussed before, 0-RTT itself is not a very secure mechanism. In QUIC-TLS, the client should abolish the 1-RTT key immediately after it is generated, so there is no need for the server to maintain 0-RTT for a long time. The corresponding encryption state, and for the selection of specific maintenance time, RFC9001 proposes a scheme similar to TCP Time_wait, that is, the server only needs to maintain the 0-RTT key as 3 PTOs to ensure that the out-of-order data will naturally die in the network.

In addition to the 0-RTT Key processing, there is also a Key Update mechanism in QUIC-TLS, which is used to update the current state key after the handshake is completed. This mechanism also faces out-of-order and new and old state keys. However, its principle is the same as that of 0-RTT, so it will not be repeated here.

PART. 4 Look at the QUIC-TLS protocol stack again

So far, we have understood how QUIC-TLS uses various detailed mechanisms to ensure that its state can be successfully evolved layer by layer. Let's look back at the QUIC-TLS protocol stack in Figure 6 below. You can see that QUIC Packet The Protection part can clearly obtain plaintext data by maintaining the key of the current stage and the QUIC message mechanism of the explicit encryption level, while the QUIC Transport layer provides a relatively independent and reliable transmission mechanism.

From this point of view, the upper-layer TLS Handshake part can be dismantled very finely and functionally independent. Due to the lazy thinking in engineering and the consideration of security and stability, the various capabilities of the existing TLS precipitation can be Of course, reuse should be done as much as possible. So we can see that QUIC-TLS defines how to design the TLS API so that it can just interact with the underlying QUIC.

Figure 10. Interaction flow between QUIC-TLS and existing TLS

At this point, this article has almost completed all the analysis of the QUIC-TLS handshake phase. It can be seen that the design of QUIC-TLS is filled with a large number of inter-layer coupling considerations. Any function point is not simply to meet the demands. It is necessary to consider both the upper application protocol and the protocol stack. adaptation. And such a design is full of various points of the QUIC protocol stack. I think this is one of the reasons why QUIC has become a standard after so many years.

The article is indeed a bit long to write here, thank you readers for being able to see it here. This article does not mention many detailed processes involved in QUIC-TLS, such as the algorithm of Head protection and the encryption of Retry token.

From my personal point of view, these are relatively independent and easy-to-understand functions. Readers should be able to understand RFC9001 by themselves, and no special analysis is required.

Of course, if readers expect to have a summary of this type of technology, they can leave a message at the end of the article , and a summary article on these technologies will be published later.

PART. 5 Outlook for QUIC-TLS

The previous article talked about the difference between QUIC-TLS and TLS. Instead, looking forward, QUIC-TLS is surprisingly consistent with the evolution of TLS. Of course, this is also a logical conclusion. Because whether it is QUIC-TLS or TLS, after all, it is to provide security for users, and the next generation of security technologies are often focused on technical details such as encryption and decryption. In the future that we can see with the naked eye, we may be able to See the implementation of these technologies in QUIC-V2:

- Encrypted ClientHello : This part has been discussed above. In order to make QUIC's Init message more secure, we can encrypt the first packet through public key encryption technology and out-of-band public key synchronization. Interested readers can see related drafts.

- Certificate Compression : The long and consistent certificate chain is one of the important reasons for the low success rate of handshake in weak network environment. Effective compression of the certificate will greatly reduce the interactive data and improve the success rate of handshake. Interested readers can see the relevant standards .

- Delegated Credential : The security of public cloud and hybrid cloud environments has always been challenged by various challenges, and private keys, as such important data, are also at great risk when deployed on public clouds. By issuing short-term delegation credentials for leaf certificates, you can Effectively reduce the attack window, and interested readers can see relevant standards.

- State secret interaction : Under the current situation, cryptographic security has risen to a very high level, and we are also trying to standardize the state secret algorithm into the QUIC-TLS process to meet compliance and security demands.

Of course, various emerging technologies are emerging one after another, and we will continue to follow up to ensure that users of Ant-related products can also get the ultimate security guarantee while enjoying a good network experience.

PART. 6 The last item to bring

Finally, after reading the technology sharing, it is better to have some product sharing and gossip moments. OpenSSL is indeed a rare open source product of conscience, but it is indeed a bit confusing in the matter of QUIC-TLS.

A long time ago, Akamai's contributors made a PR submission for the function of QUIC-TLS, but OpenSSL has always used QUIC as the reason why it has not been standardized, and did not give consideration to the merger. After QUIC was standardized, the OpenSSL official community said that it was not satisfied. Since there is only QUIC-TLS library support, it is necessary to build a complete implementation of QUIC ( including s_client, s_server and other test clients/servers for QUIC support), although the community is full of a lot of doubts, but in the end still failed Shaking their determination, of course, this does not mean that OpenSSL's choice is wrong, because from the perspective of the OpenSSL organization, OpenSSL is not satisfied with the current role of simply providing TLS library capabilities for QUIC, and they want to go further Transitioning into a role of providing a QUIC library to the product, and the current choice is their go-to.

Of course, their ideals are lofty, and the hard part is that I am a heavy OpenSSL user. In fact, there are still many small problems in the use of the open source PR in the early stage of OpenSSL. The lack of support from the community will make a large number of users wait and see about this part of the function. Attitude, then these details will be more difficult to expose, and the motivation of users to submit PR will be much weaker. And because of OpenSSL's official unsupported attitude, most open source QUIC libraries also choose BoringSSL, which is a disaster for some existing products that have been implemented based on OpenSSL, and these products want to switch to BoringSSL It is by no means easy to integrate the corresponding QUIC library.

Fortunately, there is always a solution to any problem. We have fully implemented QUIC-TLS in our open source BabaSSL library. In addition to helping the original PR of the community to improve its corresponding functions, it is also compatible with some BoringSSL APIs. , this part has also passed the production test of ant. Readers are welcome to experience it. Of course, not only that, we are also implementing or have completed the implementation of the technologies mentioned in the QUIC-TLS outlook above. Readers are welcome to come and try it.

learn more...

BabaSSL Star ✨:
https://github.com/BabaSSL/BabaSSL

【Reference link】

[1] https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14

[2] https://datatracker.ietf.org/doc/html/rfc8879

[3] https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-12