Hi, (copying in openvpn-devel, as this is something Steffan will want to see...)
On Tue, Oct 09, 2018 at 06:41:30PM +0300, Alex K wrote:
> Adding some more lines (verbosity 3):
>
> Tue Oct 9 15:38:17 2018 UDP link remote: [AF_INET]<remote>:1195
> Tue Oct 9 15:38:17 2018 TLS: Initial packet from [AF_INET]<remote>:1195,
> sid=45b5d735 c7b01909
> Tue Oct 9 15:38:18 2018 VERIFY OK: depth=1, C=GR, ST=Attiki, L=Location,
> O=Company, OU=Server, CN=Server, name=Server, emailAddress=
> supp...@tech-group.com
> Tue Oct 9 15:38:18 2018 VERIFY OK: nsCertType=SERVER
> Tue Oct 9 15:38:18 2018 VERIFY OK: depth=0, C=GR, ST=Attiki, L=Location,
> O=Company, OU=Server, CN=Server, name=Server, emailAddress=
> supp...@tech-group.com
> Tue Oct 9 15:38:20 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3
> ECDHE-RSA-AES256-GCM-SHA384, 1024 bit RSA
> Tue Oct 9 15:38:20 2018 [Server] Peer Connection Initiated with
> [AF_INET]<remote>:1195
> Tue Oct 9 15:38:21 2018 SENT CONTROL [Server]: 'PUSH_REQUEST' (status=1)
> Tue Oct 9 15:38:22 2018 PUSH: Received control message:
> 'PUSH_REPLY,route-gateway 169.250.0.1,topology subnet,ping 120,ping-restart
> 600,ifconfig 169.250.0.2 255.255.0.0,peer-id 0,cipher AES-256-GCM'
So, the TLS handshake works just fine. The server recognizes that this
is a new client that claims to be capable of using the AES-GCM cipher
modes (= faster, more secure, less overhead) and sends back "please use
AES-256-GCM"
[..]
> Tue Oct 9 15:38:22 2018 WARNING: this configuration may cache passwords in
> memory -- use the auth-nocache option to prevent this
> Tue Oct 9 15:38:22 2018 Initialization Sequence Completed
Everything seems to be just fine.
> Tue Oct 9 15:38:41 2018 cipher_ctx_update_ad: EVP_CipherUpdate() failed
> Tue Oct 9 15:38:41 2018 Exiting due to fatal error
19 seconds later, "something explodes".
Possibly this is when the first packet is sent by the client or when
the first packet comes in for decryption - "man EVP_CipherUpdate" says
that this is for encryption or decryption.
The code in question is here:
cipher_ctx_update_ad(EVP_CIPHER_CTX *ctx, const uint8_t *src, int src_len)
{
#ifdef HAVE_AEAD_CIPHER_MODES
int len;
if (!EVP_CipherUpdate(ctx, NULL, &len, src, src_len))
{
crypto_msg(M_FATAL, "%s: EVP_CipherUpdate() failed", __func__);
}
return 1;
#else /* ifdef HAVE_AEAD_CIPHER_MODES */
ASSERT(0);
#endif
... which basically assumes "this operation can never fail". If it does,
the client gives up, because it does not know what to do.
There are two things to test here
- since you built from source (if I understand you right), run
"make check" in the openvpn source tree - this will test all cipher
modes including AES-GCM, so it should also fail
- run the client with "--ncp-disable" configured - this will make it
stop advertising NCP capability to the server, so the server will
not try to push AES-256-GCM to the client. Effectively bumping crypto
handshake to 2.3.x level.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
