From Walter.H at mathemainzel.info  Sun Feb  1 17:48:24 2015
From: Walter.H at mathemainzel.info (Walter H.)
Date: Sun, 01 Feb 2015 18:48:24 +0100
Subject: [openssl-users] Strange behaviour with Chrome (client OS = WinXP
	x64) ...
Message-ID: <54CE66E8.4010609@mathemainzel.info>

Hello,

can someone please try the following website with Google Chrome - I use 
the latest release: Version 39.0.2171.99 m -

https://banking.ing-diba.at/   (an electronic Banking site)

with the following policy enabled:

RequireOnlineRevocationChecksForLocalAnchors = 1

with this banking site I get the following error from Google Chrome

"Your connection is not private

Attackers might be trying to steal your information from 
banking.ing-diba.at (for example, passwords, messages, or credit cards)."

with the following banking sites of other banks I have no troubles:

https://ebanking.easybank.at/ or
https://banking.raiffeisen.at/

without enabling the policy above or not setting at all, this banking 
site works, but
the symbol it shows differs; it is the same as if a man-in-the-middle 
like SSL-Bump would be between;

Google chrome uses the same cert store as IE, and with IE there is no 
connection problem,
only another thing the banking site is telling: the browser is out 
dated, of course IE 7
the IE even shows a green bar when connecting to this banking site ...

can someone please tell me what is there special with this banking 
site:   https://banking.ing-diba.at/ ?

I'm using SSL bump with the exception of banking sites, the specific 
part of the squid.conf
looks like this:

acl ssl_bump_domains_bankingsites dstdomain banking.raiffeisen.at 
banking.ing-diba.at ebanking.easybank.at services.kepler.at 
www.kepler.at www.rcb.at
acl ssl_bump_domains_msftupdates dstdomain .update.microsoft.com
ssl_bump none ssl_bump_domains_bankingsites
ssl_bump none ssl_bump_domains_msftupdates
ssl_bump server-first all

sslproxy_cert_error allow all
sslproxy_cipher HIGH:MEDIUM:!AECDH:!ADH:!DSS:!SSLv2:+SSLv3:+3DES:!MD5
sslproxy_flags DONT_VERIFY_PEER,NO_DEFAULT_CA
sslproxy_options NO_SSLv2 NO_SSLv3

sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/local/squid/ssl_db -M 16MB
sslcrtd_children 8

http_port 3128 ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=16MB cert=/etc/squid/cert/squid.pem 
options=NO_SSLv2,SINGLE_DH_USE dhparams=/etc/squid/cert/dhparam.pem

# squid.pem contains both cert+key

I'm using my own CA, this means this SSL-bump CA cert is signed by my 
root CA certificate;

what is missing, wrong, ... so that this one banking site will work ...?

the SSL-bump CA certificate contain this:

Authority Information Access:
                 OCSP - URI:#url-to-ocsp#
                 CA Issuers - URI:#url-to-root-cert#

and

  X509v3 CRL Distribution Points:
                 Full Name:
                   URI:#url-to-crl#

everything is working, the OCSP, the root-cert, and the CRL ...

what causes Google Chrome producing the mentioned error above, when 
activating this mentioned policy?

the question to squid specialists: was it a good idea signing the 
SSL-bump CA certificate with the root certificate of my CA?

Thanks

-- 
Best regards,
Walter H.



-------------- 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/20150201/8ad5988b/attachment.bin>

From dpb795795 at gmail.com  Sun Feb  1 19:37:47 2015
From: dpb795795 at gmail.com (Deepak)
Date: Mon, 2 Feb 2015 01:07:47 +0530
Subject: [openssl-users] OpenSSL 'verify' command and c_ rehash script on
	Cygwin
In-Reply-To: <88F86BCF-3A81-45E2-AC06-1CF379FA9A39@gmail.com>
References: <88F86BCF-3A81-45E2-AC06-1CF379FA9A39@gmail.com>
Message-ID: <CAGg4YWE1o-Em8OE6MAvgtkujHqrsyNcnJQ9VMiF2Z-0dpNFrKQ@mail.gmail.com>

---------- Forwarded message ----------
From: "Deepak" <dpb795795 at gmail.com>
Date: Jan 31, 2015 8:05 AM
Subject: OpenSSL 'verify' command and c_ rehash script on Cygwin
To: <openssl-users at openssl.org>
Cc:

Hi,

Can following behaviour be confirmed as expected?

OpenSSL verify test (test_verify) fails

Env-
c_rehash run using Cygwin. Run c_rehash on /path/to/certs/demo

Cmd -
openssl verify -CApath ../certs/demo ../certs/demo/*.pem

Cause -
Symbolic links (from hash.0 to file.pem) created by c_rehash when run with
Cygwin could not be read by OpenSSL.exe verify command.

Result -
Error 20: could read issuer certificate
OpenSSL.exe fails to establish certificate chain.

Workaround -
Modify c_rehash to use  MS API 'mklink'

Thank You.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150202/bebb4da7/attachment-0001.html>

From rasjv at yandex.com  Sun Feb  1 20:36:20 2015
From: rasjv at yandex.com (Serj)
Date: Sun, 01 Feb 2015 23:36:20 +0300
Subject: [openssl-users] What is the best practise for shutdown SSL
	connections?
Message-ID: <7145121422822980@web21h.yandex.ru>

Hello,

What is the best practise for shutdown SSL connections? When client and server both not mine. For example, http client or server.

I have read:
https://www.openssl.org/docs/ssl/SSL_shutdown.html
https://www.openssl.org/docs/ssl/SSL_set_shutdown.html

I use non-blocking sockets and create sockets manually, then with BIO_new_socket()   and SSL_set_bio() associate them with SSL object.

I have 3 themes and corresponding questions:

1. Return values for SSL_shutdown() 
I never get 2 as a return value! Only 1 as successful then SSL_SENT_SHUTDOWN and SSL_RECEIVED_SHUTDOWN are both set. Maybe something wrong at the documentation?


2. What is the best practise for shutdown SSL connections for CLIENT?

As I understand unidirectional shutdown for client is more suitable, doesn't require special work for waiting "close_notify". But we must be sure that server got a "close_notify" - this is the question! So, the code for CLIENT:
------------------------------------------------
//all data were obtained from the server

SSL_shutdown(ssl);

//here we must be sure that "close_notify" alert is gotten by server
//...

closesocket(s);
------------------------------------------------

How to do this check: server got the "close_notify" alert? What is the best practise?
I see that SSL_get_shutdown() returns SSL_SENT_SHUTDOWN immediatly after we  have called SSL_shutdown() first time, so it only sets the flag after sending "close_notify" but doesn't wait.


3. What is the best practise for shutdown SSL connections for SERVER?
As I understand SERVER must get "close_notify" from client otherwise it will not be able to save a session, am i right? And the session will be invalid in this case.

So, for server the code is:
------------------------------------------------
//all data has been sent to the client

SSL_shutdown(ssl); //will not be superfluous

//here we must wait a "close_notify" alert from client
//we can do this by examine flag SSL_RECEIVED_SHUTDOWN with SSL_get_shutdown()
//...

//and only after this we can safely close the connection
closesocket(s);
------------------------------------------------


I will be very glad if these 3 themes and corresponding questions will not go unanswered!

--
Best Regards,

Serj

From openssl-users at dukhovni.org  Sun Feb  1 20:48:13 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 1 Feb 2015 20:48:13 +0000
Subject: [openssl-users] What is the best practise for shutdown SSL
 connections?
In-Reply-To: <7145121422822980@web21h.yandex.ru>
References: <7145121422822980@web21h.yandex.ru>
Message-ID: <20150201204813.GE8034@mournblade.imrryr.org>

On Sun, Feb 01, 2015 at 11:36:20PM +0300, Serj wrote:

> 1. Return values for SSL_shutdown() 

    0  initially if shutdown alert sent, but not yet received from
       the peer.

> I never get 2 as a return value!

Why do you expect "2"?  [ Note, something is screwing up itemized
lists in the on-line documentation.  Instead of showing item labels,
item numbers are showing up instead. ]  The nroff manpage says:

    RETURN VALUES
       The following return values can occur:

       0   The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional
           shutdown shall be performed.  The output of SSL_get_error(3) may be misleading, as an erroneous
           SSL_ERROR_SYSCALL may be flagged even though no error occurred.

       1   The shutdown was successfully completed. The "close notify" alert was sent and the peer's "close
           notify" alert was received.

       -1  The shutdown was not successful because a fatal error occurred either at the protocol level or a
           connection failure occurred. It can also occur if action is need to continue the operation for
           non-blocking BIOs.  Call SSL_get_error(3) with the return value ret to find out the reason.

> 2. What is the best practise for shutdown SSL connections for CLIENT?

Call ssl_shutdown() and if it returns 0, call it again processing
WANT_READ/WANT_WRITE as required.

-- 
	Viktor.

From rasjv at yandex.com  Sun Feb  1 21:28:12 2015
From: rasjv at yandex.com (Serj)
Date: Mon, 02 Feb 2015 00:28:12 +0300
Subject: [openssl-users] What is the best practise for shutdown SSL
	connections?
In-Reply-To: <20150201204813.GE8034@mournblade.imrryr.org>
References: <7145121422822980@web21h.yandex.ru>
 <20150201204813.GE8034@mournblade.imrryr.org>
Message-ID: <17472611422826092@web4m.yandex.ru>


Hi, Viktor.


01.02.2015, 23:50, "Viktor Dukhovni" <openssl-users at dukhovni.org>:
> On Sun, Feb 01, 2015 at 11:36:20PM +0300, Serj wrote:
>> ?1. Return values for SSL_shutdown()
>
> ????0 ?initially if shutdown alert sent, but not yet received from
> ???????the peer.
>> ?I never get 2 as a return value!
>
> Why do you expect "2"? ?[ Note, something is screwing up itemized
> lists in the on-line documentation. ?Instead of showing item labels,
> item numbers are showing up instead. ] 

Here: https://www.openssl.org/docs/ssl/SSL_shutdown.html I see only this:
-----------------------------------------------------
RETURN VALUES

The following return values can occur:

 1.  The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional shutdown shall be performed. The output of SSL_get_error may be misleading, as an erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred.

 2.  The shutdown was successfully completed. The "close notify" alert was sent and the peer's "close notify" alert was received.

    <0

        The shutdown was not successful because a fatal error occurred either at the protocol level or a connection failure occurred. It can also occur if action is need to continue the operation for non-blocking BIOs. Call SSL_get_error with the return value ret to find out the reason.
-----------------------------------------------------


>?The nroff manpage says:
> ????RETURN VALUES
> ???????The following return values can occur:
>
> ???????0 ??The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional
> ???????????shutdown shall be performed. ?The output of SSL_get_error(3) may be misleading, as an erroneous
> ???????????SSL_ERROR_SYSCALL may be flagged even though no error occurred.
>
> ???????1 ??The shutdown was successfully completed. The "close notify" alert was sent and the peer's "close
> ???????????notify" alert was received.
>
> ???????-1 ?The shutdown was not successful because a fatal error occurred either at the protocol level or a
> ???????????connection failure occurred. It can also occur if action is need to continue the operation for
> ???????????non-blocking BIOs. ?Call SSL_get_error(3) with the return value ret to find out the reason.


Seems to be this is right.
This is exactly what I wanted to see here:  https://www.openssl.org/docs/ssl/SSL_shutdown.html


>> ?2. What is the best practise for shutdown SSL connections for CLIENT?
>
> Call ssl_shutdown() and if it returns 0, call it again processing
> WANT_READ/WANT_WRITE as required.

I use non-blocking sockets. That's why I got -1 as return value after first ssl_shutdown().
I process WANT_READ/WANT_WRITE. But some servers don't send "close_notify", so we never got a 1 as a return value.
We must be sure that server got a "close_notify" - this is the question! What is the best practise for that?



--
Best Regards,

Serj

From rasjv at yandex.com  Sun Feb  1 21:38:26 2015
From: rasjv at yandex.com (Serj)
Date: Mon, 02 Feb 2015 00:38:26 +0300
Subject: [openssl-users] SSL/TLS sessions of client
Message-ID: <17480231422826706@web4m.yandex.ru>

Hello,

I want to use only internal cache right now.

SSL_SESS_CACHE_CLIENT is not set by default. As I understand for client we must: 

1. Set SSL_SESS_CACHE_CLIENT flag with SSL_CTX_set_session_cache_mode()

2. Manually save SSL_SESSION object to be able to choose session with SSL_set_session() next time or we can only save a pointer to SSL_SESSION object with SSL_get1_session() (because all data already will be kept in memory until we explicitly call SSL_SESSION_free()) and then we can give this pointer to the SSL_set_session()?

--
Best Regards,

Serj

From openssl-users at dukhovni.org  Sun Feb  1 22:11:29 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 1 Feb 2015 22:11:29 +0000
Subject: [openssl-users] What is the best practise for shutdown SSL
 connections?
In-Reply-To: <17472611422826092@web4m.yandex.ru>
References: <7145121422822980@web21h.yandex.ru>
 <20150201204813.GE8034@mournblade.imrryr.org>
 <17472611422826092@web4m.yandex.ru>
Message-ID: <20150201221129.GF8034@mournblade.imrryr.org>

On Mon, Feb 02, 2015 at 12:28:12AM +0300, Serj wrote:

> > Why do you expect "2"? ?[ Note, something is screwing up itemized
> > lists in the on-line documentation. ?Instead of showing item labels,
> > item numbers are showing up instead. ] 
> 
> Here: https://www.openssl.org/docs/ssl/SSL_shutdown.html I see only this:
> -----------------------------------------------------
> RETURN VALUES
> 
> The following return values can occur:
> 
>  1.  The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional shutdown shall be performed. The output of SSL_get_error may be misleading, as an erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred.
> 
>  2.  The shutdown was successfully completed. The "close notify" alert was sent and the peer's "close notify" alert was received.
> 
>     <0

The formatting of itemized lists in the on-line HTML is broken.

-- 
	Viktor.

From rasjv at yandex.com  Sun Feb  1 22:32:42 2015
From: rasjv at yandex.com (Serj)
Date: Mon, 02 Feb 2015 01:32:42 +0300
Subject: [openssl-users] What is the best practise for shutdown SSL
	connections?
In-Reply-To: <20150201221129.GF8034@mournblade.imrryr.org>
References: <7145121422822980@web21h.yandex.ru>
 <20150201204813.GE8034@mournblade.imrryr.org>
 <17472611422826092@web4m.yandex.ru>
 <20150201221129.GF8034@mournblade.imrryr.org>
Message-ID: <10257621422829962@web28o.yandex.ru>



02.02.2015, 01:13, "Viktor Dukhovni" <openssl-users at dukhovni.org>:
> The formatting of itemized lists in the on-line HTML is broken.

Ok.

But what about the best practise for shutdown of connection on the client side?
Server can don't send "close notify" alert.

And what about the best practise for shutdown of connection on the server side? Is it mandatory to wait "close_notify" from client to be able to save valid session for this client or not? If server close the connection after all data has been sent to the client and don't receive "close_notify", will be the session kept?


--
Best Regards,

Serj

From openssl-users at dukhovni.org  Sun Feb  1 23:06:46 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 1 Feb 2015 23:06:46 +0000
Subject: [openssl-users] What is the best practise for shutdown SSL
 connections?
In-Reply-To: <10257621422829962@web28o.yandex.ru>
References: <7145121422822980@web21h.yandex.ru>
 <20150201204813.GE8034@mournblade.imrryr.org>
 <17472611422826092@web4m.yandex.ru>
 <20150201221129.GF8034@mournblade.imrryr.org>
 <10257621422829962@web28o.yandex.ru>
Message-ID: <20150201230646.GH8034@mournblade.imrryr.org>

On Mon, Feb 02, 2015 at 01:32:42AM +0300, Serj wrote:

> But what about the best practice for shutdown of connection on the client side?

    http://tools.ietf.org/html/rfc5246#section-7.2.1

> And what about the best practice for shutdown of connection on the server
> side? Is it mandatory to wait "close_notify" from client to be able to
> save valid session for this client or not? If server close the connection
> after all data has been sent to the client and don't receive "close_notify",
> will be the session kept?

    http://tools.ietf.org/html/rfc5246#section-7.2.1

-- 
	Viktor.

From raji.kotamraju at gmail.com  Mon Feb  2 02:18:10 2015
From: raji.kotamraju at gmail.com (Rajeswari K)
Date: Mon, 2 Feb 2015 07:48:10 +0530
Subject: [openssl-users] ECDHE-ECDSA certificate returning with no shared
	cipher error
Message-ID: <CA+mfXPGjF=1gYM85F8BJx8bFu7=J=jDkUtRb7kKkzhoYw5Jh5g@mail.gmail.com>

Hello Openssl users,

Am facing an issue of "no shared cipher" error during SSL Handshake, when
tried to negotiate ECDHE cipher suite.

We are using openssl-1.0.1j version.  Can you please share your thoughts?

Following are the logs during SSL Handshake.

Server has 2 from 0xE29690E0:
0x10B42900:ECDHE-ECDSA-AES256-SHA
0x10B428D0:ECDHE-ECDSA-AES128-SHA
Client sent 2 from 0xE442F5B0:
0x10B42900:ECDHE-ECDSA-AES256-SHA
0x10B428D0:ECDHE-ECDSA-AES128-SHA
rt=0 rte=0 dht=1 ecdht=1 re=1 ree=1 rs=0 ds=0 dhr=0 dhd=0
0:[00000080:00000040:00000089:00000005]0x10B42900:ECDHE-ECDSA-AES256-SHA
rt=0 rte=0 dht=1 ecdht=1 re=1 ree=1 rs=0 ds=0 dhr=0 dhd=0
0:[00000080:00000040:00000089:00000005]0x10B428D0:ECDHE-ECDSA-AES128-SHA


*Feb  2 01:00:46.884: SSL_accept:before/accept initialization
*Feb  2 01:00:46.884: SSL_accept:would block on read in SSLv3 read client
hello B

*Feb  2 01:00:47.892: <<< TLS 1.2 Handshake [length 0092], ClientHello
*Feb  2 01:00:47.892:     01 00 00 8E 03 03 C3 CB 15 58 20 B9 49 1D 73 C7
*Feb  2 01:00:47.892:     F8 C1 4D 31 10 A1 B6 D9 62 9E DF 91 A8 DC 8F 79
*Feb  2 01:00:47.892:     95 79 20 55 AC CF 00 00 06 C0 0A C0 09 00 FF 01
*Feb  2 01:00:47.893:     00 00 5F 00 0B 00 04 03 00 01 02 00 0A 00 34 00
*Feb  2 01:00:47.893:     32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00
*Feb  2 01:00:47.893:     0A 00 16 00 17 00 08 00 06 00 07 00 14 00 15 00
*Feb  2 01:00:47.893:     04 00 05 00 12 00 13 00 01 00 02 00 03 00 0F 00
*Feb  2 01:00:47.893:     10 00 11 00 0D 00 16 00 14 06 01 06 03 05 01 05
*Feb  2 01:00:47.893:     03 04 01 04 03 03 01 03 03 02 01 02 03 00 0F 00
*Feb  2 01:00:47.893:     01 01
*Feb  2 01:00:47.893: TLS client extension "EC point formats" (id=11), len=4

*Feb  2 01:00:47.893:     03 00 01 02
*Feb  2 01:00:47.893: TLS client extension "elliptic curves" (id=10), len=52

*Feb  2 01:00:47.893:     00 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09
*Feb  2 01:00:47.893:     00 0A 00 16 00 17 00 08 00 06 00 07 00 14 00 15
*Feb  2 01:00:47.893:     00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0F
*Feb  2 01:00:47.893:     00 10 00 11
*Feb  2 01:00:47.893: TLS client extension "signature algorithms" (id=13),
len=22

*Feb  2 01:00:47.893:     00 14 06 01 06 03 05 01 05 03 04 01 04 03 03 01
*Feb  2 01:00:47.893:     03 03 02 01 02 03
*Feb  2 01:00:47.893: TLS client extension "heartbeat" (id=15), len=1

*Feb  2 01:00:47.893:     01

*Feb  2 01:00:47.894: >>> TLS 1.2 Alert [length 0002], fatal
handshake_failure
*Feb  2 01:00:47.894:     02 28
*Feb  2 01:00:47.894:
Router#
*Feb  2 01:00:47.894: SSL3 alert write:fatal:handshake failure
*Feb  2 01:00:47.894: SSL_accept:error in SSLv3 read client hello C
*Feb  2 01:00:47.894: 3854049196:error:1408A0C1:SSL
routines:SSL3_GET_CLIENT_HELLO:no shared cipher  s3_srvr.c:1381:


Have updated with temporary ECDH callback during SSL Server initialization.

ECDSA certificate is being signed using openssl commands.

Am not seeing any issue with RSA baesd ciphers. But only with ECDSA based
ciphers having problem on my setup.

Can you please share will the certificate loading is something different
than RSA?

Thanks,
Rajeswari.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150202/c1d6050b/attachment-0001.html>

From rasjv at yandex.com  Mon Feb  2 06:23:19 2015
From: rasjv at yandex.com (Serj)
Date: Mon, 02 Feb 2015 09:23:19 +0300
Subject: [openssl-users] What is the best practise for shutdown SSL
	connections?
In-Reply-To: <20150201230646.GH8034@mournblade.imrryr.org>
References: <7145121422822980@web21h.yandex.ru>
 <20150201204813.GE8034@mournblade.imrryr.org>
 <17472611422826092@web4m.yandex.ru>
 <20150201221129.GF8034@mournblade.imrryr.org>
 <10257621422829962@web28o.yandex.ru>
 <20150201230646.GH8034@mournblade.imrryr.org>
Message-ID: <9843941422858199@web1h.yandex.ru>

Hi, Viktor.

02.02.2015, 02:08, "Viktor Dukhovni" <openssl-users at dukhovni.org>:
> On Mon, Feb 02, 2015 at 01:32:42AM +0300, Serj wrote:
>> ?But what about the best practice for shutdown of connection on the client side?
>
> ????http://tools.ietf.org/html/rfc5246#section-7.2.1

I read RFC. Have read "7.2.1. Closure Alerts" once again.
But this is the normative document. I ask: what in practise in terms of OpenSSL API?

As I already said some servers don't send "close_notify" and just close the connection.

So I think the shutdown algorithm for SSL client must be the following:
-------------------------------------------------------------------------
//...
//all data was obtained from the server

if (SSL_shutdown(ssl)==1)
{
  closesocket(s)
  goto l_shutdown_complete;
}

shutdown(s,SD_SEND);

//set timeout for getting "close_notify" from SERVER
//in the cycle... waiting events from socket or timeout (which comes first):
//
//1. process SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE (in this case only SSL_ERROR_WANT_READ because seems to be SSL_shutdown() send "close_notify" alert to SERVER), call SSL_shutdown() once again and examine it's return value for 1 OR examine SSL_get_shutdown() for (SSL_SENT_SHUTDOWN|SSL_RECEIVED_SHUTDOWN)
//
//2. Wait FD_CLOSE
//
//3. Timeout

//if one of three happens closesocket(s)
-------------------------------------------------------------------------



>> ?And what about the best practice for shutdown of connection on the server
>> ?side? Is it mandatory to wait "close_notify" from client to be able to
>> ?save valid session for this client or not? If server close the connection
>> ?after all data has been sent to the client and don't receive "close_notify",
>> ?will be the session kept?
>
> ????http://tools.ietf.org/html/rfc5246#section-7.2.1

I ask: what in practise in terms of OpenSSL API?
If SERVER close the connection after all data has been sent to the client and will not wait for "close_notify" alert from CLIENT, will be the session kept and valid in OpenSLL API?
I mean, can CLIENT then reuse this session, if it doesn't send "close_notify" alert? Or this session will be invalid?

--
Best Regards,

Serj

From raji.kotamraju at gmail.com  Mon Feb  2 10:04:43 2015
From: raji.kotamraju at gmail.com (Rajeswari K)
Date: Mon, 2 Feb 2015 15:34:43 +0530
Subject: [openssl-users] ECDSA private key load error
Message-ID: <CA+mfXPFysFSFjgOEq5qhoOddgexEbreOuyhvGtLsp09G69rZFw@mail.gmail.com>

Hello Openssl users,

Am facing following issue while am loading ECDSA private key using
EVP_PKCS82PKEY().

I hope am missing some initialization in this regard. Can you please point
me what am i doing wrong.

Steps followed :
Have generated CSR and signed using openssl commans.

Following are the parameters updated in the certificate.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 6 (0x6)
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=ecdsa
        Validity
            Not Before: Feb  2 06:00:29 2015 GMT
            Not After : Feb  2 06:00:29 2016 GMT
        Subject: CN=eccert
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:

                ASN1 OID: prime256v1
        X509v3 extensions:
            X509v3 Subject Key Identifier:

            X509v3 Authority Key Identifier:


            X509v3 Key Usage: critical
                Digital Signature
    Signature Algorithm: ecdsa-with-SHA256

Step 2 : Tried to convert the private key in to PKCS8 format.

Step 3 : Tried to call "EVP_PKCS82PKEY(pkey)".

This function is always returning NULL.

When further checked on the return types, i could see following.

As part of "PKCS8_pkey_get0(&algoid, NULL, NULL, NULL, p8)", the type is of
V_ASN1_OCTET_STRING. (i.e. p8->pkey->type == V_ASN1_OCTET_STRING).


But OBJ_obj2nid(algoid) returning the nid value as 0 i.e. NID_undef.

Due to this, EVP_PKEY_set_type(pkey, OBJ_obj2nid(algoid)) always returns
NULL.

Can you help me to get out of this error.

Thanks,
Rajeswari.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150202/13b5d909/attachment.html>

From gayathri.annur at gmail.com  Mon Feb  2 13:01:51 2015
From: gayathri.annur at gmail.com (Gayathri Manoj)
Date: Mon, 2 Feb 2015 18:31:51 +0530
Subject: [openssl-users] i2d_X509_SIG() in FIPS mode
In-Reply-To: <CAKqy4TNDrr1BDFtx7RAr1Mn-RDwiMSv7AGd3x7TQaPfptOJrpA@mail.gmail.com>
References: <CAKqy4TNDrr1BDFtx7RAr1Mn-RDwiMSv7AGd3x7TQaPfptOJrpA@mail.gmail.com>
Message-ID: <CAKqy4TMOknfZeqTzS7ck3-m9OUK4H70g_uBJRNVOQt1Vhub1jA@mail.gmail.com>

Hi All,

Please let me know shall I need to take care the memory separately for the
fips mode.
Only in FIPS mode i am getting the below error while calling i2d_x509_sig().

Program received signal SIGSEGV, Segmentation fault.
0x00d9d045 in __memcpy_ssse3_rep () from /lib/libc.so.6

Thanks,
Gayathri

On Fri, Jan 30, 2015 at 7:09 PM, Gayathri Manoj <gayathri.annur at gmail.com>
wrote:

> Hi All,
>
> I am getting segfault while using i2d_X509_SIG() in FIPS mode.
> (gdb) bt
> #0  0x01f95045 in __memcpy_ssse3_rep () from /lib/libc.so.6
> #1  0x00466837 in asn1_ex_i2c () from /usr/local/cm/lib/libcrypto.so.1.0.1
> #2  0x00466a36 in asn1_i2d_ex_primitive () from
> /usr/local/cm/lib/libcrypto.so.1.0.1
> #3  0x00466c4c in ASN1_item_ex_i2d () from
> /usr/local/cm/lib/libcrypto.so.1.0.1
> #4  0x0046727a in asn1_template_ex_i2d () from
> /usr/local/cm/lib/libcrypto.so.1.0.1
> #5  0x00466eb3 in ASN1_item_ex_i2d () from
> /usr/local/cm/lib/libcrypto.so.1.0.1
> #6  0x004675f3 in ASN1_item_i2d () from
> /usr/local/cm/lib/libcrypto.so.1.0.1
> #7  0x0045fb3e in i2d_X509_SIG () from /usr/local/cm/lib/libcrypto.so.1.0.1
>
> unsigned char *ptr, *tmp=NULL;
> len=i2d_X509_SIG(&sig,NULL);     --> No issue
> sig.algor->algorithm=OBJ_nid2obj(NID_sha1);
> tmp = (unsigned char*) malloc(512+1);
> ptr=tmp;
> i2d_X509_SIG(&sig, &p);  -->while calling secod time gettign core file.
>
> Its working fine in nonfips mode. But in FIPS getting core files. Please
> let me know how can i solve this issue.
>
> Thanks,
> Gayathri
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150202/615d8916/attachment.html>

From steve at openssl.org  Mon Feb  2 13:08:58 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Mon, 2 Feb 2015 13:08:58 +0000
Subject: [openssl-users] i2d_X509_SIG() in FIPS mode
In-Reply-To: <CAKqy4TMOknfZeqTzS7ck3-m9OUK4H70g_uBJRNVOQt1Vhub1jA@mail.gmail.com>
References: <CAKqy4TNDrr1BDFtx7RAr1Mn-RDwiMSv7AGd3x7TQaPfptOJrpA@mail.gmail.com>
 <CAKqy4TMOknfZeqTzS7ck3-m9OUK4H70g_uBJRNVOQt1Vhub1jA@mail.gmail.com>
Message-ID: <20150202130858.GA14363@openssl.org>

On Mon, Feb 02, 2015, Gayathri Manoj wrote:

> Hi All,
> 
> Please let me know shall I need to take care the memory separately for the
> fips mode.
> Only in FIPS mode i am getting the below error while calling i2d_x509_sig().
> 

I'm not sure how that can happen. The function i2d_X509_SIG isn't part of the
FIPS module so shouldn't be affected. How are you calling i2d_X509_SIG?

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

From curious_freddy at gmsl.co.uk  Mon Feb  2 13:13:40 2015
From: curious_freddy at gmsl.co.uk (Fred)
Date: Mon, 02 Feb 2015 13:13:40 +0000
Subject: [openssl-users] Specify algorithm for openssl smime decrypt
In-Reply-To: <20150106123859.GA5817@openssl.org>
References: <54ABBC1B.3080107@gmsl.co.uk> <20150106123859.GA5817@openssl.org>
Message-ID: <54CF7804.20701@gmsl.co.uk>

On 06/01/2015 12:38, Dr. Stephen Henson wrote:
> On Tue, Jan 06, 2015, Fred wrote:
>> I need to decrypt some  S/MIME content with an invalid key length
>> for the AlgOID specified in the PCKS7 content.
>>
>> AES-256 is specified as the AlgOID, but a key length of 192 bits is
>> being used.
>>
>> Is there anyway to get openssl to decrypt this using the openssl
>> smime command? i.e. override the cipher used so that is uses
>> aes-192-cbc ?
>
> Not using the smime command no. There are ways to handle this either with a
> short program or by using a binary cut+paste using asn1parse.
>
> Another alternative is to use a modified version of OpenSSL which detects this
> and works around the problem.
(snip)

I take it this kind of behaviour is non-standard, which is why OpenSSL 
has a problem?

Does this behaviour (AlgID mismatch) explicitly contravene some RFC or 
is it that this is simply undefined and openssl is just being sensible?

It would be useful to know if the software used to create the encrypted 
software is broken (it would seem it is).

From gayathri.annur at gmail.com  Mon Feb  2 13:45:12 2015
From: gayathri.annur at gmail.com (Gayathri Manoj)
Date: Mon, 2 Feb 2015 19:15:12 +0530
Subject: [openssl-users] i2d_X509_SIG() in FIPS mode
In-Reply-To: <20150202130858.GA14363@openssl.org>
References: <CAKqy4TNDrr1BDFtx7RAr1Mn-RDwiMSv7AGd3x7TQaPfptOJrpA@mail.gmail.com>
 <CAKqy4TMOknfZeqTzS7ck3-m9OUK4H70g_uBJRNVOQt1Vhub1jA@mail.gmail.com>
 <20150202130858.GA14363@openssl.org>
Message-ID: <CAKqy4TM=KAg3YPpo+_HT01B+3h_aKmETfnAT=Ycc8keYkufBEQ@mail.gmail.com>

Hi Steve,

unsigned char *ptr, *tmp=NULL;
 X509_SIG sig;
....
len=i2d_X509_SIG(sig,NULL);
tmp = (unsigned char*) malloc(513);
ptr=tmp;
i2d_X509_SIG(&sig, &ptr);  // here causing problem.

Thanks,
Gayathri

On Mon, Feb 2, 2015 at 6:38 PM, Dr. Stephen Henson <steve at openssl.org>
wrote:

> On Mon, Feb 02, 2015, Gayathri Manoj wrote:
>
> > Hi All,
> >
> > Please let me know shall I need to take care the memory separately for
> the
> > fips mode.
> > Only in FIPS mode i am getting the below error while calling
> i2d_x509_sig().
> >
>
> I'm not sure how that can happen. The function i2d_X509_SIG isn't part of
> the
> FIPS module so shouldn't be affected. How are you calling i2d_X509_SIG?
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> _______________________________________________
> 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/20150202/999e430b/attachment-0001.html>

From openssl-users at dukhovni.org  Mon Feb  2 15:00:51 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 2 Feb 2015 15:00:51 +0000
Subject: [openssl-users] What is the best practise for shutdown SSL
 connections?
In-Reply-To: <9843941422858199@web1h.yandex.ru>
References: <7145121422822980@web21h.yandex.ru>
 <20150201204813.GE8034@mournblade.imrryr.org>
 <17472611422826092@web4m.yandex.ru>
 <20150201221129.GF8034@mournblade.imrryr.org>
 <10257621422829962@web28o.yandex.ru>
 <20150201230646.GH8034@mournblade.imrryr.org>
 <9843941422858199@web1h.yandex.ru>
Message-ID: <20150202150051.GO8034@mournblade.imrryr.org>

On Mon, Feb 02, 2015 at 09:23:19AM +0300, Serj wrote:

> > http://tools.ietf.org/html/rfc5246#section-7.2.1
> 
> I read RFC. Have read "7.2.1. Closure Alerts" once again.
> But this is the normative document. I ask: what in practise in terms of OpenSSL API?
> 
> As I already said some servers don't send "close_notify" and just close the connection.

If you close first, that's OK.  Also OK, if there's an application-level
end-of-data indication.  For example, with SMTP client sends
"QUIT<CRLF>" and server sends "221 Goodbye", there's no need to
explicitly perform an SSL_shutdown().  However, Postfix does it
by the book per TLSv1.0:

	if (SSL_shutdown() == 0)
	    SSL_shutdown()

with appropriate handling of WANT_READ/WANT_WRITE, timeouts, ...

> >> And what about the best practice for shutdown of connection on the server
> >> side? Is it mandatory to wait "close_notify" from client to be able to
> >> save valid session for this client or not? If server close the connection
> >> after all data has been sent to the client and don't receive "close_notify",
> >> will be the session kept?
> >
> > http://tools.ietf.org/html/rfc5246#section-7.2.1
> 
> I ask: what in practise in terms of OpenSSL API?
> If SERVER close the connection after all data has been sent to the client and will not wait for "close_notify" alert from CLIENT, will be the session kept and valid in OpenSLL API?

It should be sufficient for the server to send its close notify
without waiting for a client response.  If the server destroys the
SSL connection without calling SSL_shutdown() I am not sure whether
the session remains cached.

> I mean, can CLIENT then reuse this session, if it doesn't send "close_notify" alert? Or this session will be invalid?

Try it, see what happens.  The client is certainly free to *try*
to the reuse the session, worst-case the server will perform a full
handshake anyway.

-- 
	Viktor.

From steve at openssl.org  Mon Feb  2 15:57:59 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Mon, 2 Feb 2015 15:57:59 +0000
Subject: [openssl-users] i2d_X509_SIG() in FIPS mode
In-Reply-To: <CAKqy4TM=KAg3YPpo+_HT01B+3h_aKmETfnAT=Ycc8keYkufBEQ@mail.gmail.com>
References: <CAKqy4TNDrr1BDFtx7RAr1Mn-RDwiMSv7AGd3x7TQaPfptOJrpA@mail.gmail.com>
 <CAKqy4TMOknfZeqTzS7ck3-m9OUK4H70g_uBJRNVOQt1Vhub1jA@mail.gmail.com>
 <20150202130858.GA14363@openssl.org>
 <CAKqy4TM=KAg3YPpo+_HT01B+3h_aKmETfnAT=Ycc8keYkufBEQ@mail.gmail.com>
Message-ID: <20150202155759.GA8252@openssl.org>

On Mon, Feb 02, 2015, Gayathri Manoj wrote:

> Hi Steve,
> 
> unsigned char *ptr, *tmp=NULL;
>  X509_SIG sig;
> ....
> len=i2d_X509_SIG(sig,NULL);
> tmp = (unsigned char*) malloc(513);
> ptr=tmp;
> i2d_X509_SIG(&sig, &ptr);  // here causing problem.
> 

Well you should really malloc 'len' bytes as it could theoretically exceed
513 (in practice it's unlikely).

How are you setting up "sig"?

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

From openssl-users at dukhovni.org  Mon Feb  2 16:01:49 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 2 Feb 2015 16:01:49 +0000
Subject: [openssl-users] i2d_X509_SIG() in FIPS mode
In-Reply-To: <CAKqy4TM=KAg3YPpo+_HT01B+3h_aKmETfnAT=Ycc8keYkufBEQ@mail.gmail.com>
References: <CAKqy4TNDrr1BDFtx7RAr1Mn-RDwiMSv7AGd3x7TQaPfptOJrpA@mail.gmail.com>
 <CAKqy4TMOknfZeqTzS7ck3-m9OUK4H70g_uBJRNVOQt1Vhub1jA@mail.gmail.com>
 <20150202130858.GA14363@openssl.org>
 <CAKqy4TM=KAg3YPpo+_HT01B+3h_aKmETfnAT=Ycc8keYkufBEQ@mail.gmail.com>
Message-ID: <20150202160149.GT8034@mournblade.imrryr.org>

On Mon, Feb 02, 2015 at 07:15:12PM +0530, Gayathri Manoj wrote:

> unsigned char *ptr, *tmp=NULL;
> X509_SIG sig;
> ....

How is "sig" initialized?

> len=i2d_X509_SIG(sig,NULL);
> tmp = (unsigned char*) malloc(513);

Why 513 and not len?  What is the value of len?

> ptr=tmp;
> i2d_X509_SIG(&sig, &ptr);  // here causing problem.

-- 
	Viktor.

From dthompson at prinpay.com  Tue Feb  3 02:58:53 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Mon, 2 Feb 2015 21:58:53 -0500
Subject: [openssl-users] ECDHE-ECDSA certificate returning with no
	shared	cipher error
In-Reply-To: <CA+mfXPGjF=1gYM85F8BJx8bFu7=J=jDkUtRb7kKkzhoYw5Jh5g@mail.gmail.com>
References: <CA+mfXPGjF=1gYM85F8BJx8bFu7=J=jDkUtRb7kKkzhoYw5Jh5g@mail.gmail.com>
Message-ID: <001801d03f5d$5a54f510$0efedf30$@prinpay.com>

> From: openssl-users On Behalf Of Rajeswari K
> Sent: Sunday, February 01, 2015 21:18

> Am facing an issue of "no shared cipher" error during SSL Handshake, 
> when tried to negotiate ECDHE cipher suite. 
<snip>
> *Feb  2 01:00:47.894: SSL_accept:error in SSLv3 read client hello C
> *Feb  2 01:00:47.894: 3854049196:error:1408A0C1:SSL routines:
> SSL3_GET_CLIENT_HELLO:no shared cipher  s3_srvr.c:1381:

> Have updated with temporary ECDH callback during SSL Server initialization. 

> ECDSA certificate is being signed using openssl commands. 

How was the keypair and CSR generated? In particular, check the 
publickey in the CSR, and thus in the cert, has the curve encoded in 
"named" form (as an OID) not "explicit" form (with all the details of 
prime or polynomial, equation coefficients, base point, and cofactor).




From raji.kotamraju at gmail.com  Tue Feb  3 03:17:26 2015
From: raji.kotamraju at gmail.com (Rajeswari K)
Date: Tue, 3 Feb 2015 08:47:26 +0530
Subject: [openssl-users] ECDHE-ECDSA certificate returning with no
 shared cipher error
In-Reply-To: <001801d03f5d$5a54f510$0efedf30$@prinpay.com>
References: <CA+mfXPGjF=1gYM85F8BJx8bFu7=J=jDkUtRb7kKkzhoYw5Jh5g@mail.gmail.com>
 <001801d03f5d$5a54f510$0efedf30$@prinpay.com>
Message-ID: <CA+mfXPEq2ox_QqH_wMJXDMwCJDnJd3P9qwWT4UQrXJkWc5M=Vw@mail.gmail.com>

Hello Dave,

Thanks for responding. Following is the output printed by openssl

./openssl req -in csr.csr -noout -text

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: CN=eccert/unstructuredName=xxxx
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:

                ASN1 OID: prime256v1
        Attributes:
        Requested Extensions:
            X509v3 Key Usage: critical
                Digital Signature
    Signature Algorithm: ecdsa-with-SHA256


Please share is there any issue with these parameters?

Thanks,
Rajeswari.


On Tue, Feb 3, 2015 at 8:28 AM, Dave Thompson <dthompson at prinpay.com> wrote:

> > From: openssl-users On Behalf Of Rajeswari K
> > Sent: Sunday, February 01, 2015 21:18
>
> > Am facing an issue of "no shared cipher" error during SSL Handshake,
> > when tried to negotiate ECDHE cipher suite.
> <snip>
> > *Feb  2 01:00:47.894: SSL_accept:error in SSLv3 read client hello C
> > *Feb  2 01:00:47.894: 3854049196:error:1408A0C1:SSL routines:
> > SSL3_GET_CLIENT_HELLO:no shared cipher  s3_srvr.c:1381:
>
> > Have updated with temporary ECDH callback during SSL Server
> initialization.
>
> > ECDSA certificate is being signed using openssl commands.
>
> How was the keypair and CSR generated? In particular, check the
> publickey in the CSR, and thus in the cert, has the curve encoded in
> "named" form (as an OID) not "explicit" form (with all the details of
> prime or polynomial, equation coefficients, base point, and cofactor).
>
>
>
> _______________________________________________
> 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/20150203/10c5cca7/attachment.html>

From gayathri.annur at gmail.com  Tue Feb  3 05:26:04 2015
From: gayathri.annur at gmail.com (Gayathri Manoj)
Date: Tue, 3 Feb 2015 10:56:04 +0530
Subject: [openssl-users] i2d_X509_SIG() in FIPS mode
In-Reply-To: <20150202160149.GT8034@mournblade.imrryr.org>
References: <CAKqy4TNDrr1BDFtx7RAr1Mn-RDwiMSv7AGd3x7TQaPfptOJrpA@mail.gmail.com>
 <CAKqy4TMOknfZeqTzS7ck3-m9OUK4H70g_uBJRNVOQt1Vhub1jA@mail.gmail.com>
 <20150202130858.GA14363@openssl.org>
 <CAKqy4TM=KAg3YPpo+_HT01B+3h_aKmETfnAT=Ycc8keYkufBEQ@mail.gmail.com>
 <20150202160149.GT8034@mournblade.imrryr.org>
Message-ID: <CAKqy4TNxqOwYzM7HhGvh7_WFHc02=YV-yYzqgYftdrne=fuyig@mail.gmail.com>

Hi Steve, Viktor,

I have tried with len also, But this also causing seg fault.
my requiremnt is to store  max  2048 bit keys. Hence I  used  length as 512
+1.
currently i ma getting len value = 28514.

X509_SIG sig;
X509_ALGOR algor;
ASN1_OCTET_STRING digest;
ASN1_TYPE parameter;
   ASN1_item_digest() // to get digest details
   sig.algor = &algor;
    sig.algor->algorithm=OBJ_nid2obj(NID_md5);
    parameter.type=V_ASN1_NULL;
    parameter.value.ptr=NULL;
    sig.algor->parameter = &parameter;
    sig.digest = &digest;
    sig.digest->data=(unsigned char*)msg;
    sig.digest->length=datalen;
    len = i2d_X509_SIG(&sig,NULL);


Thanks,
Gayathri

On Mon, Feb 2, 2015 at 9:31 PM, Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Mon, Feb 02, 2015 at 07:15:12PM +0530, Gayathri Manoj wrote:
>
> > unsigned char *ptr, *tmp=NULL;
> > X509_SIG sig;
> > ....
>
> How is "sig" initialized?
>
> > len=i2d_X509_SIG(sig,NULL);
> > tmp = (unsigned char*) malloc(513);
>
> Why 513 and not len?  What is the value of len?
>
> > ptr=tmp;
> > i2d_X509_SIG(&sig, &ptr);  // here causing problem.
>
> --
>         Viktor.
> _______________________________________________
> 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/20150203/6d4f9248/attachment.html>

From goran.hammarback at foxt.com  Tue Feb  3 08:41:02 2015
From: goran.hammarback at foxt.com (=?ISO-8859-1?Q?G=F6ran_Hammarb=E4ck?=)
Date: Tue, 03 Feb 2015 09:41:02 +0100
Subject: [openssl-users] Openssl 1.0.2 evp_test core dumps on Sparc T4,
	solaris 11
Message-ID: <1422952862.19595.105.camel@rydra.dev.top>

I am building openssl 1.0.2 on a number of platforms, and I am having
problems on a virtual Solaris 11.0 machine running on a Sparc T4.
The code builds fine, but the evp_test core dumps.
Here are the last lines of output from the command (test/evp_test
test/evptests.txt):

Testing cipher id-aes256-CCM(encrypt/decrypt)
Key
0000 1b de 32 51 d4 1a 8b 5e a0 13 c1 95 ae 12 8b 21
0010 8b 3e 03 06 37 63 57 07 7e f1 c1 c7 85 48 b9 2e
IV
0000 5b 8e 40 74 6f 6b 98 e0 0f 1d 13 ff 41
Plaintext
0000 53 bd 72 a9 70 89 e3 12 42 2b f7 2e 24 23 77 b3
0010 c6 ee 3e 20 75 38 9b 99 9c 4e f7 f2 8b d2 b8 0a
Ciphertext
0000 9a 5f cc cd b4 cf 04 e7 29 3d 27 75 cc 76 a4 88
0010 f0 42 38 2d 94 9b 43 b7 d6 bb 2b 98 64 78 67 26
AAD
0000 c1 7a 32 51 4e b6 10 3f 32 49 e0 76 d4 c8 71 dc
0010 97 e0 4b 28 66 99 e5 44 91 dc 18 f6 d7 34 d4 c0
Tag
0000 20 24 93 1d 73 bc a4 80 c2 4a 24 ec e6 b6 c2 bf
zsh: segmentation fault (core dumped)  ./test/evp_test test/evptests.txt

pstack:
sol11b% pstack core
core 'core' of 19831:   ./test/evp_test test/evptests.txt
 00000b80 ???????? (6bb20, ffbfec80, ffbfd240, 20, b80, 1)
 ff20c3c4 aes_ccm_cipher (ffbfe240, ffbfd240, ffbfec80, 20, ff20c220,
ff2d8894) + 1a4
 ff205e90 EVP_EncryptUpdate (ffbfe240, ffbfd240, ffbfd22c, ffbfec80, 20,
1) + 110
 00011afc test1    (ff2d8894, ffbfec24, ffffec00, ffbfe2d0, d, 0) + 33c
 00012ed8 main     (ffbfe394, ffffe76c, ffffffff, ffbfe398, ffffe768,
ffffe794) + 658
 0001161c _start   (0, 0, 0, 0, 0, 0) + 5c

If I comment out the aes-256-ccm line in evptests.txt, all other tests
run fine. When I run the same binary on a virtual machine on a Sparc T2,
it works fine. I also tried building the code on the T2, but it still
fails on the T4. ldd on evp_test shows that it is using the correct
1.0.2 versions of libssl.so and libcrypto.so.

I also tried with the openssl-1.0.2-stable-SNAP-20150202 snapshot but
got the same result.

Anyone had similar problems?

G?ran Hammarb?ck


From dfnsonfsduifb at gmx.de  Tue Feb  3 09:00:18 2015
From: dfnsonfsduifb at gmx.de (Johannes Bauer)
Date: Tue, 03 Feb 2015 10:00:18 +0100
Subject: [openssl-users] "openssl dgst" computes wrong HMAC?
Message-ID: <54D08E22.9090904@gmx.de>

Hi list,

when I use OpenSSL I suspect some funny business going on with the HMAC
computation of "openssl dgst" command line tool. Consider:

$ echo -n foobar | openssl dgst -sha256 -hex -hmac aabbcc
(stdin)= 6e74cdc3b72b8b66535b914357c7d656a22acbb1700b4e6de688fd5c091d305c

But

#include <stdio.h>
#include <stdint.h>
#include <stdbool.h>
#include <openssl/hmac.h>
#include "hexdump.h"

int main() {
	uint8_t digest[32];
	HMAC_CTX hmacCtx;
	HMAC_CTX_init(&hmacCtx);
	HMAC_Init_ex(&hmacCtx, "\xaa\xbb\xcc", 3, EVP_sha256(), NULL);
	HMAC_Update(&hmacCtx, "foobar", 6);

	unsigned int length;
	HMAC_Final(&hmacCtx, digest, &length);
	HMAC_CTX_cleanup(&hmacCtx);
	HexDump(digest, 32);
	return 0;
}

Yields 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e

Also, Python:

#!/usr/bin/python3
import Crypto.Hash.HMAC
import Crypto.Hash.SHA256
key = b"\xaa\xbb\xcc"
data = b"foobar"
hmac = Crypto.Hash.HMAC.new(digestmod = Crypto.Hash.SHA256, key = key)
hmac.update(data)
result = hmac.digest()
print("".join("%02x" % (c) for c in result))

Yields 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e

Am I using "openssl dgst" wrong or is it just plain broken?

Regards,
Johannes

From dfnsonfsduifb at gmx.de  Tue Feb  3 09:16:23 2015
From: dfnsonfsduifb at gmx.de (Johannes Bauer)
Date: Tue, 03 Feb 2015 10:16:23 +0100
Subject: [openssl-users] "openssl dgst" computes wrong HMAC?
In-Reply-To: <54D08E22.9090904@gmx.de>
References: <54D08E22.9090904@gmx.de>
Message-ID: <54D091E7.3050802@gmx.de>

On 03.02.2015 10:00, Johannes Bauer wrote:

> when I use OpenSSL I suspect some funny business going on with the HMAC
> computation of "openssl dgst" command line tool. Consider:

Damn, I'm sorry. Forgot to include the version:

OpenSSL 1.0.1f 6 Jan 2014

Regards,
Johannes

From jan.weil at ptb.de  Tue Feb  3 09:57:46 2015
From: jan.weil at ptb.de (jan.weil at ptb.de)
Date: Tue, 3 Feb 2015 10:57:46 +0100
Subject: [openssl-users] Certificate verification fails with latest commits
	(ECDSA)
Message-ID: <OF3707820A.E5987198-ONC1257DE1.00329CA7-C1257DE1.0036BA0E@ptb.de>

Hi,

we have noticed that with the latest Debian wheezy-security update of the 
libssl1.0.0 package sudenly the verification of some of our ECDSA-signed 
certificates failed.

I've looked into this and I've traced it down to the following patch

https://github.com/openssl/openssl/commit/684400ce192dac51df3d3e92b61830a6ef90be3e

which introduces a new statement to check the length of the DER-coded 
signature in ecs_vrf.c:

- if (d2i_ECDSA_SIG(&s, &sigbuf, sig_len) == NULL) goto err;
+ if (d2i_ECDSA_SIG(&s, &p, sig_len) == NULL) goto err;
+ /* Ensure signature uses DER and doesn't have trailing garbage */
+ derlen = i2d_ECDSA_SIG(s, &der);
+ if (derlen != sig_len || memcmp(sigbuf, der, derlen))
+ goto err;

This check fails for some of our certificates and the reason is that 
openssl adds a padding byte for BIGNUMs in crypto/asn1/x_bignum.c if the 
MSB is set. Our encoding does not contain these padding bytes and, 
consequently, the re-encoded version of our certificate signature is two 
bytes longer than before which results in an error.

RFC3279 defines

   Ecdsa-Sig-Value  ::=  SEQUENCE  {
           r     INTEGER,
           s     INTEGER  }

I've looked up the DER encoding rules for INTEGER here

http://www.itu.int/rec/T-REC-X.690-200811-I

and I can't find any evidence that this padding byte is mandatory. See 
below for the relevant paragraph.

So my question is: Would you agree that this is an openssl bug or is the 
padding byte indeed mandatory and we have to adapt the encoding of our 
certificates?

I am attaching one of the certificates for which the verification fails 
along with the root ca's certificate. 

Cheers,

Jan


X.690 INTEGER:

8.3 Encoding of an integer value
8.3.1 The encoding of an integer value shall be primitive. The contents 
octets shall consist of one or more octets.
8.3.2 If the contents octets of an integer value encoding consist of more 
than one octet, then the bits of the first
octet and bit 8 of the second octet:
a) shall not all be ones; and
b) shall not all be zero.
NOTE ? These rules ensure that an integer value is always encoded in the 
smallest possible number of octets.
8.3.3 The contents octets shall be a two's complement binary number equal 
to the integer value, and consisting of
bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second 
octet, followed by bits 8 to 1 of each octet in turn up to
and including the last octet of the contents octets.
NOTE ? The value of a two's complement binary number is derived by 
numbering the bits in the contents octets, starting with bit
1 of the last octet as bit zero and ending the numbering with bit 8 of the 
first octet. Each bit is assigned a numerical value of 2N,
where N is its position in the above numbering sequence. The value of the 
two's complement binary number is obtained by
summing the numerical values assigned to each bit for those bits which are 
set to one, excluding bit 8 of the first octet, and then
reducing this value by the numerical value assigned to bit 8 of the first 
octet if that bit is set to one.





Jan Weil
Physikalisch-Technische Bundesanstalt
Arbeitsgruppe 8.52 Datenkommunikation und -sicherheit
Abbestr. 2 - 12
10587 Berlin
Telefon: (+49 30) 34 81 - 77 64
Fax: (+49 30) 34 81 - 69 77 64
Email: jan.weil at ptb.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GTS001.pem
Type: application/octet-stream
Size: 631 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150203/60eee7d0/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OSM_ROOT.pem
Type: application/octet-stream
Size: 652 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150203/60eee7d0/attachment-0001.obj>

From bbrumley at gmail.com  Tue Feb  3 10:16:06 2015
From: bbrumley at gmail.com (Billy Brumley)
Date: Tue, 3 Feb 2015 12:16:06 +0200
Subject: [openssl-users] "openssl dgst" computes wrong HMAC?
In-Reply-To: <54D08E22.9090904@gmx.de>
References: <54D08E22.9090904@gmx.de>
Message-ID: <CAFeDd5b7bGwCmpmXQrKhHOUuxo_b9MwRR7wwSW9JXiq2vW-nqA@mail.gmail.com>

> $ echo -n foobar | openssl dgst -sha256 -hex -hmac aabbcc
> (stdin)= 6e74cdc3b72b8b66535b914357c7d656a22acbb1700b4e6de688fd5c091d305c

This gets posted every once in a while -- google around. Something
about the hmac switch not doing what you think it's doing.

$ echo -n foobar | openssl dgst -sha256 -mac HMAC -macopt hexkey:aabbcc
(stdin)= 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e

BBB

From rasjv at yandex.com  Tue Feb  3 10:18:20 2015
From: rasjv at yandex.com (Serj)
Date: Tue, 03 Feb 2015 13:18:20 +0300
Subject: [openssl-users] i2d_ d2i_ b2i_ i2b_ functions and EVP_PKEY
Message-ID: <3904601422958700@web2m.yandex.ru>


Hello.

I see many functions have prefixes: i2d_ d2i_ b2i_ i2b_ 

For example:
i2d_PublicKey
i2d_PrivateKey

d2i_PublicKey
d2i_PrivateKey

b2i_PublicKey
b2i_PrivateKey

i2b_PublicKey_bio
i2b_PrivateKey_bio

I think these letters: 'i', 'd', 'b' have some meaning. Can somebody help me to understand what they are mean?


And one more question.
In accordance to: https://www.openssl.org/docs/crypto/EVP_PKEY_new.html, EVP_PKEY structure is used by OpenSSL to store private keys. But there are above functions which use as parameters pointer to EVP_PKEY structure and as they are named they can work with both public and private keys. So the questions are:
1. can we save to EVP_PKEY structure public key not private?
2. can we save to EVP_PKEY structure public and private keys at once?

For example:
EVP_PKEY * pkey;
pkey = EVP_PKEY_new();
RSA * rsa;
rsa = RSA_generate_key(...)
EVP_PKEY_assign_RSA(pkey, rsa);

What key or keys will be in pkey after that?


--
Best Regards,

Serj

From dfnsonfsduifb at gmx.de  Tue Feb  3 11:11:15 2015
From: dfnsonfsduifb at gmx.de (Johannes Bauer)
Date: Tue, 03 Feb 2015 12:11:15 +0100
Subject: [openssl-users] "openssl dgst" computes wrong HMAC?
In-Reply-To: <CAFeDd5b7bGwCmpmXQrKhHOUuxo_b9MwRR7wwSW9JXiq2vW-nqA@mail.gmail.com>
References: <54D08E22.9090904@gmx.de>
 <CAFeDd5b7bGwCmpmXQrKhHOUuxo_b9MwRR7wwSW9JXiq2vW-nqA@mail.gmail.com>
Message-ID: <54D0ACD3.3060608@gmx.de>

On 03.02.2015 11:16, Billy Brumley wrote:
>> $ echo -n foobar | openssl dgst -sha256 -hex -hmac aabbcc
>> (stdin)= 6e74cdc3b72b8b66535b914357c7d656a22acbb1700b4e6de688fd5c091d305c
> 
> This gets posted every once in a while -- google around. Something
> about the hmac switch not doing what you think it's doing.
> 
> $ echo -n foobar | openssl dgst -sha256 -mac HMAC -macopt hexkey:aabbcc
> (stdin)= 985343745ee86b452c7c0b327171829c77e1a022f423d95156b52fa22083db8e

Ah, interesting. I did google the issue, but only found post of people
who didn't realize that echo without "-n" appends a newline.

If this topic really comes up every now and then, I'd still suggest
updating the help page to clarify while remaining identical behavior.
Currently it reads "-hmac arg    set the HMAC key to arg". I would
suggest "-hmac str    set the HMAC key to the string str".

Regards,
Johannes


From rasjv at yandex.com  Tue Feb  3 11:21:54 2015
From: rasjv at yandex.com (Serj)
Date: Tue, 03 Feb 2015 14:21:54 +0300
Subject: [openssl-users] i2d_ d2i_ b2i_ i2b_ functions and EVP_PKEY
In-Reply-To: <3904601422958700@web2m.yandex.ru>
References: <3904601422958700@web2m.yandex.ru>
Message-ID: <16531331422962514@web1o.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150203/3cb7923f/attachment.html>

From steve at openssl.org  Tue Feb  3 12:41:12 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 3 Feb 2015 12:41:12 +0000
Subject: [openssl-users] Certificate verification fails with latest
 commits (ECDSA)
In-Reply-To: <OF3707820A.E5987198-ONC1257DE1.00329CA7-C1257DE1.0036BA0E@ptb.de>
References: <OF3707820A.E5987198-ONC1257DE1.00329CA7-C1257DE1.0036BA0E@ptb.de>
Message-ID: <20150203124112.GA21538@openssl.org>

On Tue, Feb 03, 2015, jan.weil at ptb.de wrote:

> 
> This check fails for some of our certificates and the reason is that 
> openssl adds a padding byte for BIGNUMs in crypto/asn1/x_bignum.c if the 
> MSB is set. Our encoding does not contain these padding bytes and, 
> consequently, the re-encoded version of our certificate signature is two 
> bytes longer than before which results in an error.
> 
> RFC3279 defines
> 
>    Ecdsa-Sig-Value  ::=  SEQUENCE  {
>            r     INTEGER,
>            s     INTEGER  }
> 
> I've looked up the DER encoding rules for INTEGER here
> 
> http://www.itu.int/rec/T-REC-X.690-200811-I
> 
> and I can't find any evidence that this padding byte is mandatory. See 
> below for the relevant paragraph.
> 

The MSB is effectively a sign bit but the explanation in the standard isn't
very clear. If you take your example of GTS001.pem and do:

  openssl asn1parse -in GTS001.pem -strparse 367 -out sig.der

It will parse out the Ecdsa-Sig-Value field and you get:

    0:d=0  hl=2 l=  52 cons: SEQUENCE          
    2:d=1  hl=2 l=  24 prim: INTEGER           :-0739E1C1762E2E3E1D4480425633EA0BB669CE784DC3ACCB
   28:d=1  hl=2 l=  24 prim: INTEGER           :-332658917A3B05831D91176C0512CF91C617819E1A7CF14B

Note the two - signs.

Just to show it isn't just OpenSSL: if you use dumpasn1 on the output (sig.der)
you get:

  0  52: SEQUENCE {
  2  24:   INTEGER
       :     F8 C6 1E 3E 89 D1 D1 C1 E2 BB 7F BD A9 CC 15 F4
       :     49 96 31 87 B2 3C 53 35
       :     Error: Integer has a negative value.
 28  24:   INTEGER
       :     CC D9 A7 6E 85 C4 FA 7C E2 6E E8 93 FA ED 30 6E
       :     39 E8 7E 61 E5 83 0E B5
       :     Error: Integer has a negative value.
       :   }

>From your quote:

> The value of the 
> two's complement binary number is obtained by
> summing the numerical values assigned to each bit for those bits which are 
> set to one, excluding bit 8 of the first octet, and then
> reducing this value by the numerical value assigned to bit 8 of the first 
> octet if that bit is set to one.
> 

What this is saying is that if the MSB is one you subtract that value from
the result.

For example 0x80 without the MSB represents '0' the MSB represents 0x80 and
you subtract that resulting in -0x80. That's why you need the 0 padding byte
prepended if the MSB is one.

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

From Andre.Wendel at bmw.de  Tue Feb  3 12:32:13 2015
From: Andre.Wendel at bmw.de (Andre.Wendel at bmw.de)
Date: Tue, 3 Feb 2015 12:32:13 +0000
Subject: [openssl-users] Support of HMAC-Based ciphersuites (RFC6367) in
	openssl 1.0.1l
Message-ID: <08BE65B36BBC1B4E907E2015603B0DF30B55B4@smucm55b>

Hello everybody,

today i tried to rework the cipher suites of my system and I wanted to integrate the Camellia HMAC-Based ciphersuites from RFC6367, extending TLS v1.2. I tried to find out, which ciphers are supported within the newest openssl version 1.0.1l, but openssl did not have any ciphers of the RFC included, because ./openssl ciphers -v 'CAMELLIA' did only print the following ciphers for SSLv3

DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(256) Mac=SHA1
ADH-CAMELLIA256-SHA     SSLv3 Kx=DH       Au=None Enc=Camellia(256) Mac=SHA1
CAMELLIA256-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(128) Mac=SHA1
ADH-CAMELLIA128-SHA     SSLv3 Kx=DH       Au=None Enc=Camellia(128) Mac=SHA1
CAMELLIA128-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1

Is there a special compiler option needed to enable the HMAC ciphersuites, or did I missed to do any configuration?

Thanks & Best regards,
Andr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150203/5a332ddb/attachment.html>

From Michael.Wojcik at microfocus.com  Tue Feb  3 13:03:34 2015
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 3 Feb 2015 13:03:34 +0000
Subject: [openssl-users] i2d_ d2i_ b2i_ i2b_ functions and EVP_PKEY
In-Reply-To: <16531331422962514@web1o.yandex.ru>
References: <3904601422958700@web2m.yandex.ru>
 <16531331422962514@web1o.yandex.ru>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088013447444E@Rock-Exchange1.microfocus.com>

"i" is an abbreviation for "internal", meaning OpenSSL's internal format.
"2" means "to".
"d" means "DER".
"b" means "blob", and refers to a "key blob" format used by Microsoft. (That's based on the OpenSSL source code; I haven't looked into the actual provenance of this blob format.)

It appears the key blob format typically uses the "PVK" file extension.

Lots of things in OpenSSL aren't documented. It's not strange at all - programmers tend to write code first, documentation second (or later). This is true of a great many open-source projects, and many commercial ones as well. If you want something documented, your best bet is to research it in the code and write the documentation yourself.


Regarding your second question: EVP_KEY is defined in evp.h, where we see it contains a pointer to one of the specific key types, such as rsa_st. rsa_st is defined in rsa.h, and if we look there we see that it contains all the RSA parameters, so it implicitly contains both the public and private key.

Michael Wojcik
Technology Specialist, Micro Focus


From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Serj
Sent: Tuesday, February 03, 2015 06:22
To: openssl-users at openssl.org
Subject: Re: [openssl-users] i2d_ d2i_ b2i_ i2b_ functions and EVP_PKEY


I have found some info and now some questions more clear for me. But still have 2 questions...

i2d_ functions write the DER representation of the object into a buffer.
d2i_ functions read the DER representation of the object from a buffer and creates the appropriate object in memory.

1. What is b2i_ and i2b_ functions?


EVP_PKEY structure can hold public or private key. It's strangely why there is no this info in the official documentation on www.openssl.org<http://www.openssl.org>

2. Can EVP_PKEY structure hold both private and public keys at once?

I have some example of code and there is a use of EVP_PKEY in this manner, that's why I am asking.


03.02.2015, 13:21, "Serj" <rasjv at yandex.com<mailto:rasjv at yandex.com>>:
> Hello.
>
> I see many functions have prefixes: i2d_ d2i_ b2i_ i2b_
>
> For example:
> i2d_PublicKey
> i2d_PrivateKey
>
> d2i_PublicKey
> d2i_PrivateKey
>
> b2i_PublicKey
> b2i_PrivateKey
>
> i2b_PublicKey_bio
> i2b_PrivateKey_bio
>
> I think these letters: 'i', 'd', 'b' have some meaning. Can somebody help me to understand what they are mean?
>
> And one more question.
> In accordance to: https://www.openssl.org/docs/crypto/EVP_PKEY_new.html, EVP_PKEY structure is used by OpenSSL to store private keys. But there are above functions which use as parameters pointer to EVP_PKEY structure and as they are named they can work with both public and private keys. So the questions are:
> 1. can we save to EVP_PKEY structure public key not private?
> 2. can we save to EVP_PKEY structure public and private keys at once?
>
> For example:
> EVP_PKEY * pkey;
> pkey = EVP_PKEY_new();
> RSA * rsa;
> rsa = RSA_generate_key(...)
> EVP_PKEY_assign_RSA(pkey, rsa);
>
> What key or keys will be in pkey after that?


--
Best Regards,

Serj


Click here<https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==> to report this email as spam.


This message has been scanned for malware by Websense. www.websense.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150203/82008e9c/attachment.html>

From jan.weil at ptb.de  Tue Feb  3 14:19:50 2015
From: jan.weil at ptb.de (jan.weil at ptb.de)
Date: Tue, 3 Feb 2015 15:19:50 +0100
Subject: [openssl-users] Certificate verification fails with latest
	commits (ECDSA)
In-Reply-To: <20150203124112.GA21538@openssl.org>
References: <OF3707820A.E5987198-ONC1257DE1.00329CA7-C1257DE1.0036BA0E@ptb.de>
 <20150203124112.GA21538@openssl.org>
Message-ID: <OF0808171C.17D401D3-ONC1257DE1.004BCE64-C1257DE1.004EB8D8@ptb.de>

Hi Steve,

thanks a lot for your quick response and for the clarification.


> Von: "Dr. Stephen Henson" <steve at openssl.org>
> The MSB is effectively a sign bit but the explanation in the standard 
isn't
> very clear. If you take your example of GTS001.pem and do:
> 
>   openssl asn1parse -in GTS001.pem -strparse 367 -out sig.der
> 
> It will parse out the Ecdsa-Sig-Value field and you get:
> 
>     0:d=0  hl=2 l=  52 cons: SEQUENCE 
>     2:d=1  hl=2 l=  24 prim: INTEGER 
> :-0739E1C1762E2E3E1D4480425633EA0BB669CE784DC3ACCB
>    28:d=1  hl=2 l=  24 prim: INTEGER 
> :-332658917A3B05831D91176C0512CF91C617819E1A7CF14B
> 
> Note the two - signs.

> [...]

> What this is saying is that if the MSB is one you subtract that value 
from
> the result.
> 
> For example 0x80 without the MSB represents '0' the MSB represents 0x80 
and
> you subtract that resulting in -0x80. 

Well, yes, that's how two's complement works.

> That's why you need the 0 padding byte prepended if the MSB is one.

The actual problem is that I have totally ignored the mathematics of ECs 
and it only occured to me when I read your reply that the values of r and 
s, as far as i understand now, can never be negative.

Not so good news for our certificates...

Thanks again!

Jan


Jan Weil
Physikalisch-Technische Bundesanstalt
Arbeitsgruppe 8.52 Datenkommunikation und -sicherheit
Abbestr. 2 - 12
10587 Berlin
Telefon: (+49 30) 34 81 - 77 64
Fax: (+49 30) 34 81 - 69 77 64
Email: jan.weil at ptb.de

From susumu.sai.2006 at gmail.com  Tue Feb  3 15:54:42 2015
From: susumu.sai.2006 at gmail.com (Susumu Sai)
Date: Tue, 3 Feb 2015 10:54:42 -0500
Subject: [openssl-users] OpenSSL FIPS Object Module 1.* is vulnerable to
	CVE-2014-3570?
Message-ID: <CAJS8VixKbf=E0-2Xn4X9y+26ezVQg8y8v54Lt3SqfPczeC2c-g@mail.gmail.com>

CVE-2014-3570 is fixed in 0.9.8ze. Does the BN_sqr implementation in FIPS
Object Module 1.* also need to be fixed?

If I run 0.9.8ze on FIPS mode with using FIPS Object Module 1.x, am I
vulnerable to the CVE-2014-3570 attacks?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150203/99532581/attachment.html>

From tsutton at cspeed.com  Tue Feb  3 17:39:41 2015
From: tsutton at cspeed.com (Sutton, Timothy)
Date: Tue, 3 Feb 2015 12:39:41 -0500
Subject: [openssl-users] Windows Embedded Compact 7 OpenSSL
Message-ID: <CAKLXFtuGpN0Hicu1ogcRQaGHSd+iPY1BK1e5uEiZwyGo-h9-9w@mail.gmail.com>

I am trying to get OpenSSL to build for Windows Embebbed Compact 7 using
Visual Studio 2008. Is there a write up some wheres that I have missed for
doing this? I am having troubles finding much of anything in the way of
support for doing this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150203/0b871dff/attachment.html>

From rsalz at openssl.org  Tue Feb  3 22:02:31 2015
From: rsalz at openssl.org (Rich Salz)
Date: Tue, 3 Feb 2015 17:02:31 -0500
Subject: [openssl-users] The evolution of the 'master' branch
Message-ID: <20150203220231.GA12587@openssl.org>

As we've already said, we are moving to making most OpenSSL data
structures opaque. We deliberately used a non-specific term. :)
As of Matt's commit of the other day, this is starting to happen
now.  We know this will inconvenience people as some applications
no longer build.  We want to work with maintainers to help them
migrate, as we head down this path.

We have a wiki page to discuss this effort.  It will eventually include
tips on migration, application and code updates, and anything else the
community finds useful.  Please visit:

	http://wiki.openssl.org/index.php/1.1_API_Changes

Thanks.

From rasjv at yandex.com  Tue Feb  3 23:07:31 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Wed, 04 Feb 2015 02:07:31 +0300
Subject: [openssl-users] i2d_ d2i_ b2i_ i2b_ functions and EVP_PKEY
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088013447444E@Rock-Exchange1.microfocus.com>
References: <3904601422958700@web2m.yandex.ru>
 <16531331422962514@web1o.yandex.ru>
 <B550B44BF8AF314BB00C4E2AC1C18088013447444E@Rock-Exchange1.microfocus.com>
Message-ID: <27158051423004851@web20m.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150204/f26610ba/attachment.html>

From rasjv at yandex.com  Tue Feb  3 23:12:02 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Wed, 04 Feb 2015 02:12:02 +0300
Subject: [openssl-users] What is the best practise for shutdown SSL
	connections?
In-Reply-To: <20150202150051.GO8034@mournblade.imrryr.org>
References: <7145121422822980@web21h.yandex.ru>
 <20150201204813.GE8034@mournblade.imrryr.org>
 <17472611422826092@web4m.yandex.ru>
 <20150201221129.GF8034@mournblade.imrryr.org>
 <10257621422829962@web28o.yandex.ru>
 <20150201230646.GH8034@mournblade.imrryr.org>
 <9843941422858199@web1h.yandex.ru>
 <20150202150051.GO8034@mournblade.imrryr.org>
Message-ID: <27160441423005122@web20m.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150204/0d7bc40f/attachment.html>

From dpb795795 at gmail.com  Wed Feb  4 08:23:47 2015
From: dpb795795 at gmail.com (Deepak)
Date: Wed, 4 Feb 2015 13:53:47 +0530
Subject: [openssl-users] Openssl verify command and c_rehash
Message-ID: <CAGg4YWEWL7keYTn_2_TGsmCV2rYspZU1spMJo+xE2wCHXs5ZBw@mail.gmail.com>

Hi,

Can following behaviour be confirmed as expected?

OpenSSL verify test (test_verify) fails

Env-
c_rehash run using Cygwin. Run c_rehash on /path/to/certs/demo

Cmd -
openssl verify -CApath ../certs/demo ../certs/demo/*.pem

Cause -
Symbolic links (from hash.0 to file.pem) created by c_rehash when run with
Cygwin could not be read by OpenSSL.exe verify command.

Result -
Error 20: could read issuer certificate
OpenSSL.exe fails to establish certificate chain.

Workaround -
Modify c_rehash to use  MS API 'mklink'

Thank You.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150204/193e3cb3/attachment.html>

From dthompson at prinpay.com  Wed Feb  4 12:39:15 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Wed, 4 Feb 2015 07:39:15 -0500
Subject: [openssl-users] ECDHE-ECDSA certificate returning with no
	shared cipher error
In-Reply-To: <CA+mfXPEq2ox_QqH_wMJXDMwCJDnJd3P9qwWT4UQrXJkWc5M=Vw@mail.gmail.com>
References: <CA+mfXPGjF=1gYM85F8BJx8bFu7=J=jDkUtRb7kKkzhoYw5Jh5g@mail.gmail.com>
 <001801d03f5d$5a54f510$0efedf30$@prinpay.com>
 <CA+mfXPEq2ox_QqH_wMJXDMwCJDnJd3P9qwWT4UQrXJkWc5M=Vw@mail.gmail.com>
Message-ID: <001a01d04077$979c6780$c6d53680$@prinpay.com>

> From: openssl-users On Behalf Of Rajeswari K
> Sent: Monday, February 02, 2015 22:17

> Thanks for responding. Following is the output printed by openssl

> ./openssl req -in csr.csr -noout -text 
<snip>
>        Subject Public Key Info:
>            Public Key Algorithm: id-ecPublicKey
>                Public-Key: (256 bit)
>                pub:
>                   
>                ASN1 OID: prime256v1

Yes, that is named form. Then I don't know what the problem is.

Generic debugging advice, if you haven't tried these already:

Does the problem occur with s_client to your server?

Does the problem occur with s_client to s_server using the same 
cert&key, cipherlist (if not default) and same or reasonable tmp-ECDH?

Actually, that's a thought. You said your server uses tmp-ECDH callback; 
does that (always) provide a curve/parameters object that *has* an OID 
which maps to one of the TLS standard curves in 4492 (and one specified 
in the client hello but your earlier trace looked like the client specified all).
s_server *only* supports named curves (and defaults to p256).




From jb-openssl at wisemo.com  Wed Feb  4 12:54:42 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 04 Feb 2015 13:54:42 +0100
Subject: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL
 1.0.1l
In-Reply-To: <001301d038cf$a1dee6f0$e59cb4d0$@sales@OnLine.fr>
References: <f2171bb27bd95da983aac552189cf15d@smtp.hushmail.com>
 <004e01d037c1$61615950$24240bf0$@sales@OnLine.fr>
 <663f33f338a983a22e3c6aee5f400219@smtp.hushmail.com>
 <000601d0388e$e06bff70$a143fe50$@sales@OnLine.fr>
 <c61dcfa4b445cf3451f32fb867d20b1e@smtp.hushmail.com>
 <001301d038cf$a1dee6f0$e59cb4d0$@sales@OnLine.fr>
Message-ID: <54D21692.7010108@wisemo.com>

Following up on this somewhat old thread just to correct some
misunderstandings about the nature of the Windows APIs.

On 25/01/2015 19:49, Michel SALES wrote:
> Hi Avery,
>
>> In the code I sent over before, I was calling CloseHandle on the thread:
>> HANDLE h1=CreateThread(0,0,thread1,0,0,&t1);  if(h1==0) { return
> 0; } CloseHandle(h1);
>
> Yes, but you were trying to close the handle of a thread which was still
> running !
> I have not checked what happens in this case.
Just FYI: On Windows (unlike the fork-like semantics of POSIX
pthreads), the handle to a thread is just one of N references
to the thread object, another of which is the actual fact of
the thread still running.  As long as at least one such
reference exists, the kernel resources associated with the
thread (an ETHREAD structure, the thread identifier etc.)
remain in use.  The act of waiting for and/or closing the
handle has no direct relationship to thread exit.  So closing
an unwanted thread handle right after thread creation is a
normal and correct resource saving coding technique.
> I am not sure to fully understand what your are doing now, but with the
> modified version I've sent to you, _CrtDumpMemoryLeaks() doesn't report any
> problem on my Windows 7 64 bits machine.
Note that _Crt functions only check internal state in the
per-compiler C runtime, they cannot check for leaks of OS
level objects, that requires OS tools, such as those
available via Task manager (taskmgr.exe) and the OS level
debuggers (WinDbg.exe, GFlags.exe etc.).

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 Feb  4 14:55:58 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 04 Feb 2015 15:55:58 +0100
Subject: [openssl-users] i2d_X509_SIG() in FIPS mode
In-Reply-To: <CAKqy4TNxqOwYzM7HhGvh7_WFHc02=YV-yYzqgYftdrne=fuyig@mail.gmail.com>
References: <CAKqy4TNDrr1BDFtx7RAr1Mn-RDwiMSv7AGd3x7TQaPfptOJrpA@mail.gmail.com>
 <CAKqy4TMOknfZeqTzS7ck3-m9OUK4H70g_uBJRNVOQt1Vhub1jA@mail.gmail.com>
 <20150202130858.GA14363@openssl.org>
 <CAKqy4TM=KAg3YPpo+_HT01B+3h_aKmETfnAT=Ycc8keYkufBEQ@mail.gmail.com>
 <20150202160149.GT8034@mournblade.imrryr.org>
 <CAKqy4TNxqOwYzM7HhGvh7_WFHc02=YV-yYzqgYftdrne=fuyig@mail.gmail.com>
Message-ID: <54D232FE.70705@wisemo.com>

On 03/02/2015 06:26, Gayathri Manoj wrote:
> Hi Steve, Viktor,
>
> I have tried with len also, But this also causing seg fault.
> my requiremnt is to store  max  2048 bit keys. Hence I  used length as 
> 512 +1.
> currently i ma getting len value = 28514.
>
> X509_SIG sig;
> X509_ALGOR algor;
> ASN1_OCTET_STRING digest;
> ASN1_TYPE parameter;
>    ASN1_item_digest() // to get digest details
>    sig.algor = &algor;
>     sig.algor->algorithm=OBJ_nid2obj(NID_md5);
There is the problem!  FIPS does not allow use of MD5,
probably never has.  Have you checked if thisreturned
NULL to indicate an error finding the MD5 OID?
>     parameter.type=V_ASN1_NULL;
>     parameter.value.ptr=NULL;
>     sig.algor->parameter = &parameter;
>     sig.digest = &digest;
>     sig.digest->data=(unsigned char*)msg;
>     sig.digest->length=datalen;
>     len = i2d_X509_SIG(&sig,NULL);
Have you checked if this returns a negative value to
indicate an error?
>
> On Mon, Feb 2, 2015 at 9:31 PM, Viktor Dukhovni 
> <openssl-users at dukhovni.org <mailto:openssl-users at dukhovni.org>> wrote:
>
>     On Mon, Feb 02, 2015 at 07:15:12PM +0530, Gayathri Manoj wrote:
>
>     > unsigned char *ptr, *tmp=NULL;
>     > X509_SIG sig;
>     > ....
>
>     How is "sig" initialized?
>
>     > len=i2d_X509_SIG(sig,NULL);
>     > tmp = (unsigned char*) malloc(513);
>
>     Why 513 and not len?  What is the value of len?
>
>     > ptr=tmp;
>     > i2d_X509_SIG(&sig, &ptr);  // here causing problem.
>
Note to OpenSSL documentation team: The documentation for
the OpenSSL X509_SIG data type is circular at best, and
refers to PKCS#1 only by name, not by its currently
available location (one or more RFCs).   Also there are
apparently no documented functions using X509_SIG other
than to read/write/encode/decode the structure, the closest
I could find were some undocumented functions in pkcs12.h .


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 steve at openssl.org  Wed Feb  4 15:26:49 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 4 Feb 2015 15:26:49 +0000
Subject: [openssl-users] i2d_X509_SIG() in FIPS mode
In-Reply-To: <CAKqy4TNxqOwYzM7HhGvh7_WFHc02=YV-yYzqgYftdrne=fuyig@mail.gmail.com>
References: <CAKqy4TNDrr1BDFtx7RAr1Mn-RDwiMSv7AGd3x7TQaPfptOJrpA@mail.gmail.com>
 <CAKqy4TMOknfZeqTzS7ck3-m9OUK4H70g_uBJRNVOQt1Vhub1jA@mail.gmail.com>
 <20150202130858.GA14363@openssl.org>
 <CAKqy4TM=KAg3YPpo+_HT01B+3h_aKmETfnAT=Ycc8keYkufBEQ@mail.gmail.com>
 <20150202160149.GT8034@mournblade.imrryr.org>
 <CAKqy4TNxqOwYzM7HhGvh7_WFHc02=YV-yYzqgYftdrne=fuyig@mail.gmail.com>
Message-ID: <20150204152649.GA18571@openssl.org>

On Tue, Feb 03, 2015, Gayathri Manoj wrote:

> Hi Steve, Viktor,
> 
> I have tried with len also, But this also causing seg fault.
> my requiremnt is to store  max  2048 bit keys. Hence I  used  length as 512
> +1.
> currently i ma getting len value = 28514.
> 
> X509_SIG sig;
> X509_ALGOR algor;
> ASN1_OCTET_STRING digest;
> ASN1_TYPE parameter;
>    ASN1_item_digest() // to get digest details
>    sig.algor = &algor;
>     sig.algor->algorithm=OBJ_nid2obj(NID_md5);
>     parameter.type=V_ASN1_NULL;
>     parameter.value.ptr=NULL;
>     sig.algor->parameter = &parameter;
>     sig.digest = &digest;
>     sig.digest->data=(unsigned char*)msg;
>     sig.digest->length=datalen;
>     len = i2d_X509_SIG(&sig,NULL);
> 

You should only use a pointer to an ASN.1 structure and not the actual
structure itself because you can end up with various fields taking odd
uninitialised values (I suspect the fact you haven't initialised "flags" is
at least one problem here. A complete set of accessor functions unfortnately
doesn't currently exist for X509_SIG so you have to access some internals.

In outline something like this:

X509_SIG *sig = X509_SIG_new();
X509_ALGOR_set0(sig->algor, OBJ_nid2obj(nid), V_ASN1_NULL, NULL);
ASN1_STRING_set(sig->digest, digest, digestlen);

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

From jb-openssl at wisemo.com  Wed Feb  4 15:27:28 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 04 Feb 2015 16:27:28 +0100
Subject: [openssl-users] Certificate verification fails with latest
 commits (ECDSA)
In-Reply-To: <20150203124112.GA21538@openssl.org>
References: <OF3707820A.E5987198-ONC1257DE1.00329CA7-C1257DE1.0036BA0E@ptb.de>
 <20150203124112.GA21538@openssl.org>
Message-ID: <54D23A60.7090902@wisemo.com>

Summary of thread so far: The latest security update enforces
that any inherently unsigned BIGNUM must be encoded as a non-
negative DER INTEGER (which has a leading 0 byte if the most
significant bit of the first byte would otherwise be set).

It is a well known historic bug that some other ASN.1
libraries incorrectly treat the DER/BER INTEGER type as
unsigned when encoding and decoding inherently unsigned
numbers, and that such libraries will thus accept the correct
encoding (leading 0 byte) as a non-canonical BER encoding
(and thankfully forget to normalize it to the wrong form),
while producing an incorrect encoding without the leading 0
byte.

Historically, OpenSSL (and probably some other ASN.1 libraries
too) have intentionally tolerated this specific incorrect
encoding, but the new security update now consistently rejects
it.  Would it reintroduce the related security issue to
explicitly tolerate the alternative encoding, perhaps by
allowing the EC code to accept negative numbers as their
unsigned encoding equivalents, while preserving the signed
form when round-tripping BER to BN to DER.  (This of cause
would still fail if the most significant 9 bits were all 1,
e.g. 0xFF8...., but that would still be 256 times rarer).

I am assuming without checking, that i2d_ASN1_INTEGER
already handles negative values.

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 Feb  4 15:48:18 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 04 Feb 2015 16:48:18 +0100
Subject: [openssl-users] The evolution of the 'master' branch
In-Reply-To: <20150203220231.GA12587@openssl.org>
References: <20150203220231.GA12587@openssl.org>
Message-ID: <54D23F42.3060203@wisemo.com>

On 03/02/2015 23:02, Rich Salz wrote:
> As we've already said, we are moving to making most OpenSSL data
> structures opaque. We deliberately used a non-specific term. :)
> As of Matt's commit of the other day, this is starting to happen
> now.  We know this will inconvenience people as some applications
> no longer build.  We want to work with maintainers to help them
> migrate, as we head down this path.
>
> We have a wiki page to discuss this effort.  It will eventually include
> tips on migration, application and code updates, and anything else the
> community finds useful.  Please visit:
>
> 	http://wiki.openssl.org/index.php/1.1_API_Changes
>
> Thanks.
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Not much on that page so far, not even a "kill list" of
intended victims except anadmission that EAY's popular DES
library can no longer be accessed via the copyin OpenSSL.

I fear that this is an indication that you will be killing
off all the othernon-EVP entrypoints in libcrypto, making
it much harder to use thelibrary with experimental or
non-standard algorithms and methods.

Just consider how hard it would now be to use libcrypto to
implement stuff like AES-GCM (if it was not already in the
library) or any of the block modes that were proposed in
the FIPS process, but not standardised by NIST (and thus
not included in EVP).

With the classic non-EVP API, it is trivial to wrap a custom
mode around the basic DES/AES/IDEA/... block functions.

And this is just one example of the flexibility provided by
not going through the more rigid EVP API.

Should everyone not doing just TLS1.2 move to a different
librarynow, such as crypto++ ?

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/20150204/76b50ea3/attachment.html>

From pbellino at mrv.com  Wed Feb  4 18:34:12 2015
From: pbellino at mrv.com (Philip Bellino)
Date: Wed, 4 Feb 2015 18:34:12 +0000
Subject: [openssl-users] make depend error in openssl-1.0.2/crypto
Message-ID: <AM3PR03MB08249850B6FE204878FB2E23C33A0@AM3PR03MB0824.eurprd03.prod.outlook.com>

Hello,
We  built OpenSSL-1.0.1j (and OpenSSL-fips-2.0.7) within my PowerPC-target build environment and have been using it successfully.
We now have upgraded to use OpenSSL-1.0.2  (and OpenSSL-fips-2.0.9).
It cannot successfully build because of the following error (which occurs identically 16 times) from within the crypto directory:

making depend in crypto...
make[3]: Entering directory `openssl-1.0.2/crypto'
<command line>:16:10: ISO C requires whitespace after the macro name


Was there something that changed between 1.0.1j and 1.0.2 that might cause this?
If not, can you shed any light on why it is happening?
Thanks,
Phil


[E-Banner]<http://www.mrv.com/landing/mrvs-software-defined-networking-sdn-and-network-function-virtualization-nfv-products-and-architecture>


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/20150204/d710e1b9/attachment.html>

From rsalz at akamai.com  Wed Feb  4 23:42:15 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 4 Feb 2015 23:42:15 +0000
Subject: [openssl-users] The evolution of the 'master' branch
In-Reply-To: <54D23F42.3060203@wisemo.com>
References: <20150203220231.GA12587@openssl.org> <54D23F42.3060203@wisemo.com>
Message-ID: <453ad2042e6c43e5897f1689e230883f@ustx2ex-dag1mb2.msg.corp.akamai.com>


>Not much on that page so far, not even a "kill list" of
>intended victims except an admission that EAY's popular DES
>library can no longer be accessed via the copy in OpenSSL.

Yup.  Pretty empty.  Over the coming year there will be more.

>I fear that this is an indication that you will be killing
>off all the other non-EVP entrypoints in libcrypto

Yes there is a good chance of that happening.

>, making
> it much harder to use the library with experimental or
> non-standard algorithms and methods.

Well, not really much harder.  I think that what DOES get harder is binary distributions of such things, as opposed to custom OpenSSL builds that have these new features.  Don't forget, *you have the source*  Hack away.  Do what you want.  And having a standard API that any of your consumers use will benefit your consumers greatly.  And by making things like the EVP structure hidden from your consumers, then you can add a new experimental crypto mechanism and -- this is an important major benefit:  THEIR CODE DOES NOT HAVE TO RECOMPILE.   As an implementor, your work is a bit harder.  For your users, it is much easier.  Imagine being able to put an OID in a config file and applications can almost transparently use any crypto available without change.  (Emphasis on ALMOST :)  To us, this is clearly the right trade-off to make.

> Should everyone not doing just TLS1.2 move to a different library now, such as crypto++ ?

Use whatever works best for you, and your consumers/customers.

Not everyone will agree with this direction. Some people will be inconvenienced and maybe even completely drop using OpenSSL. We discussed this pretty thoroughly, and while we respect that some may disagree, please give us credit for not doing this arbitrarily, or on a whim.

	/r$


From oyljerry at gmail.com  Thu Feb  5 02:54:04 2015
From: oyljerry at gmail.com (Jerry OELoo)
Date: Thu, 5 Feb 2015 10:54:04 +0800
Subject: [openssl-users]  How to load local certificate folder on windows
Message-ID: <CAEKwp_FS6U-cLQjSOEWgcSj_dyaTPNdd9bZSR1pJk8zDXWFpEw@mail.gmail.com>

Hi All:

I am using openssl 1.0.2 on windows 7 OS.

I have put some root certificate files into a folder certs. when I
using X509_STORE_load_locations() to load this folder into store, it
returns 1 means success,
but when I using X509_verify_cert(), it will return 0, and error shows
19(self signed certificate in certificate chain).
It seems my local root certificates files is not checked by openssl,
So what should I do to add certs folder?

-- 
Rejoice,I Desire!

From gayathri.annur at gmail.com  Thu Feb  5 08:43:18 2015
From: gayathri.annur at gmail.com (Gayathri Manoj)
Date: Thu, 5 Feb 2015 14:13:18 +0530
Subject: [openssl-users] i2d_X509_SIG() in FIPS mode
In-Reply-To: <20150204152649.GA18571@openssl.org>
References: <CAKqy4TNDrr1BDFtx7RAr1Mn-RDwiMSv7AGd3x7TQaPfptOJrpA@mail.gmail.com>
 <CAKqy4TMOknfZeqTzS7ck3-m9OUK4H70g_uBJRNVOQt1Vhub1jA@mail.gmail.com>
 <20150202130858.GA14363@openssl.org>
 <CAKqy4TM=KAg3YPpo+_HT01B+3h_aKmETfnAT=Ycc8keYkufBEQ@mail.gmail.com>
 <20150202160149.GT8034@mournblade.imrryr.org>
 <CAKqy4TNxqOwYzM7HhGvh7_WFHc02=YV-yYzqgYftdrne=fuyig@mail.gmail.com>
 <20150204152649.GA18571@openssl.org>
Message-ID: <CAKqy4TPmc7wN82tJCBsGDFE2ijW2vLj7sf8N-eJaT38g5gzuVw@mail.gmail.com>

Hi All,

Tried with  above method and its not worked. Please let me know  is it
possible to use  NID_md5WithRSAEncryption, NID_md5  in fips mode.

Thanks,
Gayathri

On Wed, Feb 4, 2015 at 8:56 PM, Dr. Stephen Henson <steve at openssl.org>
wrote:

> On Tue, Feb 03, 2015, Gayathri Manoj wrote:
>
> > Hi Steve, Viktor,
> >
> > I have tried with len also, But this also causing seg fault.
> > my requiremnt is to store  max  2048 bit keys. Hence I  used  length as
> 512
> > +1.
> > currently i ma getting len value = 28514.
> >
> > X509_SIG sig;
> > X509_ALGOR algor;
> > ASN1_OCTET_STRING digest;
> > ASN1_TYPE parameter;
> >    ASN1_item_digest() // to get digest details
> >    sig.algor = &algor;
> >     sig.algor->algorithm=OBJ_nid2obj(NID_md5);
> >     parameter.type=V_ASN1_NULL;
> >     parameter.value.ptr=NULL;
> >     sig.algor->parameter = &parameter;
> >     sig.digest = &digest;
> >     sig.digest->data=(unsigned char*)msg;
> >     sig.digest->length=datalen;
> >     len = i2d_X509_SIG(&sig,NULL);
> >
>
> You should only use a pointer to an ASN.1 structure and not the actual
> structure itself because you can end up with various fields taking odd
> uninitialised values (I suspect the fact you haven't initialised "flags" is
> at least one problem here. A complete set of accessor functions
> unfortnately
> doesn't currently exist for X509_SIG so you have to access some internals.
>
> In outline something like this:
>
> X509_SIG *sig = X509_SIG_new();
> X509_ALGOR_set0(sig->algor, OBJ_nid2obj(nid), V_ASN1_NULL, NULL);
> ASN1_STRING_set(sig->digest, digest, digestlen);
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> _______________________________________________
> 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/20150205/d5f9519c/attachment.html>

From steve at openssl.org  Thu Feb  5 12:47:10 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 5 Feb 2015 12:47:10 +0000
Subject: [openssl-users] i2d_X509_SIG() in FIPS mode
In-Reply-To: <CAKqy4TPmc7wN82tJCBsGDFE2ijW2vLj7sf8N-eJaT38g5gzuVw@mail.gmail.com>
References: <CAKqy4TNDrr1BDFtx7RAr1Mn-RDwiMSv7AGd3x7TQaPfptOJrpA@mail.gmail.com>
 <CAKqy4TMOknfZeqTzS7ck3-m9OUK4H70g_uBJRNVOQt1Vhub1jA@mail.gmail.com>
 <20150202130858.GA14363@openssl.org>
 <CAKqy4TM=KAg3YPpo+_HT01B+3h_aKmETfnAT=Ycc8keYkufBEQ@mail.gmail.com>
 <20150202160149.GT8034@mournblade.imrryr.org>
 <CAKqy4TNxqOwYzM7HhGvh7_WFHc02=YV-yYzqgYftdrne=fuyig@mail.gmail.com>
 <20150204152649.GA18571@openssl.org>
 <CAKqy4TPmc7wN82tJCBsGDFE2ijW2vLj7sf8N-eJaT38g5gzuVw@mail.gmail.com>
Message-ID: <20150205124710.GA9735@openssl.org>

On Thu, Feb 05, 2015, Gayathri Manoj wrote:

> Hi All,
> 
> Tried with  above method and its not worked. Please let me know  is it
> possible to use  NID_md5WithRSAEncryption, NID_md5  in fips mode.
> 

You can use the OID and encode structures using it: the ASN.1 code is not
part of the FIPS module.

You can't use the signing or digest algorithm (at least by default) as that is
blocked in FIPS mode. But you'd get an error message and not a crash.

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

From srirrao at gmail.com  Thu Feb  5 13:30:27 2015
From: srirrao at gmail.com (Srinivas Rao)
Date: Thu, 5 Feb 2015 19:00:27 +0530
Subject: [openssl-users] using openssl to create PKCS#7/CMS on windows
Message-ID: <CAPOCt68r7CL8unT4+_HWUEQ2Hf7d7C7aTXpxqshhk_VV_1nRTA@mail.gmail.com>

Hi All,

Is there a way to use openssl to sign data using a private key (on USB
token) and produce PKCS7 output on win32, if:

a) the data to be signed message is not touched yet and goes as input
to the solution to the answer to this problem, OR

b) signature is already generated, i.e message is hashed and signed
and only needs to be encoded in PKCS7,

If yes, for which of the above case and how (please give some pointers
on how to go about it).

Thanks
Srinivas


On 1/30/15, Srinivas Rao <srirrao at gmail.com> wrote:
> All,
>
> Please let me know if my below mentioned usage of PKCS7_sign()+adding
> signer info is wrong and how.
>
> Really appreciate your response.
>
> cheers and regards
> Srinivas
>
> On 1/29/15, Srinivas Rao <srirrao at gmail.com> wrote:
>> OpenSSL experts,
>>
>> Here the intention is to get the signed data (raw signature obtained
>> by PKCS11 APIs like C_Sign) to be packed in PKCS7 format (attached -
>> with certificate, content and signer info) using openssl.
>>
>> I am using USB token (smart card) for signing.
>>
>> Here's the code snippet.
>>
>> 	PKCS7* p7 = PKCS7_new();
>> 	PKCS7_set_type(p7, NID_pkcs7_signed);
>> 	//PKCS7_SIGNER_INFO* pSI = PKCS7_SIGNER_INFO_new();
>> 	//PKCS7_SIGNER_INFO_set(pSI, pX509, pX509->cert_info->key->pkey,
>> EVP_sha256());
>> 	//PKCS7_add_signer(p7, pSI);
>> 	PKCS7_SIGNER_INFO* pSI = PKCS7_add_signature(p7, pX509,
>> pX509->cert_info->key->pkey, EVP_sha256());  // <== core dumps here
>>         :
>>         :
>> where pX509 is correctly obtained X509* node using d2i_X509() from the
>> value obtained from PKCS11 funcstions like C_GetAttributeValue() etc.
>>
>> I believe the set of the commented lines is the alternate way for this
>> add signature function - that also dumps core at
>> PKCS7_SIGNER_INFO_set() function.
>>
>> I have no clue as to what am I doing wrong here.
>>
>> Appreciate your help.
>>
>> regards
>> Srinivas

From steve at openssl.org  Thu Feb  5 13:51:55 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 5 Feb 2015 13:51:55 +0000
Subject: [openssl-users] i2d_X509_SIG() in FIPS mode
In-Reply-To: <CAKqy4TPmc7wN82tJCBsGDFE2ijW2vLj7sf8N-eJaT38g5gzuVw@mail.gmail.com>
References: <CAKqy4TNDrr1BDFtx7RAr1Mn-RDwiMSv7AGd3x7TQaPfptOJrpA@mail.gmail.com>
 <CAKqy4TMOknfZeqTzS7ck3-m9OUK4H70g_uBJRNVOQt1Vhub1jA@mail.gmail.com>
 <20150202130858.GA14363@openssl.org>
 <CAKqy4TM=KAg3YPpo+_HT01B+3h_aKmETfnAT=Ycc8keYkufBEQ@mail.gmail.com>
 <20150202160149.GT8034@mournblade.imrryr.org>
 <CAKqy4TNxqOwYzM7HhGvh7_WFHc02=YV-yYzqgYftdrne=fuyig@mail.gmail.com>
 <20150204152649.GA18571@openssl.org>
 <CAKqy4TPmc7wN82tJCBsGDFE2ijW2vLj7sf8N-eJaT38g5gzuVw@mail.gmail.com>
Message-ID: <20150205135155.GA14940@openssl.org>

On Thu, Feb 05, 2015, Gayathri Manoj wrote:

> 
> Tried with  above method and its not worked. Please let me know  is it
> possible to use  NID_md5WithRSAEncryption, NID_md5  in fips mode.
> 

I threw together a quick test program and it has no problems for me. Let
me know if it doesn't work for you.

#include <stdio.h>
#include <openssl/x509.h>
#include <openssl/bio.h>

main()
{
int len;
unsigned char *der = NULL;
BIO *out;
X509_SIG *sig = X509_SIG_new();
FIPS_mode_set(1);
printf("Fips mode is %d\n", FIPS_mode());
X509_ALGOR_set0(sig->algor, OBJ_nid2obj(NID_md5), V_ASN1_NULL, NULL);
ASN1_STRING_set(sig->digest, "Hello World", -1);
len = i2d_X509_SIG(sig, &der);
out = BIO_new_fp(stdout, BIO_NOCLOSE);
ASN1_parse(out, der, len, 0);
}

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

From florencej at us.panasonic.com  Thu Feb  5 18:31:05 2015
From: florencej at us.panasonic.com (Florence, Jacques)
Date: Thu, 5 Feb 2015 18:31:05 +0000
Subject: [openssl-users] Parameters for using ECDHE and ECDSA
Message-ID: <B5AC76DEBCF8B845BDF39508D0DD14C3AC57BE@ptcpasaexmb04.pasa.pas.local>

Hello,
I am trying to use ECDHE and ECDSA on a simple openSSL application.
Here are the steps I did relevant to the problem at hand:
I generated the key and certificate with ECDSA.
Then I load the cert and the key with SSL_CTX_use_PrivateKeyFile
I select the ciphers: SSL_CTX_set_cipher_list(ctx, "ECDHE-ECDSA-AES128-GCM-SHA256");

But when I try to connect, the server tells me no shared cipher.
I don't know where this comes from. I am using TLSv1_2_method().
Do I need to load some parameters like with PEM_read_bio_DHparams and SSL_CTX_set_tmp_dh ?

There is not much documentation on openSSL ECC
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150205/0c6a18c8/attachment.html>

From matt at openssl.org  Thu Feb  5 19:31:09 2015
From: matt at openssl.org (Matt Caswell)
Date: Thu, 05 Feb 2015 19:31:09 +0000
Subject: [openssl-users] Parameters for using ECDHE and ECDSA
In-Reply-To: <B5AC76DEBCF8B845BDF39508D0DD14C3AC57BE@ptcpasaexmb04.pasa.pas.local>
References: <B5AC76DEBCF8B845BDF39508D0DD14C3AC57BE@ptcpasaexmb04.pasa.pas.local>
Message-ID: <54D3C4FD.7080402@openssl.org>



On 05/02/15 18:31, Florence, Jacques wrote:
> Hello,
> 
> I am trying to use ECDHE and ECDSA on a simple openSSL application.
> 
> Here are the steps I did relevant to the problem at hand:
> 
> I generated the key and certificate with ECDSA.
> 
> Then I load the cert and the key with SSL_CTX_use_PrivateKeyFile
> 
> I select the ciphers: SSL_CTX_set_cipher_list(ctx,
> ?ECDHE-ECDSA-AES128-GCM-SHA256?);
> 
>  
> 
> But when I try to connect, the server tells me no shared cipher.
> 
> I don?t know where this comes from. I am using TLSv1_2_method().
> 
> Do I need to load some parameters like with PEM_read_bio_DHparams and
> SSL_CTX_set_tmp_dh ?

Yes. If you are using OpenSSL 1.0.2 you can use:

SSL_CTX_set_ecdh_auto

The above will automatically select a suitable ECDH curve to use.

Otherwise you can set a curve explicitly using:

SSL_CTX_set_tmp_ecdh

Matt


From florencej at us.panasonic.com  Thu Feb  5 23:15:50 2015
From: florencej at us.panasonic.com (Florence, Jacques)
Date: Thu, 5 Feb 2015 23:15:50 +0000
Subject: [openssl-users] Parameters for using ECDHE and ECDSA
In-Reply-To: <54D3C4FD.7080402@openssl.org>
References: <B5AC76DEBCF8B845BDF39508D0DD14C3AC57BE@ptcpasaexmb04.pasa.pas.local>
 <54D3C4FD.7080402@openssl.org>
Message-ID: <B5AC76DEBCF8B845BDF39508D0DD14C3AC57DD@ptcpasaexmb04.pasa.pas.local>

Thanks, I found it!

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell
Sent: Thursday, February 05, 2015 2:31 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Parameters for using ECDHE and ECDSA



On 05/02/15 18:31, Florence, Jacques wrote:
> Hello,
> 
> I am trying to use ECDHE and ECDSA on a simple openSSL application.
> 
> Here are the steps I did relevant to the problem at hand:
> 
> I generated the key and certificate with ECDSA.
> 
> Then I load the cert and the key with SSL_CTX_use_PrivateKeyFile
> 
> I select the ciphers: SSL_CTX_set_cipher_list(ctx, 
> "ECDHE-ECDSA-AES128-GCM-SHA256");
> 
>  
> 
> But when I try to connect, the server tells me no shared cipher.
> 
> I don't know where this comes from. I am using TLSv1_2_method().
> 
> Do I need to load some parameters like with PEM_read_bio_DHparams and 
> SSL_CTX_set_tmp_dh ?

Yes. If you are using OpenSSL 1.0.2 you can use:

SSL_CTX_set_ecdh_auto

The above will automatically select a suitable ECDH curve to use.

Otherwise you can set a curve explicitly using:

SSL_CTX_set_tmp_ecdh

Matt

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

From florencej at us.panasonic.com  Thu Feb  5 23:21:14 2015
From: florencej at us.panasonic.com (Florence, Jacques)
Date: Thu, 5 Feb 2015 23:21:14 +0000
Subject: [openssl-users] custom name attributes not sent with certificate
Message-ID: <B5AC76DEBCF8B845BDF39508D0DD14C3AC57E9@ptcpasaexmb04.pasa.pas.local>

I created a client certificate with custom name attributes:
In the openssl.cnf file, I addedunder section [ new_oids ] the line: myattribute=1.2.3.4
And under [ req_distinguished_name ] I added the line: myattribute = hello
If I use the openssl tool x509, I see that my new attribute appears in the name, after the email address.

However, when the certificate is sent to the server, the server cannot read this attribute.
I used wireshark and saw that my custome attribute is not sent with the rest of the name.
Why is that ?
Thanks
Jacques
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150205/936b52f1/attachment.html>

From gayathri.annur at gmail.com  Fri Feb  6 09:46:28 2015
From: gayathri.annur at gmail.com (Gayathri Manoj)
Date: Fri, 6 Feb 2015 15:16:28 +0530
Subject: [openssl-users] i2d_X509_SIG() in FIPS mode
In-Reply-To: <20150205135155.GA14940@openssl.org>
References: <CAKqy4TNDrr1BDFtx7RAr1Mn-RDwiMSv7AGd3x7TQaPfptOJrpA@mail.gmail.com>
 <CAKqy4TMOknfZeqTzS7ck3-m9OUK4H70g_uBJRNVOQt1Vhub1jA@mail.gmail.com>
 <20150202130858.GA14363@openssl.org>
 <CAKqy4TM=KAg3YPpo+_HT01B+3h_aKmETfnAT=Ycc8keYkufBEQ@mail.gmail.com>
 <20150202160149.GT8034@mournblade.imrryr.org>
 <CAKqy4TNxqOwYzM7HhGvh7_WFHc02=YV-yYzqgYftdrne=fuyig@mail.gmail.com>
 <20150204152649.GA18571@openssl.org>
 <CAKqy4TPmc7wN82tJCBsGDFE2ijW2vLj7sf8N-eJaT38g5gzuVw@mail.gmail.com>
 <20150205135155.GA14940@openssl.org>
Message-ID: <CAKqy4TOJu97OhfRj7SqR5WBmUr-S3WTSrf9Buw4QHfmywemSXw@mail.gmail.com>

Thanks Steve for looking into this. Earlier I have tested the same  way and
no values  came in der.

Finally i find out the crash reason. For getting digest we have used
ASN1_item_digest() and in this we have passed  digest type as EVP_MD5()
which is not allowed in fips and its not thrown any error.  And got return
value of this api as SUCCESS. Later i changed this to EVP_sha1() and able
to get the value in i2d_X509_SIG().

Thanks,
Gayathri


On Thu, Feb 5, 2015 at 7:21 PM, Dr. Stephen Henson <steve at openssl.org>
wrote:

> On Thu, Feb 05, 2015, Gayathri Manoj wrote:
>
> >
> > Tried with  above method and its not worked. Please let me know  is it
> > possible to use  NID_md5WithRSAEncryption, NID_md5  in fips mode.
> >
>
> I threw together a quick test program and it has no problems for me. Let
> me know if it doesn't work for you.
>
> #include <stdio.h>
> #include <openssl/x509.h>
> #include <openssl/bio.h>
>
> main()
> {
> int len;
> unsigned char *der = NULL;
> BIO *out;
> X509_SIG *sig = X509_SIG_new();
> FIPS_mode_set(1);
> printf("Fips mode is %d\n", FIPS_mode());
> X509_ALGOR_set0(sig->algor, OBJ_nid2obj(NID_md5), V_ASN1_NULL, NULL);
> ASN1_STRING_set(sig->digest, "Hello World", -1);
> len = i2d_X509_SIG(sig, &der);
> out = BIO_new_fp(stdout, BIO_NOCLOSE);
> ASN1_parse(out, der, len, 0);
> }
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> _______________________________________________
> 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/20150206/68d94a9c/attachment.html>

From Neil.Martin at ncr.com  Fri Feb  6 10:08:35 2015
From: Neil.Martin at ncr.com (Martin, Neil)
Date: Fri, 6 Feb 2015 05:08:35 -0500
Subject: [openssl-users] Is it possible to add eContent to a signedData
	which has no signers
Message-ID: <58C1450995691B499FF4E7092826DB3026D1562102@susday214.corp.ncr.com>

Hi,

I'd like to know if it is possible to add eContent to a signedData which has no signers?

The ANS X9 TR34 technical report defines a rebind token as having the following structure.

SignedData (inner content):
   There are no digestAlgorithms included.
   The EncapsulatedContentInfo eContentType is id-data.
   The EncapsulatedContentInfo eContent includes an identifier  as an 
      issuerAndSerialNumber field.
   1 Certificate is included in the certificates field.
   The CRL field is omitted.
   There are no signers on the content.

SignedData (outer content):
   The digestAlgorithms field specifies id- sha256 : '2.16.840.1.101.3.4.2.1'.
   The EncapsulatedContentInfo eContentType is id-signedData.
   The certificates field is omitted.
   1 is included in the crl field.
   IssuerAndSerialNumber is chosen for SignerInfo SignerIdentifier.
   The current certificate owner identifier is included in the SignerInfos
     issuerAndSerialNumber field.
   The SignerInfo digestAlgorithm field specifies id- sha256 : '2.16.840.1.101.3.4.2.1'.
   The random number, is included as random nonce authenticated attribute
     within SignerInfo SignedAttributes.
   The signatureAlgorithm is specified as id-sha256WithrsaEncryption
      '1.2.840.113549.1.1.11'
   The unsignedAttrs field is omitted.

My problem is I can't include the eContent  in the inner content.
In the following code, CMS_final for the inner content fails.

void CreateRebindToken(X509* deviceCertificate, X509* currentCertificate, EVP_PKEY* currentPrivateKey, X509* newCertificate, X509_CRL* crl, LPCSTR tokenFile)
{
    int rc = 0;

    // Prepare the inner content
    CMS_ContentInfo* cms = CMS_sign(NULL, NULL, NULL, NULL, CMS_PARTIAL);

    rc = CMS_add1_cert(cms, newCertificate);

    BIO* eContentBio = BIO_new(BIO_s_mem()); 
    CreateIssuerAndSerialNumberSequence(deviceCertificate, eContentBio);

    // This fails, presumably because no signer has been added. 
    // How can eContent be added to a SignedData structure with no signers?
    rc = CMS_final(cms, eContentBio, NULL, CMS_NOATTR | SMIME_BINARY);

    rc = BIO_free(eContentBio);
    eContentBio = NULL;

    // Cache the inner content cms in DER format then free the cms
    eContentBio = BIO_new(BIO_s_mem()); 
    rc = i2d_CMS_bio(eContentBio, cms);
    CMS_ContentInfo_free(cms);
    cms = NULL;

    // prepare the outer content
    cms = CMS_sign(NULL, NULL, NULL, NULL, CMS_PARTIAL);
    rc = CMS_add1_crl(cms, crl);
    CMS_SignerInfo* si = CMS_add1_signer(cms, currentCertificate, currentPrivateKey, EVP_sha256(), CMS_NOATTR | CMS_NOCERTS);
    rc = CMS_final(cms, eContentBio, NULL, SMIME_BINARY);

    BIO_free(eContentBio);
    eContentBio = NULL;

    // Write to file
    BIO* bio = BIO_new_file(tokenFile, "wb");
    rc = i2d_CMS_bio(bio, cms);

    // Cleanup
    rc = BIO_free(bio);
    bio = NULL;

    CMS_ContentInfo_free(cms);
    cms = NULL;
}

Thanks,
Neil



From jb-openssl at wisemo.com  Fri Feb  6 14:15:29 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 06 Feb 2015 15:15:29 +0100
Subject: [openssl-users] custom name attributes not sent with certificate
In-Reply-To: <B5AC76DEBCF8B845BDF39508D0DD14C3AC57E9@ptcpasaexmb04.pasa.pas.local>
References: <B5AC76DEBCF8B845BDF39508D0DD14C3AC57E9@ptcpasaexmb04.pasa.pas.local>
Message-ID: <54D4CC81.3010002@wisemo.com>

On 06/02/2015 00:21, Florence, Jacques wrote:
>
> I created a client certificate with custom name attributes:
>
> In the openssl.cnf file, I addedunder section [ new_oids ] the line: 
> myattribute=1.2.3.4
>
> And under [ req_distinguished_name ] I added the line: myattribute = hello
>
> If I use the openssl tool x509, I see that my new attribute appears in 
> the name, after the email address.
>
> However, when the certificate is sent to the server, the server cannot 
> read this attribute.
>
> I used wireshark and saw that my custome attribute is not sent with 
> the rest of the name.
>
> Why is that ?
>
>
Are you sure this is what is really happening?

If any byte in the signed part of the certificate (and this
most certainly includes the name) is changed, the certificate
should completely fail to verify.

So are you sure the name isn't sent?  Maybe it is just the
utility you use to display the sent certificate which fails
to display unknown name components.

P.S.

I presume that for any real use, you would use an officially
allocated OID to avoid clashing with what other people use.

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 florencej at us.panasonic.com  Fri Feb  6 14:37:52 2015
From: florencej at us.panasonic.com (Florence, Jacques)
Date: Fri, 6 Feb 2015 14:37:52 +0000
Subject: [openssl-users] custom name attributes not sent with certificate
In-Reply-To: <54D4CC81.3010002@wisemo.com>
References: <B5AC76DEBCF8B845BDF39508D0DD14C3AC57E9@ptcpasaexmb04.pasa.pas.local>
 <54D4CC81.3010002@wisemo.com>
Message-ID: <B5AC76DEBCF8B845BDF39508D0DD14C3AC581F@ptcpasaexmb04.pasa.pas.local>

Jakob,
Thanks for the reply. 
You're right, the cert shouldn't verify if it's changed.
However, using wireshark, I can see the other parts of the name being sent in clear ascii, but not that custom attribute.
Assuming it's encoded in some format.
Once the server receives the cert, it is not able to acces this attribute:
Using X509_NAME_print_ex_fp(...) I don't see that attribute.
Also, if I create an ASN1_OBJECT using OBJ_create() (with the OID and name I assigned in the cnf file) then OBJ_nid2obj(), 
and then use X509_NAME_get_entry and X509_NAME_ENTRY_get_object, I can display the standard fields, but not my attribute


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jakob Bohm
Sent: Friday, February 06, 2015 9:15 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] custom name attributes not sent with certificate

On 06/02/2015 00:21, Florence, Jacques wrote:
>
> I created a client certificate with custom name attributes:
>
> In the openssl.cnf file, I addedunder section [ new_oids ] the line: 
> myattribute=1.2.3.4
>
> And under [ req_distinguished_name ] I added the line: myattribute = 
> hello
>
> If I use the openssl tool x509, I see that my new attribute appears in 
> the name, after the email address.
>
> However, when the certificate is sent to the server, the server cannot 
> read this attribute.
>
> I used wireshark and saw that my custome attribute is not sent with 
> the rest of the name.
>
> Why is that ?
>
>
Are you sure this is what is really happening?

If any byte in the signed part of the certificate (and this most certainly includes the name) is changed, the certificate should completely fail to verify.

So are you sure the name isn't sent?  Maybe it is just the utility you use to display the sent certificate which fails to display unknown name components.

P.S.

I presume that for any real use, you would use an officially allocated OID to avoid clashing with what other people use.

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 jb-openssl at wisemo.com  Fri Feb  6 14:38:48 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 06 Feb 2015 15:38:48 +0100
Subject: [openssl-users] using openssl to create PKCS#7/CMS on windows
In-Reply-To: <CAPOCt68r7CL8unT4+_HWUEQ2Hf7d7C7aTXpxqshhk_VV_1nRTA@mail.gmail.com>
References: <CAPOCt68r7CL8unT4+_HWUEQ2Hf7d7C7aTXpxqshhk_VV_1nRTA@mail.gmail.com>
Message-ID: <54D4D1F8.2000601@wisemo.com>

On 05/02/2015 14:30, Srinivas Rao wrote:
> Hi All,
>
> Is there a way to use openssl to sign data using a private key (on USB
> token) and produce PKCS7 output on win32, if:
>
> a) the data to be signed message is not touched yet and goes as input
> to the solution to the answer to this problem, OR
>
> b) signature is already generated, i.e message is hashed and signed
> and only needs to be encoded in PKCS7,
>
> If yes, for which of the above case and how (please give some pointers
> on how to go about it).
>
> Thanks
> Srinivas

Are you trying to get us to help with a school assignment?
This looks a lot like how a teacher would ask a question to
his students to find out how much they have understood
themselves.

That said, the main pointers I can give you are these:

Verylittlein OpenSSL differs between Win32 and other
systems.  Howeverthere is one part in the question that
will usually be slightly different onWin32.If you
understand the question and OpenSSL general features, you
should be able to recognize which part that is.

One of the alternatives is going to be more difficult than
the other because it is a less common task, but it may still
be doable with some ingenuity.

The task (either one if both are doable) can be performed
using almost no APIs and interfaces other than those
provided by OpenSSL and ANSI C.  If you are tempted to use
other tools, look closer at the OpenSSL feature lists and
available options.

In your code below you forgot to use two of the items your
teacher gave you, which is probably the problem.

> On 1/30/15, Srinivas Rao <srirrao at gmail.com> wrote:
>> All,
>>
>> Please let me know if my below mentioned usage of PKCS7_sign()+adding
>> signer info is wrong and how.
>>
>> Really appreciate your response.
>>
>> cheers and regards
>> Srinivas
>>
>> On 1/29/15, Srinivas Rao <srirrao at gmail.com> wrote:
>>> OpenSSL experts,
>>>
>>> Here the intention is to get the signed data (raw signature obtained
>>> by PKCS11 APIs like C_Sign) to be packed in PKCS7 format (attached -
>>> with certificate, content and signer info) using openssl.
>>>
>>> I am using USB token (smart card) for signing.
>>>
>>> Here's the code snippet.
>>>
>>> 	PKCS7* p7 = PKCS7_new();
>>> 	PKCS7_set_type(p7, NID_pkcs7_signed);
>>> 	//PKCS7_SIGNER_INFO* pSI = PKCS7_SIGNER_INFO_new();
>>> 	//PKCS7_SIGNER_INFO_set(pSI, pX509, pX509->cert_info->key->pkey,
>>> EVP_sha256());
>>> 	//PKCS7_add_signer(p7, pSI);
>>> 	PKCS7_SIGNER_INFO* pSI = PKCS7_add_signature(p7, pX509,
>>> pX509->cert_info->key->pkey, EVP_sha256());  // <== core dumps here
>>>          :
>>>          :
>>> where pX509 is correctly obtained X509* node using d2i_X509() from the
>>> value obtained from PKCS11 funcstions like C_GetAttributeValue() etc.
>>>
>>> I believe the set of the commented lines is the alternate way for this
>>> add signature function - that also dumps core at
>>> PKCS7_SIGNER_INFO_set() function.
>>>
>>> I have no clue as to what am I doing wrong here.
>>>
>>> Appreciate your help.

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 Neil.Martin at ncr.com  Fri Feb  6 10:08:35 2015
From: Neil.Martin at ncr.com (Martin, Neil)
Date: Fri, 6 Feb 2015 05:08:35 -0500
Subject: [openssl-users] Is it possible to add eContent to a signedData
	which has no signers
Message-ID: <58C1450995691B499FF4E7092826DB3026D1562102@susday214.corp.ncr.com>

Hi,

I'd like to know if it is possible to add eContent to a signedData which has no signers?

The ANS X9 TR34 technical report defines a rebind token as having the following structure.

SignedData (inner content):
   There are no digestAlgorithms included.
   The EncapsulatedContentInfo eContentType is id-data.
   The EncapsulatedContentInfo eContent includes an identifier  as an 
      issuerAndSerialNumber field.
   1 Certificate is included in the certificates field.
   The CRL field is omitted.
   There are no signers on the content.

SignedData (outer content):
   The digestAlgorithms field specifies id- sha256 : '2.16.840.1.101.3.4.2.1'.
   The EncapsulatedContentInfo eContentType is id-signedData.
   The certificates field is omitted.
   1 is included in the crl field.
   IssuerAndSerialNumber is chosen for SignerInfo SignerIdentifier.
   The current certificate owner identifier is included in the SignerInfos
     issuerAndSerialNumber field.
   The SignerInfo digestAlgorithm field specifies id- sha256 : '2.16.840.1.101.3.4.2.1'.
   The random number, is included as random nonce authenticated attribute
     within SignerInfo SignedAttributes.
   The signatureAlgorithm is specified as id-sha256WithrsaEncryption
      '1.2.840.113549.1.1.11'
   The unsignedAttrs field is omitted.

My problem is I can't include the eContent  in the inner content.
In the following code, CMS_final for the inner content fails.

void CreateRebindToken(X509* deviceCertificate, X509* currentCertificate, EVP_PKEY* currentPrivateKey, X509* newCertificate, X509_CRL* crl, LPCSTR tokenFile)
{
    int rc = 0;

    // Prepare the inner content
    CMS_ContentInfo* cms = CMS_sign(NULL, NULL, NULL, NULL, CMS_PARTIAL);

    rc = CMS_add1_cert(cms, newCertificate);

    BIO* eContentBio = BIO_new(BIO_s_mem()); 
    CreateIssuerAndSerialNumberSequence(deviceCertificate, eContentBio);

    // This fails, presumably because no signer has been added. 
    // How can eContent be added to a SignedData structure with no signers?
    rc = CMS_final(cms, eContentBio, NULL, CMS_NOATTR | SMIME_BINARY);

    rc = BIO_free(eContentBio);
    eContentBio = NULL;

    // Cache the inner content cms in DER format then free the cms
    eContentBio = BIO_new(BIO_s_mem()); 
    rc = i2d_CMS_bio(eContentBio, cms);
    CMS_ContentInfo_free(cms);
    cms = NULL;

    // prepare the outer content
    cms = CMS_sign(NULL, NULL, NULL, NULL, CMS_PARTIAL);
    rc = CMS_add1_crl(cms, crl);
    CMS_SignerInfo* si = CMS_add1_signer(cms, currentCertificate, currentPrivateKey, EVP_sha256(), CMS_NOATTR | CMS_NOCERTS);
    rc = CMS_final(cms, eContentBio, NULL, SMIME_BINARY);

    BIO_free(eContentBio);
    eContentBio = NULL;

    // Write to file
    BIO* bio = BIO_new_file(tokenFile, "wb");
    rc = i2d_CMS_bio(bio, cms);

    // Cleanup
    rc = BIO_free(bio);
    bio = NULL;

    CMS_ContentInfo_free(cms);
    cms = NULL;
}

Thanks,
Neil



From florencej at us.panasonic.com  Fri Feb  6 15:26:40 2015
From: florencej at us.panasonic.com (Florence, Jacques)
Date: Fri, 6 Feb 2015 15:26:40 +0000
Subject: [openssl-users] custom name attributes not sent with certificate
References: <B5AC76DEBCF8B845BDF39508D0DD14C3AC57E9@ptcpasaexmb04.pasa.pas.local>
 <54D4CC81.3010002@wisemo.com> 
Message-ID: <B5AC76DEBCF8B845BDF39508D0DD14C3AC5838@ptcpasaexmb04.pasa.pas.local>

My bad.
I was using the wrong version of the certificate.
Sometimes double checking is not enough. I learned a lesson: Always triple check.
Sorry,
Jacques

-----Original Message-----
From: Florence, Jacques 
Sent: Friday, February 06, 2015 9:38 AM
To: 'openssl-users at openssl.org'
Subject: RE: [openssl-users] custom name attributes not sent with certificate

Jakob,
Thanks for the reply. 
You're right, the cert shouldn't verify if it's changed.
However, using wireshark, I can see the other parts of the name being sent in clear ascii, but not that custom attribute.
Assuming it's encoded in some format.
Once the server receives the cert, it is not able to acces this attribute:
Using X509_NAME_print_ex_fp(...) I don't see that attribute.
Also, if I create an ASN1_OBJECT using OBJ_create() (with the OID and name I assigned in the cnf file) then OBJ_nid2obj(), and then use X509_NAME_get_entry and X509_NAME_ENTRY_get_object, I can display the standard fields, but not my attribute


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jakob Bohm
Sent: Friday, February 06, 2015 9:15 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] custom name attributes not sent with certificate

On 06/02/2015 00:21, Florence, Jacques wrote:
>
> I created a client certificate with custom name attributes:
>
> In the openssl.cnf file, I addedunder section [ new_oids ] the line: 
> myattribute=1.2.3.4
>
> And under [ req_distinguished_name ] I added the line: myattribute = 
> hello
>
> If I use the openssl tool x509, I see that my new attribute appears in 
> the name, after the email address.
>
> However, when the certificate is sent to the server, the server cannot 
> read this attribute.
>
> I used wireshark and saw that my custome attribute is not sent with 
> the rest of the name.
>
> Why is that ?
>
>
Are you sure this is what is really happening?

If any byte in the signed part of the certificate (and this most certainly includes the name) is changed, the certificate should completely fail to verify.

So are you sure the name isn't sent?  Maybe it is just the utility you use to display the sent certificate which fails to display unknown name components.

P.S.

I presume that for any real use, you would use an officially allocated OID to avoid clashing with what other people use.

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 shinrich at ieee.org  Fri Feb  6 15:48:36 2015
From: shinrich at ieee.org (Susan Hinrichs)
Date: Fri, 06 Feb 2015 09:48:36 -0600
Subject: [openssl-users] Means to update read bio only
Message-ID: <54D4E254.2060105@ieee.org>

Hello,

In Apache Traffic Server we are primarily using SSL_accept and 
SSL_read/SSL_write with file descriptor bios.

But during the handshake, we need to feed in our own packets via 
read-only buffers.  We use the BIO mem_buf to pass along this data 
without incurring another copy.  But on each read during the handshake, 
we need to reset the read bio.  We leave the write bio as the file 
descriptor bio the whole time.

I originally tried to use SSL_set_bio(ssl, new_rbio, SSL_get_wbio(ssl)), 
but that would adjust the output buffering and the handshake would not 
complete.

So we created a SSL_set_rbio(ssl, new_rbio), that just frees the old 
rbio and sets the new one.  It leaves the wbio and the bbio alone.

This has worked well for us for a couple releases, but looking forward 
to openssl 1.1, we will no longer be able to use this approach.  Can 
someone point me to the preferred way of updating a read bio without 
affecting the write bio processing?

Thanks,
Susan

From jb-openssl at wisemo.com  Fri Feb  6 16:03:31 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 06 Feb 2015 17:03:31 +0100
Subject: [openssl-users] The evolution of the 'master' branch
In-Reply-To: <453ad2042e6c43e5897f1689e230883f@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <20150203220231.GA12587@openssl.org> <54D23F42.3060203@wisemo.com>
 <453ad2042e6c43e5897f1689e230883f@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <54D4E5D3.6090808@wisemo.com>

On 05/02/2015 00:42, Salz, Rich wrote:
>> Not much on that page so far, not even a "kill list" of
>> intended victims except an admission that EAY's popular DES
>> library can no longer be accessed via the copy in OpenSSL.
> Yup.  Pretty empty.  Over the coming year there will be more.
>> I fear that this is an indication that you will be killing
>> off all the other non-EVP entrypoints in libcrypto
> Yes there is a good chance of that happening.
>> , making
>> it much harder to use the library with experimental or
>> non-standard algorithms and methods.
> Well, not really much harder.  I think that what DOES get harder is binary distributions of such things, as opposed to custom OpenSSL builds that have these new features.  Don't forget, *you have the source*  Hack away.  Do what you want.  And having a standard API that any of your consumers use will benefit your consumers greatly.  And by making things like the EVP structure hidden from your consumers, then you can add a new experimental crypto mechanism and -- this is an important major benefit:  THEIR CODE DOES NOT HAVE TO RECOMPILE.   As an implementor, your work is a bit harder.  For your users, it is much easier.  Imagine being able to put an OID in a config file and applications can almost transparently use any crypto available without change.  (Emphasis on ALMOST :)  To us, this is clearly the right trade-off to make.
You seem to misunderstand the scenario:

My scenario is:

1. Load an unchanged shared libcrypto.so.1.1 provided by an
   OS distribution.

2. Implement / use / experiment with non-standard methods
   (such as new modes of operation or new zero-knowledge
   proofs) by calling the functions that are exported by
   libcrypto out of the box.  The higher level libssl is
   not used for anything.

Your scenario is:

1. Extend the higher level stuff (TLS1.2, CMS etc.) with non-
   standard methods (such as new modes of operation or new
   signature forms).

2. Inject this new functionality into existing applications
   that use OpenSSL in generic ways, such as wget and WebKit
   browsers.

My scenario got great advantages from the large number of
fundamental interfaces exported from libcrypto.so.1.0 and
will automatically benefit when a new patch release of
OpenSSL is installed on the system (e.g. to fix a timing
attack on one of the algorithm implementations).  Having
to create a custom libnotquitecrypto.so.1.1 would not do
this, and distributing such a library as source patches
became much harder when you reformatted the source.

Looking at the reverse dependencies in Debian, the
followingprojects probably use low level libcrypto
interfaces to do interesting things: afflib, asterisk,
bind, clamav, crda (WiFi), crtmpserver, encfs, ewf-tools,
faifa (Ethernet over Power), gfsd, gnugk, gnupg-pkcs11-scd,
hfsprogs, hostapd (WiFi), ipppd, KAME IPSEC, OpenBSD IPSEC,
ldnsutils, apache mod-auth-cas, apache mod-auth-openid,
perl's Crypt::OpenSSL::Bignum, libh323, liblasso, barada,
StrongSWAN, unbound, libxmlsec, libzrtpcpp, nsd, opensc,
openssh, rdd, rdesktop, rsyncrypto, samdump, tor,
tpm-tools, trousers, wpasupplicant (WiFi), yate, zfs-fuse.
*This is only a rough list based on features claimed by
OpenSSL-depending packages*

>> Should everyone not doing just TLS1.2 move to a different library now, such as crypto++ ?
> Use whatever works best for you, and your consumers/customers.
>
> Not everyone will agree with this direction. Some people will be inconvenienced and maybe even completely drop using OpenSSL. We discussed this pretty thoroughly, and while we respect that some may disagree, please give us credit for not doing this arbitrarily, or on a whim.	
I believe you have made the mistake of discussing only amongst
yourselves, thus gradually convincing each other of the
righteousness of a flawed decision.

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/20150206/28ca86f4/attachment.html>

From rsalz at akamai.com  Fri Feb  6 16:16:06 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 6 Feb 2015 16:16:06 +0000
Subject: [openssl-users] The evolution of the 'master' branch
In-Reply-To: <54D4E5D3.6090808@wisemo.com>
References: <20150203220231.GA12587@openssl.org> <54D23F42.3060203@wisemo.com>
 <453ad2042e6c43e5897f1689e230883f@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <54D4E5D3.6090808@wisemo.com>
Message-ID: <a63f521adc6645ef81566e14c4ea1873@ustx2ex-dag1mb2.msg.corp.akamai.com>

Thanks for your detailed reply.  Not sure what else I can say except that we disagree.


From dthompson at prinpay.com  Fri Feb  6 17:03:50 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Fri, 6 Feb 2015 12:03:50 -0500
Subject: [openssl-users] How to load local certificate folder on windows
In-Reply-To: <CAEKwp_FS6U-cLQjSOEWgcSj_dyaTPNdd9bZSR1pJk8zDXWFpEw@mail.gmail.com>
References: <CAEKwp_FS6U-cLQjSOEWgcSj_dyaTPNdd9bZSR1pJk8zDXWFpEw@mail.gmail.com>
Message-ID: <000c01d0422e$e32fe4c0$a98fae40$@prinpay.com>

> From: openssl-users On Behalf Of Jerry OELoo
> Sent: Wednesday, February 04, 2015 21:54

> I am using openssl 1.0.2 on windows 7 OS.
> 
> I have put some root certificate files into a folder certs. when I
> using X509_STORE_load_locations() to load this folder into store, it
> returns 1 means success,
> but when I using X509_verify_cert(), it will return 0, and error shows
> 19(self signed certificate in certificate chain).

Nitpick: STORE_load_locations (and CTX_load_verify_locations which uses it) 
actually loads the contents of a CAfile into memory, but it only stores the 
*name* of a CApath and *later* dynamically loads files from that directory.

Did you use filenames, or possibly* linknames, based on subject hash 
as described in https://www.openssl.org/docs/apps/verify.html ?

* Windows beginning AIR XP or maybe NT does support links on NTFS,
but they're not easy to use and not well known, and I think I saw a recent 
bug report that they don't even work for OpenSSL,  at least sometimes.

Less likely but possible if these files were prepared on an another system: 
did you use hashnames created with OpenSSL >1.0.0 or higher<?

Is this a FAQ yet?



From rex at kalos-inc.com  Fri Feb  6 19:13:08 2015
From: rex at kalos-inc.com (Rex Bloom)
Date: Fri, 6 Feb 2015 13:13:08 -0600
Subject: [openssl-users] openssl genrsa question
Message-ID: <71570E7AB2E42D41A10FC97E532B699D0141985921DC@MAILSERVER.KalosInc.local>

I am being required to generate the following type of digital signature:

RSASSA-PKCS1-v1_5

I am doing the following:

openssl genrsa -aes128 -out private.pem 2048

Can anyone confirm this is correct or point out what I should change?

Thanks,
Rex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150206/7e672610/attachment.html>

From Michael.Wojcik at microfocus.com  Fri Feb  6 19:19:22 2015
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 6 Feb 2015 19:19:22 +0000
Subject: [openssl-users] How to load local certificate folder on windows
In-Reply-To: <000c01d0422e$e32fe4c0$a98fae40$@prinpay.com>
References: <CAEKwp_FS6U-cLQjSOEWgcSj_dyaTPNdd9bZSR1pJk8zDXWFpEw@mail.gmail.com>
 <000c01d0422e$e32fe4c0$a98fae40$@prinpay.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801344971B4@Rock-Exchange1.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Dave Thompson
> Sent: Friday, February 06, 2015 12:04
> 
> * Windows beginning AIR XP or maybe NT does support links on NTFS,
> but they're not easy to use and not well known, and I think I saw a recent
> bug report that they don't even work for OpenSSL,  at least sometimes.

In modern versions of Windows, NTFS supports three sorts of link-like objects: file symbolic links, directory symbolic links, and junctions, all of which are types of reparse points. Older versions of NTFS only support junctions. These can be created with the mklink command. Prior to Vista, there was no command in the base OS for this purpose, and you needed something like linkd from the Windows Server Resource Kit to manipulate links.

I just did a bit of testing with openssl.exe from OpenSSL 1.0.1k. It appears to work correctly with all three.

Windows also supports "shortcuts", but those are a Windows Explorer artifact. They're just files that have a particular extension and particular sort of contents. OpenSSL doesn't support them, but then neither do most programs. Shortcuts were invented for Windows 95 to overcome some of the limitations of the FAT32 filesystem. They're rubbish.

And Cygwin provides both hard and symbolic UNIX-style links for NTFS. Hard links can only be to files. I'm not sure how Cygwin implements them, but they seem to work fine with OpenSSL.

Cygwin supports multiple implementations of symbolic links; see https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks. Default symbolic links are ordinary files recognized by the Cygwin library as special, so they aren't handled by (non-Cygwin) OpenSSL. Shortcut-style symlinks are shortcuts, so per above they do not work. Native symlinks are Windows symlinks and should work fine with OpenSSL. The native implementation can be selected by setting the CYGWIN environment variable appropriately, so (contrary to recent messages on the list) there's no reason to rewrite c_rehash for use on Windows.

-- 
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com

From matt at openssl.org  Fri Feb  6 20:59:17 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 06 Feb 2015 20:59:17 +0000
Subject: [openssl-users] The evolution of the 'master' branch
In-Reply-To: <54D4E5D3.6090808@wisemo.com>
References: <20150203220231.GA12587@openssl.org> <54D23F42.3060203@wisemo.com>
 <453ad2042e6c43e5897f1689e230883f@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <54D4E5D3.6090808@wisemo.com>
Message-ID: <54D52B25.7010505@openssl.org>



On 06/02/15 16:03, Jakob Bohm wrote:
> I believe you have made the mistake of discussing only amongst
> yourselves, thus gradually convincing each other of the
> righteousness of a flawed decision.


...and, Rich said in a previous email (in response to your comment):
>> I fear that this is an indication that you will be killing
>> off all the other non-EVP entrypoints in libcrypto
>
> Yes there is a good chance of that happening.

I'd like to stress that there has been no decision. In fact we're not
even close to a decision on that at the moment.

Whilst this has certainly been discussed I don't believe we are near to
a consensus view at the moment. So whilst there is a good chance of that
happening....there's also a very good chance of it not. It is still
under discussion.

Matt

From openssl-users at dukhovni.org  Fri Feb  6 21:37:17 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 6 Feb 2015 21:37:17 +0000
Subject: [openssl-users] openssl genrsa question
In-Reply-To: <71570E7AB2E42D41A10FC97E532B699D0141985921DC@MAILSERVER.KalosInc.local>
References: <71570E7AB2E42D41A10FC97E532B699D0141985921DC@MAILSERVER.KalosInc.local>
Message-ID: <20150206213717.GY8034@mournblade.imrryr.org>

On Fri, Feb 06, 2015 at 01:13:08PM -0600, Rex Bloom wrote:

> I am being required to generate the following type of digital signature:
> 
> RSASSA-PKCS1-v1_5

A PKCS#1 v1.5 signature.

> I am doing the following:
> 
> openssl genrsa -aes128 -out private.pem 2048

You're generating a private key, that could be used to create PKCS#1
signatures of various objects, or could be used for some other RSA
signature scheme.

-- 
	Viktor.

From matt at openssl.org  Fri Feb  6 21:46:32 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 06 Feb 2015 21:46:32 +0000
Subject: [openssl-users] Means to update read bio only
In-Reply-To: <54D4E254.2060105@ieee.org>
References: <54D4E254.2060105@ieee.org>
Message-ID: <54D53638.7030208@openssl.org>



On 06/02/15 15:48, Susan Hinrichs wrote:
> Hello,
> 
> In Apache Traffic Server we are primarily using SSL_accept and
> SSL_read/SSL_write with file descriptor bios.
> 
> But during the handshake, we need to feed in our own packets via
> read-only buffers.  We use the BIO mem_buf to pass along this data
> without incurring another copy.  But on each read during the handshake,
> we need to reset the read bio.  We leave the write bio as the file
> descriptor bio the whole time.
> 
> I originally tried to use SSL_set_bio(ssl, new_rbio, SSL_get_wbio(ssl)),
> but that would adjust the output buffering and the handshake would not
> complete.
> 
> So we created a SSL_set_rbio(ssl, new_rbio), that just frees the old
> rbio and sets the new one.  It leaves the wbio and the bbio alone.
> 
> This has worked well for us for a couple releases, but looking forward
> to openssl 1.1, we will no longer be able to use this approach.  Can
> someone point me to the preferred way of updating a read bio without
> affecting the write bio processing?


Hmmmm... that's a good question. I don't think you can set just the rbio
by itself.

I wonder if maybe we extended SSL_set_bio, so that you could do this:

SSL_set_bio(s, rbio, NULL);

I'll look into it.

This would be a good item to add to Rich's wiki page.

Matt



From aixtools at gmail.com  Sat Feb  7 11:12:26 2015
From: aixtools at gmail.com (Michael Felt)
Date: Sat, 7 Feb 2015 12:12:26 +0100
Subject: [openssl-users] The evolution of the 'master' branch
In-Reply-To: <54D52B25.7010505@openssl.org>
References: <20150203220231.GA12587@openssl.org> <54D23F42.3060203@wisemo.com>
 <453ad2042e6c43e5897f1689e230883f@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <54D4E5D3.6090808@wisemo.com> <54D52B25.7010505@openssl.org>
Message-ID: <CANvxniX9eyam8TbBnxPz2qUvAj05r2FHm_+BEGEdM-Do2hws5A@mail.gmail.com>

>From someone who does NOT understand the in's and out's of what people
(developers and users) have been using openSSL for.
My first reaction is: have developers been using openSSL, or has it gone to
abusing it?
For the sake of argument - let's say just use as it has always been
intended.

Many technologies - especially related to security - whether it be a big
log through 'something', to skeleton keys', to digital keys, etc - we want
to be able to trust our locks. When the lock technology is no longer
trustworthy - whether it be packaging (which is what the discussion sounds
like atm) or unrepairable "concerns" with the technology asis - we change
our locks.

Not everyone changes locks at the same moment in time. urgency depends on
need, i.e., what is at risk.

I started following these discussions because I am concerned (remember I am
not really interested in the inner workings. I just think my locks are
broken and wondering if it is time to change to something that maybe "can
do less" - but what it does, does it better than what I have now.

Regardless of the choices made by openssl - people outside openssl have
needs and are looking at alternatives. To someone like me it is obvious
something must change - even if technically it is cosmetic - because
(open)SSL is losing the trust of it's users.

As a user - I need a alternative. And just as I stopped using
telnet/ftp/rsh/etc- because I could not entrust the integrity of my systems
when those doors were open - so are my concerns re: (open)SSL. In short, is
SSL still secure? And, very simply, as an un-knowledgeable user - given the
choice of a library that does something well - and that's it, versus
something else that does that - but leaves room for 'experiments' - Not on
my systems. Experiment in experiment-land.

My two bits.

On Fri, Feb 6, 2015 at 9:59 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 06/02/15 16:03, Jakob Bohm wrote:
> > I believe you have made the mistake of discussing only amongst
> > yourselves, thus gradually convincing each other of the
> > righteousness of a flawed decision.
>
>
> ...and, Rich said in a previous email (in response to your comment):
> >> I fear that this is an indication that you will be killing
> >> off all the other non-EVP entrypoints in libcrypto
> >
> > Yes there is a good chance of that happening.
>
> I'd like to stress that there has been no decision. In fact we're not
> even close to a decision on that at the moment.
>
> Whilst this has certainly been discussed I don't believe we are near to
> a consensus view at the moment. So whilst there is a good chance of that
> happening....there's also a very good chance of it not. It is still
> under discussion.
>
> 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/20150207/9dbbb8bc/attachment-0001.html>

From matt at openssl.org  Sat Feb  7 14:33:40 2015
From: matt at openssl.org (Matt Caswell)
Date: Sat, 07 Feb 2015 14:33:40 +0000
Subject: [openssl-users] Means to update read bio only
In-Reply-To: <54D53638.7030208@openssl.org>
References: <54D4E254.2060105@ieee.org> <54D53638.7030208@openssl.org>
Message-ID: <54D62244.1000807@openssl.org>



On 06/02/15 21:46, Matt Caswell wrote:
> 
> 
> On 06/02/15 15:48, Susan Hinrichs wrote:
>> Hello,
>>
>> In Apache Traffic Server we are primarily using SSL_accept and
>> SSL_read/SSL_write with file descriptor bios.
>>
>> But during the handshake, we need to feed in our own packets via
>> read-only buffers.  We use the BIO mem_buf to pass along this data
>> without incurring another copy.  But on each read during the handshake,
>> we need to reset the read bio.  We leave the write bio as the file
>> descriptor bio the whole time.
>>
>> I originally tried to use SSL_set_bio(ssl, new_rbio, SSL_get_wbio(ssl)),
>> but that would adjust the output buffering and the handshake would not
>> complete.
>>
>> So we created a SSL_set_rbio(ssl, new_rbio), that just frees the old
>> rbio and sets the new one.  It leaves the wbio and the bbio alone.
>>
>> This has worked well for us for a couple releases, but looking forward
>> to openssl 1.1, we will no longer be able to use this approach.  Can
>> someone point me to the preferred way of updating a read bio without
>> affecting the write bio processing?
> 
> 
> Hmmmm... that's a good question. I don't think you can set just the rbio
> by itself.
> 
> I wonder if maybe we extended SSL_set_bio, so that you could do this:
> 
> SSL_set_bio(s, rbio, NULL);
> 
> I'll look into it.
> 
> This would be a good item to add to Rich's wiki page.
> 

I've just pushed a new commit to master (1.1.0), that adds SSL_set_rbio,
and SSL_set_wbio as new API functions along with some associated
documentation.

Matt


From richmoore44 at gmail.com  Sat Feb  7 14:41:53 2015
From: richmoore44 at gmail.com (Richard Moore)
Date: Sat, 7 Feb 2015 14:41:53 +0000
Subject: [openssl-users] [openssl-dev] The evolution of the 'master'
	branch
In-Reply-To: <20150203220231.GA12587@openssl.org>
References: <20150203220231.GA12587@openssl.org>
Message-ID: <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>

On 3 February 2015 at 22:02, Rich Salz <rsalz at openssl.org> wrote:

> As we've already said, we are moving to making most OpenSSL data
> structures opaque. We deliberately used a non-specific term. :)
> As of Matt's commit of the other day, this is starting to happen
> now.  We know this will inconvenience people as some applications
> no longer build.  We want to work with maintainers to help them
> migrate, as we head down this path.
>
> We have a wiki page to discuss this effort.  It will eventually include
> tips on migration, application and code updates, and anything else the
> community finds useful.  Please visit:
>
>         http://wiki.openssl.org/index.php/1.1_API_Changes


I've documented what got broken in Qt by the changes so far. I've listed
the functions I think we can use instead where they exist, and those where
there does not appear to be a replacement.

Cheers

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

From matt at openssl.org  Sat Feb  7 14:44:53 2015
From: matt at openssl.org (Matt Caswell)
Date: Sat, 07 Feb 2015 14:44:53 +0000
Subject: [openssl-users] [openssl-dev] The evolution of the 'master'
	branch
In-Reply-To: <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
References: <20150203220231.GA12587@openssl.org>
 <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
Message-ID: <54D624E5.70603@openssl.org>



On 07/02/15 14:41, Richard Moore wrote:
> 
> 
> On 3 February 2015 at 22:02, Rich Salz <rsalz at openssl.org
> <mailto:rsalz at openssl.org>> wrote:
> 
>     As we've already said, we are moving to making most OpenSSL data
>     structures opaque. We deliberately used a non-specific term. :)
>     As of Matt's commit of the other day, this is starting to happen
>     now.  We know this will inconvenience people as some applications
>     no longer build.  We want to work with maintainers to help them
>     migrate, as we head down this path.
> 
>     We have a wiki page to discuss this effort.  It will eventually include
>     tips on migration, application and code updates, and anything else the
>     community finds useful.  Please visit:
> 
>             http://wiki.openssl.org/index.php/1.1_API_Changes
> 
> 
> I've documented what got broken in Qt by the changes so far. I've listed
> the functions I think we can use instead where they exist, and those
> where there does not appear to be a replacement.

Great. Thanks Rich - that's really useful. I'll take a look to see what
we can do to plug the gap.

Matt


From giuseppe.dangelo at kdab.com  Sat Feb  7 16:15:05 2015
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Sat, 07 Feb 2015 17:15:05 +0100
Subject: [openssl-users] [openssl-dev] The evolution of the 'master'
	branch
In-Reply-To: <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
References: <20150203220231.GA12587@openssl.org>
 <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
Message-ID: <54D63A09.5000003@kdab.com>

Il 07/02/2015 15:41, Richard Moore ha scritto:
> I've documented what got broken in Qt by the changes so far. I've listed
> the functions I think we can use instead where they exist, and those
> where there does not appear to be a replacement.

The other question would be: assuming there's no replacement for some 
direct field access, are people willing to add the needed functions not 
only into 1.1 but also into 1.0.x, in order to avoid code duplication 
for end users?

Thanks,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4048 bytes
Desc: Firma crittografica S/MIME
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150207/decedd60/attachment.bin>

From steve at openssl.org  Sat Feb  7 17:22:11 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sat, 7 Feb 2015 17:22:11 +0000
Subject: [openssl-users] [openssl-dev] The evolution of the 'master'
 branch
In-Reply-To: <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
References: <20150203220231.GA12587@openssl.org>
 <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
Message-ID: <20150207172211.GA26814@openssl.org>

On Sat, Feb 07, 2015, Richard Moore wrote:

> 
> I've documented what got broken in Qt by the changes so far. I've listed
> the functions I think we can use instead where they exist, and those where
> there does not appear to be a replacement.
> 

For the DH case could you store the encoding of the DHparams structure and
call d2i_DHparams instead? That should work on all versions of OpenSSL
including 1.1.

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

From noloader at gmail.com  Sat Feb  7 18:14:04 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 7 Feb 2015 13:14:04 -0500
Subject: [openssl-users] Fwd: Automated Reminder: Your Domain Name Has
	Expired 2015-02-03
In-Reply-To: <CAH8yC8=RtC1v1xY_h4WaUdO-o3AwM_E0ZHcpMw=eb=AmtywrMQ@mail.gmail.com>
References: <312592453.0.07Feb2015035207-osrs-resellers-167404@cron01.osrs.prod.tucows.net>
 <CAH8yC8=RtC1v1xY_h4WaUdO-o3AwM_E0ZHcpMw=eb=AmtywrMQ@mail.gmail.com>
Message-ID: <CAH8yC8=5btMit9+XPo57U4ZLtJRSvt2UqmqGf4vYUds7UNWjXw@mail.gmail.com>

STOP FUCKING USING MY FUCKING EMAIL ADDRESS IN EMAILS. IF YOU WANT TO
SEND AN EMAIL, SEND IT FROM YOUR OWN ACCOUNT.

BELOW, I REPLIED TO AN EMAIL SENT BY OPENSRS. BUT BECAUSE OPENSRS IS
PRETENDING TO BE ME, IT WAS SENT TO ME INSTEAD OF OPENSRS.

I'VE CHANGED ALL THESE CONTACT POINTS TO OPENSRES, SO ALL THESE SHOULD
BE COMING FROM OPENSRS AND NOT ME.

OPENSRS IS NOT AUTHORIZED TO PRETEND TO BE ME.

STOP FUCKING USING MY FUCKING EMAIL ADDRESS IN EMAILS.

---------- Forwarded message ----------
From: Jeffrey Walton <noloader at gmail.com>
Date: Sat, Feb 7, 2015 at 1:10 PM
Subject: Re: Automated Reminder: Your Domain Name Has Expired 2015-02-03
To: Jeffrey Walton <noloader at gmail.com>


I'm not renewing the domain.

There's no need to contact me 10 or 20 times. Please stop contacting
me about this.

On Sat, Feb 7, 2015 at 3:52 AM, None <noloader at gmail.com> wrote:
> Please note that your domain name has expired.
>
> Domain Name, Expiry Date
> softwareintegrity.mobi, 2015-02-03
>
>  ********IMPORTANT*******
> You can still retain this name by renewing it. Please contact your supplier immediately to renew your domain name.
>
> Thank you

From richmoore44 at gmail.com  Sat Feb  7 19:58:47 2015
From: richmoore44 at gmail.com (Richard Moore)
Date: Sat, 7 Feb 2015 19:58:47 +0000
Subject: [openssl-users] [openssl-dev] The evolution of the 'master'
	branch
In-Reply-To: <20150207172211.GA26814@openssl.org>
References: <20150203220231.GA12587@openssl.org>
 <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
 <20150207172211.GA26814@openssl.org>
Message-ID: <CAMp7mVumVF3pevj6LQM6XDVgVz492+_pYnPQpbKgVszoFDcH2w@mail.gmail.com>

On 7 February 2015 at 17:22, Dr. Stephen Henson <steve at openssl.org> wrote:

> On Sat, Feb 07, 2015, Richard Moore wrote:
>
> >
> > I've documented what got broken in Qt by the changes so far. I've listed
> > the functions I think we can use instead where they exist, and those
> where
> > there does not appear to be a replacement.
> >
>
> For the DH case could you store the encoding of the DHparams structure and
> call d2i_DHparams instead? That should work on all versions of OpenSSL
> including 1.1.
>

Good idea, yes that should work for us.

Cheers

Rich.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150207/75a6dcef/attachment-0001.html>

From viktor at szepe.net  Sat Feb  7 20:51:52 2015
From: viktor at szepe.net (=?utf-8?b?U3rDqXBl?= Viktor)
Date: Sat, 07 Feb 2015 21:51:52 +0100
Subject: [openssl-users] SHA256 docs
Message-ID: <20150207215152.Horde.AuuUM7N4D0zNQU6ea6Hbfg1@szepe.net>


Please consider including other message digest algorithms like sha256

For example here: https://www.openssl.org/docs/apps/ca.html

Thank you!

Sz?pe Viktor
-- 
+36-20-4242498  sms at szepe.net  skype: szepe.viktor
Budapest, XX. ker?let





From matt at openssl.org  Sun Feb  8 00:19:39 2015
From: matt at openssl.org (Matt Caswell)
Date: Sun, 08 Feb 2015 00:19:39 +0000
Subject: [openssl-users] [openssl-dev] The evolution of the 'master'
	branch
In-Reply-To: <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
References: <20150203220231.GA12587@openssl.org>
 <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
Message-ID: <54D6AB9B.9070703@openssl.org>



On 07/02/15 14:41, Richard Moore wrote:
> 
> 
> On 3 February 2015 at 22:02, Rich Salz <rsalz at openssl.org
> <mailto:rsalz at openssl.org>> wrote:
> 
>     As we've already said, we are moving to making most OpenSSL data
>     structures opaque. We deliberately used a non-specific term. :)
>     As of Matt's commit of the other day, this is starting to happen
>     now.  We know this will inconvenience people as some applications
>     no longer build.  We want to work with maintainers to help them
>     migrate, as we head down this path.
> 
>     We have a wiki page to discuss this effort.  It will eventually include
>     tips on migration, application and code updates, and anything else the
>     community finds useful.  Please visit:
> 
>             http://wiki.openssl.org/index.php/1.1_API_Changes
> 
> 
> I've documented what got broken in Qt by the changes so far. I've listed
> the functions I think we can use instead where they exist, and those
> where there does not appear to be a replacement.


On the wiki you say this:

"cipher->valid - we were directly accessing the valid field of
SSL_CIPHER. No replacement found."

I'm just trying to work out why you need this? As far as I can tell from
the code the only time valid isn't true is for cipher aliases ("ALL",
"COMPLEMENTOFALL" etc)...but I thought these were only used as an
SSL_CIPHER internally. E.g. if you call SSL_get_ciphers() then you only
get valid ciphers I think??

What scenario do you have where you are seeing ciphers that aren't valid?

Matt


From richmoore44 at gmail.com  Sun Feb  8 01:11:31 2015
From: richmoore44 at gmail.com (Richard Moore)
Date: Sun, 8 Feb 2015 01:11:31 +0000
Subject: [openssl-users] [openssl-dev] The evolution of the 'master'
	branch
In-Reply-To: <54D6AB9B.9070703@openssl.org>
References: <20150203220231.GA12587@openssl.org>
 <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
 <54D6AB9B.9070703@openssl.org>
Message-ID: <CAMp7mVuOJ5f1=vbibF2bkoDHraQUGyUGf73rc4X7_2Y0c6g+dA@mail.gmail.com>

On 8 February 2015 at 00:19, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 07/02/15 14:41, Richard Moore wrote:
> >
> >
> > On 3 February 2015 at 22:02, Rich Salz <rsalz at openssl.org
> > <mailto:rsalz at openssl.org>> wrote:
> >
> >     As we've already said, we are moving to making most OpenSSL data
> >     structures opaque. We deliberately used a non-specific term. :)
> >     As of Matt's commit of the other day, this is starting to happen
> >     now.  We know this will inconvenience people as some applications
> >     no longer build.  We want to work with maintainers to help them
> >     migrate, as we head down this path.
> >
> >     We have a wiki page to discuss this effort.  It will eventually
> include
> >     tips on migration, application and code updates, and anything else
> the
> >     community finds useful.  Please visit:
> >
> >             http://wiki.openssl.org/index.php/1.1_API_Changes
> >
> >
> > I've documented what got broken in Qt by the changes so far. I've listed
> > the functions I think we can use instead where they exist, and those
> > where there does not appear to be a replacement.
>
>
> On the wiki you say this:
>
> "cipher->valid - we were directly accessing the valid field of
> SSL_CIPHER. No replacement found."
>
> I'm just trying to work out why you need this? As far as I can tell from
> the code the only time valid isn't true is for cipher aliases ("ALL",
> "COMPLEMENTOFALL" etc)...but I thought these were only used as an
> SSL_CIPHER internally. E.g. if you call SSL_get_ciphers() then you only
> get valid ciphers I think??
>
> What scenario do you have where you are seeing ciphers that aren't valid?
>

Excellent question. This is code I inherited, and I can't see a sane reason
why the cipher might not be valid. I strongly suspect removing this bit of
code is actually the right solution here. The code is at
http://code.woboq.org/qt5/qtbase/src/network/ssl/qsslsocket_openssl.cpp.html#651

Maybe some edge case for things like the TLS_FALLBACK_SCSV could have an
effect, but even then I can't see how it would relevant to the code that's
actually doing this.

Cheers

Rich.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150208/4e0d6f52/attachment.html>

From getur.srikanth at gmail.com  Sun Feb  8 08:16:46 2015
From: getur.srikanth at gmail.com (Itsmesri)
Date: Sun, 8 Feb 2015 01:16:46 -0700 (MST)
Subject: [openssl-users] error:02001002:system library:fopen:No such file or
 directory:.\crypto\bio\bss_file.c
Message-ID: <1423383406512-56325.post@n7.nabble.com>

I am newbie to OPENSSL world.I am trying into install openssl certification
on my microsoft exchange server. For this I was following below article step
by step. at one place I stuck while createing 'ca' and getting below errors. 

I have created index.txt , serial files and have proper permissions.

article: 
http://www.stephen-scotter.net/computers/windows/exchange/using-openssl-to-create-a-certificate-for-exchange-2010#exchange2010
<http://www.stephen-scotter.net/computers/windows/exchange/using-openssl-to-create-a-certificate-for-exchange-2010#exchange2010>  

C:\OpenSSL-Win64>bin\openssl.exe ca -name ServerCA -policy policy_anything
-in SIFY_CA\requests\SIFYSERV4-EXCHANGE.csr -o
t SIFY_CA\certs\SIFYSERV4-EXCHANGE-WRONGFORMAT.cer -md sha1
Using configuration from c:\OpenSSL-Win64\bin\openssl.cfg
Loading 'screen' into random state - done
Enter pass phrase for \\DALLAS\OpenSSL-Win64\SIFY_CA\private\SIFY_CA.key:
Error Loading extension section ca_cert
11128:error:02001002:system library:fopen:No such file or
directory:.\crypto\bio\bss_file.c:169:fopen('\\DALLAS\OpenSSL-Win64\SIFY_CA\index.txt.attr','rb')
11128:error:2006D080:BIO routines:BIO_new_file:no such
file:.\crypto\bio\bss_file.c:172:
11128:error:0E078072:configuration file routines:DEF_LOAD:no such
file:.\crypto\conf\conf_def.c:197:
11128:error:2207507C:X509 V3 routines:v2i_GENERAL_NAME_ex:missing
value:.\crypto\x509v3\v3_alt.c:537:
11128:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in
extension:.\crypto\x509v3\v3_conf.c:93:name=subjectAltName, value=D
S:sifytech.com,DNS:www.sifytech.com;DNS:*.sifytech.com,mail.SIFY.com,owa.sifytech.com

 openssl.cfg
---------------
HOME     = \\\\DALLAS\\OpenSSL-Win64
#RANDFILE = $HOME\\.rnd

[ca]
default_ca = SIFY_CA

[SIFY_CA]
dir              = $HOME\\SIFY_CA
certs            = $dir\\certs
crl_dir          = $dir\\crl
database         = $dir\\index.txt
new_certs_dir    = $dir\\newcerts
certificate      = $certs\\SIFY_CA.cer
serial           = $dir\\serial
crl              = $crl_dir\\SIFY_CA.crl
private_key      = $dir\\private\\SIFY_CA.key
RANDFILE         = $dir\\private\\.rnd
unique_subject   = no
email_in_dn      = yes
policy           = policy_match
x509_extensions  = ca_cert
default_days     = 18250 
default_crl_days = 18250 
default_md       = md5


[ServerCA]
dir              = $HOME\\SIFY_CA
certs            = $dir\\certs
crl_dir          = $dir\\crl
database         = $dir\\index.txt
new_certs_dir    = $dir\\newcerts
certificate      = $certs\\SIFY_CA.cer
serial           = $dir\\serial
#####crl              = $crl_dir\\ServerCA.crl
crl              = $crl_dir\\SIFY_CA.crl
private_key      = $dir\\private\\SIFY_CA.key
RANDFILE         = $dir\\private\\.rnd
unique_subject   = no
email_in_dn      = yes
policy           = policy_match
x509_extensions  = ca_cert
default_days     = 18250 
default_crl_days = 18250 
default_md       = md5
#####copy_extensions  = copy
#####copy_extensions  = none

[policy_match]
countryName            = match
stateOrProvinceName    = optional
organizationName       = optional
organizationalUnitName = supplied
commonName             = supplied
emailAddress           = optional

[policy_anything]
countryName            = optional
stateOrProvinceName    = optional
localityName           = optional
organizationName       = optional
organizationalUnitName = optional
commonName             = supplied
emailAddress           = optional

[req]
default_bits       = 2048
default_keyfile    = privkey.pem
distinguished_name = req_distinguished_name
#attributes        = req_attributes
x509_extensions    = v3_ca
req_extensions     = v3_req

[req_distinguished_name]
countryName			= Country Name (2 letter code)
countryName_default		= GB
countryName_min			= 2
countryName_max			= 2
stateOrProvinceName		= State or Province Name (full name)
stateOrProvinceName_default	= West Midlands
localityName			= Locality Name (eg, city)
localityName_default            = Birmingham
0.organizationName		= Organization Name (eg, company)
0.organizationName_default	= WHLB (Certificate Authority)
organizationalUnitName		= Organizational Unit Name (eg, section)
organizationalUnitName_default	=
commonName			= Common Name (eg, YOUR name)
commonName_default		= WHLB (Certificate Authority)
commonName_max			= 64
emailAddress			= Email Address
emailAddress_max		= 64


[v3_ca]
#basicConstraints      = critical, CA:true, pathlen:0
basicConstraints      = CA:true
#nsCertType            = sslCA
#keyUsage              = cRLSign, keyCertSign
#extendedKeyUsage      = serverAuth, clientAuth
nsComment             = "OpenSSL CA Certificate"
crlDistributionPoints =
URI:http://dallas.sifytech.com/SIFY_ca/crl/SIFY_CA.crl

[v3_req]
basicConstraints      = CA:FALSE
keyUsage              = nonRepudiation, digitalSignature, keyEncipherment
crlDistributionPoints =
URI:http://dallas.sifytech.com/SIFY_ca/crl/SIFY_CA.crl

[ca_cert]
basicConstraints       = CA:true
nsComment              = "OpenSSL Generated Certificate"
subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid, issuer:always
extendedKeyUsage       = serverAuth, clientAuth
crlDistributionPoints =
URI:https://dallas.sifytech.com/SIFY_ca/crl/SIFY_CA.crl
subjectAltName        =
DNS:sifytech.com,DNS:www.sifytech.com;DNS:*.sifytech.com,mail.intensify.com,owa.sifytech.com

What could be wrong? Did I miss anything here? Help me out?



--
View this message in context: http://openssl.6102.n7.nabble.com/error-02001002-system-library-fopen-No-such-file-or-directory-crypto-bio-bss-file-c-tp56325.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From matt at openssl.org  Sun Feb  8 16:14:03 2015
From: matt at openssl.org (Matt Caswell)
Date: Sun, 08 Feb 2015 16:14:03 +0000
Subject: [openssl-users] [openssl-dev] The evolution of the 'master'
	branch
In-Reply-To: <CAMp7mVuOJ5f1=vbibF2bkoDHraQUGyUGf73rc4X7_2Y0c6g+dA@mail.gmail.com>
References: <20150203220231.GA12587@openssl.org>
 <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
 <54D6AB9B.9070703@openssl.org>
 <CAMp7mVuOJ5f1=vbibF2bkoDHraQUGyUGf73rc4X7_2Y0c6g+dA@mail.gmail.com>
Message-ID: <54D78B4B.8040206@openssl.org>



On 08/02/15 01:11, Richard Moore wrote:
> Maybe some edge case for things like the TLS_FALLBACK_SCSV could have an
> effect, but even then I can't see how it would relevant to the code
> that's actually doing this.

I thought about that myself and so checked TLS_FALLBACK_SCSV - but even
that is marked as "valid".

Matt

From rsalz at akamai.com  Sun Feb  8 23:21:32 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 8 Feb 2015 23:21:32 +0000
Subject: [openssl-users] [openssl-dev] The evolution of the
	'master'	branch
In-Reply-To: <54D63A09.5000003@kdab.com>
References: <20150203220231.GA12587@openssl.org>
 <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
 <54D63A09.5000003@kdab.com>
Message-ID: <19d281b1a3cf49cd84429a19f5e9604c@ustx2ex-dag1mb2.msg.corp.akamai.com>

> The other question would be: assuming there's no replacement for some
> direct field access, are people willing to add the needed functions not only
> into 1.1 but also into 1.0.x, in order to avoid code duplication for end users?

The idea of a 'shim' layer that helps bridge the gap between 1.1 new functions and 1.0.x exposed struct's seems like a great idea and hopefully not a lot of work.

From khang.social at gmail.com  Mon Feb  9 10:56:34 2015
From: khang.social at gmail.com (Khang Nguyen)
Date: Mon, 9 Feb 2015 17:56:34 +0700
Subject: [openssl-users] ui_openssl.c is assuming that current console is
	ECHO(termios) enabled
In-Reply-To: <CA+ZoFDFKhHNpvt7SiH_KiEY72wz+O3D+b9Z254U=NgzOPcunxQ@mail.gmail.com>
References: <CA+ZoFDFKhHNpvt7SiH_KiEY72wz+O3D+b9Z254U=NgzOPcunxQ@mail.gmail.com>
Message-ID: <CA+ZoFDFsMhLP4MZz=PwWAUOx7vWRLiFh5Lm7MgyGHjcmc74NPQ@mail.gmail.com>

Hi,

OpenSSL, to be specific, ui_openssl.c, in my opinion, is assuming that
the current console before "Enter PEM pass phrase" prompt being
carried out is set with ECHO on (termios).

After using that prompt to get a pass phrase, applications using stdin
with ECHO off such as in the case of pseudo-terminals (pty) will
display any character twice when its key was pressed instead of only
once.

One example is text-mode pty IRC client irssi 0.8.15, using
self-signed certificate login protected with a pass phrase, utilizing
the "Enter PEM pass phrase" prompt.

crypto/ui/ui_openssl.c

static int noecho_console(UI *ui)
{
  #ifdef TTY_FLAGS
	  memcpy(&(tty_new),&(tty_orig),sizeof(tty_orig));
	  tty_new.TTY_FLAGS &= ~ECHO;
  #endif
...
}

static int echo_console(UI *ui)
	{
#if defined(TTY_set) && !defined(OPENSSL_SYS_VMS)
	memcpy(&(tty_new),&(tty_orig),sizeof(tty_orig));
	tty_new.TTY_FLAGS |= ECHO;
#endif
...
}

Of course, a guard can be put into client applications to back up and
restore the attributes. But should this behaviour in openssl be
allowed ? Or am I looking into the wrong place ?

I wonder why ECHO is added to the current terminal attributes after
the prompt is finished. My strace log found that c_lflags (local
modes) before the prompt is 0x8a31 and 0x8a39 afterwards.

OS : Slackware 14.1

Regards,
Khang.

From shinrich at ieee.org  Mon Feb  9 15:15:00 2015
From: shinrich at ieee.org (Susan Hinrichs)
Date: Mon, 09 Feb 2015 09:15:00 -0600
Subject: [openssl-users] Means to update read bio only
In-Reply-To: <54D62244.1000807@openssl.org>
References: <54D4E254.2060105@ieee.org> <54D53638.7030208@openssl.org>
 <54D62244.1000807@openssl.org>
Message-ID: <54D8CEF4.3040903@ieee.org>


On 2/7/2015 8:33 AM, Matt Caswell wrote:
>
> On 06/02/15 21:46, Matt Caswell wrote:
>>
>> On 06/02/15 15:48, Susan Hinrichs wrote:
>>> Hello,
>>>
>>> In Apache Traffic Server we are primarily using SSL_accept and
>>> SSL_read/SSL_write with file descriptor bios.
>>>
>>> But during the handshake, we need to feed in our own packets via
>>> read-only buffers.  We use the BIO mem_buf to pass along this data
>>> without incurring another copy.  But on each read during the handshake,
>>> we need to reset the read bio.  We leave the write bio as the file
>>> descriptor bio the whole time.
>>>
>>> I originally tried to use SSL_set_bio(ssl, new_rbio, SSL_get_wbio(ssl)),
>>> but that would adjust the output buffering and the handshake would not
>>> complete.
>>>
>>> So we created a SSL_set_rbio(ssl, new_rbio), that just frees the old
>>> rbio and sets the new one.  It leaves the wbio and the bbio alone.
>>>
>>> This has worked well for us for a couple releases, but looking forward
>>> to openssl 1.1, we will no longer be able to use this approach.  Can
>>> someone point me to the preferred way of updating a read bio without
>>> affecting the write bio processing?
>>
>> Hmmmm... that's a good question. I don't think you can set just the rbio
>> by itself.
>>
>> I wonder if maybe we extended SSL_set_bio, so that you could do this:
>>
>> SSL_set_bio(s, rbio, NULL);
>>
>> I'll look into it.
>>
>> This would be a good item to add to Rich's wiki page.
>>
> I've just pushed a new commit to master (1.1.0), that adds SSL_set_rbio,
> and SSL_set_wbio as new API functions along with some associated
> documentation.
>
> Matt

Great!  Thanks for the addition.  I'll take it for a spin.

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


From sanchit1.arora at gmail.com  Mon Feb  9 20:17:46 2015
From: sanchit1.arora at gmail.com (sanchit arora)
Date: Mon, 9 Feb 2015 15:17:46 -0500
Subject: [openssl-users] DTLS Handshake issue
 (openssl-1.0.1e-dtls-ecc-ext.patch) leads to process crash
Message-ID: <CAGgXGhJWRapuKc3bzBxyC2-DckGLTKnxQXHwnoyfFJ9jd-QkQw@mail.gmail.com>

Bug report

OS: Linux

OpenSSL Version: 1.0.1e-30


While doing DTLS testing with openssl-1.0.1e-30 Version and patches
for RT3327, RT3470 and RT3483 on top of that, we are facing an issue
where our process is crashing during the duration run of 24 hours.

Use Case:
*        There are 125 DTLS Server Connections and 125 DTLS Client Connections.
*        Connection Attempts towards Server connections are also being
made every 1 second.
*        Client Connections are initiating connection attempts every 1 second .
*        SSL Handshake is made to fail so that connection attempts
continues and there are no crashes observed.

During the above duration run, process is always crashing at the below
location always.

#4  <signal handler called>
#5  0x00007f61e97188e9 in sha1_block_data_order_ssse3 () from
/usr/lib64/libcrypto.so.10
#6  0xad89a0d6776026f6 in ?? ()
#7  0xf9e71fd74025dad7 in ?? ()
#8  0x2243d5d8167d7997 in ?? ()
#9  0x8bbb75d9b4efd5d8 in ?? ()
#10 0xea9689da4d4ac2cb in ?? ()
#11 0x7067bc5f5034983b in ?? ()
#12 0xe19f5aa4a5679ed0 in ?? ()
#13 0x8ecbf7e83d1d8ccd in ?? ()
#14 0x00007f61e9a827ce in state () from /usr/lib64/libcrypto.so.10
#15 0x00000000bc803cd0 in ?? ()
#16 0x0000000000000011 in ?? ()
#17 0x00007f61e9715de7 in SHA1_Update () from /usr/lib64/libcrypto.so.10
#18 0x00007f61e97899fd in ssleay_rand_add () from /usr/lib64/libcrypto.so.10
#19 0x00007f61e9ed92f9 in dtls1_accept () from /usr/lib64/libssl.so.10

When we tested with openssl-1.0.1e-16 Version and patches for RT3327,
RT3470 and RT3483 on top of that, the use case works fine.

On investigation, we found that there are 11 patches added between
openssl-1.0.1e-30 and openssl-1.0.1e-16 version out of which following
3 patches are related to DTLS.

openssl-1.0.1e-dtls-ecc-ext.
patch
openssl-1.0.1e-cve-2014-3513.
patch
openssl-1.0.1e-fallback-scsv.patch

We have narrowed down that when we use openssl-1.0.1e-30 Version with
the openssl-1.0.1e-dtls-ecc-ext.patch and patches for RT3327, RT3470
and RT3483 on top of that, process crashes with the above abterm
during the duration run of 24 hours.

When we excluded the openssl-1.0.1e-dtls-ecc-ext.patch from
openssl-1.0.1e-30 Version, we didn't see an abterm during the duration
run of 24  hours.

Therefore, it seems that the openssl-1.0.1e-dtls-ecc-ext.patch is
causing the abterm in the duration run.

Please let us know if there could be issues with the
openssl-1.0.1e-dtls-ecc-ext.patch?

Regards,
Sanchit Arora

From matt at openssl.org  Mon Feb  9 23:07:50 2015
From: matt at openssl.org (Matt Caswell)
Date: Mon, 09 Feb 2015 23:07:50 +0000
Subject: [openssl-users] DTLS Handshake issue
 (openssl-1.0.1e-dtls-ecc-ext.patch) leads to process crash
In-Reply-To: <CAGgXGhJWRapuKc3bzBxyC2-DckGLTKnxQXHwnoyfFJ9jd-QkQw@mail.gmail.com>
References: <CAGgXGhJWRapuKc3bzBxyC2-DckGLTKnxQXHwnoyfFJ9jd-QkQw@mail.gmail.com>
Message-ID: <54D93DC6.90300@openssl.org>



On 09/02/15 20:17, sanchit arora wrote:
> Bug report
> 
> OS: Linux

Which distro?

> 
> OpenSSL Version: 1.0.1e-30

That is not an OpenSSL version - that is an OS vendor specific version
based on OpenSSL 1.0.1e

> While doing DTLS testing with openssl-1.0.1e-30 Version and patches
> for RT3327, RT3470 and RT3483 on top of that, we are facing an issue
> where our process is crashing during the duration run of 24 hours.
> 
> Use Case:
> *        There are 125 DTLS Server Connections and 125 DTLS Client Connections.
> *        Connection Attempts towards Server connections are also being
> made every 1 second.
> *        Client Connections are initiating connection attempts every 1 second .
> *        SSL Handshake is made to fail so that connection attempts
> continues and there are no crashes observed.
> 
> During the above duration run, process is always crashing at the below
> location always.
> 
> #4  <signal handler called>
> #5  0x00007f61e97188e9 in sha1_block_data_order_ssse3 () from
> /usr/lib64/libcrypto.so.10
> #6  0xad89a0d6776026f6 in ?? ()
> #7  0xf9e71fd74025dad7 in ?? ()
> #8  0x2243d5d8167d7997 in ?? ()
> #9  0x8bbb75d9b4efd5d8 in ?? ()
> #10 0xea9689da4d4ac2cb in ?? ()
> #11 0x7067bc5f5034983b in ?? ()
> #12 0xe19f5aa4a5679ed0 in ?? ()
> #13 0x8ecbf7e83d1d8ccd in ?? ()
> #14 0x00007f61e9a827ce in state () from /usr/lib64/libcrypto.so.10
> #15 0x00000000bc803cd0 in ?? ()
> #16 0x0000000000000011 in ?? ()
> #17 0x00007f61e9715de7 in SHA1_Update () from /usr/lib64/libcrypto.so.10
> #18 0x00007f61e97899fd in ssleay_rand_add () from /usr/lib64/libcrypto.so.10
> #19 0x00007f61e9ed92f9 in dtls1_accept () from /usr/lib64/libssl.so.10

There is insufficient information in the above to diagnose the problem.
We would need a build with full debugging symbols.


> 
> When we tested with openssl-1.0.1e-16 Version and patches for RT3327,
> RT3470 and RT3483 on top of that, the use case works fine.
> 
> On investigation, we found that there are 11 patches added between
> openssl-1.0.1e-30 and openssl-1.0.1e-16 version out of which following
> 3 patches are related to DTLS.
> 
> openssl-1.0.1e-dtls-ecc-ext.
> patch
> openssl-1.0.1e-cve-2014-3513.
> patch
> openssl-1.0.1e-fallback-scsv.patch
> 
> We have narrowed down that when we use openssl-1.0.1e-30 Version with
> the openssl-1.0.1e-dtls-ecc-ext.patch and patches for RT3327, RT3470
> and RT3483 on top of that, process crashes with the above abterm
> during the duration run of 24 hours.
> 
> When we excluded the openssl-1.0.1e-dtls-ecc-ext.patch from
> openssl-1.0.1e-30 Version, we didn't see an abterm during the duration
> run of 24  hours.
> 
> Therefore, it seems that the openssl-1.0.1e-dtls-ecc-ext.patch is
> causing the abterm in the duration run.
> 
> Please let us know if there could be issues with the
> openssl-1.0.1e-dtls-ecc-ext.patch?

All of the above are vendor specific patches (probably based on original
OpenSSL commits). However I don't know from the name what dtls-ecc-ext
is referring to. You would need to address your specific question to
your vendor.

Is it possible that you can run the latest 1.0.1 version of standard
OpenSSL (i.e. OpenSSL 1.0.1l)? There have been some significant DTLS
related fixes that have been applied in recent versions.

Matt






From jb-openssl at wisemo.com  Tue Feb 10 00:46:27 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 10 Feb 2015 01:46:27 +0100
Subject: [openssl-users] How to load local certificate folder on windows
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801344971B4@Rock-Exchange1.microfocus.com>
References: <CAEKwp_FS6U-cLQjSOEWgcSj_dyaTPNdd9bZSR1pJk8zDXWFpEw@mail.gmail.com>
 <000c01d0422e$e32fe4c0$a98fae40$@prinpay.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801344971B4@Rock-Exchange1.microfocus.com>
Message-ID: <54D954E3.7000103@wisemo.com>

On 06/02/2015 20:19, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of Dave Thompson
>> Sent: Friday, February 06, 2015 12:04
>>
>> * Windows beginning AIR XP or maybe NT does support links on NTFS,
>> but they're not easy to use and not well known, and I think I saw a recent
>> bug report that they don't even work for OpenSSL,  at least sometimes.
> In modern versions of Windows, NTFS supports three sorts of link-like objects: file symbolic links, directory symbolic links, and junctions, all of which are types of reparse points. Older versions of NTFS only support junctions. These can be created with the mklink command. Prior to Vista, there was no command in the base OS for this purpose, and you needed something like linkd from the Windows Server Resource Kit to manipulate links.
Actually, there is a 4th and 5th form of NTFS native
symbolic links: "POSIX" subsystem symbolic links, which
have all the expected semantics but may not work with
Win32 programs such as OpenSSL; and DFS junctions which
have special semantics for the SMB/CIFS file sharing
protocol.
> I just did a bit of testing with openssl.exe from OpenSSL 1.0.1k. It appears to work correctly with all three.
>
> Windows also supports "shortcuts", but those are a Windows Explorer artifact. They're just files that have a particular extension and particular sort of contents. OpenSSL doesn't support them, but then neither do most programs. Shortcuts were invented for Windows 95 to overcome some of the limitations of the FAT32 filesystem. They're rubbish.
Actually, shortcuts are really desktop/start menu entries,
which store a command line, startup directory, menu icon
and launch options.  They work like the ".desktop" files
in modern Linux desktop environments and should never have
been confused with symbolic links.  They were created as
a more flexible replacement for the Windows 3.x program
manager icon group files.
> And Cygwin provides both hard and symbolic UNIX-style links for NTFS. Hard links can only be to files. I'm not sure how Cygwin implements them, but they seem to work fine with OpenSSL.
All versions of NTFS support hard links natively, though
there is no command in the base OS to create them, and
prior to Windows 2000, they could only be created via
an undocumented API and/or by using the "POSIX" subsystem
(which did include a working ln command though).  When
you run chkdsk (fsck) on an NTFS file system, you will see
inodes referred to as "Files" in the "Master File Table"
and directories as "Indexes".
> Cygwin supports multiple implementations of symbolic links; see https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks. Default symbolic links are ordinary files recognized by the Cygwin library as special, so they aren't handled by (non-Cygwin) OpenSSL. Shortcut-style symlinks are shortcuts, so per above they do not work. Native symlinks are Windows symlinks and should work fine with OpenSSL. The native implementation can be selected by setting the CYGWIN environment variable appropriately, so (contrary to recent messages on the list) there's no reason to rewrite c_rehash for use on Windows.

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 secaficionado at gmail.com  Tue Feb 10 00:53:19 2015
From: secaficionado at gmail.com (Sec_Aficionado)
Date: Mon, 9 Feb 2015 19:53:19 -0500
Subject: [openssl-users] AES-GCM failing from Command Line Interface
Message-ID: <F6BC0BA9-2194-4772-9DA5-1DFB348D7F6F@gmail.com>

Hello,

I am trying to encrypt a short message using AES-256-GCM as mentioned in the subject.

My command is:
openssl enc -aes-256-gcm -p -in payload.txt -out enc.txt

I get prompted for password as expected.

The encryption goes well, and then I proceed to decrypt using:
openssl enc -d -aes-256-gcm -p -in enc.txt -out dec.txt

The program executes but I get a "bad decrypt" message. However, when I open dec.txt, it is the same as the original file payload.txt

My guess is that the problem is in the padding, but I have not been able to eliminate the error message, even setting the -nopad option and padding manually.

Can someone please explain to me why this might be happening?

I am running openSSL 1.0.1f (6 Jan 14) on an Ubuntu 14.04 LTS VM with current patches.

Thanks in advance for your help.

Sent from my mobile

From jb-openssl at wisemo.com  Tue Feb 10 01:16:33 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 10 Feb 2015 02:16:33 +0100
Subject: [openssl-users] The evolution of the 'master' branch
In-Reply-To: <CANvxniX9eyam8TbBnxPz2qUvAj05r2FHm_+BEGEdM-Do2hws5A@mail.gmail.com>
References: <20150203220231.GA12587@openssl.org> <54D23F42.3060203@wisemo.com>
 <453ad2042e6c43e5897f1689e230883f@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <54D4E5D3.6090808@wisemo.com> <54D52B25.7010505@openssl.org>
 <CANvxniX9eyam8TbBnxPz2qUvAj05r2FHm_+BEGEdM-Do2hws5A@mail.gmail.com>
Message-ID: <54D95BF1.5080003@wisemo.com>

On 07/02/2015 12:12, Michael Felt wrote:
> From someone who does NOT understand the in's and out's of what people 
> (developers and users) have been using openSSL for.
> My first reaction is: have developers been using openSSL, or has it 
> gone to abusing it?
> For the sake of argument - let's say just use as it has always been 
> intended.
>
Fundamentally, since its inception by EAY years ago, "OpenSSL"
has provided two things to other software developers: A very
popular implementation of the SSL protocols defined by
Netscape/Mozilla/IETF, and an equally popular library of
fundamental cryptographic building blocks such as large
numbers and various types of encryption and decryption.

My criticism of the OpenSSL changes in the future version
1.1.0 is that they are removing the most flexible building
blocks from the part that is intended to be used.

> Many technologies - especially related to security - whether it be a 
> big log through 'something', to skeleton keys', to digital keys, etc - 
> we want to be able to trust our locks. When the lock technology is no 
> longer trustworthy - whether it be packaging (which is what the 
> discussion sounds like atm) or unrepairable "concerns" with the 
> technology asis - we change our locks.
>
2014 saw some widely published problems with various SSL
variants.

   "Heartbleed" was a programming error found *only* in
the OpenSSL SSL code and did not affect the handful of
competing SSL implementations (such as the NSS one by
Mozilla and the STUNNEL one by Microsoft).  Essentially,
heartbleed allowed people to put a hook through the
keyhole and steal the key from behind the locked door.

   "Poodle" was a new way to attack a known weakness in
the old version 3.0 of the SSL protocol, affecting all
implementations, combined with a weakness in how Web
Browsers work around bad SSL libraries that refuse to
even reply to requests for protocol version 3.1 ("TLS
1.0").  On top of that, it turned out that a few minor
competing SSL implementations (not OpenSSL, NSS and
STUNNEL) never implemented the TLS 1.0 protection
against the known weakness, leading to a rumor that
poodle affected all "TLS 1.0" implementations, and
not just the few broken ones.

> Not everyone changes locks at the same moment in time. urgency depends 
> on need, i.e., what is at risk.
>
> I started following these discussions because I am concerned (remember 
> I am not really interested in the inner workings. I just think my 
> locks are broken and wondering if it is time to change to something 
> that maybe "can do less" - but what it does, does it better than what 
> I have now.
>
> Regardless of the choices made by openssl - people outside openssl 
> have needs and are looking at alternatives. To someone like me it is 
> obvious something must change - even if technically it is cosmetic - 
> because (open)SSL is losing the trust of it's users.
>
> As a user - I need a alternative. And just as I stopped using 
> telnet/ftp/rsh/etc- because I could not entrust the integrity of my 
> systems when those doors were open - so are my concerns re: (open)SSL. 
> In short, is SSL still secure? And, very simply, as an 
> un-knowledgeable user - given the choice of a library that does 
> something well - and that's it, versus something else that does that - 
> but leaves room for 'experiments' - Not on my systems. Experiment in 
> experiment-land.
>
> My two bits.
>
> On Fri, Feb 6, 2015 at 9:59 PM, Matt Caswell <matt at openssl.org 
> <mailto:matt at openssl.org>> wrote:
>
>
>
>     On 06/02/15 16:03, Jakob Bohm wrote:
>     > I believe you have made the mistake of discussing only amongst
>     > yourselves, thus gradually convincing each other of the
>     > righteousness of a flawed decision.
>
>
>     ...and, Rich said in a previous email (in response to your comment):
>     >> I fear that this is an indication that you will be killing
>     >> off all the other non-EVP entrypoints in libcrypto
>     >
>     > Yes there is a good chance of that happening.
>
>     I'd like to stress that there has been no decision. In fact we're not
>     even close to a decision on that at the moment.
>
>     Whilst this has certainly been discussed I don't believe we are
>     near to
>     a consensus view at the moment. So whilst there is a good chance
>     of that
>     happening....there's also a very good chance of it not. It is still
>     under discussion.
>
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/20150210/b1a4e385/attachment-0001.html>

From steve at openssl.org  Tue Feb 10 02:23:30 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 10 Feb 2015 02:23:30 +0000
Subject: [openssl-users] AES-GCM failing from Command Line Interface
In-Reply-To: <F6BC0BA9-2194-4772-9DA5-1DFB348D7F6F@gmail.com>
References: <F6BC0BA9-2194-4772-9DA5-1DFB348D7F6F@gmail.com>
Message-ID: <20150210022330.GA15638@openssl.org>

On Mon, Feb 09, 2015, Sec_Aficionado wrote:

> Hello,
> 
> I am trying to encrypt a short message using AES-256-GCM as mentioned in the subject.
> 
> My command is:
> openssl enc -aes-256-gcm -p -in payload.txt -out enc.txt
> 
> I get prompted for password as expected.
> 
> The encryption goes well, and then I proceed to decrypt using:
> openssl enc -d -aes-256-gcm -p -in enc.txt -out dec.txt
> 
> The program executes but I get a "bad decrypt" message. However, when I open dec.txt, it is the same as the original file payload.txt
> 
> My guess is that the problem is in the padding, but I have not been able to eliminate the error message, even setting the -nopad option and padding manually.
> 
> Can someone please explain to me why this might be happening?
> 
> I am running openSSL 1.0.1f (6 Jan 14) on an Ubuntu 14.04 LTS VM with current patches.
> 

AES GCM is not supported by the 'enc' utility. More recent versions of OpenSSL
throw out and error message if you try to use it from the command line.

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

From oyljerry at gmail.com  Tue Feb 10 07:17:18 2015
From: oyljerry at gmail.com (Jerry OELoo)
Date: Tue, 10 Feb 2015 15:17:18 +0800
Subject: [openssl-users] How to construct certificate chain
In-Reply-To: <20141117074340.GZ13179@mournblade.imrryr.org>
References: <CAEKwp_GY=HJ9nYF5wwmDHt=S5rxMMGyTt-nDMKBxspHHRjubdw@mail.gmail.com>
 <20141117074340.GZ13179@mournblade.imrryr.org>
Message-ID: <CAEKwp_FzJ9syf=2VjF=ThEVFjzbvnNvt+7qi1x+U517sqmhVOA@mail.gmail.com>

I am using 1.0.2 stable release and add below code but it still get
Equifax but browser get GeoTrust Global CA

    X509_VERIFY_PARAM *param;
    param = X509_VERIFY_PARAM_new();
    X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_TRUSTED_FIRST);
    SSL_CTX_set1_param(ctx, param);
    X509_VERIFY_PARAM_free(param);




On Mon, Nov 17, 2014 at 3:43 PM, Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
> On Mon, Nov 17, 2014 at 03:13:22PM +0800, Jerry OELoo wrote:
>
>> When I construct google's (www.google.com) certificate chain, it is
>> different with browser's
>>
>> [openssl API]
>> www.google.com -> Google Internet Authority G2 -> GeoTrust Global CA
>> -> Equifax Secure Certificate Authority
>
> This is what Google sends on the wire.
>
>> [IE/Chrome]
>> www.google.com -> Google Internet Authority G2 -> GeoTrust Global CA
>
> The browsers short-cicuit the chain, by finding an alternative trusted
> issuer for "G2"
>
>> It seems openssl use one certificate path with "bridge cert" but
>> browsers use another certificate path, and in answer, it said
>> "OpenSSL, which curl uses, is not, or at least not yet; thus you must
>> tell curl to give OpenSSL the Equifax root. (The OpenSSL 1.0.2
>> release, currently in beta, is announced to have enhancements in the
>> area of cert chain validation, which I haven't looked at in detail
>> yet.",
>
> Commit 9d2006d8 (1.0.2 branch) implements a new X509_V_FLAG_TRUSTED_FIRST
> flag which should give similar (to the browsers) results if set in
> the X509_STORE_CTX used to validate the chain via:
>
>     X509_VERIFY_PARAM_set_flags()
>
> and
>
>     SSL_CTX_set1_param()
>
> see apps/apps.c and apps/s_client.c
>
>> So is there any way that openssl 1.0.1j can solve this and construct
>> same certificate path with browsers did?
>
> No, but it is far from clear why "this" is a problem.  Google sends
> a chain signed by Equifax.  So OpenSSL builds a chain with that.
> When Google stops sending the Equifax cert, OpenSSL will use the
> GeoTrust root CA if that's configured.
>
> --
>         Viktor.
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users at openssl.org
> Automated List Manager                           majordomo at openssl.org



-- 
Rejoice,I Desire!

From secaficionado at gmail.com  Tue Feb 10 14:09:02 2015
From: secaficionado at gmail.com (Sec_Aficionado)
Date: Tue, 10 Feb 2015 09:09:02 -0500
Subject: [openssl-users] AES-GCM failing from Command Line Interface
In-Reply-To: <20150210022330.GA15638@openssl.org>
References: <F6BC0BA9-2194-4772-9DA5-1DFB348D7F6F@gmail.com>
 <20150210022330.GA15638@openssl.org>
Message-ID: <FCF226D1-49CA-41B4-8703-F0C3F68E335A@gmail.com>

Ah, thank you! I tried a lot of things and was very frustrated. I wish the documentation reflected that. I'll see if I can contribute by updating it.

Regarding AES-GCM from the command line, or PHP bindings, is that something that any of the OpenSSL components support? I think EVP is the intended way but there are no PHP bindings, only C from what I can tell.

As a bit of background, I need to send an encrypted token to a client, which will return it when communicating back with the server. I need some form of authenticated encryption for that and OpenSSL seems like a perfect fit.

Thanks for your help.

Sent from my mobile

> On Feb 9, 2015, at 9:23 PM, Dr. Stephen Henson <steve at openssl.org> wrote:
> 
>> On Mon, Feb 09, 2015, Sec_Aficionado wrote:
>> 
>> Hello,
>> 
>> I am trying to encrypt a short message using AES-256-GCM as mentioned in the subject.
>> 
>> My command is:
>> openssl enc -aes-256-gcm -p -in payload.txt -out enc.txt
>> 
>> I get prompted for password as expected.
>> 
>> The encryption goes well, and then I proceed to decrypt using:
>> openssl enc -d -aes-256-gcm -p -in enc.txt -out dec.txt
>> 
>> The program executes but I get a "bad decrypt" message. However, when I open dec.txt, it is the same as the original file payload.txt
>> 
>> My guess is that the problem is in the padding, but I have not been able to eliminate the error message, even setting the -nopad option and padding manually.
>> 
>> Can someone please explain to me why this might be happening?
>> 
>> I am running openSSL 1.0.1f (6 Jan 14) on an Ubuntu 14.04 LTS VM with current patches.
> 
> AES GCM is not supported by the 'enc' utility. More recent versions of OpenSSL
> throw out and error message if you try to use it from the command line.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From matt at openssl.org  Tue Feb 10 14:21:16 2015
From: matt at openssl.org (Matt Caswell)
Date: Tue, 10 Feb 2015 14:21:16 +0000
Subject: [openssl-users] AES-GCM failing from Command Line Interface
In-Reply-To: <FCF226D1-49CA-41B4-8703-F0C3F68E335A@gmail.com>
References: <F6BC0BA9-2194-4772-9DA5-1DFB348D7F6F@gmail.com>
 <20150210022330.GA15638@openssl.org>
 <FCF226D1-49CA-41B4-8703-F0C3F68E335A@gmail.com>
Message-ID: <54DA13DC.8050305@openssl.org>



On 10/02/15 14:09, Sec_Aficionado wrote:
> Ah, thank you! I tried a lot of things and was very frustrated. I wish the documentation reflected that. I'll see if I can contribute by updating it.

It does:

https://www.openssl.org/docs/apps/enc.html
"The enc program does not support authenticated encryption modes like
CCM and GCM. The utility does not store or retrieve the authentication tag."

> 
> Regarding AES-GCM from the command line, or PHP bindings, is that something that any of the OpenSSL components support? I think EVP is the intended way but there are no PHP bindings, only C from what I can tell.

No - you can't do AES-GCM from the command line (things like s_server
and s_client support it - but that doesn't help you for what you want to
do). We don't supply the PHP bindings - you'll have to talk to the PHP
guys about that.

Matt

From sanchit1.arora at gmail.com  Tue Feb 10 14:50:06 2015
From: sanchit1.arora at gmail.com (sanchit arora)
Date: Tue, 10 Feb 2015 09:50:06 -0500
Subject: [openssl-users] DTLS Handshake issue
 (openssl-1.0.1e-dtls-ecc-ext.patch) leads to process crash
In-Reply-To: <54D93DC6.90300@openssl.org>
References: <CAGgXGhJWRapuKc3bzBxyC2-DckGLTKnxQXHwnoyfFJ9jd-QkQw@mail.gmail.com>
 <54D93DC6.90300@openssl.org>
Message-ID: <CAGgXGhK=aJ1tihc7Rpz2JFYNjzdaH=+xtyqbmaobxwYaYMVZkA@mail.gmail.com>

Which distro?
>>>>>>>>>>>>>>

OS is Red Hat Enterprise Linux Server release 6.5
OpenSSL Version :1.0.1e


All of the above are vendor specific patches (probably based on original
OpenSSL commits). However I don't know from the name what dtls-ecc-ext
is referring to. You would need to address your specific question to
your vendor.
>>>>>>>

The patch openssl-1.0.1e-dtls-ecc-ext.patch with changes is decribed below:

https://bugzilla.redhat.com/show_bug.cgi?id=1119800

Could it be that the changes in the above patch are causing issues in
DTLS Handshake causing the process to crash always at the below
location:

#4  <signal handler called>
#5  0x00007f61e97188e9 in sha1_block_data_order_ssse3 () from
/usr/lib64/libcrypto.so.10
#6  0xad89a0d6776026f6 in ?? ()
#7  0xf9e71fd74025dad7 in ?? ()
#8  0x2243d5d8167d7997 in ?? ()
#9  0x8bbb75d9b4efd5d8 in ?? ()
#10 0xea9689da4d4ac2cb in ?? ()
#11 0x7067bc5f5034983b in ?? ()
#12 0xe19f5aa4a5679ed0 in ?? ()
#13 0x8ecbf7e83d1d8ccd in ?? ()
#14 0x00007f61e9a827ce in state () from /usr/lib64/libcrypto.so.10
#15 0x00000000bc803cd0 in ?? ()
#16 0x0000000000000011 in ?? ()
#17 0x00007f61e9715de7 in SHA1_Update () from /usr/lib64/libcrypto.so.10
#18 0x00007f61e97899fd in ssleay_rand_add () from /usr/lib64/libcrypto.so.10
#19 0x00007f61e9ed92f9 in dtls1_accept () from /usr/lib64/libssl.so.10

Is it possible that you can run the latest 1.0.1 version of standard
OpenSSL (i.e. OpenSSL 1.0.1l)? There have been some significant DTLS
related fixes that have been applied in recent versions.
>>>>>>>>>

it would not be possible as other modules are also using 1.0.1e version.

Thanks,
Sanchit Arora

On Mon, Feb 9, 2015 at 6:07 PM, Matt Caswell <matt at openssl.org> wrote:
>
>
> On 09/02/15 20:17, sanchit arora wrote:
>> Bug report
>>
>> OS: Linux
>
> Which distro?
>
>>
>> OpenSSL Version: 1.0.1e-30
>
> That is not an OpenSSL version - that is an OS vendor specific version
> based on OpenSSL 1.0.1e
>
>> While doing DTLS testing with openssl-1.0.1e-30 Version and patches
>> for RT3327, RT3470 and RT3483 on top of that, we are facing an issue
>> where our process is crashing during the duration run of 24 hours.
>>
>> Use Case:
>> *        There are 125 DTLS Server Connections and 125 DTLS Client Connections.
>> *        Connection Attempts towards Server connections are also being
>> made every 1 second.
>> *        Client Connections are initiating connection attempts every 1 second .
>> *        SSL Handshake is made to fail so that connection attempts
>> continues and there are no crashes observed.
>>
>> During the above duration run, process is always crashing at the below
>> location always.
>>
>> #4  <signal handler called>
>> #5  0x00007f61e97188e9 in sha1_block_data_order_ssse3 () from
>> /usr/lib64/libcrypto.so.10
>> #6  0xad89a0d6776026f6 in ?? ()
>> #7  0xf9e71fd74025dad7 in ?? ()
>> #8  0x2243d5d8167d7997 in ?? ()
>> #9  0x8bbb75d9b4efd5d8 in ?? ()
>> #10 0xea9689da4d4ac2cb in ?? ()
>> #11 0x7067bc5f5034983b in ?? ()
>> #12 0xe19f5aa4a5679ed0 in ?? ()
>> #13 0x8ecbf7e83d1d8ccd in ?? ()
>> #14 0x00007f61e9a827ce in state () from /usr/lib64/libcrypto.so.10
>> #15 0x00000000bc803cd0 in ?? ()
>> #16 0x0000000000000011 in ?? ()
>> #17 0x00007f61e9715de7 in SHA1_Update () from /usr/lib64/libcrypto.so.10
>> #18 0x00007f61e97899fd in ssleay_rand_add () from /usr/lib64/libcrypto.so.10
>> #19 0x00007f61e9ed92f9 in dtls1_accept () from /usr/lib64/libssl.so.10
>
> There is insufficient information in the above to diagnose the problem.
> We would need a build with full debugging symbols.
>
>
>>
>> When we tested with openssl-1.0.1e-16 Version and patches for RT3327,
>> RT3470 and RT3483 on top of that, the use case works fine.
>>
>> On investigation, we found that there are 11 patches added between
>> openssl-1.0.1e-30 and openssl-1.0.1e-16 version out of which following
>> 3 patches are related to DTLS.
>>
>> openssl-1.0.1e-dtls-ecc-ext.
>> patch
>> openssl-1.0.1e-cve-2014-3513.
>> patch
>> openssl-1.0.1e-fallback-scsv.patch
>>
>> We have narrowed down that when we use openssl-1.0.1e-30 Version with
>> the openssl-1.0.1e-dtls-ecc-ext.patch and patches for RT3327, RT3470
>> and RT3483 on top of that, process crashes with the above abterm
>> during the duration run of 24 hours.
>>
>> When we excluded the openssl-1.0.1e-dtls-ecc-ext.patch from
>> openssl-1.0.1e-30 Version, we didn't see an abterm during the duration
>> run of 24  hours.
>>
>> Therefore, it seems that the openssl-1.0.1e-dtls-ecc-ext.patch is
>> causing the abterm in the duration run.
>>
>> Please let us know if there could be issues with the
>> openssl-1.0.1e-dtls-ecc-ext.patch?
>
> All of the above are vendor specific patches (probably based on original
> OpenSSL commits). However I don't know from the name what dtls-ecc-ext
> is referring to. You would need to address your specific question to
> your vendor.
>
> Is it possible that you can run the latest 1.0.1 version of standard
> OpenSSL (i.e. OpenSSL 1.0.1l)? There have been some significant DTLS
> related fixes that have been applied in recent versions.
>
> Matt
>
>
>
>
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From secaficionado at gmail.com  Tue Feb 10 15:31:10 2015
From: secaficionado at gmail.com (Sec_Aficionado)
Date: Tue, 10 Feb 2015 10:31:10 -0500
Subject: [openssl-users] AES-GCM failing from Command Line Interface
In-Reply-To: <54DA13DC.8050305@openssl.org>
References: <F6BC0BA9-2194-4772-9DA5-1DFB348D7F6F@gmail.com>
 <20150210022330.GA15638@openssl.org>
 <FCF226D1-49CA-41B4-8703-F0C3F68E335A@gmail.com>
 <54DA13DC.8050305@openssl.org>
Message-ID: <F4A26374-8F40-4E9A-A71F-5ED18F2E3E97@gmail.com>

Matt,

Thanks for keeping me honest! I see it now, but I totally missed it before. I must have just played with the cli and not read the full page.

Can you please confirm that EVP is the way to go? I'll create my own little PHP extension since I only need a very specific action.

Thanks for your help!

Sent from my mobile
Please forgive any "autocorrections" I may have missed

> On Feb 10, 2015, at 9:21 AM, Matt Caswell <matt at openssl.org> wrote:
> 
> 
> 
>> On 10/02/15 14:09, Sec_Aficionado wrote:
>> Ah, thank you! I tried a lot of things and was very frustrated. I wish the documentation reflected that. I'll see if I can contribute by updating it.
> 
> It does:
> 
> https://www.openssl.org/docs/apps/enc.html
> "The enc program does not support authenticated encryption modes like
> CCM and GCM. The utility does not store or retrieve the authentication tag."
> 
>> 
>> Regarding AES-GCM from the command line, or PHP bindings, is that something that any of the OpenSSL components support? I think EVP is the intended way but there are no PHP bindings, only C from what I can tell.
> 
> No - you can't do AES-GCM from the command line (things like s_server
> and s_client support it - but that doesn't help you for what you want to
> do). We don't supply the PHP bindings - you'll have to talk to the PHP
> guys about that.
> 
> Matt
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From matt at openssl.org  Tue Feb 10 15:43:26 2015
From: matt at openssl.org (Matt Caswell)
Date: Tue, 10 Feb 2015 15:43:26 +0000
Subject: [openssl-users] AES-GCM failing from Command Line Interface
In-Reply-To: <F4A26374-8F40-4E9A-A71F-5ED18F2E3E97@gmail.com>
References: <F6BC0BA9-2194-4772-9DA5-1DFB348D7F6F@gmail.com>
 <20150210022330.GA15638@openssl.org>
 <FCF226D1-49CA-41B4-8703-F0C3F68E335A@gmail.com>
 <54DA13DC.8050305@openssl.org>
 <F4A26374-8F40-4E9A-A71F-5ED18F2E3E97@gmail.com>
Message-ID: <54DA271E.9010608@openssl.org>



On 10/02/15 15:31, Sec_Aficionado wrote:
> Matt,
> 
> Thanks for keeping me honest! I see it now, but I totally missed it before. I must have just played with the cli and not read the full page.
> 
> Can you please confirm that EVP is the way to go? I'll create my own little PHP extension since I only need a very specific action.

Yes. EVP is the correct way to use GCM.

See:

http://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption

and

https://www.openssl.org/docs/crypto/EVP_EncryptInit.html#gcm_and_ocb_modes

Note the docs on the website are for 1.1.0 (unreleased) and are subtly
different to 1.0.2/1.0.1. In particular they use the newly introduced
AEAD flags instead of mode specific ones. So where the docs talk about:
EVP_CTRL_AEAD_SET_IVLEN
EVP_CTRL_AEAD_GET_TAG
EVP_CTRL_AEAD_SET_TAG

You should instead use the GCM specific versions:
EVP_CTRL_GCM_SET_IVLEN
EVP_CTRL_GCM_GET_TAG
EVP_CTRL_GCM_SET_TAG

These will still work when 1.1.0 is released.

Matt

From rsalz at akamai.com  Tue Feb 10 21:15:36 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 10 Feb 2015 21:15:36 +0000
Subject: [openssl-users] Proposed cipher changes for post-1.0.2
Message-ID: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>

I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2

Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW

Anything that was 40-bit encryption is removed:
/* Cipher 03 "EXP-RC4-MD5" removed */
/* Cipher 06 "EXP-RC2-CBC-MD5" removed */
/* Cipher 08 "EXP-DES-CBC-SHA" removed */
/* Cipher 0B "EXP-DH-DSS-DES-CBC-SHA" removed */
/* Cipher 0E "EXP-DH-RSA-DES-CBC-SHA" removed */
/* Cipher 11 "EXP-DHE-DSS-DES-CBC-SHA" removed */
/* Cipher 14 "EXP-DHE-RSA-DES-CBC-SHA" removed */
/* Cipher 17 "EXP-ADH-RC4-MD5" removed */
/* Cipher 19 "EXP-ADH-DES-CBC-SHA" removed */
/* Cipher 26 "EXP-KRB5-DES-CBC-SHA" removed */
/* Cipher 27 "EXP-KRB5-RC2-CBC-SHA" removed */
/* Cipher 28 "EXP-KRB5-RC4-SHA" removed */
/* Cipher 29 "EXP-KRB5-DES-CBC-MD5" removed */
/* Cipher 2A "EXP-KRB5-RC2-CBC-MD5" removed */
/* Cipher 2B "EXP-KRB5-RC4-MD5" removed */

The value of DEFAULT changes to this:
                ALL:!LOW:!EXPORT:!aNULL:!eNULL

The combination of the first and last changes means that anyone who wants or needs to use, say RC4 must explicitly say so.

Comments?

--
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me<mailto:rsalz at jabber.me> Twitter: RichSalz

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

From thomas.francis.jr at pobox.com  Tue Feb 10 21:16:59 2015
From: thomas.francis.jr at pobox.com (Tom Francis)
Date: Tue, 10 Feb 2015 16:16:59 -0500
Subject: [openssl-users] The evolution of the 'master' branch
In-Reply-To: <54D4E5D3.6090808@wisemo.com>
References: <20150203220231.GA12587@openssl.org> <54D23F42.3060203@wisemo.com>
 <453ad2042e6c43e5897f1689e230883f@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <54D4E5D3.6090808@wisemo.com>
Message-ID: <37FA559B-F877-42C5-9166-12DE5B320FC7@pobox.com>

I think Jakob?s real concern (as expressed to me off-list a month or so ago) is that OpenSSL?s libcrypto will become entirely hidden.  I found several of his comments confusing until he mentioned that.  So, I think the fair question to be asking is:

Is there any plan to make libcrypto go completely opaque, such that _only_ the APIs exposed in libssl will be available?

Thanks!

TOM

> On Feb 6, 2015, at 11:03 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> 
> On 05/02/2015 00:42, Salz, Rich wrote:
>>> Not much on that page so far, not even a "kill list" of
>>> intended victims except an admission that EAY's popular DES
>>> library can no longer be accessed via the copy in OpenSSL.
>>> 
>> Yup.  Pretty empty.  Over the coming year there will be more.
>> 
>>> I fear that this is an indication that you will be killing
>>> off all the other non-EVP entrypoints in libcrypto
>>> 
>> Yes there is a good chance of that happening.
>> 
>>> , making
>>> it much harder to use the library with experimental or
>>> non-standard algorithms and methods.
>>> 
>> Well, not really much harder.  I think that what DOES get harder is binary distributions of such things, as opposed to custom OpenSSL builds that have these new features.  Don't forget, *you have the source*  Hack away.  Do what you want.  And having a standard API that any of your consumers use will benefit your consumers greatly.  And by making things like the EVP structure hidden from your consumers, then you can add a new experimental crypto mechanism and -- this is an important major benefit:  THEIR CODE DOES NOT HAVE TO RECOMPILE.   As an implementor, your work is a bit harder.  For your users, it is much easier.  Imagine being able to put an OID in a config file and applications can almost transparently use any crypto available without change.  (Emphasis on ALMOST :)  To us, this is clearly the right trade-off to make.
>> 
> You seem to misunderstand the scenario:
> 
> My scenario is:
> 
> 1. Load an unchanged shared libcrypto.so.1.1 provided by an
>   OS distribution.
> 
> 2. Implement / use / experiment with non-standard methods
>   (such as new modes of operation or new zero-knowledge
>   proofs) by calling the functions that are exported by
>   libcrypto out of the box.  The higher level libssl is
>   not used for anything.
> 
> Your scenario is:
> 
> 1. Extend the higher level stuff (TLS1.2, CMS etc.) with non-
>   standard methods (such as new modes of operation or new
>   signature forms).
> 
> 2. Inject this new functionality into existing applications
>   that use OpenSSL in generic ways, such as wget and WebKit
>   browsers.
> 
> My scenario got great advantages from the large number of
> fundamental interfaces exported from libcrypto.so.1.0 and
> will automatically benefit when a new patch release of
> OpenSSL is installed on the system (e.g. to fix a timing
> attack on one of the algorithm implementations).  Having
> to create a custom libnotquitecrypto.so.1.1 would not do
> this, and distributing such a library as source patches
> became much harder when you reformatted the source.
> 
> Looking at the reverse dependencies in Debian, the
> following projects probably use low level libcrypto
> interfaces to do interesting things: afflib, asterisk,
> bind, clamav, crda (WiFi), crtmpserver, encfs, ewf-tools,
> faifa (Ethernet over Power), gfsd, gnugk, gnupg-pkcs11-scd,
> hfsprogs, hostapd (WiFi), ipppd, KAME IPSEC, OpenBSD IPSEC,
> ldnsutils, apache mod-auth-cas, apache mod-auth-openid,
> perl's Crypt::OpenSSL::Bignum, libh323, liblasso, barada,
> StrongSWAN, unbound, libxmlsec, libzrtpcpp, nsd, opensc,
> openssh, rdd, rdesktop, rsyncrypto, samdump, tor,
> tpm-tools, trousers, wpasupplicant (WiFi), yate, zfs-fuse.
> *This is only a rough list based on features claimed by
> OpenSSL-depending packages*
> 
>>>  
>>> Should everyone not doing just TLS1.2 move to a different library now, such as crypto++ ?
>>> 
>> Use whatever works best for you, and your consumers/customers.
>> 
>> Not everyone will agree with this direction. Some people will be inconvenienced and maybe even completely drop using OpenSSL. We discussed this pretty thoroughly, and while we respect that some may disagree, please give us credit for not doing this arbitrarily, or on a whim.	
>> 
> I believe you have made the mistake of discussing only amongst
> yourselves, thus gradually convincing each other of the
> righteousness of a flawed decision.
> 
>  
> 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 openssl-users at dukhovni.org  Tue Feb 10 21:46:46 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 10 Feb 2015 21:46:46 +0000
Subject: [openssl-users] [openssl-dev] Proposed cipher changes for
	post-1.0.2
In-Reply-To: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150210214646.GB12867@mournblade.imrryr.org>

On Tue, Feb 10, 2015 at 09:15:36PM +0000, Salz, Rich wrote:

> I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2
> 
> Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW

Note, that RC4 is already the only commonly used cipher-suite in MEDIUM.

Changing the definitions of EXPOR, LOW, MEDIUM introduces significant
compatibility issues for opportunistic TLS (e.g. Postfix) where
RC4 is still required for interop and is better than cleartext.

I have no issues with changing "DEFAULT", but would strongly prefer
to not see RC4 demoted to LOW.  Just define:

    DEFAULT = ALL:!aNULL:!EXPORT:!LOW:!RC4:!MD5

Which leaves from MEDIUM just SEED and IDEA:

    $ openssl ciphers -v 'MEDIUM:!aNULL:!MD5:!RC4'
    DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
    DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
    DH-RSA-SEED-SHA         SSLv3 Kx=DH/RSA   Au=DH   Enc=SEED(128) Mac=SHA1
    DH-DSS-SEED-SHA         SSLv3 Kx=DH/DSS   Au=DH   Enc=SEED(128) Mac=SHA1
    SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
    IDEA-CBC-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=SHA1

--
	Viktor.

From rsalz at akamai.com  Tue Feb 10 22:00:35 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 10 Feb 2015 22:00:35 +0000
Subject: [openssl-users] The evolution of the 'master' branch
In-Reply-To: <37FA559B-F877-42C5-9166-12DE5B320FC7@pobox.com>
References: <20150203220231.GA12587@openssl.org> <54D23F42.3060203@wisemo.com>
 <453ad2042e6c43e5897f1689e230883f@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <54D4E5D3.6090808@wisemo.com>
 <37FA559B-F877-42C5-9166-12DE5B320FC7@pobox.com>
Message-ID: <eef4447ccc9449f19302cb1957b5350c@ustx2ex-dag1mb2.msg.corp.akamai.com>

> Is there any plan to make libcrypto go completely opaque, such that _only_
> the APIs exposed in libssl will be available?

Absolutely not.

Thanks for asking!

From matt at openssl.org  Tue Feb 10 22:48:36 2015
From: matt at openssl.org (Matt Caswell)
Date: Tue, 10 Feb 2015 22:48:36 +0000
Subject: [openssl-users] The evolution of the 'master' branch
In-Reply-To: <37FA559B-F877-42C5-9166-12DE5B320FC7@pobox.com>
References: <20150203220231.GA12587@openssl.org> <54D23F42.3060203@wisemo.com>
 <453ad2042e6c43e5897f1689e230883f@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <54D4E5D3.6090808@wisemo.com>
 <37FA559B-F877-42C5-9166-12DE5B320FC7@pobox.com>
Message-ID: <54DA8AC4.6080700@openssl.org>



On 10/02/15 21:16, Tom Francis wrote:
> I think Jakob?s real concern (as expressed to me off-list a month or so ago) is that OpenSSL?s libcrypto will become entirely hidden.  I found several of his comments confusing until he mentioned that.  So, I think the fair question to be asking is:
> 
> Is there any plan to make libcrypto go completely opaque, such that _only_ the APIs exposed in libssl will be available?

No.

There is a plan to make "most structures" opaque, with accessor
functions provided instead if required (in much the same way as we are
doing with libssl). The bn stuff has already had that treatment applied.

There is also a discussion about whether low-level cipher APIs should be
removed in favour of EVP or not. It's a discussion. No decisions or
consensus either way at the moment.

Matt


From rsalz at akamai.com  Wed Feb 11 00:22:44 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Feb 2015 00:22:44 +0000
Subject: [openssl-users] [openssl-dev] Proposed cipher changes for
	post-1.0.2
In-Reply-To: <87bnl1qru5.fsf@alice.fifthhorseman.net>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
Message-ID: <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>


> currently, this is an error:
> 
> 0 dkg at alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER
> bash: !NO-SUCH-CIPHER: event not found
> 0 dkg at alice:~$

Yeah, but that's coming from bash, not openssl :)
; openssl ciphers -v ALL | wc
    111     675    8403
; openssl ciphers -v ALL:!FOOBAR | wc
    111     675    8403

RC4 in LOW has a bit of pushback so far.  My cover for it is that the IETF says "don't use it."  So I think saying "if you want it, say so" is the way to go.

	/r$


From openssl-users at dukhovni.org  Wed Feb 11 01:21:37 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Feb 2015 01:21:37 +0000
Subject: [openssl-users] [openssl-dev] Proposed cipher changes for
	post-1.0.2
In-Reply-To: <87bnl1qru5.fsf@alice.fifthhorseman.net>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
Message-ID: <20150211012137.GH12867@mournblade.imrryr.org>

On Tue, Feb 10, 2015 at 06:17:38PM -0500, Daniel Kahn Gillmor wrote:

> On Tue 2015-02-10 16:15:36 -0500, Salz, Rich wrote:
> > I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2
> >
> > Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW
> 
> yes, please!

There are lots of ways to disable RC4:

    * You can do that in a browser, or any other application
    * The NCONF interface allows one to specify this in suitable
      configuration files.
    * Security levels can be similarly specified, ...
    * TLS 1.3 will not support RC4, ...

However, OpenSSL MUST NOT force this choice on applications or
require them to be explicitly modified to continue to support RC4.
It is NOT the library's job to set this policy.

> when these are "removed", what will that do to a cipherstring that
> specifies them by negation?
> 
> currently, this is an error:
> 
> 0 dkg at alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER
> bash: !NO-SUCH-CIPHER: event not found

PBKAC:

    $ openssl ciphers -v 'RC4:!FOOBARXYZZY'
    ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
    ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
    AECDH-RC4-SHA           SSLv3 Kx=ECDH     Au=None Enc=RC4(128)  Mac=SHA1
    ADH-RC4-MD5             SSLv3 Kx=DH       Au=None Enc=RC4(128)  Mac=MD5
    ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
    ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
    RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
    RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
    RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
    PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1
    EXP-ADH-RC4-MD5         SSLv3 Kx=DH(512)  Au=None Enc=RC4(40)   Mac=MD5  export
    EXP-RC4-MD5             SSLv3 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export
    EXP-RC4-MD5             SSLv2 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export

-- 
	Viktor.

From openssl-users at dukhovni.org  Wed Feb 11 02:00:50 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Feb 2015 02:00:50 +0000
Subject: [openssl-users] [openssl-dev] Proposed cipher changes for
	post-1.0.2
In-Reply-To: <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150211020050.GI12867@mournblade.imrryr.org>

On Wed, Feb 11, 2015 at 12:22:44AM +0000, Salz, Rich wrote:

> RC4 in LOW has a bit of pushback so far.  My cover for it is that
> the IETF says "don't use it."  So I think saying "if you want it,
> say so" is the way to go.

By all means, don't use it, but it is not OpenSSL's choice to make
by breaking the meaning of existing interfaces.

If you put RC4 in LOW, one can no longer exclude LOW ciphers if
one still needs RC4.  Nobody uses single-DES, but enough peers
still use (only) RC4 to make disabling of RC4 a choice best made
by applications.

-- 
	Viktor.

From rsalz at akamai.com  Wed Feb 11 03:30:57 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Feb 2015 03:30:57 +0000
Subject: [openssl-users] [openssl-dev] Proposed cipher changes for
	post-1.0.2
In-Reply-To: <20150211020050.GI12867@mournblade.imrryr.org>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
Message-ID: <a396c0b540bc4af9a23eefdbc451550f@ustx2ex-dag1mb2.msg.corp.akamai.com>


> By all means, don't use it, but it is not OpenSSL's choice to make by breaking
> the meaning of existing interfaces.

Except that we've explicitly stated we're breaking things with this new release.

Those magic cipher keywords are point-in-time statements.  And time has moved on.

From openssl-users at dukhovni.org  Wed Feb 11 03:49:53 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Feb 2015 03:49:53 +0000
Subject: [openssl-users] [openssl-dev] Proposed cipher changes for
 post-1.0.2
In-Reply-To: <a396c0b540bc4af9a23eefdbc451550f@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
 <a396c0b540bc4af9a23eefdbc451550f@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150211034953.GP12867@mournblade.imrryr.org>

On Wed, Feb 11, 2015 at 03:30:57AM +0000, Salz, Rich wrote:

> > By all means, don't use it, but it is not OpenSSL's choice to make by breaking
> > the meaning of existing interfaces.
> 
> Except that we've explicitly stated we're breaking things with this new release.
> 
> Those magic cipher keywords are point-in-time statements.  And time has moved on.

Those categories had and continue to have sensible definitions to
which the proposed changes would do unwarranted violence.

It is OK to drop EXPORT ciphers entirely.  It is OK to drop LOW
ciphers entirely.  Nobody is using either.

The deprecation of RC4 is still aspirational, and reclassifying it
as LOW breaks configurations where it is still needed.

It is largely sufficient to drop RC4 from the "DEFAULT" cipherlist,
leaving applications that make more fine-grained choices to make
their own RC4 decisions.

The DEFAULT cipherlist is a point-in-time definition, but EXPORT,
LOW, MEDIUM and HIGH have more precise expected semantics.

Libraries should only break compatibility when there is no choice.
Here there are many alternatives.  Including the "security level"
features already in the master release, which address the issue
more systematically.  This, plus further work on documenting NCONF,
publishing reasonably complete best-practice sample client and
server programs will do a lot more good than needlessly breaking
non-browser opportunistic TLS applications.

-- 
	Viktor.

From openssl-users at dukhovni.org  Wed Feb 11 07:13:46 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Feb 2015 07:13:46 +0000
Subject: [openssl-users] [openssl-dev] Proposed cipher changes for
	post-1.0.2
In-Reply-To: <87twytosbk.fsf@alice.fifthhorseman.net>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87twytosbk.fsf@alice.fifthhorseman.net>
Message-ID: <20150211071345.GT12867@mournblade.imrryr.org>

On Wed, Feb 11, 2015 at 01:50:07AM -0500, Daniel Kahn Gillmor wrote:

> > RC4 in LOW has a bit of pushback so far.  My cover for it is that the
> > IETF says "don't use it."  So I think saying "if you want it, say so" is
> > the way to go.
> 
> I think that's the correct position.  People who want to be able to
> negotiate a deprecated cipher should need to explicitly state that
> that's their intent.

I do:

	aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH

The proposal to now misclassify RC4 as LOW (lumped in with single
DES and similar) needlessly breaks this.

--
	Viktor.

From joerg.eyring at topix.de  Wed Feb 11 08:44:21 2015
From: joerg.eyring at topix.de (=?iso-8859-1?Q?J=F6rg_Eyring?=)
Date: Wed, 11 Feb 2015 09:44:21 +0100
Subject: [openssl-users] OpenSSL 1.0.1l: X509_NAME_add_entry_by_txt broken?
Message-ID: <2F7A0129-3291-4E1B-895B-5705E92A5C02@topix.de>

Hi all,

I'm generating a certificate request and the necessary entries are added with:

...
if(!X509_NAME_add_entry_by_txt(subj,"C", MBSTRING_ASC, (unsigned char *) CountryName,-1,-1,0))
...
if(!X509_NAME_add_entry_by_txt(subj,"O", MBSTRING_ASC, (unsigned char *) OrganizationName,-1,-1,0))
...
if(!X509_NAME_add_entry_by_txt(subj,"OU", MBSTRING_ASC, (unsigned char *) OrganizationUnit,-1,-1,0))
...

X509_NAME_add_entry_by_txt does only respect the given encoding MBSTRING_ASC for the first entry, the subsequent entries are encoded with MBSTRING_UTF8 (seen with a BER Viewer). The certificate request is declined by the authority with an error: "...doesn't contain five PRINTABLESTRING elements..."

The most recent version of OpenSSL we've been using was 1.0.1c where everything worked fine.

Any ideas what's going wrong?

Thanks, J?rg




From joerg.eyring at topix.de  Wed Feb 11 09:09:04 2015
From: joerg.eyring at topix.de (=?iso-8859-1?Q?J=F6rg_Eyring?=)
Date: Wed, 11 Feb 2015 10:09:04 +0100
Subject: [openssl-users] OpenSSL 1.0.1l: X509_NAME_add_entry_by_txt
	broken?
In-Reply-To: <2F7A0129-3291-4E1B-895B-5705E92A5C02@topix.de>
References: <2F7A0129-3291-4E1B-895B-5705E92A5C02@topix.de>
Message-ID: <9C42C70C-DBD9-44CD-B674-B37CC4BAA9A3@topix.de>

Sorry, if my post shows up several times - I had some problems with my mail client ;-)

It was meant to posted only once...

J?rg

From Michael.Wojcik at microfocus.com  Wed Feb 11 15:07:11 2015
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 11 Feb 2015 15:07:11 +0000
Subject: [openssl-users] [openssl-dev] Proposed cipher changes
	for	post-1.0.2
In-Reply-To: <20150211020050.GI12867@mournblade.imrryr.org>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801344A7F17@Rock-Exchange1.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Viktor Dukhovni
> Sent: Tuesday, February 10, 2015 21:01
> To: openssl-dev at openssl.org; openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Proposed cipher changes for
> post-1.0.2
> 
> On Wed, Feb 11, 2015 at 12:22:44AM +0000, Salz, Rich wrote:
> 
> > RC4 in LOW has a bit of pushback so far.  My cover for it is that
> > the IETF says "don't use it."  So I think saying "if you want it,
> > say so" is the way to go.
> 
> By all means, don't use it, but it is not OpenSSL's choice to make
> by breaking the meaning of existing interfaces.
> 
> If you put RC4 in LOW, one can no longer exclude LOW ciphers if
> one still needs RC4.  Nobody uses single-DES, but enough peers
> still use (only) RC4 to make disabling of RC4 a choice best made
> by applications.

I agree with Viktor. His suggestion (keep RC4 in MEDIUM, suppress it explicilty in DEFAULT) is a good one that maintains important backward compatibility while providing the desired removal of RC4 by default. There's no advantage to moving RC4 to LOW.

-- 
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com

From rsalz at akamai.com  Wed Feb 11 15:46:54 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Feb 2015 15:46:54 +0000
Subject: [openssl-users] [openssl-dev] Proposed cipher
	changes	for	post-1.0.2
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801344A7F17@Rock-Exchange1.microfocus.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
 <B550B44BF8AF314BB00C4E2AC1C1808801344A7F17@Rock-Exchange1.microfocus.com>
Message-ID: <240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com>

> I agree with Viktor. His suggestion (keep RC4 in MEDIUM, suppress it
> explicilty in DEFAULT) is a good one that maintains important backward
> compatibility while providing the desired removal of RC4 by default. There's
> no advantage to moving RC4 to LOW.

Sure there is:  it's an accurate description of the quality of protection provided by the algorithm. :)

It's also compatible with our documentation, which as was pointed out, always uses the word "currently" to describe the magic keywords.

And it's also planned for the next version which won't be available until near the end of the year.

And it's also compliant with the expected publication of the IETF RFC's that talk about TLS configuration and attacks.

Postfix can work lay the groundwork to be future-compliant by changing its default configuration to be HIGH:MEDIUM:RC4.


From Michael.Wojcik at microfocus.com  Wed Feb 11 18:16:06 2015
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 11 Feb 2015 18:16:06 +0000
Subject: [openssl-users] [openssl-dev] Proposed
	cipher	changes	for	post-1.0.2
In-Reply-To: <240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
 <B550B44BF8AF314BB00C4E2AC1C1808801344A7F17@Rock-Exchange1.microfocus.com>
 <240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801344AA79A@Rock-Exchange1.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Salz, Rich
> Sent: Wednesday, February 11, 2015 10:47
> To: openssl-users at openssl.org; openssl-dev at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Proposed cipher changes for
> post-1.0.2
> 
> > I agree with Viktor. His suggestion (keep RC4 in MEDIUM, suppress it
> > explicilty in DEFAULT) is a good one that maintains important backward
> > compatibility while providing the desired removal of RC4 by default. There's
> > no advantage to moving RC4 to LOW.
> 
> Sure there is:  it's an accurate description of the quality of protection
> provided by the algorithm. :)

Hobgoblin consistency.

> It's also compatible with our documentation, which as was pointed out,
> always uses the word "currently" to describe the magic keywords.

Hobgoblins everywhere. And by that argument, any action is equally "compatible" with the documentation.

> And it's also planned for the next version which won't be available until near
> the end of the year.

I'm not sure why that's relevant.

> And it's also compliant with the expected publication of the IETF RFC's that
> talk about TLS configuration and attacks.

Frankly, that's rubbish. OpenSSL cipher lists are not "compliant" with RFCs because RFCs don't specify OpenSSL cipher lists. It's an entirely specious justification. And even if it weren't, explicitly disabling RC4 in the DEFAULT list would "comply" with the RFC.

> Postfix can work lay the groundwork to be future-compliant by changing its
> default configuration to be HIGH:MEDIUM:RC4.

All sorts of things can be done. Clearly, in the Brave New World of well-funded OpenSSL, they'll have to be, because it's apparent that we're going to see a lot of disruptive change made on the flimsiest of pretexts, with objections from the user community brushed aside. That's your prerogative, of course, and anyone's free to fork OpenSSL. But it's a shame.

-- 
Michael Wojcik
Technology Specialist, Micro Focus

 


This message has been scanned for malware by Websense. www.websense.com

From rsalz at akamai.com  Wed Feb 11 18:25:44 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Feb 2015 18:25:44 +0000
Subject: [openssl-users] [openssl-dev]
	Proposed	cipher	changes	for	post-1.0.2
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801344AA79A@Rock-Exchange1.microfocus.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
 <B550B44BF8AF314BB00C4E2AC1C1808801344A7F17@Rock-Exchange1.microfocus.com>
 <240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801344AA79A@Rock-Exchange1.microfocus.com>
Message-ID: <ec5f3bbfde334d398d36461ae44f4cf8@ustx2ex-dag1mb2.msg.corp.akamai.com>

> All sorts of things can be done. Clearly, in the Brave New World of well-
> funded OpenSSL, they'll have to be, because it's apparent that we're going to
> see a lot of disruptive change made on the flimsiest of pretexts, with
> objections from the user community brushed aside. That's your prerogative,
> of course, and anyone's free to fork OpenSSL. But it's a shame.

I am surprised by the strength of your reaction.  Hmm.


From jb-openssl at wisemo.com  Wed Feb 11 19:06:52 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 11 Feb 2015 20:06:52 +0100
Subject: [openssl-users] [openssl-dev] Proposed cipher
	changes	for	post-1.0.2
In-Reply-To: <240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
 <B550B44BF8AF314BB00C4E2AC1C1808801344A7F17@Rock-Exchange1.microfocus.com>
 <240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <54DBA84C.8000001@wisemo.com>

On 11/02/2015 16:46, Salz, Rich wrote:
>> I agree with Viktor. His suggestion (keep RC4 in MEDIUM, suppress it
>> explicilty in DEFAULT) is a good one that maintains important backward
>> compatibility while providing the desired removal of RC4 by default. There's
>> no advantage to moving RC4 to LOW.
> Sure there is:  it's an accurate description of the quality of protection provided by the algorithm. :)
Is the security level (i.e. log2 of the cost of the best
known direct attack) 40 bits (historical EXPORT label), 56
bits (historical LOW label), 112 to 127 bits (historical
MEDIUM) level, or somewhere in between?

This is the real question that should guide its
classification, not if it is "lower than what is currently
recommended".

Given the currenly available ciphers, it may make sense to
add new groups: HIGH192, HIGH256 and larger ones still. As
time progresses, the default can then move from HIGH to
HIGH192, to HIGH256 as the state of the art changes,
without redefining semantics.

Furthermore, the various attacks on SSL3/TLS1.0 padding and
IV logic creates an ongoing need to have a widely supported,
TLS1.0 compatible stream-or-otherwise-unpadded cipher choice
as an emergency fallback as other protections are being
rolled out by all kinds of vendors.

For example RC4 is immune to POODLE as well as a previous
widelypublicized attack, simply because it uses neither the
flawed SSL3padding nor the sometimes problematic TLS1.0 IV
selection.  No other cipher provides this protection when
talking to older peers that cannot or will not upgrade to
the latest-and-greatest TLS standards.

> It's also compatible with our documentation, which as was pointed out, always uses the word "currently" to describe the magic keywords.
>
> And it's also planned for the next version which won't be available until near the end of the year.
>
> And it's also compliant with the expected publication of the IETF RFC's that talk about TLS configuration and attacks.
>
> Postfix can work lay the groundwork to be future-compliant by changing its default configuration to be HIGH:MEDIUM:RC4.


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/20150211/42cc62a3/attachment.html>

From openssl-users at dukhovni.org  Wed Feb 11 19:47:11 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Feb 2015 19:47:11 +0000
Subject: [openssl-users] [openssl-dev] Proposed cipher
	changes	for	post-1.0.2
In-Reply-To: <240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
 <B550B44BF8AF314BB00C4E2AC1C1808801344A7F17@Rock-Exchange1.microfocus.com>
 <240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150211194711.GX12867@mournblade.imrryr.org>

On Wed, Feb 11, 2015 at 03:46:54PM +0000, Salz, Rich wrote:

> > I agree with Viktor. His suggestion (keep RC4 in MEDIUM, suppress it
> > explicitly in DEFAULT) is a good one that maintains important backward
> > compatibility while providing the desired removal of RC4 by default. There's
> > no advantage to moving RC4 to LOW.
> 
> Sure there is:  it's an accurate description of the quality of protection provided by the algorithm. :)

Except that it is not.  There are off-the-shelf key recovery attacks
on 56-bit DES (essentially the only LOW cipher anyone might actually
use, though nobody does anymore).  The known attacks on RC4 are
only effective when a great many plaintexts includes the same
sensitive content at a fixed position in the data stream.  While
this does mean we should stop using RC4 as soon as practical, it
is far from equating the security of RC4 with single-DES.


> It's also compatible with our documentation, which as was pointed
> out, always uses the word "currently" to describe the magic keywords.

Sure, there's some rope there, it does not mean we need to hang
ourselves.  The basic ciphersuite primitives by now have well
understood meanings that should only be changed with great care if
at all.

> Postfix can work lay the groundwork to be future-compliant by changing its default configuration to be HIGH:MEDIUM:RC4.

Except that "RC4" includes export-grade RC4, so that would be wrong.
Also Postfix defines a more usable user-interface of cipher "grades":
	
	smtp_tls_cipher_grade = null | export | low | medium | high

where "export" is EXPORT and up, "low" is "LOW" and up, "medium"
is "MEDIUM" and up, with the underlying definitions also configurable
but most users are encouraged to stay well clear of those:

	tls_null_cipherlist = eNULL:!aNULL
	tls_export_cipherlist = aNULL:-aNULL:ALL:+RC4:@STRENGTH
	tls_low_cipherlist = aNULL:-aNULL:ALL:!EXPORT:+RC4:@STRENGTH
	tls_medium_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH
	tls_high_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH

instead users choose a grade, and may also specify exclusions:

    smtp_tls_exclude_ciphers = RC4, PSK, aDSS, ...

this provides enough flexibility to allow emergency tweaks to be
applied by users to deal with future issues, without requiring
users to be experts in OpenSSL cipherlists.

It is important to remember that all the moving pieces are part of
an ecosystem:

    * The OpenSSL project provides a foundation library to application
      developers (like myself with Postfix) AND to O/S release
      engineering teams that take upstream Postfix and upstream
      OpenSSL and package these into integrated systems.

    * The Postfix developers create a Postfix release with sensible
      backwards-compatible and reasonably future-proof cipherlist
      settings.

    * Postfix is built from source by the O/S release engineering
      team against some OpenSSL library available at the time of
      the build.

    * Users deploy systems with some Postfix version and some
      OpenSSL version.  They expect Postfix to be reasonably
      interoperable and backwards-compatible out of the box.

I am not sympathetic to the view that libraries should set application
policy because application developers are lazy.  I am not lazy,
and take the time to give users carefully chosen cipher settings.

These setting use documented primitives that avoid being too
specific, so that Postfix will take advantage of new ciphers (not
block progress) as these become available, and prioritizes these
appropriately.

If some developers do nothing and just want the library to be magic
security pixie-dust, then they benefit or get hurt by the "DEFAULT"
ciphersuite.  If developers or users do make more fine-grained
choices, those ought not change capriciously.

-- 
	Viktor.

From Michael.Wojcik at microfocus.com  Wed Feb 11 19:58:53 2015
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 11 Feb 2015 19:58:53 +0000
Subject: [openssl-users]
	[openssl-dev]	Proposed	cipher	changes	for	post-1.0.2
In-Reply-To: <ec5f3bbfde334d398d36461ae44f4cf8@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
 <B550B44BF8AF314BB00C4E2AC1C1808801344A7F17@Rock-Exchange1.microfocus.com>
 <240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801344AA79A@Rock-Exchange1.microfocus.com>
 <ec5f3bbfde334d398d36461ae44f4cf8@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C1808801344AA9A2@Rock-Exchange1.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Salz, Rich
> Sent: Wednesday, February 11, 2015 13:26
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Proposed cipher changes for
> post-1.0.2
> 
> > All sorts of things can be done. Clearly, in the Brave New World of well-
> > funded OpenSSL, they'll have to be, because it's apparent that we're going to
> > see a lot of disruptive change made on the flimsiest of pretexts, with
> > objections from the user community brushed aside. That's your prerogative,
> > of course, and anyone's free to fork OpenSSL. But it's a shame.
> 
> I am surprised by the strength of your reaction.  Hmm.

Well, let me try to explain.

There are two related issues here. One is simply that we're seeing a lot of OpenSSL roadmap announcements. That's good in the sense that before the funding boost, progress was of course much slower and communication much less frequent. On the other hand, it's worrying because those changes have consequences for developers working with OpenSSL, and so we need to account for them in our plans. And while those announcements are generally couched as requests for feedback, arguments against them usually don't seem to carry much weight. Things are changing relatively quickly with OpenSSL and that is a destabilizing circumstance in itself.

(The obvious answer would be to delay adopting new OpenSSL releases, and only pick up fixes. Sometimes that's a solution. Sometimes new fix levels change behavior, though; and sometimes, in these post-Heartbleed days, customers demand the latest release for no very good reason. Right now I have a customer insisting we update one product line to OpenSSL 1.0.1m, which obviously is a little difficult.)

The second issue is that any user-visible change in behavior that's not solely a fix to a vulnerability is significant work for us, particularly if it involves code changes. We have to make the necessary updates, test, provide documentation, and ensure customers are aware of the change. It's a substantial effort if the change in OpenSSL requires a corresponding change in our code, but at least in that case the integration process catches it. If it's a runtime behavior change, then we have to make sure all the affected development teams are aware of it, because we can't be sure that everyone has tests that will catch it.

We have multiple teams in the organization using OpenSSL independently. We're working on a plan to bring all our OpenSSL builds under a single group which can be responsible for tracking changes, but that's a long way off yet. We have product lines that use our other products internally to provide SSL/TLS, and those teams don't know what's happening with OpenSSL - they just expect it to work.

(This does raise a rather delicate point: sponsorship. Let's just say that I've suggested it in the past and it hasn't gotten a lot of traction. I keep meaning to donate personally but ... oh, hell, let's just do it now. Done. Coals to Newcastle these days, but every bit helps, I suppose.)

So, for the components I personally work on, this change (RC4 into LOW) isn't a big deal. One product line sets ciphers explicitly, either using its own default list or one configured by the user; another might need a change (haven't checked) to maintain existing behavior, but it's time to review that anyway. It's the 20-odd other product lines that I'm more worried about, because i don't even know what all of them are.

And I don't know how changes like this in OpenSSL behavior affect, say, the SUSE division - how many updated packages they'll have to integrate and test. Maybe it's not a big deal; maybe it's a lot of work. Maybe they welcome this particular change regardless. (I'll have to ask on our next security call.)

Anyway, this has gone on too long already. The basic point is that these changes affect us, the users of OpenSSL, sometimes in quite disruptive ways. And sometimes they leak through to our users, and we have to handle that situation. So yes, some of us will be resistant to changes that we think aren't strongly justified.

-- 
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com

From openssl-users at dukhovni.org  Wed Feb 11 20:21:37 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Feb 2015 20:21:37 +0000
Subject: [openssl-users] [openssl-dev] Proposed cipher changes for
	post-1.0.2
In-Reply-To: <1672004.gQCVnt9D6P@pintsize.usersys.redhat.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210214646.GB12867@mournblade.imrryr.org>
 <1672004.gQCVnt9D6P@pintsize.usersys.redhat.com>
Message-ID: <20150211202137.GY12867@mournblade.imrryr.org>

On Wed, Feb 11, 2015 at 12:59:22PM +0100, Hubert Kario wrote:

> On Tuesday 10 February 2015 21:46:46 Viktor Dukhovni wrote:
> > On Tue, Feb 10, 2015 at 09:15:36PM +0000, Salz, Rich wrote:
> > > I would like to make the following changes in the cipher specs, in the
> > > master branch, which is planned for the next release after 1.0.2
> > > 
> > > Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW
> > 
> > Note, that RC4 is already the only commonly used cipher-suite in MEDIUM.
> > 
> > Changing the definitions of EXPOR, LOW, MEDIUM introduces significant
> > compatibility issues for opportunistic TLS (e.g. Postfix) where
> > RC4 is still required for interop and is better than cleartext.
> 
> Opportunistic TLS is a-typical use of TLS. One that is vulnerable to trivial 
> MitM attacks by the very definition. Using "ALL", possibly "ALL:!aNULL", 
> instead of "DEFAULT" doesn't make it much less secure.

Yeah, right, 70-90% of the world's email using opportunistic TLS
is "atypical".  XMPP server-to-server using opportunistic TLS is
"atypical", sorry the browser use-case is not the sole use of TLS.

As for vulnerable to MiTM, opportunistic TLS is less vulnerable
than cleartext.  (I'll believe that you actually care that
opportunistic TLS is not secure enough when Redhat deploys DNSSEC
and DANE TLSA RRs for its MX hosts).

-- 
	Viktor.

From jb-openssl at wisemo.com  Wed Feb 11 20:58:40 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 11 Feb 2015 21:58:40 +0100
Subject: [openssl-users] Changelog inconsistency between 1.0.1l and 1.0.2
Message-ID: <54DBC280.6070603@wisemo.com>

The changelog (file CHANGES) in the 1.0.2 tarball contains
some confusingdifferences fromthe one in 1.0.1l.

Specifically:

The 1.0.2 changelog seems to indicate that a few bugs that
were fixed in the 1.0.1 branch were not fixed in the 1.0.2
branch (dtls1_get_record segmentation fault,
dtls1_buffer_record memory leak, no-ssl3 NULL issue,
unverified DH client certificates, BN_sqr bug).

The 1.0.2 changelog also contains a spurious copy of an
incomplete draft of the 1.0.1j changes, sandwiched between
1.0.1h and 1.0.1i.

Please clarify if the missing entries are actually fixed
in 1.0.2 anyway.

Also pleaseclean up any differences that are just typos
before the future 1.0.2arelease.

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/20150211/2045622e/attachment-0001.html>

From dthompson at prinpay.com  Thu Feb 12 00:28:09 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Wed, 11 Feb 2015 19:28:09 -0500
Subject: [openssl-users] OpenSSL 1.0.1l: X509_NAME_add_entry_by_txt
	broken?
In-Reply-To: <2F7A0129-3291-4E1B-895B-5705E92A5C02@topix.de>
References: <2F7A0129-3291-4E1B-895B-5705E92A5C02@topix.de>
Message-ID: <003601d0465a$ca77e380$5f67aa80$@prinpay.com>

> From: openssl-users On Behalf Of J?rg Eyring
> Sent: Wednesday, February 11, 2015 03:44

> I'm generating a certificate request and the necessary entries are added
> with:
> ...
> if(!X509_NAME_add_entry_by_txt(subj,"C", MBSTRING_ASC, (unsigned
> char *) CountryName,-1,-1,0)) <snip>
> X509_NAME_add_entry_by_txt does only respect the given encoding
> MBSTRING_ASC for the first entry, the subsequent entries are encoded with
> MBSTRING_UTF8 (seen with a BER Viewer). The certificate request is
> declined by the authority with an error: "...doesn't contain five
> PRINTABLESTRING elements..."
> 
> The most recent version of OpenSSL we've been using was 1.0.1c where
> everything worked fine.
> 
ASN1 strings set with the "generic" MBSTRING_ types that are for 
known/standard OID-value pairs are constrained by tbl_standard in 
asn1/a_strnid.c. A few like Country are forced to Printable as per standard.

Those standardized as DirectoryString are anded with a "default mask" then 
a_mbstr.c chooses the "lowest" type supporting the characters in the value.
Which allowed *two* of the eight single-byte types (Teletex and Printable).
This is mentioned, very briefly, in the manpage for X509_NAME_add_entry.

1.0.1h in 2014 and later changed this mask to force UTF8 only, I believe 
to implement the MUST UTF8 for DirectoryString's in 2459 and 3280, 
even though 5280 in 2008 had relaxed it to MUST UTF8 OR Printable, 
I suspect to be safe for implementations of the older standard.

req and ca override this by calling ASN1_STRING_set_default_mask_asc  
with the (string) value of string_mask in the configuration if specified,
and 
the supplied openssl.cnf back to 1.0.0 in 2009 set utf8only for those utils.
There is also a numeric version ASN1_STRING_set_default_mask .

HTH.



From raji.kotamraju at gmail.com  Thu Feb 12 05:39:32 2015
From: raji.kotamraju at gmail.com (Rajeswari K)
Date: Thu, 12 Feb 2015 11:09:32 +0530
Subject: [openssl-users] i2d and d2i fucntions
Message-ID: <CA+mfXPGRw3fdUYbDaKo9FSJJ2KBz37xkPttNRvEqeN6hPnCh9Q@mail.gmail.com>

Hello Openssl users,

I have a query on d2i_PUBKEY() and i2d_PUBKEY().

i have a EC public key in form of character buffer.
Have inputted this character buffer to d2i_PUBKEY() and got EVP_PKEY format
EC key.

Now i tried to input this EVP_PKEY to i2d_PUBKEY() to compare will i get
exactly same data which i gave as input to d2i_PUBKEY().

But i see that the outputs are completely different.

i2d_PUBKEY() is leaving lots of 0's at the o/p buffer.

0
0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
FD  1   10  DF  AB  12  34  CD  0   6F  0   0   0   0   1   83
F   8B  AF  D8  D  ................................................

My goal is, to get complete EC public key in form of asn1 der encoded from
EC_KEY structure.

I tried to use i2d_EC_PUBKEY() and i20_ECPublickey(). But both results
seems similar.
0
FD  1   10  DF  AB  12  34  CD  0   6F  0   0   0   0   1   83
F   8B  AF  D8  D   ......................................

Can you please help me with respective API's to call to get complete EC
public key buffer which will have asn1 oid's, formats etc. included in the
public key buffer.

Thanks,
Rajeswari.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150212/47fe638f/attachment.html>

From matt at openssl.org  Thu Feb 12 10:15:53 2015
From: matt at openssl.org (Matt Caswell)
Date: Thu, 12 Feb 2015 10:15:53 +0000
Subject: [openssl-users] Code Reformat blog post
Message-ID: <54DC7D59.9010603@openssl.org>

I have posted a new blog article covering the recent reformat activity:
https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/

It's basically a review of what we did, how we did it and the problems
we encountered. It also discusses the various tags that we've created in
the repo, and outlines how you might go about reformatting patches that
you maintain.

Matt

From joerg.eyring at topix.de  Thu Feb 12 11:16:49 2015
From: joerg.eyring at topix.de (=?iso-8859-1?Q?J=F6rg_Eyring?=)
Date: Thu, 12 Feb 2015 12:16:49 +0100
Subject: [openssl-users] OpenSSL 1.0.1l: X509_NAME_add_entry_by_txt
	broken?
In-Reply-To: <003601d0465a$ca77e380$5f67aa80$@prinpay.com>
References: <2F7A0129-3291-4E1B-895B-5705E92A5C02@topix.de>
 <003601d0465a$ca77e380$5f67aa80$@prinpay.com>
Message-ID: <76DBA776-4B76-493C-BF39-1F524967E05C@topix.de>

Am 12.02.2015 um 01:28 schrieb Dave Thompson <dthompson at prinpay.com>:

> ASN1 strings set with the "generic" MBSTRING_ types that are for 
> known/standard OID-value pairs are constrained by tbl_standard in 
> asn1/a_strnid.c. A few like Country are forced to Printable as per standard.
> 
> Those standardized as DirectoryString are anded with a "default mask" then 
> a_mbstr.c chooses the "lowest" type supporting the characters in the value.
> Which allowed *two* of the eight single-byte types (Teletex and Printable).
> This is mentioned, very briefly, in the manpage for X509_NAME_add_entry.
> 
> 1.0.1h in 2014 and later changed this mask to force UTF8 only, I believe 
> to implement the MUST UTF8 for DirectoryString's in 2459 and 3280, 
> even though 5280 in 2008 had relaxed it to MUST UTF8 OR Printable, 
> I suspect to be safe for implementations of the older standard.
> 
> req and ca override this by calling ASN1_STRING_set_default_mask_asc  
> with the (string) value of string_mask in the configuration if specified,
> and 
> the supplied openssl.cnf back to 1.0.0 in 2009 set utf8only for those utils.
> There is also a numeric version ASN1_STRING_set_default_mask .
> 
> HTH.

Hi Dave,

thanks for your explanation. I wish these changes would have been documented somewhere in the version history of OpenSSL.

unsigned long defaultMask = ASN1_STRING_get_default_mask();
ASN1_STRING_set_default_mask (B_ASN1_PRINTABLESTRING);

...add entries?

ASN1_STRING_set_default_mask (defaultMask);

seems to do the job.

J?rg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150212/439f5758/attachment.html>

From dthompson at prinpay.com  Thu Feb 12 21:06:34 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Thu, 12 Feb 2015 16:06:34 -0500
Subject: [openssl-users] i2d and d2i fucntions
In-Reply-To: <CA+mfXPGRw3fdUYbDaKo9FSJJ2KBz37xkPttNRvEqeN6hPnCh9Q@mail.gmail.com>
References: <CA+mfXPGRw3fdUYbDaKo9FSJJ2KBz37xkPttNRvEqeN6hPnCh9Q@mail.gmail.com>
Message-ID: <001701d04707$ca50f1f0$5ef2d5d0$@prinpay.com>

> From: openssl-users On Behalf Of Rajeswari K
> Sent: Thursday, February 12, 2015 00:40

> I have a query on d2i_PUBKEY() and i2d_PUBKEY().

> i have a EC public key in form of character buffer. 
> Have inputted this character buffer to d2i_PUBKEY() and got EVP_PKEY format EC key. 

To be exact, a byte (or even more exact octet) buffer. In C 
(and C++ and ObjC) it's type 'char[]' or better 'unsigned char[]',
but the values do not and often cannot represent *characters&.

> Now i tried to input this EVP_PKEY to i2d_PUBKEY() to compare will i get 
> exactly same data which i gave as input to d2i_PUBKEY().

> But i see that the outputs are completely different.

> i2d_PUBKEY() is leaving lots of 0's at the o/p buffer. 

> 0
> 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
> 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
> FD  1   10  DF  AB  12  34  CD  0   6F  0   0   0   0   1   83
> F   8B  AF  D8  D  ................................................

You must be doing something wrong. Probably the most common is,
are you looking at the beginning of the buffer? Remember that after 
calling i2d_whatever, the pointer you give it is moved to point 
*after* the encoded data, at unused and often junk memory.

If that's not it, reduce your code to the minimum that shows the 
problem, post it, and identify the version and build you are using.

> My goal is, to get complete EC public key in form of asn1 der 
> encoded from EC_KEY structure.

> I tried to use i2d_EC_PUBKEY() and i20_ECPublickey(). <snip>

Note that PUBKEY is the X.509 SPKI format: it contains an 
AlgorithmIdentifier identifying the algorithm and the curve,
*and* the public key value (a point) embedded in a bitstring,
all combined into an ASN.1 structure and DER encoded.

i2o_ECPublicKey (letter o not zero) uses a special non-ASN1 
non-DER encoding that contains *only* the point. 



From raji.kotamraju at gmail.com  Thu Feb 12 23:18:15 2015
From: raji.kotamraju at gmail.com (Rajeswari K)
Date: Fri, 13 Feb 2015 04:48:15 +0530
Subject: [openssl-users] i2d and d2i fucntions
In-Reply-To: <001701d04707$ca50f1f0$5ef2d5d0$@prinpay.com>
References: <CA+mfXPGRw3fdUYbDaKo9FSJJ2KBz37xkPttNRvEqeN6hPnCh9Q@mail.gmail.com>
 <001701d04707$ca50f1f0$5ef2d5d0$@prinpay.com>
Message-ID: <CA+mfXPH2ZJKGMKk3VQbwmthXwC5zoxgsvgtANBZftMmhA5p0Lw@mail.gmail.com>

Hello Dave,

Am really thankful to you. I am unaware that i2d_EC_PUBKEY() or i2d_xxxxx
function will move the pointer to after the encoded data. Due to which am
seeing unexpected data.

Based on your reply, i tried to print the data from the memory address
which i allocated. Now the data is exactly same as what i inputted through
d2i_PUBKEY().

This resolves my current issue. Once again, thanks alot.

Rajeswari.

On Fri, Feb 13, 2015 at 2:36 AM, Dave Thompson <dthompson at prinpay.com>
wrote:

> > From: openssl-users On Behalf Of Rajeswari K
> > Sent: Thursday, February 12, 2015 00:40
>
> > I have a query on d2i_PUBKEY() and i2d_PUBKEY().
>
> > i have a EC public key in form of character buffer.
> > Have inputted this character buffer to d2i_PUBKEY() and got EVP_PKEY
> format EC key.
>
> To be exact, a byte (or even more exact octet) buffer. In C
> (and C++ and ObjC) it's type 'char[]' or better 'unsigned char[]',
> but the values do not and often cannot represent *characters&.
>
> > Now i tried to input this EVP_PKEY to i2d_PUBKEY() to compare will i get
> > exactly same data which i gave as input to d2i_PUBKEY().
>
> > But i see that the outputs are completely different.
>
> > i2d_PUBKEY() is leaving lots of 0's at the o/p buffer.
>
> > 0
> > 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
> > 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
> > FD  1   10  DF  AB  12  34  CD  0   6F  0   0   0   0   1   83
> > F   8B  AF  D8  D  ................................................
>
> You must be doing something wrong. Probably the most common is,
> are you looking at the beginning of the buffer? Remember that after
> calling i2d_whatever, the pointer you give it is moved to point
> *after* the encoded data, at unused and often junk memory.
>
> If that's not it, reduce your code to the minimum that shows the
> problem, post it, and identify the version and build you are using.
>
> > My goal is, to get complete EC public key in form of asn1 der
> > encoded from EC_KEY structure.
>
> > I tried to use i2d_EC_PUBKEY() and i20_ECPublickey(). <snip>
>
> Note that PUBKEY is the X.509 SPKI format: it contains an
> AlgorithmIdentifier identifying the algorithm and the curve,
> *and* the public key value (a point) embedded in a bitstring,
> all combined into an ASN.1 structure and DER encoded.
>
> i2o_ECPublicKey (letter o not zero) uses a special non-ASN1
> non-DER encoding that contains *only* the point.
>
>
> _______________________________________________
> 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/20150213/9aad3128/attachment-0001.html>

From raji.kotamraju at gmail.com  Fri Feb 13 14:47:40 2015
From: raji.kotamraju at gmail.com (Rajeswari K)
Date: Fri, 13 Feb 2015 20:17:40 +0530
Subject: [openssl-users] i2d and d2i fucntions
In-Reply-To: <CA+mfXPH2ZJKGMKk3VQbwmthXwC5zoxgsvgtANBZftMmhA5p0Lw@mail.gmail.com>
References: <CA+mfXPGRw3fdUYbDaKo9FSJJ2KBz37xkPttNRvEqeN6hPnCh9Q@mail.gmail.com>
 <001701d04707$ca50f1f0$5ef2d5d0$@prinpay.com>
 <CA+mfXPH2ZJKGMKk3VQbwmthXwC5zoxgsvgtANBZftMmhA5p0Lw@mail.gmail.com>
Message-ID: <CA+mfXPFi6DEmOdf=a6eJTGMHe_FJf90DwgH8nLr6+fzY8LVXzQ@mail.gmail.com>

Hello Openssl Team,

Currently am seeing an issue as follows.

We would like to use our internal verification logics for the key exchange
message received at SSL client.

As part of this, we have registered with our function pointers.

ECDSA_verify() is now calling our registered function to perform signature
verification.

As part of signature verification, we first take lenght_of_signature
received and compare with double the size of number_of_bytes from curve
parameter.

Have converted the ECDSA_SIG to unsigned char * using the function
i2d_ECDSA_SIG().

Length returned by i2d_ECDSA_SIG() is 103.

Whereas, the number_of_bytes value from curve parameter is 48.

Our verification failing as (103 != 2*48).

Can you please share do we need to skip any number of bytes from the
sig_buf converted via i2d_ECDSA_SIG()?

Or, am i missing anything in this context?


Thanks,
Rajeswari.

On Fri, Feb 13, 2015 at 4:48 AM, Rajeswari K <raji.kotamraju at gmail.com>
wrote:

> Hello Dave,
>
> Am really thankful to you. I am unaware that i2d_EC_PUBKEY() or i2d_xxxxx
> function will move the pointer to after the encoded data. Due to which am
> seeing unexpected data.
>
> Based on your reply, i tried to print the data from the memory address
> which i allocated. Now the data is exactly same as what i inputted through
> d2i_PUBKEY().
>
> This resolves my current issue. Once again, thanks alot.
>
> Rajeswari.
>
> On Fri, Feb 13, 2015 at 2:36 AM, Dave Thompson <dthompson at prinpay.com>
> wrote:
>
>> > From: openssl-users On Behalf Of Rajeswari K
>> > Sent: Thursday, February 12, 2015 00:40
>>
>> > I have a query on d2i_PUBKEY() and i2d_PUBKEY().
>>
>> > i have a EC public key in form of character buffer.
>> > Have inputted this character buffer to d2i_PUBKEY() and got EVP_PKEY
>> format EC key.
>>
>> To be exact, a byte (or even more exact octet) buffer. In C
>> (and C++ and ObjC) it's type 'char[]' or better 'unsigned char[]',
>> but the values do not and often cannot represent *characters&.
>>
>> > Now i tried to input this EVP_PKEY to i2d_PUBKEY() to compare will i get
>> > exactly same data which i gave as input to d2i_PUBKEY().
>>
>> > But i see that the outputs are completely different.
>>
>> > i2d_PUBKEY() is leaving lots of 0's at the o/p buffer.
>>
>> > 0
>> > 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
>> > 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
>> > FD  1   10  DF  AB  12  34  CD  0   6F  0   0   0   0   1   83
>> > F   8B  AF  D8  D  ................................................
>>
>> You must be doing something wrong. Probably the most common is,
>> are you looking at the beginning of the buffer? Remember that after
>> calling i2d_whatever, the pointer you give it is moved to point
>> *after* the encoded data, at unused and often junk memory.
>>
>> If that's not it, reduce your code to the minimum that shows the
>> problem, post it, and identify the version and build you are using.
>>
>> > My goal is, to get complete EC public key in form of asn1 der
>> > encoded from EC_KEY structure.
>>
>> > I tried to use i2d_EC_PUBKEY() and i20_ECPublickey(). <snip>
>>
>> Note that PUBKEY is the X.509 SPKI format: it contains an
>> AlgorithmIdentifier identifying the algorithm and the curve,
>> *and* the public key value (a point) embedded in a bitstring,
>> all combined into an ASN.1 structure and DER encoded.
>>
>> i2o_ECPublicKey (letter o not zero) uses a special non-ASN1
>> non-DER encoding that contains *only* the point.
>>
>>
>> _______________________________________________
>> 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/20150213/36ed1a40/attachment.html>

From mikec1404 at gmail.com  Fri Feb 13 15:29:41 2015
From: mikec1404 at gmail.com (Mike Collins)
Date: Fri, 13 Feb 2015 09:29:41 -0600
Subject: [openssl-users] 1.0.1 upgrade issue
Message-ID: <CABQOMtZBqUsS68AqfKJDYXFcgk2vxmS8P2XpPJq5vT1CU1f9Sg@mail.gmail.com>

I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l due to a
requirement for TLS v1.1. Version 1.0.1 will cross compile without errors
using my 1.0.0 configuration but I have identified the following errors on
the board (so far) with the build using 1.0.1:
1.) Cannot create a RSA key
2.) Trying to connect to the board's Lighttpd web server via https will
timeout with PKCS #11 error
3.) Curl https POST calls fail with RSA padding error.

Board has a ARM926EJ based processor and I am using a Codesourcery Lite
toolchain. Configure settings (besides --prefix, etc) are shared, no-asm,
linux-generic32, no-ssl2. All the other packages on the board have been
rebuilt against the new openssl version.

I am looking at the key creation first since that may be causing the other
issues. If I try to create a key from the board command line using "openssl
genrsa -out testkey.pem 2048" I get a response of "Generating RSA private
key, 2048 bit long modulus". At this point it seems to get stuck in a loop;
I am seeing the progress indicators (".") but it will never finish creating
the key. I have let it run 10-15 minutes without completion; it just keeps
displaying successive progress indicators. I can do Ctrl-C and it will
exit.

I don't think so but are there any dependency changes from 1.0.0 to 1.0.1?

I noticed 1.0.2 has been released so tried that as well but have the same
result as 1.0.1

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150213/00203f25/attachment.html>

From rsalz at akamai.com  Fri Feb 13 16:14:37 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 13 Feb 2015 16:14:37 +0000
Subject: [openssl-users]
	[openssl-dev]	Proposed	cipher	changes	for	post-1.0.2
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801344AA9A2@Rock-Exchange1.microfocus.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
 <B550B44BF8AF314BB00C4E2AC1C1808801344A7F17@Rock-Exchange1.microfocus.com>
 <240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801344AA79A@Rock-Exchange1.microfocus.com>
 <ec5f3bbfde334d398d36461ae44f4cf8@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <B550B44BF8AF314BB00C4E2AC1C1808801344AA9A2@Rock-Exchange1.microfocus.com>
Message-ID: <9a867e735e8c4148a789854a4c85a1b0@ustx2ex-dag1mb4.msg.corp.akamai.com>

> From: Michael Wojcik [mailto:Michael.Wojcik at microfocus.com]

Thanks for the detailed and thoughtful response.  I only want to respond to a few of your points.

> One is simply that we're seeing a lot of
> OpenSSL roadmap announcements. That's good in the sense that before the
> funding boost, progress was of course much slower and communication
> much less frequent. On the other hand, it's worrying because those changes
> have consequences for developers working with OpenSSL, and so we need
> to account for them in our plans.

It seems to me that now folks are being told what is coming (or planned, or might, or we want to) a pretty long time in advance.  I don't think that's ever happened before. I understand the stress this can cause -- "how will we handle it" -- but at least there's advance notice now, which there never was before.  Also, keep in mind that the big flurry of activity is happening in master, which isn't going to be released until, at best, year-end.  That's a pretty long time. And we are working pretty hard to keep the community informed and engaged. 

> And while those announcements are
> generally couched as requests for feedback, arguments against them usually
> don't seem to carry much weight.

I disagree with this.  On the platform issue, Netware was kept and nodbody else raised an issue.  On the #ifdef issue, Brian Smith raised a concern and Richard reassured him. On the API issue, Jakob is upset; some of that is, supposedly, addressed by overall retaining the crypto API's, and some of it we just disagree. On the cipher strength, the discussion is still ongoing and I haven't seen much support for Viktor's viewpoint.  Have I missed any?

--  
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me Twitter: RichSalz

From jayf0ster at roadrunner.com  Fri Feb 13 16:48:12 2015
From: jayf0ster at roadrunner.com (Jay Foster)
Date: Fri, 13 Feb 2015 08:48:12 -0800
Subject: [openssl-users] 1.0.1 upgrade issue
In-Reply-To: <CABQOMtZBqUsS68AqfKJDYXFcgk2vxmS8P2XpPJq5vT1CU1f9Sg@mail.gmail.com>
References: <CABQOMtZBqUsS68AqfKJDYXFcgk2vxmS8P2XpPJq5vT1CU1f9Sg@mail.gmail.com>
Message-ID: <54DE2ACC.2010807@roadrunner.com>

I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also on 
an ARM926EJ linux based system.  I used the 'no-ssl2 no-ssl3 linux-armv4 
shared' options (plus some others).  I found that it works with and 
without the ARM assembly accelerations (no-asm option), even though the 
ARM926EJ is an arm5te.  It works fine with lighttpd and passes the 
OpenSSL tests.  I assume you are also using the appropriate 
'--cross-compile-prefix=<prefix>' option.   You might try adding 
"-mlittle-endian -mcpu=arm926ej-s -DL_ENDIAN" to the CFLAGS, although 
that should be redundant (the compiler should already know this).  Also, 
make sure there are no '-nostdinc' (or similar) type compiler options 
creeping in.  These change the search order of header files, which can 
cause OpenSSL to be built against the (old) headers in your tool chain, 
rather than it's local (current) headers.

I did discover that with 1.0.2, I also needed to add 
'-DOPENSSL_USE_BUILD_DATE' to the CFLAGS to get the 'openssl version -a' 
command to report a useful build date.

Jay
On 2/13/2015 7:29 AM, Mike Collins wrote:
> I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l due 
> to a requirement for TLS v1.1. Version 1.0.1 will cross compile 
> without errors using my 1.0.0 configuration but I have identified the 
> following errors on the board (so far) with the build using 1.0.1:
> 1.) Cannot create a RSA key
> 2.) Trying to connect to the board's Lighttpd web server via https 
> will timeout with PKCS #11 error
> 3.) Curl https POST calls fail with RSA padding error.
>
> Board has a ARM926EJ based processor and I am using a Codesourcery 
> Lite toolchain. Configure settings (besides --prefix, etc) are shared, 
> no-asm, linux-generic32, no-ssl2. All the other packages on the board 
> have been rebuilt against the new openssl version.
>
> I am looking at the key creation first since that may be causing the 
> other issues. If I try to create a key from the board command line 
> using "openssl genrsa -out testkey.pem 2048" I get a response of 
> "Generating RSA private key, 2048 bit long modulus". At this point it 
> seems to get stuck in a loop; I am seeing the progress indicators 
> (".") but it will never finish creating the key. I have let it run 
> 10-15 minutes without completion; it just keeps displaying successive 
> progress indicators. I can do Ctrl-C and it will exit.
>
> I don't think so but are there any dependency changes from 1.0.0 to 1.0.1?
>
> I noticed 1.0.2 has been released so tried that as well but have the 
> same result as 1.0.1
>
> Mike
>
>
>
>
> _______________________________________________
> 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/20150213/2a1a9f10/attachment-0001.html>

From dev+openssl at seantek.com  Fri Feb 13 18:43:01 2015
From: dev+openssl at seantek.com (Sean Leonard)
Date: Fri, 13 Feb 2015 10:43:01 -0800
Subject: [openssl-users] pkcs12 how to have different key friendlyName?
Message-ID: <54DE45B5.7000000@seantek.com>

Using the openssl pkcs12 -export command, how can one specify a 
different friendlyName attribute for the private key?

For example, consider the command:
openssl pkcs12 -export -out pkcs12.p12 -name "sean key 2015" -inkey 
key.txt -in user.crt -name "sean user cert 2015" -certfile othercerts.txt

The resulting PKCS #12 file is structured:
=================================================
Certificate bag
Bag Attributes
     localKeyID: A8 27 59 DA...
     friendlyName: sean user cert 2015
subject=/...
issuer=/...
-----BEGIN CERTIFICATE-----
MIIFNzCCBB+gAwIBAgIQM9l4W5HgK1Amk8O6j/ceiDANBgkqhkiG9w0BAQsFADCB
...
-----END CERTIFICATE-----
Certificate bag
...
-----BEGIN CERTIFICATE-----
MIIFOjCCBCKgAwIBAgIRAOeNEe8GIrMlFJ1tdJReavQwDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----
Certificate bag
...
-----BEGIN CERTIFICATE-----
MIIFNzCCBB+gAwIBAgIQNeTi/66wrvlNcjCDiUjjWzANBgkqhkiG9w0BAQsFADCB
...
-----END CERTIFICATE-----
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
Bag Attributes
     localKeyID: A8 27 59 DA...
     friendlyName: sean user cert 2015
Key Attributes: <No Attributes>
Enter PEM pass phrase: [input]
Verifying - Enter PEM pass phrase: [input]
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFDjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIgGNOtafMxE8CAggA
...
-----END ENCRYPTED PRIVATE KEY-----

=================================================

Note that the friendlyName of the Shrouded Keybag is the friendly name 
of the certificate, which is not the intent.

If it is not possible to change the key name with the command-line, 
perhaps someone can point me to the source code location(s) where the 
key name can be altered?

Thanks!

Sean

From dev+openssl at seantek.com  Fri Feb 13 19:33:46 2015
From: dev+openssl at seantek.com (Sean Leonard)
Date: Fri, 13 Feb 2015 11:33:46 -0800
Subject: [openssl-users] pkcs12 is no encryption possible for certs?
Message-ID: <54DE519A.10201@seantek.com>

Using the openssl pkcs12 -export command, is it possible to specify a 
"-certpbe" value that does not do encryption? Perhaps you only want 
integrity protection--you don't care whether the certificates are 
shrouded. The PKCS #12 standard seems to imply that "certBags" can be 
used as-is; however, all examples of PKCS #12 files that I have seen 
encrypt the certificates.

Will other common crypto stacks be able to process such a PKCS #12 file 
(that does not encrypt the certificates)?

Thanks, Sean

From dthompson at prinpay.com  Fri Feb 13 19:54:36 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Fri, 13 Feb 2015 14:54:36 -0500
Subject: [openssl-users] i2d and d2i fucntions
In-Reply-To: <CA+mfXPFi6DEmOdf=a6eJTGMHe_FJf90DwgH8nLr6+fzY8LVXzQ@mail.gmail.com>
References: <CA+mfXPGRw3fdUYbDaKo9FSJJ2KBz37xkPttNRvEqeN6hPnCh9Q@mail.gmail.com>
 <001701d04707$ca50f1f0$5ef2d5d0$@prinpay.com>
 <CA+mfXPH2ZJKGMKk3VQbwmthXwC5zoxgsvgtANBZftMmhA5p0Lw@mail.gmail.com>
 <CA+mfXPFi6DEmOdf=a6eJTGMHe_FJf90DwgH8nLr6+fzY8LVXzQ@mail.gmail.com>
Message-ID: <004801d047c6$e754b790$b5fe26b0$@prinpay.com>

> From: openssl-users On Behalf Of Rajeswari K
> Sent: Friday, February 13, 2015 09:48
<snip>
> As part of [ECDSA] signature verification, we first take lenght_of_signature received 
> and compare with double the size of number_of_bytes from curve parameter. 
> Have converted the ECDSA_SIG to unsigned char * using the function i2d_ECDSA_SIG().
> Length returned by i2d_ECDSA_SIG() is 103.
> Whereas, the number_of_bytes value from curve parameter is 48. 

An EDCSA signature, like a DSA signature, and as the 'i2d' should clue you in,
is an ASN1 DER-encoded value. Specifically it is a SEQUENCE of two INTEGERs.
That means it consists of:

2 octets tag and length for the sequence -- OR 3 if the components together 
exceed 127 octets, which will occur almost always if the curve size exceeds 
496 bits and sometimes for slightly smaller curves, see below.

For each integer, 2 octets tag and length then N octets value, as long as the 
curve size does not exceed 1015 bits (and none currently come even close).
Remember DER INTEGERs are two's complement, and the R and S values 
are positive numbers that are for practical purposes uniform random up to 
the curve order which is usually chosen to be nearly a power of two that 
is a multiple of 8 (like 192, 256, 384) and thus require an extra sign octet.

Thus for a 384-bit curve, the encoded signature will be 6+2*48=102 
roughly 25% of the time, 6+48+49 about 50% and 6+49*2 about 25%.




From kudzu at tenebras.com  Fri Feb 13 20:02:06 2015
From: kudzu at tenebras.com (Michael Sierchio)
Date: Fri, 13 Feb 2015 12:02:06 -0800
Subject: [openssl-users] pkcs12 is no encryption possible for certs?
In-Reply-To: <54DE519A.10201@seantek.com>
References: <54DE519A.10201@seantek.com>
Message-ID: <CAHu1Y729=pspcXzJJmo6uMSfvKZQsP1Yh3iTRrkzR7+FKvabuQ@mail.gmail.com>

On Fri, Feb 13, 2015 at 11:33 AM, Sean Leonard <dev+openssl at seantek.com> wrote:
> Using the openssl pkcs12 -export command, is it possible to specify a
> "-certpbe" value that does not do encryption? Perhaps you only want
> integrity protection--you don't care whether the certificates are shrouded.
> The PKCS #12 standard seems to imply that "certBags" can be used as-is;
> however, all examples of PKCS #12 files that I have seen encrypt the
> certificates.
>
> Will other common crypto stacks be able to process such a PKCS #12 file
> (that does not encrypt the certificates)?

Whenever I hear someone talking about encrypting a certificate, I
conclude that they are horribly confused. A cert is signed, over the
entire contents, so integrity is reducible to the cryptographic
algorithms employed. A cert is not a secret, does not contain secrets,
etc.

- M

From openssl-users at dukhovni.org  Fri Feb 13 20:07:45 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 13 Feb 2015 20:07:45 +0000
Subject: [openssl-users] i2d and d2i fucntions
In-Reply-To: <CA+mfXPFi6DEmOdf=a6eJTGMHe_FJf90DwgH8nLr6+fzY8LVXzQ@mail.gmail.com>
References: <CA+mfXPGRw3fdUYbDaKo9FSJJ2KBz37xkPttNRvEqeN6hPnCh9Q@mail.gmail.com>
 <001701d04707$ca50f1f0$5ef2d5d0$@prinpay.com>
 <CA+mfXPH2ZJKGMKk3VQbwmthXwC5zoxgsvgtANBZftMmhA5p0Lw@mail.gmail.com>
 <CA+mfXPFi6DEmOdf=a6eJTGMHe_FJf90DwgH8nLr6+fzY8LVXzQ@mail.gmail.com>
Message-ID: <20150213200745.GO1260@mournblade.imrryr.org>

On Fri, Feb 13, 2015 at 08:17:40PM +0530, Rajeswari K wrote:

> We would like to use our internal verification logics for the key exchange
> message received at SSL client.

That sounds like a bad idea.  Let OpenSSL do the work for you,
configure appropriate trust anchors, or trusted leaf certificate
fingerprints.

-- 
	Viktor.

From steve at openssl.org  Fri Feb 13 20:12:19 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 13 Feb 2015 20:12:19 +0000
Subject: [openssl-users] pkcs12 is no encryption possible for certs?
In-Reply-To: <54DE519A.10201@seantek.com>
References: <54DE519A.10201@seantek.com>
Message-ID: <20150213201219.GA29935@openssl.org>

On Fri, Feb 13, 2015, Sean Leonard wrote:

> Using the openssl pkcs12 -export command, is it possible to specify
> a "-certpbe" value that does not do encryption? Perhaps you only
> want integrity protection--you don't care whether the certificates
> are shrouded. The PKCS #12 standard seems to imply that "certBags"
> can be used as-is; however, all examples of PKCS #12 files that I
> have seen encrypt the certificates.
> 

Try -certpbe NONE

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

From steve at openssl.org  Fri Feb 13 20:23:21 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 13 Feb 2015 20:23:21 +0000
Subject: [openssl-users] pkcs12 how to have different key friendlyName?
In-Reply-To: <54DE45B5.7000000@seantek.com>
References: <54DE45B5.7000000@seantek.com>
Message-ID: <20150213202321.GB29935@openssl.org>

On Fri, Feb 13, 2015, Sean Leonard wrote:

> Using the openssl pkcs12 -export command, how can one specify a
> different friendlyName attribute for the private key?
> 
> For example, consider the command:
> openssl pkcs12 -export -out pkcs12.p12 -name "sean key 2015" -inkey
> key.txt -in user.crt -name "sean user cert 2015" -certfile
> othercerts.txt
> 

I'm curious as to why you want to do this.

If no friendlyname is specified on the command line an "alias" associated with
the certificate is used instead. You can associate an alias with a certificate
like this:

openssl x509 -in cert.pem -setalias "some name" -out newcert.pem

Unfortunately the -name option specified on the command line will also be
used even if there is an alias present. You can change this by looking in
crypto/pkcs12/p12_crt.c in the function PKCS12_create. Comment out the
following lines:

        if (name && !PKCS12_add_friendlyname(bag, name, -1))
            goto err;

Then you can specify the certificate friendlyname using the alias and the
private key friendly name using the command line -name option.

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

From openssl-users at dukhovni.org  Fri Feb 13 20:32:35 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 13 Feb 2015 20:32:35 +0000
Subject: [openssl-users] pkcs12 is no encryption possible for certs?
In-Reply-To: <CAHu1Y729=pspcXzJJmo6uMSfvKZQsP1Yh3iTRrkzR7+FKvabuQ@mail.gmail.com>
References: <54DE519A.10201@seantek.com>
 <CAHu1Y729=pspcXzJJmo6uMSfvKZQsP1Yh3iTRrkzR7+FKvabuQ@mail.gmail.com>
Message-ID: <20150213203234.GP1260@mournblade.imrryr.org>

On Fri, Feb 13, 2015 at 12:02:06PM -0800, Michael Sierchio wrote:

> Whenever I hear someone talking about encrypting a certificate, I
> conclude that they are horribly confused. A cert is signed, over the
> entire contents, so integrity is reducible to the cryptographic
> algorithms employed. A cert is not a secret, does not contain secrets,
> etc.

And yet, PKCS#12 objects are encrypted, and include certificates.

-- 
	Viktor.

From gregs at sloop.net  Fri Feb 13 20:32:13 2015
From: gregs at sloop.net (Gregory Sloop)
Date: Fri, 13 Feb 2015 12:32:13 -0800
Subject: [openssl-users] pkcs12 is no encryption possible for certs?
In-Reply-To: <CAHu1Y729=pspcXzJJmo6uMSfvKZQsP1Yh3iTRrkzR7+FKvabuQ@mail.gmail.com>
References: <54DE519A.10201@seantek.com>
 <CAHu1Y729=pspcXzJJmo6uMSfvKZQsP1Yh3iTRrkzR7+FKvabuQ@mail.gmail.com>
Message-ID: <1712104131.20150213123213@sloop.net>



MS> On Fri, Feb 13, 2015 at 11:33 AM, Sean Leonard <dev+openssl at seantek.com> wrote:
>> Using the openssl pkcs12 -export command, is it possible to specify a
>> "-certpbe" value that does not do encryption? Perhaps you only want
>> integrity protection--you don't care whether the certificates are shrouded.
>> The PKCS #12 standard seems to imply that "certBags" can be used as-is;
>> however, all examples of PKCS #12 files that I have seen encrypt the
>> certificates.

>> Will other common crypto stacks be able to process such a PKCS #12 file
>> (that does not encrypt the certificates)?

MS> Whenever I hear someone talking about encrypting a certificate, I
MS> conclude that they are horribly confused. A cert is signed, over the
MS> entire contents, so integrity is reducible to the cryptographic
MS> algorithms employed. A cert is not a secret, does not contain secrets,
MS> etc.

It's easy to make a mistake and...
...type "cert" when you really mean "key."
...not remember/understand/grok that PKCS12 files often contain both certs and keys. [And that both can be encrypted.]

BTW, as long as we're talking about p12's and encryption. It's my experience that using a cipher other than 3DES [i.e. AES128/256] won't be handled well [i.e. not at all] by current versions of Windows or OSX. 

I know that's not the direction of the question, and only oblique to it, but perhaps it's useful.

-Greg


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

From kudzu at tenebras.com  Fri Feb 13 21:25:11 2015
From: kudzu at tenebras.com (Michael Sierchio)
Date: Fri, 13 Feb 2015 13:25:11 -0800
Subject: [openssl-users] pkcs12 is no encryption possible for certs?
In-Reply-To: <20150213203234.GP1260@mournblade.imrryr.org>
References: <54DE519A.10201@seantek.com>
 <CAHu1Y729=pspcXzJJmo6uMSfvKZQsP1Yh3iTRrkzR7+FKvabuQ@mail.gmail.com>
 <20150213203234.GP1260@mournblade.imrryr.org>
Message-ID: <CAHu1Y71-H98-2KQ0uuU1AYZygdbLub8rt-qiFGq01p=Sz9PBEQ@mail.gmail.com>

Yes, I am sure that some folks find known plaintext in an encrypted object
to be helpful.

[apologies for top-posting... dumb smart phone]

- M
On Feb 13, 2015 1:21 PM, "Viktor Dukhovni" <openssl-users at dukhovni.org>
wrote:

> On Fri, Feb 13, 2015 at 12:02:06PM -0800, Michael Sierchio wrote:
>
> > Whenever I hear someone talking about encrypting a certificate, I
> > conclude that they are horribly confused. A cert is signed, over the
> > entire contents, so integrity is reducible to the cryptographic
> > algorithms employed. A cert is not a secret, does not contain secrets,
> > etc.
>
> And yet, PKCS#12 objects are encrypted, and include certificates.
>
> --
>         Viktor.
> _______________________________________________
> 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/20150213/8c7ba729/attachment.html>

From raji.kotamraju at gmail.com  Sat Feb 14 04:50:06 2015
From: raji.kotamraju at gmail.com (Rajeswari K)
Date: Sat, 14 Feb 2015 10:20:06 +0530
Subject: [openssl-users] i2d and d2i fucntions
In-Reply-To: <004801d047c6$e754b790$b5fe26b0$@prinpay.com>
References: <CA+mfXPGRw3fdUYbDaKo9FSJJ2KBz37xkPttNRvEqeN6hPnCh9Q@mail.gmail.com>
 <001701d04707$ca50f1f0$5ef2d5d0$@prinpay.com>
 <CA+mfXPH2ZJKGMKk3VQbwmthXwC5zoxgsvgtANBZftMmhA5p0Lw@mail.gmail.com>
 <CA+mfXPFi6DEmOdf=a6eJTGMHe_FJf90DwgH8nLr6+fzY8LVXzQ@mail.gmail.com>
 <004801d047c6$e754b790$b5fe26b0$@prinpay.com>
Message-ID: <CA+mfXPE8nmJcLdcJZLWiBXzj_1JS1+ZP7mkWkbBr+ANo6LW8-Q@mail.gmail.com>

Hello Dave,

Based on your input, have stopped calling i2d_ECDSA_SIG() and used
BN_bn2bin() to overcome the der headers.

And now, my verification is working fine.

Is there any function at openssl, to get the HASH used for the digest at
ECDSA_verify()?

I see that, for ECDSA_verify(), first argument is type. But when its
calling the function pointer, ECDSA_verify() is not passing the type of the
hash.

So, would like to get the hash type from digest data.

I can understand that for TLS1.2, openssl uses SHA512. But the same
information i would like to get from digest data. Is there any way to get
this? Please share.

Thanks,
Rajeswari.

On Sat, Feb 14, 2015 at 1:24 AM, Dave Thompson <dthompson at prinpay.com>
wrote:

> > From: openssl-users On Behalf Of Rajeswari K
> > Sent: Friday, February 13, 2015 09:48
> <snip>
> > As part of [ECDSA] signature verification, we first take
> lenght_of_signature received
> > and compare with double the size of number_of_bytes from curve parameter.
> > Have converted the ECDSA_SIG to unsigned char * using the function
> i2d_ECDSA_SIG().
> > Length returned by i2d_ECDSA_SIG() is 103.
> > Whereas, the number_of_bytes value from curve parameter is 48.
>
> An EDCSA signature, like a DSA signature, and as the 'i2d' should clue you
> in,
> is an ASN1 DER-encoded value. Specifically it is a SEQUENCE of two
> INTEGERs.
> That means it consists of:
>
> 2 octets tag and length for the sequence -- OR 3 if the components together
> exceed 127 octets, which will occur almost always if the curve size exceeds
> 496 bits and sometimes for slightly smaller curves, see below.
>
> For each integer, 2 octets tag and length then N octets value, as long as
> the
> curve size does not exceed 1015 bits (and none currently come even close).
> Remember DER INTEGERs are two's complement, and the R and S values
> are positive numbers that are for practical purposes uniform random up to
> the curve order which is usually chosen to be nearly a power of two that
> is a multiple of 8 (like 192, 256, 384) and thus require an extra sign
> octet.
>
> Thus for a 384-bit curve, the encoded signature will be 6+2*48=102
> roughly 25% of the time, 6+48+49 about 50% and 6+49*2 about 25%.
>
>
>
> _______________________________________________
> 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/20150214/85def9b1/attachment.html>

From dev+openssl at seantek.com  Sat Feb 14 07:36:06 2015
From: dev+openssl at seantek.com (Sean Leonard)
Date: Fri, 13 Feb 2015 23:36:06 -0800
Subject: [openssl-users] pkcs12 is no encryption possible for certs?
In-Reply-To: <20150213201219.GA29935@openssl.org>
References: <54DE519A.10201@seantek.com> <20150213201219.GA29935@openssl.org>
Message-ID: <54DEFAE6.5060309@seantek.com>

On 2/13/2015 12:12 PM, Dr. Stephen Henson wrote:
> On Fri, Feb 13, 2015, Sean Leonard wrote:
>
>> Using the openssl pkcs12 -export command, is it possible to specify
>> a "-certpbe" value that does not do encryption? Perhaps you only
>> want integrity protection--you don't care whether the certificates
>> are shrouded. The PKCS #12 standard seems to imply that "certBags"
>> can be used as-is; however, all examples of PKCS #12 files that I
>> have seen encrypt the certificates.
>>
> Try -certpbe NONE

Thank you! That did the trick. The resultant PKCS #12 file contains the 
certBag type containing OCTET STRINGS identified as x509Certificate, 
containing the binary certificates. A partial analyzed example from 
"asn1js" is included for doubters.

Importing this PKCS #12 file into Microsoft CryptoAPI, Mozilla NSS, and 
Apple Mac OS X Keychain succeeded in all cases. (Note that the -macalg 
was not changed; it used the default of SHA-1.)

Best regards,

Sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shows-certbag-oids-example.png
Type: image/png
Size: 22280 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150213/0d65b1b7/attachment-0001.png>

From dev+openssl at seantek.com  Sat Feb 14 07:56:05 2015
From: dev+openssl at seantek.com (Sean Leonard)
Date: Fri, 13 Feb 2015 23:56:05 -0800
Subject: [openssl-users] pkcs12 how to have different key friendlyName?
In-Reply-To: <20150213202321.GB29935@openssl.org>
References: <54DE45B5.7000000@seantek.com> <20150213202321.GB29935@openssl.org>
Message-ID: <54DEFF95.50103@seantek.com>

On 2/13/2015 12:23 PM, Dr. Stephen Henson wrote:
> On Fri, Feb 13, 2015, Sean Leonard wrote:
>
>> Using the openssl pkcs12 -export command, how can one specify a
>> different friendlyName attribute for the private key?
>>
>> For example, consider the command:
>> openssl pkcs12 -export -out pkcs12.p12 -name "sean key 2015" -inkey
>> key.txt -in user.crt -name "sean user cert 2015" -certfile
>> othercerts.txt
>>
> I'm curious as to why you want to do this.

Well, as a PKI and S/MIME developer I am researching how various bits of 
information relating to crypto objects can be preserved between systems. 
It is useful to set the cert and key friendly names independently for 
certain development and possibly usability reasons. Development reasons 
include needing to address the private key specifically, regardless of 
whether it is associated with any particular certificate, and to see 
when certificates have private key (instances) on particular crypto tokens.

Usability reasons include distinguishing between certificates and 
private keys for users, who tend to get confused about these things 
because virtually no existing UIs meaningfully distinguish between the 
two (usually certificates for which you have a private key are simply 
called "certificates", or possibly "your certificates"...thus a user 
sends "your [his/her] certificate" and while the user's mental model is 
that the certificate is intended to be shared, the user unwittingly 
sends along a p12 file with a simple password like 123456).

Whether the usability is an area of research that I am looking into. No 
pronouncements can be made one way or another yet. Suffice to say that 
the technical capability has to exist at the lower layer before one can 
evaluate usability enhancements at higher layers.

>
> If no friendlyname is specified on the command line an "alias" associated with
> the certificate is used instead. You can associate an alias with a certificate
> like this:
>
> openssl x509 -in cert.pem -setalias "some name" -out newcert.pem
>
> Unfortunately the -name option specified on the command line will also be
> used even if there is an alias present. You can change this by looking in
> crypto/pkcs12/p12_crt.c in the function PKCS12_create. Comment out the
> following lines:
>
>          if (name && !PKCS12_add_friendlyname(bag, name, -1))
>              goto err;
>
> Then you can specify the certificate friendlyname using the alias and the
> private key friendly name using the command line -name option.

Sounds good...I will attempt this and report back. Ah, the TRUSTED 
CERTIFICATE format returns...

Sean

From BenBE at geshi.org  Sat Feb 14 12:05:48 2015
From: BenBE at geshi.org (Benny Baumann)
Date: Sat, 14 Feb 2015 13:05:48 +0100
Subject: [openssl-users] Fwd: Problem with encoding a CRL's signing algorithm
In-Reply-To: <54DB2525.3000300@dogcraft.de>
References: <54DB2525.3000300@dogcraft.de>
Message-ID: <54DF3A1C.8010106@geshi.org>

Hi,

I think there is somewhat strange behaviour in OpenSSL that causes
interesting bugs to happen when trying to encode CRLs based on deltas.
More information about the issue (causing a segfault under certain
conditions) is in the attached mail by Felix who discovered it.

Regards,
BenBE.
-------------- next part --------------
An embedded message was scrubbed...
From: =?UTF-8?B?RmVsaXggRMO2cnJl?= <felix at dogcraft.de>
Subject: Problem with encoding a CRL's signing algorithm
Date: Wed, 11 Feb 2015 10:47:17 +0100
Size: 5922
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150214/fa3b2b27/attachment.eml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150214/fa3b2b27/attachment.sig>

From steve at openssl.org  Sat Feb 14 16:54:49 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sat, 14 Feb 2015 16:54:49 +0000
Subject: [openssl-users] Fwd: Problem with encoding a CRL's signing
 algorithm
In-Reply-To: <54DF3A1C.8010106@geshi.org>
References: <54DB2525.3000300@dogcraft.de>
 <54DF3A1C.8010106@geshi.org>
Message-ID: <20150214165449.GA13918@openssl.org>

On Sat, Feb 14, 2015, Benny Baumann wrote:

> 
> I want to encode a new CRL's (X509_CRL_new), currently invalid,
> Signing algorithm (i2d_X509_ALGOR( crl->siging_alg, ... ) ) and
> restore that with "d2i_X509_ALGOR( &crl->signing_alg, ...)"
> afterwards. Restoring of the algorithm works fine in OpenSSL
> 1.0.1.f, but fails in OpenSSL 1.0.1j and 1.0.1l. This is probably
> because the "i2d" function encodes the (invalid) Signing algorithms
> slightly different in the different versions. This happens, because
> the invalid signing algorithm is represented slightly different in
> the internal structure.
> In version 1.0.1f the invalid algorithm is encoded as sequence with
> an object id with length 1 and content "00" ( -> 30 03 06 01 00). In
> the newer versions (1.0.1j and 1.0.1l)  the invalid algorithm gets
> encoded as sequence with an object id of length 0 ( -> 30 02 06 00).
> This new encoding causes the "d2i" function to fail. Now the "d2i"
> function nulls the "sig_alg". This causes a "X509_CRL_verify" to
> cause a segfault.
> 
> Is this behavior expected? Am I doing something wrong? Is there a
> problem with what "X509_CRL_new" does (setting different
> "UNDEFINED"-ObjectId-Objects)?
> For better clarifying my problem, I have attached a small example
> code that creates such a CRL, tries to verify it (what will fail,
> but not crash), does the i2d, d2i re-setting of the Algorithm and
> re-calls X509_CRL_verify which now crashes in 1.0.1j and 1.0.1l, but
> works fine in 1.0.1.f.
> 

Arguably the bug is in the i2d functions which should refuse to encode
a structure which hasn't been properly initialised.

If you set the algorithm OID to a valid value (which you can change later)
this should work in all versions of OpenSSL.

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

From raji.kotamraju at gmail.com  Mon Feb 16 08:05:23 2015
From: raji.kotamraju at gmail.com (Rajeswari K)
Date: Mon, 16 Feb 2015 13:35:23 +0530
Subject: [openssl-users] i2d and d2i fucntions
In-Reply-To: <CA+mfXPE8nmJcLdcJZLWiBXzj_1JS1+ZP7mkWkbBr+ANo6LW8-Q@mail.gmail.com>
References: <CA+mfXPGRw3fdUYbDaKo9FSJJ2KBz37xkPttNRvEqeN6hPnCh9Q@mail.gmail.com>
 <001701d04707$ca50f1f0$5ef2d5d0$@prinpay.com>
 <CA+mfXPH2ZJKGMKk3VQbwmthXwC5zoxgsvgtANBZftMmhA5p0Lw@mail.gmail.com>
 <CA+mfXPFi6DEmOdf=a6eJTGMHe_FJf90DwgH8nLr6+fzY8LVXzQ@mail.gmail.com>
 <004801d047c6$e754b790$b5fe26b0$@prinpay.com>
 <CA+mfXPE8nmJcLdcJZLWiBXzj_1JS1+ZP7mkWkbBr+ANo6LW8-Q@mail.gmail.com>
Message-ID: <CA+mfXPFXeSD3J+TPa3hdp4Kpgu28ZEeDdm+VsZf7XirPDMG_Mg@mail.gmail.com>

Hello Dave,

Our current signature and verification logics are working just fine with
TLS1.0 and TLS1.1 for ECDHE_ECDSA cipher suite.

But, when tested the same cipher suite with TLS1.2, SSL handshake always
failing with "bad signature".

Do we need to take care of anything specific for TLS1.2 handshake?

Thanks,
Rajeswari.

On Sat, Feb 14, 2015 at 10:20 AM, Rajeswari K <raji.kotamraju at gmail.com>
wrote:

> Hello Dave,
>
> Based on your input, have stopped calling i2d_ECDSA_SIG() and used
> BN_bn2bin() to overcome the der headers.
>
> And now, my verification is working fine.
>
> Is there any function at openssl, to get the HASH used for the digest at
> ECDSA_verify()?
>
> I see that, for ECDSA_verify(), first argument is type. But when its
> calling the function pointer, ECDSA_verify() is not passing the type of the
> hash.
>
> So, would like to get the hash type from digest data.
>
> I can understand that for TLS1.2, openssl uses SHA512. But the same
> information i would like to get from digest data. Is there any way to get
> this? Please share.
>
> Thanks,
> Rajeswari.
>
> On Sat, Feb 14, 2015 at 1:24 AM, Dave Thompson <dthompson at prinpay.com>
> wrote:
>
>> > From: openssl-users On Behalf Of Rajeswari K
>> > Sent: Friday, February 13, 2015 09:48
>> <snip>
>> > As part of [ECDSA] signature verification, we first take
>> lenght_of_signature received
>> > and compare with double the size of number_of_bytes from curve
>> parameter.
>> > Have converted the ECDSA_SIG to unsigned char * using the function
>> i2d_ECDSA_SIG().
>> > Length returned by i2d_ECDSA_SIG() is 103.
>> > Whereas, the number_of_bytes value from curve parameter is 48.
>>
>> An EDCSA signature, like a DSA signature, and as the 'i2d' should clue
>> you in,
>> is an ASN1 DER-encoded value. Specifically it is a SEQUENCE of two
>> INTEGERs.
>> That means it consists of:
>>
>> 2 octets tag and length for the sequence -- OR 3 if the components
>> together
>> exceed 127 octets, which will occur almost always if the curve size
>> exceeds
>> 496 bits and sometimes for slightly smaller curves, see below.
>>
>> For each integer, 2 octets tag and length then N octets value, as long as
>> the
>> curve size does not exceed 1015 bits (and none currently come even close).
>> Remember DER INTEGERs are two's complement, and the R and S values
>> are positive numbers that are for practical purposes uniform random up to
>> the curve order which is usually chosen to be nearly a power of two that
>> is a multiple of 8 (like 192, 256, 384) and thus require an extra sign
>> octet.
>>
>> Thus for a 384-bit curve, the encoded signature will be 6+2*48=102
>> roughly 25% of the time, 6+48+49 about 50% and 6+49*2 about 25%.
>>
>>
>>
>> _______________________________________________
>> 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/20150216/3c2c46cd/attachment.html>

From dthompson at prinpay.com  Mon Feb 16 18:23:46 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Mon, 16 Feb 2015 13:23:46 -0500
Subject: [openssl-users] i2d and d2i fucntions
In-Reply-To: <CA+mfXPFXeSD3J+TPa3hdp4Kpgu28ZEeDdm+VsZf7XirPDMG_Mg@mail.gmail.com>
References: <CA+mfXPGRw3fdUYbDaKo9FSJJ2KBz37xkPttNRvEqeN6hPnCh9Q@mail.gmail.com>
 <001701d04707$ca50f1f0$5ef2d5d0$@prinpay.com>
 <CA+mfXPH2ZJKGMKk3VQbwmthXwC5zoxgsvgtANBZftMmhA5p0Lw@mail.gmail.com>
 <CA+mfXPFi6DEmOdf=a6eJTGMHe_FJf90DwgH8nLr6+fzY8LVXzQ@mail.gmail.com>
 <004801d047c6$e754b790$b5fe26b0$@prinpay.com>
 <CA+mfXPE8nmJcLdcJZLWiBXzj_1JS1+ZP7mkWkbBr+ANo6LW8-Q@mail.gmail.com>
 <CA+mfXPFXeSD3J+TPa3hdp4Kpgu28ZEeDdm+VsZf7XirPDMG_Mg@mail.gmail.com>
Message-ID: <001e01d04a15$b5eb74e0$21c25ea0$@prinpay.com>

> From: openssl-users On Behalf Of Rajeswari K
> Sent: Monday, February 16, 2015 03:05

> Our current signature and verification logics are working just fine 
> with TLS1.0 and TLS1.1 for ECDHE_ECDSA cipher suite.

> But, when tested the same cipher suite with TLS1.2, SSL handshake 
> always failing with "bad signature".

> Do we need to take care of anything specific for TLS1.2 handshake?

Not as such. But you do need to correctly handle truncating a hash 
to be signed/verified that is longer than the key size, both in bits, 
as shown in OpenSSL's implementation in ecs_ossl.c.

That case will occur for TLS1.2 if SHA512 is offered and chosen for the 
hash and the key in use is a 384-bit key, which your previous questions 
have suggested. That case will only occur for 1.0 and 1.1 only if using 
a key too small to be secure, which obviously you shouldn't do.




From dthompson at prinpay.com  Mon Feb 16 18:23:46 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Mon, 16 Feb 2015 13:23:46 -0500
Subject: [openssl-users] i2d and d2i fucntions
In-Reply-To: <CA+mfXPE8nmJcLdcJZLWiBXzj_1JS1+ZP7mkWkbBr+ANo6LW8-Q@mail.gmail.com>
References: <CA+mfXPGRw3fdUYbDaKo9FSJJ2KBz37xkPttNRvEqeN6hPnCh9Q@mail.gmail.com>
 <001701d04707$ca50f1f0$5ef2d5d0$@prinpay.com>
 <CA+mfXPH2ZJKGMKk3VQbwmthXwC5zoxgsvgtANBZftMmhA5p0Lw@mail.gmail.com>
 <CA+mfXPFi6DEmOdf=a6eJTGMHe_FJf90DwgH8nLr6+fzY8LVXzQ@mail.gmail.com>
 <004801d047c6$e754b790$b5fe26b0$@prinpay.com>
 <CA+mfXPE8nmJcLdcJZLWiBXzj_1JS1+ZP7mkWkbBr+ANo6LW8-Q@mail.gmail.com>
Message-ID: <001f01d04a15$b776a8c0$2663fa40$@prinpay.com>

> From: openssl-users On Behalf Of Rajeswari K
> Sent: Friday, February 13, 2015 23:50
> Hello Dave,
> Based on your input, have stopped calling i2d_ECDSA_SIG() 
> and used BN_bn2bin() to overcome the der headers. 
> And now, my verification is working fine.

ECDSA_verify in ecs_vrf.c only uses i2d to *check* that the 
input was canonical, to block certain possible attacks. It's 
the d2i that parsed the signature, and the internal form 
(ECDSA_SIG structure) is used for the actual verification.

> Is there any function at openssl, to get the HASH used for 
> the digest at ECDSA_verify()?
> I see that, for ECDSA_verify(), first argument is type. But 
> when its calling the function pointer, ECDSA_verify() is not 
> passing the type of the hash. 
> So, would like to get the hash type from digest data. 

ECDSA (and DSA) signatures do not care about the hash 
algorithm, only the length of the hash *value*. Notice 
that ECDSA_verify does not pass type to ECDSA_do_verify, 
which does the actual dispatch to a possible engine.
(This differs from RSA, at least PKCS#1 as used by SSL/TLS, 
where the hash algorithm identifier is included in padding.)

> I can understand that for TLS1.2, openssl uses SHA512. 
> But the same information i would like to get from digest data. 
> Is there any way to get this? Please share. 

For the ServerKeyExchange message (the case you said 
you cared about) in TLS1.2, it appears OpenSSL server uses 
the client's preference as stated in the sigalgs extension,
except in 1.0.2 a new SuiteB option forces SuiteB choices.
If the client offers all current hashes for ECDSA in strength 
order, which is very reasonable, SHA512 will be the choice.




From dev+openssl at seantek.com  Mon Feb 16 22:48:50 2015
From: dev+openssl at seantek.com (Sean Leonard)
Date: Mon, 16 Feb 2015 14:48:50 -0800
Subject: [openssl-users] pkcs12 how to have different key friendlyName?
In-Reply-To: <20150213202321.GB29935@openssl.org>
References: <54DE45B5.7000000@seantek.com> <20150213202321.GB29935@openssl.org>
Message-ID: <54E273D2.1080102@seantek.com>

On 2/13/2015 12:23 PM, Dr. Stephen Henson wrote:
> On Fri, Feb 13, 2015, Sean Leonard wrote:
>
>> Using the openssl pkcs12 -export command, how can one specify a
>> different friendlyName attribute for the private key?
>>
>> For example, consider the command:
>> openssl pkcs12 -export -out pkcs12.p12 -name "sean key 2015" -inkey
>> key.txt -in user.crt -name "sean user cert 2015" -certfile
>> othercerts.txt
>>
> I'm curious as to why you want to do this.
>
> If no friendlyname is specified on the command line an "alias" associated with
> the certificate is used instead. You can associate an alias with a certificate
> like this:
>
> openssl x509 -in cert.pem -setalias "some name" -out newcert.pem
>
> Unfortunately the -name option specified on the command line will also be
> used even if there is an alias present. You can change this by looking in
> crypto/pkcs12/p12_crt.c in the function PKCS12_create. Comment out the
> following lines:
>
>          if (name && !PKCS12_add_friendlyname(bag, name, -1))
>              goto err;
>
> Then you can specify the certificate friendlyname using the alias and the
> private key friendly name using the command line -name option.

I attempted to do this today (comment out those two lines) with OpenSSL 
1.0.2. It was around line 127 in p12_crt.c in the 1.0.2 distribution.

Using the -name option managed to set the friendly name of the private 
key, not the certificate. Unfortunately, using {x509 -setalias} followed 
by inputting it to {pkcs12 -in aliasedcert.pem} did not work: the 
friendly name attribute was not set on the certificate. Only the 
localKeyID property was set. I verified the pkcs12 output with {pkcs12 
-in pkcs12.p12 -info}.

When I changed the code to:

         if (!PKCS12_add_friendlyname(bag, "HARDCODED FRIENDLYNAME", -1))
             goto err;

the friendly name of the certificate was set properly to the hardcoded 
value, and the private key friendly name was set to the -name option 
(presumably the name local variable in the same function).

Any ideas on why the alias name is not getting used?

I looked into PKCS12_add_cert (also in p12_crt.c) and did not see 
anything particularly amiss. That function calls X509_alias_get0 -> 
PKCS12_add_friendlyname. As long as the certificate structure has the 
"aux" appendage, it should work. I ran {x509 -in aliasedcert.pem -alias} 
and the proper alias was output. Therefore, I am thinking that something 
is going on with certificate processing prior to the PKCS12_create call, 
which strips the aux information.

Kind regards,

Sean


From trapni at gmail.com  Tue Feb 17 09:47:46 2015
From: trapni at gmail.com (Christian Parpart)
Date: Tue, 17 Feb 2015 10:47:46 +0100
Subject: [openssl-users] How to retrieve the commonName / Alt-Name
	(DNS-Name) from a .crt file
Message-ID: <CA+qvzFM8Z4fCyC-rtAtEFuT6y6XGHJPct7tEoJQaFcSzrA9kKA@mail.gmail.com>

Hey guys,

I am rather new to OpenSSL development, but I'd like to integrate SSL
communication in my little HTTP server.
While this one is working so far, for SNI I actually need to read out the
server certificates DNS name extenion and commonName subject.

Currently I am doing something like:

SSL_CTX* ctx = SSL_CTX_new(TLSv1_2_server_method());
SSL_CTX_use_certificate_file(ctx, "/path/to/server1.crt",SSL_FILETYPE_PEM);
SSL_CTX_use_PrivateKey_file(ctx, "/path/to/server1.key", SSL_FILETYPE_PEM);

I need to somehow get a ptr to the X509 struct to do something like:

X509* crt = /* how to get  my X509 out of the SSL_CTX */
STACK_OF(GENERAL_NAME) altnames =
         X509_get_ext_d2i(crt, NID_subject_alt_name, NULL, NULL);
int numAltNames = sk_GENERAL_NAME_num(altnames);

for (int i = 0; i < numAltNames; ++i) {
    GENERAL_NAME* altname = sk_GENERAL_NAME_value(altnames, i);
    if (altname->type == GEN_DNS) {
        printf("found DNS-Name: %s\n", altname->d.dNSName);
    }
}
GENERAL_NAMES_free(altnames);

in order to get the DNS alt-name at least.
But how do I come from the SSL_CTX to my X509 struct, or how to I do it
else?

Many thanks in advance,
Christian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150217/7e7b3143/attachment.html>

From raji.kotamraju at gmail.com  Tue Feb 17 11:44:16 2015
From: raji.kotamraju at gmail.com (Rajeswari K)
Date: Tue, 17 Feb 2015 17:14:16 +0530
Subject: [openssl-users] i2d and d2i fucntions
In-Reply-To: <001f01d04a15$b776a8c0$2663fa40$@prinpay.com>
References: <CA+mfXPGRw3fdUYbDaKo9FSJJ2KBz37xkPttNRvEqeN6hPnCh9Q@mail.gmail.com>
 <001701d04707$ca50f1f0$5ef2d5d0$@prinpay.com>
 <CA+mfXPH2ZJKGMKk3VQbwmthXwC5zoxgsvgtANBZftMmhA5p0Lw@mail.gmail.com>
 <CA+mfXPFi6DEmOdf=a6eJTGMHe_FJf90DwgH8nLr6+fzY8LVXzQ@mail.gmail.com>
 <004801d047c6$e754b790$b5fe26b0$@prinpay.com>
 <CA+mfXPE8nmJcLdcJZLWiBXzj_1JS1+ZP7mkWkbBr+ANo6LW8-Q@mail.gmail.com>
 <001f01d04a15$b776a8c0$2663fa40$@prinpay.com>
Message-ID: <CA+mfXPHNsO2h5THek3x_r-G=99gccoKGHfK_ChnXGEX0kzQ5pQ@mail.gmail.com>

Hello Dave,

What you said is right. Have checked ecs_ossl.c and implemented similar way
to truncate the digest based on the order.

Now, handshake is successful even for TLS1.2.

Thanks alot.

Rajeswari.

On Mon, Feb 16, 2015 at 11:53 PM, Dave Thompson <dthompson at prinpay.com>
wrote:

> > From: openssl-users On Behalf Of Rajeswari K
> > Sent: Friday, February 13, 2015 23:50
> > Hello Dave,
> > Based on your input, have stopped calling i2d_ECDSA_SIG()
> > and used BN_bn2bin() to overcome the der headers.
> > And now, my verification is working fine.
>
> ECDSA_verify in ecs_vrf.c only uses i2d to *check* that the
> input was canonical, to block certain possible attacks. It's
> the d2i that parsed the signature, and the internal form
> (ECDSA_SIG structure) is used for the actual verification.
>
> > Is there any function at openssl, to get the HASH used for
> > the digest at ECDSA_verify()?
> > I see that, for ECDSA_verify(), first argument is type. But
> > when its calling the function pointer, ECDSA_verify() is not
> > passing the type of the hash.
> > So, would like to get the hash type from digest data.
>
> ECDSA (and DSA) signatures do not care about the hash
> algorithm, only the length of the hash *value*. Notice
> that ECDSA_verify does not pass type to ECDSA_do_verify,
> which does the actual dispatch to a possible engine.
> (This differs from RSA, at least PKCS#1 as used by SSL/TLS,
> where the hash algorithm identifier is included in padding.)
>
> > I can understand that for TLS1.2, openssl uses SHA512.
> > But the same information i would like to get from digest data.
> > Is there any way to get this? Please share.
>
> For the ServerKeyExchange message (the case you said
> you cared about) in TLS1.2, it appears OpenSSL server uses
> the client's preference as stated in the sigalgs extension,
> except in 1.0.2 a new SuiteB option forces SuiteB choices.
> If the client offers all current hashes for ECDSA in strength
> order, which is very reasonable, SHA512 will be the choice.
>
>
>
> _______________________________________________
> 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/20150217/3dcbe06f/attachment.html>

From rasjv at yandex.com  Tue Feb 17 19:56:13 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Tue, 17 Feb 2015 22:56:13 +0300
Subject: [openssl-users] How to retrieve the commonName / Alt-Name
	(DNS-Name) from a .crt file
In-Reply-To: <CA+qvzFM8Z4fCyC-rtAtEFuT6y6XGHJPct7tEoJQaFcSzrA9kKA@mail.gmail.com>
References: <CA+qvzFM8Z4fCyC-rtAtEFuT6y6XGHJPct7tEoJQaFcSzrA9kKA@mail.gmail.com>
Message-ID: <15186611424202973@web21o.yandex.ru>

Hi, Christian 

17.02.2015, 12:55, "Christian Parpart" <trapni at gmail.com>:
> I am rather new to OpenSSL development, but I'd like to integrate SSL
> communication in my little HTTP server.
> While this one is working so far, for SNI I actually need to read out the
> server certificates DNS name extenion and commonName subject.

How to get CN and "subject alternative names" from cert you can see this wiki page:?http://wiki.openssl.org/index.php/Hostname_validation


> But how do I come from the SSL_CTX to my X509 struct, or how to I do it else?

1.?SSL_CTX_set_verify() or SSL_set_verify(),??then in callback  X509_STORE_CTX_get_current_cert()
2. SSL_get_peer_certificate()


--
Best Regards,

Serj Rakitov

From noloader at gmail.com  Tue Feb 17 20:14:56 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 17 Feb 2015 15:14:56 -0500
Subject: [openssl-users] How to retrieve the commonName / Alt-Name
 (DNS-Name) from a .crt file
In-Reply-To: <CA+qvzFM8Z4fCyC-rtAtEFuT6y6XGHJPct7tEoJQaFcSzrA9kKA@mail.gmail.com>
References: <CA+qvzFM8Z4fCyC-rtAtEFuT6y6XGHJPct7tEoJQaFcSzrA9kKA@mail.gmail.com>
Message-ID: <CAH8yC8=+=BURrREtHCFghEihGOqRBU6q8CORxU_bFtKPXA-txA@mail.gmail.com>

> X509* crt = /* how to get  my X509 out of the SSL_CTX */

    X509* cert = SSL_get_peer_certificate(ssl);
    if(cert) { X509_free(cert); }

Its reference counted, so be sure to free it.

Jeff

On Tue, Feb 17, 2015 at 4:47 AM, Christian Parpart <trapni at gmail.com> wrote:
> Hey guys,
>
> I am rather new to OpenSSL development, but I'd like to integrate SSL
> communication in my little HTTP server.
> While this one is working so far, for SNI I actually need to read out the
> server certificates DNS name extenion and commonName subject.
>
> Currently I am doing something like:
>
> SSL_CTX* ctx = SSL_CTX_new(TLSv1_2_server_method());
> SSL_CTX_use_certificate_file(ctx, "/path/to/server1.crt",SSL_FILETYPE_PEM);
> SSL_CTX_use_PrivateKey_file(ctx, "/path/to/server1.key", SSL_FILETYPE_PEM);
>
> I need to somehow get a ptr to the X509 struct to do something like:
>
> X509* crt = /* how to get  my X509 out of the SSL_CTX */
> STACK_OF(GENERAL_NAME) altnames =
>          X509_get_ext_d2i(crt, NID_subject_alt_name, NULL, NULL);
> int numAltNames = sk_GENERAL_NAME_num(altnames);
>
> for (int i = 0; i < numAltNames; ++i) {
>     GENERAL_NAME* altname = sk_GENERAL_NAME_value(altnames, i);
>     if (altname->type == GEN_DNS) {
>         printf("found DNS-Name: %s\n", altname->d.dNSName);
>     }
> }
> GENERAL_NAMES_free(altnames);
>
> in order to get the DNS alt-name at least.
> But how do I come from the SSL_CTX to my X509 struct, or how to I do it
> else?

From kebabking2015 at gmail.com  Tue Feb 17 20:49:34 2015
From: kebabking2015 at gmail.com (=?UTF-8?B?U8O4cmViw7ggTGluZGE=?=)
Date: Tue, 17 Feb 2015 12:49:34 -0800
Subject: [openssl-users] (no subject)
Message-ID: <CALAkgJbNCpPWJ-U6Z2guMigqa1tswtPY4g8LrveUUq1i-zs=xg@mail.gmail.com>

confirm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150217/207f3cf5/attachment.html>

From trapni at gmail.com  Wed Feb 18 11:20:55 2015
From: trapni at gmail.com (Christian Parpart)
Date: Wed, 18 Feb 2015 11:20:55 +0000
Subject: [openssl-users] How to retrieve the commonName / Alt-Name
 (DNS-Name) from a .crt file
References: <CA+qvzFM8Z4fCyC-rtAtEFuT6y6XGHJPct7tEoJQaFcSzrA9kKA@mail.gmail.com>
 <CAH8yC8=+=BURrREtHCFghEihGOqRBU6q8CORxU_bFtKPXA-txA@mail.gmail.com>
Message-ID: <CA+qvzFPeqEWL9toOmNikm0g85TQrS=2bGPTJ9q1R59rG=d5bZQ@mail.gmail.com>

On Tue Feb 17 2015 at 9:23:36 PM Jeffrey Walton <noloader at gmail.com> wrote:

> > X509* crt = /* how to get  my X509 out of the SSL_CTX */
>
>     X509* cert = SSL_get_peer_certificate(ssl);
>     if(cert) { X509_free(cert); }
>
> Its reference counted, so be sure to free it.
>

Thanks for the notice.

Cheers,
Christian.




> Jeff
>
> On Tue, Feb 17, 2015 at 4:47 AM, Christian Parpart <trapni at gmail.com>
> wrote:
> > Hey guys,
> >
> > I am rather new to OpenSSL development, but I'd like to integrate SSL
> > communication in my little HTTP server.
> > While this one is working so far, for SNI I actually need to read out the
> > server certificates DNS name extenion and commonName subject.
> >
> > Currently I am doing something like:
> >
> > SSL_CTX* ctx = SSL_CTX_new(TLSv1_2_server_method());
> > SSL_CTX_use_certificate_file(ctx, "/path/to/server1.crt",SSL_
> FILETYPE_PEM);
> > SSL_CTX_use_PrivateKey_file(ctx, "/path/to/server1.key",
> SSL_FILETYPE_PEM);
> >
> > I need to somehow get a ptr to the X509 struct to do something like:
> >
> > X509* crt = /* how to get  my X509 out of the SSL_CTX */
> > STACK_OF(GENERAL_NAME) altnames =
> >          X509_get_ext_d2i(crt, NID_subject_alt_name, NULL, NULL);
> > int numAltNames = sk_GENERAL_NAME_num(altnames);
> >
> > for (int i = 0; i < numAltNames; ++i) {
> >     GENERAL_NAME* altname = sk_GENERAL_NAME_value(altnames, i);
> >     if (altname->type == GEN_DNS) {
> >         printf("found DNS-Name: %s\n", altname->d.dNSName);
> >     }
> > }
> > GENERAL_NAMES_free(altnames);
> >
> > in order to get the DNS alt-name at least.
> > But how do I come from the SSL_CTX to my X509 struct, or how to I do it
> > else?
> _______________________________________________
> 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/20150218/7471c8eb/attachment.html>

From stm at pdflib.com  Wed Feb 18 12:19:59 2015
From: stm at pdflib.com (=?UTF-8?B?U3RlcGhhbiBNw7xobHN0cmFzc2Vy?=)
Date: Wed, 18 Feb 2015 13:19:59 +0100
Subject: [openssl-users] Meaning of OCSP_NOEXPLICIT for OCSP_basic_verify()
Message-ID: <54E4836F.6010406@pdflib.com>

Hi,

I have a question about the behavior of OCSP_basic_verify() and the 
meaning of the OCSP_NOEXPLICIT flag. The OCSP_basic_verify() function is 
the only place where this flag has an effect in the whole OpenSSL 
source, and in the "openssl ocsp" application it can be set with the 
"-no_explicit" command line option:

/*
  * Easy case: explicitly trusted. Get root CA and check for explicit
  * trust
  */
if (flags & OCSP_NOEXPLICIT)
     goto end;

x = sk_X509_value(chain, sk_X509_num(chain) - 1);
if (X509_check_trust(x, NID_OCSP_sign, 0) != X509_TRUST_TRUSTED) {
     OCSPerr(OCSP_F_OCSP_BASIC_VERIFY, OCSP_R_ROOT_CA_NOT_TRUSTED);
     goto end;
}

Unfortunately the "-no_explicit" command line option is not documented:

https://www.openssl.org/docs/apps/ocsp.html

What is the meaning of setting the OCSP_NOEXPLICIT flag resp. using the 
"-no_explicit" command line option. What exactly is checked by the 
X509_check_trust() call above with respect to the relevant RFCs?

Best regards
Stephan

From mikec1404 at gmail.com  Wed Feb 18 16:03:31 2015
From: mikec1404 at gmail.com (Mike Collins)
Date: Wed, 18 Feb 2015 10:03:31 -0600
Subject: [openssl-users] 1.0.1 upgrade issue
Message-ID: <CABQOMta3sSANMVe58LwQ57kU=bPaQQ=o-_+_KBeoj+5MtTaifA@mail.gmail.com>

Thanks for the suggestions Jay but am still not having much luck.

Does 1.0.1 have any minimum requirements for the libc version or kernel
version? I am currently building against libc version 2.5 with the kernel
at 2.6.30.

Mike

---------- Forwarded message ----------
From: Jay Foster <jayf0ster at roadrunner.com>
To: openssl-users at openssl.org
Cc:
Date: Fri, 13 Feb 2015 08:48:12 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also on an
ARM926EJ linux based system.  I used the 'no-ssl2 no-ssl3 linux-armv4
shared' options (plus some others).  I found that it works with and without
the ARM assembly accelerations (no-asm option), even though the ARM926EJ is
an arm5te.  It works fine with lighttpd and passes the OpenSSL tests.  I
assume you are also using the appropriate '--cross-compile-prefix=<prefix>'
option.   You might try adding "-mlittle-endian -mcpu=arm926ej-s
-DL_ENDIAN" to the CFLAGS, although that should be redundant (the compiler
should already know this).  Also, make sure there are no '-nostdinc' (or
similar) type compiler options creeping in.  These change the search order
of header files, which can cause OpenSSL to be built against the (old)
headers in your tool chain, rather than it's local (current) headers.

I did discover that with 1.0.2, I also needed to add
'-DOPENSSL_USE_BUILD_DATE' to the CFLAGS to get the 'openssl version -a'
command to report a useful build date.

Jay


On 2/13/2015 7:29 AM, Mike Collins wrote:
 I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l due to
a requirement for TLS v1.1. Version 1.0.1 will cross compile without errors
using my 1.0.0 configuration but I have identified the following errors on
the board (so far) with the build using 1.0.1:
1.) Cannot create a RSA key
2.) Trying to connect to the board's Lighttpd web server via https will
timeout with PKCS #11 error
3.) Curl https POST calls fail with RSA padding error.

 Board has a ARM926EJ based processor and I am using a Codesourcery Lite
toolchain. Configure settings (besides --prefix, etc) are shared, no-asm,
linux-generic32, no-ssl2. All the other packages on the board have been
rebuilt against the new openssl version.

 I am looking at the key creation first since that may be causing the other
issues. If I try to create a key from the board command line using "openssl
genrsa -out testkey.pem 2048" I get a response of "Generating RSA private
key, 2048 bit long modulus". At this point it seems to get stuck in a loop;
I am seeing the progress indicators (".") but it will never finish creating
the key. I have let it run 10-15 minutes without completion; it just keeps
displaying successive progress indicators. I can do Ctrl-C and it will
exit.

 I don't think so but are there any dependency changes from 1.0.0 to 1.0.1?

 I noticed 1.0.2 has been released so tried that as well but have the same
result as 1.0.1

 Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150218/1abb1478/attachment.html>

From jayf0ster at roadrunner.com  Wed Feb 18 18:30:40 2015
From: jayf0ster at roadrunner.com (Jay Foster)
Date: Wed, 18 Feb 2015 10:30:40 -0800
Subject: [openssl-users] 1.0.1 upgrade issue
In-Reply-To: <CABQOMta3sSANMVe58LwQ57kU=bPaQQ=o-_+_KBeoj+5MtTaifA@mail.gmail.com>
References: <CABQOMta3sSANMVe58LwQ57kU=bPaQQ=o-_+_KBeoj+5MtTaifA@mail.gmail.com>
Message-ID: <54E4DA50.9060209@roadrunner.com>

I'm building against libc6 (glibc 2.9) and kernel 3.2.6.  Are you 
skipping the 'make depend' step?  My build script does, './Configure 
<args>', 'make depend', 'make'.

Jay

On 2/18/2015 8:03 AM, Mike Collins wrote:
> Thanks for the suggestions Jay but am still not having much luck.
>
> Does 1.0.1 have any minimum requirements for the libc version or 
> kernel version? I am currently building against libc version 2.5 with 
> the kernel at 2.6.30.
>
> Mike
>
> ---------- Forwarded message ----------
> From: Jay Foster <jayf0ster at roadrunner.com 
> <mailto:jayf0ster at roadrunner.com>>
> To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
> Cc:
> Date: Fri, 13 Feb 2015 08:48:12 -0800
> Subject: Re: [openssl-users] 1.0.1 upgrade issue
> I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also 
> on an ARM926EJ linux based system.  I used the 'no-ssl2 no-ssl3 
> linux-armv4 shared' options (plus some others).  I found that it works 
> with and without the ARM assembly accelerations (no-asm option), even 
> though the ARM926EJ is an arm5te.  It works fine with lighttpd and 
> passes the OpenSSL tests.  I assume you are also using the appropriate 
> '--cross-compile-prefix=<prefix>' option.   You might try adding 
> "-mlittle-endian -mcpu=arm926ej-s -DL_ENDIAN" to the CFLAGS, although 
> that should be redundant (the compiler should already know this).  
> Also, make sure there are no '-nostdinc' (or similar) type compiler 
> options creeping in.  These change the search order of header files, 
> which can cause OpenSSL to be built against the (old) headers in your 
> tool chain, rather than it's local (current) headers.
>
> I did discover that with 1.0.2, I also needed to add 
> '-DOPENSSL_USE_BUILD_DATE' to the CFLAGS to get the 'openssl version 
> -a' command to report a useful build date.
>
> Jay
>
>
> On 2/13/2015 7:29 AM, Mike Collins wrote:
> I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l due 
> to a requirement for TLS v1.1. Version 1.0.1 will cross compile 
> without errors using my 1.0.0 configuration but I have identified the 
> following errors on the board (so far) with the build using 1.0.1:
> 1.) Cannot create a RSA key
> 2.) Trying to connect to the board's Lighttpd web server via https 
> will timeout with PKCS #11 error
> 3.) Curl https POST calls fail with RSA padding error.
>
> Board has a ARM926EJ based processor and I am using a Codesourcery 
> Lite toolchain. Configure settings (besides --prefix, etc) are shared, 
> no-asm, linux-generic32, no-ssl2. All the other packages on the board 
> have been rebuilt against the new openssl version.
>
> I am looking at the key creation first since that may be causing the 
> other issues. If I try to create a key from the board command line 
> using "openssl genrsa -out testkey.pem 2048" I get a response of 
> "Generating RSA private key, 2048 bit long modulus". At this point it 
> seems to get stuck in a loop; I am seeing the progress indicators 
> (".") but it will never finish creating the key. I have let it run 
> 10-15 minutes without completion; it just keeps displaying successive 
> progress indicators. I can do Ctrl-C and it will exit.
>
> I don't think so but are there any dependency changes from 1.0.0 to 1.0.1?
>
> I noticed 1.0.2 has been released so tried that as well but have the 
> same result as 1.0.1
>
> Mike
>
>
> _______________________________________________
> 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/20150218/db062c2c/attachment-0001.html>

From openssl at lists.killian.com  Wed Feb 18 18:25:37 2015
From: openssl at lists.killian.com (openssl at lists.killian.com)
Date: Wed, 18 Feb 2015 10:25:37 -0800
Subject: [openssl-users] genpkey usage for openssl-1.0.1k on openSUSE-13.2
Message-ID: <20150218182537.A9261A574B@maple.killian.com>

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150218/6823b5c3/attachment.ksh>

From mikec1404 at gmail.com  Wed Feb 18 20:53:50 2015
From: mikec1404 at gmail.com (Mike Collins)
Date: Wed, 18 Feb 2015 14:53:50 -0600
Subject: [openssl-users] 1.0.1 upgrade issue
Message-ID: <CABQOMtaSG1k9EL5O_g9ekm10VohGehMUGyd+SYU7RMRL3x=n7g@mail.gmail.com>

Thanks Jay.

My build script is doing the same.

Not sure where to go next except to update libc to a newer version. Due to
the toolchain (not created by me) it may be a major undertaking.

Mike

From: Jay Foster <jayf0ster at roadrunner.com>
To: openssl-users at openssl.org
Cc:
Date: Wed, 18 Feb 2015 10:30:40 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I'm building against libc6 (glibc 2.9) and kernel 3.2.6.  Are you skipping
the 'make depend' step?  My build script does, './Configure <args>', 'make
depend', 'make'.

Jay

On 2/18/2015 8:03 AM, Mike Collins wrote:

Thanks for the suggestions Jay but am still not having much luck.

Does 1.0.1 have any minimum requirements for the libc version or kernel
version? I am currently building against libc version 2.5 with the kernel
at 2.6.30.

Mike

---------- Forwarded message ----------
From: Jay Foster <jayf0ster at roadrunner.com>
To: openssl-users at openssl.org
Cc:
Date: Fri, 13 Feb 2015 08:48:12 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also on an
ARM926EJ linux based system.  I used the 'no-ssl2 no-ssl3 linux-armv4
shared' options (plus some others).  I found that it works with and without
the ARM assembly accelerations (no-asm option), even though the ARM926EJ is
an arm5te.  It works fine with lighttpd and passes the OpenSSL tests.  I
assume you are also using the appropriate '--cross-compile-prefix=<prefix>'
option.   You might try adding "-mlittle-endian -mcpu=arm926ej-s
-DL_ENDIAN" to the CFLAGS, although that should be redundant (the compiler
should already know this).  Also, make sure there are no '-nostdinc' (or
similar) type compiler options creeping in.  These change the search order
of header files, which can cause OpenSSL to be built against the (old)
headers in your tool chain, rather than it's local (current) headers.

I did discover that with 1.0.2, I also needed to add
'-DOPENSSL_USE_BUILD_DATE' to the CFLAGS to get the 'openssl version -a'
command to report a useful build date.

Jay


On 2/13/2015 7:29 AM, Mike Collins wrote:

I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l due to a
requirement for TLS v1.1. Version 1.0.1 will cross compile without errors
using my 1.0.0 configuration but I have identified the following errors on
the board (so far) with the build using 1.0.1:
1.) Cannot create a RSA key
2.) Trying to connect to the board's Lighttpd web server via https will
timeout with PKCS #11 error
3.) Curl https POST calls fail with RSA padding error.

Board has a ARM926EJ based processor and I am using a Codesourcery Lite
toolchain. Configure settings (besides --prefix, etc) are shared, no-asm,
linux-generic32, no-ssl2. All the other packages on the board have been
rebuilt against the new openssl version.

I am looking at the key creation first since that may be causing the other
issues. If I try to create a key from the board command line using "openssl
genrsa -out testkey.pem 2048" I get a response of "Generating RSA private
key, 2048 bit long modulus". At this point it seems to get stuck in a loop;
I am seeing the progress indicators (".") but it will never finish creating
the key. I have let it run 10-15 minutes without completion; it just keeps
displaying successive progress indicators. I can do Ctrl-C and it will
exit.

I don't think so but are there any dependency changes from 1.0.0 to 1.0.1?

I noticed 1.0.2 has been released so tried that as well but have the same
result as 1.0.1

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150218/5f748c08/attachment.html>

From rsalz at akamai.com  Wed Feb 18 21:03:05 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 18 Feb 2015 21:03:05 +0000
Subject: [openssl-users] 1.0.1 upgrade issue
In-Reply-To: <CABQOMtaSG1k9EL5O_g9ekm10VohGehMUGyd+SYU7RMRL3x=n7g@mail.gmail.com>
References: <CABQOMtaSG1k9EL5O_g9ekm10VohGehMUGyd+SYU7RMRL3x=n7g@mail.gmail.com>
Message-ID: <4feeb19a06b940ef9e54f4a5a3a415b5@ustx2ex-dag1mb4.msg.corp.akamai.com>

Is there a chance you can interrupt and get a backtrace to see where it?s hanging?

--
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me<mailto:rsalz at jabber.me> Twitter: RichSalz

From: Mike Collins [mailto:mikec1404 at gmail.com]
Sent: Wednesday, February 18, 2015 3:54 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] 1.0.1 upgrade issue

Thanks Jay.

My build script is doing the same.

Not sure where to go next except to update libc to a newer version. Due to the toolchain (not created by me) it may be a major undertaking.

Mike

From: Jay Foster <jayf0ster at roadrunner.com<mailto:jayf0ster at roadrunner.com>>
To: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Cc:
Date: Wed, 18 Feb 2015 10:30:40 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I'm building against libc6 (glibc 2.9) and kernel 3.2.6.  Are you skipping the 'make depend' step?  My build script does, './Configure <args>', 'make depend', 'make'.

Jay

On 2/18/2015 8:03 AM, Mike Collins wrote:
Thanks for the suggestions Jay but am still not having much luck.
Does 1.0.1 have any minimum requirements for the libc version or kernel version? I am currently building against libc version 2.5 with the kernel at 2.6.30.
Mike

---------- Forwarded message ----------
From: Jay Foster <jayf0ster at roadrunner.com<mailto:jayf0ster at roadrunner.com>>
To: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Cc:
Date: Fri, 13 Feb 2015 08:48:12 -0800
Subject: Re: [openssl-users] 1.0.1 upgrade issue
I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also on an ARM926EJ linux based system.  I used the 'no-ssl2 no-ssl3 linux-armv4 shared' options (plus some others).  I found that it works with and without the ARM assembly accelerations (no-asm option), even though the ARM926EJ is an arm5te.  It works fine with lighttpd and passes the OpenSSL tests.  I assume you are also using the appropriate '--cross-compile-prefix=<prefix>' option.   You might try adding "-mlittle-endian -mcpu=arm926ej-s -DL_ENDIAN" to the CFLAGS, although that should be redundant (the compiler should already know this).  Also, make sure there are no '-nostdinc' (or similar) type compiler options creeping in.  These change the search order of header files, which can cause OpenSSL to be built against the (old) headers in your tool chain, rather than it's local (current) headers.

I did discover that with 1.0.2, I also needed to add '-DOPENSSL_USE_BUILD_DATE' to the CFLAGS to get the 'openssl version -a' command to report a useful build date.

Jay


On 2/13/2015 7:29 AM, Mike Collins wrote:
I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l due to a requirement for TLS v1.1. Version 1.0.1 will cross compile without errors using my 1.0.0 configuration but I have identified the following errors on the board (so far) with the build using 1.0.1:
1.) Cannot create a RSA key
2.) Trying to connect to the board's Lighttpd web server via https will timeout with PKCS #11 error
3.) Curl https POST calls fail with RSA padding error.

Board has a ARM926EJ based processor and I am using a Codesourcery Lite toolchain. Configure settings (besides --prefix, etc) are shared, no-asm, linux-generic32, no-ssl2. All the other packages on the board have been rebuilt against the new openssl version.

I am looking at the key creation first since that may be causing the other issues. If I try to create a key from the board command line using "openssl genrsa -out testkey.pem 2048" I get a response of "Generating RSA private key, 2048 bit long modulus". At this point it seems to get stuck in a loop; I am seeing the progress indicators (".") but it will never finish creating the key. I have let it run 10-15 minutes without completion; it just keeps displaying successive progress indicators. I can do Ctrl-C and it will exit.

I don't think so but are there any dependency changes from 1.0.0 to 1.0.1?

I noticed 1.0.2 has been released so tried that as well but have the same result as 1.0.1

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150218/04301a7d/attachment-0001.html>

From jayf0ster at roadrunner.com  Wed Feb 18 22:21:38 2015
From: jayf0ster at roadrunner.com (Jay Foster)
Date: Wed, 18 Feb 2015 14:21:38 -0800
Subject: [openssl-users] 1.0.1 upgrade issue
In-Reply-To: <CABQOMtaSG1k9EL5O_g9ekm10VohGehMUGyd+SYU7RMRL3x=n7g@mail.gmail.com>
References: <CABQOMtaSG1k9EL5O_g9ekm10VohGehMUGyd+SYU7RMRL3x=n7g@mail.gmail.com>
Message-ID: <54E51072.6060307@roadrunner.com>

I'm using gcc 4.3.3 for what it's worth.
Jay
On 2/18/2015 12:53 PM, Mike Collins wrote:
> Thanks Jay.
>
> My build script is doing the same.
>
> Not sure where to go next except to update libc to a newer version. 
> Due to the toolchain (not created by me) it may be a major undertaking.
>
> Mike
>
> From: Jay Foster <jayf0ster at roadrunner.com 
> <mailto:jayf0ster at roadrunner.com>>
> To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
> Cc:
> Date: Wed, 18 Feb 2015 10:30:40 -0800
> Subject: Re: [openssl-users] 1.0.1 upgrade issue
> I'm building against libc6 (glibc 2.9) and kernel 3.2.6. Are you 
> skipping the 'make depend' step?  My build script does, './Configure 
> <args>', 'make depend', 'make'.
>
> Jay
>
> On 2/18/2015 8:03 AM, Mike Collins wrote:
>> Thanks for the suggestions Jay but am still not having much luck.
>>
>> Does 1.0.1 have any minimum requirements for the libc version or 
>> kernel version? I am currently building against libc version 2.5 with 
>> the kernel at 2.6.30.
>>
>> Mike
>>
>> ---------- Forwarded message ----------
>> From: Jay Foster <jayf0ster at roadrunner.com 
>> <mailto:jayf0ster at roadrunner.com>>
>> To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>> Cc:
>> Date: Fri, 13 Feb 2015 08:48:12 -0800
>> Subject: Re: [openssl-users] 1.0.1 upgrade issue
>> I have successfully built OpenSSL 1.0.0..., 1.0.1..., and 1.0.2 also 
>> on an ARM926EJ linux based system.  I used the 'no-ssl2 no-ssl3 
>> linux-armv4 shared' options (plus some others).  I found that it 
>> works with and without the ARM assembly accelerations (no-asm 
>> option), even though the ARM926EJ is an arm5te.  It works fine with 
>> lighttpd and passes the OpenSSL tests.  I assume you are also using 
>> the appropriate '--cross-compile-prefix=<prefix>' option.   You might 
>> try adding "-mlittle-endian -mcpu=arm926ej-s -DL_ENDIAN" to the 
>> CFLAGS, although that should be redundant (the compiler should 
>> already know this).  Also, make sure there are no '-nostdinc' (or 
>> similar) type compiler options creeping in.  These change the search 
>> order of header files, which can cause OpenSSL to be built against 
>> the (old) headers in your tool chain, rather than it's local 
>> (current) headers.
>>
>> I did discover that with 1.0.2, I also needed to add 
>> '-DOPENSSL_USE_BUILD_DATE' to the CFLAGS to get the 'openssl version 
>> -a' command to report a useful build date.
>>
>> Jay
>>
>>
>> On 2/13/2015 7:29 AM, Mike Collins wrote:
>> I am upgrading an embedded linux board's BSP from 1.0.0m to 1.0.1l 
>> due to a requirement for TLS v1.1. Version 1.0.1 will cross compile 
>> without errors using my 1.0.0 configuration but I have identified the 
>> following errors on the board (so far) with the build using 1.0.1:
>> 1.) Cannot create a RSA key
>> 2.) Trying to connect to the board's Lighttpd web server via https 
>> will timeout with PKCS #11 error
>> 3.) Curl https POST calls fail with RSA padding error.
>>
>> Board has a ARM926EJ based processor and I am using a Codesourcery 
>> Lite toolchain. Configure settings (besides --prefix, etc) are 
>> shared, no-asm, linux-generic32, no-ssl2. All the other packages on 
>> the board have been rebuilt against the new openssl version.
>>
>> I am looking at the key creation first since that may be causing the 
>> other issues. If I try to create a key from the board command line 
>> using "openssl genrsa -out testkey.pem 2048" I get a response of 
>> "Generating RSA private key, 2048 bit long modulus". At this point it 
>> seems to get stuck in a loop; I am seeing the progress indicators 
>> (".") but it will never finish creating the key. I have let it run 
>> 10-15 minutes without completion; it just keeps displaying successive 
>> progress indicators. I can do Ctrl-C and it will exit.
>>
>> I don't think so but are there any dependency changes from 1.0.0 to 
>> 1.0.1?
>>
>> I noticed 1.0.2 has been released so tried that as well but have the 
>> same result as 1.0.1
>>
>> Mike
>
>
> _______________________________________________
> 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/20150218/fc42cf53/attachment.html>

From openssl-users at eldondev.com  Thu Feb 19 06:30:43 2015
From: openssl-users at eldondev.com (openssl-users at eldondev.com)
Date: Thu, 19 Feb 2015 01:30:43 -0500
Subject: [openssl-users] Illegal Instruction on AMD with avx without XOP
Message-ID: <20150219063043.GG27439@npcomp.ithought.org>

Hello,
I am running on openssl 1.0.2 and I am getting an "Illegal Instruction"
when attempting to download a certain file with wget. It also occurs
with curl. I have disassembled the code around the bug, and it appears
that I am reaching this line:
https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-sha256-x86_64.pl#L147

It may perhaps be due to the fact that I am using an AMD machine with
the AVX extensions [1], but without XOP or AVX2, which would not enter any
of the branches. I don't work in assembler often, so I may be way off
base here, if so please enlighten me. If more information would be
useful, or if I should attempt to create a bug in request tracker,
please just let me know.

Thanks very much,
Eldon

[1] http://en.wikipedia.org/wiki/List_of_AMD_accelerated_processing_unit_microprocessors#.22Kabini.22.2C_.22Temash.22_.282013.2C_28_nm.29

PS:
Other versions in the environment are:
Gentoo Linux kernel 3.19.0
wget 1.16.1

From dthompson at prinpay.com  Thu Feb 19 08:22:09 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Thu, 19 Feb 2015 03:22:09 -0500
Subject: [openssl-users] genpkey usage for openssl-1.0.1k on
	openSUSE-13.2
In-Reply-To: <20150218182537.A9261A574B@maple.killian.com>
References: <20150218182537.A9261A574B@maple.killian.com>
Message-ID: <001501d04c1d$29aef9c0$7d0ced40$@prinpay.com>

> From: openssl-users On Behalf Of openssl at lists.killian.com
> Sent: Wednesday, February 18, 2015 13:26

> I noticed that openssl(1) says that various things have been superseded by
> genpkey, so I tried changing my scripts to use it. It works fine for RSA,
but the
> man page is not very helpful on EC. I tried
> 
>     openssl genpkey -out key.new -algorithm EC -pkeyopt
> ec_paramgen_curve:secp384r1
> 
> and got
> 
>     parameter setting error
>     139638314907280:error:06089094:digital envelope
> routines:EVP_PKEY_CTX_ctrl:invalid operation:pmeth_lib.c:404:
<snip>

genpkey has a standard idea, across all algorithms that have parameters 
(which RSA does not), to generate parameters and key(s) as separate 
steps with a file in between. For DSA and DH this is good; you may want 
to generate your own params, or you may want to use existing ones 
(in an existing file) e.g. Oakley or SSH-non-GEX. For EC it makes less
sense, 
as generating your own curve is complicated (OpenSSL certainly doesn't do
it) 
and in practice everyone* uses the named curves. Nonetheless you still do:

openssl genpkey -genparam -algorithm EC -pkeyopt ec_paramgen_curve:x >pfile
openssl genpkey -paramfile pfile >keyfile 

Depending on your OS and shell you may be able to combine these like
openssl genpkey -genparam | openssl genpkey -paramfile /dev/fd/0
or openssl genpkey -paramfile <<<$(openssl genpkey -genparam)

* Well, everybody except the crowd around Dan Bernstein, and they use 
non-Weierstrauss curves that OpenSSL can't even represent (now?).



From jonetsu at teksavvy.com  Thu Feb 19 10:16:50 2015
From: jonetsu at teksavvy.com (jonetsu at teksavvy.com)
Date: Thu, 19 Feb 2015 05:16:50 -0500
Subject: [openssl-users] FIPS, continuous tests, and error reporting
Message-ID: <20150219051650.42c44274@mevla>

Hello,

I have some questions regarding table '6b - Conditional Tests' of the
2.0.7 Security Policy.

It is mentioned that there are continuous tests for stuck fault. Is
the meaning of 'continuous' a the matter of frequency ?  Or are these
continuous tests ran each time an algorithm is used ?

The document mentions: "In the event of a DRBG self-test failure the
calling application must..." - how is the result communicated to the
application ?

For that matter and in a general sense, so far I've seen that many
encryption methods do not return any error code.  How does error
reporting generally works ?

Regards.


From jonetsu at teksavvy.com  Thu Feb 19 10:19:37 2015
From: jonetsu at teksavvy.com (jonetsu at teksavvy.com)
Date: Thu, 19 Feb 2015 05:19:37 -0500
Subject: [openssl-users] OpenSSL FIPS mode system integration
Message-ID: <20150219051937.770a9da4@mevla>

Hello,

Could you please comment on the following ?  Any suggestion, insight,
hint, is greatly appreciated.

In FIPS mode, the OS, the device, must be aware of crypto errors, and
adopt a certain behaviour when one occurs.  Like shutting down all
data output interfaces.

This means that when using OpenSSL, a link must be made between
OpenSSL (or the application using it) and the OS, if only to signal
the OS of such errors.

I would like to modify the FIPS OpenSSL library in such a way that a
OS-specific action is taken when a FIPS error is detected.  That
action could be writing a file, writing a specific log msg, sending a
signal to an application, etc.  To continue in the same vein, are
there major exit points in the library that could reduce the amount of
modifications to be made ?  Is error information inh FIPS mode
traveling in the library in such a way that it could be examined and
acted upon at a precise point, covering all error conditions ?

Are these mainlines making sense, based on your experience with the
OpenSSL library ?

Another way would be to modify the applications that uses the OpenSSL
library. I tend to think that it would be more efficient and easier on
maintenance to modify the OpenSSL library.  But then, the complexity
of tapping on (every) exit point from the library could be
overwhelming, when compared to the source code of several
applications.

Any comment, suggestions welcomed.


From rsalz at akamai.com  Thu Feb 19 12:34:41 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 19 Feb 2015 12:34:41 +0000
Subject: [openssl-users] FIPS, continuous tests, and error reporting
In-Reply-To: <20150219051650.42c44274@mevla>
References: <20150219051650.42c44274@mevla>
Message-ID: <a7fff18520454c429e6302a4a5c067ad@ustx2ex-dag1mb4.msg.corp.akamai.com>


> For that matter and in a general sense, so far I've seen that many encryption
> methods do not return any error code.  How does error reporting generally
> works ?

Really?  Which ones?

From meissner at suse.de  Thu Feb 19 12:45:58 2015
From: meissner at suse.de (Marcus Meissner)
Date: Thu, 19 Feb 2015 13:45:58 +0100
Subject: [openssl-users] OpenSSL FIPS mode system integration
In-Reply-To: <20150219051937.770a9da4@mevla>
References: <20150219051937.770a9da4@mevla>
Message-ID: <20150219124558.GA9352@suse.de>

On Thu, Feb 19, 2015 at 05:19:37AM -0500, jonetsu at teksavvy.com wrote:
> Hello,
> 
> Could you please comment on the following ?  Any suggestion, insight,
> hint, is greatly appreciated.
> 
> In FIPS mode, the OS, the device, must be aware of crypto errors, and
> adopt a certain behaviour when one occurs.  Like shutting down all
> data output interfaces.
> 
> This means that when using OpenSSL, a link must be made between
> OpenSSL (or the application using it) and the OS, if only to signal
> the OS of such errors.
> 
> I would like to modify the FIPS OpenSSL library in such a way that a
> OS-specific action is taken when a FIPS error is detected.  That
> action could be writing a file, writing a specific log msg, sending a
> signal to an application, etc.  To continue in the same vein, are
> there major exit points in the library that could reduce the amount of
> modifications to be made ?  Is error information inh FIPS mode
> traveling in the library in such a way that it could be examined and
> acted upon at a precise point, covering all error conditions ?
> 
> Are these mainlines making sense, based on your experience with the
> OpenSSL library ?
> 
> Another way would be to modify the applications that uses the OpenSSL
> library. I tend to think that it would be more efficient and easier on
> maintenance to modify the OpenSSL library.  But then, the complexity
> of tapping on (every) exit point from the library could be
> overwhelming, when compared to the source code of several
> applications.

Well, the writing is that the "crypto module" must stop operating
on error.

We solved this by calling abort(); in the openssl library on FIPS
related error conditions.

Ciao, Marcus

From steve at openssl.org  Thu Feb 19 13:36:47 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 19 Feb 2015 13:36:47 +0000
Subject: [openssl-users] genpkey usage for openssl-1.0.1k on
	openSUSE-13.2
In-Reply-To: <001501d04c1d$29aef9c0$7d0ced40$@prinpay.com>
References: <20150218182537.A9261A574B@maple.killian.com>
 <001501d04c1d$29aef9c0$7d0ced40$@prinpay.com>
Message-ID: <20150219133647.GA16976@openssl.org>

On Thu, Feb 19, 2015, Dave Thompson wrote:

> > From: openssl-users On Behalf Of openssl at lists.killian.com
> > Sent: Wednesday, February 18, 2015 13:26
> 
> > I noticed that openssl(1) says that various things have been superseded by
> > genpkey, so I tried changing my scripts to use it. It works fine for RSA,
> but the
> > man page is not very helpful on EC. I tried
> > 
> >     openssl genpkey -out key.new -algorithm EC -pkeyopt
> > ec_paramgen_curve:secp384r1
> > 
> > and got
> > 
> >     parameter setting error
> >     139638314907280:error:06089094:digital envelope
> > routines:EVP_PKEY_CTX_ctrl:invalid operation:pmeth_lib.c:404:
> <snip>
> 
> genpkey has a standard idea, across all algorithms that have parameters 
> (which RSA does not), to generate parameters and key(s) as separate 
> steps with a file in between. For DSA and DH this is good; you may want 
> to generate your own params, or you may want to use existing ones 
> (in an existing file) e.g. Oakley or SSH-non-GEX. For EC it makes less
> sense, 
> as generating your own curve is complicated (OpenSSL certainly doesn't do
> it) 
> and in practice everyone* uses the named curves. Nonetheless you still do:
> 
> openssl genpkey -genparam -algorithm EC -pkeyopt ec_paramgen_curve:x >pfile
> openssl genpkey -paramfile pfile >keyfile 
> 
> Depending on your OS and shell you may be able to combine these like
> openssl genpkey -genparam | openssl genpkey -paramfile /dev/fd/0
> or openssl genpkey -paramfile <<<$(openssl genpkey -genparam)
> 

For OpenSSL 1.0.2 you can specify the parameters when a key is generated. So
the OPs command should work with 1.0.2.

It's also common to use the named curve form of encoding which isn't the
default in 1.0.x branches (for compatiblity reasons). So in 1.0.2 you can do:

  openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -pkeyopt \
  ec_param_enc:named_curve

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

From jonetsu at teksavvy.com  Thu Feb 19 14:33:41 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Thu, 19 Feb 2015 09:33:41 -0500
Subject: [openssl-users] FIPS, continuous tests, and error reporting
In-Reply-To: <a7fff18520454c429e6302a4a5c067ad@ustx2ex-dag1mb4.msg.corp.akamai.com>
References: <20150219051650.42c44274@mevla>
 <a7fff18520454c429e6302a4a5c067ad@ustx2ex-dag1mb4.msg.corp.akamai.com>
Message-ID: <6dfda3f88055237390364fcba1a3d92f@teksavvy.com>



-----Original Message----- 
> From: "Salz, Rich" <rsalz at akamai.com> 
> To: openssl-users at openssl.org 
> Date: 02/19/15 07:43 
> Subject: Re: [openssl-users] FIPS, continuous tests, and error reporting 
> 
> > For that matter and in a general sense, so far I've seen that many encryption
> > methods do not return any error code. ?How does error reporting generally
> > works ?
> 
> Really? ?Which ones?

For instance, any of the void DES_*_encrypt().? This cursory observation is also supported by a vendor application code such as:

?static void des_encrypt(char key1[8], char key2[8], char key3[8], char ivec[8],
???????????????? char *input, char *output, int len,
???????????????? int encrypt)
?{

?? [snip]

??? DES_set_key(&des_key1, &schedule1);
??? DES_set_key(&des_key2, &schedule2);
??? DES_set_key(&des_key3, &schedule3);
??? DES_ede3_cbc_encrypt((unsigned char *)input, (unsigned char *)output, len,
???????????????????????? &schedule1, &schedule2, &schedule3, &des_ivec,
???????????????????????? encrypt);
?}


This is basically why I'm wondering about how errors propagate in the OpenSSL library.





From marquess at openssl.com  Thu Feb 19 14:32:34 2015
From: marquess at openssl.com (Steve Marquess)
Date: Thu, 19 Feb 2015 09:32:34 -0500
Subject: [openssl-users] OpenSSL FIPS mode system integration
In-Reply-To: <20150219051937.770a9da4@mevla>
References: <20150219051937.770a9da4@mevla>
Message-ID: <54E5F402.4090700@openssl.com>

On 02/19/2015 05:19 AM, jonetsu at teksavvy.com wrote:
> ...This means that when using OpenSSL, a link must be made between
> OpenSSL (or the application using it) and the OS, if only to signal
> the OS of such errors.

Ummm, no. The FIPS module stops functioning (i.e. doesn't perform any
useful crypto operations) in the (highly unlikely) event of POST, KAT,
or continuous test errors.

Your application might as well curl up and die at that point (hint: look
at the error codes from the API calls, in particular FIPS_mode_set()),
but the module itself will fail without any intervention.

> ...
> I would like to modify the FIPS OpenSSL library ...

That's a non-starter right there: the instant you modify the FIPS
module, at all or for any reason, it instantly becomes "non validated".
Without the all-important "validated" status that code is worthless and
there is no reason to use it (unless you want to pay and wait for your
own custom validation of the modified code).

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From steve at openssl.org  Thu Feb 19 14:49:33 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 19 Feb 2015 14:49:33 +0000
Subject: [openssl-users] FIPS, continuous tests, and error reporting
In-Reply-To: <6dfda3f88055237390364fcba1a3d92f@teksavvy.com>
References: <20150219051650.42c44274@mevla>
 <a7fff18520454c429e6302a4a5c067ad@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <6dfda3f88055237390364fcba1a3d92f@teksavvy.com>
Message-ID: <20150219144933.GA21840@openssl.org>

On Thu, Feb 19, 2015, jonetsu wrote:

> 
> 
> -----Original Message----- 
> > From: "Salz, Rich" <rsalz at akamai.com> 
> > To: openssl-users at openssl.org 
> > Date: 02/19/15 07:43 
> > Subject: Re: [openssl-users] FIPS, continuous tests, and error reporting 
> > 
> > > For that matter and in a general sense, so far I've seen that many encryption
> > > methods do not return any error code. ?How does error reporting generally
> > > works ?
> > 
> > Really? ?Which ones?
> 
> For instance, any of the void DES_*_encrypt().? This cursory observation is also supported by a vendor application code such as:
> 

The low level cipher and digest APIs cannot be used in FIPS mode: you have to
use EVP.

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

From jonetsu at teksavvy.com  Thu Feb 19 14:57:56 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Thu, 19 Feb 2015 09:57:56 -0500
Subject: [openssl-users] OpenSSL FIPS mode system integration
In-Reply-To: <20150219124558.GA9352@suse.de>
References: <20150219051937.770a9da4@mevla>
	<20150219124558.GA9352@suse.de>
Message-ID: <c6dc30a56e89a6641ed357f3c220d50f@teksavvy.com>



-----Original Message----- 
> From: "Marcus Meissner" <meissner at suse.de> 
> To: openssl-users at openssl.org 
> Date: 02/19/15 08:07 
> Subject: Re: [openssl-users] OpenSSL FIPS mode system integration 

> Well, the writing is that the "crypto module" must stop operating
> on error.
?
> We solved this by calling abort(); in the openssl library on FIPS
> related error conditions.

Hmmmm... What I have written from a consultancy compliance report is that all crypto operations must stop and, all data output of the designed Data Output interface(s) must also stop.? Hence my concern for the OS knowing about FIPS crypto test results.? Thanks for your comment.





From hgb at ifi.uio.no  Thu Feb 19 15:50:33 2015
From: hgb at ifi.uio.no (Henrik Grindal Bakken)
Date: Thu, 19 Feb 2015 16:50:33 +0100
Subject: [openssl-users] OpenSSL FIPS mode system integration
References: <20150219051937.770a9da4@mevla>
Message-ID: <x2emw49aoja.fsf@vetur.ifi.uio.no>

"jonetsu at teksavvy.com"
<jonetsu at teksavvy.com> writes:

> Hello,
>
> Could you please comment on the following ?  Any suggestion, insight,
> hint, is greatly appreciated.
>
> In FIPS mode, the OS, the device, must be aware of crypto errors, and
> adopt a certain behaviour when one occurs.  Like shutting down all
> data output interfaces.
>
> This means that when using OpenSSL, a link must be made between
> OpenSSL (or the application using it) and the OS, if only to signal
> the OS of such errors.

I'm not sure it will be called on every conceivable error in the FIPS
module, but what I do in similar situations is something like this:

static int post_cb(int op, int id, int subid, void *ex)
{
    if (op == FIPS_POST_FAIL)
        system("/bin/fipserror");
    return 1;
}

And there somewhere:

FIPS_post_set_callback(post_cb);

-- 
Henrik Grindal Bakken <hgb at ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52


From openssl at lists.killian.com  Thu Feb 19 15:56:54 2015
From: openssl at lists.killian.com (Earl Killian)
Date: Thu, 19 Feb 2015 07:56:54 -0800
Subject: [openssl-users] Separate signing and encryption certificates for
	Thunderbird
Message-ID: <54E607C6.2070003@lists.killian.com>

I wanted to switch to having separate signing and encryption 
certificates. I followed the outline at Stefan Holek's excellent
http://pki-tutorial.readthedocs.org/en/latest/expert/index.html
That is the signing cert request used

    keyUsage                = critical,digitalSignature
    extendedKeyUsage        = emailProtection,clientAuth
    subjectKeyIdentifier    = hash
    subjectAltName          = email:move

And the encryption cert request used

    keyUsage                = critical,keyEncipherment
    extendedKeyUsage        = emailProtection
    subjectKeyIdentifier    = hash
    subjectAltName          = email:move

The generated csrs were signed by my own CA using the following -extensions

    keyUsage                = critical,digitalSignature
    basicConstraints        = CA:false
    extendedKeyUsage        = emailProtection,clientAuth,msSmartcardLogin
    subjectKeyIdentifier    = hash
    authorityKeyIdentifier  = keyid:always
    authorityInfoAccess     = @issuer_info
    crlDistributionPoints   = @crl_info

and

    keyUsage                = critical,keyEncipherment
    basicConstraints        = CA:false
    extendedKeyUsage        = emailProtection,msEFS
    subjectKeyIdentifier    = hash
    authorityKeyIdentifier  = keyid:always
    authorityInfoAccess     = @issuer_info
    crlDistributionPoints   = @crl_info

respectively, resulting in certificate serials 0x19, and 0x0D. This was 
done with openssl-1.0.1k on openSUSE 13.2.

I imported the CA cert into Thunderbird under "Authorities" and set it 
to be trusted, and imported 0x19 and 0x0D into Thunderbird under "Your 
Certificates". I then went to Account Settings > Security, and clicked 
on "Select" button for the Digital Signing box. It offers me a choice of 
0x19 or my old combined sign/encrypt cert. I pick 0x19. It asks me 
whether I want to use it for encryption too, and I said no. I then 
clicked on the "Select" for the Encryption box. It offered me the same 
two certs as choices: 0x19 or my old combined cert. It did not offer 0x0D.

So the question is what does the above recipe fail to do to make an 
encryption cert that Thunderbird would recognize and offer as a choice?

The CN and SAN of the two certs are identical (my name and my email 
address respectively). Is that a problem? How do others create separate 
signing and encryption certs?

I don't want to delete my old combined cert, since then I would not be 
able to read old S/MIME messages to me.

Suggestions and comments welcome.

-Earl

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

From rsalz at akamai.com  Thu Feb 19 16:09:47 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 19 Feb 2015 16:09:47 +0000
Subject: [openssl-users] FIPS, continuous tests, and error reporting
In-Reply-To: <6dfda3f88055237390364fcba1a3d92f@teksavvy.com>
References: <20150219051650.42c44274@mevla>
 <a7fff18520454c429e6302a4a5c067ad@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <6dfda3f88055237390364fcba1a3d92f@teksavvy.com>
Message-ID: <72eb522526374046a7311937cb99e9d9@ustx2ex-dag1mb4.msg.corp.akamai.com>

> For instance, any of the void DES_*_encrypt().? This cursory observation is
> also supported by a vendor application code such as:

Ah, okay.  Those functions are 'just math'  They depend on no external state.  They can't fail.  It's shifts and masking, etc.

> This is basically why I'm wondering about how errors propagate in the
> OpenSSL library.

Functions that can fail return a status.  Those that are just math are often void. There's an "error stack" where functions can put more detailed status, and it propagates; see ERR_get_error, ERR_clear_error, etc., for details.  


From openssl at lists.killian.com  Thu Feb 19 17:25:35 2015
From: openssl at lists.killian.com (Earl Killian)
Date: Thu, 19 Feb 2015 09:25:35 -0800
Subject: [openssl-users] genpkey usage for openssl-1.0.1k on
	openSUSE-13.2
In-Reply-To: <001501d04c1d$29aef9c0$7d0ced40$@prinpay.com>
References: <20150218182537.A9261A574B@maple.killian.com>
 <001501d04c1d$29aef9c0$7d0ced40$@prinpay.com>
Message-ID: <54E61C8F.4070501@lists.killian.com>

On 2015/2/19 00:22, Dave Thompson wrote:
> genpkey has a standard idea, across all algorithms that have parameters
> (which RSA does not), to generate parameters and key(s) as separate
> steps with a file in between. For DSA and DH this is good; you may want
> to generate your own params, or you may want to use existing ones
> (in an existing file) e.g. Oakley or SSH-non-GEX. For EC it makes less
> sense,
> as generating your own curve is complicated (OpenSSL certainly doesn't do
> it)
> and in practice everyone* uses the named curves. Nonetheless you still do:
>
> openssl genpkey -genparam -algorithm EC -pkeyopt ec_paramgen_curve:x >pfile
> openssl genpkey -paramfile pfile >keyfile
Thank you, this is clear now. It might be worth adding an example to the 
man page to prevent others from being similarly confused.


From marquess at openssl.com  Thu Feb 19 19:34:38 2015
From: marquess at openssl.com (Steve Marquess)
Date: Thu, 19 Feb 2015 14:34:38 -0500
Subject: [openssl-users] FIPS, continuous tests, and error reporting
In-Reply-To: <72eb522526374046a7311937cb99e9d9@ustx2ex-dag1mb4.msg.corp.akamai.com>
References: <20150219051650.42c44274@mevla>
 <a7fff18520454c429e6302a4a5c067ad@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <6dfda3f88055237390364fcba1a3d92f@teksavvy.com>
 <72eb522526374046a7311937cb99e9d9@ustx2ex-dag1mb4.msg.corp.akamai.com>
Message-ID: <54E63ACE.6010501@openssl.com>

On 02/19/2015 11:09 AM, Salz, Rich wrote:
>> For instance, any of the void DES_*_encrypt().  This cursory observation is
>> also supported by a vendor application code such as:
> 
> Ah, okay.  Those functions are 'just math'  They depend on no external state.  They can't fail.  It's shifts and masking, etc.

Which incidentally is true also of most of the FIPS 140-2 required KATs;
they are tautological in the sense that they only way they can possibly
fail is if the math is wrong, i.e. 1+1 != 2.

Apparently in the dim mists of time from whence the basic FIPS 140-2
requirements originated, when cryptography was done with mechanical
devices and dedicated discrete component electronics, such failures were
a serious concern. So to this day in a FIPS module the POST does the
equivalent of diligently confirming that 1+1=2, many times over.

If one of those tautological tests *does* fail, then you have worse
problems than a non-functioning FIPS module.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From jonetsu at teksavvy.com  Thu Feb 19 20:12:22 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Thu, 19 Feb 2015 15:12:22 -0500
Subject: [openssl-users] FIPS, continuous tests, and error reporting
In-Reply-To: <20150219144933.GA21840@openssl.org>
References: <20150219051650.42c44274@mevla>
 <a7fff18520454c429e6302a4a5c067ad@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <6dfda3f88055237390364fcba1a3d92f@teksavvy.com>
 <20150219144933.GA21840@openssl.org>
Message-ID: <3f1f807def1616ffbe85d940fae40939@teksavvy.com>



> From: "Dr. Stephen Henson" <steve at openssl.org> 
> To: openssl-users at openssl.org 
> Date: 02/19/15 11:34 
> Subject: Re: [openssl-users] FIPS, continuous tests, and error reporting 
?
> The low level cipher and digest APIs cannot be used in FIPS mode: you have to
> use EVP.

That's quite an important point.? It brings a question: how are the 'continuous' FIPS tests performed ?? Are they automatically called at the beginning of an EVP_* method ?? Do they run periodically in the background ?? Both ?

Regards.



From dj at deadhat.com  Thu Feb 19 21:22:19 2015
From: dj at deadhat.com (dj at deadhat.com)
Date: Thu, 19 Feb 2015 21:22:19 -0000
Subject: [openssl-users] FIPS, continuous tests, and error reporting
In-Reply-To: <20150219051650.42c44274@mevla>
References: <20150219051650.42c44274@mevla>
Message-ID: <9bd4d2daec31c3db146e798ea8f7ec23.squirrel@www.deadhat.com>

> Hello,
>
> I have some questions regarding table '6b - Conditional Tests' of the
> 2.0.7 Security Policy.
>
> It is mentioned that there are continuous tests for stuck fault. Is
> the meaning of 'continuous' a the matter of frequency ?  Or are these
> continuous tests ran each time an algorithm is used ?
>

The CRNGT test is described in section 4.9.2 of FIPS 140-2. It is
continuous in that it is applied to all the output of the RNG. The spec is
absolutely not clear on what you do with a failure, nor is it an effective
stuck at fault test. It is not present in the ISO equivalent spec, nor was
it present in the drafts of the (now defunct) 140-3 draft. It is a data
modifying test and has interest mathematical properties that raise
concerns that it is something other than a stuck-at test.





From frans at fransdb.nl  Fri Feb 20 10:42:35 2015
From: frans at fransdb.nl (Frans de Boer)
Date: Fri, 20 Feb 2015 11:42:35 +0100
Subject: [openssl-users] Grub troubles
Message-ID: <54E70F9B.8070604@fransdb.nl>

Hi,

I have a server running 12.3 and want to install on a different 
partition the newer 13.2 distribution. Alas, after installation I can't 
boot 12.3 anymore because of wrong references. Every time I install a 
fresh kernel I have to manually edit the grub.cfg files to get 12.3 
booted again.

I also want to install a third system (LFS) without having to manually 
edit grub.cfg every time.
So, is it possible to install the GRUB core image in a different 
partition and have the kernels be placed in the /boot directory of their 
respective partitions? Using this method I just need to chain to the 
relevant partition to start the local GRUB menu handler.

- Between MBR and first partition: GRUB bootloader.
- First partition: GRUB core and simple menu.
- Second partition contains swap space
- partitions 3..n Contain GRUB menu handlers and local linux kernels in 
local /boot dir.

I need local GRUB handlers because of preserving the kernel version as 
supported by openSuse and newer standard kernels with better or newer 
support modules.

Reading the GRUB 2.00 manual is not so helpful - to me - because of lack 
of unambiguous explanations or examples.

Any suggestions?

Regards, Frans.

From matt at openssl.org  Fri Feb 20 10:59:27 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 20 Feb 2015 10:59:27 +0000
Subject: [openssl-users] Grub troubles
In-Reply-To: <54E70F9B.8070604@fransdb.nl>
References: <54E70F9B.8070604@fransdb.nl>
Message-ID: <54E7138F.1070301@openssl.org>



On 20/02/15 10:42, Frans de Boer wrote:
> Any suggestions?

Perhaps asking on an opensuse forum might get you a better response?
This is openssl!! :-)

Matt


From frans at fransdb.nl  Fri Feb 20 11:03:08 2015
From: frans at fransdb.nl (Frans de Boer)
Date: Fri, 20 Feb 2015 12:03:08 +0100
Subject: [openssl-users] Grub troubles CANCEL
In-Reply-To: <54E70F9B.8070604@fransdb.nl>
References: <54E70F9B.8070604@fransdb.nl>
Message-ID: <54E7146C.5050703@fransdb.nl>

On 02/20/2015 11:42 AM, Frans de Boer wrote:
> Hi,
>
> I have a server running 12.3 and want to install on a different
> partition the newer 13.2 distribution. Alas, after installation I can't
> boot 12.3 anymore because of wrong references. Every time I install a
> fresh kernel I have to manually edit the grub.cfg files to get 12.3
> booted again.
>
> I also want to install a third system (LFS) without having to manually
> edit grub.cfg every time.
> So, is it possible to install the GRUB core image in a different
> partition and have the kernels be placed in the /boot directory of their
> respective partitions? Using this method I just need to chain to the
> relevant partition to start the local GRUB menu handler.
>
> - Between MBR and first partition: GRUB bootloader.
> - First partition: GRUB core and simple menu.
> - Second partition contains swap space
> - partitions 3..n Contain GRUB menu handlers and local linux kernels in
> local /boot dir.
>
> I need local GRUB handlers because of preserving the kernel version as
> supported by openSuse and newer standard kernels with better or newer
> support modules.
>
> Reading the GRUB 2.00 manual is not so helpful - to me - because of lack
> of unambiguous explanations or examples.
>
> Any suggestions?
>
> Regards, Frans.
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Sorry wrong list posting

From jonetsu at teksavvy.com  Fri Feb 20 14:06:42 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Fri, 20 Feb 2015 07:06:42 -0700 (MST)
Subject: [openssl-users] OpenSSL FIPS mode system integration
In-Reply-To: <x2emw49aoja.fsf@vetur.ifi.uio.no>
References: <20150219051937.770a9da4@mevla> <x2emw49aoja.fsf@vetur.ifi.uio.no>
Message-ID: <1424441202738-56586.post@n7.nabble.com>

On Feb 19, 2015 10:50am Henrik Grindal Bakken wrote:

> I'm not sure it will be called on every conceivable error in
> the FIPS module, but what I do in similar situations is
> something like this:

> static int post_cb(int op, int id, int subid, void *ex)
> {
>     if (op == FIPS_POST_FAIL)
>         system("/bin/fipserror");
>     return 1;
> }

> And there somewhere:

> FIPS_post_set_callback(post_cb)

This is very interesting, thanks.  Following this hint, in the same vein the
FIPS code also has:

FIPS_drbg_set_callbacks(<args>)

Although this one looks more like an entropy callback than
anythong that could be used to know about status.

The FIPS User Guide mentions both, although the information on
FIPS_post_set_callback() is not much at all.  Is there another
source than the User Guide 2.0, for detailed descriptions of
these FIPS-related methods ?  For isnatnce, the 'op' variable of 
FIPS_post_set_callback() is not described at all.  Any manual or 
info pages ?  Could be other potentially interesting methods in there. 





--
View this message in context: http://openssl.6102.n7.nabble.com/openssl-users-OpenSSL-FIPS-mode-system-integration-tp56563p56586.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From steve at openssl.org  Fri Feb 20 14:55:27 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 20 Feb 2015 14:55:27 +0000
Subject: [openssl-users] OpenSSL FIPS mode system integration
In-Reply-To: <1424441202738-56586.post@n7.nabble.com>
References: <20150219051937.770a9da4@mevla> <x2emw49aoja.fsf@vetur.ifi.uio.no>
 <1424441202738-56586.post@n7.nabble.com>
Message-ID: <20150220145527.GA9508@openssl.org>

On Fri, Feb 20, 2015, jonetsu wrote:

> On Feb 19, 2015 10:50am Henrik Grindal Bakken wrote:
> 
> > I'm not sure it will be called on every conceivable error in
> > the FIPS module, but what I do in similar situations is
> > something like this:
> 
> > static int post_cb(int op, int id, int subid, void *ex)
> > {
> >     if (op == FIPS_POST_FAIL)
> >         system("/bin/fipserror");
> >     return 1;
> > }
> 
> > And there somewhere:
> 
> > FIPS_post_set_callback(post_cb)
> 
> This is very interesting, thanks.  Following this hint, in the same vein the
> FIPS code also has:
> 
> FIPS_drbg_set_callbacks(<args>)
> 
> Although this one looks more like an entropy callback than
> anythong that could be used to know about status.
> 
> The FIPS User Guide mentions both, although the information on
> FIPS_post_set_callback() is not much at all.  Is there another
> source than the User Guide 2.0, for detailed descriptions of
> these FIPS-related methods ?  For isnatnce, the 'op' variable of 
> FIPS_post_set_callback() is not described at all.  Any manual or 
> info pages ?  Could be other potentially interesting methods in there. 
> 

The main prupose of FIPS_post_set_callback() was to show how the 
self tests were progressing to the labs and how it behaves correctly
when failure is induced in each self test.

This is demonstrated by fips_test_suite which has an example of a POST
callback.

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

From foleyj at cisco.com  Fri Feb 20 15:52:29 2015
From: foleyj at cisco.com (John Foley)
Date: Fri, 20 Feb 2015 10:52:29 -0500
Subject: [openssl-users] Blank pages in FIPS 2.0 user guide
Message-ID: <54E7583D.8050908@cisco.com>

Appendix E.2 in the FIPS 2.0 users guide
(https://www.openssl.org/docs/fips/UserGuide-2.0.pdf) contains blank
pages on pages 134-136.  Is this intentional?  It appears the iOS build
instructions starting on page 133 are incomplete. 
 


From npmccallum at redhat.com  Fri Feb 20 16:13:37 2015
From: npmccallum at redhat.com (Nathaniel McCallum)
Date: Fri, 20 Feb 2015 11:13:37 -0500
Subject: [openssl-users] Max size on ASN1_item_d2i_bio()?
Message-ID: <1424448817.2532.3.camel@redhat.com>

I'd like to use ASN1_item_d2i_bio() (or something similar) to parse an 
incoming message. However, given that types like ASN1_OCTET_STRING 
have (essentially) unbounded length, how do I prevent an attacker from 
DOS'ing via OOM?

Is there some way to set a max packet size?

Nathaniel

From npmccallum at redhat.com  Fri Feb 20 16:13:37 2015
From: npmccallum at redhat.com (Nathaniel McCallum)
Date: Fri, 20 Feb 2015 11:13:37 -0500
Subject: [openssl-users] Max size on ASN1_item_d2i_bio()?
Message-ID: <1424448817.2532.3.camel@redhat.com>

I'd like to use ASN1_item_d2i_bio() (or something similar) to parse an 
incoming message. However, given that types like ASN1_OCTET_STRING 
have (essentially) unbounded length, how do I prevent an attacker from 
DOS'ing via OOM?

Is there some way to set a max packet size?

Nathaniel

From marquess at openssl.com  Fri Feb 20 17:30:24 2015
From: marquess at openssl.com (Steve Marquess)
Date: Fri, 20 Feb 2015 12:30:24 -0500
Subject: [openssl-users] Blank pages in FIPS 2.0 user guide
In-Reply-To: <54E7583D.8050908@cisco.com>
References: <54E7583D.8050908@cisco.com>
Message-ID: <54E76F30.8060103@openssl.com>

On 02/20/2015 10:52 AM, John Foley wrote:
> Appendix E.2 in the FIPS 2.0 users guide
> (https://www.openssl.org/docs/fips/UserGuide-2.0.pdf) contains blank
> pages on pages 134-136.  Is this intentional?  It appears the iOS build
> instructions starting on page 133 are incomplete. 

John, I can tell you without looking that there are no intentionally
blank pages in the FIPS User Guide.

I am seriously remiss in updating that document. Among other things the
build process for iOS has changed significantly as of 2.0.9, thanks to
some elegant work by Andy Polyakov.

It's on my list... a long list unfortunately. At the moment any spare
time I have available for FIPS issues is spent addressing yet another
existential threat to the open source based validations.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From foleyj at cisco.com  Fri Feb 20 18:07:52 2015
From: foleyj at cisco.com (John Foley)
Date: Fri, 20 Feb 2015 13:07:52 -0500
Subject: [openssl-users] Blank pages in FIPS 2.0 user guide
In-Reply-To: <54E76F30.8060103@openssl.com>
References: <54E7583D.8050908@cisco.com> <54E76F30.8060103@openssl.com>
Message-ID: <54E777F8.3000808@cisco.com>

Are the current iOS build instructions documented anywhere else?  We
haven't built for iOS in several years, at which time xCode was still
using gcc.  It appears xCode now uses clang and the signature embedding
no longer works.  Looking at the following commit...

https://github.com/openssl/openssl/commit/7447e65fccc95fa2ee97b40e43dc46f97e7b958b

It appears OpenSSL may support the newer clang tool chain.  But the old
build steps we use to follow no longer embed the signature properly. 
Can anyone comment if the following steps are current:

https://github.com/GotoHack/iOS-openSSL-FIPS




On 02/20/2015 12:30 PM, Steve Marquess wrote:
> On 02/20/2015 10:52 AM, John Foley wrote:
>> Appendix E.2 in the FIPS 2.0 users guide
>> (https://www.openssl.org/docs/fips/UserGuide-2.0.pdf) contains blank
>> pages on pages 134-136.  Is this intentional?  It appears the iOS build
>> instructions starting on page 133 are incomplete. 
> John, I can tell you without looking that there are no intentionally
> blank pages in the FIPS User Guide.
>
> I am seriously remiss in updating that document. Among other things the
> build process for iOS has changed significantly as of 2.0.9, thanks to
> some elegant work by Andy Polyakov.
>
> It's on my list... a long list unfortunately. At the moment any spare
> time I have available for FIPS issues is spent addressing yet another
> existential threat to the open source based validations.
>
> -Steve M.
>



From jakub.openssl at gmail.com  Fri Feb 20 20:34:44 2015
From: jakub.openssl at gmail.com (Jakub Zelenka)
Date: Fri, 20 Feb 2015 20:34:44 +0000
Subject: [openssl-users] AES-GCM failing from Command Line Interface
In-Reply-To: <F4A26374-8F40-4E9A-A71F-5ED18F2E3E97@gmail.com>
References: <F6BC0BA9-2194-4772-9DA5-1DFB348D7F6F@gmail.com>
 <20150210022330.GA15638@openssl.org>
 <FCF226D1-49CA-41B4-8703-F0C3F68E335A@gmail.com>
 <54DA13DC.8050305@openssl.org>
 <F4A26374-8F40-4E9A-A71F-5ED18F2E3E97@gmail.com>
Message-ID: <CAPdL4PPZHEJ0XWP4kXSYFHBg+x=Z=E3JcmdLx-A7oCzamaFnqA@mail.gmail.com>

Hi,

On Tue, Feb 10, 2015 at 3:31 PM, Sec_Aficionado <secaficionado at gmail.com>
wrote:

> Matt,
>
> Thanks for keeping me honest! I see it now, but I totally missed it
> before. I must have just played with the cli and not read the full page.
>
> Can you please confirm that EVP is the way to go? I'll create my own
> little PHP extension since I only need a very specific action.
>
>
I'm probably a bit late with the reply... If you haven't implemented
already, this might help you: https://github.com/bukka/php-crypto . However
the api is still unstable (it means that there will be changes in the
future). I have frozen the development for some time but will soon resume
it as I will be finally able add compat layer for PHP 7 that is almost
stable.

Cheers

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

From steve at openssl.org  Fri Feb 20 22:24:08 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 20 Feb 2015 22:24:08 +0000
Subject: [openssl-users] Max size on ASN1_item_d2i_bio()?
In-Reply-To: <1424448817.2532.3.camel@redhat.com>
References: <1424448817.2532.3.camel@redhat.com>
Message-ID: <20150220222408.GA22847@openssl.org>

On Fri, Feb 20, 2015, Nathaniel McCallum wrote:

> I'd like to use ASN1_item_d2i_bio() (or something similar) to parse an 
> incoming message. However, given that types like ASN1_OCTET_STRING 
> have (essentially) unbounded length, how do I prevent an attacker from 
> DOS'ing via OOM?
> 
> Is there some way to set a max packet size?
> 

No there isn't but if the input is in DER form you can peek the first few
bytes and get the tag+length fields to determine the size of the structure. If
the input uses indefinite length encoding that isn't possible however.

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

From secaficionado at gmail.com  Sat Feb 21 07:50:50 2015
From: secaficionado at gmail.com (Sec_Aficionado)
Date: Sat, 21 Feb 2015 02:50:50 -0500
Subject: [openssl-users] AES-GCM failing from Command Line Interface
In-Reply-To: <CAPdL4PPZHEJ0XWP4kXSYFHBg+x=Z=E3JcmdLx-A7oCzamaFnqA@mail.gmail.com>
References: <F6BC0BA9-2194-4772-9DA5-1DFB348D7F6F@gmail.com>
 <20150210022330.GA15638@openssl.org>
 <FCF226D1-49CA-41B4-8703-F0C3F68E335A@gmail.com>
 <54DA13DC.8050305@openssl.org>
 <F4A26374-8F40-4E9A-A71F-5ED18F2E3E97@gmail.com>
 <CAPdL4PPZHEJ0XWP4kXSYFHBg+x=Z=E3JcmdLx-A7oCzamaFnqA@mail.gmail.com>
Message-ID: <D1441F55-7251-43DC-99A3-6688BE349308@gmail.com>

Hi Jakub,

I have my custom solution in place and it works well, but I'm always willing to learn other ways to solve the problem.

I'll take a look this coming week. Thanks!

Sent from my mobile

> On Feb 20, 2015, at 3:34 PM, Jakub Zelenka <jakub.openssl at gmail.com> wrote:
> 
> Hi,
> 
>> On Tue, Feb 10, 2015 at 3:31 PM, Sec_Aficionado <secaficionado at gmail.com> wrote:
>> Matt,
>> 
>> Thanks for keeping me honest! I see it now, but I totally missed it before. I must have just played with the cli and not read the full page.
>> 
>> Can you please confirm that EVP is the way to go? I'll create my own little PHP extension since I only need a very specific action.
> 
> I'm probably a bit late with the reply... If you haven't implemented already, this might help you: https://github.com/bukka/php-crypto . However the api is still unstable (it means that there will be changes in the future). I have frozen the development for some time but will soon resume it as I will be finally able add compat layer for PHP 7 that is almost stable.
> 
> Cheers
> 
> Jakub
> _______________________________________________
> 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/20150221/2e7f8426/attachment-0001.html>

From rasjv at yandex.com  Sat Feb 21 10:58:35 2015
From: rasjv at yandex.com (Serj Rakitov)
Date: Sat, 21 Feb 2015 13:58:35 +0300
Subject: [openssl-users] SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE
Message-ID: <2185001424516315@web24h.yandex.ru>

Hello.

I set socket to non-blocking mode.

1. If I do SSL_read() and get result <=0 and then SSL_get_error() returns SSL_ERROR_WANT_WRITE what must I to do?
Is it enough to call SSL_write(ssl,0,0) one time and then again call SSL_read() untill it successed. Is this right?


2.  If I do SSL_write() and get result <=0 and then SSL_get_error() returns SSL_ERROR_WANT_READ what must I to do?
If I must read some data can it be application data or no? So, if I call SSL_read(ssl,buf,buf_size) must I waiting in buf some application data or never?
And after I did SSL_read(ssl,buf,buf_size) then I must again call SSL_write() untill it returns with success?


3. Can be this situation: SSL_write() returns <=0 and then SSL_get_error() returns SSL_ERROR_WANT_WRITE?
What to do in this case for non-blocking socket?


--
Best Regards,

Serj Rakitov

From minfrin at sharp.fm  Sat Feb 21 11:21:59 2015
From: minfrin at sharp.fm (Graham Leggett)
Date: Sat, 21 Feb 2015 13:21:59 +0200
Subject: [openssl-users] SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE
In-Reply-To: <2185001424516315@web24h.yandex.ru>
References: <2185001424516315@web24h.yandex.ru>
Message-ID: <9DBCE555-B4A6-44C9-B52D-523ED3195209@sharp.fm>

On 21 Feb 2015, at 12:58 PM, Serj Rakitov <rasjv at yandex.com> wrote:

> I set socket to non-blocking mode.
> 
> 1. If I do SSL_read() and get result <=0 and then SSL_get_error() returns SSL_ERROR_WANT_WRITE what must I to do?
> Is it enough to call SSL_write(ssl,0,0) one time and then again call SSL_read() untill it successed. Is this right?
> 
> 
> 2.  If I do SSL_write() and get result <=0 and then SSL_get_error() returns SSL_ERROR_WANT_READ what must I to do?
> If I must read some data can it be application data or no? So, if I call SSL_read(ssl,buf,buf_size) must I waiting in buf some application data or never?
> And after I did SSL_read(ssl,buf,buf_size) then I must again call SSL_write() untill it returns with success?
> 
> 
> 3. Can be this situation: SSL_write() returns <=0 and then SSL_get_error() returns SSL_ERROR_WANT_WRITE?
> What to do in this case for non-blocking socket?

In both cases you return back to your poll and ask the OS to wait for the event that openssl asked for. If openssl asked for read, you poll until the socket is readable. If openssl asked for a write, you poll until the socket is writable.

When you get the event you asked for, you just run whatever you were running again. For example, if you were running SSL_read, run SSL_read again. If you were running SSL_write, run SSL write again.

So to write it out:

- Call SSL_read(), it returns SSL_ERROR_WANT_WRITE
- Poll for the socket being writable.
- It?s writable! call SSL_read() again. it might return SSL_ERROR_WANT_READ
- Poll for the socket being readable.
- It?s readable! Call SSL_read() again, and so on.

If openssl wants read, poll for read. If openssl wants write, poll for write. Don?t arbitrarily swap round SSL_read and SSL_write, those two calls are what *you* want to do, not what openssl wants to do.

Regards,
Graham
?


From dthompson at prinpay.com  Sun Feb 22 00:33:17 2015
From: dthompson at prinpay.com (Dave Thompson)
Date: Sat, 21 Feb 2015 19:33:17 -0500
Subject: [openssl-users] Max size on ASN1_item_d2i_bio()?
In-Reply-To: <20150220222408.GA22847@openssl.org>
References: <1424448817.2532.3.camel@redhat.com>
 <20150220222408.GA22847@openssl.org>
Message-ID: <002a01d04e37$297389f0$7c5a9dd0$@prinpay.com>

> From: openssl-users On Behalf Of Dr. Stephen Henson
> Sent: Friday, February 20, 2015 17:24

> On Fri, Feb 20, 2015, Nathaniel McCallum wrote:
> 
> > I'd like to use ASN1_item_d2i_bio() (or something similar) to parse an
> > incoming message. However, given that types like ASN1_OCTET_STRING
> > have (essentially) unbounded length, how do I prevent an attacker from
> > DOS'ing via OOM?
> >
> > Is there some way to set a max packet size?
> >
> 
> No there isn't but if the input is in DER form you can peek the first few
> bytes and get the tag+length fields to determine the size of the
structure. If
> the input uses indefinite length encoding that isn't possible however.
> 
Some other possibilities:

If the bio is memBIO or fileBIO its input size is known before you start,
at least if it contains only one root item. More generally you could layer 
a simple filter BIO that limits total reads to a chosen amount like 1M, 
probably measured from a CTRL operation  -- or a more complex one 
that looks dynamically at your memory-used and/or memory-available 
and chooses whether/when to force EOF, but that would be dependent 
on your particular platform and not portable.

Alternatively or in addition, OpenSSL allows you to provide your own 
malloc/realloc/free implementations used instead of the standard ones. 
But these are used for *all* OpenSSL heap allocations, so you might need 
some care to count the space used "for" or at least during a d2i 
as opposed to other purposes and times.



From eranya at essence-grp.com  Sun Feb 22 14:32:37 2015
From: eranya at essence-grp.com (Eran Yasso)
Date: Sun, 22 Feb 2015 14:32:37 +0000
Subject: [openssl-users] Build OpenSSL for arm NXP
Message-ID: <DBXPR03MB511D2F55CAA48DA55A379ED95280@DBXPR03MB511.eurprd03.prod.outlook.com>

Hi all,

Is it possible to build OpenSSL for ARM (NXP Cortex M4) KEIL OS?
I saw that perl is needed for that, but I am not sure it will be compiled for ARM.

Thank for the help.

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

From tinkr at openmailbox.org  Sun Feb 22 21:02:49 2015
From: tinkr at openmailbox.org (Tinker)
Date: Mon, 23 Feb 2015 02:32:49 +0530
Subject: [openssl-users] =?utf-8?q?Nonblocking_IO=3A_Kindly_need_your_urge?=
 =?utf-8?q?nt_authoritative_confirmation_that_the_OpenSSL_API=27s_SSL=5Fre?=
 =?utf-8?q?ad_and_SSL=5Fwrite_and_select=28=29_must_indeed_be_used_togethe?=
 =?utf-8?q?r_*exactly*_like_this=2C_as_to_keep_us_all_safe_=28from_infinit?=
 =?utf-8?q?e_loop_=26_zombification_bugs=29!?=
Message-ID: <fd1649b103c9c66f39002fc9307cdf0c@openmailbox.org>

 

Dear OpenSSL list, 

I need your authoritative answer on the following question. 

Guaranteedly, this same question has been voiced on this mailing list
already, in less or more similar wording. My question is: 

Please help me to get clear on *exactly* what my program needs to do in
response to a SSL_WANTS_READ or SSL_WANTS_WRITE return value, from
either of SSL_read, SSL_write and SSL_shutdown. 

This is for use of OpenSSL in the Nonblocking IO mode on a socket. I
will also use the BIO mode later, so let's include this in the question
too; 

The reason I ask, is that if my understanding of how this should be
handled is not *ABSOLUTELY CORRECT*, then because of my incorrect
understanding I will be at risk of implementing the select() calls in my
program incorrectly, and that would lead to risk of either *INFINITE
LOOP* or *ZOMBIFICATION* (because of doing a select() too little or too
much), which would be *ABOUT AS BAD AS A PROGRAM BUG COULD EVER BE*. 

I humbly ask you to help me get clear on this, simply by confirming to
me that the understanding expressed in each the following points is
*ABSOLUTELY CORRECT*. 

With your clear confirmation that each of these points are indeed
correct, perhaps maybe the last word needed to be voiced on this topic
will have been said - thank you very much!! 

The points: 

	* By giving me an SSL_WANTS_READ return value to an SSL_read call,
OpenSSL tells me that it cannot do any more SSL_read work for me i.e.
any more reading from the SSL channel for me, without that I re-invoke
SSL_read, *and before that re-invocation* performed a select() for
*readability* on this socket (so that is, include this socket in the
*readfds* argument to the select() call) as to get a confirmation that
more data has arrived on this socket and then having acquired this
confirmation.

	* By giving me an SSL_WANTS_READ return value to an SSL_write call,
OpenSSL tells me that it cannot do any more SSL_write work for me i.e.
any more writing to the SSL channel for me, without that I re-invoke
SSL_write, *and before that re-invocation* performed a select() for
*readability* on this socket (so that is, include this socket in the
*readfds* argument to the select() call) as to get a confirmation that
more data has arrived on this socket and then having acquired this
confirmation.

	* By giving me an SSL_WANTS_READ return value to an SSL_shutdown call,
OpenSSL tells me that it cannot do any more SSL_shutdown work for me
i.e. any more pushing forward of the clean closure of the SSL channel
for me, without that I re-invoke SSL_shutdown, *and before that
re-invocation* performed a select() for *readability* on this socket (so
that is, include this socket in the *readfds* argument to the select()
call) as to get a confirmation that more data has arrived on this socket
and then having acquired this confirmation.

	* Thus in all points 1)-3), SSL_WANTS_READ is essentially OpenSSL's way
to say that it ran out of input data on the socket, and that it needs
more input data in order to proceed with the respective operation at
hand.

	* By giving me an SSL_WANTS_WRITE return value to an SSL_read call,
OpenSSL tells me that it cannot do any more SSL_read work for me i.e.
any more reading from the SSL channel for me, without that I re-invoke
SSL_read, *and before that re-invocation* performed a select() for
*writability* on this socket (so that is, include this socket in the
*writefds* argument to the select() call) as to get a confirmation that
the next SSL_read call performed will be able to write more data to the
socket, than the SSL_read call that returned SSL_WANTS_WRITE could.

	* By giving me an SSL_WANTS_WRITE return value to an SSL_write call,
OpenSSL tells me that it cannot do any more SSL_write work for me i.e.
any more writing to the SSL channel for me, without that I re-invoke
SSL_write, *and before that re-invocation* performed a select() for
*writability* on this socket (so that is, include this socket in the
*writefds* argument to the select() call) as to get a confirmation that
the next SSL_write call performed will be able to write more data to the
socket, than the SSL_write call that returned SSL_WANTS_WRITE could.

	* By giving me an SSL_WANTS_WRITE return value to an SSL_shutdown call,
OpenSSL tells me that it cannot do any more SSL_shutdown work for me
i.e. any more pushing forward of the clean closure of the SSL channel
for me, without that I re-invoke SSL_shutdown, *and before that
re-invocation* performed a select() for *writability* on this socket (so
that is, include this socket in the *writefds* argument to the select()
call) as to get a confirmation that the next SSL_shutdown call performed
will be able to write more data to the socket, than the SSL_shutdown
call that returned SSL_WANTS_WRITE could.

	* Thus in all points 5)-7), SSL_WANTS_WRITE is essentially OpenSSL's
way to say that the OS' write buffer filled out so that OpenSSL's call
to fwrite() for the socket, wouldn't accept any more data written to the
socket at the time, and that for this reason it needs/wants separate
ascertainment that the socket is now writable i.e. an fwrite() to the
socket will accept at least one more byte of data written to it.

	* Beyond the SSL_read and SSL_write calls mentioned specifically to be
done in points 1)-3) and 5)-7) (and if mentioned only), my program is
*not needed or otherwise indicated perform any more SSL_read and
SSL_write calls whatsoever, at any point*.

	* 

One consequence of all of the above 1)-9) is that, if I would want to
implement a flexible SSL channel reading procedure in my program, and i
implement it in terms of SSL_read() and select() only, and the point
with my procedure is to provide a facility for reading from an SSL
channel in such a way that
* A certain number of bytes are required to be read before it returns,
and the procedure should block until it gets that many bytes (let's call
these "bytes_needed"), and
* A certain number of bytes are allowed to be read before it returns
just in case they would happen to be available for reading already at
the time of the call, but there will be no blocking to get that many
bytes (let's call these "bytes_optional"). 

So, this procedure would be defined something like: 

my_flexible_reading_procedure(SSL* ssl,int socket,void* buffer,int
bytes_needed,int bytes_optional). 

Then, my program invokes this procedure, for needing 1 byte and
optionally accepting another 999. 

my_flexible_reading_procedure invokes SSL_read(), which returns
SSL_WANTS_READ. 

my_flexible_reading_procedure select():s for readability and eventually
the select() tells us that more input data is available. 

my_flexible_reading_procedure then invokes SSL_read() again, and it
tells us it read 5 bytes. 

my_flexible_reading_procedure has now gotten all bytes it needed (which
was 1), but, it *must assume* that the reason that SSL_read() returned
with only 5 bytes instead of all the 1 + 999 = 1000 bytes, was because
of technicalities regarding buffering or whatever, so
my_flexible_reading_procedure must reinvoke SSL_read(): 

my_flexible_reading_procedure invokes SSL_read() again, and this time it
returns SSL_WANTS_READ. 

Now, thanks to the clarifications above, we know that a SSL_WANTS_READ
return value just means that OpenSSL has read all input data available
from the socket at this time, and that my_flexible_reading_procedure
want to read/get any more SSL channel data then it at first needs to
wait for more data to come in on the socket from the other party, by
making another select() for readability. 

my_flexible_reading_procedure doesn't want this though, because it
already got all the bytes it needed, which was 1. 

So therefore, my_flexible_reading_procedure returns with a success
result, reporting that it got 5 bytes, and we know that the SSL channel
is in a healthy state, and my program is free to make another SSL_read,
SSL_write or SSL_shutdown call at any moment it wishes to, and then of
course if that respective call would return SSL_WANTS_READ or
SSL_WANTS_WRITE in turn, then that will need to be handled as described
in 1)-3) and 5)-7) above.

	* 

This means that libCurl's handling of SSL_ERROR_WANT_READ result, and
SSL_ERROR_WANT_WRITE result too right?, from SSL_read, defined on rows
1000-1007 and 3079-3083 in
https://github.com/bagder/curl/blob/aba2c4dca2601cb942f47ea9622e01001c01b799/lib/vtls/openssl.c
, 

and its handling of SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE results
from SSL_write, defined on rows 3025-3031, 

is *absolutely broken* right? 

(Perhaps libCurl's use of OpenSSL is done in some limited scope and
context so that somehow doing it like this works, but generally
speaking, implementing it like this is *absolutely broken*.)

	* 

Nginx' handling of SSL_WANT_READ&_WRITE result from SSL_read and
SSL_write is correct though,
https://github.com/git-mirror/nginx/blob/76c07f20962badcadaa0e01d0d8be73cc9ed461f/src/event/ngx_event_openssl.c
: SSL_WANT_READ is channelized to a select() for more input data (that's
on rows 803 and 1318), and SSL_WANT_WRITE is channelized to a select()
for writability (that's on rows 819 and 1061). 

(Presuming that what "c->read->ready = 0;" really does is to trig a
select() for more input data, and what "c->write->ready = 0;" really
does is to trig a select() for writability.)

Thank you very much for taking your time to clarify this matter! 

Mikael

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

From tinkr at openmailbox.org  Sun Feb 22 21:22:16 2015
From: tinkr at openmailbox.org (Tinker)
Date: Mon, 23 Feb 2015 02:52:16 +0530
Subject: [openssl-users]
 =?utf-8?q?Nonblocking_IO=3A_Kindly_need_your_urge?=
 =?utf-8?q?nt_authoritative_confirmation_that_the_OpenSSL_API=27s_SSL=5Fre?=
 =?utf-8?q?ad_and_SSL=5Fwrite_and_select=28=29_must_indeed_be_used_togethe?=
 =?utf-8?q?r_*exactly*_like_this=2C_as_to_keep_us_all_safe_=28from_infinit?=
 =?utf-8?q?e_loop_=26_zombification_bugs=29!?=
Message-ID: <2a137ca2abfefca84ae34ecfed991591@openmailbox.org>

(This is a resubmit of the same post with the numbered list represented 
better here in text format, as the previous mail got the numbered list 
presented well only in the HTML version.)


Dear OpenSSL list,

I need your authoritative answer on the following question.

Guaranteedly, this same question has been voiced on this mailing list 
already, in less or more similar wording. My question is:



Please help me to get clear on *exactly* what my program needs to do in 
response to a SSL_WANTS_READ or SSL_WANTS_WRITE return value, from 
either of SSL_read, SSL_write and SSL_shutdown.

This is for use of OpenSSL in the Nonblocking IO mode on a socket. I 
will also use the BIO mode later, so let's include this in the question 
too;


The reason I ask, is that if my understanding of how this should be 
handled is not *ABSOLUTELY CORRECT*, then because of my incorrect 
understanding I will be at risk of implementing the select() calls in my 
program incorrectly, and that would lead to risk of either *INFINITE 
LOOP* or *ZOMBIFICATION* (because of doing a select() too little or too 
much), which would be *ABOUT AS BAD AS A PROGRAM BUG COULD EVER BE*.



I humbly ask you to help me get clear on this, simply by confirming to 
me that the understanding expressed in each the following points is 
*ABSOLUTELY CORRECT*.

With your clear confirmation that each of these points are indeed 
correct, perhaps maybe the last word needed to be voiced on this topic 
will have been said - thank you very much!!



The points that I kindly ask you to confirm that they are absolutely 
correct are:

  ## 1
By giving me an SSL_WANTS_READ return value to an SSL_read call, OpenSSL 
tells me that it cannot do any more SSL_read work for me i.e. any more 
reading from the SSL channel for me, without that I re-invoke SSL_read, 
*and before that re-invocation* performed a select() for *readability* 
on this socket (so that is, include this socket in the *readfds* 
argument to the select() call) as to get a confirmation that more data 
has arrived on this socket and then having acquired this confirmation.

  ## 2
By giving me an SSL_WANTS_READ return value to an SSL_write call, 
OpenSSL tells me that it cannot do any more SSL_write work for me i.e. 
any more writing to the SSL channel for me, without that I re-invoke 
SSL_write, *and before that re-invocation* performed a select() for 
*readability* on this socket (so that is, include this socket in the 
*readfds* argument to the select() call) as to get a confirmation that 
more data has arrived on this socket and then having acquired this 
confirmation.

  ## 3
By giving me an SSL_WANTS_READ return value to an SSL_shutdown call, 
OpenSSL tells me that it cannot do any more SSL_shutdown work for me 
i.e. any more pushing forward of the clean closure of the SSL channel 
for me, without that I re-invoke SSL_shutdown, *and before that 
re-invocation* performed a select() for *readability* on this socket (so 
that is, include this socket in the *readfds* argument to the select() 
call) as to get a confirmation that more data has arrived on this socket 
and then having acquired this confirmation.

  ## 4
Thus in all points 1)-3), SSL_WANTS_READ is essentially OpenSSL's way to 
say that it ran out of input data on the socket, and that it needs more 
input data in order to proceed with the respective operation at hand.


  ## 5
By giving me an SSL_WANTS_WRITE return value to an SSL_read call, 
OpenSSL tells me that it cannot do any more SSL_read work for me i.e. 
any more reading from the SSL channel for me, without that I re-invoke 
SSL_read, *and before that re-invocation* performed a select() for 
*writability* on this socket (so that is, include this socket in the 
*writefds* argument to the select() call) as to get a confirmation that 
the next SSL_read call performed will be able to write more data to the 
socket, than the SSL_read call that returned SSL_WANTS_WRITE could.

  ## 6
By giving me an SSL_WANTS_WRITE return value to an SSL_write call, 
OpenSSL tells me that it cannot do any more SSL_write work for me i.e. 
any more writing to the SSL channel for me, without that I re-invoke 
SSL_write, *and before that re-invocation* performed a select() for 
*writability* on this socket (so that is, include this socket in the 
*writefds* argument to the select() call) as to get a confirmation that 
the next SSL_write call performed will be able to write more data to the 
socket, than the SSL_write call that returned SSL_WANTS_WRITE could.

  ## 7
By giving me an SSL_WANTS_WRITE return value to an SSL_shutdown call, 
OpenSSL tells me that it cannot do any more SSL_shutdown work for me 
i.e. any more pushing forward of the clean closure of the SSL channel 
for me, without that I re-invoke SSL_shutdown, *and before that 
re-invocation* performed a select() for *writability* on this socket (so 
that is, include this socket in the *writefds* argument to the select() 
call) as to get a confirmation that the next SSL_shutdown call performed 
will be able to write more data to the socket, than the SSL_shutdown 
call that returned SSL_WANTS_WRITE could.

  ## 8
Thus in all points 5)-7), SSL_WANTS_WRITE is essentially OpenSSL's way 
to say that the OS' write buffer filled out so that OpenSSL's call to 
fwrite() for the socket, wouldn't accept any more data written to the 
socket at the time, and that for this reason it needs/wants separate 
ascertainment that the socket is now writable i.e. an fwrite() to the 
socket will accept at least one more byte of data written to it.


  ## 9
Beyond the SSL_read and SSL_write calls mentioned specifically to be 
done in points 1)-3) and 5)-7) (and if mentioned only), my program is 
*not needed or otherwise indicated perform any more SSL_read and 
SSL_write calls whatsoever, at any point*.

  ## 10
One consequence of all of the above 1)-9) is that, if I would want to 
implement a flexible SSL channel reading procedure in my program, and i 
implement it in terms of SSL_read() and select() only, and the point 
with my procedure is to provide a facility for reading from an SSL 
channel in such a way that
* A certain number of bytes are required to be read before it returns, 
and the procedure should block until it gets that many bytes (let's call 
these "bytes_needed"), and
* A certain number of bytes are allowed to be read before it returns 
just in case they would happen to be available for reading already at 
the time of the call, but there will be no blocking to get that many 
bytes (let's call these "bytes_optional").

So, this procedure would be defined something like:

my_flexible_reading_procedure(SSL* ssl,int socket,void* buffer,int 
bytes_needed,int bytes_optional).

Then, my program invokes this procedure, for needing 1 byte and 
optionally accepting another 999.

my_flexible_reading_procedure invokes SSL_read(), which returns 
SSL_WANTS_READ.

my_flexible_reading_procedure select():s for readability and eventually 
the select() tells us that more input data is available.

my_flexible_reading_procedure then invokes SSL_read() again, and it 
tells us it read 5 bytes.

my_flexible_reading_procedure has now gotten all bytes it needed (which 
was 1), but, it *must assume* that the reason that SSL_read() returned 
with only 5 bytes instead of all the 1 + 999 = 1000 bytes, was because 
of technicalities regarding buffering or whatever, so 
my_flexible_reading_procedure must reinvoke SSL_read():

my_flexible_reading_procedure invokes SSL_read() again, and this time it 
returns SSL_WANTS_READ.

Now, thanks to the clarifications above, we know that a SSL_WANTS_READ 
return value just means that OpenSSL has read all input data available 
from the socket at this time, and that my_flexible_reading_procedure 
want to read/get any more SSL channel data then it at first needs to 
wait for more data to come in on the socket from the other party, by 
making another select() for readability.

my_flexible_reading_procedure doesn't want this though, because it 
already got all the bytes it needed, which was 1.

So therefore, my_flexible_reading_procedure returns with a success 
result, reporting that it got 5 bytes, and we know that the SSL channel 
is in a healthy state, and my program is free to make another SSL_read, 
SSL_write or SSL_shutdown call at any moment it wishes to, and then of 
course if that respective call would return SSL_WANTS_READ or 
SSL_WANTS_WRITE in turn, then that will need to be handled as described 
in 1)-3) and 5)-7) above.

11)
This means that libCurl's handling of SSL_ERROR_WANT_READ result, and 
SSL_ERROR_WANT_WRITE result too right?, from SSL_read, defined on rows 
1000-1007 and 3079-3083 in 
https://github.com/bagder/curl/blob/aba2c4dca2601cb942f47ea9622e01001c01b799/lib/vtls/openssl.c 
,

and its handling of SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE results 
from SSL_write, defined on rows 3025-3031,

is *absolutely broken* right?

(Perhaps libCurl's use of OpenSSL is done in some limited scope and 
context so that somehow doing it like this works, but generally 
speaking, implementing it like this is *absolutely broken*.)

  ## 12
Nginx' handling of SSL_WANT_READ&_WRITE result from SSL_read and 
SSL_write is correct though, 
https://github.com/git-mirror/nginx/blob/76c07f20962badcadaa0e01d0d8be73cc9ed461f/src/event/ngx_event_openssl.c 
: SSL_WANT_READ is channelized to a select() for more input data (that's 
on rows 803 and 1318), and SSL_WANT_WRITE is channelized to a select() 
for writability (that's on rows 819 and 1061).

(Presuming that what "c->read->ready = 0;" really does is to trig a 
select() for more input data, and what "c->write->ready = 0;" really 
does is to trig a select() for writability.)


Thank you very much for taking your time to clarify this matter!

Mikael

From p.mrunal at gmail.com  Mon Feb 23 09:36:13 2015
From: p.mrunal at gmail.com (Mrunal Nerpawar)
Date: Mon, 23 Feb 2015 15:06:13 +0530
Subject: [openssl-users] FIPSLD 2.0.5 (HP-UX AI64 11.23) fails to link with
	pthread error
Message-ID: <CAF5AerH_+p_Fo0tb3o6Yh2V1Heqx3vxw=hgUY4sRHtEdihnzJQ@mail.gmail.com>

Details
======
Fips 2.0.5 configured with no-asm and threads.
Openssl 1.0.1H configured with shared, fips, threads no-asm (many alogos
omitted)
compiler -  using aCC 6.25 on HPUX-IA64 11.23.

bash-2.05$ aCC --version
aCC: HP C/aC++ B3910B A.06.25.02 [Nov 25 2010]
bash-2.05$

product linking with fipsld fails with error ...
=================================
:DLFCN_LOAD:could not load the shared
library:dso_dlfcn.c:187:filename(./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0):
Cannot dlopen load module '/usr/lib/hpux32/libpthread.so.1' because it
contains thread specific data.

Options tried
==========
* Compiling Cxx sources with -mt.
* Linking with -lpthread,
* setting LD_PRELOAD.
None worked effectively. with LD_PRELOAD option, ended up getting error -
undefined symbol Ztil, etc.

complete error is as follows.
=====================

Building shared library
objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
FIPSLD_CC=aCC FIPSLD_LINK=aCC
/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/fipsld
+Z -b -g -O2 -AA -Wl,+s +tls=dynamic -o
objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
objs/HP-UX-B.11.23-ia64-64/stdafx.o objs/HP-UX-B.11.23-ia64-64/UserUtil.o
objs/HP-UX-B.11.23-ia64-64/LSSpawner.o
objs/HP-UX-B.11.23-ia64-64/LSFilter.o
objs/HP-UX-B.11.23-ia64-64/LSCmdOutputParser.o
objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor.o
objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor_1.o
objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor_2.o
objs/HP-UX-B.11.23-ia64-64/GroupUtil.o
objs/HP-UX-B.11.23-ia64-64/ShadowHelper.o
objs/HP-UX-B.11.23-ia64-64/BlockedFiles.o
objs/HP-UX-B.11.23-ia64-64/NISUtil.o objs/HP-UX-B.11.23-ia64-64/Utilities.o
objs/HP-UX-B.11.23-ia64-64/MachineUtil.o
objs/HP-UX-B.11.23-ia64-64/BvNetworkInfo.o
objs/HP-UX-B.11.23-ia64-64/NSSwitch.o
objs/HP-UX-B.11.23-ia64-64/FileUtil_1.o
objs/HP-UX-B.11.23-ia64-64/FileUtil_2.o
objs/HP-UX-B.11.23-ia64-64/SecurityThreatCheck.o
objs/HP-UX-B.11.23-ia64-64/UserEnumerator.o
objs/HP-UX-B.11.23-ia64-64/LocalUserEnumerator.o
objs/HP-UX-B.11.23-ia64-64/UnixUserEnumerator.o
objs/HP-UX-B.11.23-ia64-64/WinUserEnumerator.o
objs/HP-UX-B.11.23-ia64-64/GetEntHandler.o
objs/HP-UX-B.11.23-ia64-64/UnixShadowReader.o
objs/HP-UX-B.11.23-ia64-64/EtcShadowReader.o
objs/HP-UX-B.11.23-ia64-64/UnixEtcShadowReader.o
objs/HP-UX-B.11.23-ia64-64/AIXShadowHelper.o
objs/HP-UX-B.11.23-ia64-64/HPLoginsShadowHelper.o
objs/HP-UX-B.11.23-ia64-64/HPTcbShadowHelper.o
objs/HP-UX-B.11.23-ia64-64/UnixHPShadowReader.o
objs/HP-UX-B.11.23-ia64-64/ProcessUtil.o
objs/HP-UX-B.11.23-ia64-64/FieldUtils.o
objs/HP-UX-B.11.23-ia64-64/LoggedInUserInfo.o
objs/HP-UX-B.11.23-ia64-64/TcpdRulesParser.o
objs/HP-UX-B.11.23-ia64-64/DirectoryUtil.o
objs/HP-UX-B.11.23-ia64-64/Timestamp.o
objs/HP-UX-B.11.23-ia64-64/Timespan.o
objs/HP-UX-B.11.23-ia64-64/NumberFormatter.o
objs/HP-UX-B.11.23-ia64-64/DateTimeParser.o
objs/HP-UX-B.11.23-ia64-64/DateTimeFormatter.o
objs/HP-UX-B.11.23-ia64-64/DateTimeFormat.o
objs/HP-UX-B.11.23-ia64-64/DateTime.o objs/HP-UX-B.11.23-ia64-64/Timezone.o
objs/HP-UX-B.11.23-ia64-64/LocalDateTime.o
objs/HP-UX-B.11.23-ia64-64/RFUtilities.o
objs/HP-UX-B.11.23-ia64-64/OpenPortUtil.o
objs/HP-UX-B.11.23-ia64-64/AIXStanzaReader.o
objs/HP-UX-B.11.23-ia64-64/Bugcheck.o objs/HP-UX-B.11.23-ia64-64/DateTime.o
objs/HP-UX-B.11.23-ia64-64/Debugger.o
objs/HP-UX-B.11.23-ia64-64/Exception.o
objs/HP-UX-B.11.23-ia64-64/GroupEnumerator.o
objs/HP-UX-B.11.23-ia64-64/UnixGroupEnumerator.o
objs/HP-UX-B.11.23-ia64-64/FileInfoFetcher.o
objs/HP-UX-B.11.23-ia64-64/UnixFileInfoAccessor.o
objs/HP-UX-B.11.23-ia64-64/FileStatSysCallProcessor.o
objs/HP-UX-B.11.23-ia64-64/StatSysCallFileInfoFetcherImpl.o
objs/HP-UX-B.11.23-ia64-64/FileInfoAccessor.o
objs/HP-UX-B.11.23-ia64-64/FileProcessorObjectFactory.o
objs/HP-UX-B.11.23-ia64-64/UUID.o objs/HP-UX-B.11.23-ia64-64/RandomStream.o
objs/HP-UX-B.11.23-ia64-64/Random.o objs/HP-UX-B.11.23-ia64-64/SHA1Engine.o
objs/HP-UX-B.11.23-ia64-64/DigestEngine.o
objs/HP-UX-B.11.23-ia64-64/FileDescriptorUtil.o
objs/HP-UX-B.11.23-ia64-64/PasswordInfo.o
objs/HP-UX-B.11.23-ia64-64/DictionaryReader.o
objs/HP-UX-B.11.23-ia64-64/PasswordCracker.o
objs/HP-UX-B.11.23-ia64-64/md5crypt.o
-L/unixhome/user/workspace/ontrolShared/UnixReusableClasses/lib/HP-UX-B.11.23-ia64-64
-lReCpp -lReCommon
-L/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/lib -lcrypto
-L/unixhome/user/workspace/product/lib/HP-UX-B.11.23-ia64-64 -lAgentCommon
-lReCoreClasses -lCommonLib  -lsec
fipsld:
THERE=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/..
fipsld: TARGET=./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
fipsld:
CANISTER_O=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fipscanister.o
fipsld:
PREMAIN_C=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fips_premain.c
fipsld: PREMAIN_O=objs/HP-UX-B.11.23-ia64-64/fips_premain.o
fipsld: FIPSLIBDIR=
fipsld: FIPSLD_CC=aCC
fipsld: FIPSLD_LINK=aCC
fipsld: Linking shared library file.
fipsld: Compiling
"/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fips_premain.c".
fipsld: Linking "./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0"
with FIPS libaries.
2130621380:error:25066067:DSO support routines:DLFCN_LOAD:could not load
the shared
library:dso_dlfcn.c:187:filename(./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0):
Cannot dlopen load module '/usr/lib/hpux32/libpthread.so.1' because it
contains thread specific data.
2130621380:error:25070067:DSO support routines:DSO_load:could not load the
shared library:dso_lib.c:244:
/unixhome/user/workspace/product/Packages/BuildScripts/Makefiles/Make.inc.shlib.rules:73:
recipe for target 'objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0'
failed
gmake: *** [objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0] Error 1
bash-2.05$


We are running short of time. If anybody has any solutions/suggestions
help, would be appreciated.

Thanks in advance.

Best regards,
Mrunal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150223/49bf200f/attachment.html>

From b_duvvuri at yahoo.com  Mon Feb 23 10:25:42 2015
From: b_duvvuri at yahoo.com (Bala Duvvuri)
Date: Mon, 23 Feb 2015 02:25:42 -0800
Subject: [openssl-users] fips_ecdhvs failing for non Prime Curves
Message-ID: <1424687142.13388.YahooMailBasic@web400202.mail.bf1.yahoo.com>

Hi All,

I am trying to test the FIPS ECDH support present in OpenSSL i.e trying to run the fips_ecdhvs.c test.

The test vectors " ECC CDH Primitive Test Vectors" from NIST website have been downloaded - http://csrc.nist.gov/groups/STM/cavp/#09 and given as the input.

The test passes for the vectors that have the field type - NID_X9_62_prime_field (NIST Prime-Curve P-192, P-256 etc ) but outputs wrong shared key for other curves like (NIST Binary-Curve K-163/B-163/K-233 etc)

The test is run using the command - ./fips_ecdhvs ecdhver KAS_ECC_CDH_PrimitiveTest.txt Out

One observation is the non prime test vectors have 0 at the begining:

QIUTx = 000000071f8b2877d6027d9c1ade4244f2dea12692ef23d5
QIUTy = 00000005c15ee776221c72b84b347ce383f38067b89c3e9a

If we print the EC key using ec_print_key, we find the leading 0's missing, is this ok?

QIUTx = 071f8b2877d6027d9c1ade4244f2dea12692ef23d5
QIUTy = 05c15ee776221c72b84b347ce383f38067b89c3e9a

Please let me know how to make the above test work?

thanks,
Bala

From rwelty at averillpark.net  Mon Feb 23 14:52:02 2015
From: rwelty at averillpark.net (Richard Welty)
Date: Mon, 23 Feb 2015 09:52:02 -0500
Subject: [openssl-users] CMS questions
Message-ID: <54EB3E92.7060106@averillpark.net>

i'm starting on some work that needs to use CMS in an
application, and i'm having trouble getting my head
wrapped around how to handle the case of verifying
a signature and then decrypting the enveloped data
that has been signed. specifically, i'm not grasping
how to extract the encrypted data to pass to CMS_decrypt
after verification is done. do i need to use a BIO
filter for this or is there some other mechanism i'm not
seeing?

thanks in advance,
  richard

-- 
rwelty at averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150223/2d801015/attachment.sig>

From stm at pdflib.com  Tue Feb 24 08:35:37 2015
From: stm at pdflib.com (=?windows-1252?Q?Stephan_M=FChlstrasser?=)
Date: Tue, 24 Feb 2015 09:35:37 +0100
Subject: [openssl-users] Meaning of OCSP_NOEXPLICIT for
	OCSP_basic_verify()
In-Reply-To: <54E4836F.6010406@pdflib.com>
References: <54E4836F.6010406@pdflib.com>
Message-ID: <54EC37D9.7080900@pdflib.com>

Am 18.02.15 um 13:19 schrieb Stephan M?hlstrasser:
>
> Unfortunately the "-no_explicit" command line option is not documented:
>
> https://www.openssl.org/docs/apps/ocsp.html
>
> What is the meaning of setting the OCSP_NOEXPLICIT flag resp. using the
> "-no_explicit" command line option. What exactly is checked by the
> X509_check_trust() call above with respect to the relevant RFCs?
>

As there is no documentation and as noone seems to know the meaning of 
the -no_explicit for "openssl ocsp", should I file a documentation 
defect in RT for that?

If I understand the code in OCSP_basic_verify() that is depending on the 
OCSP_NOEXPLICIT flag correctly, it checks the root CA for the presence 
of the OCSPSigning flag in the extended key usage field. I could not 
find anything in RFC 6960 and RFC 2560 that would mandate such a check 
for the root CA certificate. Only the OCSP signing certificate must have 
OCSPSigning in the extended key usage field.

So maybe it is even a bug in the code itself?

-- 
Stephan


From steve at openssl.org  Tue Feb 24 13:47:28 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 24 Feb 2015 13:47:28 +0000
Subject: [openssl-users] Meaning of OCSP_NOEXPLICIT for
 OCSP_basic_verify()
In-Reply-To: <54E4836F.6010406@pdflib.com>
References: <54E4836F.6010406@pdflib.com>
Message-ID: <20150224134728.GA28453@openssl.org>

On Wed, Feb 18, 2015, Stephan M?hlstrasser wrote:

> 
> What is the meaning of setting the OCSP_NOEXPLICIT flag resp. using
> the "-no_explicit" command line option. What exactly is checked by
> the X509_check_trust() call above with respect to the relevant RFCs?
> 

If the responder root CA is set to be trusted for OCSP signing then it can be
used to sign OCSP responses for any certificate (aka a global responder). This
comes under:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question

or alternatively:

   Additional acceptance or rejection criteria may apply to either the
   response itself or to the certificate used to validate the signature
   on the response.

from RFC2560 et al.

If the -no_explicit flag is set or OCSP_NOEXPLICIT is set then this behaviour
is disabled.

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

From steve at openssl.org  Tue Feb 24 14:21:06 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 24 Feb 2015 14:21:06 +0000
Subject: [openssl-users] CMS questions
In-Reply-To: <54EB3E92.7060106@averillpark.net>
References: <54EB3E92.7060106@averillpark.net>
Message-ID: <20150224142106.GA1228@openssl.org>

On Mon, Feb 23, 2015, Richard Welty wrote:

> i'm starting on some work that needs to use CMS in an
> application, and i'm having trouble getting my head
> wrapped around how to handle the case of verifying
> a signature and then decrypting the enveloped data
> that has been signed. specifically, i'm not grasping
> how to extract the encrypted data to pass to CMS_decrypt
> after verification is done. do i need to use a BIO
> filter for this or is there some other mechanism i'm not
> seeing?
> 

Typically you'd write the signed content to a memory BIO and then decrypt
that. Precisely how you decrypt the enveloped data depends on the format. It
might be in MIME format in which case you'd pass it through the MIME parser.
Alternatively it could be enveloped data content type in which case you'd
decode it as BER form.

There are shortcuts you can make if, for example, you know the signed content
is not detached and in BER form.

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

From steve at openssl.org  Tue Feb 24 14:30:49 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 24 Feb 2015 14:30:49 +0000
Subject: [openssl-users] fips_ecdhvs failing for non Prime Curves
In-Reply-To: <1424687142.13388.YahooMailBasic@web400202.mail.bf1.yahoo.com>
References: <1424687142.13388.YahooMailBasic@web400202.mail.bf1.yahoo.com>
Message-ID: <20150224143049.GB1228@openssl.org>

On Mon, Feb 23, 2015, Bala Duvvuri wrote:

> Hi All,
> 
> I am trying to test the FIPS ECDH support present in OpenSSL i.e trying to run the fips_ecdhvs.c test.
> 

When you say ECDH support present in OpenSSL do you mean in the FIPS module or
in OpenSSL itself?

If you mean in OpenSSL itself then you need to use cofactor ECDH for the tests
which is only supported in OpenSSL 1.0.2 and later (it is supported in the
FIPS module). The results for cofactor ECDH differ from ECDH if the curve
cofactor is not 1: this is true for several binary curves which would account
for the differences you were seeing.

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

From rwelty at averillpark.net  Tue Feb 24 14:30:14 2015
From: rwelty at averillpark.net (Richard Welty)
Date: Tue, 24 Feb 2015 09:30:14 -0500
Subject: [openssl-users] CMS questions
In-Reply-To: <20150224142106.GA1228@openssl.org>
References: <54EB3E92.7060106@averillpark.net>
 <20150224142106.GA1228@openssl.org>
Message-ID: <54EC8AF6.70407@averillpark.net>

On 2/24/15 9:21 AM, Dr. Stephen Henson wrote:
>
> Typically you'd write the signed content to a memory BIO and then decrypt
> that. Precisely how you decrypt the enveloped data depends on the format. It
> might be in MIME format in which case you'd pass it through the MIME parser.
> Alternatively it could be enveloped data content type in which case you'd
> decode it as BER form.
>
> There are shortcuts you can make if, for example, you know the signed content
> is not detached and in BER form.
>
it will not be detached, and will be in BER form. shortcuts (as long as
they're
in a documented API) are welcome as this is in a path that should be fast.

thanks,
   richard

-- 
rwelty at averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150224/88ea9422/attachment.sig>

From rsalz at akamai.com  Tue Feb 24 15:02:34 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 24 Feb 2015 15:02:34 +0000
Subject: [openssl-users] Meaning of OCSP_NOEXPLICIT
	for	OCSP_basic_verify()
In-Reply-To: <54EC37D9.7080900@pdflib.com>
References: <54E4836F.6010406@pdflib.com> <54EC37D9.7080900@pdflib.com>
Message-ID: <5173a1ab515947459e3bf9876035dbaa@ustx2ex-dag1mb2.msg.corp.akamai.com>

> As there is no documentation and as noone seems to know the meaning of
> the -no_explicit for "openssl ocsp", should I file a documentation defect in RT
> for that?

yes, please.

From steve at openssl.org  Tue Feb 24 15:10:22 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 24 Feb 2015 15:10:22 +0000
Subject: [openssl-users] CMS questions
In-Reply-To: <54EC8AF6.70407@averillpark.net>
References: <54EB3E92.7060106@averillpark.net>
 <20150224142106.GA1228@openssl.org>
 <54EC8AF6.70407@averillpark.net>
Message-ID: <20150224151022.GA12696@openssl.org>

On Tue, Feb 24, 2015, Richard Welty wrote:

> On 2/24/15 9:21 AM, Dr. Stephen Henson wrote:
> >
> > Typically you'd write the signed content to a memory BIO and then decrypt
> > that. Precisely how you decrypt the enveloped data depends on the format. It
> > might be in MIME format in which case you'd pass it through the MIME parser.
> > Alternatively it could be enveloped data content type in which case you'd
> > decode it as BER form.
> >
> > There are shortcuts you can make if, for example, you know the signed content
> > is not detached and in BER form.
> >
> it will not be detached, and will be in BER form. shortcuts (as long as
> they're
> in a documented API) are welcome as this is in a path that should be fast.
> 

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().

A couple of those functions are currently undocumented (that will be fixed) but
nothing in that involves using structure internals.

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

From jonetsu at teksavvy.com  Tue Feb 24 15:19:08 2015
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 24 Feb 2015 10:19:08 -0500
Subject: [openssl-users] FIPS methods and symlinks
Message-ID: <9234a28fb182c37f5bbcebfc6236fb4a@teksavvy.com>

Hello,

? To grasp how FIPS methods are called, and following one method
as an example, HMAC_Update() in hmac.c, we can see that if FIPS
mode is active then FIPS_hmac_update() will be called.? This is
fine although searching the sources for the physical definiton of
FIPS_hmac_update() does not yield any results.? How does the
symbolic links function, what ends up being executed in this case
and through which path ?

Thanks, regards.




From minfrin at sharp.fm  Tue Feb 24 15:18:20 2015
From: minfrin at sharp.fm (Graham Leggett)
Date: Tue, 24 Feb 2015 17:18:20 +0200
Subject: [openssl-users] Nonblocking IO: Kindly need your urgent
	authoritative confirmation that the OpenSSL API's SSL_read
	and SSL_write and select() must indeed be used together
	*exactly* like this,
	as to keep us all safe (from infinite loop & zombification bugs)!
In-Reply-To: <2a137ca2abfefca84ae34ecfed991591@openmailbox.org>
References: <2a137ca2abfefca84ae34ecfed991591@openmailbox.org>
Message-ID: <5C6941D5-119F-48D1-8668-9D82CF2D3D40@sharp.fm>

On 22 Feb 2015, at 11:22 PM, Tinker <tinkr at openmailbox.org> wrote:

> I need your authoritative answer on the following question.

[snip stuff that is too long]

You are totally overthinking this.

The SSL protocol involves negotiation, during which the sender and the receiver exchange data with each other. What this means is that during either SSL_read, or SSL_write, openssl might try to write or read respectively. If your non-blocking code isn?t geared to handle this, you might end up either hanging or spinning as you wait for the wrong event.

The SSL_WANTS_READ response code is a warning that means ?I want to read during SSL_write, are you ok with me doing this??.

The SSL_WANTS_WRITE response code is a warning that means ?I want to write during SSL_read, are you ok with me doing this??.

In both cases, once you have determined that it is ok to read, or ok to write, you simply retry SSL_write() or SSL_read() again.

For example, a read loop:

sense = READ;
while (sense == READ ? if_ready_to_read() : if_ready_to_write()) {
    rc = SSL_read();
    if (rc == SSL_WANT_WRITE) {
        sense = WRITE;
    } else {
        sense = READ;
    }
    // do stuff with what you read (you may have read nothing, but that?s fine too)
}

Regards,
Graham
?


From rsalz at akamai.com  Tue Feb 24 15:19:48 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 24 Feb 2015 15:19:48 +0000
Subject: [openssl-users] Meaning of
	OCSP_NOEXPLICIT	for	OCSP_basic_verify()
In-Reply-To: <5173a1ab515947459e3bf9876035dbaa@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <54E4836F.6010406@pdflib.com> <54EC37D9.7080900@pdflib.com>
 <5173a1ab515947459e3bf9876035dbaa@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <b3b00d5bb2644c6894af99b3f1ae6b54@ustx2ex-dag1mb2.msg.corp.akamai.com>

> > As there is no documentation and as noone seems to know the meaning of
> > the -no_explicit for "openssl ocsp", should I file a documentation
> > defect in RT for that?
> 
> yes, please.

Never mind, Stephen already fixed the doc in master :)


From stm at pdflib.com  Tue Feb 24 16:00:54 2015
From: stm at pdflib.com (=?windows-1252?Q?Stephan_M=FChlstrasser?=)
Date: Tue, 24 Feb 2015 17:00:54 +0100
Subject: [openssl-users] Meaning of OCSP_NOEXPLICIT for
	OCSP_basic_verify()
In-Reply-To: <20150224134728.GA28453@openssl.org>
References: <54E4836F.6010406@pdflib.com> <20150224134728.GA28453@openssl.org>
Message-ID: <54ECA036.3000502@pdflib.com>

Am 24.02.15 um 14:47 schrieb Dr. Stephen Henson:

> If the responder root CA is set to be trusted for OCSP signing then it can be
> used to sign OCSP responses for any certificate (aka a global responder). This
> comes under:
>
>     1. Matches a local configuration of OCSP signing authority for the
>     certificate in question
>
> or alternatively:
>
>     Additional acceptance or rejection criteria may apply to either the
>     response itself or to the certificate used to validate the signature
>     on the response.
>
> from RFC2560 et al.
>
> If the -no_explicit flag is set or OCSP_NOEXPLICIT is set then this behaviour
> is disabled.
>

Do I understand it correctly then that "a local configuration of OCSP 
signing authority" here means that it is a deliberate choice inside 
OpenSSL itself to look for the OCSPSigning flag in the extended key 
usage of the root CA, although RFC 2560 does not say so?

-- 
Stephan

From steve at openssl.org  Tue Feb 24 16:16:17 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 24 Feb 2015 16:16:17 +0000
Subject: [openssl-users] FIPS methods and symlinks
In-Reply-To: <9234a28fb182c37f5bbcebfc6236fb4a@teksavvy.com>
References: <9234a28fb182c37f5bbcebfc6236fb4a@teksavvy.com>
Message-ID: <20150224161617.GA32189@openssl.org>

On Tue, Feb 24, 2015, jonetsu wrote:

> Hello,
> 
> ? To grasp how FIPS methods are called, and following one method
> as an example, HMAC_Update() in hmac.c, we can see that if FIPS
> mode is active then FIPS_hmac_update() will be called.? This is
> fine although searching the sources for the physical definiton of
> FIPS_hmac_update() does not yield any results.? How does the
> symbolic links function, what ends up being executed in this case
> and through which path ?
> 

Function names get changed through fips/fipssyms.h in the FIPS module source.

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

From steve at openssl.org  Tue Feb 24 18:24:30 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 24 Feb 2015 18:24:30 +0000
Subject: [openssl-users] Meaning of OCSP_NOEXPLICIT for
 OCSP_basic_verify()
In-Reply-To: <54ECA036.3000502@pdflib.com>
References: <54E4836F.6010406@pdflib.com> <20150224134728.GA28453@openssl.org>
 <54ECA036.3000502@pdflib.com>
Message-ID: <20150224182430.GA26745@openssl.org>

On Tue, Feb 24, 2015, Stephan M?hlstrasser wrote:

> 
> Do I understand it correctly then that "a local configuration of
> OCSP signing authority" here means that it is a deliberate choice
> inside OpenSSL itself to look for the OCSPSigning flag in the
> extended key usage of the root CA, although RFC 2560 does not say
> so?
> 

No it's a separate thing called a "trust setting" which is not part of the
certificate itself . This is something which has to be explicitly configured
to trust that root CA for OCSPSigning.

It's OpenSSL's version of the trust settings you see in browsers.

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

From stm at pdflib.com  Tue Feb 24 18:25:12 2015
From: stm at pdflib.com (=?windows-1252?Q?Stephan_M=FChlstrasser?=)
Date: Tue, 24 Feb 2015 19:25:12 +0100
Subject: [openssl-users] Meaning of
	OCSP_NOEXPLICIT	for	OCSP_basic_verify()
In-Reply-To: <b3b00d5bb2644c6894af99b3f1ae6b54@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <54E4836F.6010406@pdflib.com> <54EC37D9.7080900@pdflib.com>
 <5173a1ab515947459e3bf9876035dbaa@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <b3b00d5bb2644c6894af99b3f1ae6b54@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <54ECC208.2050207@pdflib.com>

Am 24.02.2015 um 16:19 schrieb Salz, Rich:
>>> As there is no documentation and as noone seems to know the meaning of
>>> the -no_explicit for "openssl ocsp", should I file a documentation
>>> defect in RT for that?
>>
>> yes, please.
>
> Never mind, Stephen already fixed the doc in master :)

Sorry, I sent already a message to the RT address.

-- 
Stephan

From jonetsu at teksavvy.com  Wed Feb 25 02:42:19 2015
From: jonetsu at teksavvy.com (jonetsu at teksavvy.com)
Date: Tue, 24 Feb 2015 21:42:19 -0500
Subject: [openssl-users] FIPS methods and symlinks
In-Reply-To: <20150224161617.GA32189@openssl.org>
References: <9234a28fb182c37f5bbcebfc6236fb4a@teksavvy.com>
 <20150224161617.GA32189@openssl.org>
Message-ID: <20150224214219.3f30e324@mevla>

On Tue, 24 Feb 2015 16:16:17 +0000
"Dr. Stephen Henson" <steve at openssl.org> wrote:

> On Tue, Feb 24, 2015, jonetsu wrote:

> > Hello,
> > 
> > ? To grasp how FIPS methods are called, and following one method
> > as an example, HMAC_Update() in hmac.c, we can see that if FIPS
> > mode is active then FIPS_hmac_update() will be called.? This is
> > fine although searching the sources for the physical definiton of
> > FIPS_hmac_update() does not yield any results.? How does the
> > symbolic links function, what ends up being executed in this case
> > and through which path ?
> 
> Function names get changed through fips/fipssyms.h in the FIPS module
> source.

Yes, for instance there is:

#define HMAC_Update FIPS_hmac_update

My question is about not having found FIPS_hmac_update.  If it is
called, then where is it ?  May sound like a simple question, although
grep did not return any actual method.  


From thomas.francis.jr at pobox.com  Wed Feb 25 03:01:41 2015
From: thomas.francis.jr at pobox.com (Tom Francis)
Date: Tue, 24 Feb 2015 22:01:41 -0500
Subject: [openssl-users] FIPSLD 2.0.5 (HP-UX AI64 11.23) fails to link
	with pthread error
In-Reply-To: <CAF5AerH_+p_Fo0tb3o6Yh2V1Heqx3vxw=hgUY4sRHtEdihnzJQ@mail.gmail.com>
References: <CAF5AerH_+p_Fo0tb3o6Yh2V1Heqx3vxw=hgUY4sRHtEdihnzJQ@mail.gmail.com>
Message-ID: <CFA3D59B-C7D4-41FD-A48A-4069E81FF0F9@pobox.com>

Have you tried changing FIPSLD_CC and FIPSLD_LINK to include the necessary options (e.g. -mt)?  Note: it might be simpler to modify fipsld instead, depending on how easy/hard it is to maintain spaces properly when settings FIPSLD_CC and FIPSLD_LINK.  Since the fipsld script is just a convenience script to help you meet the requirements of the security policy, you?re free to modify it.  Just don?t modify it such that the security policy is no longer followed.  Generally speaking, adding more options to the compile and link steps will be safe.

TOM

> On Feb 23, 2015, at 4:36 AM, Mrunal Nerpawar <p.mrunal at gmail.com> wrote:
> 
> Details
> ======
> Fips 2.0.5 configured with no-asm and threads.
> Openssl 1.0.1H configured with shared, fips, threads no-asm (many alogos omitted) 
> compiler -  using aCC 6.25 on HPUX-IA64 11.23.
> 
> bash-2.05$ aCC --version
> aCC: HP C/aC++ B3910B A.06.25.02 [Nov 25 2010]
> bash-2.05$
> 
> product linking with fipsld fails with error ...
> =================================
> :DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0):  Cannot dlopen load module '/usr/lib/hpux32/libpthread.so.1' because it contains thread specific data.
> 
> Options tried
> ==========
> * Compiling Cxx sources with -mt.
> * Linking with -lpthread,
> * setting LD_PRELOAD.
> None worked effectively. with LD_PRELOAD option, ended up getting error - undefined symbol Ztil, etc.
> 
> complete error is as follows.
> =====================
> 
> Building shared library objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
> FIPSLD_CC=aCC FIPSLD_LINK=aCC /unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/fipsld  +Z -b -g -O2 -AA -Wl,+s +tls=dynamic -o objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0 objs/HP-UX-B.11.23-ia64-64/stdafx.o objs/HP-UX-B.11.23-ia64-64/UserUtil.o objs/HP-UX-B.11.23-ia64-64/LSSpawner.o objs/HP-UX-B.11.23-ia64-64/LSFilter.o objs/HP-UX-B.11.23-ia64-64/LSCmdOutputParser.o objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor.o objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor_1.o objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor_2.o objs/HP-UX-B.11.23-ia64-64/GroupUtil.o objs/HP-UX-B.11.23-ia64-64/ShadowHelper.o objs/HP-UX-B.11.23-ia64-64/BlockedFiles.o objs/HP-UX-B.11.23-ia64-64/NISUtil.o objs/HP-UX-B.11.23-ia64-64/Utilities.o objs/HP-UX-B.11.23-ia64-64/MachineUtil.o objs/HP-UX-B.11.23-ia64-64/BvNetworkInfo.o objs/HP-UX-B.11.23-ia64-64/NSSwitch.o objs/HP-UX-B.11.23-ia64-64/FileUtil_1.o objs/HP-UX-B.11.23-ia64-64/FileUtil_2.o objs/HP-UX-B.11.23-ia64-64/SecurityThreatCheck.o objs/HP-UX-B.11.23-ia64-64/UserEnumerator.o objs/HP-UX-B.11.23-ia64-64/LocalUserEnumerator.o objs/HP-UX-B.11.23-ia64-64/UnixUserEnumerator.o objs/HP-UX-B.11.23-ia64-64/WinUserEnumerator.o objs/HP-UX-B.11.23-ia64-64/GetEntHandler.o objs/HP-UX-B.11.23-ia64-64/UnixShadowReader.o objs/HP-UX-B.11.23-ia64-64/EtcShadowReader.o objs/HP-UX-B.11.23-ia64-64/UnixEtcShadowReader.o objs/HP-UX-B.11.23-ia64-64/AIXShadowHelper.o objs/HP-UX-B.11.23-ia64-64/HPLoginsShadowHelper.o objs/HP-UX-B.11.23-ia64-64/HPTcbShadowHelper.o objs/HP-UX-B.11.23-ia64-64/UnixHPShadowReader.o objs/HP-UX-B.11.23-ia64-64/ProcessUtil.o objs/HP-UX-B.11.23-ia64-64/FieldUtils.o objs/HP-UX-B.11.23-ia64-64/LoggedInUserInfo.o objs/HP-UX-B.11.23-ia64-64/TcpdRulesParser.o objs/HP-UX-B.11.23-ia64-64/DirectoryUtil.o objs/HP-UX-B.11.23-ia64-64/Timestamp.o objs/HP-UX-B.11.23-ia64-64/Timespan.o objs/HP-UX-B.11.23-ia64-64/NumberFormatter.o objs/HP-UX-B.11.23-ia64-64/DateTimeParser.o objs/HP-UX-B.11.23-ia64-64/DateTimeFormatter.o objs/HP-UX-B.11.23-ia64-64/DateTimeFormat.o objs/HP-UX-B.11.23-ia64-64/DateTime.o objs/HP-UX-B.11.23-ia64-64/Timezone.o objs/HP-UX-B.11.23-ia64-64/LocalDateTime.o objs/HP-UX-B.11.23-ia64-64/RFUtilities.o objs/HP-UX-B.11.23-ia64-64/OpenPortUtil.o objs/HP-UX-B.11.23-ia64-64/AIXStanzaReader.o objs/HP-UX-B.11.23-ia64-64/Bugcheck.o objs/HP-UX-B.11.23-ia64-64/DateTime.o objs/HP-UX-B.11.23-ia64-64/Debugger.o objs/HP-UX-B.11.23-ia64-64/Exception.o objs/HP-UX-B.11.23-ia64-64/GroupEnumerator.o objs/HP-UX-B.11.23-ia64-64/UnixGroupEnumerator.o objs/HP-UX-B.11.23-ia64-64/FileInfoFetcher.o objs/HP-UX-B.11.23-ia64-64/UnixFileInfoAccessor.o objs/HP-UX-B.11.23-ia64-64/FileStatSysCallProcessor.o objs/HP-UX-B.11.23-ia64-64/StatSysCallFileInfoFetcherImpl.o objs/HP-UX-B.11.23-ia64-64/FileInfoAccessor.o objs/HP-UX-B.11.23-ia64-64/FileProcessorObjectFactory.o objs/HP-UX-B.11.23-ia64-64/UUID.o objs/HP-UX-B.11.23-ia64-64/RandomStream.o objs/HP-UX-B.11.23-ia64-64/Random.o objs/HP-UX-B.11.23-ia64-64/SHA1Engine.o objs/HP-UX-B.11.23-ia64-64/DigestEngine.o objs/HP-UX-B.11.23-ia64-64/FileDescriptorUtil.o objs/HP-UX-B.11.23-ia64-64/PasswordInfo.o objs/HP-UX-B.11.23-ia64-64/DictionaryReader.o objs/HP-UX-B.11.23-ia64-64/PasswordCracker.o objs/HP-UX-B.11.23-ia64-64/md5crypt.o -L/unixhome/user/workspace/ontrolShared/UnixReusableClasses/lib/HP-UX-B.11.23-ia64-64 -lReCpp -lReCommon -L/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/lib -lcrypto -L/unixhome/user/workspace/product/lib/HP-UX-B.11.23-ia64-64 -lAgentCommon -lReCoreClasses -lCommonLib  -lsec
> fipsld: THERE=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/..
> fipsld: TARGET=./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
> fipsld: CANISTER_O=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fipscanister.o
> fipsld: PREMAIN_C=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fips_premain.c
> fipsld: PREMAIN_O=objs/HP-UX-B.11.23-ia64-64/fips_premain.o
> fipsld: FIPSLIBDIR=
> fipsld: FIPSLD_CC=aCC
> fipsld: FIPSLD_LINK=aCC
> fipsld: Linking shared library file.
> fipsld: Compiling "/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fips_premain.c".
> fipsld: Linking "./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0" with FIPS libaries.
> 2130621380:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0): Cannot dlopen load module '/usr/lib/hpux32/libpthread.so.1' because it contains thread specific data.
> 2130621380:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244:
> /unixhome/user/workspace/product/Packages/BuildScripts/Makefiles/Make.inc.shlib.rules:73: recipe for target 'objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0' failed
> gmake: *** [objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0] Error 1
> bash-2.05$
> 
> 
> We are running short of time. If anybody has any solutions/suggestions help, would be appreciated.
> 
> Thanks in advance.
> 
> Best regards,
> Mrunal
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From thomas.francis.jr at pobox.com  Wed Feb 25 03:26:18 2015
From: thomas.francis.jr at pobox.com (Tom Francis)
Date: Tue, 24 Feb 2015 22:26:18 -0500
Subject: [openssl-users] FIPS methods and symlinks
In-Reply-To: <20150224214219.3f30e324@mevla>
References: <9234a28fb182c37f5bbcebfc6236fb4a@teksavvy.com>
 <20150224161617.GA32189@openssl.org> <20150224214219.3f30e324@mevla>
Message-ID: <520360E1-DFAA-4019-AB79-66ADF44FEBCC@pobox.com>


> On Feb 24, 2015, at 9:42 PM, jonetsu at teksavvy.com wrote:
> 
> On Tue, 24 Feb 2015 16:16:17 +0000
> "Dr. Stephen Henson" <steve at openssl.org> wrote:
> 
>> On Tue, Feb 24, 2015, jonetsu wrote:
> 
>>> Hello,
>>> 
>>>   To grasp how FIPS methods are called, and following one method
>>> as an example, HMAC_Update() in hmac.c, we can see that if FIPS
>>> mode is active then FIPS_hmac_update() will be called.  This is
>>> fine although searching the sources for the physical definiton of
>>> FIPS_hmac_update() does not yield any results.  How does the
>>> symbolic links function, what ends up being executed in this case
>>> and through which path ?
>> 
>> Function names get changed through fips/fipssyms.h in the FIPS module
>> source.
> 
> Yes, for instance there is:
> 
> #define HMAC_Update FIPS_hmac_update
> 
> My question is about not having found FIPS_hmac_update.  If it is
> called, then where is it ?  May sound like a simple question, although
> grep did not return any actual method.  

You?ll find it in the FIPS Object Module.  But in the source for the FIPS Object Module, it?s called HMAC_Update.  You just need to read the table backwards.  If you want to understand why, think about it a moment.  The module is mostly just a specific, tested, version of OpenSSL?s libcrypto (with extra fluff added, and some stuff removed*).  It was pretty simple** to just keep the source identical (with appropriate #ifdef to control adding in the fluff and removing other things), and then rename all the symbols in the result to avoid duplicate symbols.  It may make it a little harder to follow after the fact, but it?s really not that hard ? HMAC_Update() in your FIPS-capable libcrypto will invoke the renamed HMAC_Update() in the FIPS Object Module when operating in FIPS mode.

Steve Marquess: Is the document (which IIRC, you published back before the first validation) on how/why the FIPS Object Module was coded still available somewhere?  If so, that?d probably be a good starting point for people who post questions like this.  It?s certainly not something that?s easy to figure out if one doesn?t already have an idea of what?s going on. :)

TOM

* That?s probably not the best way to put it, it?s certainly not precise. :)
** Says a guy who in no way contributed to that effort. :)

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


From Isaac.Hailperin at lcsystems.ch  Wed Feb 25 07:57:34 2015
From: Isaac.Hailperin at lcsystems.ch (Isaac Hailperin)
Date: Wed, 25 Feb 2015 07:57:34 +0000
Subject: [openssl-users] building 0.9.8ze with fipscanister on solaris 10
	fails
In-Reply-To: <E47948B37D787D4EA0D3014A45A0D092C80CC5C8@tgw00i-1401.lcsys.ch>
References: <E47948B37D787D4EA0D3014A45A0D092C80CC5C8@tgw00i-1401.lcsys.ch>
Message-ID: <E47948B37D787D4EA0D3014A45A0D092C80CCBDC@tgw00i-1401.lcsys.ch>

Hi,
I am trying to build openssl 0.9.8ze with fipscansiter on solaris 10 (latest patches installed). I configure like this:
./config fipscanisterbuild --prefix=${OPENSSL_BASE} --openssldir=${OPENSSL_BASE} shared

This worked until 0.9.8x, but stopped at 0.9.8y. When I try to build (make), I get

make[2]: Entering directory `/local/src/openssl-0.9.8ze/test'
Undefined                       first referenced
symbol                             in file
CRYPTO_memcmp                       ../fips/fipscanister.o
ld: fatal: symbol referencing errors. No output written to fips_shatest
collect2: ld returned 1 exit status
make[2]: *** [link_app.solaris] Error 1
make[2]: Leaving directory `/local/src/openssl-0.9.8ze/test'

It looks like it is connected to the following change in the code:
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=270881316664396326c461ec7a124aec2c6cc081

Building without the fipscanister option works fine - but client regulations dictate that I use this option.

Does anyone know how I get this to work? What am I missing?

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

From tinkr at openmailbox.org  Wed Feb 25 11:28:26 2015
From: tinkr at openmailbox.org (Tinker)
Date: Wed, 25 Feb 2015 16:58:26 +0530
Subject: [openssl-users]
 =?utf-8?q?Nonblocking_IO=3A_Kindly_need_your_urge?=
 =?utf-8?q?nt_authoritative_confirmation_that_the_OpenSSL_API=27s_SSL=5Fre?=
 =?utf-8?q?ad_and_SSL=5Fwrite_and_select=28=29_must_indeed_be_used_togethe?=
 =?utf-8?q?r_*exactly*_like_this=2C_as_to_keep_us_all_safe_=28from_infinit?=
 =?utf-8?q?e_loop_=26_zombification_bugs=29!?=
In-Reply-To: <5C6941D5-119F-48D1-8668-9D82CF2D3D40@sharp.fm>
References: <2a137ca2abfefca84ae34ecfed991591@openmailbox.org>
 <5C6941D5-119F-48D1-8668-9D82CF2D3D40@sharp.fm>
Message-ID: <e77ba032a6a1980aa5f42a958a0ee538@openmailbox.org>

Hi Graham,

Thank you a lot for your response! -

Just to merge this properly with your previous response to another 
thread this past Sat the 21:st in 
https://mta.openssl.org/pipermail/openssl-users/2015-February/000608.html 
,

It's not just ?I want to read during SSL_write, are you ok with me doing 
this?? but rather "I want to read during SSL_write [nevermind if I tried 
already or not]. Please invoke me next time when there's actual input 
data available, thank you." -

SSL_ERROR_WANTS_READ/WRITE is how OpenSSL says that it needs more data 
on the socket ie asks user to select() with the socket in readfds and 
reinvoke when there is more data, or it wants to write for the socket 
and it's not writable anymore now, so it asks the user to select() with 
the socket in writefds and reinvoke when it's writable, right?


I.e. the if_ready_to_read/if_ready_to_write you suggested below would 
generally be implemented in terms of a select() call.

And then of course, as a caller I'm not obliged to do a select() and 
reiterate but I may do anything, or do another SSL operation such as 
another SSL_read or SSL_shutdown (though supposedly also that one would 
return with the same SSL_ERROR_WANTS_READ/WRITE so that would just be to 
postpone the problem) right?


..And also I suppose this means you confirm that all the points in my 
previous email were correct.

Thanks :)

On 2015-02-24 20:48, Graham Leggett wrote:
> On 22 Feb 2015, at 11:22 PM, Tinker <tinkr at openmailbox.org> wrote:
> 
>> I need your authoritative answer on the following question.
> 
> [snip stuff that is too long]
> 
> You are totally overthinking this.
> 
> The SSL protocol involves negotiation, during which the sender and the
> receiver exchange data with each other. What this means is that during
> either SSL_read, or SSL_write, openssl might try to write or read
> respectively. If your non-blocking code isn?t geared to handle this,
> you might end up either hanging or spinning as you wait for the wrong
> event.
> 
> The SSL_WANTS_READ response code is a warning that means ?I want to
> read during SSL_write, are you ok with me doing this??.
> 
> The SSL_WANTS_WRITE response code is a warning that means ?I want to
> write during SSL_read, are you ok with me doing this??.
> 
> In both cases, once you have determined that it is ok to read, or ok
> to write, you simply retry SSL_write() or SSL_read() again.
> 
> For example, a read loop:
> 
> sense = READ;
> while (sense == READ ? if_ready_to_read() : if_ready_to_write()) {
>     rc = SSL_read();
>     if (rc == SSL_WANT_WRITE) {
>         sense = WRITE;
>     } else {
>         sense = READ;
>     }
>     // do stuff with what you read (you may have read nothing, but
> that?s fine too)
> }
> 
> Regards,
> Graham
> ?
> 
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From tinkr at openmailbox.org  Wed Feb 25 11:56:56 2015
From: tinkr at openmailbox.org (Tinker)
Date: Wed, 25 Feb 2015 17:26:56 +0530
Subject: [openssl-users]
 =?utf-8?q?Nonblocking_IO=3A_Kindly_need_your_urge?=
 =?utf-8?q?nt_authoritative_confirmation_that_the_OpenSSL_API=27s_SSL=5Fre?=
 =?utf-8?q?ad_and_SSL=5Fwrite_and_select=28=29_must_indeed_be_used_togethe?=
 =?utf-8?q?r_*exactly*_like_this=2C_as_to_keep_us_all_safe_=28from_infinit?=
 =?utf-8?q?e_loop_=26_zombification_bugs=29!?=
In-Reply-To: <5C6941D5-119F-48D1-8668-9D82CF2D3D40@sharp.fm>
References: <2a137ca2abfefca84ae34ecfed991591@openmailbox.org>
 <5C6941D5-119F-48D1-8668-9D82CF2D3D40@sharp.fm>
Message-ID: <71741f5e82550b55993043553dd094a0@openmailbox.org>

Wait,

On 2015-02-24 20:48, Graham Leggett wrote:
[..]
> sense = READ;
> while (sense == READ ? if_ready_to_read() : if_ready_to_write()) {
>     rc = SSL_read();
>     if (rc == SSL_WANT_WRITE) {
>         sense = WRITE;
>     } else {
>         sense = READ;
>     }
>     // do stuff with what you read (you may have read nothing, but
> that?s fine too)
> }

Just to clarify and extend your pseudocode example a bit, this is 
absolutely correct right?:

int my_flexible_read_routine(SSL* ssl, int socket,int bytes_needed,int 
bytes_accepted,void* to) {
     reiterate:
     rc = SSL_read(ssl,socket,...);

     if (rc -- SSL_ERROR_WANT_READ) {

         if (i actually need more data from SSL_read ie bytes_needed 
bytes haven't been read yet) {

             // OpenSSL needed more input data from the socket to 
proceed, and it wasn't available. Therefore wait for it to drop in, and 
then reiterate SSL_read();
             select(socket for readability indefinitely);
             if (select said we got new data) goto reiterate; else return 
error;
         }
     } else if (rc -- SSL_ERROR_WANT_WRITE) {
         if (i actually need more data from SSL_read ie bytes_needed 
bytes haven't been read yet) {

             // OpenSSL needed to write more data to socket to proceed, 
than the OS allowed it to do right now. Therefore wait for the socket to 
become writable, and then reiterate SSL_read();
             select(socket for writability indefinitely);
             if (select said the socket is now writable) goto reiterate; 
else return error;
         }
     }

     if (bytes_needed > bytes read) goto reiterate;

     return bytes read;
}


From jaya.nageswar at gmail.com  Wed Feb 25 13:23:15 2015
From: jaya.nageswar at gmail.com (Jaya Nageswar)
Date: Wed, 25 Feb 2015 18:53:15 +0530
Subject: [openssl-users] X509_CINF_dup fails with "invalid object
 encoding" error
In-Reply-To: <CAHrpcJ8uSUyDBbLC31tnjOaKEcUe=H9mf+-k3xQp6kMST1KznQ@mail.gmail.com>
References: <CAHrpcJ8uSUyDBbLC31tnjOaKEcUe=H9mf+-k3xQp6kMST1KznQ@mail.gmail.com>
Message-ID: <CAGdAg4e9C1mDqeSTQtN7orXW1qfDT7DMDAsjTJUvFL1x9H3XaA@mail.gmail.com>

I am also facing the same issue with the openssl 1.0.1l version.

Appreciate if someone can provide their inputs on this particular problem.

Thanks in advance.

Regards,
-Jaya Nageswar.

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150225/2089dbeb/attachment.html>

From marquess at openssl.com  Wed Feb 25 13:29:10 2015
From: marquess at openssl.com (Steve Marquess)
Date: Wed, 25 Feb 2015 08:29:10 -0500
Subject: [openssl-users] FIPS methods and symlinks
In-Reply-To: <520360E1-DFAA-4019-AB79-66ADF44FEBCC@pobox.com>
References: <9234a28fb182c37f5bbcebfc6236fb4a@teksavvy.com>
 <20150224161617.GA32189@openssl.org> <20150224214219.3f30e324@mevla>
 <520360E1-DFAA-4019-AB79-66ADF44FEBCC@pobox.com>
Message-ID: <54EDCE26.4040805@openssl.com>

On 02/24/2015 10:26 PM, Tom Francis wrote:
> ...  
> 
> Steve Marquess: Is the document (which IIRC, you published back
> before the first validation) on how/why the FIPS Object Module was
> coded still available somewhere?  If so, that?d probably be a good
> starting point for people who post questions like this.  It?s
> certainly not something that?s easy to figure out if one doesn?t
> already have an idea of what?s going on. :)

Hmmm ... that's a long time ago (over a dozen years) and TBH I have no
memory of that document. If you can recall a file name or some
distinctive content I could search for it in our extensive internal
archives, but that early history is extensive and convoluted so I doubt
I could find it otherwise. For that first validation it took a lot of
false starts to eventually stumble into an approach the CMVP considered
acceptable.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From steve at openssl.org  Wed Feb 25 13:52:11 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 25 Feb 2015 13:52:11 +0000
Subject: [openssl-users] X509_CINF_dup fails with "invalid object
 encoding" error
In-Reply-To: <CAGdAg4e9C1mDqeSTQtN7orXW1qfDT7DMDAsjTJUvFL1x9H3XaA@mail.gmail.com>
References: <CAHrpcJ8uSUyDBbLC31tnjOaKEcUe=H9mf+-k3xQp6kMST1KznQ@mail.gmail.com>
 <CAGdAg4e9C1mDqeSTQtN7orXW1qfDT7DMDAsjTJUvFL1x9H3XaA@mail.gmail.com>
Message-ID: <20150225135211.GA24094@openssl.org>

On Wed, Feb 25, 2015, Jaya Nageswar wrote:

> I am also facing the same issue with the openssl 1.0.1l version.
> 
> Appreciate if someone can provide their inputs on this particular problem.
> 

OpenSSL 1.0.1l removed some invalid objects from the OID database. This would
create broken encodings. Now you have to initialise OIDs with a valid value
instead of the invalid default "undef" object.

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

From marquess at openssl.com  Wed Feb 25 14:08:00 2015
From: marquess at openssl.com (Steve Marquess)
Date: Wed, 25 Feb 2015 09:08:00 -0500
Subject: [openssl-users] End of the line for the OpenSSL FIPS Object Module?
Message-ID: <54EDD740.70408@openssl.com>

As always, if you don't know or care what FIPS 140-2 is count yourself
very, very lucky and move on.

The open source based OpenSSL FIPS module validations now date back over
a decade, a period during which we've encountered many challenges.
We have recently hit an issue that is apparently inconsequential on its
face, but which threatens to bring an end to the era of the open source
validated module. This is a situation that reminds me of the old "for
want of a nail..." ditty (https://en.wikipedia.org/wiki/For_Want_of_a_Nail).

Tedious details can be found here:

  http://openssl.com/fips/hostage.html

The short take is that for now at least the OpenSSL FIPS Object Module
v2.0, certificate #1747, can no longer be updated to include new
platforms. This development also wrecks the already marginal economics
of tentative plans for a new open source based validation to succeed the
current #1747. So, the #1747 validation may be the last of the
collaborative open source FIPS modules.

If you are a stakeholder currently using the OpenSSL FIPS module, or
with a desire to use it or successor modules (either directly or as the
basis for a "private label" validation), this is the time to speak up.
Feel free to contact me directly for specific suggestions or to
coordinate with other stakeholders.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From dlmeetei at gmail.com  Wed Feb 25 17:27:01 2015
From: dlmeetei at gmail.com (Devchandra L Meetei)
Date: Wed, 25 Feb 2015 22:57:01 +0530
Subject: [openssl-users] Integrating openSSL with libuv's event loop
Message-ID: <CAKmFMKfuz5qxarXRJ-bvfhoPDtULaq1aHYp4eFG0-tBXS4OOcQ@mail.gmail.com>

Hi lists
I am in the process of enabling TLS support on top of libuv.
The approach being employed is to feed the data ,received from stream, to a
BIO from BIO pair.

and write back the data from the BIO read using BIO_read after a call to
BIO_pending.
Will this read/write cycle drive the SSL handshake? Do we need to
explicitly do handshake in case
of server?

Currently, we do SSL_read to read application data manually by checking if
handshake is completed.
Is there a better way to do this? is there a way to get notified?

All the code run on the event loop thread.

The real reason for the mail is that, the approach highlighted above works
fine for a single client.
But it is unable to handle multiple client.
Will somebody please guide me through with what is wrong.

In case, anybody want to have a look at the code. It is available at
https://github.com/deleisha/libuv-tls




-- 
Warm Regards
--Dev
OpenPegasus Developer

"I'm one of those people that think Thomas Edison and the light bulb
changed the world more than Karl Marx ever did," Steve Jobs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150225/587a8903/attachment.html>

From tinkr at openmailbox.org  Wed Feb 25 18:31:08 2015
From: tinkr at openmailbox.org (Tinker)
Date: Thu, 26 Feb 2015 00:01:08 +0530
Subject: [openssl-users] =?utf-8?q?Two_broken_SSL=5FERROR=5FWANT=5FREAD/WR?=
 =?utf-8?q?ITE_handling_examples_-_how_exploit_cpu-hogging_and_zombificati?=
 =?utf-8?q?on=2C_and=2C_how_badly_broken_do_you_consider_them_to_be=3F?=
Message-ID: <e065aa7d498b29a9e1abbd52370db9c5@openmailbox.org>

Dear list,

I have been given two example programs that I have been requested to 
provide exploits for.

I would kindly ask you to suggest me the simplest way to cause as much 
cpu-hogging in the first one, and zombification in the second, as 
possible.

For causing this, you may use

  * As server for it to connect to, any simple unix tool or C script of 
your choice, and

  * You may alter any Linux kernel settings you want, to alterate the 
fwrite() and fread() behavior that OpenSSL gets.

My suggestions for how exploit below, but without exploit scripts.

Also, if you think these are *not explotaible*, please tell!!


Also just for reference, how badly broken do you consider programs that 
do select() in the wrong direction like this to be - do you consider 
them disqualified from any production use?


Thanks!!



(1)

The first program invokes SSL_write only. Its error is that it responds 
to SSL_ERROR_READ by making a select() for writability, which is of 
course basically always there, meaning that when that is the case it 
will.

How would you cause this program to hog as much CPU as possible?

void make_me_hog_cpu_main() {
     [Connects to an SSL server of your choice, sets the SSL in 
nonblocking mode, and does all way up to SSL_connect.]

     char buf[1];
     // Needed?: SSL_write(ssl,buf,1);
     do {
         int r = SSL_write(ssl,buf,0);
         int e = SSL_get_error(ssl,r);
         if ((e == SSL_ERROR_WANT_READ) || (e == SSL_ERROR_WANT_WRITE)) {
             select( with the SSL socket in writefds );
         }
     } while (not EOF yet);
}


I think the way I would do it, would be to make it connect to a dummy 
TCP server that reads all data and throws it away, but never responds 
with any data.


(2)

The second program invokes SSL_read only. Its error is that it responds 
to SSL_ERROR_WRITE by making a select() for readability.

It should be easy to make the select() call never return.

How would you cause this program to zombify?

void make_me_zombify_main() {
     [Connects to an SSL server of your choice, sets the SSL in 
nonblocking mode, and does all way up to SSL_connect.]

     do {
         int r = SSL_read(ssl,buf,1);
         int e = SSL_get_error(ssl,r);
         if ((e == SSL_ERROR_WANT_READ) || (e == SSL_ERROR_WANT_WRITE)) {
             select( with the SSL socket in readfds );
         }
     } while (not EOF yet);
}

I see this one as a bit trickier - what I see is that OpenSSL starts 
with writing 320 bytes on the socket (see strace output below), when 
starting negotiation.

If I somehow would decrease Linux' NIC's MTU, decrease OS write buffers, 
and similar things, to less than 320 bytes so say to 1 byte, then the 
SSL_read SSL negotiation's first fwrite() would not write all 320 bytes 
and thus it would return SSL_ERROR_WRITE and the server would never 
answer anything, at least not before disconnecting, so the select() 
would cause the connection to zombify until it closes.


Thanks!











strace openssl s_connect -host wikipedia.org -port 443 shows:

socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [0], 4) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(443), 
sin_addr=inet_addr("208.80.154.224")}, 16) = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7f9c3e8be000
write(1, "CONNECTED(00000003)\n", 20CONNECTED(00000003)
)   = 20
select(4, [3], [3], NULL, NULL)         = 1 (out [3])
time(NULL)                              = 1424859317
time(NULL)                              = 1424859317
write(3, 
"\26\3\1\1;\1\0\0017\3\3T\355\240\265\341\232v\352N\6\357Q\1\0}\2248\362\332\240\201"..., 
320) = 320
read(3, "\26\3\3\0B\2\0", 7)            = 7
time(NULL)                              = 1424859317
time(NULL)                              = 1424859317
read(3, 
"\0>\3\3T\355\240\265+\246\24\\(\337\214\336\241\356)\33\357\342\217\253\254X\257\267\335\35\233\36"..., 
64) = 64
read(3, "\26\3\3\fT", 5)                = 5
read(3, 
"\v\0\fP\0\fM\0\7\3320\202\7\3260\202\6\276\240\3\2\1\2\2\22\21!\227.2\245\345"..., 
3156) = 1384
read(3, "g\202\rwikipedia.org0\t\6\3U\35\23\4\0020\0000\35\6\3U"..., 
1772) = 1772

From Isaac.Hailperin at lcsystems.ch  Thu Feb 26 12:04:24 2015
From: Isaac.Hailperin at lcsystems.ch (Isaac Hailperin)
Date: Thu, 26 Feb 2015 12:04:24 +0000
Subject: [openssl-users] End of the line for the OpenSSL FIPS Object
 Module?
In-Reply-To: <54EDD740.70408@openssl.com>
References: <54EDD740.70408@openssl.com>
Message-ID: <E47948B37D787D4EA0D3014A45A0D092C80CD040@tgw00i-1401.lcsys.ch>

Steve,

thank you for alerting us.
Do I understand correctly that by "platform", not  a general OS (like "Linux", "Solaris") on a specific hardware (sparc, x86, ...) is meant, but a very specific distribution release, like "Ubuntu 14.04", or "CentOS 7.0", on e.g. x86? This would mean that there would be no fips compliant openssl build possible on e.g. a future "CentOS 8.1"?

We are currently using the fips module on Solaris 10, and have plans to use it on Linux, probably RHEL 7.X, but depending on the time in the future, that could well be RHEL 8.X.

Isaac

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steve Marquess
Sent: Mittwoch, 25. Februar 2015 15:08
To: openssl-users at openssl.org
Subject: [openssl-users] End of the line for the OpenSSL FIPS Object Module?

As always, if you don't know or care what FIPS 140-2 is count yourself very, very lucky and move on.

The open source based OpenSSL FIPS module validations now date back over a decade, a period during which we've encountered many challenges.
We have recently hit an issue that is apparently inconsequential on its face, but which threatens to bring an end to the era of the open source validated module. This is a situation that reminds me of the old "for want of a nail..." ditty (https://en.wikipedia.org/wiki/For_Want_of_a_Nail).

Tedious details can be found here:

  http://openssl.com/fips/hostage.html

The short take is that for now at least the OpenSSL FIPS Object Module v2.0, certificate #1747, can no longer be updated to include new platforms. This development also wrecks the already marginal economics of tentative plans for a new open source based validation to succeed the current #1747. So, the #1747 validation may be the last of the collaborative open source FIPS modules.

If you are a stakeholder currently using the OpenSSL FIPS module, or with a desire to use it or successor modules (either directly or as the basis for a "private label" validation), this is the time to speak up.
Feel free to contact me directly for specific suggestions or to coordinate with other stakeholders.

-Steve M.

--
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From piotr.lobacz at radmor.com.pl  Thu Feb 26 12:37:17 2015
From: piotr.lobacz at radmor.com.pl (Piotr =?UTF-8?Q?=C5=81obacz?=)
Date: Thu, 26 Feb 2015 13:37:17 +0100
Subject: [openssl-users] Fips CTR_DRBG
Message-ID: <1424954237.15035.8.camel@piotr-desktop>

Hello,
i have a question about FIPS CTR_DRBG. I have managed to compile openssl
with fips and everything works fine. The method FIPS_mode returns me 1
so i am in FIPS mode, but what is my problem i dunno how to use properly
FIPS_drbg api. I have managed to create new DRBG context and than i
should instantiate it and here are the ladders showing up, because i
need to call FIPS_drbg_set_callbacks. According to file
openssl-fips-2.0.9/fips/rand/fips_drbg_selftest.c i have created those 2
functions:

static size_t test_entropy(DRBG_CTX *dctx, unsigned char **pout,
                                int entropy, size_t min_len, size_t
max_len)
        {
        TEST_ENT *t = (TEST_ENT*)FIPS_drbg_get_app_data(dctx);
        *pout = (unsigned char *)t->ent;
        t->entcnt++;
        return t->entlen;
        }

static size_t test_nonce(DRBG_CTX *dctx, unsigned char **pout,
                                int entropy, size_t min_len, size_t
max_len)
        {
        TEST_ENT *t = (TEST_ENT*)FIPS_drbg_get_app_data(dctx);
        *pout = (unsigned char *)t->nonce;
        t->noncecnt++;
        return t->noncelen;
        }

and entropy and nonce is being set properly but the result is different
than the one in NIST test vectors. Iam trying to check this one:

[AES-256 use df]
[PredictionResistance = False]
[EntropyInputLen = 256]
[NonceLen = 128]
[PersonalizationStringLen = 0]
[AdditionalInputLen = 0]
[ReturnedBitsLen = 512]

COUNT = 0
EntropyInput =
36401940fa8b1fba91a1661f211d78a0b9389a74e5bccfece8d766af1a6d3b14
Nonce = 496f25b0f1301b4f501be30380a137eb
PersonalizationString = 
** INSTANTIATE:
	Key = 3363d9000e6db47c16d3fc65f2872c08a35f99b2d174afa537a66ec153052d98
	V   = 9ee8d2e9c618ccbb8e66b5eb5333dce1

AdditionalInput = 
** GENERATE (FIRST CALL):
	Key = b1dff09c816af6d4b2111fe63c4507cb196154f8c59957a94a2b641a7c16cc01
	V   = 69eec01b2dd4ff3aab5fac9467f54485

AdditionalInput = 
ReturnedBits =
5862eb38bd558dd978a696e6df164782ddd887e7e9a6c9f3f1fbafb78941b535a64912dfd224c6dc7454e5250b3d97165e16260c2faf1cc7735cb75fb4f07e1d

mine Returned bits are
0a84276ebca04933c92bb9f565dd91819e656009b4d9327edc5c777ee2e05a27d9bfd26ab7a0bf2c689ee358d2982de1b1dff09c816af6d4b2111fe63c4507cb

I would be pleased if somebody could point me what am i doing wrong...
-- 

________________________________________________________________________
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 marquess at openssl.com  Thu Feb 26 13:18:22 2015
From: marquess at openssl.com (Steve Marquess)
Date: Thu, 26 Feb 2015 08:18:22 -0500
Subject: [openssl-users] End of the line for the OpenSSL FIPS Object
	Module?
In-Reply-To: <E47948B37D787D4EA0D3014A45A0D092C80CD040@tgw00i-1401.lcsys.ch>
References: <54EDD740.70408@openssl.com>
 <E47948B37D787D4EA0D3014A45A0D092C80CD040@tgw00i-1401.lcsys.ch>
Message-ID: <54EF1D1E.4020102@openssl.com>

On 02/26/2015 07:04 AM, Isaac Hailperin wrote:
> Steve,
> 
> thank you for alerting us. Do I understand correctly that by
> "platform", not  a general OS (like "Linux", "Solaris") on a specific
> hardware (sparc, x86, ...) is meant, but a very specific distribution
> release, like "Ubuntu 14.04", or "CentOS 7.0", on e.g. x86? This
> would mean that there would be no fips compliant openssl build
> possible on e.g. a future "CentOS 8.1"?

Note the pedantically correct term is "FIPS 140-2 validated", not "FIPS
compliant". But yes, correct.

> We are currently using the fips module on Solaris 10, and have plans
> to use it on Linux, probably RHEL 7.X, but depending on the time in
> the future, that could well be RHEL 8.X.

"Platform" -- technically "Operational Environment" or "OE" -- is a
rather peculiar concept in the context of FIPS 140-2 validations, and
unfortunately one that has never been clearly defined (also one that
changes over time due to ever shifting CMPV "guidance").

Based on observation and the conventional wisdom of the FIPS validation
community, I'll attempt an oversimplified, unofficial,
non-authoritative, non-definitive, and thoroughly worthless definition:

For Level 1 validations, very roughly speaking, an OE is an operating
system name (e.g. "Ubuntu") and the first two dot-rev levels of the
version number (e.g. "14.04" for "14.04.01", "14.04.02", etc.), *and* a
"processor architecture". All x86-64 processors with AES-NI (again
roughly speaking) are the same "processor architecture", as are all
those without (and ditto for ARMv7 and NEON).

32 and 64 code comprise separate "platforms", and a given OS+OS
version+processor architecture+address bit length "platform" running
"bare-iron" constitutes a different "platform" from the exact same
software+hardware combination running virtualized under each distinct
brand name and version of hypervisor environment. So for instance

  Ubuntu 14.04 64bit on Intel Xeon E3-1220 under Vmware ESXi 5.1

is a different "platform" from

  Ubuntu 14.04 64bit on Intel Xeon E3-1220 under Vmware ESXi 5.5

I've left out a number of known exceptions, complications, and anomalies...

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From steve at openssl.org  Thu Feb 26 13:28:47 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 26 Feb 2015 13:28:47 +0000
Subject: [openssl-users] Fips CTR_DRBG
In-Reply-To: <1424954237.15035.8.camel@piotr-desktop>
References: <1424954237.15035.8.camel@piotr-desktop>
Message-ID: <20150226132847.GA2560@openssl.org>

On Thu, Feb 26, 2015, Piotr ??obacz wrote:

> Hello,
> i have a question about FIPS CTR_DRBG. I have managed to compile openssl
> with fips and everything works fine. The method FIPS_mode returns me 1
> so i am in FIPS mode, but what is my problem i dunno how to use properly
> FIPS_drbg api.

If you simply want to use the DRBG in CTR mode then you don't need to do
anything special: in FIPS mode the DRBG in CTR mode with a 256 bit AES key is
the default and you can just use the normal RAND APIs.

Do not use the self test or algorithm test code in applications: you need to
set up proper entropy gathering callbacks and the test code contains
deterministic examples which would have zero security in a real application.
That's what the RAND API will do by default.

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

From piotr.lobacz at radmor.com.pl  Thu Feb 26 14:10:12 2015
From: piotr.lobacz at radmor.com.pl (Piotr =?UTF-8?Q?=C5=81obacz?=)
Date: Thu, 26 Feb 2015 15:10:12 +0100
Subject: [openssl-users] Fips CTR_DRBG
In-Reply-To: <20150226132847.GA2560@openssl.org>
References: <1424954237.15035.8.camel@piotr-desktop>
 <20150226132847.GA2560@openssl.org>
Message-ID: <1424959812.15035.13.camel@piotr-desktop>

Yes,
i have read that RAND API will use CTR_DRBG by default but what if i
want to have set seed and than calculate and have the same results on
two different machines? As far as i understand if i set seed - which is
calculated from entropy, nonce and personal string - if it is given i
should get some deterministic value of returned buffer and RAND_bytes
doesn't give me such result it is always different. Correct me if i am
wrong.

Dnia 2015-02-26, czw o godzinie 13:28 +0000, Dr. Stephen Henson pisze:
> On Thu, Feb 26, 2015, Piotr ??obacz wrote:
> 
> > Hello,
> > i have a question about FIPS CTR_DRBG. I have managed to compile openssl
> > with fips and everything works fine. The method FIPS_mode returns me 1
> > so i am in FIPS mode, but what is my problem i dunno how to use properly
> > FIPS_drbg api.
> 
> If you simply want to use the DRBG in CTR mode then you don't need to do
> anything special: in FIPS mode the DRBG in CTR mode with a 256 bit AES key is
> the default and you can just use the normal RAND APIs.
> 
> Do not use the self test or algorithm test code in applications: you need to
> set up proper entropy gathering callbacks and the test code contains
> deterministic examples which would have zero security in a real application.
> That's what the RAND API will do by default.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 

________________________________________________________________________
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 Isaac.Hailperin at lcsystems.ch  Thu Feb 26 14:35:23 2015
From: Isaac.Hailperin at lcsystems.ch (Isaac Hailperin)
Date: Thu, 26 Feb 2015 14:35:23 +0000
Subject: [openssl-users] End of the line for the OpenSSL FIPS
	Object	Module?
In-Reply-To: <54EF1D1E.4020102@openssl.com>
References: <54EDD740.70408@openssl.com>
 <E47948B37D787D4EA0D3014A45A0D092C80CD040@tgw00i-1401.lcsys.ch>
 <54EF1D1E.4020102@openssl.com>
Message-ID: <E47948B37D787D4EA0D3014A45A0D092C80CD1EE@tgw00i-1401.lcsys.ch>

Thanks, that makes things a lot clearer for me.
Not sure what we will do.

Isaac

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steve Marquess
Sent: Donnerstag, 26. Februar 2015 14:18
To: openssl-users at openssl.org
Subject: Re: [openssl-users] End of the line for the OpenSSL FIPS Object Module?

On 02/26/2015 07:04 AM, Isaac Hailperin wrote:
> Steve,
> 
> thank you for alerting us. Do I understand correctly that by 
> "platform", not  a general OS (like "Linux", "Solaris") on a specific 
> hardware (sparc, x86, ...) is meant, but a very specific distribution 
> release, like "Ubuntu 14.04", or "CentOS 7.0", on e.g. x86? This would 
> mean that there would be no fips compliant openssl build possible on 
> e.g. a future "CentOS 8.1"?

Note the pedantically correct term is "FIPS 140-2 validated", not "FIPS compliant". But yes, correct.

> We are currently using the fips module on Solaris 10, and have plans 
> to use it on Linux, probably RHEL 7.X, but depending on the time in 
> the future, that could well be RHEL 8.X.

"Platform" -- technically "Operational Environment" or "OE" -- is a rather peculiar concept in the context of FIPS 140-2 validations, and unfortunately one that has never been clearly defined (also one that changes over time due to ever shifting CMPV "guidance").

Based on observation and the conventional wisdom of the FIPS validation community, I'll attempt an oversimplified, unofficial, non-authoritative, non-definitive, and thoroughly worthless definition:

For Level 1 validations, very roughly speaking, an OE is an operating system name (e.g. "Ubuntu") and the first two dot-rev levels of the version number (e.g. "14.04" for "14.04.01", "14.04.02", etc.), *and* a "processor architecture". All x86-64 processors with AES-NI (again roughly speaking) are the same "processor architecture", as are all those without (and ditto for ARMv7 and NEON).

32 and 64 code comprise separate "platforms", and a given OS+OS
version+processor architecture+address bit length "platform" running
"bare-iron" constitutes a different "platform" from the exact same
software+hardware combination running virtualized under each distinct
brand name and version of hypervisor environment. So for instance

  Ubuntu 14.04 64bit on Intel Xeon E3-1220 under Vmware ESXi 5.1

is a different "platform" from

  Ubuntu 14.04 64bit on Intel Xeon E3-1220 under Vmware ESXi 5.5

I've left out a number of known exceptions, complications, and anomalies...

-Steve M.

--
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From steve at openssl.org  Thu Feb 26 16:43:41 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 26 Feb 2015 16:43:41 +0000
Subject: [openssl-users] Fips CTR_DRBG
In-Reply-To: <1424959812.15035.13.camel@piotr-desktop>
References: <1424954237.15035.8.camel@piotr-desktop>
 <20150226132847.GA2560@openssl.org>
 <1424959812.15035.13.camel@piotr-desktop>
Message-ID: <20150226164341.GA24957@openssl.org>

On Thu, Feb 26, 2015, Piotr ??obacz wrote:

> Yes,
> i have read that RAND API will use CTR_DRBG by default but what if i
> want to have set seed and than calculate and have the same results on
> two different machines? As far as i understand if i set seed - which is
> calculated from entropy, nonce and personal string - if it is given i
> should get some deterministic value of returned buffer and RAND_bytes
> doesn't give me such result it is always different. Correct me if i am
> wrong.
> 

OK, can you give some details of how you are instantiating the DRBG?

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

From dlmeetei at gmail.com  Thu Feb 26 17:42:58 2015
From: dlmeetei at gmail.com (Devchandra L Meetei)
Date: Thu, 26 Feb 2015 23:12:58 +0530
Subject: [openssl-users] Integrating openSSL with libuv's event loop
In-Reply-To: <CAKmFMKfuz5qxarXRJ-bvfhoPDtULaq1aHYp4eFG0-tBXS4OOcQ@mail.gmail.com>
References: <CAKmFMKfuz5qxarXRJ-bvfhoPDtULaq1aHYp4eFG0-tBXS4OOcQ@mail.gmail.com>
Message-ID: <CAKmFMKf9jccCtYTPemYLsMzr6ewpqBkwrjQVYO3aXSuPg_T=nQ@mail.gmail.com>

Will somebody please kind enough to answer
On Feb 25, 2015 10:57 PM, "Devchandra L Meetei" <dlmeetei at gmail.com> wrote:

> Hi lists
> I am in the process of enabling TLS support on top of libuv.
> The approach being employed is to feed the data ,received from stream, to
> a BIO from BIO pair.
>
> and write back the data from the BIO read using BIO_read after a call to
> BIO_pending.
> Will this read/write cycle drive the SSL handshake? Do we need to
> explicitly do handshake in case
> of server?
>
> Currently, we do SSL_read to read application data manually by checking if
> handshake is completed.
> Is there a better way to do this? is there a way to get notified?
>
> All the code run on the event loop thread.
>
> The real reason for the mail is that, the approach highlighted above works
> fine for a single client.
> But it is unable to handle multiple client.
> Will somebody please guide me through with what is wrong.
>
> In case, anybody want to have a look at the code. It is available at
> https://github.com/deleisha/libuv-tls
>
>
>
>
> --
> Warm Regards
> --Dev
> OpenPegasus Developer
>
> "I'm one of those people that think Thomas Edison and the light bulb
> changed the world more than Karl Marx ever did," Steve Jobs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150226/8234c051/attachment.html>

From noloader at gmail.com  Fri Feb 27 02:24:41 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 26 Feb 2015 21:24:41 -0500
Subject: [openssl-users] End of the line for the OpenSSL FIPS Object
	Module?
In-Reply-To: <54EDD740.70408@openssl.com>
References: <54EDD740.70408@openssl.com>
Message-ID: <CAH8yC8=VpYFk-oy0m7Xt+5jRUqxLJeAd6AK3+6u07ZUa6Ugi-Q@mail.gmail.com>

Hi Steve,

I read the 'The FIPS 140-2 "Hostage" Issue' page. Its not clear to me
what the problem is, or how OpenSSL is a hostage.

I was looking under "The New Requirement" for a statement of the
problem (assuming the new requirement is causing the problem), but its
escaping me (forgive my ignorance). I think the "The New Requirement "
section is bogged down with some background information, which is
masking out the statement being made about the problem.

If its "... the change that is being demanded is that we supply
explicit version numbers for the hypervisor based platforms, so for
instance an existing platform", then why is that a problem?

How is virtualization a problem? (I know real problems exist in
virtualized environments, so PRNGs can suffer. We had one appliance
vendor tell us to do the "link /dev/random to /dev/urandom trick"
(sigh...)).

Can't that be worked around by having vendors provide real iron? (Most
validated platforms appear to be real iron, so it seems nothing has
changed to me).

Is it a problem on mobile platforms?

How is it holding OpenSSL hostage?

Can you provide the executive summary here?

Jeff

On Wed, Feb 25, 2015 at 9:08 AM, Steve Marquess <marquess at openssl.com> wrote:
> As always, if you don't know or care what FIPS 140-2 is count yourself
> very, very lucky and move on.
>
> The open source based OpenSSL FIPS module validations now date back over
> a decade, a period during which we've encountered many challenges.
> We have recently hit an issue that is apparently inconsequential on its
> face, but which threatens to bring an end to the era of the open source
> validated module. This is a situation that reminds me of the old "for
> want of a nail..." ditty (https://en.wikipedia.org/wiki/For_Want_of_a_Nail).
>
> Tedious details can be found here:
>
>   http://openssl.com/fips/hostage.html
>
> The short take is that for now at least the OpenSSL FIPS Object Module
> v2.0, certificate #1747, can no longer be updated to include new
> platforms. This development also wrecks the already marginal economics
> of tentative plans for a new open source based validation to succeed the
> current #1747. So, the #1747 validation may be the last of the
> collaborative open source FIPS modules.
>
> If you are a stakeholder currently using the OpenSSL FIPS module, or
> with a desire to use it or successor modules (either directly or as the
> basis for a "private label" validation), this is the time to speak up.
> Feel free to contact me directly for specific suggestions or to
> coordinate with other stakeholders.
>
> -Steve M.

From zakkir.kharim at gmail.com  Fri Feb 27 05:16:53 2015
From: zakkir.kharim at gmail.com (zakkir hussain Kharim)
Date: Fri, 27 Feb 2015 10:46:53 +0530
Subject: [openssl-users] openssl_tpm_engine - create_tpm_key failed when
	tried to wrap key
Message-ID: <CAP0K13-FoyycEVXhuVKh+y4yT72a==2Wjv4uC+dYi3LxOw0jkA@mail.gmail.com>

*Problem*

We are trying to wrap a private key using storage root key using the
"create_tpm_key" tool which is part of openssl tpm engine. But it is
failing. We tried to debug this in multiple ways, but not able to
understand what is wrong*.  * We are trying to wrap using Storage root key.
Input private key is a 2048 bit length RSA key without any passphrase. The
failure seems to related to getting public key of SRK from the SRK handle
loaded.







*Command Executed:*

# create_tpm_key -w private.pem rsmpvtkey.blob

SRK Password:



################################### result=12

create_tpm_key.c:444 Tspi_Key_WrapKey result: 0xc (Invalid keyhandle)





*TPM trousers code:*



 File: tspi/tspi_key.c

 Function : Tspi_Key_GetPubKey





        if ((result = TCS_API(tspContext)->GetPubKey(tspContext,
tcsKeyHandle, pAuth,

                                                     pulPubKeyLength,
prgbPubKey)))

          {

               printf("\n ###################################
result=%d\n",result);

                return result;   // returns value 12

          }





*Version details:*

trousers-0.3.13

openssl_tpm_engine-0.4.2

tpm-tools-1.3.8





*tpm version*

  TPM 1.2 Version Info:

  Chip Version:        1.2.3.16

  Spec Level:          2

  Errata Revision:     2

  TPM Vendor ID:       IFX

  Vendor Specific data: 0310000a 00

  TPM Version:         01010000





Thanks and Regards

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

From piotr.lobacz at radmor.com.pl  Fri Feb 27 06:35:43 2015
From: piotr.lobacz at radmor.com.pl (Piotr =?UTF-8?Q?=C5=81obacz?=)
Date: Fri, 27 Feb 2015 07:35:43 +0100
Subject: [openssl-users] Fips CTR_DRBG
In-Reply-To: <20150226164341.GA24957@openssl.org>
References: <1424954237.15035.8.camel@piotr-desktop>
 <20150226132847.GA2560@openssl.org>
 <1424959812.15035.13.camel@piotr-desktop>
 <20150226164341.GA24957@openssl.org>
Message-ID: <1425018943.3946.1.camel@piotr-desktop>

I can do mutch more i can give the source code:

#include <iostream>
using std::cout;
using std::endl;
#include <stdlib.h>
#include <openssl/evp.h>
#include <openssl/err.h>
#include <fips/fips_rand.h>
#include <fips/fips_rand_lcl.h>
#include <openssl/rand.h>
#include <string.h>

typedef struct 
        {
        const unsigned char *ent;
        size_t entlen;
        int entcnt;
        const unsigned char *nonce;
        size_t noncelen;
        int noncecnt;
        } TEST_ENT;


static unsigned char dummy_drbg_entropy[1024];

static unsigned char entropy_x[32];
static unsigned char nonce[16];


static size_t test_entropy(DRBG_CTX *dctx, unsigned char **pout,
                                int entropy, size_t min_len, size_t
max_len)
        {
        TEST_ENT *t = (TEST_ENT*)FIPS_drbg_get_app_data(dctx);
        *pout = (unsigned char *)t->ent;
        t->entcnt++;
        return t->entlen;
        }

static size_t test_nonce(DRBG_CTX *dctx, unsigned char **pout,
                                int entropy, size_t min_len, size_t
max_len)
        {
        TEST_ENT *t = (TEST_ENT*)FIPS_drbg_get_app_data(dctx);
        *pout = (unsigned char *)t->nonce;
        t->noncecnt++;
        return t->noncelen;
        }

int main(int argc, char* argv[])
{
    int rc, mode;

    mode = FIPS_mode();
    if(mode == 0)
    {
        rc = FIPS_mode_set(1);
        if(rc == 0) {
            cout << "Failed to enable FIPS mode, ";
            cout << "error: " << ERR_get_error() << endl;
        } else {
            cout << "Enabled FIPS mode" << endl;
        }
    }
    else
    {
        cout << "Already in FIPS mode" << endl;
    }

	  DRBG_CTX *dctx;
	  dctx = FIPS_drbg_new(NID_aes_256_ctr, DRBG_FLAG_CTR_USE_DF);

	  unsigned char entropytmp[] =
	  {
		0x36, 0x40, 0x19, 0x40, 0xfa, 0x8b, 0x1f, 0xba,
		0x91, 0xa1, 0x66, 0x1f, 0x21, 0x1d, 0x78, 0xa0,
		0xb9, 0x38, 0x9a, 0x74, 0xe5, 0xbc, 0xcf, 0xec,
		0xe8, 0xd7, 0x66, 0xaf, 0x1a, 0x6d, 0x3b, 0x14
	  };

	  unsigned char noncetmp[] =
	  {
		0x49, 0x6f, 0x25, 0xb0, 0xf1, 0x30, 0x1b, 0x4f,
		0x50, 0x1b, 0xe3, 0x03, 0x80, 0xa1, 0x37, 0xeb
	  };
	/* AES-256 use df PR  */


	std::cout << FIPS_drbg_get_strength(dctx) << " " <<
FIPS_rand_strength() << std::endl;

	  //if (!FIPS_drbg_set_callbacks(dctx, drbg_test_entropy, 0, 0x10,
drbg_test_nonce, 0))
	  if (!FIPS_drbg_set_callbacks(dctx, test_entropy, 0, 0, test_nonce,
0))
	  {
		  std::cout << "dupa" << std::endl;
	  }
	  
	  //memcpy(entropy_x, entropytmp, sizeof(entropy_x));
	 // memcpy(nonce, noncetmp, sizeof(nonce));
	
	TEST_ENT t;

        FIPS_drbg_set_app_data(dctx, &t);

        t.ent = entropytmp;
        t.entlen = sizeof(entropytmp);
        t.nonce = noncetmp;
        t.noncelen = sizeof(noncetmp);
        t.entcnt = 0;
        t.noncecnt = 0;

       


	  //FIPS_drbg_instantiate(dctx, pers, sizeof(pers));
	  if (!FIPS_drbg_instantiate(dctx, NULL, 0))
	  {
	     ERR_load_crypto_strings();
	     ERR_print_errors(BIO_new_fp(stderr,BIO_NOCLOSE));
	  }

	  size_t outlen = 32;
	  unsigned char outbuf[outlen];

	  if(!FIPS_drbg_generate(dctx, outbuf, outlen, 0, NULL, 0))
	  {
	     ERR_load_crypto_strings();
	     ERR_print_errors(BIO_new_fp(stderr,BIO_NOCLOSE));

	  }

	  FIPS_drbg_uninstantiate(dctx);
	  FIPS_drbg_free(dctx);

    return 0;
      * }



Dnia 2015-02-26, czw o godzinie 16:43 +0000, Dr. Stephen Henson pisze:
> On Thu, Feb 26, 2015, Piotr ??obacz wrote:
> 
> > Yes,
> > i have read that RAND API will use CTR_DRBG by default but what if i
> > want to have set seed and than calculate and have the same results on
> > two different machines? As far as i understand if i set seed - which is
> > calculated from entropy, nonce and personal string - if it is given i
> > should get some deterministic value of returned buffer and RAND_bytes
> > doesn't give me such result it is always different. Correct me if i am
> > wrong.
> > 
> 
> OK, can you give some details of how you are instantiating the DRBG?
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 

________________________________________________________________________
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 jb-openssl at wisemo.com  Fri Feb 27 06:56:07 2015
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 27 Feb 2015 07:56:07 +0100
Subject: [openssl-users] End of the line for the OpenSSL FIPS Object
	Module?
In-Reply-To: <CAH8yC8=VpYFk-oy0m7Xt+5jRUqxLJeAd6AK3+6u07ZUa6Ugi-Q@mail.gmail.com>
References: <54EDD740.70408@openssl.com>
 <CAH8yC8=VpYFk-oy0m7Xt+5jRUqxLJeAd6AK3+6u07ZUa6Ugi-Q@mail.gmail.com>
Message-ID: <54F01507.8020402@wisemo.com>

I think it was clear enough:

NIST/NSA/CMVP is demanding that OpenSSL change the
definition of*already* "validated" platforms before they
will allow OpenSSL to addnew platforms.

But changing those definitions would invalidate existing
governmentcontracts for delivery of products that used
the OpenSSL FIPS moduleon those platforms, so the users
that actually need the FIPS validationwill be hurt
either way.

For example, if company X has an existing contract where
they promisethat the foo system they delivered to some
US Government agencyuses only crypto code which was
validated for "Red Hat EnterpriseLinux 7.0 (x86_64)
running on VmWare ESX", then if OpenSSL obeysthe
demand to change the definition to read "Red Hat
EnterpriseLinux 7.0 (x86_64) running on VmWare ESX
5.1", then company Xwould suddenly be unable to
fulfill their contract, which may evenbe a criminal
offense.  But if OpenSSL refuses to change the
definition, OpenSSL cannot deliver to company X a
new validationfor "Apple OS/X 10.8 (x86_64) running
on raw Apple hardware",so company X cannot get a new
government contract to deliver forthat platform, and
neither can anybody else.

So currently, OpenSSL's realistic options are:

A. Wait for someone to convince the US Government to
   drop thisretroactive requirement.
B. Start over with a new validation for a new FIPS
   module version 3, whichwould have to be modified
   to meet other new demands, whichdidn't exist when
   FIPS module version 2 was originally submitted.
    This would involve 2 variants of the FIPS interface
   code in OpenSSL1.0.3, lots of new code and a very
   very expensive bill to get thecode validated all
   over again.

On 27/02/2015 03:24, Jeffrey Walton wrote:
> Hi Steve,
>
> I read the 'The FIPS 140-2 "Hostage" Issue' page. Its not clear to me
> what the problem is, or how OpenSSL is a hostage.
>
> I was looking under "The New Requirement" for a statement of the
> problem (assuming the new requirement is causing the problem), but its
> escaping me (forgive my ignorance). I think the "The New Requirement "
> section is bogged down with some background information, which is
> masking out the statement being made about the problem.
>
> If its "... the change that is being demanded is that we supply
> explicit version numbers for the hypervisor based platforms, so for
> instance an existing platform", then why is that a problem?
>
> How is virtualization a problem? (I know real problems exist in
> virtualized environments, so PRNGs can suffer. We had one appliance
> vendor tell us to do the "link /dev/random to /dev/urandom trick"
> (sigh...)).
>
> Can't that be worked around by having vendors provide real iron? (Most
> validated platforms appear to be real iron, so it seems nothing has
> changed to me).
>
> Is it a problem on mobile platforms?
>
> How is it holding OpenSSL hostage?
>
> Can you provide the executive summary here?
>
> Jeff
>
> On Wed, Feb 25, 2015 at 9:08 AM, Steve Marquess <marquess at openssl.com> wrote:
>> As always, if you don't know or care what FIPS 140-2 is count yourself
>> very, very lucky and move on.
>>
>> The open source based OpenSSL FIPS module validations now date back over
>> a decade, a period during which we've encountered many challenges.
>> We have recently hit an issue that is apparently inconsequential on its
>> face, but which threatens to bring an end to the era of the open source
>> validated module. This is a situation that reminds me of the old "for
>> want of a nail..." ditty (https://en.wikipedia.org/wiki/For_Want_of_a_Nail).
>>
>> Tedious details can be found here:
>>
>>    http://openssl.com/fips/hostage.html
>>
>> The short take is that for now at least the OpenSSL FIPS Object Module
>> v2.0, certificate #1747, can no longer be updated to include new
>> platforms. This development also wrecks the already marginal economics
>> of tentative plans for a new open source based validation to succeed the
>> current #1747. So, the #1747 validation may be the last of the
>> collaborative open source FIPS modules.
>>
>> If you are a stakeholder currently using the OpenSSL FIPS module, or
>> with a desire to use it or successor modules (either directly or as the
>> basis for a "private label" validation), this is the time to speak up.
>> Feel free to contact me directly for specific suggestions or to
>> coordinate with other stakeholders.
>>
>> -Steve M.

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/20150227/aa7079ae/attachment.html>

From steve at openssl.org  Fri Feb 27 12:54:46 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 27 Feb 2015 12:54:46 +0000
Subject: [openssl-users] Fips CTR_DRBG
In-Reply-To: <1425018943.3946.1.camel@piotr-desktop>
References: <1424954237.15035.8.camel@piotr-desktop>
 <20150226132847.GA2560@openssl.org>
 <1424959812.15035.13.camel@piotr-desktop>
 <20150226164341.GA24957@openssl.org>
 <1425018943.3946.1.camel@piotr-desktop>
Message-ID: <20150227125446.GA18616@openssl.org>

On Fri, Feb 27, 2015, Piotr ??obacz wrote:

> I can do mutch more i can give the source code:
> 
> 	  dctx = FIPS_drbg_new(NID_aes_256_ctr, DRBG_FLAG_CTR_USE_DF);
> 

Try including the flag DRBG_FLAG_TEST: the DRBG needs to be in test mode
otherwise the continuous PRNG test discards the first block generated.

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

From piotr.lobacz at radmor.com.pl  Fri Feb 27 13:24:25 2015
From: piotr.lobacz at radmor.com.pl (Piotr =?UTF-8?Q?=C5=81obacz?=)
Date: Fri, 27 Feb 2015 14:24:25 +0100
Subject: [openssl-users] Fips CTR_DRBG
In-Reply-To: <20150227125446.GA18616@openssl.org>
References: <1424954237.15035.8.camel@piotr-desktop>
 <20150226132847.GA2560@openssl.org>
 <1424959812.15035.13.camel@piotr-desktop>
 <20150226164341.GA24957@openssl.org>
 <1425018943.3946.1.camel@piotr-desktop>
 <20150227125446.GA18616@openssl.org>
Message-ID: <1425043465.3946.3.camel@piotr-desktop>

Thanks a lot, adding this flag did the trick. The returned block is
identical as the expected.

Dnia 2015-02-27, pi? o godzinie 12:54 +0000, Dr. Stephen Henson pisze:
> On Fri, Feb 27, 2015, Piotr ??obacz wrote:
> 
> > I can do mutch more i can give the source code:
> > 
> > 	  dctx = FIPS_drbg_new(NID_aes_256_ctr, DRBG_FLAG_CTR_USE_DF);
> > 
> 
> Try including the flag DRBG_FLAG_TEST: the DRBG needs to be in test mode
> otherwise the continuous PRNG test discards the first block generated.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 

________________________________________________________________________
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 marquess at openssl.com  Fri Feb 27 13:40:06 2015
From: marquess at openssl.com (Steve Marquess)
Date: Fri, 27 Feb 2015 08:40:06 -0500
Subject: [openssl-users] End of the line for the OpenSSL FIPS Object
	Module?
In-Reply-To: <CAH8yC8=VpYFk-oy0m7Xt+5jRUqxLJeAd6AK3+6u07ZUa6Ugi-Q@mail.gmail.com>
References: <54EDD740.70408@openssl.com>
 <CAH8yC8=VpYFk-oy0m7Xt+5jRUqxLJeAd6AK3+6u07ZUa6Ugi-Q@mail.gmail.com>
Message-ID: <54F073B6.5020804@openssl.com>

On 02/26/2015 09:24 PM, Jeffrey Walton wrote:
> Hi Steve,
> 
> I read the 'The FIPS 140-2 "Hostage" Issue' page. Its not clear to me
> what the problem is, ...

I have failed miserably in my objective then, as that web page is an
attempt to explain a complex and important issue. It's always a struggle
to succinctly explain the Alice-in-Wonderland world of FIPS 140-2 to
those haven't spent way too many years exposed to it.

> ...or how OpenSSL is a hostage.

The hostages are those vendors (such as Vendor "X") who have funded past
platform validations, or those vendors (such as Vendor "Y") who would
like to add new platforms. We were put in the painful position of
sacrificing one set of hostages or the other.

> I was looking under "The New Requirement" for a statement of the
> problem (assuming the new requirement is causing the problem), but its
> escaping me (forgive my ignorance). I think the "The New Requirement "
> section is bogged down with some background information, which is
> masking out the statement being made about the problem.
> 
> If its "... the change that is being demanded is that we supply
> explicit version numbers for the hypervisor based platforms, so for
> instance an existing platform", then why is that a problem?

I discuss that in the last three paragraphs of section 3, which I've
re-read just now. Perhaps I should elaborate more on the fine print and
process issues with government procurement paperwork (which may not be
fully appreciated by those who haven't suffered though it). Or perhaps I
should expand the penultimate paragraph to emphasize that vendor "X" and
"Y" paid money to have platforms added to the OpenSSL FIPS module, and
that as with all such sponsors we try to respect those investments?

> How is virtualization a problem? (I know real problems exist in
> virtualized environments, so PRNGs can suffer. We had one appliance
> vendor tell us to do the "link /dev/random to /dev/urandom trick"
> (sigh...)).
> 
> Can't that be worked around by having vendors provide real iron? (Most
> validated platforms appear to be real iron, so it seems nothing has
> changed to me).
> 
> Is it a problem on mobile platforms?
> 
> How is it holding OpenSSL hostage?
> 
> Can you provide the executive summary here?

Hmmm...

I'm at a bit of a loss here and find myself tempted to just repeat what
is already there. I will try to say something different here:

Many companies -- hundreds of them -- have used the OpenSSL FIPS modules
at little or no cost. That was the intent, that is open source goodness.

The validated module is generally useful to an end user only to the
extent that it includes "platforms" of interest to that end user.
"Platforms" can (or could) be added to existing validations relatively
inexpensively, and once added become accessible to everyone. More open
source goodness.

Those validations are difficult and expensive. They have to be paid for
somehow. The bulk of the funding has come from the "change letter"
updates that add new platforms. The OpenSSL FIPS module validations have
thus largely been "self funded" by the community of users.

The CMVP continually changes the requirements for new validations, but
until recently has not retroactively imposed crippling changes on
existing validations. They have started to do so, twice now in 12
months, preventing the addition of new platforms.

If new platforms cannot be added to those hard-won validations, the
overall utility to the end user community is greatly reduced. Even
worse, the pursuit of new validations becomes economically infeasible.

I'm open to suggestions on improving that web page for the TL;DR crowd.
"Make it clearer" may not be enough as I've already attempted and failed
at that.  Specific suggested edits perhaps?

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From kgoldman at us.ibm.com  Fri Feb 27 13:53:37 2015
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Fri, 27 Feb 2015 08:53:37 -0500
Subject: [openssl-users] openssl_tpm_engine - create_tpm_key failed when
 tried to wrap key
In-Reply-To: <CAP0K13-FoyycEVXhuVKh+y4yT72a==2Wjv4uC+dYi3LxOw0jkA@mail.gmail.com>
References: <CAP0K13-FoyycEVXhuVKh+y4yT72a==2Wjv4uC+dYi3LxOw0jkA@mail.gmail.com>
Message-ID: <mcpst0$o77$1@ger.gmane.org>

I don't know  trousers very well, but there is a mailing list 
specifically for it.

trousers supports the software TPM from

	http://sourceforge.net/projects/ibmswtpm/

If you run with that, it traces the TPM operation in detail.  Send me 
the trace and I can probably tell you what's wrong.

On 2/27/2015 12:16 AM, zakkir hussain Kharim wrote:
> *Problem*
>
> We are trying to wrap a private key using storage root key using the
> "create_tpm_key" tool which is part of openssl tpm engine. But it is
> failing. We tried to debug this in multiple ways, but not able to
> understand what is wrong*. * We are trying to wrap using Storage root
> key. Input private key is a 2048 bit length RSA key without any
> passphrase. The failure seems to related to getting public key of SRK
> from the SRK handle loaded.



From marquess at openssl.com  Fri Feb 27 14:01:05 2015
From: marquess at openssl.com (Steve Marquess)
Date: Fri, 27 Feb 2015 09:01:05 -0500
Subject: [openssl-users] End of the line for the OpenSSL FIPS Object
	Module?
In-Reply-To: <54F01507.8020402@wisemo.com>
References: <54EDD740.70408@openssl.com>
 <CAH8yC8=VpYFk-oy0m7Xt+5jRUqxLJeAd6AK3+6u07ZUa6Ugi-Q@mail.gmail.com>
 <54F01507.8020402@wisemo.com>
Message-ID: <54F078A1.5010901@openssl.com>

On 02/27/2015 01:56 AM, Jakob Bohm wrote:
> I think it was clear enough:
> 
> NIST/NSA/CMVP is demanding that OpenSSL change the
> definition of*already* "validated" platforms before they
> will allow OpenSSL to addnew platforms.
> 
> But changing those definitions would invalidate existing
> governmentcontracts for delivery of products that used
> the OpenSSL FIPS moduleon those platforms, so the users
> that actually need the FIPS validationwill be hurt
> either way.
> 
> For example, if company X has an existing contract where
> they promisethat the foo system they delivered to some
> US Government agencyuses only crypto code which was
> validated for "Red Hat EnterpriseLinux 7.0 (x86_64)
> running on VmWare ESX", then if OpenSSL obeysthe
> demand to change the definition to read "Red Hat
> EnterpriseLinux 7.0 (x86_64) running on VmWare ESX
> 5.1", then company Xwould suddenly be unable to
> fulfill their contract, which may evenbe a criminal
> offense.  But if OpenSSL refuses to change the
> definition, OpenSSL cannot deliver to company X a
> new validationfor "Apple OS/X 10.8 (x86_64) running
> on raw Apple hardware",so company X cannot get a new
> government contract to deliver forthat platform, and
> neither can anybody else.

Jakob, you nailed it. Do you mind if I add that explanation as a
footnote (with attribution)?

I've spent so long in the government arena I forget that not everyone
realizes how arduous the procurement process can be, or how rigid and
inflexible.

> 
> So currently, OpenSSL's realistic options are:
> 
> A. Wait for someone to convince the US Government to
>   drop thisretroactive requirement.

Which we are doing, and I do expect this latest retroactive requirement
to be rescinded eventually (as happened before in early 2014). However,
once again the delay has a severe short term cost for the sponsors of
pending new platforms.

> B. Start over with a new validation for a new FIPS
>   module version 3, whichwould have to be modified
>   to meet other new demands, whichdidn't exist when
>   FIPS module version 2 was originally submitted.

We do want to begin a new validation to address all the new requirements
that have accumulated since the #1747 validation was awarded in 2012.
But, while platform sponsors are easy to find, sponsors for the big pain
and big bucks of new validations are not.

We *may* have such sponsorship, at long last, but both we and those
sponsor(s) realize that our plans for that new validation have assumed
that we would be able to extend it indefinitely with change letter
updates (as has traditionally been the case). With that assumption now
in doubt the validation effort becomes economically infeasible for OSF,
as we'll take a loss on the validation itself that could only be
recouped via subsequent change letters. Likewise, the sponsor(s) had
planned on leveraging their substantial investment over time by adding
new platforms as needed.

>    This would involve 2 variants of the FIPS interface
>   code in OpenSSL1.0.3, lots of new code and a very
>   very expensive bill to get thecode validated all
>   over again.

Very expensive indeed -- well into six figures -- but the platform
validation costs are typically spread over a large number of platform
sponsors. Each prospective platform sponsor is reminded that if they are
willing to wait long enough some other sponsor may do that platform for
them; but I've found that the platform sponsors are usually delighted to
have the option of paying themselves for a platform validation now
rather than waiting indefinitely. Those sponsors usually have pending
sales that easily justify the platform validation costs.

The hard part has always been funding the initial new validation.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From lionkimbro at gmail.com  Fri Feb 27 18:23:22 2015
From: lionkimbro at gmail.com (Lion Kimbro)
Date: Fri, 27 Feb 2015 18:23:22 +0000
Subject: [openssl-users] Getting General SSL Help
Message-ID: <CAEmWhShR816GGEzLMHX+YJF4=tO1EfCcDBNKjBW0feEvbJ0=9Q@mail.gmail.com>

Hello, thank you.

I'm wondering:  Where can I go to get answers to basic questions about
SSL?  I've been learning about SSL while using OpenSSL to make SSL
certificates for work, and I have a lot of questions.

For example, one of my questions is:
"Why are certificates called certificate *requests*?"  I would think that a
request for a certificate would be a message on the order of [a machine
encoded:] "Hello would you please send me your certificate?", or "Hello,
would you please send me your certificate for example.net?"

Instead, I find that a certificate request (crt) is an actual certificate
file?

I'm having difficulty finding in my research, answers to basic questions
like this.  What's a good forum on the Internet for finding answers to more
fundamental SSL questions like this?

Thank you,
  Lion Kimbro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150227/d1b8136c/attachment.html>

From reichert at numachi.com  Fri Feb 27 18:31:28 2015
From: reichert at numachi.com (Brian Reichert)
Date: Fri, 27 Feb 2015 13:31:28 -0500
Subject: [openssl-users] has anyone developed a standalone test for
	CVE-2014-8730?
Message-ID: <20150227183128.GC44176@numachi.com>

I've found one on-line tester for CVE-2014-8730 here:

  https://www.ssllabs.com/ssltest/

But, I was looking for an offline test I could perform in our dev
environment.

Does anyone know of one?  I've had no luck as of yet...

-- 
Brian Reichert				<reichert at numachi.com>
BSD admin/developer at large	

From Michael.Wojcik at microfocus.com  Fri Feb 27 19:55:32 2015
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 27 Feb 2015 19:55:32 +0000
Subject: [openssl-users] Getting General SSL Help
In-Reply-To: <CAEmWhShR816GGEzLMHX+YJF4=tO1EfCcDBNKjBW0feEvbJ0=9Q@mail.gmail.com>
References: <CAEmWhShR816GGEzLMHX+YJF4=tO1EfCcDBNKjBW0feEvbJ0=9Q@mail.gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C180880134531D09@Rock-Exchange1.microfocus.com>

Eric Rescorla's book SSL and TLS is a good start. There are many online references and tutorials, but I can't say I've found any I'm especially fond of. SSL and TLS is now quite old (unless he's written a new edition; the one I have is from 2001), but TLS 1.2 is not so terribly different from 1.0 as to make the book misleading. Basically the past fourteen years have seen some protocol tweaks and suites with new cryptographic primitives (ciphers, digests, combining modes, etc). These have important security ramifications but don't introduce major new conceptual matters.



To answer your specific question below: certificates are not called certificate requests. Those are two different things. A certificate request is a message sent to a CA asking it to generate a signed certificate.



________________________________
From: openssl-users [openssl-users-bounces at openssl.org] on behalf of Lion Kimbro [lionkimbro at gmail.com]
Sent: Friday, February 27, 2015 1:23 PM
To: openssl-users at openssl.org
Subject: [openssl-users] Getting General SSL Help

Hello, thank you.

I'm wondering:  Where can I go to get answers to basic questions about SSL?  I've been learning about SSL while using OpenSSL to make SSL certificates for work, and I have a lot of questions.

For example, one of my questions is:
"Why are certificates called certificate requests?"  I would think that a request for a certificate would be a message on the order of [a machine encoded:] "Hello would you please send me your certificate?", or "Hello, would you please send me your certificate for example.net<http://example.net>?"

Instead, I find that a certificate request (crt) is an actual certificate file?

I'm having difficulty finding in my research, answers to basic questions like this.  What's a good forum on the Internet for finding answers to more fundamental SSL questions like this?

Thank you,
  Lion Kimbro




Click here<https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==> to report this email as spam.


This message has been scanned for malware by Websense. www.websense.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150227/d06dd2e9/attachment.html>

From matt at openssl.org  Fri Feb 27 20:08:02 2015
From: matt at openssl.org (Matt Caswell)
Date: Fri, 27 Feb 2015 20:08:02 +0000
Subject: [openssl-users] Getting General SSL Help
In-Reply-To: <CAEmWhShR816GGEzLMHX+YJF4=tO1EfCcDBNKjBW0feEvbJ0=9Q@mail.gmail.com>
References: <CAEmWhShR816GGEzLMHX+YJF4=tO1EfCcDBNKjBW0feEvbJ0=9Q@mail.gmail.com>
Message-ID: <54F0CEA2.9000509@openssl.org>



On 27/02/15 18:23, Lion Kimbro wrote:
> Hello, thank you.
> 
> I'm wondering:  Where can I go to get answers to basic questions about
> SSL?  I've been learning about SSL while using OpenSSL to make SSL
> certificates for work, and I have a lot of questions.

I can recommend Ivan Ristic's book "Bulletproof SSL and TLS".

Matt


From rsalz at akamai.com  Fri Feb 27 20:05:30 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 27 Feb 2015 20:05:30 +0000
Subject: [openssl-users] Getting General SSL Help
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C180880134531D09@Rock-Exchange1.microfocus.com>
References: <CAEmWhShR816GGEzLMHX+YJF4=tO1EfCcDBNKjBW0feEvbJ0=9Q@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C180880134531D09@Rock-Exchange1.microfocus.com>
Message-ID: <bff292cd9fde44d6b37f4be90c2991c2@ustx2ex-dag1mb2.msg.corp.akamai.com>

I like https://www.feistyduck.com/

--
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me<mailto:rsalz at jabber.me> Twitter: RichSalz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150227/c9162fdb/attachment-0001.html>

From tinkr at openmailbox.org  Sat Feb 28 17:07:22 2015
From: tinkr at openmailbox.org (Tinker)
Date: Sat, 28 Feb 2015 22:37:22 +0530
Subject: [openssl-users]
 =?utf-8?q?Two_broken_SSL=5FERROR=5FWANT=5FREAD/WR?=
 =?utf-8?q?ITE_handling_examples_-_how_exploit_cpu-hogging_and_zombificati?=
 =?utf-8?q?on=2C_and=2C_how_badly_broken_do_you_consider_them_to_be=3F?=
In-Reply-To: <e065aa7d498b29a9e1abbd52370db9c5@openmailbox.org>
References: <e065aa7d498b29a9e1abbd52370db9c5@openmailbox.org>
Message-ID: <c8aa3bb9da6f69f9d298015ffca20d1f@openmailbox.org>

Program (1) below goes into 100% CPU consumption by running a dummy TCP 
server e.g. "nc -l 10000 > /dev/null" and making the program connect to 
that.

That's enough of an exploit to show that a program with this behavior is 
absolutely broken.

Thanks.



On 2015-02-26 00:01, Tinker wrote:
> Dear list,
> 
> I have been given two example programs that I have been requested to
> provide exploits for.
> 
> I would kindly ask you to suggest me the simplest way to cause as much
> cpu-hogging in the first one, and zombification in the second, as
> possible.
> 
> For causing this, you may use
> 
>  * As server for it to connect to, any simple unix tool or C script of
> your choice, and
> 
>  * You may alter any Linux kernel settings you want, to alterate the
> fwrite() and fread() behavior that OpenSSL gets.
> 
> My suggestions for how exploit below, but without exploit scripts.
> 
> Also, if you think these are *not explotaible*, please tell!!
> 
> 
> Also just for reference, how badly broken do you consider programs
> that do select() in the wrong direction like this to be - do you
> consider them disqualified from any production use?
> 
> 
> Thanks!!
> 
> 
> 
> (1)
> 
> The first program invokes SSL_write only. Its error is that it
> responds to SSL_ERROR_READ by making a select() for writability, which
> is of course basically always there, meaning that when that is the
> case it will.
> 
> How would you cause this program to hog as much CPU as possible?
> 
> void make_me_hog_cpu_main() {
>     [Connects to an SSL server of your choice, sets the SSL in
> nonblocking mode, and does all way up to SSL_connect.]
> 
>     char buf[1];
>     // Needed?: SSL_write(ssl,buf,1);
>     do {
>         int r = SSL_write(ssl,buf,0);
>         int e = SSL_get_error(ssl,r);
>         if ((e == SSL_ERROR_WANT_READ) || (e == SSL_ERROR_WANT_WRITE)) 
> {
>             select( with the SSL socket in writefds );
>         }
>     } while (not EOF yet);
> }
> 
> 
> I think the way I would do it, would be to make it connect to a dummy
> TCP server that reads all data and throws it away, but never responds
> with any data.
> 
> 
> (2)
> 
> The second program invokes SSL_read only. Its error is that it
> responds to SSL_ERROR_WRITE by making a select() for readability.
> 
> It should be easy to make the select() call never return.
> 
> How would you cause this program to zombify?
> 
> void make_me_zombify_main() {
>     [Connects to an SSL server of your choice, sets the SSL in
> nonblocking mode, and does all way up to SSL_connect.]
> 
>     do {
>         int r = SSL_read(ssl,buf,1);
>         int e = SSL_get_error(ssl,r);
>         if ((e == SSL_ERROR_WANT_READ) || (e == SSL_ERROR_WANT_WRITE)) 
> {
>             select( with the SSL socket in readfds );
>         }
>     } while (not EOF yet);
> }
> 
> I see this one as a bit trickier - what I see is that OpenSSL starts
> with writing 320 bytes on the socket (see strace output below), when
> starting negotiation.
> 
> If I somehow would decrease Linux' NIC's MTU, decrease OS write
> buffers, and similar things, to less than 320 bytes so say to 1 byte,
> then the SSL_read SSL negotiation's first fwrite() would not write all
> 320 bytes and thus it would return SSL_ERROR_WRITE and the server
> would never answer anything, at least not before disconnecting, so the
> select() would cause the connection to zombify until it closes.
> 
> 
> Thanks!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> strace openssl s_connect -host wikipedia.org -port 443 shows:
> 
> socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
> setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [0], 4) = 0
> connect(3, {sa_family=AF_INET, sin_port=htons(443),
> sin_addr=inet_addr("208.80.154.224")}, 16) = 0
> fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7f9c3e8be000
> write(1, "CONNECTED(00000003)\n", 20CONNECTED(00000003)
> )   = 20
> select(4, [3], [3], NULL, NULL)         = 1 (out [3])
> time(NULL)                              = 1424859317
> time(NULL)                              = 1424859317
> write(3,
> "\26\3\1\1;\1\0\0017\3\3T\355\240\265\341\232v\352N\6\357Q\1\0}\2248\362\332\240\201"...,
> 320) = 320
> read(3, "\26\3\3\0B\2\0", 7)            = 7
> time(NULL)                              = 1424859317
> time(NULL)                              = 1424859317
> read(3,
> "\0>\3\3T\355\240\265+\246\24\\(\337\214\336\241\356)\33\357\342\217\253\254X\257\267\335\35\233\36"...,
> 64) = 64
> read(3, "\26\3\3\fT", 5)                = 5
> read(3,
> "\v\0\fP\0\fM\0\7\3320\202\7\3260\202\6\276\240\3\2\1\2\2\22\21!\227.2\245\345"...,
> 3156) = 1384
> read(3, "g\202\rwikipedia.org0\t\6\3U\35\23\4\0020\0000\35\6\3U"...,
> 1772) = 1772
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From rsalz at akamai.com  Sat Feb 28 22:16:58 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 28 Feb 2015 22:16:58 +0000
Subject: [openssl-users] has anyone developed a standalone test
	for	CVE-2014-8730?
In-Reply-To: <20150227183128.GC44176@numachi.com>
References: <20150227183128.GC44176@numachi.com>
Message-ID: <867253b170bb4cc7a0e76bba5554da5c@ustx2ex-dag1mb2.msg.corp.akamai.com>


> I've found one on-line tester for CVE-2014-8730 here:

You sure that's the one you want?  That is only for F5.  See
 https://support.f5.com/kb/en-us/solutions/public/15000/800/sol15882.html

From richmoore44 at gmail.com  Sat Feb 28 22:50:27 2015
From: richmoore44 at gmail.com (Richard Moore)
Date: Sat, 28 Feb 2015 22:50:27 +0000
Subject: [openssl-users] has anyone developed a standalone test for
	CVE-2014-8730?
In-Reply-To: <20150227183128.GC44176@numachi.com>
References: <20150227183128.GC44176@numachi.com>
Message-ID: <CAMp7mVsaxOrXGkO2AaTqdT3GXdpYiPm9ihsw8vHPmPAH1Ze3UA@mail.gmail.com>

I wrote a test using tlslite - only a few lines of code, so it should be
pretty easy to reproduce.

Rich.


On 27 February 2015 at 18:31, Brian Reichert <reichert at numachi.com> wrote:

> I've found one on-line tester for CVE-2014-8730 here:
>
>   https://www.ssllabs.com/ssltest/
>
> But, I was looking for an offline test I could perform in our dev
> environment.
>
> Does anyone know of one?  I've had no luck as of yet...
>
> --
> Brian Reichert                          <reichert at numachi.com>
> BSD admin/developer at large
> _______________________________________________
> 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/20150228/1fe2a191/attachment.html>