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: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@xxxxxxxxx> <mailto:grace.priscilla@xxxxxxxxx > <mailto:grace.priscilla@xxxxxxxxx>> > > <mailto:grace.priscilla@xxxxxxxxx > <mailto:grace.priscilla@xxxxxxxxx> > > <mailto:grace.priscilla@xxxxxxxxx <mailto:grace.priscilla@xxxxxxxxx>>>> 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
