net: Add ControlContext to Dialer

[pquerna]

The net.Dialer struct contains a the .Control field, a callback. The original intention of this method was to "Permit setting socket options", as noted in the Go 1.11 release notes. One additional use case for this function is a defensive purpose: Preventing some types of Server Side Request Forgery (SSRF) -- as detailed in this blog post:

https://www.agwa.name/blog/post/preventing_server_side_request_forgery_in_golang

In security focused use case, having a variant of the .Control method which received the context.Context would be very helpful:

1. It would allow propagation of logging contexts, metric context or other metadata down to the callback.
2. Potentially, the callback could be doing I/O, such as checking with an external service, if a destination is allowed. Today without a context.Context, you don't get cancellation or other context.Values that could be helpful.

Proposed addition to the Dialer struct:

type Dialer struct {
    ControlContext (ctx context.Context, network string, address string, c syscall.RawConn) error
}

Similar to other *Context variants in the standard library, it would only be used if set, and used in preference to the non-context variant.

[rsc]

/cc @neild

[neild]

Using the Control callback for security controls feels like scope creep; Control was intended for injecting socket options, which is why it's called after the socket is created.

That said, I can think of other cases where it might be useful to pass a Context down to the Control func. We've got a package inside Google which passes socket-level network QoS settings via the Context, for example, and I could imagine having a Control func that sets the QoS based on the context value.

I don't have a strong opinion on whether we should add a ControlContext, but it doesn't seem unreasonable.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

The filtering sounds maybe questionable, but there are other good reasons to have a ControlContext form.

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

[gopherbot]

Change https://go.dev/cl/444955 mentions this issue: net: Add ControlContext to Dialer

[database64128]

It might be too late to post this, but I think it would be nice if the new control function has netip.AddrPort instead of string as the address type.

[database64128]

Control is ignored if ControlContext is not nil.

This change breaks forward compatibility for types that wrap a net.Dialer and manipulate the user-specified control function. For example, tfo-go implements TCP Fast Open support on Linux by providing a Dialer type that wraps a net.Dialer and dials by replacing Dialer.Control with a function that does the setup and calls the user-specified control function. If the user upgrades Go and starts using ControlContext, this would be broken.

[ianlancetaylor]

That is true, but it's OK (not ideal, but OK) if a program that uses a new library feature fails to work as expected when using an existing package that is not aware of that new library feature. It should be straightforward for those packages to be updated for the new release.

[gopherbot]

Change https://go.dev/cl/451420 mentions this issue: doc/go1.20: add release notes for net package