Hello Cesc,

Thanks for your answer!

If you want just one setup, then you are forced to use the "less

secure" setup so that your UAs can support it. I think this is not a sufficient solution. Maybe it's possible to make black- or whitelists for authentication rules in future developments (just an quick'n'dirty idea). With NAPTR-lookup support, the t_relay_to_tls("specific domain","specific port") function could also be serviced by t_relay(), or am I wrong?

regards, Philipp

Cesc wrote:

Hi Alexander,

That is a very good question. An option you have is to use tls_verify=1 tls_require_cert=0 This will make ser to request a certificate from the other peer, but if the peer does not send one the TLS handshake will still succeed.

This is from the readme file:

• How does verification work?

Verification is the process by which the authentication data provided by the peers is checked. This data consists usually of a peer certificate, plus a chain of trusted certification authorities. If for whatever reason, either of the peers thinks that the handshake is not valid, the ssl connection is not established. The reasons could be many: untrusted server certficate, too-weak algorithm, invalid client cert, no client authentication, ...

The "tls_verify" and "tls_require_certificate" are SER-names for the OpenSSL defined flags SSL_VERIFY_PEER (tls_verify) and SSL_VERIFY_FAIL_IF_NO_PEER_CERT (tls_require_certificate). tls_require_certificate is only used if tls_verify=1.

If we are acting as a server, we always send our server-side certificate to the client. - If tls_verify=0, we do not request the client a client-certificate. This means that the client is not authenticated. - If tls_verify=1, we (the server) send a client-certificate request to the client. But the client is free to not provide any. In this case, tls_require_certificate comes into play: _ if tls_require_cert=0, the verification process will succedd if the client does not provide a certificate, or if it provides one, it verifies correctly against the server's list of trusted certification authorities. _ if tls_require_cert=1, the verification process will only succeed if the client provides a certificate and this verifies correctly against the server's list of trusted CAs.

=====================================================================

Now, another option: Create two different domains, one for UAs, the other for inter-proxy connection. This way, on the UA domain you can be more lax in the settings (tls_verify=1, tls_require_cert=0), whereas in the inter-proxy domain you can force certs (tls_verify=1, tls_require_cert=1).

I guess this you probably don't want to do. If you want just one setup, then you are forced to use the "less secure" setup so that your UAs can support it.

Hope it helps,

Cesc

On 10/8/05, *Alexander Ph. Lintenhofer* <lintenhofer@aon.at mailto:lintenhofer@aon.at> wrote:

Hi there,

I have a question concerning TLS in openser:

By switching tls_require_certificate to "on", the peer is forced
to send
his certificate for means of mutual authentication.

My problem is, that the peer may be another proxy server whom I
want to
authenticate with its cert - but the peer might also be an user agent.
In my situation I use a Snom 360 which has not the possibility to
import
an own user-certificate (only a CA-cert for verifying server-certs).

-----------                         ----------
---------
| snom 360  | <------  TLS -------> | outbound | <----- TLS -----> |
inbound |
-----------   server sends cert     ----------     mutual AUTH
---------


But when I activate tls_require_certificate=on in the openser.cfg
of the
outbound proxy, the snom360 can't register, because it has no
user-cert.
On the other hand, when I disable tls_require_certificate, the
snom can
register, but the security between the proxies is weak.

Is there an appropriate solution for this problem ?? Maybe I didn't
understand the sample configuration at all....

Thanks in advance and regards,

Philipp


_______________________________________________
Users mailing list
Users@openser.org <mailto:Users@openser.org>
http://openser.org/cgi-bin/mailman/listinfo/users