Wildcard / RegEx SSL ByPass

[Justin99b]

It would really be usefull if we could just add a *.domain.com to bypass ssl

or use a regex

[pimterry]

Can you share some context? Why are you connecting to a large number of unknown invalid SSL servers?

Note that for self-signed certificates, you can just trust the CA instead using the trustAdditionalCAs option. This is generally the much better option: it doesn't disable any normal TLS protections, and will work for all hostnames using that CA.

[Justin99b]

Im talking about the sslPassthrough Option in the https Options when you initialize the Proxy.
Maybe there is another way of doing this. This is ment for SSL pinning and Services that dont need to be mocked or read. So instead of talking Care or the pinning which is Not Always possible i Just want to Bypass the Proxy or in that passthrought

[pimterry]

Ah, I see, sorry I thought you meant a different option.

This makes sense, I can see how that would be useful. I think a regex would be preferable, since that's more flexible and we already have various APIs available which use regexes elsewhere.

Want to make a PR?

One challenge here is that these options are also sent by remote clients, just serialized as JSON, and regexps don't serialize by default, so a tiny bit of serialization/deserialization logic to transfer regex configuration would be required. Happy to give you some pointers on how to make that work if you're interested, and you could start with just server-side support first anyway.

[Justin99b]

Sure you can give me some starting points, i wont be able to test this properly but i can share some modifications if it works for simple usecases without remote clients. But good point. You refering to the Admin api when you say remote clients right?

[pimterry]

You refering to the Admin api when you say remote clients right?

Yes, exactly

Sure you can give me some starting points

To make this happen, we'd need to:

• Create an automated test for this, probably near/within the existing tests here
• Modify the HTTPS options type to allow regex values here
• Modify analyzeAndMaybePassThroughTls to use these values when looking at incoming hostnames
• Modify the admin client to serialize regexes (e.g. to { regexSource: [string] }), if they're present within the options here
• Modify the admin API to deseralize regexes here

[lipsumar]

I find myself in a similar situation, but somehow reversed: I'd like for all requests to "passThroughTLS" unless it's a specific domain. I'm using mockttp as a system proxy and I really just want to intercept and modify requests for a specific domain, ideally all other traffic would be left completely untouched.

Basically I'm looking for a solution similar to mitmproxy's --allow-hosts option, where all other traffic is ignored.

Would this be possible with mockttp ?

[pimterry]

Good suggestion @lipsumar! That definitely makes sense.

This would require a different change to the options format used - since it'd be very awkward to do this via an array of positive regex matches, it'd need to be a different option entirely, or an explicitly separate option value like {match:"inverted",values:[...]} (just an example, there's probably clearer names for this).

Thats all quite possible though, and it's a compelling use case. Want to open a PR?

In the meantime, the best alternative solution to this would be to handle it in the noproxy settings of the client - most clients support some kind of config on their side that can do this. That's less flexible to configure, but it should do what you need.

[lipsumar]

How about this:

type MockttpHttpsOptions = CAOptions & {
  // ...existing options 

  tlsOnlyFor?: Array<{ hostname: string }>;
}

This option would be the exact inverse of tlsPassthrough, and there would be a check that both are not used simultaneously. I'm not super convinced that's a good name, feel free to suggest another.

If this direction works for you then I'll open a PR.

[pimterry]

Sure, that makes sense... How about tlsPassthroughExclusion or noTlsPassthrough? It would be useful to make the two options clearly very closely related, so it's more obvious that they're mutually exclusive.

Anyway the name is a small detail we can tweak easily until release. Regardless, yes - let's go that route. Happy to go with whatever name you like best and worry about that later.

We can add regexes/wildcards (the original issue here) on top for both cases later on, so just an array type matching the existing tlsPassthrough option is fine.