We have a multi-threaded network application that has been using sockets
for 10 years and now we're trying to secure the application with OpenSSL
0.9.8L. Over the years, the application's network protocols have been
designed to take advantage of the duplex nature of a single socket
Reading (writing) over an SSL connection may result in the transport writing
(reading).
Concurrent use of the same SSL structure will cause things to break.
/r$
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
We have a multi-threaded network application that has been using sockets
for 10 years and now we're trying to secure the application with OpenSSL
0.9.8L. Over the years, the application's network protocols have been
designed to take advantage of the duplex nature of a single socket
On Mon, Apr 30, 2012, Welling, Conrad Gerhart wrote:
>
>
> Our client application uses cURL-7.19.7 + openssl-0.9.8l to transfer
> text files via HTTPS, using server-only authentication. The only call
> the cURL source makes to an openssl d2i_*_bio() or d2i_*_fp() function
>
Our client application uses cURL-7.19.7 + openssl-0.9.8l to transfer
text files via HTTPS, using server-only authentication. The only call
the cURL source makes to an openssl d2i_*_bio() or d2i_*_fp() function
is d2i_PKCS12_fp(). Unfortunately, it is not absolutely clear - yet -
that a PKCS
6068946
error:14080152:SSL routines:SSL3_ACCEPT:unsafe legacy renegotiation disabled
In my investigation, similar error occuers with OpenSSL 0.9.8l, 0.9.8m,
0.9.8n and 1.0.0.
I know this is concerned about security issue CVE-2009-3555, but many
browsers fails to connect the server.
I know only Firefo
Hi,
Wanted a clarification on OpenSSL 0.9.8l ( CVE-2009-3555 - TLS / SSLv3
Renegotiating vulnerability) . When I execute the following
./openssl s_client -connect www.testapp.com:8090
--- [snipped... openssl output]
HEAD / HTTP/1.0
R
RENEGOTIATING
The below output is shown
HTTP/1.1
> Should the caller specify an empty ivec (to the correct length) in this case
> or am I missing something?
I think so too.
If you always initialise the IVEC to NUL bytes,
and use the same key to encrypt lots of small packets,
it becomes easier to crack the key.
If you use some variable data tha
Hello,
Looking at test/evp_test.c and the test data test/evptests.txt for
encryption/decryption, I don't understand how the initialisation vector
('iv' variable) is used.
The test data in evptests.txt is expressed as Hex strings which are then
translated to bit patterns before use:
cipher:
Marc
- Original Message -
From: "Jeremy Farrell"
To:
Sent: Tuesday, November 17, 2009 5:20 AM
Subject: RE: Cygwin - OpenSSL 0.9.8l linker errors
@$(CC) $(LDFLAGS) $(LIBS) $(OBJ) -o $(BIN)
needs to be
@$(CC) $(LDFLAGS) $(OBJ) $(LIBS) -o $(BIN)
-Original Message-
From: o
Jeremy Farrell wrote:
@$(CC) $(LDFLAGS) $(LIBS) $(OBJ) -o $(BIN)
needs to be
@$(CC) $(LDFLAGS) $(OBJ) $(LIBS) -o $(BIN)
forget to include needed information.
The order of the libs may need to be reversed also
LIBS = -lssl -lcrypto
__
gt; To: openssl-users@openssl.org
> Subject: Cygwin - OpenSSL 0.9.8l linker errors
>
> Hi,
>
> I am trying to add OpenSSL to my project but fail linking
> OpenSSL to it on
> Cygwin.
>
> I always get the following error messages where zOpenSSL is
> my test project:
I am trying to get the source compiled with OpenSSL version
0.9.8l-2 (the one which is automatically installed via cygwin setup) but I
also tried to compile openssl-0.9.8l and openssl-1.0.0-beta4 myself.
Everything is compiling correctly, make install is working fine but
compiling my project still
Hi all,
Just wondering if there is any plan to release OpenSSL 0.9.8l ?
If so, do we know when?
I'd like to stay with the 0.9.8 branch, but I do see some fixes double
committed from the 1.0.0 branch.
Thanks,
Alex.
14 matches
Mail list logo