Re: SSL 3.0 and older ciphers selected in applications
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
Reply to: