Re: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q

[Jeffrey Walton]

On Sun, Jun 19, 2016 at 10:10 AM, Blumenthal, Uri - 0553 - MITLL
 wrote:
> I'm also speaking out of turn, but having both ends trying to be both server 
> and client *on the same connection* just does not make sense, TLS or DTLS.
>

Yeah, I was having trouble envisioning the use case. But I did not
want to dismiss it until I understood the requirements.

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

Re: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q

[Blumenthal, Uri - 0553 - MITLL]

I'm also speaking out of turn, but having both ends trying to be both server 
and client *on the same connection* just does not make sense, TLS or DTLS.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Jeffrey Walton
Sent: Sunday, June 19, 2016 09:59
To: OpenSSL Users
Reply To: noloa...@gmail.com
Subject: Re: [openssl-users] Fwd: issue with dtls failure during openssl 
upgrade from 1.0.1m to q

On Sun, Jun 19, 2016 at 9:47 AM, Test ssl <testossl2...@gmail.com> wrote:
> Hi Matt,
>
> This is a DTLSv1.0 connection, so the hosts on both sides will connect to
> each other acting as both TLS client and TLS server.
>
> We think the dtls failure is due to cipher suites. But we are not able to
> understand why it works for 1.0.1m with same certificate.
>
> Please help us.

I don't mean to speak out of turn, but you are not giving Matt too
much to work with.

Perhaps you could put together a minimum sample program which
demonstrates the problem? Or maybe give him s_server and s_client
commands to duplicate it?

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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q

[Matt Caswell]

On 19/06/16 14:47, Test ssl wrote:
> Hi Matt,
> 
> This is a DTLSv1.0 connection, so the hosts on both sides will connect
> to each other acting as both TLS client and TLS server.

That makes no sense at all - it isn't the way DTLS works. DTLS has a
single client role and a single server role in all DTLS versions
(including DTLSv1.0). In that respect it is the same as TLS.


> 
> We think the dtls failure is due to cipher suites. But we are not able
> to understand why it works for 1.0.1m with same certificate.

Possibly it is. However the confused roles above are highly suspect and
that could also be the cause. The traces you sent suggest that you are
mixing messages from two different DTLS connections across a single UDP
connection. If that's really what is happening then I'm not surprised it
fails.

Matt


> 
> Please help us.
> 
> Regards,
> 
> On Fri, Jun 17, 2016 at 10:05 PM, Matt Caswell  > wrote:
> 
> 
> 
> On 17/06/16 17:29, Test ssl wrote:
> > Hi Matt,
> >
> > With same application code and openssl1.0.1m we are not facing "Alert
> > (Handshake Failure)" but in case of 1.0.1q we are facing it.
> >
> > That is what we are not able to understand that what is the reason for
> > this "Alert (Handshake Failure)".
> >
> > Please help us on this, which part of functionality we can modify in the
> > application code to overcome this DTLS handshake failure.
> 
> Well to have a chance of answering that I need to understand why your
> application is behaving in the way I described below. If your
> application is doing something weird and unexpected it may well be that
> it just happened to work by accident in 1.0.1m, but something under the
> hood changed, and it doesn't any more.
> 
> Why do we see this strange double handshake in your application where
> the client/server apparently switch roles? Is there something about your
> application design that could explain it? Is it intentional?
> 
> Matt
> 
> 
> >
> > Regards,
> >
> > On Fri, Jun 17, 2016 at 5:55 PM, Matt Caswell  
> > >> wrote:
> >
> > Hello
> >
> > On 17/06/16 12:04, Test ssl wrote:
> > > We are facing an issue with DTLS failure during the Openssl
> upgrade from
> > > 1.0.1m to 1.0.1q. We have attached the network trace file in
> attachment
> > > with good (1.0.1m) and fail (1.0.1q) case.
> > >
> > > The test scenario is that we are trying to connect a cisco based
> > > Endpoint device to a Video conference server, where our code
> resides.
> > >
> > > Please help us with this DTLS failure scenario which we are
> not able to
> > > understand that what wrong we did in our application code in
> using
> > > Openssl APIs.
> >
> > This looks like quite a strange trace in both the success and
> > failure cases.
> >
> > The traces are slightly confusing because it looks like you
> are making
> > multiple connections from different ports. To simplify things
> in the
> > success case I filtered wireshark to only show me the port
> 22602 <->
> > port 49164 communication.
> >
> > This showed me the following interaction
> >
> >
> > Client Server
> > == ==
> >
> > ClientHello
> >ServerHello
> >Certificate
> >ServerHelloDone
> > ClientKeyExchange
> > ChangeCipherSpec
> > EncryptedHandshakeMessage
> >ChangeCipherSpec
> >EncryptedHandshakeMessage
> >
> > So far so good. This looks like a normal successful handshake. The
> > EncryptedHandshakeMessages at the end of these exchanges are the
> > Finished messages indicating that the handshake was
> successful. I would
> > then expect to see Application Data being exchanged. Instead I
> see this:
> >
> > Client Server
> > == ==
> >
> >ClientHello
> > ServerHello
> > Certificate
> > ServerKeyExchange
> > CertificateRequest
> > ServerHelloDone
> >Certificate
> >ClientKeyExchange
> >CertificateVerify
> >ChangeCipherSpec
> >EncryptedHandshakeMessage
> > ChangeCipherSpec
> > EncryptedHandshakeMessage
> >
> >

Re: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q

[Jeffrey Walton]

On Sun, Jun 19, 2016 at 9:47 AM, Test ssl  wrote:
> Hi Matt,
>
> This is a DTLSv1.0 connection, so the hosts on both sides will connect to
> each other acting as both TLS client and TLS server.
>
> We think the dtls failure is due to cipher suites. But we are not able to
> understand why it works for 1.0.1m with same certificate.
>
> Please help us.

I don't mean to speak out of turn, but you are not giving Matt too
much to work with.

Perhaps you could put together a minimum sample program which
demonstrates the problem? Or maybe give him s_server and s_client
commands to duplicate it?

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

Re: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q

[Test ssl]

Hi Matt,

This is a DTLSv1.0 connection, so the hosts on both sides will connect to
each other acting as both TLS client and TLS server.

We think the dtls failure is due to cipher suites. But we are not able to
understand why it works for 1.0.1m with same certificate.

Please help us.

Regards,

On Fri, Jun 17, 2016 at 10:05 PM, Matt Caswell  wrote:

>
>
> On 17/06/16 17:29, Test ssl wrote:
> > Hi Matt,
> >
> > With same application code and openssl1.0.1m we are not facing "Alert
> > (Handshake Failure)" but in case of 1.0.1q we are facing it.
> >
> > That is what we are not able to understand that what is the reason for
> > this "Alert (Handshake Failure)".
> >
> > Please help us on this, which part of functionality we can modify in the
> > application code to overcome this DTLS handshake failure.
>
> Well to have a chance of answering that I need to understand why your
> application is behaving in the way I described below. If your
> application is doing something weird and unexpected it may well be that
> it just happened to work by accident in 1.0.1m, but something under the
> hood changed, and it doesn't any more.
>
> Why do we see this strange double handshake in your application where
> the client/server apparently switch roles? Is there something about your
> application design that could explain it? Is it intentional?
>
> Matt
>
>
> >
> > Regards,
> >
> > On Fri, Jun 17, 2016 at 5:55 PM, Matt Caswell  > > wrote:
> >
> > Hello
> >
> > On 17/06/16 12:04, Test ssl wrote:
> > > We are facing an issue with DTLS failure during the Openssl
> upgrade from
> > > 1.0.1m to 1.0.1q. We have attached the network trace file in
> attachment
> > > with good (1.0.1m) and fail (1.0.1q) case.
> > >
> > > The test scenario is that we are trying to connect a cisco based
> > > Endpoint device to a Video conference server, where our code
> resides.
> > >
> > > Please help us with this DTLS failure scenario which we are not
> able to
> > > understand that what wrong we did in our application code in using
> > > Openssl APIs.
> >
> > This looks like quite a strange trace in both the success and
> > failure cases.
> >
> > The traces are slightly confusing because it looks like you are
> making
> > multiple connections from different ports. To simplify things in the
> > success case I filtered wireshark to only show me the port 22602 <->
> > port 49164 communication.
> >
> > This showed me the following interaction
> >
> >
> > Client Server
> > == ==
> >
> > ClientHello
> >ServerHello
> >Certificate
> >ServerHelloDone
> > ClientKeyExchange
> > ChangeCipherSpec
> > EncryptedHandshakeMessage
> >ChangeCipherSpec
> >EncryptedHandshakeMessage
> >
> > So far so good. This looks like a normal successful handshake. The
> > EncryptedHandshakeMessages at the end of these exchanges are the
> > Finished messages indicating that the handshake was successful. I
> would
> > then expect to see Application Data being exchanged. Instead I see
> this:
> >
> > Client Server
> > == ==
> >
> >ClientHello
> > ServerHello
> > Certificate
> > ServerKeyExchange
> > CertificateRequest
> > ServerHelloDone
> >Certificate
> >ClientKeyExchange
> >CertificateVerify
> >ChangeCipherSpec
> >EncryptedHandshakeMessage
> > ChangeCipherSpec
> > EncryptedHandshakeMessage
> >
> > So AFAICT the client and server appear to have swapped roles!!! The
> > server is sending Client message and the client is sending server
> > messages. Not only that but the connection previously established
> seems
> > to have been thrown away and they are starting from scratch (i.e.
> > unencrypted) without having first shutdown the previous connection or
> > having sent any application data.
> >
> > The failure case is similar. The client and server apparently
> > successfully complete a handshake. They then seem to swap roles
> > (starting from scratch again, without any app data being sent),
> except
> > this time we see:
> >
> > Client Server
> > == ==
> >
> >ClientHello
> >
> > ServerHello
> > Certificate
> > ServerKeyExchange
> > CertificateRequest
> > ServerHelloDone
> >Alert (Handshake Failure)
> >ClientHello
> > 

Re: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q

[Matt Caswell]

On 17/06/16 17:29, Test ssl wrote:
> Hi Matt,
> 
> With same application code and openssl1.0.1m we are not facing "Alert
> (Handshake Failure)" but in case of 1.0.1q we are facing it.
> 
> That is what we are not able to understand that what is the reason for
> this "Alert (Handshake Failure)".
> 
> Please help us on this, which part of functionality we can modify in the
> application code to overcome this DTLS handshake failure.

Well to have a chance of answering that I need to understand why your
application is behaving in the way I described below. If your
application is doing something weird and unexpected it may well be that
it just happened to work by accident in 1.0.1m, but something under the
hood changed, and it doesn't any more.

Why do we see this strange double handshake in your application where
the client/server apparently switch roles? Is there something about your
application design that could explain it? Is it intentional?

Matt


> 
> Regards,
> 
> On Fri, Jun 17, 2016 at 5:55 PM, Matt Caswell  > wrote:
> 
> Hello
> 
> On 17/06/16 12:04, Test ssl wrote:
> > We are facing an issue with DTLS failure during the Openssl upgrade from
> > 1.0.1m to 1.0.1q. We have attached the network trace file in attachment
> > with good (1.0.1m) and fail (1.0.1q) case.
> >
> > The test scenario is that we are trying to connect a cisco based
> > Endpoint device to a Video conference server, where our code resides.
> >
> > Please help us with this DTLS failure scenario which we are not able to
> > understand that what wrong we did in our application code in using
> > Openssl APIs.
> 
> This looks like quite a strange trace in both the success and
> failure cases.
> 
> The traces are slightly confusing because it looks like you are making
> multiple connections from different ports. To simplify things in the
> success case I filtered wireshark to only show me the port 22602 <->
> port 49164 communication.
> 
> This showed me the following interaction
> 
> 
> Client Server
> == ==
> 
> ClientHello
>ServerHello
>Certificate
>ServerHelloDone
> ClientKeyExchange
> ChangeCipherSpec
> EncryptedHandshakeMessage
>ChangeCipherSpec
>EncryptedHandshakeMessage
> 
> So far so good. This looks like a normal successful handshake. The
> EncryptedHandshakeMessages at the end of these exchanges are the
> Finished messages indicating that the handshake was successful. I would
> then expect to see Application Data being exchanged. Instead I see this:
> 
> Client Server
> == ==
> 
>ClientHello
> ServerHello
> Certificate
> ServerKeyExchange
> CertificateRequest
> ServerHelloDone
>Certificate
>ClientKeyExchange
>CertificateVerify
>ChangeCipherSpec
>EncryptedHandshakeMessage
> ChangeCipherSpec
> EncryptedHandshakeMessage
> 
> So AFAICT the client and server appear to have swapped roles!!! The
> server is sending Client message and the client is sending server
> messages. Not only that but the connection previously established seems
> to have been thrown away and they are starting from scratch (i.e.
> unencrypted) without having first shutdown the previous connection or
> having sent any application data.
> 
> The failure case is similar. The client and server apparently
> successfully complete a handshake. They then seem to swap roles
> (starting from scratch again, without any app data being sent), except
> this time we see:
> 
> Client Server
> == ==
> 
>ClientHello
> 
> ServerHello
> Certificate
> ServerKeyExchange
> CertificateRequest
> ServerHelloDone
>Alert (Handshake Failure)
>ClientHello
> ServerHello
> Certificate
> ServerKeyExchange
> CertificateRequest
> ServerHelloDone
>Alert (Decrypt Error)
> 
> 
> So here we see the "server", that seems to have forgotten it is the
> server and is now acting as the client attempt to initiate a handshake
> (forgetting all about the previous connection). It then fails with a
> Handshake Failure (I'm not surprised), and apparently decides to have
> another go. This time we see a DecryptError which suggests the "server"
> (acting as a client) is expecting to receive 

Re: [openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q

[Test ssl]

Hi Matt,

With same application code and openssl1.0.1m we are not facing "Alert
(Handshake Failure)" but in case of 1.0.1q we are facing it.

That is what we are not able to understand that what is the reason for this
"Alert (Handshake Failure)".

Please help us on this, which part of functionality we can modify in the
application code to overcome this DTLS handshake failure.

Regards,

On Fri, Jun 17, 2016 at 5:55 PM, Matt Caswell  wrote:

> Hello
>
> On 17/06/16 12:04, Test ssl wrote:
> > We are facing an issue with DTLS failure during the Openssl upgrade from
> > 1.0.1m to 1.0.1q. We have attached the network trace file in attachment
> > with good (1.0.1m) and fail (1.0.1q) case.
> >
> > The test scenario is that we are trying to connect a cisco based
> > Endpoint device to a Video conference server, where our code resides.
> >
> > Please help us with this DTLS failure scenario which we are not able to
> > understand that what wrong we did in our application code in using
> > Openssl APIs.
>
> This looks like quite a strange trace in both the success and failure
> cases.
>
> The traces are slightly confusing because it looks like you are making
> multiple connections from different ports. To simplify things in the
> success case I filtered wireshark to only show me the port 22602 <->
> port 49164 communication.
>
> This showed me the following interaction
>
>
> Client Server
> == ==
>
> ClientHello
>ServerHello
>Certificate
>ServerHelloDone
> ClientKeyExchange
> ChangeCipherSpec
> EncryptedHandshakeMessage
>ChangeCipherSpec
>EncryptedHandshakeMessage
>
> So far so good. This looks like a normal successful handshake. The
> EncryptedHandshakeMessages at the end of these exchanges are the
> Finished messages indicating that the handshake was successful. I would
> then expect to see Application Data being exchanged. Instead I see this:
>
> Client Server
> == ==
>
>ClientHello
> ServerHello
> Certificate
> ServerKeyExchange
> CertificateRequest
> ServerHelloDone
>Certificate
>ClientKeyExchange
>CertificateVerify
>ChangeCipherSpec
>EncryptedHandshakeMessage
> ChangeCipherSpec
> EncryptedHandshakeMessage
>
> So AFAICT the client and server appear to have swapped roles!!! The
> server is sending Client message and the client is sending server
> messages. Not only that but the connection previously established seems
> to have been thrown away and they are starting from scratch (i.e.
> unencrypted) without having first shutdown the previous connection or
> having sent any application data.
>
> The failure case is similar. The client and server apparently
> successfully complete a handshake. They then seem to swap roles
> (starting from scratch again, without any app data being sent), except
> this time we see:
>
> Client Server
> == ==
>
>ClientHello
>
> ServerHello
> Certificate
> ServerKeyExchange
> CertificateRequest
> ServerHelloDone
>Alert (Handshake Failure)
>ClientHello
> ServerHello
> Certificate
> ServerKeyExchange
> CertificateRequest
> ServerHelloDone
>Alert (Decrypt Error)
>
>
> So here we see the "server", that seems to have forgotten it is the
> server and is now acting as the client attempt to initiate a handshake
> (forgetting all about the previous connection). It then fails with a
> Handshake Failure (I'm not surprised), and apparently decides to have
> another go. This time we see a DecryptError which suggests the "server"
> (acting as a client) is expecting to receive encrypted data, but the
> client (acting as a server) is still sending unencrypted data.
>
> You need to try and figure out why the two ends of the communication are
> so confused about what role they are playing (or is there something you
> haven't told me about the way your application works?).
>
> Matt
>
>
>
> --
> 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] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q

[Matt Caswell]

Hello

On 17/06/16 12:04, Test ssl wrote:
> We are facing an issue with DTLS failure during the Openssl upgrade from
> 1.0.1m to 1.0.1q. We have attached the network trace file in attachment
> with good (1.0.1m) and fail (1.0.1q) case.
> 
> The test scenario is that we are trying to connect a cisco based
> Endpoint device to a Video conference server, where our code resides.
> 
> Please help us with this DTLS failure scenario which we are not able to
> understand that what wrong we did in our application code in using
> Openssl APIs.

This looks like quite a strange trace in both the success and failure cases.

The traces are slightly confusing because it looks like you are making
multiple connections from different ports. To simplify things in the
success case I filtered wireshark to only show me the port 22602 <->
port 49164 communication.

This showed me the following interaction


Client Server
== ==

ClientHello
   ServerHello
   Certificate
   ServerHelloDone
ClientKeyExchange
ChangeCipherSpec
EncryptedHandshakeMessage
   ChangeCipherSpec
   EncryptedHandshakeMessage

So far so good. This looks like a normal successful handshake. The
EncryptedHandshakeMessages at the end of these exchanges are the
Finished messages indicating that the handshake was successful. I would
then expect to see Application Data being exchanged. Instead I see this:

Client Server
== ==

   ClientHello
ServerHello
Certificate
ServerKeyExchange
CertificateRequest
ServerHelloDone
   Certificate
   ClientKeyExchange
   CertificateVerify
   ChangeCipherSpec
   EncryptedHandshakeMessage
ChangeCipherSpec
EncryptedHandshakeMessage

So AFAICT the client and server appear to have swapped roles!!! The
server is sending Client message and the client is sending server
messages. Not only that but the connection previously established seems
to have been thrown away and they are starting from scratch (i.e.
unencrypted) without having first shutdown the previous connection or
having sent any application data.

The failure case is similar. The client and server apparently
successfully complete a handshake. They then seem to swap roles
(starting from scratch again, without any app data being sent), except
this time we see:

Client Server
== ==

   ClientHello

ServerHello
Certificate
ServerKeyExchange
CertificateRequest
ServerHelloDone
   Alert (Handshake Failure)
   ClientHello
ServerHello
Certificate
ServerKeyExchange
CertificateRequest
ServerHelloDone
   Alert (Decrypt Error)


So here we see the "server", that seems to have forgotten it is the
server and is now acting as the client attempt to initiate a handshake
(forgetting all about the previous connection). It then fails with a
Handshake Failure (I'm not surprised), and apparently decides to have
another go. This time we see a DecryptError which suggests the "server"
(acting as a client) is expecting to receive encrypted data, but the
client (acting as a server) is still sending unencrypted data.

You need to try and figure out why the two ends of the communication are
so confused about what role they are playing (or is there something you
haven't told me about the way your application works?).

Matt



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

[openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q

[Test ssl]

Hi Openssl Team,



We are facing an issue with DTLS failure during the Openssl upgrade from
1.0.1m to 1.0.1q. We have attached the network trace file in attachment
with good (1.0.1m) and fail (1.0.1q) case.

The test scenario is that we are trying to connect a cisco based Endpoint
device to a Video conference server, where our code resides.

Please help us with this DTLS failure scenario which we are not able to
understand that what wrong we did in our application code in using Openssl
APIs.



Regards,


Successtrace.pcap
Description: Binary data


Failure_SSL.pcap
Description: Binary data
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users