Podcast Detail

SANS Stormcast Tuesday, March 10th, 2026: Encrypted Client Hello; ExitTool Vulnerability;

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9842.mp3

previous
Podcast Logo
Encrypted Client Hello; ExitTool Vulnerability;
00:00

Podcast Transcript

 Hello and welcome to the Tuesday, March 10th, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida. This episode is brought to you by
 the SANS.edu Graduate Certificate Program in
 Cybersecurity Leadership. Today I noticed that last week
 two RFCs were published that well have been in the work for
 a while. And actually I thought they already had been
 published, but guess they were not. The first one is 9848,
 that's bootstrapping TLS encrypted client hello with
 DNS service bindings. And the second one is 9849 TLS
 encrypted client hello. So what this does is really it
 establishes a standard for encrypted TLS client hellos.
 This has been sort of an ongoing issue because it was
 sort of the one information leak that still existed in TLS
 as part of the client hello. The client typically will
 send, for example, the host name of the client it's going
 to connect to, which of course does remove part of the
 anonymity, privacy that you expect from TLS. So with this
 extension, it's now possible to encrypt the complete client
 hello. This also does prevent some fingerprinting, basically
 figuring out what browser or other client you may be using.
 There has been a prior to this proposal for encrypted server
 name indication that basically just encrypts the host name
 being communicated during the client hello. But with this
 proposal now, the entire client hello is being
 encrypted or most of it. And that of course, it solves a
 bigger problem and really also is not any more complicated
 than just encrypting the server name. So that's why
 server name indication got kind of deprecated and we now
 only have the complete client hello encryption. Now the
 trick with these client hello encryptions is that we somehow
 have to communicate the public key that's being then used for
 the encryption because the client hello is the first data
 packet being sent as part of a TLS handshake. That happens
 via DNS. There are two DNS types that are being used
 here. One is HTTPS. That's the one that you are most likely
 going to see because most likely you're going to see
 this used with HTTPS and that's already HTTPS that type
 comes in. And then we also have a service binding type.
 That one is basically for any other TLS application, not
 HTTPS that may take advantage of this particular feature.
 So, yes, the standard is out there and it has already been
 implemented and used for a while. Actually, that's why I
 was a little bit surprised that it the standard actually
 hadn't been released yet. Cloudflare as so often has
 been one of the front runners here when it comes to
 encrypted client hello. And if you have paid for a Cloudflare
 account, well, it's as simple as just checking a checkbox
 and you have it enabled. Now, if you're looking at it from a
 detection point of view, of course, it removes details
 from your network. You could suppress encrypted client
 hello if you're blocking these HTTPS or these SVDB records.
 With HTTPS, you will also use HTTP 3 or QUIC because that's
 also negotiated via these HTTPS records that may
 actually be in your favor. Like maybe something that you
 do want. So just blocking HTTPS outright may be an
 option for you. As so often before you block stuff, you
 know, make sure that it's actually in line with whatever
 you need for your business. And then we have a new vulnerability
 in EXIF tool. EXIF tool is a command line utility that
 usually comes on Unix systems that allows you to extract the
 EXIF data, basic comments and such that are being embedded
 in certain image formats. This can be a very useful tool, for
 example, to extract things like geolocation information
 or other metadata from a particular image. But the tool
 has had issues in the past and this latest vulnerability
 could potentially use be used for command execution. So
 scenarios where this particular critical is where
 you do have, for example, a web application or such that
 processes EXIF data from user submitted data and then, well,
 isn't doing so carefully enough. In particular here,
 there is the dash N option EXIF tool that does output
 data as it finds it. It doesn't sort of try to parse
 it. So when you're using that raw data mode, that will
 trigger this vulnerability. Kaspersky, who found a
 vulnerability, is particularly pointing out here that macOS
 systems are vulnerable because they come with the vulnerable
 version of EXIF tools. And so far, there hasn't been a
 patch. This has been a little bit of an issue with Macs in
 general that they're using these open source tools. But
 then, of course, they only sort of have these somewhat
 irregular patch days where they then patch all the, well,
 recently discovered open source vulnerabilities. And
 let's hope we're sort of expecting actually an update
 next week for macOS that they'll include an update for
 EXIF tool. And for anybody self-hosting cloud services,
 if you're using Nextcloud Flow, I highly recommend you
 update. There is a vulnerable windmill version in Nextcloud
 Flow that does leak the super admin secret, which, well, can
 then be used to basically authenticate as an
 administrator. This is part of the entire windmill users
 config.json file that's being leaked here. Now, a couple of
 things about the vulnerability announcement. It's fairly
 sparse, so not a lot of details here. And it doesn't
 really say exactly how it happens. The CVSS score of
 this is 8.8. In part, it doesn't make of the nine the
 critical range because it says that in order to exploit it,
 the attack vector is adjacent, which, in my opinion, usually
 means you have to be in the same network segment. Now,
 without any additional details, I can't really
 question that. How this happens, maybe not some kind
 of multicast DNS packet or so that leaks it. But I would be
 a little bit more careful here and definitely consider this a
 critical vulnerability. Well, and this is it for today. So,
 thanks for listening. Thanks for liking and thanks for
 subscribing. And talk to you again tomorrow. Bye.