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
SIP
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
> #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 int
On Thu, Oct 16, 2014 at 4:42 PM, Nou Dadoun 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 deployed clients and s
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
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 som
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: openssl-users@opens
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 -qkeyword=inlin
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…
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 Beh
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
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 -qm
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 disab
Does applying the following two patches fix your build?
http://git.openssl.org/gitweb/?p=openssl.git&a=commit&h=8202802fadf7f70c656b92f3697da39c9c4271d7
http://git.openssl.org/gitweb/?p=openssl.git&a=commit&h=e2e5326e5b068411999f62b4ba67835d64764ca5
These are build fixes that we appear to have mi
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: e
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 this test when doing a FIPS build?
I only ask
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 scr
Hi,
Do we have a patch for ALPN extension ?
Thanks,
Jayadev
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 bio_ss
-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:
libto
> 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
_
> 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 tha
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 openssl-en
Im getting the following error
using openssl x509 -inform DER -in cms_cert.der -text
140026491385512:error:100D7010:elliptic curve routines:ECKEY_PUB_DECODE:EC
lib:ec_ameth.c:206:
140026491385512:error:0B07707D:x509 certificate routines:X509_PUBKEY_get:public
key decode error:x_pubkey.c:164:
This is not quite the same discussion as in the TLS Working Group, but I
certainly think that the claim that "new SCSV does not help with [the SSL
3.0 protocol issue related to CBC padding] at all" is wrong, and that my
statement that TLS_FALLBACK_SCSV can be used to counter CVE-2014-3566 is
right.
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 ciphe
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 i
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 file
> 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 in the TLS WG mail?
/r$
--
Pri
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 3.0
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'
c
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 DTLS_me
-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.
https:/
33 matches
Mail list logo
