I was confused about what kind of QUIC API this blog post is about until I got near the end. This is an API between a TLS implementation and a QUIC implementation. At the moment curl supports multiple OpenSSL forks as TLS backends for ngtcp2 QUIC, but OpenSSL itself only provided a monolithic QUIC+TLS stack.
Why would OpenSSL implement QUIC? It’s a TLS implementation, which is at heart just a stream plugin; it shouldn’t be involved in the underlying data stream. Is this just feature creep?
It was one of the worst OpenSSL decisions I’ve seen. OpenSSL was (is?) in the business of providing security and cryptography services. Now they want to be in the business of networking protocols and, perhaps one day, HTTP.
I suspect that if they keep going along this path, one day OpenSSL will ship its own TCP/IP stack as well, perhaps as a replacement for lwIP.
I was confused about what kind of QUIC API this blog post is about until I got near the end. This is an API between a TLS implementation and a QUIC implementation. At the moment curl supports multiple OpenSSL forks as TLS backends for ngtcp2 QUIC, but OpenSSL itself only provided a monolithic QUIC+TLS stack.
Why would OpenSSL implement QUIC? It’s a TLS implementation, which is at heart just a stream plugin; it shouldn’t be involved in the underlying data stream. Is this just feature creep?
It was one of the worst OpenSSL decisions I’ve seen. OpenSSL was (is?) in the business of providing security and cryptography services. Now they want to be in the business of networking protocols and, perhaps one day, HTTP. I suspect that if they keep going along this path, one day OpenSSL will ship its own TCP/IP stack as well, perhaps as a replacement for lwIP.