There are quite a few places in the current implementation where a nul
terminated string is generated from binary data. Add a helper function
to simplify the code a bit.
Signed-hostap: Jouni Malinen <j@w1.fi>
This phase1 parameter for TLS-based EAP methods was already supported
with GnuTLS and this commit extends that support for OpenSSL and the
internal TLS implementation.
There may be more than one attribute of same type (e.g., multiple DC
attributes), so the code needs to be able to handle that. Replace the
fixed structure with an array of attributes.
In addition, start ordering header file includes to be in more
consistent order: system header files, src/utils, src/*, same
directory as the *.c file.
These could, at least in theory, be used to generate unexpected common
name or subject alternative name matches should a CA sign strings with
NUL (C string termination) in them. For now, just reject the certificate
if an embedded NUL is detected. In theory, all the comparison routines
could be made to compare these strings as binary blobs (with additional
X.509 rules to handle some exceptions) and display NUL characters
somehow. Anyway, just rejecting the certificate will get rid of
potential problems with the C string getting terminated and it should
not really be used in certificates, so this should not break valid use
cases.
