[openssl-users] Fwd: issue with dtls failure during openssl upgrade from 1.0.1m to q
Matt Caswell
matt at openssl.org
Sun Jun 19 14:12:38 UTC 2016
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 <matt at openssl.org
> <mailto: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>
> > <mailto: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
>
>
>
>
More information about the openssl-users
mailing list