Negotiate SSL

[pdarragh]

Currently, as I understand the use of SSL with Radmind, SSL must be enabled at the server level and the clients must be set up or scripted to use it.

I'd like to see SSL support move to something more like the gzip feature that was added. I'd like to set the server up to accept SSL, perhaps with a minimum and/or maximum level of authorization.

Then, I'd like the clients to be able to negotiate with the server to either use or not use SSL based on what the server expects.

For example, with gzip compression, I can set -Z6 on the Radmind server process. Clients can then use anything up to and including -Z6 with ktcheck and lapply, but they aren't required to use it at all.

I'd like to have a similar setup for SSL. If server is configured to use SSL, possibly with no minimum level but a maximum of -w2, then the client should be able to use or not SSL over the same port defined for that server. For SSL, it might also make sense to set a minimum level for a server.

Original comment by: jaharmi

[pdarragh]

Logged In: YES user_id=1296576 Originator: NO

Sounds reasonable. As you said, you'd have to set a minimum level so admins could force the use of certificates.

Current New none or -z=0 none or -z=0 or -zmin=0 -zmax=0 -z1 -z1 or -zmin=1 -zmax=1 -z2 -z2 or -zmin=2 -zmax=2

New options: -zmin=1 : require server cert, optionally accept client cert -zmax=1 : optional accept server cert -zmin=2 : require server cert, require client cert -zmax=2 : optional accept client -zmin=1 -zmax=2 : require server cert, optionally accept client cert

Note: when a client cert is required, I'd venture to say that the server cert would also be required.

Would something like that work?

Original comment by: umeditor

[pdarragh]

• labels: --> UNIX

Original comment by: umeditor

[pdarragh]

Logged In: YES user_id=1324617 Originator: YES

My immediate reaction is that it is a lot of options but that's to be expected when setting both a minimum and maximum.

What about having -w continue to set a floor, but allow negotiation to allow higher levels if they are present? This would make it more like -Z, although they would be opposites (which is perhaps called for by their function).

I think using -z is confusing since it's already used on the radmind server executable (to select the server's private certificate) as well as being very similar to -Z for gzip.

If "wmin" and "wmax" were to be used, I'd be happy with having them be double-dash word options, if that's acceptable for Radmind style. Then there would have to be rules about whether they override -w if they are all set on the same command line.

I'd also like to see the client not need to have -w or -wmin or -wmax set at all, and just have some core code that negotiates based on the server's options. This is basically what I have my client scripts doing; they detect that there are certificates available in the default locations on the local system, and attempt to use either -w2 or -w1 depending on whether they find both client and server or just the server cert. If this behavior could be brought into the tools, it would simplify the client scripting significantly and put more of the logic into the tools (rather than scripts) on both the client and server.

Something like this:

Option Server behavior Client behavior

---

-w0 Server allows -w0/1/2 Client connects based on certs, -w2 first -w1 Server allows -w1/2 Client connects based on certs, -w2 first -w2 Server allows -w2 Client connects based on certs, -w2 first --wminX Server allows -wX min Client connects based on certs, -wX min --wmaxY Server allows -wY max Client connects based on certs, -wY max

However, I don't necessarily think that the client tools should even have the options anymore. They may be useful for testing/verification purposes, but overall I think the client should just negotiate the "best" authorization type allowed by the server (and its administrator).

Original comment by: jaharmi