[openssl-users] Issue on DTLS over UDP
Grace Priscilla Jero
grace.priscilla at gmail.com
Thu Jan 11 09:18:41 UTC 2018
Thankyou Matt!
On Thu, Jan 11, 2018 at 1:01 AM, Matt Caswell <matt at openssl.org> wrote:
>
>
> On 10/01/18 09:24, Grace Priscilla Jero wrote:
> > Thankyou Matt for the patch.
> > It works fine now with the patch. In which release will you be including
> > this patch?
>
> The patch is already merged into the 1.1.0 branch so it will be in the
> next release (1.1.0h).
>
> Matt
>
>
> >
> > 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
> > <mailto: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
> > <https://github.com/openssl/openssl/pull/5018>
> >
> > And the 1.0.2 version is here:
> >
> > https://github.com/openssl/openssl/pull/5019
> > <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>
> > > <mailto: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>>
> > > <mailto: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>
> > > <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/20180111/61e10845/attachment-0001.html>
More information about the openssl-users
mailing list