Re: [openssl-users] session resumption tls1.2/tls1.3
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.
> > 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)?
>
> 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.
> >
> > No. Time SourceDestination
> > Protocol Length Info
> > 217 18.381210 ::1 ::1
> > TLSv1.3 9917 Application Data --*Intended
> > Application Data that was intended to be early data *
> > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
> > 830, Ack: 3738, Len: 9841
> >
> > No. Time SourceDestination
> > Protocol Length Info
> > 219 18.381308 ::1 ::1
> > TLSv1.3 100Application Data . -Application Data
> > from client (I also see this application data sent everytime, not sure
> why)
> > Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
>
[openssl-users] OpenSSL on windows
Hi I'm trying to run amy application with OpenSSL libraries. I've generated fipscanister.lib, ssleay32.lib and libeayfips32.lib. In my code I'm making a call to FIPS_rsa_sign(). The test crashes when the control hits this function. But the same code runs successfully on Linux. -- Thanks... -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] session resumption tls1.2/tls1.3
On Mon, Jul 31, 2017 at 9:43 AM, Matt Caswell wrote:
> Apologies for the delayed response - I've been away on holiday. Comments
> inserted below.
>
No problem thanks for the replies
>
> Matt
>
>
> 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 )
>
>
> >> 2) Why does the server not send data (for early write) after the
> >> server Hello(and other encrypted message) message even when
> >> early_write succeeds on server side. Why does server wait to
> >> finish the handshake. I know it waits because I see client sending
> >> encrypted messages after server hello message before my intended
> >> application data gets sent from server. These encrypted messages
> >> from the client side are the usual messages from the client side
> >> for handshake completion.
> >>
> >
> > From a quick look through the state machine code, this is supposed
> > to work. But someone would probably have to instrument the code
> > (e.g., with printf) to tell why the delay is being introduced. I
> > don't think I have the availability to do so in the near future,
> myself.
> >
> >
> >
> > I see that the application data is not being sent from server to an
> > unauthenticated client. The server is sending data only after receiving
> > some encrypted message which I believe is the EndOfEarlyData and
> > Finished messages. Following is a dump of wireshark logs for the
> > communication with early data enabled. I also tried with some logs in
> > Openssl libraries, I see early data gets written from server side when
> > write_early_data is called. Internally SSL_write_ex is called which
> > completes write and handshake. But I am not sure why application data is
> > not actually pushed from the server side. It is waiting for the Client
> > finished message.
> > I have disabled Nagle's algo during this operation.
>
> Can you confirm whether you have disabled Nagle's algo on both the
> client *and* the server?`
>
Nagle's algorithm is disabled on both the client and the server side.
>
>
> >
> > Client port is 56806 and server port is 12345
> >
> >
> > No. Time SourceDestination
> > Protocol Length Info
> > 207 18.380298 ::1 ::1
> > TLSv1.3 956Client Hello - Client
> Hello
> >
> >
> > No. Time SourceDestination
> > Protocol Length Info
> > 208 18.380335 ::1 ::1
> > TLSv1.3 2849 Application Data --*Early Data
> > from the client side (Intended Application Data)*
> > Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> > 881, Ack: 1, Len: 2773
> >
> > No. Time SourceDestination
> > Protocol Length Info
> > 211 18.380624 ::1 ::1
> > TLSv1.3 219Server Hello, Application Data, Application Data .
> > Server Hello and (encrypted handshake message/extensions)
> > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 1,
> > Ack: 3654, Len: 143
> >
> > No. Time SourceDestination
> > Protocol Length Info
> > 213 18.380819 ::1 ::1
> > TLSv1.3 160Application Data, Application Data--Encrypted
> > handshake msg from client (*I believe they are end early data and
> finished*)
> > Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> > 3654, Ack: 144, Len: 84
> >
> >
> > No. Time SourceDestination
> > Protocol Length Info
> > 215 18.381122 ::1 ::1
Re: [openssl-users] openssl 1.0 and 1.1 co-exist
On 6/22/2017 7:05 AM, Jakob Bohm wrote: On 22/06/2017 04:31, Viktor Dukhovni wrote: On Wed, Jun 21, 2017 at 01:44:34PM -0400, Ken Goldman wrote: This is probably Linux specific ... Can both openssl versions co-exist on the same platform. I know that the .so is versioned, but how about the header files? Can I choose which library to build with? I wasn't specific enough. 1 - ... using standard rpms, not a custom install 2 - ... building as well as executing 3 - ... just modifying the makefile to point to different headers and so I.e., do the headers both go into /usr/include/openssl (which would clash)? Do the .so's both have the same name - libcrypto.so? It already works with a custom install and makefile. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] session resumption tls1.2/tls1.3
On 31/07/17 17:43, Matt Caswell wrote: > 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, I meant to say SSL_read_early_data() should have returned SSL_READ_EARLY_DATA_FINISH. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] session resumption tls1.2/tls1.3
Apologies for the delayed response - I've been away on holiday. Comments
inserted below.
Matt
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.
>> 2) Why does the server not send data (for early write) after the
>> server Hello(and other encrypted message) message even when
>> early_write succeeds on server side. Why does server wait to
>> finish the handshake. I know it waits because I see client sending
>> encrypted messages after server hello message before my intended
>> application data gets sent from server. These encrypted messages
>> from the client side are the usual messages from the client side
>> for handshake completion.
>>
>
> From a quick look through the state machine code, this is supposed
> to work. But someone would probably have to instrument the code
> (e.g., with printf) to tell why the delay is being introduced. I
> don't think I have the availability to do so in the near future, myself.
>
>
>
> I see that the application data is not being sent from server to an
> unauthenticated client. The server is sending data only after receiving
> some encrypted message which I believe is the EndOfEarlyData and
> Finished messages. Following is a dump of wireshark logs for the
> communication with early data enabled. I also tried with some logs in
> Openssl libraries, I see early data gets written from server side when
> write_early_data is called. Internally SSL_write_ex is called which
> completes write and handshake. But I am not sure why application data is
> not actually pushed from the server side. It is waiting for the Client
> finished message.
> I have disabled Nagle's algo during this operation.
Can you confirm whether you have disabled Nagle's algo on both the
client *and* the server?`
>
> Client port is 56806 and server port is 12345
>
>
> No. Time SourceDestination
> Protocol Length Info
> 207 18.380298 ::1 ::1
> TLSv1.3 956Client Hello - Client Hello
>
>
> No. Time SourceDestination
> Protocol Length Info
> 208 18.380335 ::1 ::1
> TLSv1.3 2849 Application Data --*Early Data
> from the client side (Intended Application Data)*
> Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> 881, Ack: 1, Len: 2773
>
> No. Time SourceDestination
> Protocol Length Info
> 211 18.380624 ::1 ::1
> TLSv1.3 219Server Hello, Application Data, Application Data .
> Server Hello and (encrypted handshake message/extensions)
> Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 1,
> Ack: 3654, Len: 143
>
> No. Time SourceDestination
> Protocol Length Info
> 213 18.380819 ::1 ::1
> TLSv1.3 160Application Data, Application Data--Encrypted
> handshake msg from client (*I believe they are end early data and finished*)
> Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> 3654, Ack: 144, Len: 84
>
>
> 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.
>
>
> No. Time SourceDestination
> Protocol Length Info
> 217 18.381210 ::1 ::1
> TLSv1.3 9917 Application Data --*Intended
> Application Data that was intended to be early data *
> Transmission Control Protocol, Src Port: 12345, D
Re: [openssl-users] Openssl 1.1 RSA_get0_key() documentation -> needs-cla
On 31/07/17 15:31, Kenneth Goldman wrote: > "openssl-users" wrote on 07/31/2017 > 09:20:59 AM: > >> From: Matt Caswell >> To: openssl-users@openssl.org >> Date: 07/31/2017 09:21 AM >> >> Click "New Issue" on this page: >> >> https://github.com/openssl/openssl/issues >> >> You'll need a github user id. >> >> > >> > I'd also be willing to help with documentation, if that's possible. >> >> It is possible. Make the relevant changes (file >> doc/man3/RSA_get0_key.pod) in a recent checkout of master and then >> create a github pull request: >> >> https://github.com/openssl/openssl/pulls > > I have an ID, but the pull request is marked needs-cla. > > How do I sign it? I just posted some commentary on that in the PR itself. Short answer, see: https://www.openssl.org/policies/cla.html Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Openssl 1.1 RSA_get0_key() documentation -> needs-cla
"openssl-users" wrote on 07/31/2017 09:20:59 AM: > From: Matt Caswell > To: openssl-users@openssl.org > Date: 07/31/2017 09:21 AM > > Click "New Issue" on this page: > > https://github.com/openssl/openssl/issues > > You'll need a github user id. > > > > > I'd also be willing to help with documentation, if that's possible. > > It is possible. Make the relevant changes (file > doc/man3/RSA_get0_key.pod) in a recent checkout of master and then > create a github pull request: > > https://github.com/openssl/openssl/pulls I have an ID, but the pull request is marked needs-cla. How do I sign it? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Openssl 1.1 RSA_get0_key() documentation
On 28/07/17 21:15, Ken Goldman wrote: > On 7/28/2017 4:05 PM, Salz, Rich via openssl-users wrote: >>> The __current__ code for this function returns values if the **BIGNUM is >>> not NULL. Thus, it appears safe to pass in NULL for values not needed. >> >>> >>> If this behavior is guaranteed, it would be nice if it was documented. >> >> Wanna open an issue to fix the doc? :) >> > > I'd be happy to, but I don't know how. Click "New Issue" on this page: https://github.com/openssl/openssl/issues You'll need a github user id. > > I'd also be willing to help with documentation, if that's possible. It is possible. Make the relevant changes (file doc/man3/RSA_get0_key.pod) in a recent checkout of master and then create a github pull request: https://github.com/openssl/openssl/pulls Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
