3 Oct
2010
3 Oct
'10
1:06 p.m.
i tried to register sip-communication over tls, but sr complained about
wrong tls version:
Oct 3 19:29:58 sip /usr/sbin/sip-proxy[31340]: ERROR: tls [tls_server.c:1174]:
tls_read_f(): TLS accept:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
rfc3261 refers to
T. Dierks and C. Allen, “The TLS protocol version 1.0,” RFC 2246,
Internet Engineering Task Force, Jan. 1999.
which is 11 years old and also to
P. Chown, “Advanced encryption standard (AES) ciphersuites for transport
layer security (TLS),” RFC 3268, Internet Engineering Task Force, June
2002.
which is 8 years old. also there is statement
The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [26] MUST be supported at a
minimum by implementers when TLS is used in a SIP application. For
purposes of backwards compatibility, proxy servers,
redirect servers, and registrars SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other
ciphersuite.
how is it possible that sip-communicator that is much newer than those
rfcs, does not support them, but proposes in its client hello SSLv2?
nowhere in rf3261 was i able to find any references to these:
* SSLv3 - only SSLv3 connections are accepted
* SSLv2 - only SSLv2 connections, for old clients. Note: you
shouldn't use SSLv2 for anything which should be highly secure.
how is it possible that they would be ever needed? why don't we have
these kind of problems when accessing web sites? has rfc3261 somehow
got it wrong or what?
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?
-- juha
3 Oct
3 Oct
4:53 p.m.
Juha,
On Sun, Oct 3, 2010 at 1:06 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
i tried to register sip-communication over tls, but sr
complained about
wrong tls version:
Oct 3 19:29:58 sip /usr/sbin/sip-proxy[31340]: ERROR: tls [tls_server.c:1174]:
tls_read_f(): TLS accept:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
rfc3261 refers to
T. Dierks and C. Allen, “The TLS protocol version 1.0,” RFC 2246,
Internet Engineering Task Force, Jan. 1999.
which is 11 years old and also to
P. Chown, “Advanced encryption standard (AES) ciphersuites for transport
layer security (TLS),” RFC 3268, Internet Engineering Task Force, June
2002.
which is 8 years old. also there is statement
The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [26] MUST be supported at a
minimum by implementers when TLS is used in a SIP application. For
purposes of backwards compatibility, proxy servers,
redirect servers, and registrars SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other
ciphersuite.
how is it possible that sip-communicator that is much newer than those
rfcs, does not support them, but proposes in its client hello SSLv2?
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).
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.
Note that although TLSv1 is required by RFC3261, in practise I have
seen most implementations using SSLv23 by default.
nowhere in rf3261 was i able to find any references to
these:
* SSLv3 - only SSLv3 connections are accepted
* SSLv2 - only SSLv2 connections, for old clients. Note: you
shouldn't use SSLv2 for anything which should be highly secure.
how is it possible that they would be ever needed? why don't we have
these kind of problems when accessing web sites? has rfc3261 somehow
got it wrong or what?
For clients that use OpenSSL these are rarely needed. There are,
however, clients that do not use OpenSSL for crypto (mostly due to
licensing reasons) and for such clients you might need these options
if they do not support TLSv1.
We don't experience these problems with websites becuase they are
mostly using SSLv23 by default (as far as I can tell) and all the
browsers use OpenSSL for crypto.
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.
-Jan
4 Oct
4 Oct
3: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
6:27 a.m.
On Oct 04, 2010 at 10:48, Juha Heinanen <jh(a)tutpro.com> wrote:
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.
In this case the client is wrong and to support it we would need to quickly
add some untested code to the new release... We would also need some
other/extended config option (strict TLSv1 and compat TLSv1).
Maybe for the 3.2 or 3.1.1.
Andrei
jan,
thanks for your comments.
Strictly speaking according to the RFCs, only TLSv1 should be supported
(and this includes only a TLSv1 hello messsage!).
The problem with SSLv23 is that it should use SSLv23 only when it acts
as server (if it uses SSLv23 when it acts as client a TLSv1 only server
will not allow it to connect). Moreover if you use SSLv23 you might end
up accepting a SSLv2 client. Theoretically we could workaround this in
the code by setting SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3 (probably only
for the server part, the client would still have to support only TLSv1)
but I never tested it.
OTOH if you don't care about accepting clients using SSLv2 or SSLv3, you
could set in the tls config the method to TLSv1 for default client mode
and SSLv23 for the default server mode.
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.
12:21 p.m.
Andrei Pelinescu-Onciul writes:
The problem with SSLv23 is that it should use SSLv23
only when it acts
as server (if it uses SSLv23 when it acts as client a TLSv1 only server
will not allow it to connect). Moreover if you use SSLv23 you might end
up accepting a SSLv2 client. Theoretically we could workaround this in
the code by setting SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3 (probably only
for the server part, the client would still have to support only TLSv1)
but I never tested it.
after i changed sr tls_method to SSLv23, sip-communicator was able to
establish tls connection and wireshark showed that negotiation resulted
in TLSv1 even when initial client hello was SSLv2.
so looks to me that it makes sense to have a new mode that only allows
TLSv1, but accepts either TLSv1 or SSLv2 initial client hello. i'll add
a tracker entry about it.
-- juha
5170
days inactive
5171
days old
4 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Jan Janak -
Juha Heinanen