Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

2014-05-02 Thread Rob Stradling

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


Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

2014-05-02 Thread Rob Stradling

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.

snip

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)

2014-05-02 Thread Jan
+1

On 1. Mai 2014 13:35:19 MESZ, Hanno Böck ha...@hboeck.de wrote:
On Thu, 1 May 2014 13:26:48 +0200
Stephen Henson via RT r...@openssl.org 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.

CVE-2014-0076 and OpenSSL 0.9.7

2014-05-02 Thread Ron Jordan

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: CVE-2014-0076 and OpenSSL 0.9.7

2014-05-02 Thread Yuval Yarom
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 ron.jor...@oracle.com 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.






SRP implementation mishandles salts with leading zeroes

2014-05-02 Thread Mechiel Lukkien
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


Minor CRLF issue in mine

2014-05-02 Thread Dirk-Willem van Gulik
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


Re: SRP implementation mishandles salts with leading zeroes

2014-05-02 Thread Mechiel Lukkien
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


Re: SRP implementation mishandles salts with leading zeroes

2014-05-02 Thread Kurt Roeckx
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: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

2014-05-02 Thread Salz, Rich
Steve, have you considered trimming the DEFAULT cipher list?
It's currently...
#define SSL_DEFAULT_CIPHER_LISTALL:!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: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

2014-05-02 Thread John Foley
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)

2014-05-02 Thread Salz, Rich
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)

2014-05-02 Thread Kurt Roeckx
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)

2014-05-02 Thread Kurt Roeckx
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)

2014-05-02 Thread Hubert Kario
- Original Message -
 From: John Foley fol...@cisco.com
 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_LISTALL:!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)

2014-05-02 Thread Salz, Rich
 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)

2014-05-02 Thread Hubert Kario
- Original Message -
 From: Rich Salz rs...@akamai.com
 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)

2014-05-02 Thread Salz, Rich
  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)

2014-05-02 Thread Viktor Dukhovni
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)

2014-05-02 Thread Viktor Dukhovni
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)

2014-05-02 Thread Piotr Sikora
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)

2014-05-02 Thread Kurt Roeckx
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 #3321] NULL pointer dereference with SSL_MODE_RELEASE_BUFFERS flag

2014-05-02 Thread mancha
Kurt Roeckx via RT rt at 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)

2014-05-02 Thread Tim Hudson
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 #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)

2014-05-02 Thread Salz, Rich
 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 #3321] NULL pointer dereference with SSL_MODE_RELEASE_BUFFERS flag

2014-05-02 Thread Kurt Roeckx via RT
On Fri, May 02, 2014 at 06:53:06PM +, mancha wrote:
 Kurt Roeckx via RT rt at 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


Concurrent calls to DH_generate_key are serialized?

2014-05-02 Thread Daniel Sands
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


[openssl.org #3321] NULL pointer dereference with SSL_MODE_RELEASE_BUFFERS flag

2014-05-02 Thread Matt Caswell via RT
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