0

When setting a DNS SRV record like _service._proto.example.com. IN SRV 0 0 443 service.example.com., why has the TLS certificate name on service.example.com:443 to be example.com and not service.example.com?

I've read on what names for TLS certificates when using SRV records that it's to prevent man in the middle attacks but I'm not sure to understand why: MITM attacks on the DNS would be prevented using DNSSEC.

The problem whith this design is the following. Consider one has the following DNS SRV records:

_service1._proto.example.com. IN  SRV 0 0 443 service1.example.com.
_service2._proto.example.com. IN  SRV 0 0 443 service2.example.com.
_service3._proto.example.com. IN  SRV 0 0 443 service.provider.com.

One has to give a TLS certificate which name is example.com to the teams managing service1 and service2 and to the external service provider's team. This way, a compromise of any of the services can lead to the compromise of all the services.

This seems like a flaw in the design of DNS SRV records. Is it?

Yann
  • 1
  • 1
  • I notice that there are conflicting answers to the question you link to. Are you certain that [smorlat's answer](https://serverfault.com/a/974093/94065) is correct? [Esa's answer](https://serverfault.com/a/862931/94065) says that the SSL certificates must match the host name, e.g., `service1.example.com` in your example. – Harry Johnston Jan 01 '20 at 11:21
  • ... when configuring Active Directory to use SSL, you [definitely use the host name rather than the domain name](https://support.microsoft.com/en-nz/help/321051/how-to-enable-ldap-over-ssl-with-a-third-party-certification-authority). Domain Controllers are found using SRV records, so at least in that case Esa's answer is correct. – Harry Johnston Jan 01 '20 at 11:25
  • It seems to be protocol dependant: Matrix requires the domain name in the certificate instead of the host name for example. – Yann Jan 03 '20 at 19:14
  • in your example as the port is the same and well known port it would be the most probably three endpoints for the one service - ``_https._tcp.example.com`` instead of ``_service1``, ``_service2`` and ``_service3``. Anyway for the general answer please check the answer I have post to this question. – Kamil J Jan 08 '20 at 22:33

1 Answers1

0

this could be implementation dependent answer. But in general it would work based on the options used for the "redirection" in DNS :

  • CNAME : The client's request is redirected - the originally requested FQDN would be presented in the destination certificate as the redirection is done during the original request.

  • SRV record (the use case you are asking) - there WOULD be subsequent query to the destination provided in SRV record so only final destination (FQDN from SRV record) would be requested in the cert as it is not the same request and subsequent request target directly the new FQDN.

This behaviour can be seen for example in case of autodiscovery feature on Exchange server. In case you have several domains hosted on one Exchange, once the autodiscovery feature is set up using SRV record only own FQDN is required in the cert on the server (so not list of all hosted domains).

The DNSSEC "requirements" here is due to this behaviour - as there is subsequent query once the attacker can pass the own SRV record in the DNS answer the destination can be any FQDN so the attacker can easily get proper trusted certificate for own domain pointed by the injected SRV record.

In case of not fully correct implementation the client side can use the information from SRV just to discover the endpoint for the query (like CNAME record) and keep original FQDN in the request. In that case the original FQDN could be needed - the present of the original FQDN in the cert on the destination system is just workaround to cover improper implementation of SRV record on the client side...

Kamil J
  • 1,587
  • 1
  • 4
  • 10