Closed Ne0nd0g closed 4 years ago
The ja3transport.JA3Client object, ideally, is used in situations where one doesn't need to use a custom utls.Config object.
In my opinion, the cleanest way to use this library when setting non-default options like InsecureSkipVerify
is to create and use a NewTransportWithConfig
and set InsecureSkipVerify
like you were talking about. Although it's more lines of code for the library user, it cleans up the potential code for this project.
My only concern with creating a new constructor whenever a tls option needs to be set is that there are 25 options which can be set in the utls.Config library. If we make one ja3transport.Client constructor for each option, it's a bit much. I really appreciate the pull request, but I think it sets a bad precedent for setting custom utls.Config options that can already be accessed by using the NewTransportWithConfig
constructor and creating an http.Client.
Also, I think you changed the go.mod file to use your username.
Let me know what you think about this.
Add
NewInsecure
,NewWithStringInsecure
, andNewTransportInsecure
functions so the returned client will accept untrusted TLS connections. This is useful for when you want to interact with a server using self-signed X.509 certificates.The other alternative is to import the
github.com/refraction-networking/utls
library, build autls.Config
structure withInsecureSkipVerify = true
, call the existingNewTransportWithConfig()
function with the previously created utls.Config, callNewWithString()
function, and update the returnedJA3Client.Config
struct to allow insecure connections.The InsecureSkipVerify must be set in two places. Once on the exported JA3Client.Config and a second time on the private (not exported) JA3Client.client (a *http.Client).