[openssl.org #3321] NULL pointer dereference with SSL_MODE_RELEASE_BUFFERS flag
This patch looks like a bit of a kludge to me. Release a buffer only to then immediately set it up again. Compare with this commit on master: https://github.com/openssl/openssl/commit/3ef477c69f2fd39549123d7b0b869029b46cf989 I think a backport of this might be more appropriate. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Concurrent calls to DH_generate_key are serialized?
Examining performance bottlenecks on a busy server, we discovered that connections are being forced to serialize due to calls to DH_generate_key. I looked through the source, and if I understand it correctly, the code locks a common DH mutex when it uses Montgomery Multiplication, and due to the way it sets a flag, it always does. But I have not yet found any reason why this requires critical section protection. I do not see any global variables that are being manipulated by the call, nor any resource contention. Is it possible that the mutex lock is a holdover from earlier code? Could this locking behavior be removed? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3321] NULL pointer dereference with SSL_MODE_RELEASE_BUFFERS flag
On Fri, May 02, 2014 at 06:53:06PM +, mancha wrote: > Kurt Roeckx via RT openssl.org> writes: > > > > There is a potentional patch for this in libresll, you can see it > > at: > > http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/commit > > /lib/libssl?id=e76e308f1fab2253ab5b4ef52a1865c5ffecdf21 > > > > Kurt > > Hello. > > This issue has been assigned CVE-2014-0198. Any news on an > OpenSSL fix? I've just created github pull request #94 for that. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
> Discussions on what the "One True Ciphersuite List" should be tend to result > in multiple correct answers. :) > Placing a set of recommendations on the wiki (wiki.openssl.org) along with > their rationale would be a good step to providing a selection of choices for > OpenSSL users. Yes, and perhaps using the profile stuff to embed some of them in the distribution. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On 2/05/2014 11:49 PM, Salz, Rich wrote: >> Steve, have you considered trimming the DEFAULT cipher list? >> It's currently... >> #define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2" >> I wonder how many of these ciphers are actually ever negotiated in >> real-world use. > I'm forwarding a bit of internal discussion; hope it's useful. This is from > one of our chief info-sec people: A set of recommendations from the Mozilla team along with a write up of how to configure cipher suite selection in a range of servers is at: https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite The short form of their recommendation is: 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256: DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256: ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384: ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256: DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA: DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA: AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK' Their rationale is described at https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritization_logic and the cipher suite you select entirely depends on what your view point is on a range of issues. Discussions on what the "One True Ciphersuite List" should be tend to result in multiple correct answers. Placing a set of recommendations on the wiki (wiki.openssl.org) along with their rationale would be a good step to providing a selection of choices for OpenSSL users. Tim. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3321] NULL pointer dereference with SSL_MODE_RELEASE_BUFFERS flag
Kurt Roeckx via RT openssl.org> writes: > > There is a potentional patch for this in libresll, you can see it > at: > http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-src/commit > /lib/libssl?id=e76e308f1fab2253ab5b4ef52a1865c5ffecdf21 > > Kurt Hello. This issue has been assigned CVE-2014-0198. Any news on an OpenSSL fix? Thanks. --mancha __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Fri, May 02, 2014 at 10:50:28AM -0400, Salz, Rich wrote: > > > How many of those sites are served by CDN's, for example? > > > I don't know, if you have a semi-robust way to detect that I'm willing to > > implement it. > > Short of giving out customer lists :) I don't. I suppose you could do a DNS > lookup and see if you got a CNAME to something else. I understand the script is available. Maybe you could run it yourself against your customer list? Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
Hey, >> How many of those sites are served by CDN's, for example? > > I don't know, if you have a semi-robust way to detect that I'm willing to > implement it. > > Though, the scan was more of a ballpark estimate than a truly representative > result. Whois the IP? That should work for majority of the CDN. For Amazon, you can distinguish S3 from CloudFront by looking for at the HTTP headers: - X-Amz-Cf-Id, - Via: ... .cloudfront.net (CloudFront), - X-Cache: ... from cloudfront. Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Fri, May 02, 2014 at 04:12:33PM +0200, Kurt Roeckx wrote: > As I understand things, RC4 needs to be before 3DES because some > exchange servers have broken 3DES and don't support anything else. No, that's a misreading of my posts. It suffices for RC4-SHA to be in the 64 ciphersuites in the client SSL HELLO. The servers in question will choose RC4-SHA if offered in the first 64 regardless of client preference. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Thu, May 01, 2014 at 12:35:52PM +0100, Rob Stradling wrote: > Steve, have you considered trimming the DEFAULT cipher list? This would be a *major* incompatibility. The master branch has security levels, which are a step in the right direction. It is perhaps safe to drop EXPORT, LOW and MD5, and not much else. > It's currently... > #define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2" > > I wonder how many of these ciphers are actually ever negotiated in > real-world use. There are a lot of "real-world" uses that we don't know about. The world is not just HTTPS. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
> > How many of those sites are served by CDN's, for example? > I don't know, if you have a semi-robust way to detect that I'm willing to > implement it. Short of giving out customer lists :) I don't. I suppose you could do a DNS lookup and see if you got a CNAME to something else. > Though, the scan was more of a ballpark estimate than a truly representative > result. Oh it's definitely interesting. My point is that the stats might be weighted by the fact that 1/3 of them are being served by a single entity, for example. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz :��I"Ϯ��r�m (Z+�7�zZ)���1���x ��hW^��^��%�� ��&jם.+-1�ځ��j:+v���h�
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
- Original Message - > From: "Rich Salz" > To: openssl-dev@openssl.org > Sent: Friday, May 2, 2014 4:28:44 PM > Subject: RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance > (padding extension) > > > After scanning Alexa top 1 million sites (as a semi-representative sample) > > the stats look like this: > > How many of those sites are served by CDN's, for example? I don't know, if you have a semi-robust way to detect that I'm willing to implement it. Though, the scan was more of a ballpark estimate than a truly representative result. -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
> After scanning Alexa top 1 million sites (as a semi-representative sample) > the stats look like this: How many of those sites are served by CDN's, for example? -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
- Original Message - > From: "John Foley" > To: openssl-dev@openssl.org > Sent: Friday, May 2, 2014 3:58:37 PM > Subject: Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance > (padding extension) > > How prevalent is RC4 today? While web browsers still advertise RC4 > cipher suites, how often do you see RC4 cipher suites advertised by the > client and no AES or 3DES suites advertised? Does Akamai have any data > on this? Maybe RC4 should now be disabled by default. After scanning Alexa top 1 million sites (as a semi-representative sample) the stats look like this: RC4 Supported 26829887.8859% RC4 Only 5418 1.7748% RC4 Preferred 59552 19.5073% RC4 preferred in TLS1.1+ 31737 10.396% > On 05/02/2014 09:49 AM, Salz, Rich wrote: > >> Steve, have you considered trimming the DEFAULT cipher list? > >> It's currently... > >> #define SSL_DEFAULT_CIPHER_LIST"ALL:!aNULL:!eNULL:!SSLv2" > >> I wonder how many of these ciphers are actually ever negotiated in > >> real-world use. > > I'm forwarding a bit of internal discussion; hope it's useful. This is > > from one of our chief info-sec people: > > My weak opinion is that cipher brokenness is most important (so put 3DES > > and RC4 last, and the AEAD modes ahead of the MAC-then-encrypt modes), RC4 is broken, 3DES is just weak (as weak as 2048 bit RSA), you shouldn't put RC4 before 3DES > > followed by hash strength, followed by PFS presence, followed by SHA and It could be argued that even MD5 is secure when used as PRF or HMAC. SHA-1 when used as a PRF or HMAC has a higher security margin than AES-128. See http://openssl.6102.n7.nabble.com/Insecure-DEFAULT-cipher-set-td48995.html for in depth discussion. > > AES bit length. I think that would give us: > > > > ECDHE-ECDSA-AES256-GCM-SHA384 > > ECDHE-ECDSA-AES256-GCM-SHA256 > > ECDHE-ECDSA-AES128-GCM-SHA256 > > ECDHE-RSA-AES256-GCM-SHA384 > > ECDHE-RSA-AES128-GCM-SHA256 > > AES256-GCM-SHA384 > > AES128-GCM-SHA256 > > ECDHE-ECDSA-AES256-SHA384 > > ECDHE-ECDSA-AES256-SHA256 > > ECDHE-ECDSA-AES128-SHA256 > > ECDHE-RSA-AES256-SHA384 > > ECDHE-RSA-AES128-SHA256 > > AES256-SHA256 > > AES128-SHA256 > > AES128-SHA > > RC4-SHA > > DES-CBC3-SHA > > > > -- > > Principal Security Engineer > > Akamai Technologies, Cambridge, MA > > IM: rs...@jabber.me; Twitter: RichSalz > > > > :��I"Ϯ��r�m(���Z+�7�zZ)���1���x��h���W^��^��%�� > > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org > -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Fri, May 02, 2014 at 09:58:37AM -0400, John Foley wrote: > How prevalent is RC4 today? Here is a recent link for web servers: https://lists.fedoraproject.org/pipermail/security/2014-April/001810.html Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Fri, May 02, 2014 at 09:49:47AM -0400, Salz, Rich wrote: > >Steve, have you considered trimming the DEFAULT cipher list? > >It's currently... > >#define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2" > > I wonder how many of these ciphers are actually ever negotiated in > > real-world use. > > I'm forwarding a bit of internal discussion; hope it's useful. This is from > one of our chief info-sec people: > My weak opinion is that cipher brokenness is most important (so put 3DES and > RC4 last, and the AEAD modes ahead of the MAC-then-encrypt modes), followed > by hash strength, followed by PFS presence, followed by SHA and AES bit > length. I think that would give us: As I understand things, RC4 needs to be before 3DES because some exchange servers have broken 3DES and don't support anything else. > ECDHE-ECDSA-AES256-GCM-SHA384 > ECDHE-ECDSA-AES256-GCM-SHA256 I don't this one exists and you meant the next one. > ECDHE-ECDSA-AES128-GCM-SHA256 > ECDHE-RSA-AES256-GCM-SHA384 > ECDHE-RSA-AES128-GCM-SHA256 > AES256-GCM-SHA384 > AES128-GCM-SHA256 > ECDHE-ECDSA-AES256-SHA384 > ECDHE-ECDSA-AES256-SHA256 > ECDHE-ECDSA-AES128-SHA256 > ECDHE-RSA-AES256-SHA384 > ECDHE-RSA-AES128-SHA256 > AES256-SHA256 > AES128-SHA256 > AES128-SHA > RC4-SHA > DES-CBC3-SHA I'm not really a fan of the ECDSA ciphers and would really put RSA in front of ECDSA, or remove them. You could optionally also remove all the AES256 versions. Since it's SMTP, you could also add anonymous ciphers. Anyway, a list of ciphers isn't that useful, the CIPHER_LIST to get the needed ones is probably more useful. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
The IETF TLS-WG is likely (my opinion) to soon put out an RFC that, basically deprecates RC4. We have customers with many embedded devices (old web TV's, almost every game console, etc), not just browsers. But for OpenSSL and in particular new code, dropping RC4 is the thing to do. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
How prevalent is RC4 today? While web browsers still advertise RC4 cipher suites, how often do you see RC4 cipher suites advertised by the client and no AES or 3DES suites advertised? Does Akamai have any data on this? Maybe RC4 should now be disabled by default. On 05/02/2014 09:49 AM, Salz, Rich wrote: >> Steve, have you considered trimming the DEFAULT cipher list? >> It's currently... >> #define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2" >> I wonder how many of these ciphers are actually ever negotiated in >> real-world use. > I'm forwarding a bit of internal discussion; hope it's useful. This is from > one of our chief info-sec people: > My weak opinion is that cipher brokenness is most important (so put 3DES and > RC4 last, and the AEAD modes ahead of the MAC-then-encrypt modes), followed > by hash strength, followed by PFS presence, followed by SHA and AES bit > length. I think that would give us: > > ECDHE-ECDSA-AES256-GCM-SHA384 > ECDHE-ECDSA-AES256-GCM-SHA256 > ECDHE-ECDSA-AES128-GCM-SHA256 > ECDHE-RSA-AES256-GCM-SHA384 > ECDHE-RSA-AES128-GCM-SHA256 > AES256-GCM-SHA384 > AES128-GCM-SHA256 > ECDHE-ECDSA-AES256-SHA384 > ECDHE-ECDSA-AES256-SHA256 > ECDHE-ECDSA-AES128-SHA256 > ECDHE-RSA-AES256-SHA384 > ECDHE-RSA-AES128-SHA256 > AES256-SHA256 > AES128-SHA256 > AES128-SHA > RC4-SHA > DES-CBC3-SHA > > -- > Principal Security Engineer > Akamai Technologies, Cambridge, MA > IM: rs...@jabber.me; Twitter: RichSalz > > :��I"Ϯ��r�m (���Z+�7�zZ)���1���x ��h���W^��^��%�� __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
>Steve, have you considered trimming the DEFAULT cipher list? >It's currently... >#define SSL_DEFAULT_CIPHER_LIST"ALL:!aNULL:!eNULL:!SSLv2" > I wonder how many of these ciphers are actually ever negotiated in real-world > use. I'm forwarding a bit of internal discussion; hope it's useful. This is from one of our chief info-sec people: My weak opinion is that cipher brokenness is most important (so put 3DES and RC4 last, and the AEAD modes ahead of the MAC-then-encrypt modes), followed by hash strength, followed by PFS presence, followed by SHA and AES bit length. I think that would give us: ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-GCM-SHA256 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA256 AES256-SHA256 AES128-SHA256 AES128-SHA RC4-SHA DES-CBC3-SHA -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz :��I"Ϯ��r�m (Z+�7�zZ)���1���x ��hW^��^��%�� ��&jם.+-1�ځ��j:+v���h�
Re: SRP implementation mishandles salts with leading zeroes
On Fri, May 02, 2014 at 12:21:51PM +0200, Mechiel Lukkien wrote: > On Fri, May 02, 2014 at 11:41:46AM +0200, Mechiel Lukkien wrote: > > thoughts? does conversion from uchar* to bignum, and back to uchar* > > indeed strip leading zeroes? > > > > i think the salt should always be passed around as just bytes. in SRP > > it is never used for calculations with bignums. > > after sending i realised that uchar* obviously won't work for data with > zero-bytes. It does work if you can add a size. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SRP implementation mishandles salts with leading zeroes
On Fri, May 02, 2014 at 11:41:46AM +0200, Mechiel Lukkien wrote: > thoughts? does conversion from uchar* to bignum, and back to uchar* > indeed strip leading zeroes? > > i think the salt should always be passed around as just bytes. in SRP > it is never used for calculations with bignums. after sending i realised that uchar* obviously won't work for data with zero-bytes. still, if i didn't miss anything, the salts are randomly generated bytes, so the zeroes can occur. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Minor CRLF issue in mine
When one creates a message with ( echo Content-Type: text/plain; name="$file" echo Content-Transfer-Encoding: base64 echo echo Hello World | base64 ) > msg.txt cat msg.txt | openssl smime -sign -signer foo.crt -inkey foo.key > msg.mime on ‚unix’ - ensuring that msg.txt is entirely \\n or LF terminated - then the resulting file is *mostly* LF terminated - except for the msg.txt - it gets CRLF substitutions. See below - lines that got changed marked with a -CRLF at the end - the rest is all LF terminated. Passing the -crlfeol flag does make them all CRLF as one would expect. So I guess that for consistency - if no -crlfeol flag is passed - openssl should not really add/subtitute the payload - and keep those as is (i.e. LF as in above example). Secondly, from rfc2046 I guess that making the crlfeol flag the default may be better practice; leaving a -lfeol flag to trigger legacy behaviour. Or am I missing something crucial ? Dw MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="52B94B8FA281627355210BB13CFD00D1" This is an S/MIME signed message --52B94B8FA281627355210BB13CFD00D1 Content-Type: text/plain -CRLF Content-Transfer-Encoding: base64 -CRLF -CRLF SGVsbG8gV29ybGQK -CRLF --52B94B8FA281627355210BB13CFD00D1 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIDVAYJKoZIhvcNAQcCoIIDRTCCA0ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCAYowggGGMIHwAgEBMA0GCSqGSIb3DQEBBQUAMAwxCjAIBgNVBAMMAUMw HhcNMTQwNTAyMTAwMDEwWhcNMTQwNjAxMTAwMDEwWjAMMQowCAYDVQQDDAFEMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1Ra+KYVo4X5suo/j9IpHzi1QwIWyo iAZOQjKGW45lsge0hf/kuI1ow72+eH/+hQNWwU3YljmLCTh7gPPOYRNEXVqiUFKa QnjaPdDOY3lkj+rx+EiGKjoh1mPiXhKXmCroRRXOqof3lUH5KVE/zjqKYXc5lViH MgX3PFs0WT3hvwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAEhoR4hQLpSAKAlZ6Sx+ MZmI+cgFZjPUeOqcGvXQkhNM1+T67YAhFQ7coCN9AKTIJ9bzlT5VMmAtDI1ZtUV1 fDQ+FpQgp/4sXRtAq68kwlip9w097OwU9Q/WYGcib23auBIRj+IHRtmDDpodcS8t zRhGl++JpWUIm61r8Qy6Lo1OMYIBkjCCAY4CAQEwETAMMQowCAYDVQQDDAFDAgEB MAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNTAyMTAwMDExWjAjBgkqhkiG9w0BCQQxFgQU1v1LyFzXxZUl 3PNQr2qU4zYmHfsweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZI AWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEgYAP45BHcXB+QJxPVgMFrC1tcotpadUpzsN+Y6hlZtV2x0ZFscV6nhVw rdntAKsDdHznE1AN2/H4/q2j1ZfEcPKlMrL+EctHrFHfjKr4nwWbfPD4LkoCVLyR 6KtkIsaqwqlEljoBTEtsqib/fvWPJqlhcN4ImXAZXu+BhfmryI6CeQ== --52B94B8FA281627355210BB13CFD00D1——— __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
SRP implementation mishandles salts with leading zeroes
the openssl SRP implementation seems to handle salts with leading zero-bytes incorrectly. salts are internally passed around as BIGNUM, and converted back to uchar* before using them. however, they are only ever needed as uchar*: only used for SHA1-ing. so my guess is the conversion to BIGNUM, and back to uchar* strips leading zeroes. i encountered this when testing a new client+server tls-srp implementation (in golang) against openssl. the authentication fails with salts with leading zeroes (it succeeds with other salts). fwiw, i also tested against gnutls, and could authenticate just fine with such salts. for example, compare, in file crypto/srp/srp_lib.c (openssl-1.0.1g): BIGNUM *SRP_Calc_x(BIGNUM *s, const char *user, const char *pass) with http://tools.ietf.org/html/rfc5054#section-2.4 x = SHA1(s | SHA1(I | ":" | P)) v = g^x % N where "I" stands for "identity", or "user". the use of "x" (bytes from sha1) in the calculation of "v" is allowed due to an implicit conversion to a number, as defined at the bottom of paragraph 2.1, http://tools.ietf.org/html/rfc5054#section-2.1 however, for salt "s", no such implicit conversion is needed. and the same goes for (same file): char *SRP_create_verifier(const char *user, const char *pass, char **salt, char **verifier, const char *N, const char *g) which calls: int SRP_create_verifier_BN(const char *user, const char *pass, BIGNUM **salt, BIGNUM **verifier, BIGNUM *N, BIGNUM *g) thoughts? does conversion from uchar* to bignum, and back to uchar* indeed strip leading zeroes? i think the salt should always be passed around as just bytes. in SRP it is never used for calculations with bignums. cheers, mechiel __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: CVE-2014-0076 and OpenSSL 0.9.7
Hi Ron, 0.9.7 does not support curves over binary fields and is not vulnerable to CVE-2014-0076. I do not know what the Solaris enhancements are and cannot say whether they are vulnerable. Note, also, that some functionality of 0.9.7, and of all later versions of OpenSSL, is vulnerable to the Flush+Reload side-channel attack. Cheers Yuval On 02/05/2014, at 4:25 AM, Ron Jordan wrote: > Hi Folks, > > I'm trying to determine whether CVE-2014-0076 applies to the patched OpenSSL > 0.9.7d that is part of Solaris 10. I looked at the fixes that were applied > to 1.0.1, 1.0.0, and 0.9.8 which include changes to the > ec_GF2m_montgomery_point_multiply() function, which doesn't exist in S10's > enhanced 0.9.7. Based on the actual fix and the fact that none of the still > existing EC routines from 0.9.7 were modified, it appears that the > vulnerability does not apply to 0.9.7. > > But the "Vulnerable software and versions" section of the NIST Vulnerability > Summary seems to imply that the vulnerability applies to 0.9.7 as well: > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0076 > > Can anyone please comment on whether CVE-2014-0076 is in fact relevant to > 0.9.7? Thank you! > > -- > ron jordan > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org > Yuval Yarom Research Associate School of Computer Science, The University of Adelaide Adelaide SA 5005 y...@cs.adelaide.edu.au CRICOS Provider Number 00123M --- IMPORTANT: This message may contain confidential or legally privileged information. If you think it was sent to you by mistake, please delete all copies and advise the sender. For the purposes of the SPAM Act 2003, this email is authorised by The University of Adelaide. Think green: read on the screen.
CVE-2014-0076 and OpenSSL 0.9.7
Hi Folks, I'm trying to determine whether CVE-2014-0076 applies to the patched OpenSSL 0.9.7d that is part of Solaris 10. I looked at the fixes that were applied to 1.0.1, 1.0.0, and 0.9.8 which include changes to the ec_GF2m_montgomery_point_multiply() function, which doesn't exist in S10's enhanced 0.9.7. Based on the actual fix and the fact that none of the still existing EC routines from 0.9.7 were modified, it appears that the vulnerability does not apply to 0.9.7. But the "Vulnerable software and versions" section of the NIST Vulnerability Summary seems to imply that the vulnerability applies to 0.9.7 as well: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0076 Can anyone please comment on whether CVE-2014-0076 is in fact relevant to 0.9.7? Thank you! -- ron jordan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
+1 On 1. Mai 2014 13:35:19 MESZ, "Hanno Böck" wrote: >On Thu, 1 May 2014 13:26:48 +0200 >"Stephen Henson via RT" wrote: > >> Ironically it was added as a workaround for another bug. The padding >> extension was believed to have no side effects... obviously that >> isn't true :-( > >Maybe this should teach us a lesson: Adding more and more Workarounds >for broken stuff isn't the way to go forward. The way to go forward is >to fix broken stuff. > >(we have another pretty simliar example - browsers implemented >out-of-protocol downgrades to "fix" broken implementations just to >notice that they introduced downgrade attacks and accidental downgrades >- now there's a proposal for a downgrade protection extension that only >tries to fix a problem we wouldn't have in the first place if people >didn't introduce stupid workarounds for broken stuff) > >-- >Hanno Böck >http://hboeck.de/ > >mail/jabber: ha...@hboeck.de >GPG: BBB51E42 -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On 01/05/14 12:26, Stephen Henson via RT wrote: On Thu May 01 12:29:58 2014, meiss...@suse.de wrote: Hi, SUSE has received a bugreport from a user, that the "padding" extension change breaks IronPort SMTP appliances. Ironically it was added as a workaround for another bug. The padding extension was believed to have no side effects... obviously that isn't true :-( If you use a smaller cipherstring it should also work without having to force SSLv3. Steve, have you considered trimming the DEFAULT cipher list? It's currently... #define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2" I wonder how many of these ciphers are actually ever negotiated in real-world use. The padding extension is only used if the ClientHello would be between 256 and 511 bytes in length so if you reduce the number of ciphersuites it wont be used. -- 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: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
See also this thread: http://www.ietf.org/mail-archive/web/tls/current/msg12143.html On 01/05/14 11:29, Marcus Meissner via RT wrote: Hi, SUSE has received a bugreport from a user, that the "padding" extension change breaks IronPort SMTP appliances. There might a RT on this already, not sure. https://bugzilla.novell.com/show_bug.cgi?id=875639 http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html Quoting from our openSUSE bugreport: Last upgrade to openssl-1.0.1g-11.36.1.x86_64 broke SSL connections to some services, e.g. Cisco Ironport SMTP appliances. 1.0.1g not only fixes the Heartbleed bug but also adds another change by adding: #define TLSEXT_TYPE_padding 21 This in turn breaks SSL connections to e.g. Ironports, probably others: SSL23_GET_SERVER_HELLO:tlsv1 alert decode error Workaround: Force protocol to SSLv3 or recompile without the define above. For details, please refer to: postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html Reproducible: Always Steps to Reproduce: 1. openssl s_client -connect some.ironport.com:25 -starttls smtp Note: Send me an email for a hostname of an Ironport SMTP appliance to test with. I don't want to disclose it here. Actual Results: CONNECTED(0003) 139718758192784:error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode error:s23_clnt.c:762: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 129 bytes and written 552 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- Expected Results: CONNECTED(0003) --- Certificate chain [...cut...] New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 [...cut..-] 250 STARTTLS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- 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
