[Live-devel] RTSPS and PKI

[Warren Young]

On Jul 20, 2025, at 22:03, Ross Finlayson <finlayson at live555.com> wrote:
> 
>> On Jul 20, 2025, at 11:11 PM, Warren Young <warren at etr-usa.com> wrote:
>> 
>> On Jul 19, 2025, at 19:55, Ross Finlayson <finlayson at live555.com> wrote:
>>> 
>>> I don’t understand this ‘word salad’ (“system wide CA keystore”, etc.).
>> 
>> On a Debian box, it means /etc/ssl/certs…
> 
> OK, but I don’t see how any of this is relevant to me

I gave concrete directories as a path past the “word salad”, and I started with Debian as a highly popular case you might already be familiar with. It was meant to ground the discussion in known tech.

> our RTSP server code takes (in a call to “setTLSState()”) two filename parameters

…neither of which is the CA’s public cert, which the underlying TLS implementation — OpenSSL? haven’t looked — must get from somewhere. Thus one of the OP’s concerns: what if it’s one of these self-signed middle box certs? How do you defeat its meddling?

One answer: client-side certificates. Instead of having just one certificate it needs to infiltrate into each client box, as via central IT's golden image rollout, it has to _exfiltrate_ one cert _from_ each client box. Harder problem.

> 1/ The optional ability of clients to check (as part of TLS connection setup) whether or not the server is using a self-signed certificate

All chains ultimately end with a self-signed certificate; that’s what CAs are.

The compromise we’ve come to is that the CA/Browser Forum cabalists all get together and decide whose CA certs to trust and whose not, which then filters out to things like the common ca-certificates package, which is a copy of Mozilla’s CA trust store, via the curl project.

If your RTSPS server’s public cert was signed by one of the CAs on that list and you trust Mozilla’s CA root store, then the client will allow the connection. If not, then you may have a locally-installed CA root that is trusted, which could also sign the streaming server’s TLS certificate. This is likely a legitimate use of “self-signed certificates”.

> we have to stick to what has been defined by the IETF.

Since it’s all based on TLS, you can punt that to the TLS spec, which allows both client and server certs.

If no other RTSPS client can apply a client-side cert but yours, that isn’t a breakage in the protocol, it’s a complete implementation of the existing specs. If no servers but yours will verify a client certificate, ditto.

(That last I doubt, since one of the options must be to put the Live555 plain-RTSP server behind nginx or similar for TLS termination.)

> (Yes, malicious clients could share passwords, but they could also share client certificates.)

The difference being that the server stores only the public half of the certificate, which gives zero leverage in finding the private half. The only thing the server can use that for is decrypting the client’s authentication messages, not encrypt connections under the client’s key.

Contrast passwords, which are symmetric once broken. How secure is Live555’s password store?

>> This is how those corporate IT snooping boxes work: they require the clients to have the middlebox’s CA cert installed, allowing it to decrypt the TLS for inspection while proxying it.
> 
> You say that like it’s a good thing :-)  I would very much like not to make this possible.

Client-side certs are one way to frustrate the snoopers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20250721/ef576297/attachment.htm>