In order to fix the Poodle vulnerability on SSLv3, I tried to disable my
SSLv3 cipher using the below cipher set, but did not even initiate SSL in
0.9.8a.
If you are running 0.9.8a Poodle is probably the least of your worries.
Looking at https://www.openssl.org/news/openssl-0.9.8-notes.html
Looking at just OPENSSL_NO_xxx, we have over 100 openssl #ifdef options and we
are considering removing nearly a third of them. Please reply soon if the
following plan would cause problems. This will happen only in master, for
post-1.0.2.
We will remove the following options. You could argue
Hello All,
I work with Apache Traffic Server. Many of our users use the SNI
callback to select the certificate that the proxy will present to the
client. This selection can take some time. Rather than blocking the
callback thread, we would like to pause the negotiation from the SNI
On Fri 2015-01-23 16:04:15 -0500, Steffen Nurpmeso wrote:
Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
|On Fri 2015-01-23 06:19:14 -0500, Steffen Nurpmeso wrote:
| brings. (Myself even starves for documentation [coverage]
| improvements.)
|
|fwiw, OpenSSL documentation is pretty
The only one of all those that matters (to me) is OPENSSL_NO_SSL_INTERN since
that provides a way to anticipate the effects of this API change. I'm fine
with it going, but it needs a specified replacement (even if the replacement
is we'll do that by default). Currently for example Qt won't
On Fri, Jan 23, 2015 at 09:57:27PM +, Salz, Rich wrote:
I hadn't thought of it as being a preview for what we plan to
do. I guess it makes sense to keep it, at least until we have a
preview of some kind that lets folks start building in the New
World Order.
I've used it to future-proof
On 1/23/2015 5:16 PM, Dr. Stephen Henson wrote:
On Fri, Jan 23, 2015, Susan Hinrichs wrote:
Hello All,
I work with Apache Traffic Server. Many of our users use the SNI
callback to select the certificate that the proxy will present to
the client. This selection can take some time. Rather
On 22/01/15 22:34, Steffen Nurpmeso wrote:
Since noone else seems to say a word.
I personally didn't understand at all why v1.0.2 when its
end-of-life is in sight already.
From my personal point of view I would like all our releases to have
defined up front lifetimes, so that it is clear how
Hello,
Thanks for OpenSSL first.
And again when you can read this.
Matt Caswell m...@openssl.org wrote:
|On 22/01/15 22:34, Steffen Nurpmeso wrote:
| Since noone else seems to say a word.
| I personally didn't understand at all why v1.0.2 when its
| end-of-life is in sight already.
|
|From
Hi,
I tried to comment on the ticket via rt, but apparently there's more
to it than just sending it to r...@openssl.org using a magic subject line
(or maybe it doesn't like subject: being replaced by the localized
Betreff: as the webmail-frontend I'm using apparently does?
Anyway, let
On Fri 2015-01-23 06:19:14 -0500, Steffen Nurpmeso wrote:
And i think we are all looking forward to see what the future
brings. (Myself even starves for documentation [coverage]
improvements.)
fwiw, OpenSSL documentation is pretty easy to read and to edit. If you
notice that things are
Team,
In order to fix the Poodle vulnerability on SSLv3, I tried to disable my SSLv3
cipher using the below cipher set, but did not even initiate SSL in 0.9.8a.
SSL_CTX_set_cipher_list(ssl_ctx,SHA1+HIGH:!SSLv2:!SSLv3:!aNULL:!eNULL:@STRENGTH);
Without !SSLv3 - by SSL connection is working fine
In order to fix the Poodle vulnerability on SSLv3, I tried to disable my
SSLv3 cipher using the below cipher set, but did not even initiate SSL in
0.9.8a.
If you are running 0.9.8a Poodle is probably the least of your worries.
Looking at https://www.openssl.org/news/openssl-0.9.8-notes.html
On Fri, Jan 23, 2015, Thirumal, Karthikeyan wrote:
Team,
In order to fix the Poodle vulnerability on SSLv3, I tried to disable my
SSLv3 cipher using the below cipher set, but did not even initiate SSL in
0.9.8a.
Looking at just OPENSSL_NO_xxx, we have over 100 openssl #ifdef options and we
are considering removing nearly a third of them. Please reply soon if the
following plan would cause problems. This will happen only in master, for
post-1.0.2.
We will remove the following options. You could argue
On Jan 23 19:11, Salz, Rich wrote:
Looking at just OPENSSL_NO_xxx, we have over 100 openssl #ifdef options and
we are considering removing nearly a third of them. Please reply soon if the
following plan would cause problems. This will happen only in master, for
post-1.0.2.
We will remove
For those of the flags controlling OS capabilities, it would be nice to have a
brief description so the OS-specific maintainers can check removing some of
them might be a problem.
I don't think I understand what you mean, but the only OS related one is
NO_BUF_FREELISTS, which has openssl
On Jan 23 20:27, Salz, Rich wrote:
For those of the flags controlling OS capabilities, it would be nice to
have a
brief description so the OS-specific maintainers can check removing some of
^^^
The only one of all those that matters (to me) is OPENSSL_NO_SSL_INTERN
since that provides a way to anticipate the effects of this API change. I'm
fine with it going, but it needs a specified replacement (even if the
replacement is we'll do that by default). Currently for example Qt won't
build
On Fri 2015-01-23 16:04:15 -0500, Steffen Nurpmeso wrote:
Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
|On Fri 2015-01-23 06:19:14 -0500, Steffen Nurpmeso wrote:
| brings. (Myself even starves for documentation [coverage]
| improvements.)
|
|fwiw, OpenSSL documentation is pretty
The only one of all those that matters (to me) is OPENSSL_NO_SSL_INTERN since
that provides a way to anticipate the effects of this API change. I'm fine
with it going, but it needs a specified replacement (even if the replacement
is we'll do that by default). Currently for example Qt won't
Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
|On Fri 2015-01-23 06:19:14 -0500, Steffen Nurpmeso wrote:
| brings. (Myself even starves for documentation [coverage]
| improvements.)
|
|fwiw, OpenSSL documentation is pretty easy to read and to edit. If you
|notice that things are
Hello All,
I work with Apache Traffic Server. Many of our users use the SNI
callback to select the certificate that the proxy will present to the
client. This selection can take some time. Rather than blocking the
callback thread, we would like to pause the negotiation from the SNI
On Fri, Jan 23, 2015 at 09:57:27PM +, Salz, Rich wrote:
I hadn't thought of it as being a preview for what we plan to
do. I guess it makes sense to keep it, at least until we have a
preview of some kind that lets folks start building in the New
World Order.
I've used it to future-proof
On Fri, Jan 23, 2015, Susan Hinrichs wrote:
Hello All,
I work with Apache Traffic Server. Many of our users use the SNI
callback to select the certificate that the proxy will present to
the client. This selection can take some time. Rather than
blocking the callback thread, we would
On 23/01/15 15:30, Daniel Kahn Gillmor wrote:
On Fri 2015-01-23 06:19:14 -0500, Steffen Nurpmeso wrote:
And i think we are all looking forward to see what the future
brings. (Myself even starves for documentation [coverage]
improvements.)
fwiw, OpenSSL documentation is pretty easy to
On 1/23/2015 5:16 PM, Dr. Stephen Henson wrote:
On Fri, Jan 23, 2015, Susan Hinrichs wrote:
Hello All,
I work with Apache Traffic Server. Many of our users use the SNI
callback to select the certificate that the proxy will present to
the client. This selection can take some time. Rather
27 matches
Mail list logo
