CUCyber / ja3transport

Impersonating JA3 signatures
MIT License
372 stars 61 forks source link

Facilitate Insecure TLS Connections #3

Closed Ne0nd0g closed 4 years ago

Ne0nd0g commented 4 years ago

Add NewInsecure,NewWithStringInsecure, and NewTransportInsecure 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 a utls.Config structure with InsecureSkipVerify = true, call the existing NewTransportWithConfig() function with the previously created utls.Config, call NewWithString() function, and update the returned JA3Client.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).

t94j0 commented 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.