DROWN vulnerability on root domain affect subdomains?

Question

I maintain a departmental server hosted on a subdomain of my organizational network, as in department.example.com.

Both example.com and department.example.com use HTTPS, but run on completely different machines, use a different Certificate Authority, and use different key pairs.

department.example.com (the server which I am over) does not support SSLv2 or SSLv3; it only support TLSv1.0 and above. The version of OpenSSL on this machine is completely up to date.

However, the example.com subdomain supports SSLv2, and uses a wildcard *.example.com certificate. It uses an out of date version of OpenSSL.

---

When I ran my website through the DROWN attack vulnerability checker at https://drownattack.com/#check, it still told me that my website was vulnerable (to a man in the middle attack if I read it correctly). If the server key pairs on my subdomain department.example.com are completely separate from the example.com's key pair, my version of OpenSSL is up to date, and I don't support SSLv2, how could I still be vulnerable to the DROWN attack?

Can a "secured" subdomain be vulnerable because of the bad management of the example.com server? If so, how does this work?

Answer 1

A not properly configured server can actually make you vulnerable to DROWN, let me show you how. As illustrated in DROWN's original website in order to be vulnerable, one of these 2 conditions has to be met:

1. The server allows SSLv2 connections. This is surprisingly common, due to misconfiguration and inappropriate default settings. Our measurements show that 17% of HTTPS servers still allow SSLv2 connections.

   Or

2. Its private key is used on any other server that allows SSLv2 connections, even for another protocol. Many companies reuse the same certificate and key on their web and email servers, for instance. In this case, if the email server supports SSLv2 and the web server does not, an attacker can take advantage of the email server to break TLS connections to the web server. When taking key reuse into account, an additional 16% of HTTPS servers are vulnerable, putting 33% of HTTPS servers at risk.

The second case (the one on the right) is of our interest here. example.com or one of its subdomains support SSLv2 and your server at department.example.com happens to use the same SSL Certificate (which means its using the same public/private key pair). Even if your server only supports TLS protocol and not SSL, the attacker can abuse the one subdomain that uses SSLv2 to do the DROWN attack and decrypt your secure TLS session.

Mitigations

1. Get other servers which use the same certificate to apply secure configurations and disable old and insecure protocols (SSLv2).
2. If for any reason number 1 is impossible, get another single domain certificate with fresh keys for your own server on your subdomain. (This is an ugly patchy solution though)

Answer 2

If a site is affected by the DROWN attack only depends on the setup of the server serving this site, not on any relation to other servers. Thus if your server is configured to not support SSLv2 it should not be affected by the DROWN attack.

Which means that either the report is wrong or your site has a different than expected setup or the outside DNS points to a different server than your inside DNS or something else went wrong. Given the information you provide it is impossible to say which of these is the case and the problem can not be reproduced to get more information.