[to...@tutus.se - Thu Mar 01 15:44:36 2012]:
Hi,
In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
parser that if one has length data such as
84 00 00 00 00
at the end of a block to be parsed, it will give header too long error
even though the ASN.1 is valid.
[zo...@zooko.com - Fri Mar 02 12:36:14 2012]:
If there's any interest, I could write a patch for openssl to zero out
memory before using it in the PRNG. I assume that you have discussed
that before now and decided against it, but if you want a patch that
does that, let me know.
This is
[var...@yahoo.com - Sat Mar 03 13:23:18 2012]:
I'll submit another request related to why I want this done; but the
move itself should be OK, I think. [I would like to be able to
check the trusted store for any matching issuer when building the
client-verification chain. This
[sebast...@breakpoint.cc - Fri Mar 02 08:55:25 2012]:
* Stephen Henson via RT | 2012-02-27 17:43:48 [+0100]:
According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
Is there a commit id or patch somewhere
[stkap...@cisco.com - Fri Feb 10 16:40:08 2012]:
I have verified with a new build that I was able to connect WITHOUT
forcing the TLS version. So the changes worked in my tests.
OK, thanks for the update, ticket resolved.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
[steve - Fri Mar 02 03:57:59 2012]:
[to...@tutus.se - Thu Mar 01 15:44:36 2012]:
Hi,
In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1
parser that if one has length data such as
84 00 00 00 00
at the end of a block to be parsed, it will give header
[nick.le...@usa.g4s.com - Mon Sep 12 10:31:50 2011]:
Thank you for looking at the patch and reporting the problem
with it. I apologise that I did not test it properly. The path loop
test in the patch should of course be first whether the issuer is
in the chain and only if it is
[seggelm...@fh-muenster.de - Mon Mar 05 15:26:38 2012]:
The DTLS implementation does not lower the assumed MTU after
unsuccessful retransmissions, which results in a failing handshake in
case fragmentation is necessary.
With this patch the MTU is reduced to a safe value of 576 - 20 - 8
[n...@gnutls.org - Sat Mar 17 14:57:31 2012]:
Hello,
My reading of RFC4492 is that the ECC ciphersuites apply only to TLS
1.0 or later. According to it: This document describes additions to TLS
to support ECC, applicable both to TLS Version 1.0 [2] and to TLS
Version 1.1 [3]. In
[fol...@cisco.com - Sat Mar 17 14:55:45 2012]:
Using openssl s_server as the application with libcrypto 1.0.1, it
appears the TLS 1.2 behavior may not be compliant with RFC 5246. Page
49 of RFC 5246 states:
If the client provided a signature_algorithms extension, then all
The documentation doesn't reflect current behaviour. The type
parameter to DSA_sign and DSA_verify is currently ignored, it should
arguably check the length is consistent with the passed digest type.
The actual algorithm implementation is OK though. The supplied digest
will be truncated if it
[n...@gnutls.org - Sat Mar 17 16:08:24 2012]:
I captured the handshake (attached), and it seems the client advertises
TLS 1.2. Could it be that the fallback is on the lowest supported
version rather than the next available?
That's strange. I tried OpenSSL 1.0.0h server (which supports
[k...@roeckx.be - Sun Mar 18 01:03:05 2012]:
On Sun, Mar 18, 2012 at 12:49:35AM +0100, Kurt Roeckx via RT wrote:
I can confirm that removing the no-ssl2 part gets me a TLS
instead of SSLv3 connection.
The problem seems to be this code in s_client.c:
#if !defined(OPENSSL_NO_SSL2)
[kapo...@melix.org - Fri Mar 23 11:59:30 2012]:
Hi,
after updating to openssl 1.0.1 (debian package), authentication
against a test server
with a 512 bit rsa key gives :
openssl s_client -connect 127.0.0.1:12346 -key /home/dev/agent1-
key.pem -cert /home/dev/agent1-cert.pem
...
[rouss...@measurement-factory.com - Wed Mar 21 10:24:07 2012]:
Hello,
A verification callback registered with SSL_CTX_set_verify() gets
called for most validation errors, as expected. The callback always
returns 1 (keep validating) result so that it can see all errors.
However,
[ste...@stebalien.com - Fri Mar 23 18:21:39 2012]:
OpenSSL negotiation times out when connecting to Outlook Exchange 2007
both through Outlook Web Access (webmail) and IMAP (POP untested). This
bug appeared between version 1.0.0h and 1.0.1-beta1.
OS: Arch Linux
Applications tested:
[k...@roeckx.be - Sun Mar 25 04:51:32 2012]:
On Fri, Mar 23, 2012 at 06:49:43PM +0100, Stephen Henson via RT wrote:
[ste...@stebalien.com - Fri Mar 23 18:21:39 2012]:
OpenSSL negotiation times out when connecting to Outlook Exchange
2007
both through Outlook Web Access (webmail
[steve - Sun Mar 25 13:11:30 2012]:
I've done some more tests and it seems that the size of the client hello
message is significant: all the options that work reduce the size of
client hello. If you use the -debug option and check out the first
message bytes 4 and 5 it seems those servers
A temporary workaround for this is to apply these two patches to OpenSSL
1.0.1:
http://cvs.openssl.org/chngview?cn=22286
http://cvs.openssl.org/chngview?cn=22306
And recompile OpenSSL with -DOPENSSL_NO_TLS1_2_CLIENT (e.g. supplied as
a command line option to config or Configure). I'm working on
[john_fitzgib...@yahoo.com - Fri Mar 30 09:21:50 2012]:
Don't know if this is related or not, but I'm also running a very
similar test that uses TLS instead of DTLS, (same scenario, OpenSSL
1.0.1 with 1.0.0 Cipher Suites selected). That works fine, except
that the 64 bit version of
[john_fitzgib...@yahoo.com - Sat Mar 31 07:50:09 2012]:
This is happening because of the following, (which looks like a bug),
in ssl/d1_srvr.c, line 923:
Time=(unsigned long)time(NULL); /*
Time */
l2n(Time,p);
[john_fitzgib...@yahoo.com - Tue Apr 03 23:24:21 2012]:
Andy has made some recent fixes to the AES code too which may be
relevant. Please check the next snapshot to see if you still have
problems.
I get the same results with openssl-1.0.1-stable-SNAP-20120403.tar.gz
To narrow down
[tm...@redhat.com - Sat Apr 07 15:39:00 2012]:
This bug report applies to the OpenSSL FIPS 2.0 module.
If dctx-get_entropy() fails and thus the tout is set to NULL we will
set the output entropy pointer to NULL + blocklen. This will later lead
to crash as we check for NULL entropy before
[openssl-dev@openssl.org - Wed Apr 25 00:33:54 2012]:
Hi,
1.0.0 had this:
/* SSL_OP_ALL: various bug workarounds that should be rather harmless.
* This used to be 0x000FL before 0.9.7. */
#define SSL_OP_ALL 0x8FFFL
1.0.1 now
[tm...@redhat.com - Wed Apr 25 12:10:34 2012]:
On Wed, 2012-04-25 at 10:35 +0200, Andy Polyakov via RT wrote:
more secure protocols. Trade-off. As 1.0.0 application is not in
position to expect anything above TLS1.0, trade-off can as well be
resolved in favor of interoperability. Note
According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
__
OpenSSL Project http://www.openssl.org
Development Mailing
[runningdoglac...@yahoo.com - Fri May 04 11:18:52 2012]:
There are two groups of four ciphersuites that I think have mismatched
key exchange cipherlist labels.
The first four are DH-DSS ciphersuites with which don't seem to be
enabled, but as long as they are in the table perhaps they
[zero...@gmail.com - Sat May 05 20:27:54 2012]:
Hi all,
Probably there is some regression in openssl.
After some
updates on my system I can't use Evernote under wine anymore. I posted
a bug: http://bugs.winehq.org/show_bug.cgi?id=30598
Looking for a
solution I've founded the
[openssl-dev@openssl.org - Fri May 11 02:12:15 2012]:
This is a problem reproducible with s_client / s_server.
OpenSSL 1.0.1b and just reconfirmed present in 1.0.1c.
Server:
openssl s_server -cert spodhuis-smtpmx.crt.pem -key spodhuis-
smtpmx.key.pem
Client:
openssl s_client
[openssl-dev@openssl.org - Fri May 11 14:35:45 2012]:
The code below deadlocks against itself in some systems because
EVP_PKEY_free call CRYPTO_add with CRYPTO_LOCK_EVP_PKEY.
Should be fixed with: http://cvs.openssl.org/chngview?cn=22568
Thanks for the report.
Steve.
--
Dr Stephen N.
According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
__
OpenSSL Project http://www.openssl.org
Development Mailing
According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.
__
OpenSSL Project http://www.openssl.org
Development Mailing
[f.val...@cepisoft.net - Fri Jun 01 20:14:30 2012]:
I'm using openssl.exe (last version 1.0.1) for encrypt some files with
Windows Seven.
My command line is :
openssl cms -encrypt -in c:\sc224.pdf -out c:\sc224.pkcs7 -outform DER
-aes-128-cbc c:\test.pem
I haven't problem for
[ma...@extendedsubset.com - Mon Jun 04 00:23:30 2012]:
Greetings,
The Tor project has uncovered an issue with the new support for TLS
1.1
and 1.2 in OpenSSL 1.0.1. It is reproducible with the s_client
utility.
There does not appear to be any obvious security impact, but it does
[openssl-dev@openssl.org - Fri Jun 08 00:27:27 2012]:
This is almost identical to an issue we found with openssl 1.0.1b and
Juniper SBR version v6.13.4949
In our case we traced it to the heartbeat extension. When the
extension is
sent in the ClientHello PEAP negotiation fails with fatal
[fol...@cisco.com - Fri Jul 06 17:50:15 2012]:
RFC 5246 allows a TLS 1.2 client to omit the Signature Algorithm
extension. See section 7.4.1.4.1 for details. This creates a problem
for OpenSSL 1.0.1 when acting as a server and either a DSA or ECDSA
certificate is used. Because the
[fol...@cisco.com - Mon Jul 09 14:14:25 2012]:
Confirmed. The problem is resolved in the latest snapshot. Thank you.
OK, thanks for the report, ticket resolved.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see:
I've finally had time to look into this. Please see if this fixes the issue:
http://cvs.openssl.org/chngview?cn=22789
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
[qua...@zimbra.com - Tue Aug 28 22:43:34 2012]:
--On Tuesday, August 28, 2012 4:36 PM +0200 The default queue via RT
r...@openssl.org wrote:
Mutex information from gdb:
(gdb) print mutex
$5 = (ldap_pvt_thread_mutex_t *) 0x7f8387626f30
(gdb) print *mutex
$6 = {__data = {__lock = 2,
[daniel-marsch...@viathinksoft.de - Wed Sep 12 14:14:40 2012]:
Hello, I found out that the rsa keysize is limited.
Here is my script: http://www.viathinksoft.de/~daniel-
marschall/asn.1/rsa-keysize-check/openssl_rsa32768_bug/
I cannot create a 32768 bits certificate which I want to create
[rob.stradl...@comodo.com - Fri Sep 21 15:02:54 2012]:
Attached are patches for 1.0.0 and 0.9.8.
Note, I updated the original change to retain compatibility with
existing behaviour as far as possible. See:
http://cvs.openssl.org/chngview?cn=22808
Steve.
--
Dr Stephen N. Henson. OpenSSL
[rob.stradl...@comodo.com - Fri Sep 21 15:55:39 2012]:
Hi Steve.
I saw your update (to 1.0.2 and HEAD), and I did start looking at
backporting it into my 1.0.1/1.0.0/0.9.8 patches.
ssl_get_server_send_pkey() is not available in 1.0.1 and earlier, so the
t1_lib.c patch would have to
[shanemhan...@gmail.com - Wed Sep 26 20:08:24 2012]:
eng_cryptodev.c appears to be exhibit bad behavior when hashing large
files.
The problem is that unless EVP_MD_CTX_FLAG_ONESHOT is set on the message
digest context, the engine will continue to suck all the data into memory
(the mac_data
[lee.bayd...@gmail.com - Mon Nov 05 14:57:30 2012]:
When attempting to build openssl-1.0.1c in fips compliant mode, the file
crypto/ec/ec2_smpl.c attempts to return the results of function
fips_ec_gf2m_simple_method(). This function is not defined in either
projects.
Did you compile
[vpodz...@redhat.com - Tue Oct 30 17:34:05 2012]:
Description of problem:
Running
$ openssl genpkey -genparam -outform DER -out dh_params.der -algorithm
DH
generates data in the PEM format instead of the requested DER format.
Version-Release number of selected component (if
[openssl-dev@openssl.org - Wed Nov 07 20:23:31 2012]:
Hi,
the attached patch implements wildcard matching and introduces the
X509_CHECK_FLAG_NO_WILDCARDS flag to disable it if necessary.
In addition, it implements case-insensitive comparison of host names and
email address domain
[mtau...@fsmat.at - Tue Nov 20 09:33:34 2012]:
Hello!
I have created a patch which adds a --with-fipsincludedir switch to
the Configure script.
If you want to create a FIPS-enabled build, the include files are
currently looked for in FIPSDIR/include. The value of this option
Thanks for the report, I've applied a fix.
I've not applied the second part of the patch because then the return
variable ret is set to the return value of X509_verify_cert() which is
intentional.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now
Thank you for the report, sorry for the delay in looking at this. This
was fixed in 1.0.1 and later but never backported for some reason.
See if this works for you:
http://cvs.openssl.org/chngview?cn=23094
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support
[openssl-dev@openssl.org - Tue Dec 11 00:48:42 2012]:
In my case, handshake rate drops down to 5-6% on the same hardware
in 1.0.1c
in comparison to 1.0.0i.
I was wrong. Handshake performance degradation is about 10%.
First guilty function is EVP_DigestSignFinal what is perform copying
[meiling...@emc.com - Wed Dec 26 21:07:57 2012]:
Hi Openssl team,
I have an performance issue with openssl_fips.
My application use openssl_fips version 0.9.8.
Recently, I found that the fips lib make my application slow.
When my application initialize the fips setting, it introduces 7000+
On Thu Jan 10 15:33:12 2013, meiling...@emc.com wrote:
Hi,
Thank you.
I just notice that the main time consumer is not the
getpid().
I also found thousands of “FIPS_selftest_failed” during
FIPS mode setup which indeed induce the getpid call.
Is it normal
that FIPS_mode_set(1) needs 5
On Sun Feb 03 19:14:05 2013, m...@netbsd.org wrote:
Here is the first EVP_PKEY_meth_free(0xbb1d0f94) call backtrace:
#0 EVP_PKEY_meth_free (pmeth=0xbb1d0f94) at
/openssl/crypto/evp/pmeth_lib.c:294
#1 0xbb7407c6 in engine_pkey_meths_free (e=0xbb2e8f90) at
On Mon Feb 04 13:16:02 2013, martin.sa...@sokordia.cz wrote:
Hi,
I got a problem after upgrading from 0.9.8o to 1.0.1c with connecting to an
Oracle Application HTTPS Server:
epr@trustica:~$ wget --no-check-certificate https://exekutor.mfcr.cz/
--2013-02-03 23:42:39--
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
On Thu Feb 07 00:43:10 2013, steve wrote:
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
On Sat Feb 09 15:02:54 2013, i...@ecsystems.nl wrote:
Same here, but what are we missing by not using /WX ? can the build be
relied upon since it is a fatal error to begin with... if it was a
warning I would not be concerned.
The /WX flags means treat all warnings as errors.
Steve.
--
Dr
On Tue Feb 12 15:20:48 2013, dw...@infradead.org wrote:
Since commit a693ead6 in HEAD, 820988a0 in 1.0.2, 014265eb in 1.0.1 and
f852b6079 in 1.0.0, DTLS_BAD_VER (needed for Cisco AnyConnect
compatibility) has been broken.
Applied now. Thanks for the report.
Steve.
--
Dr Stephen N. Henson.
On Wed Feb 13 20:28:12 2013, rs...@akamai.com wrote:
Some targets need to be removed before rebuilding them:
Unfortunately some platforms can't automatically build the files e.g. WIN32,
VMS.
Also:
# objects.pl both reads and writes obj_mac.num
obj_mac.h: objects.pl objects.txt obj_mac.num
On Thu Feb 14 04:35:05 2013, rs...@akamai.com wrote:
Unfortunately some platforms can't automatically build the files
e.g. WIN32, VMS.
Okay, so those targets shouldn't get invoked?
Or are you saying that you WANT the build to fail on those
platforms?
Ah so you're saying the files would
On Thu Feb 14 18:14:37 2013, woll...@igel.com wrote:
Hi,
there is a problem with certificate verification. Windows allows the
generation of CA certificates which uses RSA-SHA512 as the hash
algorithm. But this hash algorithm is currently not supported by
OpenSSL. Will this issue be fixed in
On Fri Feb 15 10:24:22 2013, woll...@igel.com wrote:
we are using OpenSSL 0.9.8k. It's not the command line utility.
We are linking against libcrypto and libssl. We load the CA
certificates with SSL_CTX_set_default_verify_paths (c_rehash has
been executed before), disable the automatic
On Thu Feb 14 14:24:18 2013, rs...@akamai.com wrote:
We extract a tarball and make everything read-only. Sometimes an item
in the distribution gets re-made. This can fail because of
permissions. So, on platforms where this would happen, we'd like to
remove the file first. I wasn't advocating
On Tue Feb 19 14:36:26 2013, sushil_sha...@in.ibm.com wrote:
Steps to Reproduce:
1. Create a x509 certificate and save the hash file in truststore.
2. upgrade openssl to 1.0.1
3. try to verify certificate using verifycommand and specify -CApath
as
truststore path.
The hash calculation
On Tue Feb 26 12:56:43 2013, araha...@in.ibm.com wrote:
Hi ,
I have gone through the change log of openssl implementation and
come to know that there is initial support for TLSv1.2 in the openssl
library.
Please let me know following are the only TLSv1.2 support in the
openssl library. Can
On Tue Mar 12 23:15:50 2013, thomas_harn...@symantec.com wrote:
When attempting to validate certificates using a CRL with the
X509_verify_cert setup, it fails w/ the error code 36 -
X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION
The extension in question is the AKID - Authority Key Identifier
On Mon Mar 18 20:37:23 2013, zhala...@loginet.hu wrote:
Hello!
I'm using OpenSSL 1.0.1c on a 64bit Gentoo Linux, and there is a server
which hangs after sending the first packet. The server does not support
TLS 1.1 or 1.2, only 1.0. Opera with TLS 1.2 enabled, and Internet
Explorer with TLS
On Thu Mar 28 14:33:41 2013, joseb...@hotmail.com wrote:
Hello,
I´m using OpenSSL 1.0.1c as a CA to sign a corporate certificate.
OpenSSL is configured as follows:
# This sets a mask for permitted string types. There are several
options.
# default: PrintableString, T61String, BMPString.
#
On Fri Mar 22 20:41:21 2013, fr...@baggins.org wrote:
Hello
When using OpenSSL-1.0.1e-fips a call to PEM_write_bio_PrivateKey
silently fails and produces a corrupt pem file when using an
EVP_PKEY_EC key and a binary curve. The same function works fine when
not using a FIPS capable OpenSSL. I
On Fri May 03 18:52:49 2013, fromopen...@homelinkcs.com wrote:
With openssl 1.0.0j, I could connect to www.energydirect.com using:
openssl s_client -connect www.energydirect.com:443
But since my distribution upgraded to 1.0.1c, that command just shows
CONNECTED(0003), hangs for a while,
On Sun May 05 23:40:18 2013, aschu...@tpip.net wrote:
Hi,
found in the current git version.
RFC 6347, Sect. 4.2.2 says:
The first message each side transmits in each handshake always has
message_seq = 0. Whenever each new message is generated, the
message_seq value is incremented by one.
On Tue May 07 15:01:11 2013, bert.reg...@absio.com wrote:
*
* libcrypto's d2i_PKCS8PrivateKey_bio function is unable to read data
that is
* generated using it's own i2d_PKCS8PrivateKey_bio function, this
also limits
* functionality tremendously in that i2d_PrivateKey can not take any
On Thu Jul 11 23:50:49 2013, f...@open.ch wrote:
Following bug occurred with s_client under
* OpenSSL 1.0.1c 10 May 2012
* OpenSSL 1.0.1e 11 Feb 2013.
However, not triggered with s_client under
* OpenSSL 0.9.8x 10 May 2012.
API calls tested and failed under
* OpenSSL 1.0.1c 10 May 2012.
On Fri Jul 12 14:22:46 2013, steve wrote:
Obviously the loop shouldn't happen: I'll look into fixing that.
Should be fixed with this:
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4b26645c1a71cf9ce489e4f79fc836760b670ffe
Regards, Steve.
--
Dr Stephen N. Henson. OpenSSL project
On Fri Jul 26 09:26:23 2013, jake.petrou...@petroules.com wrote:
Hello,
I've discovered a bug in OpenSSL HMAC handling -- when calling the
HMAC() (http://www.openssl.org/docs/crypto/hmac.html) function, an
incorrect result will be given if the `key` parameter is a NULL
pointer, even when
On Mon Jul 29 23:00:40 2013, cgal...@gmail.com wrote:
While attempting to build an indirect CRL signing role, I managed to
come up with a way to revoke a certificate but allow it to pass the
CRL checks of the verify utility. I'm not yet sure if this is a bug
or if the chain I created is
On Fri Aug 02 10:23:05 2013, martin.pe...@nsn.com wrote:
- the code in crypto/cmp also includes the functionality to perform the
most important cmp message sequences via HTTP. This code depends on
libcurl, so it is split into its own library (libcrypto_cmpseq.a) in
order to help deal with the
On Tue Aug 06 10:05:56 2013, pi...@cloudflare.com wrote:
While it cannot be enabled via ./config options,
Why not? The standard way to include such options is via config or Configure
and some platforms (e.g. Windows) require this.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
On Fri Aug 02 10:23:23 2013, j...@jimkeener.com wrote:
With -verify and -Verify I believe that the server should reject the
connection if the certificate isn't signed by a valid CA. Is there a way
to emulate such behaviour, or is there a reason that this behaves in
such a manner?
The
On Tue Aug 20 09:00:56 2013, shay.gue...@intel.com wrote:
OpenSSL’s DH implementation uses an unnecessarily long exponent,
leading to significant performance loss
OpenSSL handles the Diffie Hellman (DH) protocol in a very
conservative way. By default, the length of the private key equals
On Sat Aug 24 21:16:05 2013, beld...@gmail.com wrote:
Greetings!
We have found an inconsistent behaviour of the openssl engine command. The
problem appeared in version 1.0.1d in case openssl is built with
--enable-shared.
1. When the config file does not mention the gost engine, the command
On Thu Sep 05 20:04:30 2013, kde...@vogtner.de wrote:
OS: various Linuxes
Version affected: 1.0.1e
unaffected: 1.0.0h, 0.9.8y
openssl s_client -connect 193.142.53.22:25 -starttls smtp -state
Well what is happening is that OpenSSL 1.0.1 and later client indicates support
for TLS v1.2 and
On Wed Sep 11 17:52:03 2013, deeng...@anl.gov wrote:
Attached is a patch to move the definition of ecdsa_method
from src/crypto/ecdsa/ecs_locl.h to ecdsa.h
and move the definition if ecdh_method
from src/crypto/ecdh/ech_locl.h to ecdh.h
It's been policy that we should avoiding direct
On Wed Oct 23 08:59:59 2013, mco...@akamai.com wrote:
*
Issue:*
The fips module has a bug that can result in segfaults when
fips_get_entropy() fails during initialization of openssl-linked-with-fips.
What version of OpenSSL are you using? This was worked around in 1.0.1e due to
the
On Wed Oct 23 21:06:00 2013, mco...@akamai.com wrote:
For my curiosity, what's difficult about modifying FIPS? More involved
change-vetting process?
Any change has to be approved as part of a change letter process with labs
which takes time and costs real money. We normally try to include any
On Fri Aug 02 10:23:33 2013, pi...@cloudflare.com wrote:
Hello,
attached patch fixes the issue with dropped support for EC cipher
suites in software that uses SSL_OP_SINGLE_ECDH_USE after upgrading to
OpenSSL-1.0.2+.
Fixed now, thanks for the report.
Steve.
--
Dr Stephen N. Henson. OpenSSL
On Thu Mar 29 21:17:31 2012, steve wrote:
A temporary workaround for this is to apply these two patches to OpenSSL
1.0.1:
http://cvs.openssl.org/chngview?cn=22286
http://cvs.openssl.org/chngview?cn=22306
And recompile OpenSSL with -DOPENSSL_NO_TLS1_2_CLIENT (e.g. supplied as
a command line
On Sun Nov 24 22:00:30 2013, noloa...@gmail.com wrote:
ssl_prepare_clienthello_tlsext has the following in t1_lib.c around
line 1690.
pref_list[] is hard coded and includes some weaker curves. For
example, pref_list[] include NID_secp160r2, which offers 80-bits of
security.
It would be
On Tue Nov 26 22:30:34 2013, cosborn...@hotmail.com wrote:
I've noticed what appears to be a bug in the 586 assembly-optimized
AES_cbc_encrypt function of OpenSSL 1.0.1e, (compiled on Windows)
when encrypting data that is 1 block in length, but not an
integral multiple of the block size.
Well
On Tue Dec 03 21:35:13 2013, afels...@cisco.com wrote:
However, I'm uncertain as to how appropriate is this use
of GENERAL_NAME_print(). Is the intent of this function to be used
for purposes like this, or is it intended more for human-readable
output, or something else entirely?
The outputs
On Sat Dec 14 08:41:53 2013, rbar...@yahoo-inc.com wrote:
We are seeing a segfault when TLS 1.2 is enabled with OpenSSL 1.0.1e (also
with 1.0.1a). We are running Apache Traffic Server on RHEL6 and when we
upgraded OpenSSL from 1.0.0 to 1.0.1 we started seeing this issue. I was
able to narrow
On Mon Dec 16 22:20:47 2013, rbar...@yahoo-inc.com wrote:
Thank you Steve. Not sure how to proceed from here, is there more
information from the core dumps which would be useful?
Yes, please print out the entire s-s3-handshake_dgst array instead of just
the first element. That is:
On Sat Dec 14 08:42:01 2013, misaki.miyash...@oracle.com wrote:
The Segmentation Fault occurred when EVP_MD_CTX_copy() failed in
tls1_mac().
tls1_mac() doesn't check the return code of EVP_MD_CTX_copy() and keep
going, which results in Segmentation Fault at EVP_DigestUpdate().
The following
I've added some error and sanity checking to the relevant piece of code.
OpenSSL *should* just end up reporting an internal error now if that happens
instead of crashing. If you end up with lots of those then it may need further
investigation.
The new code is here:
On Wed, Dec 18, 2013, Ron Barber via RT wrote:
Thanks Steve. After applying the patch and letting it run in production
for approx. 5 hours I did not see any crashes. The only suspicious (i.e.
Change in behavior from previous) looking error message was two of these:
[Dec 18 15:27:51.789]
On Sun Sep 15 14:53:12 2013, dmy...@frankopak.com wrote:
I have discussed this situation with some Squid developers and we
decided - after SSL error 1408F10B calling standard/raw read()
instead of SSL_read() for empty socket buffer and this patch
stopped crash Squid.
In general you can't
On Fri Dec 20 18:37:18 2013, d...@fifthhorseman.net wrote:
I posted a series of 10 changesets to openssl-dev which standardizes
OpenSSL's input, API, and output on the standard names (DHE and ECDHE)
while retaining backward compatibility for string input and API for
the
older EDH and EECDH
On Fri Dec 20 19:04:32 2013, d...@fifthhorseman.net wrote:
I can do whatever you think is most useful, but i need a bit more
guidance to be sure i'm giving you what will be most useful for you.
I've pulled the update now, thanks.
Well I have to admit to being far from a git expert. For me
btw, since you only raise concerns about the string value returned for
the ciphersuites, It sounds like you're OK with the change to the
packet
tracing output -- i didn't think that the packet tracing would be
contentious, but just want to make sure that change is on your radar
too. Should
On Mon Dec 30 22:47:32 2013, d...@fifthhorseman.net wrote:
I don't mean to be impatient -- if it's just a matter of playing catchup
over the close of the winter holiday, i can wait :)
Yes that's pretty much it. I'll be looking reviewing the patches in the next
few days.
Steve.
--
Dr Stephen
501 - 600 of 926 matches
Mail list logo
