Re: SSL 3.0 and older ciphers selected in applications

[Daniel Pocock <daniel@pocock.pro>]

On 08/12/14 21:28, Daniel Pocock wrote:
> 
> 
> 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.
>>
> 
> It plays a few roles:
> 
> 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
> 

Thanks for this feedback, I made a patch for the existing package and
submitted another unblock:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772634

To keep the change smaller, I just hardcoded it to use SSLv23_method and
not to use TLS 1.2 for any client connections.  This is still an
improvement over the previous behavior of the package using TLS 1.0 for
everything.