TLS 1.3 support #1005
Comments
|
TLS 1.3 isn’t trivial for a lot of reasons. For a variety of other reasons I have stayed clear of OpenSSL. When I looked at WolfSSL last time there were licensing constraints which led me away from TLS 1.3. It seems strange to me that there would already be environments that require TLS 1.3 as it only recently got standardized. I’m not opposed to someone putting together a PR to enable another TLS implementation but it’s unlikely I will be racing to do so myself in the immediate future. I have been looking at BearSSL but it also lacks TLS 1.3. |
|
We've had attacks on the TLS 1.2 handshake in the past, and had to migrate to TLS 1.3. Yes, GPL licensing is the reason I'd rather avoid WolfSSL and matrixssl, but since it's for internal use only, I guess it won't matter that much. Besides OpenSSL, there's another Apache 2.0 TLS 1.3 implementation called miTLS, which is part of Project Everest. Basically, they formally specify TLS 1.3 in a language called F*, verify it with formal methods and tools, and then convert this in stages into Low* and then C with yet another tool, where it can be used like any other TLS library. Some of their crypto primitives are also formally verified this way (HACL*). This is an interesting project, but I don't know how hard it will be to use. Never tried it before. |
|
The biggest problem is not so much licensing (Hint: WolfSSL and MatrixSSL IS commercially licenseable...saying GPLed is not understanding things as well as you SHOULD...to be honest with you.) it's that you need TLS 1.3 support AND something like FIPS-140-2 support. You don't get this with mbedTLS or Project Everest's stuff. PERIOD. You get this with OpenSSL, WolfSSL, and MatrixSSL. We need at least ONE good TLS that can be put into a FIPS mode. |
|
I do understand that those other SSL options have commercial licensing options. However, as a free software project, I wouldn't like to prioritize supporting those options over other liberally licensed ones. Often such options are rather toxic, and forcing consumers to pay $$ to a third party to avoid the GPL runs counter to my thinking. Having said all that, OpenSSL is liberally licensed enough, but the code is just poor. That's the only reason I've avoided it. If you need FIPS support, then I presume you're looking for a commercial solution. In that case, what I'd suggest is that you reach out to me out of band -- it probably would not be too much effort to come to a solution here if you are willing to sponsor the effort. Alternatively, we (mostly I mean me) could come up with the code ourselves. If I did that, I'd probably have that module set up with licensing terms similar to WolfSSL, whereby you'd either have to accept a GPL-ized version of the code, or pay me for a commercial license. (You'd still have to pay the WolfSSL people for their license.) What I'm particularly not interested in doing is creating a version of the code that exclusively enriches a 3rd party vendor while both reducing freedoms for other folks and providing nothing back to me for my effort. If either of these sound interesting to you then please drop me a line. (Oh, you're also welcome to develop the module yourself -- the TLS interfaces in the code are intended to support easily swapping out the TLS implementation -- you just have to write the adapting glue code to do so.) |
|
Don't sell my helping out short. It all depends on my bandwidth on things
runit and OE in general and whether or not Motorola Solutions lets me do it
as a function of my day job. X-D
As for your take on the not enriching someone- we're *very* much on the
same page there. 35+ years of which most of it has been involved with
using/providing FOSS software myself...yeah, I don't want that either.
I'll drop you a line shortly
…On Sun, Nov 10, 2019 at 7:19 AM gdamore ***@***.***> wrote:
I do understand that those other SSL options have commercial licensing
options. However, as a free software project, I wouldn't like to prioritize
supporting those options over other liberally licensed ones. Often such
options are rather toxic, and forcing consumers to pay $$ to a third party
to avoid the GPL runs counter to my thinking.
Having said all that, OpenSSL is liberally licensed enough, but the code
is just poor. That's the only reason I've avoided it.
If you *need* FIPS support, then I presume you're looking for a
commercial solution. In that case, what I'd suggest is that you reach out
to me out of band -- it probably would not be too much effort to come to a
solution here if you are willing to sponsor the effort.
Alternatively, we (mostly I mean me) could come up with the code
ourselves. If I did that, I'd probably have that module set up with
licensing terms similar to WolfSSL, whereby you'd either have to accept a
GPL-ized version of the code, or pay me for a commercial license. (You'd
still have to pay the WolfSSL people for their license.) What I'm
particularly *not* interested in doing is creating a version of the code
that exclusively enriches a 3rd party vendor while both reducing freedoms
for other folks and providing nothing back to me for my effort.
If either of these sound interesting to you then please drop me a line.
(Oh, you're also welcome to develop the module yourself -- the TLS
interfaces in the code are intended to support easily swapping out the TLS
implementation -- you just have to write the adapting glue code to do so.)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1005?email_source=notifications&email_token=ABKF6CMQGB4U6Z5VESSWLKDQTAC7DA5CNFSM4JFLFV62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDU5AXA#issuecomment-552194140>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKF6COQMXKJCRYSASUU6DTQTAC7DANCNFSM4JFLFV6Q>
.
|
|
And, yes...we kind of need FIPS support if it leaves the device. It
becomes much of a bigger seller if it works for more than just IPC type
things- and FIPS is a hard requirement here for the customer bases.
…On Mon, Nov 11, 2019 at 11:29 AM Frank Earl ***@***.***> wrote:
Don't sell my helping out short. It all depends on my bandwidth on things
runit and OE in general and whether or not Motorola Solutions lets me do it
as a function of my day job. X-D
As for your take on the not enriching someone- we're *very* much on the
same page there. 35+ years of which most of it has been involved with
using/providing FOSS software myself...yeah, I don't want that either.
I'll drop you a line shortly
On Sun, Nov 10, 2019 at 7:19 AM gdamore ***@***.***> wrote:
> I do understand that those other SSL options have commercial licensing
> options. However, as a free software project, I wouldn't like to prioritize
> supporting those options over other liberally licensed ones. Often such
> options are rather toxic, and forcing consumers to pay $$ to a third party
> to avoid the GPL runs counter to my thinking.
>
> Having said all that, OpenSSL is liberally licensed enough, but the code
> is just poor. That's the only reason I've avoided it.
>
> If you *need* FIPS support, then I presume you're looking for a
> commercial solution. In that case, what I'd suggest is that you reach out
> to me out of band -- it probably would not be too much effort to come to a
> solution here if you are willing to sponsor the effort.
>
> Alternatively, we (mostly I mean me) could come up with the code
> ourselves. If I did that, I'd probably have that module set up with
> licensing terms similar to WolfSSL, whereby you'd either have to accept a
> GPL-ized version of the code, or pay me for a commercial license. (You'd
> still have to pay the WolfSSL people for their license.) What I'm
> particularly *not* interested in doing is creating a version of the code
> that exclusively enriches a 3rd party vendor while both reducing freedoms
> for other folks and providing nothing back to me for my effort.
>
> If either of these sound interesting to you then please drop me a line.
> (Oh, you're also welcome to develop the module yourself -- the TLS
> interfaces in the code are intended to support easily swapping out the TLS
> implementation -- you just have to write the adapting glue code to do so.)
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#1005?email_source=notifications&email_token=ABKF6CMQGB4U6Z5VESSWLKDQTAC7DA5CNFSM4JFLFV62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDU5AXA#issuecomment-552194140>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABKF6COQMXKJCRYSASUU6DTQTAC7DANCNFSM4JFLFV6Q>
> .
>
|
|
Well, maybe @ejohnstown or @dgarske have time for a little side project :) |
|
0-RTT is only really a big deal if you're using short-lived connections. If you're using short-lived connections, then probably NNG and nanomsg isn't ideal for you. The design goals for NNG are centered around the Scalability Protocols and longer lived connections. (In particular, connection establishment is expensive, which is not ideal if you're looking at low-latency networking.) |
|
@wamserma Thanks for the heads up. I'll add this to the community project to-do list. One of us will take a look when we get some free time between paid projects. |
My thought was more about a quick reconnect after an endpoint comes up from suspend. |
|
A wolfSSL engine for TLS with 1.3 is in the works (stay tuned). I'm also planning to build a matrixSSL one. This will be GPL v3.0 with a commercial license available as well. |
This introduces support for an external wolfSSL plugin. This is the start of a pluggable layer for TLS and SSL, that will permit alternate TLS implementations. The wolfSSL engine is provided via an external module, available either under a GPLv3 license or a commercial license.
This introduces support for an external wolfSSL plugin, and generally creates the framework for pluggable TLS implementations. The wolfSSL engine is provided via an external module (git submodule), available either under a GPLv3 license or a commercial license.
Hello,
since mbedTLS support for TLS 1.3 is still missing, due to extensive code refactoring, nng can't currently be deployed in TLS 1.3-only environments... except via custom tunnels, which is suboptimal, to say the least. Of course, we could simply wait for the mbedTLS team to finish their work, but what can be done in the mean time?
TLS 1.3 is supported by WolfSSL and OpenSSL.
So I'm wondering how hard it would be to hook one or both of those libraries into nng. Anyone already working on this? Any hope to see multi TLS library support in nng before the next release?
Thanks.
Edit: Or course, wolfSSL has the drawback of being GPLed, but if we go this route, we may as well also add support for matrixssl.
Edit 2: starting at nng/src/supplemental/tls, and adding the additional TLS libs there, using none/tls.c and mbedtls/tls.c as a template seems to be the first step. Are there any other places in the tree to consider?
The text was updated successfully, but these errors were encountered: