Thankyou Matt! On Thu, Jan 11, 2018 at 1:01 AM, Matt Caswell <m...@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 <m...@openssl.org > > <mailto:m...@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 <m...@openssl.org > <mailto:m...@openssl.org> > > > <mailto:m...@openssl.org <mailto:m...@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.prisci...@gmail.com > > <mailto:grace.prisci...@gmail.com> <mailto:grace.prisci...@gmail.com > > <mailto:grace.prisci...@gmail.com>> > > > <mailto:grace.prisci...@gmail.com > > <mailto:grace.prisci...@gmail.com> > > > <mailto:grace.prisci...@gmail.com <mailto: > grace.prisci...@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
