There is an opinion: the DANE technology for browsers failed
We are talking about what DANE technology is for authenticating domain names by DNS and why it is not widely used in browsers.
/ Unsplash / Paulius Dragunas
Certification Centers (CA) are organizations that authenticate cryptographic SSL certificates . They put their electronic signature on them, confirming the authenticity. However, sometimes there are situations when certificates are issued with violations. For example, last year, Google initiated a “procedure for terminating confidence” in Symantec certificates because of their compromise (we covered this story in detail in our blog - once and twice ).
')
To avoid such situations, a few years ago, the IETF began to develop the DANE technology (but it was not widely used in browsers - why it happened, let's talk further).
DANE (DNS-based Authentication of Named Entities) is a set of specifications that allows DNSSEC (Name System Security Extensions) to be used to control the validity of SSL certificates. DNSSEC is an extension to the domain name system that minimizes attacks related to address spoofing. Using these two technologies, the webmaster or client can contact one of the DNS zone operators and confirm the validity of the certificate used.
In essence, DANE acts as a self-signed certificate (DNSSEC is a guarantor of its reliability) and complements the functions of CA.
The DANE specification is described in RFC6698 . According to the document, a new type has been added to the DNS resource records - TLSA. It contains information about the certificate to be transferred, the size and type of the transmitted data, as well as the data itself. The webmaster creates a digital thumbprint of the certificate, signs it with DNSSEC, and places it in the TLSA.
The DANE wiki page shows the following example DNS request to the example.org server on TCP port 443:
The answer to it is:
DANE has several extensions that work with other DNS records besides TLSA. The first is the DNS record SSHFP for checking keys for SSH connections. It is described in RFC4255 , RFC6594, and RFC7479 . The second is the OPENPGPKEY entry for key exchange using PGP ( RFC7929 ). Finally, the third is the SMIMEA record (the standard is not defined in the RFC, there is only its draft ) for cryptographic key exchange via S / MIME.
In mid-May, a DNS-OARC conference was held (this is a non-profit organization that deals with security, stability and development of the domain name system). On one of the panels, the experts concluded that the DANE technology in browsers failed (at least in the current implementation version). Geoff Huston, a leading researcher at APNIC , one of five regional Internet registrars, who was present at the conference, spoke of DANE as a “dead technology”.
Problems with the spread of DANE in browsers are associated with the duration of the DNSSEC validation process. The system is forced to perform cryptographic calculations to verify the authenticity of the SSL certificate and pass through the entire chain of DNS servers (from the root zone to the host domain) when it is first connected to the resource.
/ Unsplash / Kaley Dykstra
This defect was attempted to be eliminated in Mozilla using the DNSSEC Chain Extension for TLS mechanism. He had to reduce the number of DNS records that the client had to view during authentication. However, within the development team there were disagreements that could not be resolved. As a result, the project was abandoned, although it was approved by the IETF in March 2018.
Another reason for the low popularity of DANE is the low prevalence of DNSSEC in the world - only 19% of resources work with it . Experts felt that this was not enough to actively promote DANE.
Most likely, the industry will develop in a different direction. Instead of using DNS to verify SSL / TLS certificates, market players, on the contrary, will promote DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) protocols. We mentioned the latter in one of our previous materials on Habré. They encrypt and verify user requests to the DNS server, preventing attackers from spoofing data. Earlier this year, DoT has already been implemented in Google for its Public DNS. As for DANE, whether the technology will succeed in “returning to the saddle” and yet become mass, will be seen in the future.
/ Unsplash / Paulius Dragunas
What is DANE
Certification Centers (CA) are organizations that authenticate cryptographic SSL certificates . They put their electronic signature on them, confirming the authenticity. However, sometimes there are situations when certificates are issued with violations. For example, last year, Google initiated a “procedure for terminating confidence” in Symantec certificates because of their compromise (we covered this story in detail in our blog - once and twice ).
')
To avoid such situations, a few years ago, the IETF began to develop the DANE technology (but it was not widely used in browsers - why it happened, let's talk further).
DANE (DNS-based Authentication of Named Entities) is a set of specifications that allows DNSSEC (Name System Security Extensions) to be used to control the validity of SSL certificates. DNSSEC is an extension to the domain name system that minimizes attacks related to address spoofing. Using these two technologies, the webmaster or client can contact one of the DNS zone operators and confirm the validity of the certificate used.
In essence, DANE acts as a self-signed certificate (DNSSEC is a guarantor of its reliability) and complements the functions of CA.
How it works
The DANE specification is described in RFC6698 . According to the document, a new type has been added to the DNS resource records - TLSA. It contains information about the certificate to be transferred, the size and type of the transmitted data, as well as the data itself. The webmaster creates a digital thumbprint of the certificate, signs it with DNSSEC, and places it in the TLSA.
A client connects to a website on the Internet and compares his certificate with a “copy” received from a DNS operator. If they match, the resource is considered trusted.
The DANE wiki page shows the following example DNS request to the example.org server on TCP port 443:
IN TLSA _443._tcp.example.org The answer to it is:
_443._tcp.example.com. IN TLSA ( 3 0 0 30820307308201efa003020102020... ) DANE has several extensions that work with other DNS records besides TLSA. The first is the DNS record SSHFP for checking keys for SSH connections. It is described in RFC4255 , RFC6594, and RFC7479 . The second is the OPENPGPKEY entry for key exchange using PGP ( RFC7929 ). Finally, the third is the SMIMEA record (the standard is not defined in the RFC, there is only its draft ) for cryptographic key exchange via S / MIME.
What is the problem with DANE
In mid-May, a DNS-OARC conference was held (this is a non-profit organization that deals with security, stability and development of the domain name system). On one of the panels, the experts concluded that the DANE technology in browsers failed (at least in the current implementation version). Geoff Huston, a leading researcher at APNIC , one of five regional Internet registrars, who was present at the conference, spoke of DANE as a “dead technology”.
Popular browsers do not support certificate authentication using DANE. There are special plug-ins on the market that reveal the functionality of TLSA-records, however, their support is gradually ceased .
Problems with the spread of DANE in browsers are associated with the duration of the DNSSEC validation process. The system is forced to perform cryptographic calculations to verify the authenticity of the SSL certificate and pass through the entire chain of DNS servers (from the root zone to the host domain) when it is first connected to the resource.
/ Unsplash / Kaley Dykstra
This defect was attempted to be eliminated in Mozilla using the DNSSEC Chain Extension for TLS mechanism. He had to reduce the number of DNS records that the client had to view during authentication. However, within the development team there were disagreements that could not be resolved. As a result, the project was abandoned, although it was approved by the IETF in March 2018.
Another reason for the low popularity of DANE is the low prevalence of DNSSEC in the world - only 19% of resources work with it . Experts felt that this was not enough to actively promote DANE.
Most likely, the industry will develop in a different direction. Instead of using DNS to verify SSL / TLS certificates, market players, on the contrary, will promote DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) protocols. We mentioned the latter in one of our previous materials on Habré. They encrypt and verify user requests to the DNS server, preventing attackers from spoofing data. Earlier this year, DoT has already been implemented in Google for its Public DNS. As for DANE, whether the technology will succeed in “returning to the saddle” and yet become mass, will be seen in the future.
What else do we have for additional reading:How to automate IT infrastructure management - we discuss three trends
How to save using the application programming interface
How does tech support 1cloud work
Source: https://habr.com/ru/post/454322/
All Articles