date:20170905

[openssl-users] Query on usage of openssl 1.1.0f with openssl-FIPS

2017-09-05 Thread Grace Priscilla Jero

Hi All,



We would want to build our openssl 1.1.0f with FIPS but we noticed it is
mentioned as

“The 2.0 FIPS module is compatible with OpenSSL releases 1.0.1 and 1.0.2,
and no others”.

I am unable to find the openssl-fips module for 1.1.0f. Do you know when it
will be available?



Could you please let us know the latest openssl 1.0 version that can be
compiled with “openssl-fips-2.0.16”?

Also, please let know if that version supports DTLS.



Thanks,

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

[openssl-users] SSL_CTX_set_cipher_list returns failure for DHE-DSS-AES256-GCM-SHA384

2017-09-05 Thread mahesh gs

Hi All,

I am using openssl version 01.01.00f for providing TLS and DTLS security
for TCP and SCTP connection for our application. I have query regarding the
"Ciphers" that are accepted by the SSL_CTX_set_cpiher_list API. The list of
ciphers that are supported by openssl version 01.01.00f that is output of
command "openssl ciphers -v" is as listed down below. When i try to set
these ciphers through API "SSL_CTX_set_cipher_list" returns success for
some and failure for some other ciphers.

For example if i set "ECDHE-RSA-AES256-GCM-SHA384" API returns success but
if i set "DHE-DSS-AES256-GCM-SHA384" or "RC4-MD5" API returns failure. My
query is what are the accepted ciphers ? and what is the reason behind not
accepting some of them?

*openssl ciphers -v*

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(256)
Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256)
Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)
 Mac=SHA384
ECDHE-RSA-AES256-SHASSLv3 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=DSS  Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH   Au=DSS  Enc=AES(256)  Mac=SHA256
DHE-RSA-AES256-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA  SSLv3 Kx=DH   Au=DSS  Enc=AES(256)  Mac=SHA1
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
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256)
Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256)
Mac=AEAD
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)
 Mac=SHA384
ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
AES256-GCM-SHA384   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES256-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA256
AES256-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA  Au=RSA  Enc=Camellia(256) Mac=SHA1
PSK-AES256-CBC-SHA  SSLv3 Kx=PSK  Au=PSK  Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(128)
Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128)
Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)
 Mac=SHA256
ECDHE-RSA-AES128-SHASSLv3 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH   Au=DSS  Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH   Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH   Au=DSS  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES128-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA  SSLv3 Kx=DH   Au=DSS  Enc=AES(128)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
DHE-RSA-SEED-SHASSLv3 Kx=DH   Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHASSLv3 Kx=DH   Au=DSS  Enc=SEED(128) 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
EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH   Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH   Au=DSS  Enc=3DES(168) Mac=SHA1
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128)
Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128)
Mac=AEAD
ECDH-RSA-AES128-SHA256  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)
 Mac=SHA256
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
AES128-GCM-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES128-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA256
AES128-SHA

Re: [openssl-users] Problem with Last step in setup

2017-09-05 Thread Michael Richardson


Gerardi, Elio  wrote:
> I am getting the following error when I run the ‘make install’ command on
> OPenSSL

> make install

> /Library/Developer/CommandLineTools/usr/bin/make depend &&
> /Library/Developer/CommandLineTools/usr/bin/make _all

> *** Installing development files

> Cannot create directory /usr/local/include: No such file or directory

Probably because you don't have a /usr/local/include, and it isn't
autocreated ("mkdir -p"), and you aren't running this as root.

(maybe you want to install it some place other than /usr/local?)

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problem with Last step in setup

2017-09-05 Thread Jakob Bohm


On 05/09/2017 17:37, Gerardi, Elio wrote:


I am getting the following error when I run the ‘make install’ command 
on OPenSSL


make install

/Library/Developer/CommandLineTools/usr/bin/make depend && 
/Library/Developer/CommandLineTools/usr/bin/make _all


*** Installing development files

Cannot create directory /usr/local/include: No such file or directory

make: *** [install_dev] Error 2


Simple.

The default "make install" location for most UNIX-style software is in
the  /usr/local/ subtree.  The Linux community even created a standard
explaining the typical layout of Linux, which is based on decades of
UNIX tradition, with some choices made where traditions varied.

The intended typical use is to run the other make steps as a build user,
then running make install as someone with the (delegated) authority to
write to /usr/local (e.g. membership of a 'staff' group).

In the case of OpenSSL 0.9.x and 1.0.x, this value can be changed by
passing --openssldir=/some/dir/of/your/choice to Configure, but
unfortunately, this also causes the compiled code to expect things like
openssl.cnf to be located beneath that directory on all machines where
the binary code are run.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://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

Re: [openssl-users] Problem with Last step in setup

2017-09-05 Thread Richard Levitte

In message  on Tue, 5 Sep 2017 
15:37:59 +, "Gerardi, Elio"  said:

Elio.Gerardi> I am getting the following error when I run the ‘make install’ 
command on OPenSSL
Elio.Gerardi> 
Elio.Gerardi> make install
Elio.Gerardi> 
Elio.Gerardi> /Library/Developer/CommandLineTools/usr/bin/make depend &&
Elio.Gerardi> /Library/Developer/CommandLineTools/usr/bin/make _all
Elio.Gerardi> 
Elio.Gerardi> *** Installing development files
Elio.Gerardi> 
Elio.Gerardi> Cannot create directory /usr/local/include: No such file or 
directory
Elio.Gerardi> 
Elio.Gerardi> make: *** [install_dev] Error 2

Is there a directory /usr/local on your system?

Does the user your running 'make install' with have permission to
write to the /usr/local directory?

An alternative, if you have sudo privileges, is this:

sudo make install

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

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

Re: [openssl-users] Testing OCSP with openssl

2017-09-05 Thread Robert Moskowitz




On 09/05/2017 11:59 AM, Dr. Stephen Henson wrote:

On Tue, Sep 05, 2017, Robert Moskowitz wrote:


Jamie Nugyen's guide uses openssl to test OCSP with 'openssl ocsp':

https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html

What is unclear here is:

Does openssl read the index.txt file once at startup, or does it
read it with each query.  From the way I read his guide it reads
like index.txt is only read at startup.


Once on startup. The mini-responder is only a test utility.
It is not usable as a full blown responder.


Oh, I got the test utility limitation.  Just for my guide, after 
revoking the certificate which results in index.txt being updated, does 
the test 'openssl ocsp' service need to be restarted to reread the 
index.txt file?


So from your response, just the once at startup, and I will have to 
specify (as Jamie does in his guide) to restart the test responder.


I am searching for a 'simple' OCSP responder for myself...

Thanks

Bob

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

Re: [openssl-users] Testing OCSP with openssl

2017-09-05 Thread Dr. Stephen Henson

On Tue, Sep 05, 2017, Robert Moskowitz wrote:

> Jamie Nugyen's guide uses openssl to test OCSP with 'openssl ocsp':
> 
> https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html
> 
> What is unclear here is:
> 
> Does openssl read the index.txt file once at startup, or does it
> read it with each query.  From the way I read his guide it reads
> like index.txt is only read at startup.
> 

Once on startup. The mini-responder is only a test utility.
It is not usable as a full blown responder.

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

[openssl-users] Problem with Last step in setup

2017-09-05 Thread Gerardi, Elio

I am getting the following error when I run the ‘make install’ command on 
OPenSSL

make install
/Library/Developer/CommandLineTools/usr/bin/make depend && 
/Library/Developer/CommandLineTools/usr/bin/make _all
*** Installing development files
Cannot create directory /usr/local/include: No such file or directory
make: *** [install_dev] Error 2



Elio Gerardi – Cloud Architect
Hyperscaler GTM team
Cloud Business Unit
cloud.netapp.com


NetApp
646.313.3079 Direct Phone
914.419.0396 Mobile Phone
e...@netapp.com

[cid:image001.jpg@01D3263B.6C8D1E70]




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

Re: [openssl-users] Testing OCSP with openssl

2017-09-05 Thread Robert Moskowitz


Michael,

Thanks for this concise review.  I look at it as the "Big Bang theory of 
Security".  i.e. what comes first.


And HOW DID we get those heavy metals beyond Iron?  :)

Bob

On 09/05/2017 09:10 AM, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Robert Moskowitz
Sent: Tuesday, September 05, 2017 08:43

Also he recommends password protecting the keypair.  That results in
needing to provide the password at responder startup.  Is this the
'normal' approach?  Is the password provided in some other file (like a
responder config file)?  I am use to putting SQL passwords into php
config files, not that I like that...

That's one of the oldest problems in IT security. Most approaches fall into one 
of three categories:

- Specialized hardware. This was one of the original intended uses for Sun's 
JavaButton hardware token, back in the '90s, but the JavaButton never really 
took off. These days we have various flavors of HSMs which act as key vaults 
and signing servers - though then you have the problem of authenticating to the 
signing server, or if you offload all crypto operations, authenticating to the 
crypto server. TPMs (which are essentially integrated HSMs), smartcard readers, 
etc can also hold keys, but typically require some authentication by a human at 
system startup.

- Attended startup with manual passphrase entry. The server can't start until 
someone enters the passphrase at the keyboard.

- Passphrase or private key in a file for unattended startup, hopefully 
protected as well as possible by filesystem permissions, filesystem encryption, 
etc. This is obviously the weakest choice for key protection, since it has a 
wider threat tree (more paths for an attacker to make use of the private key) 
than the other two options.

For general-purpose applications where you don't need particularly good 
performance, such as a moderate-volume web server, there are some very 
inexpensive hardware options. OpenSSL works well with the NitroKey HSM (via the 
PKCS#11 engine), for example. Things get tougher as you add requirements.



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

Re: [openssl-users] Testing OCSP with openssl

2017-09-05 Thread Michael Wojcik

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Robert Moskowitz
> Sent: Tuesday, September 05, 2017 08:43
> 
> Also he recommends password protecting the keypair.  That results in
> needing to provide the password at responder startup.  Is this the
> 'normal' approach?  Is the password provided in some other file (like a
> responder config file)?  I am use to putting SQL passwords into php
> config files, not that I like that...

That's one of the oldest problems in IT security. Most approaches fall into one 
of three categories:

- Specialized hardware. This was one of the original intended uses for Sun's 
JavaButton hardware token, back in the '90s, but the JavaButton never really 
took off. These days we have various flavors of HSMs which act as key vaults 
and signing servers - though then you have the problem of authenticating to the 
signing server, or if you offload all crypto operations, authenticating to the 
crypto server. TPMs (which are essentially integrated HSMs), smartcard readers, 
etc can also hold keys, but typically require some authentication by a human at 
system startup.

- Attended startup with manual passphrase entry. The server can't start until 
someone enters the passphrase at the keyboard.

- Passphrase or private key in a file for unattended startup, hopefully 
protected as well as possible by filesystem permissions, filesystem encryption, 
etc. This is obviously the weakest choice for key protection, since it has a 
wider threat tree (more paths for an attacker to make use of the private key) 
than the other two options.

For general-purpose applications where you don't need particularly good 
performance, such as a moderate-volume web server, there are some very 
inexpensive hardware options. OpenSSL works well with the NitroKey HSM (via the 
PKCS#11 engine), for example. Things get tougher as you add requirements.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 


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

[openssl-users] Testing OCSP with openssl

2017-09-05 Thread Robert Moskowitz


Jamie Nugyen's guide uses openssl to test OCSP with 'openssl ocsp':

https://jamielinux.com/docs/openssl-certificate-authority/online-certificate-status-protocol.html

What is unclear here is:

Does openssl read the index.txt file once at startup, or does it read it 
with each query.  From the way I read his guide it reads like index.txt 
is only read at startup.


Also he recommends password protecting the keypair.  That results in 
needing to provide the password at responder startup.  Is this the 
'normal' approach?  Is the password provided in some other file (like a 
responder config file)?  I am use to putting SQL passwords into php 
config files, not that I like that...


thanks

Bob

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

[openssl-users] Introduce a TLS application library - a proposal on the overall OpenSSL code structure

2017-09-05 Thread David von Oheimb

Back on 13 May 2016 I had proposed by email to a couple of people
including Rich Salz
a third library level (on top of crypto and ssl) with more high-level,
application-oriented code.
His response was:
> That is a really interesting idea.  Please bring this up on openssl-dev 
> mailing list.

Then I posted that by mistake unfortunately not in the right forum but at:
https://groups.google.com/forum/#!topic/mailing.openssl.dev/FOL2afc3cb8

I quote my post here for convenience:
> So far, the OpenSSL code has essentially a three-level structure with
> a hierarchy of two libraries and a command-line application at the top:
>
> apps/openssl
> libssl
> libcrypto
>
> In the apps/ directory there is various generally useful code like
> handling crypto-related files and messages, general TLS client/server
> and CA functionality, implementing parts of protocols like S/MIME,
> CRL, and OCSP, and certainly more to come.
>
> While this code serves as a model for using the libraries and it can
> be used in a limited way by invoking the openssl application binary,
> it cannot be re-used directly. Other applications that need similar
> functionality need to copy/re-implement and then maintain portions of
> that code.
>
> On the other hand, the libraries contain some code that is actually
> too high-level for them, for instance the minimal HTTP client as part
> of the crypto library (crypto/ocsp/ocsp_ht.c).
>
> It would be very helpful to introduce a further level in the hierarchy
> consisting of a more application-oriented library:
>
> apps/openssl
> libtlsapps <-- new (with tentative name here)
> libssl
> libcrypto
>
> Then all more high-level and application support functionality will go
> there. This would make much of the generally useful code that so far
> resides in the apps/ folder directly accessible to other
>  applications at the programming level, i.e., in the form of a
> library/API, with all the re-usability advantages that this brings. It
> would also relieve libcrypto from more application-/high-level topics
> like HTTP.
>
> This library would also form an ideal condensation point for further
> high-level uses of TLS that may in the future get integrated with
> OpenSSL, like CMP and EST implementations. 

I recently learned that LibreSSL 
already/meanwhile has something in this direction:

  * libtls : a new TLS library,
designed to make it easier to write foolproof applications

I believe this would be of great benefit also for OpenSSL itself.

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

Re: [openssl-users] [openssl-dev] How to use BIO_do_connect(), blocking and non-blocking with timeout, coping with errors

2017-09-05 Thread David von Oheimb

/[ Further below I quote my first two messages including my original
questions and tentative code,//
// since Cc'ing to openssl-users did not work when I tried first. In
this way I hope to get further, //
// more detailed responses by people with specific experience on the
issues I mentioned,//
// possibly even concrete feedback how to enhance my code or where to
find a better solution. ]/


On 09/01/2017 06:32 PM, Salz, Rich via openssl-users wrote:
>
> FWIW, there’s a ‘libtls’ library from the libre folks that might be
> worth looking at.
>
This looks very nice. Yet is this of any practical benefit when using
OpenSSL?

> If you come up with useful snippets we can start by posting them to
> the wiki, for example
>
Which wiki do you mean? I could not find anything related on
https://wiki.openssl.org/

Anyway, most people (including me) would not search through wikis for
finding useful code,
and it would be much more useful if code like the bio_connect() function
I mentioned below
was readily available within the OpenSSL libraries, in an official
high-level API.
/[ Since this is worth a topic of its own, I'll write more on this in my
next email. ]/

More low-level code that is already used by the crypto lib itself (e.g.,
using select() in rand_unix.c)
would be better packaged into abstractions within that library, for
instance the socket_wait() function
for waiting on a socket with a timeout that I proposed below. I'd
contribute pull requests for those I'm aware of.


On 29.08.2017 16:15, Salz, Rich via openssl-dev wrote:
>> Getting the client connect right appears surprisingly messy when one
>> needs to cope with all kinds of network error situations including
>> domain name resolution issues and temporarily unreachable servers.
>> Both indefinitely blocking and non-blocking behavior (i.e., connection
>> attempts with and without a timeout) should be supported.
> It is a complicated issue and hard to get right for all definitions of right 
> for all applications ☺
Hmm - on the one hand, good to get confirmation that I did not just miss
a simple way of out the maze, ...
> A set of API’s that set up all the TLS “metadata”, and took a connected 
> socket might be a way through the maze.  For example:
> SSL *SSL_connection(int socket, const char *servername, …whatever…)
... on the other hand, it's a pity that such a high-level API does not
(yet) exist, at least not in OpenSSL.

How about adding at least some clearly useful abstractions like the
below socket_wait() function,
which would reduce code duplication in the OpenSSL crypto lib and apps
and help application developers?

Maybe other OpenSSL users have specific experience on error and timeout
handling for BIO_do_connect() etc.
and can comment in more detail on the (approximate) solution,
bio_connect(), that I gave below?

On 28.08.2017 13:46, David von Oheimb wrote:
> Hi all,
>
> I'm currently enhancing HTTP(S) clients based on OpenSSL in several
> flavors, in particular a CMP client, which in turn uses simple HTTP
> clients for contacting CRL distribution points or OCSP responders.
>
> Getting the client connect right appears surprisingly messy when one
> needs to cope with all kinds of network error situations including
> domain name resolution issues and temporarily unreachable servers.
> Both indefinitely blocking and non-blocking behavior (i.e., connection
> attempts with and without a timeout) should be supported.
>
> Since these are pretty general problems I wonder why there there is
> rather limited support via generic higher-level OpenSSL or C library
> functions, or at least I was unable to find it. Instead, the OpenSSL
> apps contain code that calls BIO_do_connect directly (or the equivalent
> BIO_do_handshake), in particular query_responder() in apps/ocsp.c.
> (The situation is similar for the subsequent exchange of data via the
> BIO, optionally with a timeout).
>
> So I constructed my own abstraction, called bio_connect, which took
> quite some effort testing network error situations. Please see below its
> code including comments on some strange behavior I experienced and my
> workarounds for that. Does this code make sense, or do I miss anything?
>
> How about adding such a function for instance to crypto/bio/bio_lib.c?
>
> BTW, my code uses a handy generic helper function, socket_wait, for
> waiting for read/write form/to a socket, with a given timeout. Since
> several instances of that pretty common code pattern using select() are
> spread over the OpenSSL apps (and crypto lib), I suggest adding this
> function to the library. Where would be a good place to put it?
>
> Thanks,
>   David
>> /* returns -1 on error, 0 on timeout, 1 on success */
>> int bio_connect(BIO *bio, int timeout) {
>> int blocking;
>> time_t max_time;
>> int rv;
>>
>> blocking = timeout == 0;
>> max_time = timeout != 0 ? time(NULL) + timeout : 0;
>>
>> if (!blocking)
>> BIO_set_nbio(bio, 1);
>>  retry:
>>

[openssl-users] Query on usage of openssl 1.1.0f with openssl-FIPS

[openssl-users] SSL_CTX_set_cipher_list returns failure for DHE-DSS-AES256-GCM-SHA384

Re: [openssl-users] Problem with Last step in setup

Re: [openssl-users] Problem with Last step in setup

Re: [openssl-users] Problem with Last step in setup

Re: [openssl-users] Testing OCSP with openssl

Re: [openssl-users] Testing OCSP with openssl

[openssl-users] Problem with Last step in setup

Re: [openssl-users] Testing OCSP with openssl

Re: [openssl-users] Testing OCSP with openssl

[openssl-users] Testing OCSP with openssl

[openssl-users] Introduce a TLS application library - a proposal on the overall OpenSSL code structure

Re: [openssl-users] [openssl-dev] How to use BIO_do_connect(), blocking and non-blocking with timeout, coping with errors

13 matches

Site Navigation

Mail list logo

Footer information