Opened 4 years ago

Last modified 15 months ago

#816 new Bug / Defect

'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA512'

Reported by: IPTRACE Owned by:
Priority: trivial Milestone:
Component: OpenVPN Connect Version: 1.0.7
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Steffan Karger



Server log indicates the following warning.

peer info: IV_GUI_VER=net.openvpn.connect.ios_1.0.7-199
peer info: IV_VER=3.0.11
peer info: IV_PLAT=ios
peer info: IV_NCP=2
peer info: IV_TCPNL=1
peer info: IV_PROTO=2
peer info: IV_LZ4=1
WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA512'

Client log shows that sets properly auth as SHA512 value.
All works as expected.

Server config:

auth SHA512

Client config:

auth SHA512

Change History (6)

comment:1 Changed 4 years ago by Gert Döring

Cc: Steffan Karger added

I assume this is due to cipher negotiation selecting AES-256-GCM and the built-into-that authentication, which shows up as "[null-digest]" - and of course, since negotiated differently from what is in the config, this shows up as a warning...

You'll see the same thing when leaving off "auth" on either side - it will use AES-256-GCM anyway (negotiated) but then complain about config-mismatch...

@syzzer: do we know that cipher and auth have been NCP'ed when comparing OCC values? In that case we could just ignore "auth" and "cipher".

comment:2 Changed 4 years ago by IPTRACE

Ok. Warning occurrs only with IOS (client) not for Wiindows client with the same configuration.

By the way. What is the bit size of Authentication TAG implemented in OpenVPN for GCM?
I read the AES-256-GCM is faster than AES-256-CBC but is less secure and security depends of the bit size.

Last edited 4 years ago by IPTRACE (previous) (diff)

comment:3 Changed 4 years ago by Steffan Karger

Component: CryptoOpenVPN Connect
Milestone: release 2.4

Hm, this seems to be an implementation difference between the 2.x and 3.x code base (the iOS app uses the 3.x codebase). The 2.x codebase sets auth to 'none' when AEAD ciphers are used, because the auth is already provided by the cipher. 3.x apparently leaves the (unused) auth in its settings. I'd argue that the 2.x codebase does it right (auth isn't used here), but then again, I wrote that code ;)

As for the tag length, OpenVPN uses 128-bit GCM tags.

comment:4 Changed 4 years ago by Gert Döring

Not challenging the correctness of the code if both sides are configured for AES-256-GCM, but we still produce a warning if ciphers are negotiated and pushed (and the original config is different but effectively ignored)... getting rid of those in the 2.x code base would be a good thing.

comment:5 Changed 4 years ago by Steffan Karger

Yes, I agree that it would we good to remove some of the unnecessary warnings. This one is slightly tricky though, because it probably means rewriting the option string checking code :(

comment:6 Changed 15 months ago by mmokrejs


any chances this false alarm will be silenced? It complicates debugging of why openvpn connection is not established (if one just cannot trust the messages openvpn produces). Thank you. Am on dd-wrt r41786 with openvpn-2.4.8.

Note: See TracTickets for help on using tickets.