[openssl-users] OpenSSL wins the Levchin prize

[Matt Caswell]

Today I have had great pleasure in attending the Real World Crypto 2018
conference in Zürich in order to receive the Levchin prize on behalf of
the OpenSSL team. More details are available in my blog post here:

https://www.openssl.org/blog/blog/2018/01/10/levchin/

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

Re: [openssl-users] Confirmation of what I believe to be true from docs and observation

[Benjamin Kaduk via openssl-users]

On 01/10/2018 02:37 PM, Karl Denninger wrote:
> On 1/10/2018 14:07, Benjamin Kaduk wrote:
>> On 01/10/2018 08:41 AM, Karl Denninger wrote:
>>> We start with a context that I load a dhparam file to (so I can take a
>>> DH connection) along with an edh curve, then set an acceptable cipher
>>> list for it to use.
>>>
>> Why not just use AUTO_DH (the only option for 1.1.0, IIRC)?
> That's a reasonable change (and I'll go ahead and make it); the
> dhparam was only there in the first place for those browsers and such
> that can't negotiate EC (which my cipher selection set prefers.)
>>> Assume I next manually load both the CA store (using
>>> X509_STORE_add_cert as many times as necessary to load the
>>> intermediate components and the root of trust) and then load the
>>> cert/key pair (using SSL_CTX_use_certificate/SSL_CTX_use_PrivateKey)
>>>
>>> I then create some number of SSLs from that context to perform
>>> communication with and all is well.
>>>
>>> Now I want to rekey that context for some reason.  It appears that
>>> while I can add things to
>>>
>> Why do you need to rekey the context as opposed to making a new one?
> I could make a new one (or more-specifically, destroy the existing one
> and re-initialize it), but that is more-complicated as the application
> in question is multi-threaded -- and it's not at all clear from the
> documentation if I destroy a context that has SSLs that have been
> generated from it will cause "bad things" to happen (like a deference
> on a freed object!)
>

Each SSL holds a reference on its parent SSL_CTX (and another reference
on its associated session_ctx, which starts out as the same SSL_CTX
object); SSL_CTX_free() does not do any deallocation until the refcount
drops to zero.

So, no "bad things" will happen if you SSL_CTX_free() the handle you
have in your application while SSL objects are still using that object.

> The reason I may want to rekey is that the cert/key pair used for that
> context may have changed.  The user's certificate may have expired for
> example (or been revoked) and I wish to reload it (and the matching
> key) without having to shut down the software and restart it.
>
>> In general, making configuration changes to an SSL_CTX after it has been
>> used to generate SSL objects is a risky proposition -- the locking model
>> does not really account for doing synchronization properly, and there
>> might be some latent race conditions.  In practice, some operations are
>> currently safe, but there is no authoritative list of which ones, and at
>> least my personal recommendation is to not try to rely on it.
> Assuming that there are SSL objects that are in use and I destroy and
> re-generate the CTX from which it was generated, is *THAT* safe?  Or
> do I need to flag all the in-use descendants and wait for them to be
> closed (or force them closed and release them) before I can safely
> destroy the context? 

You do not need to flag and wait, due to the reference counting on the
SSL and SSL_CTX objects.

>>> the CA chain trying to load the same component that is already in
>>> there returns a failure (somewhat-expected; that is, it does not
>>> overwrite but rather adds, and if you try to add what's already there
>>> you get an error back) and there's no call to CLEAR the certificate
>>> validation chain -- if I want to *replace* the validation chain I have
>>> to destroy the context and initialize a new one from scratch.
>>>
>> N.B. that the X509_STORE_add_cert behavior when presented with a
>> duplicate certificate changed in commit
>> c0452248ea1a59a41023a4765ef7d9825e80a62b (from returning an error to
>> doing nothing and returning success); this will be in 1.1.1.
>>
>> As to the desired behavior, there does not seem to be an API to remove
>> an entry from an X509_STORE.  With the above caveat about thread-safety
>> in mind, couldn't you just make a call to SSL_CTX_set{1}_cert_store() to
>> replace the X509_STORE without tearing down the whole SSL_CTX?
> Yeah, I didn't see one either.  I'm not particularly concerned about
> the verification chain being able to be modified while "in-use"; that
> ought not happen except in an extreme circumstance (e.g. the
> intermediate cert's key is compromised and thus both it and the cert
> have to be regenerated and re-distributed.)  If it DOES happen when
> the end-entity cert and key are reloaded (as they've been signed from
> the new intermediate) they'll fail to validate against the old chain
> and the user will get plenty of notice that there's trouble.
>>> It appears, however, that I *can* load over the top of a certificate
>>> and private key of the same type and that's acceptable.  In other
>>> words, if I have an RSA key/cert pair in the context and I load
>>> another one, the first one is replaced.  This *looks* to be working ok
>>> as far as I can tell and it doesn't appear to leak memory doing that
>>> but it's not explicitly stated that this is considered acceptable
>>> (rather than destroying 

Re: [openssl-users] Confirmation of what I believe to be true from docs and observation

[Karl Denninger]

On 1/10/2018 14:07, Benjamin Kaduk wrote:
> On 01/10/2018 08:41 AM, Karl Denninger wrote:
>> We start with a context that I load a dhparam file to (so I can take a
>> DH connection) along with an edh curve, then set an acceptable cipher
>> list for it to use.
>>
> Why not just use AUTO_DH (the only option for 1.1.0, IIRC)?
That's a reasonable change (and I'll go ahead and make it); the dhparam
was only there in the first place for those browsers and such that can't
negotiate EC (which my cipher selection set prefers.)
>> Assume I next manually load both the CA store (using
>> X509_STORE_add_cert as many times as necessary to load the
>> intermediate components and the root of trust) and then load the
>> cert/key pair (using SSL_CTX_use_certificate/SSL_CTX_use_PrivateKey)
>>
>> I then create some number of SSLs from that context to perform
>> communication with and all is well.
>>
>> Now I want to rekey that context for some reason.  It appears that
>> while I can add things to
>>
> Why do you need to rekey the context as opposed to making a new one?
I could make a new one (or more-specifically, destroy the existing one
and re-initialize it), but that is more-complicated as the application
in question is multi-threaded -- and it's not at all clear from the
documentation if I destroy a context that has SSLs that have been
generated from it will cause "bad things" to happen (like a deference on
a freed object!)

The reason I may want to rekey is that the cert/key pair used for that
context may have changed.  The user's certificate may have expired for
example (or been revoked) and I wish to reload it (and the matching key)
without having to shut down the software and restart it.

> In general, making configuration changes to an SSL_CTX after it has been
> used to generate SSL objects is a risky proposition -- the locking model
> does not really account for doing synchronization properly, and there
> might be some latent race conditions.  In practice, some operations are
> currently safe, but there is no authoritative list of which ones, and at
> least my personal recommendation is to not try to rely on it.
Assuming that there are SSL objects that are in use and I destroy and
re-generate the CTX from which it was generated, is *THAT* safe?  Or do
I need to flag all the in-use descendants and wait for them to be closed
(or force them closed and release them) before I can safely destroy the
context?
>> the CA chain trying to load the same component that is already in
>> there returns a failure (somewhat-expected; that is, it does not
>> overwrite but rather adds, and if you try to add what's already there
>> you get an error back) and there's no call to CLEAR the certificate
>> validation chain -- if I want to *replace* the validation chain I have
>> to destroy the context and initialize a new one from scratch.
>>
> N.B. that the X509_STORE_add_cert behavior when presented with a
> duplicate certificate changed in commit
> c0452248ea1a59a41023a4765ef7d9825e80a62b (from returning an error to
> doing nothing and returning success); this will be in 1.1.1.
>
> As to the desired behavior, there does not seem to be an API to remove
> an entry from an X509_STORE.  With the above caveat about thread-safety
> in mind, couldn't you just make a call to SSL_CTX_set{1}_cert_store() to
> replace the X509_STORE without tearing down the whole SSL_CTX?
Yeah, I didn't see one either.  I'm not particularly concerned about the
verification chain being able to be modified while "in-use"; that ought
not happen except in an extreme circumstance (e.g. the intermediate
cert's key is compromised and thus both it and the cert have to be
regenerated and re-distributed.)  If it DOES happen when the end-entity
cert and key are reloaded (as they've been signed from the new
intermediate) they'll fail to validate against the old chain and the
user will get plenty of notice that there's trouble.
>> It appears, however, that I *can* load over the top of a certificate
>> and private key of the same type and that's acceptable.  In other
>> words, if I have an RSA key/cert pair in the context and I load
>> another one, the first one is replaced.  This *looks* to be working ok
>> as far as I can tell and it doesn't appear to leak memory doing that
>> but it's not explicitly stated that this is considered acceptable
>> (rather than destroying and re-creating the context.)
>>
> The leaf certificate and private key are stored as arrays (for different
> types of certificates) of pointers in the associated CERT structure, and
> the "set" routines do not currently check for and error out if there is
> already one set.
Yes, but do they replace the pointer and, if they do, do they decrement
the reference counter on the existing one before replacing it so it will
get freed?   If yes then all is ok but if not then I need to destroy the
context otherwise I'm going to be leaking memory.
>> Is my understanding correct?
>>
>>
> Mostly ... but I am not sure that 

Re: [openssl-users] Confirmation of what I believe to be true from docs and observation

[Benjamin Kaduk via openssl-users]

On 01/10/2018 08:41 AM, Karl Denninger wrote:
>
> We start with a context that I load a dhparam file to (so I can take a
> DH connection) along with an edh curve, then set an acceptable cipher
> list for it to use.
>

Why not just use AUTO_DH (the only option for 1.1.0, IIRC)?

> Assume I next manually load both the CA store (using
> X509_STORE_add_cert as many times as necessary to load the
> intermediate components and the root of trust) and then load the
> cert/key pair (using SSL_CTX_use_certificate/SSL_CTX_use_PrivateKey)
>
> I then create some number of SSLs from that context to perform
> communication with and all is well.
>
> Now I want to rekey that context for some reason.  It appears that
> while I can add things to
>

Why do you need to rekey the context as opposed to making a new one?

In general, making configuration changes to an SSL_CTX after it has been
used to generate SSL objects is a risky proposition -- the locking model
does not really account for doing synchronization properly, and there
might be some latent race conditions.  In practice, some operations are
currently safe, but there is no authoritative list of which ones, and at
least my personal recommendation is to not try to rely on it.

> the CA chain trying to load the same component that is already in
> there returns a failure (somewhat-expected; that is, it does not
> overwrite but rather adds, and if you try to add what's already there
> you get an error back) and there's no call to CLEAR the certificate
> validation chain -- if I want to *replace* the validation chain I have
> to destroy the context and initialize a new one from scratch.
>

N.B. that the X509_STORE_add_cert behavior when presented with a
duplicate certificate changed in commit
c0452248ea1a59a41023a4765ef7d9825e80a62b (from returning an error to
doing nothing and returning success); this will be in 1.1.1.

As to the desired behavior, there does not seem to be an API to remove
an entry from an X509_STORE.  With the above caveat about thread-safety
in mind, couldn't you just make a call to SSL_CTX_set{1}_cert_store() to
replace the X509_STORE without tearing down the whole SSL_CTX?

> It appears, however, that I *can* load over the top of a certificate
> and private key of the same type and that's acceptable.  In other
> words, if I have an RSA key/cert pair in the context and I load
> another one, the first one is replaced.  This *looks* to be working ok
> as far as I can tell and it doesn't appear to leak memory doing that
> but it's not explicitly stated that this is considered acceptable
> (rather than destroying and re-creating the context.)
>

The leaf certificate and private key are stored as arrays (for different
types of certificates) of pointers in the associated CERT structure, and
the "set" routines do not currently check for and error out if there is
already one set.

> Is my understanding correct?
>
>

Mostly ... but I am not sure that your desired workflow is wise.

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

Re: [openssl-users] Binding the socket to a source IP address before connect

[Sanjaya Joshi]

Hi,
Thanks Michael. I'll check if your proposal fits my requirement.

Regards,
Sanjaya

On Wed, Jan 10, 2018 at 7:55 PM, Michael Richardson 
wrote:

>
> Sanjaya Joshi  wrote:
> > Is there a BIO family of API that OpenSSL provides to bind to a
> > specific source IP address before creating a socket connection (using
> > for e.g. BIO_new_connect()) ?
>
> I think not... BIO_new_connect() allocates the BIO, and so there isn't any
> state to set up before you call that.
>
> I've had to add a place to store the sockaddr to the DGRAM method in order
> to
> make DTLS work the way I want it, and it could be extended to TCP sockets I
> think, but not using the flow that you are using.
>
> However, you can provide the FD to the SSL context using BIO_set_fd()
> and SSL_set_bio():
>
> BIO_set_fd(inbio, connectedfd, BIO_NOCLOSE);
> SSL_set_bio(ssl, inbio, outbio);
>
> Then you can set up the connectedfd any way you want, calling bind() before
> connect.  That means that you might have to parse the host/IP + port
> yourself, but getaddrinfo() can do that for you, and
>   int BIO_lookup(const char *host, const char *service,
>  enum BIO_lookup_type lookup_type,
>  int family, int socktype, BIO_ADDRINFO **res);
>
> wraps it all nicely for you.
>
> > My application does not need to rely on the kernel-provided source IP
> > address and hence the need for this.
>
> Just remember to test with IPv6 Link-Local addresses, because they do
> matter, and they are hard to get right from userspace.
> (And if you aren't doing IPv6 testing, then you probably shouldn't be
> creating new code)
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works| network
> architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Issue on DTLS over UDP

[Matt Caswell]

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  > 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  
> > >> 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.
> >
> >     

Re: [openssl-users] cert chain file ordering question

[Norm Green]

On 1/9/18 19:32, Viktor Dukhovni wrote:

This Key Usage is more appropriate.  When the "Key Usage" is present in
a CA certificate, it*MUST*  include "Certificate Sign".
That was indeed the problem.  Thank you!! It seems strange to me that 
OpenSSL will allow creation of a CA cert (CA:TRUE) that may not be used 
to sign other certs.


I appreciate your help Viktor.

Norm

P.S. Seems you didn't need machine-readable certificates to help me 
after all ;-)
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Confirmation of what I believe to be true from docs and observation

[Karl Denninger]

We start with a context that I load a dhparam file to (so I can take a
DH connection) along with an edh curve, then set an acceptable cipher
list for it to use.

Assume I next manually load both the CA store (using X509_STORE_add_cert
as many times as necessary to load the intermediate components and the
root of trust) and then load the cert/key pair (using
SSL_CTX_use_certificate/SSL_CTX_use_PrivateKey)

I then create some number of SSLs from that context to perform
communication with and all is well.

Now I want to rekey that context for some reason.  It appears that while
I can add things to the CA chain trying to load the same component that
is already in there returns a failure (somewhat-expected; that is, it
does not overwrite but rather adds, and if you try to add what's already
there you get an error back) and there's no call to CLEAR the
certificate validation chain -- if I want to *replace* the validation
chain I have to destroy the context and initialize a new one from scratch.

It appears, however, that I *can* load over the top of a certificate and
private key of the same type and that's acceptable.  In other words, if
I have an RSA key/cert pair in the context and I load another one, the
first one is replaced.  This *looks* to be working ok as far as I can
tell and it doesn't appear to leak memory doing that but it's not
explicitly stated that this is considered acceptable (rather than
destroying and re-creating the context.)

Is my understanding correct?

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Binding the socket to a source IP address before connect

[Michael Richardson]

Sanjaya Joshi  wrote:
> Is there a BIO family of API that OpenSSL provides to bind to a
> specific source IP address before creating a socket connection (using
> for e.g. BIO_new_connect()) ?

I think not... BIO_new_connect() allocates the BIO, and so there isn't any
state to set up before you call that.

I've had to add a place to store the sockaddr to the DGRAM method in order to
make DTLS work the way I want it, and it could be extended to TCP sockets I
think, but not using the flow that you are using.

However, you can provide the FD to the SSL context using BIO_set_fd()
and SSL_set_bio():

BIO_set_fd(inbio, connectedfd, BIO_NOCLOSE);
SSL_set_bio(ssl, inbio, outbio);

Then you can set up the connectedfd any way you want, calling bind() before
connect.  That means that you might have to parse the host/IP + port
yourself, but getaddrinfo() can do that for you, and
  int BIO_lookup(const char *host, const char *service,
 enum BIO_lookup_type lookup_type,
 int family, int socktype, BIO_ADDRINFO **res);

wraps it all nicely for you.

> My application does not need to rely on the kernel-provided source IP
> address and hence the need for this.

Just remember to test with IPv6 Link-Local addresses, because they do
matter, and they are hard to get right from userspace.
(And if you aren't doing IPv6 testing, then you probably shouldn't be
creating new code)

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 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  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  > > 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
> > > 
> >  > >> 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