Hello,
Running the following command always fails, because the code is hard-coded to
assume all Certification Requests are received in PEM format, despite that it
is not documented in the manual or the CLI help output.
openssl x509 \
-inform der \
-keyform der \
-outform der \
-req \
-in test-c
On Tue, Feb 05, 2013 at 03:18:28PM +0100, OpenSSL wrote:
> OpenSSL Security Advisory [05 Feb 2013]
>
>
> SSL, TLS and DTLS Plaintext Recovery Attack (CVE-2013-0169)
>
>
> Nadhem Alfardan and Kenn
On Wed Feb 06 23:01:25 2013, bugs-...@moonlit-rail.com wrote:
>
> I haven't had a chance (yet?) to bisect the code to find the culprit,
> but I can take a stab at it if a developer doesn't know off the top of
> their head just where it might be.
>
Stop gap measure for now is to revert commit 12509
On Wed, Feb 06, 2013, Dr. Stephen Henson wrote:
> On Wed, Feb 06, 2013, Brad House wrote:
>
> In ssl/s3_cbc.c and the function ssl3_cbc_record_digest_supported try
> setting it to return 0 when NID_sha1 is passed.
>
> >
> > Have you not been able to reproduce this issue? I've seen it on more t
Hi,
FIPS enabled build fail at same line.
Brad House wrote:
It appears there is a major regression with OpenSSL 1.0.1d over
1.0.1c. I've narrowed it down to setting a custom cipher
list I think as if I do not set a cipher list, the issue does
not occur.
I have reproduced the issue with the op
I forgot to mention in my original e-mail that remove /WX from CFLAGS
allows this to compile.
Andy
On 02/06/2013 03:59 PM, The default queue via RT wrote:
> Greetings,
>
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> "OpenSSL
A serious regression was introduced in 1.0.1d that corrupts the data
stream under certain circumstances.
Firefox requests to an Apache server running on Linux/X86_64 with
OpenSSL-1.0.1d result in "501 Server Error" responses. OpenSSL versions
1.0.1c and earlier are not affected. i686 (32 bit)
Configured and built openssl on Windows with:
perl Configure VC-WIN32
ms\do_nasm
nmake -f ms\ntdll.mak
Building OpenSSL
cl /Fotmp32dll\s3_cbc.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2
/W3 /WX /
Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN
-DL_ENDIAN -DD
SO_WIN32 -D_C
hi openssl community maintainers,
I found the original patch was created a few years ago:
http://rt.openssl.org/Ticket/Display.html?id=1325&user=guest&pass=guest
But it's still not push into the upstream repo. I made the patch work
with openssl-1.0.0e. If you don't mind, please put it into the
up
Hi, when I configure openssl-1.0.1d as follows:
./Configure zlib shared linux-x86_64
make test_ssl fails with the following errors
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
dh
test tls1 with 1024bit anonymous DH, multiple handshakes
Ava
Hi,
I'm trying to build my xcode project linked to the FIPS capable library.
I followed the instructions available at
http://www.openssl.org/docs/fips/UserGuide-2.0.pdf for iOS
The last step is to add a build phase script on the application target to
embed the Module signature.
After adding thi
On 02/06/2013 03:21 PM, Brad House wrote:
On 02/06/2013 03:07 PM, Holger Weiß wrote:
* Dr. Stephen Henson [2013-02-06 20:14]:
On Wed, Feb 06, 2013, Brad House wrote:
DHE-RSA-CAMELLIA256-SHA also has the same issue. I'm thinking it may be
a -SHA issue as the only -SHA cipher I've gotten to wo
On 02/06/2013 03:07 PM, Holger Weiß wrote:
* Dr. Stephen Henson [2013-02-06 20:14]:
On Wed, Feb 06, 2013, Brad House wrote:
DHE-RSA-CAMELLIA256-SHA also has the same issue. I'm thinking it may be
a -SHA issue as the only -SHA cipher I've gotten to work so far is RC4-SHA.
Note though the TLSv1
On 02/06/2013 02:14 PM, Dr. Stephen Henson wrote:
On Wed, Feb 06, 2013, Brad House wrote:
On 02/06/2013 01:37 PM, Dr. Stephen Henson wrote:
A possibility is the AESNI+SHA1 stitched code which is handled as a special
case. You'd only see that with AES+SHA1 ciphersuites on AES-NI supporting
proc
* Dr. Stephen Henson [2013-02-06 20:14]:
> On Wed, Feb 06, 2013, Brad House wrote:
> > DHE-RSA-CAMELLIA256-SHA also has the same issue. I'm thinking it may be
> > a -SHA issue as the only -SHA cipher I've gotten to work so far is RC4-SHA.
> > Note though the TLSv1.2+HIGH ciphers that use SHA256 a
After rebuilding my OpenLDAP servers against 1.0.1d, my perl scripts can no
longer negotiate startTLS with the OpenLDAP server, and hang infinitely.
This is a major regression vs 1.0.1c.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
-
On Wed, Feb 06, 2013, Brad House wrote:
> On 02/06/2013 01:37 PM, Dr. Stephen Henson wrote:
> >A possibility is the AESNI+SHA1 stitched code which is handled as a special
> >case. You'd only see that with AES+SHA1 ciphersuites on AES-NI supporting
> >processors.
>
> DHE-RSA-CAMELLIA256-SHA also h
On 02/06/2013 01:37 PM, Dr. Stephen Henson wrote:
A possibility is the AESNI+SHA1 stitched code which is handled as a special
case. You'd only see that with AES+SHA1 ciphersuites on AES-NI supporting
processors.
DHE-RSA-CAMELLIA256-SHA also has the same issue. I'm thinking it may be
a -SHA iss
On Wed, Feb 06, 2013, Brad House wrote:
> On 02/06/2013 12:30 PM, Brad House wrote:
> ..
> > I should also note that currently I am using
> >OpenSSL 1.0.1d-fips 5 Feb 2013
> >On an Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz running Ubuntu 12.04 64bit
> >(so presumably I'm using AES-NI ... notice
On 02/06/2013 12:30 PM, Brad House wrote:
..
> I should also note that currently I am using
OpenSSL 1.0.1d-fips 5 Feb 2013
On an Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz running Ubuntu 12.04 64bit
(so presumably I'm using AES-NI ... noticed changes to that in the
changelog).
I have not yet t
It appears there is a major regression with OpenSSL 1.0.1d over
1.0.1c. I've narrowed it down to setting a custom cipher
list I think as if I do not set a cipher list, the issue does
not occur.
I have reproduced the issue with the openssl s_server/s_client
command line utility. You can see my f
On 02/06/2013 09:43 AM, Salz, Rich wrote:
>> There are actually two licenses. The second allows all software (even
>> closed), but only for non-military use.
>
> I would say that's still a problem. For example, we could use OpenSSL on our
> network to provide acceleration for public DoD sites.
> There are actually two licenses. The second allows all software (even
> closed), but only for non-military use.
I would say that's still a problem. For example, we could use OpenSSL on our
network to provide acceleration for public DoD sites. Is that military use?
Suppose it's for use on a
23 matches
Mail list logo