-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feature] Dialer: Support for custom NetDial for TLS #745
Comments
Fixes issue: gorilla#745 With the previous interface, NetDial and NetDialContext were used for both TLS and non-TLS TCP connections, and afterwards TLSClientConfig was used to do the TLS handshake. While this API works for most cases, it prevents from using more advance authentication methods during the TLS handshake, as this is out of the control of the user. This commits introduces another pair of dial methods, NetDialTLS and NetDialTLSContext which are used when dialing for TLS/TCP. The code then assumes that the handshake is done there and TLSClientConfig is not used. This API change is fully backwards compatible and it better aligns with net/http.Transport API, which has these four dial flavors. See: https://pkg.go.dev/net/http#Transport Signed-off-by: Lluis Campos <[email protected]>
Fixes issue: gorilla#745 With the previous interface, NetDial and NetDialContext were used for both TLS and non-TLS TCP connections, and afterwards TLSClientConfig was used to do the TLS handshake. While this API works for most cases, it prevents from using more advance authentication methods during the TLS handshake, as this is out of the control of the user. This commits introduces another pair of dial methods, NetDialTLS and NetDialTLSContext which are used when dialing for TLS/TCP. The code then assumes that the handshake is done there and TLSClientConfig is not used. This API change is fully backwards compatible and it better aligns with net/http.Transport API, which has these four dial flavors. See: https://pkg.go.dev/net/http#Transport Signed-off-by: Lluis Campos <[email protected]>
By switching to the "enhanced" API for websocket.Dialer from mendersoftware's fork. There is a limitation in current gorilla/websocket.Dialer API in that the user cannot specify a dial method for TLS/TCP connections. The TLS handshake is always done by the library based on user's TLSClientConfig, but that is not enough for Mender as we need it to be done via OpenSSL (aka our dial wrapper for TLS) so that advance auth features like getting the keys from HSM. This commit switches to mendersoftware's fork and modifies the code accordingly (one line change!). The patch has been submitted upstream. See: * gorilla/websocket#745 * gorilla/websocket#746 Changelog: None No changelog, commit 84204a3 claims to support websockets, this commit just fixes a bug there which has not been released. Signed-off-by: Lluis Campos <[email protected]>
Fixes issue: gorilla#745 With the previous interface, NetDial and NetDialContext were used for both TLS and non-TLS TCP connections, and afterwards TLSClientConfig was used to do the TLS handshake. While this API works for most cases, it prevents from using more advance authentication methods during the TLS handshake, as this is out of the control of the user. This commits introduces another a new dial method, NetDialTLSContext, which is used when dialing for TLS/TCP. The code then assumes that the handshake is done there and TLSClientConfig is not used. This API change is fully backwards compatible and it better aligns with net/http.Transport API, which has these two dial flavors. See: https://pkg.go.dev/net/http#Transport Signed-off-by: Lluis Campos <[email protected]>
Based on feedback from the pull request, the resulting change will only add |
Fixes issue: #745 With the previous interface, NetDial and NetDialContext were used for both TLS and non-TLS TCP connections, and afterwards TLSClientConfig was used to do the TLS handshake. While this API works for most cases, it prevents from using more advance authentication methods during the TLS handshake, as this is out of the control of the user. This commits introduces another a new dial method, NetDialTLSContext, which is used when dialing for TLS/TCP. The code then assumes that the handshake is done there and TLSClientConfig is not used. This API change is fully backwards compatible and it better aligns with net/http.Transport API, which has these two dial flavors. See: https://pkg.go.dev/net/http#Transport Signed-off-by: Lluis Campos <[email protected]>
Now that upstream have merged our PR. Slightly modify our code accordingly. See: * gorilla/websocket#745 * gorilla/websocket#746 Changelog: None Signed-off-by: Lluis Campos <[email protected]>
Now that upstream have merged our PR. Slightly modify our code accordingly. See: * gorilla/websocket#745 * gorilla/websocket#746 Changelog: None Signed-off-by: Lluis Campos <[email protected]>
Is your feature request related to a problem? Please describe.
On the
Dialer
, I need to use a customNetDial
method for TLS connections to be able to use some advance authentication methods like Mutual TLS using a client key from a Hardware Security Module (HSM). I have some go code wrapping OpenSSL that does the TLS dialing, including the handshake.This works fine for regular
https
requests by setting this dial function asDialTLS
fornet/http.Transport
.The problem in
gorilla/websocket
is that the currentDialer
interface only supports setting one pair of dial methods (NetDial
andNetDialContext
) which is used both forhttp
andhttps
connections. Later, forhttps
a handshake is performed usingTLSClientConfig
, but in my casetls.Config
fields are not enough to do the handshake, code here.Describe the solution you'd like
My suggestion is to have two pair of dial functions,
NetDial
+NetDialContext
, andNetDialTLS
+NetDialTLSContext
. The latter pair would be used onwss
/https
connections. To avoid unexpected behavior when settingTLSClientConfig
, if eitherNetDialTLS
orNetDialTLSContext
are set the code would assume that the TLS handshake has been performed there andTLSClientConfig
can be ignored.This API change would be completely backwards compatible, and it will better mimic the API of
net/http.Transport
(doc here).I do have a working code for exact this API change that I am suggesting. I want to add some tests before submitting a PR. In the meanwhile, any feedback is welcome 😃
Describe alternatives you've considered
My workaround was to force the url to passed to
Dial
bews
, so that this specific block is skip... However this only works on certain circumstances and it is very hacky.The text was updated successfully, but these errors were encountered: