Re: [openssl-users] Query regarding DTLS handshake

[Martin Brejcha]

Matt Caswell wrote on 04/20/2017 03:23 PM:
> 
> 
> On 20/04/17 14:19, Martin Brejcha wrote:
>>
>>
>> Matt Caswell wrote on 04/20/2017 01:29 PM:
>>>
>>>
>>> On 20/04/17 12:26, mahesh gs wrote:
>>>> Hi Matt,
>>>>
>>>> Yes I raised github case for the same issue. I also tried running this
>>>> call flow with the latest SNAPSHOT code (openssl-SNAP-20170419) and
>>>> handshake is successful with the latest SNAPSHOT code which is not an
>>>> official release.
>>>>
>>>> I checked the github repo history and observer that during commits on
>>>> (11 th Jan) as a part of "Move state machine knowledge out of the record
>>>> layer".  "renegotiate" bit that is set to "2" in function
>>>> "tls_post_process_client_hello" has been removed. May be that is causing
>>>> the call flow to be successful in the latest SNAPSHOT release.
>>>>
>>>> I am assuming commits that are done on 11th Jan or later are not part of
>>>> release openssl 01.01.00e
>>>
>>> Ah. No. That commit is in the dev branch only (scheduled for version
>>> 1.1.1) and won't be backported to the 1.1.0 branch. I can see why that
>>> commit might help things, but probably a different solution is more
>>> appropriate for 1.1.0.
>>>
>>> I'm looking at this issue at the moment.
>>>
>>> Matt
>>>
>>
>> hi,
>>
>> btw: I've tested similar scenario and handshake works fine.
>> test env: client and server on different VMs (rhel7.2, openssl 1.1.0e, 
>> non-blocking sockets and segmented certificate)
>> So, it should work also with 1.1.0e version.
> 
> Thanks. Did your handshake include client auth? I think this issue only
> arises in that case.
> 
> Matt
> 
> 

yes, client auth with segmented certificate has been included.

Martin



> 
> 


0xB42AB632.asc
Description: application/pgp-keys


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

Re: [openssl-users] Query regarding DTLS handshake

[Martin Brejcha]

Matt Caswell wrote on 04/20/2017 01:29 PM:
> 
> 
> On 20/04/17 12:26, mahesh gs wrote:
>> Hi Matt,
>>
>> Yes I raised github case for the same issue. I also tried running this
>> call flow with the latest SNAPSHOT code (openssl-SNAP-20170419) and
>> handshake is successful with the latest SNAPSHOT code which is not an
>> official release.
>>
>> I checked the github repo history and observer that during commits on
>> (11 th Jan) as a part of "Move state machine knowledge out of the record
>> layer".  "renegotiate" bit that is set to "2" in function
>> "tls_post_process_client_hello" has been removed. May be that is causing
>> the call flow to be successful in the latest SNAPSHOT release.
>>
>> I am assuming commits that are done on 11th Jan or later are not part of
>> release openssl 01.01.00e
> 
> Ah. No. That commit is in the dev branch only (scheduled for version
> 1.1.1) and won't be backported to the 1.1.0 branch. I can see why that
> commit might help things, but probably a different solution is more
> appropriate for 1.1.0.
> 
> I'm looking at this issue at the moment.
> 
> Matt
> 

hi,

btw: I've tested similar scenario and handshake works fine.
test env: client and server on different VMs (rhel7.2, openssl 1.1.0e, 
non-blocking sockets and segmented certificate)
So, it should work also with 1.1.0e version.

Martin


>>
>>
>> Thanks,
>> Mahesh G S 
>>
>> On Wed, Apr 19, 2017 at 6:56 PM, Matt Caswell > > wrote:
>>
>> For those following this discussion Mahesh has created a github issue
>> with much more detail (at least I am assuming this is the same issue):
>>
>> https://github.com/openssl/openssl/issues/3251
>> 
>>
>> Matt
>>
>>
>> On 18/04/17 21:17, Michael Tuexen wrote:
>> >> On 13. Apr 2017, at 11:11, mahesh gs > > wrote:
>> >>
>> >> Hi,
>> >>
>> >> We are running SCTP connections with DTLS enabled in our
>> application. We have adapted openssl version (openssl-1.1.0e) to
>> achieve the same.
>> >>
>> >> We have generated the self signed root and node certificates for
>> testing. We have a strange problem with the incomplete DTLS
>> handshake if we run the DTLS client and DTLS server is different
>> systems.If we run the DTLS client and server in same system
>> handshake is successful, handshake is not successful if run client
>> and server in different VM's.
>> >>
>> >> This strange problem happens only for SCTP/DTLS connection. With
>> the same set of certificates TCP/TLS connection is successful and we
>> are able to exchange the application data.
>> >>
>> >> I am attaching the code bits for SSL_accept and SSL_connect and
>> also the wireshark trace of unsuccessful handshake. Please assist me
>> to debug this problem.
>> >>
>> >> SSL_accept returns  SSL_ERROR_WANT_READ(2) infinite times but
>> SSL_connect is called 4 or 5 times and select system call timeout.
>> > Which OS are you using? With a test program I could reproduce
>> SSL_accept() returning SSL_ERROR_WANT_READ under FreeBSD,
>> > but not under Linux. Haven't figured out what the problem is. So
>> if you are using FreeBSD we might experience the same problem...
>> >
>> > Best regards
>> > Michael
>> >>
>> >> Thanks,
>> >> Mahesh G S
>> >>
>> >>
>> >> --
>> >> 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
>> 
>>
>>
>>
>>


0xB42AB632.asc
Description: application/pgp-keys


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

Re: [openssl-users] Query regarding DTLS handshake

[Martin Brejcha]

Matt Caswell wrote on 04/13/2017 03:45 PM:
> 
> 
> On 13/04/17 10:11, mahesh gs wrote:
>> Hi,
>>
>> We are running SCTP connections with DTLS enabled in our application. We
>> have adapted openssl version (openssl-1.1.0e) to achieve the same.
>>
>> We have generated the self signed root and node certificates for
>> testing. We have a strange problem with the incomplete DTLS handshake if
>> we run the DTLS client and DTLS server is different systems.If we run
>> the DTLS client and server in same system handshake is successful,
>> handshake is not successful if run client and server in different VM's.
>>
>> This strange problem happens only for SCTP/DTLS connection. With the
>> same set of certificates TCP/TLS connection is successful and we are
>> able to exchange the application data.
>>
>> I am attaching the code bits for SSL_accept and SSL_connect and also the
>> wireshark trace of unsuccessful handshake. Please assist me to debug
>> this problem.
>>
>> SSL_accept returns  SSL_ERROR_WANT_READ(2) infinite times but
>> SSL_connect is called 4 or 5 times and select system call timeout.
> 
> Your trace shows the following interactions occurring:
> 
> Client Server
> -- --
> 
> ClientHello  >
>  < ServerHello
>  < Certificate
>  < CertificateRequest
>  < ServerDone
> Certificate  ->
> ClientKeyExchange->
> CertificateVerify->
> CCS  ->
> [Encrypted Finished]
> 
> We would expect the server to continue with its own CCS and Encrypted
> Finished to complete the handshake. It seems that, for some reason, the
> server is not receiving (or acting upon) the client's second flight of
> messages.
> 
> Normally in DTLS this sort of thing can happen due to lost messages etc
> but, obviously, with SCTP, this is not the case. Something else must be
> happening.
> 

There are some SCTP segmented messages during handshake.
May be some issue in reassembling could lead to strange behavior.
Can be observed these segmented messages also when the handshake is successful?

M.


> In your description you say SSL_accept() gets called repeatedly and
> always gives SSL_ERROR_WANT_READ. Looking at your code it looks like you
> are calling pollSocketForEvents() after each accept. I am assuming that
> this is returning true each time (otherwise you would break out of the
> loop). This suggests that the "select" call thinks there is something to
> read from the underlying socket. Am I correct? The question is why
> doesn't OpenSSL then read that data out of the socket?
> 
> Are you able to build a debug version of OpenSSL (run "config" with -d),
> and step through to figure out where it gets stuck. Is it attempting to
> read the data and failing, or does it not get as far attempting to read it?
> 
> Another question: does this fail every time or does it sometimes work
> and sometimes not (which might suggest some race condition)?
> 
> Matt
> 


0xB42AB632.asc
Description: application/pgp-keys


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