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

Hi Cesc,

Cesc wrote:

See inline ...

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

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

Do you mean something like: if connecting ip:port is in white list, apply a less restrictive tls authentication (do not require peer cert) if connectin ip:port is not in white list or in black list, demand a stronger auth Is that it? Note that you can only do this lists based on ip:port, as TLS setup is previous to any sip exchange.

What i really think it could work is to create a function (probably in a tls_utils module), which may allow to perform the extra verification that you could not when tls setup. I mean, you setup all tls asking for a certificate from the other peer, but do not require that it sends it. Then, from within the config file, you could use a special function and force ser to perform the extra verification on the tls (equivalent to tls_require_cert=1)

I think this would be a good work around and not difficult to add. It's something like Klaus suggested in later email

Just a thought ...

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?

Indeed, it should work. I don't know if ser uses the lookups correctly ... t_relay should already work if your endpoint registered the contact over tls (transport=tls). For inter-proxy, either you rely on naptr or use the t_relay_to_tls.

the problem with t_relay_to_xxx is that it needs a port to be specify. And if port is specify, no SRV lookup is perform (according to RFC). Once we will have the NAPTR lookup, I'm thinking to redesign the function interface of al this t_relay...... function to be more flexible and easy to remember :-/.

right now, you cannot do (in a nice way), a relay to another proxy via TLS by using SRV. If you do t_relay_to_tls() -> adios SRV :(

The only solution I found was to use the DST_URI to force TLS without any port specifications: avp_write("sip:proxy.com;transport=tls","i:11"); avp_pushto("$duri","i:11"); t_relay();

it should also work with : avp_write("sips:proxy.com","i:11"); but never tried.

regards, bogdan