start	end	text
1760	6200	Hello everyone, and welcome to Domain Fronting is Dead, Long Live Domain Fronting.
6200	11940	Using TLS 1.3 to evade sensors, bypass network defenses, and blend in with the noise.
11940	16200	My name is Eric Hunstad, and I'm the CTO and Adversary Emulation Lead at 6Gen,
16400	19700	a full-spectrum cybersecurity company based in Annapolis, Maryland.
19780	25040	Today, I'm going to go over what domain fronting is, including HTTP and HTTPS basics.
25040	28940	I'll talk about TLS 1.3 and encrypted server name indication,
28940	30800	and how this can be used for domain hiding.
31120	34120	I'll show some demos of this in action, from basic bypasses,
34120	37020	to bypassing an enterprise TLS decrypting firewall.
37320	41560	And finally, I'll talk about some ideas for defenders who may want to detect this in their environment.
42460	43920	Domain Fronting 101.
44020	46580	If we're going to discuss a new method for domain fronting,
46580	50900	let's all get up to speed on what domain fronting is, why it works, and what happened to it.
51300	55680	Like many things in security, to understand the cool stuff, you have to dig into the basics.
55680	60920	To understand domain fronting, we really need to understand HTTP and HTTPS.
61060	64220	Specifically, we'll be focused on server name indication,
64220	69220	which is a special extension added to TLS that allows multiple sites to be hosted on the same server.
69220	74760	But TLS 1.3, this extension can be encrypted, and combined with encrypted secure DNS,
74760	78360	we can do domain fronting 2.0, or domain hiding.
79140	81320	Okay, let's start with HTTP.
81440	84700	I'll skip over the super low-level stuff as it's not relevant here.
84700	89660	The first external request involved in an HTTP connection is a DNS request.
89700	94300	This DNS request gets sent out unencrypted via UDP to port 53.
94860	98720	The DNS server responds, also unencrypted via UDP,
98720	103140	with an answer that contains the IP address of the domain from the request.
103440	106660	Now that the user's computer knows where the domain is hosted,
106660	109820	it can issue an HTTP request to that IP address,
109820	113520	with the host header indicating the domain the user wishes to browse.
113520	116840	This request uses TCP, but it's unencrypted.
117120	121160	The web server responds with content, in this case some simple HTML.
121460	125720	This was fine for the early days of the Internet, when it was just a few research institutions,
125720	128260	but as soon as people wanted to conduct business online,
128260	131960	the obvious issues with completely unencrypted traffic had to be fixed.
132500	139020	Plus, without encryption, all your data is free game for any number of actors that are positioned between you and the web server.
139920	144760	HTTPS was the answer to this problem, and it starts off the same way, with a DNS request.
144980	149020	The DNS request and response are still unencrypted when using HTTPS,
149020	151680	unless you use a different system, which we'll talk about later on.
151780	154360	Here's where HTTPS is different.
154360	159180	The connection to the server starts with a TLS connection, specifically a client hello.
159380	165040	In this packet, the server name extension is used to tell the web server which website the user is requesting.
165160	168820	This allows the web server to return the proper certificate for that site.
168820	172180	The server returns the certificate in a server hello packet,
172180	177940	and then the client and server can agree on which encryption algorithms to use, and exchange session keys.
178240	183340	All traffic after this is encrypted, but both the client hello and server hello are unencrypted,
183340	187760	which leaks the domain and certificate to anyone between the client and the web server.
188400	191940	And we know there are plenty of organizations interested in that data.
192220	195520	With the basics covered, let's talk about domain fronting.
195520	200900	Domain fronting is a technique to get around network defenses or sensors by connecting to an approved server,
200900	204500	while hiding the true destination of the HTTPS request.
204620	209560	One of the biggest restrictions of domain fronting is that the fronted domain and the true destination domain
209560	212580	must be hosted by the same service provider.
212620	215000	Typically, this is a content delivery network.
215180	217420	So how does domain fronting work in practice?
217420	223020	Well, it starts with the same DNS lookup as before, and the TLS handshake is the same as well.
223020	228840	However, in the handshake, the client connects to the front domain, not the true destination domain.
228840	232940	Once the TLS handshake is complete with the front domain, the fronting begins.
232940	237760	The client sends an HTTP request to the front domain, wrapped in TLS,
237760	240780	but with a host header of the true destination domain.
240900	245220	When the content delivery provider receives this request and inspects the host header,
245220	248640	determines that it's for a different domain hosted on the same provider,
248640	252160	and dutifully forwards the request to the true destination domain.
252160	255960	You can think of domain fronting like a postcard inside an envelope.
256160	259560	On the outside of the envelope, the client writes the address of the CDN,
259560	263540	but on the inside, the true destination domain is on the postcard.
263760	268180	The network filters or sensors are like mailmen, who can see the outside of the envelope,
268180	271280	and they deliver it, since the CDN is an approved address.
271360	276880	However, when the CDN opens the letter, they deliver the postcard to the true destination internally.
277140	281020	This was working well on all major CDNs until April of 2018,
281020	284540	when the Russian government put pressure on cloud providers to stop it,
284540	289680	since the popular messaging app Telegram was using both Google and AWS for domain fronting.
289720	292500	Both Google and Amazon stated that the reasons were technical,
292500	296800	and domain fronting was either never supported or a violation of Terms of Service,
296800	299920	and other providers follow suit to include Cloudflare.
300240	306740	Microsoft's Azure platform still allows domain fronting for now, as do a few other smaller CDNs.
307020	310400	Domain fronting is a great censorship or network bypass technique,
310400	312140	but it has some major problems.
312280	316960	For any network censorship bypass to be effective, it has to be really painful to block,
316960	320940	and since the largest provider shut it down, it lacks the punch that it once had.
321120	325780	Also, the true destination domain has to be hosted on the same service as the front domain,
325780	330640	which limits the potential front sites and imposes costs on anyone wishing to set up fronting.
330860	334400	With the background out of the way, we can talk about TLS 1.3,
334400	338380	encrypted server name indication, and what can be called domain hiding.
338380	343480	First, let's talk about TLS 1.3. It's seeing steady growth on the internet today.
343480	348920	This is data from Quali's SSL Labs, which tests the most popular 150,000 sites.
348960	356260	As you can see, TLS 1.3 is on the rise, and is supported by 31.7% of those sites tested last month.
357020	363360	Cloudflare is seeing 59% of all traffic using TLS 1.3, again, showing a steady increase.
363360	371160	Before we dig into the mechanics of a TLS 1.3 handshake with ESNI, we first have to secure the DNS process.
371220	375900	If a network defender or sensor can see our DNS requests, they can easily be blocked.
376080	380500	Also, secure DNS is a cornerstone of ESNI, which we'll see in a moment.
380620	384520	The first solution is to simply wrap a DNS query in a TLS connection.
384580	387600	To make things even more difficult for network defenders or sensors,
388000	392660	DNS via HTTPS is a newer standard that is seeing more widespread adoption.
393580	398700	Once we have an encrypted way to perform DNS queries, we can use this to retrieve a public key
398700	403600	for a domain which we can use to encrypt the server name in the client hello packet.
403620	410080	In this screenshot from Wireshark, you can see the encrypted underscore server underscore name TLS extension,
410080	414020	and the encrypted SNI value is just an encrypted hex string.
414020	419760	No longer can defenders use the server name value to block traffic based on a plain text value.
419760	425080	A TLS 1.3 connection with ESNI relies on having the server's public key
425080	427920	in order to encrypt the server name in the client hello.
427920	430960	And the current standard for how to get this key is to use DNS
430960	435080	and query the underscore ESNI text record for that domain.
435480	441220	This request returns a Base64 encoded public key the client can use to derive a session key
441220	443160	that encrypts the server name.
443420	447880	Providers that support this should rotate this key to provide some forward secrecy.
447880	452140	Cloudflare, for example, rotates this key every hour, but allows a few hours of buffer
452140	457100	in case a client has a slightly stale key from a previous request or from caching.
458000	462540	Armed with the server's ESNI public key, the client derives a session key
462540	466820	and uses that to encrypt the server name and sends the client hello.
467220	471420	The server has the corresponding private key and can derive the same session key,
471420	476060	which it uses to decrypt the server name and performs the same steps as standard TLS.
476060	480720	This session key generation ensures that the key is tied to the session that generated it
480720	482880	and prevents replay attacks.
483440	490700	Another difference between TLS 1.3 and previous versions is that the certificate returned by the server is encrypted.
490880	496880	This is possible because in TLS 1.3, the client hello includes a list of supported ciphers,
496880	501640	and the client also makes a guess as to which key agreement algorithm the server is going to choose,
501640	504720	and it preemptively sends a keyshare for that algorithm.
504720	509420	So all the plain text portions of HTTPS we saw before have been mitigated.
509420	514020	However, there are still weak spots where sensors or network defenders could stop the connection.
514680	520840	Even if the DNS request itself is encrypted inside either TLS or HTTPS,
520840	523840	the data returned by a resolver may be poisoned.
523920	530140	Imagine a scenario where a country or enterprise returns their own key for all underscore ESNI requests,
530140	533120	no matter the domain, to enable man-in-the-middle.
533120	538540	DNSSEC solves this problem by signing the record set and allowing the chain of trust to be checked.
538660	542980	The details of DNSSEC are outside the scope of this talk, but I encourage you to check it out.
543500	546580	But what if encrypted DNS is completely blocked?
546580	552220	The solution here is to bootstrap the connection by preloading the current ESNI keys by some other means.
552280	558180	Maybe encrypted DNS is blocked, but what if I have a script that updates a GitHub gist with the current keys every hour?
558180	564380	Or, you could just bake the keys directly into your binary if you know it's going to be executed in the next hour or two.
564960	570700	Okay, let's say we get a valid ESNI key, but the IP address of the server we want to connect to is blocked.
570920	574500	The IP may be shared with other sites, but it doesn't have to be.
574700	579560	Is there a way to route from arbitrary domains and IPs to our true destination domain and IP?
579720	582500	The answer is no, but let's see how close we can get.
583380	593660	So far, I haven't introduced anything new, but we have covered a lot of ground and identified potential issues and solutions around domain hiding with TLS 1.3 and ESNI.
593660	597840	Let's tackle that last point and get around IP or domain blocks.
598740	602560	We'll do this by leveraging the world's largest CDN.
602800	606640	Cloudflare was founded in 2009 and has had explosive growth.
606640	615540	It's now the world's largest CDN, with the most internet exchange points, as well as being an authoritative DNS server hosting over 26 million domains.
615540	624760	Cloudflare is on the forefront of internet technology and supports TLS 1.3, ESNI, WebSockets, QUIC, and DNSSEC.
624920	632280	This new technique, which I'm calling domain hiding, accomplishes the same goals as domain fronting, but uses different technologies.
632280	643980	A TLS 1.3 connection with an ESNI of the true destination is made to any Cloudflare IP, and the underlying HTTP request also has a host header of the true destination.
644120	650840	This enables any Cloudflare-owned IP to act as a front for any domain hosted by Cloudflare DNS.
650920	656060	This technique was first shown to be possible by Robin Wood, so props to him for the discovery.
656980	670040	Today, I'm releasing Noctilucent, a project that enables ESNI in Go's crypto-slash-TLS library, as well as exposes two additional configuration options, ESNI Server Name and Preserve SNI.
670040	676560	It can be used by any project currently using the standard crypto-slash-TLS library, as it's backwards compatible.
676560	688420	It comes with a demo client application that allows you to control just about every part of the TLS connection, as well as the HTTP GET request, so you can play with what's possible using this technique.
688420	696020	It also supports WebSockets, and through the magic of Go, it compiles cross-platform to a single binary with no dependencies.
697180	701820	Here's what a standard TLS 1.3 connection looks like with Noctilucent.
701820	709880	We've specified the TLS host in red, the server name indication in yellow, and the HTTP host header in green.
709880	724060	The output shows what we expect. There's no ESNI, the SNI is set to cloudflare.com, we're connecting to cloudflare.com on port 443, and our GET request to cloudflare.com returns the expected 301 response.
724060	725700	Nothing fancy yet.
726720	730480	Let's enable ESNI and set the ESNI server name.
730480	742180	Everything is the same as the normal TLS 1.3 connection we looked at on the last slide, except this time, the ESNI value is set to cloudflare.com, and there is no standard SNI.
742180	745520	Progress, but no fronting or domain hiding quite yet.
745520	759240	Now I'll change the ESNI server name and HTTP host header to a domain we control, in this case, DEFCON28.hackthis.computer, but leave the TLS host as cloudflare.com.
759240	769760	Notice that this connection is still going to cloudflare.com, but the HTTP request successfully goes to DEFCON28.hackthis.computer, which returns hello DEFCON.
769760	778140	To anyone between this host and cloudflare, it appears to be a TLS connection to cloudflare.com. We've successfully achieved domain hiding.
778980	787680	Now the fun begins. Here we send an ESNI and standard SNI, where the standard SNI is cloudflare.com.
787680	794040	Because cloudflare ignores the standard SNI when an encrypted SNI is used, we can set it to anything.
794040	809820	The HTTP connection works as before, and this time, anyone between this host and cloudflare, looking at SNI data, thinks this connection is going to cloudflare.com, in addition to the underlying TLS connection actually connecting to a cloudflare.com IP.
810220	818640	What I've demonstrated is the ability to arbitrarily front or hide any IP behind a domain that is using DNS provided by Cloudflare.
818640	828740	The true destination IP doesn't have to be a Cloudflare worker or other Cloudflare service. In fact, all the examples today are IPs hosted by DigitalOcean.
828920	834440	Best of all, the requirements to sign up for Cloudflare DNS are minimal, and it's free.
835960	846220	What domains can we use for this hiding? It turns out a lot. Over 21% of the top 100,000 sites are behind Cloudflare and allow this to work.
846220	858400	Some notable examples are shown below, including 3 of 11 domains which are both on the Palo Alto decryption whitelist and behind Cloudflare. I'll demonstrate why this is important in a minute.
859360	872100	There's a little bit of everything on this list, from security-related sites, banks, sports, higher education, streaming services, and even government sites. And porn. So much porn.
872680	884920	Here's a good example of how the variety of available domains to hide behind can be useful. This is a request to www.okta.com, a single sign-on and identity provider used by many enterprises.
884940	896300	But the actual request is going to a server I control. To a sensor or network defender, this looks like standard Okta traffic, with the exception of the ESNI extension being used.
896300	908780	The logical next step is to try out Noctilucent with some web filtering and see how it fares. It turns out most web filtering is done by inspecting the ESNI and making a filtering decision based on that.
908780	916580	Here I set up the untangle firewall with federal government settings and explicitly blocked defcon28.hacktest.computer.
917160	929720	On a host behind the untangle firewall, I made this request, which succeeded. I set the unencrypted SNI to bypass-untangle.com to see if it appears in the logs anywhere.
931260	940320	After repeating the request 30 times or so, back on the firewall, we can see that the top domains include the decoy domain that we sent with the request.
941140	956740	Simple SNI filters were easy to defeat, but what about HTTPS decrypting firewalls? These are often seen in enterprise environments and work by breaking and then re-encrypting HTTPS using a root certificate placed on endpoints behind the firewall.
956740	973580	You can think of it as a corporate man-in-the-middle that allows the network defenders to inspect full, encrypted packet data. Kazakhstan actually attempted to implement this nationwide for a few weeks back in July of 2019 before major international backlash forced them to abandon what they called a, quote, test.
974540	1001140	I headed to AWS and spun up the latest and greatest in enterprise firewalls, Apollo Alto PAVM version 10.0.0. Released in June, this version touts the ability to decrypt TLS 1.3 with a two-time speed boost. Imagine my surprise when it was all set up and the default decryption profile didn't include TLS 1.3. Instead, it let it pass through while logging an error about a version mismatch.
1002080	1024920	Once set up with a decryption profile that enabled decryption of TLS 1.3, I pulled the list of default domains that are allowed to bypass decryption for a variety of reasons, such as having a PIN certificate. Here, the firewall interface is on the left and a Windows VM behind the firewall is on the right. We can see that decryption is enabled and we have no other decryption rules that would allow traffic to bypass decryption.
1024920	1035520	Normally, in an enterprise environment, categories like banking or healthcare bypass decryption due to privacy laws, but this setup is as strict as possible. No explicit exemptions.
1035920	1047780	On the Windows VM, I'll run a PowerShell script that checks the certificate hashes of major sites against hard-coded known fingerprints. We see that it fails, indicating that all tested sites are being man-in-the-middled.
1047780	1055640	Additionally, opening a browser and going to google.com shows a lock icon, but inspecting the certificate shows that it's the firewall certificate.
1056160	1071280	Switching to the command line and using the Noctilucent test client, I'll set the TLS host to mozilla.org, the host header to defcon28.hackthis.computer, and the unencrypted SNI to mozilla.org, which is on the decryption exemption list.
1071280	1081700	The SNI is preserved and set to mozilla.org. A connection is made to mozilla.org on port 443, and we see the hello defcon28 response we expect from the test server.
1082280	1087400	We'll run an NS lookup of mozilla.org so we can look for the connection in the logs.
1091460	1097180	Looking at the firewall traffic logs shows a connection to one of the IP addresses for mozilla.org.
1101120	1113400	Moving to the decryption logs, we see DNS over HTTPS, which is the ESNI key lookup that is performed before each TLS connection, but no traffic to mozilla.org's IP.
1116060	1120640	To make sure we didn't miss it, I'll add a filter for the two possible IPs.
1121380	1126080	No results, because mozilla.org is exempted from decryption by default.
1126080	1133300	We have successfully defeated an HTTPS decrypting firewall by using built-in default exemption and domain hiding.
1133380	1139880	This bypass is great, but every time we want to send data, we'll add an entry to the traffic log, which could stand out.
1139880	1141720	What if there was a better way to hide?
1141720	1147720	This technique works at the TLS level, so any protocol that Cloudflare supports underneath would also work.
1147720	1152960	We saw that regular HTTP requests work, but create a new connection for each request.
1153300	1161060	WebSockets are a technology used by many streaming services that enable full duplex communication channels over a single TCP connection.
1161200	1170900	And we can take this a step further by using one or more of these WebSocket connections to tunnel arbitrary TCP or UDP packets to a proxy beyond the firewall.
1172200	1181120	Here's the Noctilucent test client sending and receiving via WebSockets to our test server while hiding behind www.okta.com.
1181240	1192200	WebSockets are the perfect candidate to use as a wrapper for a proxy protocol that allows us to send arbitrary TCP or UDP traffic using a helper program while only making a single TCP connection.
1192200	1206200	The Noctilucent project includes a fork of the Amazing Cloak project by Andy Wang that enables two new options in the client configuration, ESNI Server Name and Preserve SNI, which operate just like they did on the test client.
1206540	1217180	Cloak is a universal, pluggable transport that cryptographically obfuscates proxy traffic as legitimate HTTPS traffic, disguises the proxy server as a normal web server,
1217180	1223740	and multiplexes traffic through a fixed amount of TCP connection while providing multi-user usage control.
1223740	1228260	With the additions from Noctilucent, it can now do domain hiding as well.
1229060	1236620	Here's the same Palo Alto and Windows VMs from before, with a public IP of 3.14.44.10.
1236740	1242460	This time, the Windows VM is running a Noctilucent Cloak client and a local Shadowsocks client.
1242460	1248700	The Cloak client is connecting to a VPS running the standard Cloak server and a Shadowsocks server.
1249020	1257120	Firefox is configured to use the local Socks proxy provided by the Shadowsocks client running locally, and I can browse the internet as I would normally.
1257580	1267580	The certificates of websites in this proxy browser are legitimate, as they are not being intercepted by the Palo Alto firewall, and all traffic is appearing to come from the DigitalOcean VPS.
1275550	1283410	The speed is surprisingly good. During testing, I was getting speeds up to 100 Mbps using four TCP connections with Cloak.
1283610	1294850	If we look at the firewall logs, we only see the four connections to Mozilla.org, which are not decrypted, while the client has been browsing freely, with all traffic remaining encrypted and uncensored.
1298010	1305470	Switching to the decryption logs, we see the DNS over HDPS requests, but no requests to Mozilla.org.
1307270	1312050	I'll filter for the Mozilla.org IPs, but we'll get no results.
1313410	1322710	What we see here is arbitrary traffic at high speeds using only four TCP connections to what Palo Alto thinks is Mozilla.org.
1324010	1329670	Can we use this technique for our pre-existing Red Team tools? If they support proxying, you bet.
1329670	1334990	Here's a Cobalt Strike listener with a SOCKS proxy setting for localhost port 9999.
1335470	1342850	For fun, we'll set Cloak to use bitdefender.com as the front domain, which has the IP address shown here.
1344890	1354210	After starting the Noctilucent Cloak client and local Shadowsocks server in SOCKS 4 mode, we'll double-click on an innocent-looking EXE.
1354210	1357750	We get the callback immediately, and it works as expected.
1359310	1363090	And of course, the first thing you do when you get access is pop a calc.
1368240	1374960	Switching to the firewall and looking at the decryption logs, we only see entries for cloudflaredns.com.
1379250	1384710	I'll paste in a filter for the two possible IPs for bitdefender.com, and we get no results.
1388600	1397080	Looking at the traffic logs, we see four connections to the IP of bitdefender.com, as well as lots of DNS over HTTPS.
1401070	1406530	Our Cobalt Strike beacon is still functioning as normal, and any network defender is none the wiser.
1407270	1416930	Packaging up Cobalt Strike, Cloak, and Shadowsocks into a clean package, possibly communicating over namepipes instead of sockets, is an exercise left up to the viewer.
1418350	1426650	Red teamers are no doubt wondering how much work it would be to integrate this with their existing tooling, and I can say if you're using Go, it's almost no work at all.
1426650	1434290	Here's a new C2 framework called DemoC2. It was released just five days ago and is built using Go and Vue.js.
1436970	1443190	I've set up an instance here with an HTTPS listener with a public IP on port 443.
1443670	1448690	Going into the listener settings, we can view the source code for an HTTPS agent.
1452760	1457820	It has the C2 host and port in the code, and the agent will connect directly to this host.
1458720	1463140	Switching to an editor, I've made a few modifications to get this to work with Noctilucent.
1463280	1474180	First, I set the host to bitdefender.com, and I've added two new variables, frontDomain and actualDomain, which are set to bitdefender.com and demos.hackess.computer.
1475100	1479260	The actual code changes needed to get everything working is just 30 lines.
1479320	1483540	First, we have to query for the ESNI keys and parse them.
1483540	1489000	If we wanted to, we could bake in the current keys here to avoid the network traffic related to querying for them.
1489320	1493920	Then I define a TLS config and set the minimum value to TLS 1.3.
1494120	1501980	I'll define the two new options from Noctilucent, ESNI server name is set to the actual domain, and preserve SNI is set to true.
1503560	1509600	I define an HTTP client by hand, so that I can tell it to use this TLS config when dialing the host.
1510620	1517860	Besides that, the only change to the agent is having the HTTP client use the actual host when it makes its POST requests.
1520580	1527180	On our Windows VM, I'll set a filter in Wireshark for the IP of Bitdefender, so we can inspect the client hello.
1527460	1531360	I'll double-click this new innocent exe and switch back to Wireshark.
1533620	1541760	In the client hello, we see the unencrypted server name is Bitdefender.com, and the encrypted server name is just a bunch of hex.
1548480	1551400	Back on the C2 server, we have an agent calling back.
1553080	1560880	Notice the external IP. When using this technique, the reported external IP will be from one of Cloudflare's ranges.
1570410	1573950	Just like with CobaltStrike, everything works as normal.
1575450	1580290	You can run WhoAmI, pop a calc, and check the public IP.
1588240	1593460	Besides the external IP appearing to be from a Cloudflare range, the agent functions as expected.
1603520	1608540	Back on the Windows VM, I'll search for traffic to the C2's server IP.
1609700	1617180	No packets. There's no trickery here, but just a small modification, this Go-based agent is using domain hiding.
1617860	1623700	So what is the blue team to do, given that we've just seemingly bypassed the most sophisticated network defenses?
1623760	1627360	The easiest thing to do would be to block TLS 1.3.
1627520	1635340	But as that's likely anywhere from 25% to 50% of the TLS traffic leaving your network, it might make a few users unhappy.
1635560	1642680	You could block Cloudflare, but dropping 21% of the most popular 100,000 domains probably is not a good idea either.
1642980	1646160	What about just targeting client hellos with ESNIs?
1646160	1651380	It's possible, and one vendor has had the ability to do that for 6 months now.
1651380	1655700	However, since you can't determine the destination site, it's all or none blocking.
1655700	1660820	There's no way to only block selective domains if you block TLS connections that have an ESNI.
1660820	1666340	I was surprised by the lack of support for this across major vendors, but perhaps it's just not an issue yet.
1666980	1675940	The most sensible way to detect this specific technique is to alert on packets that contain both a server name and an encrypted server name TLS extension.
1675940	1683520	There are no default helpers for TLS and SNORT besides SSL underscore state, which can help you get the client hello packet,
1683520	1687020	and TLS dot version, which can get you TLS 1.3.
1687020	1691400	So you'll have to get creative with the content parser and look for the extension types.
1692020	1699880	SecureKata has a bit more horsepower than SNORT, but only has a selector for TLS dot SNI and not TLS dot ESNI,
1699880	1702600	so custom rules will be required here as well.
1703400	1708040	It's going to come down to tried and true techniques that work regardless of traffic content.
1708080	1716600	Things like beaconing detection and anomaly detection can help show clients that all of a sudden start sending regular traffic to destinations that perhaps don't make sense.
1716800	1719880	There are even some open source tools that do just this.
1720180	1725400	A network defender should be asking if a traffic pattern to a given endpoint makes sense in context.
1725520	1730480	Perhaps that Windows machine and accounting shouldn't be sending gigs of data to your single sign-on provider.
1732380	1737140	TLS fingerprinting with JAW3 and JAW3S is another technique that could be effective.
1737340	1745700	JAW3 looks at the specific options used in a client hello that can sometimes uniquely identify a client, and JAW3S does the same for servers.
1746180	1755320	This will work until attackers tune their tools to be identical to browsers and common web servers, and work is already underway to do this in projects like Cloak and uTLS.
1755320	1765360	As always, a layered approach that uses strong, instrumented and managed endpoint detection and response, and other techniques, is the best way to prevent compromise.
1765440	1770500	Or as Microsoft so helpfully says, just don't let untrusted code ever run on your server.
1771520	1782280	To wrap up today, I've discussed the basics of HTTP, HTTPS, domain fronting, and a new form of censorship-resistant communication, domain hiding.
1782280	1790120	This technique is usable today with Noctilucent, either as a drop-in replacement for the Go TLS library, or as a proxy.
1790300	1797340	The ESNI standard is still very much a draft, and this technique will continue to evolve as the changes in adoption grows.
1797340	1800340	In fact, it's not even called ESNI anymore.
1800620	1805100	Just as with standard domain fronting, this relies on the CDN permitting it.
1805100	1811340	However, in this case, besides preserving the standard SNI header, we aren't really doing anything terribly out of spec.
1811340	1816040	I look forward to seeing the snort and securicada rules to detect and block this technique.
1816100	1822440	And like every good red teamer, I'll push my customers with the latest techniques, hopefully before the real adversary can.
1822880	1830580	I want to give special thanks to Robin Wood, who first showed this technique was possible with a rough POC using a fork of OpenSSL.
1830760	1837740	Andy Wang, the creator of Cloak, and Nick Sullivan from Cloudflare, who helped get me data on TLS 1.3 adoption.
1838640	1840660	Noctilucent is available now on GitHub.
1840660	1847580	If you have any questions or comments, feel free to hit me up on Twitter, where my personal handle is at badsectorlabs.
1847580	1848940	Thanks for watching.