Thankyou Matt!
On Thu, Jan 11, 2018 at 1:01 AM, Matt Caswell <matt@xxxxxxxxxxx> 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@xxxxxxxxxxx
> <mailto:matt@xxxxxxxxxxx>> 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@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>
> > <mailto:grace.priscilla@> > <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>> 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@xxxxxxxxx
> <mailto:grace.priscilla@gmail.com > <mailto:grace.priscilla@gmail.com
> <mailto:grace.priscilla@gmail.com >>
> > <mailto:grace.priscilla@gmail.com
> <mailto:grace.priscilla@gmail.com >
gmail.com <mailto:grace.priscilla@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 >>
> >
> >
>
>
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
