Hello!
30. Jun 2017 18:56 by g...@greenie.muc.de:
> Hi,
>
> On Fri, Jun 30, 2017 at 06:20:29PM +0200, > open...@keemail.me> wrote:
>> Now, in some cases, when the client connects with different ciphers, the
>> server appears to wrongly choose the peer cipher or data channel enc/dec
>> cipher.
>>
>> In the server logs this is can be observed as:
>>
>> <DATETIME> us=416063 <CLIENT-NAME>/<CLIENT-IP:PORT> WARNING: 'link-mtu' is
>> used inconsistently, local='link-mtu 1602', remote='link-mtu 1550'
>> <DATETIME> us=416125 <CLIENT-NAME>/<CLIENT-IP:PORT> WARNING: 'cipher' is
>> used inconsistently, local='cipher AES-256-CBC', remote='cipher AES-128-GCM'
>> <DATETIME> us=416182 <CLIENT-NAME>/<CLIENT-IP:PORT> WARNING: 'auth' is used
>> inconsistently, local='auth SHA512', remote='auth [null-digest]'
>> <DATETIME> us=416317 <CLIENT-NAME>/<CLIENT-IP:PORT> WARNING: 'keysize' is
>> used inconsistently, local='keysize 256', remote='keysize 128'
>> <DATETIME> us=416538 <CLIENT-NAME>/<CLIENT-IP:PORT> Data Channel Encrypt:
>> Cipher 'AES-256-CBC' initialized with 256 bit key
>> <DATETIME> us=416614 <CLIENT-NAME>/<CLIENT-IP:PORT> Data Channel Encrypt:
>> Using 512 bit message hash 'SHA512' for HMAC authentication
>> <DATETIME> us=416672 <CLIENT-NAME>/<CLIENT-IP:PORT> Data Channel Decrypt:
>> Cipher 'AES-256-CBC' initialized with 256 bit key
>> <DATETIME> us=416730 <CLIENT-NAME>/<CLIENT-IP:PORT> Data Channel Decrypt:
>> Using 512 bit message hash 'SHA512' for HMAC authentication
>> <DATETIME> us=416803 <CLIENT-NAME>/<CLIENT-IP:PORT> TLS: move_session:
>> dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1
>> <DATETIME> us=417059 <CLIENT-NAME>/<CLIENT-IP:PORT> TLS: tls_multi_process:
>> untrusted session promoted to semi-trusted
>
> If you look closely, you can see that there is no "Connection established"
> here, because the server does not see this as a *new* connection, but
> thinks it's a TLS renegotiation.
Does the server and/or the client cache TLS connections or in an other way keep
track of previous connections?
Is there a way to prevent this behaviour?
>
>
> Unless there is a specific reason, always use --nobind on the client, which
> ensures that a client restart will use a different port, avoiding this
> issue.
>
>> WR<DATETIME> us=417997 <CLIENT-NAME>/<CLIENT-IP:PORT> Control Channel:
>> TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4069 bit RSA
>> R<DATETIME> us=551112 <CLIENT-NAME>/<CLIENT-IP:PORT> PUSH: Received control
>> message: 'PUSH_REQUEST'
>> WR<DATETIME> us=690323 <CLIENT-NAME>/<CLIENT-IP:PORT> PUSH: Received control
>> message: 'PUSH_REQUEST'
>> WR<DATETIME> us=956749 <CLIENT-NAME>/<CLIENT-IP:PORT> PUSH: Received control
>> message: 'PUSH_REQUEST'
>> WR<DATETIME> us=474589 <CLIENT-NAME>/<CLIENT-IP:PORT> PUSH: Received control
>> message: 'PUSH_REQUEST'
>> WR<DATETIME> us=993878 <CLIENT-NAME>/<CLIENT-IP:PORT> PUSH: Received control
>> message: 'PUSH_REQUEST'
>
> Something is funky here anyway, as we shouldn't be receving multiple
> PUSH_REQUESTS in short order, but since you mangled the timestamps and
> client ports, it's not easy to see what really happened.
>
>> <DATETIME> us=993980 <CLIENT-NAME>/<CLIENT-IP:PORT> Using peer cipher
>> 'AES-128-GCM'
>
>
The client is connected mutliple times at this moment, I know the mangled
IP/Port/Datetimes make that hard to see, but the logs are chronological and
only concern with the client connection using AES-128-GCM.
> ... why is the client not using NCP anyway? "using peer cipher" is just
> a fallback option for 2.3 clients that cannot be properly upgraded...
>
> [..]
>> Why does this occur and how can I fix this issue?
>
> - use --nobind on the client
> - use 2.4.3 everywhere
> - do not use --ncp-disable and varying --cipher settings unless there is
> a very specific situation that you need this for
You have valid and very helpful comments, but for this specific case I ca not
use --nobind.
The client(s) will be updated any day now, but I need to keep --ncp-disable and
varying --cipher's as that's a requirement for me.
>
>
> gert
>
> --
> USENET is *not* the non-clickable part of WWW!
> //www.muc.de/~gert/
> Gert Doering - Munich, Germany >
> g...@greenie.muc.de
> fax: +49-89-35655025 >
> g...@net.informatik.tu-muenchen.de
Thank youÂ
op------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
