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