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.
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
+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
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
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
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,
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
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
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
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
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,
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.
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
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
- 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
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
- 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
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
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,
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
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
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
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
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
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
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
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
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
28 matches
Mail list logo
