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. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54875743.1050...@pocock.pro
