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 what
On Tue, Jun 24, 2014 at 02:29:10PM +, Stefan Runkel wrote:
> Stephen Henson via RT 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
Stephen Henson via RT 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 TLSEXT_TYPE_padding
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.
> >
> > h
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 ac
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 appli
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 SS
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
> 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 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
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 decided whether to use the
padding extension or not.
Steve.
--
Dr Stephen N. Henson. OpenSSL p
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 defec
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:
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:
http://www.cisco.com/c/dam/en/us/td/docs/sec
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 inform
> 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, an
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
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
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
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 cl
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,
> > 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,
- 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 site
> 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: "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 browse
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
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
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
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,
>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.
+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 sh
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 extens
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 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 refere
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 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
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.
>
> Ther
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 p
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 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 th
On Thu, 1 May 2014 14:29:44 +0200
Kurt Roeckx 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 stuff.
>
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 ge
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 br
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
> http://postfix.
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=8756
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-inte
45 matches
Mail list logo