RE: [LibReSSL] Allow key generation to use arbitrary public exponents
From: owner-openssl-...@openssl.org On Behalf Of Benny Baumann Sent: Sunday, August 10, 2014 08:44 Am 09.08.2014 19:24, schrieb Annie Yousar: Hi Ben, you can generate keys with arbitrary exponents using the genpkey command: openssl genpkey -algorithm rsa \ -pkeyopt rsa_keygen_bits:16384 -pkeyopt rsa_keygen_pubexp:4711 Thanks for this information. Now that you mention this: I read about it in the documentation. But unfortunately genpkey and genrsa produce slightly different output (plain RSA key vs. publicKeyInfo) - thus having such a -pkeyopt like interface available uniformly for genrsa, gendsa and ec might be useful. You can pipe genpkey alg=rsa through rsa to convert to the bare form. gendsa or genpkey alg=dsa is only a random choice with no options. Same for ecparam -genkey or genpkey alg=ec, and genpkey alg=dh. *dsaparam* or genpkey-genparam alg=dsa could in principle allow selection of the subgroup size, but for 2 prime sizes the standard allows only one choice, and for the 3rd prime size the standard allows only two choices. That hardly seems worth the bother. genpkey-genparam alg=dh vs dhparam is the only other interesting case. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3490] bug report: SRP still broken in 1.0.1 snapshot
The first chunk in the s3_lib.c patch doesn't apply. But the second
chunk does (shown below). When applying this to 1.0.1 stable, it
appears to resolve the problem.
@@ -4357,8 +4359,13 @@ SSL_CIPHER *ssl3_choose_cipher(SSL *s,
STACK_OF(SSL_CIPHER) *clnt,
emask_k = cert-export_mask_k;
emask_a = cert-export_mask_a;
#ifndef OPENSSL_NO_SRP
- mask_k=cert-mask_k | s-srp_ctx.srp_Mask;
- emask_k=cert-export_mask_k | s-srp_ctx.srp_Mask;
+ if (s-srp_ctx.srp_Mask SSL_kSRP)
+ {
+ mask_k |= SSL_kSRP;
+ emask_k |= SSL_kSRP;
+ mask_a |= SSL_aSRP;
+ emask_a |= SSL_aSRP;
+ }
#endif
#ifdef KSSL_DEBUG
On 08/12/2014 01:43 PM, Kurt Roeckx via RT wrote:
On Tue, Aug 12, 2014 at 01:26:30AM +0200, John Foley via RT wrote:
The commit into 1.0.1 didn't include the changes to s3_lib.c. SRP is still
broken on this branch. Are there any plans to fix this?
Can you confirm that that commit from master fixes things for you?
On Aug 11, 2014, at 6:41 PM, Kurt Roeckx via RT r...@openssl.org wrote:
On Mon, Aug 11, 2014 at 11:09:51PM +0200, John Foley via RT wrote:
The fix discussed in this thread appears to be incomplete:
http://marc.info/?l=openssl-usersm=140752401023837w=2
This fix works for SRP cipher suites that uses RSA for DSA, which
includes 6 of the 9 supported SRP cipher suites. But the three SRP
cipher suites that don't rely on a server-side certificate are still
broken. This problem can be recreated using these commands:
I believe this is already in master in commit
9e72d496d4f9880ec98f0ed9168246e35c1c3059
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Openssl 1.0.1h | RHEL-6 | x86_64 | Crash in lh_retrieve
Thanks Stephen. Removing it seems to have solved the issue. It appears that a patch which ignored multiple call to add digests have been reverted back in some 0.9.8x version. -Arun On Thu, Aug 7, 2014 at 5:00 PM, Arun Muralidharan arun11...@gmail.com wrote: hmm...Will update you on this once I get it tested with the latest build. Thanks again. -Arun On Thu, Aug 7, 2014 at 4:49 PM, Dr. Stephen Henson st...@openssl.org wrote: On Thu, Aug 07, 2014, Arun Muralidharan wrote: Thanks Stephen for your reply. I am doing OpenSSL_add_all_digests in one of my class initialization routine, so it gets called whenever an instance of this class gets created (I am now building my code with this removed). But I am not removing digests/algorithm as you mention, I am just adding them. Can it still be the reason for this race ? It could be yes. The algorithm tables should be initialised when the application starts up. If they could be modified when other threads are attempting to read from the tables that could result in the problem you are seeing. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
nameConstraints : leading . in permission list items
Hi Folks --
0) Beware that I am not an expert in this area. What follows is
probably mostly true, but I'm still feeling my way to some extent.
1) There are actually some people who are using v3 nameConstraints.
Not a lot, but some.
An example can be found in one of the fully-trusted root certificates
that is distributed in the current Ubuntu release, and several previous
releases:
/etc/ssl/certs/Hellenic_Academic_and_Research_Institutions_RootCA_2011.pem
which is a symlink to
/usr/share/ca-certificates/mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt
Let's take a look at it:
openssl x509 -text -noout
Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt
[snip]
X509v3 Name Constraints:
Permitted:
DNS:.gr
DNS:.eu
DNS:.edu
DNS:.org
email:.gr
email:.eu
email:.edu
email:.org
2) Note the leading . in each item in the permission list.
a) This seems entirely logical and reasonable to me.
b) All the documentation and examples I've seen on the web assume
the . should be there. It's not even a topic of discussion.
3) Desired behavior: openssl should tolerate the leading .
Question: Does anybody think the leading . should be mandatory?
Or should we tolerate it either way
4) Observed behavior: As of openssl-1.0.1i the leading . is
not tolerated. In particular:
openssl verify -verbose -check_ss_sig -CAfile $CA_NAME-cert.pem
$TARGET-cert.pem
server.example.net-cert.pem: C = US, CN = server.example.net
error 47 at 0 depth lookup:permitted subtree violation
In more detail: I added some debugging printf statements:
checking DNS 'www.example.net' against '.example.net' ... result: 47
checking DNS 'www.example.net' against 'example.net' ... result: 0
The certs I used to test this can be found at
http://www.av8n.com/openssl/namecon-ca-cert.pem
http://www.av8n.com/openssl/server.example.net-cert.pem
If somebody wants the ugly little config files I used to create those
certs, they can be provided.
5) Here is a patch that seems to make the problem go away.
http://www.av8n.com/openssl/leading-dot.patch
I do not guarantee that this is high-security industrial-strength code,
but it should suffice to let people know where I think the issue lies.
If somebody wants to take a closer look at what the code is doing,
here is a bundle of debugging printf statements:
http://www.av8n.com/openssl/namecon-printf.patch
This is not meant to be elegant.
It's quick-and-dirty experimentation.
I found it useful. YMMV.
---
Let's discuss this on the -dev list for a little while to see if anybody
has any better insight as to what's going on. Then maybe we can send it
over to the request tracker.
There's more I could say about this, but I'll stop here for now.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: nameConstraints : leading . in permission list items
Hey John et al, If you could also take a look at https://github.com/openssl/openssl/pull/111 we have listed a number of reasons. What are your thoughts on this? Regards, Vyronas Tsingaras On 13/08/2014 11:57 πμ, John Denker wrote: Hi Folks -- 0) Beware that I am not an expert in this area. What follows is probably mostly true, but I'm still feeling my way to some extent. 1) There are actually some people who are using v3 nameConstraints. Not a lot, but some. An example can be found in one of the fully-trusted root certificates that is distributed in the current Ubuntu release, and several previous releases: /etc/ssl/certs/Hellenic_Academic_and_Research_Institutions_RootCA_2011.pem which is a symlink to /usr/share/ca-certificates/mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt Let's take a look at it: openssl x509 -text -noout Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt [snip] X509v3 Name Constraints: Permitted: DNS:.gr DNS:.eu DNS:.edu DNS:.org email:.gr email:.eu email:.edu email:.org 2) Note the leading . in each item in the permission list. a) This seems entirely logical and reasonable to me. b) All the documentation and examples I've seen on the web assume the . should be there. It's not even a topic of discussion. 3) Desired behavior: openssl should tolerate the leading . Question: Does anybody think the leading . should be mandatory? Or should we tolerate it either way 4) Observed behavior: As of openssl-1.0.1i the leading . is not tolerated. In particular: openssl verify -verbose -check_ss_sig -CAfile $CA_NAME-cert.pem $TARGET-cert.pem server.example.net-cert.pem: C = US, CN = server.example.net error 47 at 0 depth lookup:permitted subtree violation In more detail: I added some debugging printf statements: checking DNS 'www.example.net' against '.example.net' ... result: 47 checking DNS 'www.example.net' against 'example.net' ... result: 0 The certs I used to test this can be found at http://www.av8n.com/openssl/namecon-ca-cert.pem http://www.av8n.com/openssl/server.example.net-cert.pem If somebody wants the ugly little config files I used to create those certs, they can be provided. 5) Here is a patch that seems to make the problem go away. http://www.av8n.com/openssl/leading-dot.patch I do not guarantee that this is high-security industrial-strength code, but it should suffice to let people know where I think the issue lies. If somebody wants to take a closer look at what the code is doing, here is a bundle of debugging printf statements: http://www.av8n.com/openssl/namecon-printf.patch This is not meant to be elegant. It's quick-and-dirty experimentation. I found it useful. YMMV. --- Let's discuss this on the -dev list for a little while to see if anybody has any better insight as to what's going on. Then maybe we can send it over to the request tracker. There's more I could say about this, but I'll stop here for now. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3481] Add space to help compiler/analyzer parse token
We plan on adopting a coding style and it will address this. The style is most likely to say put spaces around operators. I'm marking this as reject (not resolve) because we're not gonna do this one-of fix. But a more comprehensive, better, answer is coming. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2342] CHM version of openssl doc
No current plans to generate CHM file from the openssl manpages. If someone can point to a good perl script we could use, we can re-open this. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2931] Bad output of -purpose with the x509 command
Yes, the fact that the any purpose OID is present means that applications may use the cert/keypair for anything. Not that you are asking to show the purpose field, which doesn't actually contradict the RFC. It says, at the bottom of page 44, Certificate using applications MAY require that the extended key usage extension be present and that a particular purpose be indicated in order for the certificate to be acceptable to that application. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1734] Enhancement Request: for dsaparam to have 2 number inputs for p and q. Tested version of openssl 0.9.8g
Perhaps I misunderstand, but... dsaparam lets you specify the number of bits. From that it calculates the q value compatible with the table you posted. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Question in regards to early warning about new openssl versions
Dear OpenSSL-Team, First of all, thank you for your great work! I hope openssl-dev is the right list for the following request: Many projects rely on OpenSSL of course and whenever a new version is published fixing security issues, it is more or less a surprise to many. After the disclosure everyone tries to have their developers jump on integrating the fixes as soon as possible, but this may take some time to allocate and coordinate resources, increasing the time to a fixed version. So my question is - would it be reasonable to send an early warning (without any details) to one of the OpenSSL lists a few days before publishing a version containing fixes for security vulnerabilities? Just saying something along the lines of we plan to release a new openssl version containing security fixes in about 2 days. Something like this would help people to already be alarmed and start preparing resources (if they like to). I think this would help decreasing the time from the actual disclosure at openssl to fixed version of the respective project. Thanks and Best Regards, Henning __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: Question in regards to early warning about new openssl versions
Thanks for your kind words. We do post a notice that we're putting out a security update. Not sure how you missed it... -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Question in regards to early warning about new openssl versions
On Wed, Aug 13, 2014 at 01:12:12PM -0400, Henning Horst wrote: Dear OpenSSL-Team, First of all, thank you for your great work! I hope openssl-dev is the right list for the following request: Many projects rely on OpenSSL of course and whenever a new version is published fixing security issues, it is more or less a surprise to many. After the disclosure everyone tries to have their developers jump on integrating the fixes as soon as possible, but this may take some time to allocate and coordinate resources, increasing the time to a fixed version. So my question is - would it be reasonable to send an early warning (without any details) to one of the OpenSSL lists a few days before publishing a version containing fixes for security vulnerabilities? Just saying something along the lines of we plan to release a new openssl version containing security fixes in about 2 days. Something like this would help people to already be alarmed and start preparing resources (if they like to). I think this would help decreasing the time from the actual disclosure at openssl to fixed version of the respective project. We did that with the last release. It was mailed to -dev, -user and -announce list. It was announced the 3rd that we'd be releasing a new update the 6th. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3490] bug report: SRP still broken in 1.0.1 snapshot
On Tue, Aug 12, 2014 at 08:36:06PM +0200, Kurt Roeckx wrote:
On Tue, Aug 12, 2014 at 08:22:38PM +0200, John Foley via RT wrote:
The first chunk in the s3_lib.c patch doesn't apply. But the second
chunk does (shown below). When applying this to 1.0.1 stable, it
appears to resolve the problem.
@@ -4357,8 +4359,13 @@ SSL_CIPHER *ssl3_choose_cipher(SSL *s,
STACK_OF(SSL_CIPHER) *clnt,
emask_k = cert-export_mask_k;
emask_a = cert-export_mask_a;
#ifndef OPENSSL_NO_SRP
- mask_k=cert-mask_k | s-srp_ctx.srp_Mask;
- emask_k=cert-export_mask_k | s-srp_ctx.srp_Mask;
+ if (s-srp_ctx.srp_Mask SSL_kSRP)
+ {
+ mask_k |= SSL_kSRP;
+ emask_k |= SSL_kSRP;
+ mask_a |= SSL_aSRP;
+ emask_a |= SSL_aSRP;
+ }
#endif
#ifdef KSSL_DEBUG
I assumed you were talking about the 1.0.1i release and not the
current git. When the mentioned commit got merged into the 1.0.1
branch the above part was somehow lost. It should get added to
the 1.0.1 branch soon.
So this got fixed in commit
03ebf85f7757c5da9f9d4fecb8ea1a1af18df46d, closing the ticket.
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3490] bug report: SRP still broken in 1.0.1 snapshot
Thank you.
On 08/13/2014 01:39 PM, Kurt Roeckx via RT wrote:
On Tue, Aug 12, 2014 at 08:36:06PM +0200, Kurt Roeckx wrote:
On Tue, Aug 12, 2014 at 08:22:38PM +0200, John Foley via RT wrote:
The first chunk in the s3_lib.c patch doesn't apply. But the second
chunk does (shown below). When applying this to 1.0.1 stable, it
appears to resolve the problem.
@@ -4357,8 +4359,13 @@ SSL_CIPHER *ssl3_choose_cipher(SSL *s,
STACK_OF(SSL_CIPHER) *clnt,
emask_k = cert-export_mask_k;
emask_a = cert-export_mask_a;
#ifndef OPENSSL_NO_SRP
- mask_k=cert-mask_k | s-srp_ctx.srp_Mask;
- emask_k=cert-export_mask_k | s-srp_ctx.srp_Mask;
+ if (s-srp_ctx.srp_Mask SSL_kSRP)
+ {
+ mask_k |= SSL_kSRP;
+ emask_k |= SSL_kSRP;
+ mask_a |= SSL_aSRP;
+ emask_a |= SSL_aSRP;
+ }
#endif
#ifdef KSSL_DEBUG
I assumed you were talking about the 1.0.1i release and not the
current git. When the mentioned commit got merged into the 1.0.1
branch the above part was somehow lost. It should get added to
the 1.0.1 branch soon.
So this got fixed in commit
03ebf85f7757c5da9f9d4fecb8ea1a1af18df46d, closing the ticket.
Kurt
.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Question in regards to early warning about new openssl versions
Hi Henning, So my question is - would it be reasonable to send an early warning (without any details) to one of the OpenSSL lists a few days before publishing a version containing fixes for security vulnerabilities? Just saying something along the lines of we plan to release a new openssl version containing security fixes in about 2 days. Something like this would help people to already be alarmed and start preparing resources (if they like to). I think this would help decreasing the time from the actual disclosure at openssl to fixed version of the respective project. This is already done, see [1]. You could also subscribe to announce, if you missed it. Best Regards, Steef [1] http://marc.info/?l=openssl-devm=140706092626158w=2 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Question in regards to early warning about new openssl versions
Hi Henning, So my question is - would it be reasonable to send an early warning (without any details) to one of the OpenSSL lists a few days before publishing a version containing fixes for security vulnerabilities? Just saying something along the lines of we plan to release a new openssl version containing security fixes in about 2 days. Something like this would help people to already be alarmed and start preparing resources (if they like to). I think this would help decreasing the time from the actual disclosure at openssl to fixed version of the respective project. This is already done, see [1]. You could also subscribe to announce, if you missed it. Regards, Steef [1] http://marc.info/?l=openssl-devm=140706092626158w=2 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3490] bug report: SRP still broken in 1.0.1 snapshot
Thank you.
On 08/13/2014 01:39 PM, Kurt Roeckx via RT wrote:
On Tue, Aug 12, 2014 at 08:36:06PM +0200, Kurt Roeckx wrote:
On Tue, Aug 12, 2014 at 08:22:38PM +0200, John Foley via RT wrote:
The first chunk in the s3_lib.c patch doesn't apply. But the second
chunk does (shown below). When applying this to 1.0.1 stable, it
appears to resolve the problem.
@@ -4357,8 +4359,13 @@ SSL_CIPHER *ssl3_choose_cipher(SSL *s,
STACK_OF(SSL_CIPHER) *clnt,
emask_k = cert-export_mask_k;
emask_a = cert-export_mask_a;
#ifndef OPENSSL_NO_SRP
- mask_k=cert-mask_k | s-srp_ctx.srp_Mask;
- emask_k=cert-export_mask_k | s-srp_ctx.srp_Mask;
+ if (s-srp_ctx.srp_Mask SSL_kSRP)
+ {
+ mask_k |= SSL_kSRP;
+ emask_k |= SSL_kSRP;
+ mask_a |= SSL_aSRP;
+ emask_a |= SSL_aSRP;
+ }
#endif
#ifdef KSSL_DEBUG
I assumed you were talking about the 1.0.1i release and not the
current git. When the mentioned commit got merged into the 1.0.1
branch the above part was somehow lost. It should get added to
the 1.0.1 branch soon.
So this got fixed in commit
03ebf85f7757c5da9f9d4fecb8ea1a1af18df46d, closing the ticket.
Kurt
.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #1872] [PATCH] Change 'Q' and 'R' behavior in s_client
In the release after 1.0.2, s_client has a new '-nocommands' flag that disables the command letters. We don't want to break existing behavior. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: nameConstraints : leading . in permission list items
Your proposed transition strategy sounds good. Maybe as a first step OpenSSL could tolerate a leading dot and in a future version implement item 6 ? mozilla:pkix and SChannel tolerate this. -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of John Denker Sent: Wednesday, August 13, 2014 7:59 PM To: openssl-dev@openssl.org Subject: Re: nameConstraints : leading . in permission list items On 08/13/2014 03:46 AM, Vyronas Tsingaras wrote: If you could also take a look at https://github.com/openssl/openssl/pull/111 we have listed a number of reasons. What are your thoughts on this? I agree with the reasoning given there. In particular, one point that I left as an open question in my original post is now persuasively answered. I apologize for not finding that item earlier. I did look; I just missed it somehow. To summarize my current understanding: 1) The pattern /foo.bar/ should match foo.bar and nothing else. It is not a wildcard. 2) The pattern /.foo.bar/ is a wildcard that should match any left-extension, including a.foo.bar, a.b.foo.bar, et cetera ... but not foo.bar itself. 3) If somebody wants to match both, they can include both on the list. 4) AFAICT this is nice and logical and consistent with what users expect and what other SSL implemenations are doing. The argument is strong for the permission list, and even stronger for the exclusion list. 5) Here is the only counterargument I can see: enforcing the non-wildcard requirement (item 1 above) will break applications that are relying on the current undocumented behavior as implemented in v3_ncons.c in openssl-1.0.1i. Therefore I suggest a transition strategy, as follows: 6) We would rather not have a situation where a given cert does one thing on some versions of openssl and different things on other versions (and on competing products). Here is a possible way to survive the transition: We could carefully and conspicuously document the following: Anybody who can tolerate matching foo.com and all of its subdomains should include both /foo.com/ and /.foo.com/ on the list. This covers the most common use-case. Anybody who wants this behavior should issue the appropriate cert ASAP, before the openssl update goes out. Note that anybody who wants to permit the subdomains but not foo.com itself has a problem until openssl gets fixed. The current code provides no way to exclude foo.com without excluding all the subdomains. I see no workaround for this. AFAICT the only fix is to patch the openssl code. I will rewrite my patch code accordingly. It will take me a little while to do this and test it. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Question in regards to early warning about new openssl versions
Duh - thank you Steef, Kurt and Rich - not sure how I could miss that either... So please only take the key message - your team does a great job with OpenSSL, thank you all! Regards, Henning On 08/13/2014 01:35 PM, Steef wrote: Hi Henning, So my question is - would it be reasonable to send an early warning (without any details) to one of the OpenSSL lists a few days before publishing a version containing fixes for security vulnerabilities? Just saying something along the lines of we plan to release a new openssl version containing security fixes in about 2 days. Something like this would help people to already be alarmed and start preparing resources (if they like to). I think this would help decreasing the time from the actual disclosure at openssl to fixed version of the respective project. This is already done, see [1]. You could also subscribe to announce, if you missed it. Best Regards, Steef [1] http://marc.info/?l=openssl-devm=140706092626158w=2 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
session cache and multiple threads
What's the programming model for using session cache with a multi-threaded server? When a client connections, a refcount on the object is incremented. But then fields can be changed (such as ecpointformat). Does it make more sense for session to deep-copy the session from the cache? -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz
Re: session cache and multiple threads
On Wed, Aug 13, 2014 at 03:32:00PM -0400, Salz, Rich wrote:
What's the programming model for using session cache with a multi-threaded
server?
When a client connects, a refcount on the object is incremented.
A lot depends on whether the cache is internal, or external via callbacks,
and wether session tickets are used.
But then fields can be changed (such as ecpointformat). Does it
make more sense for session to deep-copy the session from the cache?
With resumption, no actual ECDH key agreement or ECDSA certificate
use takes place, so perhaps such updates can be suppressed. The
resumed session should I think be essentially read-only.
Don't know the internal cache use-case well enough. With Postfix,
the session is always deep-copied, because the cache is external.
On the other-hand MTAs are not even remotely under as much TPS
pressure as web servers, so the latency of interacting with an
external cache daemon, doing deep copies, ... is not significant.
For other applications, that could be more problematic.
Postfix supports a single session object in the internal cache,
should it/can it instead set the internal cache size to zero?
/*
* Initialize the session cache.
*
* With a large number of concurrent smtpd(8) processes, it is not a
* good idea to cache multiple large session objects in each process.
* We set the internal cache size to 1, and don't register a
* remove_cb so as to avoid deleting good sessions from the
* external cache prematurely (when the internal cache is full,
* OpenSSL removes sessions from the external cache also)!
*
* This makes SSL_CTX_remove_session() not useful for flushing broken
* sessions from the external cache, so we must delete them directly
* (not via a callback).
*
* Set a session id context to identify to what type of server process
* created a session. In our case, the context is simply the name of
* the mail system: Postfix/TLS.
*/
SSL_CTX_sess_set_cache_size(server_ctx, 1);
SSL_CTX_set_session_id_context(server_ctx,
(void *) server_session_id_context,
sizeof(server_session_id_context));
SSL_CTX_set_session_cache_mode(server_ctx,
SSL_SESS_CACHE_SERVER |
SSL_SESS_CACHE_NO_AUTO_CLEAR);
if (cachable) {
app_ctx-cache_type = mystrdup(props-cache_type);
SSL_CTX_sess_set_get_cb(server_ctx, get_server_session_cb);
SSL_CTX_sess_set_new_cb(server_ctx, new_server_session_cb);
}
I could probably add: SSL_SESS_CACHE_NO_INTERNAL to the cache mode,
and use the external cache exclusively. It is not clear whether
with a cache size of 1 I need to ever call SSL_CTX_flush_sessions(3).
--
Viktor.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
RE: session cache and multiple threads
We're using the standard internal session (maintained per SSL_CTX object); not tickets. We're seeing that the sessions are shared, a refcount is maintained, but that SSL does modified fields within a session while it's being used. Most notably an address sanitizer build found the EC point stuff being mangled. It seems there are bugs in the OpenSSL stuff. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1704] bug report, Windows VC-32 debug build
Andy pointed out that this has been fixed since 1.0.0 where /Zi is added unconditionally. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #781] [PATCH] NetWare Support for OpenSSL 0.9.7
Very old release. Netware is no longer supported. After trying to carefully read the text of the RT, I don't *think* there's an OpenSSL bug; please file a new RT if I'm wrong about that. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2226] OSSL 1.0.0 and NetWare + nasm
Netware is no longer a supported platform. very old release. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1948] [PROPOSAL] change ecdsatest,enginetest to fit into 8.3 naming scheme
Netware is not a supported platform any more. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1697] openssl 2.2.8g: failure to check the return value of sk_new_null() in /apps/pkcs12.c, ocsp.c, engine.c and cr12p7.c
There are now type-safe, so its sk_X_new_null calls. And all of them in apps/*.c are now checked. This will be part of a post-1.0.2 release. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1973] [PATCH 11/14] Ensure 'make links' gets all headers correctly.
The comments refer to Jivin Stephen Henson Hilarious :) But issue was resolved. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3486] Bug Report: Openssl 1.0.1h | RHEL-6 | x86_64 | Crash in lh_retrieve
As indicated in message thread in openssl-dev this is now resolved. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #573] Possible bug in conf parser
I believe this commit fixed it, years ago: commit 23acb0eeb2ec89cb3d673dd0fb04838d83b13a1a Author: Richard Levitte levi...@openssl.org Date: Wed Sep 28 18:02:41 2005 + Change a comment so it corresponds to reality. Put back a character that was previously replaced with a NUL for parsing purposes. This seems to fix a very weird parsing bug involving two variable references in the same value. -- Rich Salz, OpenSSL dev team; rs...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
