Certain JA3 tokens appear to be failing

[darek292]

Actual behavior A clear and concise description of what the bug is.

I apologize if this is related to #14 - I wasn't sure.

I'm getting an error when using the following JA3 token:

771,4866-4867-4865-49199-49195-49200-49196-158-49191-103-49192-107-163-159-52393-52392-52394-49327-49325-49315-49311-49245-49249-49239-49235-162-49326-49324-49314-49310-49244-49248-49238-49234-49188-106-49187-64-49162-49172-57-56-49161-49171-51-50-157-49313-49309-49233-156-49312-49308-49232-61-60-53-47-255,0-11-10-35-22-23-13-43-45-51,29-23-1035-25-24,0-1-2

The error looks like a spam similar to the following:

goroutine 132 [chan receive]:
main.worker(0xc00010a060, 0xc00010a0c0)
        /home/runner/work/CycleTLS/CycleTLS/golang/index.go:210 +0xe5
created by main.workerPool
        /home/runner/work/CycleTLS/CycleTLS/golang/index.go:204 +0x59

goroutine 133 [chan receive]:
main.worker(0xc00010a060, 0xc00010a0c0)
        /home/runner/work/CycleTLS/CycleTLS/golang/index.go:210 +0xe5
created by main.workerPool
        /home/runner/work/CycleTLS/CycleTLS/golang/index.go:204 +0x59

    at Socket.<anonymous> (xxxxx\node_modules\cycletls\dist\index.js:67:33)
    at Socket.emit (node:events:369:20)
    at addChunk (node:internal/streams/readable:313:12)
    at readableAddChunk (node:internal/streams/readable:288:9)
    at Socket.Readable.push (node:internal/streams/readable:227:10)
    at Pipe.onStreamRead (node:internal/stream_base_commons:190:23)
Error: Command failed: taskkill /pid 22720 /T /F
ERROR: The process with PID 20108 (child process of PID 22720) could not be terminated.
Reason: There is no running instance of the task.

    at ChildProcess.exithandler (node:child_process:326:12)
    at ChildProcess.emit (node:events:369:20)
    at maybeClose (node:internal/child_process:1067:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5) {
  killed: false,
  code: 255,
  signal: null,
  cmd: 'taskkill /pid 22720 /T /F'
}

Expected behavior A clear and concise description of what you expected to
happen.

No error is raised and the JA3 token is parsed & spoofed successfully

To Reproduce Steps to reproduce the behavior

const fetch = require('node-fetch')
const initCycleTLS = require('cycletls')

async function start () {
  const fetchResp = await fetch('https://ja3er.com/json')
  const ja3 = (await fetchResp.json()).ja3
  // ja3 = "771,4866-4867-4865-49199-49195-49200-49196-158-49191-103-49192-107-163-159-52393-52392-52394-49327-49325-49315-49311-49245-49249-49239-49235-162-49326-49324-49314-49310-49244-49248-49238-49234-49188-106-49187-64-49162-49172-57-56-49161-49171-51-50-157-49313-49309-49233-156-49312-49308-49232-61-60-53-47-255,0-11-10-35-22-23-13-43-45-51,29-23-1035-25-24,0-1-2"

  const cycleTLS = await initCycleTLS()
  const response = await cycleTLS('https://ja3er.com/json', {
    ja3,
    userAgent: 'node-fetch/1.0 (+https://github.com/bitinn/node-fetch)',
  }, 'get')

  console.log(response)

  cycleTLS.exit()
}

start()

Additional Information

I also want to mention that in addition to the above this library seems to strain my CPU (5950X) quite a lot for some reason.

const initCycleTLS = require('cycletls')

async function start () {
  // await initCycleTLS()

  while (true) {
    await new Promise(resolve => setTimeout(resolve, 2000))
    console.log('sleep')
  }
}

start()

Uncommenting the initCycleTLS() bumps my CPU from 50c to 75c, I'm not sure if this is because of the Golang process it spawns, but it does seem excessive? mytls library does not appear to have this issue, CPU remains the same, no additional load.

Example:

• Operating System information (e.g. Ubuntu 18.04): Windows 10 @ cycletls@0.0.12
• Node version: v15.12.0
• Golang version: Golang isn't installed

[Danny-Dasilva]

Good catch, thanks for the info. This Ja3 token is actually raising a stack overflow error in Golang causing the failure that appears.
I'm looking into this and will update when I figure out exactly where the memory leak is.

The library should not be raising CPU usage from just the import. I believe this may be cause by the fact that Golang isn't installed but I'll investigate this.

[Danny-Dasilva]

Follow up: it appears that the issue lies with the TLSExtension number 22 in the SSL Extensions section of the token 0-11-10-35-(22)-23-13-43-45-51,29-23-1035-25-24. Will update the repo once I find the correct extension to cover this.

[darek292]

Thanks for looking into this! As for the CPU usage, it looks like I can reliably reproduce this even on my CentOS servers where a single vCPU blasts off to 100% (mytls doesn't appear to exhibit the same increase and stays at 2-3%)

[darek292]

@Danny-Dasilva - I can confirm the CPU temp/load is resolved with the latest update, 0.0.12 shows the increase in temps and load, but 0.0.13 is completely fine, so thanks for that.

I did notice that the following JA3 fingerprint is failing, but the one given in the example is now OK.

771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27,,

I'll run some tests to see how this update does.

[darek292]

@89z

Thanks for the comment, I actually just pointed my browser to https://ja3er.com/form, which tells me that my JA3 string right now is:

771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27,,

Using this it fails (most likely due to what you mentioned, 11 and 11).

I then tried to use this in the JA3 argument but that just fails.

My current user agent is
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36

[darek292]

{"agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36", "cert_compression_algs": [2, 0, 2], "cluster": 2, "cluster_seen": 73166682, "seen": 41235184, "seen_total": 210347850, "id": "8466c4390d4bc355", "frac_seen": 0.19603330388211718, "rank": 2, "supported_versions": [10, 10, 3, 4, 3, 3, 3, 2, 3, 1], "addr": "82.27.52.79", "cipher_suites": [10, 10, 19, 1, 19, 2, 19, 3, 192, 43, 192, 47, 192, 44, 192, 48, 204, 169, 204, 168, 192, 19, 192, 20, 0, 156, 0, 157, 0, 47, 0, 53], "port": 62732, "record_size_limit": [], "client_hello": "1603010200010001fc03031ebd9320ab3f2cf87f18a47245f85b047e0f587cfcb7e9c7325bd95e53c9c53c20b2296dffe3d92db8484d259fc1ad5dae1d8a38b7d6627df212279532aad203ef0020caca130113021303c02bc02fc02cc030cca9cca8c013c014009c009d002f003501000193baba00000000001d001b000018636c69656e742e746c7366696e6765727072696e742e696f00170000ff01000100000a000a00084a4a001d00170018000b00020100002300000010000e000c02683208687474702f312e31000500050100000000000d0012001004030804040105030805050108060601001200000033002b00294a4a000100001d002013d8da50bdfb92e8012dc7bb7ba8b15815376111ad89fb9237b94ad912c12715002d00020101002b000b0a9a9a0304030303020301001b00030200024469000500030268326a6a000100001500bb00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", "pt_fmts": [1, 0], "psk_key_exchange_modes": [1], "tls_version": 769, "ch_version": 771, "compression_methods": [0], "nid": -8906215463763328171, "sni": "client.tlsfingerprint.io", "curves": [0, 8, 10, 10, 0, 29, 0, 23, 0, 24], "sig_algs": [0, 16, 4, 3, 8, 4, 4, 1, 5, 3, 8, 5, 5, 1, 8, 6, 6, 1], "key_share": [10, 10, 0, 1, 0, 29, 0, 32], "cluster_fps": 52, "cluster_frac": 0.3478366049379635, "extensions": [10, 10, 0, 0, 0, 23, 255, 1, 0, 10, 0, 11, 0, 35, 0, 16, 0, 5, 0, 13, 0, 18, 0, 51, 0, 45, 0, 43, 0, 27, 68, 105, 10, 10, 0, 21], "alpn": [0, 12, 2, 104, 50, 8, 104, 116, 116, 112, 47, 49, 46, 49]}

[darek292]

What would be the best way to say find my browser's fingerprint? It's a bit odd as sometimes it's giving:

771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27,,

And other times:

771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-21,29-23-24,0

Basically adding the following at the end: -21,29-23-24,0. Unsure what's causing it. But neither of them work unfortunately.

I'm trying to see if I can successfully spoof my browser fingerprint in my JS code, but using Chrome that's giving issues at least. Firefox worked without issues.

[frzsombor]

I was experimenting with JA3 string I found online, and some of them are still causing different types of bugs/errors.
I'm just trying to help, so for testing, here are a few of them.

---

Error (same problem as in #42):

Error: runtime: goroutine stack exceeds 1000000000-byte limit
runtime: sp=0xc020560318 stack=[0xc020560000, 0xc040560000]
fatal error: stack overflow

caused by:

769,49200-49196-49192-49188-49172-49162-163-159-107-106-57-56-136-135-49202-49198-49194-49190-49167-49157-157-61-53-132-49199-49195-49191-49187-49171-49161-162-158-103-64-51-50-154-153-69-68-49201-49197-49193-49189-49166-49156-156-60-47-150-65-7-49169-49159-49164-49154-5-4-49170-49160-22-19-49165-49155-10-21-18-9-255,0-11-10-13-15-21,14-13-25-11-12-24-9-10-22-23-8-6-7-20-21-4-5-18-19-1-2-3-15-16-17,0-1-2
769,4-5-47-51-50-10-22-19-9-21-18-3-8-20-17-255,,,
769,53-47-255,0-11-10-35-15,14-13-25-11-12-24-9-10-22-23-8-6-7-20-21-4-5-18-19-1-2-3-15-16-17,0-1-2
769,49200-49196-49192-49188-49172-49162-163-159-107-106-57-56-136-135-49202-49198-49194-49190-49167-49157-157-61-53-132-49170-49160-22-19-49165-49155-10-49199-49195-49191-49187-49171-49161-162-158-103-64-51-50-154-153-69-68-49201-49197-49193-49189-49166-49156-156-60-47-150-65-49169-49159-49164-49154-5-4-255,0-11-10-13-15,14-13-25-11-12-24-9-10-22-23-8-6-7-20-21-4-5-18-19-1-2-3-15-16-17,0-1-2
769,49200-49196-49192-49188-49172-49162-163-159-107-106-57-56-136-135-49202-49198-49194-49190-49167-49157-157-61-53-132-49199-49195-49191-49187-49171-49161-162-158-103-64-51-50-69-68-49201-49197-49193-49189-49166-49156-156-60-47-65-49169-49159-49164-49154-5-4-49170-49160-22-19-49165-49155-10-21-18-9-255,0-11-10-13-15-21,14-13-25-11-12-24-9-10-22-23-8-6-7-20-21-4-5-18-19-1-2-3-15-16-17,0-1-2
769,49172-49162-57-56-136-135-49167-49157-53-132-49171-49161-51-50-154-153-69-68-49166-49156-47-150-65-255,0-11-10-35-15,25-24-22-23-20-21-18-19-15-16-17,0-1-2
770,49162-49172-136-135-57-56-49167-49157-132-53-49159-49161-49169-49171-69-68-102-51-50-49164-49166-49154-49156-150-65-5-4-47-49160-49170-22-19-49165-49155-65279-10,0-65281-10-11-35-13172-30031-5,23-24-25,0

---

An other error:

Error: panic: runtime error: index out of range [0] with length 0

caused by:

771,49195-49199-52393-52392-49196-49200-49161-49171-49162-49172-156-157-47-53-10,65281-0-23-35-13-5-13172-18-11-10,29-23-24,0

---

Again, as I just found these online while searching for strings other than my own browsers, so is it possible that all of these are just "invalid" strings for some reason, but I can not verify this right now.

[Danny-Dasilva]

I was experimenting with JA3 string I found online, and some of them are still causing different types of bugs/errors. I'm just trying to help, so for testing, here are a few of them.

@frzsombor I dont think your comment has enough information to be helpful. The user @darek292 provided problem JA3, as well as the source:

#39 (comment)

So you just saying "oh I got these somewhere online" is about as useful as just manually constructing random JA3 until we find one that breaks. Yes, the package should be able to handle arbitrary JA3 (and fail gracefully), but I dont think were at that point yet. So until then, we need the source of any problem JA3, so we can address as needed. Thanks.

To the point of gracefully exiting as of 0.0.14 we should be returning a message of Extension {{ extension number }} is not Supported by CycleTLS please raise an issue on failed ja3 token extensions. This obviously does not solve the malformed extension issue ja3er is producing but should no longer cause a stack overflow on unsupported extensions.

#51 (comment)

CycleTLS/cycletls/errors.go

Lines 84 to 86 in 473bed8

	func (w *errExtensionNotExist) Error() string {
	return fmt.Sprintf("Extension {{ %s }} is not Supported by CycleTLS please raise an issue", w.Context)
	}

CycleTLS/cycletls/roundtripper.go

Lines 247 to 254 in 473bed8

	var exts []utls.TLSExtension
	for _, e := range extensions {
	te, ok := extMap[e]
	if !ok {
	return nil, raiseExtensionError(e)
	}
	exts = append(exts, te)
	}

[Danny-Dasilva]

and probably my code too, is not valid. Quoting from RFC 8446 [1]:

Makes sense, this version is not actually set or used anywhere in the code (I believe I removed this some time ago).

CycleTLS/cycletls/roundtripper.go

Line 270 in 473bed8

_ = vid

Just checked using wireshark and tls 1.0 is being sent on the initial handshake.

So I guess my question is what is what scenario where we would want to manually set a higher default version?

Plugin link in case you want to test yourself.

[frzsombor]

A bit off-topic, as not exactly related to this specific issue, just found an awesome website showing a byte-by-byte walkthrough of a TLS connection. Sharing it as right now that's all I can maybe help with. Hope someone finds it useful:
TLS v1.2: https://tls.ulfheim.net/
TLS v1.3: https://tls13.ulfheim.net/

[Danny-Dasilva]

Closing this as I don't think there is much relevant in this to justify keeping it open.