On Jul 20, 2025, at 22:03, Ross Finlayson <[email protected]> wrote:
>
>> On Jul 20, 2025, at 11:11 PM, Warren Young <[email protected]> wrote:
>>
>> On Jul 19, 2025, at 19:55, Ross Finlayson <[email protected]> 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.
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
