4 Oct
2010
4 Oct
'10
9:48 a.m.
jan,
thanks for your comments.
yes, but as i mention in above, looks like sr's tls_method TLSv1 does
not wait for the upgrade, but reject the connection attempt at first
hello.
If sip-communicator uses openssl then it should also
support SSLv23
and TLSv1. It maybe be configured to use the SSLv23 mode by default
which should theoretically provide the best compatibility with other
implementations because it supports all other protocols (TLSv1, SSLv3,
SSLv2).
there are on configuration options in sip-communicator ui regarding ssl
protocol versions.
In SSLv23 the client is supposed to send the initial
hello in SSLv2
for compatibility reasons.
If you configured your server to use TLSv1 then it will accept TLSv1
hellos only and the SSLv2 hello won't be accepted.
if SSLv23 supports all protocol versions (also TLSv1) then i think sip
router tls module needs a fix: if i tls_method TLSv1 is set, then sr
should accept whatever hellos as long as the final result of the
negotiation is TLSv1.
andrei, any commend on this?
also, it was
not clear from tls/README that if i set
modparam("tls", "tls_method", "SSLv23")
will it mean that TLSv1 connections (as required by rfc3261) are not
accepted if UA only support TLSv1 and proposes in client hello?
Yes. But if the client is configured to use SSLv23, they could
exchange the initial hellos in SSLv2 and then upgrade to TLSv1. Although RFC3261 requires TLSv1, it is not clear to me
whether they
mean that TLSv1 connections should be used from start or if upgrading
to TLSv1 after the initial hello in SSLv2 is also considered
compliant.
it sounds reasonable to me that as long the result is TLSv1, it should
not matter what kind of negotiation was done to achieve it. the old
rule is be liberal in what you expect.
-- juha