Hi list,
as a follow-up to the discussion we had in the community meeting:
(13:38:08) dazo: janjust: if you get a chance to verify whether using
non-ncp-listed cipher works with ccd, that's a good detail to know
the answer is: yes and no ;)
Yes, it is possible to specify a *NEW* list of ncp ciphers in a CCD
file, overruling what is specified globally, provided that this same
"new" list of NCP ciphers is specified on the client side. This means
that the maximum *cipher* length is dependent on whatever is specified
in a CCD file. However, most ciphers used nowadays are 256 bits (32
bytes) in length anyways, so the impact on the maximum cipher length is
quite small.
No, it is NOT possible to specify a new "auth" parameter, e.g. "auth
sha512" as this would break many things, including tls-crypt. Thus,
there is no need to do a "worst case" calculation inside
"crypto_max_overhead()" to determine the biggest HMAC value possible.
Whatever is specified globally is as big as it will get.
My current conclusion is that the crypto_max_overhead function needs a
significant rewrite. The current code is:
755 size_t
756 crypto_max_overhead(void)
757 {
758 return packet_id_size(true) + OPENVPN_MAX_IV_LENGTH
759 +OPENVPN_MAX_CIPHER_BLOCK_SIZE
760 +max_int(OPENVPN_MAX_HMAC_SIZE, OPENVPN_AEAD_TAG_LENGTH);
761 }
Question: is the packet_id part of the crypto? or is packet_id used,
regardless of whether crypto is used at all? If so, then the
packet_id_size needs to be removed from this function.
I'd be in favor of updating the above code to
- take into account the space allocated for the default/globally
specified crypto; if the default/globally specified crypto is at the
maximum value (currently 256 bits) then don't bother calculating a worst
case value
- determine *at runtime* the worst case scenario for the crypto
overhead, possibly by checking if client-config-dir and/or
client-connect script or plugin is specified. If one of those IS
specified, then allocate more space, otherwise use the largest cipher
length from the first step.
- figure out whether the OPENVPN_MAX_IV_LENGTH is needed whenever an
AEAD cipher is used - in which case the overhead needs to be calculated
differently.
I hope others like syzzer can comment on my proposal :)
share and enjoy,
JJK
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
