Re: Issue on DTLS over UDP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux