Currently, there is no public interface to supply TLSConfig to the srv *Server argument of dialTLS. There is only one caller of dialTLS: DialTLSExt which constructs a Server without TLSConfig just prior to calling dialTLS.
Therefore InsecureSkipVerify will always be true in the TLSConfig used by the client. It's an understandable default since ServerName must be part of the config if InsecureSkipVerify is false, according to: https://pkg.go.dev/crypto/tls#Client. Just there isn't a way to get to the other branch of that if. All the customization from supplying a TLSConfig such as using a different cert bundle than the system level certs are also not accessible.
Perhaps another DialTLS variant could be added to supply the TLSConfig? I expect the existing interfaces probably shouldn't change as there are likely many uses of them.
Currently, there is no public interface to supply
TLSConfig
to thesrv *Server
argument ofdialTLS
. There is only one caller ofdialTLS
:DialTLSExt
which constructs aServer
withoutTLSConfig
just prior to callingdialTLS
.So in
dialTLS
srv.TLSConfig
is alwaysnil
in the following: https://github.com/fiorix/go-diameter/blob/f6f13778dcc4d7d18197f76eab5252de712f3ba6/diam/client.go#L135-L139Therefore
InsecureSkipVerify
will always be true in the TLSConfig used by the client. It's an understandable default sinceServerName
must be part of the config ifInsecureSkipVerify
is false, according to: https://pkg.go.dev/crypto/tls#Client. Just there isn't a way to get to the other branch of that if. All the customization from supplying a TLSConfig such as using a different cert bundle than the system level certs are also not accessible.Perhaps another
DialTLS
variant could be added to supply theTLSConfig
? I expect the existing interfaces probably shouldn't change as there are likely many uses of them.