[openssl-dev] SSL_CTX_add_cient_custom_ext() and known extensions

[David Woodhouse]

The documentation for SSL_CTX_add_client_custom_ext() states that "the
extension type must not be handled by OpenSSL internally or an error
occurs".

This isn't entirely true. In custom_ext_meth_add() we have this
comment:

    /*
     * Don't add if extension supported internally, but make exception
     * for extension types that previously were not supported, but now are.
     */

The code that follows this comment just has an explicit exception for
TLSEXT_TYPE_signed_certificate_timestamp, so an application is allowed
to register its own handler for that even when OpenSSL does support it.

(With another hard-coded check in SSL_CTX_add_client_custom_ext() so
that you can only do so if you either don't *enable* OpenSSL's own SCT
support.... or do so *after* registering your custom handler. The
latter probably isn't intentional.)

I'm interested in what interpretation exists of "extension types that
previously were not supported, but now are" that isn't a tautology.

But mostly I'd like to know how it would relate to the PSK identity
support in draft-jay-tls-psk-identity-extension¹.

I'd like to use that extension for OpenConnect VPN, but I'm concerned
that when the RFC is published and OpenSSL starts to support it, my
call to SSL_CTX_add_client_custom_ext() would suddenly start failing.

Would it?


-- 
dwmw2

¹ https://tools.ietf.org/html/draft-jay-tls-psk-identity-extension-01
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160919/6c391e33/attachment-0001.bin>