Features Download
From: Timothe Litt <litt <at> acm.org>
Subject: Re: Topics for today's community meeting
Newsgroups: gmane.network.openvpn.devel
Date: Thursday 24th April 2014 13:23:59 UTC (over 3 years ago)
The tls_read_plaintext error discussion continued past the e-mail chains 
pointed to on the meeting topic.

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 
   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  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 
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-[email protected] 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>
CD: 2ms