3.2.0: TLS-* attributes for incoming and outgoing RadSec connections

[Alan DeKok]

On Jun 3, 2022, at 4:48 AM, Stefan Winter <stefan.winter at restena.lu> wrote:
> while playing with RadSec inbound and outbound I noticed that for both directions, the cert properties of the other end are stored in a series of TLS-Client-Cert-* attributes.

  Hm... that seems wrong.

> But when initiating an outbound connection, these attributes store the properties of the *server* we are contacting, while the name suggests something about client (which would be our own cert, which is useless).

  The implementation looks at where the certificates are in the chain, as supplied by OpenSSL.  I guess it passes the certificates in a different order for outgoing connections?

  Or maybe if you're not supplying a client cert, the other end server cert shows up at offset 0, which is typically the client cert.

  So are you using a client cert for radsec?

> Example:
> 
> (TLS) Trying new outgoing proxy connection to proxy (0.0.0.0, 0) -> home_server (145.100.189.5, 2083)
> Requiring Server certificate
> 
> [...]
> 
> (0)  TLS-Client-Cert-Common-Name := "slagroom.eduroam.nl"
> 
> 
> That should really be TLS-Server-Cert-Common-Name (same goes for all other properties of course).

  I agree.

> Could these attributes be duplicated for -Server and be populated as such during outbound connections?

  I don't want to change existing behavior, but we can add a configuration flag saying "whoops, use a better order".

  I'll take a look.

  Alan DeKok.