Query regarding DTLS handshake

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Help with ssl error

Joseph Southwell
Sorry we did do that. It just didn’t look different so I didn’t send it (pasted below). I also have asked for help from the server admin but it is a non English speaking country and they don’t seem to be interested in talking to me. I have another product supposedly using OpenSSL that is currently working fine so it must be possible. That product is using 0.9.8something. So specifying -cipher "AES128-SHA” will cause it to not use DHE?

openssl s_client -state -msg -cipher "ALL" -connect ftp.echannel.banksys.be:16370 -starttls ftp
CONNECTED(00000104)
SSL_connect:before SSL initialization
>>> ??? [length 0005]
    16 03 01 00 f7
>>> TLS 1.2Handshake [length 00f7], ClientHello
    01 00 00 f3 03 03 da ac 89 55 94 51 e0 ce 4b 3b
    ec ee 33 fd 31 1f 75 f1 50 1a 50 73 09 07 5a 0e
    cf 7d c3 ac 54 03 00 00 84 c0 2c c0 30 00 a3 00
    9f cc a9 cc a8 cc aa c0 af c0 ad c0 a3 c0 9f c0
    2b c0 2f 00 a2 00 9e c0 ae c0 ac c0 a2 c0 9e c0
    24 c0 28 00 6b 00 6a c0 73 c0 77 00 c4 00 c3 c0
    23 c0 27 00 67 00 40 c0 72 c0 76 00 be 00 bd c0
    0a c0 14 00 39 00 38 00 88 00 87 c0 09 c0 13 00
    33 00 32 00 9a 00 99 00 45 00 44 00 9d c0 a1 c0
    9d 00 9c c0 a0 c0 9c 00 3d 00 c0 00 3c 00 ba 00
    35 00 84 00 2f 00 96 00 41 00 07 00 ff 01 00 00
    46 00 0b 00 04 03 00 01 02 00 0a 00 0a 00 08 00
    1d 00 17 00 19 00 18 00 23 00 00 00 0d 00 20 00
    1e 06 01 06 02 06 03 05 01 05 02 05 03 04 01 04
    02 04 03 03 01 03 02 03 03 02 01 02 02 02 03 00
    16 00 00 00 17 00 00
SSL_connect:SSLv3/TLS write client hello
<<< ??? [length 0005]
    15 03 02 00 02
<<< TLS 1.2Alert [length 0002], fatal insufficient_security
    02 47
SSL3 alert read:fatal:insufficient security
SSL_connect:error in SSLv3/TLS write client hello
2152:error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient security:ssl\record\rec_layer_s3.c:1385:SSL alert number 71

On Apr 19, 2017, at 11:43 AM, Viktor Dukhovni <[hidden email]> wrote:

On Tue, Apr 18, 2017 at 05:06:40PM +0000, Viktor Dukhovni wrote:

The ClientHello decodes via tshark as:

[...]
               Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
               Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
               Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
               Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
[...]

This is a modern ClientHello (OpenSSL 1.1.0 it seems) and should
be broadly interoperable.  The DEFAULT cipherlist includes only
AES, is there a chance that the server only supports RC4 and/or
3DES?

Try:

   $ openssl s_client -state -msg -cipher ALL \
       -connect ftp.echannel.banksys.be:16370 -starttls ftp

Capture a PCAP file of the traffic with

   # tcpdump -s0 -w /some/file tcp port 16370

and post the the decode from:

   $ tshark -r /tmp/p2 -d tcp.port==16370,ssl -V |
       sed -ne '/^Secure Sockets Layer/,/^$/p'

Or just attach the PCAP file to your follow-up message.

On Wed, Apr 19, 2017 at 10:53:27AM -0400, Joseph Southwell wrote:

Is there a way to enable one or both of those ciphers in OpenSSL?

On Apr 18, 2017, at 1:28 PM, Jason Schultz <[hidden email]> wrote:

RSA_With_AES_128_CBC_SHA and RSA_With_3DES_EDE_CBC_SHA

With so many different names for the underlying TLS ciphersuites
one can only guess which ones are the same.  That said, I'd say
that the first one on your list is enabled by default, and was used
in your TLS ClientHello (TLS_RSA_WITH_AES_128_CBC_SHA 0x002f).

It is possible that (despite any claims to the contrary) the server
only supports the 3DES ciphersuite above, in which case you need
either OpenSSL 1.0.2 or a build of OpenSSL 1.1.0 with the Configure
option "--enable-weak-ssl-ciphers".   The 3DES TLS ciphers are by
default disabled at compile-time in OpenSSL 1.1.0 and later.

I did suggest the "-cipher ALL" option as a first place to start to
find out what the server actually supports.  I'm puzzled as to why
you've not tried that yet.

A more exotic scenario is that the server is configured with a weak
DHE group and having chosen DHE decides that the group is too weak.
In that case you could try just the purported AES cipher:

-cipher "AES128-SHA"

The name was obtained via:

   $ openssl ciphers -V ALL | grep 0x00,0x2F
     0x00,0x2F - AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1

Finally, you really should ask for help from the server administrator
they should have useful data in their logs.

--
Viktor.
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Help with ssl error

Viktor Dukhovni

> On Apr 19, 2017, at 12:48 PM, Joseph Southwell <[hidden email]> wrote:
>
> Sorry we did do that. It just didn’t look different so I didn’t send it (pasted below). I also have asked for help from the server admin but it is a non English speaking country and they don’t seem to be interested in talking to me. I have another product supposedly using OpenSSL that is currently working fine so it must be possible. That product is using 0.9.8something.

The "0.9.8something" releases support RC4, 3DES, export ciphers, ...
OpenSSL 1.1.0 does not by default include any of these.  You can
get RC4 and 3DES by compiling with weak ciphers enabled, the EXPORT
ciphers are expunged from the code.

> So specifying -cipher "AES128-SHA” will cause it to not use DHE?

Yes, it will offer just that single ciphersuite "0x002f" and nothing
else.  If that does not work, the claim that the server supports RSA
with AES-128-CBC is not credible.

To find out what it does support, build OpenSSL 1.0.2, and try connecting
with that version of "s_client".

Another thing to try is sending an SNI name (-servername ...), perhaps
the server wants to see that, though it seems very unlikely for FTP.

You could also try restricting the protocol to TLS 1.0, perhaps the
server mishandles TLS 1.2 and/or TLS 1.1:

        ... -no_tls1_2 -no_tls1_1

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

mahesh gs
In reply to this post by Matt Caswell-2
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


Thanks,
Mahesh G S 

On Wed, Apr 19, 2017 at 6:56 PM, Matt Caswell <[hidden email]> 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 <[hidden email]> 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
>>
>>
>> <testcode.txt><proxy.cap>--
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

Matt Caswell-2


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

>
>
> Thanks,
> Mahesh G S
>
> On Wed, Apr 19, 2017 at 6:56 PM, Matt Caswell <[hidden email]
> <mailto:[hidden email]>> 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
>     <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 <[hidden email]
>     <mailto:[hidden email]>> 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
>     >>
>     >>
>     >> <testcode.txt><proxy.cap>--
>     >> openssl-users mailing list
>     >> To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>     >
>     --
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>
>
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>     <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 <[hidden email]
>>     <mailto:[hidden email]>> 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
>>     >>
>>     >>
>>     >> <testcode.txt><proxy.cap>--
>>     >> openssl-users mailing list
>>     >> To unsubscribe:
>>     https://mta.openssl.org/mailman/listinfo/openssl-users
>>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>>     >
>>     --
>>     openssl-users mailing list
>>     To unsubscribe:
>>     https://mta.openssl.org/mailman/listinfo/openssl-users
>>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>>
>>
>>
>>

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

0xB42AB632.asc (3K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

Matt Caswell-2


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



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

signature.asc (491 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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



>
>

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

0xB42AB632.asc (3K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

mahesh gs
Hi,

This issue occur purely based on the time (sequence of events) at which SSL read_state_machine enter the post processing of certificate verify which is received from client.

Handshake works fine if the certificate verify post processing is done before the next message arrives at SCTP socket layer (In your case may be there is a delay in receiving the next message at SCTP layer). Handshake works fine even in my environment some times. 


I added some debug statements, below is the debug statements. 


Debug statements when the handshake does not work

Inline image 1

Length of the next packet (Cipher spec change) is exactly 14 as i mentioned  in - https://github.com/openssl/openssl/issues/3251

Debug logs when the handshake is successful

Inline image 3

If no message is waiting to be received at socket layer then handshake is successful. If message is waiting to be received at socket layer then the handshake will never be completed. 


Thanks,
Mahesh G S

On Thu, Apr 20, 2017 at 7:17 PM, Martin Brejcha <[hidden email]> wrote:


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



>
>

--
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
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

Michael Tuexen-4
> On 20. Apr 2017, at 20:01, mahesh gs <[hidden email]> wrote:
>
> Hi,
>
> This issue occur purely based on the time (sequence of events) at which SSL read_state_machine enter the post processing of certificate verify which is received from client.
>
> Handshake works fine if the certificate verify post processing is done before the next message arrives at SCTP socket layer (In your case may be there is a delay in receiving the next message at SCTP layer). Handshake works fine even in my environment some times.
Can you try the attached patch and report if it fixes the issue for you?

Best regards
Michael



>
>
> I added some debug statements, below is the debug statements.
>
>
> Debug statements when the handshake does not work
>
> <image.png>
>
> Length of the next packet (Cipher spec change) is exactly 14 as i mentioned  in - https://github.com/openssl/openssl/issues/3251
>
> Debug logs when the handshake is successful
>
> <image.png>
>
> If no message is waiting to be received at socket layer then handshake is successful. If message is waiting to be received at socket layer then the handshake will never be completed.
>
>
> Thanks,
> Mahesh G S
>
> On Thu, Apr 20, 2017 at 7:17 PM, Martin Brejcha <[hidden email]> wrote:
>
>
> 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
>
>
>
> >
> >
>
> --
> 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

dtls.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

mahesh gs


On Sun, Apr 30, 2017 at 11:11 PM, Michael Tuexen <[hidden email]> wrote:
> On 20. Apr 2017, at 20:01, mahesh gs <[hidden email]> wrote:
>
> Hi,
>
> This issue occur purely based on the time (sequence of events) at which SSL read_state_machine enter the post processing of certificate verify which is received from client.
>
> Handshake works fine if the certificate verify post processing is done before the next message arrives at SCTP socket layer (In your case may be there is a delay in receiving the next message at SCTP layer). Handshake works fine even in my environment some times.
Can you try the attached patch and report if it fixes the issue for you?

    I have tried with the patch provided by Matt. Our test results are successful. Issue is fixed with the patch.

Best regards
Michael



>
>
> I added some debug statements, below is the debug statements.
>
>
> Debug statements when the handshake does not work
>
> <image.png>
>
> Length of the next packet (Cipher spec change) is exactly 14 as i mentioned  in - https://github.com/openssl/openssl/issues/3251
>
> Debug logs when the handshake is successful
>
> <image.png>
>
> If no message is waiting to be received at socket layer then handshake is successful. If message is waiting to be received at socket layer then the handshake will never be completed.
>
>
> Thanks,
> Mahesh G S
>
> On Thu, Apr 20, 2017 at 7:17 PM, Martin Brejcha <[hidden email]> wrote:
>
>
> 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
>
>
>
> >
> >
>
> --
> 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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Query regarding DTLS handshake

Michael Tuexen-4

> On 2. May 2017, at 08:03, mahesh gs <[hidden email]> wrote:
>
>
>
> On Sun, Apr 30, 2017 at 11:11 PM, Michael Tuexen <[hidden email]> wrote:
> > On 20. Apr 2017, at 20:01, mahesh gs <[hidden email]> wrote:
> >
> > Hi,
> >
> > This issue occur purely based on the time (sequence of events) at which SSL read_state_machine enter the post processing of certificate verify which is received from client.
> >
> > Handshake works fine if the certificate verify post processing is done before the next message arrives at SCTP socket layer (In your case may be there is a delay in receiving the next message at SCTP layer). Handshake works fine even in my environment some times.
> Can you try the attached patch and report if it fixes the issue for you?
>
>     I have tried with the patch provided by Matt. Our test results are successful. Issue is fixed with the patch.
OK, I see. It isn't fixed in our case. That is why I sent the patch.
Thanks for the feedback.

Best regards
Michael

>
> Best regards
> Michael
>
>
>
> >
> >
> > I added some debug statements, below is the debug statements.
> >
> >
> > Debug statements when the handshake does not work
> >
> > <image.png>
> >
> > Length of the next packet (Cipher spec change) is exactly 14 as i mentioned  in - https://github.com/openssl/openssl/issues/3251
> >
> > Debug logs when the handshake is successful
> >
> > <image.png>
> >
> > If no message is waiting to be received at socket layer then handshake is successful. If message is waiting to be received at socket layer then the handshake will never be completed.
> >
> >
> > Thanks,
> > Mahesh G S
> >
> > On Thu, Apr 20, 2017 at 7:17 PM, Martin Brejcha <[hidden email]> wrote:
> >
> >
> > 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
> >
> >
> >
> > >
> > >
> >
> > --
> > 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 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
12