Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WolfSSL sucks too, so now what?

blog.feld.me

Post reply on HN
Print view View original

121–130 of 136 posts

Re: WolfSSL sucks too, so now what?

#121

Post by otterley »

naasking wrote: post #120
otterley wrote: post #112

Earlier quoted context omitted.

Maintaining an open-source software project is frequently a hobby that’s performed out of a labor of love. There’s no duty owed to anyone, nor should one be implied by past behavior. The open-source community is not a slave trade.

Hence why I said "voluntarily".

I don't see how that changes anything (and you didn't say "voluntarily"). Volunteering does not create a duty. One can volunteer to pick up litter and give up halfway through; the only consequence would be disappointment.

Re: WolfSSL sucks too, so now what?

#122

Post by reanimus »

pseudohadamard wrote: post #90
reanimus wrote: post #10

Earlier quoted context omitted.

I don't know, I don't think it's really a huge waste of time considering I just read the entire comment thread in a handful of minutes. And beyond that, failing to comply with RFC requirements is the bug here -- a workaround existing for a specific language isn't a fix.

It's not entirely WolfSSL's fault. TLS 1.3 is a mass of kludges and hacks to deal with the fact that they created a new protocol that's nothing like TLS 1.0-1.2 but dressed it up to make it look like TLS 1.2. It even lies about its protocol version in the handshake, hiding the real version in one of the many extensions they had to invent to kludge it into working. And in terms of RFC compliance, one of the most widel…

The problem is there are many middleboxes that monitor port 443 and will drop any traffic that they can't decode as TLS (which in this case means TLS 1.2 or below). The choice was between masking traffic as an earlier version of TLS or forcing the replacement of all of those middleboxes. It's a no-brainer.

Re: WolfSSL sucks too, so now what?

#123

Post by pseudohadamard »

reanimus wrote: post #122
pseudohadamard wrote: post #90

Earlier quoted context omitted.

It's not entirely WolfSSL's fault. TLS 1.3 is a mass of kludges and hacks to deal with the fact that they created a new protocol that's nothing like TLS 1.0-1.2 but dressed it up to make it look like TLS 1.2. It even lies about its protocol version in the handshake, hiding the real version in one of the many extensions they had to invent to kludge it into working. And in terms of RFC compliance, one of the most widel…

The problem is there are many middleboxes that monitor port 443 and will drop any traffic that they can't decode as TLS (which in this case means TLS 1.2 or below). The choice was between masking traffic as an earlier version of TLS or forcing the replacement of all of those middleboxes. It's a no-brainer.

Then don't put it on 443 and pretend (badly) that it's TLS 1.2. Given that QUIC also uses 443 (and 80) without too many problems and that doesn't look anything remotely like TLS, presumably non-TLS 1.2 traffic to 443 is OK.

The problem isn't really the port used, it's the uncanny-valley approach they took in creating something that looks like a creepy zombie version of TLS 1.2, which keep-suspicious-things-out appliances quite rightly get suspicious over.

Re: WolfSSL sucks too, so now what?

#124

Post by randallsquared »

move-on-by wrote: post #117
randallsquared wrote: post #109

Earlier quoted context omitted.

The "victim" was the Elixir or Erlang library, not himself. To be clear.

I don’t think it was clear, but thanks for the insight. Was WolfSSL forced upon Elixir or Erlang? Did they purchase it and received a defective product? Are they held hostage by WolfSSL’s decisions? Are they not allowed to modify WolfSSL as needed themselves? I fail to see any victims beyond perhaps the WolfSSL maintainers for having to suffer such entitlement.

The lib is (AIUI) a client library, meaning that it will fail to communicate with an HTTPS-enabled, WolfSSL) server, ostensibly because the WolfSSL isn’t SOEC-compliant.

Re: WolfSSL sucks too, so now what?

#125

Post by jcgl »

pseudohadamard wrote: post #123
reanimus wrote: post #122

Earlier quoted context omitted.

The problem is there are many middleboxes that monitor port 443 and will drop any traffic that they can't decode as TLS (which in this case means TLS 1.2 or below). The choice was between masking traffic as an earlier version of TLS or forcing the replacement of all of those middleboxes. It's a no-brainer.

Then don't put it on 443 and pretend (badly) that it's TLS 1.2. Given that QUIC also uses 443 (and 80) without too many problems and that doesn't look anything remotely like TLS, presumably non-TLS 1.2 traffic to 443 is OK. The problem isn't really the port used, it's the uncanny-valley approach they took in creating something that looks like a creepy zombie version of TLS 1.2, which keep-suspicious-things-out applia…

But QUIC doesn’t use 443/TCP; it uses 443/UDP. So it’s unsurprising that middleboxes that care about 443/TCP would ignore it. That doesn’t support your claim that “non-TLS 1.2 traffic to 443 is OK.”

Re: WolfSSL sucks too, so now what?

#126

Post by jezek2 »

AtlasBarfed wrote: post #57
mappu wrote: post #49

Go can create C ABI shared libraries, I think OpenSSL-compatible C bindings to Go's crypto/tls would be a really interesting option.

Do you want garbage collection in your SSL?

Clearing of the secrets is a separate issue from memory allocation mechanism. It must be done all the way from the encryption layer to the program to avoid the leaks.

This is typically not done, only certain parts such as handling of the crypto keys. That's because it's pervasive and requires reworking everything with that in mind (TLS library, web framework, application).

On the other hand the centralization and global usage of GC in the process allows to modify it to always zero out the memory that it deallocated and to do GC at regular intervals so it can have advantage here (it's very easy to inadvertly leak the secrets to some string).

Re: WolfSSL sucks too, so now what?

#127

Post by pseudohadamard »

jcgl wrote: post #125
pseudohadamard wrote: post #123

Earlier quoted context omitted.

Then don't put it on 443 and pretend (badly) that it's TLS 1.2. Given that QUIC also uses 443 (and 80) without too many problems and that doesn't look anything remotely like TLS, presumably non-TLS 1.2 traffic to 443 is OK. The problem isn't really the port used, it's the uncanny-valley approach they took in creating something that looks like a creepy zombie version of TLS 1.2, which keep-suspicious-things-out applia…

But QUIC doesn’t use 443/TCP; it uses 443/UDP. So it’s unsurprising that middleboxes that care about 443/TCP would ignore it. That doesn’t support your claim that “non-TLS 1.2 traffic to 443 is OK.”

The point I was trying to make, probably badly, was that there was no need to make TLS 1.3 pretend to be TLS 1.2 going to TCP/443. They could have picked some new port, called it TLS 2.0 (which is what it actually is), and run with that. If QUIC can pick its own port and, by the looks of it, not run into massive problems, there's no reason why TLS 2.0 can't do so too.

Re: WolfSSL sucks too, so now what?

#129

Post by naasking »

otterley wrote: post #121
naasking wrote: post #120

Earlier quoted context omitted.

Hence why I said "voluntarily".

I don't see how that changes anything (and you didn't say "voluntarily"). Volunteering does not create a duty. One can volunteer to pick up litter and give up halfway through; the only consequence would be disappointment.

> Volunteering does not create a duty.

Volunteering to maintain a project literally does create entail accepting duties, that's what taking on the role of maintainer entails. They are of course free to give up that role at any time, but those duties exist while that role has been adopted.

Re: WolfSSL sucks too, so now what?

#130

Post by otterley »

naasking wrote: post #129
otterley wrote: post #121

Earlier quoted context omitted.

I don't see how that changes anything (and you didn't say "voluntarily"). Volunteering does not create a duty. One can volunteer to pick up litter and give up halfway through; the only consequence would be disappointment.

> Volunteering does not create a duty. Volunteering to maintain a project literally does create entail accepting duties, that's what taking on the role of maintainer entails. They are of course free to give up that role at any time, but those duties exist while that role has been adopted.

Let's suppose for the sake of the argument that while you are a volunteer, you take on some duty. What is the nature of that duty? And how do we enforce the execution of said duty? What are the consequences of it not being performed?

You can't really say someone has a "duty" without also implying that they have a "responsibility," and thus liability if they fail to execute those duties properly. I don't see how this fits at all for a volunteer. Very few people are going to volunteer for no pay if they're taking on a risk of liability.

Maybe you mean a civic duty? That would make somewhat more sense, but the problem is that there’s no objective standard against which to test performance. It’s completely subjective and will be forever argued—much like this thread. :-)

Post reply on HN