From farazrkhan at gmail.com  Fri May  1 01:11:26 2015
From: farazrkhan at gmail.com (faraz khan)
Date: Fri, 01 May 2015 01:11:26 +0000
Subject: [openssl-users] Trying to understand DTLS (as it applies to webrtc)
Message-ID: <CALBWJdV2G27uWvhGz=pWnbPC_7Q7gmgmth8-ct2vVBwVH138Nw@mail.gmail.com>

Hi everyone,
This is my first time posting to this list - so if theres a better place
for this question please let me know.

The problem I'm trying to fix applies to the Janus webrtc gateway (
https://github.com/meetecho/janus-gateway) and my application which is
using native C++ webrtc.

What happens is that after hundreds of successful connections, sometimes
the Janus server is unable to negotiate a DTLS handshake and after a key
exchange the webrtc client replied with a DTLS Alert: Decrypt failed
message. I'm attaching a wireshark trace of the issue happening and one for
the correct negotiation.

The problem refuses to fix itself till Janus is restarted.

Both installations are using Openssl. Janus is compiled with version 1.0.1f

If someone can help explain how DTLS key exchange works and whats going
wrong in the above trace it would be great! I'm completely at a loss as far
as this is concerned!

Thanks all!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150501/e38be86d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WebrtcDTLSNegotation.pcapng
Type: application/octet-stream
Size: 7272 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150501/e38be86d/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: janusbaddtlsnegotiation.pcapng
Type: application/octet-stream
Size: 39736 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150501/e38be86d/attachment-0003.obj>

From bcall at apache.org  Fri May  1 01:49:34 2015
From: bcall at apache.org (Bryan Call)
Date: Thu, 30 Apr 2015 18:49:34 -0700
Subject: [openssl-users] Performance problems with OpenSSL and threading
In-Reply-To: <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org>
References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org>
 <5539844F.4090107@cisco.com>
 <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com>
 <A5F20DF3-E379-4952-82BB-C3CB3A4BC5DA@apache.org>
 <553ACEF9.4080702@cisco.com>
 <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org>
 <553FC1D0.9090302@cisco.com>
 <E98AE19B-413A-40D3-BC9C-67C83BBC3EB8@apache.org>
 <554124E9.9060405@cisco.com>
 <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org>
Message-ID: <3EA8BB30-273F-4483-8E9E-F4BBEA49B670@apache.org>

(plain text and removed most of the history)

John if you don?t mind reviewing my change to Apache Traffic Server.  It seems to be working very well.  Thank you again!

https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=blobdiff;f=iocore/net/SSLUtils.cc;h=0b732440636ab4e9eaedf237a5674bdc790c3e73;hp=2fae4820d7bab301340368e6be22445476d8d948;hb=d41e96f;hpb=ba1d6f7c9394c5efadb68cf9cf06f9b90f267b09

-Bryan




> On Apr 30, 2015, at 3:52 PM, Bryan Call <bcall at apache.org> wrote:
> 
> This is for Apache Traffic Server and we have no knobs for turning on/off FIPS.  I am thinking about always disabling FIPS right now and that would happen before we create the threads. 
> 
> I was able to get rid of all the FIPS lock connection with the changes you recommend (Big Thanks!).  The big one now is type 1.  I am printing out the log every time the contention total is mod 1M.  Are there any tricks I can do for type 1 locks?
> 
> [Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for lock - total contention: 4000000 waiting: 1 file: pmeth_lib.c line: 185 type: 10
> [Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for lock - total contention: 11000000 waiting: 2 file: err.c line: 469 type: 1
> [Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for lock - total contention: 4000000 waiting: 0 file: ex_data.c line: 304 type: 2
> [Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for lock - total contention: 12000000 waiting: 5 file: err.c line: 446 type: 1
> [Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for lock - total contention: 1000000 waiting: 0 file: rand_lib.c line: 212 type: 19
> 
> -Bryan
> 


From dthompson at prinpay.com  Fri May  1 04:59:02 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Fri, 1 May 2015 00:59:02 -0400
Subject: [openssl-users] SHA256() to EVP_* ?
In-Reply-To: <1430316437144-57791.post@n7.nabble.com>
References: <1430243581216-57774.post@n7.nabble.com>
 <006001d08213$99561750$cc0245f0$@prinpay.com>
 <1430316437144-57791.post@n7.nabble.com>
Message-ID: <002801d083cb$8c28aca0$a47a05e0$@prinpay.com>

> From: openssl-users On Behalf Of jonetsu
> Sent: Wednesday, April 29, 2015 10:07
<snip>
> The man page (the one online from OpenSSL project - SHA256.html)
> gives a description using SHA1() which computes a message digest.

Note this is the same page for
SHA{1,224,256,384,512}{,_Init,_Update,_Final}.html 
and is the same content that is provided as 'man' pages on a Unix install of
OpenSSL.
On Unix systems a man page for several related routines (or types/structures
etc) 
can actually be one file with multiple links to it, but the website doesn't
bother.

> Being generally new to OpenSSL at that level, what is then the
> difference between using, say, SHA1() vs. using SHA1_Init,
> SHA1_Update and SHA1_Final ?  Is it only that the latter allows
> for continuously add data until _Final is called ?
> 
Very nearly. The 'all-in-one' routine SHA1() consists of:
- declare (thus implicitly allocate) CTX 
- provide a static buffer by default (for legacy but this is a bad idea,
it is unsafe for threads or recursion, and should not be used today)
- do SHA1_Init and test for error (error won't actually occur but this 
preserves a consistent structure with other algorithms that might)
- do EXACTLY ONE SHA1_Update
- do SHA1_Final
- "cleanse" the CTX to prevent leakage of data that might be sensitive
(whether it actually is sensitive depends on what the data is, but to be 
on safe side always cleanse) and implicitly deallocate 

and similarly for the other algorithms.

So the difference using separate calls is: you can do multiple _Update 
steps/buffers, and you must handle the CTX and output buffer.

And you can do more flexible things like compute both SHA1 and MD5 
for the same data concurrently, without needing to buffer all the data 
(which in some applications might exceed your memory) or reread it 
(which may be impossible in some applications like streaming video).

You may be thinking: this is just a small convenience, it's not hard to 
do the separate routines. You're right, it's not. But if it happens 10 
or 20 or 50 places in your code, saving 10 lines 50 times is 500 lines 
you don't have to write, read, keep in source control, compile every 
build, cover in your test strategy and coverage reports, etc.
Even a small convenience is still a convenience.



From dthompson at prinpay.com  Fri May  1 04:59:02 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Fri, 1 May 2015 00:59:02 -0400
Subject: [openssl-users] Error signing document
In-Reply-To: <E7206BA2D53D894BAD0C4B62B2C52E7722E3CA8252@MBX01.hosting01.active24.com>
References: <E7206BA2D53D894BAD0C4B62B2C52E7722E3CA8252@MBX01.hosting01.active24.com>
Message-ID: <002901d083cb$8cca6ae0$a65f40a0$@prinpay.com>

> From: openssl-users On Behalf Of m.de.groot
> Sent: Thursday, April 30, 2015 14:46

> I converted the pfx file to a pem file using the following command
> openssl pkcs12 -in CustKeyIcBD001.pfx -out CustKeyIcBD001.pem -nodes
> 
> After this I trying to sign a file using this key with the following
command
> 
> openssl cms -sign -in TestfileIN.txt -out TestfileSign.tmp -outform DER -
> binary -nodetach -md SHA1 -signer CustKeyIcBD001.pem
> 
> However I keep getting the message
> 
> No signer certificate specified
> 
If you have accurately copied your command to the email, you are using 
a  Windows-cp1252 "dash" character (hex code 96) not a hyphen (2D) 
for the -signer option. Use the classic traditional ASCII hyphen.




From m.de.groot at dmdg.nl  Fri May  1 09:05:18 2015
From: m.de.groot at dmdg.nl (m.de.groot)
Date: Fri, 1 May 2015 11:05:18 +0200
Subject: [openssl-users] Error signing document
In-Reply-To: <002901d083cb$8cca6ae0$a65f40a0$@prinpay.com>
References: <E7206BA2D53D894BAD0C4B62B2C52E7722E3CA8252@MBX01.hosting01.active24.com>,
 <002901d083cb$8cca6ae0$a65f40a0$@prinpay.com>
Message-ID: <E7206BA2D53D894BAD0C4B62B2C52E7722E3CA8253@MBX01.hosting01.active24.com>

Great Dave this did the trick.
Thanks,
Mark

________________________________________
Van: openssl-users [openssl-users-bounces at openssl.org] namens Dave Thompson [dthompson at prinpay.com]
Verzonden: vrijdag 1 mei 2015 6:59
Aan: openssl-users at openssl.org
Onderwerp: Re: [openssl-users] Error signing document

> From: openssl-users On Behalf Of m.de.groot
> Sent: Thursday, April 30, 2015 14:46

> I converted the pfx file to a pem file using the following command
> openssl pkcs12 -in CustKeyIcBD001.pfx -out CustKeyIcBD001.pem -nodes
>
> After this I trying to sign a file using this key with the following
command
>
> openssl cms -sign -in TestfileIN.txt -out TestfileSign.tmp -outform DER -
> binary -nodetach -md SHA1 -signer CustKeyIcBD001.pem
>
> However I keep getting the message
>
> No signer certificate specified
>
If you have accurately copied your command to the email, you are using
a  Windows-cp1252 "dash" character (hex code 96) not a hyphen (2D)
for the -signer option. Use the classic traditional ASCII hyphen.



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

From matt at openssl.org  Fri May  1 09:36:18 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 01 May 2015 10:36:18 +0100
Subject: [openssl-users] Trying to understand DTLS (as it applies to
	webrtc)
In-Reply-To: <CALBWJdV2G27uWvhGz=pWnbPC_7Q7gmgmth8-ct2vVBwVH138Nw@mail.gmail.com>
References: <CALBWJdV2G27uWvhGz=pWnbPC_7Q7gmgmth8-ct2vVBwVH138Nw@mail.gmail.com>
Message-ID: <55434912.5030503@openssl.org>



On 01/05/15 02:11, faraz khan wrote:
> Hi everyone,
> This is my first time posting to this list - so if theres a better place
> for this question please let me know.
> 
> The problem I'm trying to fix applies to the Janus webrtc gateway
> (https://github.com/meetecho/janus-gateway) and my application which is
> using native C++ webrtc.
> 
> What happens is that after hundreds of successful connections, sometimes
> the Janus server is unable to negotiate a DTLS handshake and after a key
> exchange the webrtc client replied with a DTLS Alert: Decrypt failed
> message. I'm attaching a wireshark trace of the issue happening and one
> for the correct negotiation.  
> 
> The problem refuses to fix itself till Janus is restarted.
> 
> Both installations are using Openssl. Janus is compiled with version 1.0.1f
> 
> If someone can help explain how DTLS key exchange works and whats going
> wrong in the above trace it would be great! I'm completely at a loss as
> far as this is concerned!
> 
> Thanks all!

Hmmmm. I can't see anything obviously wrong with the above traces. The
handshake seems to proceed as normal and then fail near the end.

A couple of things of note:
* A client cert is being sent, but it has expired. I don't think this is
the problem though because it is the same cert in the "good" trace and
the "bad" trace.
        Validity
            Not Before: Feb  9 16:18:45 2007 GMT
            Not After : Feb  8 16:18:45 2009 GMT

* A different ciphersuite is being negotiated between the "good" version
and the "bad" version. "Good" is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
whilst "Bad" is TLS_RSA_WITH_AES_256_CBC_SHA. I'm not sure if that is
significant, but I can't see why a server restart would make any
difference if it were.

Are there any server logs which might indicate why it is sending the
alert? Looking at the code there are only a few places in the code which
generate a decrypt error alert. It would probably help diagnose the
problem if we could narrow down which of those places this is coming
from. OpenSSL adds an error to its error queue for each of those places.

The other point of note is that there have been quite a lot of DTLS
related defect fixes in the OpenSSL code since 1.0.1f. An upgrade would
be a really good idea.

Matt


From jonetsu at teksavvy.com  Fri May  1 11:32:32 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Fri, 1 May 2015 04:32:32 -0700 (MST)
Subject: [openssl-users] SHA256() to EVP_* ?
In-Reply-To: <002801d083cb$8c28aca0$a47a05e0$@prinpay.com>
References: <1430243581216-57774.post@n7.nabble.com>
 <006001d08213$99561750$cc0245f0$@prinpay.com>
 <1430316437144-57791.post@n7.nabble.com>
 <002801d083cb$8c28aca0$a47a05e0$@prinpay.com>
Message-ID: <1430479952186-57826.post@n7.nabble.com>

> Even a small convenience is still a convenience. 

And eventually they add up.

Thanks for the comments - it's appreciated.



--
View this message in context: http://openssl.6102.n7.nabble.com/SHA256-to-EVP-tp57774p57826.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From foleyj at cisco.com  Fri May  1 12:34:26 2015
From: foleyj at cisco.com (John Foley)
Date: Fri, 01 May 2015 08:34:26 -0400
Subject: [openssl-users] Performance problems with OpenSSL and threading
In-Reply-To: <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org>
References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org>
 <5539844F.4090107@cisco.com>
 <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com>
 <A5F20DF3-E379-4952-82BB-C3CB3A4BC5DA@apache.org>
 <553ACEF9.4080702@cisco.com>
 <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org>
 <553FC1D0.9090302@cisco.com>
 <E98AE19B-413A-40D3-BC9C-67C83BBC3EB8@apache.org>
 <554124E9.9060405@cisco.com>
 <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org>
Message-ID: <554372D2.30109@cisco.com>

Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors. 
It appears your application is generating a lot of errors for some
reason.  Never tried it myself, but you probably can't disable this lock
with multiple threads running.  You should take a look at the error log
to identify the cause of the errors.  Then resolve the issue, whatever
it may be. 



On 04/30/2015 06:52 PM, Bryan Call wrote:
> This is for Apache Traffic Server and we have no knobs for turning
> on/off FIPS.  I am thinking about always disabling FIPS right now and
> that would happen before we create the threads. 
>
> I was able to get rid of all the FIPS lock connection with the changes
> you recommend (Big Thanks!).  The big one now is type 1.  I am
> printing out the log every time the contention total is mod 1M.  Are
> there any tricks I can do for type 1 locks?
>
> [Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for
> lock - total contention: 4000000 waiting: 1 file: pmeth_lib.c line:
> 185 type: 10
> [Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for
> lock - total contention: 11000000 waiting: 2 file: err.c line: 469 type: 1
> [Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for
> lock - total contention: 4000000 waiting: 0 file: ex_data.c line: 304
> type: 2
> *[Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for
> lock - total contention: 12000000 waiting: 5 file: err.c line: 446
> type: 1*
> [Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for
> lock - total contention: 1000000 waiting: 0 file: rand_lib.c line: 212
> type: 19
>
> -Bryan
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150501/b31afdec/attachment.html>

From foleyj at cisco.com  Fri May  1 12:36:58 2015
From: foleyj at cisco.com (John Foley)
Date: Fri, 01 May 2015 08:36:58 -0400
Subject: [openssl-users] Performance problems with OpenSSL and threading
In-Reply-To: <3EA8BB30-273F-4483-8E9E-F4BBEA49B670@apache.org>
References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org>
 <5539844F.4090107@cisco.com>
 <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com>
 <A5F20DF3-E379-4952-82BB-C3CB3A4BC5DA@apache.org>
 <553ACEF9.4080702@cisco.com>
 <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org>
 <553FC1D0.9090302@cisco.com>
 <E98AE19B-413A-40D3-BC9C-67C83BBC3EB8@apache.org>
 <554124E9.9060405@cisco.com>
 <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org>
 <3EA8BB30-273F-4483-8E9E-F4BBEA49B670@apache.org>
Message-ID: <5543736A.6060208@cisco.com>

The changes to SSL_locking_callback() look good.  But the code you've
added to SSL_CTX_add_extra_chain_cert_file() doesn't accomplish much. 
You're checking if FIPS is on or off, then setting the FIPS mode to the
current setting, which is a no-op.


On 04/30/2015 09:49 PM, Bryan Call wrote:
> (plain text and removed most of the history)
>
> John if you don?t mind reviewing my change to Apache Traffic Server.  It seems to be working very well.  Thank you again!
>
> https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;a=blobdiff;f=iocore/net/SSLUtils.cc;h=0b732440636ab4e9eaedf237a5674bdc790c3e73;hp=2fae4820d7bab301340368e6be22445476d8d948;hb=d41e96f;hpb=ba1d6f7c9394c5efadb68cf9cf06f9b90f267b09
>
> -Bryan
>
>
>
>
>> On Apr 30, 2015, at 3:52 PM, Bryan Call <bcall at apache.org> wrote:
>>
>> This is for Apache Traffic Server and we have no knobs for turning on/off FIPS.  I am thinking about always disabling FIPS right now and that would happen before we create the threads. 
>>
>> I was able to get rid of all the FIPS lock connection with the changes you recommend (Big Thanks!).  The big one now is type 1.  I am printing out the log every time the contention total is mod 1M.  Are there any tricks I can do for type 1 locks?
>>
>> [Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for lock - total contention: 4000000 waiting: 1 file: pmeth_lib.c line: 185 type: 10
>> [Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for lock - total contention: 11000000 waiting: 2 file: err.c line: 469 type: 1
>> [Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for lock - total contention: 4000000 waiting: 0 file: ex_data.c line: 304 type: 2
>> [Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for lock - total contention: 12000000 waiting: 5 file: err.c line: 446 type: 1
>> [Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for lock - total contention: 1000000 waiting: 0 file: rand_lib.c line: 212 type: 19
>>
>> -Bryan
>>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From rwelty at nwtime.org  Fri May  1 13:21:08 2015
From: rwelty at nwtime.org (Richard Welty)
Date: Fri, 01 May 2015 09:21:08 -0400
Subject: [openssl-users] CMS questions
In-Reply-To: <20150224151022.GA12696@openssl.org>
References: <54EB3E92.7060106@averillpark.net>
 <20150224142106.GA1228@openssl.org> <54EC8AF6.70407@averillpark.net>
 <20150224151022.GA12696@openssl.org>
Message-ID: <55437DC4.80006@nwtime.org>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

[resending from the correct email address; list moderator, if you see this
first, just delete the one in the non-member queue]

On 2/24/15 10:10 AM, Dr. Stephen Henson wrote:
> So the embedded content type will be enveloped data?
>
> If so first you can check that type using CMS_get0_eContentType().
>
> Then you can use CMS_get0_content() to retrieve the embedded content as a
> pointer to an OCTET STRING pointer. You should check that content is
not NULL
> and then retrieve the encoding of the content using ASN1_STRING_data and
> ASN1_STRING_length.
>
> Once you have those you can decode using d2i_CMS_ContentInfo().
>
ok, i'm not understanding how i supply the private key for decrypting
the enveloped data in this scenario.

thanks,
   richard
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVQ33EAAoJEBg+LdNh/YEcvwAP/16TWRrGEPlVTSR9KGdezeSm
4ViStqMGbS2QHAmMHEZhypJMjuMEeeXJARXybH2ymCg8F6ATVRge5z4LGvSQheKu
5XU/sgw6T9rTuMcLuKiUnwqiIeFuz3IgDlBEwNOdS5DHXqWbfnbE6C5q/4d1mp7O
IttTQlsmPNE61+jiyffK4UYTG5wnHac58l7OYVrnS08ViIeCYC9vhNV9iFaQqekB
04r9eEs0NKzbfMGaiAVyZqkCJlFvfpH55cgPqHD4xu+yUDb4zAvA0N7tmYiGSPOa
nhCr9gwKKCVZvSsbZ45OUNpwrDIqFdKwgonKOfNOl28LeuMMXssrm2PM5yXvuQwR
YrP/vSj+4zuWtLg1J+vOciKb3LL+WOeJtMhHu9UDdLkQ2T7uPEdkSUSNn83P6YNu
DPFeW807omn3A3VgZhBbzd283/jEMkQOXZmrXOrPZ/vz95lFk4fLsDL6JtuMDryd
0aZila+Fm9NSm5AdMfC2Maf9wK2QFR/lbb7+CVi7nLWzY6nJjcHGrYvXn5NupaNF
bZ78+FOgbEJ5poktU+e68Iz1RhEGtSPuc6z8n8CA7F8NdFybsBzy16V16bAoBSdO
gLYWaDpWT6t2IRUkdNLwyBaMNuCMnkhl7MDjYIzZgmYWPD04yH46I9esehr99hrg
39ihWLRHKM/CZVspAh4/
=DS0I
-----END PGP SIGNATURE-----



From steve at openssl.org  Fri May  1 13:36:33 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 1 May 2015 13:36:33 +0000
Subject: [openssl-users] CMS questions
In-Reply-To: <55437DC4.80006@nwtime.org>
References: <54EB3E92.7060106@averillpark.net>
 <20150224142106.GA1228@openssl.org>
 <54EC8AF6.70407@averillpark.net>
 <20150224151022.GA12696@openssl.org> <55437DC4.80006@nwtime.org>
Message-ID: <20150501133633.GA19961@openssl.org>

On Fri, May 01, 2015, Richard Welty wrote:

> 
> 
> On 2/24/15 10:10 AM, Dr. Stephen Henson wrote:
> > So the embedded content type will be enveloped data?
> >
> > If so first you can check that type using CMS_get0_eContentType().
> >
> > Then you can use CMS_get0_content() to retrieve the embedded content as a
> > pointer to an OCTET STRING pointer. You should check that content is
> not NULL
> > and then retrieve the encoding of the content using ASN1_STRING_data and
> > ASN1_STRING_length.
> >
> > Once you have those you can decode using d2i_CMS_ContentInfo().
> >
> ok, i'm not understanding how i supply the private key for decrypting
> the enveloped data in this scenario.
> 

You get back a CMS_ContentInfo structure which you can then process using the
appropriate CMS functions such as CMS_decrypt().

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From rsalz at akamai.com  Fri May  1 13:49:11 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 1 May 2015 13:49:11 +0000
Subject: [openssl-users] Performance problems with OpenSSL and threading
In-Reply-To: <554372D2.30109@cisco.com>
References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org>
 <5539844F.4090107@cisco.com>
 <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com>
 <A5F20DF3-E379-4952-82BB-C3CB3A4BC5DA@apache.org>
 <553ACEF9.4080702@cisco.com>
 <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org>
 <553FC1D0.9090302@cisco.com>
 <E98AE19B-413A-40D3-BC9C-67C83BBC3EB8@apache.org>
 <554124E9.9060405@cisco.com>
 <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org> <554372D2.30109@cisco.com>
Message-ID: <78e3a2ed0b8f47ecb8d2701d1a54bf5f@usma1ex-dag1mb4.msg.corp.akamai.com>

>Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors.? It appears your application is generating a lot of errors for some reason.? Never tried it myself, but you probably can't disable this lock with multiple threads running.? You should take a look at the error log to identify the cause of the errors.? Then resolve the issue, whatever it may be.? 

I have a rewrite of the error-stack stuff that halves the number of locks.  If you want to try it, drop me a line.

From farazrkhan at gmail.com  Fri May  1 15:51:45 2015
From: farazrkhan at gmail.com (faraz khan)
Date: Fri, 01 May 2015 15:51:45 +0000
Subject: [openssl-users] Trying to understand DTLS (as it applies to
	webrtc)
In-Reply-To: <55434912.5030503@openssl.org>
References: <CALBWJdV2G27uWvhGz=pWnbPC_7Q7gmgmth8-ct2vVBwVH138Nw@mail.gmail.com>
 <55434912.5030503@openssl.org>
Message-ID: <CALBWJdXypPoO=LK3CP8cuH-eTTnaaKBA3MCNVcMf9KXBLmbhCw@mail.gmail.com>

Matt,
Thanks for taking the time to go through this. Unfortunately this error
only happens when WebRTC is acting as the server in the dtls handshake and
no logs (at all) seem to be printed but I think that's because openssl
logging is done in a different way in native WebRTC which I'm not handling.
I'll try increasing logs and / or printing openssl errors.

The janus server gets the alert packet which I'm guessing is an error
produced by the server in the transaction above.

I'm assuming the problem is with the client reply that janus sent. Any idea
what it could have sent wrong that WebRTC didn't like? Could it have
encrypted the message with a wrong crypto or something or is this
negotiation wholly handled by openssl? I'm trying to understand if janus is
doing something wrong or is the dtls stuff completely handled by libssl -
in which case this might be a dtls bug?

I'm a newbie to openssl and dtls so dont mind the stupid questions. I
however do know C and socket stuff so can get in to check with some
guidance :)


On Fri, May 1, 2015, 2:37 AM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 01/05/15 02:11, faraz khan wrote:
> > Hi everyone,
> > This is my first time posting to this list - so if theres a better place
> > for this question please let me know.
> >
> > The problem I'm trying to fix applies to the Janus webrtc gateway
> > (https://github.com/meetecho/janus-gateway) and my application which is
> > using native C++ webrtc.
> >
> > What happens is that after hundreds of successful connections, sometimes
> > the Janus server is unable to negotiate a DTLS handshake and after a key
> > exchange the webrtc client replied with a DTLS Alert: Decrypt failed
> > message. I'm attaching a wireshark trace of the issue happening and one
> > for the correct negotiation.
> >
> > The problem refuses to fix itself till Janus is restarted.
> >
> > Both installations are using Openssl. Janus is compiled with version
> 1.0.1f
> >
> > If someone can help explain how DTLS key exchange works and whats going
> > wrong in the above trace it would be great! I'm completely at a loss as
> > far as this is concerned!
> >
> > Thanks all!
>
> Hmmmm. I can't see anything obviously wrong with the above traces. The
> handshake seems to proceed as normal and then fail near the end.
>
> A couple of things of note:
> * A client cert is being sent, but it has expired. I don't think this is
> the problem though because it is the same cert in the "good" trace and
> the "bad" trace.
>         Validity
>             Not Before: Feb  9 16:18:45 2007 GMT
>             Not After : Feb  8 16:18:45 2009 GMT
>
> * A different ciphersuite is being negotiated between the "good" version
> and the "bad" version. "Good" is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
> whilst "Bad" is TLS_RSA_WITH_AES_256_CBC_SHA. I'm not sure if that is
> significant, but I can't see why a server restart would make any
> difference if it were.
>
> Are there any server logs which might indicate why it is sending the
> alert? Looking at the code there are only a few places in the code which
> generate a decrypt error alert. It would probably help diagnose the
> problem if we could narrow down which of those places this is coming
> from. OpenSSL adds an error to its error queue for each of those places.
>
> The other point of note is that there have been quite a lot of DTLS
> related defect fixes in the OpenSSL code since 1.0.1f. An upgrade would
> be a really good idea.
>
> Matt
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150501/01b8ad20/attachment.html>

From matt at openssl.org  Fri May  1 16:32:06 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 01 May 2015 17:32:06 +0100
Subject: [openssl-users] Trying to understand DTLS (as it applies to
	webrtc)
In-Reply-To: <CALBWJdXypPoO=LK3CP8cuH-eTTnaaKBA3MCNVcMf9KXBLmbhCw@mail.gmail.com>
References: <CALBWJdV2G27uWvhGz=pWnbPC_7Q7gmgmth8-ct2vVBwVH138Nw@mail.gmail.com>
 <55434912.5030503@openssl.org>
 <CALBWJdXypPoO=LK3CP8cuH-eTTnaaKBA3MCNVcMf9KXBLmbhCw@mail.gmail.com>
Message-ID: <5543AA86.3070500@openssl.org>



On 01/05/15 16:51, faraz khan wrote:
> Matt,
> Thanks for taking the time to go through this. Unfortunately this error
> only happens when WebRTC is acting as the server in the dtls handshake
> and no logs (at all) seem to be printed but I think that's because
> openssl logging is done in a different way in native WebRTC which I'm
> not handling. I'll try increasing logs and / or printing openssl errors.
> 
> The janus server gets the alert packet which I'm guessing is an error
> produced by the server in the transaction above.

Yes. You can see the following exchanges in the traces:

Client                    Server
------                    ------

ClientHello ------------>
                          ServerHello
                          Certificate
                          CertificateRequest
            <------------ ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
ChangeCipherSpec
[Finished (Encrypted)] -->
            <------------ Alert (Decrypt Error)

If I understand your setup correctly (I'm not familiar with Janus or
WebRTC), Janus is acting as the client here and WebRTC is the server,
and both are using OpenSSL?

> 
> I'm assuming the problem is with the client reply that janus sent. Any
> idea what it could have sent wrong that WebRTC didn't like? Could it
> have encrypted the message with a wrong crypto or something or is this
> negotiation wholly handled by openssl? I'm trying to understand if janus
> is doing something wrong or is the dtls stuff completely handled by
> libssl - in which case this might be a dtls bug?

The server doesn't like something the Client sent in the last flight of
messages, i.e. the Certificate, ClientKeyExchange, CertificateVerify,
ChangeCipherSpec or Finished. It's unlikely to be the Certificate as, as
far as I can tell, its the same Certificate in the "good" exchange
versus the bad. So that means either the ClientKeyExchange,
CertificateVerify or Finished messages (CCS is super simple so I don't
think its that).

Is WebRTC using 1.0.1 too (and if so which letter version)? Looking at
the 1.0.1 code there are only a few places where a decrypt error can
come from. Possible causes (in 1.0.1 code base):

- digest check failed processing the Finished message
- CRL signature failure processing the client Certificate
- Bad RSA decrypt processing the CertificateVerify
- Bad RSA signature processing the CertificateVerify

There are a few other places that emit Decrypt Error alerts but none of
them seem to apply here. Getting some additional logging might help us
figure out which one of these is the cause.

These are all quite low level issues though...deep in OpenSSL internals.

Matt




From farazrkhan at gmail.com  Fri May  1 19:09:10 2015
From: farazrkhan at gmail.com (faraz khan)
Date: Fri, 01 May 2015 19:09:10 +0000
Subject: [openssl-users] Trying to understand DTLS (as it applies to
	webrtc)
In-Reply-To: <5543AA86.3070500@openssl.org>
References: <CALBWJdV2G27uWvhGz=pWnbPC_7Q7gmgmth8-ct2vVBwVH138Nw@mail.gmail.com>
 <55434912.5030503@openssl.org>
 <CALBWJdXypPoO=LK3CP8cuH-eTTnaaKBA3MCNVcMf9KXBLmbhCw@mail.gmail.com>
 <5543AA86.3070500@openssl.org>
Message-ID: <CALBWJdWJNUvTdj+9jsh_S4NC1DR3Tn+6NWZ1H880r9caAFPiCw@mail.gmail.com>

Matt,
Thanks again! To be precise webrtc is using boringssl (Google's fork of
openssl). From the commits it seems VERY recent but I'm unable to figure
out the last openssl merge-in. You think this could be the issue? Should I
try both with boringSSL (its kinda hard to compile webrtc with openSSL now
since after the move to boringSSL)

On Fri, May 1, 2015 at 9:33 AM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 01/05/15 16:51, faraz khan wrote:
> > Matt,
> > Thanks for taking the time to go through this. Unfortunately this error
> > only happens when WebRTC is acting as the server in the dtls handshake
> > and no logs (at all) seem to be printed but I think that's because
> > openssl logging is done in a different way in native WebRTC which I'm
> > not handling. I'll try increasing logs and / or printing openssl errors.
> >
> > The janus server gets the alert packet which I'm guessing is an error
> > produced by the server in the transaction above.
>
> Yes. You can see the following exchanges in the traces:
>
> Client                    Server
> ------                    ------
>
> ClientHello ------------>
>                           ServerHello
>                           Certificate
>                           CertificateRequest
>             <------------ ServerHelloDone
> Certificate
> ClientKeyExchange
> CertificateVerify
> ChangeCipherSpec
> [Finished (Encrypted)] -->
>             <------------ Alert (Decrypt Error)
>
> If I understand your setup correctly (I'm not familiar with Janus or
> WebRTC), Janus is acting as the client here and WebRTC is the server,
> and both are using OpenSSL?
>
> >
> > I'm assuming the problem is with the client reply that janus sent. Any
> > idea what it could have sent wrong that WebRTC didn't like? Could it
> > have encrypted the message with a wrong crypto or something or is this
> > negotiation wholly handled by openssl? I'm trying to understand if janus
> > is doing something wrong or is the dtls stuff completely handled by
> > libssl - in which case this might be a dtls bug?
>
> The server doesn't like something the Client sent in the last flight of
> messages, i.e. the Certificate, ClientKeyExchange, CertificateVerify,
> ChangeCipherSpec or Finished. It's unlikely to be the Certificate as, as
> far as I can tell, its the same Certificate in the "good" exchange
> versus the bad. So that means either the ClientKeyExchange,
> CertificateVerify or Finished messages (CCS is super simple so I don't
> think its that).
>
> Is WebRTC using 1.0.1 too (and if so which letter version)? Looking at
> the 1.0.1 code there are only a few places where a decrypt error can
> come from. Possible causes (in 1.0.1 code base):
>
> - digest check failed processing the Finished message
> - CRL signature failure processing the client Certificate
> - Bad RSA decrypt processing the CertificateVerify
> - Bad RSA signature processing the CertificateVerify
>
> There are a few other places that emit Decrypt Error alerts but none of
> them seem to apply here. Getting some additional logging might help us
> figure out which one of these is the cause.
>
> These are all quite low level issues though...deep in OpenSSL internals.
>
> Matt
>
>
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150501/33a9a2bb/attachment-0001.html>

From matt at openssl.org  Fri May  1 20:01:47 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 01 May 2015 21:01:47 +0100
Subject: [openssl-users] Trying to understand DTLS (as it applies to
	webrtc)
In-Reply-To: <CALBWJdWJNUvTdj+9jsh_S4NC1DR3Tn+6NWZ1H880r9caAFPiCw@mail.gmail.com>
References: <CALBWJdV2G27uWvhGz=pWnbPC_7Q7gmgmth8-ct2vVBwVH138Nw@mail.gmail.com>
 <55434912.5030503@openssl.org>
 <CALBWJdXypPoO=LK3CP8cuH-eTTnaaKBA3MCNVcMf9KXBLmbhCw@mail.gmail.com>
 <5543AA86.3070500@openssl.org>
 <CALBWJdWJNUvTdj+9jsh_S4NC1DR3Tn+6NWZ1H880r9caAFPiCw@mail.gmail.com>
Message-ID: <5543DBAB.9060201@openssl.org>



On 01/05/15 20:09, faraz khan wrote:
> Matt,
> Thanks again! To be precise webrtc is using boringssl (Google's fork of
> openssl). From the commits it seems VERY recent but I'm unable to figure
> out the last openssl merge-in. You think this could be the issue? Should
> I try both with boringSSL (its kinda hard to compile webrtc with openSSL
> now since after the move to boringSSL)

Ahhh. BoringSSL. That means a slightly different list of potential
causes (they forked OpenSSL 1.0.2, and have continued to make changes
since then). I've just checked the latest dev version, and that means
possible causes:

- digest check failed processing the Finished message
- CRL signature failure processing the client Certificate
- Overly short RSA key
- Bad RSA decrypt/signature processing the CertificateVerify

To be honest I am more inclined to believe it is a problem on the client
side rather than the WebRTC side. The fact that it goes away after you
restart the client suggests to me that the client is getting itself into
a strange state. Perhaps some kind of memory corruption (either through
client application or openssl bug)?

Anyway I'd suggest two things as next steps:
- Try and figure out how to get more logging out of WebRTC to find out
more specifically what it is complaining about
- Upgrade your OpenSSL version to 1.0.1m

Matt


From bcall at apache.org  Fri May  1 21:10:55 2015
From: bcall at apache.org (Bryan Call)
Date: Fri, 1 May 2015 14:10:55 -0700
Subject: [openssl-users] Performance problems with OpenSSL and threading
In-Reply-To: <554372D2.30109@cisco.com>
References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org>
 <5539844F.4090107@cisco.com>
 <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com>
 <A5F20DF3-E379-4952-82BB-C3CB3A4BC5DA@apache.org>
 <553ACEF9.4080702@cisco.com>
 <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org>
 <553FC1D0.9090302@cisco.com>
 <E98AE19B-413A-40D3-BC9C-67C83BBC3EB8@apache.org>
 <554124E9.9060405@cisco.com>
 <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org> <554372D2.30109@cisco.com>
Message-ID: <9309F974-5CEC-40CC-99E0-D608204197AA@apache.org>

So can I assume the FIPS POST has completed if I never call FIPS_mode_set() in the code?  I was confused about that.

When we call SSL_read() and get a 0 byte return we call SSL_get_error() to see if there was an error not not.  Maybe there is a more efficient handle this, like looking at the shutdown flag?

       0   The read operation was not successful. The reason may either be a
           clean shutdown due to a "close notify" alert sent by the peer (in
           which case the SSL_RECEIVED_SHUTDOWN flag in the ssl shutdown state
           is set (see SSL_shutdown(3), SSL_set_shutdown(3)). It is also
           possible, that the peer simply shut down the underlying transport
           and the shutdown is incomplete. Call SSL_get_error() with the
           return value ret to find out, whether an error occurred or the
           connection was shut down cleanly (SSL_ERROR_ZERO_RETURN).

When we call SSL_accept we also call SSL_get_error() to see we need to read or write.  Is there a more efficient way to tell if we need to read or write?

       If the underlying BIO is non-blocking, SSL_accept() will also return
       when the underlying BIO could not satisfy the needs of SSL_accept() to
       continue the handshake, indicating the problem by the return value -1.
       In this case a call to SSL_get_error() with the return value of
       SSL_accept() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE.
       The calling process then must repeat the call after taking appropriate
       action to satisfy the needs of SSL_accept().  The action depends on the
       underlying BIO. When using a non-blocking socket, nothing is to be
       done, but select() can be used to check for the required condition.
       When using a buffering BIO, like a BIO pair, data must be written into
       or retrieved out of the BIO before being able to continue.


Thank you...

-Bryan




> On May 1, 2015, at 5:34 AM, John Foley <foleyj at cisco.com> wrote:
> 
> Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors.  It appears your application is generating a lot of errors for some reason.  Never tried it myself, but you probably can't disable this lock with multiple threads running.  You should take a look at the error log to identify the cause of the errors.  Then resolve the issue, whatever it may be.  
> 
> 
> 
> On 04/30/2015 06:52 PM, Bryan Call wrote:
>> This is for Apache Traffic Server and we have no knobs for turning on/off FIPS.  I am thinking about always disabling FIPS right now and that would happen before we create the threads. 
>> 
>> I was able to get rid of all the FIPS lock connection with the changes you recommend (Big Thanks!).  The big one now is type 1.  I am printing out the log every time the contention total is mod 1M.  Are there any tricks I can do for type 1 locks?
>> 
>> [Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for lock - total contention: 4000000 waiting: 1 file: pmeth_lib.c line: 185 type: 10
>> [Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for lock - total contention: 11000000 waiting: 2 file: err.c line: 469 type: 1
>> [Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for lock - total contention: 4000000 waiting: 0 file: ex_data.c line: 304 type: 2
>> [Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for lock - total contention: 12000000 waiting: 5 file: err.c line: 446 type: 1
>> [Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for lock - total contention: 1000000 waiting: 0 file: rand_lib.c line: 212 type: 19
>> 
>> -Bryan
>> 
>> 
> 
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From kurt at roeckx.be  Fri May  1 21:38:08 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 1 May 2015 23:38:08 +0200
Subject: [openssl-users] Trying to understand DTLS (as it applies to
 webrtc)
In-Reply-To: <5543DBAB.9060201@openssl.org>
References: <CALBWJdV2G27uWvhGz=pWnbPC_7Q7gmgmth8-ct2vVBwVH138Nw@mail.gmail.com>
 <55434912.5030503@openssl.org>
 <CALBWJdXypPoO=LK3CP8cuH-eTTnaaKBA3MCNVcMf9KXBLmbhCw@mail.gmail.com>
 <5543AA86.3070500@openssl.org>
 <CALBWJdWJNUvTdj+9jsh_S4NC1DR3Tn+6NWZ1H880r9caAFPiCw@mail.gmail.com>
 <5543DBAB.9060201@openssl.org>
Message-ID: <20150501213808.GA31024@roeckx.be>

On Fri, May 01, 2015 at 09:01:47PM +0100, Matt Caswell wrote:
> 
> 
> On 01/05/15 20:09, faraz khan wrote:
> > Matt,
> > Thanks again! To be precise webrtc is using boringssl (Google's fork of
> > openssl). From the commits it seems VERY recent but I'm unable to figure
> > out the last openssl merge-in. You think this could be the issue? Should
> > I try both with boringSSL (its kinda hard to compile webrtc with openSSL
> > now since after the move to boringSSL)
> 
> Ahhh. BoringSSL. That means a slightly different list of potential
> causes (they forked OpenSSL 1.0.2, and have continued to make changes
> since then). I've just checked the latest dev version, and that means
> possible causes:
> 
> - digest check failed processing the Finished message
> - CRL signature failure processing the client Certificate
> - Overly short RSA key
> - Bad RSA decrypt/signature processing the CertificateVerify
> 
> To be honest I am more inclined to believe it is a problem on the client
> side rather than the WebRTC side. The fact that it goes away after you
> restart the client suggests to me that the client is getting itself into
> a strange state. Perhaps some kind of memory corruption (either through
> client application or openssl bug)?
> 
> Anyway I'd suggest two things as next steps:
> - Try and figure out how to get more logging out of WebRTC to find out
> more specifically what it is complaining about
> - Upgrade your OpenSSL version to 1.0.1m

He could also try to use something like valgrind to see if memory
gets corrupted, or use build it using address sanitizer.


Kurt


From foleyj at cisco.com  Fri May  1 22:33:18 2015
From: foleyj at cisco.com (John Foley)
Date: Fri, 01 May 2015 18:33:18 -0400
Subject: [openssl-users] Performance problems with OpenSSL and threading
In-Reply-To: <9309F974-5CEC-40CC-99E0-D608204197AA@apache.org>
References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org>
 <5539844F.4090107@cisco.com>
 <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com>
 <A5F20DF3-E379-4952-82BB-C3CB3A4BC5DA@apache.org>
 <553ACEF9.4080702@cisco.com>
 <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org>
 <553FC1D0.9090302@cisco.com>
 <E98AE19B-413A-40D3-BC9C-67C83BBC3EB8@apache.org>
 <554124E9.9060405@cisco.com>
 <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org> <554372D2.30109@cisco.com>
 <9309F974-5CEC-40CC-99E0-D608204197AA@apache.org>
Message-ID: <5543FF2E.2060707@cisco.com>

Yes, if you never call FIPS_mode_set(), the POST will never run.  I'll
defer to the experts on your other questions.


On 05/01/2015 05:10 PM, Bryan Call wrote:
> So can I assume the FIPS POST has completed if I never call FIPS_mode_set() in the code?  I was confused about that.
>
> When we call SSL_read() and get a 0 byte return we call SSL_get_error() to see if there was an error not not.  Maybe there is a more efficient handle this, like looking at the shutdown flag?
>
>        0   The read operation was not successful. The reason may either be a
>            clean shutdown due to a "close notify" alert sent by the peer (in
>            which case the SSL_RECEIVED_SHUTDOWN flag in the ssl shutdown state
>            is set (see SSL_shutdown(3), SSL_set_shutdown(3)). It is also
>            possible, that the peer simply shut down the underlying transport
>            and the shutdown is incomplete. Call SSL_get_error() with the
>            return value ret to find out, whether an error occurred or the
>            connection was shut down cleanly (SSL_ERROR_ZERO_RETURN).
>
> When we call SSL_accept we also call SSL_get_error() to see we need to read or write.  Is there a more efficient way to tell if we need to read or write?
>
>        If the underlying BIO is non-blocking, SSL_accept() will also return
>        when the underlying BIO could not satisfy the needs of SSL_accept() to
>        continue the handshake, indicating the problem by the return value -1.
>        In this case a call to SSL_get_error() with the return value of
>        SSL_accept() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE.
>        The calling process then must repeat the call after taking appropriate
>        action to satisfy the needs of SSL_accept().  The action depends on the
>        underlying BIO. When using a non-blocking socket, nothing is to be
>        done, but select() can be used to check for the required condition.
>        When using a buffering BIO, like a BIO pair, data must be written into
>        or retrieved out of the BIO before being able to continue.
>
>
> Thank you...
>
> -Bryan
>
>
>
>
>> On May 1, 2015, at 5:34 AM, John Foley <foleyj at cisco.com> wrote:
>>
>> Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors.  It appears your application is generating a lot of errors for some reason.  Never tried it myself, but you probably can't disable this lock with multiple threads running.  You should take a look at the error log to identify the cause of the errors.  Then resolve the issue, whatever it may be.  
>>
>>
>>
>> On 04/30/2015 06:52 PM, Bryan Call wrote:
>>> This is for Apache Traffic Server and we have no knobs for turning on/off FIPS.  I am thinking about always disabling FIPS right now and that would happen before we create the threads. 
>>>
>>> I was able to get rid of all the FIPS lock connection with the changes you recommend (Big Thanks!).  The big one now is type 1.  I am printing out the log every time the contention total is mod 1M.  Are there any tricks I can do for type 1 locks?
>>>
>>> [Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for lock - total contention: 4000000 waiting: 1 file: pmeth_lib.c line: 185 type: 10
>>> [Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for lock - total contention: 11000000 waiting: 2 file: err.c line: 469 type: 1
>>> [Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for lock - total contention: 4000000 waiting: 0 file: ex_data.c line: 304 type: 2
>>> [Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for lock - total contention: 12000000 waiting: 5 file: err.c line: 446 type: 1
>>> [Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for lock - total contention: 1000000 waiting: 0 file: rand_lib.c line: 212 type: 19
>>>
>>> -Bryan
>>>
>>>
>> _______________________________________________
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> .
>


From matt at openssl.org  Fri May  1 22:40:13 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 01 May 2015 23:40:13 +0100
Subject: [openssl-users] Trying to understand DTLS (as it applies to
	webrtc)
In-Reply-To: <CALBWJdV2G27uWvhGz=pWnbPC_7Q7gmgmth8-ct2vVBwVH138Nw@mail.gmail.com>
References: <CALBWJdV2G27uWvhGz=pWnbPC_7Q7gmgmth8-ct2vVBwVH138Nw@mail.gmail.com>
Message-ID: <554400CD.7030506@openssl.org>



On 01/05/15 02:11, faraz khan wrote:
> Hi everyone,
> This is my first time posting to this list - so if theres a better place
> for this question please let me know.
> 
> The problem I'm trying to fix applies to the Janus webrtc gateway
> (https://github.com/meetecho/janus-gateway) and my application which is
> using native C++ webrtc.
> 
> What happens is that after hundreds of successful connections, sometimes
> the Janus server is unable to negotiate a DTLS handshake and after a key
> exchange the webrtc client replied with a DTLS Alert: Decrypt failed
> message. I'm attaching a wireshark trace of the issue happening and one
> for the correct negotiation.

Can you confirm that the trace you attached for the correct negotiation
also came from Janus? I spotted some odd things about the extensions in
the ClientHello:

It has the "extended master secret" extension. That extension is not
supported by any released version of OpenSSL (we have it in the dev
version of 1.1.0 - but that is unreleased).

It correctly adds the ec_point_formats and elliptic_curves extensions.
However it so happens that OpenSSL 1.0.1f has a bug in it (not in the
latest version) which suppresses those extensions for DTLS (this is a
significant enough bug in itself that it is worthwhile upgrading your
OpenSSL)

OpenSSL always adds extensions in the same order - and these extensions
are in a different order.

Due to the above it looks to me like the OpenSSL DTLS stack was not used
to generate that ClientHello. The failed one *does* look like an OpenSSL
generated ClientHello.

Matt


From farazrkhan at gmail.com  Fri May  1 23:08:24 2015
From: farazrkhan at gmail.com (faraz khan)
Date: Fri, 01 May 2015 23:08:24 +0000
Subject: [openssl-users] Trying to understand DTLS (as it applies to
	webrtc)
In-Reply-To: <554400CD.7030506@openssl.org>
References: <CALBWJdV2G27uWvhGz=pWnbPC_7Q7gmgmth8-ct2vVBwVH138Nw@mail.gmail.com>
 <554400CD.7030506@openssl.org>
Message-ID: <CALBWJdXMfpGAfJrwaP_2EAc8KkVOonbY+oNYTUDkG7+EU-ZkXw@mail.gmail.com>

Matt,
Sorry for the confusion. In the first (correct) trace the client is
BoringSSL (webrtc) and the server hello comes from Janus (OpenSSL). In the
bad trace the Client is openSSL and the server is BoringSSL. The error
almost always seems to happen in this configuration (when client ==
openSSL, Server == BoringSSL)

So im guessing the client hello is different since it comes from boring SSL.

I'm currently testing janus with both 1.0.1m and BoringSSL (same version as
webrtc/chrome M43). I'll post my results if it doesnt end up in the same
state in a few days as I get some testing on these servers!

This has been amazing helpful. OpenSSL seems DTLS handshakes seem so easy
:) I cant believe theres a SSL_do_handshake() function!

Thank you!




On Fri, May 1, 2015 at 3:41 PM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 01/05/15 02:11, faraz khan wrote:
> > Hi everyone,
> > This is my first time posting to this list - so if theres a better place
> > for this question please let me know.
> >
> > The problem I'm trying to fix applies to the Janus webrtc gateway
> > (https://github.com/meetecho/janus-gateway) and my application which is
> > using native C++ webrtc.
> >
> > What happens is that after hundreds of successful connections, sometimes
> > the Janus server is unable to negotiate a DTLS handshake and after a key
> > exchange the webrtc client replied with a DTLS Alert: Decrypt failed
> > message. I'm attaching a wireshark trace of the issue happening and one
> > for the correct negotiation.
>
> Can you confirm that the trace you attached for the correct negotiation
> also came from Janus? I spotted some odd things about the extensions in
> the ClientHello:
>
> It has the "extended master secret" extension. That extension is not
> supported by any released version of OpenSSL (we have it in the dev
> version of 1.1.0 - but that is unreleased).
>
> It correctly adds the ec_point_formats and elliptic_curves extensions.
> However it so happens that OpenSSL 1.0.1f has a bug in it (not in the
> latest version) which suppresses those extensions for DTLS (this is a
> significant enough bug in itself that it is worthwhile upgrading your
> OpenSSL)
>
> OpenSSL always adds extensions in the same order - and these extensions
> are in a different order.
>
> Due to the above it looks to me like the OpenSSL DTLS stack was not used
> to generate that ClientHello. The failed one *does* look like an OpenSSL
> generated ClientHello.
>
> Matt
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150501/d967f376/attachment-0001.html>

From naynjain at in.ibm.com  Sat May  2 02:36:43 2015
From: naynjain at in.ibm.com (Nayna Jain)
Date: Sat, 2 May 2015 08:06:43 +0530
Subject: [openssl-users] PEM_read_bio_PrivateKey(..) or
 PEM_read_bio_RSAPrivateKey(..) both returns NULL
Message-ID: <OF4BD3AE09.09F0F0C7-ON65257E39.000E1790-65257E39.000E5560@in.ibm.com>


Hi,

I have a privatekey file written using the call PEM_write_bio_RSAPrivateKey
(...)

The file write operation has been successful.

However, when i am trying to read it via calls PEM_read_bio_PrivateKey(..)
or PEM_read_bio_RSAPrivateKey(..) , it is always returning NULL.
There is no encryption also done . It i unencrypted private key. Can
someone help me to understand what might be wrong.

And the same is while reading public key also

Actually write operations are successful but read operations are not
successful, what I am might be missing?

Thanks & Regards,
Nayna Jain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150502/42ef8823/attachment.html>

From dthompson at prinpay.com  Sun May  3 00:34:30 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Sat, 2 May 2015 20:34:30 -0400
Subject: [openssl-users] PEM_read_bio_PrivateKey(..) or
	PEM_read_bio_RSAPrivateKey(..) both returns NULL
In-Reply-To: <OF4BD3AE09.09F0F0C7-ON65257E39.000E1790-65257E39.000E5560@in.ibm.com>
References: <OF4BD3AE09.09F0F0C7-ON65257E39.000E1790-65257E39.000E5560@in.ibm.com>
Message-ID: <001801d08538$ee2b9200$ca82b600$@prinpay.com>

> From: openssl-users On Behalf Of Nayna Jain
> Sent: Friday, May 01, 2015 22:37

> I have a privatekey file written using the call
PEM_write_bio_RSAPrivateKey(...)

> The file write operation has been successful.

Do you mean the PEM_write_ returned 1, or do you mean the file contains 
correct (or at least reasonable) contents? Can you read it with commandline 
'openssl pkey <file' ?

> However, when i am trying to read it via calls PEM_read_bio_PrivateKey(..)
or 
> PEM_read_bio_RSAPrivateKey(..) , it is always returning NULL.
> There is no encryption also done . It i unencrypted private key. 
> Can someone help me to understand what might be wrong.

http://www.openssl.org/support/faq.html#PROG6 
http://www.openssl.org/support/faq.html#PROG7




From doctor at doctor.nl2k.ab.ca  Sun May  3 11:54:44 2015
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Sun, 3 May 2015 05:54:44 -0600
Subject: [openssl-users] openssl 20150503 SNAP issue
Message-ID: <20150503115444.GA19929@doctor.nl2k.ab.ca>


Script started on Sun May  3 05:43:13 2015
ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150503$ make && make tes 
t
making all in crypto...
making all in crypto/objects...
making all in crypto/md4...
making all in crypto/md5...
making all in crypto/sha...
making all in crypto/mdc2...
making all in crypto/hmac...
making all in crypto/ripemd...
making all in crypto/whrlpool...
making all in crypto/des...
making all in crypto/aes...
making all in crypto/rc2...
making all in crypto/rc4...
making all in crypto/rc5...
making all in crypto/idea...
making all in crypto/bf...
making all in crypto/cast...
making all in crypto/camellia...
making all in crypto/seed...
making all in crypto/modes...
making all in crypto/bn...
making all in crypto/ec...
making all in crypto/rsa...
making all in crypto/dsa...
making all in crypto/ecdsa...
making all in crypto/dh...
making all in crypto/ecdh...
making all in crypto/dso...
making all in crypto/engine...
making all in crypto/buffer...
making all in crypto/bio...
making all in crypto/stack...
making all in crypto/lhash...
making all in crypto/rand...
making all in crypto/err...
making all in crypto/evp...
making all in crypto/asn1...
making all in crypto/pem...
making all in crypto/x509...
making all in crypto/x509v3...
making all in crypto/conf...
making all in crypto/txt_db...
making all in crypto/pkcs7...
making all in crypto/pkcs12...
making all in crypto/comp...
making all in crypto/ocsp...
making all in crypto/ui...
making all in crypto/krb5...
making all in crypto/cms...
making all in crypto/pqueue...
making all in crypto/ts...
making all in crypto/jpake...
making all in crypto/srp...
making all in crypto/store...
making all in crypto/cmac...
if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then  (cd ..; make libcrypto.so.1.0.0);  fi
[ -z "" ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude  -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso   fips_premain.c fipscanister.o  libcrypto.a -lgmp -ldl -lm -lc
making all in ssl...
if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then  (cd ..; make libssl.so.1.0.0);  fi
[ -z "" ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude  -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso   fips_premain.c fipscanister.o  libcrypto.a -lgmp -ldl -lm -lc
making all in engines...
echo 

making all in engines/ccgost...
making all in apps...
making all in test...
making all in tools...
testing...
making all in apps...
../util/shlib_wrap.sh ./destest
Doing cbcm
Doing ecb
Doing ede ecb
Doing cbc
Doing desx cbc
Doing ede cbc
Doing pcbc
Doing cfb8 cfb16 cfb32 cfb48 cfb64 cfb64() ede_cfb64() done
Doing ofb
Doing ofb64
Doing ede_ofb64
Doing cbc_cksum
Doing quad_cksum
input word alignment test 0 1 2 3
output word alignment test 0 1 2 3
fast crypt test 
../util/shlib_wrap.sh ./ideatest
ecb idea ok
cbc idea ok
cfb64 idea ok
../util/shlib_wrap.sh ./shatest
test 1 ok
test 2 ok
test 3 ok
../util/shlib_wrap.sh ./sha1test
test 1 ok
test 2 ok
test 3 ok
../util/shlib_wrap.sh ./sha256t
Testing SHA-256 ... passed.
Testing SHA-224 ... passed.
../util/shlib_wrap.sh ./sha512t
Testing SHA-512 ... passed.
Testing SHA-384 ... passed.
../util/shlib_wrap.sh ./md4test
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
test 7 ok
../util/shlib_wrap.sh ./md5test
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
test 7 ok
../util/shlib_wrap.sh ./hmactest
test 0 ok
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
../util/shlib_wrap.sh ./md2test
No MD2 support
../util/shlib_wrap.sh ./mdc2test
pad1 - ok
pad2 - ok
../util/shlib_wrap.sh ./wp_test
Testing Whirlpool ......... passed.
../util/shlib_wrap.sh ./rmdtest
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
test 7 ok
test 8 ok
../util/shlib_wrap.sh ./rc2test
ecb RC2 ok
../util/shlib_wrap.sh ./rc4test
test 0 ok
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test end processing ....................done
test multi-call ....................done
bulk test ok
../util/shlib_wrap.sh ./rc5test
ecb RC5 ok
cbc RC5 ok
../util/shlib_wrap.sh ./bftest
testing blowfish in raw ecb mode
testing blowfish in ecb mode
testing blowfish set_key
testing blowfish in cbc mode
testing blowfish in cfb64 mode
testing blowfish in ofb64
../util/shlib_wrap.sh ./casttest
ecb cast5 ok
This test will take some time....123456789ABCDEF ok
../util/shlib_wrap.sh ./randtest
test 1 done
test 2 done
test 3 done
test 4 done
starting big number library test, could take a while...
test BN_add
test BN_sub
test BN_lshift1
test BN_lshift (fixed)
test BN_lshift
test BN_rshift1
test BN_rshift
test BN_sqr
test BN_mul
test BN_div
test BN_div_word
test BN_div_recp
test BN_mod
test BN_mod_mul
test BN_mont
test BN_mod_exp
test BN_mod_exp_mont_consttime
test BN_exp
test BN_kronecker
.................++++++
....................................................................................................
test BN_mod_sqrt
.....
.....
.....
.....
.....
.....
.....
.....
...++++++++++++
.....
.......++++++++++++
.....
..............................++++++++++++
.....
.++++++++++++
.....
.++++++++++++
.....
...........................................++++++++++++
.....
..............++++++++++++
.....
..++++++++++++
.....
test BN_GF2m_add
test BN_GF2m_mod
test BN_GF2m_mod_mul
test BN_GF2m_mod_sqr
test BN_GF2m_mod_inv
test BN_GF2m_mod_div
test BN_GF2m_mod_exp
test BN_GF2m_mod_sqrt
test BN_GF2m_mod_solve_quad
running bc

verify BN_add....................................................................................................
verify BN_sub......................................................................................................................................................
verify BN_lshift1....................................................................................................
verify BN_lshift (fixed)....................................................................................................
verify BN_lshift....................................................................................................
verify BN_rshift1....................................................................................................
verify BN_rshift....................................................................................................
verify BN_sqr......................................................................................................
verify BN_mul......................................................................................................................................................
verify BN_div............................................................................................................................................................................................................................................................................................................
verify BN_div_word........................................................................................................................................................................................................
verify BN_div_recp............................................................................................................................................................................................................................................................................................................
verify BN_mod....................................................................................................
verify BN_mod_mul............................................................................................................................................................................................................................................................................................................
verify BN_mont.....
verify BN_mod_exp.....
verify BN_mod_exp_mont_consttime.....
verify BN_exp.....
verify BN_kronecker
verify BN_mod_sqrt
verify BN_GF2m_add
verify BN_GF2m_mod
verify BN_GF2m_mod_mul
verify BN_GF2m_mod_sqr
verify BN_GF2m_mod_inv
verify BN_GF2m_mod_div
verify BN_GF2m_mod_exp
verify BN_GF2m_mod_sqrt
verify BN_GF2m_mod_solve_quad
2222 tests passed
test a^b%c implementations
../util/shlib_wrap.sh ./exptest
........................................................................................................................................................................................................
done
test elliptic curves
../util/shlib_wrap.sh ./ectest
Curve defined by Weierstrass equation
     y^2 = x^3 + a*x + b  (mod 0x17)
     a = 0x1
     b = 0x1
A cyclic subgroup:
     point at infinity
     x = 0xD, y = 0x7
     x = 0x5, y = 0x4
     x = 0x11, y = 0x3
     x = 0x11, y = 0x14
     x = 0x5, y = 0x13
     x = 0xD, y = 0x10
Generator as octet string, compressed form:
     030D
Generator as octet string, uncompressed form:
     040D07
Generator as octet string, hybrid form:
     070D07
A representation of the inverse of that generator in
Jacobian projective coordinates:
     X = 0xC, Y = 0xF, Z = 0xA

SEC2 curve secp160r1 -- Generator:
     x = 0x4A96B5688EF573284664698968C38BB913CBFC82
     y = 0x23A628553168947D59DCC912042351377AC5FB32
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-192 -- Generator:
     x = 0x188DA80EB03090F67CBF20EB43A18800F4FF0AFD82FF1012
     y = 0x7192B95FFC8DA78631011ED6B24CDD573F977A11E794811
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-224 -- Generator:
     x = 0xB70E0CBD6BB4BF7F321390B94A03C1D356C21122343280D6115C1D21
     y = 0xBD376388B5F723FB4C22DFE6CD4375A05A07476444D5819985007E34
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-256 -- Generator:
     x = 0x6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296
     y = 0x4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-384 -- Generator:
     x = 0xAA87CA22BE8B05378EB1C71EF320AD746E1D3B628BA79B9859F741E082542A385502F25DBF55296C3A545E3872760AB7
     y = 0x3617DE4A96262C6F5D9E98BF9292DC29F8F41DBD289A147CE9DA3113B5F0B8C00A60B1CE1D7E819D7A431D7C90EA0E5F
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-521 -- Generator:
     x = 0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66
     y = 0x11839296A789A3BC0045C8A5FB42C7D1BD998F54449579B446817AFBD17273E662C97EE72995EF42640C550B9013FAD0761353C7086A272C24088BE94769FD16650
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok
combined multiplication ..... ok


Curve defined by Weierstrass equation
     y^2 + x*y = x^3 + a*x^2 + b  (mod 0x13)
     a = 0x3
     b = 0x1
(0x... means binary polynomial)
A cyclic subgroup:
     point at infinity
     x = 0x6, y = 0x8
     x = 0x1, y = 0xD
     x = 0x7, y = 0x2
     x = 0x0, y = 0x1
     x = 0x7, y = 0x5
     x = 0x1, y = 0xC
     x = 0x6, y = 0xE

Generator as octet string, uncompressed form:
     040608

NIST curve K-163 -- Generator:
     x = 0x2FE13C0537BBC11ACAA07D793DE4E6D5E5C94EEE8
     y = 0x289070FB05D38FF58321F2E800536D538CCDAA3D9
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-163 -- Generator:
     x = 0x3F0EBA16286A2D57EA0991168D4994637E8343E36
     y = 0xD51FBC6C71A0094FA2CDD545B11C5C0C797324F1
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve K-233 -- Generator:
     x = 0x17232BA853A7E731AF129F22FF4149563A419C26BF50A4C9D6EEFAD6126
     y = 0x1DB537DECE819B7F70F555A67C427A8CD9BF18AEB9B56E0C11056FAE6A3
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-233 -- Generator:
     x = 0xFAC9DFCBAC8313BB2139F1BB755FEF65BC391F8B36F8F8EB7371FD558B
     y = 0x1006A08A41903350678E58528BEBF8A0BEFF867A7CA36716F7E01F81052
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve K-283 -- Generator:
     x = 0x503213F78CA44883F1A3B8162F188E553CD265F23C1567A16876913B0C2AC2458492836
     y = 0x1CCDA380F1C9E318D90F95D07E5426FE87E45C0E8184698E45962364E34116177DD2259
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-283 -- Generator:
     x = 0x5F939258DB7DD90E1934F8C70B0DFEC2EED25B8557EAC9C80E2E198F8CDBECD86B12053
     y = 0x3676854FE24141CB98FE6D4B20D02B4516FF702350EDDB0826779C813F0DF45BE8112F4
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve K-409 -- Generator:
     x = 0x60F05F658F49C1AD3AB1890F7184210EFD0987E307C84C27ACCFB8F9F67CC2C460189EB5AAAA62EE222EB1B35540CFE9023746
     y = 0x1E369050B7C4E42ACBA1DACBF04299C3460782F918EA427E6325165E9EA10E3DA5F6C42E9C55215AA9CA27A5863EC48D8E0286B
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-409 -- Generator:
     x = 0x15D4860D088DDB3496B0C6064756260441CDE4AF1771D4DB01FFE5B34E59703DC255A868A1180515603AEAB60794E54BB7996A7
     y = 0x61B1CFAB6BE5F32BBFA78324ED106A7636B9C5A7BD198D0158AA4F5488D08F38514F1FDF4B4F40D2181B3681C364BA0273C706
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve K-571 -- Generator:
     x = 0x26EB7A859923FBC82189631F8103FE4AC9CA2970012D5D46024804801841CA44370958493B205E647DA304DB4CEB08CBBD1BA39494776FB988B47174DCA88C7E2945283A01C8972
     y = 0x349DC807F4FBF374F4AEADE3BCA95314DD58CEC9F307A54FFC61EFC006D8A2C9D4979C0AC44AEA74FBEBBB9F772AEDCB620B01A7BA7AF1B320430C8591984F601CD4C143EF1C7A3
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-571 -- Generator:
     x = 0x303001D34B856296C16C0D40D3CD7750A93D1D2955FA80AA5F40FC8DB7B2ABDBDE53950F4C0D293CDD711A35B67FB1499AE60038614F1394ABFA3B4C850D927E1E7769C8EEC2D19
     y = 0x37BF27342DA639B6DCCFFFEB73D69D78C6C27A6009CBBCA1980F8533921E8A684423E43BAB08A576291AF8F461BB2A8B3531D2F0485C19B16E2F1516E23DD3C1A4827AF1B8AC15B
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok
combined multiplication ..... ok

testing internal curves: ................................................................................. ok

test ecdsa
../util/shlib_wrap.sh ./ecdsatest
some tests from X9.62:
testing prime192v1: .... ok
testing prime239v1: .... ok
testing c2tnb191v1: .... ok
testing c2tnb239v1: .... ok

testing ECDSA_sign() and ECDSA_verify() with some internal curves:
secp160k1: ........ ok
secp160r1: ........ ok
secp160r2: ........ ok
secp192k1: ........ ok
secp224k1: ........ ok
secp224r1: ........ ok
secp256k1: ........ ok
secp384r1: ........ ok
secp521r1: ........ ok
prime192v1: ........ ok
prime192v2: ........ ok
prime192v3: ........ ok
prime239v1: ........ ok
prime239v2: ........ ok
prime239v3: ........ ok
prime256v1: ........ ok
sect163k1: ........ ok
sect163r1: ........ ok
sect163r2: ........ ok
sect193r1: ........ ok
sect193r2: ........ ok
sect233k1: ........ ok
sect233r1: ........ ok
sect239k1: ........ ok
sect283k1: ........ ok
sect283r1: ........ ok
sect409k1: ........ ok
sect409r1: ........ ok
sect571k1: ........ ok
sect571r1: ........ ok
c2pnb163v1: ........ ok
c2pnb163v2: ........ ok
c2pnb163v3: ........ ok
c2pnb176v1: ........ ok
c2tnb191v1: ........ ok
c2tnb191v2: ........ ok
c2tnb191v3: ........ ok
c2pnb208w1: ........ ok
c2tnb239v1: ........ ok
c2tnb239v2: ........ ok
c2tnb239v3: ........ ok
c2pnb272w1: ........ ok
c2pnb304w1: ........ ok
c2tnb359v1: ........ ok
c2pnb368w1: ........ ok
c2tnb431r1: ........ ok
wap-wsg-idm-ecid-wtls3: ........ ok
wap-wsg-idm-ecid-wtls5: ........ ok
wap-wsg-idm-ecid-wtls7: ........ ok
wap-wsg-idm-ecid-wtls9: ........ ok
wap-wsg-idm-ecid-wtls10: ........ ok
wap-wsg-idm-ecid-wtls11: ........ ok
wap-wsg-idm-ecid-wtls12: ........ ok
brainpoolP160r1: ........ ok
brainpoolP160t1: ........ ok
brainpoolP192r1: ........ ok
brainpoolP192t1: ........ ok
brainpoolP224r1: ........ ok
brainpoolP224t1: ........ ok
brainpoolP256r1: ........ ok
brainpoolP256t1: ........ ok
brainpoolP320r1: ........ ok
brainpoolP320t1: ........ ok
brainpoolP384r1: ........ ok
brainpoolP384t1: ........ ok
brainpoolP512r1: ........ ok
brainpoolP512t1: ........ ok

ECDSA test passed
test ecdh
../util/shlib_wrap.sh ./ecdhtest
Testing key generation with NIST Prime-Curve P-192 .... ok
Testing key generation with NIST Prime-Curve P-224 .... ok
Testing key generation with NIST Prime-Curve P-256 .... ok
Testing key generation with NIST Prime-Curve P-384 .... ok
Testing key generation with NIST Prime-Curve P-521 .... ok
Testing key generation with NIST Binary-Curve K-163 .... ok
Testing key generation with NIST Binary-Curve B-163 .... ok
Testing key generation with NIST Binary-Curve K-233 .... ok
Testing key generation with NIST Binary-Curve B-233 .... ok
Testing key generation with NIST Binary-Curve K-283 .... ok
Testing key generation with NIST Binary-Curve B-283 .... ok
Testing key generation with NIST Binary-Curve K-409 .... ok
Testing key generation with NIST Binary-Curve B-409 .... ok
Testing key generation with NIST Binary-Curve K-571 .... ok
Testing key generation with NIST Binary-Curve B-571 .... ok
Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP256r1 ok
Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP384r1 ok
Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP512r1 ok
cat
base64
aes-128-cbc
aes-128-cbc base64
aes-128-ecb
aes-128-ecb base64
aes-192-cbc
aes-192-cbc base64
aes-192-ecb
aes-192-ecb base64
aes-256-cbc
aes-256-cbc base64
aes-256-ecb
aes-256-ecb base64
base64
base64 base64
bf
bf base64
bf-cbc
bf-cbc base64
bf-cfb
bf-cfb base64
bf-ecb
bf-ecb base64
bf-ofb
bf-ofb base64
camellia-128-cbc
camellia-128-cbc base64
camellia-128-ecb
camellia-128-ecb base64
camellia-192-cbc
camellia-192-cbc base64
camellia-192-ecb
camellia-192-ecb base64
camellia-256-cbc
camellia-256-cbc base64
camellia-256-ecb
camellia-256-ecb base64
cast
cast base64
cast-cbc
cast-cbc base64
cast5-cbc
cast5-cbc base64
cast5-cfb
cast5-cfb base64
cast5-ecb
cast5-ecb base64
cast5-ofb
cast5-ofb base64
des
des base64
des-cbc
des-cbc base64
des-cfb
des-cfb base64
des-ecb
des-ecb base64
des-ede
des-ede base64
des-ede-cbc
des-ede-cbc base64
des-ede-cfb
des-ede-cfb base64
des-ede-ofb
des-ede-ofb base64
des-ede3
des-ede3 base64
des-ede3-cbc
des-ede3-cbc base64
des-ede3-cfb
des-ede3-cfb base64
des-ede3-ofb
des-ede3-ofb base64
des-ofb
des-ofb base64
des3
des3 base64
desx
desx base64
idea
idea base64
idea-cbc
idea-cbc base64
idea-cfb
idea-cfb base64
idea-ecb
idea-ecb base64
idea-ofb
idea-ofb base64
rc2
rc2 base64
rc2-40-cbc
rc2-40-cbc base64
rc2-64-cbc
rc2-64-cbc base64
rc2-cbc
rc2-cbc base64
rc2-cfb
rc2-cfb base64
rc2-ecb
rc2-ecb base64
rc2-ofb
rc2-ofb base64
rc4
rc4 base64
rc4-40
rc4-40 base64
rc5
rc5 base64
rc5-cbc
rc5-cbc base64
rc5-cfb
rc5-cfb base64
rc5-ecb
rc5-ecb base64
rc5-ofb
rc5-ofb base64
seed
seed base64
seed-cbc
seed-cbc base64
seed-cfb
seed-cfb base64
seed-ecb
seed-ecb base64
seed-ofb
seed-ofb base64
zlib
zlib base64
echo test normal x509v1 certificate
test normal x509v1 certificate
sh ./tx509 2>/dev/null
testing X509 conversions
p -> d
p -> n
p -> p
d -> d
n -> d
p -> d
d -> n
n -> n
p -> n
d -> p
n -> p
p -> p
echo test first x509v3 certificate
test first x509v3 certificate
sh ./tx509 v3-cert1.pem 2>/dev/null
testing X509 conversions
p -> d
p -> n
p -> p
d -> d
n -> d
p -> d
d -> n
n -> n
p -> n
d -> p
n -> p
p -> p
echo test second x509v3 certificate
test second x509v3 certificate
sh ./tx509 v3-cert2.pem 2>/dev/null
testing X509 conversions
p -> d
p -> n
p -> p
d -> d
n -> d
p -> d
d -> n
n -> n
p -> n
d -> p
n -> p
p -> p
rsa
testing rsa conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
../util/shlib_wrap.sh ./rsa_test
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
testing crl conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing session-id conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
Generate and verify a certificate request
generating certificate request
rsa
There should be a 2 sequences of .'s and some +'s.
There should not be more that at most 80 per line
This could take some time.
Generating a 1024 bit RSA private key
....................++++++
..................++++++
writing new private key to 'testkey.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
State or Province Name (full name) [Queensland]:
Locality Name (eg, city) []:Brisbane
Organization Name (eg, company) []:CryptSoft Pty Ltd
Organizational Unit Name (eg, section) []:.
Common Name (eg, YOUR name) []:Eric Young
Email Address []:eay at mincom.oz.au
verify OK
testing req conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing req conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing pkcs7 conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing pkcs7 conversions (2)
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
The following command should have some OK's and some failures
There are definitly a few expired certificates
../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs/demo ../certs/demo/*.pem
Segmentation fault
*** Error code 139

Stop.
*** Error code 1

Stop.
ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150503$ x
sh: x: command not found
ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150503$ exit
exit

Script done on Sun May  3 05:46:57 2015

Please fix.  This was working in 20150502 Snapshots.

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Alberta time to save the province from corruption! Vote Liberal on 5 May 2015!!

From bird_112 at hotmail.com  Sun May  3 14:07:43 2015
From: bird_112 at hotmail.com (jack seth)
Date: Sun, 3 May 2015 09:07:43 -0500
Subject: [openssl-users] Working with large DH parameters
In-Reply-To: <SNT152-W688E316B2714C76C3B5924BFE80@phx.gbl>
References: <SNT152-W688E316B2714C76C3B5924BFE80@phx.gbl>
Message-ID: <SNT152-W808E9499C8ECD6131B7873BFD30@phx.gbl>

Can someone offer an opinion on my questions below?  Thanks!

> From: bird_112 at hotmail.com
> To: openssl-users at openssl.org
> Subject: Working with large DH parameters
> Date: Tue, 28 Apr 2015 09:26:25 -0500
> 
> Ok I have been doing some experiments with OpenVPN and I can connect using 10000 bit DH parameters.  Any bigger than that up to at least 13824 I get the following 'modulus too large' error on the client log:
> 
> TLS_ERROR: BIO read tls_read_plaintext error: error:05066067:Diffie-Hellman routines:COMPUTE_KEY:modulus too large: error:14098005:SSL routines:SSL3_SEND_CLIENT_KEY_EXCHANGE:DH lib
> Wed Apr 22 07:08:58 2015 TLS Error: TLS object -> incoming plaintext read error
> Wed Apr 22 07:08:58 2015 TLS Error: TLS handshake failed
> 
> Something interesting/weird also happened.  I tried to test 10001, 10002, and 10004 bit DH to find the exact place I would get the 'modulus too large' error.  But the server log reported the DH parameters being 10008 instead.  I did a test at 15104 that gave the same error but then I tried two more times and the client just sat at the 'initial packet point' like it does with the 16384 bit parameters.  So somewhere between 13824 and 16384 it switches between the error above and just sitting there 'frozen'.
> 
> Questions: 1. Can the modulus error be cured?  2. Do you think the same modulus error is going on when the client appears to freeze with parameters larger than 13824 or is something else going (i.e. why does it freeze instead of giving the 'modulus error')?  3. Why does the server log report 10001, 10002, 10004 bit DH as 10008? 		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150503/8d5da00b/attachment.html>

From kurt at roeckx.be  Sun May  3 15:57:26 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 3 May 2015 17:57:26 +0200
Subject: [openssl-users] Working with large DH parameters
In-Reply-To: <SNT152-W688E316B2714C76C3B5924BFE80@phx.gbl>
References: <SNT152-W688E316B2714C76C3B5924BFE80@phx.gbl>
Message-ID: <20150503155726.GA30874@roeckx.be>

On Tue, Apr 28, 2015 at 09:26:25AM -0500, jack seth wrote:
> Ok I have been doing some experiments with OpenVPN and I can connect using 10000 bit DH parameters.? Any bigger than that up to at least 13824 I get the following 'modulus too large' error on the client log:
> 
> TLS_ERROR: BIO read tls_read_plaintext error: error:05066067:Diffie-Hellman routines:COMPUTE_KEY:modulus too large: error:14098005:SSL routines:SSL3_SEND_CLIENT_KEY_EXCHANGE:DH lib
> Wed Apr 22 07:08:58 2015 TLS Error: TLS object -> incoming plaintext read error
> Wed Apr 22 07:08:58 2015 TLS Error: TLS handshake failed
> 
> Something interesting/weird also happened.? I tried to test 10001, 10002, and 10004 bit DH to find the exact place I would get the 'modulus too large' error.? But the server log reported the DH parameters being 10008 instead.? I did a test at 15104 that gave the same error but then I tried two more times and the client just sat at the 'initial packet point' like it does with the 16384 bit parameters.? So somewhere between 13824 and 16384 it switches between the error above and just sitting there 'frozen'.
> 
> Questions: 1. Can the modulus error be cured?? 2. Do you think the same modulus error is going on when the client appears to freeze with parameters larger than 13824 or is something else going (i.e. why does it freeze instead of giving the 'modulus error')?? 3. Why does the server log report 10001, 10002, 10004 bit DH as 10008? 		 	   		  

There is a limit of 10000:
#define OPENSSL_DH_MAX_MODULUS_BITS    10000

I suggest you do not change this.  It just gets slower without
adding security.

I have no idea why it would freeze with something larger than
13824.

I'm not sure what is logging the size, but it might be using
DH_size()*8 to log it.  I don't think their currently is an API
that returns it in bits.


Kurt


From rsalz at akamai.com  Sun May  3 18:21:15 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 3 May 2015 18:21:15 +0000
Subject: [openssl-users] [openssl-dev] openssl 20150503 SNAP issue
In-Reply-To: <20150503115444.GA19929@doctor.nl2k.ab.ca>
References: <20150503115444.GA19929@doctor.nl2k.ab.ca>
Message-ID: <5d14748f44fa4ec4a9b7b23616566bd5@usma1ex-dag1mb4.msg.corp.akamai.com>

SNAP releases are just that, snapshots.

If you see the same problem twice, say, it is worth reporting.


From googleersatz at oliverniebuhr.de  Mon May  4 09:20:04 2015
From: googleersatz at oliverniebuhr.de (Oliver Niebuhr)
Date: Mon, 04 May 2015 11:20:04 +0200
Subject: [openssl-users] Bug(?) in 1.0.2a: Target Already defined
Message-ID: <554739C4.1070605@oliverniebuhr.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello People.

My Name is Oliver and I am new since today. I just joined because I
maybe found a Bug or Issue in Version 1.0.2a:

Whenever I try to run:

./Configure ?prefix=$PWD/dist no-idea no-mdc2 no-rc5 shared mingw64

or

./Configure ?prefix=$PWD/dist no-idea no-mdc2 no-rc5 shared mingw

I get the following Error Message:
"./Configure prefix=$PWD/dist no-idea no-mdc2 no-rc5 shared mingw64
target already defined - prefix=/c/openssl-1.0.2a/dist (offending arg:
mingw64)"

[The same Error comes up with 'offending arg: mingw' for the x86 Version
]

I never got this Error before. It all started with Version 1.0.2a. As a
Noob, I am out of Ideas.

Google says, in Version 1.0.0d, to edit or remove a 'die' line". But I
am not sure what this is.

Build Machine:
OS: Windows 7 x64
Used Shell: MSYS1
Compiler:
MingW x86: 4.9.2 Release Posix-Dwarf, rt_v3, Revision 1
MingW x64: 4.9.2 Release Posix-SEH, rt_v3, Revision 1

If I want to compile x86 DLL's, I put the MingW32 Compiler in the System
Path. And vice versa for the MingW64 OpenSSL DLL's. Before OpenSLL
1.0.2a, it always worked for me this way.

But even removing all Traces from the User and System Path Settings, did
not change anything.

Steps to compile:
1.) tar xvzf openssl-1.0.2a.tar.gz
2.) cd openssl-1.0.2a
3.) ./Configure ?prefix=$PWD/dist no-idea no-mdc2 no-rc5 shared mingw64
4.) [Normally, if all would work]: make depend && make && make install

I just need the OpenSSL DLL's to use them with the Qt Framework
(self-compiled MingW Variant. Like I said, my OpenSSL knowledge is still
limited. Any Hint or Tip would be much appreciated!

Thanks :)
Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJVRznCAAoJEPq9qaaq4qg9qfMP/0D7eh98CjyG3uZOBPUHBS/x
zZSKYZLRaC14aSRMERQt8rPe3Gr0pJybY9kf5eENiIY5uk3cZTSLvNTo7jjxS+RX
QshSc6dfevB+bVbL8cciD6/ohs2CZYpCHDJjpp7uNyJfxneisR7DTJ54JB7dSjkb
mbbAqmpsgza+Vt5lJzzQgIqhigcrJSGq23PnDV1UNDWbAABtTq9XBpO6UJ7zbE4j
0MqScnM+FazIW50sxSik6rmhDTkKOijGuluR5EVbZbRZ4/HnoMbbiiUbgLAe56su
EaIMuld9dExL/8QvPzLwFWK/kVK+XWKotdoqW2/HiMWuoz1KZ3o5g4T8iXFQc8G2
HsXpVp+VTuqkKtrcUpSO3uuMcHhPCYcJlTKy5L9jPwjztxOn3h7gIZU6r0gGwvMk
Z9kOu9E8odgwr398bk253GeaN1fwocffT1IrcM3lHbKg+5ZE/6fPHMUG/PIOPGGD
OaHOsjA/AbyO5oPLSXP5TdY9MxGnfWbxOJWSpozWQBbzsW28DZ3ue/c45bZIw9jN
Ota+iO6D1pe5zNWmRQ+GLVmBPCA7ig83ndu6+Bu+PmFpUadbLlFadULh3gLIqjt0
wHF3KgWs3pkANXKR1vTHu5ijb67E7v39IIx3kUbrcdVShDmNhULXsymU5g1vfYkh
Gl+Ok3izukEYSVvKtsAk
=9OpK
-----END PGP SIGNATURE-----

From doctor at doctor.nl2k.ab.ca  Mon May  4 13:21:11 2015
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 4 May 2015 07:21:11 -0600
Subject: [openssl-users] openssl-1.0.2-stable-SNAP-20150504 error
Message-ID: <20150504132111.GA10272@doctor.nl2k.ab.ca>

This also occured in openssl-1.0.2-stable-SNAP-20150503


Script started on Mon May  4 07:06:41 2015
ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ egrep bsdi Confi 
gure
"bsdi-elf-gcc",     "gcc:-DPERL5 -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall::(unknown)::-ldl:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
"debug-bsdi-x86-elf",   "gcc3:-DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g::${BSDthreads}::-lgmp -ldl -lm -lc:THIRY_TWO_BIT_LONG RC4_CHUNK BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ mak && make test 
ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ mak && make test
sh: mak: command not found
ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ ^k^ke
make && make test
making all in crypto...
making all in crypto/objects...
making all in crypto/md4...
making all in crypto/md5...
making all in crypto/sha...
making all in crypto/mdc2...
making all in crypto/hmac...
making all in crypto/ripemd...
making all in crypto/whrlpool...
making all in crypto/des...
making all in crypto/aes...
making all in crypto/rc2...
making all in crypto/rc4...
making all in crypto/rc5...
making all in crypto/idea...
making all in crypto/bf...
making all in crypto/cast...
making all in crypto/camellia...
making all in crypto/seed...
making all in crypto/modes...
making all in crypto/bn...
making all in crypto/ec...
making all in crypto/rsa...
making all in crypto/dsa...
making all in crypto/ecdsa...
making all in crypto/dh...
making all in crypto/ecdh...
making all in crypto/dso...
making all in crypto/engine...
making all in crypto/buffer...
making all in crypto/bio...
making all in crypto/stack...
making all in crypto/lhash...
making all in crypto/rand...
making all in crypto/err...
making all in crypto/evp...
making all in crypto/asn1...
making all in crypto/pem...
making all in crypto/x509...
making all in crypto/x509v3...
making all in crypto/conf...
making all in crypto/txt_db...
making all in crypto/pkcs7...
making all in crypto/pkcs12...
making all in crypto/comp...
making all in crypto/ocsp...
making all in crypto/ui...
making all in crypto/krb5...
making all in crypto/cms...
making all in crypto/pqueue...
making all in crypto/ts...
making all in crypto/jpake...
making all in crypto/srp...
making all in crypto/store...
making all in crypto/cmac...
if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then  (cd ..; make libcrypto.so.1.0.0);  fi
[ -z "" ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude  -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso   fips_premain.c fipscanister.o  libcrypto.a -lgmp -ldl -lm -lc
making all in ssl...
if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then  (cd ..; make libssl.so.1.0.0);  fi
[ -z "" ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude  -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso   fips_premain.c fipscanister.o  libcrypto.a -lgmp -ldl -lm -lc
making all in engines...
echo 

making all in engines/ccgost...
making all in apps...
making all in test...
making all in tools...
testing...
making all in apps...
../util/shlib_wrap.sh ./destest
Doing cbcm
Doing ecb
Doing ede ecb
Doing cbc
Doing desx cbc
Doing ede cbc
Doing pcbc
Doing cfb8 cfb16 cfb32 cfb48 cfb64 cfb64() ede_cfb64() done
Doing ofb
Doing ofb64
Doing ede_ofb64
Doing cbc_cksum
Doing quad_cksum
input word alignment test 0 1 2 3
output word alignment test 0 1 2 3
fast crypt test 
../util/shlib_wrap.sh ./ideatest
ecb idea ok
cbc idea ok
cfb64 idea ok
../util/shlib_wrap.sh ./shatest
test 1 ok
test 2 ok
test 3 ok
../util/shlib_wrap.sh ./sha1test
test 1 ok
test 2 ok
test 3 ok
../util/shlib_wrap.sh ./sha256t
Testing SHA-256 ... passed.
Testing SHA-224 ... passed.
../util/shlib_wrap.sh ./sha512t
Testing SHA-512 ... passed.
Testing SHA-384 ... passed.
../util/shlib_wrap.sh ./md4test
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
test 7 ok
../util/shlib_wrap.sh ./md5test
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
test 7 ok
../util/shlib_wrap.sh ./hmactest
test 0 ok
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
../util/shlib_wrap.sh ./md2test
No MD2 support
../util/shlib_wrap.sh ./mdc2test
pad1 - ok
pad2 - ok
../util/shlib_wrap.sh ./wp_test
Testing Whirlpool ......... passed.
../util/shlib_wrap.sh ./rmdtest
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test 6 ok
test 7 ok
test 8 ok
../util/shlib_wrap.sh ./rc2test
ecb RC2 ok
../util/shlib_wrap.sh ./rc4test
test 0 ok
test 1 ok
test 2 ok
test 3 ok
test 4 ok
test 5 ok
test end processing ....................done
test multi-call ....................done
bulk test ok
../util/shlib_wrap.sh ./rc5test
ecb RC5 ok
cbc RC5 ok
../util/shlib_wrap.sh ./bftest
testing blowfish in raw ecb mode
testing blowfish in ecb mode
testing blowfish set_key
testing blowfish in cbc mode
testing blowfish in cfb64 mode
testing blowfish in ofb64
../util/shlib_wrap.sh ./casttest
ecb cast5 ok
This test will take some time....123456789ABCDEF ok
../util/shlib_wrap.sh ./randtest
test 1 done
test 2 done
test 3 done
test 4 done
starting big number library test, could take a while...
test BN_add
test BN_sub
test BN_lshift1
test BN_lshift (fixed)
test BN_lshift
test BN_rshift1
test BN_rshift
test BN_sqr
test BN_mul
test BN_div
test BN_div_word
test BN_div_recp
test BN_mod
test BN_mod_mul
test BN_mont
test BN_mod_exp
test BN_mod_exp_mont_consttime
test BN_exp
test BN_kronecker
....++++++
....................................................................................................
test BN_mod_sqrt
.....
.....
.....
.....
.....
.....
.....
.....
......++++++++++++
.....
............++++++++++++
.....
.....++++++++++++
.....
.................++++++++++++
.....
.............++++++++++++
.....
..++++++++++++
.....
.........++++++++++++
.....
..++++++++++++
.....
test BN_GF2m_add
test BN_GF2m_mod
test BN_GF2m_mod_mul
test BN_GF2m_mod_sqr
test BN_GF2m_mod_inv
test BN_GF2m_mod_div
test BN_GF2m_mod_exp
test BN_GF2m_mod_sqrt
test BN_GF2m_mod_solve_quad
running bc

verify BN_add....................................................................................................
verify BN_sub......................................................................................................................................................
verify BN_lshift1....................................................................................................
verify BN_lshift (fixed)....................................................................................................
verify BN_lshift....................................................................................................
verify BN_rshift1....................................................................................................
verify BN_rshift....................................................................................................
verify BN_sqr......................................................................................................
verify BN_mul......................................................................................................................................................
verify BN_div............................................................................................................................................................................................................................................................................................................
verify BN_div_word........................................................................................................................................................................................................
verify BN_div_recp............................................................................................................................................................................................................................................................................................................
verify BN_mod....................................................................................................
verify BN_mod_mul............................................................................................................................................................................................................................................................................................................
verify BN_mont.....
verify BN_mod_exp.....
verify BN_mod_exp_mont_consttime.....
verify BN_exp.....
verify BN_kronecker
verify BN_mod_sqrt
verify BN_GF2m_add
verify BN_GF2m_mod
verify BN_GF2m_mod_mul
verify BN_GF2m_mod_sqr
verify BN_GF2m_mod_inv
verify BN_GF2m_mod_div
verify BN_GF2m_mod_exp
verify BN_GF2m_mod_sqrt
verify BN_GF2m_mod_solve_quad
2222 tests passed
test a^b%c implementations
../util/shlib_wrap.sh ./exptest
........................................................................................................................................................................................................
done
test elliptic curves
../util/shlib_wrap.sh ./ectest
Curve defined by Weierstrass equation
     y^2 = x^3 + a*x + b  (mod 0x17)
     a = 0x1
     b = 0x1
A cyclic subgroup:
     point at infinity
     x = 0xD, y = 0x7
     x = 0x5, y = 0x4
     x = 0x11, y = 0x3
     x = 0x11, y = 0x14
     x = 0x5, y = 0x13
     x = 0xD, y = 0x10
Generator as octet string, compressed form:
     030D
Generator as octet string, uncompressed form:
     040D07
Generator as octet string, hybrid form:
     070D07
A representation of the inverse of that generator in
Jacobian projective coordinates:
     X = 0xC, Y = 0xF, Z = 0xA

SEC2 curve secp160r1 -- Generator:
     x = 0x4A96B5688EF573284664698968C38BB913CBFC82
     y = 0x23A628553168947D59DCC912042351377AC5FB32
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-192 -- Generator:
     x = 0x188DA80EB03090F67CBF20EB43A18800F4FF0AFD82FF1012
     y = 0x7192B95FFC8DA78631011ED6B24CDD573F977A11E794811
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-224 -- Generator:
     x = 0xB70E0CBD6BB4BF7F321390B94A03C1D356C21122343280D6115C1D21
     y = 0xBD376388B5F723FB4C22DFE6CD4375A05A07476444D5819985007E34
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-256 -- Generator:
     x = 0x6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296
     y = 0x4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-384 -- Generator:
     x = 0xAA87CA22BE8B05378EB1C71EF320AD746E1D3B628BA79B9859F741E082542A385502F25DBF55296C3A545E3872760AB7
     y = 0x3617DE4A96262C6F5D9E98BF9292DC29F8F41DBD289A147CE9DA3113B5F0B8C00A60B1CE1D7E819D7A431D7C90EA0E5F
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve P-521 -- Generator:
     x = 0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66
     y = 0x11839296A789A3BC0045C8A5FB42C7D1BD998F54449579B446817AFBD17273E662C97EE72995EF42640C550B9013FAD0761353C7086A272C24088BE94769FD16650
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok
combined multiplication ..... ok


Curve defined by Weierstrass equation
     y^2 + x*y = x^3 + a*x^2 + b  (mod 0x13)
     a = 0x3
     b = 0x1
(0x... means binary polynomial)
A cyclic subgroup:
     point at infinity
     x = 0x6, y = 0x8
     x = 0x1, y = 0xD
     x = 0x7, y = 0x2
     x = 0x0, y = 0x1
     x = 0x7, y = 0x5
     x = 0x1, y = 0xC
     x = 0x6, y = 0xE

Generator as octet string, uncompressed form:
     040608

NIST curve K-163 -- Generator:
     x = 0x2FE13C0537BBC11ACAA07D793DE4E6D5E5C94EEE8
     y = 0x289070FB05D38FF58321F2E800536D538CCDAA3D9
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-163 -- Generator:
     x = 0x3F0EBA16286A2D57EA0991168D4994637E8343E36
     y = 0xD51FBC6C71A0094FA2CDD545B11C5C0C797324F1
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve K-233 -- Generator:
     x = 0x17232BA853A7E731AF129F22FF4149563A419C26BF50A4C9D6EEFAD6126
     y = 0x1DB537DECE819B7F70F555A67C427A8CD9BF18AEB9B56E0C11056FAE6A3
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-233 -- Generator:
     x = 0xFAC9DFCBAC8313BB2139F1BB755FEF65BC391F8B36F8F8EB7371FD558B
     y = 0x1006A08A41903350678E58528BEBF8A0BEFF867A7CA36716F7E01F81052
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve K-283 -- Generator:
     x = 0x503213F78CA44883F1A3B8162F188E553CD265F23C1567A16876913B0C2AC2458492836
     y = 0x1CCDA380F1C9E318D90F95D07E5426FE87E45C0E8184698E45962364E34116177DD2259
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-283 -- Generator:
     x = 0x5F939258DB7DD90E1934F8C70B0DFEC2EED25B8557EAC9C80E2E198F8CDBECD86B12053
     y = 0x3676854FE24141CB98FE6D4B20D02B4516FF702350EDDB0826779C813F0DF45BE8112F4
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve K-409 -- Generator:
     x = 0x60F05F658F49C1AD3AB1890F7184210EFD0987E307C84C27ACCFB8F9F67CC2C460189EB5AAAA62EE222EB1B35540CFE9023746
     y = 0x1E369050B7C4E42ACBA1DACBF04299C3460782F918EA427E6325165E9EA10E3DA5F6C42E9C55215AA9CA27A5863EC48D8E0286B
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-409 -- Generator:
     x = 0x15D4860D088DDB3496B0C6064756260441CDE4AF1771D4DB01FFE5B34E59703DC255A868A1180515603AEAB60794E54BB7996A7
     y = 0x61B1CFAB6BE5F32BBFA78324ED106A7636B9C5A7BD198D0158AA4F5488D08F38514F1FDF4B4F40D2181B3681C364BA0273C706
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve K-571 -- Generator:
     x = 0x26EB7A859923FBC82189631F8103FE4AC9CA2970012D5D46024804801841CA44370958493B205E647DA304DB4CEB08CBBD1BA39494776FB988B47174DCA88C7E2945283A01C8972
     y = 0x349DC807F4FBF374F4AEADE3BCA95314DD58CEC9F307A54FFC61EFC006D8A2C9D4979C0AC44AEA74FBEBBB9F772AEDCB620B01A7BA7AF1B320430C8591984F601CD4C143EF1C7A3
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok

NIST curve B-571 -- Generator:
     x = 0x303001D34B856296C16C0D40D3CD7750A93D1D2955FA80AA5F40FC8DB7B2ABDBDE53950F4C0D293CDD711A35B67FB1499AE60038614F1394ABFA3B4C850D927E1E7769C8EEC2D19
     y = 0x37BF27342DA639B6DCCFFFEB73D69D78C6C27A6009CBBCA1980F8533921E8A684423E43BAB08A576291AF8F461BB2A8B3531D2F0485C19B16E2F1516E23DD3C1A4827AF1B8AC15B
verify degree ... ok
verify group order .... ok
long/negative scalar tests allowing precomputation ... without precomputation ... ok
combined multiplication ..... ok

testing internal curves: ................................................................................. ok

test ecdsa
../util/shlib_wrap.sh ./ecdsatest
some tests from X9.62:
testing prime192v1: .... ok
testing prime239v1: .... ok
testing c2tnb191v1: .... ok
testing c2tnb239v1: .... ok

testing ECDSA_sign() and ECDSA_verify() with some internal curves:
secp160k1: ........ ok
secp160r1: ........ ok
secp160r2: ........ ok
secp192k1: ........ ok
secp224k1: ........ ok
secp224r1: ........ ok
secp256k1: ........ ok
secp384r1: ........ ok
secp521r1: ........ ok
prime192v1: ........ ok
prime192v2: ........ ok
prime192v3: ........ ok
prime239v1: ........ ok
prime239v2: ........ ok
prime239v3: ........ ok
prime256v1: ........ ok
sect163k1: ........ ok
sect163r1: ........ ok
sect163r2: ........ ok
sect193r1: ........ ok
sect193r2: ........ ok
sect233k1: ........ ok
sect233r1: ........ ok
sect239k1: ........ ok
sect283k1: ........ ok
sect283r1: ........ ok
sect409k1: ........ ok
sect409r1: ........ ok
sect571k1: ........ ok
sect571r1: ........ ok
c2pnb163v1: ........ ok
c2pnb163v2: ........ ok
c2pnb163v3: ........ ok
c2pnb176v1: ........ ok
c2tnb191v1: ........ ok
c2tnb191v2: ........ ok
c2tnb191v3: ........ ok
c2pnb208w1: ........ ok
c2tnb239v1: ........ ok
c2tnb239v2: ........ ok
c2tnb239v3: ........ ok
c2pnb272w1: ........ ok
c2pnb304w1: ........ ok
c2tnb359v1: ........ ok
c2pnb368w1: ........ ok
c2tnb431r1: ........ ok
wap-wsg-idm-ecid-wtls3: ........ ok
wap-wsg-idm-ecid-wtls5: ........ ok
wap-wsg-idm-ecid-wtls7: ........ ok
wap-wsg-idm-ecid-wtls9: ........ ok
wap-wsg-idm-ecid-wtls10: ........ ok
wap-wsg-idm-ecid-wtls11: ........ ok
wap-wsg-idm-ecid-wtls12: ........ ok
brainpoolP160r1: ........ ok
brainpoolP160t1: ........ ok
brainpoolP192r1: ........ ok
brainpoolP192t1: ........ ok
brainpoolP224r1: ........ ok
brainpoolP224t1: ........ ok
brainpoolP256r1: ........ ok
brainpoolP256t1: ........ ok
brainpoolP320r1: ........ ok
brainpoolP320t1: ........ ok
brainpoolP384r1: ........ ok
brainpoolP384t1: ........ ok
brainpoolP512r1: ........ ok
brainpoolP512t1: ........ ok

ECDSA test passed
test ecdh
../util/shlib_wrap.sh ./ecdhtest
Testing key generation with NIST Prime-Curve P-192 .... ok
Testing key generation with NIST Prime-Curve P-224 .... ok
Testing key generation with NIST Prime-Curve P-256 .... ok
Testing key generation with NIST Prime-Curve P-384 .... ok
Testing key generation with NIST Prime-Curve P-521 .... ok
Testing key generation with NIST Binary-Curve K-163 .... ok
Testing key generation with NIST Binary-Curve B-163 .... ok
Testing key generation with NIST Binary-Curve K-233 .... ok
Testing key generation with NIST Binary-Curve B-233 .... ok
Testing key generation with NIST Binary-Curve K-283 .... ok
Testing key generation with NIST Binary-Curve B-283 .... ok
Testing key generation with NIST Binary-Curve K-409 .... ok
Testing key generation with NIST Binary-Curve B-409 .... ok
Testing key generation with NIST Binary-Curve K-571 .... ok
Testing key generation with NIST Binary-Curve B-571 .... ok
Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP256r1 ok
Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP384r1 ok
Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP512r1 ok
cat
base64
aes-128-cbc
aes-128-cbc base64
aes-128-ecb
aes-128-ecb base64
aes-192-cbc
aes-192-cbc base64
aes-192-ecb
aes-192-ecb base64
aes-256-cbc
aes-256-cbc base64
aes-256-ecb
aes-256-ecb base64
base64
base64 base64
bf
bf base64
bf-cbc
bf-cbc base64
bf-cfb
bf-cfb base64
bf-ecb
bf-ecb base64
bf-ofb
bf-ofb base64
camellia-128-cbc
camellia-128-cbc base64
camellia-128-ecb
camellia-128-ecb base64
camellia-192-cbc
camellia-192-cbc base64
camellia-192-ecb
camellia-192-ecb base64
camellia-256-cbc
camellia-256-cbc base64
camellia-256-ecb
camellia-256-ecb base64
cast
cast base64
cast-cbc
cast-cbc base64
cast5-cbc
cast5-cbc base64
cast5-cfb
cast5-cfb base64
cast5-ecb
cast5-ecb base64
cast5-ofb
cast5-ofb base64
des
des base64
des-cbc
des-cbc base64
des-cfb
des-cfb base64
des-ecb
des-ecb base64
des-ede
des-ede base64
des-ede-cbc
des-ede-cbc base64
des-ede-cfb
des-ede-cfb base64
des-ede-ofb
des-ede-ofb base64
des-ede3
des-ede3 base64
des-ede3-cbc
des-ede3-cbc base64
des-ede3-cfb
des-ede3-cfb base64
des-ede3-ofb
des-ede3-ofb base64
des-ofb
des-ofb base64
des3
des3 base64
desx
desx base64
idea
idea base64
idea-cbc
idea-cbc base64
idea-cfb
idea-cfb base64
idea-ecb
idea-ecb base64
idea-ofb
idea-ofb base64
rc2
rc2 base64
rc2-40-cbc
rc2-40-cbc base64
rc2-64-cbc
rc2-64-cbc base64
rc2-cbc
rc2-cbc base64
rc2-cfb
rc2-cfb base64
rc2-ecb
rc2-ecb base64
rc2-ofb
rc2-ofb base64
rc4
rc4 base64
rc4-40
rc4-40 base64
rc5
rc5 base64
rc5-cbc
rc5-cbc base64
rc5-cfb
rc5-cfb base64
rc5-ecb
rc5-ecb base64
rc5-ofb
rc5-ofb base64
seed
seed base64
seed-cbc
seed-cbc base64
seed-cfb
seed-cfb base64
seed-ecb
seed-ecb base64
seed-ofb
seed-ofb base64
zlib
zlib base64
echo test normal x509v1 certificate
test normal x509v1 certificate
sh ./tx509 2>/dev/null
testing X509 conversions
p -> d
p -> n
p -> p
d -> d
n -> d
p -> d
d -> n
n -> n
p -> n
d -> p
n -> p
p -> p
echo test first x509v3 certificate
test first x509v3 certificate
sh ./tx509 v3-cert1.pem 2>/dev/null
testing X509 conversions
p -> d
p -> n
p -> p
d -> d
n -> d
p -> d
d -> n
n -> n
p -> n
d -> p
n -> p
p -> p
echo test second x509v3 certificate
test second x509v3 certificate
sh ./tx509 v3-cert2.pem 2>/dev/null
testing X509 conversions
p -> d
p -> n
p -> p
d -> d
n -> d
p -> d
d -> n
n -> n
p -> n
d -> p
n -> p
p -> p
rsa
testing rsa conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
../util/shlib_wrap.sh ./rsa_test
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
PKCS #1 v1.5 encryption/decryption ok
OAEP encryption/decryption ok
testing crl conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing session-id conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
Generate and verify a certificate request
generating certificate request
rsa
There should be a 2 sequences of .'s and some +'s.
There should not be more that at most 80 per line
This could take some time.
Generating a 1024 bit RSA private key
.......................++++++
..........................................................++++++
writing new private key to 'testkey.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
State or Province Name (full name) [Queensland]:
Locality Name (eg, city) []:Brisbane
Organization Name (eg, company) []:CryptSoft Pty Ltd
Organizational Unit Name (eg, section) []:.
Common Name (eg, YOUR name) []:Eric Young
Email Address []:eay at mincom.oz.au
verify OK
testing req conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing req conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing pkcs7 conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing pkcs7 conversions (2)
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
The following command should have some OK's and some failures
There are definitly a few expired certificates
../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs/demo ../certs/demo/*.pem
Segmentation fault
*** Error code 139

Stop.
*** Error code 1

Stop.
ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ exit
exit

Script done on Mon May  4 07:09:07 2015


This error does not occur in openssl-1.0.2-stable-SNAP-20150502

Please fix.

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Alberta time to save the province from corruption! Vote Liberal on 5 May 2015!!

From foleyj at cisco.com  Mon May  4 13:28:37 2015
From: foleyj at cisco.com (John Foley)
Date: Mon, 04 May 2015 09:28:37 -0400
Subject: [openssl-users] openssl-1.0.2-stable-SNAP-20150504 error
In-Reply-To: <20150504132111.GA10272@doctor.nl2k.ab.ca>
References: <20150504132111.GA10272@doctor.nl2k.ab.ca>
Message-ID: <55477405.6080702@cisco.com>

That's the same symptom I see on 32-bit systems.  It appears to be
caused by 5b38d54753acdabbf6b1d5e15d38ee81fb0612a2.


On 05/04/2015 09:21 AM, The Doctor wrote:
> This also occured in openssl-1.0.2-stable-SNAP-20150503
>
>
> Script started on Mon May  4 07:06:41 2015
> ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ egrep bsdi Confi 
> gure
> "bsdi-elf-gcc",     "gcc:-DPERL5 -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall::(unknown)::-ldl:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> "debug-bsdi-x86-elf",   "gcc3:-DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g::${BSDthreads}::-lgmp -ldl -lm -lc:THIRY_TWO_BIT_LONG RC4_CHUNK BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ mak && make test 
> ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ mak && make test
> sh: mak: command not found
> ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ ^k^ke
> make && make test
> making all in crypto...
> making all in crypto/objects...
> making all in crypto/md4...
> making all in crypto/md5...
> making all in crypto/sha...
> making all in crypto/mdc2...
> making all in crypto/hmac...
> making all in crypto/ripemd...
> making all in crypto/whrlpool...
> making all in crypto/des...
> making all in crypto/aes...
> making all in crypto/rc2...
> making all in crypto/rc4...
> making all in crypto/rc5...
> making all in crypto/idea...
> making all in crypto/bf...
> making all in crypto/cast...
> making all in crypto/camellia...
> making all in crypto/seed...
> making all in crypto/modes...
> making all in crypto/bn...
> making all in crypto/ec...
> making all in crypto/rsa...
> making all in crypto/dsa...
> making all in crypto/ecdsa...
> making all in crypto/dh...
> making all in crypto/ecdh...
> making all in crypto/dso...
> making all in crypto/engine...
> making all in crypto/buffer...
> making all in crypto/bio...
> making all in crypto/stack...
> making all in crypto/lhash...
> making all in crypto/rand...
> making all in crypto/err...
> making all in crypto/evp...
> making all in crypto/asn1...
> making all in crypto/pem...
> making all in crypto/x509...
> making all in crypto/x509v3...
> making all in crypto/conf...
> making all in crypto/txt_db...
> making all in crypto/pkcs7...
> making all in crypto/pkcs12...
> making all in crypto/comp...
> making all in crypto/ocsp...
> making all in crypto/ui...
> making all in crypto/krb5...
> making all in crypto/cms...
> making all in crypto/pqueue...
> making all in crypto/ts...
> making all in crypto/jpake...
> making all in crypto/srp...
> making all in crypto/store...
> making all in crypto/cmac...
> if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then  (cd ..; make libcrypto.so.1.0.0);  fi
> [ -z "" ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude  -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso   fips_premain.c fipscanister.o  libcrypto.a -lgmp -ldl -lm -lc
> making all in ssl...
> if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then  (cd ..; make libssl.so.1.0.0);  fi
> [ -z "" ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude  -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso   fips_premain.c fipscanister.o  libcrypto.a -lgmp -ldl -lm -lc
> making all in engines...
> echo 
>
> making all in engines/ccgost...
> making all in apps...
> making all in test...
> making all in tools...
> testing...
> making all in apps...
> ../util/shlib_wrap.sh ./destest
> Doing cbcm
> Doing ecb
> Doing ede ecb
> Doing cbc
> Doing desx cbc
> Doing ede cbc
> Doing pcbc
> Doing cfb8 cfb16 cfb32 cfb48 cfb64 cfb64() ede_cfb64() done
> Doing ofb
> Doing ofb64
> Doing ede_ofb64
> Doing cbc_cksum
> Doing quad_cksum
> input word alignment test 0 1 2 3
> output word alignment test 0 1 2 3
> fast crypt test 
> ../util/shlib_wrap.sh ./ideatest
> ecb idea ok
> cbc idea ok
> cfb64 idea ok
> ../util/shlib_wrap.sh ./shatest
> test 1 ok
> test 2 ok
> test 3 ok
> ../util/shlib_wrap.sh ./sha1test
> test 1 ok
> test 2 ok
> test 3 ok
> ../util/shlib_wrap.sh ./sha256t
> Testing SHA-256 ... passed.
> Testing SHA-224 ... passed.
> ../util/shlib_wrap.sh ./sha512t
> Testing SHA-512 ... passed.
> Testing SHA-384 ... passed.
> ../util/shlib_wrap.sh ./md4test
> test 1 ok
> test 2 ok
> test 3 ok
> test 4 ok
> test 5 ok
> test 6 ok
> test 7 ok
> ../util/shlib_wrap.sh ./md5test
> test 1 ok
> test 2 ok
> test 3 ok
> test 4 ok
> test 5 ok
> test 6 ok
> test 7 ok
> ../util/shlib_wrap.sh ./hmactest
> test 0 ok
> test 1 ok
> test 2 ok
> test 3 ok
> test 4 ok
> test 5 ok
> test 6 ok
> ../util/shlib_wrap.sh ./md2test
> No MD2 support
> ../util/shlib_wrap.sh ./mdc2test
> pad1 - ok
> pad2 - ok
> ../util/shlib_wrap.sh ./wp_test
> Testing Whirlpool ......... passed.
> ../util/shlib_wrap.sh ./rmdtest
> test 1 ok
> test 2 ok
> test 3 ok
> test 4 ok
> test 5 ok
> test 6 ok
> test 7 ok
> test 8 ok
> ../util/shlib_wrap.sh ./rc2test
> ecb RC2 ok
> ../util/shlib_wrap.sh ./rc4test
> test 0 ok
> test 1 ok
> test 2 ok
> test 3 ok
> test 4 ok
> test 5 ok
> test end processing ....................done
> test multi-call ....................done
> bulk test ok
> ../util/shlib_wrap.sh ./rc5test
> ecb RC5 ok
> cbc RC5 ok
> ../util/shlib_wrap.sh ./bftest
> testing blowfish in raw ecb mode
> testing blowfish in ecb mode
> testing blowfish set_key
> testing blowfish in cbc mode
> testing blowfish in cfb64 mode
> testing blowfish in ofb64
> ../util/shlib_wrap.sh ./casttest
> ecb cast5 ok
> This test will take some time....123456789ABCDEF ok
> ../util/shlib_wrap.sh ./randtest
> test 1 done
> test 2 done
> test 3 done
> test 4 done
> starting big number library test, could take a while...
> test BN_add
> test BN_sub
> test BN_lshift1
> test BN_lshift (fixed)
> test BN_lshift
> test BN_rshift1
> test BN_rshift
> test BN_sqr
> test BN_mul
> test BN_div
> test BN_div_word
> test BN_div_recp
> test BN_mod
> test BN_mod_mul
> test BN_mont
> test BN_mod_exp
> test BN_mod_exp_mont_consttime
> test BN_exp
> test BN_kronecker
> ....++++++
> ....................................................................................................
> test BN_mod_sqrt
> .....
> .....
> .....
> .....
> .....
> .....
> .....
> .....
> ......++++++++++++
> .....
> ............++++++++++++
> .....
> .....++++++++++++
> .....
> .................++++++++++++
> .....
> .............++++++++++++
> .....
> ..++++++++++++
> .....
> .........++++++++++++
> .....
> ..++++++++++++
> .....
> test BN_GF2m_add
> test BN_GF2m_mod
> test BN_GF2m_mod_mul
> test BN_GF2m_mod_sqr
> test BN_GF2m_mod_inv
> test BN_GF2m_mod_div
> test BN_GF2m_mod_exp
> test BN_GF2m_mod_sqrt
> test BN_GF2m_mod_solve_quad
> running bc
>
> verify BN_add....................................................................................................
> verify BN_sub......................................................................................................................................................
> verify BN_lshift1....................................................................................................
> verify BN_lshift (fixed)....................................................................................................
> verify BN_lshift....................................................................................................
> verify BN_rshift1....................................................................................................
> verify BN_rshift....................................................................................................
> verify BN_sqr......................................................................................................
> verify BN_mul......................................................................................................................................................
> verify BN_div............................................................................................................................................................................................................................................................................................................
> verify BN_div_word........................................................................................................................................................................................................
> verify BN_div_recp............................................................................................................................................................................................................................................................................................................
> verify BN_mod....................................................................................................
> verify BN_mod_mul............................................................................................................................................................................................................................................................................................................
> verify BN_mont.....
> verify BN_mod_exp.....
> verify BN_mod_exp_mont_consttime.....
> verify BN_exp.....
> verify BN_kronecker
> verify BN_mod_sqrt
> verify BN_GF2m_add
> verify BN_GF2m_mod
> verify BN_GF2m_mod_mul
> verify BN_GF2m_mod_sqr
> verify BN_GF2m_mod_inv
> verify BN_GF2m_mod_div
> verify BN_GF2m_mod_exp
> verify BN_GF2m_mod_sqrt
> verify BN_GF2m_mod_solve_quad
> 2222 tests passed
> test a^b%c implementations
> ../util/shlib_wrap.sh ./exptest
> ........................................................................................................................................................................................................
> done
> test elliptic curves
> ../util/shlib_wrap.sh ./ectest
> Curve defined by Weierstrass equation
>      y^2 = x^3 + a*x + b  (mod 0x17)
>      a = 0x1
>      b = 0x1
> A cyclic subgroup:
>      point at infinity
>      x = 0xD, y = 0x7
>      x = 0x5, y = 0x4
>      x = 0x11, y = 0x3
>      x = 0x11, y = 0x14
>      x = 0x5, y = 0x13
>      x = 0xD, y = 0x10
> Generator as octet string, compressed form:
>      030D
> Generator as octet string, uncompressed form:
>      040D07
> Generator as octet string, hybrid form:
>      070D07
> A representation of the inverse of that generator in
> Jacobian projective coordinates:
>      X = 0xC, Y = 0xF, Z = 0xA
>
> SEC2 curve secp160r1 -- Generator:
>      x = 0x4A96B5688EF573284664698968C38BB913CBFC82
>      y = 0x23A628553168947D59DCC912042351377AC5FB32
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
>
> NIST curve P-192 -- Generator:
>      x = 0x188DA80EB03090F67CBF20EB43A18800F4FF0AFD82FF1012
>      y = 0x7192B95FFC8DA78631011ED6B24CDD573F977A11E794811
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
>
> NIST curve P-224 -- Generator:
>      x = 0xB70E0CBD6BB4BF7F321390B94A03C1D356C21122343280D6115C1D21
>      y = 0xBD376388B5F723FB4C22DFE6CD4375A05A07476444D5819985007E34
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
>
> NIST curve P-256 -- Generator:
>      x = 0x6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296
>      y = 0x4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
>
> NIST curve P-384 -- Generator:
>      x = 0xAA87CA22BE8B05378EB1C71EF320AD746E1D3B628BA79B9859F741E082542A385502F25DBF55296C3A545E3872760AB7
>      y = 0x3617DE4A96262C6F5D9E98BF9292DC29F8F41DBD289A147CE9DA3113B5F0B8C00A60B1CE1D7E819D7A431D7C90EA0E5F
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
>
> NIST curve P-521 -- Generator:
>      x = 0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66
>      y = 0x11839296A789A3BC0045C8A5FB42C7D1BD998F54449579B446817AFBD17273E662C97EE72995EF42640C550B9013FAD0761353C7086A272C24088BE94769FD16650
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
> combined multiplication ..... ok
>
>
> Curve defined by Weierstrass equation
>      y^2 + x*y = x^3 + a*x^2 + b  (mod 0x13)
>      a = 0x3
>      b = 0x1
> (0x... means binary polynomial)
> A cyclic subgroup:
>      point at infinity
>      x = 0x6, y = 0x8
>      x = 0x1, y = 0xD
>      x = 0x7, y = 0x2
>      x = 0x0, y = 0x1
>      x = 0x7, y = 0x5
>      x = 0x1, y = 0xC
>      x = 0x6, y = 0xE
>
> Generator as octet string, uncompressed form:
>      040608
>
> NIST curve K-163 -- Generator:
>      x = 0x2FE13C0537BBC11ACAA07D793DE4E6D5E5C94EEE8
>      y = 0x289070FB05D38FF58321F2E800536D538CCDAA3D9
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
>
> NIST curve B-163 -- Generator:
>      x = 0x3F0EBA16286A2D57EA0991168D4994637E8343E36
>      y = 0xD51FBC6C71A0094FA2CDD545B11C5C0C797324F1
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
>
> NIST curve K-233 -- Generator:
>      x = 0x17232BA853A7E731AF129F22FF4149563A419C26BF50A4C9D6EEFAD6126
>      y = 0x1DB537DECE819B7F70F555A67C427A8CD9BF18AEB9B56E0C11056FAE6A3
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
>
> NIST curve B-233 -- Generator:
>      x = 0xFAC9DFCBAC8313BB2139F1BB755FEF65BC391F8B36F8F8EB7371FD558B
>      y = 0x1006A08A41903350678E58528BEBF8A0BEFF867A7CA36716F7E01F81052
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
>
> NIST curve K-283 -- Generator:
>      x = 0x503213F78CA44883F1A3B8162F188E553CD265F23C1567A16876913B0C2AC2458492836
>      y = 0x1CCDA380F1C9E318D90F95D07E5426FE87E45C0E8184698E45962364E34116177DD2259
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
>
> NIST curve B-283 -- Generator:
>      x = 0x5F939258DB7DD90E1934F8C70B0DFEC2EED25B8557EAC9C80E2E198F8CDBECD86B12053
>      y = 0x3676854FE24141CB98FE6D4B20D02B4516FF702350EDDB0826779C813F0DF45BE8112F4
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
>
> NIST curve K-409 -- Generator:
>      x = 0x60F05F658F49C1AD3AB1890F7184210EFD0987E307C84C27ACCFB8F9F67CC2C460189EB5AAAA62EE222EB1B35540CFE9023746
>      y = 0x1E369050B7C4E42ACBA1DACBF04299C3460782F918EA427E6325165E9EA10E3DA5F6C42E9C55215AA9CA27A5863EC48D8E0286B
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
>
> NIST curve B-409 -- Generator:
>      x = 0x15D4860D088DDB3496B0C6064756260441CDE4AF1771D4DB01FFE5B34E59703DC255A868A1180515603AEAB60794E54BB7996A7
>      y = 0x61B1CFAB6BE5F32BBFA78324ED106A7636B9C5A7BD198D0158AA4F5488D08F38514F1FDF4B4F40D2181B3681C364BA0273C706
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
>
> NIST curve K-571 -- Generator:
>      x = 0x26EB7A859923FBC82189631F8103FE4AC9CA2970012D5D46024804801841CA44370958493B205E647DA304DB4CEB08CBBD1BA39494776FB988B47174DCA88C7E2945283A01C8972
>      y = 0x349DC807F4FBF374F4AEADE3BCA95314DD58CEC9F307A54FFC61EFC006D8A2C9D4979C0AC44AEA74FBEBBB9F772AEDCB620B01A7BA7AF1B320430C8591984F601CD4C143EF1C7A3
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
>
> NIST curve B-571 -- Generator:
>      x = 0x303001D34B856296C16C0D40D3CD7750A93D1D2955FA80AA5F40FC8DB7B2ABDBDE53950F4C0D293CDD711A35B67FB1499AE60038614F1394ABFA3B4C850D927E1E7769C8EEC2D19
>      y = 0x37BF27342DA639B6DCCFFFEB73D69D78C6C27A6009CBBCA1980F8533921E8A684423E43BAB08A576291AF8F461BB2A8B3531D2F0485C19B16E2F1516E23DD3C1A4827AF1B8AC15B
> verify degree ... ok
> verify group order .... ok
> long/negative scalar tests allowing precomputation ... without precomputation ... ok
> combined multiplication ..... ok
>
> testing internal curves: ................................................................................. ok
>
> test ecdsa
> ../util/shlib_wrap.sh ./ecdsatest
> some tests from X9.62:
> testing prime192v1: .... ok
> testing prime239v1: .... ok
> testing c2tnb191v1: .... ok
> testing c2tnb239v1: .... ok
>
> testing ECDSA_sign() and ECDSA_verify() with some internal curves:
> secp160k1: ........ ok
> secp160r1: ........ ok
> secp160r2: ........ ok
> secp192k1: ........ ok
> secp224k1: ........ ok
> secp224r1: ........ ok
> secp256k1: ........ ok
> secp384r1: ........ ok
> secp521r1: ........ ok
> prime192v1: ........ ok
> prime192v2: ........ ok
> prime192v3: ........ ok
> prime239v1: ........ ok
> prime239v2: ........ ok
> prime239v3: ........ ok
> prime256v1: ........ ok
> sect163k1: ........ ok
> sect163r1: ........ ok
> sect163r2: ........ ok
> sect193r1: ........ ok
> sect193r2: ........ ok
> sect233k1: ........ ok
> sect233r1: ........ ok
> sect239k1: ........ ok
> sect283k1: ........ ok
> sect283r1: ........ ok
> sect409k1: ........ ok
> sect409r1: ........ ok
> sect571k1: ........ ok
> sect571r1: ........ ok
> c2pnb163v1: ........ ok
> c2pnb163v2: ........ ok
> c2pnb163v3: ........ ok
> c2pnb176v1: ........ ok
> c2tnb191v1: ........ ok
> c2tnb191v2: ........ ok
> c2tnb191v3: ........ ok
> c2pnb208w1: ........ ok
> c2tnb239v1: ........ ok
> c2tnb239v2: ........ ok
> c2tnb239v3: ........ ok
> c2pnb272w1: ........ ok
> c2pnb304w1: ........ ok
> c2tnb359v1: ........ ok
> c2pnb368w1: ........ ok
> c2tnb431r1: ........ ok
> wap-wsg-idm-ecid-wtls3: ........ ok
> wap-wsg-idm-ecid-wtls5: ........ ok
> wap-wsg-idm-ecid-wtls7: ........ ok
> wap-wsg-idm-ecid-wtls9: ........ ok
> wap-wsg-idm-ecid-wtls10: ........ ok
> wap-wsg-idm-ecid-wtls11: ........ ok
> wap-wsg-idm-ecid-wtls12: ........ ok
> brainpoolP160r1: ........ ok
> brainpoolP160t1: ........ ok
> brainpoolP192r1: ........ ok
> brainpoolP192t1: ........ ok
> brainpoolP224r1: ........ ok
> brainpoolP224t1: ........ ok
> brainpoolP256r1: ........ ok
> brainpoolP256t1: ........ ok
> brainpoolP320r1: ........ ok
> brainpoolP320t1: ........ ok
> brainpoolP384r1: ........ ok
> brainpoolP384t1: ........ ok
> brainpoolP512r1: ........ ok
> brainpoolP512t1: ........ ok
>
> ECDSA test passed
> test ecdh
> ../util/shlib_wrap.sh ./ecdhtest
> Testing key generation with NIST Prime-Curve P-192 .... ok
> Testing key generation with NIST Prime-Curve P-224 .... ok
> Testing key generation with NIST Prime-Curve P-256 .... ok
> Testing key generation with NIST Prime-Curve P-384 .... ok
> Testing key generation with NIST Prime-Curve P-521 .... ok
> Testing key generation with NIST Binary-Curve K-163 .... ok
> Testing key generation with NIST Binary-Curve B-163 .... ok
> Testing key generation with NIST Binary-Curve K-233 .... ok
> Testing key generation with NIST Binary-Curve B-233 .... ok
> Testing key generation with NIST Binary-Curve K-283 .... ok
> Testing key generation with NIST Binary-Curve B-283 .... ok
> Testing key generation with NIST Binary-Curve K-409 .... ok
> Testing key generation with NIST Binary-Curve B-409 .... ok
> Testing key generation with NIST Binary-Curve K-571 .... ok
> Testing key generation with NIST Binary-Curve B-571 .... ok
> Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP256r1 ok
> Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP384r1 ok
> Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP512r1 ok
> cat
> base64
> aes-128-cbc
> aes-128-cbc base64
> aes-128-ecb
> aes-128-ecb base64
> aes-192-cbc
> aes-192-cbc base64
> aes-192-ecb
> aes-192-ecb base64
> aes-256-cbc
> aes-256-cbc base64
> aes-256-ecb
> aes-256-ecb base64
> base64
> base64 base64
> bf
> bf base64
> bf-cbc
> bf-cbc base64
> bf-cfb
> bf-cfb base64
> bf-ecb
> bf-ecb base64
> bf-ofb
> bf-ofb base64
> camellia-128-cbc
> camellia-128-cbc base64
> camellia-128-ecb
> camellia-128-ecb base64
> camellia-192-cbc
> camellia-192-cbc base64
> camellia-192-ecb
> camellia-192-ecb base64
> camellia-256-cbc
> camellia-256-cbc base64
> camellia-256-ecb
> camellia-256-ecb base64
> cast
> cast base64
> cast-cbc
> cast-cbc base64
> cast5-cbc
> cast5-cbc base64
> cast5-cfb
> cast5-cfb base64
> cast5-ecb
> cast5-ecb base64
> cast5-ofb
> cast5-ofb base64
> des
> des base64
> des-cbc
> des-cbc base64
> des-cfb
> des-cfb base64
> des-ecb
> des-ecb base64
> des-ede
> des-ede base64
> des-ede-cbc
> des-ede-cbc base64
> des-ede-cfb
> des-ede-cfb base64
> des-ede-ofb
> des-ede-ofb base64
> des-ede3
> des-ede3 base64
> des-ede3-cbc
> des-ede3-cbc base64
> des-ede3-cfb
> des-ede3-cfb base64
> des-ede3-ofb
> des-ede3-ofb base64
> des-ofb
> des-ofb base64
> des3
> des3 base64
> desx
> desx base64
> idea
> idea base64
> idea-cbc
> idea-cbc base64
> idea-cfb
> idea-cfb base64
> idea-ecb
> idea-ecb base64
> idea-ofb
> idea-ofb base64
> rc2
> rc2 base64
> rc2-40-cbc
> rc2-40-cbc base64
> rc2-64-cbc
> rc2-64-cbc base64
> rc2-cbc
> rc2-cbc base64
> rc2-cfb
> rc2-cfb base64
> rc2-ecb
> rc2-ecb base64
> rc2-ofb
> rc2-ofb base64
> rc4
> rc4 base64
> rc4-40
> rc4-40 base64
> rc5
> rc5 base64
> rc5-cbc
> rc5-cbc base64
> rc5-cfb
> rc5-cfb base64
> rc5-ecb
> rc5-ecb base64
> rc5-ofb
> rc5-ofb base64
> seed
> seed base64
> seed-cbc
> seed-cbc base64
> seed-cfb
> seed-cfb base64
> seed-ecb
> seed-ecb base64
> seed-ofb
> seed-ofb base64
> zlib
> zlib base64
> echo test normal x509v1 certificate
> test normal x509v1 certificate
> sh ./tx509 2>/dev/null
> testing X509 conversions
> p -> d
> p -> n
> p -> p
> d -> d
> n -> d
> p -> d
> d -> n
> n -> n
> p -> n
> d -> p
> n -> p
> p -> p
> echo test first x509v3 certificate
> test first x509v3 certificate
> sh ./tx509 v3-cert1.pem 2>/dev/null
> testing X509 conversions
> p -> d
> p -> n
> p -> p
> d -> d
> n -> d
> p -> d
> d -> n
> n -> n
> p -> n
> d -> p
> n -> p
> p -> p
> echo test second x509v3 certificate
> test second x509v3 certificate
> sh ./tx509 v3-cert2.pem 2>/dev/null
> testing X509 conversions
> p -> d
> p -> n
> p -> p
> d -> d
> n -> d
> p -> d
> d -> n
> n -> n
> p -> n
> d -> p
> n -> p
> p -> p
> rsa
> testing rsa conversions
> p -> d
> p -> p
> d -> d
> p -> d
> d -> p
> p -> p
> ../util/shlib_wrap.sh ./rsa_test
> PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> PKCS #1 v1.5 encryption/decryption ok
> OAEP encryption/decryption ok
> testing crl conversions
> p -> d
> p -> p
> d -> d
> p -> d
> d -> p
> p -> p
> testing session-id conversions
> p -> d
> p -> p
> d -> d
> p -> d
> d -> p
> p -> p
> Generate and verify a certificate request
> generating certificate request
> rsa
> There should be a 2 sequences of .'s and some +'s.
> There should not be more that at most 80 per line
> This could take some time.
> Generating a 1024 bit RSA private key
> .......................++++++
> ..........................................................++++++
> writing new private key to 'testkey.pem'
> -----
> You are about to be asked to enter information that will be incorporated
> into your certificate request.
> What you are about to enter is what is called a Distinguished Name or a DN.
> There are quite a few fields but you can leave some blank
> For some fields there will be a default value,
> If you enter '.', the field will be left blank.
> -----
> Country Name (2 letter code) [AU]:AU
> State or Province Name (full name) [Queensland]:
> Locality Name (eg, city) []:Brisbane
> Organization Name (eg, company) []:CryptSoft Pty Ltd
> Organizational Unit Name (eg, section) []:.
> Common Name (eg, YOUR name) []:Eric Young
> Email Address []:eay at mincom.oz.au
> verify OK
> testing req conversions
> p -> d
> p -> p
> d -> d
> p -> d
> d -> p
> p -> p
> testing req conversions
> p -> d
> p -> p
> d -> d
> p -> d
> d -> p
> p -> p
> testing pkcs7 conversions
> p -> d
> p -> p
> d -> d
> p -> d
> d -> p
> p -> p
> testing pkcs7 conversions (2)
> p -> d
> p -> p
> d -> d
> p -> d
> d -> p
> p -> p
> The following command should have some OK's and some failures
> There are definitly a few expired certificates
> ../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs/demo ../certs/demo/*.pem
> Segmentation fault
> *** Error code 139
>
> Stop.
> *** Error code 1
>
> Stop.
> ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ exit
> exit
>
> Script done on Mon May  4 07:09:07 2015
>
>
> This error does not occur in openssl-1.0.2-stable-SNAP-20150502
>
> Please fix.
>


From bird_112 at hotmail.com  Mon May  4 14:00:21 2015
From: bird_112 at hotmail.com (jack seth)
Date: Mon, 4 May 2015 09:00:21 -0500
Subject: [openssl-users] Working with large DH parameters
In-Reply-To: <mailman.396.1430745700.30392.openssl-users@openssl.org>
References: <mailman.396.1430745700.30392.openssl-users@openssl.org>
Message-ID: <SNT152-W68ECAC0BB7C01D0A5F80BFBFD20@phx.gbl>

> There is a limit of 10000:
> #define OPENSSL_DH_MAX_MODULUS_BITS 10000
>
> I suggest you do not change this. It just gets slower without
> adding security.
>
> I have no idea why it would freeze with something larger than
> 13824.
>
> I'm not sure what is logging the size, but it might be using
> DH_size()*8 to log it. I don't think their currently is an API
> that returns it in bits.
>
>
> Kurt

Thanks for the response.? Could you elaborate on why a larger size doesn't add security?? For the sake of discussion, lets ignore how slow it would be.? According to section 5.6.1 of http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf? you would need 15360+ bit to have security equal to AES256.?? Is NIST wrong here?? If so, why?
 		 	   		  

From frans at fransdb.nl  Mon May  4 14:33:10 2015
From: frans at fransdb.nl (Frans de Boer)
Date: Mon, 04 May 2015 16:33:10 +0200
Subject: [openssl-users] New kernel and Dracut
Message-ID: <55478326.10204@fransdb.nl>

OK, I compiled a new kernel for the 13.2 release and was installing it. 
I have to manually copy bzImage and System.map because I do not use the 
make install which requires the perl-Bootloader to be available.

Before I just did mkinitrd -B and the initrd file was made. Now that is 
part of dracut and I can't create a new initrd file. The message log 
states that many modules are not supported - like "Module "raid1.ko" is 
not supported......". This is true because I did not compiled this as a 
module, but as a build-in.

My system is not booting because it is waiting for my drives to appear. 
The exact same config is used under 12.3 and of course working. Now with 
dracut I run into problems.

Any suggestions?
Regards, Frans

From james.arivazhagan at gmail.com  Mon May  4 15:08:08 2015
From: james.arivazhagan at gmail.com (James)
Date: Mon, 4 May 2015 20:38:08 +0530
Subject: [openssl-users] Regarding the Support for TLS 1.3
Message-ID: <CAJLNLpf1mQgaYn=HNcGFq8EnfkEo7CLi093iUy0BCX_5HniH+A@mail.gmail.com>

Hi there,
I would like to know whether OpenSSL supports TLS 1.3, if supported from
which version of OpenSSL the implementation started.

regards,
James Arivazhagan Ponnusamy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150504/4927f428/attachment.html>

From rsalz at akamai.com  Mon May  4 15:12:17 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 4 May 2015 15:12:17 +0000
Subject: [openssl-users] Regarding the Support for TLS 1.3
In-Reply-To: <CAJLNLpf1mQgaYn=HNcGFq8EnfkEo7CLi093iUy0BCX_5HniH+A@mail.gmail.com>
References: <CAJLNLpf1mQgaYn=HNcGFq8EnfkEo7CLi093iUy0BCX_5HniH+A@mail.gmail.com>
Message-ID: <06319dd616ee4cdca013c990bf6007df@usma1ex-dag1mb2.msg.corp.akamai.com>

> I would like to know whether OpenSSL supports TLS 1.3, if supported from which version of OpenSSL the implementation started. 

Since TLS 1.3 is not even done yet, no.  If I had to guess, I'd say it won't be "done" for at least six months.

	/r$, IETF TLS WG member

From kurt at roeckx.be  Mon May  4 16:59:39 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 4 May 2015 18:59:39 +0200
Subject: [openssl-users] [openssl-dev]
	openssl-1.0.2-stable-SNAP-20150504 error
In-Reply-To: <20150504132111.GA10272@doctor.nl2k.ab.ca>
References: <20150504132111.GA10272@doctor.nl2k.ab.ca>
Message-ID: <20150504165939.GA14230@roeckx.be>

On Mon, May 04, 2015 at 07:21:11AM -0600, The Doctor wrote:
> This also occured in openssl-1.0.2-stable-SNAP-20150503

This will most likely be fixed in the next snapshot.


Kurt


From kurt at roeckx.be  Mon May  4 17:13:55 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 4 May 2015 19:13:55 +0200
Subject: [openssl-users] Working with large DH parameters
In-Reply-To: <SNT152-W68ECAC0BB7C01D0A5F80BFBFD20@phx.gbl>
References: <mailman.396.1430745700.30392.openssl-users@openssl.org>
 <SNT152-W68ECAC0BB7C01D0A5F80BFBFD20@phx.gbl>
Message-ID: <20150504171355.GA14730@roeckx.be>

On Mon, May 04, 2015 at 09:00:21AM -0500, jack seth wrote:
> > There is a limit of 10000:
> > #define OPENSSL_DH_MAX_MODULUS_BITS 10000
> >
> > I suggest you do not change this. It just gets slower without
> > adding security.
> >
> > I have no idea why it would freeze with something larger than
> > 13824.
> >
> > I'm not sure what is logging the size, but it might be using
> > DH_size()*8 to log it. I don't think their currently is an API
> > that returns it in bits.
> >
> >
> > Kurt
> 
> Thanks for the response.? Could you elaborate on why a larger size doesn't add security?? For the sake of discussion, lets ignore how slow it would be.? According to section 5.6.1 of http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf? you would need 15360+ bit to have security equal to AES256.?? Is NIST wrong here?? If so, why?

Everything in the chain would need to be providing 256 bit of
security, there are no ciphers that support more than 192 as far
as I know.

Once you're at 128 or above it's also far more likekly that
something other than the crypto is the weakest part, like a human.


Kurt


From kurt at roeckx.be  Mon May  4 17:15:37 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 4 May 2015 19:15:37 +0200
Subject: [openssl-users] Regarding the Support for TLS 1.3
In-Reply-To: <06319dd616ee4cdca013c990bf6007df@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <CAJLNLpf1mQgaYn=HNcGFq8EnfkEo7CLi093iUy0BCX_5HniH+A@mail.gmail.com>
 <06319dd616ee4cdca013c990bf6007df@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150504171537.GB14730@roeckx.be>

On Mon, May 04, 2015 at 03:12:17PM +0000, Salz, Rich wrote:
> > I would like to know whether OpenSSL supports TLS 1.3, if supported from which version of OpenSSL the implementation started. 
> 
> Since TLS 1.3 is not even done yet, no.  If I had to guess, I'd say it won't be "done" for at least six months.

I would say that TLS 1.3 is just a bunch of ideas at this point.
There is nothing we can really do to even prepare for it.


Kurt


From noloader at gmail.com  Mon May  4 18:59:14 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 4 May 2015 14:59:14 -0400
Subject: [openssl-users] Working with large DH parameters
In-Reply-To: <SNT152-W68ECAC0BB7C01D0A5F80BFBFD20@phx.gbl>
References: <mailman.396.1430745700.30392.openssl-users@openssl.org>
 <SNT152-W68ECAC0BB7C01D0A5F80BFBFD20@phx.gbl>
Message-ID: <CAH8yC8kJO5yFxP7pa9U-y2-_k4KVMG3=QVEDJY9oWf3sxaTXqQ@mail.gmail.com>

On Mon, May 4, 2015 at 10:00 AM, jack seth <bird_112 at hotmail.com> wrote:
>> There is a limit of 10000:
>> #define OPENSSL_DH_MAX_MODULUS_BITS 10000
>>
>> I suggest you do not change this. It just gets slower without
>> adding security.
>>
>> I have no idea why it would freeze with something larger than
>> 13824.
>>
>> I'm not sure what is logging the size, but it might be using
>> DH_size()*8 to log it. I don't think their currently is an API
>> that returns it in bits.
>>
> Thanks for the response.  Could you elaborate on why a larger size doesn't add security?  For the sake of discussion, lets ignore how slow it would be.  According to section 5.6.1 of http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf  you would need 15360+ bit to have security equal to AES256.   Is NIST wrong here?  If so, why?
>
Also see https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe.
The largest integer field size called out in the standards is 8192.
(Corrections, please).

Usually, when you want those kinds of security levels, you switch to EC.

But like Kurt said.... At higher security levels, the attackers go
around the crypto and not through it. Phishing emails to ladies in HR
and Accounts Receivable is more effective and very inexpensive....

From openssl-users at dukhovni.org  Mon May  4 20:45:28 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 4 May 2015 20:45:28 +0000
Subject: [openssl-users] Bug(?) in 1.0.2a: Target Already defined
In-Reply-To: <554739C4.1070605@oliverniebuhr.de>
References: <554739C4.1070605@oliverniebuhr.de>
Message-ID: <20150504204528.GX17743@mournblade.imrryr.org>

On Mon, May 04, 2015 at 11:20:04AM +0200, Oliver Niebuhr wrote:

> ./Configure ?prefix=$PWD/dist no-idea no-mdc2 no-rc5 shared mingw64

I imagine that non-ASCII character is some sort of ndash inserted
by an overeager MUA.  Anyway the syntax is:

	./Configure --prefix=$PWD/dist ..

use two ASCII minus characters.

-- 
	Viktor.

From googleersatz at oliverniebuhr.de  Mon May  4 21:09:58 2015
From: googleersatz at oliverniebuhr.de (Google Ersatz)
Date: Mon, 04 May 2015 23:09:58 +0200
Subject: [openssl-users] Bug(?) in 1.0.2a: Target Already defined
In-Reply-To: <20150504204528.GX17743@mournblade.imrryr.org>
References: <554739C4.1070605@oliverniebuhr.de>
 <20150504204528.GX17743@mournblade.imrryr.org>
Message-ID: <20150504210958.6139982.49863.976@oliverniebuhr.de>

Evening.

I have no Idea why MailMan changed some of the Text. But yes, I always use 2 ASCII minus Characters.

Seems I have to go back to a 1.0.1 Version and hope that it will be fixed one Day.

Thanks anyways.
Oliver

Send?from?a?Mobile?Device.?Encoding?Problems can?happen.
? Originalnachricht ?
Von: Viktor Dukhovni
Gesendet: Montag, 4. Mai 2015 22:47
An: openssl-users at openssl.org
Antwort an: openssl-users at openssl.org
Betreff: Re: [openssl-users] Bug(?) in 1.0.2a: Target Already defined

On Mon, May 04, 2015 at 11:20:04AM +0200, Oliver Niebuhr wrote:

> ./Configure ?prefix=$PWD/dist no-idea no-mdc2 no-rc5 shared mingw64

I imagine that non-ASCII character is some sort of ndash inserted
by an overeager MUA. Anyway the syntax is:

./Configure --prefix=$PWD/dist ..

use two ASCII minus characters.

-- 
Viktor.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From wargand at gmx.de  Tue May  5 08:06:31 2015
From: wargand at gmx.de (Guido Seifert)
Date: Tue, 5 May 2015 10:06:31 +0200
Subject: [openssl-users] Link errors openssl 1.0.2a with mingw-w64
Message-ID: <20150505100631.251e3e69.wargand@gmx.de>

Hi,
I try to compile the latest openssl (1.0.2a) with Mingw-w64. The compiling part looks fine.
If there only wasn't this nasty link problem at the end (see end of mail).

I configured it with:

./Configure mingw64 shared --prefix=/usr/local

My build environment and configuration cannot be that wrong, since it works with 
version 1.0.1m. Ok, works except for the installation, but I can live without this
step.

Any ideas?

Guido



libcrypto.a(aesni-sha256-x86_64.o):fake:(.pdata+0x0): undefined reference to `.L                              SEH_begin_aesni_cbc_sha256_enc_xop'
libcrypto.a(aesni-sha256-x86_64.o):fake:(.pdata+0x4): undefined reference to `.L                              SEH_end_aesni_cbc_sha256_enc_xop'
libcrypto.a(aesni-sha256-x86_64.o):fake:(.pdata+0x8): undefined reference to `.L                              SEH_info_aesni_cbc_sha256_enc_xop'
libcrypto.a(aesni-sha256-x86_64.o):fake:(.pdata+0xc): undefined reference to `.L                              SEH_begin_aesni_cbc_sha256_enc_avx'
libcrypto.a(aesni-sha256-x86_64.o):fake:(.pdata+0x10): undefined reference to `.                              LSEH_end_aesni_cbc_sha256_enc_avx'
libcrypto.a(aesni-sha256-x86_64.o):fake:(.pdata+0x14): undefined reference to `.                              LSEH_info_aesni_cbc_sha256_enc_avx'
collect2.exe: error: ld returned 1 exit status
Makefile.shared:279: recipe for target 'link_a.cygwin' failed
make[4]: *** [link_a.cygwin] Error 1
make[4]: Leaving directory 'C:/Users/wargand/openssl-1.0.2a'
Makefile:349: recipe for target 'do_cygwin-shared' failed
make[3]: *** [do_cygwin-shared] Error 2
make[3]: Leaving directory 'C:/Users/wargand/openssl-1.0.2a'
Makefile:302: recipe for target 'libcrypto.dll.a' failed
make[2]: *** [libcrypto.dll.a] Error 2
make[2]: Leaving directory 'C:/Users/wargand/openssl-1.0.2a'
Makefile:109: recipe for target 'shared' failed
make[1]: *** [shared] Error 2
make[1]: Leaving directory 'C:/Users/wargand/openssl-1.0.2a/crypto'
Makefile:279: recipe for target 'build_crypto' failed
make: *** [build_crypto] Error 1

From matt at openssl.org  Tue May  5 08:21:28 2015
From: matt at openssl.org (Matt Caswell)
Date: Tue, 05 May 2015 09:21:28 +0100
Subject: [openssl-users] Kerberos
Message-ID: <55487D88.7010909@openssl.org>

I am considering removing Kerberos support from OpenSSL 1.1.0. There are
a number of problems with the functionality as it stands, and it seems
to me to be a very rarely used feature. I'm interested in hearing any
opinions on this (either for or against).

Thanks in advance for your input,

Matt

From wargand at gmx.de  Tue May  5 08:39:49 2015
From: wargand at gmx.de (Guido Seifert)
Date: Tue, 5 May 2015 10:39:49 +0200
Subject: [openssl-users] Link errors openssl 1.0.2a with mingw-w64
In-Reply-To: <20150505100631.251e3e69.wargand@gmx.de>
References: <20150505100631.251e3e69.wargand@gmx.de>
Message-ID: <20150505103949.06047e8b.wargand@gmx.de>


May I answer my own question? Problem solved (sort of). I did not have yasm installed.
Adding no-asm to ./Configure fixed the linker problem. Now trying to get yasm :-)

Guido

> Hi,
> I try to compile the latest openssl (1.0.2a) with Mingw-w64. The compiling part looks fine.
> If there only wasn't this nasty link problem at the end (see end of mail).
> 
> I configured it with:
> 
> ./Configure mingw64 shared --prefix=/usr/local
> 
> My build environment and configuration cannot be that wrong, since it works with 
> version 1.0.1m. Ok, works except for the installation, but I can live without this
> step.
> 
> Any ideas?
> 
> Guido

From xxiao8 at fosiao.com  Tue May  5 21:06:38 2015
From: xxiao8 at fosiao.com (xxiao8)
Date: Tue, 05 May 2015 16:06:38 -0500
Subject: [openssl-users] openssl_ciphers in wpa_supplicant.conf
Message-ID: <554930DE.50802@fosiao.com>

I'm trying to make wpa_supplicant fips-safe and one step is to set up:
#openssl_ciphers=DEFAULT:!EXP:!LOW
(based on http://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf)

https://www.openssl.org/docs/apps/ciphers.html has a list of all ciphers.

Is there a way somehow to set up a FIPS suite for 
openssl_ciphers,something like:
openssl_ciphers=FIPS?

I'm using the FIPS-compatible openssl library etc. Just don't know how 
to set up the openssl_ciphers in wpa_supplicant.conf.

Thanks,
xxiao



From dan at kohlbek.com  Wed May  6 00:02:19 2015
From: dan at kohlbek.com (DAN KOHLBEK)
Date: Tue, 5 May 2015 20:02:19 -0400
Subject: [openssl-users] OpenSSL Linux Client with Microsoft CA
Message-ID: <COL125-W122147C0337223A3EBA4F0B2D00@phx.gbl>

This is a cloud based setup, Linux with OpenSSL 1.0.1g-fips 7 Apr 2014, trying to connect to MS AD, and using a MS CA.  Is there a doc someone can point me to on how to configure the client in a MS CA environment?
Thank you,Dan  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150505/2c6a0217/attachment.html>

From openssl-users at dukhovni.org  Wed May  6 04:58:39 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 6 May 2015 04:58:39 +0000
Subject: [openssl-users] openssl_ciphers in wpa_supplicant.conf
In-Reply-To: <554930DE.50802@fosiao.com>
References: <554930DE.50802@fosiao.com>
Message-ID: <20150506045839.GS17272@mournblade.imrryr.org>

On Tue, May 05, 2015 at 04:06:38PM -0500, xxiao8 wrote:

> I'm trying to make wpa_supplicant fips-safe and one step is to set up:

The phrase "fips-safe" is a rather odd choice.  I think you mean
something along the lines of "FIPS compliant".  For that you'd need
to use a FIPS-capable OpenSSL release and arrange to enable "FIPS
mode".

> #openssl_ciphers=DEFAULT:!EXP:!LOW
> (based on http://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf)

In FIPS mode, openssl should automatically disable non-compliant
algorithms.

> Is there a way somehow to set up a FIPS suite for openssl_ciphers,something
> like:
>
> openssl_ciphers=FIPS?

To comply with FIPS, you need to enable FIPS mode, customizing
cipher lists does not do that.  On page 23, and in section 5.2 of:

    https://www.openssl.org/docs/fips/UserGuide-1.1.1.pdf

you'll learn that setting the environment variable OPENSSL_FIPS=1
turns on FIPS mode in a FIPS-capable OpenSSL.  Alternatively, the
application can call FIPS_mode_set(), or use OpenSSL_config() with
a suitable configuration file and choice of "section" name.

-- 
	Viktor.

From izaqyos at gmail.com  Wed May  6 08:19:34 2015
From: izaqyos at gmail.com (yosi izaq)
Date: Wed, 6 May 2015 11:19:34 +0300
Subject: [openssl-users] Programmatically add extension dirName to SAN in CSR
Message-ID: <CAOoUfZBVZ-SUqkEJx94zUJ1+EOGqOF3EgBsyQm-bYPNU-EWPpw@mail.gmail.com>

Hi,


I'm trying to add extension dirName to SAN in CSR programmatically.

I started with the example code, mkreq.c, as basis.

I then added some code for adding extension dirName to SAN.

"

X509V3_CTX CTX;

X509V3_set_ctx_nodb(&CTX);

X509V3_set_ctx(&CTX, 0, 0, x, 0, 0);

X509V3_EXT_conf_nid(NULL, CTX, NID_subject_alt_name,
"dirName:/C=UK/CN=OpenSSL Group"));

"

After initializing X509_REQ *x;

The CSR is created. With SAN containing email but w/o dirName. I also added
error prints and getting:

"

mkreq() add DirName extenion

Got error: error:2207507C:X509 V3 routines:v2i_GENERAL_NAME_ex:missing
value

error code: 570904700 in
/SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/x509v3/v3_alt.c line
433.

Got error: error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in
extension

error code: 571048064 in
/SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/x509v3/v3_conf.c line
93.

error data: name=subjectAltName, value=digitalSignature,keyEncipherment

Got error: error:2208E094:X509 V3 routines:X509V3_get_section:operation not
defined

error code: 571007124 in
/SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/x509v3/v3_conf.c line
400.

Got error: error:22090096:X509 V3 routines:DO_DIRNAME:section not found

error code: 571015318 in
/SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/x509v3/v3_alt.c line
571.

error data: section=/C=UK/CN=OpenSSL Group

Got error: error:22075095:X509 V3 routines:v2i_GENERAL_NAME_ex:dirname
error

error code: 570904725 in
/SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/x509v3/v3_alt.c line
495.

Got error: error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in
extension

error code: 571048064 in
/SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/crypto/x509v3/v3_conf.c line
93.

error data: name=subjectAltName, value=dirName:/C=UK/CN=OpenSSL Group
"


Reading the manual I understand I'm not supposed to dirName as simple type
value pair (like DNS,IP etc) but rather "point to a section containing the
distinguished name to use as a set of name value pairs" (quote manual).

My question is whether my understanding is correct and if so how to perform
that programmatically.


Would greatly appreciate help on the matter.

Thanks!

Yosi


For reference, skeleton of source code I'm testing:

nt main(int argc, char **argv)

{

BIO *bio_err;

X509_REQ *req=NULL;

EVP_PKEY *pkey=NULL;


CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON);


bio_err=BIO_new_fp(stderr, BIO_NOCLOSE);


//loadconf();

mkreq(&req,&pkey,512,0,365);


RSA_print_fp(stdout,pkey->pkey.rsa,0);

X509_REQ_print_fp(stdout,req);


PEM_write_X509_REQ(stdout,req);


X509_REQ_free(req);

EVP_PKEY_free(pkey);


#ifndef OPENSSL_NO_ENGINE

ENGINE_cleanup();

#endif

CRYPTO_cleanup_all_ex_data();


CRYPTO_mem_leaks(bio_err);

BIO_free(bio_err);

return(0);

}
int mkreq(X509_REQ **req, EVP_PKEY **pkeyp, int bits, int serial, int days)
{
    printf("mkreq() called \n");
X509_REQ *x;
EVP_PKEY *pk;
RSA *rsa;
X509_NAME *name=NULL;
STACK_OF(X509_EXTENSION) *exts = NULL;
 if ((pk=EVP_PKEY_new()) == NULL)
goto err;

if ((x=X509_REQ_new()) == NULL)
goto err;

rsa=RSA_generate_key(bits,RSA_F4,callback,NULL);
if (!EVP_PKEY_assign_RSA(pk,rsa))
goto err;

rsa=NULL;

X509_REQ_set_pubkey(x,pk);

name=X509_REQ_get_subject_name(x);

/* This function creates and adds the entry, working out the
 * correct string type and performing checks on its length.
 * Normally we'd check the return value for errors...
 */
X509_NAME_add_entry_by_txt(name,"C",
MBSTRING_ASC, "UK", -1, -1, 0);
X509_NAME_add_entry_by_txt(name,"CN",
MBSTRING_ASC, "OpenSSL Group", -1, -1, 0);

#ifdef REQUEST_EXTENSIONS
/* Certificate requests can contain extensions, which can be used
 * to indicate the extensions the requestor would like added to
 * their certificate. CAs might ignore them however or even choke
 * if they are present.
 */

/* For request extensions they are all packed in a single attribute.
 * We save them in a STACK and add them all at once later...
 */

exts = sk_X509_EXTENSION_new_null();
/* Standard extenions */

    printf("mkreq() add 1st extenion  \n");
add_ext(NULL, exts, NID_key_usage,
"critical,digitalSignature,keyEncipherment");

/* This is a typical use for request extensions: requesting a value for
 * subject alternative name.
 */

    printf("mkreq() add email extenion  \n");
add_ext(NULL, exts, NID_subject_alt_name, "email:steve at openssl.org");

    X509V3_CTX CTX;
        X509V3_set_ctx_nodb(&CTX);
X509V3_set_ctx(&CTX, 0, 0, x, 0, 0);


//add_ext(exts, NID_subject_alt_name,
"DirName:/C=DE/O=Novell/OU=Security/CN=DUS-LAB-NPS");
    printf("mkreq() add DirName extenion  \n");
//add_ext(exts, NID_subject_alt_name, "DirName:/CN=DUS-LAB-NPS");
add_ext(&CTX, exts, NID_subject_alt_name, "dirName:/C=UK/CN=OpenSSL Group");
    printf("mkreq() added DirName extenion  \n");
    print_errors();

/* Some Netscape specific extensions */
add_ext(NULL, exts, NID_netscape_cert_type, "client,email");



#ifdef CUSTOM_EXT
/* Maybe even add our own extension based on existing */
{
int nid;
nid = OBJ_create("1.2.3.4", "MyAlias", "My Test Alias Extension");
X509V3_EXT_add_alias(nid, NID_netscape_comment);
add_ext(NULL, x, nid, "example comment alias");
}
#endif

/* Now we've created the extensions we add them to the request */

X509_REQ_add_extensions(x, exts);

sk_X509_EXTENSION_pop_free(exts, X509_EXTENSION_free);

#endif
 if (!X509_REQ_sign(x,pk,EVP_sha1()))
goto err;

*req=x;
*pkeyp=pk;
return(1);
err:
return(0);
}

/* Add extension using V3 code: we can set the config file as NULL
 * because we wont reference any other sections.v3_alt.c
 */

int add_ext(X509V3_CTX * CTX, STACK_OF(X509_EXTENSION) *sk, int nid, char
*value)
{
X509_EXTENSION *ex;
//ex = X509V3_EXT_conf_nid(NULL, CTX, nid, value);
char                     *name = "subjectAltName";
ex = X509V3_EXT_conf(NULL, CTX, name, value);
if (!ex)
return 0;
sk_X509_EXTENSION_push(sk, ex);

return 1;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150506/9d3a333f/attachment-0001.html>

From piotr.lobacz at radmor.com.pl  Thu May  7 05:43:31 2015
From: piotr.lobacz at radmor.com.pl (Piotr =?UTF-8?Q?=C5=81obacz?=)
Date: Thu, 07 May 2015 07:43:31 +0200
Subject: [openssl-users] ECDSA with hmac sha
Message-ID: <1430977411.3042.2.camel@piotr-desktop>

Hello,
i have a question as in the subject is it possible with EVP api to sign
data with ECDSA using HMAC-SHA instead of SHA and if yes could you guid
me somehow?

-- 

________________________________________________________________________
Piotr ?obacz

Biuro System?w i Oprogramowania

RADMOR S.A.

tel. (58) 6996 929

e-mail: piotr.lobacz at radmor.com.pl

www.radmor.com.pl




RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia

NIP: 586-010-21-39

REGON: 190432077

KRS: 0000074029 (S?d Rejonowy Gda?sk-P??noc w Gda?sku)

Kapita? zak?adowy wp?acony: 9 282 830 PLN


From openssl-users at dukhovni.org  Thu May  7 07:00:17 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 7 May 2015 07:00:17 +0000
Subject: [openssl-users] [TLS] Update spec to match current practices
 for certificate chain order
In-Reply-To: <55487D88.7010909@openssl.org>
 <201505062313.06092.davemgarrett@gmail.com>
 <02805C01-924F-4B21-B61F-21414D4CE20D@gmail.com>
Message-ID: <20150507070017.GI17272@mournblade.imrryr.org>

On Thu, May 07, 2015 at 08:49:21AM +0300, Yoav Nir wrote:

> > I think there was also discussion on this list at some point suggesting
> > changing that "MAY" for omitting the root CA cert to a "SHOULD" or a
> > "MUST". (I think the argument for the latter was to reduce wasted bandwidth)

Sorry, this is incompatible with use of DANE TLSA records when the
ceritificate usage is DANE-TA(2).  See:

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-16#section-3.1.2
    https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-5.2

The first of these is currently in IETF LC, the second in DANE WG LC.

> SHOULD is OK, MUST would imply perfect knowledge of how the other side is
> configured.

As you note, there is more than one way to verify certificates,
and the server cannot know exactly which certificates are needed
by the client.  A SHOULD or MUST would be counter-productive.

> The root of trust may or may not be the self-signed certificate.
> But it?s probably always fine to omit the self-signed certificate.

No, not always.

> > Any reason this would be problematic? It'd be a simple change to add
> > for the TLS 1.3 spec that would align things better with real-world usage.
> 
> None that I can think of

You won't be able to say that next time. :-)

-- 
	Viktor.

From piotr.lobacz at radmor.com.pl  Thu May  7 08:28:49 2015
From: piotr.lobacz at radmor.com.pl (Piotr =?UTF-8?Q?=C5=81obacz?=)
Date: Thu, 07 May 2015 10:28:49 +0200
Subject: [openssl-users] ECDSA with random number
Message-ID: <1430987329.3042.5.camel@piotr-desktop>

As in the subject is it possible to generate signature with given random
number? According to the documentation of ECDSA uses RNG so it would be
difficult to find out private key from signature but i want just to test
my data to check if signature is being generated properly and i have'nt
found any possible place where i would be able to pass random value. Any
ideas?
-- 

________________________________________________________________________
Piotr ?obacz

Biuro System?w i Oprogramowania

RADMOR S.A.

tel. (58) 6996 929

e-mail: piotr.lobacz at radmor.com.pl

www.radmor.com.pl




RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia

NIP: 586-010-21-39

REGON: 190432077

KRS: 0000074029 (S?d Rejonowy Gda?sk-P??noc w Gda?sku)

Kapita? zak?adowy wp?acony: 9 282 830 PLN


From wangqun at alumni.nus.edu.sg  Thu May  7 08:56:36 2015
From: wangqun at alumni.nus.edu.sg (Aaron)
Date: Thu, 7 May 2015 01:56:36 -0700 (MST)
Subject: [openssl-users] Default ciphersuite has changed from 1.0.1l to
	1.0.2a?
Message-ID: <1430988996397-57937.post@n7.nabble.com>

Hello,

We have an OpenSSL application in which the client calls SSL_connect() to
connect to the server. 

We upgraded the OpenSSL used inour application from 1.0.1l to 1.0.2a
recently.

When OpenSSL 1.0.1l was used, the ciphersuite the client got was
ECDHE_RSA_WITH_AES_256_CBC_SHA. When OpenSSL 1.0.1a is used, we notice that
the ciphersuite the client gets has become DHE_RSA_WITH_AES_256_CBC_SHA.

I traced OpenSSL 1.0.2a source code. Here is the stack trace.
ssl_get_cipher_by_char()
ssl3_get_server_hello()
ssl3_connect()
SSL_connect()
ssl23_get_server_hello()
ssl23_connect()
SSL_connect()

I noticed that in routine ssl_get_cipher_by_char() the internal cipher name
it gets is DHE_RSA_AES256_SHA which should be corresponding to
DHE_RSA_WITH_AES_256_CBC_SHA.

My question is if this behavior change is expected?

Thanks in advance,
Aaron



--
View this message in context: http://openssl.6102.n7.nabble.com/Default-ciphersuite-has-changed-from-1-0-1l-to-1-0-2a-tp57937.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From b_duvvuri at yahoo.com  Thu May  7 09:41:17 2015
From: b_duvvuri at yahoo.com (Bala Duvvuri)
Date: Thu, 7 May 2015 02:41:17 -0700
Subject: [openssl-users] DRBG and prediction resistance
Message-ID: <1430991677.80676.YahooMailBasic@web400203.mail.bf1.yahoo.com>

Hi All,

What is the reason that the DRBG random generation function- fips_drbg_bytes does not consider prediction resistance as input? 

Inside  fips_drbg_bytes
rv = FIPS_drbg_generate(dctx, out, rcnt, 0, adin, adinlen); //prediction resistance disabled

And as a result the entropy generation callback - get_entropy , is never invoked.

How can we enable prediction resistance when using fips_drbg_bytes?

thanks,
Bala

From thulasi.goriparthi at gmail.com  Thu May  7 10:27:56 2015
From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi)
Date: Thu, 7 May 2015 15:57:56 +0530
Subject: [openssl-users] ECDSA with random number
In-Reply-To: <1430987329.3042.5.camel@piotr-desktop>
References: <1430987329.3042.5.camel@piotr-desktop>
Message-ID: <CAB7O4GwjiLhvVbQ3sFfoS-ERxPCbHN1i2jmK6fpXMKYYg6UOng@mail.gmail.com>

Hi Piotr,

As you have found out, choosing the per message random number in ECDSA
signature is crucial for the security of private key.

Leaving this responsibility on users is dangerous. This is the reason you
won't find any crypto API to feed the random number for ECDSA signature.

If you want to see how ECDSA is implemented, refer crypto/ecdsa/ecs_ossl.c.

Signature is generated in the following two steps.

ecdsa_sign_setup:
-- chooses the random number (k) and generates the first part of the ECDSA
signature (r).
-- returns inverse of k(required to generate second part of signature) and r

ecdsa_do_sign:
-- uses k inverse and r (received from ecdsa_sign_setup) to generate the
second part of the signature(s).


Thanks,
Thulasi.

On 7 May 2015 at 13:58, Piotr ?obacz <piotr.lobacz at radmor.com.pl> wrote:

> As in the subject is it possible to generate signature with given random
> number? According to the documentation of ECDSA uses RNG so it would be
> difficult to find out private key from signature but i want just to test
> my data to check if signature is being generated properly and i have'nt
> found any possible place where i would be able to pass random value. Any
> ideas?
> --
>
> ________________________________________________________________________
> Piotr ?obacz
>
> Biuro System?w i Oprogramowania
>
> RADMOR S.A.
>
> tel. (58) 6996 929
>
> e-mail: piotr.lobacz at radmor.com.pl
>
> www.radmor.com.pl
>
>
>
>
> RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia
>
> NIP: 586-010-21-39
>
> REGON: 190432077
>
> KRS: 0000074029 (S?d Rejonowy Gda?sk-P??noc w Gda?sku)
>
> Kapita? zak?adowy wp?acony: 9 282 830 PLN
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150507/03d473c0/attachment.html>

From openssl-users at dukhovni.org  Thu May  7 15:17:40 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 7 May 2015 15:17:40 +0000
Subject: [openssl-users] ECDSA with random number
In-Reply-To: <1430987329.3042.5.camel@piotr-desktop>
References: <1430987329.3042.5.camel@piotr-desktop>
Message-ID: <20150507151740.GM17272@mournblade.imrryr.org>

On Thu, May 07, 2015 at 10:28:49AM +0200, Piotr ?obacz wrote:

> According to the documentation of ECDSA uses RNG so it would be
> difficult to find out private key from signature but i want just to test
> my data to check if signature is being generated properly and I have'nt
> found any possible place where I would be able to pass random value. Any
> ideas?

To check that signatures are produced properly, verify the signature
by running the signature verification algorithm.  Unfortunately,
ECDSA does not easily admit determininistic test vectors.

The CFRG is discussing next negeration EC signature schemes right
now, and a consensus seems to be emerging around de-randomized
designs, where "k" is a pseudo-random function of the message and
a key-dependent secret.  Such a design admits test vectors.

-- 
	Viktor.

From bcall at apache.org  Wed May  6 23:12:54 2015
From: bcall at apache.org (Bryan Call)
Date: Wed, 6 May 2015 16:12:54 -0700
Subject: [openssl-users] Performance problems with OpenSSL and threading
In-Reply-To: <78e3a2ed0b8f47ecb8d2701d1a54bf5f@usma1ex-dag1mb4.msg.corp.akamai.com>
References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org>
 <5539844F.4090107@cisco.com>
 <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com>
 <A5F20DF3-E379-4952-82BB-C3CB3A4BC5DA@apache.org>
 <553ACEF9.4080702@cisco.com>
 <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org>
 <553FC1D0.9090302@cisco.com>
 <E98AE19B-413A-40D3-BC9C-67C83BBC3EB8@apache.org>
 <554124E9.9060405@cisco.com>
 <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org> <554372D2.30109@cisco.com>
 <78e3a2ed0b8f47ecb8d2701d1a54bf5f@usma1ex-dag1mb4.msg.corp.akamai.com>
Message-ID: <DFBB7439-1044-4190-8ECF-30AB1D6537B2@apache.org>

Do you know if there is a way from preventing a call to SSL_get_error() after getting a 0 byte read from SSL_read()?  This is the main issue I am facing with the OpenSSL error locking right now.

-Bryan




> On May 1, 2015, at 6:49 AM, Salz, Rich <rsalz at akamai.com> wrote:
> 
>> Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors.  It appears your application is generating a lot of errors for some reason.  Never tried it myself, but you probably can't disable this lock with multiple threads running.  You should take a look at the error log to identify the cause of the errors.  Then resolve the issue, whatever it may be.  
> 
> I have a rewrite of the error-stack stuff that halves the number of locks.  If you want to try it, drop me a line.
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150506/e6b28ff0/attachment-0001.html>

From foleyj at cisco.com  Thu May  7 17:59:00 2015
From: foleyj at cisco.com (John Foley)
Date: Thu, 07 May 2015 13:59:00 -0400
Subject: [openssl-users] Performance problems with OpenSSL and threading
In-Reply-To: <DFBB7439-1044-4190-8ECF-30AB1D6537B2@apache.org>
References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org>
 <5539844F.4090107@cisco.com>
 <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com>
 <A5F20DF3-E379-4952-82BB-C3CB3A4BC5DA@apache.org>
 <553ACEF9.4080702@cisco.com>
 <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org>
 <553FC1D0.9090302@cisco.com>
 <E98AE19B-413A-40D3-BC9C-67C83BBC3EB8@apache.org>
 <554124E9.9060405@cisco.com>
 <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org> <554372D2.30109@cisco.com>
 <78e3a2ed0b8f47ecb8d2701d1a54bf5f@usma1ex-dag1mb4.msg.corp.akamai.com>
 <DFBB7439-1044-4190-8ECF-30AB1D6537B2@apache.org>
Message-ID: <554BA7E4.1050003@cisco.com>

Not sure. 

Are you using blocking or non-blocking IO? 
Have you tried SSL_MODE_AUTO_RETRY?
Do you notice a different return value from SSL_read() after a zero byte
read compared to other errors?



On 05/06/2015 07:12 PM, Bryan Call wrote:
> Do you know if there is a way from preventing a call to
> SSL_get_error() after getting a 0 byte read from SSL_read()?  This is
> the main issue I am facing with the OpenSSL error locking right now.
>
> -Bryan
>
>
>
>
>> On May 1, 2015, at 6:49 AM, Salz, Rich <rsalz at akamai.com
>> <mailto:rsalz at akamai.com>> wrote:
>>
>>> Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging
>>> errors.  It appears your application is generating a lot of errors
>>> for some reason.  Never tried it myself, but you probably can't
>>> disable this lock with multiple threads running.  You should take a
>>> look at the error log to identify the cause of the errors.  Then
>>> resolve the issue, whatever it may be. 
>>
>> I have a rewrite of the error-stack stuff that halves the number of
>> locks.  If you want to try it, drop me a line.
>> _______________________________________________
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150507/461abf50/attachment.html>

From npmccallum at redhat.com  Fri May  8 00:00:17 2015
From: npmccallum at redhat.com (Nathaniel McCallum)
Date: Thu, 07 May 2015 20:00:17 -0400
Subject: [openssl-users] Kerberos
In-Reply-To: <55487D88.7010909@openssl.org>
References: <55487D88.7010909@openssl.org>
Message-ID: <1431043217.2505.3.camel@redhat.com>

On Tue, 2015-05-05 at 09:21 +0100, Matt Caswell wrote:
> I am considering removing Kerberos support from OpenSSL 1.1.0. There 
> are
> a number of problems with the functionality as it stands, and it 
> seems
> to me to be a very rarely used feature. I'm interested in hearing any
> opinions on this (either for or against).
> 
> Thanks in advance for your input,

There have been some conversations behind Red Hat doors about
improving the state of Kerberos/TLS in both standards and
implementations. Could we maybe have a broader conversation about how
to fix this situation?

Nathaniel

From openssl-users at dukhovni.org  Fri May  8 00:40:35 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 8 May 2015 00:40:35 +0000
Subject: [openssl-users] Kerberos
In-Reply-To: <1431043217.2505.3.camel@redhat.com>
References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com>
Message-ID: <20150508004035.GE17272@mournblade.imrryr.org>

On Thu, May 07, 2015 at 08:00:17PM -0400, Nathaniel McCallum wrote:

> There have been some conversations behind Red Hat doors about
> improving the state of Kerberos/TLS in both standards and
> implementations. Could we maybe have a broader conversation about how
> to fix this situation?

To be blunt, if you want better Kerberos support in TLS, the fix
is to expand the TLS WG charter to explore new directions in TLS
Kerberos support.  Given all the current efforts on 1.3, this is
not going to happen for quite some time.

There's nothing that can be done in just OpenSSL, and the right
immediate action is to drop support for the obsolete protocol.

[ FWIW, Nico concurs. ]

-- 
	Viktor.

From jaltman at secure-endpoints.com  Fri May  8 01:28:34 2015
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Thu, 07 May 2015 21:28:34 -0400
Subject: [openssl-users] Kerberos
In-Reply-To: <20150508004035.GE17272@mournblade.imrryr.org>
References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com>
 <20150508004035.GE17272@mournblade.imrryr.org>
Message-ID: <554C1142.9090002@secure-endpoints.com>

On 5/7/2015 8:40 PM, Viktor Dukhovni wrote:
> On Thu, May 07, 2015 at 08:00:17PM -0400, Nathaniel McCallum wrote:
> 
>> There have been some conversations behind Red Hat doors about
>> improving the state of Kerberos/TLS in both standards and
>> implementations. Could we maybe have a broader conversation about how
>> to fix this situation?
> 
> To be blunt, if you want better Kerberos support in TLS, the fix
> is to expand the TLS WG charter to explore new directions in TLS
> Kerberos support.  Given all the current efforts on 1.3, this is
> not going to happen for quite some time.
> 
> There's nothing that can be done in just OpenSSL, and the right
> immediate action is to drop support for the obsolete protocol.
> 
> [ FWIW, Nico concurs. ]

As do I and I am one of the individuals that pushed to get RFC 2712
passed the TLS WG and added to OpenSSL back in 1999.

While Viktor is correct that GSS authentication used over TLS with
appropriate channel bindings is a good option, it is not an option for
everyone.  It isn't easy to re-architect protocols that have been
deployed for more than 15 years in production.

There have been several efforts over the years to better integrate GSS
and Kerberos into TLS.  The approach that I prefer is one in which TLS
relies upon GSS authentication to produce a shared secret key that is
used to feed the TLS Pre-Shared Key (PSK) functionality.  However that
went nowhere.  TLS is complicated enough and there were significant
concerns that creating a GSS hole in the protocol would risk broader
security and performance issues.

SSH2 + GSS Key Exchange demonstrates how easy it should be to combine
GSS Kerberos with a security protocol and remove the dependency on key
management.  I have often wondered if the real resistance to adding GSS
to TLS is the negative impact it would have on the bottom lines of
companies that sell server certificates.

Regardless, the inability to improve the support in this area has left
the those organizations that rely upon 2712 with the choice of use
insecure protocols or re-implement the applications.  I do not believe
that any sane OS or application vendor can with a straight face continue
to ship 2712 support.  As such it should be removed from OpenSSL master.

Jeffrey Altman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4589 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150507/e7dd7693/attachment.bin>

From Arne.Fitzenreiter at ipfire.org  Fri May  8 07:46:38 2015
From: Arne.Fitzenreiter at ipfire.org (Arne Fitzenreiter)
Date: Fri, 08 May 2015 09:46:38 +0200
Subject: [openssl-users] vpaes performance problems on SSSE3 capable Amd and
	Intel Baytrail cpus
In-Reply-To: <243c384b5560628337e05341325a6bb6@mail01.ipfire.org>
References: <243c384b5560628337e05341325a6bb6@mail01.ipfire.org>
Message-ID: <4c64532a8032a7e270e19e614717bda4@mail01.ipfire.org>

Hi,

i have a performance problem with aes-xxx-cbc in evp mode on some cpus. 
Drop from 70MB/s to 30MB/s. It seems that the vpaes implemention is not 
good for all cpus that support ssse3. (I know that it speed up a lot on 
many Intel cpu's)

Tested cpu's that have the problem:
AMD E-?350
AMD E2-?1800
AMD A4-?5000 (only noticeable when disabling AES-?NI)
AMD FX8150 (only noticeable when disabling AES-?NI)

Intel Celeron J1900
Inter Celeron N2930

I will add some output with older OpenSSL from a Linux-Mint system but 
it is the same with current 1.0.2a on IPFire build.

Any Ideas to solve this without disabling vpaes for all cpu's.

I already have a patch to disable it for Amd because i have not found 
any Amd that are faster with vpaes, but for Intel Core2 it brings a lot 
of speed.

http://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/patches/openssl-1.0.2a_disable_ssse3_for_amd.patch;h=097cc80713ffc592dfe708ba9155591407c34c14;hb=0e2f9b011b8945dbfdfd3cac9fe1a486c48732e1

Regards,
Arne Fitzenreiter
Maintainer IPFire 2.x

-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?-?
arne at hp-e2 ~ $ cat /?proc/?cpuinfo
processor    : 0
vendor_id    : AuthenticAMD
cpu family    : 20
model        : 2
model name    : AMD E2-?1800 APU with Radeon(tm) HD Graphics
stepping    : 0
microcode    : 0x500010d
cpu MHz        : 850.000
cache size    : 512 KB
physical id    : 0
siblings    : 2
core id        : 0
cpu cores    : 2
apicid        : 0
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 6
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt 
pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid 
aperfmperf pni monitor ssse3 cx16 popcnt lahf_lm cmp_legacy svm extapic 
cr8_legacy abm sse4a misalignsse 3dnowprefetch ibs skinit wdt arat 
hw_pstate npt lbrv svm_lock nrip_save pausefilter
bogomips    : 3393.76
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 36 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
-?-?-?-? other 4 cores removed -?-?-?-?

For reference without -?evp
hp-?e2 ~ # openssl speed aes-?256-?cbc
Doing aes-256 cbc for 3s on 16 size blocks: 4735277 aes-256 cbc's in 
3.00s
Doing aes-256 cbc for 3s on 64 size blocks: 1244427 aes-256 cbc's in 
2.99s
Doing aes-256 cbc for 3s on 256 size blocks: 316282 aes-256 cbc's in 
2.99s
Doing aes-256 cbc for 3s on 1024 size blocks: 209266 aes-256 cbc's in 
2.99s
Doing aes-256 cbc for 3s on 8192 size blocks: 26337 aes-256 cbc's in 
2.99s
OpenSSL 1.0.1f 6 Jan 2014
built on: Thu Mar 19 15:12:02 UTC 2015
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) 
blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 
-fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions 
-Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int 
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 
bytes
aes-256 cbc      25254.81k    26636.56k    27079.66k    71668.36k    
72158.09k

now with -?evp
hp-?e2 ~ # openssl speed -?evp aes-?256-?cbc
Doing aes-256-cbc for 3s on 16 size blocks: 4915660 aes-256-cbc's in 
2.98s
Doing aes-256-cbc for 3s on 64 size blocks: 1278970 aes-256-cbc's in 
2.98s
Doing aes-256-cbc for 3s on 256 size blocks: 324633 aes-256-cbc's in 
2.99s
Doing aes-256-cbc for 3s on 1024 size blocks: 81472 aes-256-cbc's in 
2.98s
Doing aes-256-cbc for 3s on 8192 size blocks: 10196 aes-256-cbc's in 
2.98s
OpenSSL 1.0.1f 6 Jan 2014
built on: Thu Mar 19 15:12:02 UTC 2015
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) 
blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 
-fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions 
-Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int 
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 
bytes
aes-256-cbc      26392.81k    27467.81k    27794.66k    27995.75k    
28028.74k

now with hided ssse3 so it has to fallback...
hp-?e2 ~ # OPENSSL_ia32cap=~0x20000000000 openssl speed -?evp 
aes-?256-?cbc
Doing aes-256-cbc for 3s on 16 size blocks: 4594852 aes-256-cbc's in 
2.99s
Doing aes-256-cbc for 3s on 64 size blocks: 1232170 aes-256-cbc's in 
2.98s
Doing aes-256-cbc for 3s on 256 size blocks: 314750 aes-256-cbc's in 
2.99s
Doing aes-256-cbc for 3s on 1024 size blocks: 207284 aes-256-cbc's in 
2.98s
Doing aes-256-cbc for 3s on 8192 size blocks: 26242 aes-256-cbc's in 
2.99s
OpenSSL 1.0.1f 6 Jan 2014
built on: Thu Mar 19 15:12:02 UTC 2015
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) 
blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 
-fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions 
-Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int 
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 
bytes
aes-256-cbc      24587.84k    26462.71k    26948.49k    71227.79k    
71897.81k
hp-?e2 ~ #

From matt at openssl.org  Fri May  8 08:40:49 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 08 May 2015 09:40:49 +0100
Subject: [openssl-users] [openssl-dev]  Kerberos
In-Reply-To: <554C1142.9090002@secure-endpoints.com>
References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com>
 <20150508004035.GE17272@mournblade.imrryr.org>
 <554C1142.9090002@secure-endpoints.com>
Message-ID: <554C7691.80906@openssl.org>



On 08/05/15 02:28, Jeffrey Altman wrote:

> Regardless, the inability to improve the support in this area has left
> the those organizations that rely upon 2712 with the choice of use
> insecure protocols or re-implement the applications.  I do not believe
> that any sane OS or application vendor can with a straight face continue
> to ship 2712 support.  As such it should be removed from OpenSSL master.

I plan to start preparing the patches to remove it next week.

Matt


From bcall at apache.org  Fri May  8 17:01:53 2015
From: bcall at apache.org (Bryan Call)
Date: Fri, 8 May 2015 10:01:53 -0700
Subject: [openssl-users] Performance problems with OpenSSL and threading
In-Reply-To: <554BA7E4.1050003@cisco.com>
References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org>
 <5539844F.4090107@cisco.com>
 <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com>
 <A5F20DF3-E379-4952-82BB-C3CB3A4BC5DA@apache.org>
 <553ACEF9.4080702@cisco.com>
 <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org>
 <553FC1D0.9090302@cisco.com>
 <E98AE19B-413A-40D3-BC9C-67C83BBC3EB8@apache.org>
 <554124E9.9060405@cisco.com>
 <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org> <554372D2.30109@cisco.com>
 <78e3a2ed0b8f47ecb8d2701d1a54bf5f@usma1ex-dag1mb4.msg.corp.akamai.com>
 <DFBB7439-1044-4190-8ECF-30AB1D6537B2@apache.org>
 <554BA7E4.1050003@cisco.com>
Message-ID: <367A405E-2D87-4545-9B6B-E0E654766E28@apache.org>

It is in non-blocking mode.

After removing the call to SSL_get_error for the SSL_read case (0 return value) I discovered we call SSL_get_error in a couple more places.  Here is a simple request and the return codes on SSL_accept, SSL_read, and SSL_write and the return codes from SSL_get_error.  Every time we get a return code that is <= 0 we call SSL_get_error.  For a simple request we call it 5 times!

[May  8 09:38:01.075] Server {0xe95c000} DEBUG: <SSLUtils.cc:2111 (SSLAccept)> (bcall) SSL_accept - return value: -1 SSL_get_error: 2 errno: 0 shutdown: 0
[May  8 09:38:01.081] Server {0xe95c000} DEBUG: <SSLUtils.cc:2099 (SSLAccept)> (bcall) SSL_accept - return value: 1 SSL_get_error: 0 errno: 0 shutdown: 0
[May  8 09:38:01.081] Server {0xe95c000} DEBUG: <SSLUtils.cc:2087 (SSLReadBuffer)> (bcall) SSL_read - bytes: 0 return value: -1 SSL_get_error: 2 errno: 35 shutdown: 0
[May  8 09:38:01.103] Server {0xe95c000} DEBUG: <SSLUtils.cc:2066 (SSLReadBuffer)> (bcall) SSL_read - bytes: 0 return value: 73 SSL_get_error: 0 errno: 0 shutdown: 0
[May  8 09:38:01.103] Server {0xe95c000} DEBUG: <SSLUtils.cc:2087 (SSLReadBuffer)> (bcall) SSL_read - bytes: 0 return value: -1 SSL_get_error: 2 errno: 35 shutdown: 0
[May  8 09:38:01.113] Server {0xe95c000} DEBUG: <SSLUtils.cc:2033 (SSLWriteBuffer)> (bcall) SSL_write - bytes: 0 return value: 364 SSL_get_error: 0 errno: 0 shutdown: 0
[May  8 09:38:01.113] Server {0xe95c000} DEBUG: <SSLUtils.cc:2033 (SSLWriteBuffer)> (bcall) SSL_write - bytes: 0 return value: 249 SSL_get_error: 0 errno: 0 shutdown: 0
[May  8 09:38:01.113] Server {0xe95c000} DEBUG: <SSLUtils.cc:2087 (SSLReadBuffer)> (bcall) SSL_read - bytes: 0 return value: -1 SSL_get_error: 2 errno: 35 shutdown: 0
[May  8 09:38:01.113] Server {0xe95c000} DEBUG: <SSLUtils.cc:2087 (SSLReadBuffer)> (bcall) SSL_read - bytes: 0 return value: 0 SSL_get_error: 6 errno: 0 shutdown: 2

errno value from above (on OSX):
sys/errno.h:#define	EAGAIN		35		/* Resource temporarily unavailable */

If someone knows of a good way to reduce the number of calls to SSL_get_error that would be really helpful.  I am trying to push 20Gbits/second on this server.  I am hoping that I can get the same results as I would have from SSL_get_error, by looking at other variables in the SSL structure or errno or should I wait for the lock handling to be cleaned up in the error-stack?

-Bryan




> On May 7, 2015, at 10:59 AM, John Foley <foleyj at cisco.com> wrote:
> 
> Not sure.  
> 
> Are you using blocking or non-blocking IO?  
> Have you tried SSL_MODE_AUTO_RETRY?
> Do you notice a different return value from SSL_read() after a zero byte read compared to other errors?
> 


From bcall at apache.org  Fri May  8 17:04:21 2015
From: bcall at apache.org (Bryan Call)
Date: Fri, 8 May 2015 10:04:21 -0700
Subject: [openssl-users] Performance problems with OpenSSL and threading
In-Reply-To: <78e3a2ed0b8f47ecb8d2701d1a54bf5f@usma1ex-dag1mb4.msg.corp.akamai.com>
References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org>
 <5539844F.4090107@cisco.com>
 <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com>
 <A5F20DF3-E379-4952-82BB-C3CB3A4BC5DA@apache.org>
 <553ACEF9.4080702@cisco.com>
 <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org>
 <553FC1D0.9090302@cisco.com>
 <E98AE19B-413A-40D3-BC9C-67C83BBC3EB8@apache.org>
 <554124E9.9060405@cisco.com>
 <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org> <554372D2.30109@cisco.com>
 <78e3a2ed0b8f47ecb8d2701d1a54bf5f@usma1ex-dag1mb4.msg.corp.akamai.com>
Message-ID: <93C98B0D-25AD-41F5-AF65-ACA422D79FF8@apache.org>

You can private message me the patch and I can benchmark it for you.  Please let me know what release version or hash on git that it will cleanly apply.  Do you know what release this will be going in?

-Bryan




> On May 1, 2015, at 6:49 AM, Salz, Rich <rsalz at akamai.com> wrote:
> 
>> Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors.  It appears your application is generating a lot of errors for some reason.  Never tried it myself, but you probably can't disable this lock with multiple threads running.  You should take a look at the error log to identify the cause of the errors.  Then resolve the issue, whatever it may be.  
> 
> I have a rewrite of the error-stack stuff that halves the number of locks.  If you want to try it, drop me a line.
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From rsalz at akamai.com  Fri May  8 17:12:09 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 8 May 2015 17:12:09 +0000
Subject: [openssl-users] Performance problems with OpenSSL and threading
In-Reply-To: <93C98B0D-25AD-41F5-AF65-ACA422D79FF8@apache.org>
References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org>
 <5539844F.4090107@cisco.com>
 <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com>
 <A5F20DF3-E379-4952-82BB-C3CB3A4BC5DA@apache.org>
 <553ACEF9.4080702@cisco.com>
 <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org>
 <553FC1D0.9090302@cisco.com>
 <E98AE19B-413A-40D3-BC9C-67C83BBC3EB8@apache.org>
 <554124E9.9060405@cisco.com>
 <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org> <554372D2.30109@cisco.com>
 <78e3a2ed0b8f47ecb8d2701d1a54bf5f@usma1ex-dag1mb4.msg.corp.akamai.com>
 <93C98B0D-25AD-41F5-AF65-ACA422D79FF8@apache.org>
Message-ID: <15c69f93229f494c8e38a042d2a56449@usma1ex-dag1mb2.msg.corp.akamai.com>

 
> You can private message me the patch and I can benchmark it for you.
> Please let me know what release version or hash on git that it will cleanly
> apply.  Do you know what release this will be going in?

It is this commit 3e47caff4830d2a117eda15b57a5feab89b846ae on master.  A quick check shows that running the patch against 1.0.2 is mostly straightforward, except that the header files moved, so you might need to tweak those.

From npmccallum at redhat.com  Fri May  8 21:17:29 2015
From: npmccallum at redhat.com (Nathaniel McCallum)
Date: Fri, 08 May 2015 17:17:29 -0400
Subject: [openssl-users] Kerberos
In-Reply-To: <554C1142.9090002@secure-endpoints.com>
References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com>
 <20150508004035.GE17272@mournblade.imrryr.org>
 <554C1142.9090002@secure-endpoints.com>
Message-ID: <1431119849.2490.2.camel@redhat.com>

On Thu, 2015-05-07 at 21:28 -0400, Jeffrey Altman wrote:
> On 5/7/2015 8:40 PM, Viktor Dukhovni wrote:
> > On Thu, May 07, 2015 at 08:00:17PM -0400, Nathaniel McCallum wrote:
> > 
> > > There have been some conversations behind Red Hat doors about
> > > improving the state of Kerberos/TLS in both standards and
> > > implementations. Could we maybe have a broader conversation 
> > > about how
> > > to fix this situation?
> > 
> > To be blunt, if you want better Kerberos support in TLS, the fix
> > is to expand the TLS WG charter to explore new directions in TLS
> > Kerberos support.  Given all the current efforts on 1.3, this is
> > not going to happen for quite some time.
> > 
> > There's nothing that can be done in just OpenSSL, and the right
> > immediate action is to drop support for the obsolete protocol.
> > 
> > [ FWIW, Nico concurs. ]
> 
> As do I and I am one of the individuals that pushed to get RFC 2712
> passed the TLS WG and added to OpenSSL back in 1999.
> 
> While Viktor is correct that GSS authentication used over TLS with
> appropriate channel bindings is a good option, it is not an option 
> for
> everyone.  It isn't easy to re-architect protocols that have been
> deployed for more than 15 years in production.
> 
> There have been several efforts over the years to better integrate 
> GSS
> and Kerberos into TLS.  The approach that I prefer is one in which 
> TLS
> relies upon GSS authentication to produce a shared secret key that is
> used to feed the TLS Pre-Shared Key (PSK) functionality.  However 
> that
> went nowhere.  TLS is complicated enough and there were significant
> concerns that creating a GSS hole in the protocol would risk broader
> security and performance issues.
> 
> SSH2 + GSS Key Exchange demonstrates how easy it should be to combine
> GSS Kerberos with a security protocol and remove the dependency on 
> key
> management.  I have often wondered if the real resistance to adding 
> GSS
> to TLS is the negative impact it would have on the bottom lines of
> companies that sell server certificates.
> 
> Regardless, the inability to improve the support in this area has 
> left
> the those organizations that rely upon 2712 with the choice of use
> insecure protocols or re-implement the applications.  I do not 
> believe
> that any sane OS or application vendor can with a straight face 
> continue
> to ship 2712 support.  As such it should be removed from OpenSSL 
> master.

I agree that the current situation is not sustainable. I was only
hoping to start a conversation about how to improve the situation.

For instance, there is this: http://tls-kdh.arpa2.net/

I don't see any reason this couldn't be expanded to do GSSAPI.

But maybe this mailing list isn't the right place for such a
discussion.

Perhaps the right question to ask is how much interest there would be
in improving this situation in the TLS WG and whether or not OpenSSL
would have interest in implementing such a project.

Nathaniel

From bcall at apache.org  Fri May  8 22:45:17 2015
From: bcall at apache.org (Bryan Call)
Date: Fri, 8 May 2015 15:45:17 -0700
Subject: [openssl-users] Performance problems with OpenSSL and threading
In-Reply-To: <15c69f93229f494c8e38a042d2a56449@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org>
 <5539844F.4090107@cisco.com>
 <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com>
 <A5F20DF3-E379-4952-82BB-C3CB3A4BC5DA@apache.org>
 <553ACEF9.4080702@cisco.com>
 <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org>
 <553FC1D0.9090302@cisco.com>
 <E98AE19B-413A-40D3-BC9C-67C83BBC3EB8@apache.org>
 <554124E9.9060405@cisco.com>
 <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org> <554372D2.30109@cisco.com>
 <78e3a2ed0b8f47ecb8d2701d1a54bf5f@usma1ex-dag1mb4.msg.corp.akamai.com>
 <93C98B0D-25AD-41F5-AF65-ACA422D79FF8@apache.org>
 <15c69f93229f494c8e38a042d2a56449@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <5183DE93-3E5B-4189-A852-E670FA5DAC3A@apache.org>

I will just grab master then.  Will this change be in the next 1.0.2 release?

-Bryan




> On May 8, 2015, at 10:12 AM, Salz, Rich <rsalz at akamai.com> wrote:
> 
> 
>> You can private message me the patch and I can benchmark it for you.
>> Please let me know what release version or hash on git that it will cleanly
>> apply.  Do you know what release this will be going in?
> 
> It is this commit 3e47caff4830d2a117eda15b57a5feab89b846ae on master.  A quick check shows that running the patch against 1.0.2 is mostly straightforward, except that the header files moved, so you might need to tweak those.
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From rsalz at akamai.com  Fri May  8 23:00:07 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 8 May 2015 23:00:07 +0000
Subject: [openssl-users] Performance problems with OpenSSL and threading
In-Reply-To: <5183DE93-3E5B-4189-A852-E670FA5DAC3A@apache.org>
References: <20A62096-F3DE-4A11-8A76-CE081638E659@apache.org>
 <5539844F.4090107@cisco.com>
 <26886ABC-ABED-4673-847C-5030C5C343D3@apache.org> <553A83D2.80206@cisco.com>
 <A5F20DF3-E379-4952-82BB-C3CB3A4BC5DA@apache.org>
 <553ACEF9.4080702@cisco.com>
 <08D500E9-5A78-4CB8-B49B-6F41523A2C2E@apache.org>
 <553FC1D0.9090302@cisco.com>
 <E98AE19B-413A-40D3-BC9C-67C83BBC3EB8@apache.org>
 <554124E9.9060405@cisco.com>
 <91F453BC-3CA5-4031-9F07-09222EE7716B@apache.org> <554372D2.30109@cisco.com>
 <78e3a2ed0b8f47ecb8d2701d1a54bf5f@usma1ex-dag1mb4.msg.corp.akamai.com>
 <93C98B0D-25AD-41F5-AF65-ACA422D79FF8@apache.org>
 <15c69f93229f494c8e38a042d2a56449@usma1ex-dag1mb2.msg.corp.akamai.com>
 <5183DE93-3E5B-4189-A852-E670FA5DAC3A@apache.org>
Message-ID: <403514fb4c2c4b2ea52b22b2e21e1d70@usma1ex-dag1mb2.msg.corp.akamai.com>


> I will just grab master then.  Will this change be in the next 1.0.2 release?

No.  Released branches only get bug-fixes.

From jaltman at secure-endpoints.com  Sat May  9 02:09:29 2015
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Fri, 08 May 2015 22:09:29 -0400
Subject: [openssl-users] Kerberos
In-Reply-To: <1431119849.2490.2.camel@redhat.com>
References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com>
 <20150508004035.GE17272@mournblade.imrryr.org>
 <554C1142.9090002@secure-endpoints.com> <1431119849.2490.2.camel@redhat.com>
Message-ID: <554D6C59.1050402@secure-endpoints.com>

On 5/8/2015 5:17 PM, Nathaniel McCallum wrote:
>
> I agree that the current situation is not sustainable. I was only
> hoping to start a conversation about how to improve the situation.
> 
> For instance, there is this: http://tls-kdh.arpa2.net/
>
> I don't see any reason this couldn't be expanded to do GSSAPI.

I think that TLS-KDH is fundamentally flawed because it is tied to the
Kerberos protocol.  Most operating systems today support Kerberos but
they do not support a stable standard Kerberos API because such a
creature does not exist in the wild.

If we want a TLS implementation to make use of Kerberos authentication
on a broad range of operating systems that we must access Kerberos
through GSS. Only by using GSS can userland TLS implementations hope to
stack on top of the OS provided Kerberos in a portable way.

> But maybe this mailing list isn't the right place for such a
> discussion.
> 
> Perhaps the right question to ask is how much interest there would be
> in improving this situation in the TLS WG and whether or not OpenSSL
> would have interest in implementing such a project.

The IETF TLS WG and perhaps the IETF Kitten WG are the appropriate
places to hold discussions.  Or perhaps hold an IETF BOF first to
explore the interest.   The last time I was involved the work product was

 https://tools.ietf.org/html/draft-santesson-tls-gssapi-03

I still believe that is a reasonable approach.

Jeffrey Altman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4589 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150508/6c463d85/attachment.bin>

From nico at cryptonector.com  Sat May  9 02:18:12 2015
From: nico at cryptonector.com (Nico Williams)
Date: Fri, 8 May 2015 21:18:12 -0500
Subject: [openssl-users] Kerberos
In-Reply-To: <1431119849.2490.2.camel@redhat.com>
References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com>
 <20150508004035.GE17272@mournblade.imrryr.org>
 <554C1142.9090002@secure-endpoints.com>
 <1431119849.2490.2.camel@redhat.com>
Message-ID: <20150509021811.GD7287@localhost>

On Fri, May 08, 2015 at 05:17:29PM -0400, Nathaniel McCallum wrote:
> I agree that the current situation is not sustainable. I was only
> hoping to start a conversation about how to improve the situation.

RFC2712 uses Authenticator, which is an ASN.1 type quite clearly NOT
intended for use outside RFC1510 because it isn't a PDU.  RFC2712
unnecessarily constructed its own AP-REQ that's different from the
RFC1510 (now 4120) AP-REQ.

This is bad for a variety of reasons, not the least of which are
complicating Kerberos APIs and/or RFC2712 implementations (which might
have to parse out the Authenticator and Ticket from a plain AP-REQ).

I also notice that the EncryptedPreMasterSecret is under-specified (is
it a Kerberos EncryptedData?  who knows?).

RFC2712 could be replaced with a properly-done protocol that uses
Kerberos in the full TLS handshake (i.e., not in session resumption).
This would be the lowest-effort fix.

A generic GSS-in-TLS extension would require much more energy (see
below).

> For instance, there is this: http://tls-kdh.arpa2.net/

Yes, it'd be nice to add PFS to the Kerberos AP exchange, and we just
might get there, but adding Kerberos and/or GSS to TLS is a very
different undertaking.

> I don't see any reason this couldn't be expanded to do GSSAPI.

Well, that's difficult because GSS has arbitrary round trips...

You're not the first to want this, see for example here:

https://tools.ietf.org/html/draft-santesson-tls-gssapi-01
https://tools.ietf.org/html/draft-williams-tls-app-sasl-opt-04

And more if you consider other efforts like False Start and look past
GSS/SASL.  Probably many more than I know of then...

Two main design axis:

1) When does the GSS context token begin, and how is channel binding
done.

 - no GSS mech negotiation, first GSS context token goes in TLS
   ClientHello;

   (channel binding done via MIC tokens or GSS_Pesudorandom() output
   exchanges)

or (e.g., if the client needs to negotiate mechs)

 - TLS ClientHello carries client mechList, server announces a mech in
   its handshake message, first GSS context token goes in second client
   handshake flight with normal channel binding

(Both options could be specified, with clients choosing as desired.)

x

2) How many GSS context tokens can be exchanged and who is responsible
for continuing past the traditional TLS handshake.

 - one round trip only

or

 - arbitrary round trips continued by TLS or by the application

The first order of business is to decide on whether or not to support
multiple round trips (IMO we must; what's the point if not?).

The second is to decide whether or not additional context token round
trips are to be done by the application, both as to how they appear on
the wire and how they appear in the API.

The third is to decide whether GSS mechanism negotiation is supported,
and whether it can be optimized away when it's not needed.

The fourth is to decide whether SASL (with SASL/GS2 to get GSS) isn't
better, since if we're going to spend a pair of flights in negotiation,
we might as well let server-talks-first SASL mechs get a leg up on GSS.
Remember, SASL can do GSS just fine via SASL/GS2 [RFC5801].

> But maybe this mailing list isn't the right place for such a
> discussion.

Well, TLS WG would be the right forum, but they are busy with TLS 1.3.
Some of us could get together elsewhere, probably not here.

> Perhaps the right question to ask is how much interest there would be
> in improving this situation in the TLS WG and whether or not OpenSSL
> would have interest in implementing such a project.

My impression is: none, because TLS WG is too busy at this time, and in
the past it has been very difficult to get the necessary level of
implementor effort.  Past performance is not always a predictor of
future performance.

It would help if GSS had better, less niche mechanisms.  For example: if
Kerberos had PKCROSS (based on DANE, say), that would help.  Or if ABFAB
went viral.  But for now everyone in the TLS world is happy _enough_
with WebPKI for server (should be service, but hey) authentication and
bearer tokens for user authentication.

Part of the problem is that HTTP authentication schemes (whether in HTTP
proper or not) have no real binding to TLS, and HTTP is basically a
routable (and usually routed) protocol anyways, which complicates
everything.  But HTTPS is the main consumer of TLS.  One might think
that adding user authentication options to TLS would be desirable for
HTTP applications, but again, the routing inherent to HTTP means that
routing must pass along user authentication information, but this isn't
always easy.  And HTTP is stateless and so doesn't deal well with
needing continuation of authentication exchanges, so bearer tokens it
basically kinda has to be, so that better mechanisms lose their appeal.

If the main consumer of GSS-in-TLS were to be something other than HTTP,
well, great, but still, HTTPS is the biggest consumer (next is SMTP)...
And it's easier then to think of GSS-in-TLS as optimizing *application*
protocols with TLS by tagging some application data along in handshake
messages -- there have been many proposals like this, and this is by far
the most promising approach for special some applications (e.g., IMAP).
But now we're talking about generic TLS extensions (to be used for GSS)
rather than adding GSS support to TLS, and while that might make it
easier to get this through, it also makes coding applications harder.

I don't mean to sound pessimistic, much less to dissuade you.  Rather, I
want you to know what level of energy it will take to accomplish what
you're after.  Hopefully something does come of this.  I'll be glad to
help.

Nico
-- 

From nico at cryptonector.com  Sat May  9 03:57:52 2015
From: nico at cryptonector.com (Nico Williams)
Date: Fri, 8 May 2015 22:57:52 -0500
Subject: [openssl-users] [openssl-dev]  Kerberos
In-Reply-To: <20150509021811.GD7287@localhost>
References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com>
 <20150508004035.GE17272@mournblade.imrryr.org>
 <554C1142.9090002@secure-endpoints.com>
 <1431119849.2490.2.camel@redhat.com>
 <20150509021811.GD7287@localhost>
Message-ID: <20150509035751.GF7287@localhost>


I should have mentioned NPN and ALPN too.

A TLS application could use ALPN to negotiate the use of a variant of
the real application protocol, with the variant starting with a
channel-bound GSS context token exchange.

The ALPN approach can optimize the GSS mechanism negotiation, at the
price of a cartesian explosion of {app protocols} x {GSS mechs}.  A
variant based on the same idea could avoid the cartesian explosion.  But
hey, TLS is the land of cartesian explosions; when in Rome...

The ALPN approach would be my preference here.  With TLS libraries
implementing the GSS context exchange, naturally.  The result would be
roughly what you seem to have in mind.

If we ask TLS WG, I strongly suspect that we'll be asked to look at ALPN
first.

I should add that I also would like to see the RFC4121 Kerberos GSS
mechanism gain PFS, independently of TLS gaining GSS.

Nico
-- 

From noloader at gmail.com  Sat May  9 09:16:22 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 9 May 2015 05:16:22 -0400
Subject: [openssl-users] Does STACK_OF(X509_NAME) need to be free'd when
	using SSL_load_client_CA_file?
Message-ID: <CAH8yC8=znK8pxSwxNfUFxHdB-wZ06wtAUWn3LN=Qw6bbBPWL9w@mail.gmail.com>

Does STACK_OF(X509_NAME) need to be free'd when using SSL_load_client_CA_file?

s_server.c uses it like so, but I'm not sure if its correct:

    if (caFile != NULL) {
        SSL_CTX_set_client_CA_list(ctx, SSL_load_client_CA_file(caFile));

Or does SSL_CTX_set_client_CA_list take ownership or assign ownership
to the context?

The man pages do not discuss the memory management requirements
(http://www.openssl.org/docs/ssl/SSL_load_client_CA_file.html and
https://www.openssl.org/docs/ssl/SSL_CTX_set_client_CA_list.html).

From ben at an3k.de  Sat May  9 18:44:50 2015
From: ben at an3k.de (Ben Humpert)
Date: Sat, 9 May 2015 20:44:50 +0200
Subject: [openssl-users] minor documentation errors
Message-ID: <CAGbjqfERO1zvsehk66J+KjFV__OSx-GMTVRQHid=cWNNXoJLyA@mail.gmail.com>

Hello list!

After getting into building and especially configuring my own CA again
I'm nearly at the end and I've noticed some errors in the
documentation I want to report.

1) On https://www.openssl.org/docs/apps/ca.html for the -md option not
all possible values (sha256, sha384, etc.) are list but just md5, sha1
and mdc2
2) On https://www.openssl.org/docs/apps/req.html for the -[digest]
option not all possible values are listed
3) On https://www.openssl.org/docs/apps/req.html the option -subj is
listed twice with a slightly different explanation
4) On https://www.openssl.org/docs/apps/req.html for the default_md
option not all possible values are listed (shouldn't this reference
the -[digest] option)
5) On https://www.openssl.org/docs/apps/x509.html not all available
options are listed in -md2|-md5|-sha1|-mdc2


I also would like to ask if there's a newer version (or subtree) of
openssl that is cleaned up. Currently there are many ways of creating
a CSR, signing a certificate, etc. I think this is confusing
everybody.

Thank you very much in advance.


Best regards,

Ben

From rsalz at akamai.com  Sat May  9 19:47:53 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 9 May 2015 19:47:53 +0000
Subject: [openssl-users] minor documentation errors
In-Reply-To: <CAGbjqfERO1zvsehk66J+KjFV__OSx-GMTVRQHid=cWNNXoJLyA@mail.gmail.com>
References: <CAGbjqfERO1zvsehk66J+KjFV__OSx-GMTVRQHid=cWNNXoJLyA@mail.gmail.com>
Message-ID: <13204570de694126b82e6e7e6af073f9@usma1ex-dag1mb2.msg.corp.akamai.com>


> After getting into building and especially configuring my own CA again I'm
> nearly at the end and I've noticed some errors in the documentation I want
> to report.

I like the "again" :)
 
> 3) On https://www.openssl.org/docs/apps/req.html the option -subj is listed
> twice with a slightly different explanation

That's a bug, we'll fix it. Thanks.

> 1) On https://www.openssl.org/docs/apps/ca.html for the -md option not all
> possible values (sha256, sha384, etc.) are list but just md5, sha1 and mdc2
> 2) On https://www.openssl.org/docs/apps/req.html for the -[digest] option
> not all possible values are listed
> 4) On https://www.openssl.org/docs/apps/req.html for the default_md
> option not all possible values are listed (shouldn't this reference the -[digest]
> option)
> 5) On https://www.openssl.org/docs/apps/x509.html not all available
> options are listed in -md2|-md5|-sha1|-mdc2

Getting this correct is incredibly painful, as it depends on the configuration options chosen when building openssl, and right now the manpages are not affected by the config.  Our plan for this is to say "any supported digest."   That will be updated in a couple of days, and then pushed to the website in hour or so later.
 
> I also would like to ask if there's a newer version (or subtree) of openssl that
> is cleaned up.

I don't know what you mean by this. 

> Currently there are many ways of creating a CSR, signing a
> certificate, etc. I think this is confusing everybody.

The CA script is a wrapper around the various commands, and is reasonable.  But we're not planning on removing any of the current mechanisms.  Ivan Ristic has a really great, free, OpenSSL cookbook that might be useful: https://www.feistyduck.com/books/openssl-cookbook/



From rsalz at akamai.com  Sun May 10 02:56:48 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 10 May 2015 02:56:48 +0000
Subject: [openssl-users] statistics in COMP_CTX
Message-ID: <9f86ee8655584415a8f867d02d380d48@usma1ex-dag1mb2.msg.corp.akamai.com>

Is anyone using the counters maintained in COMP_CTX?
    unsigned long compress_in;
    unsigned long compress_out;
    unsigned long expand_in;
    unsigned long expand_out;

We're making that structure opaque in 1.1, and are wondering if we need an API (two, probably) to make those numbers available...

--
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150510/026e234f/attachment.html>

From openssl-users at dukhovni.org  Sun May 10 03:19:35 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 10 May 2015 03:19:35 +0000
Subject: [openssl-users] Does STACK_OF(X509_NAME) need to be free'd when
 using SSL_load_client_CA_file?
In-Reply-To: <CAH8yC8=znK8pxSwxNfUFxHdB-wZ06wtAUWn3LN=Qw6bbBPWL9w@mail.gmail.com>
References: <CAH8yC8=znK8pxSwxNfUFxHdB-wZ06wtAUWn3LN=Qw6bbBPWL9w@mail.gmail.com>
Message-ID: <20150510031931.GR17272@mournblade.imrryr.org>

On Sat, May 09, 2015 at 05:16:22AM -0400, Jeffrey Walton wrote:

> Does STACK_OF(X509_NAME) need to be free'd when using SSL_load_client_CA_file?

Yes, unless it is passed to SSL_CTX_set_client_CA_list() which
takes ownership of the stack.  That is, you must not free a stack
that is passed to that function, because the stack will be freed
when the context is freed.

> s_server.c uses it like so, but I'm not sure if its correct:
> 
>     if (caFile != NULL) {
>         SSL_CTX_set_client_CA_list(ctx, SSL_load_client_CA_file(caFile));

This is correct.

> Or does SSL_CTX_set_client_CA_list take ownership or assign ownership
> to the context?

It takes ownership.  

By the way, there is an implementation oddity in SSL_load_client_CA_file().
It builds two stacks, one of which is always freed.  I don't know
why.  The second seems to be used for duplicate detection, but I
fail to see why the returned stack can't be used for that.

-- 
	Viktor.

From ben at an3k.de  Sun May 10 09:58:11 2015
From: ben at an3k.de (Ben Humpert)
Date: Sun, 10 May 2015 11:58:11 +0200
Subject: [openssl-users] minor documentation errors
In-Reply-To: <13204570de694126b82e6e7e6af073f9@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <CAGbjqfERO1zvsehk66J+KjFV__OSx-GMTVRQHid=cWNNXoJLyA@mail.gmail.com>
 <13204570de694126b82e6e7e6af073f9@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAGbjqfEkTAMfVvPTnf_zAvnO94giieROJ9xf4oXmK-ZVibuWVw@mail.gmail.com>

2015-05-09 21:47 GMT+02:00 Salz, Rich <rsalz at akamai.com>:
>
>> After getting into building and especially configuring my own CA again I'm
>> nearly at the end and I've noticed some errors in the documentation I want
>> to report.
>
> I like the "again" :)

Yeah, once upon a time I had done a comprehensive configuration with a
Root CA and two Signing CAs and wrote down the command lines I need to
use but then I didn't even touched it for over four years so I only
had few memories. A good PKI tutorial and my files helped me getting
into it again quickly.

>> 1) On https://www.openssl.org/docs/apps/ca.html for the -md option not all
>> possible values (sha256, sha384, etc.) are list but just md5, sha1 and mdc2
>> 2) On https://www.openssl.org/docs/apps/req.html for the -[digest] option
>> not all possible values are listed
>> 4) On https://www.openssl.org/docs/apps/req.html for the default_md
>> option not all possible values are listed (shouldn't this reference the -[digest]
>> option)
>> 5) On https://www.openssl.org/docs/apps/x509.html not all available
>> options are listed in -md2|-md5|-sha1|-mdc2
>
> Getting this correct is incredibly painful, as it depends on the configuration options chosen when building openssl, and right now the manpages are not affected by the config.  Our plan for this is to say "any supported digest."   That will be updated in a couple of days, and then pushed to the website in hour or so later.

I see. I thought about mentioning "get a list of supported (message)
digests by using the command > openssl list-message-digest-commands <
in the doc but after I tried that command I just got md4, md5, rmd160,
sha, sha1 but since I was able to create a sha-256 with the -sha256
command option I guess it's just the wrong command to get a list of
supported digest?

I also tried openssl list-message-digest-algorithms and that shows
SHA512, SHA256, whirlpool (I like that one) and more. However I don't
think that it shows the correct names of supported options
(case-sensitive?). Additionally some options are listed twice like
DSA, DSA-SHA, MD4, MD5. Is that a bug too?

While being on it I also issued openssl list-cipher-algorithms and
here all entries are listed twice. The output gives a list which
contains of list (B) appended to list (A). List (A) has 93 unique
entries and shows aliases uppercase (eg. CAMELLIA256 =>
CAMELLIA-256-CBC). List (B) has 100 entries, 97 of them are unique.
Aliases are shown lowercase (camellia256 => CAMELLIA-256-CBC). The
additional entries are id-aes128-GCM, id-aes192-GCM, id-aes256-GCM and
blowfish => BF-CBC while the three aes ones are listed twice (once
correctly between AES-xxx-ECB and and AES-xxx-OFB once incorrectly
between DESX-CBC and rc2 => RC2-CBC).

>> I also would like to ask if there's a newer version (or subtree) of openssl that
>> is cleaned up.
>
> I don't know what you mean by this.

Well I just asked because if that would've been planned I would've
liked to participate in that process. What I meant was a version
that's cleaned up of superseded / deprecated commands and has a more
logical structure or command names, eg. no CA command and not three
different ways of getting the same result. It's simple enough for
doing simple stuff like quickly getting a self-signed certificate and
just gets a little bit more complicated than it has so be when you
begin with complex stuff. But I don't have a problem with how it's
done now :)

>> Currently there are many ways of creating a CSR, signing a
>> certificate, etc. I think this is confusing everybody.
>
> The CA script is a wrapper around the various commands, and is reasonable.  But we're not planning on removing any of the current mechanisms.  Ivan Ristic has a really great, free, OpenSSL cookbook that might be useful: https://www.feistyduck.com/books/openssl-cookbook/

Thanks for that like. I'll definitely cook some delicious meals with that ;)

From doctor at doctor.nl2k.ab.ca  Sun May 10 11:50:33 2015
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Sun, 10 May 2015 05:50:33 -0600
Subject: [openssl-users] openssl 1.0.2 and openssl 1.1.0 Snapshots
Message-ID: <20150510115033.GA19624@doctor.nl2k.ab.ca>

What is happening lately?

openssl 1.0.2 snapshots have do materialised properly in the last 2 days
and now opensl 1.1.0 is flopping.  Please fix.
-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
UK! Vote LDem on 7 May 2015!!

From elns at xs4all.nl  Sun May 10 15:37:29 2015
From: elns at xs4all.nl (Erik Leunissen)
Date: Sun, 10 May 2015 17:37:29 +0200
Subject: [openssl-users] DSA_generate_key() or DSA_print_fp() with
	passphrase protection
Message-ID: <554F7B39.7000000@xs4all.nl>

Hi all,

The openssl gendsa command supports passphrase protected generation of 
dsa keys.

I'm doing the dsa parameter and key generation, using the C API, using 
DSA_generate_parameters(), DSA_generate_key() and DSA_print_fp()

Now, I'd like to write, store the dsa keys and/or parameters in a 
passphrase protected fashion like the openssl gendsa command provides.

I could not find any information in the docs about how to handle that.
Have I been overlooking the obvious?

I'd be very grateful for directions about how to handle such passphrase 
protection with the C interface.

Thanks in advance,

Erik Leunissen.
--

From elns at xs4all.nl  Sun May 10 16:23:55 2015
From: elns at xs4all.nl (Erik Leunissen)
Date: Sun, 10 May 2015 18:23:55 +0200
Subject: [openssl-users] DSA_generate_key() or DSA_print_fp() with
 passphrase protection
In-Reply-To: <554F7B39.7000000@xs4all.nl>
References: <554F7B39.7000000@xs4all.nl>
Message-ID: <554F861B.9060707@xs4all.nl>

On 10/05/15 17:37, Erik Leunissen wrote:
> Hi all,
>
> The openssl gendsa command supports passphrase protected generation of
> dsa keys.
>
> I'm doing the dsa parameter and key generation, using the C API, using
> DSA_generate_parameters(), DSA_generate_key() and DSA_print_fp()
>
> Now, I'd like to write, store the dsa keys and/or parameters in a
> passphrase protected fashion like the openssl gendsa command provides.
>
> I could not find any information in the docs about how to handle that.
> Have I been overlooking the obvious?
>

In the meantime, a search separate from the openssl online documentation 
for the above C API's, made me find:

  https://www.openssl.org/docs/crypto/pem.html

where I found:

     PEM_write_DSAPrivateKey()

which seems to be what I want.

In order to make that page "findable" from the manual pages for the C 
API's DSA_generate_parameters(), DSA_generate_key() and DSA_print_fp(), 
I'd suggest to include a link in the respective "SEE ALSO" sections.

Sincerely,

Erik Leunissen
--

> I'd be very grateful for directions about how to handle such passphrase
> protection with the C interface.
>
> Thanks in advance,
>
> Erik Leunissen.
> --
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From konstantinakos.a at gmail.com  Sun May 10 18:47:35 2015
From: konstantinakos.a at gmail.com (konstantinos Alexiou)
Date: Sun, 10 May 2015 21:47:35 +0300
Subject: [openssl-users] Stand alone AES-CTR module
Message-ID: <CANW8MyQUS03=8e6D828XfLunirFDB6ECG860dEVdkhMzbM+Hmg@mail.gmail.com>

Dear Sirs,


I am new to C programming and i am trying to create an independent to
libraries source code for demonstration purposes for AES-CTR mode.Could i
have some help on doing that using the source code contained under
crypto/aes.


Thank you very much in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150510/def384dc/attachment-0001.html>

From akihana at gmail.com  Sun May 10 21:58:31 2015
From: akihana at gmail.com (Mike Mohr)
Date: Sun, 10 May 2015 14:58:31 -0700
Subject: [openssl-users] Stand alone AES-CTR module
In-Reply-To: <CANW8MyQUS03=8e6D828XfLunirFDB6ECG860dEVdkhMzbM+Hmg@mail.gmail.com>
References: <CANW8MyQUS03=8e6D828XfLunirFDB6ECG860dEVdkhMzbM+Hmg@mail.gmail.com>
Message-ID: <CAJe-LUg6Jd1iXw8TokLsVXotZYMh8yUCLMLqN=tTkm+ZVeaHDA@mail.gmail.com>

The task of implementing AES should not be undertaken by a novice
programmer.  Please save the world another heartbleed and pick something
more in line with your skill level.
On May 10, 2015 11:48 AM, "konstantinos Alexiou" <konstantinakos.a at gmail.com>
wrote:

> Dear Sirs,
>
>
> I am new to C programming and i am trying to create an independent to
> libraries source code for demonstration purposes for AES-CTR mode.Could i
> have some help on doing that using the source code contained under
> crypto/aes.
>
>
> Thank you very much in advance.
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150510/545fc9c7/attachment.html>

From bhat.jayalakshmi at gmail.com  Mon May 11 05:01:34 2015
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Sun, 10 May 2015 23:01:34 -0600
Subject: [openssl-users] a question on SSL_MAX_BUF_FREELIST_LEN_DEFAULT
Message-ID: <CALq8RvLS-SWuz+nJb4GFyDgqYaVm3FjPei5ZZw7nUyi+AjSR8g@mail.gmail.com>

Hi All,

We are using OpenSSL on a multihome device. Device has 4 interfaces. Each
network interface creates one SSL context (SSL_CTX)  and supports 16
connections. As per OpenSSL implementation Each SSL context can maintain a
free buffer list of 32. And this retained till SSL context (SSL_CTX) is
deleted.

I wanted to know is there any reason behind defining  #define
SSL_MAX_BUF_FREELIST_LEN_DEFAULT 32 . Can I reduce it to say 4 or some
smaller value.

Also can I use OpenSSL_malloc/OpenSSL_free instead of
freelist_extract/freelist_insert in
 ssl3_setup_read_buffer/ssl3_setup_write_buffer. Are there any side effects?

Any help is appreciated. Thanks in advance.

Regards
Jayalakshmi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150510/e1652de8/attachment.html>

From patpro at patpro.net  Mon May 11 05:07:13 2015
From: patpro at patpro.net (Patrick Proniewski)
Date: Mon, 11 May 2015 07:07:13 +0200
Subject: [openssl-users] upgrade system's OpenSSL and libs on Mac OS X 10.6.8
Message-ID: <DAC6C030-BBA0-4E5E-B860-747C4D3B54BD@patpro.net>

Hi,

Disclaimer: I'm not a developer.

I would like to upgrade openssl, libssl and libcrypto on my Mac OS X 10.6.8 system. The purpose is to allow system and softwares to use the new libs (for example ssh, sshd, Mail...). Do you think it's possible?

I can already install openssl and libs somewhere else (/usr/local), but if possible I would like to replace those provided by the system.

Any help greatly appreciated.
patpro

From patpro at patpro.net  Mon May 11 05:24:10 2015
From: patpro at patpro.net (Patrick Proniewski)
Date: Mon, 11 May 2015 07:24:10 +0200
Subject: [openssl-users] compared performances on Mac OS X 10.6.8
Message-ID: <285DB3C9-B81B-4818-9296-97F77921C64D@patpro.net>

Hello,

I've compiled OpenSSL 1.0.2a on Mac OS X 10.6.8, and used `openssl speed` to compare performances with stock OpenSSL (0.9.8). In many tests, 1.0.2a is a bit faster, or as fast as 0.9.8y, but on the 6 AES tests, the old one is almost twice as fast as the new one:

OpenSSL 1.0.2a 19 Mar 2015
built on: reproducible build, date unspecified
options:bn(64,32) rc4(8x,mmx) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) 
compiler: cc -I. -I.. -I../include  -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch i386 -O3 -fomit-frame-pointer -DL_ENDIAN -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
../..
aes-128 cbc      93494.07k   102637.16k   104677.80k   105762.76k   106145.31k
aes-192 cbc      78912.98k    84939.17k    86991.87k    88263.00k    88350.72k
aes-256 cbc      68691.56k    73564.65k    74554.37k    75421.01k    75803.31k
../..
aes-128 ige      89849.59k    94381.10k    97713.32k    98399.23k    97045.16k
aes-192 ige      76133.38k    80632.62k    81332.31k    82033.66k    81988.27k
aes-256 ige      66744.15k    69558.66k    70501.12k    70079.15k    70041.60k
../..


OpenSSL 0.9.8y 5 Feb 2013
built on: Jun 27 2013
options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr2) 
compiler: -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O3 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_NO_IDEA -DOPENSSL_PIC -DOPENSSL_THREADS -DZLIB -mmacosx-version-min=10.6
../..
aes-128 cbc     149709.21k   157970.02k   159079.54k   160057.16k   159908.25k
aes-192 cbc     132826.18k   138516.09k   139301.84k   139847.86k   139845.95k
aes-256 cbc     119058.45k   123144.42k   123989.61k   124192.42k   124275.21k
../..
aes-128 ige     157970.54k   168814.05k   171997.82k   171239.04k   172713.37k
aes-192 ige     139152.02k   145860.99k   148705.55k   148606.98k   150433.13k
aes-256 ige     124678.17k   130624.07k   132307.43k   131849.37k   132539.38k


Is it a compilation issue? (I've tested both -arch on 1.0.2a with same results).

thanks,
patpro

From openssl-users at dukhovni.org  Mon May 11 05:43:41 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 May 2015 05:43:41 +0000
Subject: [openssl-users] upgrade system's OpenSSL and libs on Mac OS X
 10.6.8
In-Reply-To: <DAC6C030-BBA0-4E5E-B860-747C4D3B54BD@patpro.net>
References: <DAC6C030-BBA0-4E5E-B860-747C4D3B54BD@patpro.net>
Message-ID: <20150511054340.GV17272@mournblade.imrryr.org>

On Mon, May 11, 2015 at 07:07:13AM +0200, Patrick Proniewski wrote:

> I would like to upgrade openssl, libssl and libcrypto on my Mac OS X 10.6.8
> system. The purpose is to allow system and softwares to use the new libs
> (for example ssh, sshd, Mail...). Do you think it's possible?

You can install OpenSSL from MacPorts or Homebrew, choose whichever
you prefer.

> I can already install openssl and libs somewhere else (/usr/local), but
> if possible I would like to replace those provided by the system.

That would be a mistake.  It is best to not replace system libraries
with incompatible upstream versions.

-- 
	Viktor.

From openssl-users at dukhovni.org  Mon May 11 05:45:48 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 May 2015 05:45:48 +0000
Subject: [openssl-users] compared performances on Mac OS X 10.6.8
In-Reply-To: <285DB3C9-B81B-4818-9296-97F77921C64D@patpro.net>
References: <285DB3C9-B81B-4818-9296-97F77921C64D@patpro.net>
Message-ID: <20150511054547.GW17272@mournblade.imrryr.org>

On Mon, May 11, 2015 at 07:24:10AM +0200, Patrick Proniewski wrote:

> I've compiled OpenSSL 1.0.2a on Mac OS X 10.6.8, and used `openssl
> speed` to compare performances with stock OpenSSL (0.9.8). In many
> tests, 1.0.2a is a bit faster, or as fast as 0.9.8y, but on the 6
> AES tests, the old one is almost twice as fast as the new one:

Use "openssl speed -evp".  Then if your hardware has AES-NI, it
will be faster in 1.0.2.  Otherwise, the slowdown is expected.
The software-only AES in 1.0.x is constant-time, and avoids
timing side-channel attacks.  The 0.9.8 version is not
constant time (faster, but less secure).

-- 
	Viktor.

From patpro at patpro.net  Mon May 11 09:14:53 2015
From: patpro at patpro.net (patpro at patpro.net)
Date: Mon, 11 May 2015 11:14:53 +0200
Subject: [openssl-users] upgrade system's OpenSSL and libs on Mac OS X
	10.6.8
In-Reply-To: <20150511054340.GV17272@mournblade.imrryr.org>
References: <DAC6C030-BBA0-4E5E-B860-747C4D3B54BD@patpro.net>
 <20150511054340.GV17272@mournblade.imrryr.org>
Message-ID: <BB85B401-CE00-4431-ADC7-55845BB31790@patpro.net>

On 11 mai 2015, at 07:43, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:

> On Mon, May 11, 2015 at 07:07:13AM +0200, Patrick Proniewski wrote:
> 
>> I would like to upgrade openssl, libssl and libcrypto on my Mac OS X 10.6.8
>> system. The purpose is to allow system and softwares to use the new libs
>> (for example ssh, sshd, Mail...). Do you think it's possible?
> 
> You can install OpenSSL from MacPorts or Homebrew, choose whichever
> you prefer.


Using MacPorts/Homebrew instead of manual install would allow /usr/bin/ssh (for example) to use /usr/local/openssl/lib/libcrypto.1.0.0.dylib instead of /usr/lib/libcrypto.0.9.8.dylib ?


>> I can already install openssl and libs somewhere else (/usr/local), but
>> if possible I would like to replace those provided by the system.
> 
> That would be a mistake.  It is best to not replace system libraries
> with incompatible upstream versions.

"how much" do you think it would be incompatible? 
The more I think about it, the more I do agree with you, but I can't help thinking that's too bad I can't upgrade openssl+libs on my system.

From patpro at patpro.net  Mon May 11 09:24:10 2015
From: patpro at patpro.net (patpro at patpro.net)
Date: Mon, 11 May 2015 11:24:10 +0200
Subject: [openssl-users] compared performances on Mac OS X 10.6.8
In-Reply-To: <20150511054547.GW17272@mournblade.imrryr.org>
References: <285DB3C9-B81B-4818-9296-97F77921C64D@patpro.net>
 <20150511054547.GW17272@mournblade.imrryr.org>
Message-ID: <19C6CC91-62F6-4C3F-AF6A-4106167DA535@patpro.net>

On 11 mai 2015, at 07:45, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:

> On Mon, May 11, 2015 at 07:24:10AM +0200, Patrick Proniewski wrote:
> 
>> I've compiled OpenSSL 1.0.2a on Mac OS X 10.6.8, and used `openssl
>> speed` to compare performances with stock OpenSSL (0.9.8). In many
>> tests, 1.0.2a is a bit faster, or as fast as 0.9.8y, but on the 6
>> AES tests, the old one is almost twice as fast as the new one:
> 
> Use "openssl speed -evp".  Then if your hardware has AES-NI, it
> will be faster in 1.0.2.  Otherwise, the slowdown is expected.
> The software-only AES in 1.0.x is constant-time, and avoids
> timing side-channel attacks.  The 0.9.8 version is not
> constant time (faster, but less secure).


Thank you for this explanation. The evp flag works great on my hardware:

$ apps/openssl speed -evp aes-256-cbc
../..
aes-256-cbc     171795.47k   200081.86k   208523.35k   211620.52k   210927.62k


$ apps/openssl speed aes-256-cbc
../..
aes-256 cbc      68905.90k    73930.92k    75199.15k    75868.16k    76136.45k


regards,
patpro

From ben at an3k.de  Mon May 11 10:37:09 2015
From: ben at an3k.de (Ben Humpert)
Date: Mon, 11 May 2015 12:37:09 +0200
Subject: [openssl-users] x509_config nameConstraints
Message-ID: <CAGbjqfH4xP4+66chQKaf0oAP28-iN54fQi2iT9gbL4yP1Feriw@mail.gmail.com>

Hi,

I read the OpenSSL Cookbook by Ivan Ristic and saw how he configured
nameConstraints so I adapted it for my setup.

First I tried the following but that doesn't work.

permitted;DNS.0=lan
permitted;DNS.1=local
permitted;IP.0=10.0.0.0/255.0.0.0
permitted;IP.1=172.16.0.0/255.240.0.0
permitted;IP.2=192.168.0.0/255.255.0.0
excluded;IP.3=0.0.0.0/0.0.0.0
excluded;IP.4=0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0

Then I thought maybe reordering might help like

excluded;IP.0=0.0.0.0/0.0.0.0
excluded;IP.1=0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0
permitted;DNS.0=lan
permitted;DNS.1=local
permitted;IP.2=10.0.0.0/255.0.0.0
permitted;IP.3=172.16.0.0/255.240.0.0
permitted;IP.4=192.168.0.0/255.255.0.0

but that gives the same result except that the ordering is different.
So I guess as soon as one permitted entry is specified everything else
is automatically excluded (vice-versa for excluded / permitted). If
that's the case the following configuration should only allow
certificates for any domain name using the TLDs lan or local and for
any IP address of one of the three private networks but everything
else will draw the certificate invalid. Is that correct?

permitted;DNS.0=lan
permitted;DNS.1=local
permitted;IP.0=10.0.0.0/255.0.0.0
permitted;IP.1=172.16.0.0/255.240.0.0
permitted;IP.2=192.168.0.0/255.255.0.0

If my assumption is correct, why does the CA/Browser Forum?s Baseline
Requirements define this? Do I have to do so because there's a bug
(somewhere) that permits certificates for IP addresses just because
DNS is permitted? Would I also have to exlcude email, URI, RID,
dirName and / or othername too?

Thank you very much in advance!


Best regards,

Ben

From secaficionado at gmail.com  Mon May 11 13:12:38 2015
From: secaficionado at gmail.com (Sec_Aficionado)
Date: Mon, 11 May 2015 09:12:38 -0400
Subject: [openssl-users] Stand alone AES-CTR module
In-Reply-To: <CAJe-LUg6Jd1iXw8TokLsVXotZYMh8yUCLMLqN=tTkm+ZVeaHDA@mail.gmail.com>
References: <CANW8MyQUS03=8e6D828XfLunirFDB6ECG860dEVdkhMzbM+Hmg@mail.gmail.com>
 <CAJe-LUg6Jd1iXw8TokLsVXotZYMh8yUCLMLqN=tTkm+ZVeaHDA@mail.gmail.com>
Message-ID: <61A47CA3-F222-4B65-ABB9-F3F1FAAC2863@gmail.com>

While implementing one's own security and/or cryptography is certainly not advisable for a novice (or even advanced programmers), creating cipher implementations from scratch is probably one of the best ways to learn and understand the intricacies of the problem at hand.

Learning about the pitfalls and advantages of the algorithms is key for a future security expert. Moreover, denying someone access to help on an open source project is antithetical to the OSS philosophy. How can anyone hope to understand code that by its very nature is cryptic and complex if there's no one willing to help disentangle, at least at a high level, the routines and functions?

InfoSec is a black art today, but it needs to get out of that mode. After the last few years it is clear that unless we open up the understanding of these disciplines, we will be at the mercy of experts with hidden agendas. Only educated users can hope to make correct use of cryptography, or be able to choose the best application for their needs. As we know, even a robust cipher is useless if utilized for the wrong purpose or poorly configured. We can't turn away those with a genuine interest in learning how to use cryptography without dooming ourselves to continue with the status quo.

I appeal to those of you who routinely share your knowledge and try to make a difference here, that you provide some guidance and not turn away people with basic questions like this one. These are the users who may become one day contributors. They should be nurtured and not shunned.

OK, I'll get off my soapbox now. Have a great week everyone.

> On May 10, 2015, at 5:58 PM, Mike Mohr <akihana at gmail.com> wrote:
> 
> The task of implementing AES should not be undertaken by a novice programmer.  Please save the world another heartbleed and pick something more in line with your skill level.
> 
>> On May 10, 2015 11:48 AM, "konstantinos Alexiou" <konstantinakos.a at gmail.com> wrote:
>> Dear Sirs,
>> 
>> 
>> I am new to C programming and i am trying to create an independent to libraries source code for demonstration purposes for AES-CTR mode.Could i have some help on doing that using the source code contained under crypto/aes.
>> 
>> 
>> Thank you very much in advance. 
>> 
>> _______________________________________________
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150511/1a8e0d08/attachment.html>

From nico at cryptonector.com  Mon May 11 16:25:33 2015
From: nico at cryptonector.com (Nico Williams)
Date: Mon, 11 May 2015 11:25:33 -0500
Subject: [openssl-users] Replacing RFC2712 (was Re: Kerberos)
In-Reply-To: <20150509035751.GF7287@localhost>
References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com>
 <20150508004035.GE17272@mournblade.imrryr.org>
 <554C1142.9090002@secure-endpoints.com>
 <1431119849.2490.2.camel@redhat.com>
 <20150509021811.GD7287@localhost> <20150509035751.GF7287@localhost>
Message-ID: <20150511162532.GH7287@localhost>

On Fri, May 08, 2015 at 10:57:52PM -0500, Nico Williams wrote:
> I should have mentioned NPN and ALPN too.
> [...]

A few more details:

 - If you don't want to depend on server certs, use anon-(EC)DH
   ciphersuites.

   Clients and servers must reject TLS connections using such a
   ciphersuite but not using a GSS-authenticated application protocol.

 - The protocol MUST use GSS channel binding to TLS.

 - Use SASL/GS2 instead of plain GSS and you get to use an authzid
   (optional) and you get a builtin authorization status result message
   at no extra cost, and all while still using GSS.

You get to optimize only the mechanism negotiation, and you get TLS w/
Kerberos (and others) and without PKIX (if you don't want it).

See RFCs 7301, 5801, 5056, and 5929 (but note that the TLS session hash
extension is required).

Nico
-- 

From openssl-users at dukhovni.org  Mon May 11 16:42:49 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 May 2015 16:42:49 +0000
Subject: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re:
	Kerberos)
In-Reply-To: <20150511162532.GH7287@localhost>
References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com>
 <20150508004035.GE17272@mournblade.imrryr.org>
 <554C1142.9090002@secure-endpoints.com>
 <1431119849.2490.2.camel@redhat.com>
 <20150509021811.GD7287@localhost> <20150509035751.GF7287@localhost>
 <20150511162532.GH7287@localhost>
Message-ID: <20150511164249.GX17272@mournblade.imrryr.org>

On Mon, May 11, 2015 at 11:25:33AM -0500, Nico Williams wrote:

>  - If you don't want to depend on server certs, use anon-(EC)DH
>    ciphersuites.
> 
>    Clients and servers must reject[*] TLS connections using such a
>    ciphersuite but not using a GSS-authenticated application protocol.

[*] Except when employing unauthenticated encrypted communication
to mitigate passive monitoring (oportunistic security).

-- 
	Viktor.

From noloader at gmail.com  Mon May 11 17:17:36 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 11 May 2015 13:17:36 -0400
Subject: [openssl-users] Stand alone AES-CTR module
In-Reply-To: <CANW8MyQUS03=8e6D828XfLunirFDB6ECG860dEVdkhMzbM+Hmg@mail.gmail.com>
References: <CANW8MyQUS03=8e6D828XfLunirFDB6ECG860dEVdkhMzbM+Hmg@mail.gmail.com>
Message-ID: <CAH8yC8mAbXS43RULX56ZYUMu=QE4R219HTYwRh-iwjmFoMZ+CQ@mail.gmail.com>

On Sun, May 10, 2015 at 2:47 PM, konstantinos Alexiou
<konstantinakos.a at gmail.com> wrote:
> Dear Sirs,
>
>
> I am new to C programming and i am trying to create an independent to
> libraries source code for demonstration purposes for AES-CTR mode.Could i
> have some help on doing that using the source code contained under
> crypto/aes.
>
You should use the EVP interfaces; see "EVP Symmetric Encryption and
Decryption" on the OpenSSL wiki
(https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption).
For counter mode, never reuse a counter or nonce within a security
context.

CTR mode provides confidentiality only, and its usually not enough to
meet expectations of security. You usually want both confidentiality
and authenticity assurances. The authenticity assurances provide both
entity authentication and data integrity. Its usually a better notion
of security and its called Authenticated Encryption.

For Authenticated Encryption, you should also use the EVP interfaces;
see "EVP Authenticated Encryption and Decryption" on the OpenSSL wiki
(https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption).
GCM mode is usually the mode you use when CWC mode (single pass) or
EAX mode (double pass; slightly better than GCM) is not available.

From noloader at gmail.com  Mon May 11 17:24:24 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 11 May 2015 13:24:24 -0400
Subject: [openssl-users] Stand alone AES-CTR module
In-Reply-To: <CAJe-LUg6Jd1iXw8TokLsVXotZYMh8yUCLMLqN=tTkm+ZVeaHDA@mail.gmail.com>
References: <CANW8MyQUS03=8e6D828XfLunirFDB6ECG860dEVdkhMzbM+Hmg@mail.gmail.com>
 <CAJe-LUg6Jd1iXw8TokLsVXotZYMh8yUCLMLqN=tTkm+ZVeaHDA@mail.gmail.com>
Message-ID: <CAH8yC8na6V0quQ3zegEON7KbWw43d2b89tjTcwOYaqp_aHUiUg@mail.gmail.com>

On Sun, May 10, 2015 at 5:58 PM, Mike Mohr <akihana at gmail.com> wrote:
> The task of implementing AES should not be undertaken by a novice
> programmer.  Please save the world another heartbleed and pick something
> more in line with your skill level.
Maybe I am not parsing it correctly.... It sounds like he wants to use
something like AES/CTR from an existing library like OpenSSL; and not
implement AES from the ground up.

Also, OpenSSL is susceptible to side channel attacks due to its table
driven implementation. So its not clear to me how he could do much
worse since a break is a break. You are either pregnant or you are
not. There's no degree's of pregnancy, like being half pregnant.

(There's some hand waiving above since it depends on the threat model.
But you usually don't exclude threats because they are inconvenient or
don't meet your efficiency goals. That's similar to what Browsers do
in their threat models - they exclude inconvenient stuff or stuff that
conflicts with their usability goals. That's one of the reasons
browser security is such a joke).

Jeff

From nico at cryptonector.com  Mon May 11 18:52:19 2015
From: nico at cryptonector.com (Nico Williams)
Date: Mon, 11 May 2015 13:52:19 -0500
Subject: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re:
 Kerberos)
In-Reply-To: <20150511164249.GX17272@mournblade.imrryr.org>
References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com>
 <20150508004035.GE17272@mournblade.imrryr.org>
 <554C1142.9090002@secure-endpoints.com>
 <1431119849.2490.2.camel@redhat.com>
 <20150509021811.GD7287@localhost> <20150509035751.GF7287@localhost>
 <20150511162532.GH7287@localhost>
 <20150511164249.GX17272@mournblade.imrryr.org>
Message-ID: <20150511185218.GI7287@localhost>

On Mon, May 11, 2015 at 04:42:49PM +0000, Viktor Dukhovni wrote:
> On Mon, May 11, 2015 at 11:25:33AM -0500, Nico Williams wrote:
> 
> >  - If you don't want to depend on server certs, use anon-(EC)DH
> >    ciphersuites.
> > 
> >    Clients and servers must reject[*] TLS connections using such a
> >    ciphersuite but not using a GSS-authenticated application protocol.
> 
> [*] Except when employing unauthenticated encrypted communication
> to mitigate passive monitoring (oportunistic security).

As this would be replacing RFC2712, it's not opportunistic to begin with :)

From akihana at gmail.com  Tue May 12 03:59:16 2015
From: akihana at gmail.com (Mike Mohr)
Date: Mon, 11 May 2015 20:59:16 -0700
Subject: [openssl-users] Stand alone AES-CTR module
In-Reply-To: <61A47CA3-F222-4B65-ABB9-F3F1FAAC2863@gmail.com>
References: <CANW8MyQUS03=8e6D828XfLunirFDB6ECG860dEVdkhMzbM+Hmg@mail.gmail.com>
 <CAJe-LUg6Jd1iXw8TokLsVXotZYMh8yUCLMLqN=tTkm+ZVeaHDA@mail.gmail.com>
 <61A47CA3-F222-4B65-ABB9-F3F1FAAC2863@gmail.com>
Message-ID: <CAJe-LUiOhEh=_s-FRfvTrktzNvpCAG-ntS7einJg+nCGTP32eg@mail.gmail.com>

If you don't know about list comprehension in Python, you can simply
construct a list in a loop to get the job done.  The end result is the same
no matter which approach you take.

The same is not true for cryptography.  While Sec_Aficionado is quite
eloquent and makes several valid points, I think his overall argument does
not hold water.  I have audited the crypto implementations in a number of
open-source projects over the years found wide variance in their quality.
In one instance a popular piece of software included a feature which
claimed to encrypt its data using AES-256.  It turned out that the code
copied the user's password directly into the key buffer, either padding
with null bytes or truncating depending on the length.  The data was then
encrypted using AES-256 in ECB mode.  The software's primary purpose was
not cryptography, and it provided innovative and creative features
otherwise.  This type of bug is insidious, since it doesn't really protect
the data in any meaningful way and lulls its users into a false sense of
security.

I am not advocating that the realm of information security be forever
relegated to a select few.  That is also dangerous, as Sec_Aficionado
correctly pointed out.  However, the study of cryptography should never be
undertaken without the guidance of an experienced practitioner.  I had the
extraordinary opportunity to study information security at university under
the guidance of an ex-NSA analyst.  I recognize that I am extremely lucky
to have had this chance, and that this kind of education is only available
to a select set of people worldwide.  I also don't have a solution to the
problem of training the next generation of cryptographers.  However, having
yet another potentially compromised AES implementation written by a novice
programmer is not something that I want to encourage.

On Mon, May 11, 2015 at 6:12 AM, Sec_Aficionado <secaficionado at gmail.com>
wrote:

> While implementing one's own security and/or cryptography is certainly not
> advisable for a novice (or even advanced programmers), creating cipher
> implementations from scratch is probably one of the best ways to learn and
> understand the intricacies of the problem at hand.
>
> Learning about the pitfalls and advantages of the algorithms is key for a
> future security expert. Moreover, denying someone access to help on an open
> source project is antithetical to the OSS philosophy. How can anyone hope
> to understand code that by its very nature is cryptic and complex if
> there's no one willing to help disentangle, at least at a high level, the
> routines and functions?
>
> InfoSec is a black art today, but it needs to get out of that mode. After
> the last few years it is clear that unless we open up the understanding of
> these disciplines, we will be at the mercy of experts with hidden agendas.
> Only educated users can hope to make correct use of cryptography, or be
> able to choose the best application for their needs. As we know, even a
> robust cipher is useless if utilized for the wrong purpose or poorly
> configured. We can't turn away those with a genuine interest in learning
> how to use cryptography without dooming ourselves to continue with the
> status quo.
>
> I appeal to those of you who routinely share your knowledge and try to
> make a difference here, that you provide some guidance and not turn away
> people with basic questions like this one. These are the users who may
> become one day contributors. They should be nurtured and not shunned.
>
> OK, I'll get off my soapbox now. Have a great week everyone.
>
> On May 10, 2015, at 5:58 PM, Mike Mohr <akihana at gmail.com> wrote:
>
> The task of implementing AES should not be undertaken by a novice
> programmer.  Please save the world another heartbleed and pick something
> more in line with your skill level.
> On May 10, 2015 11:48 AM, "konstantinos Alexiou" <
> konstantinakos.a at gmail.com> wrote:
>
>> Dear Sirs,
>>
>>
>> I am new to C programming and i am trying to create an independent to
>> libraries source code for demonstration purposes for AES-CTR mode.Could i
>> have some help on doing that using the source code contained under
>> crypto/aes.
>>
>>
>> Thank you very much in advance.
>>
>> _______________________________________________
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150511/87e942b0/attachment.html>

From lgrosenthal at 2rosenthals.com  Tue May 12 04:24:42 2015
From: lgrosenthal at 2rosenthals.com (Lewis Rosenthal)
Date: Tue, 12 May 2015 00:24:42 -0400
Subject: [openssl-users] Stand alone AES-CTR module
In-Reply-To: <CAJe-LUiOhEh=_s-FRfvTrktzNvpCAG-ntS7einJg+nCGTP32eg@mail.gmail.com>
References: <CANW8MyQUS03=8e6D828XfLunirFDB6ECG860dEVdkhMzbM+Hmg@mail.gmail.com>
 <CAJe-LUg6Jd1iXw8TokLsVXotZYMh8yUCLMLqN=tTkm+ZVeaHDA@mail.gmail.com>
 <61A47CA3-F222-4B65-ABB9-F3F1FAAC2863@gmail.com>
 <CAJe-LUiOhEh=_s-FRfvTrktzNvpCAG-ntS7einJg+nCGTP32eg@mail.gmail.com>
Message-ID: <5551808A.5000909@2rosenthals.com>

Hi, all...

I think it wise to go back to the OP's stated objective, to create "an 
independent to libraries source code for demonstration purposes for 
AES-CTR mode." The operative prepositional phrase here being "for 
demonstration purposes."

Thus, whether it is wise to implement one's own crypto 
library/engine/etc. in *production*, I see no particular reason why 
learning from creating one as a demonstration or proof of concept (and 
even providing such code here or elsewhere for critique) is such a bad 
thing.

This list is replete with experienced practitioners. If this isn't a 
good place to critique such a demonstration or proof of concept, perhaps 
someone here knows of a better list (one perhaps not focused on using 
OpenSSL in particular, say crypto.stackexchange.com - adn that is not an 
endorsement, merely an example).

On 05/11/2015 11:59 PM, Mike Mohr wrote:
> If you don't know about list comprehension in Python, you can simply 
> construct a list in a loop to get the job done. The end result is the 
> same no matter which approach you take.
>
> The same is not true for cryptography.  While Sec_Aficionado is quite 
> eloquent and makes several valid points, I think his overall argument 
> does not hold water.  I have audited the crypto implementations in a 
> number of open-source projects over the years found wide variance in 
> their quality.  In one instance a popular piece of software included a 
> feature which claimed to encrypt its data using AES-256.  It turned 
> out that the code copied the user's password directly into the key 
> buffer, either padding with null bytes or truncating depending on the 
> length.  The data was then encrypted using AES-256 in ECB mode.  The 
> software's primary purpose was not cryptography, and it provided 
> innovative and creative features otherwise.  This type of bug is 
> insidious, since it doesn't really protect the data in any meaningful 
> way and lulls its users into a false sense of security.
>
> I am not advocating that the realm of information security be forever 
> relegated to a select few.  That is also dangerous, as Sec_Aficionado 
> correctly pointed out.  However, the study of cryptography should 
> never be undertaken without the guidance of an experienced 
> practitioner.  I had the extraordinary opportunity to study 
> information security at university under the guidance of an ex-NSA 
> analyst.  I recognize that I am extremely lucky to have had this 
> chance, and that this kind of education is only available to a select 
> set of people worldwide.  I also don't have a solution to the problem 
> of training the next generation of cryptographers. However, having yet 
> another potentially compromised AES implementation written by a novice 
> programmer is not something that I want to encourage.
>
> On Mon, May 11, 2015 at 6:12 AM, Sec_Aficionado 
> <secaficionado at gmail.com <mailto:secaficionado at gmail.com>> wrote:
>
>     While implementing one's own security and/or cryptography is
>     certainly not advisable for a novice (or even advanced
>     programmers), creating cipher implementations from scratch is
>     probably one of the best ways to learn and understand the
>     intricacies of the problem at hand.
>
>     Learning about the pitfalls and advantages of the algorithms is
>     key for a future security expert. Moreover, denying someone access
>     to help on an open source project is antithetical to the OSS
>     philosophy. How can anyone hope to understand code that by its
>     very nature is cryptic and complex if there's no one willing to
>     help disentangle, at least at a high level, the routines and
>     functions?
>
>     InfoSec is a black art today, but it needs to get out of that
>     mode. After the last few years it is clear that unless we open up
>     the understanding of these disciplines, we will be at the mercy of
>     experts with hidden agendas. Only educated users can hope to make
>     correct use of cryptography, or be able to choose the best
>     application for their needs. As we know, even a robust cipher is
>     useless if utilized for the wrong purpose or poorly configured. We
>     can't turn away those with a genuine interest in learning how to
>     use cryptography without dooming ourselves to continue with the
>     status quo.
>
>     I appeal to those of you who routinely share your knowledge and
>     try to make a difference here, that you provide some guidance and
>     not turn away people with basic questions like this one. These are
>     the users who may become one day contributors. They should be
>     nurtured and not shunned.
>
>     OK, I'll get off my soapbox now. Have a great week everyone.
>
>     On May 10, 2015, at 5:58 PM, Mike Mohr <akihana at gmail.com
>     <mailto:akihana at gmail.com>> wrote:
>
>>     The task of implementing AES should not be undertaken by a novice
>>     programmer. Please save the world another heartbleed and pick
>>     something more in line with your skill level.
>>
>>     On May 10, 2015 11:48 AM, "konstantinos Alexiou"
>>     <konstantinakos.a at gmail.com <mailto:konstantinakos.a at gmail.com>>
>>     wrote:
>>
>>         Dear Sirs,
>>
>>
>>         I am new to C programming and i am trying to create an
>>         independent to libraries source code for demonstration
>>         purposes for AES-CTR mode.Could i have some help on doing
>>         that using the source code contained under crypto/aes.
>>
>>
>>         Thank you very much in advance.
>>

-- 
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA
Rosenthal & Rosenthal, LLC                www.2rosenthals.com
visit my IT blog                www.2rosenthals.net/wordpress
IRS Circular 230 Disclosure applies   see www.2rosenthals.com
-------------------------------------------------------------


From secaficionado at gmail.com  Tue May 12 12:47:49 2015
From: secaficionado at gmail.com (Sec_Aficionado)
Date: Tue, 12 May 2015 08:47:49 -0400
Subject: [openssl-users] Stand alone AES-CTR module
In-Reply-To: <5551808A.5000909@2rosenthals.com>
References: <CANW8MyQUS03=8e6D828XfLunirFDB6ECG860dEVdkhMzbM+Hmg@mail.gmail.com>
 <CAJe-LUg6Jd1iXw8TokLsVXotZYMh8yUCLMLqN=tTkm+ZVeaHDA@mail.gmail.com>
 <61A47CA3-F222-4B65-ABB9-F3F1FAAC2863@gmail.com>
 <CAJe-LUiOhEh=_s-FRfvTrktzNvpCAG-ntS7einJg+nCGTP32eg@mail.gmail.com>
 <5551808A.5000909@2rosenthals.com>
Message-ID: <6A855AE9-D8F2-4C34-A919-518C2DB0BD82@gmail.com>

Mike,

I agree that only security experts should implement production ciphers. But as Lewis pointed out, the OP's stated intention is to create a demo from scratch. This is what I think is worth doing and only for private distribution.

Publishing that demo or distributing it widely would be unwise, to say the least. In that case, I would totally echo your words. Paraphrasing Matthew D Green, we don't need to add more stupid to the Internet.

I'm advocating for the opportunity to learn from some of the best people in the field, not for adding noise to the misinformation out there.

> On May 12, 2015, at 12:24 AM, Lewis Rosenthal <lgrosenthal at 2rosenthals.com> wrote:
> 
> Hi, all...
> 
> I think it wise to go back to the OP's stated objective, to create "an independent to libraries source code for demonstration purposes for AES-CTR mode." The operative prepositional phrase here being "for demonstration purposes."
> 
> Thus, whether it is wise to implement one's own crypto library/engine/etc. in *production*, I see no particular reason why learning from creating one as a demonstration or proof of concept (and even providing such code here or elsewhere for critique) is such a bad thing.
> 
> This list is replete with experienced practitioners. If this isn't a good place to critique such a demonstration or proof of concept, perhaps someone here knows of a better list (one perhaps not focused on using OpenSSL in particular, say crypto.stackexchange.com - adn that is not an endorsement, merely an example).
> 
>> On 05/11/2015 11:59 PM, Mike Mohr wrote:
>> If you don't know about list comprehension in Python, you can simply construct a list in a loop to get the job done. The end result is the same no matter which approach you take.
>> 
>> The same is not true for cryptography.  While Sec_Aficionado is quite eloquent and makes several valid points, I think his overall argument does not hold water.  I have audited the crypto implementations in a number of open-source projects over the years found wide variance in their quality.  In one instance a popular piece of software included a feature which claimed to encrypt its data using AES-256.  It turned out that the code copied the user's password directly into the key buffer, either padding with null bytes or truncating depending on the length.  The data was then encrypted using AES-256 in ECB mode.  The software's primary purpose was not cryptography, and it provided innovative and creative features otherwise.  This type of bug is insidious, since it doesn't really protect the data in any meaningful way and lulls its users into a false sense of security.
>> 
>> I am not advocating that the realm of information security be forever relegated to a select few.  That is also dangerous, as Sec_Aficionado correctly pointed out.  However, the study of cryptography should never be undertaken without the guidance of an experienced practitioner.  I had the extraordinary opportunity to study information security at university under the guidance of an ex-NSA analyst.  I recognize that I am extremely lucky to have had this chance, and that this kind of education is only available to a select set of people worldwide.  I also don't have a solution to the problem of training the next generation of cryptographers. However, having yet another potentially compromised AES implementation written by a novice programmer is not something that I want to encourage.
>> 
>> On Mon, May 11, 2015 at 6:12 AM, Sec_Aficionado <secaficionado at gmail.com <mailto:secaficionado at gmail.com>> wrote:
>> 
>>    While implementing one's own security and/or cryptography is
>>    certainly not advisable for a novice (or even advanced
>>    programmers), creating cipher implementations from scratch is
>>    probably one of the best ways to learn and understand the
>>    intricacies of the problem at hand.
>> 
>>    Learning about the pitfalls and advantages of the algorithms is
>>    key for a future security expert. Moreover, denying someone access
>>    to help on an open source project is antithetical to the OSS
>>    philosophy. How can anyone hope to understand code that by its
>>    very nature is cryptic and complex if there's no one willing to
>>    help disentangle, at least at a high level, the routines and
>>    functions?
>> 
>>    InfoSec is a black art today, but it needs to get out of that
>>    mode. After the last few years it is clear that unless we open up
>>    the understanding of these disciplines, we will be at the mercy of
>>    experts with hidden agendas. Only educated users can hope to make
>>    correct use of cryptography, or be able to choose the best
>>    application for their needs. As we know, even a robust cipher is
>>    useless if utilized for the wrong purpose or poorly configured. We
>>    can't turn away those with a genuine interest in learning how to
>>    use cryptography without dooming ourselves to continue with the
>>    status quo.
>> 
>>    I appeal to those of you who routinely share your knowledge and
>>    try to make a difference here, that you provide some guidance and
>>    not turn away people with basic questions like this one. These are
>>    the users who may become one day contributors. They should be
>>    nurtured and not shunned.
>> 
>>    OK, I'll get off my soapbox now. Have a great week everyone.
>> 
>>    On May 10, 2015, at 5:58 PM, Mike Mohr <akihana at gmail.com
>>    <mailto:akihana at gmail.com>> wrote:
>> 
>>>    The task of implementing AES should not be undertaken by a novice
>>>    programmer. Please save the world another heartbleed and pick
>>>    something more in line with your skill level.
>>> 
>>>    On May 10, 2015 11:48 AM, "konstantinos Alexiou"
>>>    <konstantinakos.a at gmail.com <mailto:konstantinakos.a at gmail.com>>
>>>    wrote:
>>> 
>>>        Dear Sirs,
>>> 
>>> 
>>>        I am new to C programming and i am trying to create an
>>>        independent to libraries source code for demonstration
>>>        purposes for AES-CTR mode.Could i have some help on doing
>>>        that using the source code contained under crypto/aes.
>>> 
>>> 
>>>        Thank you very much in advance.
> 
> -- 
> Lewis
> -------------------------------------------------------------
> Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA
> Rosenthal & Rosenthal, LLC                www.2rosenthals.com
> visit my IT blog                www.2rosenthals.net/wordpress
> IRS Circular 230 Disclosure applies   see www.2rosenthals.com
> -------------------------------------------------------------
> 
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150512/02695ee9/attachment-0001.html>

From ben at an3k.de  Tue May 12 14:56:07 2015
From: ben at an3k.de (Ben Humpert)
Date: Tue, 12 May 2015 16:56:07 +0200
Subject: [openssl-users] x509_config nameConstraints
In-Reply-To: <CAGbjqfH4xP4+66chQKaf0oAP28-iN54fQi2iT9gbL4yP1Feriw@mail.gmail.com>
References: <CAGbjqfH4xP4+66chQKaf0oAP28-iN54fQi2iT9gbL4yP1Feriw@mail.gmail.com>
Message-ID: <CAGbjqfGe1YEkn+vHDw_u5vD_jiPsOGmWCW7qz3MkQ1C2CJp8MQ@mail.gmail.com>

Ok, after plenty of testing and some googling: the name constraints
extension is ... improvable. I ran plenty of tests but it looks like
that the extension is not very well implemented in todays browsers.

I have attached three txt files (DOS format) with the settings and
results of each test run. Between each test the browsers cache, etc.
was completely cleared and the browser got restarted. I validated the
used leaf certificates using serial number / hash and the signing CA
hash between each test run.

I used "certificate warning" if an error is shown but the user is
allowed to continue browsing and "certificate error" if the user is
NOT allowed to continue.

Results:
- Internet Explorer 11 does not understand the name IP in the
subjectAltName extension. However it understands the name DNS.
- Internet Explorer 11 just knows one certificate warning "This
website's address doesn't match the address in the security
certificate" regardless of why the certificate is invalid and no error
at all.

- (Test Run A.txt) nameConstraints extension NOT present
  - everything is fine

- (Test Run B.txt) nameConstraints extension present with
permitted;DNS and permitted;IP
  - OpenSSL s_client throws "Verify return code: 51 (unsupported name
constraint type)" whenever the name IP is present in the
subjectAltName extension. It does not do so when the name DNS is used
or when no subjectAltName extension is present at all. See Test B1,
B5, B8 and compare with Test B2, B3, B7
  - OpenSSL s_client throws "Verify return code: 47 (permitted subtree
violation)" while there is no violation. See Test B2
  - OpenSSL s_client does not check for nameConstraints violation in
CN at all. See Test B7, B10
  - Firefox does NOT check for nameConstraints violation in CN if
subjectAltName is present. See Test B5
  - Firefox just throws a warning "ssl_error_bad_cert_domain" instead
of an error when the certificate is used on a domain / ip address
which is not specified in the certificate. See Test B3, B4
  - Chrome throws an error "Server's certificate is invalid" when
there is no subjectAltName present but the ip address matches the
certificate CN. See Test B4

- (Test Run C.txt) nameConstraints extension present with
permitted;DNS and permitted;IP and permitted;dirName
  - Firefox throws an error "sec_error_cert_not_in_name_space" even
when the domain is specified in subjectAltName and no nameConstraints
violation exists. It's by the way the first time Internet Explorer
acted correctly ;). See Test C2
  - OpenSSL s_client throws "Verify return code: 47 (permitted subtree
violation)" while there is no violation. See Test C2
  - Chrome, Firefox (and for sure Internet Explorer) throwed an error
while there is no nameConstraints violation. Only OpenSSL s_client
acted correctly (but only because it doesn't check CN). See Test C4

From ben at an3k.de  Tue May 12 14:56:38 2015
From: ben at an3k.de (Ben Humpert)
Date: Tue, 12 May 2015 16:56:38 +0200
Subject: [openssl-users] x509_config nameConstraints
In-Reply-To: <CAGbjqfGe1YEkn+vHDw_u5vD_jiPsOGmWCW7qz3MkQ1C2CJp8MQ@mail.gmail.com>
References: <CAGbjqfH4xP4+66chQKaf0oAP28-iN54fQi2iT9gbL4yP1Feriw@mail.gmail.com>
 <CAGbjqfGe1YEkn+vHDw_u5vD_jiPsOGmWCW7qz3MkQ1C2CJp8MQ@mail.gmail.com>
Message-ID: <CAGbjqfGCAqBD8ucH2-c_Ma9phKFbgfNvYvLgPWRvK584R4Uuwg@mail.gmail.com>

I love that when it happens :)

2015-05-12 16:56 GMT+02:00 Ben Humpert <ben at an3k.de>:
> Ok, after plenty of testing and some googling: the name constraints
> extension is ... improvable. I ran plenty of tests but it looks like
> that the extension is not very well implemented in todays browsers.
>
> I have attached three txt files (DOS format) with the settings and
> results of each test run. Between each test the browsers cache, etc.
> was completely cleared and the browser got restarted. I validated the
> used leaf certificates using serial number / hash and the signing CA
> hash between each test run.
>
> I used "certificate warning" if an error is shown but the user is
> allowed to continue browsing and "certificate error" if the user is
> NOT allowed to continue.
>
> Results:
> - Internet Explorer 11 does not understand the name IP in the
> subjectAltName extension. However it understands the name DNS.
> - Internet Explorer 11 just knows one certificate warning "This
> website's address doesn't match the address in the security
> certificate" regardless of why the certificate is invalid and no error
> at all.
>
> - (Test Run A.txt) nameConstraints extension NOT present
>   - everything is fine
>
> - (Test Run B.txt) nameConstraints extension present with
> permitted;DNS and permitted;IP
>   - OpenSSL s_client throws "Verify return code: 51 (unsupported name
> constraint type)" whenever the name IP is present in the
> subjectAltName extension. It does not do so when the name DNS is used
> or when no subjectAltName extension is present at all. See Test B1,
> B5, B8 and compare with Test B2, B3, B7
>   - OpenSSL s_client throws "Verify return code: 47 (permitted subtree
> violation)" while there is no violation. See Test B2
>   - OpenSSL s_client does not check for nameConstraints violation in
> CN at all. See Test B7, B10
>   - Firefox does NOT check for nameConstraints violation in CN if
> subjectAltName is present. See Test B5
>   - Firefox just throws a warning "ssl_error_bad_cert_domain" instead
> of an error when the certificate is used on a domain / ip address
> which is not specified in the certificate. See Test B3, B4
>   - Chrome throws an error "Server's certificate is invalid" when
> there is no subjectAltName present but the ip address matches the
> certificate CN. See Test B4
>
> - (Test Run C.txt) nameConstraints extension present with
> permitted;DNS and permitted;IP and permitted;dirName
>   - Firefox throws an error "sec_error_cert_not_in_name_space" even
> when the domain is specified in subjectAltName and no nameConstraints
> violation exists. It's by the way the first time Internet Explorer
> acted correctly ;). See Test C2
>   - OpenSSL s_client throws "Verify return code: 47 (permitted subtree
> violation)" while there is no violation. See Test C2
>   - Chrome, Firefox (and for sure Internet Explorer) throwed an error
> while there is no nameConstraints violation. Only OpenSSL s_client
> acted correctly (but only because it doesn't check CN). See Test C4
-------------- next part --------------
Ok, after plenty of testing and some googling: the name constraints extension is ... improvable.

My Structure:
- Root CA
  - Intermediate CA 1
    - Intermediate CA 2
      - Intermediate CA 3
        - Signing CA

The Intermediate CA 3 writes name constraints into the Signing CA's certificate. The web server provides certificates for all Intermediate CAs and the Signing CA in the correct order.

I didn't had any nameConstraints configured in these tests
###################################
Test A1

leaf certificate issued to >> E = root at an3k.de, CN = backup.an3k.lan, O = an3k Industries Ltd., L = Munich, S = DE-BY, C = DE <<
subjectAltName=IP:10.11.12.13

- Google Chrome 42
  https://backup.an3k.lan	certification warning ("Server's certificate does not match the URL")
  https://10.11.12.13		green lock

- Mozilla Firefox 37
  https://backup.an3k.lan	certification warning ("ssl_error_bad_cert_domain")
  https://10.11.12.13		gray lock

- Internet Explorer 11
  https://backup.an3k.lan	black lock
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client 
  https://10.11.12.13		"Verify return code: 0 (ok)"
###################################
Test A2 (need to test)

leaf certificate issued to >> E = root at an3k.de, CN = 10.11.12.13, O = an3k Industries Ltd., L = Munich, S = DE-BY, C = DE <<
subjectAltName=DNS:backup.an3k.lan

- Google Chrome 42
  https://backup.an3k.lan	green lock
  https://10.11.12.13		certification warning ("Server's certificate does not match the URL")

- Mozilla Firefox 37
  https://backup.an3k.lan	gray lock
  https://10.11.12.13		certification warning ("ssl_error_bad_cert_domain")

- Internet Explorer 11
  https://backup.an3k.lan	black lock
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client 
  https://10.11.12.13		"Verify return code: 0 (ok)"
###################################
Test A3

leaf certificate issued to >> E = root at an3k.de, CN = backup.an3k.lan, O = an3k Industries Ltd., L = Munich, S = DE-BY, C = DE <<
no subjectAltName extension

- Google Chrome 42
  https://backup.an3k.lan	green lock
  https://10.11.12.13		certification warning ("Server's certificate does not match the URL")

- Mozilla Firefox 37
  https://backup.an3k.lan	gray lock
  https://10.11.12.13		certification warning ("ssl_error_bad_cert_domain")

- Internet Explorer 11
  https://backup.an3k.lan	black lock
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client 
  https://10.11.12.13		"Verify return code: 0 (ok)"
###################################
Test A4

leaf certificate issued to >> E = root at an3k.de, CN = 10.11.12.13, O = an3k Industries Ltd., L = Munich, S = DE-BY, C = DE <<
no subjectAltName extension

- Google Chrome 42
  https://backup.an3k.lan	certification error ("Server's certificate is invalid")
  https://10.11.12.13		green lock

- Mozilla Firefox 37
  https://backup.an3k.lan	certification warning ("ssl_error_bad_cert_domain")
  https://10.11.12.13		gray lock

- Internet Explorer 11
  https://backup.an3k.lan	certification warning ("This website's address doesn't match the address in the security certificate")
  https://10.11.12.13		black lock

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client 
  https://10.11.12.13		"Verify return code: 0 (ok)"
-------------- next part --------------
Ok, after plenty of testing and some googling: the name constraints extension is ... improvable.

My Structure:
- Root CA
  - Intermediate CA 1
    - Intermediate CA 2
      - Intermediate CA 3
        - Signing CA

The Intermediate CA 3 writes name constraints into the Signing CA's certificate. The web server provides certificates for all Intermediate CAs and the Signing CA in the correct order.

I used this configuration:
permitted;DNS.0=.lan
permitted;DNS.1=.local
permitted;IP.0=10.0.0.0/255.0.0.0
permitted;IP.1=172.16.0.0/255.240.0.0
permitted;IP.2=192.168.0.0/255.255.0.0
###################################
Test B1

leaf certificate issued to >> E = root at an3k.de, CN = backup.an3k.lan, O = an3k Industries Ltd., L = Munich, S = DE-BY, C = DE <<
subjectAltName=IP:10.11.12.13

- Google Chrome 42
  https://backup.an3k.lan	certification warning ("Server's certificate does not match the URL")
  https://10.11.12.13		green lock

- Mozilla Firefox 37
  https://backup.an3k.lan	certification warning ("ssl_error_bad_cert_domain")
  https://10.11.12.13		gray lock

- Internet Explorer 11
  https://backup.an3k.lan	black lock
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client
  https://10.11.12.13		"Verify return code: 51 (unsupported name constraint type)"
###################################
Test B2

leaf certificate issued to >> E = root at an3k.de, CN = 10.11.12.13, O = an3k Industries Ltd., L = Munich, S = DE-BY, C = DE <<
subjectAltName=DNS:backup.an3k.lan

- Google Chrome 42
  https://backup.an3k.lan	green lock
  https://10.11.12.13		certification warning ("Server's certificate does not match the URL")

- Mozilla Firefox 37
  https://backup.an3k.lan	gray lock
  https://10.11.12.13		certification warning ("ssl_error_bad_cert_domain")

- Internet Explorer 11
  https://backup.an3k.lan	black lock
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client
  https://10.11.12.13		"Verify return code: 47 (permitted subtree violation)"
###################################
Test B3

leaf certificate issued to >> E = root at an3k.de, CN = backup.an3k.lan, O = an3k Industries Ltd., L = Munich, S = DE-BY, C = DE <<
no subjectAltName extension

- Google Chrome 42
  https://backup.an3k.lan	green lock
  https://10.11.12.13		certification error ("Server's certificate is invalid")

- Mozilla Firefox 37
  https://backup.an3k.lan	gray lock
  https://10.11.12.13		certification warning ("ssl_error_bad_cert_domain")

- Internet Explorer 11
  https://backup.an3k.lan	black lock
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client
  https://10.11.12.13		"Verify return code: 0 (ok)"
###################################
Test B4

leaf certificate issued to >> E = root at an3k.de, CN = 10.11.12.13, O = an3k Industries Ltd., L = Munich, S = DE-BY, C = DE <<
no subjectAltName extension

- Google Chrome 42
  https://backup.an3k.lan	certification error ("Server's certificate does not match the URL" and "Server's certificate is invalid")
  https://10.11.12.13		certification error ("Server's certificate is invalid")

- Mozilla Firefox 37
  https://backup.an3k.lan	certification warning ("ssl_error_bad_cert_domain")
  https://10.11.12.13		gray lock

- Internet Explorer 11
  https://backup.an3k.lan	certification warning ("This website's address doesn't match the address in the security certificate")
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client
  https://10.11.12.13		"Verify return code: 0 (ok)"
###################################
Test B5

leaf certificate issued to >> E = root at an3k.de, CN = www.an3k.de, O = an3k Industries Ltd., L = Munich, S = DE-BY, C = DE <<
subjectAltName=IP:10.11.12.13

- Google Chrome 42
  https://www.an3k.de		certification error ("Server's certificate does not match the URL" and "Server's certificate is invalid")
  https://10.11.12.13		certification error ("Server's certificate is invalid")

- Mozilla Firefox 37
  https://www.an3k.de		certification warning ("ssl_error_bad_cert_domain")
  https://10.11.12.13		gray lock

- Internet Explorer 11
  https://www.an3k.de		certification warning ("This website's address doesn't match the address in the security certificate")
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client
  https://10.11.12.13		"Verify return code: 51 (unsupported name constraint type)"
###################################
Test B6

leaf certificate issued to >> E = root at an3k.de, CN = 10.11.12.13, O = an3k Industries Ltd., L = Munich, S = DE-BY, C = DE <<
subjectAltName=DNS:www.an3k.de

- Google Chrome 42
  https://www.an3k.de		certification error ("Server's certificate is invalid")
  https://10.11.12.13		certification error ("Server's certificate does not match the URL" and "Server's certificate is invalid")

- Mozilla Firefox 37
  https://www.an3k.de		certification error ("sec_error_cert_not_in_name_space")
  https://10.11.12.13		certification error ("sec_error_cert_not_in_name_space")

- Internet Explorer 11
  https://www.an3k.de		certification warning ("This website's address doesn't match the address in the security certificate")
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client
  https://10.11.12.13		"Verify return code: 47 (permitted subtree violation)"
###################################
Test B7

leaf certificate issued to >> E = root at an3k.de, CN = www.an3k.de, O = an3k Industries Ltd., L = Munich, S = DE-BY, C = DE <<
no subjectAltName extension

- Google Chrome 42
  https://www.an3k.de		certification error ("Server's certificate is invalid")
  https://10.11.12.13		certification error ("Server's certificate does not match the URL" and "Server's certificate is invalid")

- Mozilla Firefox 37
  https://www.an3k.de		certification error ("sec_error_cert_not_in_name_space")
  https://10.11.12.13		certification error ("sec_error_cert_not_in_name_space")

- Internet Explorer 11
  https://www.an3k.de		certification warning ("This website's address doesn't match the address in the security certificate")
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client
  https://10.11.12.13		"Verify return code: 0 (ok)"
###################################
Test B8

leaf certificate issued to >> E = root at an3k.de, CN = www.an3k.de, O = an3k Industries Ltd., L = Munich, S = DE-BY, C = DE <<
subjectAltName=IP:8.8.8.8

- Google Chrome 42
  https://www.an3k.de		certification error ("Server's certificate does not match the URL" and "Server's certificate is invalid")
  https://10.11.12.13		certification error ("Server's certificate does not match the URL" and "Server's certificate is invalid")

- Mozilla Firefox 37
  https://www.an3k.de		certification error ("sec_error_cert_not_in_name_space")
  https://10.11.12.13		certification error ("sec_error_cert_not_in_name_space")

- Internet Explorer 11
  https://www.an3k.de		certification warning ("This website's address doesn't match the address in the security certificate")
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client
  https://10.11.12.13		"Verify return code: 51 (unsupported name constraint type)"
###################################
Test B9

leaf certificate issued to >> E = root at an3k.de, CN = 8.8.8.8, O = an3k Industries Ltd., L = Munich, S = DE-BY, C = DE <<
subjectAltName=DNS:www.an3k.de

- Google Chrome 42
  https://www.an3k.de		certification error ("Server's certificate is invalid")
  https://10.11.12.13		certification error ("Server's certificate does not match the URL" and "Server's certificate is invalid")

- Mozilla Firefox 37
  https://www.an3k.de		certification error ("sec_error_cert_not_in_name_space")
  https://10.11.12.13		certification error ("sec_error_cert_not_in_name_space")

- Internet Explorer 11
  https://www.an3k.de		certification warning ("This website's address doesn't match the address in the security certificate")
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client
  https://10.11.12.13		"Verify return code: 47 (permitted subtree violation)"
###################################
Test B10

leaf certificate issued to >> E = root at an3k.de, CN = 8.8.8.8, O = an3k Industries Ltd., L = Munich, S = DE-BY, C = DE <<
no subjectAltName extension

- Google Chrome 42
  https://backup.an3k.lan	certification error ("Server's certificate does not match the URL" and "Server's certificate is invalid")
  https://10.11.12.13		certification error ("Server's certificate does not match the URL" and "Server's certificate is invalid")

- Mozilla Firefox 37
  https://backup.an3k.lan	certification error ("sec_error_cert_not_in_name_space")
  https://10.11.12.13		certification error ("sec_error_cert_not_in_name_space")

- Internet Explorer 11
  https://backup.an3k.lan	certification warning ("This website's address doesn't match the address in the security certificate")
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client
  https://10.11.12.13		"Verify return code: 0 (ok)"
-------------- next part --------------
Ok, after plenty of testing and some googling: the name constraints extension is ... improvable.

My Structure:
- Root CA
  - Intermediate CA 1
    - Intermediate CA 2
      - Intermediate CA 3
        - Signing CA

The Intermediate CA 3 writes name constraints into the Signing CA's certificate. The web server provides certificates for all Intermediate CAs and the Signing CA in the correct order.

I used this configuration:
permitted;DNS.0=.lan
permitted;DNS.1=.local
permitted;IP.0=10.0.0.0/255.0.0.0
permitted;IP.1=172.16.0.0/255.240.0.0
permitted;IP.2=192.168.0.0/255.255.0.0
permitted;dirName=dir_sect

[dir_sect]
CN=10.11.12.13
###################################
Test C1

leaf certificate issued to >> CN = backup.an3k.lan <<
subjectAltName=IP:10.11.12.13

- Google Chrome 42
  https://backup.an3k.lan	certification error ("Server's certificate does not match the URL" and "Server's certificate is invalid")
  https://10.11.12.13		certification error ("Server's certificate is invalid")

- Mozilla Firefox 37
  https://backup.an3k.lan	certification error ("sec_error_cert_not_in_name_space")
  https://10.11.12.13		certification error ("sec_error_cert_not_in_name_space")

- Internet Explorer 11
  https://backup.an3k.lan	certification warning ("This website's address doesn't match the address in the security certificate")
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client
  https://10.11.12.13		"Verify return code: 47 (permitted subtree violation)"
###################################
Test C2

leaf certificate issued to >> CN = 10.11.12.13 <<
subjectAltName=DNS:backup.an3k.lan

- Google Chrome 42
  https://backup.an3k.lan	green lock
  https://10.11.12.13		certification warning ("Server's certificate does not match the URL")

- Mozilla Firefox 37
  https://backup.an3k.lan	certification error ("sec_error_cert_not_in_name_space")
  https://10.11.12.13		certification error ("sec_error_cert_not_in_name_space")

- Internet Explorer 11
  https://backup.an3k.lan	black lock
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client
  https://10.11.12.13		"Verify return code: 47 (permitted subtree violation)"
###################################
Test C3

leaf certificate issued to >> CN = backup.an3k.lan <<
no subjectAltName extension

- Google Chrome 42
  https://backup.an3k.lan	certification error ("Server's certificate is invalid")
  https://10.11.12.13		certification error ("Server's certificate does not match the URL" and "Server's certificate is invalid")

- Mozilla Firefox 37
  https://backup.an3k.lan	certification error ("sec_error_cert_not_in_name_space")
  https://10.11.12.13		certification error ("sec_error_cert_not_in_name_space")

- Internet Explorer 11
  https://backup.an3k.lan	certification warning ("This website's address doesn't match the address in the security certificate")
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client
  https://10.11.12.13		"Verify return code: 47 (permitted subtree violation)"
###################################
Test C4

leaf certificate issued to >> CN = 10.11.12.13 <<
no subjectAltName extension

- Google Chrome 42
  https://backup.an3k.lan	certification error ("Server's certificate does not match the URL" and "Server's certificate is invalid")
  https://10.11.12.13		certification error ("Server's certificate is invalid")

- Mozilla Firefox 37
  https://backup.an3k.lan	certification error ("sec_error_cert_not_in_name_space")
  https://10.11.12.13		certification error ("sec_error_cert_not_in_name_space")

- Internet Explorer 11
  https://backup.an3k.lan	certification warning ("This website's address doesn't match the address in the security certificate")
  https://10.11.12.13		certification warning ("This website's address doesn't match the address in the security certificate")

- OpenSSL 1.0.1f (Ubuntu Server 14.04.2) s_client
  https://10.11.12.13		"Verify return code: 0 (ok)"

From jb-openssl at wisemo.com  Tue May 12 16:43:38 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 12 May 2015 18:43:38 +0200
Subject: [openssl-users] How do I uninitialize OpenSSL properly?
In-Reply-To: <trinity-e775453c-a4c4-48cd-a2d9-e2f62667b377-1430387290110@3capp-webde-bs49>
References: <trinity-cb605a5d-851f-4643-b1ed-0e0f5348ef85-1429886585113@msvc-mesg-web009>
 <553CFAA0.6060201@web.de>
 <aaef61b169274a8ebcb3d1631f1f3ec9@usma1ex-dag1mb2.msg.corp.akamai.com>
 <553D2B19.1080405@web.de> <553FC83F.9010206@web.de>,
 <054704bd6a5a4a8a991e802dd8102e7c@usma1ex-dag1mb4.msg.corp.akamai.com>
 <trinity-e775453c-a4c4-48cd-a2d9-e2f62667b377-1430387290110@3capp-webde-bs49>
Message-ID: <55522DBA.9010002@wisemo.com>

(Top posting to keep thread consistent).

It is also worth noting that if OpenSSL is used in a
plugin, which is unloaded (along with OpenSSL) and later
reloaded long before the container process is unloaded,
then "things that are only allocated once per OpenSSL
library lifetime" become very real memory leaks in that
container process.

On 30/04/2015 11:48, Newcomer83 at web.de wrote:
> According to the answer I received at 
> http://stackoverflow.com/questions/29845527/how-to-properly-uninitialize-openssl 
> there is apparently a ticket with my problem out there already, namely 
> the one here: https://rt.openssl.org/Ticket/Display.html?id=2561 The 
> newest answer even references my thread.
> I know some people don't like removing memory leaks of objects that 
> get initialized only once and are being used until shutdown, but if 
> the solution Mat proposed really does the trick, I would really 
> appreciate it if someone(tm) could take the time to put this seemingly 
> small fix in the code.
> Cheers
> Alex
> *Gesendet:* Dienstag, 28. April 2015 um 20:06 Uhr
> *Von:* "Salz, Rich" <rsalz at akamai.com>
> *An:* "openssl-users at openssl.org" <openssl-users at openssl.org>
> *Betreff:* Re: [openssl-users] How do I uninitialize OpenSSL properly?
> > Unfortunately this didn't solve my problem, but at least I narrowed 
> it down.
> > The leaks are caused by my call to "SSL_CTX_load_verify_locations", 
> which is
> > essentially "X509_STORE_load_locations".
>
> Doesn't freeing the SSL_CTX_free release that data? If not, please 
> file an RT ticket.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From m.vinicius at samsung.com  Tue May 12 17:56:05 2015
From: m.vinicius at samsung.com (Marcus Vinicius do Nascimento)
Date: Tue, 12 May 2015 14:56:05 -0300
Subject: [openssl-users] Testing OpenSSL based solution
Message-ID: <008001d08cdc$ec857f50$c5907df0$@samsung.com>

I'm working on a C++ security library solution that uses openssl internally.

It offers Sign/Verify, Digest and Encrypt/Decrypt as its features (please
check available methods below).

 

I'm using FIPS 2.0 test vectors to validate my library, but I'm having a bit
of trouble with that.

 

Testing Digest is easy. It is just a matter of providing any data and check
whether the returned value matches expected values.

FIPS 2.0 is working just fine here.

 

Testing Sign/Verify is a whole different story. My understanding is that
algorithms use random parameters to sign data, so two consecutive calls to
sign with the same parameters would yield different results.

I guess I have to sign some data, and verify it to make sure that's working.

FIPS provides testing parameters that are not trivial (message, y, r, s) and
I'm not sure how to handle them. Is it possible to use those parameters
considering my API (check below)?

 

I haven't tried testing the encrypt/decrypt methods, since I'm stuck in the
Sign/Verify.

 

Do you think using FIPS test vectors to validate my solution is a
good/feasible approach?

Is there any better/simpler testing approach?

 

This is my API:

    Sign/Verify:

 

        std::string /* B64 */ sign( std::string algorithm, std::string
private_key /* B64 */, std::string data /* B64 */, bool &error );

        bool verify( std::string algorithm, std::string data /* B64 */,
std::string signature /* B64 */, std::string public_key /* B64 */, bool
&error );

    

        Algorithims: SHA1, SHA256, SHA384, SHA512 with RSA, ECDSA and
SHA1withDSA.

 

    Digest:

 

        std::string /* B64 */ digest( std::string algorithm, std::string
data );

    

        Algorithms: SHA1, SHA256, SHA384, SHA512.

 

    Encrypt/Decrypt:

 

        std::string /* B64 */ encrypt( std::string algorithm, bool padding,
std::string data /* B64 */, std::string key  /* B64 */ );

        std::string /* B64 */ decrypt( std::string algorithm, bool padding,
std::string data /* B64 */, std::string key  /* B64 */ );

 

        Algorithms: des-ede-cbc, des-ede, des-ede-cfb, des-ede-ofb,
des-ede3-cbc, des-ede3, des3, des-ede3-cfb, des-ede3-ofb,
aes-[128|192|256]-cbc, aes-[128|192|256], aes-[128|192|256]-cfb,
aes-[128|192|256]-cfb1, aes-[128|192|256]-cfb8, aes-[128|192|256]-ecb,
aes-[128|192|256]-ofb.

 

Thanks very much,

 

Marcus

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150512/1488f720/attachment.html>

From rsalz at akamai.com  Tue May 12 18:10:39 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 12 May 2015 18:10:39 +0000
Subject: [openssl-users] Testing OpenSSL based solution
In-Reply-To: <008001d08cdc$ec857f50$c5907df0$@samsung.com>
References: <008001d08cdc$ec857f50$c5907df0$@samsung.com>
Message-ID: <956488fa72044d4fbd2be123d14dd2ff@ustx2ex-dag1mb4.msg.corp.akamai.com>

You can't easily have test vectors for DSA signatures since they include a random.  Any test vector would have to include the random, and any API would have to be able to accept the random as part of the "sign" API.  Verification should be okay.


From jb-openssl at wisemo.com  Tue May 12 18:23:34 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 12 May 2015 20:23:34 +0200
Subject: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re:
	Kerberos)
In-Reply-To: <20150511185218.GI7287@localhost>
References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com>
 <20150508004035.GE17272@mournblade.imrryr.org>
 <554C1142.9090002@secure-endpoints.com> <1431119849.2490.2.camel@redhat.com>
 <20150509021811.GD7287@localhost> <20150509035751.GF7287@localhost>
 <20150511162532.GH7287@localhost>
 <20150511164249.GX17272@mournblade.imrryr.org>
 <20150511185218.GI7287@localhost>
Message-ID: <55524526.4000207@wisemo.com>

On 11/05/2015 20:52, Nico Williams wrote:
> On Mon, May 11, 2015 at 04:42:49PM +0000, Viktor Dukhovni wrote:
>> On Mon, May 11, 2015 at 11:25:33AM -0500, Nico Williams wrote:
>>
>>>   - If you don't want to depend on server certs, use anon-(EC)DH
>>>     ciphersuites.
>>>
>>>     Clients and servers must reject[*] TLS connections using such a
>>>     ciphersuite but not using a GSS-authenticated application protocol.
>> [*] Except when employing unauthenticated encrypted communication
>> to mitigate passive monitoring (oportunistic security).
> As this would be replacing RFC2712, it's not opportunistic to begin with :)
As this would be a new RFC, it might be usable for cases
where RFC2712 was never usable.

How about the following simplifications for the new
extension, lets call  it "GSS-2" (at least in this e-mail).

1. GSS (including SASL/GS2) is always done via the SPNego
GSS mechanism, which provides standard handling of
mechanism negotiation (including round-trip optimizations),
and is already its own standard (complete with workarounds
for historic bugs in the dominant implementation...).

2. The TLS client always begins by sending the first
GSS/SPNego leg in a (new) TLS extension "GSS-2".

3. The TLS server (if it supports and allows the extension)
responds with a 0 byte TLS extension "GSS-2" to confirm
support.

4. The second and subsequent legs of the GSS handshake are
sent as the sole contents of the first encrypted records,
actual application data is not sent until the GSS handshake
succeeds.  Note that the first encrypted server to client
record (containing the second leg) can be sent in the same
protocol round trip as the second half of the TLS
handshake.  It is an open design issue if these TLS records
should be tagged as application records or key exchange
records.

5. In the last legs, the GSS mechanism is told to (mutually
if possible) authenticate some already defined hash of the
TLS handshake, thereby protecting the key exchange.Other
than the round trip saving for the first 2 legs, this is
what distinguishes GSS-2 from simply doing application level
GSS over a TLS connection.  Any GSS negotiated keys are not
used beyond this authentication of the TLS key exchange.

6. If the GSS mechanism preferred by the client requires the
authenticated hash value to be known before sending the
first GSS leg, then the client shall simply abstain from
including that first leg in the first leg SPNego message
if sent in the client hello extension.

7. If the client wants encryption of the first GSS leg, it
can either abstain from including that leg in the first
SPNego GSS leg, or it can send a 0-byte first leg and then
send the real first SPNego leg in the first encrypted client
o server record, with the server responding with the second
leg in the first encrypted server to client record as before
(but no longer in the same round trip as the second half of
the TLS handshake).

8. If the GSS mechanism reports failure, the TLS connection
SHALL be aborted with a specified alert.

9. When the "GSS-2" extension is negotiated, TLS
implementations SHOULD allow anonymous (unauthenticated)
cipher suites even if they would not otherwise do so,
however they MUST be able to combine the "GSS-2" extension
with any and all of the cipher suites and TLS versions they
otherwise implement.  For instance, if an implementation of
the "GSS-2" extension is somehow bolted on to a fully
patched OpenSSL 1.0.0 library (via generic extension
mechanisms), then that combination would support it with
TLS 1.0 only, and TLS 1.3 capable implementations would be
negotiating TLS 1.0 when doing "GSS-2" with such an
implementation.

10. Session resumption and Session renegotiation shall have
the same semantics for the GSS authentication result as
they do for certificate validation results done in the
same handshakes.

11. NPN and ALPN are neither required nor affected by GSS-2
and operate as they would with any other TLS mechanisms,
such as certificates.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150512/d9bfd323/attachment-0001.html>

From jb-openssl at wisemo.com  Tue May 12 18:42:01 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 12 May 2015 20:42:01 +0200
Subject: [openssl-users] Testing OpenSSL based solution
In-Reply-To: <956488fa72044d4fbd2be123d14dd2ff@ustx2ex-dag1mb4.msg.corp.akamai.com>
References: <008001d08cdc$ec857f50$c5907df0$@samsung.com>
 <956488fa72044d4fbd2be123d14dd2ff@ustx2ex-dag1mb4.msg.corp.akamai.com>
Message-ID: <55524979.7000809@wisemo.com>

On 12/05/2015 20:10, Salz, Rich wrote:
> You can't easily have test vectors for DSA signatures since they include a random.  Any test vector would have to include the random, and any API would have to be able to accept the random as part of the "sign" API.  Verification should be okay.
>
>

What Mr. Salz refers to by "Verification should be okay"
is probably this:

You can have test vectors in the form of known good
signatures withpublic keys listed in the test vector.
For DSA, those would be the (message, y, r, s)quads
mentioned by the OP (y is the public key, (r, s) is the
signature), dependingon his class library, it might be
possible to reformat those vectors to the formatused
by his code for real messages.

The importance of such test vectors is to detect if an
implementation is accidentally implementing a different
signature algorithm (such as accidentally appending a 0
byte to each message both during signing and
verification).  This would not be detected by signing
and verifying sample messages with random parameters.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150512/42bf5255/attachment.html>

From rsalz at akamai.com  Tue May 12 18:44:33 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 12 May 2015 18:44:33 +0000
Subject: [openssl-users] Testing OpenSSL based solution
In-Reply-To: <55524979.7000809@wisemo.com>
References: <008001d08cdc$ec857f50$c5907df0$@samsung.com>
 <956488fa72044d4fbd2be123d14dd2ff@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <55524979.7000809@wisemo.com>
Message-ID: <a1297350c138421daf179dc4109dd8ce@ustx2ex-dag1mb4.msg.corp.akamai.com>

> What Mr. Salz refers to by "Verification should be okay" is probably this:

Yes and Mr. Salz greatly appreciates Mr. Bohm's elaboration.

:)

Lest the humor be misunderstood:  yes, you're right, thanks for explaining.

From dweidenkopf at cococorp.com  Tue May 12 18:49:50 2015
From: dweidenkopf at cococorp.com (David Weidenkopf)
Date: Tue, 12 May 2015 11:49:50 -0700
Subject: [openssl-users] FIPS mode and
	AES_set_encrypt_key/AES_set_decrypt_key
Message-ID: <CACdfkSJbJQrKybrXt9go_Ue+_FajHE68YrMs+bZRVOK39NT+_w@mail.gmail.com>

Can anyone shed light on why these APIs are disabled in FIPS mode? They
involve operations that must be implemented within the boundary of the FIPS
crypto module? It seems like disabling them is intended to prevent mistakes
from developers trying to write their own AES mode implementations?


Thanks in advance for any insight...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150512/e68e34b0/attachment.html>

From nico at cryptonector.com  Tue May 12 19:45:29 2015
From: nico at cryptonector.com (Nico Williams)
Date: Tue, 12 May 2015 14:45:29 -0500
Subject: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re:
 Kerberos)
In-Reply-To: <55524526.4000207@wisemo.com>
References: <1431043217.2505.3.camel@redhat.com>
 <20150508004035.GE17272@mournblade.imrryr.org>
 <554C1142.9090002@secure-endpoints.com>
 <1431119849.2490.2.camel@redhat.com>
 <20150509021811.GD7287@localhost> <20150509035751.GF7287@localhost>
 <20150511162532.GH7287@localhost>
 <20150511164249.GX17272@mournblade.imrryr.org>
 <20150511185218.GI7287@localhost> <55524526.4000207@wisemo.com>
Message-ID: <20150512194528.GQ7287@localhost>

On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote:
> How about the following simplifications for the new
> extension, lets call  it "GSS-2" (at least in this e-mail).
> 
> 1. GSS (including SASL/GS2) is always done via the SPNego
> GSS mechanism, which provides standard handling of
> mechanism negotiation (including round-trip optimizations),
> and is already its own standard (complete with workarounds
> for historic bugs in the dominant implementation...).

SASL/GS2 and SPNEGO are incompatible.

The ALPN approach is to do the mechanism negotiation via ALPN.  This is
much better than SPNEGO in general.

We don't have to use the ALPN approach, and we don't have to support
SASL.  But see below.

> 2. The TLS client always begins by sending the first
> GSS/SPNego leg in a (new) TLS extension "GSS-2".

This is incompatible with doing channel binding the GSS way.  Instead
we'd have to exchange MICs of the channel binding when the GSS context
is fully established.  (This is fine, of course, and not a criticism,
just pointing this out.)

> 3. The TLS server (if it supports and allows the extension)
> responds with a 0 byte TLS extension "GSS-2" to confirm
> support.

Well, presumably the first response GSS token should go here.

> 4. The second and subsequent legs of the GSS handshake are
> sent as the sole contents of the first encrypted records,
> actual application data is not sent until the GSS handshake
> succeeds.  Note that the first encrypted server to client
> record (containing the second leg) can be sent in the same
> protocol round trip as the second half of the TLS
> handshake.  It is an open design issue if these TLS records
> should be tagged as application records or key exchange
> records.

This is just as in the ALPN approach.  They should be tagged as
application records so that the implementation can be either at the
application layer or in the TLS library.

> 5. In the last legs, the GSS mechanism is told to (mutually
> if possible) authenticate some already defined hash of the
> TLS handshake, thereby protecting the key exchange.Other
> than the round trip saving for the first 2 legs, this is
> what distinguishes GSS-2 from simply doing application level
> GSS over a TLS connection.  Any GSS negotiated keys are not
> used beyond this authentication of the TLS key exchange.

This is the MIC exchange I mention above.

> 6. If the GSS mechanism preferred by the client requires the
> authenticated hash value to be known before sending the
> first GSS leg, then the client shall simply abstain from
> including that first leg in the first leg SPNego message
> if sent in the client hello extension.

If we're doing a MIC exchange then we don't need to know the channel
binding a initial security context token production time.

> 7. If the client wants encryption of the first GSS leg, it
> can either abstain from including that leg in the first
> SPNego GSS leg, or it can send a 0-byte first leg and then
> send the real first SPNego leg in the first encrypted client
> o server record, with the server responding with the second
> leg in the first encrypted server to client record as before
> (but no longer in the same round trip as the second half of
> the TLS handshake).

With the ALPN approach this is a given.

> 8. If the GSS mechanism reports failure, the TLS connection
> SHALL be aborted with a specified alert.

Yes.

> 9. When the "GSS-2" extension is negotiated, TLS
> implementations SHOULD allow anonymous (unauthenticated)
> cipher suites even if they would not otherwise do so,
> however they MUST be able to combine the "GSS-2" extension
> with any and all of the cipher suites and TLS versions they
> otherwise implement.  For instance, if an implementation of
> the "GSS-2" extension is somehow bolted on to a fully
> patched OpenSSL 1.0.0 library (via generic extension
> mechanisms), then that combination would support it with
> TLS 1.0 only, and TLS 1.3 capable implementations would be
> negotiating TLS 1.0 when doing "GSS-2" with such an
> implementation.

If only GSS mechanisms that provide integrity protection or better as
used, then this is fine.

> 10. Session resumption and Session renegotiation shall have
> the same semantics for the GSS authentication result as
> they do for certificate validation results done in the
> same handshakes.

Yes.

> 11. NPN and ALPN are neither required nor affected by GSS-2
> and operate as they would with any other TLS mechanisms,
> such as certificates.

NPN is out of the question now.

You're missing a status message for authorization (GSS authentication
might complete, but authorization fail), though this is not strictly
necessary: the server can simply close the connection, including sending
an alert about this (or not) just before closing the connection.

Nico
-- 

From nico at cryptonector.com  Tue May 12 20:00:32 2015
From: nico at cryptonector.com (Nico Williams)
Date: Tue, 12 May 2015 15:00:32 -0500
Subject: [openssl-users] Testing OpenSSL based solution
In-Reply-To: <956488fa72044d4fbd2be123d14dd2ff@ustx2ex-dag1mb4.msg.corp.akamai.com>
References: <008001d08cdc$ec857f50$c5907df0$@samsung.com>
 <956488fa72044d4fbd2be123d14dd2ff@ustx2ex-dag1mb4.msg.corp.akamai.com>
Message-ID: <20150512200031.GR7287@localhost>

On Tue, May 12, 2015 at 06:10:39PM +0000, Salz, Rich wrote:
> You can't easily have test vectors for DSA signatures since they
> include a random.  Any test vector would have to include the random,
> and any API would have to be able to accept the random as part of the
> "sign" API.  Verification should be okay.

It'd be nice to have derandomized *DSA forms for OpenSSL.

CFRG is on the case, thankfully, so eventually there should be a
derandomized ECC signature scheme in OpenSSL.  (Assuming the consensus
ends up being in favor of having a deterministic, state-less signature
scheme.)

Nico
-- 

From m.vinicius at samsung.com  Tue May 12 20:05:56 2015
From: m.vinicius at samsung.com (Marcus Vinicius do Nascimento)
Date: Tue, 12 May 2015 17:05:56 -0300
Subject: [openssl-users] RES:  Testing OpenSSL based solution
In-Reply-To: <55524979.7000809@wisemo.com>
References: <008001d08cdc$ec857f50$c5907df0$@samsung.com>
 <956488fa72044d4fbd2be123d14dd2ff@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <55524979.7000809@wisemo.com>
Message-ID: <009e01d08cef$0fa1d1c0$2ee57540$@samsung.com>

Thanks for both answers.

 

I tried using Y as the public key, but ssl seems not to accept that.

Here is the error scenario:

 

>From the FIP file:

 

[mod = 1024]

 

P =
fda5442483ccf7a12399d6c13d56ff882d689524f1885fcb7424e26da2d200a1657b631dcc74
c73ecbd89fe42cc554b7062835c73d7203161e09742392b2b7c75253eea04a0b55d511646fbe
2e81a9d80463e956527f8d6d42f4193984d5dcc6a8dadff80f31e44405840828581f013e0748
59b885908aaab30d87660bbaf8cb

Q = dc678f95c673538f74dcbf67a80454c843937795

G =
efd89f2dcf6e6a6a77cf18f238b2419de127864218eb4550c9e1a73085f97d7988322d7eea91
590646373aa66f7a3d0994cb5ac741a19874eb9e79862b000e5978f3305bb70be4f987a12a68
6167316e663f4de995b36e74062e39a79a4b30e4d36977276e3d33c5165911d303d5682f8e0a
96c510e1d9606d09b5573a675362

 

Msg =
58b7b3639a8d99babfe57f814024c5e7a0893bcf47b692768e6c11561796894b5f898bf5968a
d85dae9019dbb24cd13759678f0edb0b687703a4a4e785e8b85293157593ab797e0eb338ff94
474a9c8752c3a83edb5798aa221db73aec931bfd1be3d70781647215f6649874a825101eb325
ee27f2a20a57145eb019f2a09993

Y =
808998aecbc5ab4679bf215e2166b371d249bb6e4bfc3404f2bcd2aaf61770851d236668252a
11f061fb54067ddaa97ed7bf5a5c836db02e5b1f9f1a627ac1eb2dcfa484ed5fef383f4bae7a
a18a3ef9ea94bab83439ccf261ec52529f298050b27df185eecccf8caa44b529c8fcbd88c6a3
3cc42b5b17244ea9e1099686a92b

R = 33bf9a15b6823e7c5583f94bcea2f0439a881f8c

S = 48feaff1ec4803fb88fdc70773d9ac7b84905d3a

Result = P

 

 

So I tried reformatting Y to pass it to PEM_read_bio_DSAPrivateKey.

 

Converting Y to Base64 =
"gImYrsvFq0Z5vyFeIWazcdJJu25L/DQE8rzSqvYXcIUdI2ZoJSoR8GH7VAZ92ql+179aXINtsC5
bH58aYnrB6y3PpITtX+84P0uueqGKPvnqlLq4NDnM8mHsUlKfKYBQsn3xhe7Mz4yqRLUpyPy9iMa
jPMQrWxckTqnhCZaGqSs="

Reformatting in PEM format = "-----BEGIN DSA PRIVATE KEY-----

gImYrsvFq0Z5vyFeIWazcdJJu25L/DQE8rzSqvYXcIUdI2ZoJSoR8GH7VAZ92ql+

179aXINtsC5bH58aYnrB6y3PpITtX+84P0uueqGKPvnqlLq4NDnM8mHsUlKfKYBQ

sn3xhe7Mz4yqRLUpyPy9iMajPMQrWxckTqnhCZaGqSs=

-----END DSA PRIVATE KEY-----

"

 

Code that matters:

 

    BIO * keybio = BIO_new_mem_buf(const_cast<char *>(key.c_str()), -1);

    if (keybio == NULL)

    {

                errormsg = "Can not create DSA key";

        return 0;

    }

 

    DSA *dsa = PEM_read_bio_DSAPrivateKey(keybio, &dsa, NULL, NULL);

                if (dsa == NULL)

                {

                                errormsg = "Can not read DSA key";

                }

    return dsa;

 

PEM_read_bio_DSAPrivateKey fails.

 

Am I missing something here?

 

 

 

 

De: openssl-users [mailto:openssl-users-bounces at openssl.org] Em nome de
Jakob Bohm
Enviada em: ter?a-feira, 12 de maio de 2015 15:42
Para: openssl-users at openssl.org
Assunto: Re: [openssl-users] Testing OpenSSL based solution

 

On 12/05/2015 20:10, Salz, Rich wrote:

You can't easily have test vectors for DSA signatures since they include a
random.  Any test vector would have to include the random, and any API would
have to be able to accept the random as part of the "sign" API.
Verification should be okay.
 
 


What Mr. Salz refers to by "Verification should be okay" 
is probably this:

You can have test vectors in the form of known good 
signatures with public keys listed in the test vector. 
For DSA, those would be the (message, y, r, s) quads 
mentioned by the OP (y is the public key, (r, s) is the 
signature), depending on his class library, it might be 
possible to reformat those vectors to the format used 
by his code for real messages.

The importance of such test vectors is to detect if an 
implementation is accidentally implementing a different 
signature algorithm (such as accidentally appending a 0 
byte to each message both during signing and 
verification).  This would not be detected by signing 
and verifying sample messages with random parameters.




Enjoy
 
Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150512/9399f6df/attachment-0001.html>

From nico at cryptonector.com  Tue May 12 20:09:30 2015
From: nico at cryptonector.com (Nico Williams)
Date: Tue, 12 May 2015 15:09:30 -0500
Subject: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re:
 Kerberos)
In-Reply-To: <20150512194528.GQ7287@localhost>
References: <20150508004035.GE17272@mournblade.imrryr.org>
 <554C1142.9090002@secure-endpoints.com>
 <1431119849.2490.2.camel@redhat.com>
 <20150509021811.GD7287@localhost> <20150509035751.GF7287@localhost>
 <20150511162532.GH7287@localhost>
 <20150511164249.GX17272@mournblade.imrryr.org>
 <20150511185218.GI7287@localhost> <55524526.4000207@wisemo.com>
 <20150512194528.GQ7287@localhost>
Message-ID: <20150512200930.GS7287@localhost>

I should add that I prefer a protocol that optimizes the GSS round trips
over one that doesn't, though that means using SPNEGO for negotiation
(when negotiation is desired).

From m.vinicius at samsung.com  Tue May 12 20:50:03 2015
From: m.vinicius at samsung.com (Marcus Vinicius do Nascimento)
Date: Tue, 12 May 2015 17:50:03 -0300
Subject: [openssl-users] RES:  RES:  Testing OpenSSL based solution
In-Reply-To: <009e01d08cef$0fa1d1c0$2ee57540$@samsung.com>
References: <008001d08cdc$ec857f50$c5907df0$@samsung.com>
 <956488fa72044d4fbd2be123d14dd2ff@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <55524979.7000809@wisemo.com> <009e01d08cef$0fa1d1c0$2ee57540$@samsung.com>
Message-ID: <00a901d08cf5$39b0f940$ad12ebc0$@samsung.com>

I did some quick research and found this:
http://en.wikipedia.org/wiki/Digital_Signature_Algorithm

If my understanding is correct, the public key is (p, q, g, y).

The private key would be x, such that y = g^x mod p.

 

Is there some way to generate both public and private keys using OpenSSL,
based on p, q, g and y?

 

 

 

De: openssl-users [mailto:openssl-users-bounces at openssl.org] Em nome de
Marcus Vinicius do Nascimento
Enviada em: ter?a-feira, 12 de maio de 2015 17:06
Para: openssl-users at openssl.org
Assunto: [openssl-users] RES: Testing OpenSSL based solution

 

Thanks for both answers.

 

I tried using Y as the public key, but ssl seems not to accept that.

Here is the error scenario:

 

>From the FIP file:

 

[mod = 1024]

 

P =
fda5442483ccf7a12399d6c13d56ff882d689524f1885fcb7424e26da2d200a1657b631dcc74
c73ecbd89fe42cc554b7062835c73d7203161e09742392b2b7c75253eea04a0b55d511646fbe
2e81a9d80463e956527f8d6d42f4193984d5dcc6a8dadff80f31e44405840828581f013e0748
59b885908aaab30d87660bbaf8cb

Q = dc678f95c673538f74dcbf67a80454c843937795

G =
efd89f2dcf6e6a6a77cf18f238b2419de127864218eb4550c9e1a73085f97d7988322d7eea91
590646373aa66f7a3d0994cb5ac741a19874eb9e79862b000e5978f3305bb70be4f987a12a68
6167316e663f4de995b36e74062e39a79a4b30e4d36977276e3d33c5165911d303d5682f8e0a
96c510e1d9606d09b5573a675362

 

Msg =
58b7b3639a8d99babfe57f814024c5e7a0893bcf47b692768e6c11561796894b5f898bf5968a
d85dae9019dbb24cd13759678f0edb0b687703a4a4e785e8b85293157593ab797e0eb338ff94
474a9c8752c3a83edb5798aa221db73aec931bfd1be3d70781647215f6649874a825101eb325
ee27f2a20a57145eb019f2a09993

Y =
808998aecbc5ab4679bf215e2166b371d249bb6e4bfc3404f2bcd2aaf61770851d236668252a
11f061fb54067ddaa97ed7bf5a5c836db02e5b1f9f1a627ac1eb2dcfa484ed5fef383f4bae7a
a18a3ef9ea94bab83439ccf261ec52529f298050b27df185eecccf8caa44b529c8fcbd88c6a3
3cc42b5b17244ea9e1099686a92b

R = 33bf9a15b6823e7c5583f94bcea2f0439a881f8c

S = 48feaff1ec4803fb88fdc70773d9ac7b84905d3a

Result = P

 

 

So I tried reformatting Y to pass it to PEM_read_bio_DSAPrivateKey.

 

Converting Y to Base64 =
"gImYrsvFq0Z5vyFeIWazcdJJu25L/DQE8rzSqvYXcIUdI2ZoJSoR8GH7VAZ92ql+179aXINtsC5
bH58aYnrB6y3PpITtX+84P0uueqGKPvnqlLq4NDnM8mHsUlKfKYBQsn3xhe7Mz4yqRLUpyPy9iMa
jPMQrWxckTqnhCZaGqSs="

Reformatting in PEM format = "-----BEGIN DSA PRIVATE KEY-----

gImYrsvFq0Z5vyFeIWazcdJJu25L/DQE8rzSqvYXcIUdI2ZoJSoR8GH7VAZ92ql+

179aXINtsC5bH58aYnrB6y3PpITtX+84P0uueqGKPvnqlLq4NDnM8mHsUlKfKYBQ

sn3xhe7Mz4yqRLUpyPy9iMajPMQrWxckTqnhCZaGqSs=

-----END DSA PRIVATE KEY-----

"

 

Code that matters:

 

    BIO * keybio = BIO_new_mem_buf(const_cast<char *>(key.c_str()), -1);

    if (keybio == NULL)

    {

                errormsg = "Can not create DSA key";

        return 0;

    }

 

    DSA *dsa = PEM_read_bio_DSAPrivateKey(keybio, &dsa, NULL, NULL);

                if (dsa == NULL)

                {

                                errormsg = "Can not read DSA key";

                }

    return dsa;

 

PEM_read_bio_DSAPrivateKey fails.

 

Am I missing something here?

 

 

 

 

De: openssl-users [mailto:openssl-users-bounces at openssl.org] Em nome de
Jakob Bohm
Enviada em: ter?a-feira, 12 de maio de 2015 15:42
Para: openssl-users at openssl.org
Assunto: Re: [openssl-users] Testing OpenSSL based solution

 

On 12/05/2015 20:10, Salz, Rich wrote:

You can't easily have test vectors for DSA signatures since they include a
random.  Any test vector would have to include the random, and any API would
have to be able to accept the random as part of the "sign" API.
Verification should be okay.
 
 


What Mr. Salz refers to by "Verification should be okay" 
is probably this:

You can have test vectors in the form of known good 
signatures with public keys listed in the test vector. 
For DSA, those would be the (message, y, r, s) quads 
mentioned by the OP (y is the public key, (r, s) is the 
signature), depending on his class library, it might be 
possible to reformat those vectors to the format used 
by his code for real messages.

The importance of such test vectors is to detect if an 
implementation is accidentally implementing a different 
signature algorithm (such as accidentally appending a 0 
byte to each message both during signing and 
verification).  This would not be detected by signing 
and verifying sample messages with random parameters.



Enjoy
 
Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150512/cb158d64/attachment.html>

From tpmarchand at gmail.com  Wed May 13 01:47:27 2015
From: tpmarchand at gmail.com (Tom Marchand)
Date: Tue, 12 May 2015 21:47:27 -0400
Subject: [openssl-users] SSE Version Of BIGNUM
Message-ID: <39555756-A5C1-48E7-95F4-69DD0E4A3BB3@gmail.com>

Does anybody know of a version of BIGNUM that is SSE enabled allowing simultaneous operations on multiple BIGNUMs?

From dthompson at prinpay.com  Wed May 13 07:22:04 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Wed, 13 May 2015 03:22:04 -0400
Subject: [openssl-users] Testing OpenSSL based solution
Message-ID: <004801d08d4d$84a5f010$8df1d030$@prinpay.com>

> From: openssl-users On Behalf Of Marcus Vinicius do Nascimento
> Sent: Tuesday, May 12, 2015 16:50

> I did some quick research and found this:
http://en.wikipedia.org/wiki/Digital_Signature_Algorithm
> If my understanding is correct, the public key is (p, q, g, y).

You might want to look at the actual standard, FIPS 186, free from NIST 
and referred to by wikipedia as well as easily searchable. The current 
version is revision -4, but the basic logic of DSA hasn't changed since 
"-0" (although the sizes used have increased).

Standardly a DSA public key is (parameters, y) where parameters is 
(p, q, g {, seed, counter}) where the optional fields in the parameters 
allow verification of the parameter generation process. OpenSSL does 
not use that option, so it uses only p,g,q and y. See below.

> The private key would be x, such that y = g^x mod p.
> Is there some way to generate both public and private keys using OpenSSL, 
> based on p, q, g and y?

You cannot recover the private key from the public key for any 
secure PKC scheme used with appropriate sizes. DSA is a secure 
scheme, and DSS and these test cases use appropriate sizes.

> De: openssl-users Em nome de Marcus Vinicius do Nascimento
> Enviada em: ter?a-feira, 12 de maio de 2015 17:06

> I tried using Y as the public key, but ssl seems not to accept that.
> From the FIP file: <snip>
> So I tried reformatting Y to pass it to PEM_read_bio_DSAPrivateKey.
> Converting Y to Base64 = <snip> 
> Reformatting in PEM format = "-----BEGIN DSA PRIVATE KEY----- <snip>
[doesn't work]

As above, the public key requires all of p,q,g and y, not just y. 
The private key would require x as well, and you don't have x.

For public keys for _all_ algorithms in files including PEM 
OpenSSL uses the format standardized by X.509 called 
SubjectPublicKeyInfo or SPKI for short, which is an ASN.1 
sequence containing an AlgorithmIdentifier which is a(nother) 
sequence containing an OID identifying the algorithm and an 
optional parameters field whose type depends on the algorithm,
followed by a BITSTRING containing a nested encoding of the 
public key value relative to the parameters for that algorithm.

For DSA, the OID identifies DSA, the parameters are a sequence 
of three INTEGERs for p,g,q, and the nested key encoding is 
just an INTEGER. All elements in ASN.1 use a "TLV" (tag, length,
value) encoding, and INTEGER (thus) consists of a tag octet of 02 
specifying integer, a length whose length itself varies depending 
on the length it encodes, and a value field which for INTEGER is 
a _signed_ big-endian binary number. Since the particular y
you tried to encode below happens to have a magnitude size of 
1024 bits, a multiple of 8, it requires a leading sign octet of 00.
So does g in this case, and p and q by design (they are specified with 
magnitude sizes which are multiples of 8, and indeed of 32).

See rfc 5280 for the generic SPKI format, and rfc 3279 (referenced there) 
for the specifics for several algorithms including DSA.

Note that the PEM type is just "BEGIN/END PUBLIC KEY"  (no DSA) 
because as above the format handles all algorithms.



From jb-openssl at wisemo.com  Wed May 13 10:03:33 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 13 May 2015 12:03:33 +0200
Subject: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re:
	Kerberos)
In-Reply-To: <20150512194528.GQ7287@localhost>
References: <1431043217.2505.3.camel@redhat.com>
 <20150508004035.GE17272@mournblade.imrryr.org>
 <554C1142.9090002@secure-endpoints.com> <1431119849.2490.2.camel@redhat.com>
 <20150509021811.GD7287@localhost> <20150509035751.GF7287@localhost>
 <20150511162532.GH7287@localhost>
 <20150511164249.GX17272@mournblade.imrryr.org>
 <20150511185218.GI7287@localhost> <55524526.4000207@wisemo.com>
 <20150512194528.GQ7287@localhost>
Message-ID: <55532175.3030703@wisemo.com>

On 12/05/2015 21:45, Nico Williams wrote:
> On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote:
>> How about the following simplifications for the new
>> extension, lets call  it "GSS-2" (at least in this e-mail).
>>
>> 1. GSS (including SASL/GS2) is always done via the SPNego
>> GSS mechanism, which provides standard handling of
>> mechanism negotiation (including round-trip optimizations),
>> and is already its own standard (complete with workarounds
>> for historic bugs in the dominant implementation...).
> SASL/GS2 and SPNEGO are incompatible.
How?  I thought SPNEGO encapsulated and negotiated
arbitrary GSS mechanisms.

I am of cause aware that some existing mechanisms have
both SASL native and GSS native bindings and that those
bindings are mutually exclusive, such that one must
decide at standardization time if the SASL native or
GSS native form shall be used for interoperability.

To me the key benefit of SPNEGO is the existence of
already battle tested negotiation code readily available
i many/most current GSS implementation.  It is one less
thing to design and implement wrong.
>
> The ALPN approach is to do the mechanism negotiation via ALPN.  This is
> much better than SPNEGO in general.
However I strongly suspect that using ALPN will cause
practical conflicts with early HTTP/2 implementations
and early ALPN implementations, as such early
implementations are likely to only cater to that
single use of ALPN.

In contrast there are now multiple unrelated deployed
TLS extensions, so that mechanism is more stable and
more ready to handle new uses.
>
> We don't have to use the ALPN approach, and we don't have to support
> SASL.  But see below.
>
>> 2. The TLS client always begins by sending the first
>> GSS/SPNego leg in a (new) TLS extension "GSS-2".
> This is incompatible with doing channel binding the GSS way.  Instead
> we'd have to exchange MICs of the channel binding when the GSS context
> is fully established.  (This is fine, of course, and not a criticism,
> just pointing this out.)
This is why I specified the alternate ordering below.
Note however that not all versions of all GSS
implementations (notable the Microsoft SSPI variant)
may support the GSS channel binding mechanism.
>
>> 3. The TLS server (if it supports and allows the extension)
>> responds with a 0 byte TLS extension "GSS-2" to confirm
>> support.
> Well, presumably the first response GSS token should go here.
No, see below.
>> 4. The second and subsequent legs of the GSS handshake are
>> sent as the sole contents of the first encrypted records,
>> actual application data is not sent until the GSS handshake
>> succeeds.  Note that the first encrypted server to client
>> record (containing the second leg) can be sent in the same
>> protocol round trip as the second half of the TLS
>> handshake.  It is an open design issue if these TLS records
>> should be tagged as application records or key exchange
>> records.
> This is just as in the ALPN approach.  They should be tagged as
> application records so that the implementation can be either at the
> application layer or in the TLS library.
However if it is negotiated via a TLS extension rather
than TLS 1.2+ ALPN, thenintegration in the TLS stack
will be unavoidable anyway.
>
>> 5. In the last legs, the GSS mechanism is told to (mutually
>> if possible) authenticate some already defined hash of the
>> TLS handshake, thereby protecting the key exchange.Other
>> than the round trip saving for the first 2 legs, this is
>> what distinguishes GSS-2 from simply doing application level
>> GSS over a TLS connection.  Any GSS negotiated keys are not
>> used beyond this authentication of the TLS key exchange.
> This is the MIC exchange I mention above.
Yep, however as this entails extra round trips, it is
not the only option.
>
>> 6. If the GSS mechanism preferred by the client requires the
>> authenticated hash value to be known before sending the
>> first GSS leg, then the client shall simply abstain from
>> including that first leg in the first leg SPNego message
>> if sent in the client hello extension.
> If we're doing a MIC exchange then we don't need to know the channel
> binding a initial security context token production time.
However the early channel binding might save a leg.
>
>> 7. If the client wants encryption of the first GSS leg, it
>> can either abstain from including that leg in the first
>> SPNego GSS leg, or it can send a 0-byte first leg and then
>> send the real first SPNego leg in the first encrypted client
>> o server record, with the server responding with the second
>> leg in the first encrypted server to client record as before
>> (but no longer in the same round trip as the second half of
>> the TLS handshake).
> With the ALPN approach this is a given.
However if the first leg need not be encrypted and
need not know thechannel binding, it can be sent a
round earlier. This can (I hope) be decided on a per
mechanism basis, thus if a GSS mechanism need not know
its channel binding until the second leg,
implementations that can provide the binding to the
GSS layer later can take advantage of it.

>
>> 8. If the GSS mechanism reports failure, the TLS connection
>> SHALL be aborted with a specified alert.
> Yes.
>
>> 9. When the "GSS-2" extension is negotiated, TLS
>> implementations SHOULD allow anonymous (unauthenticated)
>> cipher suites even if they would not otherwise do so,
>> however they MUST be able to combine the "GSS-2" extension
>> with any and all of the cipher suites and TLS versions they
>> otherwise implement.  For instance, if an implementation of
>> the "GSS-2" extension is somehow bolted on to a fully
>> patched OpenSSL 1.0.0 library (via generic extension
>> mechanisms), then that combination would support it with
>> TLS 1.0 only, and TLS 1.3 capable implementations would be
>> negotiating TLS 1.0 when doing "GSS-2" with such an
>> implementation.
> If only GSS mechanisms that provide integrity protection or better as
> used, then this is fine.
And why would this not work with any other form of
channel binding?  Key requirement is that the TLS
key exchange is bound to the specific authentication
in some way not susceptible to man in the middle.
>
>> 10. Session resumption and Session renegotiation shall have
>> the same semantics for the GSS authentication result as
>> they do for certificate validation results done in the
>> same handshakes.
> Yes.
>
>> 11. NPN and ALPN are neither required nor affected by GSS-2
>> and operate as they would with any other TLS mechanisms,
>> such as certificates.
> NPN is out of the question now.
However it is going to exist for SPDY backward
compatibility for a few years, so the non-conflict
needs to be specified, if only by a few words.
>
> You're missing a status message for authorization (GSS authentication
> might complete, but authorization fail), though this is not strictly
> necessary: the server can simply close the connection, including sending
> an alert about this (or not) just before closing the connection.
For security it is best if successful authentication
of an unauthorized account (thinkroot) is
indistinguishable from unsuccessful authentication of
that account.



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From jb-openssl at wisemo.com  Wed May 13 10:09:07 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 13 May 2015 12:09:07 +0200
Subject: [openssl-users] RES:  RES:  Testing OpenSSL based solution
In-Reply-To: <00a901d08cf5$39b0f940$ad12ebc0$@samsung.com>
References: <008001d08cdc$ec857f50$c5907df0$@samsung.com>
 <956488fa72044d4fbd2be123d14dd2ff@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <55524979.7000809@wisemo.com> <009e01d08cef$0fa1d1c0$2ee57540$@samsung.com>
 <00a901d08cf5$39b0f940$ad12ebc0$@samsung.com>
Message-ID: <555322C3.90507@wisemo.com>

On 12/05/2015 22:50, Marcus Vinicius do Nascimento wrote:
>
> I did some quick research and found this: 
> http://en.wikipedia.org/wiki/Digital_Signature_Algorithm
>
> If my understanding is correct, the public key is (p, q, g, y).
>
> The private key would be x, such that y = g^x mod p.
>
> Is there some way to generate both public and private keys using 
> OpenSSL, based on p, q, g and y?
>
Not without finding a way to breaking DSA.
The whole point is you cannot get x from y.

However for your library to be any use at all,
it needs to already support that the
computer/user that runs it to verify
signatures don't know the private key
either.

So somewhere you should already have a way
to input ((p, q, g), y) and use that to
verify a signature.

> *De:*openssl-users [mailto:openssl-users-bounces at openssl.org] *Em nome 
> de *Marcus Vinicius do Nascimento
> *Enviada em:* ter?a-feira, 12 de maio de 2015 17:06
> *Para:* openssl-users at openssl.org
> *Assunto:* [openssl-users] RES: Testing OpenSSL based solution
>
> Thanks for both answers.
>
> I tried using Y as the public key, but ssl seems not to accept that.
>
> Here is the error scenario:
>
> From the FIP file:
>
> [mod = 1024]
>
> P = 
> fda5442483ccf7a12399d6c13d56ff882d689524f1885fcb7424e26da2d200a1657b631dcc74c73ecbd89fe42cc554b7062835c73d7203161e09742392b2b7c75253eea04a0b55d511646fbe2e81a9d80463e956527f8d6d42f4193984d5dcc6a8dadff80f31e44405840828581f013e074859b885908aaab30d87660bbaf8cb
>
> Q = dc678f95c673538f74dcbf67a80454c843937795
>
> G = 
> efd89f2dcf6e6a6a77cf18f238b2419de127864218eb4550c9e1a73085f97d7988322d7eea91590646373aa66f7a3d0994cb5ac741a19874eb9e79862b000e5978f3305bb70be4f987a12a686167316e663f4de995b36e74062e39a79a4b30e4d36977276e3d33c5165911d303d5682f8e0a96c510e1d9606d09b5573a675362
>
> Msg = 
> 58b7b3639a8d99babfe57f814024c5e7a0893bcf47b692768e6c11561796894b5f898bf5968ad85dae9019dbb24cd13759678f0edb0b687703a4a4e785e8b85293157593ab797e0eb338ff94474a9c8752c3a83edb5798aa221db73aec931bfd1be3d70781647215f6649874a825101eb325ee27f2a20a57145eb019f2a09993
>
> Y = 
> 808998aecbc5ab4679bf215e2166b371d249bb6e4bfc3404f2bcd2aaf61770851d236668252a11f061fb54067ddaa97ed7bf5a5c836db02e5b1f9f1a627ac1eb2dcfa484ed5fef383f4bae7aa18a3ef9ea94bab83439ccf261ec52529f298050b27df185eecccf8caa44b529c8fcbd88c6a33cc42b5b17244ea9e1099686a92b
>
> R = 33bf9a15b6823e7c5583f94bcea2f0439a881f8c
>
> S = 48feaff1ec4803fb88fdc70773d9ac7b84905d3a
>
> Result = P
>
> So I tried reformatting Y to pass it to PEM_read_bio_DSAPrivateKey.
>
> Converting Y to Base64 = 
> "gImYrsvFq0Z5vyFeIWazcdJJu25L/DQE8rzSqvYXcIUdI2ZoJSoR8GH7VAZ92ql+179aXINtsC5bH58aYnrB6y3PpITtX+84P0uueqGKPvnqlLq4NDnM8mHsUlKfKYBQsn3xhe7Mz4yqRLUpyPy9iMajPMQrWxckTqnhCZaGqSs="
>
> Reformatting in PEM format = "-----BEGIN DSA PRIVATE KEY-----
>
> gImYrsvFq0Z5vyFeIWazcdJJu25L/DQE8rzSqvYXcIUdI2ZoJSoR8GH7VAZ92ql+
>
> 179aXINtsC5bH58aYnrB6y3PpITtX+84P0uueqGKPvnqlLq4NDnM8mHsUlKfKYBQ
>
> sn3xhe7Mz4yqRLUpyPy9iMajPMQrWxckTqnhCZaGqSs=
>
> -----END DSA PRIVATE KEY-----
>
> "
>
> Code that matters:
>
> BIO * keybio = BIO_new_mem_buf(const_cast<char *>(key.c_str()), -1);
>
> if (keybio == NULL)
>
> {
>
> errormsg = "Can not create DSA key";
>
> return 0;
>
> }
>
> DSA *dsa = PEM_read_bio_DSAPrivateKey(keybio, &dsa, NULL, NULL);
>
> if (dsa == NULL)
>
> {
>
> errormsg = "Can not read DSA key";
>
> }
>
> return dsa;
>
> PEM_read_bio_DSAPrivateKey fails.
>
> Am I missing something here?
>
> *De:*openssl-users [mailto:openssl-users-bounces at openssl.org] *Em nome 
> de *Jakob Bohm
> *Enviada em:* ter?a-feira, 12 de maio de 2015 15:42
> *Para:* openssl-users at openssl.org
> *Assunto:* Re: [openssl-users] Testing OpenSSL based solution
>
> On 12/05/2015 20:10, Salz, Rich wrote:
>
>     You can't easily have test vectors for DSA signatures since they include a random.  Any test vector would have to include the random, and any API would have to be able to accept the random as part of the "sign" API.  Verification should be okay.
>
>       
>
>       
>
>
> What Mr. Salz refers to by "Verification should be okay"
> is probably this:
>
> You can have test vectors in the form of known good
> signatures with public keys listed in the test vector.
> For DSA, those would be the (message, y, r, s) quads
> mentioned by the OP (y is the public key, (r, s) is the
> signature), depending on his class library, it might be
> possible to reformat those vectors to the format used
> by his code for real messages.
>
> The importance of such test vectors is to detect if an
> implementation is accidentally implementing a different
> signature algorithm (such as accidentally appending a 0
> byte to each message both during signing and
> verification).  This would not be detected by signing
> and verifying sample messages with random parameters.
>

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From Newcomer83 at web.de  Wed May 13 14:11:12 2015
From: Newcomer83 at web.de (Newcomer83 at web.de)
Date: Wed, 13 May 2015 16:11:12 +0200
Subject: [openssl-users] 2nd client connects to 1:1-server leads to client
	crash
Message-ID: <trinity-62564d5e-ad4c-4523-b756-cf1878a929e8-1431526272044@msvc-mesg-web002>

Hello everyone,

I have a server that is supposed to accept only one client. The connection works just fine. When I tried to connect to the server with a second client while another connection is already active, I expected that the 2nd client would return some error code, but instead it crashes completely. I am using non-blocking sockets for both clients (i.e. both clients are the same application, but different instances). Interestingly it doesn't crash during the connect call, but during the call to SSL_connect. My non-blocking socket attempts to connect until either an error happens or WSAEISCONN is returned (i.e. connect request was mande on an already connected socket), so it seems to connect even though the server isn't waiting for a connection anymore.
In most cases it crashes after I got an SSL_ERROR_WANT_READ from SSL_connect, sometimes it crashes before that. In some lucky cases I get error code 5 without it crashing, but in most cases the crash happens.

My server looks pretty much like this one: https://www.cs.utah.edu/~swalton/listings/articles/ssl_server.c
I.e. it waits for a connection and when a client connected it waits for a message, processes it and returns the result. Do I have to reprogram the server to actively refuse multiple connections? And why does the connect function work?

I am using OpenSSL 1.0.2a. The client runs on Windows 7, the server on lUbuntu inside a VM on the same PC.

Thanks in advance for the help!

Cheers
Alex

From matt at openssl.org  Wed May 13 14:19:24 2015
From: matt at openssl.org (Matt Caswell)
Date: Wed, 13 May 2015 15:19:24 +0100
Subject: [openssl-users] [openssl-dev]  Kerberos
In-Reply-To: <554C7691.80906@openssl.org>
References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com>
 <20150508004035.GE17272@mournblade.imrryr.org>
 <554C1142.9090002@secure-endpoints.com> <554C7691.80906@openssl.org>
Message-ID: <55535D6C.4060109@openssl.org>



On 08/05/15 09:40, Matt Caswell wrote:
> 
> 
> On 08/05/15 02:28, Jeffrey Altman wrote:
> 
>> Regardless, the inability to improve the support in this area has left
>> the those organizations that rely upon 2712 with the choice of use
>> insecure protocols or re-implement the applications.  I do not believe
>> that any sane OS or application vendor can with a straight face continue
>> to ship 2712 support.  As such it should be removed from OpenSSL master.
> 
> I plan to start preparing the patches to remove it next week.

FYI, these patches have now been applied to master.

Matt


From nico at cryptonector.com  Wed May 13 15:46:42 2015
From: nico at cryptonector.com (Nico Williams)
Date: Wed, 13 May 2015 10:46:42 -0500
Subject: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re:
 Kerberos)
In-Reply-To: <55532175.3030703@wisemo.com>
References: <554C1142.9090002@secure-endpoints.com>
 <1431119849.2490.2.camel@redhat.com>
 <20150509021811.GD7287@localhost> <20150509035751.GF7287@localhost>
 <20150511162532.GH7287@localhost>
 <20150511164249.GX17272@mournblade.imrryr.org>
 <20150511185218.GI7287@localhost> <55524526.4000207@wisemo.com>
 <20150512194528.GQ7287@localhost> <55532175.3030703@wisemo.com>
Message-ID: <20150513154641.GU7287@localhost>

On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote:
> On 12/05/2015 21:45, Nico Williams wrote:
> >On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote:
> >>How about the following simplifications for the new
> >>extension, lets call  it "GSS-2" (at least in this e-mail).
> >>
> >>1. GSS (including SASL/GS2) is always done via the SPNego
> >>GSS mechanism, which provides standard handling of
> >>mechanism negotiation (including round-trip optimizations),
> >>and is already its own standard (complete with workarounds
> >>for historic bugs in the dominant implementation...).
> >SASL/GS2 and SPNEGO are incompatible.
>
> How?  I thought SPNEGO encapsulated and negotiated
> arbitrary GSS mechanisms.

The problem is that negotiating twice is bad (for various reasons), and
SASL has non-GSS mechanisms, so negotiating SASL mechanisms, then GSS is
a two-level negotiation that is fraught with peril, therefore forbidden.

> To me the key benefit of SPNEGO is the existence of
> already battle tested negotiation code readily available
> i many/most current GSS implementation.  It is one less
> thing to design and implement wrong.

It's quite complex owing to having been underspecified in the first
place then having grown a number of bug workarounds over the years.

It'd be much easier to send a list of mechanism OIDs in the ClientHello,
have the server announce a choice in its response, and have the first
GSS token sent as early application data in the same flight as the
client's Finished message (assuming traditional TLS handshakes here),
with GSS channel binding.  When the client knows what mechanism they
want they could send the initial context token in the ClientHello (if
it's not too large) and use MIC tokens for channel binding.

> >The ALPN approach is to do the mechanism negotiation via ALPN.  This is
> >much better than SPNEGO in general.
>
> However I strongly suspect that using ALPN will cause
> practical conflicts with early HTTP/2 implementations
> and early ALPN implementations, as such early
> implementations are likely to only cater to that
> single use of ALPN.

Perhaps so.  I would prefer to optimize the GSS flights as well too.

> >>3. The TLS server (if it supports and allows the extension)
> >>responds with a 0 byte TLS extension "GSS-2" to confirm
> >>support.
> >Well, presumably the first response GSS token should go here.
> No, see below.

In your protocol the client already sent a SPNEGO initial security
context token.  A response is required, as GSS context establishment
token exchanges are strictly synchronous.

> >>5. In the last legs, the GSS mechanism is told to (mutually
> >>if possible) authenticate some already defined hash of the
> >>TLS handshake, thereby protecting the key exchange.Other
> >>than the round trip saving for the first 2 legs, this is
> >>what distinguishes GSS-2 from simply doing application level
> >>GSS over a TLS connection.  Any GSS negotiated keys are not
> >>used beyond this authentication of the TLS key exchange.
> >
> >This is the MIC exchange I mention above.
>
> Yep, however as this entails extra round trips, it is
> not the only option.

With PROT_READY there should be no need for an extra round-trip.

> >>6. If the GSS mechanism preferred by the client requires the
> >>authenticated hash value to be known before sending the
> >>first GSS leg, then the client shall simply abstain from
> >>including that first leg in the first leg SPNego message
> >>if sent in the client hello extension.
> >
> >If we're doing a MIC exchange then we don't need to know the channel
> >binding a initial security context token production time.
>
> However the early channel binding might save a leg.

You mean late.  Your idea seems to be to exposed knowledge of when is
the latest that a mechanism can begin to use the channel binding so as
to delay giving it the channel binding until we know it.  That would be
a significant change to GSS, and often it won't help (e.g., Kerberos,
the mechanism of interest in this thread).

> >>7. If the client wants encryption of the first GSS leg, it
> >>can either abstain from including that leg in the first
> >>SPNego GSS leg, or it can send a 0-byte first leg and then
> >>send the real first SPNego leg in the first encrypted client
> >>o server record, with the server responding with the second
> >>leg in the first encrypted server to client record as before
> >>(but no longer in the same round trip as the second half of
> >>the TLS handshake).
> >
> >With the ALPN approach this is a given.
> 
> However if the first leg need not be encrypted and
> need not know thechannel binding, it can be sent a
> round earlier. This can (I hope) be decided on a per
> mechanism basis, thus if a GSS mechanism need not know
> its channel binding until the second leg,
> implementations that can provide the binding to the
> GSS layer later can take advantage of it.

No, this can't be decided on a per-mechanism basis, not without first
modifying GSS significantly.

> >>9. When the "GSS-2" extension is negotiated, TLS
> >>implementations SHOULD allow anonymous (unauthenticated)
> >>cipher suites even if they would not otherwise do so,
> >>however they MUST be able to combine the "GSS-2" extension
> >>with any and all of the cipher suites and TLS versions they
> >>otherwise implement.  For instance, if an implementation of
> >>the "GSS-2" extension is somehow bolted on to a fully
> >>patched OpenSSL 1.0.0 library (via generic extension
> >>mechanisms), then that combination would support it with
> >>TLS 1.0 only, and TLS 1.3 capable implementations would be
> >>negotiating TLS 1.0 when doing "GSS-2" with such an
> >>implementation.
> >
> >If only GSS mechanisms that provide integrity protection or better as
> >used, then this is fine.
>
> And why would this not work with any other form of
> channel binding?  Key requirement is that the TLS
> key exchange is bound to the specific authentication
> in some way not susceptible to man in the middle.

I was referring to GSS per-message tokens.  You're proposing changes to
GSS -- I hadn't understood that then.

> >You're missing a status message for authorization (GSS authentication
> >might complete, but authorization fail), though this is not strictly
> >necessary: the server can simply close the connection, including sending
> >an alert about this (or not) just before closing the connection.
> 
> For security it is best if successful authentication
> of an unauthorized account (thinkroot) is
> indistinguishable from unsuccessful authentication of
> that account.

With GSS that's not really true.  The mechanism token exchange is a
black box.  It may yield failure with error tokens.  The application can
detect this and elect not to send error tokens, but if a final token was
expected in the success case then the peer will know what happened
anyways.  It's very difficult to generically ensure what you propose,
and not that valuable.

Nico
-- 

From jb-openssl at wisemo.com  Wed May 13 17:10:10 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 13 May 2015 19:10:10 +0200
Subject: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re:
	Kerberos)
In-Reply-To: <20150513154641.GU7287@localhost>
References: <554C1142.9090002@secure-endpoints.com>
 <1431119849.2490.2.camel@redhat.com> <20150509021811.GD7287@localhost>
 <20150509035751.GF7287@localhost> <20150511162532.GH7287@localhost>
 <20150511164249.GX17272@mournblade.imrryr.org>
 <20150511185218.GI7287@localhost> <55524526.4000207@wisemo.com>
 <20150512194528.GQ7287@localhost> <55532175.3030703@wisemo.com>
 <20150513154641.GU7287@localhost>
Message-ID: <55538572.5090704@wisemo.com>

For the TL;DR: My original quick writeup included some
mistakes in the details of TLS (forgot about Finished
messages) and SASL/GS2.  It is thus in more than
anticipated need of change before it can become a
proper spec, finding and fixing such mistakes is the
main benefit of having this kind of discussion.

On 13/05/2015 17:46, Nico Williams wrote:
> On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote:
>> On 12/05/2015 21:45, Nico Williams wrote:
>>> On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote:
>>>> How about the following simplifications for the new
>>>> extension, lets call  it "GSS-2" (at least in this e-mail).
>>>>
>>>> 1. GSS (including SASL/GS2) is always done via the SPNego
>>>> GSS mechanism, which provides standard handling of
>>>> mechanism negotiation (including round-trip optimizations),
>>>> and is already its own standard (complete with workarounds
>>>> for historic bugs in the dominant implementation...).
>>> SASL/GS2 and SPNEGO are incompatible.
>> How?  I thought SPNEGO encapsulated and negotiated
>> arbitrary GSS mechanisms.
> The problem is that negotiating twice is bad (for various reasons), and
> SASL has non-GSS mechanisms, so negotiating SASL mechanisms, then GSS is
> a two-level negotiation that is fraught with peril, therefore forbidden.
Ok, having not studied the standard SASL in GSS
specification, I presumed each GSS-encapsulated SASL
mechanism would have its own GSS mechanism OID in
some systematic way, leaving just one negotiation.
>
>> To me the key benefit of SPNEGO is the existence of
>> already battle tested negotiation code readily available
>> i many/most current GSS implementation.  It is one less
>> thing to design and implement wrong.
> It's quite complex owing to having been underspecified in the first
> place then having grown a number of bug workarounds over the years.
Yes, but it is now a mature protocol, and I was trying
to avoid creating yet another near identical
handshake protocol.
>
> It'd be much easier to send a list of mechanism OIDs in the ClientHello,
> have the server announce a choice in its response, and have the first
> GSS token sent as early application data in the same flight as the
> client's Finished message (assuming traditional TLS handshakes here),
> with GSS channel binding.  When the client knows what mechanism they
> want they could send the initial context token in the ClientHello (if
> it's not too large) and use MIC tokens for channel binding.
But isn't that (essentially) what SPnego does, but in a
standardized way with historic quirks?
>
>>> The ALPN approach is to do the mechanism negotiation via ALPN.  This is
>>> much better than SPNEGO in general.
>> However I strongly suspect that using ALPN will cause
>> practical conflicts with early HTTP/2 implementations
>> and early ALPN implementations, as such early
>> implementations are likely to only cater to that
>> single use of ALPN.
> Perhaps so.  I would prefer to optimize the GSS flights as well too.

Ditto.

>
>>>> 3. The TLS server (if it supports and allows the extension)
>>>> responds with a 0 byte TLS extension "GSS-2" to confirm
>>>> support.
>>> Well, presumably the first response GSS token should go here.
>> No, see below.
> In your protocol the client already sent a SPNEGO initial security
> context token.  A response is required, as GSS context establishment
> token exchanges are strictly synchronous.
As written, I had forgotten about the "Finished"
messages.  Thus the point wasto simply delay the
server GSS response (2. GSS leg) to just after
switching onthe encryption, later in the same
round of messages.  The 3. leg (second client to
server "GSS token") would then follow etc.

The ordering of GSS message tokens is of cause
crucial for the security guarantees of many
mechanisms.  It was all about when to send the
next token, never about reordering or omitting
them.

>>>> 5. In the last legs, the GSS mechanism is told to (mutually
>>>> if possible) authenticate some already defined hash of the
>>>> TLS handshake, thereby protecting the key exchange.Other
>>>> than the round trip saving for the first 2 legs, this is
>>>> what distinguishes GSS-2 from simply doing application level
>>>> GSS over a TLS connection.  Any GSS negotiated keys are not
>>>> used beyond this authentication of the TLS key exchange.
>>> This is the MIC exchange I mention above.
>> Yep, however as this entails extra round trips, it is
>> not the only option.
> With PROT_READY there should be no need for an extra round-trip.
Depends a lot on the mechanism.  Some GSS mechanisms
(other than Kerberos IV/V) cannot use their MIC until
they have received a later token from the other end,
but can incorporate binding data earlier than that.  I
think GSS-SRP-6a has that property.
>
>>>> 6. If the GSS mechanism preferred by the client requires the
>>>> authenticated hash value to be known before sending the
>>>> first GSS leg, then the client shall simply abstain from
>>>> including that first leg in the first leg SPNego message
>>>> if sent in the client hello extension.
>>> If we're doing a MIC exchange then we don't need to know the channel
>>> binding a initial security context token production time.
>> However the early channel binding might save a leg.
> You mean late.  Your idea seems to be to exposed knowledge of when is
> the latest that a mechanism can begin to use the channel binding so as
> to delay giving it the channel binding until we know it.  That would be
> a significant change to GSS, and often it won't help (e.g., Kerberos,
> the mechanism of interest in this thread).
The idea would be if an implementation (not the protocol
extension specification as such) is blessed with a
non-standard GSS option to provide the channel binding
after the 1. leg, but not with the early MIC use ability
of Kerberos, the the protocol extension should not prevent
it from taking advantage of this to do the channel binding
before the 2. leg, rather than after the n-th leg.

Like this

     ClientHello+GSS1 ----->
                      <-----  ServerHello
                      <-----  "enable crypto"
                      <-----  GSS2 (bound)
     Finished         ----->
     "enable crypto"  ----->
     GSS3 (bound)     ----->

Versus

     ClientHello+GSS1 ----->
                      <-----  ServerHello
                      <-----  "enable crypto"
                      <-----  GSS2
     Finished         ----->
     "enable crypto"  ----->
     GSS3             ----->
                      <-----  MIC(binding)
     MIC(binding)     ----->

Also even without that ability, if a GSS mechanism (other
than Kerberos) can do the server-to client leg first, but
not tuck MIC signing onto the penultimate leg, then direct
channel binding would still save one leg (half a round).


     ClientHello+""   ----->
                      <-----  ServerHello
                      <-----  "enable crypto"
                      <-----  GSS1 (bound)
     Finished         ----->
     "enable crypto"  ----->
     GSS2 (bound)     ----->
                      <-----  GSS3 (bound)


I obviously forgot about this order already saving that
half leg:

     ClientHello+GSS1 ----->
                      <-----  ServerHello
                      <-----  "enable crypto"
                      <-----  GSS2
     Finished         ----->
     "enable crypto"  ----->
     GSS3             ----->
     MIC(binding) ----->
                      <----- MIC(binding)

>
>>>> 7. If the client wants encryption of the first GSS leg, it
>>>> can either abstain from including that leg in the first
>>>> SPNego GSS leg, or it can send a 0-byte first leg and then
>>>> send the real first SPNego leg in the first encrypted client
>>>> o server record, with the server responding with the second
>>>> leg in the first encrypted server to client record as before
>>>> (but no longer in the same round trip as the second half of
>>>> the TLS handshake).
>>> With the ALPN approach this is a given.
>> However if the first leg need not be encrypted and
>> need not know thechannel binding, it can be sent a
>> round earlier. This can (I hope) be decided on a per
>> mechanism basis, thus if a GSS mechanism need not know
>> its channel binding until the second leg,
>> implementations that can provide the binding to the
>> GSS layer later can take advantage of it.
> No, this can't be decided on a per-mechanism basis, not without first
> modifying GSS significantly.
The need to encrypt the first leg for privacy (e.g. to
hide the user id) would bea protocol property which
the application could know from standards (no extra
GSS calls or flags needed).  E.g. "Mechanism FOO reveals
semi-sensitive information to passive observers of leg1,
but Mechanism BAR does not".  As a local matter, this can
even change during the lifetime of the protocol as new
attacks on mechanisms are discovered.  An overly
conservative implementation could pretend that all
mechanisms need encryption, an overly optimistic
implementation could pretend that none do.

The lack of need to know the channel binding early can
be determined from either:
- A local or global decision to use the MIC technique
  for this mechanism.
- Site local availability of extra GSS calls or flags
  to provide channel binding later forsome mechanisms.

>
>>>> 9. When the "GSS-2" extension is negotiated, TLS
>>>> implementations SHOULD allow anonymous (unauthenticated)
>>>> cipher suites even if they would not otherwise do so,
>>>> however they MUST be able to combine the "GSS-2" extension
>>>> with any and all of the cipher suites and TLS versions they
>>>> otherwise implement.  For instance, if an implementation of
>>>> the "GSS-2" extension is somehow bolted on to a fully
>>>> patched OpenSSL 1.0.0 library (via generic extension
>>>> mechanisms), then that combination would support it with
>>>> TLS 1.0 only, and TLS 1.3 capable implementations would be
>>>> negotiating TLS 1.0 when doing "GSS-2" with such an
>>>> implementation.
>>> If only GSS mechanisms that provide integrity protection or better as
>>> used, then this is fine.
>> And why would this not work with any other form of
>> channel binding?  Key requirement is that the TLS
>> key exchange is bound to the specific authentication
>> in some way not susceptible to man in the middle.
> I was referring to GSS per-message tokens.  You're proposing changes to
> GSS -- I hadn't understood that then.
No, I was referring to the apparently existing ability
to do "GSS-style" channel binding in a standard way
for some but not all GSS mechanisms.  An ability someone
else mentioned earlier in this thread (first I heard of
itin GSS context, but inherently natural in context, and
thus believable without reading through the RFCs to find
the details).
>
>>> You're missing a status message for authorization (GSS authentication
>>> might complete, but authorization fail), though this is not strictly
>>> necessary: the server can simply close the connection, including sending
>>> an alert about this (or not) just before closing the connection.
>> For security it is best if successful authentication
>> of an unauthorized account (thinkroot) is
>> indistinguishable from unsuccessful authentication of
>> that account.
> With GSS that's not really true.  The mechanism token exchange is a
> black box.  It may yield failure with error tokens.  The application can
> detect this and elect not to send error tokens, but if a final token was
> expected in the success case then the peer will know what happened
> anyways.  It's very difficult to generically ensure what you propose,
> and not that valuable.
Like other per mechanism properties, this can be simply
tabulated as:

"for mechanism X, check the authorization before sending
the 2. GSS token and simulate failure using call sequence
A"
"for mechanism Y, check the authorization before sending
the 1. GSS token and simulate failure using call sequence
A"
"for mechanism Z, check the authorization before sending
the 2. GSS token and simulate failure using call sequence
B"

All done opaquely, but with knowledge of where to put
the "square" black boxes versus the "round" black boxes.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From nico at cryptonector.com  Wed May 13 19:17:34 2015
From: nico at cryptonector.com (Nico Williams)
Date: Wed, 13 May 2015 14:17:34 -0500
Subject: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re:
 Kerberos)
In-Reply-To: <55538572.5090704@wisemo.com>
References: <20150509021811.GD7287@localhost> <20150509035751.GF7287@localhost>
 <20150511162532.GH7287@localhost>
 <20150511164249.GX17272@mournblade.imrryr.org>
 <20150511185218.GI7287@localhost> <55524526.4000207@wisemo.com>
 <20150512194528.GQ7287@localhost> <55532175.3030703@wisemo.com>
 <20150513154641.GU7287@localhost> <55538572.5090704@wisemo.com>
Message-ID: <20150513191733.GX7287@localhost>


We're closer.

On Wed, May 13, 2015 at 07:10:10PM +0200, Jakob Bohm wrote:
> On 13/05/2015 17:46, Nico Williams wrote:
> >On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote:
> >>On 12/05/2015 21:45, Nico Williams wrote:
> >>>On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote:
> >>>>How about the following simplifications for the new
> >>>>extension, lets call  it "GSS-2" (at least in this e-mail).
> >>>>
> >>>>1. GSS (including SASL/GS2) is always done via the SPNego
> >>>>GSS mechanism, which provides standard handling of
> >>>>mechanism negotiation (including round-trip optimizations),
> >>>>and is already its own standard (complete with workarounds
> >>>>for historic bugs in the dominant implementation...).
> >>>
> >>>SASL/GS2 and SPNEGO are incompatible.
> >>
> >>How?  I thought SPNEGO encapsulated and negotiated
> >>arbitrary GSS mechanisms.
> >
> >The problem is that negotiating twice is bad (for various reasons), and
> >SASL has non-GSS mechanisms, so negotiating SASL mechanisms, then GSS is
> >a two-level negotiation that is fraught with peril, therefore forbidden.
>
> Ok, having not studied the standard SASL in GSS
> specification, I presumed each GSS-encapsulated SASL
> mechanism would have its own GSS mechanism OID in
> some systematic way, leaving just one negotiation.

SASL/GS2 is the other way around: GSS in SASL.

The idea is that you can have GSS as SASL mechanisms in a way that sucks
less than the original GSS-in-SASL bridge in RFC2222 (that added an
extra round-trip), and which makes it easy to add mechanisms like SCRAM
as both, a GSS and a SASL mechanism.

I'm perfectly happy to drop SASL though.

> >>To me the key benefit of SPNEGO is the existence of
> >>already battle tested negotiation code readily available
> >>i many/most current GSS implementation.  It is one less
> >>thing to design and implement wrong.
> >
> >It's quite complex owing to having been underspecified in the first
> >place then having grown a number of bug workarounds over the years.
>
> Yes, but it is now a mature protocol, and I was trying
> to avoid creating yet another near identical
> handshake protocol.

The only complication in a negotiation mechanism is protecting the
negotiation.  Since the TLS handshakes are ultimately integrity-
protected, there's no complication at all to having the client send a
list of mechanisms and the server pick one (the client can even send an
optimistic choice's initial context token).  In fact, it's much nicer
than SPNEGO in many ways; if at all possible one should avoid SPNEGO.

Among other things, not using SPNEGO means that it will be much easier
to implement this protocol without extensions to GSS (extensions would
be needed only to optimize it).

> >In your protocol the client already sent a SPNEGO initial security
> >context token.  A response is required, as GSS context establishment
> >token exchanges are strictly synchronous.
> 
> As written, I had forgotten about the "Finished"
> messages.  Thus the point wasto simply delay the
> server GSS response (2. GSS leg) to just after
> switching onthe encryption, later in the same
> round of messages.  The 3. leg (second client to
> server "GSS token") would then follow etc.

We could extend GSS (see below) to support late channel binding, but
since a mechanism might not be able to do it, this protocol would have
to fall back on MIC tokens to complete the channel binding, in some
cases at a cost of one more round trip.

> >With PROT_READY there should be no need for an extra round-trip.
> 
> Depends a lot on the mechanism.  Some GSS mechanisms
> (other than Kerberos IV/V) cannot use their MIC until
> they have received a later token from the other end,
> but can incorporate binding data earlier than that.  I
> think GSS-SRP-6a has that property.

Kerberos in particular supports PROT_READY.  There is no Kerberos IV GSS
mechanism, FYI.  I'd never heard of GSS-SRP-6a; do you have a reference?

> >>>>6. If the GSS mechanism preferred by the client requires the
> >>>>authenticated hash value to be known before sending the
> >>>>first GSS leg, then the client shall simply abstain from
> >>>>including that first leg in the first leg SPNego message
> >>>>if sent in the client hello extension.
> >>>If we're doing a MIC exchange then we don't need to know the channel
> >>>binding a initial security context token production time.
> >>However the early channel binding might save a leg.
> >
> >You mean late.  Your idea seems to be to exposed knowledge of when is
> >the latest that a mechanism can begin to use the channel binding so as
> >to delay giving it the channel binding until we know it.  That would be
> >a significant change to GSS, and often it won't help (e.g., Kerberos,
> >the mechanism of interest in this thread).
>
> The idea would be if an implementation (not the protocol
> extension specification as such) is blessed with a
> non-standard GSS option to provide the channel binding
> after the 1. leg, but not with the early MIC use ability
> of Kerberos, the the protocol extension should not prevent
> it from taking advantage of this to do the channel binding
> before the 2. leg, rather than after the n-th leg.

If we finish the channel binding state flag extension we can support
late channel binding.

The application would provide channel bindings late and the mechanism
would indicate the channel binding status, and if it couldn't do it then
the application would have to fall back on MIC tokens.  Where PROT_READY
is indicated early the fallback MIC token exchange never costs extra
round trips.

For 2- and 3-token mechanisms the MIC token exchange also never costs
additional round trips regardless of PROT_READY or late channel binding
support.

For some imaginable mechanisms there is nothing we could do to avoid an
extra round trip, but most likely they will never exist.

> >>However if the first leg need not be encrypted and
> >>need not know thechannel binding, it can be sent a
> >>round earlier. This can (I hope) be decided on a per
> >>mechanism basis, thus if a GSS mechanism need not know
> >>its channel binding until the second leg,
> >>implementations that can provide the binding to the
> >>GSS layer later can take advantage of it.
> >
> >No, this can't be decided on a per-mechanism basis, not without first
> >modifying GSS significantly.
>
> The need to encrypt the first leg for privacy (e.g. to
> hide the user id) would bea protocol property which
> the application could know from standards (no extra
> GSS calls or flags needed).  E.g. "Mechanism FOO reveals
> semi-sensitive information to passive observers of leg1,
> but Mechanism BAR does not".  As a local matter, this can
> even change during the lifetime of the protocol as new
> attacks on mechanisms are discovered.  An overly
> conservative implementation could pretend that all
> mechanisms need encryption, an overly optimistic
> implementation could pretend that none do.

Yes, though if the mechanism was not going to expose the client's
identity in the first context token... but yes, this is much better left
as an application decision not based on knowledge of the mechanism.

> The lack of need to know the channel binding early can
> be determined from either:
> - A local or global decision to use the MIC technique
>  for this mechanism.
> - Site local availability of extra GSS calls or flags
>  to provide channel binding later forsome mechanisms.

Right.

> >>For security it is best if successful authentication
> >>of an unauthorized account (thinkroot) is
> >>indistinguishable from unsuccessful authentication of
> >>that account.
> >
> >With GSS that's not really true.  The mechanism token exchange is a
> >black box.  It may yield failure with error tokens.  The application can
> >detect this and elect not to send error tokens, but if a final token was
> >expected in the success case then the peer will know what happened
> >anyways.  It's very difficult to generically ensure what you propose,
> >and not that valuable.
>
> Like other per mechanism properties, this can be simply
> tabulated as:
> 
> "for mechanism X, check the authorization before sending
> the 2. GSS token and simulate failure using call sequence
> A"
> "for mechanism Y, check the authorization before sending
> the 1. GSS token and simulate failure using call sequence
> A"
> "for mechanism Z, check the authorization before sending
> the 2. GSS token and simulate failure using call sequence
> B"
> 
> All done opaquely, but with knowledge of where to put
> the "square" black boxes versus the "round" black boxes.

I don't think this works as well as you think, and I see very little
value in it.  For Kerberos this means sending a bogus KRB-ERROR on
authorization failure which will confuse the user if there was an error
they could have dealt with, or which will not confuse anyone because it
will be obvious that this means "authorization denied", so might as well
have sent an authorization denied message instead.

It would be much easier instead to let the application define its own
authorization status message (if it needs one at all) and send it (or
shut the door, or provide bogus content, or...) as it pleases.

Nico
-- 

From nico at cryptonector.com  Wed May 13 19:18:58 2015
From: nico at cryptonector.com (Nico Williams)
Date: Wed, 13 May 2015 14:18:58 -0500
Subject: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re:
 Kerberos)
In-Reply-To: <55538572.5090704@wisemo.com>
References: <20150509021811.GD7287@localhost> <20150509035751.GF7287@localhost>
 <20150511162532.GH7287@localhost>
 <20150511164249.GX17272@mournblade.imrryr.org>
 <20150511185218.GI7287@localhost> <55524526.4000207@wisemo.com>
 <20150512194528.GQ7287@localhost> <55532175.3030703@wisemo.com>
 <20150513154641.GU7287@localhost> <55538572.5090704@wisemo.com>
Message-ID: <20150513191853.GY7287@localhost>


I wonder if we could do this in the KITTEN WG list.  Maybe not every
extension to TLS needs to be treated as a TLS WG work item...  We should
ask the security ADs.

Nico
-- 

From jaltman at secure-endpoints.com  Wed May 13 19:37:17 2015
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Wed, 13 May 2015 15:37:17 -0400
Subject: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re:
	Kerberos)
In-Reply-To: <20150513191733.GX7287@localhost>
References: <20150509021811.GD7287@localhost>
 <20150509035751.GF7287@localhost> <20150511162532.GH7287@localhost>
 <20150511164249.GX17272@mournblade.imrryr.org>
 <20150511185218.GI7287@localhost> <55524526.4000207@wisemo.com>
 <20150512194528.GQ7287@localhost> <55532175.3030703@wisemo.com>
 <20150513154641.GU7287@localhost> <55538572.5090704@wisemo.com>
 <20150513191733.GX7287@localhost>
Message-ID: <5553A7ED.4060206@secure-endpoints.com>

On 5/13/2015 3:17 PM, Nico Williams wrote:
> Kerberos in particular supports PROT_READY.  There is no Kerberos IV GSS
> mechanism, FYI.  I'd never heard of GSS-SRP-6a; do you have a reference?

Nico,

Look for draft-burdis-cat-srp-sasl.  It was never standardized but I
believe there is an implementation in Cyrus/SASL.  This is the most
recent version I could find

 http://www.opensource.apple.com/source/passwordserver_sasl/passwordserver_sasl-159/cyrus_sasl/doc/draft-burdis-cat-srp-sasl-xx.txt

Jeffrey Altman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4589 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150513/b9f1b954/attachment-0001.bin>

From m.vinicius at samsung.com  Thu May 14 13:39:53 2015
From: m.vinicius at samsung.com (Marcus Vinicius do Nascimento)
Date: Thu, 14 May 2015 10:39:53 -0300
Subject: [openssl-users] RES:  Testing OpenSSL based solution
In-Reply-To: <004801d08d4d$84a5f010$8df1d030$@prinpay.com>
References: <004801d08d4d$84a5f010$8df1d030$@prinpay.com>
Message-ID: <007001d08e4b$75f0a160$61d1e420$@samsung.com>

Thanks Dave.

Sure I can't recover the private key from the public. Otherwise it wouldn't
make any sense to use the DSA algorithm at all.

I dig a little into fips code and think using FIPs test vectors to validate
my API is not practical.
Looks like FIPs deals with openssl internals to test it. Structures that
should be opaque to the user are not to FIPs code.

I believe a simples approach like creating my own test vectors could be more
productive.
I know it wouldn't cover everything FIPs covers. But maybe this is exactly
the point, since openssl is well tested against FIPs and my code wraps
openssl.
Does it make sense?

Thanks.


-----Mensagem original-----
De: openssl-users [mailto:openssl-users-bounces at openssl.org] Em nome de Dave
Thompson
Enviada em: quarta-feira, 13 de maio de 2015 04:22
Para: openssl-users at openssl.org
Assunto: Re: [openssl-users] Testing OpenSSL based solution

> From: openssl-users On Behalf Of Marcus Vinicius do Nascimento
> Sent: Tuesday, May 12, 2015 16:50

> I did some quick research and found this:
http://en.wikipedia.org/wiki/Digital_Signature_Algorithm
> If my understanding is correct, the public key is (p, q, g, y).

You might want to look at the actual standard, FIPS 186, free from NIST and
referred to by wikipedia as well as easily searchable. The current version
is revision -4, but the basic logic of DSA hasn't changed since "-0"
(although the sizes used have increased).

Standardly a DSA public key is (parameters, y) where parameters is (p, q, g
{, seed, counter}) where the optional fields in the parameters allow
verification of the parameter generation process. OpenSSL does not use that
option, so it uses only p,g,q and y. See below.

> The private key would be x, such that y = g^x mod p.
> Is there some way to generate both public and private keys using 
> OpenSSL, based on p, q, g and y?

You cannot recover the private key from the public key for any secure PKC
scheme used with appropriate sizes. DSA is a secure scheme, and DSS and
these test cases use appropriate sizes.

> De: openssl-users Em nome de Marcus Vinicius do Nascimento Enviada em: 
> ter?a-feira, 12 de maio de 2015 17:06

> I tried using Y as the public key, but ssl seems not to accept that.
> From the FIP file: <snip>
> So I tried reformatting Y to pass it to PEM_read_bio_DSAPrivateKey.
> Converting Y to Base64 = <snip>
> Reformatting in PEM format = "-----BEGIN DSA PRIVATE KEY----- <snip>
[doesn't work]

As above, the public key requires all of p,q,g and y, not just y. 
The private key would require x as well, and you don't have x.

For public keys for _all_ algorithms in files including PEM 
OpenSSL uses the format standardized by X.509 called 
SubjectPublicKeyInfo or SPKI for short, which is an ASN.1 
sequence containing an AlgorithmIdentifier which is a(nother) 
sequence containing an OID identifying the algorithm and an 
optional parameters field whose type depends on the algorithm,
followed by a BITSTRING containing a nested encoding of the 
public key value relative to the parameters for that algorithm.

For DSA, the OID identifies DSA, the parameters are a sequence 
of three INTEGERs for p,g,q, and the nested key encoding is 
just an INTEGER. All elements in ASN.1 use a "TLV" (tag, length,
value) encoding, and INTEGER (thus) consists of a tag octet of 02 
specifying integer, a length whose length itself varies depending 
on the length it encodes, and a value field which for INTEGER is 
a _signed_ big-endian binary number. Since the particular y
you tried to encode below happens to have a magnitude size of 
1024 bits, a multiple of 8, it requires a leading sign octet of 00.
So does g in this case, and p and q by design (they are specified with 
magnitude sizes which are multiples of 8, and indeed of 32).

See rfc 5280 for the generic SPKI format, and rfc 3279 (referenced there) 
for the specifics for several algorithms including DSA.

Note that the PEM type is just "BEGIN/END PUBLIC KEY"  (no DSA) 
because as above the format handles all algorithms.


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


From jaltman at secure-endpoints.com  Thu May 14 14:14:34 2015
From: jaltman at secure-endpoints.com (Jeffrey Altman)
Date: Thu, 14 May 2015 10:14:34 -0400
Subject: [openssl-users] [openssl-dev]  Kerberos
In-Reply-To: <55535D6C.4060109@openssl.org>
References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com>
 <20150508004035.GE17272@mournblade.imrryr.org>
 <554C1142.9090002@secure-endpoints.com> <554C7691.80906@openssl.org>
 <55535D6C.4060109@openssl.org>
Message-ID: <5554ADCA.4070902@secure-endpoints.com>

On 5/13/2015 10:19 AM, Matt Caswell wrote:
> 
> 
> On 08/05/15 09:40, Matt Caswell wrote:
>>
>>
>> On 08/05/15 02:28, Jeffrey Altman wrote:
>>
>>> Regardless, the inability to improve the support in this area has left
>>> the those organizations that rely upon 2712 with the choice of use
>>> insecure protocols or re-implement the applications.  I do not believe
>>> that any sane OS or application vendor can with a straight face continue
>>> to ship 2712 support.  As such it should be removed from OpenSSL master.
>>
>> I plan to start preparing the patches to remove it next week.
> 
> FYI, these patches have now been applied to master.
> 
> Matt


Thank you.

Jeffrey Altman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4589 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150514/af10e4b3/attachment.bin>

From jayf0ster at roadrunner.com  Thu May 14 22:09:10 2015
From: jayf0ster at roadrunner.com (Jay Foster)
Date: Thu, 14 May 2015 15:09:10 -0700
Subject: [openssl-users] Truncating A Hash
Message-ID: <55551D06.7060601@roadrunner.com>

What is the down side of truncating a hash?  For example, an SHA-256 
hash is 256 bits.  Is it any less secure if one was to drop the last 128 
bits to make a 128 bit hash or take the MD5 hash of the SHA-256 hash to 
get a 128 bit hash?  It does not seem that such an action would make it 
any easier to brute force reverse the hash, but then again, I am clearly 
not a security expert.

Jay

From openssl-users at dukhovni.org  Thu May 14 22:43:34 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 14 May 2015 22:43:34 +0000
Subject: [openssl-users] Truncating A Hash
In-Reply-To: <55551D06.7060601@roadrunner.com>
References: <55551D06.7060601@roadrunner.com>
Message-ID: <20150514224334.GT17272@mournblade.imrryr.org>

On Thu, May 14, 2015 at 03:09:10PM -0700, Jay Foster wrote:

> What is the down side of truncating a hash?  For example, an SHA-256 hash is
> 256 bits.  Is it any less secure if one was to drop the last 128 bits to
> make a 128 bit hash

Yes, a truncated hash is less secure against both collision and
2nd-preimage attacks.


> or take the MD5 hash of the SHA-256 hash to get a 128
> bit hash?

This would not help.

> It does not seem that such an action would make it any easier to
> brute force reverse the hash, but then again, I am clearly not a security
> expert.

Hashes are not encryption algorithms, and dictionary attacks to
discover the original input are not the primary attacks of interest.

In the special case where hashes are used for verifying passwords,
suitably salted and extensively iterated hashes can be truncated
to shorter lengths that still avoid false positives with wrong
passwords, because protection against dictionary attacks comes from
salting and high iteration count (PBKDF2 or similar with 10^5
iterations or more) not the hash length.

-- 
	Viktor.

From Michael.Wojcik at microfocus.com  Thu May 14 23:13:00 2015
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 14 May 2015 23:13:00 +0000
Subject: [openssl-users] Truncating A Hash
In-Reply-To: <55551D06.7060601@roadrunner.com>
References: <55551D06.7060601@roadrunner.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088014BB506A9@Rock-Exchange1.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Jay Foster
> Sent: Thursday, May 14, 2015 18:09
> To: openssl-users at openssl.org
> Subject: [openssl-users] Truncating A Hash
> 
> What is the down side of truncating a hash?  For example, an SHA-256
> hash is 256 bits.  Is it any less secure if one was to drop the last 128
> bits to make a 128 bit hash or take the MD5 hash of the SHA-256 hash to
> get a 128 bit hash?  It does not seem that such an action would make it
> any easier to brute force reverse the hash, but then again, I am clearly
> not a security expert.

Every bit you remove makes it half as expensive to find a collision by brute force. Discarding 128 bits of an SHA-256 hash makes it 2^128 times easier to "break" the hash.

Precisely how much truncation benefits an attack that's not brute force - that is, an attack on the compression function itself - depends on the attack. But it certainly isn't going to make such an attack more difficult.

Truncation is, broadly speaking, a Bad Idea. Whether it actually poses a credible threat depends on your threat model, but it's something to avoid.

Rehashing with another function that has smaller output (as in your proposal of composing SHA-256 with MD5) is worse than truncation, assuming the initial function is strong, because the result won't be better than truncation and could expose the overall system to other classes of better-than-brute-force attacks.

You're asking the wrong question, by the way, for two reasons. First, there is no "reverse the hash". A hash cannot be reversed, because it's a lossy function with a domain larger than its range; there are many preimages that hash to the same image. Defeating a cryptographic hash by brute force is a matter of finding another preimage that hashes to the same image. (That's oversimplified but good enough for our purposes.) When you discard a bit from the hash, you reduce the total number of possible hash values by a factor of two, so you make it twice as easy to find a collision.

Second, the question isn't "is it safe to truncate the output of a cryptographic hash". It's "I have problem X, under threat model Y; how can I solve X while satisfying Y as much as possible?". You need to tell us your X and explain what you can of your Y.

For example: "I have a legacy system that only allows 8 printable characters for passwords. I want to put a front end on it that lets users enter long passwords. Then I'll hash the password and convert the hash to Base64 and use the first 8 characters as the system password. But that's only using 48 bits of the hash value. Can I do better?"

(Another question would be what this has to do with OpenSSL...)

-- 
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com

From secinterlocutor at gmail.com  Fri May 15 08:44:45 2015
From: secinterlocutor at gmail.com (SecInterlocutor)
Date: Fri, 15 May 2015 09:44:45 +0100
Subject: [openssl-users] Fwd: X9.31 RSA key generation for FIPS validation
	(180-4)
In-Reply-To: <CAPU23zMY4i9uAbnU3SuzrfFr0YP0oudQMixJkrAKNCOaRY0QCw@mail.gmail.com>
References: <CAPU23zMY4i9uAbnU3SuzrfFr0YP0oudQMixJkrAKNCOaRY0QCw@mail.gmail.com>
Message-ID: <CAPU23zOAPCcVT8aW5i=cgzwxeTzAA+oQfk+Z-dm=gbkVRUtw_w@mail.gmail.com>

Hello,


Our product was FIPS-certified a few years ago. We are now about to start
the re-certification process.


The test for RSA X9.31 key generation have somewhat changed, or so it looks
like to me anyway.


A few years ago, we received test vectors with the following parameters:
modulus size, e, xp1, xp2, Xp, xq1, xq2, Xq.

The response we provided included the previous parameters and these
generated values: p, q, n, d.


We used  FIPS_rsa_x931_derive_ex()  to generate the values.

I believe this function implements section B.3.6: Generation of Probable
Primes with Conditions Based on Auxiliary Probable Primes. Prime method:
Primes p1, p2, q1,q2, p and q shall all be probable primes.

Is my assumption correct?


If so, we?d like to minimise effort and reuse our test sw for the new tests
in http://csrc.nist.gov/groups/STM/cavp/documents/dss2/rsa2vs.pdf.


I?m looking at section 6.2.1 where the parameters are: modulus size, e,
N=25 (number of iterations). It seems to me that we have to send a response
with all of the other parameters: xp1, xp2, Xp, xq1, xq2, Xq, p, q, n, d.

xp1, xp2, Xp, xq1, xq2, Xq are random numbers, some of them have to be odd.


Which function(s) do you suggest to use to generate them?

Or can I just use FIPS_rsa_x931_generate_key_ex() ? Is this used with a
fixed exponent? Does it also implement section B.3.6?


We also have to indicate to NIST the type of Probabilistic Primality Test
the (specific) OpenSSL functions use:

a)      Table C.2. Minimum number of rounds of M-R testing when generating
primes

b)      Table C.3. Minimum number of rounds of M-R testing when generating
primes using an error probability of 2^?100


Which one(s) does OpenSSL implement? If both, how is that chosen?





Many thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150515/1cb294ec/attachment-0001.html>

From mebeyn at gmail.com  Fri May 15 10:57:55 2015
From: mebeyn at gmail.com (Martin Beynon)
Date: Fri, 15 May 2015 11:57:55 +0100
Subject: [openssl-users] OpenSSL Behaviour under low bandwidth
Message-ID: <CADpW=+3XX_U-z=kwin8OQh1T98CuheOMh=VNerrzgKLvxTPx3Q@mail.gmail.com>

Hi all,

I have discovered some strange behaviour with OpenSSL under low bandwidth
conditions.

I've found that with the bandwidth < about 150 kpbs that the throughput
drops heavily and doesn't appear to be anywhere near the available
bandwidth, spending a lot of time doing nothing.

I've tested various bandwidth conditions and all seems work as expected
until the bandwidth available drops below around 150 kpbs and it becomes
unusable at 56 kbps. However if we slow the rate at which data is passed to
OpenSSL to about the output bandwidth it continues to operate as expected -
smoothly, giving the throughput expected.

I've tested with s_client between my PC and an AWS EC2 instance. I've also
tried using s_tunnel and nmap/ncat. The results appear the same. Using
wireshark I see a lot of TCP retransmissions.

At first I thought it was a problem with s_client, but after some
investigation it looks more like the issue is within the OpenSSL lib itself.

Any ideas what could be going wrong? Should we expect OpenSSL to work under
low bandwidth conditions?

Just to note; I've not tested with the latest 1.0.2 versions of
OpenSSL...yet. Should I expect any different behaviour?


Thanks in advance,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150515/42571e73/attachment.html>

From rsalz at akamai.com  Fri May 15 11:00:58 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 15 May 2015 11:00:58 +0000
Subject: [openssl-users] OpenSSL Behaviour under low bandwidth
In-Reply-To: <CADpW=+3XX_U-z=kwin8OQh1T98CuheOMh=VNerrzgKLvxTPx3Q@mail.gmail.com>
References: <CADpW=+3XX_U-z=kwin8OQh1T98CuheOMh=VNerrzgKLvxTPx3Q@mail.gmail.com>
Message-ID: <15c38d163f1f4469b34cd24229a50f04@ustx2ex-dag1mb4.msg.corp.akamai.com>

>I've tested with s_client between my PC and an AWS EC2 instance. I've also tried using s_tunnel and nmap/ncat. The results appear the same. Using wireshark I see a lot of TCP retransmissions.

That sounds like a network issue.  Try testing using something like netcat and see if you also get TCP retransmissions.

--  
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz



From mebeyn at gmail.com  Fri May 15 11:16:00 2015
From: mebeyn at gmail.com (Martin Beynon)
Date: Fri, 15 May 2015 12:16:00 +0100
Subject: [openssl-users] OpenSSL Behaviour under low bandwidth
In-Reply-To: <15c38d163f1f4469b34cd24229a50f04@ustx2ex-dag1mb4.msg.corp.akamai.com>
References: <CADpW=+3XX_U-z=kwin8OQh1T98CuheOMh=VNerrzgKLvxTPx3Q@mail.gmail.com>
 <15c38d163f1f4469b34cd24229a50f04@ustx2ex-dag1mb4.msg.corp.akamai.com>
Message-ID: <CADpW=+1JM9VPax6Qnj5ZfYXPxLYE=qBrreUZuxQwVM7Tk+ye4w@mail.gmail.com>

Hi Rich,

Thanks for your quick response.

It does...and I do wonder if it has something to do with the bandwidth
limiting / traffic shaping feature on the DrayTek router that I'm using to
simulate low bandwidth.

The reason I am looking at this now is because I'm experiencing some
customer issues in the wild, and the only common factor is low bandwidth...
So network issues seem unlikely, plus if I add some delay in my application
to slow the rate at which I feed data to openssl the problem goes away, and
it only occurs below 150 kpbs (getting noticeably worse as I approach 56
kpbs).

Cheers,

Martin

On 15 May 2015 at 12:00, Salz, Rich <rsalz at akamai.com> wrote:

> >I've tested with s_client between my PC and an AWS EC2 instance. I've
> also tried using s_tunnel and nmap/ncat. The results appear the same. Using
> wireshark I see a lot of TCP retransmissions.
>
> That sounds like a network issue.  Try testing using something like netcat
> and see if you also get TCP retransmissions.
>
> --
> Senior Architect, Akamai Technologies
> IM: richsalz at jabber.at Twitter: RichSalz
>
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150515/c8ca1b9d/attachment.html>

From rsalz at akamai.com  Fri May 15 11:19:56 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 15 May 2015 11:19:56 +0000
Subject: [openssl-users] OpenSSL Behaviour under low bandwidth
In-Reply-To: <CADpW=+1JM9VPax6Qnj5ZfYXPxLYE=qBrreUZuxQwVM7Tk+ye4w@mail.gmail.com>
References: <CADpW=+3XX_U-z=kwin8OQh1T98CuheOMh=VNerrzgKLvxTPx3Q@mail.gmail.com>
 <15c38d163f1f4469b34cd24229a50f04@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <CADpW=+1JM9VPax6Qnj5ZfYXPxLYE=qBrreUZuxQwVM7Tk+ye4w@mail.gmail.com>
Message-ID: <dbcc024eef6645f4adaee77595931306@ustx2ex-dag1mb4.msg.corp.akamai.com>

?It does?  Does that mean you have the same behavior?  If so, it is possible that your simulator is, well, not great. But this doesn?t seem an openssl issue. Not sure where to suggest you go for help.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150515/229272af/attachment.html>

From mebeyn at gmail.com  Fri May 15 11:44:03 2015
From: mebeyn at gmail.com (Martin Beynon)
Date: Fri, 15 May 2015 12:44:03 +0100
Subject: [openssl-users] OpenSSL Behaviour under low bandwidth
In-Reply-To: <dbcc024eef6645f4adaee77595931306@ustx2ex-dag1mb4.msg.corp.akamai.com>
References: <CADpW=+3XX_U-z=kwin8OQh1T98CuheOMh=VNerrzgKLvxTPx3Q@mail.gmail.com>
 <15c38d163f1f4469b34cd24229a50f04@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <CADpW=+1JM9VPax6Qnj5ZfYXPxLYE=qBrreUZuxQwVM7Tk+ye4w@mail.gmail.com>
 <dbcc024eef6645f4adaee77595931306@ustx2ex-dag1mb4.msg.corp.akamai.com>
Message-ID: <CADpW=+2H1ftkjiz7KCxbKZwfG1dc+hng-CJnYGk993APtPkPsg@mail.gmail.com>

Sorry Rich,

It does - as in; look like a network issue. But I fail to see how.

If I try to push 10MB/s into openssl and everything works as expected until
the available network bandwidth drops below 150 kpbs, this points at
openssl - I think.

That is right from 100Mbps down to 150 kpbs everything works as expected.
As I continue tuning down the bandwidth below 150kbps openssl starts to
stop sending data. It becomes very bursty and there are whole periods of
seconds where no data is sent from openssl even though it's 17KB TLS buffer
is full and pings, for example, can be sent and received normally.

There appears to be some relation to the size of this buffer and the
minimum achievable throughput we can get.. Unless my maths is off; 140 Kbps
would give about 17KB/s throughput.. Coincidence?

Have you tested sending large amounts of data between two s_clients across
a limited bandwidth link?
On 15 May 2015 12:20, "Salz, Rich" <rsalz at akamai.com> wrote:

>  ?It does?  Does that mean you have the same behavior?  If so, it is
> possible that your simulator is, well, not great. But this doesn?t seem an
> openssl issue. Not sure where to suggest you go for help.
>
>
>
>
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150515/92d8197d/attachment.html>

From jb-openssl at wisemo.com  Fri May 15 11:50:03 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 15 May 2015 13:50:03 +0200
Subject: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re:
	Kerberos)
In-Reply-To: <5553A7ED.4060206@secure-endpoints.com>
References: <20150509021811.GD7287@localhost>
 <20150509035751.GF7287@localhost> <20150511162532.GH7287@localhost>
 <20150511164249.GX17272@mournblade.imrryr.org>
 <20150511185218.GI7287@localhost> <55524526.4000207@wisemo.com>
 <20150512194528.GQ7287@localhost> <55532175.3030703@wisemo.com>
 <20150513154641.GU7287@localhost> <55538572.5090704@wisemo.com>
 <20150513191733.GX7287@localhost> <5553A7ED.4060206@secure-endpoints.com>
Message-ID: <5555DD6B.1080909@wisemo.com>

On 13/05/2015 21:37, Jeffrey Altman wrote:
> On 5/13/2015 3:17 PM, Nico Williams wrote:
>> Kerberos in particular supports PROT_READY.  There is no Kerberos IV GSS
>> mechanism, FYI.  I'd never heard of GSS-SRP-6a; do you have a reference?
> Nico,
>
> Look for draft-burdis-cat-srp-sasl.  It was never standardized but I
> believe there is an implementation in Cyrus/SASL.  This is the most
> recent version I could find
>
>   http://www.opensource.apple.com/source/passwordserver_sasl/passwordserver_sasl-159/cyrus_sasl/doc/draft-burdis-cat-srp-sasl-xx.txt
>
> Jeffrey Altman
No, I was referring to the (apparently never defined,
though I thought it was) use of RFC2945 (SRP 3) as a
GSS mechanism, with the additional bug fixes in SRP-6
(RFC5054) and SRP-6a (no RFC).  Here I am referring
to the SRP mechanism enhancements in RFC5054, not the
TLS binding also in RFC5054.

Because SRP-3 and SRP-6 is (from the outside) a kind
of authenticated DH exchange, neither end will be
ready to calculate MIC values until the primary
exchange messages have been completed (this does not
include any additional key confirmation messages that
might be folded into the channel binding legs).

This differs from Kerberos, where each end knows the
MIC key before sending its first GSS token.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150515/fa327afe/attachment-0001.html>

From jb-openssl at wisemo.com  Fri May 15 12:30:49 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 15 May 2015 14:30:49 +0200
Subject: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re:
	Kerberos)
In-Reply-To: <20150513191733.GX7287@localhost>
References: <20150509021811.GD7287@localhost>
 <20150509035751.GF7287@localhost> <20150511162532.GH7287@localhost>
 <20150511164249.GX17272@mournblade.imrryr.org>
 <20150511185218.GI7287@localhost> <55524526.4000207@wisemo.com>
 <20150512194528.GQ7287@localhost> <55532175.3030703@wisemo.com>
 <20150513154641.GU7287@localhost> <55538572.5090704@wisemo.com>
 <20150513191733.GX7287@localhost>
Message-ID: <5555E6F9.4020900@wisemo.com>

On 13/05/2015 21:17, Nico Williams wrote:
> We're closer.
>
> On Wed, May 13, 2015 at 07:10:10PM +0200, Jakob Bohm wrote:
>> On 13/05/2015 17:46, Nico Williams wrote:
>>> On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote:
>>>> On 12/05/2015 21:45, Nico Williams wrote:
>>>>> On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote:
>>>>>> How about the following simplifications for the new
>>>>>> extension, lets call  it "GSS-2" (at least in this e-mail).
>>>>>>
>>>>>> 1. GSS (including SASL/GS2) is always done via the SPNego
>>>>>> GSS mechanism, which provides standard handling of
>>>>>> mechanism negotiation (including round-trip optimizations),
>>>>>> and is already its own standard (complete with workarounds
>>>>>> for historic bugs in the dominant implementation...).
>>>>> SASL/GS2 and SPNEGO are incompatible.
>>>> How?  I thought SPNEGO encapsulated and negotiated
>>>> arbitrary GSS mechanisms.
>>> The problem is that negotiating twice is bad (for various reasons), and
>>> SASL has non-GSS mechanisms, so negotiating SASL mechanisms, then GSS is
>>> a two-level negotiation that is fraught with peril, therefore forbidden.
>> Ok, having not studied the standard SASL in GSS
>> specification, I presumed each GSS-encapsulated SASL
>> mechanism would have its own GSS mechanism OID in
>> some systematic way, leaving just one negotiation.
> SASL/GS2 is the other way around: GSS in SASL.
>
> The idea is that you can have GSS as SASL mechanisms in a way that sucks
> less than the original GSS-in-SASL bridge in RFC2222 (that added an
> extra round-trip), and which makes it easy to add mechanisms like SCRAM
> as both, a GSS and a SASL mechanism.
>
> I'm perfectly happy to drop SASL though.
Ah, I thought from context it was a way to use SASL
as GSS mechanisms, with GSS presumably beingthe more
powerful API for multi-leg protocols.

Since I generally expect some mechanisms to only have
standards for a form that can be bound to a channel or
MIC, it would be best to keep the ability to reuse both
standards via some existing bridging mechanism.
>
>>>> To me the key benefit of SPNEGO is the existence of
>>>> already battle tested negotiation code readily available
>>>> i many/most current GSS implementation.  It is one less
>>>> thing to design and implement wrong.
>>> It's quite complex owing to having been underspecified in the first
>>> place then having grown a number of bug workarounds over the years.
>> Yes, but it is now a mature protocol, and I was trying
>> to avoid creating yet another near identical
>> handshake protocol.
> The only complication in a negotiation mechanism is protecting the
> negotiation.  Since the TLS handshakes are ultimately integrity-
> protected, there's no complication at all to having the client send a
> list of mechanisms and the server pick one (the client can even send an
> optimistic choice's initial context token).  In fact, it's much nicer
> than SPNEGO in many ways; if at all possible one should avoid SPNEGO.
>
> Among other things, not using SPNEGO means that it will be much easier
> to implement this protocol without extensions to GSS (extensions would
> be needed only to optimize it).
Again, please say which GSS extensions would be
needed to use SPNEGO rather thanyet-another-
negotiation-protocol.
>
>>> In your protocol the client already sent a SPNEGO initial security
>>> context token.  A response is required, as GSS context establishment
>>> token exchanges are strictly synchronous.
>> As written, I had forgotten about the "Finished"
>> messages.  Thus the point wasto simply delay the
>> server GSS response (2. GSS leg) to just after
>> switching onthe encryption, later in the same
>> round of messages.  The 3. leg (second client to
>> server "GSS token") would then follow etc.
> We could extend GSS (see below) to support late channel binding, but
> since a mechanism might not be able to do it, this protocol would have
> to fall back on MIC tokens to complete the channel binding, in some
> cases at a cost of one more round trip.
There is also the fallback to early channel binding (by
not sending the first legs before the channel binding
data is available).  The resulting round trip counts
would need to be studied closely to pick one.
>
>>> With PROT_READY there should be no need for an extra round-trip.
>> Depends a lot on the mechanism.  Some GSS mechanisms
>> (other than Kerberos IV/V) cannot use their MIC until
>> they have received a later token from the other end,
>> but can incorporate binding data earlier than that.  I
>> think GSS-SRP-6a has that property.
> Kerberos in particular supports PROT_READY.  There is no Kerberos IV GSS
> mechanism, FYI.  I'd never heard of GSS-SRP-6a; do you have a reference?
See other subthread.
>
>>>>>> 6. If the GSS mechanism preferred by the client requires the
>>>>>> authenticated hash value to be known before sending the
>>>>>> first GSS leg, then the client shall simply abstain from
>>>>>> including that first leg in the first leg SPNego message
>>>>>> if sent in the client hello extension.
>>>>> If we're doing a MIC exchange then we don't need to know the channel
>>>>> binding a initial security context token production time.
>>>> However the early channel binding might save a leg.
>>> You mean late.  Your idea seems to be to exposed knowledge of when is
>>> the latest that a mechanism can begin to use the channel binding so as
>>> to delay giving it the channel binding until we know it.  That would be
>>> a significant change to GSS, and often it won't help (e.g., Kerberos,
>>> the mechanism of interest in this thread).
>> The idea would be if an implementation (not the protocol
>> extension specification as such) is blessed with a
>> non-standard GSS option to provide the channel binding
>> after the 1. leg, but not with the early MIC use ability
>> of Kerberos, the the protocol extension should not prevent
>> it from taking advantage of this to do the channel binding
>> before the 2. leg, rather than after the n-th leg.
> If we finish the channel binding state flag extension we can support
> late channel binding.
>
> The application would provide channel bindings late and the mechanism
> would indicate the channel binding status, and if it couldn't do it then
> the application would have to fall back on MIC tokens.  Where PROT_READY
> is indicated early the fallback MIC token exchange never costs extra
> round trips.
>
> For 2- and 3-token mechanisms the MIC token exchange also never costs
> additional round trips regardless of PROT_READY or late channel binding
> support.
>
> For some imaginable mechanisms there is nothing we could do to avoid an
> extra round trip, but most likely they will never exist.
>
>>>> However if the first leg need not be encrypted and
>>>> need not know thechannel binding, it can be sent a
>>>> round earlier. This can (I hope) be decided on a per
>>>> mechanism basis, thus if a GSS mechanism need not know
>>>> its channel binding until the second leg,
>>>> implementations that can provide the binding to the
>>>> GSS layer later can take advantage of it.
>>> No, this can't be decided on a per-mechanism basis, not without first
>>> modifying GSS significantly.
>> The need to encrypt the first leg for privacy (e.g. to
>> hide the user id) would bea protocol property which
>> the application could know from standards (no extra
>> GSS calls or flags needed).  E.g. "Mechanism FOO reveals
>> semi-sensitive information to passive observers of leg1,
>> but Mechanism BAR does not".  As a local matter, this can
>> even change during the lifetime of the protocol as new
>> attacks on mechanisms are discovered.  An overly
>> conservative implementation could pretend that all
>> mechanisms need encryption, an overly optimistic
>> implementation could pretend that none do.
> Yes, though if the mechanism was not going to expose the client's
> identity in the first context token... but yes, this is much better left
> as an application decision not based on knowledge of the mechanism.
However such an application decision would be meaningless
(and downright stupid) without mechanism knowledge.Note
that I distinguish clearly between knowledge of mechanism
properties (e.g. "Kerberos VI encrypts the client identity
in its 1st leg, NTLM does not"), which is fair game; versus
knowledge of mechanism internals (e.g. where Kerberos
stores/transmits various stuff), which should be known only
inside the mechanism black boxes.
>
>> The lack of need to know the channel binding early can
>> be determined from either:
>> - A local or global decision to use the MIC technique
>>   for this mechanism.
>> - Site local availability of extra GSS calls or flags
>>   to provide channel binding later forsome mechanisms.
> Right.
>
>>>> For security it is best if successful authentication
>>>> of an unauthorized account (thinkroot) is
>>>> indistinguishable from unsuccessful authentication of
>>>> that account.
>>> With GSS that's not really true.  The mechanism token exchange is a
>>> black box.  It may yield failure with error tokens.  The application can
>>> detect this and elect not to send error tokens, but if a final token was
>>> expected in the success case then the peer will know what happened
>>> anyways.  It's very difficult to generically ensure what you propose,
>>> and not that valuable.
>> Like other per mechanism properties, this can be simply
>> tabulated as:
>>
>> "for mechanism X, check the authorization before sending
>> the 2. GSS token and simulate failure using call sequence
>> A"
>> "for mechanism Y, check the authorization before sending
>> the 1. GSS token and simulate failure using call sequence
>> A"
>> "for mechanism Z, check the authorization before sending
>> the 2. GSS token and simulate failure using call sequence
>> B"
>>
>> All done opaquely, but with knowledge of where to put
>> the "square" black boxes versus the "round" black boxes.
> I don't think this works as well as you think, and I see very little
> value in it.  For Kerberos this means sending a bogus KRB-ERROR on
> authorization failure which will confuse the user if there was an error
> they could have dealt with, or which will not confuse anyone because it
> will be obvious that this means "authorization denied", so might as well
> have sent an authorization denied message instead.
You are presuming too much.  "Call sequence A" etc.
would be mechanisms to somehow generate what would
be indistinguishable from an authentication failure,
including whatever gymnastics is needed to make
Kerberos generate such a message.

Now for traditional 3-way Kerberos, "invalid username
or password" would be a message sent only from the
KDC during the TGT request, not from the target server,
so there would be no way to make this indistinguishable.
But for a Kerberos encapsulation where the TGT request
is relayed via the target server (by encapsulating it
inside the client-server GSS tokens), this would imply
some way of disrupting the process early to protect the
KDC from being indirectly probed for password validity
on accounts that shouldn't have been exposed in the
first place.

> It would be much easier instead to let the application define its own
> authorization status message (if it needs one at all) and send it (or
> shut the door, or provide bogus content, or...) as it pleases.


The whole point is to *integrate* the authentication
and authorization into the TLS setup (as seen from
the application), which completely precludes moving
it to the application level.  It may happen that some
implementations of this extension will look like
"application code" to various existing TLS libraries
(such as OpenSSL), but like "TLS code" to the actual
application, as this is the nature of adding TLS
extensions to an existing system.  But to the actual
application this should be as easy as calling
"somefunction_to_setup_TLS(options => {...,
Use_GSS_SASL(args), ...}) where "args" includes some
way to indicate which authenticated ids are considered
valid/invalid.

It would be the job of a "plugin" extension library to
implement rejecting unauthorized ids in a way remotely
indistinguishable from use of non-existing ids.  And
it would be the job of the extension specification to
say how this should be done in general.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150515/282c3af9/attachment-0001.html>

From kurt at roeckx.be  Fri May 15 20:21:41 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 15 May 2015 22:21:41 +0200
Subject: [openssl-users] OpenSSL Behaviour under low bandwidth
In-Reply-To: <CADpW=+2H1ftkjiz7KCxbKZwfG1dc+hng-CJnYGk993APtPkPsg@mail.gmail.com>
References: <CADpW=+3XX_U-z=kwin8OQh1T98CuheOMh=VNerrzgKLvxTPx3Q@mail.gmail.com>
 <15c38d163f1f4469b34cd24229a50f04@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <CADpW=+1JM9VPax6Qnj5ZfYXPxLYE=qBrreUZuxQwVM7Tk+ye4w@mail.gmail.com>
 <dbcc024eef6645f4adaee77595931306@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <CADpW=+2H1ftkjiz7KCxbKZwfG1dc+hng-CJnYGk993APtPkPsg@mail.gmail.com>
Message-ID: <20150515202141.GA11292@roeckx.be>

On Fri, May 15, 2015 at 12:44:03PM +0100, Martin Beynon wrote:
> 
> That is right from 100Mbps down to 150 kpbs everything works as expected.
> As I continue tuning down the bandwidth below 150kbps openssl starts to
> stop sending data. It becomes very bursty and there are whole periods of
> seconds where no data is sent from openssl even though it's 17KB TLS buffer
> is full and pings, for example, can be sent and received normally.
> 
> There appears to be some relation to the size of this buffer and the
> minimum achievable throughput we can get.. Unless my maths is off; 140 Kbps
> would give about 17KB/s throughput.. Coincidence?

Do you send packets to OpenSSL in blocks of 17 KB?  Is that
blocking or non-blocking?


Kurt


From mebeyn at gmail.com  Fri May 15 20:33:29 2015
From: mebeyn at gmail.com (Martin Beynon)
Date: Fri, 15 May 2015 21:33:29 +0100
Subject: [openssl-users] OpenSSL Behaviour under low bandwidth
In-Reply-To: <20150515202141.GA11292@roeckx.be>
References: <CADpW=+3XX_U-z=kwin8OQh1T98CuheOMh=VNerrzgKLvxTPx3Q@mail.gmail.com>
 <15c38d163f1f4469b34cd24229a50f04@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <CADpW=+1JM9VPax6Qnj5ZfYXPxLYE=qBrreUZuxQwVM7Tk+ye4w@mail.gmail.com>
 <dbcc024eef6645f4adaee77595931306@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <CADpW=+2H1ftkjiz7KCxbKZwfG1dc+hng-CJnYGk993APtPkPsg@mail.gmail.com>
 <20150515202141.GA11292@roeckx.be>
Message-ID: <CADpW=+0bWKvrCut8n2Qcf=9DB4BSF1BNvKig+Hx0OTtXOoL65w@mail.gmail.com>

Hi Kurt,

I send OpenSSL blocks of 512 bytes...but as fast as it will consume them
(since I want rid of the data as fast as possible). Blocking.

Martin

On 15 May 2015 at 21:21, Kurt Roeckx <kurt at roeckx.be> wrote:

> On Fri, May 15, 2015 at 12:44:03PM +0100, Martin Beynon wrote:
> >
> > That is right from 100Mbps down to 150 kpbs everything works as expected.
> > As I continue tuning down the bandwidth below 150kbps openssl starts to
> > stop sending data. It becomes very bursty and there are whole periods of
> > seconds where no data is sent from openssl even though it's 17KB TLS
> buffer
> > is full and pings, for example, can be sent and received normally.
> >
> > There appears to be some relation to the size of this buffer and the
> > minimum achievable throughput we can get.. Unless my maths is off; 140
> Kbps
> > would give about 17KB/s throughput.. Coincidence?
>
> Do you send packets to OpenSSL in blocks of 17 KB?  Is that
> blocking or non-blocking?
>
>
> Kurt
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150515/a503d7eb/attachment.html>

From BenBE at geshi.org  Sat May 16 23:29:46 2015
From: BenBE at geshi.org (Benny Baumann)
Date: Sun, 17 May 2015 01:29:46 +0200
Subject: [openssl-users] Working with large DH parameters
In-Reply-To: <20150504171355.GA14730@roeckx.be>
References: <mailman.396.1430745700.30392.openssl-users@openssl.org>
 <SNT152-W68ECAC0BB7C01D0A5F80BFBFD20@phx.gbl>
 <20150504171355.GA14730@roeckx.be>
Message-ID: <5557D2EA.30906@geshi.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

Am 04.05.2015 um 19:13 schrieb Kurt Roeckx:
> On Mon, May 04, 2015 at 09:00:21AM -0500, jack seth wrote:
>>> There is a limit of 10000: #define OPENSSL_DH_MAX_MODULUS_BITS
>>> 10000
I suggested replacing this compile time constant by a SSL_CTX option,
but due to the lack of configuring this without having to change all
programs there's no patch for this yet.

On a side-note: This limit also affects DSA keys, but not RSA.

Second note: RSA is unlimited when used as server cert, but limited at
4096 bit when providing client certs. This leads to quite annoying
situations with XMPP when the server needs to authenticate itself with
the server cert at the remote host:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747453

Suggested solution here (discussed off-list with Rich recently) is to
have this limit in the SSL_CTX and provide a way to configure the
default for new connections externally (such that the program can
still override this value, but an admin can configure this without the
program needing to care about this setting).

BUT: While I understand why this line isn't simply removed (patch
attached at the linked debian BTS issue, I'd prefer that OpenSSL did
in each situation allow you to set at least 256 bit security
equivalent values (16384 for RSA, DSA, DH, 521 for ECC). Yes, doing
16384 Bit DHE isn't fast, but 10k is just about 192 bit and for client
cert auth you only get 144 bit (y = 1.2x^.5 + 4.47x^[1/3] | x,y > 0 Bit).
>>> 
>>> I suggest you do not change this. It just gets slower without 
>>> adding security.
As shown above: It limits security at 144 Bit in certain situations ...

A feature you can't disable is a bug and thus should be fixed ;-)
>>> 
>>> I have no idea why it would freeze with something larger than 
>>> 13824.
I occationally use 13337 Bit DH with non-OpenSSL clients which takes
about 5-10 seconds for the handshake; OpenSSL-based clients barf as
noted above. Production usually uses 8k keys for both cert and kex.
>>> 
>>> I'm not sure what is logging the size, but it might be using 
>>> DH_size()*8 to log it. I don't think their currently is an API 
>>> that returns it in bits.
>>> 
>>> 
>>> Kurt
>> 
>> Thanks for the response.  Could you elaborate on why a larger
>> size doesn't add security?  For the sake of discussion, lets
>> ignore how slow it would be.  According to section 5.6.1 of
>> http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
>> you would need 15360+ bit to have security equal to AES256.   Is
>> NIST wrong here?  If so, why?
> 
> Everything in the chain would need to be providing 256 bit of 
> security, there are no ciphers that support more than 192 as far as
> I know.
The limitation here is with the MAC of the cipher suite as the largest
one specified for use in a cipher suite is SHA384 providing 192 bit.
Combined with ECDHE_ECDSA_WITH_AES256_SHA384 (CBC) you get 192 bit,
but won't like the CBC in it. With GCM you usually get 128 bit for the
MAC. Not sure for Chacha20/Poly1305: Chacha20 provides 256 bit
theoretically, but I'm not sure with Poly1305 (as far as I'm reading
the specs you get something around 64-128 bit, but not sure here).
> 
> Once you're at 128 or above it's also far more likekly that 
> something other than the crypto is the weakest part, like a human.
ACK.
> 
> 
> Kurt
> 
Regards,
BenBE.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJVV9LpAAoJEPHTXLno4S6tGe0QAKrZcQhWSCpFTi8hzW1GVPxC
fHzN2ndzCiVhOz0uPgM0i/m3qbHqpaCi98mmynH9YKhboyzg+Z1v1RkjInlQWx4m
mXUB254/mN3TIBtLvSF8LFltzjxLDXzvDMzJdQ7a8kDyfEPKf708KLZltbRTXkct
gN+MoaGvNaa1HiSo0AVQ/zmRy8xCyTToeGZZICM7i5DEJYzylen3tUImGiuNiE8q
NwtJRJ/tE/6O/Rj9ULO/R7Q/hqdq9yb5TPXMI2tGS816zu3tWehtIhollxxXsRGN
pjqvCELpKTrD5GmUt+KxDeyf4/GEMZKDaZ0EhDN2hlxZTEH1Mzl6lM5lU5g9+pyO
tt858/isCz5KH8iiOGy3wr86onjZdAGBfpg/Pp44aiYH2C1j35XSBzsrFnDCcOyy
kMDuXTYbW+PcLVqG6qb2cYyidsdCvbf3vLQ8aCoZP4P9Udr/fiYzvlJMbZudoTQ4
CNdrWqjZyIh/o3TeIJv1bojDRjIUuOi5zIPF2MPaveoFAyr3rdaT0Va2XK49ayka
Z7oU+vzTZXlv6TXEOqBw0YAWiEN+I4oKwmuasCnvj6QPQfenL3lC0rIgqGyEWrkT
kSHVrwKNKvQWDiN0if0v+FnQ0yrTle8SN9KCvrOXI2a4+eo5Wslfm0X/i1+3GXaN
PysMd2ipmAXriAlvAVTg
=r1dk
-----END PGP SIGNATURE-----

From noloader at gmail.com  Sat May 16 23:43:51 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 16 May 2015 19:43:51 -0400
Subject: [openssl-users] Working with large DH parameters
In-Reply-To: <5557D2EA.30906@geshi.org>
References: <mailman.396.1430745700.30392.openssl-users@openssl.org>
 <SNT152-W68ECAC0BB7C01D0A5F80BFBFD20@phx.gbl>
 <20150504171355.GA14730@roeckx.be> <5557D2EA.30906@geshi.org>
Message-ID: <CAH8yC8kU6SGHEbeOxp69anuG_cOXSkYXf_dyxJ247oy2cWv+Cw@mail.gmail.com>

On Sat, May 16, 2015 at 7:29 PM, Benny Baumann <BenBE at geshi.org> wrote:
>>>> There is a limit of 10000: #define OPENSSL_DH_MAX_MODULUS_BITS
>>>> 10000
> I suggested replacing this compile time constant by a SSL_CTX option,
> but due to the lack of configuring this without having to change all
> programs there's no patch for this yet...
>
A related issue is there are no more bits available in the options.
SSL_OP_SAFARI_ECDHE_ECDSA_BUG re-purposed an exiting bit.

Jeff

From randescr at gmail.com  Tue May 19 11:54:57 2015
From: randescr at gmail.com (Weichen Lin)
Date: Tue, 19 May 2015 19:54:57 +0800
Subject: [openssl-users] incorrect name of cipher suite
Message-ID: <CAMB-dJChR77z7PQHHS2PRz3+oDKy8ek5NxGovYxc8HW4VhMGVw@mail.gmail.com>

according https://www.openssl.org/docs/apps/ciphers.html
the name of TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is DHE-DSS-DES-CBC3-SHA
but I found it's not working, and finally success with EDH-DSS-DES-CBC3-SHA

I think it's typo on document, where can I report this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150519/d49de442/attachment.html>

From matt at openssl.org  Tue May 19 12:12:39 2015
From: matt at openssl.org (Matt Caswell)
Date: Tue, 19 May 2015 13:12:39 +0100
Subject: [openssl-users] incorrect name of cipher suite
In-Reply-To: <CAMB-dJChR77z7PQHHS2PRz3+oDKy8ek5NxGovYxc8HW4VhMGVw@mail.gmail.com>
References: <CAMB-dJChR77z7PQHHS2PRz3+oDKy8ek5NxGovYxc8HW4VhMGVw@mail.gmail.com>
Message-ID: <555B28B7.1090605@openssl.org>



On 19/05/15 12:54, Weichen Lin wrote:
> according https://www.openssl.org/docs/apps/ciphers.html
> the name of TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is DHE-DSS-DES-CBC3-SHA
> but I found it's not working, and finally success with EDH-DSS-DES-CBC3-SHA
> 
> I think it's typo on document, where can I report this?

It isn't a typo - the docs are correct.

DHE is the name that is commonly used practically everywhere for
ephemeral Diffie-Hellman. For historical reasons however within OpenSSL
it used to be called EDH. Starting from OpenSSL 1.0.2 both forms are
available, but the we refer to the standard DHE name in the docs.

Older versions of OpenSSL (before 1.0.2) still use EDH. The
documentation that accompanies those older versions also uses that form.

Currently we only make one version of the documentation available on the
website, i.e. the documentation for the current development version
1.1.0 (perhaps more useful would be 1.0.2 but that's a different
discussion). The docs are correct for that version.

For future referene though, the way to report defects (code or
documentation) is to send an email describing the problem to rt at openssl.org.

Matt


From randescr at gmail.com  Tue May 19 12:28:36 2015
From: randescr at gmail.com (Weichen Lin)
Date: Tue, 19 May 2015 20:28:36 +0800
Subject: [openssl-users] incorrect name of cipher suite
In-Reply-To: <555B28B7.1090605@openssl.org>
References: <CAMB-dJChR77z7PQHHS2PRz3+oDKy8ek5NxGovYxc8HW4VhMGVw@mail.gmail.com>
 <555B28B7.1090605@openssl.org>
Message-ID: <CAMB-dJA4tDJRo5vt-divqRSz8ecGsGhaq_KLtPFct2QVos_-Yw@mail.gmail.com>

Thank you, its very clearly
2015?5?19? ??8:13? "Matt Caswell" <matt at openssl.org>???

>
>
> On 19/05/15 12:54, Weichen Lin wrote:
> > according https://www.openssl.org/docs/apps/ciphers.html
> > the name of TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is DHE-DSS-DES-CBC3-SHA
> > but I found it's not working, and finally success with
> EDH-DSS-DES-CBC3-SHA
> >
> > I think it's typo on document, where can I report this?
>
> It isn't a typo - the docs are correct.
>
> DHE is the name that is commonly used practically everywhere for
> ephemeral Diffie-Hellman. For historical reasons however within OpenSSL
> it used to be called EDH. Starting from OpenSSL 1.0.2 both forms are
> available, but the we refer to the standard DHE name in the docs.
>
> Older versions of OpenSSL (before 1.0.2) still use EDH. The
> documentation that accompanies those older versions also uses that form.
>
> Currently we only make one version of the documentation available on the
> website, i.e. the documentation for the current development version
> 1.1.0 (perhaps more useful would be 1.0.2 but that's a different
> discussion). The docs are correct for that version.
>
> For future referene though, the way to report defects (code or
> documentation) is to send an email describing the problem to
> rt at openssl.org.
>
> Matt
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150519/ffe826a0/attachment-0001.html>

From m.vinicius at samsung.com  Tue May 19 19:56:31 2015
From: m.vinicius at samsung.com (Marcus Vinicius do Nascimento)
Date: Tue, 19 May 2015 16:56:31 -0300
Subject: [openssl-users] AES-128-CFB1 encrypt
Message-ID: <008001d0926d$e8c48c30$ba4da490$@samsung.com>

Hello,

 

I'm trying to use the CFB1 mode for AES-128.

However I'm having a bit of trouble interpreting the encrypt output.

 

I believe the EVP_EnvryptUpdate should get the data length in BITS (other
algorithms it should use in bytes). Is it correct?

How can I interpret the output correctly?

 

I got my testing data from the FIPS140 test vectors.

 

Here is a quick code snippet to illustrate it:

 

#include <openssl/evp.h>

#include <string.h>

 

int main() {

                unsigned char outbuf[1024];

                int outlen, tmplen;

 

                // From FIPS 140 test vectors (CFB1MCT128.rsp):

                //   COUNT = 0

                //   KEY = 6f219ca589944101d9b8d1997ec7f384

                //   IV = 00179d5c1f0436af09de22c09825b02d

                //   PLAINTEXT = 0

                //   CIPHERTEXT = 0

                unsigned char key[] = {0x6f, 0x21, 0x9c, 0xa5, 0x89, 0x94,
0x41, 0x01, 0xd9, 0xb8, 0xd1, 0x99, 0x7e, 0xc7, 0xf3, 0x84};

                unsigned char iv[] = {0x00, 0x17, 0x9d, 0x5c, 0x1f, 0x04,
0x36, 0xaf, 0x09, 0xde, 0x22, 0xc0, 0x98, 0x25, 0xb0, 0x2d};

                unsigned char intext[] = {0x00};

 

                EVP_CIPHER_CTX ctx;

                EVP_CIPHER_CTX_init(&ctx);

                EVP_EncryptInit_ex(&ctx, EVP_aes_128_cfb1(), NULL, key, iv);

 

                // EVP_EnvryptUpdate expects the number of bits or bytes in
CFB1 mode?

                int datalen = 1; 

 

                if (!EVP_EncryptUpdate(&ctx, outbuf, &outlen, intext,
datalen)) return 1;

                if (!EVP_EncryptFinal_ex(&ctx, outbuf + outlen, &tmplen))
return 1;

                outlen += tmplen;

                EVP_CIPHER_CTX_cleanup(&ctx);

 

                for (int ii = 0; ii < outlen; ++ii) printf("%02x",
outbut[ii]);

                printf("\n");

 

                // outbuf should contain CIPHERTEXT. However, it contains
one single byte: 0x47 (71 decimal).

 

                return 0;

}

 

Thanks very much.

 

Best,

Marcus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150519/85e78f02/attachment.html>

From ben at an3k.de  Wed May 20 09:39:48 2015
From: ben at an3k.de (Ben Humpert)
Date: Wed, 20 May 2015 11:39:48 +0200
Subject: [openssl-users] Vulnerability >> logjam << downgrades TLS
	connections to 512 Bit
Message-ID: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>

Technical report: https://weakdh.org/imperfect-forward-secrecy.pdf

Check your browser (currently all are affected) at https://weakdh.org/

Check your Server at https://weakdh.org/sysadmin.html

Deploying Guide: https://weakdh.org/sysadmin.html

From secinterlocutor at gmail.com  Wed May 20 10:05:03 2015
From: secinterlocutor at gmail.com (SecInterlocutor)
Date: Wed, 20 May 2015 11:05:03 +0100
Subject: [openssl-users] Fwd: X9.31 RSA key generation for FIPS validation
	(180-4)
In-Reply-To: <CAPU23zOAPCcVT8aW5i=cgzwxeTzAA+oQfk+Z-dm=gbkVRUtw_w@mail.gmail.com>
References: <CAPU23zMY4i9uAbnU3SuzrfFr0YP0oudQMixJkrAKNCOaRY0QCw@mail.gmail.com>
 <CAPU23zOAPCcVT8aW5i=cgzwxeTzAA+oQfk+Z-dm=gbkVRUtw_w@mail.gmail.com>
Message-ID: <CAPU23zNp=9uaAznzvAHyX113kpcUvHcz5OHfNfHqTLPG2g2yMQ@mail.gmail.com>

Hello again,

I am resending this email in case it's been forgotten. Is there anyone who
can help me at all?
If more information is needed, please let me know.

Many thanks.

---------- Forwarded message ----------
From: SecInterlocutor <secinterlocutor at gmail.com>
Date: Fri, May 15, 2015 at 9:44 AM
Subject: Fwd: X9.31 RSA key generation for FIPS validation (180-4)
To: openssl-users at openssl.org


Hello,


Our product was FIPS-certified a few years ago. We are now about to start
the re-certification process.


The test for RSA X9.31 key generation have somewhat changed, or so it looks
like to me anyway.


A few years ago, we received test vectors with the following parameters:
modulus size, e, xp1, xp2, Xp, xq1, xq2, Xq.

The response we provided included the previous parameters and these
generated values: p, q, n, d.


We used  FIPS_rsa_x931_derive_ex()  to generate the values.

I believe this function implements section B.3.6: Generation of Probable
Primes with Conditions Based on Auxiliary Probable Primes. Prime method:
Primes p1, p2, q1,q2, p and q shall all be probable primes.

Is my assumption correct?


If so, we?d like to minimise effort and reuse our test sw for the new tests
in http://csrc.nist.gov/groups/STM/cavp/documents/dss2/rsa2vs.pdf.


I?m looking at section 6.2.1 where the parameters are: modulus size, e,
N=25 (number of iterations). It seems to me that we have to send a response
with all of the other parameters: xp1, xp2, Xp, xq1, xq2, Xq, p, q, n, d.

xp1, xp2, Xp, xq1, xq2, Xq are random numbers, some of them have to be odd.


Which function(s) do you suggest to use to generate them?

Or can I just use FIPS_rsa_x931_generate_key_ex() ? Is this used with a
fixed exponent? Does it also implement section B.3.6?


We also have to indicate to NIST the type of Probabilistic Primality Test
the (specific) OpenSSL functions use:

a)      Table C.2. Minimum number of rounds of M-R testing when generating
primes

b)      Table C.3. Minimum number of rounds of M-R testing when generating
primes using an error probability of 2^?100


Which one(s) does OpenSSL implement? If both, how is that chosen?





Many thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150520/7c78d4c3/attachment.html>

From scott_n at xypro.com  Wed May 20 15:47:33 2015
From: scott_n at xypro.com (Scott Neugroschl)
Date: Wed, 20 May 2015 15:47:33 +0000
Subject: [openssl-users] Vulnerability >> logjam << downgrades
	TLS	connections to 512 Bit
In-Reply-To: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
References: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
Message-ID: <D358E5B1511A314F8160ADC6F375498706A0CF5A@XYSVEX02.XYPRO-23.LOCAL>

Is OpenSSL vulnerable to Logjam?



From kurt at roeckx.be  Wed May 20 17:17:46 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 20 May 2015 19:17:46 +0200
Subject: [openssl-users] Vulnerability >> logjam << downgrades TLS
 connections to 512 Bit
In-Reply-To: <D358E5B1511A314F8160ADC6F375498706A0CF5A@XYSVEX02.XYPRO-23.LOCAL>
References: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F375498706A0CF5A@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <20150520171745.GA13887@roeckx.be>

On Wed, May 20, 2015 at 03:47:33PM +0000, Scott Neugroschl wrote:
> Is OpenSSL vulnerable to Logjam?

See
http://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/


Kurt


From scott_n at xypro.com  Wed May 20 20:29:12 2015
From: scott_n at xypro.com (Scott Neugroschl)
Date: Wed, 20 May 2015 20:29:12 +0000
Subject: [openssl-users] Vulnerability >> logjam << downgrades TLS
 connections to 512 Bit
In-Reply-To: <20150520171745.GA13887@roeckx.be>
References: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F375498706A0CF5A@XYSVEX02.XYPRO-23.LOCAL>
 <20150520171745.GA13887@roeckx.be>
Message-ID: <D358E5B1511A314F8160ADC6F375498706A0CFFE@XYSVEX02.XYPRO-23.LOCAL>

On Wednesday, May 20, 2015 10:18 AM, Kurt Roeckx wrote:
> On Wed, May 20, 2015 at 03:47:33PM +0000, Scott Neugroschl wrote:
>> Is OpenSSL vulnerable to Logjam?

> See
> http://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/

Thanks.

Scott


From noloader at gmail.com  Wed May 20 21:29:51 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 20 May 2015 17:29:51 -0400
Subject: [openssl-users] Vulnerability >> logjam << downgrades TLS
 connections to 512 Bit
In-Reply-To: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
References: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
Message-ID: <CAH8yC8kWPWoaRmUTh2D30rEehJDmK26kF1T-qYbKOnbmQZvirg@mail.gmail.com>

On Wed, May 20, 2015 at 5:39 AM, Ben Humpert <ben at an3k.de> wrote:
> Technical report: https://weakdh.org/imperfect-forward-secrecy.pdf
>
> Check your browser (currently all are affected) at https://weakdh.org/
>
> Check your Server at https://weakdh.org/sysadmin.html
>
> Deploying Guide: https://weakdh.org/sysadmin.html

Also see "Minimum size of DH",
http://rt.openssl.org/Ticket/Display.html?id=3120&user=guest&pass=guest.
The problem of the small DH group was reported years ago.

I can't help but feel it contributes to this observation from the paper:

    We find that 82% of vulnerable servers use a
    single 512-bit group, allowing us to compromise
    connections to 7% of Alexa Top Million HTTPS sites.

Jeff

From chris.hillsec at gmail.com  Thu May 21 01:45:36 2015
From: chris.hillsec at gmail.com (Chris Hill)
Date: Wed, 20 May 2015 21:45:36 -0400
Subject: [openssl-users] Question on logjam
Message-ID: <CALstPiP-FShy9+Af3gdnmUS0jqZiB2N-6M=GJD33+iVV=LH-8A@mail.gmail.com>

Folks, can you pls confirm that none of the below ciphers are affected by
this logjam bug? From my understanding, only ciphers containing DH or DHE
would be affected.

TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x62)
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_WITH_DES_CBC_SHA

The above are weak (e.g. vulnerable to freak), no argument there, but just
want to ensure these are not vulnerable to this newly published bug.

Thanks all!
Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150520/12135ff3/attachment.html>

From rhidalgo at indra.es  Thu May 21 13:54:47 2015
From: rhidalgo at indra.es (Hidalgo Eguiagaray, Rafael)
Date: Thu, 21 May 2015 15:54:47 +0200
Subject: [openssl-users] OS390 Make fail
Message-ID: <A9162E604233B146B0146C1321848185026F540244@MADARRMAILBOX01.indra.es>

I am trying to install openssl-1.0.2a  in zOS 1.3 .
Configure ran OK, but I am getting :
........
>>> Makefile: line 263: Defined macro BUILD_CMD=if [ -d "$$dir" ]; then  (      cd $$dir && echo "making $$target in $$dir..." &&  $(CLEARENV) && $(MAKE) -e $(BUILDENV) TOP=.. DIR=$$dir $$target  ) || exit 1;  fi
>>> Makefile: line 264: Defined macro RECURSIVE_BUILD_CMD=for dir in $(DIRS); do $(BUILD_CMD); done
>>> Makefile: line 268: Defined macro BUILD_ONE_CMD=if expr " $(DIRS) " : ".* $$dir " >/dev/null 2>&1; then  $(BUILD_CMD);  fi
>>> Defined macro INCDEPTH=0
make: Error -- FSUM8229 Incomplete rule recipe group detected

I did untar with pax -rf openssl-1.0.2a.tar -ofrom=ISO8859-1,to=IBM-1047.

Any Ideas??







________________________________
Este correo electr?nico y, en su caso, cualquier fichero anexo al mismo, contiene informaci?n de car?cter confidencial exclusivamente dirigida a su destinatario o destinatarios. Si no es vd. el destinatario indicado, queda notificado que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n est? prohibida en virtud de la legislaci?n vigente. En el caso de haber recibido este correo electr?nico por error, se ruega notificar inmediatamente esta circunstancia mediante reenv?o a la direcci?n electr?nica del remitente.
Evite imprimir este mensaje si no es estrictamente necesario.

This email and any file attached to it (when applicable) contain(s) confidential information that is exclusively addressed to its recipient(s). If you are not the indicated recipient, you are informed that reading, using, disseminating and/or copying it without authorisation is forbidden in accordance with the legislation in effect. If you have received this email by mistake, please immediately notify the sender of the situation by resending it to their email address.
Avoid printing this message if it is not absolutely necessary.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150521/2c2677c7/attachment.html>

From jb-openssl at wisemo.com  Thu May 21 17:10:47 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 21 May 2015 19:10:47 +0200
Subject: [openssl-users] Vulnerability >> logjam << downgrades TLS
 connections to 512 Bit
In-Reply-To: <D358E5B1511A314F8160ADC6F375498706A0CFFE@XYSVEX02.XYPRO-23.LOCAL>
References: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F375498706A0CF5A@XYSVEX02.XYPRO-23.LOCAL>
 <20150520171745.GA13887@roeckx.be>
 <D358E5B1511A314F8160ADC6F375498706A0CFFE@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <555E1197.1090801@wisemo.com>

On 20/05/2015 22:29, Scott Neugroschl wrote:
> On Wednesday, May 20, 2015 10:18 AM, Kurt Roeckx wrote:
>> On Wed, May 20, 2015 at 03:47:33PM +0000, Scott Neugroschl wrote:
>>> Is OpenSSL vulnerable to Logjam?
>> See
>> http://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/

To supplement this, maybe change the server side code
that calls the DH group callback to never ask for less
than 1024 bits, even if the client appears to do so.
While you are at it, also use ClientHello details to
estimate if you should ask the application for 1024,
2048 or some other strength, such that JRE6 based and
other old clients can get 1024 bit DHE, while modern
clients can get 2048 bit DHE.
  For OpenSSL based servers, I suspect that to be the
most common path of attack.

As an additional change for 1.0.2c or later (no need to
delay the urgent fix), maybe adjust internal operations
to discourage use of hardcoded DH groups for TLS DH (but
NOT for generic DH-like operations such as openssl-based
implementations of SRP).  The change should be such that
it does not break software that actively changes the DH
groups outside the OpenSSL code.

i.e. Don't simply disable the functions that take DH
groups as input, but do devise some way to work around
the commonly used code pattern of calling openssl
dhparam at build time and then making all users of a
distribution use the resulting DH group.



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From noloader at gmail.com  Fri May 22 01:57:56 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 21 May 2015 21:57:56 -0400
Subject: [openssl-users] Vulnerability >> logjam << downgrades TLS
 connections to 512 Bit
In-Reply-To: <555E1197.1090801@wisemo.com>
References: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F375498706A0CF5A@XYSVEX02.XYPRO-23.LOCAL>
 <20150520171745.GA13887@roeckx.be>
 <D358E5B1511A314F8160ADC6F375498706A0CFFE@XYSVEX02.XYPRO-23.LOCAL>
 <555E1197.1090801@wisemo.com>
Message-ID: <CAH8yC8nN0avvuRPmMT--7mA-fLV6amgXiSz4NgVKzLcqgHafrg@mail.gmail.com>

> As an additional change for 1.0.2c or later (no need to
> delay the urgent fix), maybe adjust internal operations
> to discourage use of hardcoded DH groups for TLS DH (but
> NOT for generic DH-like operations such as openssl-based
> implementations of SRP).
That's going to be tough because standards groups like the TLS WG are
actively promoting fully specified, named parameters and curves.

See, for example, "Negotiated Finite Field Diffie-Hellman Ephemeral
Parameters for TLS",
https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09; and
the discussion of magic primes at "Re: [TLS] Another IRINA bug in
TLS", https://www.ietf.org/mail-archive/web/tls/current/msg16417.html.
(The thread is due to the recent attacks on DH).

Jeff

From jb-openssl at wisemo.com  Fri May 22 04:51:42 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 22 May 2015 06:51:42 +0200
Subject: [openssl-users] Vulnerability >> logjam << downgrades TLS
 connections to 512 Bit
In-Reply-To: <CAH8yC8nN0avvuRPmMT--7mA-fLV6amgXiSz4NgVKzLcqgHafrg@mail.gmail.com>
References: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F375498706A0CF5A@XYSVEX02.XYPRO-23.LOCAL>
 <20150520171745.GA13887@roeckx.be>
 <D358E5B1511A314F8160ADC6F375498706A0CFFE@XYSVEX02.XYPRO-23.LOCAL>
 <555E1197.1090801@wisemo.com>
 <CAH8yC8nN0avvuRPmMT--7mA-fLV6amgXiSz4NgVKzLcqgHafrg@mail.gmail.com>
Message-ID: <555EB5DE.8060909@wisemo.com>

On 22/05/2015 03:57, Jeffrey Walton wrote:
>> As an additional change for 1.0.2c or later (no need to
>> delay the urgent fix), maybe adjust internal operations
>> to discourage use of hardcoded DH groups for TLS DH (but
>> NOT for generic DH-like operations such as openssl-based
>> implementations of SRP).
> That's going to be tough because standards groups like the TLS WG are
> actively promoting fully specified, named parameters and curves.
>
> See, for example, "Negotiated Finite Field Diffie-Hellman Ephemeral
> Parameters for TLS",
> https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09; and
> the discussion of magic primes at "Re: [TLS] Another IRINA bug in
> TLS", https://www.ietf.org/mail-archive/web/tls/current/msg16417.html.
> (The thread is due to the recent attacks on DH).
The latter thread contains posts from respected experts
asking not to use fixed parameters for DH, and a lot of
noise from experts promoting their pet algorithms, such
as ECDH (off topic for DH issues), specific ideas of
which groups are the safest (most promoting the
"(p-1)/2 also prime" variant, none acknowledging the
DSA-like X9.42 variant), or just asking if LogJam is at
all real.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From noloader at gmail.com  Fri May 22 05:18:24 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 22 May 2015 01:18:24 -0400
Subject: [openssl-users] Vulnerability >> logjam << downgrades TLS
 connections to 512 Bit
In-Reply-To: <555EB5DE.8060909@wisemo.com>
References: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F375498706A0CF5A@XYSVEX02.XYPRO-23.LOCAL>
 <20150520171745.GA13887@roeckx.be>
 <D358E5B1511A314F8160ADC6F375498706A0CFFE@XYSVEX02.XYPRO-23.LOCAL>
 <555E1197.1090801@wisemo.com>
 <CAH8yC8nN0avvuRPmMT--7mA-fLV6amgXiSz4NgVKzLcqgHafrg@mail.gmail.com>
 <555EB5DE.8060909@wisemo.com>
Message-ID: <CAH8yC8n3Gv1cHwp6=yMCXvvhqKDc3dX+Fy6hZ+MPc5DJ7z1xpQ@mail.gmail.com>

On Fri, May 22, 2015 at 12:51 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> On 22/05/2015 03:57, Jeffrey Walton wrote:
>>>
>>> As an additional change for 1.0.2c or later (no need to
>>> delay the urgent fix), maybe adjust internal operations
>>> to discourage use of hardcoded DH groups for TLS DH (but
>>> NOT for generic DH-like operations such as openssl-based
>>> implementations of SRP).
>>
>> That's going to be tough because standards groups like the TLS WG are
>> actively promoting fully specified, named parameters and curves.
>>
>> See, for example, "Negotiated Finite Field Diffie-Hellman Ephemeral
>> Parameters for TLS",
>> https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09; and
>> the discussion of magic primes at "Re: [TLS] Another IRINA bug in
>> TLS", https://www.ietf.org/mail-archive/web/tls/current/msg16417.html.
>> (The thread is due to the recent attacks on DH).
>
> The latter thread contains posts from respected experts
> asking not to use fixed parameters for DH...

Well, I'm not sure how much more respected one can get than Daniel
Kahn Gillmore, Stephen Farrell, Eric Recorla; or have better
credentials than practicing cryptographers.

How high is your bar :)

From jb-openssl at wisemo.com  Fri May 22 05:55:45 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 22 May 2015 07:55:45 +0200
Subject: [openssl-users] Vulnerability >> logjam << downgrades TLS
 connections to 512 Bit
In-Reply-To: <CAH8yC8n3Gv1cHwp6=yMCXvvhqKDc3dX+Fy6hZ+MPc5DJ7z1xpQ@mail.gmail.com>
References: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F375498706A0CF5A@XYSVEX02.XYPRO-23.LOCAL>
 <20150520171745.GA13887@roeckx.be>
 <D358E5B1511A314F8160ADC6F375498706A0CFFE@XYSVEX02.XYPRO-23.LOCAL>
 <555E1197.1090801@wisemo.com>
 <CAH8yC8nN0avvuRPmMT--7mA-fLV6amgXiSz4NgVKzLcqgHafrg@mail.gmail.com>
 <555EB5DE.8060909@wisemo.com>
 <CAH8yC8n3Gv1cHwp6=yMCXvvhqKDc3dX+Fy6hZ+MPc5DJ7z1xpQ@mail.gmail.com>
Message-ID: <555EC4E1.2050601@wisemo.com>

On 22/05/2015 07:18, Jeffrey Walton wrote:
> On Fri, May 22, 2015 at 12:51 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote:
>> On 22/05/2015 03:57, Jeffrey Walton wrote:
>>>> As an additional change for 1.0.2c or later (no need to
>>>> delay the urgent fix), maybe adjust internal operations
>>>> to discourage use of hardcoded DH groups for TLS DH (but
>>>> NOT for generic DH-like operations such as openssl-based
>>>> implementations of SRP).
>>> That's going to be tough because standards groups like the TLS WG are
>>> actively promoting fully specified, named parameters and curves.
>>>
>>> See, for example, "Negotiated Finite Field Diffie-Hellman Ephemeral
>>> Parameters for TLS",
>>> https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09; and
>>> the discussion of magic primes at "Re: [TLS] Another IRINA bug in
>>> TLS", https://www.ietf.org/mail-archive/web/tls/current/msg16417.html.
>>> (The thread is due to the recent attacks on DH).
>> The latter thread contains posts from respected experts
>> asking not to use fixed parameters for DH...
> Well, I'm not sure how much more respected one can get than Daniel
> Kahn Gillmore, Stephen Farrell, Eric Recorla; or have better
> credentials than practicing cryptographers.
>
> How high is your bar :)
Whom did I say were not highly respected cryptographers?

I read the thread as some of the highly respected experts
saying that the LogJam supplemental finding (some fixed
DH groups of once recommended size used by so many it
makes expensive attacks pay) shows why fixed DH groups
should not be mandatory, while other respected experts
talk about other subjects.

I saw posts from respected experts arguing how to shoehorn
non-fixed DH curves back into the drafts of how to use
fixed DH curves (rather than simply dropping that protocol
change for DH).

I saw posts from respected experts arguing if the cost of
client side primality checks of DH parameters would exceed
the cost of using a secure enough group size.

I saw no posts in that thread arguing why fixed DH groups
would be a good thing.

I saw no posts discussing if DH parameters signed by the
trusted server really need to be fully validated client
side, or if cheaper checks (range, length, correspondence
to seed etc.) would be good enough given better uses for
the CPU time.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From noloader at gmail.com  Fri May 22 06:30:23 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 22 May 2015 02:30:23 -0400
Subject: [openssl-users] Vulnerability >> logjam << downgrades TLS
 connections to 512 Bit
In-Reply-To: <555EC4E1.2050601@wisemo.com>
References: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F375498706A0CF5A@XYSVEX02.XYPRO-23.LOCAL>
 <20150520171745.GA13887@roeckx.be>
 <D358E5B1511A314F8160ADC6F375498706A0CFFE@XYSVEX02.XYPRO-23.LOCAL>
 <555E1197.1090801@wisemo.com>
 <CAH8yC8nN0avvuRPmMT--7mA-fLV6amgXiSz4NgVKzLcqgHafrg@mail.gmail.com>
 <555EB5DE.8060909@wisemo.com>
 <CAH8yC8n3Gv1cHwp6=yMCXvvhqKDc3dX+Fy6hZ+MPc5DJ7z1xpQ@mail.gmail.com>
 <555EC4E1.2050601@wisemo.com>
Message-ID: <CAH8yC8=8B=nEis7=33YMHcX8QRxZb-SRFmiK_8f_74w1ps=VvQ@mail.gmail.com>

On Fri, May 22, 2015 at 1:55 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> On 22/05/2015 07:18, Jeffrey Walton wrote:
>>
>> On Fri, May 22, 2015 at 12:51 AM, Jakob Bohm <jb-openssl at wisemo.com>
>> wrote:
>>>
>>> On 22/05/2015 03:57, Jeffrey Walton wrote:
>>>>>
>>>>> As an additional change for 1.0.2c or later (no need to
>>>>> delay the urgent fix), maybe adjust internal operations
>>>>> to discourage use of hardcoded DH groups for TLS DH (but
>>>>> NOT for generic DH-like operations such as openssl-based
>>>>> implementations of SRP).
>>>>
>>>> That's going to be tough because standards groups like the TLS WG are
>>>> actively promoting fully specified, named parameters and curves.
>>>>
>>>> See, for example, "Negotiated Finite Field Diffie-Hellman Ephemeral
>>>> Parameters for TLS",
>>>> https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09; and
>>>> the discussion of magic primes at "Re: [TLS] Another IRINA bug in
>>>> TLS", https://www.ietf.org/mail-archive/web/tls/current/msg16417.html.
>>>> (The thread is due to the recent attacks on DH).
>>>
>>> The latter thread contains posts from respected experts
>>> asking not to use fixed parameters for DH...
>>
>> Well, I'm not sure how much more respected one can get than Daniel
>> Kahn Gillmore, Stephen Farrell, Eric Recorla; or have better
>> credentials than practicing cryptographers.
>>
>> How high is your bar :)
>
> Whom did I say were not highly respected cryptographers?
> ...
> I saw no posts in that thread arguing why fixed DH groups
> would be a good thing.

That's Gillmor's
https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09. Its a
set of fixed DH groups called out by name for use in TLS.

Or are you talking about server certificates with fixed DH parameters?

Jeff

From jb-openssl at wisemo.com  Fri May 22 10:09:06 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 22 May 2015 12:09:06 +0200
Subject: [openssl-users] Vulnerability >> logjam << downgrades TLS
 connections to 512 Bit
In-Reply-To: <CAH8yC8=8B=nEis7=33YMHcX8QRxZb-SRFmiK_8f_74w1ps=VvQ@mail.gmail.com>
References: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F375498706A0CF5A@XYSVEX02.XYPRO-23.LOCAL>
 <20150520171745.GA13887@roeckx.be>
 <D358E5B1511A314F8160ADC6F375498706A0CFFE@XYSVEX02.XYPRO-23.LOCAL>
 <555E1197.1090801@wisemo.com>
 <CAH8yC8nN0avvuRPmMT--7mA-fLV6amgXiSz4NgVKzLcqgHafrg@mail.gmail.com>
 <555EB5DE.8060909@wisemo.com>
 <CAH8yC8n3Gv1cHwp6=yMCXvvhqKDc3dX+Fy6hZ+MPc5DJ7z1xpQ@mail.gmail.com>
 <555EC4E1.2050601@wisemo.com>
 <CAH8yC8=8B=nEis7=33YMHcX8QRxZb-SRFmiK_8f_74w1ps=VvQ@mail.gmail.com>
Message-ID: <555F0042.8050105@wisemo.com>

On 22/05/2015 08:30, Jeffrey Walton wrote:
> On Fri, May 22, 2015 at 1:55 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote:
>> On 22/05/2015 07:18, Jeffrey Walton wrote:
>>> On Fri, May 22, 2015 at 12:51 AM, Jakob Bohm <jb-openssl at wisemo.com>
>>> wrote:
>>>> On 22/05/2015 03:57, Jeffrey Walton wrote:
>>>>>> As an additional change for 1.0.2c or later (no need to
>>>>>> delay the urgent fix), maybe adjust internal operations
>>>>>> to discourage use of hardcoded DH groups for TLS DH (but
>>>>>> NOT for generic DH-like operations such as openssl-based
>>>>>> implementations of SRP).
>>>>> That's going to be tough because standards groups like the TLS WG are
>>>>> actively promoting fully specified, named parameters and curves.
>>>>>
>>>>> See, for example, "Negotiated Finite Field Diffie-Hellman Ephemeral
>>>>> Parameters for TLS",
>>>>> https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09; and
>>>>> the discussion of magic primes at "Re: [TLS] Another IRINA bug in
>>>>> TLS", https://www.ietf.org/mail-archive/web/tls/current/msg16417.html.
>>>>> (The thread is due to the recent attacks on DH).
>>>> The latter thread contains posts from respected experts
>>>> asking not to use fixed parameters for DH...
>>> Well, I'm not sure how much more respected one can get than Daniel
>>> Kahn Gillmore, Stephen Farrell, Eric Recorla; or have better
>>> credentials than practicing cryptographers.
>>>
>>> How high is your bar :)
>> Whom did I say were not highly respected cryptographers?
>> ...
>> I saw no posts in that thread arguing why fixed DH groups
>> would be a good thing.
> That's Gillmor's
> https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09. Its a
> set of fixed DH groups called out by name for use in TLS.
>
> Or are you talking about server certificates with fixed DH parameters?
I was talking about the current post-logjam discussion
thread, not the pre-logjam draft.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From naynjain at in.ibm.com  Fri May 22 10:11:09 2015
From: naynjain at in.ibm.com (Nayna Jain)
Date: Fri, 22 May 2015 15:41:09 +0530
Subject: [openssl-users] What key length is used for DHE by default ?
Message-ID: <OFF9E983C4.FCAF38D3-ON65257E4D.0037A5D9-65257E4D.0037F2EC@in.ibm.com>


Hi,

With the latest logjam attack, as I was trying to verify if my server
(lighttpd) accepts DHE_xxx  ciphers,  I saw that it accepted and I didn't
do any configuration setting done for DH parameters explicitly.

But I couldn't verify what is the key length did it use by default
512/1024/2048 ?

Eg. the one it negotiated was DHE-RSA-AES128-SHA256  and for TLSv1.2
protocol ?

Will the key length be different for different protocols like
SSLv3/TLSv1.0/TLSv1.1/TLSv1.2?  If yes , then what for each of them.


Thanks & Regards,
Nayna Jain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150522/58a5f8ff/attachment.html>

From matt at openssl.org  Fri May 22 10:17:21 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 22 May 2015 11:17:21 +0100
Subject: [openssl-users] What key length is used for DHE by default ?
In-Reply-To: <OFF9E983C4.FCAF38D3-ON65257E4D.0037A5D9-65257E4D.0037F2EC@in.ibm.com>
References: <OFF9E983C4.FCAF38D3-ON65257E4D.0037A5D9-65257E4D.0037F2EC@in.ibm.com>
Message-ID: <555F0231.2090607@openssl.org>



On 22/05/15 11:11, Nayna Jain wrote:
> Hi,
> 
> With the latest logjam attack, as I was trying to verify if my server
> (lighttpd) accepts DHE_xxx  ciphers,  I saw that it accepted and I
> didn't do any configuration setting done for DH parameters explicitly.
> 
> But I couldn't verify what is the key length did it use by default
> 512/1024/2048 ?
> 
> Eg. the one it negotiated was DHE-RSA-AES128-SHA256  and for TLSv1.2
> protocol ?
> 
> Will the key length be different for different protocols like
> SSLv3/TLSv1.0/TLSv1.1/TLSv1.2?  If yes , then what for each of them.

How that is configured depends on the application that is using OpenSSL.
A quick google search throws up this:

http://redmine.lighttpd.net/projects/1/wiki/docs_ssl

'Diffie-Hellman and Elliptic-Curve Diffie-Hellman parameters
Diffie-Hellman and Elliptic-Curve Diffie-Hellman key agreement protocols
will be supported in lighttpd 1.4.29. By default, Diffie-Hellman and
Elliptic-Curve Diffie-Hellman key agreement protocols use, respectively,
the 1024-bit MODP Group with 160-bit prime order subgroup from RFC 5114
and "prime256v1" (also known as "secp256r1") elliptic curve from RFC
4492. The Elliptic-Curve Diffie-Hellman key agreement protocol is
supported in OpenSSL from 0.9.8f version onwards. For maximum
interoperability, OpenSSL only supports the "named curves" from RFC 4492.

Using the ssl.dh-file and ssl.ec-curve configuration variables, you can
define your own set of Diffie-Hellman domain parameters. For example:

ssl.dh-file = "/etc/lighttpd/ssl/dh2048.pem"
ssl.ec-curve = "secp384r1"'


Matt

From Walter.H at mathemainzel.info  Fri May 22 09:20:06 2015
From: Walter.H at mathemainzel.info (Walter H.)
Date: Fri, 22 May 2015 11:20:06 +0200
Subject: [openssl-users] DH parameters [was: Vulnerability >> logjam <<
 downgrades TLS connections to 512 Bit]
In-Reply-To: <CAH8yC8=8B=nEis7=33YMHcX8QRxZb-SRFmiK_8f_74w1ps=VvQ@mail.gmail.com>
References: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F375498706A0CF5A@XYSVEX02.XYPRO-23.LOCAL>
 <20150520171745.GA13887@roeckx.be>
 <D358E5B1511A314F8160ADC6F375498706A0CFFE@XYSVEX02.XYPRO-23.LOCAL>
 <555E1197.1090801@wisemo.com>
 <CAH8yC8nN0avvuRPmMT--7mA-fLV6amgXiSz4NgVKzLcqgHafrg@mail.gmail.com>
 <555EB5DE.8060909@wisemo.com>
 <CAH8yC8n3Gv1cHwp6=yMCXvvhqKDc3dX+Fy6hZ+MPc5DJ7z1xpQ@mail.gmail.com>
 <555EC4E1.2050601@wisemo.com>
 <CAH8yC8=8B=nEis7=33YMHcX8QRxZb-SRFmiK_8f_74w1ps=VvQ@mail.gmail.com>
Message-ID: <555EF4C6.9090004@mathemainzel.info>

Hello

On 22.05.2015 08:30, Jeffrey Walton wrote:
> Or are you talking about server certificates with fixed DH parameters?
can you please tell me more about this?

how do I have to create the certificate request?
(using debian 7 latest updates installed:   'apt-get update & apt-get 
upgrade' has nothing to do)

Thanks,
Walter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5971 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150522/448255f7/attachment-0001.bin>

From pbellino at mrv.com  Fri May 22 12:46:23 2015
From: pbellino at mrv.com (Philip Bellino)
Date: Fri, 22 May 2015 12:46:23 +0000
Subject: [openssl-users] FIPs validation questions
Message-ID: <AM3PR03MB08242CF7C9AB3849B7CDFF15C3C00@AM3PR03MB0824.eurprd03.prod.outlook.com>

Hello,

We use OpenSSL-1.0.2a and FIPS 2.0.9 and have questions we need to answer in conjunction with the FIPS validation

process.

One question is whether SHA1 accepts NULL (zero-length) messages?  I couldn't find anything on the OpenSSL

wiki so I thought I'd ask here.

Also, another questions is whether the AES CTR counter source is internal or external?



Any information would be appreciated.
Thanks,
Phil



MRV Communications is a global supplier of packet and optical solutions that power the world's largest networks. Our products combine innovative hardware with intelligent software to make networks smarter, faster and more efficient.



The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150522/75b45bfb/attachment.html>

From noloader at gmail.com  Fri May 22 17:37:12 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 22 May 2015 13:37:12 -0400
Subject: [openssl-users] DH parameters [was: Vulnerability >> logjam <<
 downgrades TLS connections to 512 Bit]
In-Reply-To: <555EF4C6.9090004@mathemainzel.info>
References: <CAGbjqfF6eKeijEVk7mjv9_zdg3OOppH=gVn9eOa6Ov9MswBkfg@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F375498706A0CF5A@XYSVEX02.XYPRO-23.LOCAL>
 <20150520171745.GA13887@roeckx.be>
 <D358E5B1511A314F8160ADC6F375498706A0CFFE@XYSVEX02.XYPRO-23.LOCAL>
 <555E1197.1090801@wisemo.com>
 <CAH8yC8nN0avvuRPmMT--7mA-fLV6amgXiSz4NgVKzLcqgHafrg@mail.gmail.com>
 <555EB5DE.8060909@wisemo.com>
 <CAH8yC8n3Gv1cHwp6=yMCXvvhqKDc3dX+Fy6hZ+MPc5DJ7z1xpQ@mail.gmail.com>
 <555EC4E1.2050601@wisemo.com>
 <CAH8yC8=8B=nEis7=33YMHcX8QRxZb-SRFmiK_8f_74w1ps=VvQ@mail.gmail.com>
 <555EF4C6.9090004@mathemainzel.info>
Message-ID: <CAH8yC8nFGi2+u38ADDtgMU3NtoiFMJVtPOC09PH7LwEDUxDKKw@mail.gmail.com>

On Fri, May 22, 2015 at 5:20 AM, Walter H. <Walter.H at mathemainzel.info> wrote:
> Hello
>
> On 22.05.2015 08:30, Jeffrey Walton wrote:
>>
>> Or are you talking about server certificates with fixed DH parameters?
>
> can you please tell me more about this?

They have a DH group called out by parameters (an not by name as in
the Gillmor draft). They also use a static key "A = g ^ a". The "A" is
the public key, and the public key is effectively fixed and presented
like an RSA key or a DSS key in the certificate.

They are being phased out or have been phased out. I don't use them,
so I don't really follow them.

Jeff

From noloader at gmail.com  Sun May 24 00:37:20 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 23 May 2015 20:37:20 -0400
Subject: [openssl-users] Expected behavior for verification when a
 subordinate in a chain is promoted to a self signed root?
Message-ID: <CAH8yC8=cVBLrbZmSGRXrj0LCu7WD4Y7qBBu-AmDaag+vJJUkmw@mail.gmail.com>

I have an odd situation, and I don't know what the expect behavior is.
It was experienced when attempting to validate a path for
usercenter.checkpoint.com.

If I use s_client and `-showcerts`, I get a chain that terminates in
an old Root called "Class 3 Public Primary Certification Authority".
Its old and deprecated, so I tried to root or anchor trust in the next
lower intermediate.

The next lower intermediate is called ''VeriSign Class 3 Public
Primary Certification Authority - G5". Its sent in the chain, *but* I
downloaded it out of band from Symantec's site.

Then I ran s_client again with the downloaded version of the
certifcate (see below). It results in "Verify return code: 20 (unable
to get local issuer certificate)".

After some digging, it looks like ''VeriSign Class 3 Public Primary
Certification Authority - G5" are two different certificates with two
different serial numbers. One is sent in the chain and one is
available for download. What changed is the G5 certificate was
promoted to a self signed root due to the former CA deprecation. But
it reused the Disntiguished Name and public key, so Authority Key
Identifier and Subject Key Identifier stayed the same.

What is the expected behavior here? Should it fail or should it succeed?

Does the chain override the root or anchor? I think RFC 4518 treats
them as different certificates, so it just looks like the old G5
certificate is suprious and unnecessary. (... but confusing due to the
DN/SKI reuse)).

Jeff

**********

$ openssl s_client -connect usercenter.checkpoint.com:443 -tls1 \
    -servername usercenter.checkpoint.com \
    -CAfile VeriSign-Class-3-Public-Primary-Certification-Authority-G5.pem
...
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: C58DA6CCEDD45F1BBA0FEE06C8A83B999E94105156DBF68365E98FD9E930668E
    Session-ID-ctx:
    Master-Key:
F725717020A58405B9B08366F46157F606F7B37CB4142B690F613F43C1073BB6E178A2D1FECB7A735D9359FDE3E2B6F0
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1432427549
    Timeout   : 7200 (sec)
    Verify return code: 20 (unable to get local issuer certificate)

From mancha1 at zoho.com  Sun May 24 03:33:39 2015
From: mancha1 at zoho.com (mancha)
Date: Sun, 24 May 2015 03:33:39 +0000
Subject: [openssl-users] What key length is used for DHE by default ?
In-Reply-To: <555F0231.2090607@openssl.org>
Message-ID: <20150524033339.GB2072@zoho.com>

On Fri, 22 May 2015 at 11:17:21AM +0100, Matt Caswell wrote:
> On 22/05/15 11:11, Nayna Jain wrote:
> > Hi,
> > 
> > With the latest logjam attack, as I was trying to verify if my
> > server (lighttpd) accepts DHE_xxx  ciphers,  I saw that it accepted
> > and I didn't do any configuration setting done for DH parameters
> > explicitly.
> > 
> > But I couldn't verify what is the key length did it use by default
> > 512/1024/2048 ?
> > 
> > Eg. the one it negotiated was DHE-RSA-AES128-SHA256  and for TLSv1.2
> > protocol ?
> > 
> > Will the key length be different for different protocols like
> > SSLv3/TLSv1.0/TLSv1.1/TLSv1.2?  If yes , then what for each of them.
> 
> How that is configured depends on the application that is using
> OpenSSL. A quick google search throws up this:
> 
> http://redmine.lighttpd.net/projects/1/wiki/docs_ssl
> 
> 'Diffie-Hellman and Elliptic-Curve Diffie-Hellman parameters
> Diffie-Hellman and Elliptic-Curve Diffie-Hellman key agreement
> protocols will be supported in lighttpd 1.4.29. By default,
> Diffie-Hellman and Elliptic-Curve Diffie-Hellman key agreement
> protocols use, respectively, the 1024-bit MODP Group with 160-bit
> prime order subgroup from RFC 5114 and "prime256v1" (also known as
> "secp256r1") elliptic curve from RFC 4492. The Elliptic-Curve
> Diffie-Hellman key agreement protocol is supported in OpenSSL from
> 0.9.8f version onwards. For maximum interoperability, OpenSSL only
> supports the "named curves" from RFC 4492.
> 
> Using the ssl.dh-file and ssl.ec-curve configuration variables, you
> can define your own set of Diffie-Hellman domain parameters. For
> example:
> 
> ssl.dh-file = "/etc/lighttpd/ssl/dh2048.pem"
> ssl.ec-curve = "secp384r1"'

OpenSSL users might like to know you can use s_client to diagnose a
server's Diffie-Hellman profile. Starting with OpenSSL 1.0.2 you can do:

$ openssl s_client -connect www.example.com:443 -cipher "EDH" | grep
"Server Temp Key"

If you're testing a server that uses a small (weak) DH group the above
command might output something like:

Server Temp Key: DH, 512 bits

Note: If you're on OpenSSL 1.0.1 you'll need to apply my back port to
have this functionality:

https://twitter.com/mancha140/status/602241770961907712

--mancha

P.S. That command also shows the elliptic curve name and bit size when
using ECDHE and the RSA modulus bit size when RSA is used for the
temporary key (as done by some export ciphers).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150524/2ce5a050/attachment.sig>

From matt at openssl.org  Sun May 24 13:41:20 2015
From: matt at openssl.org (Matt Caswell)
Date: Sun, 24 May 2015 14:41:20 +0100
Subject: [openssl-users] Expected behavior for verification when a
 subordinate in a chain is promoted to a self signed root?
In-Reply-To: <CAH8yC8=cVBLrbZmSGRXrj0LCu7WD4Y7qBBu-AmDaag+vJJUkmw@mail.gmail.com>
References: <CAH8yC8=cVBLrbZmSGRXrj0LCu7WD4Y7qBBu-AmDaag+vJJUkmw@mail.gmail.com>
Message-ID: <5561D500.9010104@openssl.org>



On 24/05/15 01:37, Jeffrey Walton wrote:
> I have an odd situation, and I don't know what the expect behavior is.
> It was experienced when attempting to validate a path for
> usercenter.checkpoint.com.
> 
> If I use s_client and `-showcerts`, I get a chain that terminates in
> an old Root called "Class 3 Public Primary Certification Authority".
> Its old and deprecated, so I tried to root or anchor trust in the next
> lower intermediate.
> 
> The next lower intermediate is called ''VeriSign Class 3 Public
> Primary Certification Authority - G5". Its sent in the chain, *but* I
> downloaded it out of band from Symantec's site.
> 
> Then I ran s_client again with the downloaded version of the
> certifcate (see below). It results in "Verify return code: 20 (unable
> to get local issuer certificate)".
> 
> After some digging, it looks like ''VeriSign Class 3 Public Primary
> Certification Authority - G5" are two different certificates with two
> different serial numbers. One is sent in the chain and one is
> available for download. What changed is the G5 certificate was
> promoted to a self signed root due to the former CA deprecation. But
> it reused the Disntiguished Name and public key, so Authority Key
> Identifier and Subject Key Identifier stayed the same.
> 
> What is the expected behavior here? Should it fail or should it succeed?
> 
> Does the chain override the root or anchor? I think RFC 4518 treats
> them as different certificates, so it just looks like the old G5
> certificate is suprious and unnecessary. (... but confusing due to the
> DN/SKI reuse)).

This was fixed in the git 1.0.2 HEAD a little while ago. If you try that
version it should work, and will be in 1.0.2b.

A backport of the fix also exists for 1.0.1 but it hasn't hit the repo yet.

Matt


From jb-openssl at wisemo.com  Mon May 25 00:31:43 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 25 May 2015 02:31:43 +0200
Subject: [openssl-users] What key length is used for DHE by default ?
In-Reply-To: <20150524033339.GB2072@zoho.com>
References: <20150524033339.GB2072@zoho.com>
Message-ID: <55626D6F.7010403@wisemo.com>

On 24/05/2015 05:33, mancha wrote:
> On Fri, 22 May 2015 at 11:17:21AM +0100, Matt Caswell wrote:
>> On 22/05/15 11:11, Nayna Jain wrote:
>>> Hi,
>>>
>>> With the latest logjam attack, as I was trying to verify if my
>>> server (lighttpd) accepts DHE_xxx  ciphers,  I saw that it accepted
>>> and I didn't do any configuration setting done for DH parameters
>>> explicitly.
>>>
>>> But I couldn't verify what is the key length did it use by default
>>> 512/1024/2048 ?
>>>
>>> Eg. the one it negotiated was DHE-RSA-AES128-SHA256  and for TLSv1.2
>>> protocol ?
>>>
>>> Will the key length be different for different protocols like
>>> SSLv3/TLSv1.0/TLSv1.1/TLSv1.2?  If yes , then what for each of them.
>> How that is configured depends on the application that is using
>> OpenSSL. A quick google search throws up this:
>>
>> http://redmine.lighttpd.net/projects/1/wiki/docs_ssl
>>
>> 'Diffie-Hellman and Elliptic-Curve Diffie-Hellman parameters
>> Diffie-Hellman and Elliptic-Curve Diffie-Hellman key agreement
>> protocols will be supported in lighttpd 1.4.29. By default,
>> Diffie-Hellman and Elliptic-Curve Diffie-Hellman key agreement
>> protocols use, respectively, the 1024-bit MODP Group with 160-bit
>> prime order subgroup from RFC 5114 and "prime256v1" (also known as
>> "secp256r1") elliptic curve from RFC 4492. The Elliptic-Curve
>> Diffie-Hellman key agreement protocol is supported in OpenSSL from
>> 0.9.8f version onwards. For maximum interoperability, OpenSSL only
>> supports the "named curves" from RFC 4492.
>>
>> Using the ssl.dh-file and ssl.ec-curve configuration variables, you
>> can define your own set of Diffie-Hellman domain parameters. For
>> example:
>>
>> ssl.dh-file = "/etc/lighttpd/ssl/dh2048.pem"
>> ssl.ec-curve = "secp384r1"'
> OpenSSL users might like to know you can use s_client to diagnose a
> server's Diffie-Hellman profile. Starting with OpenSSL 1.0.2 you can do:
>
> $ openssl s_client -connect www.example.com:443 -cipher "EDH" | grep
> "Server Temp Key"
>
> If you're testing a server that uses a small (weak) DH group the above
> command might output something like:
>
> Server Temp Key: DH, 512 bits
>
> Note: If you're on OpenSSL 1.0.1 you'll need to apply my back port to
> have this functionality:
>
> https://twitter.com/mancha140/status/602241770961907712
>
> --mancha
>
> P.S. That command also shows the elliptic curve name and bit size when
> using ECDHE and the RSA modulus bit size when RSA is used for the
> temporary key (as done by some export ciphers).
>
BEWARE: If the application is written to use different
DH key lengths for different ciphers (as is traditional),
this will only show the DH group for the current cipher,
not for any other cipher.  In the most common case,
selecting one of the old "export" ciphers will switch
from the longer DH group to a 512 bit DH group!


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From lists at rustichelli.net  Mon May 25 12:05:41 2015
From: lists at rustichelli.net (lists)
Date: Mon, 25 May 2015 14:05:41 +0200
Subject: [openssl-users] Truncating A Hash
In-Reply-To: <55551D06.7060601@roadrunner.com>
References: <55551D06.7060601@roadrunner.com>
Message-ID: <55631015.80309@rustichelli.net>

On 05/15/2015 12:09 AM, Jay Foster wrote:
> What is the down side of truncating a hash?  For example, an SHA-256 
> hash is 256 bits.  Is it any less secure if one was to drop the last 
> 128 bits to make a 128 bit hash or take the MD5 hash of the SHA-256 
> hash to get a 128 bit hash?  It does not seem that such an action 
> would make it any easier to brute force reverse the hash, but then 
> again, I am clearly not a security expert.

I'm not sure the previous replies, though correct, made the point clear.
Theoretically speaking, truncating a 256 bits long hash to 128 bits 
makes it as good as if you applied an hash of 128 bits, that's all 
(provided that the "hypotetical" latter hash algorithm has the same 
virtues of the former).
And yes, it is bad idea to re-hash, it is much better to truncate 
because re-hashing will not increase security, can only weaken it.

What is the purpose of it, though? For instance, HOTP uses a fraction of 
a hash to produce the (next) One Time Password, the security of the 
procedure depends on the use you make of it.


From jb-openssl at wisemo.com  Mon May 25 15:01:32 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 25 May 2015 17:01:32 +0200
Subject: [openssl-users] Truncating A Hash
In-Reply-To: <55551D06.7060601@roadrunner.com>
References: <55551D06.7060601@roadrunner.com>
Message-ID: <5563394C.1030806@wisemo.com>

On 15-05-2015 00:09, Jay Foster wrote:
> What is the down side of truncating a hash?  For example, an SHA-256 
> hash is 256 bits.  Is it any less secure if one was to drop the last 
> 128 bits to make a 128 bit hash or take the MD5 hash of the SHA-256 
> hash to get a 128 bit hash?  It does not seem that such an action 
> would make it any easier to brute force reverse the hash, but then 
> again, I am clearly not a security expert.
>
In addition to the previous 3 answers, "recent" versions
of the official SHA-256 standard (US Federal Information
Processing Standard 180-4) specify that if you want to
truncate SHA-512 or any of the other "SHA-2" hashes, then
you are supposed to change the initial state at the start
of the calculation to a value that depends on how many
bits you are going to keep.

The alternate start value is specified for SHA-512/128
(which is the same as SHA-384/128) via a formula (which
is somewhat underspecified, check that your
interpretation provides the correct values for
SHA-512/256).  There is currently no clear formula for
SHA-256/t and thus SHA-256/128.

Note that unless otherwise specified in another official
standard (such as NIST Special Publication 800-107),
only the specific truncations SHA-512/256 and SHA-512/224
are approved for use by/for the US government.  This is
purely a bureaucratic requirement, there is no known
security reason for the rest of the world to follow this
latter limitation to the letter.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From rt at openssl.org  Mon May 25 12:34:06 2015
From: rt at openssl.org (Andy Polyakov via RT)
Date: Mon, 25 May 2015 14:34:06 +0200
Subject: [openssl-users] [openssl-dev] [openssl.org #3804] BUG: OpenSSL
	1.0.2 Solaris 32 bit build is broken
In-Reply-To: <556316B2.7070709@openssl.org>
References: <RT-Ticket-3804@openssl.org>
 <CO1PR02MB158F5C3E6C4FAE8CEDBD6E2F0E50@CO1PR02MB158.namprd02.prod.outlook.com>
 <rt-4.0.4-28364-1429094221-1388.3804-21-0@openssl.org>
 <556316B2.7070709@openssl.org>
Message-ID: <rt-4.0.4-5064-1432557246-1457.3804-6-0@openssl.org>

Hi,

> I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 32 bit. I want to upgrade but neither 1.0.2 nor 1.0.2a work.
> 
> Solaris 10
> Solaris Studio 12.4
> 
> Make test log attached.
> 
> 1 When building 1.0.2 using
> 
> ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden
> 
> openssl s_client crashes on start:
> 
> -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250
> Segmentation Fault (core dumped)
> -bash-3.00$ pstack core
> core 'core' of 468:     ./openssl s_client -connect eos.es.cpth.ie:4250
> 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8

Well, combining no-shared and -xcode=pic32 results in ambiguity in the
very beginning of this and few other subroutines. For code to be
compiled as position-independent __PIC__ macro is required to be
defined, but I don't think passing -xcode=pic32 cuts it. Question is
what is your objective? I mean why is it such contradicting mixture of
no-shared and pic options? If the goal is to build static library that
can be later linked into another shared library, then I'd suggest
no-shared -KPIC, which supposedly can be followed by -xcode=pic32
-xlscope=hidden. Keyword here is that -KPIC ought to pre-define __PIC__.
If it doesn't, then complement it with -DOPENSSL_PIC, i.e. './Configure
solaris-sparcv9-cc no-shared -KPIC -DOPENSSL_PIC ...'

> 2 So I then rebuilt adding no-asm flag. It manages to connect but negotiation fails with an error:
> 
> 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1456:SSL alert number 20
> 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
> 
> This is against the server that is still running 1.0.1h and can be successfully connected with openssl s_client built with 1.0.1h.
> 
> The 64 bit build seems to work perfectly. The 32 bit builds that we use on Windows and Linux also work perfectly.
> 
> 1.0.2a build fails in the same way. gcc build fails in the same way.

So what you are saying is that everything works, but 32-bit SPARC 1.0.2
build and it doesn't matter if it's compiled with vendor compiler or
gcc. H-m-m-m... Did you run 'make clean' in between? Thing is that
normal reaction in such situation is to suspect compiler bug, but two
compilers are highly unlikely to share bug. So try 'make clean' in
between tries, or better yet, try builds in separate directories. If
both still fail, play with -cipher option to identify faulty algorithm...



From oyljerry at gmail.com  Tue May 26 03:17:55 2015
From: oyljerry at gmail.com (Jerry OELoo)
Date: Tue, 26 May 2015 11:17:55 +0800
Subject: [openssl-users]  Why no peer certificate available.
Message-ID: <CAEKwp_GJYe=G1YL0csF0wwAo6j+8MQydvjEj49fWKw+dj0W2+g@mail.gmail.com>

Hi.
I found there is a website which has https support.
https://www.ib-channel.net/miegin/web/jsp/B02-01.jsp
and browser can show its certificate chain.
but when I use openssl to connect website, it returns fail.

openssl s_client -connect www.ib-channel.net:443
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 305 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

So what is wrong that openssl can not get website's certificate? Thanks!

-- 
Rejoice,I Desire!

From patpro at patpro.net  Tue May 26 04:55:14 2015
From: patpro at patpro.net (Patrick Proniewski)
Date: Tue, 26 May 2015 06:55:14 +0200
Subject: [openssl-users] Why no peer certificate available.
In-Reply-To: <CAEKwp_GJYe=G1YL0csF0wwAo6j+8MQydvjEj49fWKw+dj0W2+g@mail.gmail.com>
References: <CAEKwp_GJYe=G1YL0csF0wwAo6j+8MQydvjEj49fWKw+dj0W2+g@mail.gmail.com>
Message-ID: <53BD3F15-53F1-445A-91D7-D5A40A45605A@patpro.net>

On 26 mai 2015, at 05:17, Jerry OELoo wrote:

> Hi.
> I found there is a website which has https support.
> https://www.ib-channel.net/miegin/web/jsp/B02-01.jsp
> and browser can show its certificate chain.
> but when I use openssl to connect website, it returns fail.


Openssl works great here: 

$ openssl s_client -connect www.ib-channel.net:443
CONNECTED(00000003)
depth=2 /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/1.3.6.1.4.1.311.60.2.1.3=JP/businessCategory=Private Organization/serialNumber=0104-01-022916/C=JP/postalCode=108-8001/ST=Tokyo/L=Minato-ku/street=7-1, Shiba 5-chome/O=NEC Corporation/OU=NEC WOSC-IB005/CN=www.ib-channel.net
...
...

but it's kinda old: 

$ openssl version
OpenSSL 0.9.8y 5 Feb 2013

A more current release shows the same error you posted: 

$ apps/openssl version
OpenSSL 1.0.2a 19 Mar 2015

$ apps/openssl s_client -connect www.ib-channel.net:443
CONNECTED(00000003)
write:errno=54
---
no peer certificate available
---
...
...

From noloader at gmail.com  Tue May 26 05:32:08 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 26 May 2015 01:32:08 -0400
Subject: [openssl-users] Why no peer certificate available.
In-Reply-To: <CAEKwp_GJYe=G1YL0csF0wwAo6j+8MQydvjEj49fWKw+dj0W2+g@mail.gmail.com>
References: <CAEKwp_GJYe=G1YL0csF0wwAo6j+8MQydvjEj49fWKw+dj0W2+g@mail.gmail.com>
Message-ID: <CAH8yC8nztJsimVgn7kV-0GyU-A+33mbQqA-aC513_2vN=YJdWA@mail.gmail.com>

On Mon, May 25, 2015 at 11:17 PM, Jerry OELoo <oyljerry at gmail.com> wrote:
> Hi.
> I found there is a website which has https support.
> https://www.ib-channel.net/miegin/web/jsp/B02-01.jsp
> and browser can show its certificate chain.
> but when I use openssl to connect website, it returns fail.
>
> openssl s_client -connect www.ib-channel.net:443
> CONNECTED(00000003)
> write:errno=104
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 305 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> ---
>
> So what is wrong that openssl can not get website's certificate? Thanks!
>

I'm timing out from US/New York using Apple's downlevel version of
OpenSSL (0.9.8). But I'm succeeding with the latest version of OpenSSL
(1.0.2a). (It seems to be opposite of what Patrick is experiencing).

Also, you usually want to specify TLS and the server name. SSLv3 is
pretty much dead now. SNI also ensures the server selects the right
certificate at during channel setup.

    openssl s_client -connect www.ib-channel.net:443 \
        -tls1 -servername www.ib-channel.net

From oyljerry at gmail.com  Tue May 26 07:49:23 2015
From: oyljerry at gmail.com (Jerry OELoo)
Date: Tue, 26 May 2015 15:49:23 +0800
Subject: [openssl-users] Why no peer certificate available.
In-Reply-To: <CAH8yC8nztJsimVgn7kV-0GyU-A+33mbQqA-aC513_2vN=YJdWA@mail.gmail.com>
References: <CAEKwp_GJYe=G1YL0csF0wwAo6j+8MQydvjEj49fWKw+dj0W2+g@mail.gmail.com>
 <CAH8yC8nztJsimVgn7kV-0GyU-A+33mbQqA-aC513_2vN=YJdWA@mail.gmail.com>
Message-ID: <CAEKwp_G8d5jLNPD-nS6oe7hCPMDM6MQn98g_=c7xtYuLiwE5zA@mail.gmail.com>

After I set -tls1 -servername, I can get certificate chain information.
But in my code. I have used SSL_set_tlsext_host_name() to set host
name, but it can not get certificate chain.

On Tue, May 26, 2015 at 1:32 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> On Mon, May 25, 2015 at 11:17 PM, Jerry OELoo <oyljerry at gmail.com> wrote:
>> Hi.
>> I found there is a website which has https support.
>> https://www.ib-channel.net/miegin/web/jsp/B02-01.jsp
>> and browser can show its certificate chain.
>> but when I use openssl to connect website, it returns fail.
>>
>> openssl s_client -connect www.ib-channel.net:443
>> CONNECTED(00000003)
>> write:errno=104
>> ---
>> no peer certificate available
>> ---
>> No client certificate CA names sent
>> ---
>> SSL handshake has read 0 bytes and written 305 bytes
>> ---
>> New, (NONE), Cipher is (NONE)
>> Secure Renegotiation IS NOT supported
>> Compression: NONE
>> Expansion: NONE
>> ---
>>
>> So what is wrong that openssl can not get website's certificate? Thanks!
>>
>
> I'm timing out from US/New York using Apple's downlevel version of
> OpenSSL (0.9.8). But I'm succeeding with the latest version of OpenSSL
> (1.0.2a). (It seems to be opposite of what Patrick is experiencing).
>
> Also, you usually want to specify TLS and the server name. SSLv3 is
> pretty much dead now. SNI also ensures the server selects the right
> certificate at during channel setup.
>
>     openssl s_client -connect www.ib-channel.net:443 \
>         -tls1 -servername www.ib-channel.net
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 
Rejoice,I Desire!

From matt at openssl.org  Tue May 26 08:09:18 2015
From: matt at openssl.org (Matt Caswell)
Date: Tue, 26 May 2015 09:09:18 +0100
Subject: [openssl-users] Why no peer certificate available.
In-Reply-To: <CAEKwp_GJYe=G1YL0csF0wwAo6j+8MQydvjEj49fWKw+dj0W2+g@mail.gmail.com>
References: <CAEKwp_GJYe=G1YL0csF0wwAo6j+8MQydvjEj49fWKw+dj0W2+g@mail.gmail.com>
Message-ID: <55642A2E.3020701@openssl.org>



On 26/05/15 04:17, Jerry OELoo wrote:
> Hi.
> I found there is a website which has https support.
> https://www.ib-channel.net/miegin/web/jsp/B02-01.jsp
> and browser can show its certificate chain.
> but when I use openssl to connect website, it returns fail.
> 
> openssl s_client -connect www.ib-channel.net:443
> CONNECTED(00000003)
> write:errno=104
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 305 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> ---
> 
> So what is wrong that openssl can not get website's certificate? Thanks!
> 

This appears to be the server hang on over long ClientHello bug. Some
buggy servers cannot cope if the ClientHello is longer than 255 bytes.

I get a hang if I attempt to connect to the above site however if I pass
"-DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=100" to Configure it all works fine.
It also works fine if I use "-no_tls1_2" with s_client to disable TLS1.2
support, or if I set a custom (reduced length) cipher list.

Matt

From naynjain at in.ibm.com  Tue May 26 08:08:53 2015
From: naynjain at in.ibm.com (Nayna Jain)
Date: Tue, 26 May 2015 13:38:53 +0530
Subject: [openssl-users] What key length is used for DHE by default ?
In-Reply-To: <55626D6F.7010403@wisemo.com>
References: <20150524033339.GB2072@zoho.com> <55626D6F.7010403@wisemo.com>
Message-ID: <OFF1AC9DA3.6F08CF49-ON65257E51.002C91B0-65257E51.002CC1EA@in.ibm.com>


I have got the openssl 1.0.2
I don't have any ssl.dh-file set.

Still by default lighttpd is negotiating Server Temp Key: DH, 2048 bits

Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-GCM-SHA384

I am surprised for this because once and only once it had negotiated 1024
bits and after  that it is showing only 2048.  Can someone help me to
explain this ?

Is there also an option to set the key length manually and check if it will
negotiate that. ?

Thanks & Regards,
Nayna Jain



From:	Jakob Bohm <jb-openssl at wisemo.com>
To:	openssl-users at openssl.org
Date:	05/25/2015 06:02 AM
Subject:	Re: [openssl-users] What key length is used for DHE by
            default ?
Sent by:	"openssl-users" <openssl-users-bounces at openssl.org>



On 24/05/2015 05:33, mancha wrote:
> On Fri, 22 May 2015 at 11:17:21AM +0100, Matt Caswell wrote:
>> On 22/05/15 11:11, Nayna Jain wrote:
>>> Hi,
>>>
>>> With the latest logjam attack, as I was trying to verify if my
>>> server (lighttpd) accepts DHE_xxx  ciphers,  I saw that it accepted
>>> and I didn't do any configuration setting done for DH parameters
>>> explicitly.
>>>
>>> But I couldn't verify what is the key length did it use by default
>>> 512/1024/2048 ?
>>>
>>> Eg. the one it negotiated was DHE-RSA-AES128-SHA256  and for TLSv1.2
>>> protocol ?
>>>
>>> Will the key length be different for different protocols like
>>> SSLv3/TLSv1.0/TLSv1.1/TLSv1.2?  If yes , then what for each of them.
>> How that is configured depends on the application that is using
>> OpenSSL. A quick google search throws up this:
>>
>> http://redmine.lighttpd.net/projects/1/wiki/docs_ssl
>>
>> 'Diffie-Hellman and Elliptic-Curve Diffie-Hellman parameters
>> Diffie-Hellman and Elliptic-Curve Diffie-Hellman key agreement
>> protocols will be supported in lighttpd 1.4.29. By default,
>> Diffie-Hellman and Elliptic-Curve Diffie-Hellman key agreement
>> protocols use, respectively, the 1024-bit MODP Group with 160-bit
>> prime order subgroup from RFC 5114 and "prime256v1" (also known as
>> "secp256r1") elliptic curve from RFC 4492. The Elliptic-Curve
>> Diffie-Hellman key agreement protocol is supported in OpenSSL from
>> 0.9.8f version onwards. For maximum interoperability, OpenSSL only
>> supports the "named curves" from RFC 4492.
>>
>> Using the ssl.dh-file and ssl.ec-curve configuration variables, you
>> can define your own set of Diffie-Hellman domain parameters. For
>> example:
>>
>> ssl.dh-file = "/etc/lighttpd/ssl/dh2048.pem"
>> ssl.ec-curve = "secp384r1"'
> OpenSSL users might like to know you can use s_client to diagnose a
> server's Diffie-Hellman profile. Starting with OpenSSL 1.0.2 you can do:
>
> $ openssl s_client -connect www.example.com:443 -cipher "EDH" | grep
> "Server Temp Key"
>
> If you're testing a server that uses a small (weak) DH group the above
> command might output something like:
>
> Server Temp Key: DH, 512 bits
>
> Note: If you're on OpenSSL 1.0.1 you'll need to apply my back port to
> have this functionality:
>
> https://twitter.com/mancha140/status/602241770961907712
>
> --mancha
>
> P.S. That command also shows the elliptic curve name and bit size when
> using ECDHE and the RSA modulus bit size when RSA is used for the
> temporary key (as done by some export ciphers).
>
BEWARE: If the application is written to use different
DH key lengths for different ciphers (as is traditional),
this will only show the DH group for the current cipher,
not for any other cipher.  In the most common case,
selecting one of the old "export" ciphers will switch
from the longer DH group to a 512 bit DH group!


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150526/eb796511/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150526/eb796511/attachment.gif>

From noloader at gmail.com  Tue May 26 08:22:36 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 26 May 2015 04:22:36 -0400
Subject: [openssl-users] Why no peer certificate available.
In-Reply-To: <55642A2E.3020701@openssl.org>
References: <CAEKwp_GJYe=G1YL0csF0wwAo6j+8MQydvjEj49fWKw+dj0W2+g@mail.gmail.com>
 <55642A2E.3020701@openssl.org>
Message-ID: <CAH8yC8mHcTMpCZS9BMdZAzzmp5CEYywMCg9LNmdGydA4w+nTHQ@mail.gmail.com>

On Tue, May 26, 2015 at 4:09 AM, Matt Caswell <matt at openssl.org> wrote:
>
>
> On 26/05/15 04:17, Jerry OELoo wrote:
>> Hi.
>> I found there is a website which has https support.
>> https://www.ib-channel.net/miegin/web/jsp/B02-01.jsp
>> and browser can show its certificate chain.
>> but when I use openssl to connect website, it returns fail.
>>
>> openssl s_client -connect www.ib-channel.net:443
>> CONNECTED(00000003)
>> write:errno=104
>> ---
>> no peer certificate available
>> ---
>> No client certificate CA names sent
>> ---
>> SSL handshake has read 0 bytes and written 305 bytes
>> ---
>> New, (NONE), Cipher is (NONE)
>> Secure Renegotiation IS NOT supported
>> Compression: NONE
>> Expansion: NONE
>> ---
>>
>> So what is wrong that openssl can not get website's certificate? Thanks!
>>
>
> This appears to be the server hang on over long ClientHello bug. Some
> buggy servers cannot cope if the ClientHello is longer than 255 bytes.
>
> I get a hang if I attempt to connect to the above site however if I pass
> "-DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=100" to Configure it all works fine.
> It also works fine if I use "-no_tls1_2" with s_client to disable TLS1.2
> support, or if I set a custom (reduced length) cipher list.
>
Good find. It sounds like an F5 or IronPort appliance.

Do we know what the appliance is?

From noloader at gmail.com  Tue May 26 10:10:10 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 26 May 2015 06:10:10 -0400
Subject: [openssl-users] Truncating A Hash
In-Reply-To: <55631015.80309@rustichelli.net>
References: <55551D06.7060601@roadrunner.com> <55631015.80309@rustichelli.net>
Message-ID: <CAH8yC8=cTyLw4jKwLC-siJM-RJZ4wkQU8uJPszB473+1WDeUUw@mail.gmail.com>

On Mon, May 25, 2015 at 8:05 AM, lists <lists at rustichelli.net> wrote:
> On 05/15/2015 12:09 AM, Jay Foster wrote:
>>
>> What is the down side of truncating a hash?  For example, an SHA-256 hash
>> is 256 bits.  Is it any less secure if one was to drop the last 128 bits to
>> make a 128 bit hash or take the MD5 hash of the SHA-256 hash to get a 128
>> bit hash?  It does not seem that such an action would make it any easier to
>> brute force reverse the hash, but then again, I am clearly not a security
>> expert.
>
>
> I'm not sure the previous replies, though correct, made the point clear.
> Theoretically speaking, truncating a 256 bits long hash to 128 bits makes it
> as good as if you applied an hash of 128 bits, that's all (provided that the
> "hypotetical" latter hash algorithm has the same virtues of the former).
> And yes, it is bad idea to re-hash, it is much better to truncate because
> re-hashing will not increase security, can only weaken it.

Its not clear that property exists for truncated hashes. At minimum,
the prefix does not change whether you lop off the last 10 bytes or 20
bytes. I believe one of the things you are supposed to do is feed in
the truncated digest size to ensure a different digest based on the
truncation size.

You should visit some of John Kelsey's work on it.
http://csrc.nist.gov/groups/ST/hash/documents/Kelsey_Truncation.pdf is
the one I am familiar with. Also see
https://www.google.com/search?q=truncated+hash+kelsey+nist

Also, for SHA-1, see Marc Steven's HashClash
(https://marc-stevens.nl/p/hashclash/). I believe he's engineering
prefix collisions.

> What is the purpose of it, though? For instance, HOTP uses a fraction of a
> hash to produce the (next) One Time Password, the security of the procedure
> depends on the use you make of it.

A HOTP is a one time password. Its just that - a temporary password.
It makes not guarantees on collision resistance and such. The range is
so small it probably can't make any guarantees.

Jeff

From pbellino at mrv.com  Tue May 26 12:01:30 2015
From: pbellino at mrv.com (Philip Bellino)
Date: Tue, 26 May 2015 12:01:30 +0000
Subject: [openssl-users] FIPS Validation questions
Message-ID: <AM3PR03MB08247B431E5FD858CE700456C3CC0@AM3PR03MB0824.eurprd03.prod.outlook.com>


Hello,
We use OpenSSL-1.0.2a and FIPS 2.0.9 and have questions we need to answer in conjunction with the FIPS validation
process.
One question is whether SHA1 accepts NULL (zero-length) messages?  I couldn't find anything on the OpenSSL
wiki so I thought I'd ask here.
Also, another questions is whether the AES CTR counter source is internal or external?

Any information would be appreciated.
Thanks,
Phil




MRV Communications is a global supplier of packet and optical solutions that power the world's largest networks. Our products combine innovative hardware with intelligent software to make networks smarter, faster and more efficient.



The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150526/edfc9cd5/attachment-0001.html>

From beldmit at gmail.com  Tue May 26 14:46:54 2015
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Tue, 26 May 2015 17:46:54 +0300
Subject: [openssl-users] Implementing the rsa_sign callback
In-Reply-To: <CADqLbzJe-cvOSPoHF4bEJhy_F7OhDmms3wv6=k5XeAP3RV0rUg@mail.gmail.com>
References: <CADqLbzJe-cvOSPoHF4bEJhy_F7OhDmms3wv6=k5XeAP3RV0rUg@mail.gmail.com>
Message-ID: <CADqLbzKeKwzccjM38OtA0a0HeTa7TS+OQko384_ribMRfW7VQA@mail.gmail.com>

Hello all,

Any suggestions?

On Thu, Apr 30, 2015 at 1:06 PM, Dmitry Belyavsky <beldmit at gmail.com> wrote:

> Hello all!
>
> I'm implementing a custom engine providing its own RSA method.
>
> I need to provide the rsa_sign callback, which is required to call my own
> code in case when ex_data is set and call a default callback otherwise.
>
> For other callbacks I use the appropriate callbacks from the
> rsa_pkcs1_eay_meth, as other engines do. But the rsa_pkcs1_eay_meth does
> not provide a rsa_sign callback.
>
> What is the correct way to implement the rsa_sign callback?
>
> Thank you!
>
> --
> SY, Dmitry Belyavsky
>



-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150526/aa56b8ab/attachment.html>

From ben at an3k.de  Tue May 26 23:21:24 2015
From: ben at an3k.de (Ben Humpert)
Date: Wed, 27 May 2015 01:21:24 +0200
Subject: [openssl-users] Android Wifi setup / CA certificate / always
	getting SSL fatal error
Message-ID: <CAGbjqfHmiLbTiWOFo8rULM02cDmRPfO9k5d+eMN-P+szyaDOLg@mail.gmail.com>

Hi everybody,

I have my RADIUS server running and Windows as well as MacOS and iOS
can successfully authenticate using EAP-PEAP, EAP-TTLS or EAP-TLS each
with server certificate validation. However, Android 4.4.4 can not and
I can't figure out why.

The complete Cert Chain:

Root CA
  - Intermediate CA1
    - Intermediate CA2
      - Intermediate CA3
        - Signing CA
          - RADIUS Server Cert
          - Android Client Cert

RADIUS server has the complete Certificate Chain in it's CA.crt file
and it's own certificate in it's server.crt file.

When I do not select any CA certificate in Android WiFi Setup but just
a User certificate EAP-TLS connection works fine. If I use the same
configuration but now select a CA certificate I get two different
errors.

When I select the Root CA certificate I get

Wed May 27 01:03:05 2015 : Debug: (106) eap: Peer sent method TLS (13)
Wed May 27 01:03:05 2015 : Debug: (106) eap: EAP TLS (13)
Wed May 27 01:03:05 2015 : Debug: (106) eap: Calling eap_tls to process EAP data
Wed May 27 01:03:05 2015 : Debug: (106) eap_tls: Authenticate
Wed May 27 01:03:05 2015 : Debug: (106) eap_tls: processing EAP-TLS
Wed May 27 01:03:05 2015 : Debug: (106) eap_tls: eaptls_verify returned 7
Wed May 27 01:03:05 2015 : Debug: (106) eap_tls: Done initial handshake
Wed May 27 01:03:05 2015 : Debug: (106) eap_tls: <<< TLS 1.0 Alert
[length 0002], fatal certificate_unknown
Wed May 27 01:03:05 2015 : ERROR: (106) eap_tls: TLS Alert
read:fatal:certificate unknown
Wed May 27 01:03:05 2015 : ERROR: (106) eap_tls: TLS_accept: Failed in
SSLv3 read client certificate A
Wed May 27 01:03:05 2015 : ERROR: (106) eap_tls: SSL says:
error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate
unknown
Wed May 27 01:03:05 2015 : Error: SSL: SSL_read failed inside of TLS
(-1), TLS session fails.
Wed May 27 01:03:05 2015 : Debug: TLS receive handshake failed during operation
Wed May 27 01:03:05 2015 : Debug: (106) eap_tls: eaptls_process returned 4
Wed May 27 01:03:05 2015 : ERROR: (106) eap: Failed continuing EAP TLS
(13) session. EAP sub-module failed

When I select any other CA certificate I always get

Wed May 27 01:05:21 2015 : Debug: (140) eap: Peer sent method TLS (13)
Wed May 27 01:05:21 2015 : Debug: (140) eap: EAP TLS (13)
Wed May 27 01:05:21 2015 : Debug: (140) eap: Calling eap_tls to process EAP data
Wed May 27 01:05:21 2015 : Debug: (140) eap_tls: Authenticate
Wed May 27 01:05:21 2015 : Debug: (140) eap_tls: processing EAP-TLS
Wed May 27 01:05:21 2015 : Debug: (140) eap_tls: eaptls_verify returned 7
Wed May 27 01:05:21 2015 : Debug: (140) eap_tls: Done initial handshake
Wed May 27 01:05:21 2015 : Debug: (140) eap_tls: <<< TLS 1.0 Alert
[length 0002], fatal unknown_ca
Wed May 27 01:05:21 2015 : ERROR: (140) eap_tls: TLS Alert read:fatal:unknown CA
Wed May 27 01:05:21 2015 : ERROR: (140) eap_tls: TLS_accept: Failed in
SSLv3 read client certificate A
Wed May 27 01:05:21 2015 : ERROR: (140) eap_tls: SSL says:
error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
Wed May 27 01:05:21 2015 : Error: SSL: SSL_read failed inside of TLS
(-1), TLS session fails.
Wed May 27 01:05:21 2015 : Debug: TLS receive handshake failed during operation
Wed May 27 01:05:21 2015 : Debug: (140) eap_tls: eaptls_process returned 4
Wed May 27 01:05:21 2015 : ERROR: (140) eap: Failed continuing EAP TLS
(13) session. EAP sub-module failed

All Windows, MacOS, iOS and Android devices have their own client
certificate and have all CA certificates installed.

Because of that I really have to ask what the funk is wrong with
Android? From all the tests I did not it feels like Android is sending
the certificates in the wrong order, so instead of sending the client
cert first it sends the CA cert first and thus RADIUS / OpenSSL errors
because it expected a client cert. Sadly I can't select the client
cert as a CA certificate or vice-versa.

Any help is much appreciated!


Best regards,

Ben

From noloader at gmail.com  Tue May 26 23:29:49 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 26 May 2015 19:29:49 -0400
Subject: [openssl-users] Android Wifi setup / CA certificate / always
 getting SSL fatal error
In-Reply-To: <CAGbjqfHmiLbTiWOFo8rULM02cDmRPfO9k5d+eMN-P+szyaDOLg@mail.gmail.com>
References: <CAGbjqfHmiLbTiWOFo8rULM02cDmRPfO9k5d+eMN-P+szyaDOLg@mail.gmail.com>
Message-ID: <CAH8yC8k0_MZV_eA3VX4McfHHps5DZ59XcwZ9=ndgdD_rPc16Cw@mail.gmail.com>

On Tue, May 26, 2015 at 7:21 PM, Ben Humpert <ben at an3k.de> wrote:
> Hi everybody,
>
> I have my RADIUS server running and Windows as well as MacOS and iOS
> can successfully authenticate using EAP-PEAP, EAP-TTLS or EAP-TLS each
> with server certificate validation. However, Android 4.4.4 can not and
> I can't figure out why.
>
> ...
> Because of that I really have to ask what the funk is wrong with
> Android? From all the tests I did not it feels like Android is sending
> the certificates in the wrong order, so instead of sending the client
> cert first it sends the CA cert first and thus RADIUS / OpenSSL errors
> because it expected a client cert. Sadly I can't select the client
> cert as a CA certificate or vice-versa.
>
> Any help is much appreciated!
>
Maybe related.... The mother of all process is Zygote. An Android
Activity is effectively forked from it (some hand waiving).

Zygote loads a down level version of OpenSSL. It used to be 0.9.8, but
its an odd mix of 1.0.0 and 1.0.1 now. When your app attempts to load
its version of OpenSSL carried around in the JNI folder, its not
loaded because Zygote already loaded a down level version provided by
the platform.

So one of my first guesses would be a bug is present due to the way
AOSP supplies OpenSSL modulo the way the way Zygote works.

Jeff

From jb-openssl at wisemo.com  Wed May 27 06:17:02 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 27 May 2015 08:17:02 +0200
Subject: [openssl-users] Android Wifi setup / CA certificate / always
 getting SSL fatal error
In-Reply-To: <CAGbjqfHmiLbTiWOFo8rULM02cDmRPfO9k5d+eMN-P+szyaDOLg@mail.gmail.com>
References: <CAGbjqfHmiLbTiWOFo8rULM02cDmRPfO9k5d+eMN-P+szyaDOLg@mail.gmail.com>
Message-ID: <5565615E.1050505@wisemo.com>

On 27/05/2015 01:21, Ben Humpert wrote:
> Hi everybody,
>
> I have my RADIUS server running and Windows as well as MacOS and iOS
> can successfully authenticate using EAP-PEAP, EAP-TTLS or EAP-TLS each
> with server certificate validation. However, Android 4.4.4 can not and
> I can't figure out why.
>
> The complete Cert Chain:
>
> Root CA
>    - Intermediate CA1
>      - Intermediate CA2
>        - Intermediate CA3
>          - Signing CA
>            - RADIUS Server Cert
>            - Android Client Cert
>
> RADIUS server has the complete Certificate Chain in it's CA.crt file
> and it's own certificate in it's server.crt file.
>
> When I do not select any CA certificate in Android WiFi Setup but just
> a User certificate EAP-TLS connection works fine. If I use the same
> configuration but now select a CA certificate I get two different
> errors.
Maybe the Android user interface is really asking about
something other than the issuing CA cert.

What are you trying to achieve by selecting a CA cert
in the client UI?
> When I select the Root CA certificate I get
>
> ...
> Wed May 27 01:03:05 2015 : Debug: (106) eap_tls: <<< TLS 1.0 Alert
> [length 0002], fatal certificate_unknown
> Wed May 27 01:03:05 2015 : ERROR: (106) eap_tls: TLS Alert
> read:fatal:certificate unknown
> Wed May 27 01:03:05 2015 : ERROR: (106) eap_tls: TLS_accept: Failed in
> SSLv3 read client certificate A
> Wed May 27 01:03:05 2015 : ERROR: (106) eap_tls: SSL says:
> error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate
> unknown
> ...
>
> When I select any other CA certificate I always get
>
> ...
> Wed May 27 01:05:21 2015 : Debug: (140) eap_tls: <<< TLS 1.0 Alert
> [length 0002], fatal unknown_ca
> Wed May 27 01:05:21 2015 : ERROR: (140) eap_tls: TLS Alert read:fatal:unknown CA
> Wed May 27 01:05:21 2015 : ERROR: (140) eap_tls: TLS_accept: Failed in
> SSLv3 read client certificate A
> Wed May 27 01:05:21 2015 : ERROR: (140) eap_tls: SSL says:
> error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca
> Wed May 27 01:05:21 2015 : Error: SSL: SSL_read failed inside of TLS
> (-1), TLS session fails.
> Wed May 27 01:05:21 2015 : Debug: TLS receive handshake failed during operation
> ...
>
> All Windows, MacOS, iOS and Android devices have their own client
> certificate and have all CA certificates installed.
>
> Because of that I really have to ask what the funk is wrong with
> Android? From all the tests I did not it feels like Android is sending
> the certificates in the wrong order, so instead of sending the client
> cert first it sends the CA cert first and thus RADIUS / OpenSSL errors
> because it expected a client cert. Sadly I can't select the client
> cert as a CA certificate or vice-versa.
>
> Any help is much appreciated!
Which OpenSSL version is the EAP_TLS code using to
verify the certificates?

I read somewhere on this list that an ultra-recent
OpenSSL version (not sure if 1.0.2 or 1.1.0) was
changed to be more tolerant of out-of-order certificates,
though I am not sure if that change is also for the
location of the peer certificate in the list, and if
that change is also in the part used by EAP_TLS.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150527/2b597155/attachment.html>

From ben at an3k.de  Wed May 27 10:47:59 2015
From: ben at an3k.de (Ben Humpert)
Date: Wed, 27 May 2015 12:47:59 +0200
Subject: [openssl-users] Android Wifi setup / CA certificate / always
 getting SSL fatal error
In-Reply-To: <5565615E.1050505@wisemo.com>
References: <CAGbjqfHmiLbTiWOFo8rULM02cDmRPfO9k5d+eMN-P+szyaDOLg@mail.gmail.com>
 <5565615E.1050505@wisemo.com>
Message-ID: <CAGbjqfGwmA0Ymg23mx2eNEiEAHT6sMpxXEqjtrroQ+MpdJ3DmA@mail.gmail.com>

2015-05-27 8:17 GMT+02:00 Jakob Bohm <jb-openssl at wisemo.com>:
> Maybe the Android user interface is really asking about
> something other than the issuing CA cert.
>
> What are you trying to achieve by selecting a CA cert
> in the client UI?

The official Google documentation as well as other sources say that it
asks for the Root CA certificate and with that selected I get a
different error message than with any other certificate so I guess it
is the right cert.

I want the users to validate the RADIUS server's certificate.

> Which OpenSSL version is the EAP_TLS code using to
> verify the certificates?

OpenSSL 1.0.1f 6 Jan 2014
built on: Thu Mar 19 15:12:02 UTC 2015
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2
-fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions
-Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

> I read somewhere on this list that an ultra-recent
> OpenSSL version (not sure if 1.0.2 or 1.1.0) was
> changed to be more tolerant of out-of-order certificates,
> though I am not sure if that change is also for the
> location of the peer certificate in the list, and if
> that change is also in the part used by EAP_TLS.

From jb-openssl at wisemo.com  Wed May 27 12:02:19 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 27 May 2015 14:02:19 +0200
Subject: [openssl-users] Android Wifi setup / CA certificate / always
 getting SSL fatal error
In-Reply-To: <CAGbjqfGwmA0Ymg23mx2eNEiEAHT6sMpxXEqjtrroQ+MpdJ3DmA@mail.gmail.com>
References: <CAGbjqfHmiLbTiWOFo8rULM02cDmRPfO9k5d+eMN-P+szyaDOLg@mail.gmail.com>
 <5565615E.1050505@wisemo.com>
 <CAGbjqfGwmA0Ymg23mx2eNEiEAHT6sMpxXEqjtrroQ+MpdJ3DmA@mail.gmail.com>
Message-ID: <5565B24B.8080305@wisemo.com>

On 27/05/2015 12:47, Ben Humpert wrote:
> 2015-05-27 8:17 GMT+02:00 Jakob Bohm <jb-openssl at wisemo.com>:
>> Maybe the Android user interface is really asking about
>> something other than the issuing CA cert.
>>
>> What are you trying to achieve by selecting a CA cert
>> in the client UI?
> The official Google documentation as well as other sources say that it
> asks for the Root CA certificate and with that selected I get a
> different error message than with any other certificate so I guess it
> is the right cert.
>
> I want the users to validate the RADIUS server's certificate.
>
>> Which OpenSSL version is the EAP_TLS code using to
>> verify the certificates?
> OpenSSL 1.0.1f 6 Jan 2014
> built on: Thu Mar 19 15:12:02 UTC 2015
> platform: debian-amd64
> options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
> compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT
> -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2
> -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions
> -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int
> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
> -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> OPENSSLDIR: "/usr/lib/ssl"
>
>> I read somewhere on this list that an ultra-recent
>> OpenSSL version (not sure if 1.0.2 or 1.1.0) was
>> changed to be more tolerant of out-of-order certificates,
>> though I am not sure if that change is also for the
>> location of the peer certificate in the list, and if
>> that change is also in the part used by EAP_TLS.
Just to clarify: The log messages in your original post,
were those from Android or from the server?


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From ben at an3k.de  Wed May 27 12:56:04 2015
From: ben at an3k.de (Ben Humpert)
Date: Wed, 27 May 2015 14:56:04 +0200
Subject: [openssl-users] Android Wifi setup / CA certificate / always
 getting SSL fatal error
In-Reply-To: <5565B24B.8080305@wisemo.com>
References: <CAGbjqfHmiLbTiWOFo8rULM02cDmRPfO9k5d+eMN-P+szyaDOLg@mail.gmail.com>
 <5565615E.1050505@wisemo.com>
 <CAGbjqfGwmA0Ymg23mx2eNEiEAHT6sMpxXEqjtrroQ+MpdJ3DmA@mail.gmail.com>
 <5565B24B.8080305@wisemo.com>
Message-ID: <CAGbjqfG_DqntH968CXLXRHRpuYfRbqDFQHCzwqctt7Vhxe-Kew@mail.gmail.com>

2015-05-27 14:02 GMT+02:00 Jakob Bohm <jb-openssl at wisemo.com>:
> Just to clarify: The log messages in your original post,
> were those from Android or from the server?

These are from the RADIUS server debug output.

From abramov at bpcbt.com  Wed May 27 13:26:00 2015
From: abramov at bpcbt.com (Pavel Abramov)
Date: Wed, 27 May 2015 16:26:00 +0300
Subject: [openssl-users] External hardware for SSL handshake (overriding
	PreMasterSecret decrypt)
Message-ID: <OF818F4F58.2DC44D05-ON43257E52.0049CA88-43257E52.0049CA99@LocalDomain>

Hi, 

I have a task to use external Security Module to perform RSA functions in my WEB-server (nginx/httpd using OpenSSL for HTTPS).
The goal is to store Server private key components and establish SSL Handshake using Hardware module. It is not an SSL hardware accelerator.

This device has proprietary API (binary protocol over TCP/UDP, a few commands like "generate RSA key pair", "premaster decrypt using key#123").

What is the easiest way to do it? Will be very grateful for keywords/advices.
Should I write my ENGINE ? Or is there any other way? 

I need only 2 functions to perform using hardware: 
- RSA key generation (private component will be saved in hardware module)
- PreMaster decrypt from client during SSL handshake

How to override only these 2 functions?


Thanks in advance!



Pavel


From jb-openssl at wisemo.com  Wed May 27 14:08:52 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 27 May 2015 16:08:52 +0200
Subject: [openssl-users] External hardware for SSL handshake (overriding
 PreMasterSecret decrypt)
In-Reply-To: <OF818F4F58.2DC44D05-ON43257E52.0049CA88-43257E52.0049CA99@LocalDomain>
References: <OF818F4F58.2DC44D05-ON43257E52.0049CA88-43257E52.0049CA99@LocalDomain>
Message-ID: <5565CFF4.8060903@wisemo.com>

On 27/05/2015 15:26, Pavel Abramov wrote:
> Hi,
>
> I have a task to use external Security Module to perform RSA functions in my WEB-server (nginx/httpd using OpenSSL for HTTPS).
> The goal is to store Server private key components and establish SSL Handshake using Hardware module. It is not an SSL hardware accelerator.
>
> This device has proprietary API (binary protocol over TCP/UDP, a few commands like "generate RSA key pair", "premaster decrypt using key#123").
>
> What is the easiest way to do it? Will be very grateful for keywords/advices.
> Should I write my ENGINE ? Or is there any other way?
>
> I need only 2 functions to perform using hardware:
> - RSA key generation (private component will be saved in hardware module)
> - PreMaster decrypt from client during SSL handshake
>
> How to override only these 2 functions?
If there is a generic engine wrapping pkcs11 or a similar
API, it may or may not be easier to implement (or reuse
if already provided) a hardware specific pkcs11 (or
similar) driver.

I am unsure if there is or is not a well maintained
pkcs11 engine for OpenSSL, either in the OpenSSL project
or elsewhere.  Maybe the opensc project has one, but I
don't know if that would be general or specific to opensc
pkcs11 drivers.

Keywords to search for:
pkcs11, pkcs11 engine, opensc project, openssl engine.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150527/87e3acf9/attachment.html>

From abramov at bpcbt.com  Thu May 28 07:00:18 2015
From: abramov at bpcbt.com (Pavel Abramov)
Date: Thu, 28 May 2015 10:00:18 +0300
Subject: [openssl-users] External hardware for SSL handshake (overriding
 PreMasterSecret decrypt)
In-Reply-To: <5565CFF4.8060903@wisemo.com>
References: <5565CFF4.8060903@wisemo.com>,
 <OF818F4F58.2DC44D05-ON43257E52.0049CA88-43257E52.0049CA99@LocalDomain>
Message-ID: <OF897F9433.62B6EFD4-ON43257E53.00267AC5-43257E53.00267AD1@LocalDomain>

thanks! 

Unfortunately there is no pkcs11 wrapper for this device.
There are a few commands implementing RSA operations (generate keyPair, PreMaster decrypt) and I have to use them to perform server-side SSL handshake.



OpenSC looks very interesting for my task.




Pavel


----- "openssl-users" <openssl-users-bounces at openssl.org>: -----
Re: [openssl-users] External hardware for SSL handshake (overriding PreMasterSecret decrypt)

On 27/05/2015 15:26, Pavel Abramov wrote:
Hi, 

I have a task to use external Security Module to perform RSA functions in my WEB-server (nginx/httpd using OpenSSL for HTTPS).
The goal is to store Server private key components and establish SSL Handshake using Hardware module. It is not an SSL hardware accelerator.

This device has proprietary API (binary protocol over TCP/UDP, a few commands like "generate RSA key pair", "premaster decrypt using key#123").

What is the easiest way to do it? Will be very grateful for keywords/advices.
Should I write my ENGINE ? Or is there any other way? 

I need only 2 functions to perform using hardware: 
- RSA key generation (private component will be saved in hardware module)
- PreMaster decrypt from client during SSL handshake

How to override only these 2 functions?

-------------------------------
If there is a generic engine wrapping pkcs11 or a similar 
API, it may or may not be easier to implement (or reuse 
if already provided) a hardware specific pkcs11 (or 
similar) driver.

I am unsure if there is or is not a well maintained 
pkcs11 engine for OpenSSL, either in the OpenSSL project
or elsewhere.? Maybe the opensc project has one, but I 
don't know if that would be general or specific to opensc 
pkcs11 drivers.

Keywords to search for: 
pkcs11, pkcs11 engine, opensc project, openssl engine.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S. ?http://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark. ?Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From ben at an3k.de  Thu May 28 09:13:52 2015
From: ben at an3k.de (Ben Humpert)
Date: Thu, 28 May 2015 11:13:52 +0200
Subject: [openssl-users] Bug in OpenSSL nameConstraints validation
Message-ID: <CAGbjqfEmfXvTaWHAAVRk6PXTT+S7AXTdBO700jTs=zZ4Zx1gyw@mail.gmail.com>

Hi,

Based on https://tools.ietf.org/pdf/draft-wilson-wpkops-browser-processing-02.pdf
section 3.3.1.2. I ran my own tests. I wrote an email
(https://mta.openssl.org/pipermail/openssl-users/2015-May/001387.html)
with the results (attachments in
https://mta.openssl.org/pipermail/openssl-users/2015-May/001388.html).

I observed that OpenSSL s_client always throws "Verify return code: 51
(unsupported name constraint type)" when the name IP is present in the
subjectAltName extension. It does not do so when the name DNS is used
or when no subjectAltName extension is present at all.
In some situations it throws "Verify return code: 47 (permitted
subtree violation)" while there is no violation.

It was also clear that s_client does not check for nameConstraints
violation in CN at all.

However, OpenSSL itself behaves differently. I tried to EAP-TLS with
Android 4.4.4 and always got "certificate unknown" in the RADIUS log.
I did so too with eapol_test and noticed that OpenSSL does not send
the correct error to the server (This is another bug). The client
reported "EAP: Status notification: local TLS alert (param=certificate
unknown)" but additionally "EAP: Status notification: remote
certificate verification (param=permitted subtree violation)" and
"OpenSSL: openssl_handshake - SSL_connect error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed" but
the server side always just received "certificate unknown" which is
like "unknown error" on windows.

With EAP-TLS I observed that (Ubuntu 14.04.2 server with OpenSSL
1.0.1f as well as Android 4.4.4) actually does check for
nameConstraints violation in CN. The used nameConstraints are

permitted;DNS.0=.lan
permitted;DNS.1=.local
permitted;DNS.3=.de
permitted;email.0=.de
permitted;IP.0=10.0.0.0/255.0.0.0
permitted;IP.1=172.16.0.0/255.240.0.0
permitted;IP.2=192.168.0.0/255.255.0.0

and the RADIUS server certificate subject is
"/C=DE/ST=DE-BY/L=Munich/O=Example Company/CN=RADIUS
Server/emailAddress=root at an3k.de" with
subjectAltName="DNS:radius.home.lan,IP:10.11.12.13"

The subtree violation that OpenSSL thinks has happened is not in
emailAddress or in subjectAltName. It is the CN field because "RADIUS
Server" is not ending on .lan .local or .de BUT s_client never
validated the CN field so why does OpenSSL so? Additionally "RADIUS
Server" is neither an IP address nor a DNS name, thus there is
actually no violation. And last but not least the subjectAltName
attribute is present, thus CN should not be validated at all!

This behavior is validated by testing a new server certificate/key but
without subjectAltName and another new cert/key without subjectAltName
but CN set to "radius.home.lan".

Windows XP, Vista, 7, 8 and 10 as well as MacOS and iOS accepted the
initial RADIUS Server certificate. It is just OpenSSL doing some weird
stuff with nameConstraints validation.

Thank you very much in advance!


Best regards,

Ben

From veredz72 at gmail.com  Sun May 31 19:53:49 2015
From: veredz72 at gmail.com (Zvi Vered)
Date: Sun, 31 May 2015 22:53:49 +0300
Subject: [openssl-users] compilation errors in
	openssl-1.0.1g\ssl\ssl_sess.cssl_sess.c
Message-ID: <17BE876CB809464E96A3847ABFEFFF5F@ZviVeredPC>

Dear Members,

In the file ssl_ openssl-1.0.1g\ssl\ssl_sess.cssl_sess.c there are some 
routines that I do not understand their prototpye.

For example:

1. void SSL_CTX_sess_set_new_cb(SSL_CTX *ctx,  int (*cb)(struct ssl_st 
*ssl,SSL_SESSION *sess))

    Return value is void. First parameter is SSL_CTX *ctx. Second parametr 
is a function pointer. Am I right ?

2. int   (*SSL_CTX_sess_get_new_cb(SSL_CTX *ctx) )  (SSL *ssl, SSL_SESSION 
*sess)

    Return value is a function pointer. First parameter is ssl, second is 
sess. Am I right ?

3. void SSL_CTX_sess_set_remove_cb(SSL_CTX *ctx,  void (*cb)(SSL_CTX 
*ctx,SSL_SESSION *sess))

4. void (*SSL_CTX_sess_get_remove_cb(SSL_CTX *ctx))(SSL_CTX * 
ctx,SSL_SESSION *sess)

I?m trying to compile those routines using diab compiler for vxworks6.3 and 
I have a syntax error.

BTW, using this compiler for vxWorks 6.9 (newer compiler) gives no syntax 
error.

Can you help me understand the parameters of those routines ?

Best regards,
Z.V