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 <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>>> 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>
>
>
From 5da19cd71eeee4515af729b546d705ab8a87abcc Mon Sep 17 00:00:00 2001
From: Matt Caswell <matt@xxxxxxxxxxx>
Date: Fri, 5 Jan 2018 10:12:29 +0000
Subject: [PATCH] Tolerate DTLS alerts with an incorrect version number
In the case of a protocol version alert being sent by a peer the record
version number may not be what we are expecting. In DTLS records with an
unexpected version number are silently discarded. This probably isn't
appropriate for alerts, so we tolerate a mismatch in the minor version
number.
This resolves an issue reported on openssl-users where an OpenSSL server
chose DTLS1.0 but the client was DTLS1.2 only and sent a protocol_version
alert with a 1.2 record number. This was silently ignored by the server.
---
ssl/record/ssl3_record.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/ssl/record/ssl3_record.c b/ssl/record/ssl3_record.c
index a189092254..6c74ea5689 100644
--- a/ssl/record/ssl3_record.c
+++ b/ssl/record/ssl3_record.c
@@ -1530,8 +1530,11 @@ int dtls1_get_record(SSL *s)
n2s(p, rr->length);
- /* Lets check version */
- if (!s->first_packet) {
+ /*
+ * Lets check the version. We tolerate alerts that don't have the exact
+ * version number (e.g. because of protocol version errors)
+ */
+ if (!s->first_packet && rr->type != SSL3_RT_ALERT) {
if (version != s->version) {
/* unexpected version, silently discard */
rr->length = 0;
--
2.14.1
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
