doc/ssl/SSL_CTX_dane_enable.pod

   1 =pod
   2
   3 =head1 NAME
   4
   5 SSL_CTX_dane_enable, SSL_CTX_dane_mtype_set, SSL_dane_enable,
   6 SSL_dane_tlsa_add, SSL_get0_dane_authority, SSL_get0_dane_tlsa -
   7 enable DANE TLS authentication of the remote TLS server in the local
   8 TLS client
   9
  10 =head1 SYNOPSIS
  11
  12  #include <openssl/ssl.h>
  13
  14  int SSL_CTX_dane_enable(SSL_CTX *ctx);
  15  int SSL_CTX_dane_mtype_set(SSL_CTX *ctx, const EVP_MD *md,
  16                             uint8_t mtype, uint8_t ord);
  17  int SSL_dane_enable(SSL *s, const char *basedomain);
  18  int SSL_dane_tlsa_add(SSL *s, uint8_t usage, uint8_t selector,
  19                        uint8_t mtype, unsigned char *data, size_t dlen);
  20  int SSL_get0_dane_authority(SSL *s, X509 **mcert, EVP_PKEY **mspki);
  21  int SSL_get0_dane_tlsa(SSL *s, uint8_t *usage, uint8_t *selector,
  22                         uint8_t *mtype, unsigned const char **data,
  23                         size_t *dlen);
  24
  25 =head1 DESCRIPTION
  26
  27 These functions implement support for DANE TLSA (RFC6698 and RFC7671)
  28 peer authentication.
  29
  30 SSL_CTX_dane_enable() must be called first to initialize the shared state
  31 required for DANE support.
  32 Individual connections associated with the context can then enable
  33 per-connection DANE support as appropriate.
  34 DANE authentication is implemented in the L<X509_verify_cert(3)> function, and
  35 applications that override L<X509_verify_cert(3)> via
  36 L<SSL_CTX_set_cert_verify_callback(3)> are responsible to authenticate the peer
  37 chain in whatever manner they see fit.
  38
  39 SSL_CTX_dane_mtype_set() may then be called zero or more times to to adjust the
  40 supported digest algorithms.
  41 This must be done before any SSL handles are created for the context.
  42
  43 The B<mtype> argument specifies a DANE TLSA matching type and the B<md>
  44 argument specifies the associated digest algorithm handle.
  45 The B<ord> argument specifies a strength ordinal.
  46 Algorithms with a larger strength ordinal are considered more secure.
  47 Strength ordinals are used to implement RFC7671 digest algorithm agility.
  48 Specifying a B<NULL> digest algorithm for a matching type disables
  49 support for that matching type.
  50 Matching type Full(0) cannot be modified or disabled.
  51
  52 By default, matching type C<SHA2-256(1)> (see RFC7218 for definitions
  53 of the DANE TLSA parameter acronyms) is mapped to C<EVP_sha256()>
  54 with a strength ordinal of C<1> and matching type C<SHA2-512(2)>
  55 is mapped to C<EVP_sha512()> with a strength ordinal of C<2>.
  56
  57 SSL_dane_enable() must be called before the SSL handshake is initiated with
  58 L<SSL_connect(3)> if (and only if) you want to enable DANE for that connection.
  59 (The connection must be associated with a DANE-enabled SSL context).
  60 The B<basedomain> argument specifies the RFC7671 TLSA base domain,
  61 which will be the primary peer reference identifier for certificate
  62 name checks.
  63 Additional server names can be specified via L<SSL_add1_host(3)>.
  64 The B<basedomain> is used as the default SNI hint if none has yet been
  65 specified via L<SSL_set_tlsext_host_name(3)>.
  66
  67 SSL_dane_tlsa_add() may then be called one or more times, to load each of the
  68 TLSA records that apply to the remote TLS peer.
  69 (This too must be done prior to the beginning of the SSL handshake).
  70 The arguments specify the fields of the TLSA record.
  71 The B<data> field is provided in binary (wire RDATA) form, not the hexadecimal
  72 ASCII presentation form, with an explicit length passed via B<dlen>.
  73 A return value of 0 indicates that "unusable" TLSA records (with invalid or
  74 unsupported parameters) were provided, a negative return value indicates an
  75 internal error in processing the records.
  76 If DANE authentication is enabled, but no TLSA records are added successfully,
  77 authentication will fail, and the handshake may not complete, depending on the
  78 B<mode> argument of L<SSL_set_verify(3)> and any verification callback.
  79
  80 SSL_get0_dane_authority() can be used to get more detailed information about
  81 the matched DANE trust-anchor after successful connection completion.
  82 The return value is negative if DANE verification failed (or was not enabled),
  83 0 if an EE TLSA record directly matched the leaf certificate, or a positive
  84 number indicating the depth at which a TA record matched an issuer certificate.
  85
  86 If the B<mcert> argument is not B<NULL> and a TLSA record matched a chain
  87 certificate, a pointer to the matching certificate is returned via B<mcert>.
  88 The returned address is a short-term internal reference to the certificate and
  89 must not be freed by the application.
  90 Applications that want to retain access to the certificate can call
  91 L<X509_up_ref(3)> to obtain a long-term reference which must then be freed via
  92 L<X509_free(3)> once no longer needed.
  93
  94 If no TLSA records directly matched any elements of the certificate chain, but
  95 a DANE-TA(2) SPKI(1) Full(0) record provided the public key that signed an
  96 element of the chain, then that key is returned via B<mspki> argument (if not
  97 NULL).
  98 In this case the return value is the depth of the top-most element of the
  99 validated certificate chain.
 100 As with B<mcert> this is a short-term internal reference, and
 101 L<EVP_PKEY_up_ref(3)> and L<EVP_PKEY_free(3)> can be used to acquire and
 102 release long-term references respectively.
 103
 104 SSL_get0_dane_tlsa() can be used to retrieve the fields of the TLSA record that
 105 matched the peer certificate chain.
 106 The return value indicates the match depth or failure to match just as with
 107 SSL_get0_dane_authority().
 108 When the return value is non-negative, the storage pointed to by the B<usage>,
 109 B<selector>, B<mtype> and B<data> parameters is updated to the corresponding
 110 TLSA record fields.
 111 The B<data> field is in binary wire form, and is therefore not NUL-terminated,
 112 its length is returned via the B<dlen> parameter.
 113 If any of these parameters is NULL, the corresponding field is not returned.
 114 The B<data> parameter is set to a short-term internal-copy of the associated
 115 data field and must not be freed by the application.
 116 Applications that need long-term access to this field need to copy the content.
 117
 118 =head1 RETURN VALUES
 119
 120 The functions SSL_CTX_dane_enable(), SSL_CTX_dane_mtype_set(),
 121 SSL_dane_enable() and SSL_dane_tlsa_add() return a positive value on success.
 122 Negative return values indicate resource problems (out of memory, etc.) in the
 123 SSL library, while a return value of B<0> indicates incorrect usage or invalid
 124 input, such as an unsupported TLSA record certificate usage, selector or
 125 matching type.
 126 Invalid input also includes malformed data, either a digest length that does
 127 not match the digest algorithm, or a C<Full(0)> (binary ASN.1 DER form)
 128 certificate or a public key that fails to parse.
 129
 130 The functions SSL_get0_dane_authority() and SSL_get0_dane_tlsa() return a
 131 negative value when DANE authentication failed or was not enabled, a
 132 non-negative value indicates the chain depth at which the TLSA record matched a
 133 chain certificate, or the depth of the top-most certificate, when the TLSA
 134 record is a full public key that is its signer.
 135
 136 =head1 EXAMPLE
 137
 138 Suppose "smtp.example.com" is the MX host of the domain "example.com", and has
 139 DNSSEC-validated TLSA records.
 140 The calls below will perform DANE authentication and arrange to match either
 141 the MX hostname or the destination domain name in the SMTP server certificate.
 142 Wildcards are supported, but must match the entire label.
 143 The actual name matched in the certificate (which might be a wildcard) is
 144 retrieved, and must be copied by the application if it is to be retained beyond
 145 the lifetime of the SSL connection.
 146
 147   SSL_CTX *ctx;
 148   SSL *ssl;
 149   int num_usable = 0;
 150   const char *nexthop_domain = "example.com";
 151   const char *dane_tlsa_domain = "smtp.example.com";
 152   uint8_t usage, selector, mtype;
 153
 154   if ((ctx = SSL_CTX_new(TLS_client_method())) == NULL)
 155     /* handle error */
 156   if (SSL_CTX_dane_enable(ctx) <= 0)
 157     /* handle error */
 158
 159   if ((ssl = SSL_new(ctx)) == NULL)
 160     /* handle error */
 161
 162   if (SSL_dane_enable(ssl, dane_tlsa_domain) <= 0)
 163     /* handle error */
 164   if (!SSL_add1_host(ssl, nexthop_domain))
 165     /* handle error */
 166   SSL_set_hostflags(ssl, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
 167
 168   for (... each TLSA record ...) {
 169     unsigned char *data;
 170     size_t len;
 171     int ret;
 172
 173     /* set usage, selector, mtype, data, len */
 174
 175     /* Opportunistic DANE TLS clients treat usages 0, 1 as unusable. */
 176     switch (usage) {
 177     case 0:     /* PKIX-TA(0) */
 178     case 1:     /* PKIX-EE(1) */
 179         continue;
 180     }
 181
 182     ret = SSL_dane_tlsa_add(ssl, usage, selector, mtype, data, len);
 183     /* free data as appropriate */
 184
 185     if (ret < 0)
 186         /* handle SSL library internal error */
 187     else if (ret == 0)
 188         /* handle unusable TLSA record */
 189     else
 190       ++num_usable;
 191   }
 192
 193   /*
 194    * Opportunistic DANE clients use unauthenticated TLS when all TLSA records
 195    * are unusable, so continue the handshake even if authentication fails.
 196    */
 197   if (num_usable == 0) {
 198     int (*cb)(int ok, X509_STORE_CTX *sctx) = NULL;
 199
 200     /* Log all records unusable? */
 201     /* Set cb to a non-NULL callback of your choice? */
 202
 203     SSL_set_verify(ssl, SSL_VERIFY_NONE, cb);
 204   }
 205
 206   /* Perform SSL_connect() handshake and handle errors here */
 207
 208   if (SSL_get_verify_result(ssl) == X509_V_OK) {
 209     const char *peername = SSL_get0_peername(ssl);
 210     EVP_PKEY *mspki = NULL;
 211
 212     int depth = SSL_get0_dane_authority(ssl, NULL, &mspki);
 213     if (depth >= 0) {
 214         (void) SSL_get0_dane_tlsa(ssl, &usage, &selector, &mtype, NULL, NULL);
 215         printf("DANE TLSA %d %d %d %s at depth %d\n", usage, selector, mtype,
 216                (mspki != NULL) ? "TA public key verified certificate" :
 217                depth ? "matched TA certificate" : "matched EE certificate",
 218                depth);
 219     }
 220     if (peername != NULL) {
 221       /* Name checks were in scope and matched the peername */
 222       printf(bio, "Verified peername: %s\n", peername);
 223     }
 224   } else {
 225     /*
 226      * Not authenticated, presumably all TLSA rrs unusable, but possibly a
 227      * callback suppressed connection termination despite presence of TLSA
 228      * usable RRs none of which matched.  Do whatever is appropriate for
 229      * unauthenticated connections.
 230      */
 231   }
 232
 233 =head1 NOTES
 234
 235 It is expected that the majority of clients employing DANE TLS will be doing
 236 "opportunistic DANE TLS" in the sense of RFC7672 and RFC7435.
 237 That is, they will use DANE authentication when DNSSEC-validated TLSA records
 238 are published for a given peer, and otherwise will use unauthenticated TLS or
 239 even cleartext.
 240
 241 Such applications should generally treat any TLSA records published by the peer
 242 with usages PKIX-TA(0) and PKIX-EE(1) as "unusable", and should not include
 243 them among the TLSA records used to authenticate peer connections.
 244 In addition, some TLSA records with supported usages may be "unusable" as a
 245 result of invalid or unsupported parameters.
 246
 247 When a peer has TLSA records, but none are "usable",  an opportunistic
 248 application must avoid cleartext, but cannot authenticate the peer,
 249 and so should generally proceed with an unauthenticated connection.
 250 Opportunistic applications need to note the return value of each
 251 call to SSL_dane_tlsa_add(), and if all return 0 (due to invalid
 252 or unsupported parameters) disable peer authentication by calling
 253 L<SSL_set_verify(3)> with B<mode> equal to B<SSL_VERIFY_NONE>.
 254
 255 =head1 SEE ALSO
 256
 257 L<SSL_new(3)>,
 258 L<SSL_add1_host(3)>,
 259 L<SSL_set_hostflags(3)>,
 260 L<SSL_set_tlsext_host_name(3)>,
 261 L<SSL_set_verify(3)>,
 262 L<SSL_CTX_set_cert_verify_callback(3)>,
 263 L<X509_verify_cert(3)>,
 264 L<SSL_connect(3)>,
 265 L<SSL_get0_peername(3)>,
 266 L<EVP_get_digestbyname(3)>,
 267 L<X509_up_ref(3)>,
 268 L<X509_free(3)>,
 269 L<EVP_PKEY_up_ref(3)>,
 270 L<EVP_PKEY_free(3)>
 271
 272 =head1 HISTORY
 273
 274 These functions were first added to OpenSSL 1.1.0.
 275
 276 =cut