Re: [openssl-users] OpenSSL FIPS Object Module v2.0

[Steve Marquess]

On 01/20/2016 05:07 PM, Imran Ali wrote:
> Hi Steve,
> 
>  
> 
> Is there any update on the submissions for the OpenSSL FIPS Object
> Module v2.0, validation(s) #1747/#2398/#2474
> 

Still waiting on the CMVP. The paperwork for all three validations was
submitted on December 20. I'm not even going to try and guess how long
they'll take to review it; we've had to wait over six months for similar
(no new platforms) change letters.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@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

Re: [openssl-users] Using TCP Fast Open with OpenSSL

[Nounou Dadoun]

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Viktor Dukhovni
Sent: Wednesday, January 20, 2016 8:55 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Using TCP Fast Open with OpenSSL


> On Jan 20, 2016, at 9:27 AM, Sara Dickinson  wrote:
> 
> I have TFO + TLS (using OpenSSL) working on OS X. However, because of 
> the specifics of the TFO implementation on Linux, I can’t see how to 
> get that working with OpenSSL. On Linux using TFO requires that
> - the connect() call is skipped entirely
> - the first data sent on the connection must be sent using the sendto() 
> function passing in the MSG_FASTOPEN flag. This sendto() call takes care of 
> both the TCP handshake, and sending the data as payload in the SYN. 
> 
> I may well be missing something, but I can’t see anyway to use this in 
> combination with the OpenSSL API, because the 
> SSL_connect()/SSL_do_handshake() functions rely on the underlying socket 
> already being setup and ready to accept a 'write'. Does anyone know of a 
> solution/workaround, or a plan to add support for client TFO to OpenSSL?

Well, I am not shy to say that the Linux Kernel API for this is poorly 
designed.  However, we can perhaps work around this.

This could be done via an enhancement of BIO_s_socket() to support completing 
the connection on the first write.
Then you just configure the modified BIO as the network BIO of the SSL handle.

The construction of the BIO could be made transparent to users of SSL_set_fd() 
via a suitable new control operation that's passed through to the underlying 
BIO.

SSL_set_fd(ssl, sock);
SSL_set_tfo_addr(ssl, struct sockaddr *sa, int salen);

(Or some variant of these types for Windows, ...)

But of course the feature itself would not initially be available on all 
platforms.

-- 
Viktor.



But if the TFO data payload is in the first SYN how can it be encrypted (etc) 
even before the TCP handshake is complete (let alone the SSL handshake) unless 
the calls are unbundled and serialized somehow.

Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 
Support: 888.281.5182  |  avigilon.com
Follow Twitter  |  Follow LinkedIn

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

Re: [openssl-users] [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11

[Salz, Rich]

> That's my issue.  I cannot get a more recent bind version to stay to stable on
> one box.

Then I think that's going to be a tough issue, and you'll either have to modify 
that source or stay at 1.0.2

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

[openssl-users] Getting the current key exchange algorithm mode from an SSL_CIPHER

[Eric Erhardt]

What is the most appropriate way to programmatically get the following 
information about an SSL_CIPHER?

Currently, we need to read:


* Which cipher algorithm is being used

* Which key exchange algorithm is being used

* Which MAC hash algorithm is being used

The way we've currently been doing this is by looking at the SSL_CIPHER's 
algorithm_enc, algorithm_mkey, and algorithm_mac fields. But since there is no 
public header that contains the enum values, we've copied the values out of 
ssl/ssl_locl.h into our own code.

This is problematic, since these values have recently changed with 
https://github.com/openssl/openssl/commit/bc71f91064a3eec10310fa4cc14fe2a3fd9bc7bb

For example:
-# define SSL_kDHE0x0008U
+# define SSL_kDHE0x0002U


One option we've discussed is to compare strings returned from 
SSL_CIPHER_get_name, or SSL_CIPHER_description, but this seems less than ideal.

Is there a better way to programmatically get this information?

Thanks in advance,
Eric Erhardt
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Using TCP Fast Open with OpenSSL

[Sara Dickinson]

> On 20 Jan 2016, at 16:55, Viktor Dukhovni  wrote:

>> On Jan 20, 2016, at 9:27 AM, Sara Dickinson  wrote:
>> 
>> I have TFO + TLS (using OpenSSL) working on OS X. However, because of the 
>> specifics of the TFO implementation on Linux, I can’t see how to get that 
>> working with OpenSSL. On Linux using TFO requires that
>> - the connect() call is skipped entirely
>> - the first data sent on the connection must be sent using the sendto() 
>> function passing in the MSG_FASTOPEN flag. This sendto() call takes care of 
>> both the TCP handshake, and sending the data as payload in the SYN. 
>> 
>> I may well be missing something, but I can’t see anyway to use this in 
>> combination with the OpenSSL API, because the 
>> SSL_connect()/SSL_do_handshake() functions rely on the underlying socket 
>> already being setup and ready to accept a 'write'. Does anyone know of a 
>> solution/workaround, or a plan to add support for client TFO to OpenSSL?
> 
> Well, I am not shy to say that the Linux Kernel API for this is
> poorly designed.  However, we can perhaps work around this.

Indeed. The OS X implementation is nicer since a connectx() call with the 
correct flags sets the socket up as needed and then the first write() call 
performs the TFO. 

> 
> This could be done via an enhancement of BIO_s_socket()
> to support completing the connection on the first write.
> Then you just configure the modified BIO as the network
> BIO of the SSL handle.
> 
> The construction of the BIO could be made transparent to
> users of SSL_set_fd() via a suitable new control operation
> that's passed through to the underlying BIO.
> 
>   SSL_set_fd(ssl, sock);
>   SSL_set_tfo_addr(ssl, struct sockaddr *sa, int salen);

Yes, that sounds like it would do the job!

> 
> (Or some variant of these types for Windows, ...)
> 
> But of course the feature itself would not initially be
> available on all platforms.

As of today TFO isn’t implemented on Windows at all AFAIK and only server side 
support is currently implemented on FreeBSD. 

Regards

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

Re: [openssl-users] [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11

[Viktor Dukhovni]

On Wed, Jan 20, 2016 at 11:05:58AM -0700, The Doctor wrote:

> > The bind code is what needs to be adjusted, given that openssl 1.1 is
> > intentionally introducing API changes and removing direct access to many
> > structures.  It seems quite unlikely that an EoL version of a
> > third-party software is going to magically receive a new release
> > allowing it to build against a version of openssl that did not exist
> > when it was released.
> 
> That's my issue.  I cannot get a more recent bind version to stay 
> to stable on one box.

Bind 9.10 works fine for me, but I use it only as an authoritative
server.  My recursive resolver is "unbound".  And I make sure to
build both without GOST support.

If BIND is not reliable enough for you, consider some combination
"unbound" and/or "nsd".

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

Re: [openssl-users] Getting the current key exchange algorithm mode from an SSL_CIPHER

[Salz, Rich]

The most portable, and longest-lasting, way is probably to get the name and 
then use that as a key to look up things in your own table of characteristics.

A PR that adds API's (and doc) for extracting various things, and returning 
them as nid's or oid's or something, would be helpful.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11

[The Doctor]

On Tue, Jan 19, 2016 at 08:53:49PM -0600, Benjamin Kaduk wrote:
> On 01/19/2016 05:37 PM, The Doctor wrote:
> > Tried to compile an old bind and ran into
> 
> Why?
> 
> > What needs to be adjusted?
> >
> >
> 
> The bind code is what needs to be adjusted, given that openssl 1.1 is
> intentionally introducing API changes and removing direct access to many
> structures.  It seems quite unlikely that an EoL version of a
> third-party software is going to magically receive a new release
> allowing it to build against a version of openssl that did not exist
> when it was released.

That's my issue.  I cannot get a more recent bind version to stay 
to stable on one box.

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

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Birthdate 29 Jan 1969 Redhill, Surrey, UK
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Using TCP Fast Open with OpenSSL

[Nounou Dadoun]

The TCP first-flight data will be the TLS ClientHello message.  This saves one 
round-trip on repeat visits:

C: SYN + TFO-COOKIE + TLS ClientHello
S: SYN-ACK
S: ACK + TLS Server Hello ...
...

-- 
Viktor.


That makes sense, thanks ... N
Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 
Support: 888.281.5182  |  avigilon.com
Follow Twitter  |  Follow LinkedIn

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

Re: [openssl-users] Using TCP Fast Open with OpenSSL

[Viktor Dukhovni]

> On Jan 20, 2016, at 9:27 AM, Sara Dickinson  wrote:
> 
> I have TFO + TLS (using OpenSSL) working on OS X. However, because of the 
> specifics of the TFO implementation on Linux, I can’t see how to get that 
> working with OpenSSL. On Linux using TFO requires that
> - the connect() call is skipped entirely
> - the first data sent on the connection must be sent using the sendto() 
> function passing in the MSG_FASTOPEN flag. This sendto() call takes care of 
> both the TCP handshake, and sending the data as payload in the SYN. 
> 
> I may well be missing something, but I can’t see anyway to use this in 
> combination with the OpenSSL API, because the 
> SSL_connect()/SSL_do_handshake() functions rely on the underlying socket 
> already being setup and ready to accept a 'write'. Does anyone know of a 
> solution/workaround, or a plan to add support for client TFO to OpenSSL?

Well, I am not shy to say that the Linux Kernel API for this is
poorly designed.  However, we can perhaps work around this.

This could be done via an enhancement of BIO_s_socket()
to support completing the connection on the first write.
Then you just configure the modified BIO as the network
BIO of the SSL handle.

The construction of the BIO could be made transparent to
users of SSL_set_fd() via a suitable new control operation
that's passed through to the underlying BIO.

SSL_set_fd(ssl, sock);
SSL_set_tfo_addr(ssl, struct sockaddr *sa, int salen);

(Or some variant of these types for Windows, ...)

But of course the feature itself would not initially be
available on all platforms.

-- 
Viktor.


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

Re: [openssl-users] Using TCP Fast Open with OpenSSL

[Sara Dickinson]

Hi, 

I have recently been adding support for TLS using OpenSSL to a client 
application. When using TCP the application uses TCP Fast Open (TFO) as 
described in this RFC: https://tools.ietf.org/html/rfc7413 
. TFO is currently available for clients 
on both Linux and OS X, however the socket API changes for TFO are different on 
the 2 platforms.

I have TFO + TLS (using OpenSSL) working on OS X. However, because of the 
specifics of the TFO implementation on Linux, I can’t see how to get that 
working with OpenSSL. On Linux using TFO requires that
- the connect() call is skipped entirely
- the first data sent on the connection must be sent using the sendto() 
function passing in the MSG_FASTOPEN flag. This sendto() call takes care of 
both the TCP handshake, and sending the data as payload in the SYN. 

I may well be missing something, but I can’t see anyway to use this in 
combination with the OpenSSL API, because the SSL_connect()/SSL_do_handshake() 
functions rely on the underlying socket already being setup and ready to accept 
a 'write'. Does anyone know of a solution/workaround, or a plan to add support 
for client TFO to OpenSSL?

Regards

Sara. 

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

Re: [openssl-users] Getting the current key exchange algorithm mode from an SSL_CIPHER

[Viktor Dukhovni]

> On Jan 20, 2016, at 1:13 PM, Eric Erhardt  wrote:
> 
> What is the most appropriate way to programmatically get the following 
> information about an SSL_CIPHER?
> 
> Currently, we need to read:
> 
> · Which cipher algorithm is being used
> · Which key exchange algorithm is being used
> · Which MAC hash algorithm is being used
> 
> The way we’ve currently been doing this is by looking at the SSL_CIPHER’s 
> algorithm_enc, algorithm_mkey, and algorithm_mac fields. But since there is 
> no public header that contains the enum values, we’ve copied the values out 
> of ssl/ssl_locl.h into our own code.
> 
> This is problematic, since these values have recently changed 
> withhttps://github.com/openssl/openssl/commit/bc71f91064a3eec10310fa4cc14fe2a3fd9bc7bb
> 
> For example:
> -# define SSL_kDHE0x0008U  
> +# define SSL_kDHE0x0002U  
> 
> 
> One option we’ve discussed is to compare strings returned from 
> SSL_CIPHER_get_name, or SSL_CIPHER_description, but this seems less than 
> ideal.
> 
> Is there a better way to programmatically get this information?

At present, you can get:

SSL_CIPHER_get_cipher_nid()
SSL_CIPHER_get_digest_nid()
SSL_CIPHER_get_id()

The last of these returns 0x0300NNMM with {NN,MM} found at the IANA
registry

  
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4

There are at present no stable nids for the key exchange, so it may be
best to apply your own mappings.

Another option is to create an SSL handle with the given cipher name as the 
first
cipher-list element and "!kDHE", "!kECDHE", "!kRSA", ... as the second and
last.  Whichever of these fails with an empty cipherlist was the actual
key exchange method.

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

Re: [openssl-users] Getting the current key exchange algorithm mode from an SSL_CIPHER

[Dr. Stephen Henson]

On Wed, Jan 20, 2016, Eric Erhardt wrote:

> What is the most appropriate way to programmatically get the following 
> information about an SSL_CIPHER?
> 
> Currently, we need to read:
> 
> 
> * Which cipher algorithm is being used
> 
> * Which key exchange algorithm is being used
> 
> * Which MAC hash algorithm is being used
> 
> The way we've currently been doing this is by looking at the SSL_CIPHER's 
> algorithm_enc, algorithm_mkey, and algorithm_mac fields. But since there is 
> no public header that contains the enum values, we've copied the values out 
> of ssl/ssl_locl.h into our own code.
> 
> This is problematic, since these values have recently changed with 
> https://github.com/openssl/openssl/commit/bc71f91064a3eec10310fa4cc14fe2a3fd9bc7bb
> 
> For example:
> -# define SSL_kDHE0x0008U
> +# define SSL_kDHE0x0002U
> 
> 
> One option we've discussed is to compare strings returned from 
> SSL_CIPHER_get_name, or SSL_CIPHER_description, but this seems less than 
> ideal.
> 
> Is there a better way to programmatically get this information?
> 

There are several functions that can extract some of the information.
SSL_CIPHER_get_cipher_nid and SSL_CIPHER_get_digest_nid for example.
Currently there isn't a function to extract the key exchange or signing
algorithm though.

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

Re: [openssl-users] [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11

[The Doctor]

On Wed, Jan 20, 2016 at 06:11:16PM +, Salz, Rich wrote:
> > That's my issue.  I cannot get a more recent bind version to stay to stable 
> > on
> > one box.
> 
> Then I think that's going to be a tough issue, and you'll either have to 
> modify that source or stay at 1.0.2
>

Source modification it is.

BTW we are more interested in Bind 9.9 and Bind 9.10 ?
 
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Birthdate 29 Jan 1969 Redhill, Surrey, UK
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL FIPS Object Module v2.0

[Imran Ali]

Hi Steve,

Is there any update on the submissions for the OpenSSL FIPS Object Module v2.0, 
validation(s) #1747/#2398/#2474

Regards,
Imran
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Using TCP Fast Open with OpenSSL

[Viktor Dukhovni]

On Wed, Jan 20, 2016 at 06:01:00PM +, Nounou Dadoun wrote:

> But if the TFO data payload is in the first SYN how can it be encrypted
> (etc) even before the TCP handshake is complete (let alone the SSL
> handshake) unless the calls are unbundled and serialized somehow.

The TCP first-flight data will be the TLS ClientHello message.  This
saves one round-trip on repeat visits:

C: SYN + TFO-COOKIE + TLS ClientHello
S: SYN-ACK
S: ACK + TLS Server Hello ...
...

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

Re: [openssl-users] Questions regarding the openssl FIPS self-tests

[Steve Marquess]

On 01/20/2016 02:00 AM, cloud force wrote:
> Hi everyone,
> 
> From the openssl tips doc it said the power-on self-tests need to be run
> when the system comes up.
> 
> If I have multiple applications which uses the openssl crypto functions
> (under fips mode), does each of this application need to run the
> power-on self-tests?
> 
> Also if the openssl fips modules are installed on a Linux server, what
> is the best way to run the power-on self-tests (e.g. run within init.d
> script or upstart scripts or run by a daemon)?

The POST is run automagically when your application code calls
FIPS_mode_SET().

For most platforms including Linux the shared library has non-writable
code/data area(s) shared among all calling processes, and writable data
area(s) private to each such process. The library state information
resides in the private writable areas, of course, so each such process
will need to independently call FIPS_mode_set().

Keep in mind that the POST doesn't really do anything useful, it is an
ideological requirement from the dim mists of history. As such you
cannot enable FIPS mode without also invoking the POST.

Note this means that one set of shared libraries can be used for all
processes, both those that care about FIPS 140-2 and those that don't.
The OpenSSL + OpenSSL FIPS module combination (the "FIPS capable"
OpenSSL) was designed for such dual use so that the FIPS behavior
wouldn't be seen *unless* FIPS_mode_set() was called.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@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