{"article":{"slug":"choose-your-backend-three-tls-bugs-in-goahead","title":"Choose Your Backend: Three TLS Bugs in GoAhead","subtitle":null,"summary":"FoxIO researcher Sébastien Féry details three independent bugs in the TLS integrations of GoAhead, an embedded web server in hundreds of millions of IoT, firewall and industrial devices: revoked client certificates accepted on OpenSSL builds (CVSS 9.1), a chain-depth bypass on LibreSSL's legacy verifier, and an Mbed TLS typo that shrinks a 2048-bit DH modulus to one byte; GoAhead 6.1.1 fixes them.","content_type":"research","language":"en","canonical_url":"https://foxio.io/blog/choose-your-backend-three-tls-bugs-in-goahead","author":{"name":"Sébastien Féry","url":null,"person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"FoxIO","url":"https://foxio.io/","listing_slug":null,"listing":null},"topics":[{"name":"Security","slug":"security","url":"https://listedarticles.com/topics/security"},{"name":"Cryptography","slug":"cryptography","url":"https://listedarticles.com/topics/cryptography"},{"name":"IoT","slug":"iot","url":"https://listedarticles.com/topics/iot"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":3243,"reading_minutes":14,"published_at":"2026-10-26T00:00:00.000Z","added_at":"2026-10-27T20:09:13.813Z","updated_at":"2026-10-27T20:09:13.813Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":true},"profile_url":"https://listedarticles.com/articles/choose-your-backend-three-tls-bugs-in-goahead","markdown_url":"https://listedarticles.com/articles/choose-your-backend-three-tls-bugs-in-goahead.md","example":false,"citation":"Sébastien Féry, FoxIO. \"Choose Your Backend: Three TLS Bugs in GoAhead.\" 26 Oct 2026. https://foxio.io/blog/choose-your-backend-three-tls-bugs-in-goahead (all-rights-reserved)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://foxio.io/blog/choose-your-backend-three-tls-bugs-in-goahead"},"body_markdown":"# Choose Your Backend: Three TLS Bugs in GoAhead\n\n![](https://framerusercontent.com/images/m6rEnNeSNpZIvF7pgpCWPegD8.png?width=1516&height=650)\n\n*Sébastien Féry · FoxIO · October 26, 2026*\n\n## TLDR\n\nGoAhead is used in hundreds of millions of IoT, Firewall, OT, and Military devices including those from Palo Alto Networks, Comcast, D-Link, HP, Canon, Honeywell, GE, Oracle, Siemens, Rockwell, Digi, Lockheed Martin, Boeing, and more.\n\nThree independent bugs in GoAhead's TLS integrations can leave revoked client certificates accepted, encrypted sessions recoverable to an observer or a configured chain-depth limit unenforced. Exposure depends on the TLS library and the verification settings built into the device:\n\n- OpenSSL-compatible backend - Critical, CVSS 9.1 - CRL loaded but not enforced, revoked client certificates are silently accepted. GOAHEAD-SA-2026-0006.\n- LibreSSL legacy verifier - High, CVSS 7.4 - An over-depth client chain is accepted when client certificates are required but issuer checking is disabled. This bypasses the chain-depth restriction. GOAHEAD-SA-2026-0004.\n- Mbed TLS - Medium, CVSS 5.9 - A buffer-length typo reduces a 2048-bit DH modulus to one byte. TLS 1.2 DHE\\_RSA sessions are decryptable when the client accepts the broken parameters. GOAHEAD-SA-2026-0005.\n\n| TLS build | GoAhead versions | Required configuration | Fix or mitigation |\n| --- | --- | --- | --- |\n| **OpenSSL-compatible backend** | >= 3.4.5, <= 6.1.0 | mTLS enabled with a CRL configured. Revoked client certificates remain accepted even with issuer verification enabled. | Upgrade to **6.1.1 or later**. |\n| **Mbed TLS backend** | >= 4.0.2, <= 6.1.0 | TLS 1.2 DHE\\_RSA negotiated with a client that accepts the broken DH parameters. | Upgrade to **6.1.1 or later**, disable finite-field DHE suites, or use the OpenSSL backend. |\n| **LibreSSL legacy verifier** — 3.2.x or 3.3.2–3.3.6 | <= 6.1.0 | `VERIFY_PEER=1` and `VERIFY_ISSUER=0`. An over-depth client chain is accepted. | Enable `VERIFY_ISSUER=1` with a trusted CA bundle, or use OpenSSL / LibreSSL 4.x. |\n\n## Background\n\nGoAhead is an embedded web server used for device management: routers, switches, printers, gateways, and industrial controls and is deployed in hundreds of millions of devices.\n\nEach finding below affects a specific subset of those deployments, depending on the build and configuration.\n\nGoAhead supports two TLS backends: OpenSSL, the default, and MbedTLS. The OpenSSL backend also works with compatible libraries such as LibreSSL.\n\nGoAhead takes a compile-time approach regarding certain configurations:\n\n- `ME_GOAHEAD_SSL_VERIFY_PEER=1` requires a client certificate.\n\n- `ME_GOAHEAD_SSL_AUTHORITY` points at a PEM bundle of trusted CAs.\n\n- `ME_GOAHEAD_SSL_VERIFY_ISSUER=1` requires the certificate chain to establish issuer trust against that bundle.\n\n- `ME_GOAHEAD_SSL_REVOKE` points at a PEM-encoded Certificate Revocation List.\n\n- The OpenSSL backend sets a chain-depth limit of 10 (`VERIFY_DEPTH`).\n\n## OpenSSL-compatible builds\n\n![](https://framerusercontent.com/images/hpSvyAUiUW81HqH23INxo9F4GCg.png?width=1186&height=418)\n\nGoAhead's OpenSSL backend loads the configured CRL into the certificate store but never enables revocation checking. Revoked client certificates can therefore complete the mTLS handshake even when issuer verification is enabled.\n\nThe CRL is loaded in `sslOpen()`:\n\n```\n// src/openssl.c\nif (ME_GOAHEAD_SSL_REVOKE && *ME_GOAHEAD_SSL_REVOKE) {\n store = SSL_CTX_get_cert_store(sslctx);\n if (!X509_STORE_load_locations(store, ME_GOAHEAD_SSL_REVOKE, 0)) {\n error(\"Cannot load certificate revoke list: %s\", ME_GOAHEAD_SSL_REVOKE);\n sslClose();\n return -1;\n }\n}\n```\n\n```\n// src/openssl.c\nif (ME_GOAHEAD_SSL_REVOKE && *ME_GOAHEAD_SSL_REVOKE) {\n store = SSL_CTX_get_cert_store(sslctx);\n if (!X509_STORE_load_locations(store, ME_GOAHEAD_SSL_REVOKE, 0)) {\n error(\"Cannot load certificate revoke list: %s\", ME_GOAHEAD_SSL_REVOKE);\n sslClose();\n return -1;\n }\n}\n```\n\n```\n// src/openssl.c\nif (ME_GOAHEAD_SSL_REVOKE && *ME_GOAHEAD_SSL_REVOKE) {\n store = SSL_CTX_get_cert_store(sslctx);\n if (!X509_STORE_load_locations(store, ME_GOAHEAD_SSL_REVOKE, 0)) {\n error(\"Cannot load certificate revoke list: %s\", ME_GOAHEAD_SSL_REVOKE);\n sslClose();\n return -1;\n }\n}\n```\n\nOpenSSL requires `X509_V_FLAG_CRL_CHECK` to enable CRL checking. Loading the file into the store does not set that flag. Without CRL or OCSP checking enabled, `check_revocation()` returns success before checking revocation status:\n\n```\n// OpenSSL crypto/x509/x509_vfy.c\nint crl_check_enabled =\n (ctx->param->flags &\n (X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL)) != 0;\n...\nif (!crl_check_enabled && !ocsp_check_enabled)\n return 1;\n```\n\n```\n// OpenSSL crypto/x509/x509_vfy.c\nint crl_check_enabled =\n (ctx->param->flags &\n (X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL)) != 0;\n...\nif (!crl_check_enabled && !ocsp_check_enabled)\n return 1;\n```\n\n```\n// OpenSSL crypto/x509/x509_vfy.c\nint crl_check_enabled =\n (ctx->param->flags &\n (X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL)) != 0;\n...\nif (!crl_check_enabled && !ocsp_check_enabled)\n return 1;\n```\n\nGoAhead never sets either CRL flag. OpenSSL returns success without checking the loaded list. The application's callback would reject error 23, `X509_V_ERR_CERT_REVOKED`, through its `default:` branch, but the verifier never generates that error.\n\nOn GoAhead 6.1.0 with OpenSSL 3.6.2, a revoked CA-signed client certificate completed the mTLS handshake with issuer verification enabled. The verification callback reported error 0 throughout the chain:\n\n```\nVERIFY_CB: preverify_ok=1 error=0(ok) depth=1\nVERIFY_CB: preverify_ok=1 error=0(ok) depth=0\n```\n\n```\nVERIFY_CB: preverify_ok=1 error=0(ok) depth=1\nVERIFY_CB: preverify_ok=1 error=0(ok) depth=0\n```\n\n```\nVERIFY_CB: preverify_ok=1 error=0(ok) depth=1\nVERIFY_CB: preverify_ok=1 error=0(ok) depth=0\n```\n\n`X509_STORE_load_locations()` succeeds, so startup produces no warning that CRL enforcement is inactive.\n\n**Affected:** GoAhead 3.4.5 through 6.1.0 using the OpenSSL-compatible backend with a CRL configured. The security impact is clearest with `VERIFY_PEER=1`, a trusted CA bundle, and `VERIFY_ISSUER=1`: a previously trusted but revoked identity retains access. When issuer checking is disabled, the CRL defect remains but unknown issuers are already accepted by policy.\n\n**Fix**: 6.1.1 now checks after loading the CRL:\n\n```\n+ X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK);\n```\n\n```\n+ X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK);\n```\n\n```\n+ X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK);\n```\n\n## Mbed TLS builds\n\n![](https://framerusercontent.com/images/4BLyEmvMcJXcmZDmMxDNt9DpE80.png?width=1508&height=1024)\n\nGoAhead's mbed TLS backend configures the RFC 3526 2048-bit DH group through `mbedtls_ssl_conf_dh_param_bin()`. The modulus length passed to that function is taken from the generator buffer:\n\n```\n// src/mbedtls.c\ncuchar dhm_p[] = MBEDTLS_DHM_RFC3526_MODP_2048_P_BIN; // 256 bytes\ncuchar dhm_g[] = MBEDTLS_DHM_RFC3526_MODP_2048_G_BIN; // 1 byte: 0x02\n\nmbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g));\n```\n\n```\n// src/mbedtls.c\ncuchar dhm_p[] = MBEDTLS_DHM_RFC3526_MODP_2048_P_BIN; // 256 bytes\ncuchar dhm_g[] = MBEDTLS_DHM_RFC3526_MODP_2048_G_BIN; // 1 byte: 0x02\n\nmbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g));\n```\n\n```\n// src/mbedtls.c\ncuchar dhm_p[] = MBEDTLS_DHM_RFC3526_MODP_2048_P_BIN; // 256 bytes\ncuchar dhm_g[] = MBEDTLS_DHM_RFC3526_MODP_2048_G_BIN; // 1 byte: 0x02\n\nmbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g));\n```\n\nThe size arguments tell mbed TLS how many bytes to read from each buffer. The call uses `sizeof(dhm_g)` for both, even though `dhm_g` is only one byte long. The length for `dhm_p` should be `sizeof(dhm_p)`, or 256 bytes.\n\nAs a result, mbed TLS reads only the first byte of `dhm_p`: `0xFF` (255). The remaining 255 bytes are discarded. It accepts this value and sends it to the client during the TLS 1.2 DHE\\_RSA handshake:\n\n```\n0c 00 01 0d 00 01 ff 00 01 02 00 01 08\n```\n\n```\n0c 00 01 0d 00 01 ff 00 01 02 00 01 08\n```\n\n```\n0c 00 01 0d 00 01 ff 00 01 02 00 01 08\n```\n\nIn ServerKeyExchange, `00 01 ff` identifies a one-byte DH parameter with the value 255. It should contain the full 256-byte value.\n\nThe broken parameters leave just eight possible shared-secret values : `01`, `02`, `04`, `08`, `10`, `20`, `40`and `80` in hex. An observer can try each candidate and identify the correct one by checking whether it decrypts the captured traffic successfully.\n\nIn the attached PoC, I managed to reproduce the shared secret after five attempts. It matched the client's secret, confirming that the same TLS session keys could be derived to decrypt the HTTP exchange.\n\nA passive observer can decrypt captured sessions using the recorded handshake and encrypted application records completely out of band.\n\nExploitation requires a client that accepts the broken DH parameters. The tested OpenSSL client rejected them with `DH_check_params_ex: modulus too small`. Permissive clients, including custom or embedded implementations without a minimum-size check, can complete a decryptable session. ECDHE sessions and TLS 1.3 are unaffected by this configured finite-field group.\n\n**Affected:** GoAhead 4.0.2 through 6.1.0 using the mbed TLS backend with TLS 1.2 DHE\\_RSA suites, where the client accepts the parameters. The typo entered in 2018 during migration to the binary-parameter API and survived the April 2024 TLS refactor. Mbed TLS 4.x removed the `TLS_DHE_*` suites, so this DHE path isn't impacted.\n\nIf you see any of these suites in the JA4S logs of your environment, you might be impacted (eg. `t120100_009f_1ca028f07214`)\n\n```\n0014 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA\n0015 TLS_DHE_RSA_WITH_DES_CBC_SHA\n0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA\n0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA\n0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA\n0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA\n0067 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256\n006B TLS_DHE_RSA_WITH_AES_256_CBC_SHA256\n0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA\n009A TLS_DHE_RSA_WITH_SEED_CBC_SHA\n009E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256\n009F TLS_DHE_RSA_WITH_AES_256_GCM_SHA384\n00BE TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256\n00C4 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256\nC044 TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256\nC045 TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384\nC052 TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256\nC053 TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384\n0C07C TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256\nC07D TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384\nC09E TLS_DHE_RSA_WITH_AES_128_CCM\nC09F TLS_DHE_RSA_WITH_AES_256_CCM\nC0A2 TLS_DHE_RSA_WITH_AES_128_CCM_8\nC0A3 TLS_DHE_RSA_WITH_AES_256_CCM_8\nCCAA TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256\n```\n\n```\n0014 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA\n0015 TLS_DHE_RSA_WITH_DES_CBC_SHA\n0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA\n0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA\n0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA\n0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA\n0067 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256\n006B TLS_DHE_RSA_WITH_AES_256_CBC_SHA256\n0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA\n009A TLS_DHE_RSA_WITH_SEED_CBC_SHA\n009E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256\n009F TLS_DHE_RSA_WITH_AES_256_GCM_SHA384\n00BE TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256\n00C4 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256\nC044 TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256\nC045 TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384\nC052 TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256\nC053 TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384\n0C07C TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256\nC07D TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384\nC09E TLS_DHE_RSA_WITH_AES_128_CCM\nC09F TLS_DHE_RSA_WITH_AES_256_CCM\nC0A2 TLS_DHE_RSA_WITH_AES_128_CCM_8\nC0A3 TLS_DHE_RSA_WITH_AES_256_CCM_8\nCCAA TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256\n```\n\n```\n0014 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA\n0015 TLS_DHE_RSA_WITH_DES_CBC_SHA\n0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA\n0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA\n0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA\n0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA\n0067 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256\n006B TLS_DHE_RSA_WITH_AES_256_CBC_SHA256\n0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA\n009A TLS_DHE_RSA_WITH_SEED_CBC_SHA\n009E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256\n009F TLS_DHE_RSA_WITH_AES_256_GCM_SHA384\n00BE TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256\n00C4 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256\nC044 TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256\nC045 TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384\nC052 TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256\nC053 TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384\n0C07C TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256\nC07D TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384\nC09E TLS_DHE_RSA_WITH_AES_128_CCM\nC09F TLS_DHE_RSA_WITH_AES_256_CCM\nC0A2 TLS_DHE_RSA_WITH_AES_128_CCM_8\nC0A3 TLS_DHE_RSA_WITH_AES_256_CCM_8\nCCAA TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256\n```\n\nA sample query you might want to run (in Splunk or other) would look like:\n\n```\nDestIP = (GoAhead Device)\nAND\nJA4S = *_0014_\n```\n\n```\nDestIP = (GoAhead Device)\nAND\nJA4S = *_0014_\n```\n\n```\nDestIP = (GoAhead Device)\nAND\nJA4S = *_0014_\n```\n\nreplacing 0014 with the curves listed above.\n\n**Fix**: 6.1.1 fixed the typo\n\n```\n- mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g))\n+ mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_p), dhm_g, sizeof(dhm_g))\n```\n\n```\n- mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g))\n+ mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_p), dhm_g, sizeof(dhm_g))\n```\n\n```\n- mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g))\n+ mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_p), dhm_g, sizeof(dhm_g))\n```\n\n## LibreSSL builds\n\n![](https://framerusercontent.com/images/9eCRwNjx8S9ZZpdm2apJKC9yN3k.png?width=1786&height=546)\n\nEssentially, an attacker can present a certificate chain longer than GoAhead’s limit and still complete the mTLS handshake on an affected build. LibreSSL reports an issuer error instead of a depth error. GoAhead accepts that issuer error when issuer checking is disabled.\n\nGoAhead 6.1.0 sets a chain-depth limit of 10 using `SSL_CTX_set_verify_depth(sslctx, VERIFY_DEPTH)`. Its verification callback also checks the depth:\n\n```\n// src/openssl.c\nif (ok && VERIFY_DEPTH < depth) {\n if (error == 0) {\n error = X509_V_ERR_CERT_CHAIN_TOO_LONG;\n }\n}\n```\n\n```\n// src/openssl.c\nif (ok && VERIFY_DEPTH < depth) {\n if (error == 0) {\n error = X509_V_ERR_CERT_CHAIN_TOO_LONG;\n }\n}\n```\n\n```\n// src/openssl.c\nif (ok && VERIFY_DEPTH < depth) {\n if (error == 0) {\n error = X509_V_ERR_CERT_CHAIN_TOO_LONG;\n }\n}\n```\n\nThat check only assigns a depth error when `ok` is true, the reported depth exceeds the limit, and no error is already present. The callback then classifies the error:\n\n```\ncase X509_V_ERR_CERT_UNTRUSTED:\ncase X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY:\n if (ME_GOAHEAD_SSL_VERIFY_ISSUER) {\n ok = 0;\n }\n break;\n\ncase X509_V_ERR_CERT_CHAIN_TOO_LONG:\ndefault:\n ok = 0;\n break;\n```\n\n```\ncase X509_V_ERR_CERT_UNTRUSTED:\ncase X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY:\n if (ME_GOAHEAD_SSL_VERIFY_ISSUER) {\n ok = 0;\n }\n break;\n\ncase X509_V_ERR_CERT_CHAIN_TOO_LONG:\ndefault:\n ok = 0;\n break;\n```\n\n```\ncase X509_V_ERR_CERT_UNTRUSTED:\ncase X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY:\n if (ME_GOAHEAD_SSL_VERIFY_ISSUER) {\n ok = 0;\n }\n break;\n\ncase X509_V_ERR_CERT_CHAIN_TOO_LONG:\ndefault:\n ok = 0;\n break;\n```\n\nError 20, `UNABLE_TO_GET_ISSUER_CERT_LOCALLY`, is tolerated when issuer checking is disabled. Error 22, `CERT_CHAIN_TOO_LONG`, is rejected.\n\nLibreSSL 3.2.x and 3.3.2–3.3.6 use the legacy X.509 verifier by default for peer verification. Its chain-building loop contains a FIXME comment (which is what prompted a look at GoAhead in the first place):\n\n```\n// LibreSSL src/lib/libcrypto/x509/x509_vfy.c\nfor (;;) {\n /* FIXME: If this happens, we should take\n * note of it and, if appropriate, use the\n * X509_V_ERR_CERT_CHAIN_TOO_LONG error code\n * later.\n */\n if (depth < num)\n break;\n```\n\n```\n// LibreSSL src/lib/libcrypto/x509/x509_vfy.c\nfor (;;) {\n /* FIXME: If this happens, we should take\n * note of it and, if appropriate, use the\n * X509_V_ERR_CERT_CHAIN_TOO_LONG error code\n * later.\n */\n if (depth < num)\n break;\n```\n\n```\n// LibreSSL src/lib/libcrypto/x509/x509_vfy.c\nfor (;;) {\n /* FIXME: If this happens, we should take\n * note of it and, if appropriate, use the\n * X509_V_ERR_CERT_CHAIN_TOO_LONG error code\n * later.\n */\n if (depth < num)\n break;\n```\n\nThe loop stops building the chain without recording the depth error. The failure later reaches GoAhead as error 20. With `VERIFY_ISSUER=0`, the callback accepts it.\n\nOn GoAhead 6.1.0 linked against LibreSSL 3.3.6, a 17-certificate chain rooted in an attacker-controlled, self-signed CA produced the following callback trace:\n\n```\nVERIFY_CB_ENTRY: preverify_ok=0 error=20(unable to get local issuer certificate) depth=10\nVERIFY_CB_ENTRY: preverify_ok=1 error=20(unable to get local issuer certificate) depth=9\nVERIFY_CB_ENTRY: preverify_ok=1 error=20(unable to get local issuer certificate) depth=8\n```\n\n```\nVERIFY_CB_ENTRY: preverify_ok=0 error=20(unable to get local issuer certificate) depth=10\nVERIFY_CB_ENTRY: preverify_ok=1 error=20(unable to get local issuer certificate) depth=9\nVERIFY_CB_ENTRY: preverify_ok=1 error=20(unable to get local issuer certificate) depth=8\n```\n\n```\nVERIFY_CB_ENTRY: preverify_ok=0 error=20(unable to get local issuer certificate) depth=10\nVERIFY_CB_ENTRY: preverify_ok=1 error=20(unable to get local issuer certificate) depth=9\nVERIFY_CB_ENTRY: preverify_ok=1 error=20(unable to get local issuer certificate) depth=8\n```\n\nThe handshake completed and the resource behind the client-certificate requirement returned HTTP 200. The same GoAhead source built against LibreSSL 4.3.1 received error 22 at depth 10 and rejected the chain.\n\nWith `VERIFY_ISSUER=0`, ordinary self-signed certificates are already allowed. The over-depth chain bypasses the separate chain-depth restriction because the verifier reports a tolerated issuer error. Deployments requiring a trusted client CA reject it.\n\n**Demonstrated configuration:** GoAhead 6.1.0 with the LibreSSL legacy verifier, `ME_GOAHEAD_SSL_VERIFY_PEER=1`, and `ME_GOAHEAD_SSL_VERIFY_ISSUER=0`. Enabling issuer trust rejects error 20. OpenSSL, BoringSSL, AWS-LC, and LibreSSL 4.x builds are not exposed to this legacy-verifier trigger.\n\n## Conclusion\n\nAll three findings affect GoAhead's integration with its TLS libraries. CRL enforcement depends on a verification flag, DH parameters depend on the supplied buffer lengths, and chain-depth enforcement depends on how verification errors are handled. None of these defects prevents the affected handshake from completing.\n\nThe backend and build configuration determine which defects apply. LibreSSL builds can inherit both the CRL defect in the OpenSSL-compatible backend and the legacy verifier's depth issue. The mbed TLS backend uses a separate verification path but is affected by the DH truncation when a client accepts the parameters.\n\nTo find impacted publicly facing servers in your fleet, here are the JA4Scan-TLS fingerprints that map to the different backends:\n\n| | |\n| --- | --- |\n| Server (GoAhead 6.1.x) | JA4Scan-TLS |\n| OpenSSL 3.6.2 | 03100h0s00sn\\_1fe27f6025fb\\_d06dc4648d2f\\_sr00ss537461 |\n| LibreSSL 3.3.6 | 03100h0s00s0\\_9d52559f55bc\\_c64486648d2f\\_sr00sc24603c |\n| LibreSSL 4.3.1 (depth bypass unaffected) | 03100h0r00s0\\_9d52559f55bc\\_c64486206461\\_sr00scc98ba1 |\n| mbedTLS 3.6.6 | 23100h0s01s0\\_d7d3025021f4\\_0475c5cede0d\\_sr0ss02265cf |\n\nRead the full blog post about JA4Scan here:\n\n\n\n## POC\n\nReproduction code is available at \n\n## Timeline\n\n- April 22 2026 - LibreSSL report\n\n- April 27 2026 - MbedTLS report\n\n- April 30 2026 - OpenSSL report\n\n- Aug 2 2026 - GoAhead 6.1.1 released\n\n- Oct 12 2026 - Advisories published\n\n- Oct 26 2026 - Blog published\n\n## References\n\n[GOAHEAD-SA-2026-0004 / CVE-2026-115884](https://github.com/embedthis/goahead/security/advisories/GHSA-r392-vqwx-3r4g): mTLS chain-depth bypass\n\n[GOAHEAD-SA-2026-0005](https://github.com/embedthis/goahead/security/advisories/GHSA-fmvx-2xfx-2gq4): MbedTLS DH parameter truncation\n\n[GOAHEAD-SA-2026-0006 / CVE-2026-115881](https://github.com/embedthis/goahead/security/advisories/GHSA-5m75-xq69-c3c5): OpenSSL CRL checking disabled\n\n[GoAhead SSL documentation](https://www.embedthis.com/goahead/doc/users/ssl.html)\n\n[OpenSSL verification flags](https://docs.openssl.org/3.6/man3/X509_VERIFY_PARAM_set_flags/)\n\n[OpenSSL](https://docs.openssl.org/3.6/man3/X509_STORE_add_cert/) `X509_STORE_set_flags(3)`\n\n[RFC 3526 - MODP Diffie-Hellman groups](https://datatracker.ietf.org/doc/html/rfc3526)\n\n---\n\n*Originally published at [FoxIO](https://foxio.io/blog/choose-your-backend-three-tls-bugs-in-goahead).*\n","body_html":"

Choose Your Backend: Three TLS Bugs in GoAhead

\n
\"\"
\n

Sébastien Féry · FoxIO · October 26, 2026

\n

TLDR

\n

GoAhead is used in hundreds of millions of IoT, Firewall, OT, and Military devices including those from Palo Alto Networks, Comcast, D-Link, HP, Canon, Honeywell, GE, Oracle, Siemens, Rockwell, Digi, Lockheed Martin, Boeing, and more.

\n

Three independent bugs in GoAhead's TLS integrations can leave revoked client certificates accepted, encrypted sessions recoverable to an observer or a configured chain-depth limit unenforced. Exposure depends on the TLS library and the verification settings built into the device:

\n\n
TLS buildGoAhead versionsRequired configurationFix or mitigation
OpenSSL-compatible backend>= 3.4.5, <= 6.1.0mTLS enabled with a CRL configured. Revoked client certificates remain accepted even with issuer verification enabled.Upgrade to 6.1.1 or later.
Mbed TLS backend>= 4.0.2, <= 6.1.0TLS 1.2 DHE_RSA negotiated with a client that accepts the broken DH parameters.Upgrade to 6.1.1 or later, disable finite-field DHE suites, or use the OpenSSL backend.
LibreSSL legacy verifier — 3.2.x or 3.3.2–3.3.6<= 6.1.0VERIFY_PEER=1 and VERIFY_ISSUER=0. An over-depth client chain is accepted.Enable VERIFY_ISSUER=1 with a trusted CA bundle, or use OpenSSL / LibreSSL 4.x.
\n

Background

\n

GoAhead is an embedded web server used for device management: routers, switches, printers, gateways, and industrial controls and is deployed in hundreds of millions of devices.

\n

Each finding below affects a specific subset of those deployments, depending on the build and configuration.

\n

GoAhead supports two TLS backends: OpenSSL, the default, and MbedTLS. The OpenSSL backend also works with compatible libraries such as LibreSSL.

\n

GoAhead takes a compile-time approach regarding certain configurations:

\n\n

OpenSSL-compatible builds

\n
\"\"
\n

GoAhead's OpenSSL backend loads the configured CRL into the certificate store but never enables revocation checking. Revoked client certificates can therefore complete the mTLS handshake even when issuer verification is enabled.

\n

The CRL is loaded in sslOpen():

\n
// src/openssl.c\nif (ME_GOAHEAD_SSL_REVOKE && *ME_GOAHEAD_SSL_REVOKE) {\n    store = SSL_CTX_get_cert_store(sslctx);\n    if (!X509_STORE_load_locations(store, ME_GOAHEAD_SSL_REVOKE, 0)) {\n        error("Cannot load certificate revoke list: %s", ME_GOAHEAD_SSL_REVOKE);\n        sslClose();\n        return -1;\n    }\n}
\n
// src/openssl.c\nif (ME_GOAHEAD_SSL_REVOKE && *ME_GOAHEAD_SSL_REVOKE) {\n    store = SSL_CTX_get_cert_store(sslctx);\n    if (!X509_STORE_load_locations(store, ME_GOAHEAD_SSL_REVOKE, 0)) {\n        error("Cannot load certificate revoke list: %s", ME_GOAHEAD_SSL_REVOKE);\n        sslClose();\n        return -1;\n    }\n}
\n
// src/openssl.c\nif (ME_GOAHEAD_SSL_REVOKE && *ME_GOAHEAD_SSL_REVOKE) {\n    store = SSL_CTX_get_cert_store(sslctx);\n    if (!X509_STORE_load_locations(store, ME_GOAHEAD_SSL_REVOKE, 0)) {\n        error("Cannot load certificate revoke list: %s", ME_GOAHEAD_SSL_REVOKE);\n        sslClose();\n        return -1;\n    }\n}
\n

OpenSSL requires X509_V_FLAG_CRL_CHECK to enable CRL checking. Loading the file into the store does not set that flag. Without CRL or OCSP checking enabled, check_revocation() returns success before checking revocation status:

\n
// OpenSSL crypto/x509/x509_vfy.c\nint crl_check_enabled =\n    (ctx->param->flags &\n     (X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL)) != 0;\n...\nif (!crl_check_enabled && !ocsp_check_enabled)\n    return 1;
\n
// OpenSSL crypto/x509/x509_vfy.c\nint crl_check_enabled =\n    (ctx->param->flags &\n     (X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL)) != 0;\n...\nif (!crl_check_enabled && !ocsp_check_enabled)\n    return 1;
\n
// OpenSSL crypto/x509/x509_vfy.c\nint crl_check_enabled =\n    (ctx->param->flags &\n     (X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL)) != 0;\n...\nif (!crl_check_enabled && !ocsp_check_enabled)\n    return 1;
\n

GoAhead never sets either CRL flag. OpenSSL returns success without checking the loaded list. The application's callback would reject error 23, X509_V_ERR_CERT_REVOKED, through its default: branch, but the verifier never generates that error.

\n

On GoAhead 6.1.0 with OpenSSL 3.6.2, a revoked CA-signed client certificate completed the mTLS handshake with issuer verification enabled. The verification callback reported error 0 throughout the chain:

\n
VERIFY_CB: preverify_ok=1 error=0(ok) depth=1\nVERIFY_CB: preverify_ok=1 error=0(ok) depth=0
\n
VERIFY_CB: preverify_ok=1 error=0(ok) depth=1\nVERIFY_CB: preverify_ok=1 error=0(ok) depth=0
\n
VERIFY_CB: preverify_ok=1 error=0(ok) depth=1\nVERIFY_CB: preverify_ok=1 error=0(ok) depth=0
\n

X509_STORE_load_locations() succeeds, so startup produces no warning that CRL enforcement is inactive.

\n

Affected: GoAhead 3.4.5 through 6.1.0 using the OpenSSL-compatible backend with a CRL configured. The security impact is clearest with VERIFY_PEER=1, a trusted CA bundle, and VERIFY_ISSUER=1: a previously trusted but revoked identity retains access. When issuer checking is disabled, the CRL defect remains but unknown issuers are already accepted by policy.

\n

Fix: 6.1.1 now checks after loading the CRL:

\n
+ X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK);
\n
+ X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK);
\n
+ X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK);
\n

Mbed TLS builds

\n
\"\"
\n

GoAhead's mbed TLS backend configures the RFC 3526 2048-bit DH group through mbedtls_ssl_conf_dh_param_bin(). The modulus length passed to that function is taken from the generator buffer:

\n
// src/mbedtls.c\ncuchar dhm_p[] = MBEDTLS_DHM_RFC3526_MODP_2048_P_BIN; // 256 bytes\ncuchar dhm_g[] = MBEDTLS_DHM_RFC3526_MODP_2048_G_BIN; // 1 byte: 0x02\n\nmbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g));
\n
// src/mbedtls.c\ncuchar dhm_p[] = MBEDTLS_DHM_RFC3526_MODP_2048_P_BIN; // 256 bytes\ncuchar dhm_g[] = MBEDTLS_DHM_RFC3526_MODP_2048_G_BIN; // 1 byte: 0x02\n\nmbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g));
\n
// src/mbedtls.c\ncuchar dhm_p[] = MBEDTLS_DHM_RFC3526_MODP_2048_P_BIN; // 256 bytes\ncuchar dhm_g[] = MBEDTLS_DHM_RFC3526_MODP_2048_G_BIN; // 1 byte: 0x02\n\nmbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g));
\n

The size arguments tell mbed TLS how many bytes to read from each buffer. The call uses sizeof(dhm_g) for both, even though dhm_g is only one byte long. The length for dhm_p should be sizeof(dhm_p), or 256 bytes.

\n

As a result, mbed TLS reads only the first byte of dhm_p: 0xFF (255). The remaining 255 bytes are discarded. It accepts this value and sends it to the client during the TLS 1.2 DHE_RSA handshake:

\n
0c 00 01 0d 00 01 ff 00 01 02 00 01 08
\n
0c 00 01 0d 00 01 ff 00 01 02 00 01 08
\n
0c 00 01 0d 00 01 ff 00 01 02 00 01 08
\n

In ServerKeyExchange, 00 01 ff identifies a one-byte DH parameter with the value 255. It should contain the full 256-byte value.

\n

The broken parameters leave just eight possible shared-secret values : 01, 02, 04, 08, 10, 20, 40and 80 in hex. An observer can try each candidate and identify the correct one by checking whether it decrypts the captured traffic successfully.

\n

In the attached PoC, I managed to reproduce the shared secret after five attempts. It matched the client's secret, confirming that the same TLS session keys could be derived to decrypt the HTTP exchange.

\n

A passive observer can decrypt captured sessions using the recorded handshake and encrypted application records completely out of band.

\n

Exploitation requires a client that accepts the broken DH parameters. The tested OpenSSL client rejected them with DH_check_params_ex: modulus too small. Permissive clients, including custom or embedded implementations without a minimum-size check, can complete a decryptable session. ECDHE sessions and TLS 1.3 are unaffected by this configured finite-field group.

\n

Affected: GoAhead 4.0.2 through 6.1.0 using the mbed TLS backend with TLS 1.2 DHE_RSA suites, where the client accepts the parameters. The typo entered in 2018 during migration to the binary-parameter API and survived the April 2024 TLS refactor. Mbed TLS 4.x removed the TLS_DHE_* suites, so this DHE path isn't impacted.

\n

If you see any of these suites in the JA4S logs of your environment, you might be impacted (eg. t120100_009f_1ca028f07214)

\n
0014  TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA\n0015  TLS_DHE_RSA_WITH_DES_CBC_SHA\n0016  TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA\n0033  TLS_DHE_RSA_WITH_AES_128_CBC_SHA\n0039  TLS_DHE_RSA_WITH_AES_256_CBC_SHA\n0045  TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA\n0067  TLS_DHE_RSA_WITH_AES_128_CBC_SHA256\n006B  TLS_DHE_RSA_WITH_AES_256_CBC_SHA256\n0088  TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA\n009A  TLS_DHE_RSA_WITH_SEED_CBC_SHA\n009E  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256\n009F  TLS_DHE_RSA_WITH_AES_256_GCM_SHA384\n00BE  TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256\n00C4  TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256\nC044  TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256\nC045  TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384\nC052  TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256\nC053  TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384\n0C07C  TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256\nC07D  TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384\nC09E  TLS_DHE_RSA_WITH_AES_128_CCM\nC09F  TLS_DHE_RSA_WITH_AES_256_CCM\nC0A2  TLS_DHE_RSA_WITH_AES_128_CCM_8\nC0A3  TLS_DHE_RSA_WITH_AES_256_CCM_8\nCCAA  TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
\n
0014  TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA\n0015  TLS_DHE_RSA_WITH_DES_CBC_SHA\n0016  TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA\n0033  TLS_DHE_RSA_WITH_AES_128_CBC_SHA\n0039  TLS_DHE_RSA_WITH_AES_256_CBC_SHA\n0045  TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA\n0067  TLS_DHE_RSA_WITH_AES_128_CBC_SHA256\n006B  TLS_DHE_RSA_WITH_AES_256_CBC_SHA256\n0088  TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA\n009A  TLS_DHE_RSA_WITH_SEED_CBC_SHA\n009E  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256\n009F  TLS_DHE_RSA_WITH_AES_256_GCM_SHA384\n00BE  TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256\n00C4  TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256\nC044  TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256\nC045  TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384\nC052  TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256\nC053  TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384\n0C07C  TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256\nC07D  TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384\nC09E  TLS_DHE_RSA_WITH_AES_128_CCM\nC09F  TLS_DHE_RSA_WITH_AES_256_CCM\nC0A2  TLS_DHE_RSA_WITH_AES_128_CCM_8\nC0A3  TLS_DHE_RSA_WITH_AES_256_CCM_8\nCCAA  TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
\n
0014  TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA\n0015  TLS_DHE_RSA_WITH_DES_CBC_SHA\n0016  TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA\n0033  TLS_DHE_RSA_WITH_AES_128_CBC_SHA\n0039  TLS_DHE_RSA_WITH_AES_256_CBC_SHA\n0045  TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA\n0067  TLS_DHE_RSA_WITH_AES_128_CBC_SHA256\n006B  TLS_DHE_RSA_WITH_AES_256_CBC_SHA256\n0088  TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA\n009A  TLS_DHE_RSA_WITH_SEED_CBC_SHA\n009E  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256\n009F  TLS_DHE_RSA_WITH_AES_256_GCM_SHA384\n00BE  TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256\n00C4  TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256\nC044  TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256\nC045  TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384\nC052  TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256\nC053  TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384\n0C07C  TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256\nC07D  TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384\nC09E  TLS_DHE_RSA_WITH_AES_128_CCM\nC09F  TLS_DHE_RSA_WITH_AES_256_CCM\nC0A2  TLS_DHE_RSA_WITH_AES_128_CCM_8\nC0A3  TLS_DHE_RSA_WITH_AES_256_CCM_8\nCCAA  TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
\n

A sample query you might want to run (in Splunk or other) would look like:

\n
DestIP = (GoAhead Device)\nAND\nJA4S = *_0014_
\n
DestIP = (GoAhead Device)\nAND\nJA4S = *_0014_
\n
DestIP = (GoAhead Device)\nAND\nJA4S = *_0014_
\n

replacing 0014 with the curves listed above.

\n

Fix: 6.1.1 fixed the typo

\n
- mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g))\n+ mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_p), dhm_g, sizeof(dhm_g))
\n
- mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g))\n+ mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_p), dhm_g, sizeof(dhm_g))
\n
- mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g))\n+ mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_p), dhm_g, sizeof(dhm_g))
\n

LibreSSL builds

\n
\"\"
\n

Essentially, an attacker can present a certificate chain longer than GoAhead’s limit and still complete the mTLS handshake on an affected build. LibreSSL reports an issuer error instead of a depth error. GoAhead accepts that issuer error when issuer checking is disabled.

\n

GoAhead 6.1.0 sets a chain-depth limit of 10 using SSL_CTX_set_verify_depth(sslctx, VERIFY_DEPTH). Its verification callback also checks the depth:

\n
// src/openssl.c\nif (ok && VERIFY_DEPTH < depth) {\n    if (error == 0) {\n        error = X509_V_ERR_CERT_CHAIN_TOO_LONG;\n    }\n}
\n
// src/openssl.c\nif (ok && VERIFY_DEPTH < depth) {\n    if (error == 0) {\n        error = X509_V_ERR_CERT_CHAIN_TOO_LONG;\n    }\n}
\n
// src/openssl.c\nif (ok && VERIFY_DEPTH < depth) {\n    if (error == 0) {\n        error = X509_V_ERR_CERT_CHAIN_TOO_LONG;\n    }\n}
\n

That check only assigns a depth error when ok is true, the reported depth exceeds the limit, and no error is already present. The callback then classifies the error:

\n
case X509_V_ERR_CERT_UNTRUSTED:\ncase X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY:\n    if (ME_GOAHEAD_SSL_VERIFY_ISSUER) {\n        ok = 0;\n    }\n    break;\n\ncase X509_V_ERR_CERT_CHAIN_TOO_LONG:\ndefault:\n    ok = 0;\n    break;
\n
case X509_V_ERR_CERT_UNTRUSTED:\ncase X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY:\n    if (ME_GOAHEAD_SSL_VERIFY_ISSUER) {\n        ok = 0;\n    }\n    break;\n\ncase X509_V_ERR_CERT_CHAIN_TOO_LONG:\ndefault:\n    ok = 0;\n    break;
\n
case X509_V_ERR_CERT_UNTRUSTED:\ncase X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY:\n    if (ME_GOAHEAD_SSL_VERIFY_ISSUER) {\n        ok = 0;\n    }\n    break;\n\ncase X509_V_ERR_CERT_CHAIN_TOO_LONG:\ndefault:\n    ok = 0;\n    break;
\n

Error 20, UNABLE_TO_GET_ISSUER_CERT_LOCALLY, is tolerated when issuer checking is disabled. Error 22, CERT_CHAIN_TOO_LONG, is rejected.

\n

LibreSSL 3.2.x and 3.3.2–3.3.6 use the legacy X.509 verifier by default for peer verification. Its chain-building loop contains a FIXME comment (which is what prompted a look at GoAhead in the first place):

\n
// LibreSSL src/lib/libcrypto/x509/x509_vfy.c\nfor (;;) {\n    /* FIXME: If this happens, we should take\n     * note of it and, if appropriate, use the\n     * X509_V_ERR_CERT_CHAIN_TOO_LONG error code\n     * later.\n     */\n    if (depth < num)\n        break;
\n
// LibreSSL src/lib/libcrypto/x509/x509_vfy.c\nfor (;;) {\n    /* FIXME: If this happens, we should take\n     * note of it and, if appropriate, use the\n     * X509_V_ERR_CERT_CHAIN_TOO_LONG error code\n     * later.\n     */\n    if (depth < num)\n        break;
\n
// LibreSSL src/lib/libcrypto/x509/x509_vfy.c\nfor (;;) {\n    /* FIXME: If this happens, we should take\n     * note of it and, if appropriate, use the\n     * X509_V_ERR_CERT_CHAIN_TOO_LONG error code\n     * later.\n     */\n    if (depth < num)\n        break;
\n

The loop stops building the chain without recording the depth error. The failure later reaches GoAhead as error 20. With VERIFY_ISSUER=0, the callback accepts it.

\n

On GoAhead 6.1.0 linked against LibreSSL 3.3.6, a 17-certificate chain rooted in an attacker-controlled, self-signed CA produced the following callback trace:

\n
VERIFY_CB_ENTRY: preverify_ok=0 error=20(unable to get local issuer certificate) depth=10\nVERIFY_CB_ENTRY: preverify_ok=1 error=20(unable to get local issuer certificate) depth=9\nVERIFY_CB_ENTRY: preverify_ok=1 error=20(unable to get local issuer certificate) depth=8
\n
VERIFY_CB_ENTRY: preverify_ok=0 error=20(unable to get local issuer certificate) depth=10\nVERIFY_CB_ENTRY: preverify_ok=1 error=20(unable to get local issuer certificate) depth=9\nVERIFY_CB_ENTRY: preverify_ok=1 error=20(unable to get local issuer certificate) depth=8
\n
VERIFY_CB_ENTRY: preverify_ok=0 error=20(unable to get local issuer certificate) depth=10\nVERIFY_CB_ENTRY: preverify_ok=1 error=20(unable to get local issuer certificate) depth=9\nVERIFY_CB_ENTRY: preverify_ok=1 error=20(unable to get local issuer certificate) depth=8
\n

The handshake completed and the resource behind the client-certificate requirement returned HTTP 200. The same GoAhead source built against LibreSSL 4.3.1 received error 22 at depth 10 and rejected the chain.

\n

With VERIFY_ISSUER=0, ordinary self-signed certificates are already allowed. The over-depth chain bypasses the separate chain-depth restriction because the verifier reports a tolerated issuer error. Deployments requiring a trusted client CA reject it.

\n

Demonstrated configuration: GoAhead 6.1.0 with the LibreSSL legacy verifier, ME_GOAHEAD_SSL_VERIFY_PEER=1, and ME_GOAHEAD_SSL_VERIFY_ISSUER=0. Enabling issuer trust rejects error 20. OpenSSL, BoringSSL, AWS-LC, and LibreSSL 4.x builds are not exposed to this legacy-verifier trigger.

\n

Conclusion

\n

All three findings affect GoAhead's integration with its TLS libraries. CRL enforcement depends on a verification flag, DH parameters depend on the supplied buffer lengths, and chain-depth enforcement depends on how verification errors are handled. None of these defects prevents the affected handshake from completing.

\n

The backend and build configuration determine which defects apply. LibreSSL builds can inherit both the CRL defect in the OpenSSL-compatible backend and the legacy verifier's depth issue. The mbed TLS backend uses a separate verification path but is affected by the DH truncation when a client accepts the parameters.

\n

To find impacted publicly facing servers in your fleet, here are the JA4Scan-TLS fingerprints that map to the different backends:

\n
Server (GoAhead 6.1.x)JA4Scan-TLS
OpenSSL 3.6.203100h0s00sn_1fe27f6025fb_d06dc4648d2f_sr00ss537461
LibreSSL 3.3.603100h0s00s0_9d52559f55bc_c64486648d2f_sr00sc24603c
LibreSSL 4.3.1 (depth bypass unaffected)03100h0r00s0_9d52559f55bc_c64486206461_sr00scc98ba1
mbedTLS 3.6.623100h0s01s0_d7d3025021f4_0475c5cede0d_sr0ss02265cf
\n

Read the full blog post about JA4Scan here:

\n

https://foxio.io/blog/introducing-ja4scan-active-server-fingerprinting-for-tls-and-quic

\n

POC

\n

Reproduction code is available at https://github.com/FoxIO-LLC/blog_poc/tree/main/chooseyourbackend

\n

Timeline

\n\n

References

\n

GOAHEAD-SA-2026-0004 / CVE-2026-115884: mTLS chain-depth bypass

\n

GOAHEAD-SA-2026-0005: MbedTLS DH parameter truncation

\n

GOAHEAD-SA-2026-0006 / CVE-2026-115881: OpenSSL CRL checking disabled

\n

GoAhead SSL documentation

\n

OpenSSL verification flags

\n

OpenSSL X509_STORE_set_flags(3)

\n

RFC 3526 - MODP Diffie-Hellman groups

\n
\n

Originally published at FoxIO.

","headings":[{"level":1,"text":"Choose Your Backend: Three TLS Bugs in GoAhead","id":"choose-your-backend-three-tls-bugs-in-goahead"},{"level":2,"text":"TLDR","id":"tldr"},{"level":2,"text":"Background","id":"background"},{"level":2,"text":"OpenSSL-compatible builds","id":"openssl-compatible-builds"},{"level":2,"text":"Mbed TLS builds","id":"mbed-tls-builds"},{"level":2,"text":"LibreSSL builds","id":"libressl-builds"},{"level":2,"text":"Conclusion","id":"conclusion"},{"level":2,"text":"POC","id":"poc"},{"level":2,"text":"Timeline","id":"timeline"},{"level":2,"text":"References","id":"references"}]}}