[openssl-users] Issue on DTLS over UDP

Wed Jan 10 09:24:44 UTC 2018

Thankyou Matt for the patch.
It works fine now with the patch. In which release will you be including
this patch?

It is a negative scenario setup on configuration.
Thanks,
Grace

On Fri, Jan 5, 2018 at 4:28 PM, Matt Caswell <matt at openssl.org> wrote:

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