[openssl-users] Get effective OPENSSLDIR path at runtime?

[Jeffrey Walton]

Hi Everyone,

opensslconf.h has a macro for the configured OpenSSL directory. We can
find the configured location of opendssl.cnf by using OPENSSLDIR.
However, the path can be influenced by `-config` options (for openssl
apps) and the `OPENSSL_CONF` environmental variable at runtime.

How can we get effective OPENSSLDIR path at runtime?

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

Re: [openssl-users] Problems with ""sequencing" of FakeBasicAuth vs. Require using client certs for Authentication

[o haya]

Hi,

Ok, thanks!

Jim


On Wed, 5/4/16, Salz, Rich  wrote:

 Subject: RE: [openssl-users] Problems with ""sequencing" of FakeBasicAuth vs. 
Require using client certs for Authentication
 To: "o haya" , "openssl-users@openssl.org" 

 Date: Wednesday, May 4, 2016, 12:33 PM
 
 > [My apologies for
 this cross-post, but I think that I realized after I posted
 this
 > on the Apache mailing list that it
 might be more appropriate here, as
 >
 "SSLOptions +FakeBasicAuth" is under
 mod_ssl...]
 
 The
 apache mailing list(s) are probably a better forum
 
 --  
 Senior
 Architect, Akamai Technologies
 IM: richs...@jabber.at
 Twitter: RichSalz
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problems with ""sequencing" of FakeBasicAuth vs. Require using client certs for Authentication

[Salz, Rich]

> [My apologies for this cross-post, but I think that I realized after I posted 
> this
> on the Apache mailing list that it might be more appropriate here, as
> "SSLOptions +FakeBasicAuth" is under mod_ssl...]

The apache mailing list(s) are probably a better forum

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problems with OpenSSL 1.0.2 h

[Short, Todd]

Have you tried to configure this cipher at the top of your cipher list 
initially with SSL_OP_SERVER_CIPHER_PREFERENCE?

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On May 4, 2016, at 12:04 PM, Benjamin Kaduk 
> wrote:

Hello,

On 05/04/2016 05:21 AM, Dirk Menstermann wrote:
Hi,

I've trouble with the newest OpenSSL as I'm operating a webserver application
that answers with HTTP1.x and HTTP2.

I registered the ALPN callback and in this the cipher list was adjusted
"SSL_set_cipher_list (ssl, "ECDHE-RSA-AES128-GCM-SHA256")" if H2 was negotiated.

With versions < OpenSSL 1.0.2h this works, but now it seems that this cipher
selection will be ignored, resulting in using a cipher that is black listed for
HTTP2 (Firefox and Chrome refuse to connect)

Was there an indented change or is there an official way to select the cipher
based on the ALPN extension value?


There was an intended change to the order in which ALPN extensions were
processed, see
https://github.com/openssl/openssl/commit/af2db04c9979554ada88d969da6332a827a47599
-- ALPN is now processed after SNI, since the ALPN callback is attached
to the SSL_CTX, and SNI processing is likely to swap out the SSL_CTX in
use.  It does look like "late" TLS extensions are now handled after
cipher selection, so the ALPN callback can no longer affect the
negotiated cipher.

Even at the specification level, how all the TLS extensions are supposed
to interact with each other and the rest of the handshake is not
terribly well specified, so adding -dev to discuss what the desired
behavior actually is.

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

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

Re: [openssl-users] Problems with OpenSSL 1.0.2 h

[Benjamin Kaduk]

Hello,

On 05/04/2016 05:21 AM, Dirk Menstermann wrote:
> Hi,
>
> I've trouble with the newest OpenSSL as I'm operating a webserver application
> that answers with HTTP1.x and HTTP2.
>
> I registered the ALPN callback and in this the cipher list was adjusted
> "SSL_set_cipher_list (ssl, "ECDHE-RSA-AES128-GCM-SHA256")" if H2 was 
> negotiated.
>
> With versions < OpenSSL 1.0.2h this works, but now it seems that this cipher
> selection will be ignored, resulting in using a cipher that is black listed 
> for
> HTTP2 (Firefox and Chrome refuse to connect)
>
> Was there an indented change or is there an official way to select the cipher
> based on the ALPN extension value?
>

There was an intended change to the order in which ALPN extensions were
processed, see
https://github.com/openssl/openssl/commit/af2db04c9979554ada88d969da6332a827a47599
-- ALPN is now processed after SNI, since the ALPN callback is attached
to the SSL_CTX, and SNI processing is likely to swap out the SSL_CTX in
use.  It does look like "late" TLS extensions are now handled after
cipher selection, so the ALPN callback can no longer affect the
negotiated cipher.

Even at the specification level, how all the TLS extensions are supposed
to interact with each other and the rest of the handshake is not
terribly well specified, so adding -dev to discuss what the desired
behavior actually is.

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

[openssl-users] Problems with OpenSSL 1.0.2 h

[Dirk Menstermann]

Hi,

I've trouble with the newest OpenSSL as I'm operating a webserver application
that answers with HTTP1.x and HTTP2.

I registered the ALPN callback and in this the cipher list was adjusted
"SSL_set_cipher_list (ssl, "ECDHE-RSA-AES128-GCM-SHA256")" if H2 was negotiated.

With versions < OpenSSL 1.0.2h this works, but now it seems that this cipher
selection will be ignored, resulting in using a cipher that is black listed for
HTTP2 (Firefox and Chrome refuse to connect)

Was there an indented change or is there an official way to select the cipher
based on the ALPN extension value?

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

Re: [openssl-users] While ssl handshake happens, getting error Operation not allowed in fips mode

[Jakob Bohm]

On 04/05/2016 08:15, mani kanta wrote:


Hello,

   While the SSL handshake is happening,I am getting the error as below
SSL_connect error:0408E09E:rsa routines:PKEY_RSA_SIGN:operation not 
allowed in fips mode.
ssl handshake went well up to client sending key exchange to server 
and failing in the process of send client verify. Why this error 
happens ? and How to overcome this ?


Background:
 1.  I built Openssl in FIPS mode. From the supplicant (application) I 
called FIPS_mode_set(1) API. In my use-case I am trying to connect 
WPA2 Enterprise Wi-Fi network which has EAP-TLS configured (used 
radius server to setup EAP-TLS).


2. From the network packets it is confirmed that the client and the 
server agreed on to use TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher 
suit. Also found that if in case TLS_RSA_WITH_AES_256_CBC_SHA256 
cipher suit is selected  then also it throws the same above mentioned 
error.


3. I am using openssl verson 1.0.2f(client side). radius 
server(3.0.11) . Server is running in ubuntu 14.04




Is your RSA key too short (FIPS mode imposes a minimum key
length by refusing to use shorter keys).



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

[openssl-users] While ssl handshake happens, getting error Operation not allowed in fips mode

[mani kanta]

Hello,

   While the SSL handshake is happening,I am getting the error as below
SSL_connect error:0408E09E:rsa routines:PKEY_RSA_SIGN:operation not allowed
in fips mode.
ssl handshake went well up to client sending key exchange to server and
failing in the process of send client verify. Why this error happens ? and
How to overcome this ?

Background:
 1.  I built Openssl in FIPS mode. From the supplicant (application) I
called FIPS_mode_set(1) API. In my use-case I am trying to connect WPA2
Enterprise Wi-Fi network which has EAP-TLS configured (used radius server
to setup EAP-TLS).

2. From the network packets it is confirmed that the client and the server
agreed on to use TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher suit. Also
found that if in case TLS_RSA_WITH_AES_256_CBC_SHA256 cipher suit is
selected  then also it throws the same above mentioned error.

3. I am using openssl verson 1.0.2f(client side). radius server(3.0.11) .
Server is running in ubuntu 14.04

  Please let me know if you need any further information.

  Thank you in advance.

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