On 9/18/2013 11:23 AM, Stephen Henson via RT wrote:
> Is this the session ticket or the session ID causing the problem? A server
> shouldn't just disconnect if it sees a ticket it doesn't like it should just
> issue a new one.
Presumably it is the session ticket. I haven't yet captured such a
pois
My proposed fix does not work. It isn't legitimate to just remove the
session.
An updated proposed fix is attached.
diff -ru ../openssl-1.0.1e-orig/apps/s_client.c ./apps/s_client.c
--- ../openssl-1.0.1e-orig/apps/s_client.c 2013-02-11 07:26:04.0
-0800
+++ ./apps/s_client.c 2013
Openssl 1.0.1e is not clearing the session ticket upon handshake
failure, contrary to the recommendation in RFC 5077 section 3.2 paragraph 4.
I am seeing that after some sort of event, Amazon ELB will respond to a
TLS 1.0 handshake containing a session ticket that it had handed out
prior to the
In openssl 1.0.1c, the doc/crypto/threads.pod documentatin gives the
wrong signature for CRYPTO_set_dynlock_create_callback().
It documents:
void CRYPTO_set_dynlock_create_callback(struct CRYPTO_dynlock_value *
(*dyn_create_function)(char *file, int line));
It should be:
void CRYPTO_
On 4/25/2012 1:21 AM, Darryl Miles via RT wrote:
> John Gardiner Myers via RT wrote:
>> There's no good reason for SSL_shutdown() to ever return a value of 0.
>> The attached patch simplifies things.
> One point of view is:
>
> Maybe so. But this is how it has alway
There's no good reason for SSL_shutdown() to ever return a value of 0.
The attached patch simplifies things.
--- openssl-1.0.1-beta3-0orig/ssl/s3_lib.c 2012-02-10 12:08:49.0
-0800
+++ openssl-1.0.1-beta3/ssl/s3_lib.c2012-03-02 11:19:53.847954000 -0800
@@ -4112,7 +4112,7 @@
While having SSL_want_read() and SSL_want_write() return nonzero after a
permanent error is a poor interface, the documentation does state that
it is necessary to check the return of SSL_get_error().
So this ticket can be closed out as invalid.
_
ssl3_shutdown() incorrectly indicates SSL_want_read() or
SSL_want_write() when the underlying read/write results in a permanent
error. This means that callers of nonblocking SSL_shutdown() will go
into an infinite loop retrying the shutdown.
This bug appears in both OpenSSL 0.9.8t and 1.0.1-bet
openssl s_client -starttls smtp -reconnect
doesn't work, because it doesn't do the starttls protocol work after
reconnecting. Fix:
[EMAIL PROTECTED] openssl-0.9.8i]$ diff -ru apps/s_client.c~ apps/s_client.c
--- apps/s_client.c~2008-06-04 13:11:17.0 -0700
+++ apps/s_client.c 200
What is the status of this request? What needs to be done in order for
somebody to check in code?
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL P
If you want to address incorrect cookbooks, you could error out on zero
or you could replace zero with the current time. Or you could pester
the cookbook authors. I'm not sure a warning would help much.
In any case, it would be nice if someone could check in the patches so far.
_
Stephen Henson via RT wrote:
>One would be the perl front end CA.pl
>
Patch attached
>Another would be if non-standard scripts initialize the serial number
>file either for 'ca' or the 'x509' utility.
>
>
My original patch fixed the -CAcreateserial switch. Not much we can do
about scripts no
Stephen Henson via RT wrote:
> I'm not sure how portable that patch is as it stands.
What would be the portability problem? The code is already calling
time() in order to calculate the expiration dates.
>As a portable alternative we could use a large random number for the
>serial number, for
The attached patch causes serial numbers to default to the current time,
significantly reducing the chance of duplicate serial numbers from a
given issuer. I have filed the necessary TSA notification.
Mozilla gets a constant stream of problem reports caused by
OpenSSL-generated certs with dup
14 matches
Mail list logo
