Apple are, apparently, dicks...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Apple are, apparently, dicks...

Ben Laurie-2
...and don't intend to fix their broken ECDSA support in Safari.

It is therefore suggested that I pull this patch:

https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d

What do people think?
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Bodo Moeller
On Thu, Jun 13, 2013 at 6:39 PM, Ben Laurie <[hidden email]> wrote:

It is therefore suggested that I pull this patch:

https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d

The behavior change applies only if new option SSL_OP_SAFARI_ECDHE_ECDSA_BUG is used (part of SSL_OP_ALL), as is standard for interoperability bug workarounds, so while it is very unfortunate that we'd need to do this, I'm in favor of accepting this patch.





Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Rob Stradling
In reply to this post by Ben Laurie-2
On 13/06/13 17:39, Ben Laurie wrote:
> ...and don't intend to fix their broken ECDSA support in Safari.

Ben, you've got your wires a bit crossed there.

The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to
10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week).

> It is therefore suggested that I pull this patch:
>
> https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d
>
> What do people think?

The unfortunate reality is that significant numbers of OSX 10.8.x users
won't upgrade to 10.8.4 anytime soon, even though the upgrade is free
and easy to install.

No server administrator will want to deploy ECDHE-ECDSA if it means
breaking compatibility with even a small fraction of deployed browsers.
  Hence why this patch is, unfortunately, necessary.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Ben Laurie-2
On 14 June 2013 09:39, Rob Stradling <[hidden email]> wrote:

> On 13/06/13 17:39, Ben Laurie wrote:
>>
>> ...and don't intend to fix their broken ECDSA support in Safari.
>
>
> Ben, you've got your wires a bit crossed there.
>
> The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to
> 10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week).
>
>
>> It is therefore suggested that I pull this patch:
>>
>>
>> https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d
>>
>> What do people think?
>
>
> The unfortunate reality is that significant numbers of OSX 10.8.x users
> won't upgrade to 10.8.4 anytime soon, even though the upgrade is free and
> easy to install.

Precisely my point - so how were my wires crossed?

> No server administrator will want to deploy ECDHE-ECDSA if it means breaking
> compatibility with even a small fraction of deployed browsers.  Hence why
> this patch is, unfortunately, necessary.

What is _necessary_ is that Apple accept responsibility for their errors :-)

Why are we chasing after them cleaning up their messes?
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Rob Stradling
On 14/06/13 10:20, Ben Laurie wrote:

> On 14 June 2013 09:39, Rob Stradling <[hidden email]> wrote:
>> On 13/06/13 17:39, Ben Laurie wrote:
>>>
>>> ...and don't intend to fix their broken ECDSA support in Safari.
>>
>> Ben, you've got your wires a bit crossed there.
>>
>> The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to
>> 10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week).
>>
>>> It is therefore suggested that I pull this patch:
>>>
>>> https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d
>>>
>>> What do people think?
>>
>> The unfortunate reality is that significant numbers of OSX 10.8.x users
>> won't upgrade to 10.8.4 anytime soon, even though the upgrade is free and
>> easy to install.
>
> Precisely my point - so how were my wires crossed?

Ah, so you're criticizing Apple for not being willing to force all OSX
10.8.x users to update to 10.8.4.

If OSX 10.8.x has a mechanism that allows Apple to force updates to be
installed, then I agree.  But my suspicion is that it doesn't, and if
so, Apple's willingness isn't the key issue here.

>> No server administrator will want to deploy ECDHE-ECDSA if it means breaking
>> compatibility with even a small fraction of deployed browsers.  Hence why
>> this patch is, unfortunately, necessary.
>
> What is _necessary_ is that Apple accept responsibility for their errors :-)

Agreed.

Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix.

> Why are we chasing after them cleaning up their messes?

Because we want ECDHE-ECDSA to be deployable.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Ben Laurie-2
On 14 June 2013 12:25, Rob Stradling <[hidden email]> wrote:

> On 14/06/13 10:20, Ben Laurie wrote:
>>
>> On 14 June 2013 09:39, Rob Stradling <[hidden email]> wrote:
>>>
>>> On 13/06/13 17:39, Ben Laurie wrote:
>>>>
>>>>
>>>> ...and don't intend to fix their broken ECDSA support in Safari.
>>>
>>>
>>> Ben, you've got your wires a bit crossed there.
>>>
>>> The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to
>>> 10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week).
>>>
>>>> It is therefore suggested that I pull this patch:
>>>>
>>>>
>>>> https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d
>>>>
>>>> What do people think?
>>>
>>>
>>> The unfortunate reality is that significant numbers of OSX 10.8.x users
>>> won't upgrade to 10.8.4 anytime soon, even though the upgrade is free and
>>> easy to install.
>>
>>
>> Precisely my point - so how were my wires crossed?
>
>
> Ah, so you're criticizing Apple for not being willing to force all OSX
> 10.8.x users to update to 10.8.4.

No.

> If OSX 10.8.x has a mechanism that allows Apple to force updates to be
> installed, then I agree.  But my suspicion is that it doesn't, and if so,
> Apple's willingness isn't the key issue here.

It has a mechanism to nag you endlessly until you do install updates.
Which makes me wonder why you think people won't install the OS
update?

>
>
>>> No server administrator will want to deploy ECDHE-ECDSA if it means
>>> breaking
>>> compatibility with even a small fraction of deployed browsers.  Hence why
>>> this patch is, unfortunately, necessary.
>>
>>
>> What is _necessary_ is that Apple accept responsibility for their errors
>> :-)
>
>
> Agreed.
>
> Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix.
>
>
>> Why are we chasing after them cleaning up their messes?
>
>
> Because we want ECDHE-ECDSA to be deployable.
>
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

The Doctor
In reply to this post by Ben Laurie-2
On Thu, Jun 13, 2013 at 05:39:36PM +0100, Ben Laurie wrote:
> ...and don't intend to fix their broken ECDSA support in Safari.
>
> It is therefore suggested that I pull this patch:
>
> https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d
>
> What do people think?

No keep the patch.

> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       [hidden email]
> Automated List Manager                           [hidden email]

--
Member - Liberal International This is [hidden email] Ici [hidden email]
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising!
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
The false churches will conform themselves to this world's demands, seeing as they do not fear and thus do not obey God. - anon
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Rob Stradling
In reply to this post by Ben Laurie-2
On 14/06/13 12:31, Ben Laurie wrote:
> On 14 June 2013 12:25, Rob Stradling <[hidden email]> wrote:
<snip>

>> Ah, so you're criticizing Apple for not being willing to force all OSX
>> 10.8.x users to update to 10.8.4.
>
> No.
>
>> If OSX 10.8.x has a mechanism that allows Apple to force updates to be
>> installed, then I agree.  But my suspicion is that it doesn't, and if so,
>> Apple's willingness isn't the key issue here.
>
> It has a mechanism to nag you endlessly until you do install updates.
> Which makes me wonder why you think people won't install the OS
> update?

Safari's User-Agent string reveals the OSX version that it is running
on.  A few weeks ago I analyzed some webserver logs to get an idea of
historical OSX update rates.  Based on that analysis, I forecast that
the majority of OSX 10.8.x users will install the 10.8.4 update, but
that a significant minority won't.

>>>> No server administrator will want to deploy ECDHE-ECDSA if it means
>>>> breaking
>>>> compatibility with even a small fraction of deployed browsers.  Hence why
>>>> this patch is, unfortunately, necessary.
>>>
>>>
>>> What is _necessary_ is that Apple accept responsibility for their errors
>>> :-)
>>
>>
>> Agreed.
>>
>> Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix.
>>
>>
>>> Why are we chasing after them cleaning up their messes?
>>
>>
>> Because we want ECDHE-ECDSA to be deployable.
>>
>>
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
>>
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed.  If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Ben Laurie-2
On 14 June 2013 13:57, Rob Stradling <[hidden email]> wrote:

> On 14/06/13 12:31, Ben Laurie wrote:
>>
>> On 14 June 2013 12:25, Rob Stradling <[hidden email]> wrote:
>
> <snip>
>
>>> Ah, so you're criticizing Apple for not being willing to force all OSX
>>> 10.8.x users to update to 10.8.4.
>>
>>
>> No.
>>
>>> If OSX 10.8.x has a mechanism that allows Apple to force updates to be
>>> installed, then I agree.  But my suspicion is that it doesn't, and if so,
>>> Apple's willingness isn't the key issue here.
>>
>>
>> It has a mechanism to nag you endlessly until you do install updates.
>> Which makes me wonder why you think people won't install the OS
>> update?
>
>
> Safari's User-Agent string reveals the OSX version that it is running on.  A
> few weeks ago I analyzed some webserver logs to get an idea of historical
> OSX update rates.  Based on that analysis, I forecast that the majority of
> OSX 10.8.x users will install the 10.8.4 update, but that a significant
> minority won't.

I guess then we need to know why? And would they upgrade Safari alone?

>
>
>>>>> No server administrator will want to deploy ECDHE-ECDSA if it means
>>>>> breaking
>>>>> compatibility with even a small fraction of deployed browsers.  Hence
>>>>> why
>>>>> this patch is, unfortunately, necessary.
>>>>
>>>>
>>>>
>>>> What is _necessary_ is that Apple accept responsibility for their errors
>>>> :-)
>>>
>>>
>>>
>>> Agreed.
>>>
>>> Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA
>>> bugfix.
>>>
>>>
>>>> Why are we chasing after them cleaning up their messes?
>>>
>>>
>>>
>>> Because we want ECDHE-ECDSA to be deployable.
>>>
>>>
>>> --
>>> Rob Stradling
>>> Senior Research & Development Scientist
>>> COMODO - Creating Trust Online
>>>
>>
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
> Office Tel: +44.(0)1274.730505
> Office Fax: +44.(0)1274.730909
> www.comodo.com
>
> COMODO CA Limited, Registered in England No. 04058690
> Registered Office:
>   3rd Floor, 26 Office Village, Exchange Quay,
>   Trafford Road, Salford, Manchester M5 3EQ
>
> This e-mail and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender by
> replying to the e-mail containing this attachment. Replies to this email may
> be monitored by COMODO for operational or business reasons. Whilst every
> endeavour is taken to ensure that e-mails are free from viruses, no
> liability can be accepted and the recipient is requested to use their own
> virus checking software.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Rob Stradling
On 14/06/13 13:58, Ben Laurie wrote:
> On 14 June 2013 13:57, Rob Stradling <[hidden email]> wrote:
<snip>
>> Safari's User-Agent string reveals the OSX version that it is running on.  A
>> few weeks ago I analyzed some webserver logs to get an idea of historical
>> OSX update rates.  Based on that analysis, I forecast that the majority of
>> OSX 10.8.x users will install the 10.8.4 update, but that a significant
>> minority won't.
>
> I guess then we need to know why? And would they upgrade Safari alone?

Apparently the ECDHE-ECDSA bug is in SecureTransport, which is an
integral component of OSX.

>>>>>> No server administrator will want to deploy ECDHE-ECDSA if it means
>>>>>> breaking
>>>>>> compatibility with even a small fraction of deployed browsers.  Hence
>>>>>> why
>>>>>> this patch is, unfortunately, necessary.
>>>>>
>>>>>
>>>>>
>>>>> What is _necessary_ is that Apple accept responsibility for their errors
>>>>> :-)
>>>>
>>>>
>>>>
>>>> Agreed.
>>>>
>>>> Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA
>>>> bugfix.
>>>>
>>>>
>>>>> Why are we chasing after them cleaning up their messes?
>>>>
>>>>
>>>>
>>>> Because we want ECDHE-ECDSA to be deployable.
>>>>
>>>>
>>>> --
>>>> Rob Stradling
>>>> Senior Research & Development Scientist
>>>> COMODO - Creating Trust Online
>>>>
>>>
>>
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
>> Office Tel: +44.(0)1274.730505
>> Office Fax: +44.(0)1274.730909
>> www.comodo.com
>>
>> COMODO CA Limited, Registered in England No. 04058690
>> Registered Office:
>>    3rd Floor, 26 Office Village, Exchange Quay,
>>    Trafford Road, Salford, Manchester M5 3EQ
>>
>> This e-mail and any files transmitted with it are confidential and intended
>> solely for the use of the individual or entity to whom they are addressed.
>> If you have received this email in error please notify the sender by
>> replying to the e-mail containing this attachment. Replies to this email may
>> be monitored by COMODO for operational or business reasons. Whilst every
>> endeavour is taken to ensure that e-mails are free from viruses, no
>> liability can be accepted and the recipient is requested to use their own
>> virus checking software.
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed.  If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Ben Laurie-2
In reply to this post by The Doctor
On 14 June 2013 13:54, The Doctor <[hidden email]> wrote:

> On Thu, Jun 13, 2013 at 05:39:36PM +0100, Ben Laurie wrote:
>> ...and don't intend to fix their broken ECDSA support in Safari.
>>
>> It is therefore suggested that I pull this patch:
>>
>> https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d
>>
>> What do people think?
>
> No keep the patch.

I am not sure what you mean by this.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Ben Laurie-2
In reply to this post by Rob Stradling
On 14 June 2013 14:08, Rob Stradling <[hidden email]> wrote:

> On 14/06/13 13:58, Ben Laurie wrote:
>>
>> On 14 June 2013 13:57, Rob Stradling <[hidden email]> wrote:
>
> <snip>
>
>>> Safari's User-Agent string reveals the OSX version that it is running on.
>>> A
>>> few weeks ago I analyzed some webserver logs to get an idea of historical
>>> OSX update rates.  Based on that analysis, I forecast that the majority
>>> of
>>> OSX 10.8.x users will install the 10.8.4 update, but that a significant
>>> minority won't.
>>
>>
>> I guess then we need to know why? And would they upgrade Safari alone?
>
>
> Apparently the ECDHE-ECDSA bug is in SecureTransport, which is an integral
> component of OSX.

https://developer.apple.com/library/mac/#documentation/security/Reference/secureTransportRef/Reference/reference.html
seems to suggest it is a library.

>
>
>>>>>>> No server administrator will want to deploy ECDHE-ECDSA if it means
>>>>>>> breaking
>>>>>>> compatibility with even a small fraction of deployed browsers.  Hence
>>>>>>> why
>>>>>>> this patch is, unfortunately, necessary.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> What is _necessary_ is that Apple accept responsibility for their
>>>>>> errors
>>>>>> :-)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Agreed.
>>>>>
>>>>> Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA
>>>>> bugfix.
>>>>>
>>>>>
>>>>>> Why are we chasing after them cleaning up their messes?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Because we want ECDHE-ECDSA to be deployable.
>>>>>
>>>>>
>>>>> --
>>>>> Rob Stradling
>>>>> Senior Research & Development Scientist
>>>>> COMODO - Creating Trust Online
>>>>>
>>>>
>>>
>>> --
>>> Rob Stradling
>>> Senior Research & Development Scientist
>>> COMODO - Creating Trust Online
>>> Office Tel: +44.(0)1274.730505
>>> Office Fax: +44.(0)1274.730909
>>> www.comodo.com
>>>
>>> COMODO CA Limited, Registered in England No. 04058690
>>> Registered Office:
>>>    3rd Floor, 26 Office Village, Exchange Quay,
>>>    Trafford Road, Salford, Manchester M5 3EQ
>>>
>>> This e-mail and any files transmitted with it are confidential and
>>> intended
>>> solely for the use of the individual or entity to whom they are
>>> addressed.
>>> If you have received this email in error please notify the sender by
>>> replying to the e-mail containing this attachment. Replies to this email
>>> may
>>> be monitored by COMODO for operational or business reasons. Whilst every
>>> endeavour is taken to ensure that e-mails are free from viruses, no
>>> liability can be accepted and the recipient is requested to use their own
>>> virus checking software.
>>
>>
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
> Office Tel: +44.(0)1274.730505
> Office Fax: +44.(0)1274.730909
> www.comodo.com
>
> COMODO CA Limited, Registered in England No. 04058690
> Registered Office:
>   3rd Floor, 26 Office Village, Exchange Quay,
>   Trafford Road, Salford, Manchester M5 3EQ
>
> This e-mail and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender by
> replying to the e-mail containing this attachment. Replies to this email may
> be monitored by COMODO for operational or business reasons. Whilst every
> endeavour is taken to ensure that e-mails are free from viruses, no
> liability can be accepted and the recipient is requested to use their own
> virus checking software.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Dr. Stephen Henson
In reply to this post by Bodo Moeller
On Fri, Jun 14, 2013, Bodo Moeller wrote:

> On Thu, Jun 13, 2013 at 6:39 PM, Ben Laurie <[hidden email]> wrote:
>
> It is therefore suggested that I pull this patch:
> >
> >
> > https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d
>
>
> The behavior change applies only if new option
> SSL_OP_SAFARI_ECDHE_ECDSA_BUG is used (part of SSL_OP_ALL), as is standard
> for interoperability bug workarounds, so while it is very unfortunate that
> we'd need to do this, I'm in favor of accepting this patch.

Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared
libraries are updated to include the patch existing applications wont set it:
they'd all need to be recompiled.

Possibly alternative is to reuse one of the existing *ancient* flags. Does
anyone really care about compatibility with a bug in SSLeay 0.80 for example?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Rob Stradling
In reply to this post by The Doctor
On 14/06/13 13:54, The Doctor wrote:

> On Thu, Jun 13, 2013 at 05:39:36PM +0100, Ben Laurie wrote:
>> ...and don't intend to fix their broken ECDSA support in Safari.
>>
>> It is therefore suggested that I pull this patch:
>>
>> https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d
>>
>> What do people think?
>
> No keep the patch.

I think you misunderstood what Ben meant by "pull".

See "man git-pull"

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Rob Stradling
In reply to this post by Dr. Stephen Henson
On 14/06/13 14:31, Dr. Stephen Henson wrote:
<snip>
>> The behavior change applies only if new option
>> SSL_OP_SAFARI_ECDHE_ECDSA_BUG is used (part of SSL_OP_ALL), as is standard
>> for interoperability bug workarounds, so while it is very unfortunate that
>> we'd need to do this, I'm in favor of accepting this patch.
>
> Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared
> libraries are updated to include the patch existing applications wont set it:
> they'd all need to be recompiled.

Yep, but 0x400 is the only currently unallocated bit.

> Possibly alternative is to reuse one of the existing *ancient* flags. Does
> anyone really care about compatibility with a bug in SSLeay 0.80 for example?

I'd wondered about that.  If you're happy to reallocate one of the
ancient flags, please do!

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Florian Weimer-2
In reply to this post by Dr. Stephen Henson
On 06/14/2013 03:31 PM, Dr. Stephen Henson wrote:
> Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared
> libraries are updated to include the patch existing applications wont set it:
> they'd all need to be recompiled.

That's a valid point.

> Possibly alternative is to reuse one of the existing *ancient* flags. Does
> anyone really care about compatibility with a bug in SSLeay 0.80 for example?

Wouldn't it be better to reverse the meaning of the flag and not set it
in SSL_OP_ALL?

--
Florian Weimer / Red Hat Product Security Team
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Bodo Moeller

Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared
libraries are updated to include the patch existing applications wont set it:
they'd all need to be recompiled.

That's a valid point.

This is true, unfortunately.

 


Possibly alternative is to reuse one of the existing *ancient* flags. Does
anyone really care about compatibility with a bug in SSLeay 0.80 for example?

Wouldn't it be better to reverse the meaning of the flag and not set it in SSL_OP_ALL?

Hm, without any SSL_OP_... settings, the expectation generally is that we kind of sort of follow the specs and don't do any weird stuff like this for interoperability's sake. If we switch semantics around for certain options, the resulting inconsistencies would make all that even more confusing.

In theory we could create an explicit "SSL_OP_ALL"-equivalent bit (SSL_OP_ALL_ALL?) that enables all current SSL_OP_ALL features and doesn't allow further masking, but that seems hard to deploy given that some current applications may expressly want SSL_OP_ALL *without* certain flags. Of course the legacy flag an application disables could be the one that we're about to recycle ... SSL_OP_ALL ideally would always have included some unused bits for future use, but that again is hard to pull off retroactively -- it's probably a good idea for a later release (with an incompatible .so version so that we can safely change SSL_OP_ALL).

If we can find an appropriate ancient flag that no one should care about (which sounds plausible), recycling that one sounds like a good idea. If we can't, using reverted semantics might be the best option we have.

Bodo

Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Ben Laurie-2
On 14 June 2013 16:10, Bodo Moeller <[hidden email]> wrote:

>
>>> Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared
>>> libraries are updated to include the patch existing applications wont set
>>> it:
>>> they'd all need to be recompiled.
>>
>>
>> That's a valid point.
>
>
> This is true, unfortunately.
>
>
>>
>>
>>
>>> Possibly alternative is to reuse one of the existing *ancient* flags.
>>> Does
>>> anyone really care about compatibility with a bug in SSLeay 0.80 for
>>> example?
>>
>>
>> Wouldn't it be better to reverse the meaning of the flag and not set it in
>> SSL_OP_ALL?
>
>
> Hm, without any SSL_OP_... settings, the expectation generally is that we
> kind of sort of follow the specs and don't do any weird stuff like this for
> interoperability's sake. If we switch semantics around for certain options,
> the resulting inconsistencies would make all that even more confusing.
>
> In theory we could create an explicit "SSL_OP_ALL"-equivalent bit
> (SSL_OP_ALL_ALL?) that enables all current SSL_OP_ALL features and doesn't
> allow further masking, but that seems hard to deploy given that some current
> applications may expressly want SSL_OP_ALL *without* certain flags. Of
> course the legacy flag an application disables could be the one that we're
> about to recycle ... SSL_OP_ALL ideally would always have included some
> unused bits for future use, but that again is hard to pull off retroactively
> -- it's probably a good idea for a later release (with an incompatible .so
> version so that we can safely change SSL_OP_ALL).
>
> If we can find an appropriate ancient flag that no one should care about
> (which sounds plausible), recycling that one sounds like a good idea. If we
> can't, using reverted semantics might be the best option we have.

We could just add an SSL_OP_ALL_FROM_FUTURE flag that did this, and
leave SSL_OP_ALL as it is?

If you really want to get funky, you could make it so any bit set with
SSL_OP_ALL_FROM_FUTURE disables the corresponding feature. This would
mean you could never re-use bits, tho...
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Apple are, apparently, dicks...

Salz, Rich
In reply to this post by Bodo Moeller

Ø  Hm, without any SSL_OP_... settings, the expectation generally is that we kind of sort of follow the specs

Ø   and don't do any weird stuff like this for interoperability's sake. If we switch semantics around for certain

Ø   options, the resulting inconsistencies would make all that even more confusing.

 

+1

 

-- 

Principal Security Engineer

Akamai Technology

Cambridge, MA

 

Reply | Threaded
Open this post in threaded view
|

Re: Apple are, apparently, dicks...

Rob Stradling
In reply to this post by Florian Weimer-2
On 14/06/13 15:25, Florian Weimer wrote:

> On 06/14/2013 03:31 PM, Dr. Stephen Henson wrote:
>> Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared
>> libraries are updated to include the patch existing applications wont
>> set it:
>> they'd all need to be recompiled.
>
> That's a valid point.
>
>> Possibly alternative is to reuse one of the existing *ancient* flags.
>> Does
>> anyone really care about compatibility with a bug in SSLeay 0.80 for
>> example?
>
> Wouldn't it be better to reverse the meaning of the flag and not set it
> in SSL_OP_ALL?

Just to complicate matters further, the 0x400 bit used to be set in
SSL_OP_ALL, and has previously been used for at least 2 other purposes!

http://cvs.openssl.org/chngview?cn=18974
http://cvs.openssl.org/chngview?cn=22501

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
12