I don't know if I'll be able to make the IRC meeting (and I'm just a user, not a developer), so here are a couple of notes:
Both the read_plaintext error (mine) and the george ross report appear to be due to TLS1.2's extra signing algorithms that use different hashes. The good luck is that their size is different - that's what's causing us to get errors.
Mine is caused by the windows crypto api, which doesn't know how to sign the client certificate with TLS1.2's hashes.
George's is not known - but the best guess is that he may be using another external key loader (such as pkcs11, or maybe an android/ios client. Or maybe the patch that provided macOS keyring support.) His log file showes that he is also sending a client certificate, and getting a digest size error.
For these, it is not necessary to go back to TLS1.0 - TLS1.1 suffices. The question of how to do this is open.James has suggested the tls-version-min/max options. Having the options seems like a good thing.
However, I think they should default to max = 'highest', and min = 1.0. (We can solve the known issues behind the scenes, with less impact.)
The main reason is that once a work-around is put into a config file, it tends to stick forever. So we don't want to have lower security be sticky.
The second reason is that it requires work and knowledge of people who write config files. Since the requirement for downgrading is transient, and option-dependent, this isn't simple to document. And teaching users what to do as things change will annoy them (and us.) So the tendency will be 'least common denominator' - which is lowest security.
To deal with the issues with external key loaders, I suggest that OpenVPN can do the right thing automagically. The approach is:
When starting to setup a tunnel: Start with min = TLS1.0, max = highest. Add required_min, required_max initialized to 3, highest.In options.c (where options are parsed), when an option that invokes an external loader (or other dependency on 1.2) is used: adjust required_min/max to the larger/smaller of the component's requirements That is, cryptoapicert would say 'max=tls1.0', so the required max would be decreased to 1.0
When the context is initialized, the option flags are adjusted to the larger of (min, required_min) and the smaller of (max, required_max). If they are different, a note can be logged. (tls-version-max reduced because an option doesn't support version > 'max' yet) If there is no solution, an error is logged. (tls version requirements can't be satisfied: min > max)
The advantages of this approach: o It's simple. (takes less code than these words)o It's automatic - people who write config files won't hardcode work-arounds of lower security o It only applies to situations where it's needed - so a client that uses cryptoapicert today will go to 1.1, but a client talking to the same server with a <cert> directive will use 1.2 o As the components with dependencies are upgraded to 1.2, nothing changes in config files; the improved security will take effect automatically. o If other dependent components (options) are identified, it's easy to add their dependencies.
A fancier implementation could have the components register their SSL version support with a formal API - but that seems like more work than a quick patch.
Note: for the known issues, a 'max' is all that's required. I included 'min' for symmetry and as a hedge for future cases.
I hope this note is helpful. On 24-Apr-14 05:42, Samuli Seppänen wrote:
Hi, We're having an IRC meeting on Thursday, starting at 18:00 UTC on #openvpn-de...@irc.freenode.net. Current topic list is here: <https://community.openvpn.net/openvpn/wiki/Topics-2014-04-24> If you have any other things you'd like to bring up, respond to this mail, send me mail privately or add them to the list yourself. In case you can't attend the meeting, please feel free to make comments on the topics by responding to this email or to the summary email sent after the meeting. Whenever possible, we'll also respond to existing, related email threads. NOTE: It's required to use a registered Freenode IRC nickname to join #openvpn-devel - look here for details: <https://community.openvpn.net/openvpn/wiki/GettingHelp#DeveloperIRCchannel>
smime.p7s
Description: S/MIME Cryptographic Signature
