1SSL_CTX_DANE_ENABLE(3)              OpenSSL             SSL_CTX_DANE_ENABLE(3)
2
3
4

NAME

6       SSL_CTX_dane_enable, SSL_CTX_dane_mtype_set, SSL_dane_enable,
7       SSL_dane_tlsa_add, SSL_get0_dane_authority, SSL_get0_dane_tlsa,
8       SSL_CTX_dane_set_flags, SSL_CTX_dane_clear_flags, SSL_dane_set_flags,
9       SSL_dane_clear_flags - enable DANE TLS authentication of the remote TLS
10       server in the local TLS client
11

SYNOPSIS

13        #include <openssl/ssl.h>
14
15        int SSL_CTX_dane_enable(SSL_CTX *ctx);
16        int SSL_CTX_dane_mtype_set(SSL_CTX *ctx, const EVP_MD *md,
17                                   uint8_t mtype, uint8_t ord);
18        int SSL_dane_enable(SSL *s, const char *basedomain);
19        int SSL_dane_tlsa_add(SSL *s, uint8_t usage, uint8_t selector,
20                              uint8_t mtype, unsigned const char *data, size_t dlen);
21        int SSL_get0_dane_authority(SSL *s, X509 **mcert, EVP_PKEY **mspki);
22        int SSL_get0_dane_tlsa(SSL *s, uint8_t *usage, uint8_t *selector,
23                               uint8_t *mtype, unsigned const char **data,
24                               size_t *dlen);
25        unsigned long SSL_CTX_dane_set_flags(SSL_CTX *ctx, unsigned long flags);
26        unsigned long SSL_CTX_dane_clear_flags(SSL_CTX *ctx, unsigned long flags);
27        unsigned long SSL_dane_set_flags(SSL *ssl, unsigned long flags);
28        unsigned long SSL_dane_clear_flags(SSL *ssl, unsigned long flags);
29

DESCRIPTION

31       These functions implement support for DANE TLSA (RFC6698 and RFC7671)
32       peer authentication.
33
34       SSL_CTX_dane_enable() must be called first to initialize the shared
35       state required for DANE support.  Individual connections associated
36       with the context can then enable per-connection DANE support as
37       appropriate.  DANE authentication is implemented in the
38       X509_verify_cert(3) function, and applications that override
39       X509_verify_cert(3) via SSL_CTX_set_cert_verify_callback(3) are
40       responsible to authenticate the peer chain in whatever manner they see
41       fit.
42
43       SSL_CTX_dane_mtype_set() may then be called zero or more times to
44       adjust the supported digest algorithms.  This must be done before any
45       SSL handles are created for the context.
46
47       The mtype argument specifies a DANE TLSA matching type and the md
48       argument specifies the associated digest algorithm handle.  The ord
49       argument specifies a strength ordinal.  Algorithms with a larger
50       strength ordinal are considered more secure.  Strength ordinals are
51       used to implement RFC7671 digest algorithm agility.  Specifying a NULL
52       digest algorithm for a matching type disables support for that matching
53       type.  Matching type Full(0) cannot be modified or disabled.
54
55       By default, matching type "SHA2-256(1)" (see RFC7218 for definitions of
56       the DANE TLSA parameter acronyms) is mapped to "EVP_sha256()" with a
57       strength ordinal of 1 and matching type "SHA2-512(2)" is mapped to
58       "EVP_sha512()" with a strength ordinal of 2.
59
60       SSL_dane_enable() must be called before the SSL handshake is initiated
61       with SSL_connect(3) if (and only if) you want to enable DANE for that
62       connection.  (The connection must be associated with a DANE-enabled SSL
63       context).  The basedomain argument specifies the RFC7671 TLSA base
64       domain, which will be the primary peer reference identifier for
65       certificate name checks.  Additional server names can be specified via
66       SSL_add1_host(3).  The basedomain is used as the default SNI hint if
67       none has yet been specified via SSL_set_tlsext_host_name(3).
68
69       SSL_dane_tlsa_add() may then be called one or more times, to load each
70       of the TLSA records that apply to the remote TLS peer.  (This too must
71       be done prior to the beginning of the SSL handshake).  The arguments
72       specify the fields of the TLSA record.  The data field is provided in
73       binary (wire RDATA) form, not the hexadecimal ASCII presentation form,
74       with an explicit length passed via dlen.  The library takes a copy of
75       the data buffer contents and the caller may free the original data
76       buffer when convenient.  A return value of 0 indicates that "unusable"
77       TLSA records (with invalid or unsupported parameters) were provided.  A
78       negative return value indicates an internal error in processing the
79       record.
80
81       The caller is expected to check the return value of each
82       SSL_dane_tlsa_add() call and take appropriate action if none are usable
83       or an internal error is encountered in processing some records.
84
85       If no TLSA records are added successfully, DANE authentication is not
86       enabled, and authentication will be based on any configured traditional
87       trust-anchors; authentication success in this case does not mean that
88       the peer was DANE-authenticated.
89
90       SSL_get0_dane_authority() can be used to get more detailed information
91       about the matched DANE trust-anchor after successful connection
92       completion.  The return value is negative if DANE verification failed
93       (or was not enabled), 0 if an EE TLSA record directly matched the leaf
94       certificate, or a positive number indicating the depth at which a TA
95       record matched an issuer certificate.  The complete verified chain can
96       be retrieved via SSL_get0_verified_chain(3).  The return value is an
97       index into this verified chain, rather than the list of certificates
98       sent by the peer as returned by SSL_get_peer_cert_chain(3).
99
100       If the mcert argument is not NULL and a TLSA record matched a chain
101       certificate, a pointer to the matching certificate is returned via
102       mcert.  The returned address is a short-term internal reference to the
103       certificate and must not be freed by the application.  Applications
104       that want to retain access to the certificate can call X509_up_ref(3)
105       to obtain a long-term reference which must then be freed via
106       X509_free(3) once no longer needed.
107
108       If no TLSA records directly matched any elements of the certificate
109       chain, but a DANE-TA(2) SPKI(1) Full(0) record provided the public key
110       that signed an element of the chain, then that key is returned via
111       mspki argument (if not NULL).  In this case the return value is the
112       depth of the top-most element of the validated certificate chain.  As
113       with mcert this is a short-term internal reference, and
114       EVP_PKEY_up_ref(3) and EVP_PKEY_free(3) can be used to acquire and
115       release long-term references respectively.
116
117       SSL_get0_dane_tlsa() can be used to retrieve the fields of the TLSA
118       record that matched the peer certificate chain.  The return value
119       indicates the match depth or failure to match just as with
120       SSL_get0_dane_authority().  When the return value is non-negative, the
121       storage pointed to by the usage, selector, mtype and data parameters is
122       updated to the corresponding TLSA record fields.  The data field is in
123       binary wire form, and is therefore not NUL-terminated, its length is
124       returned via the dlen parameter.  If any of these parameters is NULL,
125       the corresponding field is not returned.  The data parameter is set to
126       a short-term internal-copy of the associated data field and must not be
127       freed by the application.  Applications that need long-term access to
128       this field need to copy the content.
129
130       SSL_CTX_dane_set_flags() and SSL_dane_set_flags() can be used to enable
131       optional DANE verification features.  SSL_CTX_dane_clear_flags() and
132       SSL_dane_clear_flags() can be used to disable the same features.  The
133       flags argument is a bitmask of the features to enable or disable.  The
134       flags set for an SSL_CTX context are copied to each SSL handle
135       associated with that context at the time the handle is created.
136       Subsequent changes in the context's flags have no effect on the flags
137       set for the handle.
138
139       At present, the only available option is
140       DANE_FLAG_NO_DANE_EE_NAMECHECKS which can be used to disable server
141       name checks when authenticating via DANE-EE(3) TLSA records.  For some
142       applications, primarily web browsers, it is not safe to disable name
143       checks due to "unknown key share" attacks, in which a malicious server
144       can convince a client that a connection to a victim server is instead a
145       secure connection to the malicious server.  The malicious server may
146       then be able to violate cross-origin scripting restrictions.  Thus,
147       despite the text of RFC7671, name checks are by default enabled for
148       DANE-EE(3) TLSA records, and can be disabled in applications where it
149       is safe to do so.  In particular, SMTP and XMPP clients should set this
150       option as SRV and MX records already make it possible for a remote
151       domain to redirect client connections to any server of its choice, and
152       in any case SMTP and XMPP clients do not execute scripts downloaded
153       from remote servers.
154

RETURN VALUES

156       The functions SSL_CTX_dane_enable(), SSL_CTX_dane_mtype_set(),
157       SSL_dane_enable() and SSL_dane_tlsa_add() return a positive value on
158       success.  Negative return values indicate resource problems (out of
159       memory, etc.) in the SSL library, while a return value of 0 indicates
160       incorrect usage or invalid input, such as an unsupported TLSA record
161       certificate usage, selector or matching type.  Invalid input also
162       includes malformed data, either a digest length that does not match the
163       digest algorithm, or a Full(0) (binary ASN.1 DER form) certificate or a
164       public key that fails to parse.
165
166       The functions SSL_get0_dane_authority() and SSL_get0_dane_tlsa() return
167       a negative value when DANE authentication failed or was not enabled, a
168       non-negative value indicates the chain depth at which the TLSA record
169       matched a chain certificate, or the depth of the top-most certificate,
170       when the TLSA record is a full public key that is its signer.
171
172       The functions SSL_CTX_dane_set_flags(), SSL_CTX_dane_clear_flags(),
173       SSL_dane_set_flags() and SSL_dane_clear_flags() return the flags in
174       effect before they were called.
175

EXAMPLE

177       Suppose "smtp.example.com" is the MX host of the domain "example.com",
178       and has DNSSEC-validated TLSA records.  The calls below will perform
179       DANE authentication and arrange to match either the MX hostname or the
180       destination domain name in the SMTP server certificate.  Wildcards are
181       supported, but must match the entire label.  The actual name matched in
182       the certificate (which might be a wildcard) is retrieved, and must be
183       copied by the application if it is to be retained beyond the lifetime
184       of the SSL connection.
185
186        SSL_CTX *ctx;
187        SSL *ssl;
188        int (*verify_cb)(int ok, X509_STORE_CTX *sctx) = NULL;
189        int num_usable = 0;
190        const char *nexthop_domain = "example.com";
191        const char *dane_tlsa_domain = "smtp.example.com";
192        uint8_t usage, selector, mtype;
193
194        if ((ctx = SSL_CTX_new(TLS_client_method())) == NULL)
195            /* error */
196        if (SSL_CTX_dane_enable(ctx) <= 0)
197            /* error */
198        if ((ssl = SSL_new(ctx)) == NULL)
199            /* error */
200        if (SSL_dane_enable(ssl, dane_tlsa_domain) <= 0)
201            /* error */
202
203        /*
204         * For many applications it is safe to skip DANE-EE(3) namechecks.  Do not
205         * disable the checks unless "unknown key share" attacks pose no risk for
206         * your application.
207         */
208        SSL_dane_set_flags(ssl, DANE_FLAG_NO_DANE_EE_NAMECHECKS);
209
210        if (!SSL_add1_host(ssl, nexthop_domain))
211            /* error */
212        SSL_set_hostflags(ssl, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
213
214        for (... each TLSA record ...) {
215            unsigned char *data;
216            size_t len;
217            int ret;
218
219            /* set usage, selector, mtype, data, len */
220
221            /*
222             * Opportunistic DANE TLS clients support only DANE-TA(2) or DANE-EE(3).
223             * They treat all other certificate usages, and in particular PKIX-TA(0)
224             * and PKIX-EE(1), as unusable.
225             */
226            switch (usage) {
227            default:
228            case 0:     /* PKIX-TA(0) */
229            case 1:     /* PKIX-EE(1) */
230                continue;
231            case 2:     /* DANE-TA(2) */
232            case 3:     /* DANE-EE(3) */
233                break;
234            }
235
236            ret = SSL_dane_tlsa_add(ssl, usage, selector, mtype, data, len);
237            /* free data as appropriate */
238
239            if (ret < 0)
240                /* handle SSL library internal error */
241            else if (ret == 0)
242                /* handle unusable TLSA record */
243            else
244                ++num_usable;
245        }
246
247        /*
248         * At this point, the verification mode is still the default SSL_VERIFY_NONE.
249         * Opportunistic DANE clients use unauthenticated TLS when all TLSA records
250         * are unusable, so continue the handshake even if authentication fails.
251         */
252        if (num_usable == 0) {
253            /* Log all records unusable? */
254
255            /* Optionally set verify_cb to a suitable non-NULL callback. */
256            SSL_set_verify(ssl, SSL_VERIFY_NONE, verify_cb);
257        } else {
258            /* At least one usable record.  We expect to verify the peer */
259
260            /* Optionally set verify_cb to a suitable non-NULL callback. */
261
262            /*
263             * Below we elect to fail the handshake when peer verification fails.
264             * Alternatively, use the permissive SSL_VERIFY_NONE verification mode,
265             * complete the handshake, check the verification status, and if not
266             * verified disconnect gracefully at the application layer, especially if
267             * application protocol supports informing the server that authentication
268             * failed.
269             */
270            SSL_set_verify(ssl, SSL_VERIFY_PEER, verify_cb);
271        }
272
273        /*
274         * Load any saved session for resumption, making sure that the previous
275         * session applied the same security and authentication requirements that
276         * would be expected of a fresh connection.
277         */
278
279        /* Perform SSL_connect() handshake and handle errors here */
280
281        if (SSL_session_reused(ssl)) {
282            if (SSL_get_verify_result(ssl) == X509_V_OK) {
283                /*
284                 * Resumed session was originally verified, this connection is
285                 * authenticated.
286                 */
287            } else {
288                /*
289                 * Resumed session was not originally verified, this connection is not
290                 * authenticated.
291                 */
292            }
293        } else if (SSL_get_verify_result(ssl) == X509_V_OK) {
294            const char *peername = SSL_get0_peername(ssl);
295            EVP_PKEY *mspki = NULL;
296
297            int depth = SSL_get0_dane_authority(ssl, NULL, &mspki);
298            if (depth >= 0) {
299                (void) SSL_get0_dane_tlsa(ssl, &usage, &selector, &mtype, NULL, NULL);
300                printf("DANE TLSA %d %d %d %s at depth %d\n", usage, selector, mtype,
301                       (mspki != NULL) ? "TA public key verified certificate" :
302                       depth ? "matched TA certificate" : "matched EE certificate",
303                       depth);
304            }
305            if (peername != NULL) {
306                /* Name checks were in scope and matched the peername */
307                printf("Verified peername: %s\n", peername);
308            }
309        } else {
310            /*
311             * Not authenticated, presumably all TLSA rrs unusable, but possibly a
312             * callback suppressed connection termination despite the presence of
313             * usable TLSA RRs none of which matched.  Do whatever is appropriate for
314             * fresh unauthenticated connections.
315             */
316        }
317

NOTES

319       It is expected that the majority of clients employing DANE TLS will be
320       doing "opportunistic DANE TLS" in the sense of RFC7672 and RFC7435.
321       That is, they will use DANE authentication when DNSSEC-validated TLSA
322       records are published for a given peer, and otherwise will use
323       unauthenticated TLS or even cleartext.
324
325       Such applications should generally treat any TLSA records published by
326       the peer with usages PKIX-TA(0) and PKIX-EE(1) as "unusable", and
327       should not include them among the TLSA records used to authenticate
328       peer connections.  In addition, some TLSA records with supported usages
329       may be "unusable" as a result of invalid or unsupported parameters.
330
331       When a peer has TLSA records, but none are "usable", an opportunistic
332       application must avoid cleartext, but cannot authenticate the peer, and
333       so should generally proceed with an unauthenticated connection.
334       Opportunistic applications need to note the return value of each call
335       to SSL_dane_tlsa_add(), and if all return 0 (due to invalid or
336       unsupported parameters) disable peer authentication by calling
337       SSL_set_verify(3) with mode equal to SSL_VERIFY_NONE.
338

SEE ALSO

340       SSL_new(3), SSL_add1_host(3), SSL_set_hostflags(3),
341       SSL_set_tlsext_host_name(3), SSL_set_verify(3),
342       SSL_CTX_set_cert_verify_callback(3), SSL_get0_verified_chain(3),
343       SSL_get_peer_cert_chain(3), SSL_get_verify_result(3), SSL_connect(3),
344       SSL_get0_peername(3), X509_verify_cert(3), X509_up_ref(3),
345       X509_free(3), EVP_get_digestbyname(3), EVP_PKEY_up_ref(3),
346       EVP_PKEY_free(3)
347

HISTORY

349       These functions were added in OpenSSL 1.1.0.
350
352       Copyright 2016-2018 The OpenSSL Project Authors. All Rights Reserved.
353
354       Licensed under the OpenSSL license (the "License").  You may not use
355       this file except in compliance with the License.  You can obtain a copy
356       in the file LICENSE in the source distribution or at
357       <https://www.openssl.org/source/license.html>.
358
359
360
3611.1.1c                            2019-05-28            SSL_CTX_DANE_ENABLE(3)
Impressum