[Openvpn-devel] [PATCH] polarssl: disable 1/n-1 record splitting

[Steffan Karger]

Disable record splitting (for now).  OpenVPN assumes records are sent
unfragmented, which is no longer a valid assumption when record splitting
is enabled (which polarssl/mbedtls did in 1.3.10, see trac #524).
Changing the code to deal with record splitting will require intrusive
changes that need thorough review and testing.  Since OpenVPN is not
susceptible to BEAST (the data transmitted over the control channel is
very hard to influence for a remote attacker), we can just disable record
splitting as a quick fix.  This gives us the time to develop a proper
solution in the mean time, and test that thoroughly.

Signed-off-by: Steffan Karger 
---
 src/openvpn/ssl_polarssl.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/openvpn/ssl_polarssl.c b/src/openvpn/ssl_polarssl.c
index 1a40304..158088f 100644
--- a/src/openvpn/ssl_polarssl.c
+++ b/src/openvpn/ssl_polarssl.c
@@ -727,6 +727,14 @@ void key_state_ssl_init(struct key_state_ssl *ks_ssl,
   if (ssl_ctx->allowed_ciphers)
ssl_set_ciphersuites (ks_ssl->ctx, ssl_ctx->allowed_ciphers);

+  /* Disable record splitting (for now).  OpenVPN assumes records are sent
+   * unfragmented, and changing that will require thorough review and
+   * testing.  Since OpenVPN is not susceptible to BEAST, we can just
+   * disable record splitting as a quick fix. */
+#if defined(POLARSSL_SSL_CBC_RECORD_SPLITTING)
+  ssl_set_cbc_record_splitting (ks_ssl->ctx, 
SSL_CBC_RECORD_SPLITTING_DISABLED);
+#endif /* POLARSSL_SSL_CBC_RECORD_SPLITTING */
+
   /* Initialise authentication information */
   if (is_server)
polar_ok(ssl_set_dh_param_ctx(ks_ssl->ctx, ssl_ctx->dhm_ctx));
-- 
2.1.4

Re: [Openvpn-devel] OpenVPN argument parsing of most options ignores "extra" parameters

[Jonathan K. Bullard]

On Sun, May 3, 2015 at 12:33 PM, Steffan Karger  wrote:
> On 17-04-15 11:28, Jonathan K. Bullard wrote:
> > I would like to propose a patch which complains if OpenVPN options
> > include parameters that are not expected.
>
> I agree that silently ignoring extra parameters is not nice. However, I
> think that breaking configs after they have worked for many years might
> result in too many unpleasant surprises for our users. How would you
> feel about just issuing a warning for ignored extra parameters?

Thanks for your comment. It's a difficult balance.

In my opinion a warning is not sufficient: if a configuration has an
extra parameter, the user probably **thinks** that the parameter is
doing something. In that situation, I would personally would rather
have an unpleasant surprise than continue in ignorance. If I have a
configuration that has worked for many years I might be more likely to
not notice one warning among all the output in a typical log at the
default "verb 3" setting.

The "fix" if a config fails is very simple: remove the extra parameter
or insert a line break if one is missing. You can then connect, and
OpenVPN's behavior will not have changed except that if a line break
was inserted then the previously ignored option will be used. If the
parameter was supposed to do something important, then more thought
might be required, but in that case, it is probably even **more**
important that the configuration breaks.

Perhaps it could go into OpenVPN 2.4 but not 2.3? As I understand it,
2.3 is gets security and bug fixes, so many people probably don't test
it as thoroughly as a new release; some probably won't test it at all
-- those are the ones that you are presumably worried about. When 2.4
is released, most people will test it at least cursorily before
deploying it. If extra parameters cause a failure, it will be
immediately obvious and can be fixed easily.

Although usually ignoring extra parameters would not cause security
problems, to the extent they do, the concept of OpenVPN being "secure
by default" is jeopardized by not causing an error. Something like
ignoring a "--redirect-gateway def1" -- which would cause traffic to
be "leaked" outside of the VPN -- could be considered a security risk.

[Openvpn-devel] Topics for today's (Monday, 4th May 2015) community meeting

[Samuli Seppänen]

Hi,

We're going to have an IRC meeting today, 4th May, starting at 20:00
CEST (18:00 UTC) on #openvpn-devel  irc.freenode.net. Current topic
list
along with basic information is here:



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:



-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock




signature.asc
Description: OpenPGP digital signature