Re: [openssl-users] Latest stable FIPS and SSL Library combo?

[Porter, Andrew]

Yes, 2.0.16 and 1.0.2l as per https://www.openssl.org/source/

But there will be a 1.0.2m out on Thursday.

Andrew

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Karyn Ulriksen
Sent: Tuesday, October 31, 2017 14:51
To: openssl-users@openssl.org
Subject: [openssl-users] Latest stable FIPS and SSL Library combo?

What is the recommended versions for the latest FIPS module (2.0.16 ?)  and SSL 
libraries  (1.0.2l ?)  There was not a clear answer.  I dug around and came up 
with the ones I mentioned, but need a sanity check.

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

[openssl-users] Latest stable FIPS and SSL Library combo?

[Karyn Ulriksen]

What is the recommended versions for the latest FIPS module (2.0.16 ?)  and SSL 
libraries  (1.0.2l ?)  There was not a clear answer.  I dug around and came up 
with the ones I mentioned, but need a sanity check.

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Benjamin Kaduk via openssl-users]

On 10/31/2017 01:05 PM, Dave Coombs wrote:
>>> If I pass in a STACK_OF(X509) *certs with only the signer's cert in it, and 
>>> NULL for X509_STORE *st since it won't be used, then I think I should get 
>>> the desired result, yes, at the cost of ocsp_find_signer(single-entry 
>>> certs) and the internal creation/destruction of an unused X509_STORE_CTX.  
>>> I'd have a small performance hit but it probably wouldn't be too bad.
>> Probably the construction of that ctx is in the wrong place. It should
>> be later in the function. I can't imagine the ocsp_find_signer() hit is
>> too great.
> Having tried this, I now see that my copying the structs from ocsp_lcl.h into 
> the external code masked the fact that the external code is getting the 
> signer's cert beforehand by directly accessing OCSP_BASICRESP->certs (and 
> ->tbsResponseData) anyway, effectively doing what ocsp_find_signer() does.  
> So it is clear that I will need to be rework this, potentially centred around 
> OCSP_basic_verify(), while remaining ignorant of the signer cert.
>
> It would be nice, though, if the API provided a way to get the signer's 
> certificate.  There is OCSP_resp_get0_signature(), but that only returns the 
> bit string.  Comparable functions in other modules (eg: 
> X509_get0_signature(), X509_REQ_get0_signature(), X509_CRL_get0_signature(), 
> CMS_SignerInfo_get0_algs()) provide a way to get any combination of bit 
> string, algorithm, and signer cert.
>

Kind of like https://github.com/openssl/openssl/pull/4573 ?

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Dave Coombs]

>> If I pass in a STACK_OF(X509) *certs with only the signer's cert in it, and 
>> NULL for X509_STORE *st since it won't be used, then I think I should get 
>> the desired result, yes, at the cost of ocsp_find_signer(single-entry certs) 
>> and the internal creation/destruction of an unused X509_STORE_CTX.  I'd have 
>> a small performance hit but it probably wouldn't be too bad.
> 
> Probably the construction of that ctx is in the wrong place. It should
> be later in the function. I can't imagine the ocsp_find_signer() hit is
> too great.

Having tried this, I now see that my copying the structs from ocsp_lcl.h into 
the external code masked the fact that the external code is getting the 
signer's cert beforehand by directly accessing OCSP_BASICRESP->certs (and 
->tbsResponseData) anyway, effectively doing what ocsp_find_signer() does.  So 
it is clear that I will need to be rework this, potentially centred around 
OCSP_basic_verify(), while remaining ignorant of the signer cert.

It would be nice, though, if the API provided a way to get the signer's 
certificate.  There is OCSP_resp_get0_signature(), but that only returns the 
bit string.  Comparable functions in other modules (eg: X509_get0_signature(), 
X509_REQ_get0_signature(), X509_CRL_get0_signature(), 
CMS_SignerInfo_get0_algs()) provide a way to get any combination of bit string, 
algorithm, and signer cert.

Cheers,
  -Dave

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Matt Caswell]

On 31/10/17 17:30, Dave Coombs wrote:
> Hi Matt, thanks for your response.
> 
>>> Is the correct solution to use OCSP_basic_verify(), which feels like
>>> overkill for my needs (the code in question is *part of* our own
>>> path-validation routine), or might there be some other way?
>>
>> Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final
>> "flags" argument? This basically finds the signer certificate and
>> verifies the signature using OCSP_BASICRESP_verify(), but skips all the
>> chain validation bit.
> 
> If I pass in a STACK_OF(X509) *certs with only the signer's cert in it, and 
> NULL for X509_STORE *st since it won't be used, then I think I should get the 
> desired result, yes, at the cost of ocsp_find_signer(single-entry certs) and 
> the internal creation/destruction of an unused X509_STORE_CTX.  I'd have a 
> small performance hit but it probably wouldn't be too bad.

Probably the construction of that ctx is in the wrong place. It should
be later in the function. I can't imagine the ocsp_find_signer() hit is
too great.

> 
> The alternative would be to change the OCSP_BASICRESP_verify() macro into an 
> externally available function, and then both it and OCSP_basic_verify() could 
> call the former macro, suitably renamed and internally scoped.  Clearly I'd 
> be happy with that, though I understand if you don't want to go that route.

I did consider it, but I'm not especially keen. I think the intended
application interface here is to use OCSP_basic_verify().
OCSP_BASICRESP_verify() should probably have never been exposed in the
first place.

Matt

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Dave Coombs]

Hi Matt, thanks for your response.

>> Is the correct solution to use OCSP_basic_verify(), which feels like
>> overkill for my needs (the code in question is *part of* our own
>> path-validation routine), or might there be some other way?
> 
> Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final
> "flags" argument? This basically finds the signer certificate and
> verifies the signature using OCSP_BASICRESP_verify(), but skips all the
> chain validation bit.

If I pass in a STACK_OF(X509) *certs with only the signer's cert in it, and 
NULL for X509_STORE *st since it won't be used, then I think I should get the 
desired result, yes, at the cost of ocsp_find_signer(single-entry certs) and 
the internal creation/destruction of an unused X509_STORE_CTX.  I'd have a 
small performance hit but it probably wouldn't be too bad.

The alternative would be to change the OCSP_BASICRESP_verify() macro into an 
externally available function, and then both it and OCSP_basic_verify() could 
call the former macro, suitably renamed and internally scoped.  Clearly I'd be 
happy with that, though I understand if you don't want to go that route.

Cheers,
  -Dave

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

Re: [openssl-users] DTLS UDP issue

[Matt Caswell]

On 31/10/17 16:58, Grace Priscilla Jero wrote:
> Hi Matt,
> 
> Please find attached the pcap which contains only the "Hello Client".

Thanks. Switching back to openssl-users.

> Search with ip.src==22.33.40.11
> 
> SSL_accept fails with -1 and get error gives the number as 2.

Error 2 is SSL_ERROR_WANT_READ which is normal. It just means it wants
to read data but hasn't got enough yet (probably because the data has
not arrived yet). You need to loop and retry SSL_accept() - are you
doing that?


> 
> Below is the sequence for accept:
> 
> Socket creation
> Make it non-blocking

How are you creating the socket?

> BIO_new_dgram
> SSL_new
> SSL_set_bio
> BIO_set_fd

Why are you calling BIO_set_fd() here? Has the fd changed from when you
called BIO_new_dgram()?

> SSL_set_accept_state
> SSL_set_fd

This replaces the BIO you created earlier with a new standard socket BIO
(i.e. not dgram) based on the supplied fd. That is not going to work.
Remove this call.

Matt


> SSL_accept
> 
> Thanks,
> Grace
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Matt Caswell]

On 31/10/17 16:42, Wouter Verhelst wrote:
> On 31-10-17 17:26, Matt Caswell wrote:
>> I agree its not a great name for it. Unfortunately we are stuck with it
>> for compatibility reasons. If we renamed it we would break any code that
>> is currently using it. We could introduce a new flag with a different
>> name which does the same thing - but I'm not sure that does anything to
>> make things less confusing.
> 
> You could always keep the old name around and mark it deprecated. GCC
> even has a pragma for that -- __attribute__((deprecated)) -- although I
> doubt it works on macros (haven't tested that).
> 
> I suppose it might be too much of an effort for too little gain, though.
> 

As a matter of policy we won't deprecate anything more until we do a
1.2.0 release.

If someone wants to create a PR for a new name for this (defining the
old one to point at the new one), then I'd review it. But if we're going
to go to that effort then we should write the documentation as part of
the PR (there seems little sense to me in replacing an undocumented name
which you have to read the source to understand with another
undocumented name that you also have to read the source to understand).

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Wouter Verhelst]

On 31-10-17 17:26, Matt Caswell wrote:
> I agree its not a great name for it. Unfortunately we are stuck with it
> for compatibility reasons. If we renamed it we would break any code that
> is currently using it. We could introduce a new flag with a different
> name which does the same thing - but I'm not sure that does anything to
> make things less confusing.

You could always keep the old name around and mark it deprecated. GCC
even has a pragma for that -- __attribute__((deprecated)) -- although I
doubt it works on macros (haven't tested that).

I suppose it might be too much of an effort for too little gain, though.

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Jakob Bohm]

On 31/10/2017 17:26, Matt Caswell wrote:


On 31/10/17 16:02, Wouter Verhelst wrote:

Hi Matt,

On 31-10-17 16:36, Matt Caswell wrote:

Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final
"flags" argument? This basically finds the signer certificate and
verifies the signature using OCSP_BASICRESP_verify(), but skips all the
chain validation bit.

Just wanted to point out that that is, actually, a confusing name for
that flag.

"NOVERIFY" seems to imply that there is no verification being done, at
all. Intuitively one senses that's not right, and that at least some
verification will be done (in casu the signature will still be checked);
but figuring out which part of the verification is being dropped and
which part isn't requires one to read either the library source or the
documentation, both of which are annoying if they can be avoided and do
not help for the readability of code that uses the flag in question.

Might I suggest that this flag be renamed somehow, to something that
makes it more clear what exactly it does?


I agree its not a great name for it. Unfortunately we are stuck with it
for compatibility reasons. If we renamed it we would break any code that
is currently using it. We could introduce a new flag with a different
name which does the same thing - but I'm not sure that does anything to
make things less confusing.

The best way forward is to document it. It isn't documented at all at
the moment along with a number of other OCSP related functions and
features. PRs welcome for that.

Matt

You could introduce the new name, but define the old name to it, and
document that the flag is alsoavailable under the other name for
backwards compatibility.  Then code that doesn't need compatibility with
1.1.0 or older can just use the new name.

As for the macro that doesn't work, wouldn't it be better to make it
a function (or a wrapper around the call with the badly named flag).
One could just as easily argue that the API was accidentally broken,
not accidentally kept.  After all, the references to internal structures
is internal to the inline implementation, not part of the interface.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Matt Caswell]

On 31/10/17 16:02, Wouter Verhelst wrote:
> Hi Matt,
> 
> On 31-10-17 16:36, Matt Caswell wrote:
>> Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final
>> "flags" argument? This basically finds the signer certificate and
>> verifies the signature using OCSP_BASICRESP_verify(), but skips all the
>> chain validation bit.
> Just wanted to point out that that is, actually, a confusing name for
> that flag.
> 
> "NOVERIFY" seems to imply that there is no verification being done, at
> all. Intuitively one senses that's not right, and that at least some
> verification will be done (in casu the signature will still be checked);
> but figuring out which part of the verification is being dropped and
> which part isn't requires one to read either the library source or the
> documentation, both of which are annoying if they can be avoided and do
> not help for the readability of code that uses the flag in question.
> 
> Might I suggest that this flag be renamed somehow, to something that
> makes it more clear what exactly it does?
> 

I agree its not a great name for it. Unfortunately we are stuck with it
for compatibility reasons. If we renamed it we would break any code that
is currently using it. We could introduce a new flag with a different
name which does the same thing - but I'm not sure that does anything to
make things less confusing.

The best way forward is to document it. It isn't documented at all at
the moment along with a number of other OCSP related functions and
features. PRs welcome for that.

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Wouter Verhelst]

Hi Matt,

On 31-10-17 16:36, Matt Caswell wrote:
> Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final
> "flags" argument? This basically finds the signer certificate and
> verifies the signature using OCSP_BASICRESP_verify(), but skips all the
> chain validation bit.
Just wanted to point out that that is, actually, a confusing name for
that flag.

"NOVERIFY" seems to imply that there is no verification being done, at
all. Intuitively one senses that's not right, and that at least some
verification will be done (in casu the signature will still be checked);
but figuring out which part of the verification is being dropped and
which part isn't requires one to read either the library source or the
documentation, both of which are annoying if they can be avoided and do
not help for the readability of code that uses the flag in question.

Might I suggest that this flag be renamed somehow, to something that
makes it more clear what exactly it does?

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Benjamin Kaduk via openssl-users]

On 10/31/2017 10:36 AM, Matt Caswell wrote:
>
> On 31/10/17 13:06, Dave Coombs wrote:
>
>> Either way, I hereby report you've got a few macros in a public
>> header that can't possibly work as things stand. :-)
> Yes - a bug. I'm tempted just to remove them.
>

That seems like the best course of action.  It's not like we're actually
removing them from the public API, since they never worked at all (on
this branch).  They were actually "removed"/desupported in the 1.1.0
release, we just didn't realize it at the time.

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Matt Caswell]

On 31/10/17 13:06, Dave Coombs wrote:
> Hello,
> 
> I was fiddling around with OpenSSL 1.1.0 this past weekend, because
> One Day We'll Need To Upgrade (tm), and ran into the following.
> 
> We have some code that uses OCSP_BASICRESP_verify() with 1.0.1 /
> 1.0.2 to confirm that the signature on an ocsp response is correct.
> This is a macro in ocsp.h, which directly accesses the signature,
> signatureAlgorithm, and tbsResponseData members of the OCSP_BASICRESP
> structure.  In 1.1.0, this structure is now opaque, but the macros
> are still present in the public ocsp.h, so any external code that
> uses this macro can't compile.
> 
> I can get around this by copying the struct definitions from
> ocsp_lcl.h into the external code, but that both defeats the purpose
> of opaque structures and will cause me problems if the structure
> contents ever change.
> 
> Is the correct solution to use OCSP_basic_verify(), which feels like
> overkill for my needs (the code in question is *part of* our own
> path-validation routine), or might there be some other way?

Can you use OCSP_basic_verify() passing in OCSP_NOVERIFY in the final
"flags" argument? This basically finds the signer certificate and
verifies the signature using OCSP_BASICRESP_verify(), but skips all the
chain validation bit.

> Either way, I hereby report you've got a few macros in a public
> header that can't possibly work as things stand. :-)

Yes - a bug. I'm tempted just to remove them.

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

Re: [openssl-users] Issue with DTLS for UDP

[Matt Caswell]

I did not get the pcap file? Perhaps it got blocked due to message size.
Try sending it direct to me.

Matt

On 31/10/17 13:26, Grace Priscilla Jero wrote:
> Matt,
> Here is more info on the process backtrace where it is stuck.
> 
> cat /proc/15602/stack
> [] inet_csk_accept+0xc1/0x1f0
> [] inet_accept+0x28/0xf5
> [] sys_accept4+0x11b/0x1b8
> [] sys_accept+0xb/0xd
> [] system_call_fastpath+0x16/0x1b
> [] 0x
> 
> Thanks,
> Grace
> 
> On Tue, Oct 31, 2017 at 4:22 PM, Grace Priscilla Jero
> > wrote:
> 
> Please find attached the pcap. It only has Client Hello.
> While debugging SSL_accept, I see it stuck in s->method->ssl_read_bytes
> 
> Thanks,
> Grace
> 
> 
> On Tue, Oct 31, 2017 at 4:16 PM, Matt Caswell  > wrote:
> 
> 
> 
> On 31/10/17 10:40, Grace Priscilla Jero wrote:
> > Hi Matt,
> > yes, we have found that later and have add the call backs. But we 
> never
> > get the Client Hello with cookie. The Hello verify request is sent 
> from
> > the server.
> >
> > Thanks for pointing out that listen was for cookies. Now without 
> that
> > providing the SSL_accept, it hangs. We are unable to figure out why 
> it
> > hangs. Only client hello is sent. Is there any way to spot what is 
> going
> > wrong.
> 
> I suggest you use Wireshark to take a look what is happening on
> the wire.
> 
> Matt
> 
> 
> >
> > Thanks,
> > Grace
> >
> > On Tue, Oct 31, 2017 at 3:50 PM, Matt Caswell  
> > >> wrote:
> >
> >
> >
> >     On 31/10/17 06:06, Grace Priscilla Jero wrote:
> >     > Thankyou for the suggestions. After correcting few options the
> >     > "ClientHello" goes successfully but we have failure in 
> "DTLSv1_listen".
> >     > There are'nt any cookies in the Client Hello request.
> >     > But DTLSv1_listen return error and the failure in see is in
> >     > "SSLerr(SSL_F_DTLSV1_LISTEN, 
> SSL_R_COOKIE_GEN_CALLBACK_FAILURE);"
> >
> >     This is most likely because you haven't called
> >     SSL_CTX_set_cookie_generate_cb() first.
> >
> >     > We are using 1.1.0f version. Is there a way we can disable 
> cookies?
> >
> >     Well the whole *point* of calling DTLSv1_listen() is to 
> generate those
> >     cookies. If you don't want cookies, don't call it.
> >
> >     Matt
> >
> >     >
> >     > Thanks,
> >     > Grace
> >     >
> >     > On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero
> >     > 
>  >
> >      
> >       wrote:
> >     >
> >     >     Hi Matt,
> >     >
> >     >     SSL_get_error()  returns 5. 
> >     >     It is the same socket using which the UDP connection is 
> established.
> >     >     Could you suggest some logging that can be done for 
> OPENSSL.
> >     >
> >     >     Thanks,
> >     >     Grace
> >     >
> >     >
> >     >     On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell 
> 
> >
> >     >     
>  >     >
> >     >
> >     >
> >     >         On 26/10/17 16:43, Grace Priscilla Jero wrote:
> >     >         > Thankyou for the responses.
> >     >         > We figured the issue. But now we are getting
> error -5
> >     from "SSL_connect"
> >     >         > and the errno is set to 22 which means invalid
> argument.
> >     >         > Is there a easy way to debug or get logs for
> SSL_connect.
> >     >         >
> >     >         > Below is the sequence for the dtls udp connect
> that we
> >     are trying.
> >     >         > ssl = SSL_new(ctx)
> >     >         > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE)
> >     >         > SSL_set_bio(ssl, bio, bio);
> >     >         > VI_res = SSL_connect(ssl)
> >     >
> >     >         Do you really mean SSL_connect() returns -5? Or
>

Re: [openssl-users] Issue with DTLS for UDP

[Grace Priscilla Jero]

Matt,
If you have any way to enable some kind of logging it will be useful to
find what is the issue.
Why do we get error 2 for ssl_accept. We have seen this for connect but not
sure why we get it for accept.

Thanks,
Grace

On 31-Oct-2017 6:56 PM, "Grace Priscilla Jero" 
wrote:

> Matt,
> Here is more info on the process backtrace where it is stuck.
>
> cat /proc/15602/stack
> [] inet_csk_accept+0xc1/0x1f0
> [] inet_accept+0x28/0xf5
> [] sys_accept4+0x11b/0x1b8
> [] sys_accept+0xb/0xd
> [] system_call_fastpath+0x16/0x1b
> [] 0x
>
> Thanks,
> Grace
>
> On Tue, Oct 31, 2017 at 4:22 PM, Grace Priscilla Jero <
> grace.prisci...@gmail.com> wrote:
>
>> Please find attached the pcap. It only has Client Hello.
>> While debugging SSL_accept, I see it stuck in s->method->ssl_read_bytes
>>
>> Thanks,
>> Grace
>>
>>
>> On Tue, Oct 31, 2017 at 4:16 PM, Matt Caswell  wrote:
>>
>>>
>>>
>>> On 31/10/17 10:40, Grace Priscilla Jero wrote:
>>> > Hi Matt,
>>> > yes, we have found that later and have add the call backs. But we never
>>> > get the Client Hello with cookie. The Hello verify request is sent from
>>> > the server.
>>> >
>>> > Thanks for pointing out that listen was for cookies. Now without that
>>> > providing the SSL_accept, it hangs. We are unable to figure out why it
>>> > hangs. Only client hello is sent. Is there any way to spot what is
>>> going
>>> > wrong.
>>>
>>> I suggest you use Wireshark to take a look what is happening on the wire.
>>>
>>> Matt
>>>
>>>
>>> >
>>> > Thanks,
>>> > Grace
>>> >
>>> > On Tue, Oct 31, 2017 at 3:50 PM, Matt Caswell >> > > wrote:
>>> >
>>> >
>>> >
>>> > On 31/10/17 06:06, Grace Priscilla Jero wrote:
>>> > > Thankyou for the suggestions. After correcting few options the
>>> > > "ClientHello" goes successfully but we have failure in
>>> "DTLSv1_listen".
>>> > > There are'nt any cookies in the Client Hello request.
>>> > > But DTLSv1_listen return error and the failure in see is in
>>> > > "SSLerr(SSL_F_DTLSV1_LISTEN, SSL_R_COOKIE_GEN_CALLBACK_FAIL
>>> URE);"
>>> >
>>> > This is most likely because you haven't called
>>> > SSL_CTX_set_cookie_generate_cb() first.
>>> >
>>> > > We are using 1.1.0f version. Is there a way we can disable
>>> cookies?
>>> >
>>> > Well the whole *point* of calling DTLSv1_listen() is to generate
>>> those
>>> > cookies. If you don't want cookies, don't call it.
>>> >
>>> > Matt
>>> >
>>> > >
>>> > > Thanks,
>>> > > Grace
>>> > >
>>> > > On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero
>>> > > 
>>> > >> > >> wrote:
>>> > >
>>> > > Hi Matt,
>>> > >
>>> > > SSL_get_error()  returns 5.
>>> > > It is the same socket using which the UDP connection is
>>> established.
>>> > > Could you suggest some logging that can be done for OPENSSL.
>>> > >
>>> > > Thanks,
>>> > > Grace
>>> > >
>>> > >
>>> > > On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell <
>>> m...@openssl.org 
>>> > > >> wrote:
>>> > >
>>> > >
>>> > >
>>> > > On 26/10/17 16:43, Grace Priscilla Jero wrote:
>>> > > > Thankyou for the responses.
>>> > > > We figured the issue. But now we are getting error -5
>>> > from "SSL_connect"
>>> > > > and the errno is set to 22 which means invalid
>>> argument.
>>> > > > Is there a easy way to debug or get logs for
>>> SSL_connect.
>>> > > >
>>> > > > Below is the sequence for the dtls udp connect that we
>>> > are trying.
>>> > > > ssl = SSL_new(ctx)
>>> > > > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE)
>>> > > > SSL_set_bio(ssl, bio, bio);
>>> > > > VI_res = SSL_connect(ssl)
>>> > >
>>> > > Do you really mean SSL_connect() returns -5? Or do you
>>> > mean that
>>> > > after a
>>> > > negative return value from SSL_connect() you call
>>> > > SSL_get_error() and
>>> > > that return 5 (SSL_ERROR_SYSCALL)?
>>> > >
>>> > > If you really mean SSL_connect() returns -5 then you need
>>> > to call
>>> > > SSL_get_error() as a next step.
>>> > >
>>> > > If you are getting SSL_ERROR_SYSCALL then my guess is
>>> that
>>> > there
>>> > > is a
>>> > > problem with sock_id. How do create it?
>>> > >
>>> > > Matt
>>> > >
>>> > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > Thanks,
>>> > > > Grace
>>> > > >
>>> > > > On 

Re: [openssl-users] Issue with DTLS for UDP

[Grace Priscilla Jero]

Matt,
Here is more info on the process backtrace where it is stuck.

cat /proc/15602/stack
[] inet_csk_accept+0xc1/0x1f0
[] inet_accept+0x28/0xf5
[] sys_accept4+0x11b/0x1b8
[] sys_accept+0xb/0xd
[] system_call_fastpath+0x16/0x1b
[] 0x

Thanks,
Grace

On Tue, Oct 31, 2017 at 4:22 PM, Grace Priscilla Jero <
grace.prisci...@gmail.com> wrote:

> Please find attached the pcap. It only has Client Hello.
> While debugging SSL_accept, I see it stuck in s->method->ssl_read_bytes
>
> Thanks,
> Grace
>
>
> On Tue, Oct 31, 2017 at 4:16 PM, Matt Caswell  wrote:
>
>>
>>
>> On 31/10/17 10:40, Grace Priscilla Jero wrote:
>> > Hi Matt,
>> > yes, we have found that later and have add the call backs. But we never
>> > get the Client Hello with cookie. The Hello verify request is sent from
>> > the server.
>> >
>> > Thanks for pointing out that listen was for cookies. Now without that
>> > providing the SSL_accept, it hangs. We are unable to figure out why it
>> > hangs. Only client hello is sent. Is there any way to spot what is going
>> > wrong.
>>
>> I suggest you use Wireshark to take a look what is happening on the wire.
>>
>> Matt
>>
>>
>> >
>> > Thanks,
>> > Grace
>> >
>> > On Tue, Oct 31, 2017 at 3:50 PM, Matt Caswell > > > wrote:
>> >
>> >
>> >
>> > On 31/10/17 06:06, Grace Priscilla Jero wrote:
>> > > Thankyou for the suggestions. After correcting few options the
>> > > "ClientHello" goes successfully but we have failure in
>> "DTLSv1_listen".
>> > > There are'nt any cookies in the Client Hello request.
>> > > But DTLSv1_listen return error and the failure in see is in
>> > > "SSLerr(SSL_F_DTLSV1_LISTEN, SSL_R_COOKIE_GEN_CALLBACK_FAILURE);"
>> >
>> > This is most likely because you haven't called
>> > SSL_CTX_set_cookie_generate_cb() first.
>> >
>> > > We are using 1.1.0f version. Is there a way we can disable
>> cookies?
>> >
>> > Well the whole *point* of calling DTLSv1_listen() is to generate
>> those
>> > cookies. If you don't want cookies, don't call it.
>> >
>> > Matt
>> >
>> > >
>> > > Thanks,
>> > > Grace
>> > >
>> > > On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero
>> > > 
>> > > > >> wrote:
>> > >
>> > > Hi Matt,
>> > >
>> > > SSL_get_error()  returns 5.
>> > > It is the same socket using which the UDP connection is
>> established.
>> > > Could you suggest some logging that can be done for OPENSSL.
>> > >
>> > > Thanks,
>> > > Grace
>> > >
>> > >
>> > > On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell <
>> m...@openssl.org 
>> > > >> wrote:
>> > >
>> > >
>> > >
>> > > On 26/10/17 16:43, Grace Priscilla Jero wrote:
>> > > > Thankyou for the responses.
>> > > > We figured the issue. But now we are getting error -5
>> > from "SSL_connect"
>> > > > and the errno is set to 22 which means invalid argument.
>> > > > Is there a easy way to debug or get logs for
>> SSL_connect.
>> > > >
>> > > > Below is the sequence for the dtls udp connect that we
>> > are trying.
>> > > > ssl = SSL_new(ctx)
>> > > > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE)
>> > > > SSL_set_bio(ssl, bio, bio);
>> > > > VI_res = SSL_connect(ssl)
>> > >
>> > > Do you really mean SSL_connect() returns -5? Or do you
>> > mean that
>> > > after a
>> > > negative return value from SSL_connect() you call
>> > > SSL_get_error() and
>> > > that return 5 (SSL_ERROR_SYSCALL)?
>> > >
>> > > If you really mean SSL_connect() returns -5 then you need
>> > to call
>> > > SSL_get_error() as a next step.
>> > >
>> > > If you are getting SSL_ERROR_SYSCALL then my guess is that
>> > there
>> > > is a
>> > > problem with sock_id. How do create it?
>> > >
>> > > Matt
>> > >
>> > >
>> > > >
>> > > >
>> > > >
>> > > > Thanks,
>> > > > Grace
>> > > >
>> > > > On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell
>> >  > m...@openssl.org
>> > >
>> > > > 
>> > > > > >
>> > > >
>> > > >
>> > > > On 24/10/17 11:25, Grace Priscilla Jero wrote:
>> > > > > We are using SSL_accept 

[openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Dave Coombs]

Hello,

I was fiddling around with OpenSSL 1.1.0 this past weekend, because One Day 
We'll Need To Upgrade (tm), and ran into the following.

We have some code that uses OCSP_BASICRESP_verify() with 1.0.1 / 1.0.2 to 
confirm that the signature on an ocsp response is correct.  This is a macro in 
ocsp.h, which directly accesses the signature, signatureAlgorithm, and 
tbsResponseData members of the OCSP_BASICRESP structure.  In 1.1.0, this 
structure is now opaque, but the macros are still present in the public ocsp.h, 
so any external code that uses this macro can't compile.

I can get around this by copying the struct definitions from ocsp_lcl.h into 
the external code, but that both defeats the purpose of opaque structures and 
will cause me problems if the structure contents ever change.

Is the correct solution to use OCSP_basic_verify(), which feels like overkill 
for my needs (the code in question is *part of* our own path-validation 
routine), or might there be some other way?

Either way, I hereby report you've got a few macros in a public header that 
can't possibly work as things stand. :-)

Thanks,
  -Dave

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

Re: [openssl-users] Issue with DTLS for UDP

[Matt Caswell]

On 31/10/17 10:40, Grace Priscilla Jero wrote:
> Hi Matt,
> yes, we have found that later and have add the call backs. But we never
> get the Client Hello with cookie. The Hello verify request is sent from
> the server.
> 
> Thanks for pointing out that listen was for cookies. Now without that
> providing the SSL_accept, it hangs. We are unable to figure out why it
> hangs. Only client hello is sent. Is there any way to spot what is going
> wrong.

I suggest you use Wireshark to take a look what is happening on the wire.

Matt


> 
> Thanks,
> Grace
> 
> On Tue, Oct 31, 2017 at 3:50 PM, Matt Caswell  > wrote:
> 
> 
> 
> On 31/10/17 06:06, Grace Priscilla Jero wrote:
> > Thankyou for the suggestions. After correcting few options the
> > "ClientHello" goes successfully but we have failure in "DTLSv1_listen".
> > There are'nt any cookies in the Client Hello request.
> > But DTLSv1_listen return error and the failure in see is in
> > "SSLerr(SSL_F_DTLSV1_LISTEN, SSL_R_COOKIE_GEN_CALLBACK_FAILURE);"
> 
> This is most likely because you haven't called
> SSL_CTX_set_cookie_generate_cb() first.
> 
> > We are using 1.1.0f version. Is there a way we can disable cookies?
> 
> Well the whole *point* of calling DTLSv1_listen() is to generate those
> cookies. If you don't want cookies, don't call it.
> 
> Matt
> 
> >
> > Thanks,
> > Grace
> >
> > On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero
> > 
>  >> wrote:
> >
> >     Hi Matt,
> >
> >     SSL_get_error()  returns 5. 
> >     It is the same socket using which the UDP connection is established.
> >     Could you suggest some logging that can be done for OPENSSL.
> >
> >     Thanks,
> >     Grace
> >
> >
> >     On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell  
> >     >> wrote:
> >
> >
> >
> >         On 26/10/17 16:43, Grace Priscilla Jero wrote:
> >         > Thankyou for the responses.
> >         > We figured the issue. But now we are getting error -5
> from "SSL_connect"
> >         > and the errno is set to 22 which means invalid argument.
> >         > Is there a easy way to debug or get logs for SSL_connect.
> >         >
> >         > Below is the sequence for the dtls udp connect that we
> are trying.
> >         > ssl = SSL_new(ctx)
> >         > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE)
> >         > SSL_set_bio(ssl, bio, bio);
> >         > VI_res = SSL_connect(ssl)
> >
> >         Do you really mean SSL_connect() returns -5? Or do you
> mean that
> >         after a
> >         negative return value from SSL_connect() you call
> >         SSL_get_error() and
> >         that return 5 (SSL_ERROR_SYSCALL)?
> >
> >         If you really mean SSL_connect() returns -5 then you need
> to call
> >         SSL_get_error() as a next step.
> >
> >         If you are getting SSL_ERROR_SYSCALL then my guess is that
> there
> >         is a
> >         problem with sock_id. How do create it?
> >
> >         Matt
> >
> >
> >         >
> >         >
> >         >
> >         > Thanks,
> >         > Grace
> >         >
> >         > On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell
>   >
> >         > 
>  >         >
> >         >
> >         >
> >         >     On 24/10/17 11:25, Grace Priscilla Jero wrote:
> >         >     > We are using SSL_accept to accept the connection
> for which we see the
> >         >     > failure. Please let know if you have any thoughts.
> >         >
> >         >     Have you set the wbio correctly? Does SSL_get_wbio()
> return your wbio
> >         >     object if you call it immediately before
> SSL_do_handshake()?
> >         >
> >         >     Matt
> >         >
> >         >     --
> >         >     openssl-users mailing list
> >         >     To unsubscribe:
> >         >   
>  https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> >          >
> >         >   
>   

Re: [openssl-users] Issue with DTLS for UDP

[Grace Priscilla Jero]

Hi Matt,
yes, we have found that later and have add the call backs. But we never get
the Client Hello with cookie. The Hello verify request is sent from the
server.

Thanks for pointing out that listen was for cookies. Now without that
providing the SSL_accept, it hangs. We are unable to figure out why it
hangs. Only client hello is sent. Is there any way to spot what is going
wrong.

Thanks,
Grace

On Tue, Oct 31, 2017 at 3:50 PM, Matt Caswell  wrote:

>
>
> On 31/10/17 06:06, Grace Priscilla Jero wrote:
> > Thankyou for the suggestions. After correcting few options the
> > "ClientHello" goes successfully but we have failure in "DTLSv1_listen".
> > There are'nt any cookies in the Client Hello request.
> > But DTLSv1_listen return error and the failure in see is in
> > "SSLerr(SSL_F_DTLSV1_LISTEN, SSL_R_COOKIE_GEN_CALLBACK_FAILURE);"
>
> This is most likely because you haven't called
> SSL_CTX_set_cookie_generate_cb() first.
>
> > We are using 1.1.0f version. Is there a way we can disable cookies?
>
> Well the whole *point* of calling DTLSv1_listen() is to generate those
> cookies. If you don't want cookies, don't call it.
>
> Matt
>
> >
> > Thanks,
> > Grace
> >
> > On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero
> > > wrote:
> >
> > Hi Matt,
> >
> > SSL_get_error()  returns 5.
> > It is the same socket using which the UDP connection is established.
> > Could you suggest some logging that can be done for OPENSSL.
> >
> > Thanks,
> > Grace
> >
> >
> > On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell  > > wrote:
> >
> >
> >
> > On 26/10/17 16:43, Grace Priscilla Jero wrote:
> > > Thankyou for the responses.
> > > We figured the issue. But now we are getting error -5 from
> "SSL_connect"
> > > and the errno is set to 22 which means invalid argument.
> > > Is there a easy way to debug or get logs for SSL_connect.
> > >
> > > Below is the sequence for the dtls udp connect that we are
> trying.
> > > ssl = SSL_new(ctx)
> > > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE)
> > > SSL_set_bio(ssl, bio, bio);
> > > VI_res = SSL_connect(ssl)
> >
> > Do you really mean SSL_connect() returns -5? Or do you mean that
> > after a
> > negative return value from SSL_connect() you call
> > SSL_get_error() and
> > that return 5 (SSL_ERROR_SYSCALL)?
> >
> > If you really mean SSL_connect() returns -5 then you need to call
> > SSL_get_error() as a next step.
> >
> > If you are getting SSL_ERROR_SYSCALL then my guess is that there
> > is a
> > problem with sock_id. How do create it?
> >
> > Matt
> >
> >
> > >
> > >
> > >
> > > Thanks,
> > > Grace
> > >
> > > On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell <
> m...@openssl.org 
> > > >> wrote:
> > >
> > >
> > >
> > > On 24/10/17 11:25, Grace Priscilla Jero wrote:
> > > > We are using SSL_accept to accept the connection for
> which we see the
> > > > failure. Please let know if you have any thoughts.
> > >
> > > Have you set the wbio correctly? Does SSL_get_wbio()
> return your wbio
> > > object if you call it immediately before
> SSL_do_handshake()?
> > >
> > > Matt
> > >
> > > --
> > > 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
> > 
> >
> >
> >
> >
> >
> --
> 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 with DTLS for UDP

[Matt Caswell]

On 31/10/17 06:06, Grace Priscilla Jero wrote:
> Thankyou for the suggestions. After correcting few options the
> "ClientHello" goes successfully but we have failure in "DTLSv1_listen".
> There are'nt any cookies in the Client Hello request.
> But DTLSv1_listen return error and the failure in see is in
> "SSLerr(SSL_F_DTLSV1_LISTEN, SSL_R_COOKIE_GEN_CALLBACK_FAILURE);"

This is most likely because you haven't called
SSL_CTX_set_cookie_generate_cb() first.

> We are using 1.1.0f version. Is there a way we can disable cookies?

Well the whole *point* of calling DTLSv1_listen() is to generate those
cookies. If you don't want cookies, don't call it.

Matt

> 
> Thanks,
> Grace
> 
> On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero
> > wrote:
> 
> Hi Matt,
> 
> SSL_get_error()  returns 5. 
> It is the same socket using which the UDP connection is established.
> Could you suggest some logging that can be done for OPENSSL.
> 
> Thanks,
> Grace
> 
> 
> On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell  > wrote:
> 
> 
> 
> On 26/10/17 16:43, Grace Priscilla Jero wrote:
> > Thankyou for the responses.
> > We figured the issue. But now we are getting error -5 from 
> "SSL_connect"
> > and the errno is set to 22 which means invalid argument.
> > Is there a easy way to debug or get logs for SSL_connect.
> >
> > Below is the sequence for the dtls udp connect that we are trying.
> > ssl = SSL_new(ctx)
> > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE)
> > SSL_set_bio(ssl, bio, bio);
> > VI_res = SSL_connect(ssl)
> 
> Do you really mean SSL_connect() returns -5? Or do you mean that
> after a
> negative return value from SSL_connect() you call
> SSL_get_error() and
> that return 5 (SSL_ERROR_SYSCALL)?
> 
> If you really mean SSL_connect() returns -5 then you need to call
> SSL_get_error() as a next step.
> 
> If you are getting SSL_ERROR_SYSCALL then my guess is that there
> is a
> problem with sock_id. How do create it?
> 
> Matt
> 
> 
> >
> >
> >
> > Thanks,
> > Grace
> >
> > On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell  
> > >> wrote:
> >
> >
> >
> >     On 24/10/17 11:25, Grace Priscilla Jero wrote:
> >     > We are using SSL_accept to accept the connection for which we 
> see the
> >     > failure. Please let know if you have any thoughts.
> >
> >     Have you set the wbio correctly? Does SSL_get_wbio() return 
> your wbio
> >     object if you call it immediately before SSL_do_handshake()?
> >
> >     Matt
> >
> >     --
> >     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
> 
> 
> 
> 
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] CMS-supported ciphers

[ch]

Hello!

I see the CMS-Interface (CMS_encrypt, X_write_CMS, ...) does not support 
AES128-GCM.


https://mta.openssl.org/pipermail/openssl-dev/2015-April/001177.html

Is there a list of all supporting ciphers for CMS?
Or how can I find out without trying it?

Thanks!
Chris


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

Re: [openssl-users] Issue with DTLS for UDP

[Grace Priscilla Jero]

Thankyou for the suggestions. After correcting few options the
"ClientHello" goes successfully but we have failure in "DTLSv1_listen".
There are'nt any cookies in the Client Hello request.
But DTLSv1_listen return error and the failure in see is in
"SSLerr(SSL_F_DTLSV1_LISTEN, SSL_R_COOKIE_GEN_CALLBACK_FAILURE);"

We are using 1.1.0f version. Is there a way we can disable cookies?

Thanks,
Grace

On Fri, Oct 27, 2017 at 12:39 PM, Grace Priscilla Jero <
grace.prisci...@gmail.com> wrote:

> Hi Matt,
>
> SSL_get_error()  returns 5.
> It is the same socket using which the UDP connection is established.
> Could you suggest some logging that can be done for OPENSSL.
>
> Thanks,
> Grace
>
>
> On Thu, Oct 26, 2017 at 9:23 PM, Matt Caswell  wrote:
>
>>
>>
>> On 26/10/17 16:43, Grace Priscilla Jero wrote:
>> > Thankyou for the responses.
>> > We figured the issue. But now we are getting error -5 from "SSL_connect"
>> > and the errno is set to 22 which means invalid argument.
>> > Is there a easy way to debug or get logs for SSL_connect.
>> >
>> > Below is the sequence for the dtls udp connect that we are trying.
>> > ssl = SSL_new(ctx)
>> > bio = BIO_new_dgram(sock_id,BIO_NOCLOSE)
>> > SSL_set_bio(ssl, bio, bio);
>> > VI_res = SSL_connect(ssl)
>>
>> Do you really mean SSL_connect() returns -5? Or do you mean that after a
>> negative return value from SSL_connect() you call SSL_get_error() and
>> that return 5 (SSL_ERROR_SYSCALL)?
>>
>> If you really mean SSL_connect() returns -5 then you need to call
>> SSL_get_error() as a next step.
>>
>> If you are getting SSL_ERROR_SYSCALL then my guess is that there is a
>> problem with sock_id. How do create it?
>>
>> Matt
>>
>>
>> >
>> >
>> >
>> > Thanks,
>> > Grace
>> >
>> > On Tue, Oct 24, 2017 at 4:07 PM, Matt Caswell > > > wrote:
>> >
>> >
>> >
>> > On 24/10/17 11:25, Grace Priscilla Jero wrote:
>> > > We are using SSL_accept to accept the connection for which we see
>> the
>> > > failure. Please let know if you have any thoughts.
>> >
>> > Have you set the wbio correctly? Does SSL_get_wbio() return your
>> wbio
>> > object if you call it immediately before SSL_do_handshake()?
>> >
>> > Matt
>> >
>> > --
>> > 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
>>
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users