On our mail system we have 18 different remote systems that TLS fails with in
the last 24 hours. I assume they are using ironport since they are the kind
of domains that would use cisco gear such as utah.edu or dell.com, but it's
hard to tell since it is a security device and doesn't announce
Stephen Henson via RT rt at openssl.org writes:
I've updated OpenSSL so the padding extension is no longer used by default
Stephen,
Does not work for me. Running sendmail 8.14.8, got the decode error
problem with openssl 1.0.1g, fixed it by ssl/tls1.h changing to
/* #define
On Tue, Jun 24, 2014 at 02:29:10PM +, Stefan Runkel wrote:
Stephen Henson via RT rt at openssl.org writes:
I've updated OpenSSL so the padding extension is no longer used by default
Stephen,
Does not work for me. Running sendmail 8.14.8, got the decode error
problem with openssl
On Thu 01 May 2014 13:26:48 Stephen Henson via RT wrote:
On Thu May 01 12:29:58 2014, meiss...@suse.de wrote:
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 Sun, Jun 01, 2014 at 07:18:18PM +0200, Stephen Henson via RT wrote:
I've updated OpenSSL so the padding extension is no longer used by default and
the option SSL_OP_TLSEXT_PADDING enables it (it is part of the SSL_OP_ALL).
This resolves this issue as applications can now decide whether to
Thanks. In particular, since SSL_OP_ALL is a compile-time constant,
applications compiled with older releases will not send the extension by
default. Only applications compiled against 1.0.1g or later that use
SSL_OP_ALL, or specifically enable this work-around, will send the extension.
On Sun, Jun 01, 2014, Viktor Dukhovni wrote:
On Sun, Jun 01, 2014 at 07:18:18PM +0200, Stephen Henson via RT wrote:
I've updated OpenSSL so the padding extension is no longer used by default
and
the option SSL_OP_TLSEXT_PADDING enables it (it is part of the SSL_OP_ALL).
This resolves
On Sun, Jun 01, 2014 at 07:47:30PM +0200, Dr. Stephen Henson wrote:
Thanks. In particular, since SSL_OP_ALL is a compile-time constant,
applications compiled with older releases will not send the extension
by default. Only applications compiled against 1.0.1g or later
that use
On Sun, Jun 01, 2014, Viktor Dukhovni wrote:
On Sun, Jun 01, 2014 at 07:47:30PM +0200, Dr. Stephen Henson wrote:
Thanks. In particular, since SSL_OP_ALL is a compile-time constant,
applications compiled with older releases will not send the extension
by default. Only applications
On Sun, Jun 01, 2014 at 08:32:55PM +0200, Dr. Stephen Henson wrote:
Repurposing bits in this way is problematic if that bit meant something else
in any OpenSSL-1.x.y release (notional ABI). If the bit is from 0.9.x, and
was never used in 1.x.y, then it is OK.
I think it is actually a
Here's more information for those who are interested...
https://supportforums.cisco.com/announcement/12198406/heartbleed-patched-email-servers-fail-tls-connections-esas-80
On 05/06/2014 07:08 PM, Viktor Dukhovni wrote:
On Tue, May 06, 2014 at 02:32:05PM -0400, John Foley wrote:
The defect
On Thu, May 01, 2014 at 01:23:51PM -0400, John Foley wrote:
I'm trying to get that information from the IronPort team. In the mean
time, this bug report appears to have some details:
https://tools.cisco.com/bugsearch/bug/CSCuo25329
It would really be nice that we can get some more
The defect information is available at
https://tools.cisco.com/bugsearch/bug/CSCuo25329. This defect is
viewable to the public. You'll have to register for an account to view
the data.
Viktor already provided a link to the following details as well:
On Tue, May 06, 2014 at 02:32:05PM -0400, John Foley wrote:
The defect information is available at
https://tools.cisco.com/bugsearch/bug/CSCuo25329. This defect is
viewable to the public. You'll have to register for an account to view
the data.
After registering, the bug details are:
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
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
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
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
On Thu, May 01, 2014 at 12:29:58PM +0200, 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
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.
There might a RT on this already, not sure.
https://bugzilla.novell.com/show_bug.cgi?id=875639
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
On Thu, May 01, 2014 at 01:35:19PM +0200, Hanno Böck wrote:
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.
The problem isn't always to fix the broken stuff but ussually to get
On Thu, 1 May 2014 14:29:44 +0200
Kurt Roeckx k...@roeckx.be wrote:
On Thu, May 01, 2014 at 01:35:19PM +0200, Hanno Böck wrote:
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
On Thu, May 01, 2014 at 02:45:19PM +0200, Hanno Böck wrote:
On Thu, 1 May 2014 14:29:44 +0200
Kurt Roeckx k...@roeckx.be wrote:
On Thu, May 01, 2014 at 01:35:19PM +0200, Hanno Böck wrote:
Maybe this should teach us a lesson: Adding more and more
Workarounds for broken stuff isn't
On Thu, May 01, 2014 at 01:26:48PM +0200, Stephen Henson via RT wrote:
Workaround: Force protocol to SSLv3 or recompile without the define
above.
If there were an SSL_OP_ flag to allow applications to disable
padding, that would be useful for SMTP applications. There is
precious little
This is a known problem in the Ironport TLS stack. Ironport has
released a hot patch to address this problem.
On 05/01/2014 06:29 AM, 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
On Thu, May 01, 2014 at 12:08:50PM -0400, John Foley wrote:
This is a known problem in the Ironport TLS stack. Ironport has
released a hot patch to address this problem.
Any links to the fix?
I'd like to post a link to the fix to the Postfix and Exim users
lists, so that if anyone runs into
I'm trying to get that information from the IronPort team. In the mean
time, this bug report appears to have some details:
https://tools.cisco.com/bugsearch/bug/CSCuo25329
On 05/01/2014 12:26 PM, Viktor Dukhovni wrote:
On Thu, May 01, 2014 at 12:08:50PM -0400, John Foley wrote:
This is a
On Thu, May 01, 2014 at 01:23:51PM -0400, John Foley wrote:
I'm trying to get that information from the IronPort team. In the mean
time, this bug report appears to have some details:
https://tools.cisco.com/bugsearch/bug/CSCuo25329
Sadly, this requires a login. The bug is however
44 matches
Mail list logo
