Re: [openssl-dev] Windows build broken?
I'm sure this would resolve the issue. The problem exists in 1.0.1, but not 1.0.2. Here's the entry in the 1.0.1 libeay.num: Fixed. It was a mistake to remove engine_rsax, and I just reverted that. Should show up in the snapshots within an hour ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
El 27/01/15 a las 08:30, Hanno Böck escribió: Hello, On Fri, 23 Jan 2015 19:11:35 + Salz, Rich rs...@akamai.com wrote: OPENSSL_NO_BUF_FREELISTS As far as I remember the post-heartbleed discussions this disables an openssl-own memory management which in the case of heartbleed circumvented memory protection measures like address sanitizer. What's the plan here? Replace openssl's own memory management by default with standard memory management calls or is the plan to disable the possibility to have standard memory management at all? If the latter I'd vote against removing that flag. I think It needs be replaced by standard memory managment, whoever wants to do something special like using a different/tweaked allocator for whatever reason should use the operating system facilities to do so. Inordinate amounts of time have been spent improving things at this level, at least in linux BUF_FREELISTS functionality makes no sense whatsover. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OCB patent stuff
On 27/01/15 12:02, david.ll...@fsmail.net wrote: Hi, Quick note about this (or could you refer me to the discussion that I missed). Although I have no problems with explicitly patented code being included with OpenSSL, shouldn't the default for such code be off with an explicit enable-ocb? Why? We have an explicit licence enabling its use - so why shouldn't it be on? Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #2923] X509_cmp() introduces unnecessary dependency on SHA1
It is no longer an option to build OpenSSL without SHA, so closing this. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
Hello, On Fri, 23 Jan 2015 19:11:35 + Salz, Rich rs...@akamai.com wrote: OPENSSL_NO_BUF_FREELISTS As far as I remember the post-heartbleed discussions this disables an openssl-own memory management which in the case of heartbleed circumvented memory protection measures like address sanitizer. What's the plan here? Replace openssl's own memory management by default with standard memory management calls or is the plan to disable the possibility to have standard memory management at all? If the latter I'd vote against removing that flag. cu, -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgp7loP3vOqCL.pgp Description: OpenPGP digital signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3616] [Patch] Implement option to disable sending TLS extensions
On Monday 26 January 2015 10:03:30 Brian Smith wrote: Hubert Kario hka...@redhat.com wrote: Actually it does not introduce it as OpenSSL does send the notification as TLS_EMPTY_RENEGOTIATION_INFO_SCSV, not the extension. On Sunday 30 November 2014 20:36:20 Richard Moore wrote: That would introduce security issues such as the TLS renegotiation flaw. Surely a better solution is to make servers that pretend to support TLS but actually only support SSL3 die a horrible death? I agree with Richard that this seems . In particular, the session hash / extended master secret [1] specification requires an extension to work securely. which is not used by openssl by default... Not having the SNI extension is likely to cause security issues (using a different and perhaps though-of-as-unused certificate). SNI needs to be set manually on a connection, many openssl consumers still don't do it... and if you don't verify server certificate no amount of extensions will help you Many servers use the values in the signature_algorithms extension to determine whether to use a SHA-2 or SHA-1 certificate, Interesting, haven't seen such ones. Can you give examples? Still, how can you test if the server does the sane thing if the client doesn't provide signature_algorithms if you have such a server? so not sending signature_algorithms is likely to cause problems for any client that disables support for SHA-1 certificates. exactly what every piece of documentation surrounding this option says Resolving these TLS (extension) intolerance issues requires collective action, and it would be great if OpenSSL could do its part by not adding features like this that exist purely to avoid participating in the collective action, especially when the added feature disables other important security features. It's implemented not so that you can interoperate with them, I implemented it so that you can detect *if* this is the reason why you can't interoperate with them. Unfortunately it's rather hard to test interoperability without actually being interoperable... There are broken clients and there are broken servers and there are broken middle boxes out there. The library already has stuff like SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION which is *really* dangerous. SSL_OP_NO_TLSEXT is less of an issue than export grade ciphers. SSL_OP_NO_TLSEXT is the default mode of operation for 0.9.8, and I think we can agree that while 0.9.8 is old it's still secure. -- Regards, Hubert Kario ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] OCB patent stuff
Hi, Quick note about this (or could you refer me to the discussion that I missed). Although I have no problems with explicitly patented code being included with OpenSSL, shouldn't the default for such code be off with an explicit enable-ocb? Added support for OCB mode. OpenSSL has been granted a patent license compatible with the OpenSSL license for use of OCB. Details are available at https://www.openssl.org/docs/misc/OCB-patent-grant-OpenSSL.pdf. Support for OCB can be removed by calling config with no-ocb. [Matt Caswell] Thanks! ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OCB patent stuff
On 27/01/15 12:02, david.ll...@fsmail.net wrote: Hi, Quick note about this (or could you refer me to the discussion that I missed). Although I have no problems with explicitly patented code being included with OpenSSL, shouldn't the default for such code be off with an explicit enable-ocb? Why? We have an explicit licence enabling its use - so why shouldn't it be on? Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OCB patent stuff
Why? We have an explicit licence enabling its use - so why shouldn't it be on? Matt You do, but I don't, and other users of OpenSSL don't either. According to my legal advice at least - your Lawyer may disagree. The linked pdf doesn't solve the problem apparently. That there is an *issued* patent on the algorithm at all immediately makes it controversial, and probably doomed to die. Compare what the BBC did with the Dirac patents - the patent was publicly filed and then they explicitly let the application lapse without getting the patent issued within the timeframe. Once a patent is actually issued, there is the always someone who is going to have a problem. So the question is: Why did they pay for the Patent unless there is an intention to require Royalties? Are you or OpenSSL going to going to pay my royalty fees and/or legal costs if I am found to be infringing on this known patent? If you are not happy to be responsible for legal costs, then I recommend you disable it by default to avoid any such confusion... ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OCB patent stuff
On 27/01/15 13:12, david.ll...@fsmail.net wrote: Why? We have an explicit licence enabling its use - so why shouldn't it be on? Matt You do, but I don't, and other users of OpenSSL don't either. According to my legal advice at least - your Lawyer may disagree. The linked pdf doesn't solve the problem apparently. That there is an *issued* patent on the algorithm at all immediately makes it controversial, and probably doomed to die. Compare what the BBC did with the Dirac patents - the patent was publicly filed and then they explicitly let the application lapse without getting the patent issued within the timeframe. Once a patent is actually issued, there is the always someone who is going to have a problem. So the question is: Why did they pay for the Patent unless there is an intention to require Royalties? Are you or OpenSSL going to going to pay my royalty fees and/or legal costs if I am found to be infringing on this known patent? If you are not happy to be responsible for legal costs, then I recommend you disable it by default to avoid any such confusion... The answer to that is in the OpenSSL licence: * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED * OF THE POSSIBILITY OF SUCH DAMAGE. and is also covered by the OpenSSL FAQ: https://www.openssl.org/support/faq.html#LEGAL1 However, it is not the first time that there are things within OpenSSL with patents, and it is not without precedent to have these things switched on (e.g. some distributions have disabled EC stuff because of patent concerns, which is on by default in standard OpenSSL). We did get our own legal advice before including it and those lawyers advised us that we were ok with the patent licence we have been granted. Your mileage may vary with your own legal advice (and of course that may vary depending on where in the world you are located)...hence the FAQ link I provided above. The option to disable OCB has been provided for the cautious. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OCB patent stuff
The answer to that is in the OpenSSL licence: * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED * OF THE POSSIBILITY OF SUCH DAMAGE. and is also covered by the OpenSSL FAQ: https://www.openssl.org/support/faq.html#LEGAL1 Thanks, that matches exactly what my Legal advice said about the pdf. I will be specifying no-ocb for my customers. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
What's the plan here? Replace openssl's own memory management by default with standard memory management calls or is the plan to disable the possibility to have standard memory management at all? If the latter I'd vote against removing that flag. We use using only malloc and free. We are no longer keeping our own freelist management. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3657] OpenSSL 1.0.1k DTLS handshake no longer works
On Thu Jan 15 17:21:35 2015, matt wrote: In response to your previous documentation question it is (unfortunately) undocumented. :-( The best I can offer you is the source code: int read_ahead; /* Read as many input bytes as possible * (for non- blocking reads) */ With regards to your second point, I consider it a bug that this is not the default for DTLS. Unfortunately that bug has remained dormant until the fix for CVE-2014-0206 exposed it. I'm keeping this ticket open, until we have a proper fix. For now though the workaround is to use the SSL_CTX_set_read_ahead function directly. A slight correction to the notes above. The reference should be to CVE-2014-3571 (not CVE-2014-0206 as stated). I have now committed the fix for this problem. See commit 8dd4ad0ff in master (for 1.0.1 see 1895583). This fix makes read_ahead the default for DTLS...and in fact you can't turn it off now for DTLS either (calls to the read_ahead functions are ignored). I've also added some documentation for the read_ahead functions in commit 85074745. These are now irrelevant for DTLS (since you can't turn read_ahead off), but still relevant for TLS. Closing this ticket. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
El 27/01/15 a las 08:30, Hanno Böck escribió: Hello, On Fri, 23 Jan 2015 19:11:35 + Salz, Rich rs...@akamai.com wrote: OPENSSL_NO_BUF_FREELISTS As far as I remember the post-heartbleed discussions this disables an openssl-own memory management which in the case of heartbleed circumvented memory protection measures like address sanitizer. What's the plan here? Replace openssl's own memory management by default with standard memory management calls or is the plan to disable the possibility to have standard memory management at all? If the latter I'd vote against removing that flag. I think It needs be replaced by standard memory managment, whoever wants to do something special like using a different/tweaked allocator for whatever reason should use the operating system facilities to do so. Inordinate amounts of time have been spent improving things at this level, at least in linux BUF_FREELISTS functionality makes no sense whatsover. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Is X509_V_FLAG_TRUSTED_FIRST safe to backport to 1.0.1
On 15/01/15 17:06, Fedor Indutny wrote: Matt, Thank you for reply. May I ask you when do you think your patch may land in 1.0.2 or whatever? If this is something of your long term goals and not going to land anywhere soon. Could you please tell me about issues in my patch (either privately or in publiс)? My apologies for the delayed response. Things went a bit mad for a while with releases and the source code reformat, and I completely forgot about this email :-( I am hoping my patch will land in master (which means 1.1.0...aiming for an end of year release). I will add some notes to your RT ticket regarding your patch. You can see my draft patch here: https://github.com/mattcaswell/openssl/commits/late-check-trusted-v2 This is still going through review so may change. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3637] [PATCH] x509: skip certs if in alternative cert chain
On Thu Dec 18 15:31:48 2014, fe...@indutny.com wrote: In situations like [0] the server may provide alternative certificate chain, which is no longer valid in the current certificate store. In fact the issuer of the leaf (or some intermediate) cert is known and trusted, but the alternative chain certs that are sent by server are not trusted, thus leading to `ctx-get_issuer(...)` return 0. This patch changes the default behavior from borking out the whole sent chain to pop as much certs as needed to make it work. Basically, it pops the last cert and checks if the previous has known issuer. [0]: https://bugzilla.mozilla.org/show_bug.cgi?id=986005#c4 Hi Fedor As per my email on openssl-dev here are some notes on the patch submitted with this ticket: The patch changes the state that the chain is left in within ctx in the event of an error. As this is a public API function this is a problem as it could break applications that depend on the behaviour. This function is actually called from server code when constructing the cert chain. The behaviour change above breaks the cert chain construction. Also the value of num is incorrectly handled so that error messages are incorrect...usually returning X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT. Finally the code goes into a loop in the event that it encounters an orphaned non-root cert in the cert store. The loop would be infinite except that the incorrect handling of num above means that it eventually escapes when the max depth is reached. As mentioned on openssl-dev I have an alternative patch with the same goal that addresses this issue. I am going to leave this ticket open until such time as that patch is in master. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Is X509_V_FLAG_TRUSTED_FIRST safe to backport to 1.0.1
Thank you! On Tue, Jan 27, 2015 at 6:02 PM, Matt Caswell m...@openssl.org wrote: On 15/01/15 17:06, Fedor Indutny wrote: Matt, Thank you for reply. May I ask you when do you think your patch may land in 1.0.2 or whatever? If this is something of your long term goals and not going to land anywhere soon. Could you please tell me about issues in my patch (either privately or in publiс)? My apologies for the delayed response. Things went a bit mad for a while with releases and the source code reformat, and I completely forgot about this email :-( I am hoping my patch will land in master (which means 1.1.0...aiming for an end of year release). I will add some notes to your RT ticket regarding your patch. You can see my draft patch here: https://github.com/mattcaswell/openssl/commits/late-check-trusted-v2 This is still going through review so may change. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Windows build broken?
It looks like the Windows export symbols may need updating now that the rsax engine has been removed (yesterday). Here's the error from the log... link /nologo /subsystem:console /opt:ref /debug /dll /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def @C:\Users\ADMINI~1\AppData\Local\Temp\1\nm3A91.tmp LIBEAY32.def : error LNK2001: unresolved external symbol ENGINE_load_rsax out32dll\libeay32.lib : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\link.EXE' : return code '0x460' Stop. The full log is located here: http://173.39.238.160:8080/job/1_0_1_windows/16/console ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups
From: Dr. Matthias St. Pierre m...@ncp-e.com
Add missing forward declarations and export declarations for DHparams
and EC[PK]PARAMETERS.
Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS
objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters().
Signed-off-by: Dr. Matthias St. Pierre matthias.st.pie...@ncp-e.com
---
crypto/ec/ec.h | 38 ++
crypto/ec/ec_asn1.c | 30 ++
util/libeay.num | 10 ++
3 files changed, 74 insertions(+), 4 deletions(-)
This patch makes the ASN1 templates used internally by OpenSSL for
serializing DH and ECDH group parameters publicly available for reuse.
For example, if one wants to save a set of [EC]DH Groups together with
application defined data (e.g, group-name, group-id) to a file, it
is much easier to define a small set of ASN1 rules extending the existing
ones and let OpenSSL do the serialization, than fiddling around with
i2d_DHparams, i2d_ECParameters, etc. to embed the curve data as an
opaque blob into an OCTET_STREAM.
The patch was created against the OpenSSL_1_0_2-stable branch. If possible,
it would be nice if it could be merged into the next 1.0.2 release.
diff --git a/crypto/ec/ec.h b/crypto/ec/ec.h
index 98edfdf..97ccee8 100644
--- a/crypto/ec/ec.h
+++ b/crypto/ec/ec.h
@@ -128,6 +128,9 @@ typedef struct ec_group_st
typedef struct ec_point_st EC_POINT;
+typedef struct ecpk_parameters_st ECPKPARAMETERS;
+typedef struct ec_parameters_st ECPARAMETERS;
+
//
/* EC_METHODs for curves over GF(p) */
//
@@ -393,6 +396,38 @@ EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const
BIGNUM *a,
*/
EC_GROUP *EC_GROUP_new_by_curve_name(int nid);
+/** Creates a new EC_GROUP object from an ECPARAMETERS object
+ * \param params pointer to the ECPARAMETERS object
+ * \return newly created EC_GROUP object with specified curve or NULL
+ * if an error occurred
+ */
+EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params);
+
+/** Creates an ECPARAMETERS object for the the given EC_GROUP object.
+ * \param group pointer to the EC_GROUP object
+ * \param params pointer to an existing ECPARAMETERS object or NULL
+ * \return pointer to the new ECPARAMETERS object or NULL
+ * if an error occurred.
+ */
+ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group,
+ECPARAMETERS *params);
+
+/** Creates a new EC_GROUP object from an ECPKPARAMETERS object
+ * \param params pointer to an existing ECPKPARAMETERS object, or NULL
+ * \return newly created EC_GROUP object with specified curve, or NULL
+ * if an error occurred
+ */
+EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params);
+
+/** Creates an ECPKPARAMETERS object for the the given EC_GROUP object.
+ * \param group pointer to the EC_GROUP object
+ * \param params pointer to an existing ECPKPARAMETERS object or NULL
+ * \return pointer to the new ECPKPARAMETERS object or NULL
+ * if an error occurred.
+ */
+ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group,
+ECPKPARAMETERS *params);
+
//
/* handling of internal curves*/
//
@@ -702,6 +737,9 @@ int EC_GROUP_have_precompute_mult(const EC_GROUP *group);
/* ASN1 stuff */
//
+DECLARE_ASN1_ITEM(ECPKPARAMETERS)
+DECLARE_ASN1_ITEM(ECPARAMETERS)
+
/*
* EC_GROUP_get_basis_type() returns the NID of the basis type used to
* represent the field elements
diff --git a/crypto/ec/ec_asn1.c b/crypto/ec/ec_asn1.c
index 2924374..d84c6d2 100644
--- a/crypto/ec/ec_asn1.c
+++ b/crypto/ec/ec_asn1.c
@@ -306,6 +306,28 @@ static EC_GROUP *ec_asn1_pkparameters2group(const
ECPKPARAMETERS *);
static ECPKPARAMETERS *ec_asn1_group2pkparameters(const EC_GROUP *,
ECPKPARAMETERS *);
+EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params)
+{
+return ec_asn1_parameters2group(params);
+}
+
+ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group,
+ECPARAMETERS *params)
+{
+return ec_asn1_group2parameters(group, params);
+}
+
+EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params)
+{
+return ec_asn1_pkparameters2group(params);
+}
+
+ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group,
+ECPKPARAMETERS *params)
+{
+return
[openssl-dev] [openssl.org #2923] X509_cmp() introduces unnecessary dependency on SHA1
It is no longer an option to build OpenSSL without SHA, so closing this. -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Windows build broken?
It looks like the Windows export symbols may need updating now that the rsax engine has been removed (yesterday). Here's the error from the log... If you remove the reference to it from util/libeay.num does that fix the build? -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Windows build broken?
I'm sure this would resolve the issue. The problem exists in 1.0.1, but not 1.0.2. Here's the entry in the 1.0.1 libeay.num: ENGINE_load_rsax 4652 EXIST::FUNCTION:ENGINE And here's the entry in the 1.0.2 flavor of libeay.num: ENGINE_load_rsax 4652 NOEXIST::FUNCTION: You just need to to make util/libeay.num in the 1.0.1-stable branch. FYI, I have not checked master. On 01/27/2015 12:54 PM, Salz, Rich wrote: It looks like the Windows export symbols may need updating now that the rsax engine has been removed (yesterday). Here's the error from the log... If you remove the reference to it from util/libeay.num does that fix the build? -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Windows build broken?
Oh, I thought it was in master! In 1.0.1 it was a mistake to remove eng_rsax. And a commit to fix that will be submitted shortl. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Windows build broken?
Thanks for the update. I was curious why it was removed from 1.0.1. It seemed to be beyond the scope of a bug fix. Given 1.0.2 has now been released, should eng_rsax been removed there too? On 01/27/2015 01:06 PM, Salz, Rich wrote: Oh, I thought it was in master! In 1.0.1 it was a mistake to remove eng_rsax. And a commit to fix that will be submitted shortl. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] TSLEXT_TYPE_opaque_prf_input
This is an implementation of an IETF draft that expired seven years ago. Is anyone using it? -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [PATCH] Make c_rehash match commands starting with - (minus) instead of minus in any starting position, otherwise a directory named a-b breaks it
Signed-off-by: Gustavo Zacarias gust...@zacarias.com.ar
---
tools/c_rehash.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/c_rehash.in b/tools/c_rehash.in
index 887e927..1df2fab 100644
--- a/tools/c_rehash.in
+++ b/tools/c_rehash.in
@@ -15,7 +15,7 @@ my $symlink_exists=eval {symlink(,); 1};
my $removelinks = 1;
## Parse flags.
-while ( $ARGV[0] =~ '-.*' ) {
+while ( $ARGV[0] =~ '^-.*' ) {
my $flag = shift @ARGV;
last if ( $flag eq '--');
if ( $flag =~ /-old/) {
--
2.0.5
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Windows build broken?
I'm sure this would resolve the issue. The problem exists in 1.0.1, but not 1.0.2. Here's the entry in the 1.0.1 libeay.num: Fixed. It was a mistake to remove engine_rsax, and I just reverted that. Should show up in the snapshots within an hour ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups
Please submit patches to r...@openssl.org.
Matt
On 27/01/15 16:15, Dr. Matthias St. Pierre wrote:
From: Dr. Matthias St. Pierre m...@ncp-e.com
Add missing forward declarations and export declarations for DHparams
and EC[PK]PARAMETERS.
Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS
objects: EC_GROUP_new_from_ec[pk]parameters(),
EC_GROUP_get_ec[pk]parameters().
Signed-off-by: Dr. Matthias St. Pierre matthias.st.pie...@ncp-e.com
---
crypto/ec/ec.h | 38 ++
crypto/ec/ec_asn1.c | 30 ++
util/libeay.num | 10 ++
3 files changed, 74 insertions(+), 4 deletions(-)
This patch makes the ASN1 templates used internally by OpenSSL for
serializing DH and ECDH group parameters publicly available for reuse.
For example, if one wants to save a set of [EC]DH Groups together with
application defined data (e.g, group-name, group-id) to a file, it
is much easier to define a small set of ASN1 rules extending the existing
ones and let OpenSSL do the serialization, than fiddling around with
i2d_DHparams, i2d_ECParameters, etc. to embed the curve data as an
opaque blob into an OCTET_STREAM.
The patch was created against the OpenSSL_1_0_2-stable branch. If possible,
it would be nice if it could be merged into the next 1.0.2 release.
diff --git a/crypto/ec/ec.h b/crypto/ec/ec.h
index 98edfdf..97ccee8 100644
--- a/crypto/ec/ec.h
+++ b/crypto/ec/ec.h
@@ -128,6 +128,9 @@ typedef struct ec_group_st
typedef struct ec_point_st EC_POINT;
+typedef struct ecpk_parameters_st ECPKPARAMETERS;
+typedef struct ec_parameters_st ECPARAMETERS;
+
//
/* EC_METHODs for curves over GF(p) */
//
@@ -393,6 +396,38 @@ EC_GROUP *EC_GROUP_new_curve_GF2m(const BIGNUM *p, const
BIGNUM *a,
*/
EC_GROUP *EC_GROUP_new_by_curve_name(int nid);
+/** Creates a new EC_GROUP object from an ECPARAMETERS object
+ * \param params pointer to the ECPARAMETERS object
+ * \return newly created EC_GROUP object with specified curve or NULL
+ * if an error occurred
+ */
+EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params);
+
+/** Creates an ECPARAMETERS object for the the given EC_GROUP object.
+ * \param group pointer to the EC_GROUP object
+ * \param params pointer to an existing ECPARAMETERS object or NULL
+ * \return pointer to the new ECPARAMETERS object or NULL
+ * if an error occurred.
+ */
+ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group,
+ECPARAMETERS *params);
+
+/** Creates a new EC_GROUP object from an ECPKPARAMETERS object
+ * \param params pointer to an existing ECPKPARAMETERS object, or NULL
+ * \return newly created EC_GROUP object with specified curve, or NULL
+ * if an error occurred
+ */
+EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS *params);
+
+/** Creates an ECPKPARAMETERS object for the the given EC_GROUP object.
+ * \param group pointer to the EC_GROUP object
+ * \param params pointer to an existing ECPKPARAMETERS object or NULL
+ * \return pointer to the new ECPKPARAMETERS object or NULL
+ * if an error occurred.
+ */
+ECPKPARAMETERS *EC_GROUP_get_ecpkparameters(const EC_GROUP *group,
+ECPKPARAMETERS *params);
+
//
/* handling of internal curves*/
//
@@ -702,6 +737,9 @@ int EC_GROUP_have_precompute_mult(const EC_GROUP *group);
/* ASN1 stuff */
//
+DECLARE_ASN1_ITEM(ECPKPARAMETERS)
+DECLARE_ASN1_ITEM(ECPARAMETERS)
+
/*
* EC_GROUP_get_basis_type() returns the NID of the basis type used to
* represent the field elements
diff --git a/crypto/ec/ec_asn1.c b/crypto/ec/ec_asn1.c
index 2924374..d84c6d2 100644
--- a/crypto/ec/ec_asn1.c
+++ b/crypto/ec/ec_asn1.c
@@ -306,6 +306,28 @@ static EC_GROUP *ec_asn1_pkparameters2group(const
ECPKPARAMETERS *);
static ECPKPARAMETERS *ec_asn1_group2pkparameters(const EC_GROUP *,
ECPKPARAMETERS *);
+EC_GROUP *EC_GROUP_new_from_ecparameters(const ECPARAMETERS *params)
+{
+return ec_asn1_parameters2group(params);
+}
+
+ECPARAMETERS *EC_GROUP_get_ecparameters(const EC_GROUP *group,
+ECPARAMETERS *params)
+{
+return ec_asn1_group2parameters(group, params);
+}
+
+EC_GROUP *EC_GROUP_new_from_ecpkparameters(const ECPKPARAMETERS
Re: [openssl-dev] [PATCH] Export ASN1 templates for DH and ECDH groups
On Tue 2015-01-27 11:15:37 -0500, Dr. Matthias St. Pierre wrote: Add missing forward declarations and export declarations for DHparams and EC[PK]PARAMETERS. Add public functions to convert between EC_GROUP objects and EC[PK]PARAMETERS objects: EC_GROUP_new_from_ec[pk]parameters(), EC_GROUP_get_ec[pk]parameters(). fwiw, the IETF TLS WG is moving away from the possibility of arbitrary EC groups, and toward the requirement of specified and vetted EC groups. I'm not sure how much extra work should be done to maintain that as a public-facing interface. --dkg ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Loading of different Server CA certificates
Hi, I want to connect with different SSL servers. So I need to load different Server CA certs into SSL Context. Is it possible to load different server CA certs of different SSL servers in a single SSL Context? If yes, when I am connecting with SSL server, SSL client can traverse all the CA certificates in the SSL context, and can find the CA certificate that is fit for the Server URL? If not, can you please help me how to address this issue? Regards, Satish This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Loading of different Server CA certificates
From: openssl-dev On Behalf Of satish.kumarya...@cognizant.com Sent: Wednesday, January 28, 2015 00:08 This is a basic user question, not dev. I want to connect with different SSL servers. So I need to load different Server CA certs into SSL Context. If the servers are (or may be) using different CAs, yes. Is it possible to load different server CA certs of different SSL servers in a single SSL Context? If yes, when I am connecting with SSL server, SSL client can traverse all the CA certificates in the SSL context, and can find the CA certificate that is fit for the Server URL? Yes. There are actually two mechanisms. For CAfile, all the certs are loaded into memory, and the lookup just searches them. For CApath, the certs are left on disk, with filenames using hashes of the canonical subject names; lookup takes the hash of the needed CA, and reads the file(s) if any for that hash to find it. See the manpage on your system or at https://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html . Also https://www.openssl.org/docs/apps/verify.html for some more details. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
