xref: /openssl/doc/man3/SSL_CTX_dane_enable.pod (revision da1c088f)
1=pod
2
3=head1 NAME
4
5SSL_CTX_dane_enable, SSL_CTX_dane_mtype_set, SSL_dane_enable,
6SSL_dane_tlsa_add, SSL_get0_dane_authority, SSL_get0_dane_tlsa,
7SSL_CTX_dane_set_flags, SSL_CTX_dane_clear_flags,
8SSL_dane_set_flags, SSL_dane_clear_flags
9- enable DANE TLS authentication of the remote TLS server in the local
10TLS client
11
12=head1 SYNOPSIS
13
14 #include <openssl/ssl.h>
15
16 int SSL_CTX_dane_enable(SSL_CTX *ctx);
17 int SSL_CTX_dane_mtype_set(SSL_CTX *ctx, const EVP_MD *md,
18                            uint8_t mtype, uint8_t ord);
19 int SSL_dane_enable(SSL *s, const char *basedomain);
20 int SSL_dane_tlsa_add(SSL *s, uint8_t usage, uint8_t selector,
21                       uint8_t mtype, const unsigned char *data, size_t dlen);
22 int SSL_get0_dane_authority(SSL *s, X509 **mcert, EVP_PKEY **mspki);
23 int SSL_get0_dane_tlsa(SSL *s, uint8_t *usage, uint8_t *selector,
24                        uint8_t *mtype, const unsigned char **data,
25                        size_t *dlen);
26 unsigned long SSL_CTX_dane_set_flags(SSL_CTX *ctx, unsigned long flags);
27 unsigned long SSL_CTX_dane_clear_flags(SSL_CTX *ctx, unsigned long flags);
28 unsigned long SSL_dane_set_flags(SSL *ssl, unsigned long flags);
29 unsigned long SSL_dane_clear_flags(SSL *ssl, unsigned long flags);
30
31=head1 DESCRIPTION
32
33These functions implement support for DANE TLSA (RFC6698 and RFC7671)
34peer authentication.
35
36SSL_CTX_dane_enable() must be called first to initialize the shared state
37required for DANE support.
38Individual connections associated with the context can then enable
39per-connection DANE support as appropriate.
40DANE authentication is implemented in the L<X509_verify_cert(3)> function, and
41applications that override L<X509_verify_cert(3)> via
42L<SSL_CTX_set_cert_verify_callback(3)> are responsible to authenticate the peer
43chain in whatever manner they see fit.
44
45SSL_CTX_dane_mtype_set() may then be called zero or more times to adjust the
46supported digest algorithms.
47This must be done before any SSL handles are created for the context.
48
49The B<mtype> argument specifies a DANE TLSA matching type and the B<md>
50argument specifies the associated digest algorithm handle.
51The B<ord> argument specifies a strength ordinal.
52Algorithms with a larger strength ordinal are considered more secure.
53Strength ordinals are used to implement RFC7671 digest algorithm agility.
54Specifying a B<NULL> digest algorithm for a matching type disables
55support for that matching type.
56Matching type Full(0) cannot be modified or disabled.
57
58By default, matching type C<SHA2-256(1)> (see RFC7218 for definitions
59of the DANE TLSA parameter acronyms) is mapped to C<EVP_sha256()>
60with a strength ordinal of C<1> and matching type C<SHA2-512(2)>
61is mapped to C<EVP_sha512()> with a strength ordinal of C<2>.
62
63SSL_dane_enable() must be called before the SSL handshake is initiated with
64L<SSL_connect(3)> if (and only if) you want to enable DANE for that connection.
65(The connection must be associated with a DANE-enabled SSL context).
66The B<basedomain> argument specifies the RFC7671 TLSA base domain,
67which will be the primary peer reference identifier for certificate
68name checks.
69Additional server names can be specified via L<SSL_add1_host(3)>.
70The B<basedomain> is used as the default SNI hint if none has yet been
71specified via L<SSL_set_tlsext_host_name(3)>.
72
73SSL_dane_tlsa_add() may then be called one or more times, to load each of the
74TLSA records that apply to the remote TLS peer.
75(This too must be done prior to the beginning of the SSL handshake).
76The arguments specify the fields of the TLSA record.
77The B<data> field is provided in binary (wire RDATA) form, not the hexadecimal
78ASCII presentation form, with an explicit length passed via B<dlen>.
79The library takes a copy of the B<data> buffer contents and the caller may
80free the original B<data> buffer when convenient.
81A return value of 0 indicates that "unusable" TLSA records (with invalid or
82unsupported parameters) were provided.
83A negative return value indicates an internal error in processing the record.
84
85The caller is expected to check the return value of each SSL_dane_tlsa_add()
86call and take appropriate action if none are usable or an internal error
87is encountered in processing some records.
88
89If no TLSA records are added successfully, DANE authentication is not enabled,
90and authentication will be based on any configured traditional trust-anchors;
91authentication success in this case does not mean that the peer was
92DANE-authenticated.
93
94SSL_get0_dane_authority() can be used to get more detailed information about
95the matched DANE trust-anchor after successful connection completion.
96The return value is negative if DANE verification failed (or was not enabled),
970 if an EE TLSA record directly matched the leaf certificate, or a positive
98number indicating the depth at which a TA record matched an issuer certificate.
99The complete verified chain can be retrieved via L<SSL_get0_verified_chain(3)>.
100The return value is an index into this verified chain, rather than the list of
101certificates sent by the peer as returned by L<SSL_get_peer_cert_chain(3)>.
102
103If the B<mcert> argument is not B<NULL> and a TLSA record matched a chain
104certificate, a pointer to the matching certificate is returned via B<mcert>.
105The returned address is a short-term internal reference to the certificate and
106must not be freed by the application.
107Applications that want to retain access to the certificate can call
108L<X509_up_ref(3)> to obtain a long-term reference which must then be freed via
109L<X509_free(3)> once no longer needed.
110
111If no TLSA records directly matched any elements of the certificate chain, but
112a DANE-TA(2) SPKI(1) Full(0) record provided the public key that signed an
113element of the chain, then that key is returned via B<mspki> argument (if not
114NULL).
115In this case the return value is the depth of the top-most element of the
116validated certificate chain.
117As with B<mcert> this is a short-term internal reference, and
118L<EVP_PKEY_up_ref(3)> and L<EVP_PKEY_free(3)> can be used to acquire and
119release long-term references respectively.
120
121SSL_get0_dane_tlsa() can be used to retrieve the fields of the TLSA record that
122matched the peer certificate chain.
123The return value indicates the match depth or failure to match just as with
124SSL_get0_dane_authority().
125When the return value is nonnegative, the storage pointed to by the B<usage>,
126B<selector>, B<mtype> and B<data> parameters is updated to the corresponding
127TLSA record fields.
128The B<data> field is in binary wire form, and is therefore not NUL-terminated,
129its length is returned via the B<dlen> parameter.
130If any of these parameters is NULL, the corresponding field is not returned.
131The B<data> parameter is set to a short-term internal-copy of the associated
132data field and must not be freed by the application.
133Applications that need long-term access to this field need to copy the content.
134
135SSL_CTX_dane_set_flags() and SSL_dane_set_flags() can be used to enable
136optional DANE verification features.
137SSL_CTX_dane_clear_flags() and SSL_dane_clear_flags() can be used to disable
138the same features.
139The B<flags> argument is a bit-mask of the features to enable or disable.
140The B<flags> set for an B<SSL_CTX> context are copied to each B<SSL> handle
141associated with that context at the time the handle is created.
142Subsequent changes in the context's B<flags> have no effect on the B<flags> set
143for the handle.
144
145At present, the only available option is B<DANE_FLAG_NO_DANE_EE_NAMECHECKS>
146which can be used to disable server name checks when authenticating via
147DANE-EE(3) TLSA records.
148For some applications, primarily web browsers, it is not safe to disable name
149checks due to "unknown key share" attacks, in which a malicious server can
150convince a client that a connection to a victim server is instead a secure
151connection to the malicious server.
152The malicious server may then be able to violate cross-origin scripting
153restrictions.
154Thus, despite the text of RFC7671, name checks are by default enabled for
155DANE-EE(3) TLSA records, and can be disabled in applications where it is safe
156to do so.
157In particular, SMTP and XMPP clients should set this option as SRV and MX
158records already make it possible for a remote domain to redirect client
159connections to any server of its choice, and in any case SMTP and XMPP clients
160do not execute scripts downloaded from remote servers.
161
162=head1 RETURN VALUES
163
164The functions SSL_CTX_dane_enable(), SSL_CTX_dane_mtype_set(),
165SSL_dane_enable() and SSL_dane_tlsa_add() return a positive value on success.
166Negative return values indicate resource problems (out of memory, etc.) in the
167SSL library, while a return value of B<0> indicates incorrect usage or invalid
168input, such as an unsupported TLSA record certificate usage, selector or
169matching type.
170Invalid input also includes malformed data, either a digest length that does
171not match the digest algorithm, or a C<Full(0)> (binary ASN.1 DER form)
172certificate or a public key that fails to parse.
173
174The functions SSL_get0_dane_authority() and SSL_get0_dane_tlsa() return a
175negative value when DANE authentication failed or was not enabled, a
176nonnegative value indicates the chain depth at which the TLSA record matched a
177chain certificate, or the depth of the top-most certificate, when the TLSA
178record is a full public key that is its signer.
179
180The functions SSL_CTX_dane_set_flags(), SSL_CTX_dane_clear_flags(),
181SSL_dane_set_flags() and SSL_dane_clear_flags() return the B<flags> in effect
182before they were called.
183
184=head1 EXAMPLES
185
186Suppose "smtp.example.com" is the MX host of the domain "example.com", and has
187DNSSEC-validated TLSA records.
188The calls below will perform DANE authentication and arrange to match either
189the MX hostname or the destination domain name in the SMTP server certificate.
190Wildcards are supported, but must match the entire label.
191The actual name matched in the certificate (which might be a wildcard) is
192retrieved, and must be copied by the application if it is to be retained beyond
193the lifetime of the SSL connection.
194
195 SSL_CTX *ctx;
196 SSL *ssl;
197 int (*verify_cb)(int ok, X509_STORE_CTX *sctx) = NULL;
198 int num_usable = 0;
199 const char *nexthop_domain = "example.com";
200 const char *dane_tlsa_domain = "smtp.example.com";
201 uint8_t usage, selector, mtype;
202
203 if ((ctx = SSL_CTX_new(TLS_client_method())) == NULL)
204     /* error */
205 if (SSL_CTX_dane_enable(ctx) <= 0)
206     /* error */
207 if ((ssl = SSL_new(ctx)) == NULL)
208     /* error */
209 if (SSL_dane_enable(ssl, dane_tlsa_domain) <= 0)
210     /* error */
211
212 /*
213  * For many applications it is safe to skip DANE-EE(3) namechecks.  Do not
214  * disable the checks unless "unknown key share" attacks pose no risk for
215  * your application.
216  */
217 SSL_dane_set_flags(ssl, DANE_FLAG_NO_DANE_EE_NAMECHECKS);
218
219 if (!SSL_add1_host(ssl, nexthop_domain))
220     /* error */
221 SSL_set_hostflags(ssl, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
222
223 for (... each TLSA record ...) {
224     unsigned char *data;
225     size_t len;
226     int ret;
227
228     /* set usage, selector, mtype, data, len */
229
230     /*
231      * Opportunistic DANE TLS clients support only DANE-TA(2) or DANE-EE(3).
232      * They treat all other certificate usages, and in particular PKIX-TA(0)
233      * and PKIX-EE(1), as unusable.
234      */
235     switch (usage) {
236     default:
237     case 0:     /* PKIX-TA(0) */
238     case 1:     /* PKIX-EE(1) */
239         continue;
240     case 2:     /* DANE-TA(2) */
241     case 3:     /* DANE-EE(3) */
242         break;
243     }
244
245     ret = SSL_dane_tlsa_add(ssl, usage, selector, mtype, data, len);
246     /* free data as appropriate */
247
248     if (ret < 0)
249         /* handle SSL library internal error */
250     else if (ret == 0)
251         /* handle unusable TLSA record */
252     else
253         ++num_usable;
254 }
255
256 /*
257  * At this point, the verification mode is still the default SSL_VERIFY_NONE.
258  * Opportunistic DANE clients use unauthenticated TLS when all TLSA records
259  * are unusable, so continue the handshake even if authentication fails.
260  */
261 if (num_usable == 0) {
262     /* Log all records unusable? */
263
264     /* Optionally set verify_cb to a suitable non-NULL callback. */
265     SSL_set_verify(ssl, SSL_VERIFY_NONE, verify_cb);
266 } else {
267     /* At least one usable record.  We expect to verify the peer */
268
269     /* Optionally set verify_cb to a suitable non-NULL callback. */
270
271     /*
272      * Below we elect to fail the handshake when peer verification fails.
273      * Alternatively, use the permissive SSL_VERIFY_NONE verification mode,
274      * complete the handshake, check the verification status, and if not
275      * verified disconnect gracefully at the application layer, especially if
276      * application protocol supports informing the server that authentication
277      * failed.
278      */
279     SSL_set_verify(ssl, SSL_VERIFY_PEER, verify_cb);
280 }
281
282 /*
283  * Load any saved session for resumption, making sure that the previous
284  * session applied the same security and authentication requirements that
285  * would be expected of a fresh connection.
286  */
287
288 /* Perform SSL_connect() handshake and handle errors here */
289
290 if (SSL_session_reused(ssl)) {
291     if (SSL_get_verify_result(ssl) == X509_V_OK) {
292         /*
293          * Resumed session was originally verified, this connection is
294          * authenticated.
295          */
296     } else {
297         /*
298          * Resumed session was not originally verified, this connection is not
299          * authenticated.
300          */
301     }
302 } else if (SSL_get_verify_result(ssl) == X509_V_OK) {
303     const char *peername = SSL_get0_peername(ssl);
304     EVP_PKEY *mspki = NULL;
305
306     int depth = SSL_get0_dane_authority(ssl, NULL, &mspki);
307     if (depth >= 0) {
308         (void) SSL_get0_dane_tlsa(ssl, &usage, &selector, &mtype, NULL, NULL);
309         printf("DANE TLSA %d %d %d ", usage, selector, mtype);
310         if (SSL_get0_peer_rpk(ssl) == NULL)
311             printf("%s certificate at depth %d\n",
312                    (mspki != NULL) ? "signed the peer" :
313                    mdpth ? "matched the TA" : "matched the EE", mdpth);
314         else
315             printf(bio, "matched the peer raw public key\n");
316     }
317     if (peername != NULL) {
318         /* Name checks were in scope and matched the peername */
319         printf("Verified peername: %s\n", peername);
320     }
321 } else {
322     /*
323      * Not authenticated, presumably all TLSA rrs unusable, but possibly a
324      * callback suppressed connection termination despite the presence of
325      * usable TLSA RRs none of which matched.  Do whatever is appropriate for
326      * fresh unauthenticated connections.
327      */
328 }
329
330=head1 NOTES
331
332It is expected that the majority of clients employing DANE TLS will be doing
333"opportunistic DANE TLS" in the sense of RFC7672 and RFC7435.
334That is, they will use DANE authentication when DNSSEC-validated TLSA records
335are published for a given peer, and otherwise will use unauthenticated TLS or
336even cleartext.
337
338Such applications should generally treat any TLSA records published by the peer
339with usages PKIX-TA(0) and PKIX-EE(1) as "unusable", and should not include
340them among the TLSA records used to authenticate peer connections.
341In addition, some TLSA records with supported usages may be "unusable" as a
342result of invalid or unsupported parameters.
343
344When a peer has TLSA records, but none are "usable", an opportunistic
345application must avoid cleartext, but cannot authenticate the peer,
346and so should generally proceed with an unauthenticated connection.
347Opportunistic applications need to note the return value of each
348call to SSL_dane_tlsa_add(), and if all return 0 (due to invalid
349or unsupported parameters) disable peer authentication by calling
350L<SSL_set_verify(3)> with B<mode> equal to B<SSL_VERIFY_NONE>.
351
352=head1 SEE ALSO
353
354L<ssl(7)>,
355L<SSL_new(3)>,
356L<SSL_add1_host(3)>,
357L<SSL_set_hostflags(3)>,
358L<SSL_set_tlsext_host_name(3)>,
359L<SSL_set_verify(3)>,
360L<SSL_CTX_set_cert_verify_callback(3)>,
361L<SSL_get0_verified_chain(3)>,
362L<SSL_get_peer_cert_chain(3)>,
363L<SSL_get_verify_result(3)>,
364L<SSL_connect(3)>,
365L<SSL_get0_peername(3)>,
366L<X509_verify_cert(3)>,
367L<X509_up_ref(3)>,
368L<X509_free(3)>,
369L<EVP_get_digestbyname(3)>,
370L<EVP_PKEY_up_ref(3)>,
371L<EVP_PKEY_free(3)>
372
373=head1 HISTORY
374
375These functions were added in OpenSSL 1.1.0.
376
377=head1 COPYRIGHT
378
379Copyright 2016-2023 The OpenSSL Project Authors. All Rights Reserved.
380
381Licensed under the Apache License 2.0 (the "License").  You may not use
382this file except in compliance with the License.  You can obtain a copy
383in the file LICENSE in the source distribution or at
384L<https://www.openssl.org/source/license.html>.
385
386=cut
387