Protect against new SSL vuln
Hi to the list, What is the way to disable SSLv3 in CalendarServer to protect against POODLE? Thanks in advance Pascal
Hi Pascal, --On October 16, 2014 at 12:38:37 PM -0400 Pascal Dallaire <pascaldallaire@cre-gim.net> wrote:
What is the way to disable SSLv3 in CalendarServer to protect against POODLE?
Our trunk code has the fix. The svn diff for the change is here: <https://trac.calendarserver.org/changeset/14035> Depending on what version you are using, you should be able to apply that change relatively easily. Older variants might also need the following applied: <https://trac.calendarserver.org/changeset/14062> -- Cyrus Daboo
Hello there, Thanks for answering so quickly! I’m trying to use the older variants method before I upgrade the Calendar server completely. But in this patch, isn’t the best method TLSv1? and not SSLv23? Pascal Le 2014-10-16 à 12:42, Cyrus Daboo <cdaboo@apple.com> a écrit :
Hi Pascal,
--On October 16, 2014 at 12:38:37 PM -0400 Pascal Dallaire <pascaldallaire@cre-gim.net> wrote:
What is the way to disable SSLv3 in CalendarServer to protect against POODLE?
Our trunk code has the fix. The svn diff for the change is here:
<https://trac.calendarserver.org/changeset/14035>
Depending on what version you are using, you should be able to apply that change relatively easily. Older variants might also need the following applied:
<https://trac.calendarserver.org/changeset/14062>
-- Cyrus Daboo
On Oct 16, 2014, at 7:41 PM, Pascal Dallaire <pascaldallaire@cre-gim.net> wrote:
Hello there,
Thanks for answering so quickly! I’m trying to use the older variants method before I upgrade the Calendar server completely. But in this patch, isn’t the best method TLSv1? and not SSLv23?
I was confused by this, too. According to https://www.openssl.org/docs/ssl/SSL_CTX_new.html SSLv23_method is a catch-all, allowing connections using SSLv2, SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols. You can then exclude particular protocols using, e.g., SSL_OP_NO_TLSv1_1 to exclude TLSv1.1 (while still allowing the others). By contrast, TLSv1_method (or SSLv3_method) allows only connections using that particular protocol (respectively TLSv1 and SSLv3). That may be OK. All (or almost all) clients speak TLSv1. But it would be preferable to allow them to negotiate a TLSv1.2 connection if possible.
Pascal
Le 2014-10-16 à 12:42, Cyrus Daboo <cdaboo@apple.com> a écrit :
Hi Pascal,
--On October 16, 2014 at 12:38:37 PM -0400 Pascal Dallaire <pascaldallaire@cre-gim.net> wrote:
What is the way to disable SSLv3 in CalendarServer to protect against POODLE?
Our trunk code has the fix. The svn diff for the change is here:
<https://trac.calendarserver.org/changeset/14035>
Depending on what version you are using, you should be able to apply that change relatively easily. Older variants might also need the following applied:
<https://trac.calendarserver.org/changeset/14062>
-- Cyrus Daboo
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
On Oct 16, 2014, at 7:26 PM, Jacques Distler <distler@golem.ph.utexas.edu> wrote:
I was confused by this, too. According to
https://www.openssl.org/docs/ssl/SSL_CTX_new.html <https://www.openssl.org/docs/ssl/SSL_CTX_new.html>
SSLv23_method is a catch-all, allowing connections using SSLv2, SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols. You can then exclude particular protocols using, e.g.,
SSL_OP_NO_TLSv1_1
to exclude TLSv1.1 (while still allowing the others).
By contrast, TLSv1_method (or SSLv3_method) allows only connections using that particular protocol (respectively TLSv1 and SSLv3).
That may be OK. All (or almost all) clients speak TLSv1. But it would be preferable to allow them to negotiate a TLSv1.2 connection if possible.
For what it's worth, this is the highly bizarre way that OpenSSL requires you to specify your protocol version requirements. In TLS itself, there's no such thing as a "method", just a protocol version. You're absolutely right that SSLv23_METHOD has nothing to do with SSLv2 or SSLv3 and just means "negotiate a protocol version out of an allowable set". In a future version of Twisted there will be the ability to specify minimum protocol version and excluded protocol version arguments, and SSLv23_METHOD should hopefully fade away and disappear into an internal implementation detail somewhere inside Twisted's TLS layer... -glyph
Hi Glyph, --On October 17, 2014 at 2:10:02 AM -0700 Glyph <glyph@twistedmatrix.com> wrote:
In a future version of Twisted there will be the ability to specify minimum protocol version and excluded protocol version arguments, and SSLv23_METHOD should hopefully fade away and disappear into an internal implementation detail somewhere inside Twisted's TLS layer...
A that's good. I was actually considering making that change myself in our calendar server code. Has this work started in Twisted? -- Cyrus Daboo
On Oct 17, 2014, at 6:36 AM, Cyrus Daboo <cdaboo@apple.com> wrote:
Hi Glyph,
--On October 17, 2014 at 2:10:02 AM -0700 Glyph <glyph@twistedmatrix.com> wrote:
In a future version of Twisted there will be the ability to specify minimum protocol version and excluded protocol version arguments, and SSLv23_METHOD should hopefully fade away and disappear into an internal implementation detail somewhere inside Twisted's TLS layer...
A that's good. I was actually considering making that change myself in our calendar server code. Has this work started in Twisted?
I've just filed the first ticket about it recently: <http://twistedmatrix.com/trac/ticket/7685 <http://twistedmatrix.com/trac/ticket/7685>>, but I've been working quite a lot in the area of TLS this year, and most things have proceeded fairly quickly. I expect that I will have something started in the next couple of weeks; keep an eye on that ticket. -glyph
participants (5)
-
Cyrus Daboo
-
Glyph
-
Glyph Lefkowitz
-
Jacques Distler
-
Pascal Dallaire