Hi,
Trying to use the 'SRP' code, I found two kinds of memory leaks in srp_vfy.c
.
1) The first kind was due to bad use of OpenSSL 'stack' code and cumbersome
/ confusing names of structure / functions.
In this case, leaks occurs when loading a verifier file containing 'index'
lines.
Hi,
When configured with the no-engine option, compilation fails (OpenSSL
1.0.2a, Windows 7 64).
This patch moves up some #include directives (as suggested by other people
on the InterNet).
engines.patch
Description: Binary data
___
openssl-dev
Hi,
When configured with the no-nextproto option, compilation fails (OpenSSL
1.0.2a, Windows 7 64).
This patch just add a #ifdef directive around targeted line.
Regards,
Michel.
no-nextproto.patch
Description: Binary data
___
openssl-dev
pkeyutl requires a certain order of the key options to work:
-pkeyopt must follow the -inkey option
-passin must precede the -inkey option
This is not documented and confusing.
It would be better if the order was ignored.
OpenSSL 1.0.2a
___
This is a very valid security concern. The reason the private key shouldn't be
on the same machine is that the Web server is installed on the client's machine
(for various reasons). This means for security reasons the private key
shouldn't be located on the client's (untrusted) machine. So one
I'm facing a crash (heap corruption) on Windows ever since I updated
OpenSSL to the version 1.0.2a. The same seems to happen in 1.0.1m.
I'm using Visual Studio 2013. I'm building the x64-static variant of
OpenSSL like so:
perl Configure VC-WIN64A no-asm
Hi,
openSSL version: 1.0.1l
openSUSE-release 13.1-1.10
This problem only show for s23_clnt.c module. The flow is correct for
s3_clnt.c module.
If the TLS client starts a client hello, with tls1.1 for example and the
server only supports tls1.0, if the TLS client receives a protocol version
from
We've found a way to recreate the scenario using s_client/s_server. We're
using the -no_ticket option on the server. Therefore, the ServerHello doesn't
contain the session ticket extension. It also doesn't send the
NewSessionTicket message.
To summarize the problem, when the client side
On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) fol...@cisco.com
wrote:
We've found a way to recreate the scenario using s_client/s_server. We're
using the -no_ticket option on the server. Therefore, the ServerHello
doesn't contain the session ticket extension. It also doesn't send the
