<div dir="ltr"><div><div><div><span lang="en-US"><font face="Calibri,sans-serif" size="2"><span style="font-size:11pt"><font color="#1F497D">Hi Matt,<br><br>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.<br><br></font></span></font></span></div><span lang="en-US"><font face="Calibri,sans-serif" size="2"><span style="font-size:11pt"><font color="#1F497D">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.<br><br></font></span></font></span></div><span lang="en-US"><font face="Calibri,sans-serif" size="2"><span style="font-size:11pt"><font color="#1F497D">Please help us.<br><br></font></span></font></span></div><span lang="en-US"><font face="Calibri,sans-serif" size="2"><span style="font-size:11pt"><font color="#1F497D">Regards,<br></font></span></font></span><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 17, 2016 at 10:05 PM, Matt Caswell <span dir="ltr"><<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 17/06/16 17:29, Test ssl wrote:<br>
> Hi Matt,<br>
><br>
> With same application code and openssl1.0.1m we are not facing "Alert<br>
> (Handshake Failure)" but in case of 1.0.1q we are facing it.<br>
><br>
> That is what we are not able to understand that what is the reason for<br>
> this "Alert (Handshake Failure)".<br>
><br>
> Please help us on this, which part of functionality we can modify in the<br>
> application code to overcome this DTLS handshake failure.<br>
<br>
</span>Well to have a chance of answering that I need to understand why your<br>
application is behaving in the way I described below. If your<br>
application is doing something weird and unexpected it may well be that<br>
it just happened to work by accident in 1.0.1m, but something under the<br>
hood changed, and it doesn't any more.<br>
<br>
Why do we see this strange double handshake in your application where<br>
the client/server apparently switch roles? Is there something about your<br>
application design that could explain it? Is it intentional?<br>
<span class="HOEnZb"><font color="#888888"><br>
Matt<br>
</font></span><span class="im HOEnZb"><br>
<br>
><br>
> Regards,<br>
><br>
> On Fri, Jun 17, 2016 at 5:55 PM, Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</a><br>
</span><div class="HOEnZb"><div class="h5">> <mailto:<a href="mailto:matt@openssl.org">matt@openssl.org</a>>> wrote:<br>
><br>
>     Hello<br>
><br>
>     On 17/06/16 12:04, Test ssl wrote:<br>
>     > We are facing an issue with DTLS failure during the Openssl upgrade from<br>
>     > 1.0.1m to 1.0.1q. We have attached the network trace file in attachment<br>
>     > with good (1.0.1m) and fail (1.0.1q) case.<br>
>     ><br>
>     > The test scenario is that we are trying to connect a cisco based<br>
>     > Endpoint device to a Video conference server, where our code resides.<br>
>     ><br>
>     > Please help us with this DTLS failure scenario which we are not able to<br>
>     > understand that what wrong we did in our application code in using<br>
>     > Openssl APIs.<br>
><br>
>     This looks like quite a strange trace in both the success and<br>
>     failure cases.<br>
><br>
>     The traces are slightly confusing because it looks like you are making<br>
>     multiple connections from different ports. To simplify things in the<br>
>     success case I filtered wireshark to only show me the port 22602 <-><br>
>     port 49164 communication.<br>
><br>
>     This showed me the following interaction<br>
><br>
><br>
>     Client                     Server<br>
>     ======                     ======<br>
><br>
>     ClientHello<br>
>                                ServerHello<br>
>                                Certificate<br>
>                                ServerHelloDone<br>
>     ClientKeyExchange<br>
>     ChangeCipherSpec<br>
>     EncryptedHandshakeMessage<br>
>                                ChangeCipherSpec<br>
>                                EncryptedHandshakeMessage<br>
><br>
>     So far so good. This looks like a normal successful handshake. The<br>
>     EncryptedHandshakeMessages at the end of these exchanges are the<br>
>     Finished messages indicating that the handshake was successful. I would<br>
>     then expect to see Application Data being exchanged. Instead I see this:<br>
><br>
>     Client                     Server<br>
>     ======                     ======<br>
><br>
>                                ClientHello<br>
>     ServerHello<br>
>     Certificate<br>
>     ServerKeyExchange<br>
>     CertificateRequest<br>
>     ServerHelloDone<br>
>                                Certificate<br>
>                                ClientKeyExchange<br>
>                                CertificateVerify<br>
>                                ChangeCipherSpec<br>
>                                EncryptedHandshakeMessage<br>
>     ChangeCipherSpec<br>
>     EncryptedHandshakeMessage<br>
><br>
>     So AFAICT the client and server appear to have swapped roles!!! The<br>
>     server is sending Client message and the client is sending server<br>
>     messages. Not only that but the connection previously established seems<br>
>     to have been thrown away and they are starting from scratch (i.e.<br>
>     unencrypted) without having first shutdown the previous connection or<br>
>     having sent any application data.<br>
><br>
>     The failure case is similar. The client and server apparently<br>
>     successfully complete a handshake. They then seem to swap roles<br>
>     (starting from scratch again, without any app data being sent), except<br>
>     this time we see:<br>
><br>
>     Client                     Server<br>
>     ======                     ======<br>
><br>
>                                ClientHello<br>
><br>
>     ServerHello<br>
>     Certificate<br>
>     ServerKeyExchange<br>
>     CertificateRequest<br>
>     ServerHelloDone<br>
>                                Alert (Handshake Failure)<br>
>                                ClientHello<br>
>     ServerHello<br>
>     Certificate<br>
>     ServerKeyExchange<br>
>     CertificateRequest<br>
>     ServerHelloDone<br>
>                                Alert (Decrypt Error)<br>
><br>
><br>
>     So here we see the "server", that seems to have forgotten it is the<br>
>     server and is now acting as the client attempt to initiate a handshake<br>
>     (forgetting all about the previous connection). It then fails with a<br>
>     Handshake Failure (I'm not surprised), and apparently decides to have<br>
>     another go. This time we see a DecryptError which suggests the "server"<br>
>     (acting as a client) is expecting to receive encrypted data, but the<br>
>     client (acting as a server) is still sending unencrypted data.<br>
><br>
>     You need to try and figure out why the two ends of the communication are<br>
>     so confused about what role they are playing (or is there something you<br>
>     haven't told me about the way your application works?).<br>
><br>
>     Matt<br>
><br>
><br>
><br>
>     --<br>
>     openssl-users mailing list<br>
>     To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
><br>
><br>
><br>
><br>
--<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
</div></div></blockquote></div><br></div></div></div></div></div></div></div>