I’m wondering if the opposite of this scenario has been tested, where the
server is running 2.3.18 (on Linux) and a client running 2.5 (on Windows) tries
to connect?
I know, I know, we should upgrade. Unfortunately in this case OpenVPN server
is running on an appliance that cannot be upgraded past Linux 2.6, and I don’t
think 2.4.x can run on Linux 2.6.
Marvin
Sent from my iPhone
> On Jul 13, 2020, at 1:57 AM, Arne Schwabe <a...@rfc2549.org> wrote:
>
>> Am 13.07.20 um 08:58 schrieb Gert Doering:
>> Hi,
>>
>>> On Mon, Jul 13, 2020 at 08:33:03AM +0200, Gert Doering wrote:
>>>> On Mon, Jul 13, 2020 at 08:10:23AM +0200, Gert Doering wrote:
>>>> Ouch. This is not good. My gut feeling is "2.3 with --enable-small =
>>>> no OCC *and* no NCP = the server runs across a NULL pointer here".
>>>
>>> Bäm. Fully reproduceable here
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x00007ffff7af51be in ?? () from /lib64/libc.so.6
>>> (gdb) where
>>> #0 0x00007ffff7af51be in ?? () from /lib64/libc.so.6
>>> #1 0x00005555555d4a7b in ncp_get_best_cipher (server_list=<optimized out>,
>>> server_cipher=0x5555555f28da "BF-CBC",
>>> peer_info=peer_info@entry=0x5555556781c0
>>> "IV_VER=2.3.18\nIV_PLAT=freebsd\nIV_PROTO=2\n", remote_cipher=0x0,
>>> gc=gc@entry=0x55555565e070) at ssl_ncp.c:231
>>
>> ... and this is why (added a msg() call):
>>
>> 2020-07-13 08:36:59 us=802772 ncp_get_best_cipher(), peer_ncp_list=,
>> tmp_ciphers=AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-192-CBC:AES-256-CBC,
>> remote_cipher=(null), server_cipher=BF-CBC
>>
>> if "remote_cipher" is NULL (= no OCC) we pass that to "strcmp()", and that
>> does not want it.
>>
>>
>> Returning NULL from ncp_get_best_cipher() if there is nothing the client
>> has to offer works fine, though it triggers this warning
>>
>> 2020-07-13 08:43:01 us=483904 cron2-freebsd-tc-amd64-23/194.97.140.21:30927
>> PUSH: No common cipher between server and client.Expect this connection not
>> to work. Server ncp-ciphers:
>> 'AES-256-GCM:AES-128-GCM:AES-128-CBC:AES-192-CBC:AES-256-CBC', client
>> supported ciphers ''
>>
>>
>> which we might want to reword for this case ("No information about cipher
>> support received from client, cannot ensure correct operation" or so).
>>
>> Patch appended.
>>
>> Comments?
>
>
>
>
> + }
> + else
> + {
> + msg(M_INFO, "PUSH: No cipher info received from
> client "
> + "(no NCP and no OCC). Cannot ensure
> compatibility.");
> + }
> gc_free(&gc);
>
>
> This is misleading. peer_chipers == "" only says that the peer does not
> send IV_CIPHERS/IV_NCP. I think I would rather do something change the
> message to:
>
>
> msg(M_INFO, "No NCP data received from peer, falling back to --cipher
> '%s'. Peer reports in OCC --cipher '%s'", o->ciphername,
> np(tls_multi->remote_ciphername));
>
>
> This avoid adding another if else for now. And yes for clients without
> occ you get that annoying warning in the log but that is okay.
>
>
> Otherwise ACK.
>
> Arne
>
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
