Custom Query (2195 matches)

There are currently a lot of duplication in the SSL backend implementation, which causes major issues, maintenance difficulties, as well as unnecessary complexity when trying to add a new SSL backend.

The major issues are primarily due to revision differences (one backend (OpenSSL) gets updated/fixed a lot, while the other (GnuTLS) lags way behind). These create behavioral differences, where new features such as the new callback on_accept2() is only available for OpenSSL, and potential security problem, since bug fixes are only applied to one backend, while leaving the others exposed.

Thus refactoring is necessary, to make sure that shared codes are put in a separate file.

Zeroing our buffers should be sufficient as we cannot really manage the OpenSSL internal buffers. Moreover, it seems that OpenSSL already does wipe out its internal buffers, i.e: a lot of OpenSSL_cleanse() calls in OpenSSL source code, the function will fill a buffer with garbage or zero. But unfortunately cannot really find official docs about it.

Additionally, SSL socket pool content will be zeroed before released, it is done using a new API pj_pool_secure_release().

Thanks Peter Koletzki for the feedback.

Call stack trace:

1  pj_strstr (string.c:154)
2  get_cn_from_gen_name (ssl_sock_ossl.c:1390)
3  get_cert_info (ssl_sock_ossl.c:1455)
4  update_certs_info (ssl_sock_ossl.c:1564)
5  on_handshake_complete (ssl_sock_ossl.c:1590)

pj_strstr() does not expect NULL input string, which is what happens when subject/issuer line is empty.

Thanks Guy Mininberg for the report and the analysis.