Hi,
On Tue, Oct 9, 2018 at 9:43 PM Gert Doering <g...@greenie.muc.de> wrote:
> 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
>
> I built this from source but on a debian7 system so it could be having
issues.
- 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.
>
I used ncp-disable and it resolved the issue. Many thanx!
> 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
>
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
