Confirmed users
299
edits
Security/DNSSEC-TLS-details: Difference between revisions
add historical content notice
(add historical content notice) |
|||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
<p style="border: 2px solid red;"><b>This is historical content and has not been revised since it was written about Firefox Desktop in 2011.</b></p> | |||
Tracking bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=672239 672239] | Tracking bug: [https://bugzilla.mozilla.org/show_bug.cgi?id=672239 672239] | ||
| Line 6: | Line 8: | ||
=== Embedding Certificate Information in DNS === | === Embedding Certificate Information in DNS === | ||
[http://tools.ietf.org/html/draft-ietf-dane-protocol- | [http://tools.ietf.org/html/draft-ietf-dane-protocol-10 DANE], [http://tools.ietf.org/html/draft-hallambaker-donotissue-04 Certification Authority Authorization (CAA)], and [http://tools.ietf.org/html/rfc2538 CERT] records are all methods of embedding certificate information in DNS records. With DANE, either the public key or entire certificate (or the hash thereof) may be put in a TLSA record that specifies, for example, the certificate or public key to be used for connecting to example.com tcp port 443 (in the record _443._tcp.example.com). CAA uses the hash of the certificate and can specify that any certificate issued for (for example) example.com must be rooted by the hashed certificate. CAA uses TYPE257 records. CAA has other policy options, as well. CERT simply embeds a certificate in a DNS record. For the time being, while CAA is powerful, it has been determined to be too complicated for this use case. Furthermore, CERT can only specify whole certificates, not just public keys, and is thus too restrictive. Thus, DANE alone will initially be supported. | ||
=== Domain Validation === | === Domain Validation === | ||
To use DNSSEC to perform domain validation, a key or certificate must be put in a DANE record corresponding to the server to validate. Then, during the TLS handshake, the chain of DNSSEC records from that record to an agreed-upon root must be sent along with the server certificate. The client can walk this chain of records to a trusted root to validate the material. If this succeeds, the client then uses either the embedded key material or the key material in the server certificate (that | To use DNSSEC to perform domain validation, a key or certificate must be put in a DANE record corresponding to the server to validate. Then, during the TLS handshake, the chain of DNSSEC records from that record to an agreed-upon root must be sent along with the server certificate. The client can walk this chain of records to a trusted root to validate the material. If this succeeds, the client then uses either the embedded key material or the key material in the server certificate (that has just been validated by the DNSSEC chain) as the public key for a key exchange. Note that if the DANE record consists of an entire certificate and that certificate will always be sent in the TLS handshake, the DANE record itself may be omitted. In this case, the RRSIG record for the DANE record will have to be used to validate the certificate sent in TLS. | ||
Obviously this mechanism could work out of band. That is, instead of embedding the DNSSEC chain in the TLS handshake, the client could perform simultaneous DNSSEC lookups to verify the material in the server certificate. However, this would be significantly slower as it would involve multiple round-trip communications with another server. | Obviously this mechanism could work out of band. That is, instead of embedding the DNSSEC chain in the TLS handshake, the client could perform simultaneous DNSSEC lookups to verify the material in the server certificate. However, this would be significantly slower as it would involve multiple round-trip communications with another server. | ||
| Line 96: | Line 98: | ||
== Creating a TLSA Record == | == Creating a TLSA Record == | ||
Material embedded in a TLSA record must follow the [http://tools.ietf.org/html/draft-ietf-dane-protocol- | Material embedded in a TLSA record must follow the [http://tools.ietf.org/html/draft-ietf-dane-protocol-10 specification]. This involves making the decision of what to embed. The embedded material may be a certificate identifying an end entity (i.e. the server clients will connect to), a certification authority's certificate (where that certificate is a trust anchor for a certificate on the server), or a public key (which may correspond to either of the two situations). Then, the actual data embedded may be the full representation, a sha256 hash, or a sha512 hash. Different decisions may be appropriate for different situations. (This information is currently undergoing change - refer to the latest draft of the specification.) | ||
Once the certificate type and reference type are determined, the appropriate values can be used to construct an entry that goes into the zone file for the DNS server that is authoritative for the domain name in question. For instance, if the sha256 hash of a public key were to be used, the entry might look like this: | Once the certificate type and reference type are determined, the appropriate values can be used to construct an entry that goes into the zone file for the DNS server that is authoritative for the domain name in question. For instance, if the sha256 hash of a public key were to be used, the entry might look like this: | ||
| Line 130: | Line 132: | ||
== Test Plans == | == Test Plans == | ||
Current test plans | Current test plans include fuzzing the added attack surface (i.e. throwing data blobs at the validator) as well as deliberately crafted DNSSEC chains (e.g. ones with expired signatures, missing links, invalid links, etc.) Additionally, the library is being run through [http://klee.llvm.org/ KLEE] to check for memory safety errors. | ||
== nginx and openssl == | == nginx and openssl == | ||