Apple are, apparently, dicks...
...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: [Patch] ALPN Implementation for OpenSSL
Hi, Attached the Patch for the OpenSSL with ALPN implementation. -Original Message- From: Parashuram Narasimhan (MS OPEN TECH) Sent: Thursday, June 13, 2013 5:57 AM To: 'openssl-dev@openssl.org' Subject: [Patch] ALPN Implementation for OpenSSL Hi, I work for Microsoft Open Technologies, a wholly owned subsidiary of Microsoft Corp. My team is currently working on the standardization process for HTTP/2.0: as I believe many of you may have heard, the latest working draft @ IETF requires using ALPN as the mechanism for secure negotiation, and we have been working on a patch to OpenSSL to allow for early testing and interoperability. More background is available at http://tools.ietf.org/html/draft-ietf-httpbis-http2-03#section-2.3, but for your convenience here goes the relevant snippet: 2.3. Starting HTTP/2.0 for https: URIs A client that makes a request to an https: URI without prior knowledge about support for HTTP/2.0 uses TLS [RFC5246] with the application layer protocol negotiation extension [TLSALPN]. Once TLS negotiation is complete, both the client and the server send a connection header (Section 3.2). We will be submitting a patch request to openssl-b...@openssl.org as advised by https://github.com/openssl/openssl/blob/master/README#L178, and we will be following discussions the mailing lists. Please feel free to give us your feedback and, in case you would be interested in a formal contribution, advice on the steps we need to take. Thanks Parashuram Microsoft Open Technologies Inc openssl-alpn.patch Description: openssl-alpn.patch
[openssl.org #3073] [Patch] ALPN Implementation for OpenSSL
Hi, I work for Microsoft Open Technologies, a wholly owned subsidiary of Microsoft Corp. My team is currently working on a patch to OpenSSL to allow for early testing and interoperability. More background is available at http://tools.ietf.org/html/draft-ietf-httpbis-http2-03#section-2.3. Attached is the patch for ALPN Implementation for OpenSSL. Had already sent an email to discuss this on the dev mailing list. Thanks Parashuram Microsoft Open Technologies Inc openssl-alpn.patch Description: Binary data
Re: Apple are, apparently, dicks...
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.
openssl 1.0.1e Signature verification problems
Hi, I am using openssl 1.0.1e to create a CA and generate certificates. I am facing an issue while generating the device certificates. After creating the ca certificate using below command # openssl req -x509 -new -newkey rsa:1024 -keyout private/cakey.pem -days 3650 -out cacert.pem when we try to display the contents the signature algorithm is shown as itu-t instead of sha1WithRSAEncryption #openssl x509 -in cacert.pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 96:15:a3:26:59:5f:46:1d Signature Algorithm: itu-t Issuer: C=US, ST=LA, L=CA, O=Internet Widgits Pty Ltd, OU=crop, CN=GWCA/subjectAltName=DNS:www.evmweb.com Validity Not Before: Jun 14 12:08:24 2013 GMT Not After : Jun 12 12:08:24 2023 GMT Subject: C=US, ST=LA, L=CA, O=Internet Widgits Pty Ltd, OU=crop, CN=GWCA/subjectAltName=DNS:www.evmweb.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:c1:73:b4:37:ed:d1:1f:fb:bf:63:b0:8a:91:82: a8:f0:83:4d:5a:32:9b:5d:bc:23:06:3f:d4:fc:77: cf:83:0f:ab:ac:35:46:98:02:e5:a3:cc:89:30:34: 05:3f:80:ad:33:ae:dc:7e:57:60:e2:02:d6:c9:6b: b8:76:f7:56:e6:0f:44:c4:71:3a:cf:e1:59:8e:b4: 4b:6a:4a:de:59:25:4d:58:74:f0:82:27:0e:35:34: 72:86:9e:7c:a3:c8:cb:ba:55:8f:d5:8f:2f:cd:a0: 1f:e8:89:7c:74:0e:92:a0:de:72:d1:33:96:41:42: bc:44:d0:20:29:cf:7b:2c:a7 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: C3:92:EF:07:DE:25:21:48:F4:51:2B:38:C8:DE:56:D0:14:8E:CD:0A X509v3 Authority Key Identifier: keyid:C3:92:EF:07:DE:25:21:48:F4:51:2B:38:C8:DE:56:D0:14:8E:CD:0A DirName:/C=US/ST=LA/L=CA/O=Internet Widgits Pty Ltd/OU=crop/CN=GWCA/subjectAltName=DNS:www.evmweb.com serial:96:15:A3:26:59:5F:46:1D X509v3 Basic Constraints: CA:TRUE Signature Algorithm: itu-t a0:0e:98:f2:46:4e:0e:b5:d9:ff:f2:e5:57:24:d2:81:66:2e: 4a:2b:3c:f6:02:48:4a:37:d8:4d:d9:70:b2:01:43:f4:71:fc: 92:27:a9:d0:0b:9f:1a:c2:b7:54:3e:67:f3:0e:71:76:15:c0: c2:0f:b7:3a:13:de:93:4e:42:27:f9:5a:bb:d9:9e:e8:19:55: 88:7e:4b:d6:3a:b7:2d:46:3f:79:13:f4:c7:da:59:37:95:ef: 15:47:91:2a:32:4d:0d:ba:6f:a6:13:c3:57:87:ac:70:53:98: 41:11:8d:ee:af:3d:46:d1:48:bb:f7:de:5d:00:a4:f1:59:c2: 0c:56 when we try to sign a device certificate I am getting below error. # openssl ca -policy policy_anything -out certs/evm1gwcert.pem -infiles evm1gwCSR.pem Using configuration from /etc/ssl/openssl.cnf Enter pass phrase for /etc/ssl/private/cakey.pem: Check that the request matches the signature Signature verification problems.. This was not observed in previous versions. When I tried to change default_md to sha1 in openssl.cnf it doesn't had any effect. Please suggest if we need to configure anything in particular in openssl.cnf or is it a bug. Thanks, Anand __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
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...
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...
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...
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...
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...
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...
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...
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...
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...
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...
Ø 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...
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...
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...
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...
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...
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...
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
Re: [PATCH] s_client, proxy support
On Wed, 07 Dec 2011 m.tr...@gmx.de wrote: Hi, I have added support for the 'HTTP CONNECT' command to s_client. Maybe it's useful for someone else. Regards Michael Hello Michael. I was doing some SSL diagnostics through a series of proxy tunnels and was about to hack HTTP CONNECT support for s_client when I came across your patch. Thank you for sharing that! I introduced a few slight changes: a) made CONNECT string RFC2817 compliant, b) shutdown on non-success of CONNECT, and c) check to prevent NULL deref. of connect_str. Similarly, I share for those who might find this useful. Cheers. --mancha openssl-0.9.8y-s_client-proxy.patch Description: Binary data openssl-1.0.1e-s_client-proxy.patch Description: Binary data
RE: [openssl.org #3072] Strange behaviour when talking to microsoft exchange
From: owner-openssl-...@openssl.org On Behalf Of Kurt Roeckx Sent: Thursday, 13 June, 2013 03:13 When talking to an exchange server I get some weird behaviour when using the 1.0.1e version. I get a TLS 1.0 connection, but the problems go away when using -no_tls1_2 If you got an agreed protocol, then it isn't the 1.2-ClientHello got bigger problem. An example connection is with: openssl s_client -connect mail.megacontractinginc.com:25 -starttls smtp -crlf -quiet 1) 250 OK HELP 214-This server supports the following commands: 214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH TURN ETRN BDAT VRFY 140527452698280:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: That's really weird, unless the server isn't actually doing starttls correctly (in spite of offering it). If you can get this to recur, try with -state -debug to see exactly where/what is happening. 2) 250 OK MAIL FROM: k...@roeckx.be 250 2.1.0 k...@roeckx.beSender OK HELP The connection hangs at this point, any command will hang it. I don't see why the -no_tls1_2 should have any effect on it. One thing I've noticed is that -no_tls1_2 has as effect that the cipher gets changed from DES-CBC3-SHA to RC4-MD5. I don't see why that would result; -no_tls1_2 excludes the 1.2-only suites (SHA2 and GCM) from ClientHello, but it still has akRSA-DES3CBC preferred over akRSA-RC4 (and akRSA-RC4-SHA over akRSA-RC4-MD5!). Are you sure there's nothing else different? Can you get a wire trace, or -msg or -debug? But given it happened, it means that the empty_fragment (0/N) CBC patch now used against BEAST becomes inapplicable. If this server/stack could be one of the ones rumored to not support 0/N (even though MS did implement 1/N in Jan. 2012 for BEAST, the infamous MS12-006) try s_client with -bugs . -debug might also be worth trying here if (most? of) your inputs and outputs are long enough to be distinguished at granularity 8 (DES block size). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Bug in Documentation
Hi, adding multiple CRL distribution points I stumbled upon a problem that could be solved by finding a seven years old bug report: http://www.mail-archive.com/openssl-dev@openssl.org/msg21907.html The Bug is still there: http://www.openssl.org/docs/apps/x509v3_config.html at the bottom of the page. Instead of: subjectAltName = @subject_alt_section [subject_alt_section] subjectAltName = URI:ldap://somehost.com/CN=foo,CN=bar it should be: subjectAltName = @subject_alt_section [subject_alt_section] URI = ldap://somehost.com/CN=foo,CN=bar Thanks! KR, Oliver smime.p7s Description: S/MIME cryptographic signature
