Settings

Settings

The Settings tab holds both one-shot configuration (CA cert, theme, SOCKS upstream) and the big traffic-control rule sets (Scope, Noise Filter, Customize Requests). Changes take effect immediately.

CA certificate

Click Download CA Cert to save joro-ca.crt. Import it into your browser's or operating system's trust store so that Joro's on-the-fly HTTPS certificates are trusted. See Getting-Started for the full first-run flow.

The CA is generated on first run and reused across restarts. It lives at ~/.joro/ca.crt (ECDSA P-256, valid for 10 years).

Appearance

• Theme: pick between available themes (bf-dark by default). Stored in your browser and applied on page load.

Updates

Joro checks for a newer release at startup and periodically in the background, and surfaces an update prompt when one is available. Disable the check here, or with --disable-update-checks at launch.

When you apply an update, Joro upgrades itself in place and re-execs:

• A binary installed from a release downloads the matching release archive from GitHub and swaps itself out.
• A binary running from a git checkout runs git pull && make build.

The Plugins page exposes a Restart Now button that uses the same re-exec, which you also need after adding or removing a plugin.

Update checks run in proxy mode only. A Listener-Mode or Team-Server instance never checks for or applies updates — upgrade those hosts manually.

Proxy

• Max requests: size of the in-memory ring buffer backing History. Default is 5000. Older entries are evicted once the buffer fills.
• Auto-forward timeout (s): how long a paused intercept request waits before Joro forwards it automatically so the client does not hang. Default is 60. Enable or disable the intercept queue itself from the Intercept button on the Intercept tab.

Connection

• HTTP/2 Upstream: toggle whether Joro negotiates HTTP/2 to upstream servers. Turn off to force HTTP/1.1 for compatibility or predictable framing.
• HTTP/1 Keep-Alive: toggle whether Joro reuses HTTP/1 connections to upstream servers. Turn off to force one connection per request.

SOCKS Proxy (upstream)

Route Joro's outbound traffic through an upstream SOCKS proxy. Fill in:

• Host and Port
• Optional Username and Password
• DNS over SOCKS: tunnel DNS queries through the proxy as well

Useful for sending engagement traffic through a corporate egress, a remote host, or any other proxy chain.

Listener URL and team credentials

Connect this proxy instance to a remote listener or team server running on a remote host.

• Listener URL: the base URL of the listener's API, for example http://<listener-ip>:9090. Once set, the Interact tab pulls tokens, probes, and interactions from this listener.
• Team Token: the 32-character hex token printed when the team server started. Required for team server mode.
• Nickname: the name other operators see in the Dashboard chat and shared Notes.

If you set Listener URL but no Team Token plus Nickname, Joro prompts for team credentials on next load. Clear these fields to disconnect.

See Listener-Mode and Team-Server for standing up the remote side.

Scope

A two-level allow/deny filter that decides which requests go through full interception and capture versus being tunneled or forwarded raw.

• Level 1 (CONNECT): when the browser opens an HTTPS tunnel, Joro checks the target host. Out-of-scope hosts are tunneled raw without MITM, so TLS is never decrypted for them.
• Level 2 (request): after TLS termination, each individual request is checked against host plus method plus path. Out-of-scope requests are forwarded without capture or intercept.

Each rule has a host pattern, optional HTTP methods, an optional path pattern, and an include/exclude flag. Exclude rules override include rules.

Scope is disabled by default, which means every request is captured. When scope is enabled with no rules, nothing matches, so everything is blocked. This is a deliberately safe default.

Noise Filter

Silently forwards common browser background traffic without capturing or decrypting it. Typical entries cover captive portal checks, telemetry endpoints, OCSP revocation lookups, and safe-browsing services.

• Enabled by default with a curated pattern list.
• Patterns can be added, removed, or the whole filter disabled.
• Runs before scope. Even if a noisy host matches a scope include rule, it is still tunneled silently and never goes through MITM, which keeps History clean.

Add hosts to the noise filter when they appear repeatedly and are never interesting. Use scope to define what you are actually testing.

Customize Requests

A sub-tab that holds two related features: Match & Replace (rewrite rules) and Custom Data (additive injection). Both run automatically on in-scope traffic and can be toggled independently.

Match & Replace

Rewrites parts of requests and responses based on pattern rules. Each rule has:

• Target: one of request_header, request_body, response_header, response_body, or ws_message.
• Match type: string (literal) or regex.
• Match: the pattern to search for.
• Replace: the replacement text.

Rules run cumulatively in order. A response body rule sees the output of any earlier response body rule. Only complete text or binary WebSocket messages are rewritten; control frames pass through untouched.

Custom Data

Custom Data is purely additive. It adds fixed headers, query parameters, or body snippets to every in-scope request. There is no match pattern.

• Header: adds a constant HTTP header (for example, X-Forwarded-For for testing IP-based logic).
• Query parameter: appends ?name=value or &name=value to the URL.
• Body: appends text to the request body when the body is a form or compatible format.

Custom Data runs after Match & Replace in the pipeline, so any addition you configure here sits on top of the rewrites you have already applied.

Configurations

Save and reload named configuration bundles so you can switch setups without re-entering everything.

• User Config captures your personal preferences: theme, auto-forward timeout, max requests, SOCKS proxy settings, and any user-scoped state from installed plugins (such as API keys or personal tokens).
• Project Config captures the engagement-specific state: scope rules, noise patterns, match-and-replace rules, custom data items, listener URL, team credentials, and any project-scoped plugin state (such as Interactsh servers with their correlation IDs).

Save a named config, load it on another machine or a future session, and delete old ones when you no longer need them. Handy for moving a project between workstations or flipping between several active engagements. Loading a config on a machine that does not have one of the referenced plugins installed preserves that plugin's state blob for next time — nothing is silently dropped.