Re: [openssl-dev] X509_cmp_time (possible) bug

[Short, Todd via openssl-dev]

Correct,

But if one want’s strcmp()’s behavior (i.e. 0 is equality), 
ASN1_TIME_cmp_time_t() will work (and was written because X509_cmp_time() 
couldn’t be changed without breaking other things).
--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Sep 11, 2017, at 10:43 AM, Daniel Kahn Gillmor 
<d...@fifthhorseman.net<mailto:d...@fifthhorseman.net>> wrote:

On Mon 2017-09-11 14:16:11 +0000, Short, Todd via openssl-dev wrote:
Yes, it’s annoying, but it’s historic. I looked into changing this at one point.

I think Dimitry's point was that the documentation doesn't match the
implementation because of the flexibility of strcmp's defined return
code.

However, i think commit 80770da39ebba0101079477611b7ce2f426653c5 ("X509
time: tighten validation per RFC 5280") resolves Dmitry's concerns.

   --dkg

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

Re: [openssl-dev] X509_cmp_time (possible) bug

[Short, Todd via openssl-dev]

Yes, it’s annoying, but it’s historic. I looked into changing this at one point.

I recommend using ASN1_TIME_cmp_time_t() (from the master branch) instead, for 
the results you are expecting.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Sep 9, 2017, at 10:10 AM, Dmitry Belyavsky 
> wrote:

Hello,

The X509_cmp_time function is documented as returning -1 or 1 on success and 0 
on error.

In fact it returns result of strcmp:
int X509_cmp_time(const ASN1_TIME *ctm, time_t *cmp_time) {
...
i = strcmp(buff1, buff2);
if (i == 0) /* wait a second then return younger */
return -1;
else
return i;
}

According to documentation to the strcmp,

The strcmp() and strncmp() functions return an integer less than, equal to, or 
greater than  zero  if  s1 (or the first n bytes thereof) is found, 
respectively, to be less than, to match, or be greater than s2.

It means (and have been met in practice) that X509_cmp_time() returns other 
values than 1/-1.
So it seems reasonable to either update documentation or fix the behavior.

Thank you!

--
SY, Dmitry Belyavsky
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

Re: [openssl-dev] Compiler requirements

[Short, Todd via openssl-dev]

I think it’s more a matter of using new features in C11 that preclude 
compilation on older platforms, rather than the use of a C11 compiler itself.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Jul 4, 2017, at 1:34 PM, Kurt Roeckx > 
wrote:

On Tue, Jul 04, 2017 at 05:42:42PM +0200, Richard Levitte wrote:
In message 
<2f548b68de1c47dfaa6a3b0107080...@usma1ex-dag1mb1.msg.corp.akamai.com>
 on Tue, 4 Jul 2017 15:05:06 +, "Salz, Rich via openssl-dev" 
> said:

openssl-dev> > beldmit> What is the minimal version of the compiler to build 
openssl?
openssl-dev> > beldmit> Is it still required C89 compatibility or C99 standard 
can be used?
openssl-dev> > beldmit>
openssl-dev> > beldmit> Unfortunately, I did not find these requirements in 
documentation.
openssl-dev> >
openssl-dev> > At the beginning of INSTALL, you will find a set of 
requirements.  On of them
openssl-dev> > is "an ANSI C compiler".
openssl-dev>
openssl-dev> That doesn't answer the question :)  Which version of ANSI C?

Ah, you're right, "ANSI C" is a bit of a loose target depending on who
you ask.  As far as I know, we refer to C89/C90 (they are essentially
the same for our intents and purposes).

openssl-dev> I believe C89 is written down somewhere.

C89 is written nowhere in the source at least, nor is C90.  We should
probably clarify that.


Speculating a bit, it's probably safe to say that C95 compiler is fine
as well.  C99, not so much, there's too much risk that we start
excluding some platforms if we start using its features.  Anyway, I
don't think it's safe to upgrade our minimum expectations now.
OpenSSL 1.2.0 would be a good time for such re-evaluations.

I think the minimum requirement is C89 + support for "long long".

A newer version shouldn't be a problem, it should work with a
compiler that defaults to C11 for instance.


Kurt

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

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

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

[Short, Todd via openssl-dev]

MLOCK_ONFAULT is a Linux-only feature (hence the need to include  
wrapped by OPENSSL_SYS_LINUX.

So, you should not be encountering any MLOCK_ONFAULT or  issues 
on MacOS.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

> On May 15, 2017, at 1:51 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> On 5/15/17, 1:20 PM, "openssl-dev on behalf of Benjamin Kaduk via 
> openssl-dev"   on behalf of openssl-dev@openssl.org 
> > wrote:
>> > On a semi-related note, I want able to locate mann.h file either.
> 
> `man mmap` will list any headers needed for the mmap() declaration and flag 
> values.
> On the random OS X machine I have handy, it claims  is needed, 
> and a /usr/include/sys/mman.h is present.
> 
> Thanks – I confirm that `man mmap` mentions /usr/include/sys/mman.h, and that 
> file does exist (how could my first `find` miss it?!). 
> This file does not contain MLOCK_ONFAULT though.
>  
> It has MAP_ANON:
>  
> /*
>  * Mapping type
>  */
> #define MAP_FILE0x  /* map from file (default) */
> #define MAP_ANON0x1000  /* allocated from memory, swap space */
> #define MAP_ANONYMOUS   MAP_ANON
>  
> And as I already mentioned, it has a world-accessible (figuratively speaking 
> :) /dev/zero that can be opened read/write.
>  
> Also, with #3455 applied the problem disappeared (thankfully :).
>  
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev 
> 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

[Short, Todd via openssl-dev]

s/want/wasn’t/ ?

So, no MLOCK_ONFAULT for you? That’s only included on Linux systems, which 
makes sense if you’re on a Mac.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

> On May 15, 2017, at 1:15 PM, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> 
> wrote:
> 
> My disk is SSD, but computer load is pretty high. Which probably explains 
> that recovery doesn't take place in 200-400 seconds...
> 
> On a semi-related note, I want able to locate mann.h file either.
> 
> Regards,
> Uri
> 
> Sent from my iPhone
> 
> On May 15, 2017, at 13:09, Short, Todd <tsh...@akamai.com 
> <mailto:tsh...@akamai.com>> wrote:
> 
>> The time of the hang actually seems dependent on the number of applications 
>> running and your disk.
>> 
>> Since a large amount of memory becomes wired, there is very little available 
>> for programs and the OS to use (in some instances I have seen ~4MB non-wired 
>> memory). Things slow down due to swapping, etc. 
>> 
>> In my testing:
>> 
>> With almost no additional programs open, the hang-time is short, ~200 
>> seconds.
>> With a lot of programs open, the hang-time is increased, ~400 seconds; twice 
>> as long. And the number of swapins is 25x and the swapouts is ~34x the 
>> original test period.
>> 
>> This is on a machine with an SSD (late-2013 MBP)
>> If you have a spinning HDD, the swapins and swapouts will be significantly 
>> more expensive in terms of performance/time.
>> 
>> If you quit all your programs, (other than Terminal), I suspect the hang may 
>> eventually recover; but if you have a hard disk that time might be quite 
>> long.
>> 
>> --
>> -Todd Short
>> // tsh...@akamai.com <mailto:tsh...@akamai.com>
>> // "One if by land, two if by sea, three if by the Internet."
>> 
>>> On May 15, 2017, at 11:51 AM, Blumenthal, Uri - 0553 - MITLL 
>>> <u...@ll.mit.edu <mailto:u...@ll.mit.edu>> wrote:
>>> 
>>> I’m tracking the current OpenSSL master only on El Capitan 10.11.6. I could 
>>> try it on Sierra 10.12.4, if you really expect it to make a difference.
>>>  
>>> In my case the hang is not for a short time. It lasts for more than 10 
>>> minutes, so I’m forced to interfere. For how long did it hang for you?
>>> — 
>>> Regards,
>>> Uri
>>>  
>>>  
>>> On 5/15/17, 11:47 AM, "openssl-dev on behalf of Short, Todd via 
>>> openssl-dev" <openssl-dev-boun...@openssl.org 
>>> <mailto:openssl-dev-boun...@openssl.org> on behalf of 
>>> openssl-dev@openssl.org <mailto:openssl-dev@openssl.org>> wrote:
>>>  
>>> We’ve been able to get some Macs (10.11.6, 8GB and 16GB) to hang for a 
>>> short period of time with the unit-tests, but it eventually recovers. 
>>>  
>>> What MacOS version are you running? I can try 10.12 later today.
>>> --
>>> -Todd Short
>>> // tsh...@akamai.com <mailto:tsh...@akamai.com>
>>> // "One if by land, two if by sea, three if by the Internet."
>>>  
>>>> On May 12, 2017, at 4:50 PM, Short, Todd via openssl-dev 
>>>> <openssl-dev@openssl.org <mailto:openssl-dev@openssl.org>> wrote:  
>>>>  
>>>> Uri: 
>>>>  
>>>> Look at https://github.com/openssl/openssl/pull/3455 
>>>> <https://github.com/openssl/openssl/pull/3455>
>>>>  
>>>> I limited the test that hung your machine to Linux.
>>>>  
>>>> Rich: this removes the OpenSSL_assert() you see.
>>>>  
>>>> --
>>>> -Todd Short
>>>> // tsh...@akamai.com <mailto:tsh...@akamai.com>
>>>> // "One if by land, two if by sea, three if by the Internet."
>>>>  
>>>>> On May 12, 2017, at 4:46 PM, Short, Todd via openssl-dev 
>>>>> <openssl-dev@openssl.org <mailto:openssl-dev@openssl.org>> wrote:
>>>>>  
>>>>> It’s trying to reserve 1<<34 bytes of memory… there goes your 16GB...
>>>>> --
>>>>> -Todd Short
>>>>> // tsh...@akamai.com <mailto:tsh...@akamai.com>
>>>>> // "One if by land, two if by sea, three if by the Internet."
>>>>>  
>>>>>> On May 12, 2017, at 4:05 PM, Blumenthal, Uri - 0553 - MITLL 
>>>>>> <u...@ll.mit.edu <mailto:u...@ll.mit.edu>> wrote:
>>>>>>  
>>>>>> Todd> Yes, it’s likely this is due to the amount of memory available in 
>>>>>> the machine. I tried to use reasonable values, but apparently not 
>>>>>> reasonable enough
>>>>>>  
>>>>>> Yep. In case it matters, my machine has 16GB of RAM (and runs a ton of 
>>>>>> stuff, besides these tests :).
>>>>>> -- 
>>>>>> openssl-dev mailing list
>>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev 
>>>>>> <https://mta.openssl.org/mailman/listinfo/openssl-dev>
>>>>>  
>>>>> -- 
>>>>> openssl-dev mailing list
>>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev 
>>>>> <https://mta.openssl.org/mailman/listinfo/openssl-dev>
>>>>  
>>>> -- 
>>>> openssl-dev mailing list
>>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev 
>>>> <https://mta.openssl.org/mailman/listinfo/openssl-dev>
>>>  
>> 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

[Short, Todd via openssl-dev]

We’ve been able to get some Macs (10.11.6, 8GB and 16GB) to hang for a short 
period of time with the unit-tests, but it eventually recovers.

What MacOS version are you running? I can try 10.12 later today.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

> On May 12, 2017, at 4:50 PM, Short, Todd via openssl-dev 
> <openssl-dev@openssl.org> wrote:
> 
> Uri:
> 
> Look at https://github.com/openssl/openssl/pull/3455 
> <https://github.com/openssl/openssl/pull/3455>
> 
> I limited the test that hung your machine to Linux.
> 
> Rich: this removes the OpenSSL_assert() you see.
> 
> --
> -Todd Short
> // tsh...@akamai.com <mailto:tsh...@akamai.com>
> // "One if by land, two if by sea, three if by the Internet."
> 
>> On May 12, 2017, at 4:46 PM, Short, Todd via openssl-dev 
>> <openssl-dev@openssl.org <mailto:openssl-dev@openssl.org>> wrote:
>> 
>> It’s trying to reserve 1<<34 bytes of memory… there goes your 16GB...
>> --
>> -Todd Short
>> // tsh...@akamai.com <mailto:tsh...@akamai.com>
>> // "One if by land, two if by sea, three if by the Internet."
>> 
>>> On May 12, 2017, at 4:05 PM, Blumenthal, Uri - 0553 - MITLL 
>>> <u...@ll.mit.edu <mailto:u...@ll.mit.edu>> wrote:
>>> 
>>> Todd> Yes, it’s likely this is due to the amount of memory available in the 
>>> machine. I tried to use reasonable values, but apparently not reasonable 
>>> enough
>>>  
>>> Yep. In case it matters, my machine has 16GB of RAM (and runs a ton of 
>>> stuff, besides these tests :).
>>> -- 
>>> openssl-dev mailing list
>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev 
>>> <https://mta.openssl.org/mailman/listinfo/openssl-dev>
>> 
>> -- 
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev 
>> <https://mta.openssl.org/mailman/listinfo/openssl-dev>
> 
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

[Short, Todd via openssl-dev]

Uri:

Look at https://github.com/openssl/openssl/pull/3455 
<https://github.com/openssl/openssl/pull/3455>

I limited the test that hung your machine to Linux.

Rich: this removes the OpenSSL_assert() you see.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

> On May 12, 2017, at 4:46 PM, Short, Todd via openssl-dev 
> <openssl-dev@openssl.org> wrote:
> 
> It’s trying to reserve 1<<34 bytes of memory… there goes your 16GB...
> --
> -Todd Short
> // tsh...@akamai.com <mailto:tsh...@akamai.com>
> // "One if by land, two if by sea, three if by the Internet."
> 
>> On May 12, 2017, at 4:05 PM, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu 
>> <mailto:u...@ll.mit.edu>> wrote:
>> 
>> Todd> Yes, it’s likely this is due to the amount of memory available in the 
>> machine. I tried to use reasonable values, but apparently not reasonable 
>> enough
>>  
>> Yep. In case it matters, my machine has 16GB of RAM (and runs a ton of 
>> stuff, besides these tests :).
>> -- 
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev 
>> <https://mta.openssl.org/mailman/listinfo/openssl-dev>
> 
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

[Short, Todd via openssl-dev]

It’s trying to reserve 1<<34 bytes of memory… there goes your 16GB...
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

> On May 12, 2017, at 4:05 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> Todd> Yes, it’s likely this is due to the amount of memory available in the 
> machine. I tried to use reasonable values, but apparently not reasonable 
> enough
>  
> Yep. In case it matters, my machine has 16GB of RAM (and runs a ton of stuff, 
> besides these tests :).
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev 
> 



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] 90-test_secmem.t hangs the machine for good

[Short, Todd via openssl-dev]

Yes, it’s likely this is due to the amount of memory available in the machine. 
I tried to use reasonable values, but apparently not reasonable enough.

This is certainly a case where we’re trying to stretch the limits of the 
hardware; so it may not be an appropriate test for all hardware.

In the case below, the call to mmap() failed, and there’s an OPENSSL_assert() 
there that’s probably not necessary; the error condition checked by the assert 
is handled safely.

This is different than the problem > 
was seeing, which is likely a condition where memory is being maxed out.

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On May 12, 2017, at 2:51 PM, Salz, Rich via openssl-dev 
> wrote:

Current master 1d0f116 fails on my machine.

../test/recipes/90-test_secmem.t ..
1..1
   # Subtest: ./secmemtest
   1..1
   # INFO:  @ test/secmemtest.c:65
   # Possible infinite loop: allocate more than available

   # INFO:  @ test/secmemtest.c:71
   # Possible infinite loop: small arena

   # INFO:  @ test/secmemtest.c:79
   # Possible infinite loop: 1<<31 limit

crypto/mem_sec.c:428: OpenSSL internal error: assertion failed: sh.map_result 
!= MAP_FAILED
../util/shlib_wrap.sh ./secmemtest => 134
not ok 1 - running secmemtest

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

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

Re: [openssl-dev] verify depth behavior change from 1.0.2 to 1.1.0?

[Short, Todd via openssl-dev]

Ben Kaduk:

Do we know the values that are being passed to SSL_CTX_set_Verify_depth() match 
the -verify_depth argument, or do they differ?
If they differ, do identical arguments to the function behave the same in 1.1.0 
and 1.0.2?

Viktor:

What we’re getting at here, is that this appears to be a potentially 
significant behavioral change. We want to understand it better.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Apr 3, 2017, at 4:43 PM, Viktor Dukhovni 
> wrote:


On Apr 3, 2017, at 4:26 PM, Benjamin Kaduk 
> wrote:

There was a fair amount of churn in x509_vfy.c with the inclusion
of the DANE stuff and whatnot, so it's not immediately clear to me
when this change actually happened.  I think there are good
arguments for the current 1.1.0 behavior and it doesn't really make
sense to try to change back to the historical behavior, but it would
be good to know when the change actually happened and that it is/was
a known change.  Ideally we could also document the different
behavior between 1.0.x and 1.1.0 better; any thoughts about where to
do so?

https://www.openssl.org/docs/man1.1.0/apps/verify.html

  -verify_depth num

Limit the certificate chain to num intermediate CA certificates.
A maximal depth chain can have up to num+2 certificates, since
neither the end-entity certificate nor the trust-anchor
certificate count against the -verify_depth limit.

https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_verify_depth.html

SSL_CTX_set_verify_depth() sets the maximum depth for the
certificate chain verification that shall be allowed for ctx.
(See the BUGS section.)
...
BUGS

The certificate verification depth set with SSL[_CTX]_verify_depth()
stops the verification at a certain depth. The error message
produced will be that of an incomplete certificate chain and
not X509_V_ERR_CERT_CHAIN_TOO_LONG as may be expected.

The 1.0.2 behaviour was under-documented and somewhat broken.  This
was fixed in 1.1.0.


Unfortunately, the SSL_CTX_set_verify_depth(3) was not brought up to date,
contributes welcome:

  https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_verify_depth.html

--
Viktor.

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

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

Re: [openssl-dev] TLSv1.3 draft 19 support

[Short, Todd via openssl-dev]

Thanks Matt!
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Mar 16, 2017, at 10:35 AM, Matt Caswell 
> wrote:

All,

I have just pushed to master the updates necessary for TLSv1.3 draft-19
support. This covers most of the required changes with the exception of
CertificateRequests which are waiting on PR 2918 to be merged.

Unfortunately there aren't other draft-19 implementations out there yet
(that I know of) so there has been no inter-operability testing.
Therefore I don't claim it to be bug free!! :-(

As and when other implementations come along I will test it and fix
anything we find.

The immediate impact of this is that anyone using master for testing
will find they are no longer able to negotiate TLSv1.3 with any
implementations still using draft-18 (i.e. most/all of them). To enable
people to still do that we have created a new branch "tlsv1.3-draft-18"
in the repo which was done immediately before pulling in the draft-19
changes. I plan to maintain that branch with any required draft-18
interoperability fixes for a short time.

Matt

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

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

[openssl-dev] PR 2351: Place ticket keys into secure memory

[Short, Todd via openssl-dev]

vdukhovi wrote:
I don't think this change is useful at present. Most applications run with a 
single context for the lifetime of the process, so this makes no difference. We 
(perhaps I) first need to implement automated key rotation, and only then do I 
think it make sense to worry about attempting to scrub the ticket keys.

richsalz wrote:
I undesrstand @vdukhovni's concerns. Let's 
discuss this on openssl-dev before merging this.

*discuss*
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

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