Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+

[Misaki Miyashita]

On 01/ 8/18 04:46 PM, Misaki Miyashita wrote:

(switching the alias to openssl-dev@openssl.org)

I would like to suggest the following fix so that a valid certificate 
at .x can be recognized during the cert validation even when 
.0 is linking to a bad/expired certificate.  This may not be the 
most elegant solution, but it is a minimal change with low impact to 
the rest of the code.


Could I possibly get a review on the change? and possibly be 
considered to be integrated to the upstream?

(This is for the 1.0.1 branch)


Sorry, I meant to say it is for the 1.0.2 branch.



Thanks in advance.

-- misaki


--- a/crypto/x509/x509_vfy.c2017-11-02 07:32:58.0 -0700
+++ b/crypto/x509/x509_vfy.c2017-12-11 12:37:55.591835780 -0800
@@ -185,6 +185,39 @@
 return xtmp;
 }

+/*
+ * Look through the trust store setup by get_issuer() and
+ * return the certificate which matches the server cert 'x'
+ * via 'xtmp'.
+ */
+static int X509_get_cert(X509 **xtmp, X509_STORE_CTX *ctx, X509 *x)
+{
+X509_OBJECT*tmp;
+inti;
+intret = 0;
+
+CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);
+for (i = 0; i < sk_X509_OBJECT_num(ctx->ctx->objs); i++) {
+tmp = sk_X509_OBJECT_value(ctx->ctx->objs, i);
+if (tmp == NULL) {
+goto exit;
+}
+if (X509_cmp(tmp->data.x509, x) == 0) {
+/*
+ * Found the cert in the trust store which matches the
+ * server cert.  Increment the ref count and return.
+ */
+X509_OBJECT_up_ref_count(tmp);
+*xtmp = tmp->data.x509;
+ret = 1;
+goto exit;
+}
+}
+exit:
+CRYPTO_w_unlock(CRYPTO_LOCK_X509_STORE);
+return ret;
+}
+
 int X509_verify_cert(X509_STORE_CTX *ctx)
 {
 X509 *x, *xtmp, *xtmp2, *chain_ss = NULL;
@@ -316,9 +350,13 @@
  * We have a single self signed certificate: see if 
we can
  * find it in the store. We must have an exact match 
to avoid

  * possible impersonation.
+ * get_issuer() sets up the trust store for the 
subject and
+ * returns the first cert via 'xtmp'. The first cert 
in the
+ * trust store may not be the certificate that we are 
interested
+ * in. Look through the trust store to see there is 
an exact match.

  */
 ok = ctx->get_issuer(, ctx, x);
-if ((ok <= 0) || X509_cmp(x, xtmp)) {
+if ((ok <= 0) || (X509_get_cert(, ctx, x) != 1)) {
 ctx->error = X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT;
 ctx->current_cert = x;
 ctx->error_depth = i - 1;


On 10/21/17 03:21 PM, Viktor Dukhovni wrote:


On Oct 21, 2017, at 11:20 AM, Misaki Miyashita 
 wrote:


We encountered a problem using OpenLDAP with OpenSSL when there were 
more than one certificate with the same subject.


Does OpenSSL stop searching for a valid certificate when it finds a 
certificate with matching DN?

Yes, when a matching issuer is found in the trust store, but is expired
no alternative certificates will be tested.  You need to remove outdated
issuer certificates from your trust store before they expire.





--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Richard Levitte]

I'm not terribly savvy regarding IoT, but I imagine that they do talk
to something bigger.  A server end, perhaps?  What do we expect to run
on that end?  What happens, in that case, if SPECK makes its way into
the TLS cipher suites?  Would it be interesting to have OpenSSL
interop with such devices?

Note: I'm not terribly partial either way, just thought that we need
to look at it from a broader perspective...

Cheers,
Richard

In message  on Mon, 8 Jan 2018 
13:58:59 -0800 (PST), Paul Dale  said:

paul.dale> I'm wondering if one of the more specialised embedded cryptographic 
toolkits mightn't be a better option for your lightweight IoT TLS stack.  There 
is a wide choice available: CycloneSSL, ECT, Fusion, MatrixSSL, mbedTLS, 
NanoSSL, SharkSSL, WolfSSL, uC/SSL and many others.  All of them claim to be 
the smallest, fastest and most feature laden :)  To sell to the US government,  
your first selection criteria should be "does the toolkit have a current FIPS 
validation?"  From memory this means: ECT, nanoSSL or WolfSSL.
paul.dale> 
paul.dale> The more comprehensive toolkits (OpenSSL, NSS, GNU TLS) are less 
suitable for embedded applications, especially tightly resource constrained 
ones.  It is possible to cut OpenSSL down in size but it will never compete 
with the designed for embedded toolkits.  Plus, the FIPS module is fixed and 
cannot be shrunk.
paul.dale> 
paul.dale> The current OpenSSL FIPS validation only applies to 1.0.2 builds 
currently.  FIPS is on the project plan for 1.1 but it isn't available at the 
moment.  The US government is forbidden to purchase any product that contains 
cryptographic operations unless the product has a FIPS validation.  No FIPS, no 
sale.
paul.dale> 
paul.dale> 
paul.dale> Pauli
paul.dale> -- 
paul.dale> Oracle
paul.dale> Dr Paul Dale | Cryptographer | Network Security & Encryption 
paul.dale> Phone +61 7 3031 7217
paul.dale> Oracle Australia
paul.dale> 
paul.dale> -Original Message-
paul.dale> From: William Bathurst [mailto:wbath...@gmail.com] 
paul.dale> Sent: Tuesday, 9 January 2018 7:10 AM
paul.dale> To: openssl-dev@openssl.org
paul.dale> Cc: llamour...@gmail.com
paul.dale> Subject: Re: [openssl-dev] Speck Cipher Integration with OpenSSL
paul.dale> 
paul.dale> Hi Hanno/all,
paul.dale> 
paul.dale> I can understand your view that "more is not always good" in crypto. 
The reasoning behind the offering can be found in the following whitepaper:
paul.dale> 
paul.dale> 
https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf
paul.dale> 
paul.dale> I will summarize in a different way though. We wish to offer an 
optimized lightweight TLS for IoT. A majority of devices found in IoT are 
resource constrained, for example a device CPU may only have 32K of RAM. 
Therefore security is an afterthought by developers. For some only AES 128 is 
available and they wish to use 256 bit encryption. Then Speck
paul.dale> 256 would be an option because it has better performance and 
provides sufficient security.
paul.dale> 
paul.dale> Based on the above scenario you can likely see why we are interested 
in OpenSSL. First, OpenSSL can be used for terminating lightweight TLS 
connections near the edge, and then forwarding using commonly used ciphers.
paul.dale> 
paul.dale> [IoT Device] -TLS/Speck>[IoT Gateway]-TLS> [Services]
paul.dale> 
paul.dale> Also, we are interested in using OpenSSL libraries at the edge for 
client creation. One thing we would like to do is provide instructions for an 
highly optimized build of OpenSSL that can be used for contrained devices.
paul.dale> 
paul.dale> I think demand will eventually grow because there is an initiative 
by the US government to improve IoT Security and Speck is being developed and 
proposed as a standard within the government. Therefore, I see users who wish 
to play in this space would be interested in a version where Speck could be 
used in OpenSSL.
paul.dale> 
paul.dale> It is my hope to accomplish the following:
paul.dale> 
paul.dale> [1] Make Speck available via Open Source, this could be as an option 
or as a patch in OpenSSL.
paul.dale> [2] If we make it available as a patch, is there a place where we 
would announce/make it known that it is available?
paul.dale> 
paul.dale> We are also looking at open-sourcing the client side code. This 
would be used to create light-weight clients that use Speck and currently we 
also build basic OAuth capability on top of it.
paul.dale> 
paul.dale> Thanks for your input!
paul.dale> 
paul.dale> Bill
paul.dale> 
paul.dale> On 1/5/2018 11:40 AM, Hanno Böck wrote:
paul.dale> > On Fri, 5 Jan 2018 10:52:01 -0800
paul.dale> > William Bathurst  wrote:
paul.dale> >
paul.dale> >> 1) Community interest in such a lightweight cipher.
paul.dale> > I think there's a shifting view that "more is not always good" in 
paul.dale> 

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Paul Dale]

I'm wondering if one of the more specialised embedded cryptographic toolkits 
mightn't be a better option for your lightweight IoT TLS stack.  There is a 
wide choice available: CycloneSSL, ECT, Fusion, MatrixSSL, mbedTLS, NanoSSL, 
SharkSSL, WolfSSL, uC/SSL and many others.  All of them claim to be the 
smallest, fastest and most feature laden :)  To sell to the US government,  
your first selection criteria should be "does the toolkit have a current FIPS 
validation?"  From memory this means: ECT, nanoSSL or WolfSSL.

The more comprehensive toolkits (OpenSSL, NSS, GNU TLS) are less suitable for 
embedded applications, especially tightly resource constrained ones.  It is 
possible to cut OpenSSL down in size but it will never compete with the 
designed for embedded toolkits.  Plus, the FIPS module is fixed and cannot be 
shrunk.

The current OpenSSL FIPS validation only applies to 1.0.2 builds currently.  
FIPS is on the project plan for 1.1 but it isn't available at the moment.  The 
US government is forbidden to purchase any product that contains cryptographic 
operations unless the product has a FIPS validation.  No FIPS, no sale.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-Original Message-
From: William Bathurst [mailto:wbath...@gmail.com] 
Sent: Tuesday, 9 January 2018 7:10 AM
To: openssl-dev@openssl.org
Cc: llamour...@gmail.com
Subject: Re: [openssl-dev] Speck Cipher Integration with OpenSSL

Hi Hanno/all,

I can understand your view that "more is not always good" in crypto. The 
reasoning behind the offering can be found in the following whitepaper:

https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf

I will summarize in a different way though. We wish to offer an optimized 
lightweight TLS for IoT. A majority of devices found in IoT are resource 
constrained, for example a device CPU may only have 32K of RAM. Therefore 
security is an afterthought by developers. For some only AES 128 is available 
and they wish to use 256 bit encryption. Then Speck
256 would be an option because it has better performance and provides 
sufficient security.

Based on the above scenario you can likely see why we are interested in 
OpenSSL. First, OpenSSL can be used for terminating lightweight TLS connections 
near the edge, and then forwarding using commonly used ciphers.

[IoT Device] -TLS/Speck>[IoT Gateway]-TLS> [Services]

Also, we are interested in using OpenSSL libraries at the edge for client 
creation. One thing we would like to do is provide instructions for an highly 
optimized build of OpenSSL that can be used for contrained devices.

I think demand will eventually grow because there is an initiative by the US 
government to improve IoT Security and Speck is being developed and proposed as 
a standard within the government. Therefore, I see users who wish to play in 
this space would be interested in a version where Speck could be used in 
OpenSSL.

It is my hope to accomplish the following:

[1] Make Speck available via Open Source, this could be as an option or as a 
patch in OpenSSL.
[2] If we make it available as a patch, is there a place where we would 
announce/make it known that it is available?

We are also looking at open-sourcing the client side code. This would be used 
to create light-weight clients that use Speck and currently we also build basic 
OAuth capability on top of it.

Thanks for your input!

Bill

On 1/5/2018 11:40 AM, Hanno Böck wrote:
> On Fri, 5 Jan 2018 10:52:01 -0800
> William Bathurst  wrote:
>
>> 1) Community interest in such a lightweight cipher.
> I think there's a shifting view that "more is not always good" in 
> crypto. OpenSSL has added features in the past "just because" and it 
> was often a bad decision.
>
> Therefore I'd generally oppose adding ciphers without a clear usecase, 
> as increased code complexity has a cost.
> So I think questions that should be answered:
> What's the usecase for speck in OpenSSL? Are there plans to use it in 
> TLS? If yes why? By whom? What advantages does it have over existing 
> ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.)
>
>
> Also just for completeness, as some may not be aware: There are some 
> concerns about Speck due to its origin (aka the NSA). I don't think 
> that is a reason to dismiss a cipher right away, what I'd find more 
> concerning is that from what I observed there hasn't been a lot of 
> research about speck.
>

--
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] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+

[Misaki Miyashita]

(switching the alias to openssl-dev@openssl.org)

I would like to suggest the following fix so that a valid certificate at 
.x can be recognized during the cert validation even when .0 
is linking to a bad/expired certificate.  This may not be the most 
elegant solution, but it is a minimal change with low impact to the rest 
of the code.


Could I possibly get a review on the change? and possibly be considered 
to be integrated to the upstream?

(This is for the 1.0.1 branch)

Thanks in advance.

-- misaki


--- a/crypto/x509/x509_vfy.c2017-11-02 07:32:58.0 -0700
+++ b/crypto/x509/x509_vfy.c2017-12-11 12:37:55.591835780 -0800
@@ -185,6 +185,39 @@
 return xtmp;
 }

+/*
+ * Look through the trust store setup by get_issuer() and
+ * return the certificate which matches the server cert 'x'
+ * via 'xtmp'.
+ */
+static int X509_get_cert(X509 **xtmp, X509_STORE_CTX *ctx, X509 *x)
+{
+X509_OBJECT*tmp;
+inti;
+intret = 0;
+
+CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);
+for (i = 0; i < sk_X509_OBJECT_num(ctx->ctx->objs); i++) {
+tmp = sk_X509_OBJECT_value(ctx->ctx->objs, i);
+if (tmp == NULL) {
+goto exit;
+}
+if (X509_cmp(tmp->data.x509, x) == 0) {
+/*
+ * Found the cert in the trust store which matches the
+ * server cert.  Increment the ref count and return.
+ */
+X509_OBJECT_up_ref_count(tmp);
+*xtmp = tmp->data.x509;
+ret = 1;
+goto exit;
+}
+}
+exit:
+CRYPTO_w_unlock(CRYPTO_LOCK_X509_STORE);
+return ret;
+}
+
 int X509_verify_cert(X509_STORE_CTX *ctx)
 {
 X509 *x, *xtmp, *xtmp2, *chain_ss = NULL;
@@ -316,9 +350,13 @@
  * We have a single self signed certificate: see if we can
  * find it in the store. We must have an exact match 
to avoid

  * possible impersonation.
+ * get_issuer() sets up the trust store for the subject and
+ * returns the first cert via 'xtmp'. The first cert in the
+ * trust store may not be the certificate that we are 
interested
+ * in. Look through the trust store to see there is an 
exact match.

  */
 ok = ctx->get_issuer(, ctx, x);
-if ((ok <= 0) || X509_cmp(x, xtmp)) {
+if ((ok <= 0) || (X509_get_cert(, ctx, x) != 1)) {
 ctx->error = X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT;
 ctx->current_cert = x;
 ctx->error_depth = i - 1;


On 10/21/17 03:21 PM, Viktor Dukhovni wrote:


On Oct 21, 2017, at 11:20 AM, Misaki Miyashita  
wrote:


We encountered a problem using OpenLDAP with OpenSSL when there were more than 
one certificate with the same subject.

Does OpenSSL stop searching for a valid certificate when it finds a certificate 
with matching DN?

Yes, when a matching issuer is found in the trust store, but is expired
no alternative certificates will be tested.  You need to remove outdated
issuer certificates from your trust store before they expire.



--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[Benjamin Kaduk via openssl-dev]

On 01/08/2018 03:10 PM, William Bathurst wrote:
> Hi Hanno/all,
>
> I can understand your view that "more is not always good" in crypto.
> The reasoning behind the offering can be found in the following
> whitepaper:
>
> https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf
>
>
> I will summarize in a different way though. We wish to offer an
> optimized lightweight TLS for IoT. A majority of devices found in IoT
> are resource constrained, for example a device CPU may only have 32K
> of RAM. Therefore security is an afterthought by developers. For some
> only AES 128 is available and they wish to use 256 bit encryption.
> Then Speck 256 would be an option because it has better performance
> and provides sufficient security.
>
> Based on the above scenario you can likely see why we are interested
> in OpenSSL. First, OpenSSL can be used for terminating lightweight TLS
> connections near the edge, and then forwarding using commonly used
> ciphers.
>
> [IoT Device] -TLS/Speck>[IoT Gateway]-TLS> [Services]
>
> Also, we are interested in using OpenSSL libraries at the edge for
> client creation. One thing we would like to do is provide instructions
> for an highly optimized build of OpenSSL that can be used for
> contrained devices.
>
> I think demand will eventually grow because there is an initiative by
> the US government to improve IoT Security and Speck is being developed
> and proposed as a standard within the government. Therefore, I see
> users who wish to play in this space would be interested in a version
> where Speck could be used in OpenSSL.
>
> It is my hope to accomplish the following:
>
> [1] Make Speck available via Open Source, this could be as an option
> or as a patch in OpenSSL.
> [2] If we make it available as a patch, is there a place where we
> would announce/make it known that it is available?
>
> We are also looking at open-sourcing the client side code. This would
> be used to create light-weight clients that use Speck and currently we
> also build basic OAuth capability on top of it.
>

Interestingly, the IETF ACE (Authentication and Authorization in
Constrained Environments) is chartered to look at this space (crypto for
constrained systems/IoT), and is aiming towards something roughly
OAuth-shaped, but there has not really been any interest in Speck
expressed that I've seen.  So, is this work happening someplace else, or
is there not actually demand for it?

-Ben

> Thanks for your input!
>
> Bill
>
> On 1/5/2018 11:40 AM, Hanno Böck wrote:
>> On Fri, 5 Jan 2018 10:52:01 -0800
>> William Bathurst  wrote:
>>
>>> 1) Community interest in such a lightweight cipher.
>> I think there's a shifting view that "more is not always good" in
>> crypto. OpenSSL has added features in the past "just because" and it
>> was often a bad decision.
>>
>> Therefore I'd generally oppose adding ciphers without a clear usecase,
>> as increased code complexity has a cost.
>> So I think questions that should be answered:
>> What's the usecase for speck in OpenSSL? Are there plans to use it in
>> TLS? If yes why? By whom? What advantages does it have over existing
>> ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.)
>>
>>
>> Also just for completeness, as some may not be aware: There are some
>> concerns about Speck due to its origin (aka the NSA). I don't think
>> that is a reason to dismiss a cipher right away, what I'd find more
>> concerning is that from what I observed there hasn't been a lot of
>> research about speck.
>>
>

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

[William Bathurst]

Hi Hanno/all,

I can understand your view that "more is not always good" in crypto. The 
reasoning behind the offering can be found in the following whitepaper:


https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf

I will summarize in a different way though. We wish to offer an 
optimized lightweight TLS for IoT. A majority of devices found in IoT 
are resource constrained, for example a device CPU may only have 32K of 
RAM. Therefore security is an afterthought by developers. For some only 
AES 128 is available and they wish to use 256 bit encryption. Then Speck 
256 would be an option because it has better performance and provides 
sufficient security.


Based on the above scenario you can likely see why we are interested in 
OpenSSL. First, OpenSSL can be used for terminating lightweight TLS 
connections near the edge, and then forwarding using commonly used ciphers.


[IoT Device] -TLS/Speck>[IoT Gateway]-TLS> [Services]

Also, we are interested in using OpenSSL libraries at the edge for 
client creation. One thing we would like to do is provide instructions 
for an highly optimized build of OpenSSL that can be used for contrained 
devices.


I think demand will eventually grow because there is an initiative by 
the US government to improve IoT Security and Speck is being developed 
and proposed as a standard within the government. Therefore, I see users 
who wish to play in this space would be interested in a version where 
Speck could be used in OpenSSL.


It is my hope to accomplish the following:

[1] Make Speck available via Open Source, this could be as an option or 
as a patch in OpenSSL.
[2] If we make it available as a patch, is there a place where we would 
announce/make it known that it is available?


We are also looking at open-sourcing the client side code. This would be 
used to create light-weight clients that use Speck and currently we also 
build basic OAuth capability on top of it.


Thanks for your input!

Bill

On 1/5/2018 11:40 AM, Hanno Böck wrote:

On Fri, 5 Jan 2018 10:52:01 -0800
William Bathurst  wrote:


1) Community interest in such a lightweight cipher.

I think there's a shifting view that "more is not always good" in
crypto. OpenSSL has added features in the past "just because" and it
was often a bad decision.

Therefore I'd generally oppose adding ciphers without a clear usecase,
as increased code complexity has a cost.
So I think questions that should be answered:
What's the usecase for speck in OpenSSL? Are there plans to use it in
TLS? If yes why? By whom? What advantages does it have over existing
ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.)


Also just for completeness, as some may not be aware: There are some
concerns about Speck due to its origin (aka the NSA). I don't think
that is a reason to dismiss a cipher right away, what I'd find more
concerning is that from what I observed there hasn't been a lot of
research about speck.



--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev