Windows Server 2019 Phoning Home on an SSLv3 Line

Table of Contents

Routine Test

At Chaser, we routinely test a variety of real-world setups through the discrimiNAT firewall. It helps keep on top of implementation subtleties by different vendors and identify any regressions early as we improve the product.

So we fire up the latest and greatest Windows this time, with outbound allowed to 0.0.0.0/0 on all ports.

These observations were made on deploying a Microsoft Windows Server 2019 Base instance with AMI ID ami-023b643326f4d6eff in the eu-west-2 region of AWS.

Flow Logs

In our setup where no discrimiNAT specific outbound rules existed in the Security Groups attached to this instance, we observed 132 disallowed connections in the 20 minutes of life it had. We were expecting it to phone home a fair bit. So no surprises there.

Query Used: stats count()

Breaking it down by destination hostnames, we get our first glimpse into the various services it’s trying to connect to.

Query Used: stats count() by dhost

Interesting that 53 times, the dhost field was empty. We wonder what’s going on there…

Query Used: filter ! ispresent(dhost) | stats count() by proto,dpt

Well, port 80 is easily explained — plaintext HTTP connections most likely. Since we don’t implement a plaintext parser, the dhost field comes out empty. However, dhost absent when the protocol is TLS is unexpected. SNI has been standard for so many years, so we decide to dig in a bit deeper.

Query Used: filter ! ispresent(dhost) | stats count() by proto,dpt,proto_v

SSLv3?

No!

We are in denial at this stage.

  • Is this a bug in our TLS parser?
  • Merely a logging issue?
  • Windows XP?

Trying Hard

Query Used: {$.dst = 40.90.137.125}

It would appear the firewall is working as expected, but Windows is attempting with a lower version of TLS in case a connection attempt fails. And it goes all the way down to SSLv3! This cycle occurs a few times during our test.

Not Always

Query Used: {$.dst = "13.74.179.117"}

In the case of hostname sls.update.microsoft.com, that doesn’t appear to be the case. It stays at TLS 1.2. A disparate but welcome behaviour!

More Questions

We know Windows carries a lot of baggage, but one can’t help wonder if this can be exploited by deliberately inducing a network issue, externally manifested. Also, the difference in the behaviour of perhaps various subsystems within Windows hints of long-forgotten tech debt.

We hope you enjoyed this CloudWatch exercise in filtering, armed now with the knowledge that a modern firewall can prevent a lot of undesirable behaviour emanating from programs we trust to run in the Cloud.

Do watch our 2-minute demo on how discrimiNAT integrates with Security Groups on AWS.