Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
SSL 3.0 and older ciphers selected in applications
67 views
Skip to first unread message
Daniel Pocock
Dec 8, 2014, 3:20:03 AM12/8/14
to
Hi all,
I've made some changes to TLS code in reSIProcate
- setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()
- adding configuration options to override the options to
SSL_CTX_set_options (as it is possible there will be some user with old
VoIP hardware out there who wants SSL v3)
- making the cipher list configurable in repro.config
The release team didn't feel these things justify an unblock
request[1]. Can anybody comment on this? Looking at the CVE
details[2], it appears that some packages still support SSL v3 while
I've heard many people just want to turn it off.
Is it important for application developers to try and minimize the use
of SSL v3 and older ciphers or will these things be phased out by
changing the options centrally in the OpenSSL packages?
I felt that by putting control of these things in the libresip API and
the repro.config file it would help avoid situations where the package
needs to be recompiled to deal with security patching and therefore
reduce the burden on the security updates process.
If it will help the release team, is there anybody from the security
team who could review the changes in my debdiff?
Regards,
Daniel
1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772487
2. https://security-tracker.debian.org/tracker/CVE-2014-3566
--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/54855E6D...@pocock.pro
Adam D. Barratt
Dec 8, 2014, 4:30:04 AM12/8/14
to
On Mon, 2014-12-08 at 09:16 +0100, Daniel Pocock wrote:
[...]
the security team.
(Also I don't see anything in the nack mail that says it was related to
being unable to review the debdiff.)
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
[...]
> If it will help the release team, is there anybody from the security
> team who could review the changes in my debdiff?
Note that debian-...@lists.debian.org is not a contact address for
> team who could review the changes in my debdiff?
the security team.
(Also I don't see anything in the nack mail that says it was related to
being unable to review the debdiff.)
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
Daniel Pocock
Dec 8, 2014, 4:40:04 AM12/8/14
to
On 08/12/14 10:20, Adam D. Barratt wrote:
> On Mon, 2014-12-08 at 09:16 +0100, Daniel Pocock wrote:
> [...]
>> If it will help the release team, is there anybody from the security
>> team who could review the changes in my debdiff?
> Note that debian-...@lists.debian.org is not a contact address for
> the security team.
>
> (Also I don't see anything in the nack mail that says it was related to
> being unable to review the debdiff.)
I wasn't suggesting that was the cause for the nack email although I
> On Mon, 2014-12-08 at 09:16 +0100, Daniel Pocock wrote:
> [...]
>> If it will help the release team, is there anybody from the security
>> team who could review the changes in my debdiff?
> Note that debian-...@lists.debian.org is not a contact address for
> the security team.
>
> (Also I don't see anything in the nack mail that says it was related to
> being unable to review the debdiff.)
remember some discussion around the wheezy release that the size of
diffs is considered a factor in unblock requests.
I understand that sometimes the security team have made decisions about
what should go through to stable, e.g. for the browser version updates
and the security team are also getting involved if some vulnerability is
found in future so I value their opinion on this particular case.
The WebSocket transport (which includes TLS support) in packages like
reSIProcate, Kamailio and Asterisk needs to remain interoperable with
the browsers and the server side also needs to remain secure throughout
the life of jessie so there are a range of reasons I'm asking about this.
Kurt Roeckx
Dec 8, 2014, 5:20:02 AM12/8/14
to
On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote:
>
> Hi all,
>
> I've made some changes to TLS code in reSIProcate
>
> - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()
This has no effect in jessie. SSLv2 and SSLv3 are disabled if you
>
> Hi all,
>
> I've made some changes to TLS code in reSIProcate
>
> - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()
use the SSLv23_* methods. The only way to enable SSLv3 is to use
the SSLv3_* methods. You should always use the SSLv23 method as
those are the only that support more than 1 protocol version.
I would love to see people stopping the SSLv3 methods, and they
have been removed in experimental. I'm also working on only
having the SSLv23 method available.
Kurt
--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Daniel Pocock
Dec 8, 2014, 5:50:03 AM12/8/14
to
On 08/12/14 11:12, Kurt Roeckx wrote:
> On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote:
>> Hi all,
>>
>> I've made some changes to TLS code in reSIProcate
>>
>> - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()
> This has no effect in jessie. SSLv2 and SSLv3 are disabled if you
> use the SSLv23_* methods. The only way to enable SSLv3 is to use
> the SSLv3_* methods. You should always use the SSLv23 method as
> those are the only that support more than 1 protocol version.
Can you please clarify that - if somebody explicitly calls
> On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote:
>> Hi all,
>>
>> I've made some changes to TLS code in reSIProcate
>>
>> - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()
> This has no effect in jessie. SSLv2 and SSLv3 are disabled if you
> use the SSLv23_* methods. The only way to enable SSLv3 is to use
> the SSLv3_* methods. You should always use the SSLv23 method as
> those are the only that support more than 1 protocol version.
SSL_CTX_clear_options with SSL_OP_NO_SSLv3 will they get back support
for SSLv3 in SSLv23_method?
> I would love to see people stopping the SSLv3 methods, and they
> have been removed in experimental. I'm also working on only
> having the SSLv23 method available.
ISDN gateways to use on their LAN. Some of the older ones may not
support anything more than SSL v3 very well.
If these devices are used on a private VLAN then the risk of using old
crypto is not the same as the risk on the public Internet so I prefer to
give these people config options to support their hardware but disabled
by default.
Just one other point: if somebody is trying sending the client hello
using SSL v2 record layer but indicating support for TLS v1.0, should
TLSv1_method or SSLv23_method accept that?
There is an example of it here:
https://issues.asterisk.org/jira/browse/ASTERISK-13845
and it looks something like this:
Secure Sockets Layer
SSLv2 Record Layer: Client Hello
...
Version: TLS 1.0 (0x0301)
...
I've noticed that the reSIProcate code using TLSv1_method refuses to
accept connections from peers like that.
Should SSLv23_method support that even with v2 and v3 disabled?
--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Kurt Roeckx
Dec 8, 2014, 6:40:04 AM12/8/14
to
On Mon, Dec 08, 2014 at 11:42:28AM +0100, Daniel Pocock wrote:
> On 08/12/14 11:12, Kurt Roeckx wrote:
> > On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote:
> >> Hi all,
> >>
> >> I've made some changes to TLS code in reSIProcate
> >>
> >> - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()
> > This has no effect in jessie. SSLv2 and SSLv3 are disabled if you
> > use the SSLv23_* methods. The only way to enable SSLv3 is to use
> > the SSLv3_* methods. You should always use the SSLv23 method as
> > those are the only that support more than 1 protocol version.
>
> Can you please clarify that - if somebody explicitly calls
> SSL_CTX_clear_options with SSL_OP_NO_SSLv3 will they get back support
> for SSLv3 in SSLv23_method?
No, the library doesn't support SSLv3 in combination with the
> On 08/12/14 11:12, Kurt Roeckx wrote:
> > On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote:
> >> Hi all,
> >>
> >> I've made some changes to TLS code in reSIProcate
> >>
> >> - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()
> > This has no effect in jessie. SSLv2 and SSLv3 are disabled if you
> > use the SSLv23_* methods. The only way to enable SSLv3 is to use
> > the SSLv3_* methods. You should always use the SSLv23 method as
> > those are the only that support more than 1 protocol version.
>
> Can you please clarify that - if somebody explicitly calls
> SSL_CTX_clear_options with SSL_OP_NO_SSLv3 will they get back support
> for SSLv3 in SSLv23_method?
SSLv23 method. Setting or clearing SSL_OP_NO_SSLv3 doesn't have
any effect.
> > I would love to see people stopping the SSLv3 methods, and they
> > have been removed in experimental. I'm also working on only
> > having the SSLv23 method available.
>
> In VoIP, this is not so trivial. People have devices like IP phones and
> ISDN gateways to use on their LAN. Some of the older ones may not
> support anything more than SSL v3 very well.
>
> If these devices are used on a private VLAN then the risk of using old
> crypto is not the same as the risk on the public Internet so I prefer to
> give these people config options to support their hardware but disabled
> by default.
> Just one other point: if somebody is trying sending the client hello
> using SSL v2 record layer but indicating support for TLS v1.0, should
> TLSv1_method or SSLv23_method accept that?
> There is an example of it here:
> https://issues.asterisk.org/jira/browse/ASTERISK-13845
>
> and it looks something like this:
>
> Secure Sockets Layer
> SSLv2 Record Layer: Client Hello
> ...
> Version: TLS 1.0 (0x0301)
> ...
>
> I've noticed that the reSIProcate code using TLSv1_method refuses to
> accept connections from peers like that.
>
> Should SSLv23_method support that even with v2 and v3 disabled?
Kurt
--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Daniel Pocock
Dec 8, 2014, 7:30:02 AM12/8/14
to
On 08/12/14 12:36, Kurt Roeckx wrote:
> On Mon, Dec 08, 2014 at 11:42:28AM +0100, Daniel Pocock wrote:
>> On 08/12/14 11:12, Kurt Roeckx wrote:
>>> On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote:
>>>> Hi all,
>>>>
>>>> I've made some changes to TLS code in reSIProcate
>>>>
>>>> - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()
>>> This has no effect in jessie. SSLv2 and SSLv3 are disabled if you
>>> use the SSLv23_* methods. The only way to enable SSLv3 is to use
>>> the SSLv3_* methods. You should always use the SSLv23 method as
>>> those are the only that support more than 1 protocol version.
>> Can you please clarify that - if somebody explicitly calls
>> SSL_CTX_clear_options with SSL_OP_NO_SSLv3 will they get back support
>> for SSLv3 in SSLv23_method?
> No, the library doesn't support SSLv3 in combination with the
> SSLv23 method. Setting or clearing SSL_OP_NO_SSLv3 doesn't have
> any effect.
>
Thanks for confirming that.
> On Mon, Dec 08, 2014 at 11:42:28AM +0100, Daniel Pocock wrote:
>> On 08/12/14 11:12, Kurt Roeckx wrote:
>>> On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote:
>>>> Hi all,
>>>>
>>>> I've made some changes to TLS code in reSIProcate
>>>>
>>>> - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method()
>>> This has no effect in jessie. SSLv2 and SSLv3 are disabled if you
>>> use the SSLv23_* methods. The only way to enable SSLv3 is to use
>>> the SSLv3_* methods. You should always use the SSLv23 method as
>>> those are the only that support more than 1 protocol version.
>> Can you please clarify that - if somebody explicitly calls
>> SSL_CTX_clear_options with SSL_OP_NO_SSLv3 will they get back support
>> for SSLv3 in SSLv23_method?
> No, the library doesn't support SSLv3 in combination with the
> SSLv23 method. Setting or clearing SSL_OP_NO_SSLv3 doesn't have
> any effect.
>
>>> I would love to see people stopping the SSLv3 methods, and they
>>> have been removed in experimental. I'm also working on only
>>> having the SSLv23 method available.
>> In VoIP, this is not so trivial. People have devices like IP phones and
>> ISDN gateways to use on their LAN. Some of the older ones may not
>> support anything more than SSL v3 very well.
>>
>> If these devices are used on a private VLAN then the risk of using old
>> crypto is not the same as the risk on the public Internet so I prefer to
>> give these people config options to support their hardware but disabled
>> by default.
> So why use SSL at all?
It is not an issue for my own personal use cases.
>> Just one other point: if somebody is trying sending the client hello
>> using SSL v2 record layer but indicating support for TLS v1.0, should
>> TLSv1_method or SSLv23_method accept that?
> I would expect that both should support that.
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Error code = 336130315 file=s3_pkt.c line=348
>
>> There is an example of it here:
>> https://issues.asterisk.org/jira/browse/ASTERISK-13845
>>
>> and it looks something like this:
>>
>> Secure Sockets Layer
>> SSLv2 Record Layer: Client Hello
>> ...
>> Version: TLS 1.0 (0x0301)
>> ...
>>
>> I've noticed that the reSIProcate code using TLSv1_method refuses to
>> accept connections from peers like that.
>>
>> Should SSLv23_method support that even with v2 and v3 disabled?
> Yes it should.
>
--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/54859797...@pocock.pro
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Kurt Roeckx
Dec 8, 2014, 8:00:04 AM12/8/14
to
On Mon, Dec 08, 2014 at 01:20:39PM +0100, Daniel Pocock wrote:
> >> Just one other point: if somebody is trying sending the client hello
> >> using SSL v2 record layer but indicating support for TLS v1.0, should
> >> TLSv1_method or SSLv23_method accept that?
> > I would expect that both should support that.
>
> With TLSv1_method and reSIProcate/OpenSSL on wheezy it fails with
>
> error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
>
> Error code = 336130315 file=s3_pkt.c line=348
So I start an s_server with:
> >> Just one other point: if somebody is trying sending the client hello
> >> using SSL v2 record layer but indicating support for TLS v1.0, should
> >> TLSv1_method or SSLv23_method accept that?
> > I would expect that both should support that.
>
> With TLSv1_method and reSIProcate/OpenSSL on wheezy it fails with
>
> error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
>
> Error code = 336130315 file=s3_pkt.c line=348
openssl s_server -tls1
And then:
openssl s_client: TLSv1
openssl s_client -tls1: TLSv1
I tried the s_server and s_client on both jessie and wheezy. This
should just work.
If both sides drop the -tls1 of course changes to TLSv1.2.
But it really should always work, and if doesn't I'd argue that's
a bug.
But you say that it sends an SSLv2 compatible client hello. By
default it shouldn't be doing that unless you change the ciphers
suite to include SSLv2 ciphers and aren't using any extentions,
and as far as I know you currently can't disable extentions in
either wheez or jessie.
Kurt
--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Daniel Pocock
Dec 8, 2014, 8:40:03 AM12/8/14
to
On 08/12/14 13:53, Kurt Roeckx wrote:
> On Mon, Dec 08, 2014 at 01:20:39PM +0100, Daniel Pocock wrote:
>>>> Just one other point: if somebody is trying sending the client hello
>>>> using SSL v2 record layer but indicating support for TLS v1.0, should
>>>> TLSv1_method or SSLv23_method accept that?
>>> I would expect that both should support that.
>> With TLSv1_method and reSIProcate/OpenSSL on wheezy it fails with
>>
>> error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
>>
>> Error code = 336130315 file=s3_pkt.c line=348
> So I start an s_server with:
> openssl s_server -tls1
>
> And then:
> openssl s_client: TLSv1
> openssl s_client -tls1: TLSv1
>
> I tried the s_server and s_client on both jessie and wheezy. This
> should just work.
>
> If both sides drop the -tls1 of course changes to TLSv1.2.
>
> But it really should always work, and if doesn't I'd argue that's
> a bug.
>
> But you say that it sends an SSLv2 compatible client hello. By
> default it shouldn't be doing that unless you change the ciphers
> suite to include SSLv2 ciphers and aren't using any extentions,
> and as far as I know you currently can't disable extentions in
> either wheez or jessie.
It is the opposite - the remote system is sending the SSLv2 compatible
> On Mon, Dec 08, 2014 at 01:20:39PM +0100, Daniel Pocock wrote:
>>>> Just one other point: if somebody is trying sending the client hello
>>>> using SSL v2 record layer but indicating support for TLS v1.0, should
>>>> TLSv1_method or SSLv23_method accept that?
>>> I would expect that both should support that.
>> With TLSv1_method and reSIProcate/OpenSSL on wheezy it fails with
>>
>> error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
>>
>> Error code = 336130315 file=s3_pkt.c line=348
> So I start an s_server with:
> openssl s_server -tls1
>
> And then:
> openssl s_client: TLSv1
> openssl s_client -tls1: TLSv1
>
> I tried the s_server and s_client on both jessie and wheezy. This
> should just work.
>
> If both sides drop the -tls1 of course changes to TLSv1.2.
>
> But it really should always work, and if doesn't I'd argue that's
> a bug.
>
> But you say that it sends an SSLv2 compatible client hello. By
> default it shouldn't be doing that unless you change the ciphers
> suite to include SSLv2 ciphers and aren't using any extentions,
> and as far as I know you currently can't disable extentions in
> either wheez or jessie.
client hello. The Debian/repro system is the server side.
I have no idea what technology is in use in the remote/client system.
If my server socket is using TLSv1_method it is rejecting the connection
and logging those errors on my server:
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
Error code = 336130315 file=s3_pkt.c line=348
--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Kurt Roeckx
Dec 8, 2014, 1:00:05 PM12/8/14
to
On Mon, Dec 08, 2014 at 02:35:00PM +0100, Daniel Pocock wrote:
>
> I have no idea what technology is in use in the remote/client system.
>
> If my server socket is using TLSv1_method it is rejecting the connection
> and logging those errors on my server:
>
> error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
> Error code = 336130315 file=s3_pkt.c line=348
>
> My server then sends TCP RST to the client
So I can actually reproduce this with the s_client from squeeze,
>
> I have no idea what technology is in use in the remote/client system.
>
> If my server socket is using TLSv1_method it is rejecting the connection
> and logging those errors on my server:
>
> error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
> Error code = 336130315 file=s3_pkt.c line=348
>
> My server then sends TCP RST to the client
since that still generates an SSLv2 compatible client hello. That
does fail talking to any server using the TLSv1 method but
works talking to the SSLv23 method. Since I'm actually going to
remove support for the TLSv1 method I don't intend to fix this.
Kurt
--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Daniel Pocock
Dec 8, 2014, 1:30:04 PM12/8/14
to
On 08/12/14 18:58, Kurt Roeckx wrote:
> On Mon, Dec 08, 2014 at 02:35:00PM +0100, Daniel Pocock wrote:
>>
>> I have no idea what technology is in use in the remote/client system.
>>
>> If my server socket is using TLSv1_method it is rejecting the connection
>> and logging those errors on my server:
>>
>> error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
>> Error code = 336130315 file=s3_pkt.c line=348
>>
>> My server then sends TCP RST to the client
>
> So I can actually reproduce this with the s_client from squeeze,
> since that still generates an SSLv2 compatible client hello. That
> does fail talking to any server using the TLSv1 method but
> works talking to the SSLv23 method. Since I'm actually going to
> remove support for the TLSv1 method I don't intend to fix this.
>
supported?
If so, then applications like repro that use it by default will need to
be patched.
--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Kurt Roeckx
Dec 8, 2014, 1:30:04 PM12/8/14
to
On Mon, Dec 08, 2014 at 07:22:33PM +0100, Daniel Pocock wrote:
>
> Will the TLSv1 method be removed in jessie or while jessie is still
> supported?
This is something post jessie.
>
> Will the TLSv1 method be removed in jessie or while jessie is still
> supported?
Kurt
--
To UNSUBSCRIBE, email to debian-secu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Daniel Pocock
Dec 8, 2014, 1:50:03 PM12/8/14
to
On 08/12/14 19:25, Kurt Roeckx wrote:
> On Mon, Dec 08, 2014 at 07:22:33PM +0100, Daniel Pocock wrote:
>>
>> Will the TLSv1 method be removed in jessie or while jessie is still
>> supported?
>
> This is something post jessie.
>
(e.g. April 2015)?
If so, it means that the repro package in jessie won't talk to a repro
package in Ubuntu.
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
Kurt Roeckx
Dec 8, 2014, 2:10:03 PM12/8/14
to
On Mon, Dec 08, 2014 at 07:42:54PM +0100, Daniel Pocock wrote:
>
> Is it something that is going to happen with Ubuntu releases next year
> (e.g. April 2015)?
>
> If so, it means that the repro package in jessie won't talk to a repro
> package in Ubuntu.
I think there is some misunderstanding.
>
> Is it something that is going to happen with Ubuntu releases next year
> (e.g. April 2015)?
>
> If so, it means that the repro package in jessie won't talk to a repro
> package in Ubuntu.
People have been using methods like SSLv3_* and TLSv1_* while they
should use SSLv23_*. SSLv3_* only support SSL 3.0, TLSv1_* only
support TLS 1.0, it does not support SSL 3.0 or TLS 1.1. SSLv23_*
on the other hand supports all versions supported by library (but
see below). The intention is to drop all methods that only
support 1 protocol version and instead have only methods that
support all versions (SSLv23).
The library in jessie supports TLS 1.0 to TLS 1.2. However the
the SSLv3 methods still exist in jessie so you can still talk SSL
3.0 in jessie. However the SSLv23 methods do not support SSL 3.0
in jessie anymore. They still supports SSL 3.0 in wheezy. That
means if one side uses SSLv3_* and the the verion in jessie or
later use SSLv23_* they will not talk to each other. And there
are packages that have been fixed to stop using the SSLv3_*
methods in jessie and they will not talk to the version in wheezy.
The versie in wheezy really should also get fixed to use the
SSLv23_* method.
The SSLv3_* method has been removed in experimental and the
TLSv1_* method will also be removed post jessie but I have no
timeframe for that. But everybody really should only use the
SSLv23_* methods.
But the removal of the TLSv1_* methods should not cause any issue
if you replace it by the SSLv23_* methods since there currently
are no plans to drop support for TLS 1.0.
Kurt
Daniel Pocock
Dec 8, 2014, 2:30:03 PM12/8/14
to
TLSv1_method.
The v1.9.8-1 upload to unstable, which will also propagate to the next
Ubuntu and will also be uploaded to Fedora very soon, uses SSLv23_method
If I understand your reply correctly, the version in Ubuntu and Fedora
will still talk TLS 1.0 with the version now waiting in jessie?
Do you believe it would be reasonable for me to request a smaller
unblock that just changes the call TLSv1_method to SSLv23_method?
Kurt Roeckx
Dec 8, 2014, 3:20:03 PM12/8/14
to
On Mon, Dec 08, 2014 at 08:17:53PM +0100, Daniel Pocock wrote:
>
> If I understand your reply correctly, the version in Ubuntu and Fedora
> will still talk TLS 1.0 with the version now waiting in jessie?
Yes.
>
> If I understand your reply correctly, the version in Ubuntu and Fedora
> will still talk TLS 1.0 with the version now waiting in jessie?
> Do you believe it would be reasonable for me to request a smaller
> unblock that just changes the call TLSv1_method to SSLv23_method?
acting as server I say yes. If it's acting as client I suggest
you also have a way to turn off TLS 1.2. I understand that it
needs to be able to talk to many different things and TLS 1.2 has
has been breaking things it shouldn't and you already indicated
problems with some products. But maybe it just needs to be used
for a while with the SSLv23 method to see if there are problems or
not.
Kurt
Daniel Pocock
Dec 8, 2014, 3:40:03 PM12/8/14
to
On 08/12/14 21:16, Kurt Roeckx wrote:
> On Mon, Dec 08, 2014 at 08:17:53PM +0100, Daniel Pocock wrote:
>>
>> If I understand your reply correctly, the version in Ubuntu and Fedora
>> will still talk TLS 1.0 with the version now waiting in jessie?
>
> Yes.
>
>> Do you believe it would be reasonable for me to request a smaller
>> unblock that just changes the call TLSv1_method to SSLv23_method?
>
> That depends on wether it's acting as client or server. If it's
> acting as server I say yes. If it's acting as client I suggest
> you also have a way to turn off TLS 1.2. I understand that it
> needs to be able to talk to many different things and TLS 1.2 has
> has been breaking things it shouldn't and you already indicated
> problems with some products. But maybe it just needs to be used
> for a while with the SSLv23 method to see if there are problems or
> not.
>
a) repro acts as a WebSocket server (for WebRTC)
b) in federated SIP, repro acts as both server and client
c) in a phone system, repro acts as server (e.g. my home phone system
has some Polycom desk phones, Jitsi with JDK1.7 and Lumicall on Android
as clients)
d) people use the reSIProcate library in all kinds of products where it
is client (e.g. in Counterpath softphones) or server (e.g. in some
commercial Session Border Controllers).
All of these use cases are supported by the Debian packages.
For the SIP proxy, repro, the smallest possible change to use SSLv23 as
default would involve touching 6 lines of code in repro/ReproRunner.cxx,
replacing SecurityTypes::TLSv1 with
SecurityTypes::SSLv23 on each. As well as changing the server behavior,
this also has the effect of enabling TLS 1.2 when acting as client in a
federated SIP connection.
For other uses of the library it is up to the developer to select SSLv23
when they call SipStack::addTransport
0 new messages