Issue on DTLS over UDP

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue on DTLS over UDP

Grace Priscilla Jero
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
Reply | Threaded
Open this post in threaded view
|

Re: Issue on DTLS over UDP

Grace Priscilla Jero
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.

Thanks,
Grace

On Fri, Dec 15, 2017 at 3:23 PM, Grace Priscilla Jero <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Issue on DTLS over UDP

Matt Caswell-2


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
> <[hidden email] <mailto:[hidden email]>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Issue on DTLS over UDP

Matt Caswell-2


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

And the 1.0.2 version is here:

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 <[hidden email]
> <mailto:[hidden email]>> 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
>     > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>> 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>
>
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

tolerate-dtls-alerts.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue on DTLS over UDP

Grace Priscilla Jero
Thankyou Matt for the patch.
It works fine now with the patch. In which release will you be including this patch?

It is a negative scenario setup on configuration.
Thanks,
Grace


On Fri, Jan 5, 2018 at 4:28 PM, Matt Caswell <[hidden email]> 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

And the 1.0.2 version is here:

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 <[hidden email]
> <mailto:[hidden email]>> 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
>     > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>> 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>
>
>


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Issue on DTLS over UDP

Matt Caswell-2


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 <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >     > <[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >     <mailto:[hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email] <mailto:[hidden email]>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Issue on DTLS over UDP

Grace Priscilla Jero
Thankyou Matt!

On Thu, Jan 11, 2018 at 1:01 AM, Matt Caswell <[hidden email]> 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 <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >     > <[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >     <mailto:[hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email] <mailto:[hidden email]>>>> 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