how to override things like clientSupported member of TLS ClientParams

[bfrk]

From 1.9.x to 2.0.x the tls package made a change to require EMS (extended main secret) by default. I must admit that I have no idea what this is about and I don't really care much. However, it turns out that for compatibility reasons I need to change it to the old behavior (which allowed but did not require it).

I am not using tls directly but via http-client-tls which is in turn based on crypton-connection. I need to install a new connection manager, using code like

manager <- newManager $ mkManagerSettings tlsSettings Nothing
setGlobalManager manager

where tlsSettings is of type TLSSettings which is provided by crypton-connection.

The problem is that this data type is either TLSSettingsSimple with no way to override things like the clientSupported member of Network.TLS.ClientParams; or else it is TLSSettings with an argument of type ClientParams, but ClientParams contains server specific data, so it is unsuitable as configuration for a generic connection manager, or at least that is how it appears to me.

The magic that fills in the host specific parameters in the case of TLSSettingsSimple is in makeTLSParams, which gets the host specific data passed as arguments. One possible solution would be to add a member

settingClientSupported :: Maybe ClientSupported

to TLSSettingsSimple and use that in makeTLSParams to override the default.

[kazu-yamamoto]

If you kindly send a PR, I will merge it and release a new version.

BTW, TLS 1.2 without EMS is insecure. I understand the server does not support it but I think you should ask to support EMS in the server side.

[bfrk]

I agree that it would be better to upgrade the server, but there are situations where this is difficult or even impossible to achieve: there are legacy servers, particularly proprietary devices which may not even be available any more much less supported with (firmware) upgrades. In my line of work this happens quite frequently.

[kazu-yamamoto]

The intention of this breaking change is to tell users that they are using insecure channels.
It is up to them whether or not they continue to use those insecure channels.

[bfrk]

Yes, I agree that this is the right approach. Ideally, a program where the server URL is specified by user input (or configuration) should issue a (single) warning for each server that doesn't support EMS. Doing this in our case would require a separate probing pass with RequireEMS for each new server, falling back to AllowEMS if that fails. I think the right place to add such a feature is the generic connection manager in http-client-tls since this is where we keep track of servers and (TLS enabled) connections.

[kazu-yamamoto]

I think that the warning-fallback approach works for clients well.
It's worth considering.
But what about server sides?
How to tell the warnings to their operators?

[bfrk]

I'd say leave it to users (of client programs I mean) to complain to server operators about annoying warnings ;-)