tls backends using connection filter IO #9962
Conversation
icing
commented
Nov 22, 2022
•
icing
commented
lib/vtls/mbedtls.c
Outdated
| (void)mbedtls_ssl_read(&backend->ssl, (unsigned char *)buf, sizeof(buf)); | ||
| backend->io_data = NULL; |
There was a problem hiding this comment.
Though I'm loathe to bring up conn->data (which was eliminated about 2 years ago) is there a better way then than the association of data like this at a bunch of seemingly arbitrary points? Yes I'm sure they're not arbitrary but I'm struggling to follow how this works. Is there a more central location where data could be assigned, like vtls for example?
There was a problem hiding this comment.
I agree that this is looking for a more elegant solution. The sprinkling of those assignments in the code is not to my liking really, either.
That we got to have data everywhere is not the right design, since we now have multi-use of connections. In the connection filter chain, bytes handled often to not belong to a specific data.
So, in my view, we should get rid of data in connection IO, at least on the filter level.
There was a problem hiding this comment.
Ok, changes now introduce a standard vtls way to save the current Curl_easy handle in a filter call and backends that need it use it from there.
The "standard" way now also NULLs at the end of a call, so UAFs should not happen.
icing
changed the title
icing
force-pushed
the
cf-tls-chain
branch
5 times, most recently
from
ba6eaaa
to
94ddf80
Compare
- OpenSSL (and compatible)
- BearSSL
- gnutls
- mbedtls
- rustls
- schannel
- secure-transport
- wolfSSL (v5.0.0 and newer)
This leaves the only the following without HTTPS-proxy support:
- gskit
- nss
- wolfSSL (versions earlier than v5.0.0)
|
@icing ready for merge? |
|
Thanks! |
