Re: [openssl-users] OCSP signature verification

[Wouter Verhelst]

On 01-12-15 14:58, Verhelst Wouter (Consultant) wrote:

Hi folks,

I'm trying to write an application that needs to verify the validity of data on 
a smartcard. That data is signed with an RSA key for which a certificate exists 
on the card; but if the card is stolen or lost, the certificate will be 
revoked, so I want to ensure that the certificate is valid. I'm doing an OCSP 
request to take care of that.

Since OpenSSL's own OCSP_sendreq_* functions don't support HTTP proxies, I'm 
currently using libcurl to send the request to the OCSP endpoint. This seems to 
work; when I get the reply and use d2i_OCSP_RESPONSE(), then with things like 
OCSP_response_status() and OCSP_resp_find_status() and friends I can manage to 
get the status of the request and a given certificate.

However, that doesn't do signature verification. I believe that I should use 
OCSP_basic_verify() for that, but I'm not entirely sure whether that is the 
case, and if so whether I would need to do some additional checks beforehand. 
Unfortunately, I can't find any documentation on OCSP_basic_verify().

I should note that due to the nature of my needs, I have a rather huge set of 
valid intermediate CAs, but a fairly limited set of root CAs that can be used 
for valid cards (that is, if the signature validates but it wasn't signed by 
any of the CAs under one of my limited set of roots, the card is a forgery and 
should be rejected as invalid).

A few questions:
- Am I right in assuming that OCSP_basic_verify will check the signature on the 
OCSP request?
- In "OCSP_basic_verify(OCSP_BASICRESP *bs, STACK_OF(X509) *certs, X509_STORE *st, unsigned long flags)", I'm not 
entirely certain of what the "st" argument is meant to contain, and can't figure out the "certs" one. Pouring 
over the code, I believe the "st" argument should allow me to limit validation to my set of root certificates, but I 
could be mistaken. As for the "certs" one, I can't understand that one at all. The only thing I can think of is that 
maybe it should contain the issuer certificate that I used for the original request, but then why is it a STACK_OF(X509)* and not 
just an X509*? What am I missing?

Thanks for any help,


Ping. Anyone?

If this is documented somewhere, feel free to point me to the 
documentation...


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

Re: [openssl-users] [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Emilia Käsper]

To close off this thread: OpenSSL will not be making any changes.

The team voted on moving a set of algorithms to maintenance mode, and
removing the corresponding assembly implementations from libcrypto, but the
vote did not pass.

Emilia

On Fri, Nov 27, 2015 at 10:19 AM, Tim Hudson  wrote:

> On 24/11/2015 4:09 AM, Jakob Bohm wrote:
> > But they care very much if Cisco AnyConnect (or any other
> > OpenSSL using program they may need) stops working or
> > becomes insecure because the OpenSSL team is breaking
> > stuff just because it is not needed in their own handful
> > of example uses.
>
> The OpenSSL team (like most open source projects) is made up of
> individuals that have widely varying backgrounds and experiences - and
> those experiences lead to different view points on a lot of fairly
> fundamental topics. This is a good thing - as frankly a project that
> doesn't have a mix of view points tends to not last.
>
> Between the OpenSSL team members our experiences cover a very wide range
> of uses and many of us have been working on the code base for 17+ years
> and have worked in areas that are certainly well outside the average or
> common uses. However despite that experience we certainly don't think
> that we know what all the users of the code base are doing.
>
> Increasingly we are making sure any debate on project direction where
> there are mixed view points within the team brings in the openssl-users
> and/or openssl-dev lists so we get to have input from a wider set of
> people - who may or may not represent uses that we don't already know
> about.
>
> All the view points being expressed are valid and there are good reasons
> why we could as a team head in either direction (dropping out code or
> keeping everything or anything along that spectrum) and what is
> important is to listen to the input and see the varying points of view
> and add that into the decision making process.
>
> So if you have a use of OpenSSL that you think the team might not know
> about then please express that clearly on the list. View points on what
> has been proposed are also welcome - but I think you'll find increasing
> the awareness of the team about what our users are doing is the more
> important of the two objectives in seeking feedback.
>
> Tim.
>
> ___
> 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] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jakob Bohm]

Could you extract the disassembly of one of the failed
calls to constant_time_eq_8() in the test program, perhaps
the compiler generates incorrect code for this deeply
nested group of near-edge arithmetic operations?

On 09/12/2015 12:44, Jayalakshmi bhat wrote:

Hi Matt,

I could build and execute the constant_time_test. I have attached the 
.c file and test results. 34 tests have failed. All failures are 
around constant_time_eq_8. This is the function I had mentioned in the 
earlier mails.


On Tue, Dec 8, 2015 at 4:26 PM, Matt Caswell > wrote:




On 08/12/15 17:27, Jakob Bohm wrote:
> On 08/12/2015 11:57, Matt Caswell wrote:
>> On 07/12/15 05:18, Jayalakshmi bhat wrote:
>>> Hi All,
>>>
>>> Is there inputs or suggestions.
>> Have you run the tests on this platform? i.e. "make test"
>>
>> I'm particular interested to know if the constant_time_test passed.
> He can't.  WinCE is not a self-hosting platform,
> everything is done by cross-compiling on a PC.

Can we copy the text exe across?


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] openssl fipsalgtest

[Steve Marquess]

On 12/09/2015 12:06 AM, xxiao8 wrote:
> I'm trying to run the algorithm tests under linux for fips 2.0.10 +
> openssl 1.0.1e, using the fips-2.0-tv.tar.gz from openssl website, and
> saw quite some errors, anything am I missing?

fipsalgtest.pl is a utility of value only for performing formal CAVP
algorithm testing. Unfortunately the CAVP is constantly changing the
format of the algorithm test files ("test vectors"), so by the time you
try to use fipsalgtest.pl on a newly obtained set of test vectors for
your validation attempt it probably won't exactly match. You'll need to
dig in and figure out the discrepancies.

Also note it's not at all unusual to receive incorrect test vectors (the
CAVS tool that generates them is very labor intensive and it's all too
easy for the test lab to miss a checkbox or whatever). Figuring out
whether a discrepancy is due to a legitimate format change or outright
error, and then convincing the test lab and CAVP of the latter, can be fun.

We developed this tool because we were doing platform tests by the
hundreds. For a one-off validation you may want to consider just
hand-jamming the "--generate-script" file.

I'll also note that sorting out the algorithm tests will be relatively
trivial compared to hacking the OpenSSL FIPS Object Module v2.0 code to
meet all the new requirements that have accumulated since that
validation was obtained. You'll want to do those mods before the
algorithm testing.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Response from server is lost on close

[Anty Rao]

Hi : ALL
Using non-blocking openssl , after detecting underlying TCP is broken, i
invoke SSL_read to attempting reading response. *sometimes* response from
server is lost, sometimes not. But tcpdump show that response is always
send back to me. what is special is that RST packages come next the
response. Can someone shed some light on me, Thanks.Here is the result of
tcpdump:

> 22:29:52.284797 IP 17.143.162.202.2195 > xx.xx.xx.xx.49038: Flags [FP.], seq 
> 4801:4838, ack 4158, win 340, option
> s [nop,nop,TS val 1184022887 ecr 2339879379], length 37
> 0x:  4500 0059 dcdb 4000 2e06 021a 118f a2ca  E..Y..@.
> 0x0010:  b73c 0214 0893 bf8e 93b8 7466 2b1b 88c2  . 0x0020:  8019 0154 faed  0101 080a 4692 c167  ...TF..g
> 0x0030:  8b77 b9d3 1503 0100 2006 f287 45d4 311e  .w..E.1.
> 0x0040:  e3fe 5cfc 9904 b7a6 2e7e 1221 9967 fdd3  ..\..~.!.g..
> 0x0050:  5314 a007 f48d 7490 d6   
> S.t..22:29:52.284802 IP xx.xx.xx.xx.49038 > 17.143.162.202.2195: Flags 
> [.], ack 4764, win 15, options [nop,nop,TS val2339879429 ecr 
> 1184022886,nop,nop,sack 1 {4801:4839}], length 0
> 0x:  4500 0040 c041 4000 4006 0ccd b73c 0214  E..@.A@.@<..
> 0x0010:  118f a2ca bf8e 0893 2b1b cca2 93b8 7441  +.tA
> 0x0020:  b010 000f ad39  0101 080a 8b77 ba05  .9...w..
> 0x0030:  4692 c166 0101 050a 93b8 7466 93b8 748c  
> F..f..tf..t.22:29:52.483487 IP 17.143.162.202.2195 > xx.xx.xx.xx.49038: 
> Flags [R], seq 2478339137, win 0, length 0
> 0x:  4500 0028  4000 2e06 df26 118f a2ca  E..(..@&
> 0x0010:  b73c 0214 0893 bf8e 93b8 7441    . 0x0020:  5004  721b       
> P...r.
> another :
> 16:18:00.168274 IP 17.143.161.207.2195 > xx.xxx.xx.xx.43361: Flags [P.], seq 
> 4764:4801, ack 37462, win 432, option
> s [nop,nop,TS val 1248125705 ecr 2355901348], length 37
> 0x:  4500 0059 c936 4000 3006 14ba 118f a1cf  E..Y.6@.0...
> 0x0010:  b73c 0214 0893 a961 1e10 133f 2197 3724  .<.a...?!.7$
> 0x0020:  8018 01b0 245e  0101 080a 4a64 e309  $^..Jd..
> 0x0030:  8c6c 33a4 1503 0100 2012 a99f e30c 37aa  .l3...7.
> 0x0040:  eda1 e24a 1819 74cb 1a73 2396 f76e b9fa  ...J..t..s#..n..
> 0x0050:  293b 8625 8a9d 09a7 30   
> );.%016:18:00.168326 IP 17.143.161.207.2195 > xx.xxx.xx.xx.43361: Flags 
> [R.], seq 4801, ack 37462, win 498, options [no
> p,nop,TS val 1248125705 ecr 2355901348], length 0
> 0x:  4500 0034 c937 4000 3006 14de 118f a1cf  E..4.7@.0...
> 0x0010:  b73c 0214 0893 a961 1e10 1364 2197 3724  .<.a...d!.7$
> 0x0020:  8014 01f2 de75  0101 080a 4a64 e309  .u..Jd..
> 0x0030:  8c6c 33a4.l3.
>
>


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

Re: [openssl-users] Response from server is lost on close

[Michael Wojcik]

(Sorry for the delay in replying - I was tied up with other things.)

Yes, you're correct. I was misremembering, and should have checked references 
first.

The BSD implementation that Gary Wright and Rich Stevens describe in TCP/IP 
Illustrated v. 2 drops queued outbound data (on both sides) and queued 
out-of-order segments waiting for reassembly on the receiving side when an RST 
is received. But it doesn't appear to drop queued in-order, ACK'd data.

And I think that's the correct behavior. If the side that receives the RST has 
ACK'd some data, then it should hang onto that data for the application to 
receive it. It should only report the error (ECONNRESET) when the application 
has successfully read the queued data.

So I suspect what you're seeing is OpenSSL behavior. It's likely reading ahead, 
seeing the ECONNRESET, and discarding the received data. But I haven't had a 
chance to look at the OpenSSL code in question.

In some cases OpenSSL will have to read ahead. It needs to receive the complete 
SSL/TLS/DTLS record before processing it, for example; and if that record is 
broken up into multiple TCP segments (because the path MTU is smaller than the 
record size) then it could have a partial record when it receives the RST. I 
can't tell if that situation is present in your case (without manually decoding 
the tcpdump trace, which I don't have time to do at the moment).

Michael Wojcik
Technology Specialist, Micro Focus
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Benjamin Kaduk]

On 12/09/2015 05:04 PM, Matt Caswell wrote:
>
> On 09/12/15 11:44, Jayalakshmi bhat wrote:
>> Hi Matt,
>>
>> I could build and execute the constant_time_test. I have attached the .c
>> file and test results. 34 tests have failed. All failures are
>> around constant_time_eq_8. This is the function I had mentioned in the
>> earlier mails.
> Not quite all. There is also a failure right at the beginning of your
> log in constant_time_is_zero_8. Although it looks very similar to the
> constant_time_eq_8 failure.
>
> As to the failure it is very strange. This is the function doing the test:
>
>  int test_binary_op_8(unsigned
> char (*op) (unsigned int a, unsigned int b),
> const char *op_name, unsigned int a,
> unsigned int b, int is_true)
> {
> unsigned char c = op(a, b);
> if (is_true && c != CONSTTIME_TRUE_8) {
> printf( "Test failed for %s(%du, %du): expected %u "
> "(TRUE), got %u at line %d\n", op_name, a, b,
> CONSTTIME_TRUE_8, c,__LINE__);
> return 1;
> } else if (!is_true && c != CONSTTIME_FALSE_8) {
> printf( "Test failed for  %s(%du, %du): expected %u "
> "(FALSE), got %u at line %d\n", op_name, a, b,
> CONSTTIME_FALSE_8, c,__LINE__);
> return 1;
> }
>   printf( "Test passed for %s(%du, %du): expected %u got %u at line %d
> with %s\n", op_name, a, b, CONSTTIME_TRUE_8,
> c,__LINE__,is_true?"TRUE":"FALSE");
> return 0;
> }
>
>
> and the output we see in the log file is:
>
> Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got
> 4294967295 at line 85
>
> That big number in the output is actually 0x7FFF in hex. The
> variable that it is printing here is "c" which is declared as an
> "unsigned char".
>
> Please someone correct me if I'm wrong but doesn't the C spec guarantee
> that a "char" is 8 bits? In which case how can the value of "c" be
> greater than 255?

C does not make such a guarantee, though recent-ish POSIX does.  (This
system is a windows one, thought, right?)

In any case, due to C's type promotion rules, it's very difficult to
actually use types narrower than 'int', since integers get auto-promoted
to int at integer conversion time.  This has extra-fun interactions with
varargs functions, depending on the platform ABI in use.  (Always cast
NULL to a pointer type when passing to a varargs function; this does
cause real bugs.)  Since c is unsigned, it is odd to see it get promoted
to (int)-1, since C type conversions are supposed to be
value-preserving, but it is certainly possible that the windows ABI is
doing something I don't expect.  Adjusting things so that the format
specifier and the type passed to printf match (whether by casting c to
int or qualifying the format specifier) might help.

-Ben

> Am I missing something?
>
> BTW can we modify the code above to print the value of sizeof(c)?
>
> 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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Matt Caswell]

On 09/12/15 11:44, Jayalakshmi bhat wrote:
> Hi Matt,
> 
> I could build and execute the constant_time_test. I have attached the .c
> file and test results. 34 tests have failed. All failures are
> around constant_time_eq_8. This is the function I had mentioned in the
> earlier mails.

Not quite all. There is also a failure right at the beginning of your
log in constant_time_is_zero_8. Although it looks very similar to the
constant_time_eq_8 failure.

As to the failure it is very strange. This is the function doing the test:

 int test_binary_op_8(unsigned
char (*op) (unsigned int a, unsigned int b),
const char *op_name, unsigned int a,
unsigned int b, int is_true)
{
unsigned char c = op(a, b);
if (is_true && c != CONSTTIME_TRUE_8) {
printf( "Test failed for %s(%du, %du): expected %u "
"(TRUE), got %u at line %d\n", op_name, a, b,
CONSTTIME_TRUE_8, c,__LINE__);
return 1;
} else if (!is_true && c != CONSTTIME_FALSE_8) {
printf( "Test failed for  %s(%du, %du): expected %u "
"(FALSE), got %u at line %d\n", op_name, a, b,
CONSTTIME_FALSE_8, c,__LINE__);
return 1;
}
printf( "Test passed for %s(%du, %du): expected %u got %u at line %d
with %s\n", op_name, a, b, CONSTTIME_TRUE_8,
c,__LINE__,is_true?"TRUE":"FALSE");
return 0;
}


and the output we see in the log file is:

Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got
4294967295 at line 85

That big number in the output is actually 0x7FFF in hex. The
variable that it is printing here is "c" which is declared as an
"unsigned char".

Please someone correct me if I'm wrong but doesn't the C spec guarantee
that a "char" is 8 bits? In which case how can the value of "c" be
greater than 255?

Am I missing something?

BTW can we modify the code above to print the value of sizeof(c)?

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

Re: [openssl-users] Response from server is lost on close

[Anty Rao]

Hi Michael,
Thanks for your reply, and appreciate your answer which clear many of my
doubts.

Currently i'm stuck with this problem, can't find a way out,let me give
more context of my problem.
I use non-blocking openssl  to interact with Apple's APNS server to send
notifications to Iphone devices.

According to protocol of APNS server, most of the time, there is no
response from server; nevertheless ,if bad things happens, server will send
a reply and close the underlying connection.The reply, which is very short,
 should be fit in one TCP segment.This can be confirmed by result of
tcpdump, which i post at the beginning in this thread.

So I always write to server until write operation fails, then i try to read
the reply.  There is one observation when doing test, if i throttle write
speed to some extent, response can be successfully fetched. However, if i
speed up write speed, response will be lost most likely.

Hopely you can look at this when you have time ,Thanks.


Thanks.
Anty.



On Wed, Dec 9, 2015 at 10:19 PM, Michael Wojcik <
michael.woj...@microfocus.com> wrote:

> (Sorry for the delay in replying - I was tied up with other things.)
>
>
>
> Yes, you're correct. I was misremembering, and should have checked
> references first.
>
>
>
> The BSD implementation that Gary Wright and Rich Stevens describe in *TCP/IP
> Illustrated* v. 2 drops queued outbound data (on both sides) and queued
> out-of-order segments waiting for reassembly on the receiving side when an
> RST is received. But it doesn't appear to drop queued in-order, ACK'd data.
>
>
>
> And I think that's the correct behavior. If the side that receives the RST
> has ACK'd some data, then it should hang onto that data for the application
> to receive it. It should only report the error (ECONNRESET) when the
> application has successfully read the queued data.
>
>
>
> So I suspect what you're seeing is OpenSSL behavior. It's likely reading
> ahead, seeing the ECONNRESET, and discarding the received data. But I
> haven't had a chance to look at the OpenSSL code in question.
>
>
>
> In some cases OpenSSL will have to read ahead. It needs to receive the
> complete SSL/TLS/DTLS record before processing it, for example; and if that
> record is broken up into multiple TCP segments (because the path MTU is
> smaller than the record size) then it could have a partial record when it
> receives the RST. I can't tell if that situation is present in your case
> (without manually decoding the tcpdump trace, which I don't have time to do
> at the moment).
>
>
>
> Michael Wojcik
> Technology Specialist, Micro Focus
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Viktor Dukhovni]

On Wed, Dec 09, 2015 at 11:04:35PM +, Matt Caswell wrote:

> unsigned char c = op(a, b);
> if (is_true && c != CONSTTIME_TRUE_8) {
> printf( "Test failed for %s(%du, %du): expected %u "
> "(TRUE), got %u at line %d\n", op_name, a, b,
> CONSTTIME_TRUE_8, c,__LINE__);

It is best to not leave "c" to the vagaries of stdarg argument
handling.  Rather, it would better to explicitly convert it to an
unsigned long, and print that.

> Test failed for constant_time_eq_8(0u, 0u): expected 255 (TRUE), got
> 4294967295 at line 85

> That big number in the output is actually 0x7FFF in hex.

Actually it is 0x, that is a 32-bit "-1".

> Please someone correct me if I'm wrong but doesn't the C spec guarantee
> that a "char" is 8 bits? In which case how can the value of "c" be
> greater than 255?

Well, it isn't greater, but the integral promotion for printf seems
to forget that c is unsigned.

> BTW can we modify the code above to print the value of sizeof(c)?

That is 1 by definition.  What we don't know on sufficiently odd
systems is whether a char is 8 bits or not.  The unit for sizeof
is chars not bytes.  So there's no point printing that.  You might
be interested in the CHAR_BIT macro from  instead, but
I don't think that's relevant at this time.

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