Skip to main content

Windows Server 2019 Phoning Home on an SSLv3 Line

· 3 min read

Observation of traffic from a Windows Server 2019 instance with a firewall restricting its egress, and a CloudWatch exercise in filtering and aggregation

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.

FQDN filter for Windows on AWS egress, shall we?

So we fire up the latest and greatest Windows this time, with outbound allowed to 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()

CloudWatch 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

CloudWatch 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

CloudWatch filter by protol and destination port

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

CloudWatch No SNI



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 =}

CloudWatch TLS Downgrade

CloudWatch JSON expanded "reason" field

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 = ""}

CloudWatch TLS 1.2 stays

In the case of hostname, 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.