-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear Users,
I have released version 5.06 of stunnel.
This is a security bugfix release. Update is recommended.
The ChangeLog entry:
Version 5.06, 2014.10.15, urgency: HIGH:
* Security bugfixes
- OpenSSL DLLs updated to version 1.0.1j.
I downloaded the OpenSSL 1.0.0o source but I am running into a new
problem when trying to compile it. The 'make depend' step fails with:
s3_lib.c:2507:4: error: #error Code needs update for SSLv23_method()
support beyond TLS1_VERSION.
d1_lib.c:273:4: error: #error Code needs update for
Greetings folks. trying to compile 0.9.8zc on aix 7.1 (and 6.1) with various
versions on xlc
Aix 7.1 has xlc 11.1
Aix 6.1 has xlc 9
Both fail given these steps:
./config shared threads
Compiles for aix-cc
making all in crypto/rsa...
gmake[2]: Entering directory `/san/dev/ssl/0.9.8/crypto/rsa'
On 10/15/2014 01:46 AM, Bodo Moeller wrote:
Here's a patch for the OpenSSL 1.0.1 branch that adds support for
TLS_FALLBACK_SCSV, which can be used to counter the POODLE attack
(CVE-2014-3566; https://www.openssl.org/~bodo/ssl-poodle.pdf).
Note that the CVE identifier was assigned to the SSL
Would you like all your OpenSSL-enabled applications to be configured
all the same, with the same protocols and same ciphersuites?
--
Erwann ABALEA
Le 15/10/2014 23:56, Todd Pfaff a écrit :
I'd like to be able to disable SSLv3 for all openssl-enabled applications
in a single configuration
On 10/16/2014 10:41 AM, Salz, Rich wrote:
Note that the CVE identifier was assigned to the SSL 3.0 protocol issue
related to CBC padding. The new SCSV does not help with that at all.
What? It prevents silently falling back to the broken protocol.
Perhaps we can keep this battle-thread just
Does the openssl library not read the config file thereby enforcing
what is available to all applications that use the openssl library?
Or am I being too optimistic?
What behaviour exists within the openssl library when it is built and
configured with options to disable certain protocols or
On Thu, 16 Oct 2014, Erwann Abalea wrote:
Would you like all your OpenSSL-enabled applications to be configured all the
same, with the same protocols and same ciphersuites?
No. I was just wondering whether it was possible to exclude support for
SSLv3 at runtime in one place for all
Does the openssl library not read the config file thereby enforcing what is
available to all applications that use the openssl library?
No it does not.
What behaviour exists within the openssl library when it is built and
configured with options to disable certain protocols or ciphers that
Again, this is not related to the question whether the fallback SCSV is a good
idea. It is a procedural issue with CVE naming.
Then take it up with the CVE folks. Not here. :)
--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Mike,
Latest build seems to be broken for me on OS X 10.10. If it matters
here, since the error is SSL related, I'm building against OpenSSL
1.0.1j which is configured without ssl2 ciphers but with ssl3 ciphers
enabled.
This is the error:
Hi,
I get the following segfault when trying to send an SSLv3 request to the
reverse proxy pound, running on openssl-1.0.1j with SSLv2/3 disabled:
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 14548]
0xb77498fa in ssl_ctrl (b=0xb7001010, cmd=1, num=0, ptr=0x0) at
Hi,
Do we have a patch for ALPN extension ?
Thanks,
Jayadev
On Wed, Oct 15, 2014, Russell Selph wrote:
Apologies if this is a duplicate post. I tried first via Google Groups, but
apparently it's read-only. ;-)
Has anyone else built 0.9.8zc with FIPS 1.2.4? I've been unable to get a
build that passes the 'make test' phase. I'm using build scripts
On 10/15/2014 3:01 PM, Jay Foster wrote:
I downloaded the OpenSSL 1.0.0o source but I am running into a new
problem when trying to compile it. The 'make depend' step fails with:
s3_lib.c:2507:4: error: #error Code needs update for SSLv23_method()
support beyond TLS1_VERSION.
d1_lib.c:273:4:
Does applying the following two patches fix your build?
http://git.openssl.org/gitweb/?p=openssl.gita=commith=8202802fadf7f70c656b92f3697da39c9c4271d7
http://git.openssl.org/gitweb/?p=openssl.gita=commith=e2e5326e5b068411999f62b4ba67835d64764ca5
These are build fixes that we appear to have
On Thu, Oct 16, 2014, Russell Selph wrote:
Thanks. We're going ahead with patching 0.9.8zc to ignore this test. I'm
not sure if it's the right solution, but given that 0.9.8 is EOL, and
therefore FIPS 1.2.4 is VERY unlikely to ever be updated, would it be
reasonable to have 0.9.8 disable
Thanks for the reply…
Applied both sets of patches (on aix 71./xlc 11.1). I added –qlanglvl=extc99…
even without this it fails with the original error
cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE
-DDSO_DLFCN -DHAVE_DLFCN_H -qlanglvl=extc99 -q32 -O -DB_ENDIAN
That is a different error, but it seems to suggest you haven't applied the
patches cleanly - you shouldn't be seeing
../constant_time_locl.h in the errors anymore as the first patch does
-#include ../constant_time_locl.h
+#include constant_time_locl.h
On Thu, Oct 16, 2014 at 7:02 PM, Kyle
Configured on aix 7.1 with:./config shared threads –qkeyword=inline
And at least it compiles ok and make test works… running through some more
options on aix and will see what compiler option may work on hpux
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On
patches are in ok, the output is from the –I paths to the compiler. There was
a local change to the header outside of the patches, which I reverted. Still
didn’t change the build result until I changed the config options -- see
incoming mail about that.
Cut from the c file that fails first…
Ah yes, I misread the first error log. This is about the 'inline' keyword.
We've hopefully fixed this problem in the master branch as well, see commits
40155f408985aff2e9f1b61b7cb04a3e518633a1
and
55c7a4cf112bf154ed405ee05a6b7924b6b1ba92
They should essentially achieve the same as
Applied the patch to e_os.h
Hp now builds without any hacks, and aix no longer requires -qlanglvl=extc99 or
–qkeyword=inline
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Emilia Käsper
Sent: Thursday, October 16, 2014 3:09 PM
To:
Hi,
Il 16/10/2014 00:01, Salz, Rich ha scritto:
I recommend that you always set that flag.
Do I need to detect which OpenSSL version I have before setting that
flag (otherwise it would break the application) or can I always safely
set it on a SSL context?
In other words: I'd like to do
A few short (simple) questions about the use of TLS_FALLBACK_SCSV since we’re
currently upgrading to the latest openssl releases.
We don’t establish sessions with any other products than our own clients and
servers.
We’ve already disabled the use of SSLv3 in both our client and server releases
On Thu, Oct 16, 2014 at 4:42 PM, Nou Dadoun ndad...@teradici.com wrote:
...
We’ve already disabled the use of SSLv3 in both our client and server
releases going forward, is there any advantage in also using
TLS_FALLBACK_SCSV – i.e. will there be any benefit in connecting to our
already
#ifndef SSL_MODE_SEND_FALLBACK_SCSV
#define SSL_MODE_SEND_FALLBACK_SCSV 0x0080L
#endif
That will not work. You can do this:
#ifdef SSL_MODE_SEND_FALLBACK_SCSV
SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV)
#endif
But that is not the same thing.
You cannot just slip SCSV into
It does not matter who you talk to. With a POODLE attack, your content can be
decrypted. Cookies, etc., were just used as an example.
Disabling ssl3 is a good thing. But set the fallback because silently dropping
from tls 1.2 to tls 1.1 is bad. It’s done during the handshake process as part
But my understanding is that it requires the same content to be submitted
repeatedly within a single session with manipulations to the padding to
incrementally decrypt the content; we use ssl to protect our session
establishment - think of a SIP call, SIP INVITE (offer) in one direction and
29 matches
Mail list logo
