Re: [openssl-users] DSA with OpenSSL-1.1

2016-07-01 Thread Matt Caswell 


On 01/07/16 16:57, pepone.onrez wrote:
> On 1 July 2016 at 16:51, pepone.onrez  wrote:
>> On 1 July 2016 at 16:40, Matt Caswell  wrote:
>>>
>>>
>>> On 01/07/16 15:22, pepone.onrez wrote:
 On 1 July 2016 at 15:39, Matt Caswell  wrote:
>
>
> On 01/07/16 14:29, pepone.onrez wrote:
>> Hi,
>>
>> After upgrade my software to use OpenSSL-1.1 one of the test is
>> failing, the test in question client and server are configured to use
>> DSA certificates. The server is configured to request a client
>> certificate.
>>
>>SSL error occurred for new outgoing connection:
>>remote address = 127.0.0.1:47812
>>error # = 336151568
>>message = error:14094410:SSL routines:ssl3_read_bytes:reason(1040)
>>location = ssl/record/rec_layer_s3.c, 1467
>>data = SSL alert number 40
>
> Is this the error you get on the server or the client? The above
> indicates the connection was aborted because a HandshakeFailure alert
> was received from the peer. Therefore you need to look at the other end
> of the communication and see if there is some error message that
> indicates why the alert was sent.
>
> Matt
 That was on the client, looking at the server I see it reports there
 is no shared
 cipher

SSL error occurred for new incoming connection:
remote address = 127.0.0.1:36951
error # = 337092801
message = error:1417A0C1:SSL
 routines:tls_post_process_client_hello:no shared cipher

 I have try to enable all ciphers with ALL:@SECLEVEL=0, but still get
 the same error,
 it is not clear why server client don't find a common cipher here.
> 
> I was not correctly setting the ciphers, Adding DHE to my ciphers and things
> work fine.
> 
> With 1.0.0 I only have DEFAULT:DSS, I guess DHE is not longer in the DEFAULT
> set

There are DHE ciphersuites in the default set, but there are no DSS
ciphersuites.

"DEFAULT" is treated as a special case when processing a cipher string -
and works completely differently to other keywords that you might use.
Most keywords are aliases for a set of ciphersuites, so "DHE" is the set
of all ciphersuites that use DHE; "DSS" is the set of all ciphersuites
that use DSS; "AES" is the set of all ciphersuites that use AES and so
on. "DEFAULT" on the other hand must appear first in a cipher string and
is just shorthand for saying:

"ALL:!COMPLEMENTOFDEFAULT:!eNULL"

COMPLEMENTOFDEFAULT is the set of ciphersuites that we don't switch on
by default (excluding eNULL based ciphersuites), and the "!" means
permanently switch off. So in other words DEFAULT is shorthand for
saying take ALL ciphersuites, and then permanently remove all of those
in the COMPLEMENTOFDEFAULT set, and permanently remove all of those in
the eNULL set.

All DSS based ciphersuites are in COMPLEMENTOFDEFAULT. Therefore
"DEFAULT:DSS" is permanently removing DSS (because its in
COMPLEMENTOFDEFAULT), and then attempting to add it back in again (which
it won't do because its been permanently removed).

Matt









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

Re: [openssl-users] DSA with OpenSSL-1.1

2016-07-01 Thread pepone.onrez 
On 1 July 2016 at 16:51, pepone.onrez  wrote:
> On 1 July 2016 at 16:40, Matt Caswell  wrote:
>>
>>
>> On 01/07/16 15:22, pepone.onrez wrote:
>>> On 1 July 2016 at 15:39, Matt Caswell  wrote:


 On 01/07/16 14:29, pepone.onrez wrote:
> Hi,
>
> After upgrade my software to use OpenSSL-1.1 one of the test is
> failing, the test in question client and server are configured to use
> DSA certificates. The server is configured to request a client
> certificate.
>
>SSL error occurred for new outgoing connection:
>remote address = 127.0.0.1:47812
>error # = 336151568
>message = error:14094410:SSL routines:ssl3_read_bytes:reason(1040)
>location = ssl/record/rec_layer_s3.c, 1467
>data = SSL alert number 40

 Is this the error you get on the server or the client? The above
 indicates the connection was aborted because a HandshakeFailure alert
 was received from the peer. Therefore you need to look at the other end
 of the communication and see if there is some error message that
 indicates why the alert was sent.

 Matt
>>> That was on the client, looking at the server I see it reports there
>>> is no shared
>>> cipher
>>>
>>>SSL error occurred for new incoming connection:
>>>remote address = 127.0.0.1:36951
>>>error # = 337092801
>>>message = error:1417A0C1:SSL
>>> routines:tls_post_process_client_hello:no shared cipher
>>>
>>> I have try to enable all ciphers with ALL:@SECLEVEL=0, but still get
>>> the same error,
>>> it is not clear why server client don't find a common cipher here.

I was not correctly setting the ciphers, Adding DHE to my ciphers and things
work fine.

With 1.0.0 I only have DEFAULT:DSS, I guess DHE is not longer in the DEFAULT
set

>>
>> Did you successfully load a DSA certificate and key into the server? If
>> the server doesn't like the cert/key for some reason then it won't make
>> any DSS ciphersuites available.
>>
>
> Yes I using SSL_CTX_use_certificate and SSL_CTX_use_PrivateKey and
> reading the pkcs12 cert with PKCS12_parse, that works fine with the rest
> of my test suite.
>
>> Also, I see you are trying to use a DHE based ciphersuite. Did you set
>> DH parameters to be used? If so how did you do it?
>>
>
> I'm using a DH callback to set the DH parameters
>
> DH*
> IceSSL_opensslDHCallback(SSL* ssl, int /*isExport*/, int keyLength)
> {
> #  if OPENSSL_VERSION_NUMBER >= 0x1010L
> SSL_CTX* ctx = SSL_get_SSL_CTX(ssl);
> #  else
> SSL_CTX* ctx = ssl->ctx;
> #  endif
> OpenSSLEngine* p =
> reinterpret_cast(SSL_CTX_get_ex_data(ctx, 0));
> return p->dhParams(keyLength);
> }
> #  endif
> }
>
> SSL_CTX_set_options(_ctx, SSL_OP_SINGLE_DH_USE);
> SSL_CTX_set_tmp_dh_callback(_ctx, IceSSL_opensslDHCallback);
>
> And for default parameters I'm using d2i_DHparams to restore the DH
> parameters I previously
> saved with i2d_DHparams
>
>
>> Matt
>>
>>
>>>
>>> Regards,
>>> José




>
> When using OpenSSL 1.0.1 the connection success
>
>cipher = DHE-DSS-AES256-GCM-SHA384
>bits = 256
>remote address = 127.0.0.1:43629
>protocol = TLSv1.2
>
>
> I try to set security level to 0 for 1.1 but that doesn't make any
> difference here, any ideas what could be the issue?
>
 --
 openssl-users mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DSA with OpenSSL-1.1

2016-07-01 Thread Salz, Rich 

> In short: Removing support for DSA in OpenSSL would prevent some of our
> products from updating to 1.1.x for a significant length of time, probably
> years.

We have no plans to do that.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DSA with OpenSSL-1.1

2016-07-01 Thread Michael Wojcik 
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Hanno Böck
> Sent: Friday, July 01, 2016 08:40
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] DSA with OpenSSL-1.1
> 
> I can't answer your question, but I have one to you: Why do you use DSA?
> 
> There was a discussion in the TLS working group a while ago about DSA
> support and there was overwhelming support to remove it in TLS 1.3.
> The rationale was basically that DSA in TLS is rarely used at all, is
> often used with insecure key sizes (1024 bit) and has a severe weakness
> when it comes to bad random numbers. On top of that it has basically no
> advantage over the much more widely used RSA. The original reason
> (in the early 90s) to use DSA over RSA were patent issues, but those are
> long expired.
> 
> So my (and I think most others) impression is that DSA in TLS is as
> dead as it can be and probably the most sane move for OpenSSL would be
> to just remove it. Given that I'd like to know why you seem to have
> chosen to still use DSA.

We have US Federal customers who require DSA. They have existing DSA 
certificates, their certificate process generates DSA certificates, and they're 
not showing any inclination to change, regardless of what crypto experts think.

Of course, this being the US Federal Government, it's entirely possible that 
tomorrow someone will issue a directive forbidding further use of DSA. But then 
it's also very likely that any such directive would be delayed for years. The 
wheels of US government cryptography grind slowly.

In short: Removing support for DSA in OpenSSL would prevent some of our 
products from updating to 1.1.x for a significant length of time, probably 
years.

-- 
Michael Wojcik
Technology Specialist, Micro Focus

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

[openssl-users] How to turn on certain elements in CMS objects

2016-07-01 Thread Stephan Mühlstrasser 

Hi,

this message is related to another question that I sent with subject 
"Unable to decrypt CMS object encrypted with EC prime256v1 certificate".


Below I have included the full ASN.1 dump of the CMS object generated by 
a third-party application.


The CMS object has two properties that I so far was not able to 
reproduce when creating CMS objects with OpenSSL:


First the AlgorithmIdentifier includes the EC curve name:

  40   19:   SEQUENCE {
  427: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 
2 1)
  518: OBJECT IDENTIFIER ansiX9p256r1 (1 2 840 
10045 3 1 7)

 : }

In CMS objects created with OpenSSL with the same recipient certificate, 
the curve name is always omitted. Is it possible to make OpenSSL emit 
the curve name as well?


Second the following:

 129   10:   [1] {
 1318: OCTET STRING B1 04 4A FD FC 8B 70 6D
 : }

If I match this correctly to RFC 5652, this is

ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL

inside the KeyAgreeRecipientInfo SEQUENCE (see 
https://tools.ietf.org/html/rfc5652#section-6.2.2).


Can OpenSSL emit this optional element? What is the purpose of the "ukm" 
field?


Thank you
Stephan

Full ASN.1 dump follows:

   0  360: SEQUENCE {
   49:   OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
  15  345:   [0] {
  19  341: SEQUENCE {
  231:   INTEGER 2
  26  256:   SET {
  30  253: [1] {
  331:   INTEGER 3
  36   91:   [0] {
  38   89: [1] {
  40   19:   SEQUENCE {
  427: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 
2 1)
  518: OBJECT IDENTIFIER ansiX9p256r1 (1 2 840 
10045 3 1 7)

 : }
  61   66:   BIT STRING
 : 04 0E 81 BC 28 63 C8 5A 1E 09 7D 47 1F D3 24 92
 : 15 6D 94 8A 8D 88 82 CC 65 1F FD 57 B4 B8 DD 77
 : 97 AB E7 D0 1D 8E C1 FE F6 CB C4 C5 9D B7 7B DE
 : 60 0E 84 F2 35 4E 19 42 EB B4 D9 F5 71 58 4F 53
 : 89
 :   }
 : }
 129   10:   [1] {
 1318: OCTET STRING B1 04 4A FD FC 8B 70 6D
 : }
 141   21:   SEQUENCE {
 1436: OBJECT IDENTIFIER '1 3 132 1 11 1'
 151   11: SEQUENCE {
 1539:   OBJECT IDENTIFIER aes128-wrap (2 16 840 1 101 
3 4 1 5)

 :   }
 : }
 164  120:   SEQUENCE {
 166  118: SEQUENCE {
 168   90:   SEQUENCE {
 170   85: SEQUENCE {
 172   11:   SET {
 1749: SEQUENCE {
 1763:   OBJECT IDENTIFIER countryName (2 5 4 6)
 1812:   PrintableString 'DE'
 :   }
 : }
 185   15:   SET {
 187   13: SEQUENCE {
 1893:   OBJECT IDENTIFIER localityName (2 5 4 7)
 1946:   UTF8String 'Munich'
 :   }
 : }
 202   20:   SET {
 204   18: SEQUENCE {
 2063:   OBJECT IDENTIFIER organizationName (2 
5 4 10)

 211   11:   UTF8String 'PDFlib GmbH'
 :   }
 : }
 224   31:   SET {
 226   29: SEQUENCE {
 2283:   OBJECT IDENTIFIER commonName (2 5 4 3)
 233   22:   UTF8String 'PDFlib GmbH Demo CA G2'
 :   }
 : }
 :   }
 2571: INTEGER 5
 : }
 260   24:   OCTET STRING
 : 2E 27 CB 94 64 71 E7 05 96 51 08 34 67 92 34 D7
 : 12 B1 69 8F 20 E9 F1 11
 :   }
 : }
 :   }
 : }
 286   76:   SEQUENCE {
 2889: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
 299   29: SEQUENCE {
 3019:   OBJECT IDENTIFIER aes128-CBC (2 16 840 1 101 3 4 1 2)
 312   16:   OCTET STRING
 : 88 E4 52 8D 63 2F A9 A5 49 0E 8B FE 7D D0 93 F9
 :   }
 330   32: [0]
 :   06 E8 97 3B AD 11 F8 49 41 C9 D6 C3 FD B4 22 4A
 :   89 DF AB 86 95 A7 D1 E0 C8 BF E5 8F 4D 79 7D D3
 : }
 :   }
 : }
 :   }

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

Re: [openssl-users] DSA with OpenSSL-1.1

2016-07-01 Thread pepone.onrez 
On 1 July 2016 at 16:40, Hanno Böck  wrote:
> Hi,
>
> On Fri, 1 Jul 2016 15:29:53 +0200
> "pepone.onrez"  wrote:
>
>> After upgrade my software to use OpenSSL-1.1 one of the test is
>> failing, the test in question client and server are configured to use
>> DSA certificates. The server is configured to request a client
>> certificate.
>
> I can't answer your question, but I have one to you: Why do you use DSA?
>
> There was a discussion in the TLS working group a while ago about DSA
> support and there was overwhelming support to remove it in TLS 1.3.
> The rationale was basically that DSA in TLS is rarely used at all, is
> often used with insecure key sizes (1024 bit) and has a severe weakness
> when it comes to bad random numbers. On top of that it has basically no
> advantage over the much more widely used RSA. The original reason
> (in the early 90s) to use DSA over RSA were patent issues, but those are
> long expired.
>
> So my (and I think most others) impression is that DSA in TLS is as
> dead as it can be and probably the most sane move for OpenSSL would be
> to just remove it. Given that I'd like to know why you seem to have
> chosen to still use DSA.

That is part of a large test suite for a library, just trying to
ensure that everithg
still works with OpenSSL 1.1.0

>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: BBB51E42
>
> --
> 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] DSA with OpenSSL-1.1

2016-07-01 Thread pepone.onrez 
On 1 July 2016 at 16:40, Matt Caswell  wrote:
>
>
> On 01/07/16 15:22, pepone.onrez wrote:
>> On 1 July 2016 at 15:39, Matt Caswell  wrote:
>>>
>>>
>>> On 01/07/16 14:29, pepone.onrez wrote:
 Hi,

 After upgrade my software to use OpenSSL-1.1 one of the test is
 failing, the test in question client and server are configured to use
 DSA certificates. The server is configured to request a client
 certificate.

SSL error occurred for new outgoing connection:
remote address = 127.0.0.1:47812
error # = 336151568
message = error:14094410:SSL routines:ssl3_read_bytes:reason(1040)
location = ssl/record/rec_layer_s3.c, 1467
data = SSL alert number 40
>>>
>>> Is this the error you get on the server or the client? The above
>>> indicates the connection was aborted because a HandshakeFailure alert
>>> was received from the peer. Therefore you need to look at the other end
>>> of the communication and see if there is some error message that
>>> indicates why the alert was sent.
>>>
>>> Matt
>> That was on the client, looking at the server I see it reports there
>> is no shared
>> cipher
>>
>>SSL error occurred for new incoming connection:
>>remote address = 127.0.0.1:36951
>>error # = 337092801
>>message = error:1417A0C1:SSL
>> routines:tls_post_process_client_hello:no shared cipher
>>
>> I have try to enable all ciphers with ALL:@SECLEVEL=0, but still get
>> the same error,
>> it is not clear why server client don't find a common cipher here.
>
> Did you successfully load a DSA certificate and key into the server? If
> the server doesn't like the cert/key for some reason then it won't make
> any DSS ciphersuites available.
>

Yes I using SSL_CTX_use_certificate and SSL_CTX_use_PrivateKey and
reading the pkcs12 cert with PKCS12_parse, that works fine with the rest
of my test suite.

> Also, I see you are trying to use a DHE based ciphersuite. Did you set
> DH parameters to be used? If so how did you do it?
>

I'm using a DH callback to set the DH parameters

DH*
IceSSL_opensslDHCallback(SSL* ssl, int /*isExport*/, int keyLength)
{
#  if OPENSSL_VERSION_NUMBER >= 0x1010L
SSL_CTX* ctx = SSL_get_SSL_CTX(ssl);
#  else
SSL_CTX* ctx = ssl->ctx;
#  endif
OpenSSLEngine* p =
reinterpret_cast(SSL_CTX_get_ex_data(ctx, 0));
return p->dhParams(keyLength);
}
#  endif
}

SSL_CTX_set_options(_ctx, SSL_OP_SINGLE_DH_USE);
SSL_CTX_set_tmp_dh_callback(_ctx, IceSSL_opensslDHCallback);

And for default parameters I'm using d2i_DHparams to restore the DH
parameters I previously
saved with i2d_DHparams


> Matt
>
>
>>
>> Regards,
>> José
>>>
>>>
>>>
>>>

 When using OpenSSL 1.0.1 the connection success

cipher = DHE-DSS-AES256-GCM-SHA384
bits = 256
remote address = 127.0.0.1:43629
protocol = TLSv1.2


 I try to set security level to 0 for 1.1 but that doesn't make any
 difference here, any ideas what could be the issue?

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

[openssl-users] Unable to decrypt CMS object encrypted with EC prime256v1 certificate

2016-07-01 Thread Stephan Mühlstrasser 

Hi,

we are testing OpenSSL interoperability with a third-party application, 
and we cannot decrypt a CMS object that is encrypted by the third-party 
application with a prime256v1 elliptic-curve certificate.


I have attached the following files:

demo_signer_ec_secp256r1.cms.der: DER-encoded CMS object
demo_signer_ec_secp256r1.cert.pem: recipient certificate
demo_signer_ec_secp256r1.pkey.pem. recipient private key (no password)

I try to decrypt the CMS object with the following command using OpenSSL 
1.0.2:


$ openssl version
OpenSSL 1.0.2h  3 May 2016
$ openssl cms -decrypt -in demo_signer_ec_secp256r1.cms.der  -inform DER 
-recip  demo_signer_ec_secp256r1.cert.pem  -inkey 
demo_signer_ec_secp256r1.pkey.pem

Error decrypting CMS using private key

When I use OpenSSL 1.1.0 beta from today's HEAD of the master branch, I 
see an additional error message:


$ openssl version
OpenSSL 1.1.0-pre6-dev  xx XXX 
$ openssl cms -decrypt -in demo_signer_ec_secp256r1.cms.der  -inform DER 
-recip  demo_signer_ec_secp256r1.cert.pem  -inkey 
demo_signer_ec_secp256r1.pkey.pem

Error decrypting CMS using private key
140735294530304:error:0D06E0A4:asn1 encoding 
routines:asn1_do_adb:unsupported any defined by 
type:crypto/asn1/tasn_utl.c:238:


Is the CMS object broken, or is this a problem in OpenSSL?

Thanks

--
Stephan


demo_signer_ec_secp256r1.cert.pem
Description: application/x509-ca-cert


demo_signer_ec_secp256r1.cms.der
Description: application/x509-ca-cert


demo_signer_ec_secp256r1.pkey.pem
Description: application/x509-ca-cert
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DSA with OpenSSL-1.1

2016-07-01 Thread Hanno Böck 
Hi,

On Fri, 1 Jul 2016 15:29:53 +0200
"pepone.onrez"  wrote:

> After upgrade my software to use OpenSSL-1.1 one of the test is
> failing, the test in question client and server are configured to use
> DSA certificates. The server is configured to request a client
> certificate.

I can't answer your question, but I have one to you: Why do you use DSA?

There was a discussion in the TLS working group a while ago about DSA
support and there was overwhelming support to remove it in TLS 1.3.
The rationale was basically that DSA in TLS is rarely used at all, is
often used with insecure key sizes (1024 bit) and has a severe weakness
when it comes to bad random numbers. On top of that it has basically no
advantage over the much more widely used RSA. The original reason
(in the early 90s) to use DSA over RSA were patent issues, but those are
long expired.

So my (and I think most others) impression is that DSA in TLS is as
dead as it can be and probably the most sane move for OpenSSL would be
to just remove it. Given that I'd like to know why you seem to have
chosen to still use DSA.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgppWLrwbnI5W.pgp
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DSA with OpenSSL-1.1

2016-07-01 Thread Matt Caswell 


On 01/07/16 15:22, pepone.onrez wrote:
> On 1 July 2016 at 15:39, Matt Caswell  wrote:
>>
>>
>> On 01/07/16 14:29, pepone.onrez wrote:
>>> Hi,
>>>
>>> After upgrade my software to use OpenSSL-1.1 one of the test is
>>> failing, the test in question client and server are configured to use
>>> DSA certificates. The server is configured to request a client
>>> certificate.
>>>
>>>SSL error occurred for new outgoing connection:
>>>remote address = 127.0.0.1:47812
>>>error # = 336151568
>>>message = error:14094410:SSL routines:ssl3_read_bytes:reason(1040)
>>>location = ssl/record/rec_layer_s3.c, 1467
>>>data = SSL alert number 40
>>
>> Is this the error you get on the server or the client? The above
>> indicates the connection was aborted because a HandshakeFailure alert
>> was received from the peer. Therefore you need to look at the other end
>> of the communication and see if there is some error message that
>> indicates why the alert was sent.
>>
>> Matt
> That was on the client, looking at the server I see it reports there
> is no shared
> cipher
> 
>SSL error occurred for new incoming connection:
>remote address = 127.0.0.1:36951
>error # = 337092801
>message = error:1417A0C1:SSL
> routines:tls_post_process_client_hello:no shared cipher
> 
> I have try to enable all ciphers with ALL:@SECLEVEL=0, but still get
> the same error,
> it is not clear why server client don't find a common cipher here.

Did you successfully load a DSA certificate and key into the server? If
the server doesn't like the cert/key for some reason then it won't make
any DSS ciphersuites available.

Also, I see you are trying to use a DHE based ciphersuite. Did you set
DH parameters to be used? If so how did you do it?

Matt


> 
> Regards,
> José
>>
>>
>>
>>
>>>
>>> When using OpenSSL 1.0.1 the connection success
>>>
>>>cipher = DHE-DSS-AES256-GCM-SHA384
>>>bits = 256
>>>remote address = 127.0.0.1:43629
>>>protocol = TLSv1.2
>>>
>>>
>>> I try to set security level to 0 for 1.1 but that doesn't make any
>>> difference here, any ideas what could be the issue?
>>>
>> --
>> 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] OpenSSL s_time output meaning

2016-07-01 Thread danigrosu 
> I'm not sure what use that information might be to you, since you haven't
told us why you're running s_time in the first place.

So that is why I am running s_time, to benchmark my customised Apache
server.
I had a little difficulty with its output. :D

Best wishes,
Dani Grosu

On 1 July 2016 at 16:12, Salz, Rich [via OpenSSL] <
ml-node+s6102n67168...@n7.nabble.com> wrote:

> Not answering the question, but that is a pretty cool thing you built!
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://openssl.6102.n7.nabble.com/OpenSSL-s-time-output-meaning-tp67092p67168.html
> To unsubscribe from OpenSSL s_time output meaning, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://openssl.6102.n7.nabble.com/OpenSSL-s-time-output-meaning-tp67092p67170.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DSA with OpenSSL-1.1

2016-07-01 Thread pepone.onrez 
On 1 July 2016 at 15:39, Matt Caswell  wrote:
>
>
> On 01/07/16 14:29, pepone.onrez wrote:
>> Hi,
>>
>> After upgrade my software to use OpenSSL-1.1 one of the test is
>> failing, the test in question client and server are configured to use
>> DSA certificates. The server is configured to request a client
>> certificate.
>>
>>SSL error occurred for new outgoing connection:
>>remote address = 127.0.0.1:47812
>>error # = 336151568
>>message = error:14094410:SSL routines:ssl3_read_bytes:reason(1040)
>>location = ssl/record/rec_layer_s3.c, 1467
>>data = SSL alert number 40
>
> Is this the error you get on the server or the client? The above
> indicates the connection was aborted because a HandshakeFailure alert
> was received from the peer. Therefore you need to look at the other end
> of the communication and see if there is some error message that
> indicates why the alert was sent.
>
> Matt
That was on the client, looking at the server I see it reports there
is no shared
cipher

   SSL error occurred for new incoming connection:
   remote address = 127.0.0.1:36951
   error # = 337092801
   message = error:1417A0C1:SSL
routines:tls_post_process_client_hello:no shared cipher

I have try to enable all ciphers with ALL:@SECLEVEL=0, but still get
the same error,
it is not clear why server client don't find a common cipher here.

Regards,
José
>
>
>
>
>>
>> When using OpenSSL 1.0.1 the connection success
>>
>>cipher = DHE-DSS-AES256-GCM-SHA384
>>bits = 256
>>remote address = 127.0.0.1:43629
>>protocol = TLSv1.2
>>
>>
>> I try to set security level to 0 for 1.1 but that doesn't make any
>> difference here, any ideas what could be the issue?
>>
> --
> 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] OpenSSL s_time output meaning

2016-07-01 Thread Salz, Rich 
Not answering the question, but that is a pretty cool thing you built!
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DSA with OpenSSL-1.1

2016-07-01 Thread Matt Caswell 


On 01/07/16 14:29, pepone.onrez wrote:
> Hi,
> 
> After upgrade my software to use OpenSSL-1.1 one of the test is
> failing, the test in question client and server are configured to use
> DSA certificates. The server is configured to request a client
> certificate.
> 
>SSL error occurred for new outgoing connection:
>remote address = 127.0.0.1:47812
>error # = 336151568
>message = error:14094410:SSL routines:ssl3_read_bytes:reason(1040)
>location = ssl/record/rec_layer_s3.c, 1467
>data = SSL alert number 40

Is this the error you get on the server or the client? The above
indicates the connection was aborted because a HandshakeFailure alert
was received from the peer. Therefore you need to look at the other end
of the communication and see if there is some error message that
indicates why the alert was sent.

Matt




> 
> When using OpenSSL 1.0.1 the connection success
> 
>cipher = DHE-DSS-AES256-GCM-SHA384
>bits = 256
>remote address = 127.0.0.1:43629
>protocol = TLSv1.2
> 
> 
> I try to set security level to 0 for 1.1 but that doesn't make any
> difference here, any ideas what could be the issue?
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] DSA with OpenSSL-1.1

2016-07-01 Thread pepone.onrez 
Hi,

After upgrade my software to use OpenSSL-1.1 one of the test is
failing, the test in question client and server are configured to use
DSA certificates. The server is configured to request a client
certificate.

   SSL error occurred for new outgoing connection:
   remote address = 127.0.0.1:47812
   error # = 336151568
   message = error:14094410:SSL routines:ssl3_read_bytes:reason(1040)
   location = ssl/record/rec_layer_s3.c, 1467
   data = SSL alert number 40

When using OpenSSL 1.0.1 the connection success

   cipher = DHE-DSS-AES256-GCM-SHA384
   bits = 256
   remote address = 127.0.0.1:43629
   protocol = TLSv1.2


I try to set security level to 0 for 1.1 but that doesn't make any
difference here, any ideas what could be the issue?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL-1.1-pre5 SSL_CTX_set_tmp_dh_callback

2016-07-01 Thread pepone.onrez 
On 1 July 2016 at 12:31, Matt Caswell  wrote:
>
>
> On 01/07/16 11:24, pepone.onrez wrote:
>> Hi,
>>
>> I trying to update my software to use OpenSSL-1.1 and I having problems
>> with DH callbacks
>>
>> When build with 1.1.0-pre5 the callback set with SSL_CTX_set_tmp_dh_callback
>> is not being called, when using 1.0.x it is called as expected.
>>
>> I have build 1.1.0-pre5 from sources with default configuration, do I
>> need any special build option for this to work?
>>
>> In my test the server and client enables only ADH ciphers, I see the
>> following ciphers are enabled:
>
> 1.1.0 has the concept of security levels to stop you from accidentally
> configuring bad things. The default security level is 1. ADH ciphers are
> in security level 0 (because they are considered insecure) and are
> therefore disabled by default, i.e. even if you configure them, if the
> security level isn't right then they won't get used.
>
> To set the security level differently you can either append
> "@SECLEVEL=0" to the end of the cipher string, or call
> SSL_set_security_level()/SSL_CTX_set_security_level().
>
> See:
> https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_security_level.html
>
> and
>
> https://www.openssl.org/docs/manmaster/apps/ciphers.html
>
> Matt

Thanks Matt that was it, setting SECLEVEL=0" make the test work
>
>
>>
>>ADH-AES256-GCM-SHA384
>>ADH-AES128-GCM-SHA256
>>ADH-AES256-SHA256
>>ADH-CAMELLIA256-SHA256
>>ADH-AES128-SHA256
>>ADH-CAMELLIA128-SHA256
>>ADH-AES256-SHA
>>ADH-CAMELLIA256-SHA
>>ADH-AES128-SHA
>>ADH-SEED-SHA
>>ADH-CAMELLIA128-SHA
>>ADH-DES-CBC3-SHA
>>
>>
>> The connection fails with
>>
>> error # = 337002677
>> message = error:141640B5:SSL routines:tls_construct_client_hello:no
>> ciphers available
>>
>> I assume this is related to the DH callback not being called, and so
>> ADH ciphers cannot be used?
>>
>> Any ideas why the DH callback is not being called, as I say the code
>> works fine with all previous OpenSSL versions.
>>
>> Regards,
>> José
>>
> --
> 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] Regarding FIPS capable openssl (I want to combine libcrypto.a and libssl.a)

2016-07-01 Thread Sahil Gandhi 
Hi All,

I am now able to solve this problem, myself.
We need to do changes in fipsld script.
Change 'crypto' or 'libcrypto' to whatever name (u want to specify for the
lib) in fipsld utility script and that's it.

Thanks,
-Sahil Gandhi

On Thu, Jun 30, 2016 at 9:28 AM, Sahil Gandhi 
wrote:

> Hi Steve,
>
> Thanks for the reply.
>
> Regards,
> Sahil
>
> On Wed, Jun 29, 2016 at 6:25 PM, Steve Marquess 
> wrote:
>
>> On 06/29/2016 07:09 AM, Sahil Gandhi wrote:
>> > Hi Ken,
>> >
>> > Sorry for the late reply. I really appreciate your suggestion but I some
>> > how need to have static library not the dynamic one.
>>
>> You can statically link an application with the FIPS module, using the
>> special "fipsld" link process, but you cannot put the FIPS module in a
>> conventional static library (as managed with "ar").
>>
>> Unfortunately the requirements of FIPS 140-2 conflict in several ways
>> with standard software engineering practice; it is the tail that wags
>> the dog.
>>
>> -Steve M.
>>
>> --
>> Steve Marquess
>> OpenSSL Validation Services, Inc.
>> 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
>>
>
>
>
> --
> Sahil Gandhi
> Project Engineer
> R CDAC, Pune
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL s_time output meaning

2016-07-01 Thread Daniel Grosu 
I've created an OpenSSL engine in order to use the GPU for RSA operations
(modular exponentiation) and I have integrated this engine with mod_ssl in
the Apache web server.
So, knowing about s_time command, I wanted to obtain the number of secured
connections per sec that Apache can handle using my engine.

Thank you for the support.

Best wishes,
Dani Grosu
On 30 Jun 2016 22:00, "Michael Wojcik" 
wrote:

> > From: openssl-users [mailto:[hidden email]
> ] On Behalf
> > Of danigrosu
> > Sent: Tuesday, June 28, 2016 22:57
> > To: [hidden email] 
> > Subject: [openssl-users] OpenSSL s_time output meaning
> >
> > Using the `$ openssl s_time -connect localhost:443 -new -time 30`
> command
> > gives this output:
> >
> > No CIPHER specified
> > Collecting connection statistics for 30 seconds
> > ** etc.
> > 8102 connections in 12.65s; 640.47 connections/user sec, bytes read 0
> > 8102 connections in 31 real seconds, 0 bytes read per connection
> >
> > What is the difference between 8102 connections in 12.65s and 8102
> > connections in 31 real seconds ?
>
> Use the source, Luke.
>
> Yes, the output is confusing; "real seconds" is not a particularly
> meaningful term. (What, the imaginary part is zero?) The value that's
> displayed there is the "wall-clock time" elapsed between the start of the
> test and when the report is produced. It's the sum of the time specified by
> -time (or the 30s default) plus the overhead that's not counted while
> timing actual OpenSSL operations, rounded to 1-second granularity.
>
> The 12.65s in the first line is the value of "totalTime", which is the
> accumulator for the timer the openssl command uses for timing the test. The
> s_time command starts this timer before the connection loop and stops it
> after the loop. The timer (in this case) counts only "user" time, that is
> time the process spends in user mode; that's why that line says "user sec".
>
> So this is telling you that your system uses about 1.5ms of user-mode CPU
> time per connection, and that it was able to make about 270 connections per
> second.
>
> I'm not sure what use that information might be to you, since you haven't
> told us why you're running s_time in the first place.
>
> --
> Michael Wojcik
> Technology Specialist, Micro Focus
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://openssl.6102.n7.nabble.com/OpenSSL-s-time-output-meaning-tp67092p67153.html
> To unsubscribe from OpenSSL s_time output meaning, click here
> 
> .
> NAML
> 
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL-1.1-pre5 SSL_CTX_set_tmp_dh_callback

2016-07-01 Thread Matt Caswell 


On 01/07/16 11:24, pepone.onrez wrote:
> Hi,
> 
> I trying to update my software to use OpenSSL-1.1 and I having problems
> with DH callbacks
> 
> When build with 1.1.0-pre5 the callback set with SSL_CTX_set_tmp_dh_callback
> is not being called, when using 1.0.x it is called as expected.
> 
> I have build 1.1.0-pre5 from sources with default configuration, do I
> need any special build option for this to work?
> 
> In my test the server and client enables only ADH ciphers, I see the
> following ciphers are enabled:

1.1.0 has the concept of security levels to stop you from accidentally
configuring bad things. The default security level is 1. ADH ciphers are
in security level 0 (because they are considered insecure) and are
therefore disabled by default, i.e. even if you configure them, if the
security level isn't right then they won't get used.

To set the security level differently you can either append
"@SECLEVEL=0" to the end of the cipher string, or call
SSL_set_security_level()/SSL_CTX_set_security_level().

See:
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_security_level.html

and

https://www.openssl.org/docs/manmaster/apps/ciphers.html

Matt


> 
>ADH-AES256-GCM-SHA384
>ADH-AES128-GCM-SHA256
>ADH-AES256-SHA256
>ADH-CAMELLIA256-SHA256
>ADH-AES128-SHA256
>ADH-CAMELLIA128-SHA256
>ADH-AES256-SHA
>ADH-CAMELLIA256-SHA
>ADH-AES128-SHA
>ADH-SEED-SHA
>ADH-CAMELLIA128-SHA
>ADH-DES-CBC3-SHA
> 
> 
> The connection fails with
> 
> error # = 337002677
> message = error:141640B5:SSL routines:tls_construct_client_hello:no
> ciphers available
> 
> I assume this is related to the DH callback not being called, and so
> ADH ciphers cannot be used?
> 
> Any ideas why the DH callback is not being called, as I say the code
> works fine with all previous OpenSSL versions.
> 
> Regards,
> José
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OpenSSL-1.1-pre5 SSL_CTX_set_tmp_dh_callback

2016-07-01 Thread pepone.onrez 
Hi,

I trying to update my software to use OpenSSL-1.1 and I having problems
with DH callbacks

When build with 1.1.0-pre5 the callback set with SSL_CTX_set_tmp_dh_callback
is not being called, when using 1.0.x it is called as expected.

I have build 1.1.0-pre5 from sources with default configuration, do I
need any special build option for this to work?

In my test the server and client enables only ADH ciphers, I see the
following ciphers are enabled:

   ADH-AES256-GCM-SHA384
   ADH-AES128-GCM-SHA256
   ADH-AES256-SHA256
   ADH-CAMELLIA256-SHA256
   ADH-AES128-SHA256
   ADH-CAMELLIA128-SHA256
   ADH-AES256-SHA
   ADH-CAMELLIA256-SHA
   ADH-AES128-SHA
   ADH-SEED-SHA
   ADH-CAMELLIA128-SHA
   ADH-DES-CBC3-SHA


The connection fails with

error # = 337002677
message = error:141640B5:SSL routines:tls_construct_client_hello:no
ciphers available

I assume this is related to the DH callback not being called, and so
ADH ciphers cannot be used?

Any ideas why the DH callback is not being called, as I say the code
works fine with all previous OpenSSL versions.

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