Lines Matching refs:extension

12 - custom TLS extension handling
75 SSL_CTX_add_custom_ext() adds a custom extension for a TLS/DTLS client or server
76 for all supported protocol versions with extension type B<ext_type> and
79 which messages and under what conditions the extension will be added/parsed (see
82 SSL_CTX_add_client_custom_ext() adds a custom extension for a TLS/DTLS client
83 with extension type B<ext_type> and callbacks B<add_cb>, B<free_cb> and
91 SSL_CTX_add_server_custom_ext() adds a custom extension for a TLS/DTLS server
92 with extension type B<ext_type> and callbacks B<add_cb>, B<free_cb> and
98 RFC5246 et al. It is B<not> a NID. In all cases the extension type must not be
101 SSL_extension_supported() returns 1 if the extension B<ext_type> is handled
106 The callback B<add_cb> is called to send custom extension data to be
108 extension type which will be added and B<add_arg> to the value set when the
109 extension handler was added. When using the new style callbacks the B<context>
113 If the application wishes to include the extension B<ext_type> it should
114 set B<*out> to the extension data, set B<*outlen> to the length of the
115 extension data and return 1.
117 If the B<add_cb> does not wish to include the extension it must return 0.
123 extension is added for B<ext_type>. For all other messages if B<add_cb> is set
124 to NULL then no extension is added.
135 extension (as long as all requirements of the specified B<context> are met).
139 met and the corresponding extension was received in the ClientHello. That is, if
140 no corresponding extension was received in the ClientHello then B<add_cb> will
143 If an extension is added (that is B<add_cb> returns 1) B<free_cb> is called
145 used to free up any dynamic extension data set by B<add_cb>. Since B<out> is
150 called if the extension is present and relevant for the context (see
153 The extension data consists of B<inlen> bytes in the buffer B<in> for the
154 extension B<ext_type>.
163 If the B<parse_cb> considers the extension data acceptable it must return
172 An extension context defines which messages and under which conditions an
173 extension should be added or expected. The context is built up by performing
181 The extension is only allowed in TLS
185 The extension is only allowed in DTLS
189 The extension is allowed in DTLS, but there is only a TLS implementation
195 the extension in SSLv3. Applications will not typically need to use this.
199 The extension is only defined for TLSv1.2/DTLSv1.2 and below. Servers will
200 ignore this extension if it is present in the ClientHello and TLSv1.3 is
205 The extension is only defined for TLS1.3 and above. Servers will ignore this
206 extension if it is present in the ClientHello and TLSv1.2 or below is
211 The extension will be ignored during parsing if a previous session is being
216 The extension may be present in the ClientHello message.
220 The extension may be present in a TLSv1.2 or below compatible ServerHello
225 The extension may be present in a TLSv1.3 compatible ServerHello message.
229 The extension may be present in an EncryptedExtensions message.
233 The extension may be present in a HelloRetryRequest message.
237 The extension may be present in a TLSv1.3 compatible Certificate message.
241 The extension may be present in a TLSv1.3 compatible NewSessionTicket message.
245 The extension may be present in a TLSv1.3 compatible CertificateRequest message.
249 The context must include at least one message value (otherwise the extension
256 be used to store the extension data received in a convenient structure or
257 pass the extension data to be added or freed when adding extensions.
259 If the same custom extension type is received multiple times a fatal
260 B<decode_error> alert is sent and the handshake aborts. If a custom extension
264 only called if the corresponding extension was received in the ClientHello. This
274 once, if an attempt is made to use an extension type handled internally by
278 SSL_extension_supported() returns 1 if the extension B<ext_type> is handled