A gateway cannot verify that the orchestrator answering a serviceURI holds the registered key

[Strykar]

Splitting this out of #437, which was closed as stale. Four of the five parts of that issue describe an architecture that no longer exists. This part does not depend on any of it.

The gap

An orchestrator registers a serviceURI on chain, so a gateway knows which address claims which endpoint. Nothing in the session establishment proves the endpoint holds that address.

Two pieces:

server/segment_rpc.go

var tlsConfig = &tls.Config{InsecureSkipVerify: true}

That is the config used to dial orchestrators, so the certificate is not checked against anything.

net/lp_rpc.proto, OrchestratorInfo carries transcoder, ticket_params, price_info, address, capabilities, auth_token, hardware and pricing. None of it is signed. address is an assertion by the responder, and AuthToken is issued by the responder, so neither demonstrates key possession.

The gateway does sign its own side; the orchestrator recovers the gateway's address from the GetOrchestrator signature. The verification is one-directional.

What that allows

Anyone positioned to answer for a registered serviceURI, by DNS, BGP, a compromised host or a stale record pointing at a reclaimed address, can present themselves as that orchestrator. They choose the ticket parameters and the price, and the gateway has no way to distinguish them from the registered operator.

Why it is worth fixing now rather than in 2018

LIP-118 moves the stake-holding key off the node. That is the right direction, and it makes the node's identity a separate question from its stake: the box answering the serviceURI increasingly does not hold the orchestrator key at all. Whatever proves identity has to work for a node that only holds a delegated or session key.

Possible shape

The eth key cannot be the TLS key, since TLS 1.3 restricts ECDSA to secp256r1, secp384r1 and secp521r1 and Ethereum uses secp256k1. That rules out the 2018 approach but not binding: the orchestrator's eth key signs the certificate public key, the signature travels in a certificate extension or in a signed field on OrchestratorInfo, and the handshake negotiates TLS 1.3 normally with a P-256 key. The gateway checks the binding against the address registered for that serviceURI.

I have a standalone probe of the binding approach and am happy to turn it into a PR if the direction is right. Worth agreeing the shape before I write it.

[j0sh]

Anyone positioned to answer for a registered serviceURI

Note that in practice we don't use the serviceURI for much these days outside of transcoding.

The main thing is we should stop using insecureSkipVerify and start enforcing the use of normal CA-derived TLS certificates. For legacy stacks within go-livepeer the change is likely not practical, but we should do it for the live runner. That should be enough with an authoritative source for the URI whether that comes from an on-chain registry, an internal list, learned through a trusted messaging channel, etc.

They choose the ticket parameters and the price, and the gateway has no way to distinguish them from the registered operator.

In this case, any payment would still go to the registered orchestrator. Presumably the attacker would not actually submit any winning tickets, so it'd be pretty much a pure griefing attack that deprives the orchestrator of fees.

[Strykar]

Checked the on-chain side and you are closer to right than my issue allowed for. redeemWinningTicket pays through updateTranscoderWithFees, and the live BondingManager target requires isActiveTranscoder rather than merely registered. That tightened in livepeer/protocol d03671e2 in August 2025 as part of the fee overclaim fix, which is why several older verified targets still read "transcoder must be registered". The pool is full at 100, so a recipient who is not in the active set cannot redeem anything, and for that attacker this is exactly the griefing you described.

Where I would still push back a little: the recipient does not have to be the attacker's own address. Whoever is on the path generates recipientRand, so handing it to a cooperating active orchestrator is enough to make the payout collectable. WinningTicketRedeemed indexes the recipient, so the collaborator is named on chain. That is a deterrent, not a control.

Separately: nothing compares TicketParams.Recipient against the address registered for the serviceURI that was dialled. That enforces the assumption in your comment rather than answering the question here, so I will put it up as its own PR and link it rather than widen this one. The advertised-node half of the same gap is question 2 on #4084.

[j0sh]

@Strykar What exactly is the concern? Is it this sequence of events?

• Attacker spoofs DNS, BGP, etc and impersonates a legitimate orchestrator
• Gateway creates tickets for a collaborator (also a legitimate orchestrator), parameterized by the impersonator.
• Attacker cashes out winning tickets, depriving the legitimate orchestrator of fees

If so, then enforcing TLS pretty much solves this unless the orchestrator's node itself is compromised in which case they are toast anyway.

There is also a (larger IMO) concern with ensuring QoS but that's a separate topic around validation etc.

About the recipient, I touched on that in #4084 (comment)

[Strykar]

@j0sh Not quite, the fee case is the weak one, conceded above. The concern is the one you called larger: someone answering as an orchestrator degrades QoS and it lands on the registered key.

CA certs close local DNS/BGP spoofing. They don't cover registrar compromise, lapsed domains, reclaimed IPs or the transcoding path, which you've said won't get enforcement. I probed all 100 active registrations yesterday: 67 of 70 reachable serve the stock self-signed cert, 20 of 97 URIs are IP literals.
On that path enforce TLS is a migration nobody has scheduled, so the gap just stays open.

Small additive alternative: the orchestrator's key signs its cert's SPKI, carried in an OrchestratorInfo field, verified only when present. If the transcoding path is closed regardless, say so and I'll stop.