<div dir="ltr">Thankyou Matt for the patch.<div>It works fine now with the patch. In which release will you be including this patch?</div><div><br></div><div>It is a negative scenario setup on configuration.</div><div>Thanks,</div><div>Grace</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 5, 2018 at 4:28 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 05/01/18 05:30, Grace Priscilla Jero wrote:<br>
> Hi Matt,<br>
> We are using openssl v 1.1.0g.<br>
> Attaching the pcap files.<br>
<br>
</span>Thanks - that helped a lot and I have been able to recreate your issue.<br>
<br>
The problem is this:<br>
<br>
- The server is DTLSv1.0 only<br>
- The client is DTLSv1.2 only<br>
- When the server selects DTLSv1.0 the client sends back a protocol<br>
version alert with a record version of DTLSv1.2<br>
- The server is expecting incoming records of version DTLSv1.0, because<br>
that is the version it selected. Anything else is silently discarded,<br>
including the incoming protocol version alert.<br>
<br>
Whether this behaviour is a "bug" or not is debatable. The spec is quite<br>
unclear in this regards. The only thing relevant I can see is this:<br>
<br>
"Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,<br>
invalid formatting, length, MAC, etc.).  In general, invalid records<br>
SHOULD be silently discarded, thus preserving the association; ..."<br>
<br>
An OpenSSL client (at least in 1.1.0 - I didn't check other versions),<br>
will respond with a DTLSv1.0 alert record if it doesn't like the<br>
protocol version selected by the server, so this situation never arises<br>
when an OpenSSL client is talking to an OpenSSL server.<br>
<br>
Probably the right thing for us to do is be more tolerant of record<br>
version number mismatches when the record type is alert. I have created<br>
a patch to do that here (master and 1.1.0):<br>
<br>
<a href="https://github.com/openssl/openssl/pull/5018" rel="noreferrer" target="_blank">https://github.com/openssl/<wbr>openssl/pull/5018</a><br>
<br>
And the 1.0.2 version is here:<br>
<br>
<a href="https://github.com/openssl/openssl/pull/5019" rel="noreferrer" target="_blank">https://github.com/openssl/<wbr>openssl/pull/5019</a><br>
<br>
I've also attached a patch file suitable for applying to 1.1.0g.<br>
<br>
This issue triggers a few other thoughts for your case:<br>
<br>
- I am wondering why you have configured your server for DTLSv1.0 only<br>
given that 1.1.0g is perfectly capable of talking both DTLSv1.2 and DTSLv1.0<br>
<br>
- Your server application should probably be modified to ensure it is<br>
capable of handling a stalled connection like this (e.g. by timing out<br>
after a period if a connection is not achieved). Such stalled<br>
connections can happen in DTLS due to packet loss. For example the<br>
protocol version alert could be dropped at a network level. Alerts are<br>
never retransmitted, so the server will wait for ever waiting for the<br>
next message.<br>
<br>
- Do you control the client in this case? I wonder why the client is<br>
configured for DTLSv1.2 only (rather than being able to handle both<br>
DTLSv1.2 *and* DTLSv1.0). Is this a deliberate choice or a<br>
mis-configuration?<br>
<br>
<br>
Matt<br>
<span class=""><br>
><br>
> yes, the SSL_get_error() gives 2.<br>
> The alert is sent but ignored.<br>
><br>
> Thanks,<br>
> Grace<br>
><br>
> On Wed, Jan 3, 2018 at 4:23 PM, Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:matt@openssl.org">matt@openssl.org</a>>> wrote:<br>
><br>
><br>
><br>
>     On 03/01/18 10:40, Grace Priscilla Jero wrote:<br>
>     > Hi,<br>
>     > Can someone please respond to the below mail as we want to confirm if it<br>
>     > is an issue with our application or a bug in openSSL.<br>
><br>
>     It isn't a known bug (which doesn't mean it isn't an unknown bug!).<br>
><br>
>     I think we're going to need some more information to help you with this<br>
>     issue. If I understand you correctly you have a server application which<br>
>     only supports DTLS 1.0 and it is that application which is failing?<br>
>     Which version of OpenSSL is this? All currently supported versions of<br>
>     OpenSSL have the capability to support DTLS1.2 so I'm not sure why you<br>
>     have this scenario.<br>
><br>
>     You say that "SSL_accept continuously loops with error 2". Do you mean<br>
>     by that SSL_accept() returns an error and calling SSL_get_error() gives<br>
>     you SSL_ERROR_WANT_READ (value 2)?<br>
><br>
>     "The ALERT is not processed": does this mean you are expecting to see an<br>
>     alert but it isn't sent? Or an alert is sent but it is ignored?<br>
><br>
>     Perhaps a wireshark trace of the exchange would help us to understand<br>
>     what you are seeing.<br>
><br>
>     Matt<br>
><br>
><br>
>     ><br>
>     > Thanks,<br>
>     > Grace<br>
>     ><br>
>     > On Fri, Dec 15, 2017 at 3:23 PM, Grace Priscilla Jero<br>
>     > <<a href="mailto:grace.priscilla@gmail.com">grace.priscilla@gmail.com</a> <mailto:<a href="mailto:grace.priscilla@gmail.com">grace.priscilla@gmail.<wbr>com</a>><br>
</div></div>>     <mailto:<a href="mailto:grace.priscilla@gmail.com">grace.priscilla@gmail.<wbr>com</a><br>
<span class="">>     <mailto:<a href="mailto:grace.priscilla@gmail.com">grace.priscilla@gmail.<wbr>com</a>>>> wrote:<br>
>     ><br>
>     >     Hi All,<br>
>     ><br>
>     >     We are having an issue with DTLS on UDP.<br>
>     ><br>
>     >     The scenario is that, when a client of DTLS version 1.2 is<br>
>     trying to<br>
>     >     connect to a server which is at version DTLS 1.0 the SSL_accept<br>
>     >     continuously loops with error 2. The ALERT is not processed. <br>
>     >     Is this a known bug?<br>
>     ><br>
>     >     Because of the loop, the application is unable to process new<br>
>     changes. <br>
>     ><br>
>     >     Thanks,<br>
>     >     Grace<br>
>     ><br>
>     ><br>
>     ><br>
>     ><br>
>     --<br>
>     openssl-users mailing list<br>
>     To unsubscribe:<br>
>     <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-users</a><br>
</span>>     <<a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-users</a><wbr>><br>
><br>
><br>
</blockquote></div><br></div></div>