JA4+ network fingerprinting

By on 22 Nov 2023

Category: Tech matters

Tags: , ,

Blog home

In this blog post, I look at new JA4+ network fingerprinting methods and examples of what they can detect.

JA4+ provides a suite of modular network fingerprints that are easy to use and easy to share, replacing the JA3 TLS fingerprinting standard from 2017. These methods are both human and machine-readable to facilitate more effective threat-hunting and analysis. The use cases for these fingerprints include scanning for threat actors, malware detection, session hijacking prevention, compliance automation, location tracking, DDoS detection, grouping of threat actors, reverse shell detection, and many more.

JA4 TLS client
JA4S TLS server response
JA4HHTTP client
JA4LLight distance / location
JA4XX509 TLS certificate
JA4SSHSSH traffic
Table 1 — Initial fingerprints.

More fingerprints are in development and will be added to the JA4+ family as they are released.

Examples are shown in Tables 2 and 3.

ApplicationJA4+ fingerprints
ChromeJA4=t13d1516h2_8daaf6152771_e5627efa2ab1 (TCP)
JA4=q13d0310h3_55b375c5d22e_cd85d2d88918 (QUIC)
JA4=t13d1516h2_8daaf6152771_02713d6af862 (ECH)
IcedID Malware DropperJA4H=ge11cn020000_9ed1ff1f7b03_cd8dafe26982
IcedID MalwareJA4=t13d201100_2b729b4bf6f3_9e7b989ebec8
Sliver MalwareJA4=t13d190900_9dc949149365_97f8aa674fd9
Cobalt StrikeJA4H=ge11cn060000_4e59edc1297a_4da5efaf0cbd
SoftEther VPNJA4=t13d880900_fcb5b95cb75a_b0d3b4ac2a14 (client)
Reverse SSH ShellJA4SSH=c76s76_c71s59_c0s70
Table 2 — JA4+ fingerprints and applications.
IP AddressDomain
Table 3 — Sliver C2 list from JA4X

What is JA4+?

JA4+ is a set of simple yet powerful network fingerprints for multiple protocols that are both human and machine-readable, facilitating improved threat-hunting and security analysis. If you are unfamiliar with network fingerprinting, I encourage you to read my posts releasing JA3 here, JARM, and this excellent blog by Fastly on the State of TLS Fingerprinting, which outlines the history of the aforementioned along with their problems. JA4+ brings dedicated support, keeping the methods up to date as the industry changes. Additionally, and by popular demand, an official JA4+ database of fingerprints, associated applications and recommended detection logic is in the process of being built.

All JA4+ fingerprints have an a_b_c format, delimiting the different sections that make up the fingerprint. This allows for hunting and detection using just ab or ac or c only. If you wanted to just do an analysis on incoming cookies into their app, you would look at JA4H_c only. This new locality-preserving format facilitates deeper and richer analysis while remaining simple, easy to use, and allowing for extensibility.

In this post, we are releasing JA4/S/H/L/X/SSH, or JA4+ for short. More fingerprints are in development and will be added to the JA4+ family as they are released.

Figure 1 — There is hope!
Figure 1 — There is hope!

JA4: TLS client fingerprint

TLS is used to encrypt the vast majority of traffic on the Internet, from web browsing to streaming to IoT usage analytics. Even malware uses TLS to hide its malicious communications. At the beginning of a TLS connection, the client sends a TLS Client Hello packet, which is sent in the clear, before encrypted communication. This packet, generated by the client application, informs the server of what ciphers it supports as well as its preferred method of communication. As such, the TLS Client Hello packet is unique per application or its underlying TLS library.

JA4 looks at this TLS Client Hello packet and builds out an easily understandable and shareable fingerprint. The format is shown in Figure 2.

Figure 2 — TLS client fingerprint.
Figure 2 — TLS client fingerprint.

JA4 fingerprints the client, no matter if the traffic is over TCP or QUIC. QUIC is the protocol used by the new HTTP/3 standard that encapsulates TLS 1.3 into UDP packets. As QUIC was developed by Google, if an organization heavily uses Google products, QUIC could make up half of their network traffic, so this is important to capture.

JA4 also clearly shows the Application-Layer Protocol Negotiation (ALPN). This represents the protocol that the application wants to communicate in after the TLS negotiation is complete. ‘h2’ = HTTP/2, ‘h1’ = HTTP/1.1, ‘dt’ = DNS-over-TLS, and so on. A full list of possible ALPNs is available. A ’00’ here denotes the lack of ALPN. Note that the presence of ALPN ‘h2’ does not indicate a browser as many IoT devices communicate over HTTP/2. However, the lack of an ALPN may indicate that the client is not a web browser.

More technical details for implementation and what the raw (unhashed) fingerprint looks like are available on GitHub.

ApplicationJA4 (client)
Chromet13d1518h2_8daaf6152771_e5627efa2ab1 (TCP initial)
t13d1518h2_8daaf6152771_9b887d9acb53 (TCP reconnect)
q13d0310h3_55b375c5d22e_cd85d2d88918 (QUIC initial)
q13d0311h3_55b375c5d22e_3512bcbbc9ec (QUIC reconnect)
SoftEther VPN Clientt13d880900_fcb5b95cb75a_b0d3b4ac2a14 (88 ciphers!?)
IcedID Malwaret13d201100_2b729b4bf6f3_9e7b989ebec8
Sliver Malwaret13d190900_9dc949149365_97f8aa674fd9 (GoLang)
Table 4 — JA4 fingerprint examples.

Even though the traffic is encrypted over TLS 1.3, we are still able to gain a huge amount of valuable information about the client application. Remember that most custom applications will have the fingerprint of their underlying TLS libraries. So, a program written in Go will likely have a JA4 that matches other Go programs. The same is true for Python, Java, and so on, while custom programs like VPN clients, Steam, Slack, and Windows functions will be unique.

JA4 can be extremely valuable in production networks where applications are largely static. If you are running an all-Linux infrastructure, then a Windows JA4 fingerprint would be worth looking into. If you’re running only Exchange servers, then a sudden Python JA4 fingerprint would be worth investigating. JA4 makes for a great pivot point in analysis when trying to understand network traffic and the a_b_c format allows for deeper analysis.

For example, GreyNoise is an Internet listener that identifies Internet scanners and is implementing JA4+ into their product. They have an actor who scans the Internet with a constantly changing single TLS cipher. This generates a massive amount of completely different JA3 fingerprints but with JA4, only the b part of the JA4 fingerprint changes, parts a and c remain the same. As such, GreyNoise can track the actor by looking at the JA4_ac fingerprint (joining a+c, dropping b).

JA4S: TLS server/session fingerprint

After a client sends its TLS Client Hello packet, the server will respond with its TLS Server Hello packet. This packet, also sent in the clear, is formulated based on the server’s selection of available options in the Client Hello. This includes the one cipher chosen out of the list of available options and any extensions the server wishes to set.

As such, the Server Hello is unique to both the server application and the Client Hello that was sent to it. A different Client Hello may cause a different Server Hello, and therefore a different JA4S, from the same server. However, the same Client Hello will always produce the same Server Hello from that server application. For example, if the client sends JA4=a_b_c and the server responds with JA4S=d_b_e, that server will always respond to a_b_c with d_b_e. But if another application sends a different Client Hello to that same server, say JA4=x_y_z, the server will respond with a different server hello, JA4S=t_y_v. So, it’s a different response to different applications but always the same response to the same application. I go into more detail on this in my JA3S blog post.

Figure 3 — TLS server response fingerprint.
Figure 3 — TLS server response fingerprint.
ApplicationJA4 (client)JA4S (server response)
IcedID Malwaret13d201100_2b729b4bf6f3_9e7b989ebec8t120300_c030_5e2616a54c73
SoftEther VPNt13d880900_fcb5b95cb75a_b0d3b4ac2a14t130200_1302_a56c5b993250
Sliver Malwaret13d190900_9dc949149365_97f8aa674fd9 (GoLang)t130200_1301_a56c5b993250 (Sliver Server)
Addigy (Apple device management)t13d190900_9dc949149365_97f8aa674fd9 (GoLang)t130200_1301_234ea6891581 (Addigy Server)
Table 5 — Example JA4+JA4S combinations.

JA4S, when combined with JA4, significantly increases detection fidelity. Going from merely identifying the underlying libraries of a client to identifying the client or malware family. Beyond application identification, one could look at just JA4S_b to understand what ciphers are being used on any given network to ensure it is meeting compliance requirements. All of this is possible without breaking encryption.

JA4H: HTTP client fingerprint

JA4H fingerprints the HTTP client based on each HTTP request. As most traffic is encrypted, JA4H is best used on servers, proxies, Web Application Firewalls (WAFs), TLS-terminating load balancers, and environments where TLS is decrypted. However, JA4H is still valuable even in environments where TLS is not decrypted because several devices and programs, including malware, still communicate over HTTP. The IcedID malware dropper, for example, doesn’t use TLS. These malware programs are very easy to fingerprint.

Figure 4 — JA4H HTTP client fingerprint.
Figure 4 — JA4H HTTP client fingerprint.

JA4H_ab is a fingerprint of the application for the given HTTP method used. The lack of an Accept-Language is a clear indication that the application is not human interactive and, therefore a bot.

JA4H_c is a fingerprint of the cookie and will be different for each website visited but will be the same for that website or application. For example, every Plex server or Okta server will produce the same JA4H_c.

JA4H_d is a fingerprint of the user and will be different per user. This allows for tracking of a user through a website without logging SPII, thereby keeping the logging system General Data Protection Regulation (GDPR) compliant.

More details on the technical implementation can be found on our GitHub.

 Application Application fingerprint Website cookie fingerprint User cookie fingerprint
JA4H_a JA4H_b JA4H_c JA4H_d
Chrome ge20cr13enus 974ebe531c03 b66fa821d02c (cnn.com) e97928733c74
JA4H = ge20cr13enus_974ebe531c03_b66fa821d02c_e97928733c74
IcedID malware ge11cn020000 9ed1ff1f7b03 cd8dafe26982 a51681cc67b
JA4H_abc = ge11cn020000_9ed1ff1f7b03_cd8dafe26982
Cobalt Strike ge11cn060000 4e59edc1297a 4da5efaf0cbd 77ba3814cca4
JA4H_ab = ge11cn060000_4e59edc1297a

Table 6 — JA4H examples.

On the server side, one could use JA4H_c as a hunting method. As the server is specifying which cookie fields the client should use, all clients should have the same JA4H_c. Discrepancies here merit investigation. One could also track a user with JA4H_d and their client application with JA4H_ab or identify bots with just JA4H_ab.

On the client side (proxy, NDR, zero trust), JA4H combined with JA4 and JA4S allow for extremely high-fidelity application and malware detection.

There are several use cases for JA4H, especially when combined with the rest of JA4+. I’ll cover all of them in more detail in a later blog post.

JA4L: Light distance locality

JA4L measures the distance between a client and a server by looking at the latency between the first few packets in a connection. We use the first few packets because these are low-level machine-generated, so there is nearly zero processing delay in creating and sending these packets. Time is measured in microseconds (µs), 1ms = 1000µs, as microseconds are a standard unit of time measurement in packet captures.

If JA4L is running server side, this will measure the distance of the client from the server and if this is running client side, this will measure the distance of the server from the client. If this is running on a network tap, it will measure the distance of each from the network tap location.

Figure 5 — JA4L: Light distance / location fingerprint.
Figure 5 — JA4L: Light distance / location fingerprint.

JA4L is split up into two measurements, client and server. For TCP, these are determined by looking at the TCP 3-way handshake. For UDP, we’re looking at the QUIC handshake.

Figure 6 — TCP.
Figure 6 — TCP.

JA4L-C = {(C-B)/2}_Client TTL
JA4L-S = {(B-A)/2}_Server TTL

In Figure 6:
JA4L-C = 11_128
JA4L-S = 1759_42

Figure 7 — QUIC.
Figure 7 — QUIC.

JA4L-C = {(D-C)/2}_Client TTL
JA4L-S = {(B-A)/2}_Server TTL

In Figure 7:
JA4L-C = 37_128
JA4L-S = 2449_42

Distance measurement

With JA4L we can determine the distance between the client and server using this formula:

D = jc/p

  • D = Distance
  • j = JA4L_a
  • c = Speed of light per µs in fibre (0.128 miles/µs or 0.206km/µs)
  • p = Propagation delay factor

Typical propagation delay depends on the terrain and how many networks are involved.

  • Poor terrain factor = 2 (around mountains, water)
  • Good terrain factor = 1.5 (along highway, undersea cables)
  • SpaceX factor = … needs to be tested

We can use the TTL to calculate the hop count, which can help inform the propagation delay factor (Table 6 is a good starting point but more testing needs to be done).

Hop countPropagation delay factor
Table 7 — Propagation delay factor informed by hop count.

To calculate the number of hops a connection went through, subtract the TTL from its estimated initial TTL.

  • Cisco, F5, and most networking devices use a TTL of 255
  • Windows uses a TTL of 128
  • Mac, Linux, phones, and IoT devices use a TTL of 64

Most routes on the Internet have less than 64 hops. Therefore, if the observed TTL, JA4L_b, is <64, the estimated initial TTL is 64. Within 65-128, the estimated initial TTL is 128. And if the TTL is >128 then the estimated initial TTL is 255.

With a JA4L-S of 2449_42, the observed TTL of 42 means the initial TTL was likely 64, a Linux server. 64-42 gives us a hop count of 22.

  • 2449×0.128/1.6=195

We can conclude that this server is within 195 miles of the client. The server may be closer than this, but it is physically impossible for it to be farther away as the speed of light is constant. If there are multiple JA4Ls for the same host, the lowest value should be taken as the most accurate.

In this example, the actual distance was 194 miles. Utilizing multiple locations, one can passively triangulate the physical location of any client or server down to a city area (more on this in a later blog post…).

Figure 8 — Triangulating the physical location of any client or server in a city area.
Figure 8 — Triangulating the physical location of any client or server in a city area.

Additionally, JA4L_b (TTL) passively facilitates the identification of source operating systems, which is an excellent data point to have when performing forensic analysis. Also, because JA4L is looking at Layer 3 data, it works on encrypted and unencrypted traffic.

Combining JA4 with JA4H and JA4L on the server side makes it possible for the server application to identify session hijacking or MiTM attacks. If a session cookie (JA4H_d) were to suddenly change locations, operating systems (JA4L), and application (JA4 and JA4H_ab), then it would make sense to revoke the session token, asking the user to log back in with MFA. With this type of logic, special care should be taken to not allowlist particular fingerprints as applications will change over time, but instead to look for dramatic changes. Session hijacking detection with JA4+ is something darksail.ai is working on right now.

JA4X: X509 TLS Certificate Fingerprinting

Credit: W.

JA4X fingerprints how TLS certificates are generated — not the values within the certificate. This can identify applications and settings used to create the certificate, which can be extremely useful in threat hunting as threat actors will create different certificates but tend to use the same methods to create said certificates, thereby having the same JA4X fingerprint.

Figure 9 — JA4X: X509 fingerprint.
Figure 9 — JA4X: X509 fingerprint.
Server ApplicationJA4X
SoftEther VPNd55f458d5a6c_d55f458d5a6c_0fc8c171b6ae
Async, Quasar, BitRAT7022c563de38_7022c563de38_0147df7a0c11
Sliver Malware / Havoc C2000000000000_7c32fa18c13e_bf0f0589fc03
Table 7 —  Identifying applications and settings used to create the certificate can be extremely useful in threat hunting.

SoftEther VPN was heavily used by Chinese APT actors, Flax Typhoon, to compromise Taiwan infrastructure, and Storm-0558 in the hacking of US government email accounts. According to Microsoft, it is very difficult to differentiate these connections from legitimate HTTPS traffic. However, because of the programmatic way that SoftEther generates its certificates, the JA4X is unique to SoftEther. If JA4X were to be implemented into a firewall, blocking traffic to SoftEther VPNs would be trivial. By using a JA4X feed, blocking inbound traffic from SoftEther VPNs would be trivial as well.

Most certificate-issuing organizations will use the same underlying program to generate and sign all of their certificates. Using Internet scan data enriched with JA4X from our friends at Hunt.io, we can examine Issuer Organization = “Microsoft Corporation” as an example.

Figure 10 — Using Internet scan data enriched with JA4X to identify certificates.
Figure 10 — Using Internet scan data enriched with JA4X to identify certificates.

In Figure 10, you can see that 99.8% of observed certificates have the same JA4X. The next one down is very similar, but the third one looks completely different. Let’s pivot on this anomaly.

Figure 11 — Oh look, it’s all Cobalt Strike! Well, that was easy.
Figure 11 — Oh look, it’s all Cobalt Strike! Well, that was easy.

Threat hunting with JA4X on Internet scan data is extremely powerful because rather than looking at the values within a certificate, which, in the case of malware, are usually randomly generated, JA4X looks at how the certificate was generated.

One final example is Sliver C2, which is a newer pentesting framework that is replacing Cobalt Strike in popularity. Like most good pentesting frameworks, Sliver is also heavily used by threat actors as it is designed to be difficult to detect.

Sliver has over 400 lines of code dedicated to randomly generating TLS certificates. As such, each certificate is unique and pivoting on a certificate hash will yield no results.

Figure 12 — Sliver C2 randomly generates TLS certificates.
Figure 12 — Sliver C2 randomly generates TLS certificates.

However, each certificate is also generated by the same application and therefore has the same JA4X. Havoc C2 uses most of the Sliver code so it too has the same JA4X, but can be differentiated by looking at the Org Name and Postal Code length. In either case, both are malware and the JA4X is unique on the Internet. Our friends at driftnet.io offer a JA4X feed and, with it, were able to quickly identify all default Sliver C2s listening on the Internet.

IP address Domain 1293195-ci21745.tw1.ru mobile-atrf.com staging.cupid.blunun.com microsoft.com.updatenetworksinfo.com hlakgabiugalibafnafadsfapian.micsoft.org remote.install-update.zip, apex.ca-utilities.com fareharbor.praetorian-assessment.xyz deniszeleniy.ru prefetch.lnrgov.info mirror-server-ubuntu.com walbridgefinancial.com mol.stoerte.net off-tube.lol americajobmail.site [no domain] [no domain] [no domain] llama.punchcyber.com hide.monster aenabasil.com.br msf.cdn.teams-telemetry.org c0rnbread.com db-postgresql-digital-ninja-do-user-13330434-0.b.db.ondigitaloc ean.com it-enterprise.cloud mikrotik-a01-cdn.info actualizaciones-alemana.cl sd.dgov.red m3m.pw genussdepot. ch torrent.tigre-bleu.net uatleviat.engineers.digital $673991.srvape.com procrastinate-group.com login.good-programmer.dev ptys.sy.gs webdevru.org host-85.ipsec.io
2001:41d0:801:200 0::1535 vps-fefdac43.vps.ovh.net v1887224.hosted-by-vdsina.ru

Table 8 — Sliver C2 List Identified from JA4X Internet Scan 9 September 2023 (this is not a full list just a small excerpt for example purposes). Source: driftnet.io‘s JA4X feed.

These examples show how JA4X can be used to detect and block traffic to SoftEther, Tor, Metasploit, Sliver, Havoc, RAT C2s, and more. Note that TLS certificates are sent in the clear in TLS 1.2 but are encrypted in TLS 1.3 so JA4X is best utilized on proxy servers, firewalls, MDR, NDR and Zero Trust applications that have that level of inspection. JA4X, when combined with JA4, JA4S, JA4H and JA4L provides an unparalleled level of visibility and detection capability. When used in Internet scanning, JA4X is an excellent tool for pivot analysis and hunting down malicious servers, especially when combined with JARM data.

JA4SSH: SSH traffic fingerprinting

JA4SSH fingerprints SSH sessions by looking at SSH packets and providing a small, simple, easy-to-read fingerprint of the session on a configurable rolling basis, every 200 packets by default. With this, we can determine what is happening within the SSH connection, even though the traffic is encrypted, and provide an analyst with a simple set of fingerprints for their analysis.

Note that JA4SSH fingerprints the SSH session, not the SSH applications. For SSH application fingerprinting, I recommend you take a look at HASSH, by my good friend Ben Reardon.

Figure 13 — JA4SSH: SSH traffic fingerprint.
Figure 13 — JA4SSH: SSH traffic fingerprint.
Type of SSH sessionJA4SSH
Interactive shell (normal)c36s36_c51s80_c69s0
Interactive reverse shellc76s76_c71s59_c0s70
SCP file transfer to clientc112s1460_c0s179_c21s0
Table 9 — JA4SSH fingerprint examples.

To understand how SSH traffic works and how to identify tunnels using traffic analysis, I recommend you read these excellent blogs on the subject by Trisul here and here.

In short, SSH packets are padded out to a particular length depending on the cipher algorithm and HMAC used. With chacha20-poly1305, that ends up being 36 bytes. When the client types a character into the SSH terminal, that character is encrypted with the packet padded to 36 bytes and then sent to the server. The server will respond with the same character in a 36-byte packet and that’s when the character is displayed in the terminal window. The client will then send a TCP ACK packet to tell the server that they’re done with the previous transaction. Because of this, a client typing in a terminal will look like Figure 14.

Figure 14 — An interactive forward SSH session.
Figure 14 — An interactive forward SSH session.

In Figure 14, notice that the TCP ACKs are coming from the side doing the SSH requests (client) and the server returns the output of the command at the bottom. The JA4SSH for this looks like c36s36_c51s80_c69s0. So, you see 36/36 and all the ACKs are from the client, the server has sent none, so from these we can easily see that it is an interactive forward SSH session.

In a reverse SSH shell, it’s SSH over SSH so the packets are double padded + HMAC (Figure 15).

Figure 15 — In a reverse SSH shell, it’s SSH over SSH so the packets are double padded + HMAC.
Figure 15 — In a reverse SSH shell, it’s SSH over SSH so the packets are double padded + HMAC.

The JA4SSH for this looks like c76s76_c71s59_c0s70. We can clearly see a common packet length of 76/76, double padded, and all of the ACKs are coming from the server, meaning it is the server side that is doing the typing. It’s important to note that SSH provides encrypted messages, not an encrypted tunnel, so Layer 4 packets, the TCP ACK packets, are sent in the clear. It is with these that we can determine which side is initiating the requests. By using JA4SSH, it is now trivial to detect reverse SSH shells.

Figure 16 — In a SCP file transfer, the TCP Length is maxed out.
Figure 16 — In a SCP file transfer, the TCP Length is maxed out.


JA4: TLS Client Fingerprinting is open source, BSD 3-Clause, the same as JA3. This allows any company or tool currently utilizing JA3 to immediately upgrade to JA4 without delay.

JA4S, JA4L, JA4H, JA4X, JA4SSH, and all future additions (collectively referred to as JA4+), are licensed under the FoxIO License 1.1. This license is permissive for most use cases, including for academic and internal business purposes, but is not permissive for monetization. If, for example, a company would like to use JA4+ internally to help secure their own company, that is permitted. If, for example, a vendor would like to sell JA4+ fingerprinting as part of their product offering, they would need to request an OEM license from us.

JA4+ can and is being implemented into open source tools, see the License FAQ for details.

This licensing allows us to provide JA4+ to the world in a way that is open and immediately usable, but also provides us with a way to fund continued support, research into new methods, and the development of the upcoming JA4+ Database. We want everyone to have the ability to utilize JA4+ and are happy to work with vendors and open source projects to help make that happen.

Figure 17 — If you experience a detection lasting longer than four hours, contact your vendor right away.
Figure 17 — If you experience a detection lasting longer than four hours, contact your vendor right away.


JA4+ provides a suite of modular network fingerprints that are easy to use and easy to share. The use cases for these fingerprints include scanning for threat actors, malware detection, session hijacking prevention, compliance automation, location tracking, DDoS detection, grouping of threat actors, reverse shell detection, and many more. JA4 (TLS Client Fingerprinting), is licensed under BSD 3-Clause, allowing tools running JA3 to immediately upgrade, while JA4+ (JA4S/L/H/X/SSH) is under the FoxIO License, which is permissive for most use cases except monetization. For that the vendor would need to purchase an OEM license, which funds further research and the development of the JA4 database (coming soon). We plan to release a new JA4 method about once per quarter so stay tuned.

JA4+ is available on GitHub. For licensing or questions, reach out to us at FoxIO. You can reach me directly on LinkedIn or Twitter/X.

JA4+ was created by John Althouse with feedback from Josh Atkins, Jeff Atkinson, Joshua Alexander, W., Joe Martin, Ben Higgins, Andrew Morris, Chris Ueland, Ben Schofield, Matthias Vallentin, Valeriy Vorotyntsev, Timothy Noel, Gary Lipsky, and engineers working at GreyNoise, Hunt, Google, ExtraHop, F5, Driftnet, and others.

John Althouse is the Founder of FoxIO and a serial inventor in cyber security.

This post is adapted from the original at FoxIO’s blog.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *