[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 <matt at openssl.org> 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 <matt at openssl.org
> > <mailto:matt at openssl.org>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160619/88cb9fa9/attachment-0001.html>