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
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 w
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=e76e308f1fab2253ab5b4ef52a1865c5ffecd
> 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
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. A
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 sites (as a semi-representative sample)
>
> 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 browsers still advertise RC4
> cipher s
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.
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 j
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
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 -signe
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, a
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
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
+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.
28 matches
Mail list logo
