Re: Apple are, apparently, dicks...

2013-06-18 Thread Rob Stradling

On 14/06/13 14:16, Ben Laurie wrote:

On 14 June 2013 14:08, Rob Stradling rob.stradl...@comodo.com wrote:

snip

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.


Ben, what else needs to happen before this patch is either committed or 
rejected?


Thanks.

--
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-15 Thread Rob Stradling

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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Apple are, apparently, dicks...

2013-06-14 Thread Ben Laurie
...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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Bodo Moeller
On Thu, Jun 13, 2013 at 6:39 PM, Ben Laurie b...@links.org 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.


Re: Apple are, apparently, dicks...

2013-06-14 Thread Rob Stradling

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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Ben Laurie
On 14 June 2013 09:39, Rob Stradling rob.stradl...@comodo.com 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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Rob Stradling

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

On 14 June 2013 09:39, Rob Stradling rob.stradl...@comodo.com 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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Ben Laurie
On 14 June 2013 12:25, Rob Stradling rob.stradl...@comodo.com wrote:
 On 14/06/13 10:20, Ben Laurie wrote:

 On 14 June 2013 09:39, Rob Stradling rob.stradl...@comodo.com 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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Rob Stradling

On 14/06/13 12:31, Ben Laurie wrote:

On 14 June 2013 12:25, Rob Stradling rob.stradl...@comodo.com 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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Ben Laurie
On 14 June 2013 13:57, Rob Stradling rob.stradl...@comodo.com wrote:
 On 14/06/13 12:31, Ben Laurie wrote:

 On 14 June 2013 12:25, Rob Stradling rob.stradl...@comodo.com 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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread The Doctor
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   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org

-- 
Member - Liberal International  This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca
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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Dr. Stephen Henson
On Fri, Jun 14, 2013, Bodo Moeller wrote:

 On Thu, Jun 13, 2013 at 6:39 PM, Ben Laurie b...@links.org 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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Florian Weimer

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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread 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


RE: Apple are, apparently, dicks...

2013-06-14 Thread Salz, Rich
Ø  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



Re: Apple are, apparently, dicks...

2013-06-14 Thread Rob Stradling

On 14/06/13 13:58, Ben Laurie wrote:

On 14 June 2013 13:57, Rob Stradling rob.stradl...@comodo.com 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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Ben Laurie
On 14 June 2013 13:54, The Doctor doc...@doctor.nl2k.ab.ca 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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Ben Laurie
On 14 June 2013 14:08, Rob Stradling rob.stradl...@comodo.com wrote:
 On 14/06/13 13:58, Ben Laurie wrote:

 On 14 June 2013 13:57, Rob Stradling rob.stradl...@comodo.com 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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Rob Stradling

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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Rob Stradling

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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: Apple are, apparently, dicks...

2013-06-14 Thread Ben Laurie
On 14 June 2013 16:10, Bodo Moeller bmoel...@acm.org 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   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org