[openssl-users] Renegotiation with Client Certs failure

2017-08-01 Thread Adam Grossman 

Hello,

I inherited the code for web-server like server that i need to 
maintain.  It is setup that when you request a certain URL, the server 
will renegotiate and request a client certificate.  They said it worked 
when they use OpenSSL 0.9.8, but we are seeing issues with 1.0.2l.  When 
it does the renegotiation, the second SSL_handshake fails with 
"SSL_ERROR_SYSCALL" and ERR_get_error() returns 0.  But if i reload the 
page, it gets the client certificate and everything works and every 
subsequent request for that URL works.  But if i clear the cache and 
connect again, i get the same error.


Any help or pointers on how to further debug this would be greatly 
appreciated.


This is the relevant code:

SSL_set_verify(ssl, SSL_VERIFY_PEER |SSL_VERIFY_FAIL_IF_NO_PEER_CERT, 
verify_callback);

ssl_data->reneg_state = RENEG_ALLOW;
r=SSL_renegotiate(ssl);

if (r<=0)
{ // return error }

r=SSL_do_handshake(ssl);
if (r<=0)
{ // return error }

ssl->state=SSL_ST_ACCEPT;
do {
ERR_clear_error();
r=SSL_do_handshake(ssl);  // this is where it fails
if (r<=0) {
e=SSL_get_error(ssl,r);
int errR = ERR_get_error();
// printf("Error Level 1: e=%d r=%d errR=%d 
errno=%d\n",e,r,errR, errno);

}
}
while ((r !=1)  &&  ((e == SSL_ERROR_WANT_READ) || (e == 
SSL_ERROR_WANT_WRITE)));



thank you very much,

adamtg


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

Re: [openssl-users] How to get a bye or word from BIGNUM in OpenSSL 1.1?

2017-08-01 Thread Jakob Bohm 

On 02/08/2017 04:21, Jeffrey Walton wrote:

I'm trying to extract the low-order byte or word from a BIGNUM in
OpenSSL 1.1. We were told to use BN_bn2binpad, but its not clear to me
how to specify the location we want to extract.

For example:

 const char v[] = "ffeeddccbbaa99887766554433221100";
 BIGNUM n = BN_new();

 if (BN_hex2bn(&n, v))
 {
 fprintf(stderr, "failed to parse BIGNUM\n");
 exit (1);
 }

I don't see how to get the low-order word 33221100, or the second to
last byte 11.

Here' the documentation but I don't see how to do it:
https://www.openssl.org/docs/man1.1.0/crypto/BN_bn2binpad.html. Other
libraries, like Java, Botan and Crypto++ allow us to specify a potion
to extract from in cases like these.

How do we extract bytes or words from a BIGNUM?

Thanks in advance.

BN_bn2binpad (and it's friends) always give you *all* the bytes
in the number in a buffer of you own.  You can then extract the
bytes from there.

If you care mostly about the least significant bytes, using
BN_bn2lebinpad may be easier than BN_bn2binpad, as the least
significant bytes will be first, not last, in the result.

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] How to get a bye or word from BIGNUM in OpenSSL 1.1?

2017-08-01 Thread Jeffrey Walton 
I'm trying to extract the low-order byte or word from a BIGNUM in
OpenSSL 1.1. We were told to use BN_bn2binpad, but its not clear to me
how to specify the location we want to extract.

For example:

const char v[] = "ffeeddccbbaa99887766554433221100";
BIGNUM n = BN_new();

if (BN_hex2bn(&n, v))
{
fprintf(stderr, "failed to parse BIGNUM\n");
exit (1);
}

I don't see how to get the low-order word 33221100, or the second to
last byte 11.

Here' the documentation but I don't see how to do it:
https://www.openssl.org/docs/man1.1.0/crypto/BN_bn2binpad.html. Other
libraries, like Java, Botan and Crypto++ allow us to specify a potion
to extract from in cases like these.

How do we extract bytes or words from a BIGNUM?

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

Re: [openssl-users] session resumption tls1.2/tls1.3

2017-08-01 Thread Neetish Pathak 
On Tue, Aug 1, 2017 at 10:46 AM, Neetish Pathak  wrote:

>
>
> On Mon, Jul 31, 2017 at 2:00 PM, Matt Caswell  wrote:
>
>>
>>
>> On 31/07/17 20:37, Neetish Pathak wrote:
>> > On 26/07/17 00:05, Neetish Pathak wrote:
>> > >> *Pseudocode for server*
>> > >> *
>> > >> *
>> > >> tcp_accept
>> > >> *
>> > >> *
>> > >> read_early{
>> > >>
>> > >>  if(read_early_success){
>> > >>   write_early(data)
>> > >>   }
>> > >> }
>> >
>> > There is a bit of complexity here (covered in the docs), i.e.
>> > SSL_read_early_data() may return SSL_READ_EARLY_DATA_SUCCESS or
>> > SSL_READ_EARLY_DATA_FINISH. In the latter case this is still a
>> success,
>> > but the server may or may not be able to write early data. I assume
>> that
>> > you have covered that in your actual code and it's just skimmed over
>> > here in your pseudo code.
>> >
>> >
>> >
>> > So, I consider read_early_sucess when  SSL_read_early_data() returns
>> > SSL_READ_EARLY_DATA_FINISH. Also, I check that early data was accepted
>> > before declaring success. Look at the case checks below
>> >
>> > *case* SSL_READ_EARLY_DATA_SUCCESS:
>> >
>> > totalBytes += readBytes;
>> >
>> > * break*;
>> >
>> > *
>> > *
>> >
>> > *case* SSL_READ_EARLY_DATA_FINISH:
>> >
>> >totalBytes += readBytes;
>> >
>> > *   if* (SSL_EARLY_DATA_ACCEPTED ==
>> > SSL_get_early_data_status(*this*->conn) && totalBytes > 0) {
>> >
>> >  readBuf = string(readBuffer);
>> >
>> > * return* SUCCESS;
>> >
>> >   }
>> >
>> >
>> > So, are you suggesting that early data may not be written from the
>> > server side if SSL_READ_EARLY_DATA_FINISH is received. Should I try
>> > writing before that (as in when SSL_READ_EARLY_DATA_SUCCESS is received
>> )
>>
>>
>> SSL_READ_EARLY_DATA_FINISH is not returned until we have seen the
>> EndOfEarlyData message. Often (but not always - dependent on the
>> implementation) the client Finished message is also in the same packet
>> which OpenSSL will immediately try and process. As soon as it has done
>> so the handshake is complete and it is too late for the server to write
>> early data. Calls to SSL_write_early_data() by the server at this point
>> should fail (do you not see this???).
>>
>> You should write early data on the server side as soon as
>> SSL_READ_EARLY_DATA_SUCCESS is received.
>>
>
>
> Yes, this is what I tried and it worked. Thanks for the clarification.
> Also, this point is not very clear from the man page on when the write
> early data be sent from the server side (after SUCCESS or FINISH). Can it
> be included?
>
>>
>>
>>
>> > > No. Time   SourceDestination
>> > > Protocol Length Info
>> > > 215 18.381122  ::1   ::1
>> > > TLSv1.3  762Application Data
>> > > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806,
>> Seq:
>> > > 144, Ack: 3738, Len: 686   -I don't know why this application
>> data
>> > > is sent from server. My guess is this is session info
>> >
>> > It could be the NewSessionTicket message going from the server to
>> the
>> > client. But if so that is a little strange. The NST message is only
>> sent
>> > after the handshake is complete (so no more early data is
>> possible). At
>> > this point SSL_read_early_data() should have returned
>> > SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return
>> true,
>> > and any calls to SSL_write_early_data() will fail.
>> >
>> >
>> > Yes, here the handshake is completed. Will the new session ticket be
>> > sent each time after the handshake? In theTLS 1.3 draft, it is mentioned
>> > that new session tickets may be sent after server receives Finished from
>> > the client and it creates a unique association between the ticket value
>> > and a secret PSK derived from the resumption master secret.
>> > But looks like, I am receiving new session ticket every-time. So, as per
>> > the implementation, new session ticket is a must I guess. Am I right?
>> > When will I not receive new session ticket in TLS 1.3?
>>
>> The OpenSSL implementation *always* sends a NewSessionTicket message
>> immediately after the handshake is complete. This is not required, but
>> is allowed by the spec. Currently there is no way to disable this
>> behaviour. Do you need/want it (if so, why)?
>>
>
> No, I do not need to disable it per se. The handshake completion at the
> client side is independent of the newsession ticket coming from the server
> side if I am correct. So the handshake operation (specifically SSL_connect)
> will return even if new session ticket has not arrived from the server. I
> was asking why new session ticket is needed during the resumption
> handshake. Isn't it just an overhead?
>
>
>>
>> >
>> > Also, I believe it is different than how new session ticket works in TLS
>> > 1.2 whe

Re: [openssl-users] session resumption tls1.2/tls1.3

2017-08-01 Thread Neetish Pathak 
On Mon, Jul 31, 2017 at 2:00 PM, Matt Caswell  wrote:

>
>
> On 31/07/17 20:37, Neetish Pathak wrote:
> > On 26/07/17 00:05, Neetish Pathak wrote:
> > >> *Pseudocode for server*
> > >> *
> > >> *
> > >> tcp_accept
> > >> *
> > >> *
> > >> read_early{
> > >>
> > >>  if(read_early_success){
> > >>   write_early(data)
> > >>   }
> > >> }
> >
> > There is a bit of complexity here (covered in the docs), i.e.
> > SSL_read_early_data() may return SSL_READ_EARLY_DATA_SUCCESS or
> > SSL_READ_EARLY_DATA_FINISH. In the latter case this is still a
> success,
> > but the server may or may not be able to write early data. I assume
> that
> > you have covered that in your actual code and it's just skimmed over
> > here in your pseudo code.
> >
> >
> >
> > So, I consider read_early_sucess when  SSL_read_early_data() returns
> > SSL_READ_EARLY_DATA_FINISH. Also, I check that early data was accepted
> > before declaring success. Look at the case checks below
> >
> > *case* SSL_READ_EARLY_DATA_SUCCESS:
> >
> > totalBytes += readBytes;
> >
> > * break*;
> >
> > *
> > *
> >
> > *case* SSL_READ_EARLY_DATA_FINISH:
> >
> >totalBytes += readBytes;
> >
> > *   if* (SSL_EARLY_DATA_ACCEPTED ==
> > SSL_get_early_data_status(*this*->conn) && totalBytes > 0) {
> >
> >  readBuf = string(readBuffer);
> >
> > * return* SUCCESS;
> >
> >   }
> >
> >
> > So, are you suggesting that early data may not be written from the
> > server side if SSL_READ_EARLY_DATA_FINISH is received. Should I try
> > writing before that (as in when SSL_READ_EARLY_DATA_SUCCESS is received )
>
>
> SSL_READ_EARLY_DATA_FINISH is not returned until we have seen the
> EndOfEarlyData message. Often (but not always - dependent on the
> implementation) the client Finished message is also in the same packet
> which OpenSSL will immediately try and process. As soon as it has done
> so the handshake is complete and it is too late for the server to write
> early data. Calls to SSL_write_early_data() by the server at this point
> should fail (do you not see this???).
>
> You should write early data on the server side as soon as
> SSL_READ_EARLY_DATA_SUCCESS is received.
>


Yes, this is what I tried and it worked. Thanks for the clarification

>
>
>
> > > No. Time   SourceDestination
> > > Protocol Length Info
> > > 215 18.381122  ::1   ::1
> > > TLSv1.3  762Application Data
> > > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806,
> Seq:
> > > 144, Ack: 3738, Len: 686   -I don't know why this application
> data
> > > is sent from server. My guess is this is session info
> >
> > It could be the NewSessionTicket message going from the server to the
> > client. But if so that is a little strange. The NST message is only
> sent
> > after the handshake is complete (so no more early data is possible).
> At
> > this point SSL_read_early_data() should have returned
> > SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return true,
> > and any calls to SSL_write_early_data() will fail.
> >
> >
> > Yes, here the handshake is completed. Will the new session ticket be
> > sent each time after the handshake? In theTLS 1.3 draft, it is mentioned
> > that new session tickets may be sent after server receives Finished from
> > the client and it creates a unique association between the ticket value
> > and a secret PSK derived from the resumption master secret.
> > But looks like, I am receiving new session ticket every-time. So, as per
> > the implementation, new session ticket is a must I guess. Am I right?
> > When will I not receive new session ticket in TLS 1.3?
>
> The OpenSSL implementation *always* sends a NewSessionTicket message
> immediately after the handshake is complete. This is not required, but
> is allowed by the spec. Currently there is no way to disable this
> behaviour. Do you need/want it (if so, why)?
>

No, I do not need to disable it per se. The handshake completion at the
client side is independent of the newsession ticket coming from the server
side if I am correct. So the handshake operation (specifically SSL_connect)
will return even if new session ticket has not arrived from the server. I
was asking why new session ticket is needed during the resumption
handshake. Isn't it just an overhead?


>
> >
> > Also, I believe it is different than how new session ticket works in TLS
> > 1.2 where it was sent only once to share the encrypted ticket from the
> > server side when the client indicates support for session tickets.
>
> Yes, TLSv1.2 session tickets share the same name and have a similar
> purpose, but are otherwise *completely* different to TLSv1.3 session
> tickets.
>

Understood

>
>
> > >
> > > No. Time   Source

Re: [openssl-users] private key difference: openssl genrsa vs opnessl req newkey

2017-08-01 Thread Viktor Dukhovni 
On Wed, Jul 26, 2017 at 09:21:43PM +0200, Michele Mase' wrote:

> So, what should be the command line to use in order to obtain the same key?
> openssl genrsa 

This creates keys in a legacy RSA algorithm-specific format.

> openssl req -nodes -newkey rsa:2048 some_extra_parameters 

This creates keys in the preferred standard PKCS#8 format.

You can use "openssl pkey" to read legacy RSA keys and output
PKCS#8 keys.  Or you can use "openssl genpkey" to generate
PKCS#8 keys directly:

# RSA
(umask 077; openssl genpkey -algorithm rsa -pkeyopt rsa_keygen_bits:2048 
-out key.pem)

# ECDSA P-256
(umask 077; openssl genpkey -algorithm ec -pkeyopt 
ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -out key.pem)

# ECDSA P-384
(umask 077; openssl genpkey -algorithm ec -pkeyopt 
ec_paramgen_curve:secp384r1 -pkeyopt ec_param_enc:named_curve -out key.pem)

# ECDSA P-521
(umask 077; openssl genpkey -algorithm ec -pkeyopt 
ec_paramgen_curve:secp521r1 -pkeyopt ec_param_enc:named_curve -out key.pem)

It is unfortunate that OpenSSL 1.0.2 does not accept curve name
aliases for ec_paramgen_curve.  Thus, for example, only "prime256v1"
is accepted for P-256 and not any of its other names.

I've not checked whether this is fixed in OpenSSL 1.1.0.

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

Re: [openssl-users] private key difference: openssl genrsa vs opnessl req newkey

2017-08-01 Thread Michele Mase' 
Anyone?

On Wed, Jul 26, 2017 at 9:21 PM, Michele Mase' 
wrote:

> Tx.
> So, what should be the command line to use in order to obtain the same key?
> openssl genrsa 
> openssl req -nodes -newkey rsa:2048 some_extra_parameters 
> Michele MAsè
>
> On Wed, Jul 26, 2017 at 6:29 PM, Benjamin Kaduk  wrote:
>
>> On 07/26/2017 10:13 AM, Michele Mase' wrote:
>>
>> During the generation of x509 certificates, both commands give the same
>> results:
>>
>> Command "a": openssl req -nodes -newkey rsa:2048 -keyout example.key -out
>> example.csr -subj "/C=GB/ST=London/L=London/O=Global Security/OU=IT
>> Department/CN=example.com
>> 
>> "
>> Command "b": openssl genrsa -out example.key
>>
>> Both commands give me a private key without password, a key that is not
>> encrypted.
>> To remove the passphrase from private key, I use the
>> Command "c":openssl rsa -in example.key -out example2.key
>>
>> The command "c" against the example.key generated by command "a", gives
>> the same private key with different content between --BEGIN RSA and --END
>> RSA. Simply, try the following:
>> diff example.key example2.key, the files are different.
>>
>> The command "c" against example.key generate by the command "b" produces
>> the same file. No differences.
>>
>> Why?
>> Perhaps I missed something in openssl manual ... :(
>> These differenced gave me troubles using custom certificates in some
>> software.
>> Any suggestion?
>>
>>
>> The output from openssl req includes an additional layer of encoding and
>> the rsaEncryption OID around the actual key parameters, as can be seen
>> using openssl asn1parse.  The conversion with 'openssl rsa' removes that
>> extra encoding.
>>
>> -Ben
>>
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] -engine pkcs11 - keyform ENGINE -inkey ABC : NOT in command line

2017-08-01 Thread majkl majkl 
I need these openssl parameters to be used without specifying it in command
line. It doesn't matter, if it is in config file or environment variables.

How to do that?

(I need to sign xml documents via xmlsec. xmlsec can use openssl as crypto,
but I do not have idea, how xmlsec call openssl. It does not try to access
the USB token for key. openssl with the command line parameters can access
the key on the USB token with no problems.)

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