[Live-devel] RTSPS and PKI

Tue Jul 22 08:17:39 PDT 2025

Classified as: {OPEN}

I think there is a confusion between confidentiality, server authentication and client authentication. 

The confidentiality is guaranteed using the server private/public keys set in the existing RTSPServer::setTLSState(). 

The server authentication can be guaranteed by checking the validity of its public key using the CA of the client. This can be achieved by setting a verify_callback in  ClientTLSState::setup() as proposed previously. The client CA file will not be transmitted to the server. 

On the other hand, the client authentication can be guaranteed using RTSP password transmitted securely over TLS as suggested in section 19.2 of RFC 7826. Or, TLS server may ask the client to send its  public key (different from the CA file used to authenticate the server). This public key is verified using the sever CA. In this case,  we have to install a verify_callback() on the server side (in ServerTLSState::setup()) with SSL_VERIFY_PEER option.

In the initial request, it was about to set server authentication (which doesn't seems to be a problem) and configure the path the client CA file. 

Actually, I still don’t understand why this later request may impact the interoperability with other RTSP implementation.

Finally, to implement SSL client authentication (symmetrically to server authentication) as supported in TLS,  one may suggest that:

- RTSPclient  configure its private/public keys as like in the existing RTSPServer::setTLSState() function.
- RTSPserver  configure its CA file as like in the proposed RTSPClient::SetSSLCAFileName()

Yahia

{OPEN}

-----Message d'origine-----
De : live-devel <live-devel-bounces at us.live555.com> De la part de Ross Finlayson
Envoyé : lundi 21 juillet 2025 06:04
À : LIVE555 Streaming Media - development & use <live-devel at us.live555.com>
Objet : Re: [Live-devel] RTSPS and PKI

> 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 for the OS-installed files and /usr/local/share/ca-certificates/ for the locally-installed ones. These directories contain only the public halves of certs for the purposes of connection verification. Red Hattish boxes have a similar split, but differently named *because Linux*.
> 
> Regardless, this is distinct — on purpose! — from the private halves used by servers to encrypt messages, in /etc/ssl/private, read-only by root on Debian, which is what the OP is talking about, in part.

OK, but I don’t see how any of this is relevant to me, because our RTSP server code takes (in a call to “setTLSState()”) two filename parameters: One filename for the certificate; another for the private key file.  I.e., the server code doesn’t care where certificates or private keys are stored; their file names are just parameters to “setTLSState()”.

I’m assuming that this will continue to work, on all OSs on which you might wish to run our server code.  (If not, then please correct me.)

> What the OP is _also_ talking about, however, is client-side certificates, which are used by the client for proving their identity to the server, in much the same way an SSH client logs in via authorized_keys.

I *think* the OP was also talking about *two* separate things:

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 (presumably so it can reject the connection if it is, if it thinks that the server having a self-signed certificate is ‘bad').  This seemed reasonable to me, which is why I added the optional "ClientTLSState::setupExtra()” mechanism on July 10th; that was intended to make this sort of thing possible.

2/ The optional ability of RTSP clients to take a certificate filename parameter.  (Again, the particular location of such a client-side certificate is irrelevant; that’s why it would be a filename parameter.)

This is what I remain deeply skeptical about.  Remember that we can’t just be designing and implementing our own protocol here; instead, we have to stick to what has been defined by the IETF.  Our RTSP client code needs to continue to be able to work with other RTSP server implementations, and our RTSP server code needs to continue to be able to work with other RTSP client implementations.  I don’t want to get into a situation where our RTSP client code will work only with our RTSP server code, or vice versa.

Unfortunately the IETF has complicated things here, because it doesn’t define RTSP-over-TLS in RFC 2326 (the specification for RTSP 1.0), but instead only in section 19.2 of RFC 7826 (the specification for RTSP 2.0).  However, almost nobody (including us) has implemented RTSP 2.0; instead, almost everyone just implements RTSP 1.0, but adds in support for RTSP-over-TLS as it’s defined in the RTSP 2.0 specification (RFC 7826).

Section 19.2 of RFC 7826 notes:

   "It should be noted that TLS allows for mutual authentication (when
   using both server and client certificates).  Still, one of the more
   common ways TLS is used is to provide only server-side authentication
   (often to avoid client certificates).  TLS is then used in addition
   to HTTP authentication, providing transport security and server
   authentication, while HTTP Authentication is used to authenticate the
   client.”

I.e., the text implies that the ’normal’ way to do RTSP-over-TLS is to use server certificates only, but instead to authenticate clients using what it calls “HTTP Authentication”, by which it means the HTTP-*style* password authentication that is already used within RTSP.  I.e., you don’t need to use a certificate to authenticate a client; instead, you can use a password.  (Yes, malicious clients could share passwords, but they could also share client certificates.)  Note also that the password mechanism does *not* involve passwords being sent over the RTSP connection, so a middlebox that somehow got to decrypt the RTSP (TLS) connection could never see the password.)

On the other hand, the RFC text doesn’t *preclude* the possibility of a RTSP client using a certificate to authenticate itself, but, once again, I don’t see what benefit this would give you over password authentication.

In any case, as I noted earlier, I would never implement client-side certificates if it meant that our RTSP client code would no longer work with other people’s RTSP server implementations.  (And I would also be averse to doing this if it meant having to modify our existing server implementation in any way.)

> 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.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel