--- Begin Message ---
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 <[email protected]> De la part de Ross Finlayson
Envoyé : lundi 21 juillet 2025 06:04
À : LIVE555 Streaming Media - development & use <[email protected]>
Objet : Re: [Live-devel] RTSPS and PKI
> 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 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
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
--- End Message ---
