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 +, 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

Re: [openssl-dev] Participate in Code Health Tuesday (tomorrow, Feb 28th)

[Short, Todd]

I’m not sure us mere mortals can add a label to a PR...
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Feb 27, 2017, at 5:04 AM, Emilia Käsper 
> wrote:

Hi OpenSSL developers!

We’re always looking for ways to improve code quality and pay our technical 
debt. This week we thought we’d run a little experiment.

We declare this Tuesday (Feb 28th) Code Health Tuesday. We’ll be setting some 
time aside to do cleanups in the codebase. The theme is “Delete”: we’ll be 
cleaning up unused files, dead code, and obsolete hacks. We invite you all to 
participate on Github!

Cheers,
Emilia

FAQ:

Q: How do I participate?
A: Find something to delete. Create a Github pull request and add the 
“code-health” label. We’ll be monitoring Github for quick turnaround.

Q: Which branches should I target?
A: You should target master. In stable branches, code churn comes with a cost, 
so let’s focus on the next release.

Q: What can I delete?
A: Normal compatibility rules apply. You cannot delete anything from public 
headers, remove command-line tool options or prune supported platform 
configurations. You can delete dead code, obsolete workarounds (16-bit 
platforms!) and outdated documentation. If you’re not sure about a particular 
functionality, open a Github issue and add the “code health” label.

Q: Do you have any tools to find what to delete?
A: We have a coverage report: 
https://coveralls.io/github/openssl/openssl
We’ll also be setting up a tools repo where you can share any tools that you 
build.

Q: Will you do it again?
A: We hope so! This is an experiment but we’ll be looking into making it a 
habit. We have a list of ideas for themed Tuesdays lined up: Document, Test, 
Refactor, ...

Q: How did you come up with this idea?
A: We were looking at this file…
https://github.com/openssl/openssl/blob/master/crypto/pkcs7/pk7_dgst.c
--
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] Integrate EVP Cipher into OpenSSL cli Speed Test

[Short, Todd]

Look at some of the changes to pull in Poly1305 and SipHash in to EVP:

https://github.com/openssl/openssl/commit/52ad5b60e3a1fef12a1a5ea01527a90b8f92a34b
https://github.com/openssl/openssl/commit/3f5616d734a92fdf99ab827f21e5b6cab85e7194

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

On Feb 22, 2017, at 11:00 PM, Schmicker, Robert 
> wrote:


Hello,

I successfully managed to integrate an encryption cipher into the EVP and has 
been
tested to work and now I'd like to get some speed tests of the cipher using 
openssl's
integrated speed test via the command line with the "-evp" flag.

What I've done so far to try and integrate it into openssl's speed test

1) Confirmed EVP_mycipher() works

2) Noticed ./apps/speed.c was calling:
 case OPT_EVP:
 evp_cipher = EVP_get_cipherbyname(opt_arg());

3) Then modified ./crypto/objects/objects.txt to include the necessary defines
 # Mycipher
   : MYCIPHER : mycipher

4) Edited crypto/evp/c_allc.c to include my cipher in the loading of all ciphers

EVP_add_cipher(EVP_mycipher());
EVP_add_cipher_alias(SN_mycipher, "mycipher");

5) Ran a make update then make and saw all necessary defines were generated

However, the speed test cannot find my cipher because EVP_get_cipherbyname()
returns NULL.

Am I missing a step here or did I mis-configure something?

It seems as if there's something to edit to tie the NID/SN/LN_mycipher to the 
algorithm.

Any help is much appreciated!

Rob Schmicker


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

[openssl-dev] RSA_METHOD_FLAG_NO_CHECK and RSA_FLAG_EXT_PKEY?

[Short, Todd]

Hi,

The RSA_METHOD_FLAG_NO_CHECK and RSA_FLAG_EXT_PKEY seem to have similar 
meanings. These are the definitions in header files:

# define RSA_METHOD_FLAG_NO_CHECK0x0001/* don't check pub/private
* match */

/*
 * This flag means the private key operations will be handled by rsa_mod_exp
 * and that they do not depend on the private key components being present:
 * for example a key stored in external hardware. Without this flag
 * bn_mod_exp gets called when private key components are absent.
 */
# define RSA_FLAG_EXT_PKEY   0x0020

In both cases, it implies that the private key may not be present, and the code 
should not be checked against the public key.

The RSA_METHOD_FLAG_NO_CHECK is checked when setting certificates and private 
keys. The RSA_FLAG_EXT_PKEY is checked when doing RSA private key operations 
and determines whether rsa_mod_exp() or bn_mod_exp() is called.

So, my question is, should RSA_FLAG_EXT_PKEY (implying the external storage of 
the private key) also be used when setting certificates/private keys? Does it 
matter?

I’m really looking to start a discussion as to whether these flags have 
identical or very-close-to-each-other meanings.

Also, should there be an ECC_FLAG_EXT_PKEY?

This is all in reference to https://github.com/openssl/openssl/pull/2243

Thanks,

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

Re: [openssl-dev] use SIPhash for OPENSSL_LH_strhash?

[Short, Todd]

I’d be doing it in a manner similar to Poly1305, since that’s a fresh memory… 
it shouldn’t take long.
--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Jan 11, 2017, at 9:44 AM, Richard Levitte 
<levi...@openssl.org<mailto:levi...@openssl.org>> wrote:

Can we look forward to a github PR?

In message 
<97d0be2d-11c6-4d01-9a5d-faccc5b27...@akamai.com<mailto:97d0be2d-11c6-4d01-9a5d-faccc5b27...@akamai.com>>
 on Tue, 10 Jan 2017 22:42:17 +, "Short, Todd" 
<tsh...@akamai.com<mailto:tsh...@akamai.com>> said:

tshort> I think I might have an init/update/final version of siphash24 lying
tshort> around somewhere that would be compatible with OpenSSL’s EVP_PKEY
tshort> mechanism (similar to Poly1305, in that it needs a key).
tshort> --
tshort> -Todd Short
tshort> // tsh...@akamai.com<mailto:tsh...@akamai.com>
tshort> // "One if by land, two if by sea, three if by the Internet."
tshort>
tshort> On Jan 10, 2017, at 4:55 PM, Richard Levitte 
<levi...@openssl.org<mailto:levi...@openssl.org>>
tshort> wrote:
tshort>
tshort>
tshort>
tshort>
tshort> Benjamin Kaduk <bka...@akamai.com<mailto:bka...@akamai.com>> skrev: 
(10 januari 2017
tshort> 20:19:21 CET)
tshort>
tshort> On 01/10/2017 12:31 PM, Richard Levitte wrote:
tshort>
tshort>
tshort> Benjamin Kaduk 
<bka...@akamai.com<mailto:bka...@akamai.com>> skrev: (10 januari 2017
tshort> 18:48:32
tshort>
tshort>
tshort> CET)
tshort>
tshort> On 01/09/2017 10:05 PM, Salz, Rich wrote:
tshort>
tshort> Should we move to using SIPHash for the default string
tshort> hashing
tshort> function in OpenSSL? It’s now in the kernel
tshort> https://lkml.org/lkml/2017/1/9/619
tshort>
tshort>
tshort>
tshort> Heck, yes!
tshort> -Ben
tshort>
tshort>
tshort> I fail to see what that would give us. OPENSSL_LH_strhash
tshort> () is used
tshort>
tshort>
tshort> to get a reasonable index for LHASH entries. Also SIPhash
tshort> gives at
tshort> least 64 bits results, do we really expect to see large enough
tshort> hash
tshort> tables to warrant that?
tshort>
tshort>
tshort>
tshort>
tshort> We don't need to use the full output width of a good hash
tshort> function.
tshort>
tshort> My main point is, "why would we want to ignore the last 20
tshort> years of
tshort> advancement in hash function research?" Section 7 of the
tshort> siphash paper
tshort> (https://131002.net/siphash/siphash.pdf) explicitly talks
tshort> about using
tshort> it
tshort> for hash tables, including using hash table indices H(m) mod
tshort> l.
tshort>
tshort>
tshort> I agree with the advice when one can expect huge tables. The
tshort> tables we handle are pretty small (I think, please correct me if
tshort> I'm wrong) and would in all likelihood not benefit very much if at
tshort> all from SIPhash's relative safety.
tshort>
tshort> Of course, one can ask the question if someone uses LHASH as a
tshort> general purpose hash table implementation rather than just for the
tshort> stuff OpenSSL. Frankly, I would probably look at a dedicated hash
tshort> table library first...
tshort>
tshort> Cheers
tshort> Richard
tshort> --
tshort> Sent from my Android device with K-9 Mail. Please excuse my
tshort> brevity.
tshort> --
tshort> openssl-dev mailing list
tshort> To unsubscribe:
tshort> https://mta.openssl.org/mailman/listinfo/openssl-dev
tshort>
--
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] use SIPhash for OPENSSL_LH_strhash?

[Short, Todd]

I think I might have an init/update/final version of siphash24 lying around 
somewhere that would be compatible with OpenSSL’s EVP_PKEY mechanism (similar 
to Poly1305, in that it needs a key).
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Jan 10, 2017, at 4:55 PM, Richard Levitte 
> wrote:



Benjamin Kaduk > skrev: (10 januari 
2017 20:19:21 CET)
On 01/10/2017 12:31 PM, Richard Levitte wrote:

Benjamin Kaduk > skrev: (10 januari 
2017 18:48:32
CET)
On 01/09/2017 10:05 PM, Salz, Rich wrote:
Should we move to using SIPHash for the default string hashing
function in OpenSSL?  It’s now in the kernel
https://lkml.org/lkml/2017/1/9/619

Heck, yes!
-Ben
I fail to see what that would give us. OPENSSL_LH_strhash() is used
to get a reasonable index for LHASH entries. Also SIPhash gives at
least 64 bits results, do we really expect to see large enough hash
tables to warrant that?


We don't need to use the full output width of a good hash function.

My main point is, "why would we want to ignore the last 20 years of
advancement in hash function research?"  Section 7 of the siphash paper
(https://131002.net/siphash/siphash.pdf) explicitly talks about using
it
for hash tables, including using hash table indices H(m) mod l.

I agree with the advice when one can expect huge tables. The tables we handle 
are pretty small (I think, please correct me if I'm wrong) and would in all 
likelihood not benefit very much if at all from SIPhash's relative safety.

Of course, one can ask the question if someone uses LHASH as a general purpose 
hash table implementation rather than just for the stuff OpenSSL. Frankly, I 
would probably look at a dedicated hash table library first...

Cheers
Richard
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
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] Add a new algorithm in "crypto" dir, how to add the source code into the build system

[Short, Todd]

Easiest way is to fork the OpenSSL Github repo and then clone it down to your 
local machine where you can do the work locally. Once you are happy, push it 
back up to your forked Github repo, and then make a pull request back to the 
OpenSSL repo.

There are lots of places you can get information on git and Github; but this 
list isn’t one of them.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Dec 22, 2016, at 8:12 AM, Wei, Changzheng 
> wrote:

Hi,
I want to implement some new algorithm. To make my future work smoothly, I want 
to add a new algorithm method like “RSA_METHOD” in OpenSSL framework so as to I 
can use an “engine” to support such algorithm.
So I add a new subdir in “crypto” and implement the code and 
build.info refer to “crypto/rsa”.
My question is how to add my new source code into the build system?

Thanks in advance!
--
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] Still showing openssl 1.0.2 snapshot issue

[Short, Todd]

FYI: The use of -DOPENSSL_NO_BUF_FREELISTS to config or Configure is not 
recommended, use the proper configuration option:

no-buf-freelists

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

On Nov 27, 2016, at 3:11 AM, Roumen Petrov 
> wrote:

Salz, Rich wrote:
[SNIP]
I posted yesterday, what's your config. I standard config/make does not do this 
for me.
For instance:
CONFIGURE_ARGS=--prefix=... -DOPENSSL_NO_BUF_FREELISTS shared no-ssl2 no-ssl3 
zlib-dynamic enable-gost enable-unit-test linux-x86_64

Roumen

--
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] Backporting opaque struct getter/setter functions

[Short, Todd]

IANAL, but:

1. Some people see GPL or even LGPL and run away screaming.
1a. Using this means that the using the OpenSSL library requires accepting the 
LGPL.
1b. Some interpretations of the LGPL permit use when the code is in a 
dynamically-linked library. Since this is a header file, any code within is 
compiled into the program in question (not dynamically linked),  as this header 
contains inline functions, not just function declarations. Anything that uses 
it cannot be considered a “work that uses the library”, since there is no way 
for a user to substitute their own version of this header file into a 
previously compiled program.
2. Under the assumption that some of the code is likely copied from OpenSSL 
1.1.0 (because it not necessarily possible to create an identical OpenSSL 
function from said definition of it), it means that a license change occurred 
to OpenSSL code, and that is a violation of the OpenSSL license: 
https://github.com/openssl/openssl/blob/master/LICENSE 
<https://github.com/openssl/openssl/blob/master/LICENSE> specifically 
provisions #1 and #6.

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

> On Nov 8, 2016, at 7:04 AM, Hubert Kario <hka...@redhat.com> wrote:
> 
> On Monday, 7 November 2016 21:26:16 CET Short, Todd wrote:
>> The file below is LPGL 2.1, and may not be compatible with various projects.
>> Can it be changed to use the OpenSSL license or equivalent?
> 
> how LGPL may not be compatible with any project?
> 
>> --
>> -Todd Short
>> // tsh...@akamai.com<mailto:tsh...@akamai.com>
>> // "One if by land, two if by sea, three if by the Internet."
>> 
>> On Nov 3, 2016, at 4:31 PM, Douglas E Engert
>> <deeng...@gmail.com<mailto:deeng...@gmail.com>> wrote:
>> 
>> 
>> 
>> On 11/3/2016 3:11 PM, Benjamin Kaduk wrote:
>> To revitalize an old thread (quoted below but summarized here), some
>> applications may desire source-code compatibility between the 1.0.2 API and
>> the 1.1.0 API.  It seems like the sense of the team is that such accessor
>> functions (or macros) should not be committed into the official 1.0.2 tree,
>> but that the community could maintain an external compatibility shim.  Is
>> that correct?
>> 
>> Does anyone already have such a compatibility header, or thoughts about
>> where it should/could reside?
>> 
>> OpenSC has such a header file to address most of the OpenSSL functions used
>> withing OpenSC.
>> 
>> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h<
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenSC_OpenS
>> C_blob_master_src_libopensc_sc-2Dossl-2Dcompat.h=DgMDaQ=96ZbZZcaMF4w0F4j
>> pN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=xoYIrv5R7W7QHyLEdOuyz
>> FJ-b7mHMoeJeaJ6OXIq3Os=nIUo0yfKtaVnPewNDTpig52n6Mbim01ii8UnkmQwYLY=>
>> 
>> 
>> 
>> 
>> We have been noticing that a lot of accessor implementations can be
>> backported as static inline functions to a compatibility header or headers
>> with no further modification.  (But not all, as, e.g., HMAC_CTX has changed
>> to hold pointers instead of embedded structs.)
>> 
>> -Ben
>> 
>> On 01/11/2016 01:20 PM, Matt Caswell wrote:
>> 
>> On 11/01/16 18:29, Viktor Dukhovni wrote:
>> 
>> 
>> On Jan 11, 2016, at 5:23 AM, Tomas Mraz
>> <tm...@redhat.com><mailto:tm...@redhat.com> wrote:
>> 
>> On Po, 2016-01-11 at 01:09 +, Peter Waltenberg wrote:
>> 
>> 
>> The point of using accessor FUNCTIONS is that the code doesn't break
>> if the structure size or offsets of fields in the underlying
>> structures change across binaries.
>> 
>> Where that mainly has an impact is updating the crypto/ssl libs
>> underneath existing binaries is more likely to just work.
>> 
>> #defines in the headers do not help at all here.
>> 
>> 
>> 
>> The point is in achieving reverse API compatibility between 1.1 and
>> 1.0.2. No binary compatibility is expected between those branches.
>> 
>> I think that having the API compatibility would be really useful thing
>> easing porting application code to 1.1 branch.
>> 
>> 
>> Yes, although in practice may users of 1.0.x will have previous releases
>> that don't have the accessors, so the issue is difficult to address
>> retroactively in OpenSSL.  In Postfix, I add the macros myself:
>> 
>> #if OPENSSL_VERSION_NUMBER < 0x1010L
>> #define X509_up_ref(x) (CRYPTO_add(>references, 1, CRYPTO_LOCK_X509))
>> #endif
>> 
>> 

Re: [openssl-dev] Backporting opaque struct getter/setter functions

[Short, Todd]

The file below is LPGL 2.1, and may not be compatible with various projects. 
Can it be changed to use the OpenSSL license or equivalent?
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Nov 3, 2016, at 4:31 PM, Douglas E Engert 
> wrote:



On 11/3/2016 3:11 PM, Benjamin Kaduk wrote:
To revitalize an old thread (quoted below but summarized here), some 
applications may desire source-code compatibility between the 1.0.2 API and the 
1.1.0 API.  It seems like the sense of the team is that such accessor functions 
(or macros) should not be committed into the official 1.0.2 tree, but that the 
community could maintain an external compatibility shim.  Is that correct?

Does anyone already have such a compatibility header, or thoughts about where 
it should/could reside?

OpenSC has such a header file to address most of the OpenSSL functions used 
withing OpenSC.

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h




We have been noticing that a lot of accessor implementations can be backported 
as static inline functions to a compatibility header or headers with no further 
modification.  (But not all, as, e.g., HMAC_CTX has changed to hold pointers 
instead of embedded structs.)

-Ben

On 01/11/2016 01:20 PM, Matt Caswell wrote:

On 11/01/16 18:29, Viktor Dukhovni wrote:


On Jan 11, 2016, at 5:23 AM, Tomas Mraz 
 wrote:

On Po, 2016-01-11 at 01:09 +, Peter Waltenberg wrote:


The point of using accessor FUNCTIONS is that the code doesn't break
if the structure size or offsets of fields in the underlying
structures change across binaries.

Where that mainly has an impact is updating the crypto/ssl libs
underneath existing binaries is more likely to just work.

#defines in the headers do not help at all here.



The point is in achieving reverse API compatibility between 1.1 and
1.0.2. No binary compatibility is expected between those branches.

I think that having the API compatibility would be really useful thing
easing porting application code to 1.1 branch.


Yes, although in practice may users of 1.0.x will have previous releases
that don't have the accessors, so the issue is difficult to address
retroactively in OpenSSL.  In Postfix, I add the macros myself:

#if OPENSSL_VERSION_NUMBER < 0x1010L
#define X509_up_ref(x) (CRYPTO_add(>references, 1, CRYPTO_LOCK_X509))
#endif

Which means that interestingly enough adding these to 1.0.x would break
my code and similar code elsewhere.

So on the whole forward-compatibility macros don't fully address the
problem, and may do as much harm as good.

I think that applications porting to 1.1.0 can and should implement
their own macros against a stable 1.0.x API that we don't change
at the last minute.  Providing your own forward-compatible glue
is easy enough...



Perhaps someone from the community could contribute a (separately
maintained) compatibility layer to provide the relevant macros?

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






--

 Douglas E. Engert  



--
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] Input on renegotiation behaviour

[Short, Todd]

+1 for making DTLS behavior like TLS in terms of attempting an abbreviated 
handshake. (2)
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Sep 29, 2016, at 4:40 AM, Matt Caswell 
> wrote:



On 28/09/16 21:40, Benjamin Kaduk wrote:
On 09/28/2016 03:27 AM, Matt Caswell wrote:
The current behaviour is not *wrong* either for TLS or DTLS, but the
discrepancy is quite weird and confusing. Should we:

1) Change TLS to behave like it used to, and like DTLS still does

2) Change DTLS to be consistent with the TLS behaviour

3) Keep it as it is and retain the current inconsistency

And if we change things, should we just change it in the current dev
branch - or backport it as a bug fix?

Thoughts?


I don't think any change should be backported --it's potentially
disruptive, and if the behavior (change) has gone unnoticed for so long,
it hardly seems urgent to normalize between DTLS and TLS.

It seems like the abbreviated handshake would save some computational
resources; on the flip side, it would not have the opportunity for a
fresh DH exchange to stir the key material.  If anything, that would
almost suggest a

(4) change DTLS to default to abbreviated handshakes and change TLS to
default to normal handshakes

since the DTLS server could be sending a HelloRequest because it had to
dump state, but the TLS/TCP connection is persistent and the potential
need for key update greater there.

That said, I do prefer consistency between DTLS and TLS, so would lean
towards option (2), myself, for the resource savings.

Thanks Ben. Option 2 still gives the server the opportunity to not
resume the session if it so wishes (and in the scenario we are talking
about the server has initiated this), so perhaps that is the more
flexible route anyway.

Any one else have any thoughts on this?

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

Re: [openssl-dev] Openssl upgrade in debian

[Short, Todd]

You need to do this on your own (get the toolchain), and/or get updates from 
Debian.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Sep 23, 2016, at 7:21 AM, Shantibhushan Sale 
> wrote:

I am a student developing some tool w.r.t openssl on DEBIAN.Currently my 
configuration of system is :
Kernel:2.6.28.10.
Openssl:1.0.1e
system:ARMv5

Now i have to upgrade openssl version to Openssl 1.0.1t or higher.I do not have 
toolchain with me.
I would need all binaries which used openssl1.0.1h for above installation.How 
can i proceed to this?

Please help me on this.I need all the depending libraries/packages w.r.t 
1.0.1t. Those are:
1.Libencryption.
2.openssh,
3.ntp,
4.ping6,
5.stunnel,
6.openldap

Please help me here to solve this.

--

Regards
Shantibhushan Sale
9545534899
Pune

--
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] [openssl-users] Building OpenSSL 1.0.1t without tls1.1 support?

[Short, Todd]

1.0.1 is old, and not really supported, except some security fixes.
1.0.x does not provide the ability to compile out TLSv1.0 from 1.1 from 1.2.
The upcoming 1.1.x does.

If you disable tls1, then you’ve also disabled all later versions, so enable 
tlsv1 at config time and use the SSL options to enable/disable the protocols at 
run time.

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

On Aug 22, 2016, at 3:08 PM, Scott Neugroschl 
> wrote:


I’ve done a custom build of OpenSSL where I ran Configure with “no-ssl2” and 
“no-ssl3”.  I’d like to disable TLS1 and 1.1 if possible.  Will the no-tls1 
option disable just TLS1 or all TLS1.x protocols?

Thanks,

ScottN



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

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

Re: [openssl-dev] DRBG entropy

[Short, Todd]

See:

https://tools.ietf.org/html/rfc4086

Section 4 suggests ways to de-skew.

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

> On Jul 28, 2016, at 6:51 AM, Hubert Kario  wrote:
> 
> On Wednesday, 27 July 2016 15:23:21 CEST Leon Brits wrote:
>> John,
>> 
>> Thanks for your reply.
>> 
>> The SP800-90B test has different types of test but the test with the lowest
>> output is used as the maximum entropy capability of the chip. That is how I
>> understand it from the FIPS lab.
>> 
>> For the FIPS validation, using a NDRNG, that source must feed the DRBG
>> directly (FIPS lab) and not from something like the PRNG. I use seed the
>> /dev/random from the NDRNG and then source from the PRNG, but that is not
>> allowed for DRBGs. Again I hope I understand them correct.
> 
> but PRNG and DRBG is the same thing, both generate pseudo-random numbers from
> a seed using (hopefully) a cryptographically secure algorithm
> 
> FIPS definitely allows you to use output of one DRBG to seed other DRBG
> 
> in the end, you should gather as much entropy as possible in the system, and
> mix it all together and then use output of a DRBG that uses all that entropy
> to seed other DRBGs
> 
> what that means in practical terms, is feed output from your NDRNG to kernel's
> entropy pool and seed everything from /dev/urandom output (or getrandom())
> 
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic--
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Auth and cipher ordering in AEAD ciphers

[Short, Todd]

AEAD ciphers within OpenSSL include AES-GCM, AES-CCM and ChaCha20-Poly1305 
(among others). AES-128 CBC SHA1-HMAC is not considered AEAD.

See 
https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption 
for examples.

The ciphers as described below are meant for TLS, thus they do MAC-then-Encrypt 
(MtE), although there is an EtM TLS extension.

You will need to use either individual crypto operations to do what you want, 
if the combinations offered by OpenSSL differ from the standards (e.g. IPSec) 
that you need to follow.

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

On Jul 5, 2016, at 6:28 AM, Nikhil Agarwal 
> wrote:

For AEAD ciphers like NID_aes_128_cbc_hmac_sha1,  I could not find any control 
interface defined to control authentication and cipher ordering.(i.e. whether 
to perform cipher first and then authentication or vice versa.(IPSEC vs. TLS 
use-case)).  If such an interface exist with OPENSSL can someone please help me 
in pointing that out? If no, is there any plan to introduce it? Also is there 
any interface for to specify difference packet range/length for cipher in Auth 
in AEAD case?

Thanks in advance
Nikhil

--
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] [openssl.org #3868] [PATCH] Add SSL_get0_peer_certificate()

[Short, Todd via RT]

Not strictly necessary; mostly convenience. Decrementing the pointer usually 
requires doing the corresponding  free, which really shouldn’t do anything but 
decrement the refcount if you just got it.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Jun 20, 2016, at 12:18 PM, Rich Salz via RT 
> wrote:

Is this needed? Can your get0 function just call get and decrement the
refcount?

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3868
Please log in as guest with password guest if prompted



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3868
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #3882]

[Short, Todd via RT]

Based on discussion, it does not appear as this will be fixed, and requires an 
unusual set of circumstances for it to happen.
It can probably be closed.

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


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3882
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #3780]

[Short, Todd via RT]

The async changes on master/1.1.0 obsolete this patch.

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


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3780
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #3722]

[Short, Todd via RT]

This could be closed, as it’s now on GitHub: 
https://github.com/openssl/openssl/pull/946
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3722
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #3867]

[Short, Todd via RT]

This could be closed, as it’s now on GitHub: 
https://github.com/openssl/openssl/pull/941
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3867
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #3877]

[Short, Todd via RT]

This could be closed, as it’s now on GitHub: 
https://github.com/openssl/openssl/pull/941
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3877
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #3729]

[Short, Todd via RT]

The changes to master/1.1.0 for pipelining completely break this patch. So, 
there’s little point in trying to add this.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3729
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #3724]

[Short, Todd via RT]

The new async feature in master/1.1.0 makes complete breaks this patch. This 
can probably be closed.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3724
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4074] [PATCH] Fixes for when PSK, SRP, SRTP and DTLS1 are disabled

[Short, Todd via RT]

This has been resolved master, and can be closed.

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


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4074
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4149] Resolved: [PATCH] ssl_set_pkey() unnecessarily updates certificates

[Short, Todd via RT]

I also closed out GH478 (which was a fix for RT4149).
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On May 31, 2016, at 9:29 AM, Matt Caswell via RT 
> wrote:

According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4149
Please log in as guest with password guest if prompted



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4149
Please log in as guest with password guest if prompted

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

[openssl-dev] master failing unit tests inconsistently?

[Short, Todd]

Hi openssl-dev:

I’ve been running the master branch and have been noticing inconsistant unit 
tests results. It is failing on a number of tests, and has been for several 
days. I’m using clang-3.6 (3.6.0-2ubuntu1~trust1) or gcc 
(4.84-2ubuntu1~14.04.01) on Linux 3.13-0-85-generic #129-Ubuntu.

This is one sample:

../test/recipes/70-test_sslcertstatus.t  Failed 1/1 subtests
../test/recipes/70-test_sslextension.t . Failed 2/3 subtests
../test/recipes/70-test_sslsessiontick.t ... Failed 9/10 subtests
../test/recipes/70-test_sslskewith0p.t . (hangs)

OR

Test Summary Report
---
../test/recipes/70-test_sslextension.t   (Wstat: 13 Tests: 2 Failed: 0)
  Non-zero wait status: 13
  Parse errors: Bad plan.  You planned 3 tests but ran 2.
../test/recipes/70-test_sslsessiontick.t (Wstat: 13 Tests: 1 Failed: 0)
  Non-zero wait status: 13
  Parse errors: Bad plan.  You planned 8 tests but ran 1.
../test/recipes/70-test_sslvertol.t  (Wstat: 13 Tests: 0 Failed: 0)
  Non-zero wait status: 13
  Parse errors: Bad plan.  You planned 2 tests but ran 0.
../test/recipes/70-test_tlsextms.t   (Wstat: 13 Tests: 1 Failed: 0)
  Non-zero wait status: 13
  Parse errors: Bad plan.  You planned 9 tests but ran 1.
Files=78, Tests=417, 107 wallclock secs ( 0.65 usr  0.08 sys + 93.02 cusr 14.76 
csys = 108.51 CPU)
Result: FAIL
Failed 4/78 test programs. 0/417 subtests failed.
make: *** [tests] Error 255

Is anyone else seeing this?

It seems related to 
https://github.com/openssl/openssl/commit/7ad5fb6267e9da1634998bf2eccaa753f443fa83

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

Re: [openssl-dev] [openssl-users] Problems with OpenSSL 1.0.2 h

[Short, Todd]

Have you tried to configure this cipher at the top of your cipher list 
initially with SSL_OP_SERVER_CIPHER_PREFERENCE?

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

On May 4, 2016, at 12:04 PM, Benjamin Kaduk 
> wrote:

Hello,

On 05/04/2016 05:21 AM, Dirk Menstermann wrote:
Hi,

I've trouble with the newest OpenSSL as I'm operating a webserver application
that answers with HTTP1.x and HTTP2.

I registered the ALPN callback and in this the cipher list was adjusted
"SSL_set_cipher_list (ssl, "ECDHE-RSA-AES128-GCM-SHA256")" if H2 was negotiated.

With versions < OpenSSL 1.0.2h this works, but now it seems that this cipher
selection will be ignored, resulting in using a cipher that is black listed for
HTTP2 (Firefox and Chrome refuse to connect)

Was there an indented change or is there an official way to select the cipher
based on the ALPN extension value?


There was an intended change to the order in which ALPN extensions were
processed, see
https://github.com/openssl/openssl/commit/af2db04c9979554ada88d969da6332a827a47599
-- ALPN is now processed after SNI, since the ALPN callback is attached
to the SSL_CTX, and SNI processing is likely to swap out the SSL_CTX in
use.  It does look like "late" TLS extensions are now handled after
cipher selection, so the ALPN callback can no longer affect the
negotiated cipher.

Even at the specification level, how all the TLS extensions are supposed
to interact with each other and the rest of the handshake is not
terribly well specified, so adding -dev to discuss what the desired
behavior actually is.

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

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

Re: [openssl-dev] [openssl.org #4509] ECC key generation under valgrind reports: impossible has happened

[Short, Todd via RT]

Valgrind does not necessarily support all instructions, if there’s any 
optimized assembly, you might run into problems.
Are you able to compile a non-assembly version of the OpenSSL library?
Are you able to update to a newer Valgrind?

You also seem to have a version discrepancy in OpenSSL: 1.0.2d-fips and 1.0.2g?
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Apr 12, 2016, at 9:41 AM, Nikos Mavrogiannopoulos via RT 
> wrote:

A part of the gnutls test suite runs under valgrind, and in fedora 23
it occasionally fails, something that I have traced it to softhsm
library and particular hardware.

The failures are due to the softhsm library which uses openssl
underneath and in particular EC key generation. This can be reproduced
using only the openssl tools:

$ openssl version
OpenSSL 1.0.2d-fips 9 Jul 2015

$ valgrind openssl genpkey -algorithm ec  -pkeyopt ec_paramgen_curve:P-256

vex: the `impossible' happened:
   isZeroU
vex storage: T total 270175784 bytes allocated
vex storage: P total 640 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

[...]

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 28037)
==28037==at 0x5B14C80: ecp_nistz256_avx2_select_w7 (in 
/usr/lib64/libcrypto.so.1.0.2g)
==28037==by 0x5AFA92F: EC_POINT_mul (in /usr/lib64/libcrypto.so.1.0.2g)
==28037==by 0x5AF9876: EC_POINT_new (in /usr/lib64/libcrypto.so.1.0.2g)
==28037==by 0x5B02835: EC_KEY_generate_key (in 
/usr/lib64/libcrypto.so.1.0.2g)
==28037==by 0x5B51B82: EVP_PKEY_keygen (in /usr/lib64/libcrypto.so.1.0.2g)
==28037==by 0x436A29: ??? (in /usr/bin/openssl)
==28037==by 0x41A457: ??? (in /usr/bin/openssl)
==28037==by 0x41A0D6: ??? (in /usr/bin/openssl)
==28037==by 0x62B357F: (below main) (libc-start.c:289)


This may be a bug in valgrind, or according to some valgrind posts,
caused by an illegal instruction. Thus reported here.


The failed system is:
model name : Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 
sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida arat 
epb pln pts dtherm intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase 
tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt


originally at: https://bugzilla.redhat.com/show_bug.cgi?id=1326024


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4509
Please log in as guest with password guest if prompted

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


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4509
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] need clarification on openssl s_server s_client applications

[Short, Todd]

DTLS standard: DTLS does not permit fragmentation of the data (handshaking has 
it’s own fragmentation mechanism separate from the record layer).

See https://tools.ietf.org/html/rfc4347#section-4.2.3

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

On Apr 13, 2016, at 9:11 AM, balaji marisetti 
> wrote:

Hi,

When I try to send any data > MTU (1500) from s_server/client
applications (in DTLS mode), I see an error (errno:90) on the sender
side. Is it normal? Is it a limitation of the s_server/client
applications or the OpenSSL implementation or the DTLS standard
itself?

I'm using Openssl-1.0.2g on Ubuntu-14.04


Thanks,
Balaji M
--
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] 1.1.0-pre4: ALPN mismatch terminates connection

[Short, Todd]

The change was actually introduced earlier (see: 
https://github.com/openssl/openssl/commit/0621786).

GH891 
(https://github.com/openssl/openssl/commit/817cd0d52f0462039d1fe60462150be7f59d2002)
 moved the ALPN processing later so that the SSL_CTX determined from SNI can be 
used, rather than the original SSL_CTX.

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

On Mar 17, 2016, at 6:28 AM, Christian Heimes 
> wrote:

On 2016-03-17 11:08, Christian Heimes wrote:
Hi,

I think I found a regression in 1.1.0-pre4's ALPN code.

And here is a fix: https://github.com/openssl/openssl/pull/891


--
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] make depend issue: if [ Makefile -nt Makefile ]

[Short, Todd]

Never mind then! :)
--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Mar 8, 2016, at 4:01 PM, Richard Levitte 
<levi...@openssl.org<mailto:levi...@openssl.org>> wrote:

I suggest reading the comment just above depend:, especially this:

   # To check if test has the file age comparison operator, we
   # simply try, and rely test to exit with 0 if the comparison
   # was true, 1 if false, and most importantly, 2 if it doesn't
   # recognise the operator.

Comparing Makefile with Makefile is because...  well, it's as good a
file as any, and since the result from the operation itself isn't the
important part on that line, a bit of Makefile narcissism can't hurt
;-)

Cheers,
Richard

In message 
<1b05c047-cb6d-4082-8c8f-b5820d22a...@akamai.com<mailto:1b05c047-cb6d-4082-8c8f-b5820d22a...@akamai.com>>
 on Tue, 8 Mar 2016 20:57:07 +, "Short, Todd" 
<tsh...@akamai.com<mailto:tsh...@akamai.com>> said:

tshort> Hi,
tshort>
tshort> I noticed the following oddity in commit f8d9d6e:
tshort>
tshort> depend:
tshort> @catdepends=false; \
tshort> if [ Makefile -nt Makefile ] 2>/dev/null || [ $$? = 1 ]; then \
tshort>
tshort> I’m not sure of the intent or the fix, but it doesn’t seem right to
tshort> compare the timestamp of a file to itself.
tshort>
tshort> --
tshort> -Todd Short
tshort> // tsh...@akamai.com<mailto:tsh...@akamai.com>
tshort> // "One if by land, two if by sea, three if by the Internet."
tshort>
--
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] make depend issue: if [ Makefile -nt Makefile ]

[Short, Todd]

Hi,

I noticed the following oddity in commit f8d9d6e:

depend:
@catdepends=false; \
if [ Makefile -nt Makefile ] 2>/dev/null || [ $$? = 1 ]; then \

I’m not sure of the intent or the fix, but it doesn’t seem right to compare the 
timestamp of a file to itself.

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

Re: [openssl-dev] ALPN and SNI callbacks in 1.0.2

[Short, Todd]

Hi,

I created pull request to reorder SNI/ALPN processing, such that ALPN occurs 
after SNI. Since SNI may change the SSL_CTX, and the ALPN callback is defined 
on the SSL_CTX, it makes sense to allow SNI to possibly update the SSL_CTX, and 
then do ALPN processing (possibly for a new virtual server).

https://github.com/openssl/openssl/pull/787
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Mar 3, 2016, at 2:33 PM, Short, Todd <tsh...@akamai.com> wrote:

We’ve run into an issue with the ALPN and SNI TLS extension callbacks in 1.0.2. 
The same behavior may be in master, but I have yet to check.

In summary, the ALPN selection callback is invoked before the SNI/servername 
callback, yet the ALPN value returned may be dependent on the server being 
connected to. In other words, ALPN may be broken for virtual servers.

There’s a comment in ssl_parse_clienthello_tlsext() that clearly states:

   /*
* Internally supported extensions are parsed first so SNI can be handled
* before custom extensions. An application processing SNI will typically
* switch the parent context using SSL_set_SSL_CTX and custom extensions
* need to be handled by the new SSL_CTX structure.
*/

There are 4 functions that handle TLS extensions, and are invoked in the 
following order

ssl_scan_clienthello_tlsext()
* saves servername
* saves ec_point_formats
* saves elliptic_curve list
* saves opaque PRF input
* calls session ticket callback
* saves status request
* saves heartbeat
* notes NPN seen
* calls ALPN callback

ssl_check_clienthello_tlsext_early()
* calls servername callback
* calls PRF callback

ssl_scan_clienthello_custom_tlsext()
* parses custom extensions

ssl_check_clienthello_tlsext_late()
* calls status callback

I would argue that ALPN data should be saved in ssl_scan_clienthello_tlsext() 
and processed in ssl_check_clienthello_tlsext_early() - after the servername 
callback

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

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

[openssl-dev] ALPN and SNI callbacks in 1.0.2

[Short, Todd]

We’ve run into an issue with the ALPN and SNI TLS extension callbacks in 1.0.2. 
The same behavior may be in master, but I have yet to check.

In summary, the ALPN selection callback is invoked before the SNI/servername 
callback, yet the ALPN value returned may be dependent on the server being 
connected to. In other words, ALPN may be broken for virtual servers.

There’s a comment in ssl_parse_clienthello_tlsext() that clearly states:

/*
 * Internally supported extensions are parsed first so SNI can be handled
 * before custom extensions. An application processing SNI will typically
 * switch the parent context using SSL_set_SSL_CTX and custom extensions
 * need to be handled by the new SSL_CTX structure.
 */

There are 4 functions that handle TLS extensions, and are invoked in the 
following order

ssl_scan_clienthello_tlsext()
* saves servername
* saves ec_point_formats
* saves elliptic_curve list
* saves opaque PRF input
* calls session ticket callback
* saves status request
* saves heartbeat
* notes NPN seen
* calls ALPN callback

ssl_check_clienthello_tlsext_early()
* calls servername callback
* calls PRF callback

ssl_scan_clienthello_custom_tlsext()
* parses custom extensions

ssl_check_clienthello_tlsext_late()
* calls status callback

I would argue that ALPN data should be saved in ssl_scan_clienthello_tlsext() 
and processed in ssl_check_clienthello_tlsext_early() - after the servername 
callback

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

Re: [openssl-dev] [openssl.org #3716] Patch for setting preferred cipher list

[Short, Todd via RT]

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


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3716
Please log in as guest with password guest if prompted

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

[openssl-dev] RT4265 no-srtp still broken

[Short, Todd]

Configuring the master branch with no-srtp is still broken.

This PR: https://github.com/openssl/openssl/pull/582 fixes it. Its a bit out of 
date, but there shouldn’t be any conflicts.

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

[openssl-dev] 3DES is a HIGH-strength cipher?

[Short, Todd]

Hi,

In OpenSSL 1.0.2, and 1.0.1i, 3DES-CBC’s bit-strength was changed from 168 to 
112, which makes sense. However, it is still considered a HIGH-strength cipher.

RC4 is listed as having a bit strength of MEDIUM, and is a 128-bit strength 
cipher (kinda).

This is a bit contradictory. According to the OpenSSL cipher documentation, 
HIGH refers to 128-bit, or stronger, ciphers.

Should 3DES ciphers be moved to the MEDIUM category?

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

Re: [openssl-dev] 3DES is a HIGH-strength cipher?

[Short, Todd]

So, if it’s “mandatory”, then it should be in the default set of ciphers, not 
necessarily the “HIGH” set.

I’m selecting “HIGH” because I want 128-bit+ ciphers, not a cipher that that 
has subsequently found to be weaker than previously thought.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Feb 12, 2016, at 3:36 PM, Viktor Dukhovni 
> wrote:


On Feb 12, 2016, at 3:15 PM, Salz, Rich 
> wrote:

So is RC4 and we don't see that as HIGH. HIGH implies strength, not MTI-ness.

Now let's not make stuff up:

http://tools.ietf.org/html/rfc5246#section-9

9.  Mandatory Cipher Suites

  In the absence of an application profile standard specifying
  otherwise, a TLS-compliant application MUST implement the cipher
  suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5  for the
  definition).

http://tools.ietf.org/html/rfc4346#section-9

9. Mandatory Cipher Suites

  In the absence of an application profile standard specifying
  otherwise, a TLS compliant application MUST implement the cipher
  suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.

http://tools.ietf.org/html/rfc2246#section-9

9. Mandatory Cipher Suites

  In the absence of an application profile standard specifying
  otherwise, a TLS compliant application MUST implement the cipher
  suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

Since many users enable just HIGH ciphers, they must not exclude the MTI
ciphers.

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

[openssl-dev] Duplicate APIs?

[Short, Todd]

Hi,

I know OpenSSL is making 1.1 not ABI compliant to 1.0, so, maybe now is a good 
time to clean this up?

I noticed that:

* SSL_cache_hit(SSL*), and
* SSL_session_reused(SSL*ssl) --> 
SSL_ctrl(ssl,SSL_CTRL_GET_SESSION_REUSED,0,NULL)

are practically the same thing; both return s->hit.

Are both really needed?
--
-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

Re: [openssl-dev] [openssl.org #1979] Add uClibc support

[Short, Todd via RT]

OpenSSL is generally able to compile with the musl C library (same idea as 
uClibc):

OpenSSL 1.0.2f:
./config
make depend
CC=/usr/local/bin/musl-gcc ./config
make

./config is run twice, because "make depend" fails since domd can’t find the 
makedepend command after CC is set to musl-gcc. However, after running ./config 
a second time (to update the CC), the make succeeds. openssl loads and run. If 
musl is configured with --disable-shared, then it does not require any dynamic 
executables.

master:
CC=/usr/local/bin/musl-gcc ./config
make depend
make
"make depend" succeeds in master, even after CC is set to musl-gcc. But linking 
fails due to setcontext, getcontext and makecontext being undefined. They 
appear to be used by the async code; there doesn’t seem to be a way to turn off 
async (or force NULL async). I looked in the musl library, and there are 
declarations of these functions()s, but no definitions.

A maintainer of the musl library has indicated that these are deprecated Posix 
APIs. Might there be a way to disable the use of these APIs, and permit only 
async_none so that these other libraries (uClibc and musl) could be used 
instead?

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

On Feb 3, 2016, at 9:00 PM, Salz, Rich via RT 
> wrote:

This might be interesting to support, but unfortunately nobody looked at the
bug in years and the build process has changed a great deal. If you could
re-integrate this against what's in master, we'd look at it. If that's too much
work, I understand. We don't have/use this particular run-time environment.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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



-
http://rt.openssl.org/Ticket/Display.html?id=1979

Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #1979] Add uClibc support

[Short, Todd via RT]

FYI: The rational for why these APIs are deprecated.
http://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html#tag_03_356_08

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



-
http://rt.openssl.org/Ticket/Display.html?id=1979

Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #3885] [BUGFIX] OpenSSL fails to cross-compile on 32-bit->64-bit

[Short, Todd via RT]

I have an available fix:

https://github.com/openssl/openssl/pull/597

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

Re: [openssl-dev] [openssl.org #4279] openssl-1.1.0-pre2 make failes on Solaris10 x64

[Short, Todd]

This sounds like RT3885.

I have an available fix:

https://github.com/openssl/openssl/pull/597

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

On Jan 29, 2016, at 12:04 PM, Viktor Dukhovni via RT 
> wrote:


On Jan 29, 2016, at 4:59 AM, Kiyoshi KANAZAWA via RT 
> wrote:

cc -I.. -I../.. -I../modes -I../include -I../../include  -DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xarch=generic64 -xstrconst -Xa 
-DL_ENDIAN -DFILIO_H -xO5 -xdepend -xbuiltin -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM 
-DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c  -o ghash-x86_64.o 
ghash-x86_64.s
cc: Warning: -xarch=generic64 is deprecated, use -m64 to create 64-bit programs
Assembler:
   "ghash-x86_64.s", line 890 : Syntax error
   Near line: "movq$1.15473355479995e+19,%rax"

You'll need a 64-bit Perl.  When I try "perl ghash-x86_64.pl" I get:

...
   subq$48,%rcx
   movq$11547335547999543296,%rax
   movdqu  48(%rsi),%xmm14
   movdqu  64(%rsi),%xmm15
...

--
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] [openssl.org #4279] openssl-1.1.0-pre2 make failes on Solaris10 x64

[Short, Todd via RT]

This sounds like RT3885.

I have an available fix:

https://github.com/openssl/openssl/pull/597

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

On Jan 29, 2016, at 12:04 PM, Viktor Dukhovni via RT 
> wrote:


On Jan 29, 2016, at 4:59 AM, Kiyoshi KANAZAWA via RT 
> wrote:

cc -I.. -I../.. -I../modes -I../include -I../../include  -DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xarch=generic64 -xstrconst -Xa 
-DL_ENDIAN -DFILIO_H -xO5 -xdepend -xbuiltin -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM 
-DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c  -o ghash-x86_64.o 
ghash-x86_64.s
cc: Warning: -xarch=generic64 is deprecated, use -m64 to create 64-bit programs
Assembler:
   "ghash-x86_64.s", line 890 : Syntax error
   Near line: "movq$1.15473355479995e+19,%rax"

You'll need a 64-bit Perl.  When I try "perl ghash-x86_64.pl" I get:

...
   subq$48,%rcx
   movq$11547335547999543296,%rax
   movdqu  48(%rsi),%xmm14
   movdqu  64(%rsi),%xmm15
...

--
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] [openssl.org #4271] Enhancement Request: Support TCP Fast Open

[Short, Todd]

However, we’re talking about botnets. They do bad things, they don’t follow the 
rules. They can masquerade as the original sender and send additional data.

The received data held ought to be limited to the initial window of the 
connection, AND, since these are all original SYNs (pun intended) the server 
receiving the data ought to only be saving one packet worth of data (i.e. TFO 
queue), since the first data pack should be repeated (because it’s the initial 
data on the connection) on subsequent SYNs on the to-be established connection.

So, the problem isn’t other members of the botnet receiving cookies, because 
they can’t exceed the TFO queue, but multiple members of the botnet doing TFO 
on their own, and not responding to the SYN-ACK, potentially opening up 
thousands of embryonic sockets with thousands of bytes of data, which is what 
the original SYN-cookies were meant to prevent in the first place.

Regardless, this can happen with or without OpenSSL support, and any server 
that supports TFO is “Asking For Trouble”, IMHO.

While I personally don’t think that TFO should be supported anywhere for 
security reasons (it is “experimental”), there’s no reason to not support it in 
in OpenSSL.

On the other hand, if someone really wanted to support this, they could write 
their own BIO.

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

On Jan 27, 2016, at 2:32 PM, Viktor Dukhovni 
> wrote:

On Wed, Jan 27, 2016 at 07:20:04PM +, Salz, Rich wrote:

Please explain.  The traffic can only come from the party who initially obtains
the cookie in a full round-trip.  How does the botnet DoS some third party
with this?

Attacker wants to bring down an akamai host.  They connect to one of our
servers with the fast-open option and get the cookie.  They then spread
that cookie all over the internet and zillions of bots connect.

The connections need to be from the attacker's original IP address that
obtained the cookie.

Our server
spawns zillions of threads and starts to do some work, or the TCP queue
fills up.  I can't filter on IP address to stop the attack because the
client IP address is bogus.

The client IP address is not entirely "bogus", it is the IP address
of the client that obtained the cookie, otherwise the cookie is
not valid.  Block sending cookies to sources whose cookies are
abused.

Also note that the TFO queue length is limited, and most requests
will require a full round-trips when the request volume is high.

Anyway, this is not the right forum for TFO threat analysis that
has nothing to do with SSL.  We should add client-side support
for TFO.

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

[openssl-dev] [openssl.org #4272] [BUG/PATCH] Unit tests fail when DTLS is disabled

[Short, Todd via RT]

Hello:

When DTLS is disabled in master (./config no-dtls) the corresponding unit tests 
fail. The same thing would happen if TLS were disabled. The issue is in the 
’TLS Version min/max tests’ and DTLS Version min/max tests’. The skip function 
is not called within a SKIP: { } block, causing the tests to fail unexpectedly 
by “skipping” the planned test, and then doing another test (i.e. ok()) later.

I have a patch, but I am waiting for the RT number.
--
-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

Re: [openssl-dev] [openssl.org #4272] [BUG/PATCH] Unit tests fail when DTLS is disabled

[Short, Todd via RT]

Pull request for RT4272:

https://github.com/openssl/openssl/pull/589
--
-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

Re: [openssl-dev] [openssl.org #4265] [BUG/PATCH] OpenSSL does not compile when SRTP is disabled

[Short, Todd via RT]

Apologies, apparently I already reported this problem ~5 weeks ago as RT4188. 
So, RT4188 and RT4265 are duplicates.

However, the latest pull request is : 
https://github.com/openssl/openssl/pull/582

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

On Jan 22, 2016, at 10:00 AM, Short, Todd via RT 
<r...@openssl.org<mailto:r...@openssl.org>> wrote:

Hello,

When SRTP is disabled, OpenSSL does not successfully compile due to an error in 
s_server.c

I have a patch for this, I am just waiting for the RT to be created first.
--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com><mailto: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


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

[openssl-dev] [openssl.org #4265] [BUG/PATCH] OpenSSL does not compile when SRTP is disabled

[Short, Todd via RT]

Hello,

When SRTP is disabled, OpenSSL does not successfully compile due to an error in 
s_server.c

I have a patch for this, I am just waiting for the RT to be created first.
--
-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

[openssl-dev] [openssl.org #4262] Fwd: Configure script warns when no configurations changes occur

[Short, Todd via RT]

Hello,

When ./config is run, the Configure script always complains about 'make depend’ 
needing to be run because the $default_depflags and $depflags do not match.
Recent changes to Configure automatically create $default_depflags, but takes 
special exceptions for shared, zip, hw and asm, which are not normally put into 
$default_depflags but are put into |$depflags| causing a mismatch leading to 
the warning.

I have a patch, but am waiting for the RT to be created first.
--
-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

Re: [openssl-dev] [openssl.org #4262] Fwd: Configure script warns when no configurations changes occur

[Short, Todd via RT]

Added pull request:

https://github.com/openssl/openssl/pull/578

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

On Jan 21, 2016, at 4:11 PM, Short, Todd via RT 
<r...@openssl.org<mailto:r...@openssl.org>> wrote:

Hello,

When ./config is run, the Configure script always complains about 'make depend’ 
needing to be run because the $default_depflags and $depflags do not match.
Recent changes to Configure automatically create $default_depflags, but takes 
special exceptions for shared, zip, hw and asm, which are not normally put into 
$default_depflags but are put into |$depflags| causing a mismatch leading to 
the warning.

I have a patch, but am waiting for the RT to be created first.
--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com><mailto: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


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

[openssl-dev] [openssl.org #4263] store does not compile with opaque data structures

[Short, Todd via RT]

Hello,

When experimental-store is enabled in the master branch, the compile fails, due 
to structures that are now opaque.

I have a patch, but am waiting for the RT to be created first.
--
-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

Re: [openssl-dev] [openssl.org #4263] store does not compile with opaque data structures

[Short, Todd via RT]

I added a pull request:

https://github.com/openssl/openssl/pull/579

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

On Jan 21, 2016, at 4:23 PM, Short, Todd via RT 
<r...@openssl.org<mailto:r...@openssl.org>> wrote:

Hello,

When experimental-store is enabled in the master branch, the compile fails, due 
to structures that are now opaque.

I have a patch, but am waiting for the RT to be created first.
--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com><mailto: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


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

[openssl-dev] [openssl.org #4206] [PATCH] Add cipher alias for ChaCha20

[Short, Todd via RT]

Updated patch for RT4206, with updated names from draft -04.




0001-Add-CHACHA20-alias-for-ciphers.patch
Description: Binary data

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

On Jan 6, 2016, at 7:46 AM, Hubert Kario via RT <r...@openssl.org> wrote:On Monday 28 December 2015 15:28:26 Kurt Roeckx via RT wrote:On Mon, Dec 28, 2015 at 03:01:28PM +0000, Short, Todd via RT wrote:Hello OpenSSL.org<http://OpenSSL.org>:This is a patch for the master branch. The changes in master to addChaCha20 to OpenSSL do not include an alias for the cipher in the"openssl cipher" command, nor in the cipher functions., even thoughthe necessary constants have been defined. The attached patch addsthat alias.The following openssl commands now behave as expected:openssl ciphers CHACHA20openssl ciphers CHACHA20:AESPlease at least also update the documentation, like ciphers.pod.I'm also not sure if CHACHA20 should only select those incombination with Poly1305, even if those are currently the onlysupported.AES selects both AES-CBC and AES-GCM while AESGCM selects just AES-GCM.Selecting ChaCha20-Poly1305 by just CHACHA20 is consistent with existing flags.-- Regards,Hubert KarioSenior Quality Engineer, QE BaseOS Security teamWeb: www.cz.redhat.comRed Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4206] [PATCH] Add cipher alias for ChaCha20

[Short, Todd via RT]

Hello OpenSSL.org:

This is a patch for the master branch. The changes in master to add ChaCha20 to 
OpenSSL do not include an alias for the cipher in the “openssl cipher” command, 
nor in the cipher functions., even though the necessary constants have been 
defined. The attached patch adds that alias.

The following openssl commands now behave as expected:

openssl ciphers CHACHA20
openssl ciphers CHACHA20:AES

Thanks,

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



0002-Add-CHACHA20-alias-for-ciphers.patch
Description: Binary data
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4206] [PATCH] Add cipher alias for ChaCha20

[Short, Todd via RT]

Updated patch. Updates documentation (ciphers.pod), and lays some groundwork in 
case ChaCha20 is used with something other than Poly1305.

(Also updates the Camellia cipher alias to use an existing #define.)

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




0002-Add-CHACHA20-alias-for-ciphers.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4206] [PATCH] Add cipher alias for ChaCha20

[Short, Todd]

True, but there’s currently no flag defined for just “ChaCha20” ciphers, just 
SSL_CHACHA20POLY1305. My understanding is that CHACHA20POLY1305 is considered 
AEAD, so the two will always be linked. That being said, nothing prevents 
CHACHA20 from referencing additional CHACHA20 ciphers, nor precludes adding 
CHACHA20POLY1305 as a cipher string.

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

On Dec 28, 2015, at 10:28 AM, Kurt Roeckx via RT 
<r...@openssl.org<mailto:r...@openssl.org>> wrote:

On Mon, Dec 28, 2015 at 03:01:28PM +, Short, Todd via RT wrote:
Hello OpenSSL.org<http://OpenSSL.org><http://OpenSSL.org>:

This is a patch for the master branch. The changes in master to add ChaCha20 to 
OpenSSL do not include an alias for the cipher in the "openssl cipher" command, 
nor in the cipher functions., even though the necessary constants have been 
defined. The attached patch adds that alias.

The following openssl commands now behave as expected:

openssl ciphers CHACHA20
openssl ciphers CHACHA20:AES

Please at least also update the documentation, like ciphers.pod.

I'm also not sure if CHACHA20 should only select those in
combination with Poly1305, even if those are currently the only
supported.


Kurt



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

Re: [openssl-dev] [openssl.org #4206] [PATCH] Add cipher alias for ChaCha20

[Short, Todd via RT]

True, but there’s currently no flag defined for just “ChaCha20” ciphers, just 
SSL_CHACHA20POLY1305. My understanding is that CHACHA20POLY1305 is considered 
AEAD, so the two will always be linked. That being said, nothing prevents 
CHACHA20 from referencing additional CHACHA20 ciphers, nor precludes adding 
CHACHA20POLY1305 as a cipher string.

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

On Dec 28, 2015, at 10:28 AM, Kurt Roeckx via RT 
<r...@openssl.org<mailto:r...@openssl.org>> wrote:

On Mon, Dec 28, 2015 at 03:01:28PM +, Short, Todd via RT wrote:
Hello OpenSSL.org<http://OpenSSL.org><http://OpenSSL.org>:

This is a patch for the master branch. The changes in master to add ChaCha20 to 
OpenSSL do not include an alias for the cipher in the "openssl cipher" command, 
nor in the cipher functions., even though the necessary constants have been 
defined. The attached patch adds that alias.

The following openssl commands now behave as expected:

openssl ciphers CHACHA20
openssl ciphers CHACHA20:AES

Please at least also update the documentation, like ciphers.pod.

I'm also not sure if CHACHA20 should only select those in
combination with Poly1305, even if those are currently the only
supported.


Kurt




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

[openssl-dev] [openssl.org #4197] [PATCH] Memory leak in state machine in error path

[Short, Todd via RT]

Hello OpenSSL org:

I found the following issue via code inspection. In 
tls_process_client_key_exchange(), when EC is disabled, and an error occurs in 
ssl_generate_master_secret() or RAND_bytes(), the error path does not free 
rsa_decrypt.

Note that rsa_decrypt is not conditionally defined by OPENSSL_NO_RSA, so I did 
not wrap the free with that conditional.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."



0001-Memory-leak-in-state-machine-in-error-path.patch
Description: Binary data
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4187] [Patch] Secure memory subsystem does not report actual size

[Short, Todd via RT]

Hello OpenSSL Organization:

This patch updates the secure memory allocator to allow callers to determine 
the actual size of the secure memory allocation. This can be used by 
applications to report accurate memory usage.

Github link:
https://github.com/akamai/openssl/commit/6d0b49bd810e0ae36d934c34cab8ad37089ca6ef

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


___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4188] [Patch/Fix] s_server.c does not compile when no-srtp is configured

[Short, Todd via RT]

Hello OpenSSL Organization:

When ‘no-srtp’ is configured, the s_server.c application does not successfully 
compile. The undefined variable srtp_profiles is referenced. This patch fixes 
the issue.

Github link:
https://github.com/akamai/openssl/commit/f78119f39621d02bee31c9427b2be3a9d2cff26f

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


___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Short, Todd]

I suspect that most “users” of OpenSSL are doing it indirectly through other 
applications that use TLS (or crypto) functionality. Example: the Cisco 
AnyConnect client is reportedly one of the most installed pieces of software 
regardless of platform; it uses OpenSSL for TLS.

Taking those indirect users into account, they don’t care about the research or 
advanced uses of OpenSSL; they just want to connect securely to their corporate 
network.

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

On Nov 20, 2015, at 9:09 PM, Peter Waltenberg 
<pwal...@au1.ibm.com<mailto:pwal...@au1.ibm.com>> wrote:

Quite reasonable except.

I'm not sure you have majority and minority the right way around. My guess 
would be that the majority of OpenSSL users are libcrypto. consumers rather 
than SSL/TLS consumers.

A point several of us have been trying to get through for some time.

Peter

-"openssl-dev" 
<openssl-dev-boun...@openssl.org<mailto:openssl-dev-boun...@openssl.org>> 
wrote: -
To: "openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>" 
<openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>>
From: "Short, Todd"
Sent by: "openssl-dev"
Date: 11/21/2015 08:28AM
Cc: "openssl-us...@openssl.org<mailto:openssl-us...@openssl.org>" 
<openssl-us...@openssl.org<mailto:openssl-us...@openssl.org>>
Subject: Re: [openssl-dev] [openssl-users] Removing obsolete crypto from 
OpenSSL 1.1 - seeking feedback

While I am all for simplicity, I also think that removing functionality is a 
“bad idea”.

To reduce the support burden, deprecate the ciphers:
1. Under support, indicate that these ciphers will no longer receive fixes.
2. Remove any assembly implementations
3. Disable them by default.

I suggest following the 80/20 rule (sometimes the 95/5 rule):

Those “who care” (the minority) about the ciphers can re-enable them and 
rebuild the library.
Those “who don’t care” (the majority) about the ciphers, should get the 
functionality that most people care about, basically SSL/TLS connectivity.

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

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

On Nov 18, 2015, at 1:52 PM, Blumenthal, Uri - 0553 - MITLL 
<u...@ll.mit.edu<mailto:u...@ll.mit.edu>> wrote:

On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
<openssl-dev-boun...@openssl.org<mailto:openssl-dev-boun...@openssl.org> on 
behalf of bka...@akamai.com<mailto:bka...@akamai.com>> wrote:

On 11/18/2015 07:05 AM, Hubert Kario wrote:
So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
support
both relatively modern TLS with user certificates, preferably the
newest
cryptosystems and hashes as well as the oldest ones that were
standardised and used.

That means that old algorithms MUST remain in OpenSSL as supported
functionality. It may require linking to a specific library to make the
EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
from it completely, definitely not before at least 50 years _after_
they
became obsolete and broken.

There seems to be a logical leap between these two paragraphs.  Why is
it necessary that OpenSSL be the only cryptographic library used by
CAdES-A/etc. implementations?

Because it used to be the only real game in town, and *people learned to
rely upon it*.

Is it in fact even necessary that only a
single version of a single cryptographic library be used for such
software?

No, of course not. But after letting people depend on this “single
cryptographic library” for many years, telling them “too bad” isn’t very
nice.

While OpenSSL may try to be a general-purpose crypto library,
when a software has stringent or unusual crypto requirements, it seems
reasonable that such a software may need to involve unusual
implementations.

The requirements did not change. What changed was the maintainers
expressing their desire to stop supporting some of them.

I do not believe that OpenSSL has promised anywhere that it will support
this sort of use case.

Implicitly, by providing that kind of service for so long. And explicitly,
as pointed out by Hubert:

From the main web page of project:

The OpenSSL Project is a collaborative effort to develop a robust,
commercial-grade, *full-featured*, and Open Source toolkit
implementing the Transport Layer Security (TLS) and Secure Sockets
Layer (SSL) protocols as well as a full-strength *general purpose*
*cryptography library* .

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

[openssl-dev] [openssl.org #4149] [PATCH] ssl_set_pkey() unnecessarily updates certificates

[Short, Todd via RT]

Hello OpenSSL.org

We have found the following issue in 1.0.2 and master branches of OpenSSL:

ssl_set_pkey() unnecessarily updates certificates

Some key types types (EC, DSA, DH, but not RSA) have separate parameters that 
are needed for correct operation. When ssl_set_pkey() is called (via 
SSL_use_PrivateKey), it copies these parameters from the newly set private key 
into the public key of the CERT structure. This could lead to a modification of 
the X509 structure while it is being used in another thread.

This parameter copy is unconditional, and always occurs during ssl_set_pkey(). 
The proposed solution is to modify the copy routine EVP_PKEY_copy_parameters() 
to check for parameter equality via the EVP_PKEY_cmp_parameters() function 
before doing the actual copy. If the parameters match, then success is returned 
and no copy is performed. (But also check to see if the parameters are there 
before the compare.)
   
This avoids unnecessary modification of the certificate structure and avoids 
the crash. The parameters may be copied on the first setting of the private 
key, but after that, the parameters will be equal and not copied any more.

There is minimal locking around the SSL_use_PrivateKey() and other 
corresponding code, so adding additional locking would not suffice.

A patch will be sent via github pull request, once a RT number is assigned.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

Re: [openssl-dev] [BUG] Data race in md_rand.c functions

[Short, Todd]

Do you set any of the locking functions and/or do you configure with no-locking?

CRYPTO_set_locking_callback()
CRYPTO_set_add_lock_callback()

see: https://www.openssl.org/docs/manmaster/crypto/threads.html


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

On Nov 5, 2015, at 8:42 PM, Dmitry Sobinov 
> wrote:

We use OpenSSL for DTLS and for general random numbers generation. While 
checking our app with Clang Thread Sanitizer, we discovered following data race:

WARNING: ThreadSanitizer: data race (pid=20055)
  Read of size 4 at 0x7f14adbb7f98 by thread T18:
#0 ssleay_rand_add 
/home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:220 
(test_client+0x00dd242a)
#1 RAND_add 
/home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/rand_lib.c:152 
(test_client+0x00c795be)
#2 dtls1_connect 
/home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/d1_clnt.c:174 
(test_client+0x00f4850a)
#3 SSL_do_handshake 
/home/dmitry.sobinov/builds/openssl-1.0.2d/ssl/ssl_lib.c:2768 
(test_client+0x00f701ec)
#4 DtlsSrtpTransport::handshakeIteration() 
/home/dmitry.sobinov/__/src/DtlsSrtpTransport.cpp:328 
(test_client+0x0079ef88)

  Previous write of size 4 at 0x7f14adbb7f98 by thread T41 (mutexes: write 
M869):
#0 ssleay_rand_bytes 
/home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:392 
(test_client+0x00dd2e1f)
#1 ssleay_rand_nopseudo_bytes 
/home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/md_rand.c:536 
(test_client+0x00dd22cb)
#2 RAND_bytes 
/home/dmitry.sobinov/builds/openssl-1.0.2d/crypto/rand/rand_lib.c:159 
(test_client+0x00c7965a)
#3 utils::generateRandomBytes(unsigned char*, unsigned long) 
/home/dmitry.sobinov/__/src/OpenSSLHelpers.cpp:45 (test_client+0x0078a697)
#4 unsigned short utils::random() 
/home/dmitry.sobinov/__/include/utils/OpenSSLHelpers.h:42 
(test_client+0x005a4bff)


Static global variable crypto_lock_rand is not protected by mutex or set as 
atomic. AFAIK it's undefined behaviour in c/c++.
OpenSSL was built with TSan instrumentation.


Thanks,
Dmitry Sobinov

___
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] 1.0.2e release?

[Short, Todd]

openssl-dev:

It’s been almost 4 months, and ~127 commits since 1.0.2d went out the door.

Are there plans for an upcoming 1.0.2e release?

Thanks,

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

Re: [openssl-dev] [openssl.org #4109] Re: Error installing openssl version 1.0.2

[Short, Todd]

This is likely the same as RT3885. Check out this fix:

https://github.com/akamai/openssl/commit/15ecb1a4dc4f75d6c33e8cd9089ca5cfc78d28dc

You may be running a 32-bit version of Perl on a 64-bit platform.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Oct 27, 2015, at 3:02 PM, Dhruv Bhatt via RT  wrote:

Hi,

I am trying to install openssl version 1.0.2.

What I do:
1. tar the version openssl-1.0.2
2. cd to that directory .
3. ./config —prefix=<> —openssldir=<>
4. make


Issue is something with crypto/modes/ghash-x86_64.s file at line 890.

junk ‘’ after expression.

Has this issue been fixed? Also it comes with 1.0.2d version as well. But if we 
try 1.0.1j version it works completely fine and I am able to install that 
version.

Thanks,
Dhruv.

P.S. I am trying to help someone install openssl and I have seen this issue 
twice till now, I do not have any logs with me will try to get one.
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
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] [openssl.org #4109] Re: Error installing openssl version 1.0.2

[Short, Todd via RT]

This is likely the same as RT3885. Check out this fix:

https://github.com/akamai/openssl/commit/15ecb1a4dc4f75d6c33e8cd9089ca5cfc78d28dc

You may be running a 32-bit version of Perl on a 64-bit platform.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Oct 27, 2015, at 3:02 PM, Dhruv Bhatt via RT  wrote:

Hi,

I am trying to install openssl version 1.0.2.

What I do:
1. tar the version openssl-1.0.2
2. cd to that directory .
3. ./config —prefix=<> —openssldir=<>
4. make


Issue is something with crypto/modes/ghash-x86_64.s file at line 890.

junk ‘’ after expression.

Has this issue been fixed? Also it comes with 1.0.2d version as well. But if we 
try 1.0.1j version it works completely fine and I am able to install that 
version.

Thanks,
Dhruv.

P.S. I am trying to help someone install openssl and I have seen this issue 
twice till now, I do not have any logs with me will try to get one.
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
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] [openssl.org #4074] [PATCH] Fixes for when PSK, SRP, SRTP and DTLS1 are disabled

[Short, Todd via RT]

Hello OpenSSL Org:

While evaluating the master branch, I discovered that the code does not 
compile, nor do the unit tests pass, when disabling certain features. 
Specifically, PSK, SRP, SRTP and DTLS1.

The following patch for master branch will fix the issues.

Thanks,

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



0001-Fix-when-SRP-SRTP-DTLS1-PSK-are-disabled.patch
Description: Binary data
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3724] Patch/Feature to add asynchronous processing for some operations

[Short, Todd via RT]

Hello,

Again, we have an updated patch for asynchronous processing: unit-tests and 
copyright.

Github link:
https://github.com/akamai/openssl/commit/92914accbb54ee085918451468575a5e76baba20

And attached file.

Thanks,

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



0003-RT3724-Add-asynchronous-event-processing.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3883] [PATCH] Add IPv4/IPv6:port-based client cache

[Short, Todd via RT]

Updates to the IPv4/IPv6: port-based client cache patch:

Updated documentation, unit-tests and copyright.

Github link:
https://github.com/akamai/openssl/commit/0a9ec5fc896c0fdc417e60366d03c1d95cc53033

And attached patch.

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




0023-RT3883-Add-IPv4-IPv6-port-based-client-cache.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3869] [PATCH] Add shared session lists in SSL_CTX

[Short, Todd via RT]

Hello OpenSSL Org:

We have an updated patch for RT 3869, which includes a deadlock fix when 
flushing sessions.

Github link:
https://github.com/akamai/openssl/commit/6b8c80239d174e7ca55f052b86f942d70ffca29ehttps://github.com/akamai/openssl/commits/akamai-master-july2015

And attachment.



0017-RT3869-Add-shared-session-lists-in-SSL_CTX.patch
Description: Binary data
Thanks.
---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

[openssl-dev] [openssl.org #3885] [BUGFIX] OpenSSL fails to cross-compile on 32-bit-64-bit

[Short, Todd via RT]

Hello OpenSSL Org:

We have an updated patch; there were issues with AES-GCM on some platforms, due 
to multiply operations on immediate constant values.

Updated github patch:
https://github.com/openssl/openssl/commit/15ecb1a4dc4f75d6c33e8cd9089ca5cfc78d28dc

And attached.



0001-RT3885-OpenSSL-fails-to-cross-compile-on-32-bit-64-b.patch
Description: Binary data
Thank you.
---Todd Short// tsh...@akamai.com// "One if by land, two if by sea, three if by the Internet."

On May 30, 2015, at 3:48 AM, Joy Tu via RT r...@openssl.org wrote:Hello OpenSSL Org:This is a change that Akamai has made to its implementation of OpenSSL.Version: master branchDescription: OpenSSL fails to cross-compile on 32-bit-64-bitOlder/32-bit versions of perl cannot handle 64-bit numbers, so whenthe x86_64-xlate.pl script encounters a 64-bit number, the oct()function munges it into a double-precision rather than a 64-bitinteger. In this case, we know it's either a hex number or an octalnumber. So, if hex, just pass through as hex string, otherwise allowoct() to handle it.This is a problem in ghash-x86_64.pl (ghash-x86_64.s), and the solutionhas an impact all 64-bit platforms. Ran the unit tests to make sure it'sOKGithub link:https://github.com/akamai/openssl/commit/89808ba6a3e3ab69b12518dc5ba651eb29c18ee7And attachment.Thank you.---Todd Short// tsh...@akamai.com// “One if by land, two if by sea, three if by the Internet.”0004-OpenSSL-fails-to-cross-compile-on-32-bit-64-bit.patch___openssl-dev mailing listTo 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] [openssl.org #3875] [PATCH] Add external X509_STORE to SSL_CTX

[Short, Todd via RT]

Updated this patch with new documentation.

Github link:
https://github.com/akamai/openssl/commit/34cd12929b479f0c229bb9d564e2d2eec3d8df5d

And attachment.
--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// One if by land, two if by sea, three if by the Internet.

On May 27, 2015, at 4:32 PM, Short, Todd via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add external X509_STORE to SSL_CTX

Add SSL_CTX_set_cert_store_ref() API to add an external X509_STORE to
an SSL_CTX. (There is no get API).
Github link:
https://github.com/akamai/openssl/commit/517559c8637cda3750b39017685742590f1b692e

And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.”

0018-Add-external-X509_STORE-to-SSL_CTX.patch___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev




0018-RT3875-Add-external-X509_STORE-to-SSL_CTX.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3881] [PATCH] Instrument OpenSSL buffer heap memory usage

[Short, Todd via RT]

Updates to the buffer heap memory usage patch:
Updated documentation.

Github link:
https://github.com/akamai/openssl/commit/222f0d2d94be8b92c306c062320fd15b59a9000a

And attached file.

Thank you,

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

On May 30, 2015, at 3:48 AM, Joy Tu via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description:  Instrument OpenSSL buffer heap memory usage

Added function to register callbacks to allocate and free data buffers.

These callbacks can then allocate and free the memory as needed, while
also recording buffer allocations.

This permits a user-definable implementation of FREE_BUFLIST, which has been 
removed.

(Yes, documentation is lacking at this point).

Github link:

https://github.com/akamai/openssl/commit/4a6d71bbd2f4fe38ebcbe2f9917a1c7fedd117f8

And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.”

0022-Instrument-OpenSSL-buffer-heap-memory-usage.patch___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



0021-RT3881-Instrument-OpenSSL-buffer-heap-memory-usage.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3865] [Patch] Add DISALLOW_RENEGOTIATION option

[Short, Todd via RT]

Hello,

Please find an updated patch that includes updated documentation.

Github link:

https://github.com/akamai/openssl/commit/9f3a6ecb83e80cbfebc038a860d5ce63817e0098

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

On May 26, 2015, at 2:56 PM, Short, Todd via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add DISALLOW_RENEGOTIATION option

Add support to disallow renegotiation in openssl
The bit definition may need to change when pulled.

Github link:
https://github.com/akamai/openssl/commit/fcab621995d55d8873a02a96d5a8157f38469ebb

And attachment.

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

0010-Add-DISALLOW_RENEGOTIATION-option.patch
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev




0010-RT3865-Add-DISALLOW_RENEGOTIATION-option.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3868] [PATCH] Add SSL_get0_peer_certificate()

[Short, Todd via RT]

Hello,

We have an updated version of the patch that includes updated documentation.

GitHub link:
https://github.com/akamai/openssl/commit/980d0b6e67dce0088dcb49e6fa66bbb868f43000

And attachment

Thanks,

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



0013-RT3868-Add-SSL_get0_peer_certificate.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3869] [PATCH] Add shared session lists in SSL_CTX

[Short, Todd via RT]

Hello,

We have an updated patch for this: updated documentation

Github link:
https://github.com/akamai/openssl/commit/246b86ee329c70cbf8c822e852cc31e1076d53fd

And attachment.

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

On May 26, 2015, at 4:29 PM, Short, Todd via RT r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add shared session lists in SSL_CTX

Support for shared session lists via SSL_CTX_share_session_cache().
Added locking during the sharing and cleanup.

Github link:
https://github.com/akamai/openssl/commit/fe1e4ac33a89e9176af0b645eafc2aaec5fc2266

And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.”

0014-Add-shared-session-lists-in-SSL_CTX.patch___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev




0014-RT3869-Add-shared-session-lists-in-SSL_CTX.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3870] [PATCH] Async TLSEXT servername support.

[Short, Todd via RT]

Hello,

We have an updated patch for this, which includes updated documentation, 
unit-tests and copyright.

Github link:
https://github.com/akamai/openssl/commit/1f26946f7e5cf85b20c3b97a8c0e6a869f9a04fa

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

On May 26, 2015, at 4:29 PM, Short, Todd via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Async TLSEXT servername support.

Adds support for processing the servername TLSEXT asynchronously,
using the SSL_WANT_EVENT mechanism (RT 3724).

Github link:
https://github.com/akamai/openssl/commit/0205cc4eee7084e65a69995293ad584f7da21fa9

And attachment.

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

0015-Async-TLSEXT-servername-support.patch___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



0015-RT3870-Async-TLSEXT-servername-support.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3874] [PATCH] Add certificate verify data to SSL struct

[Short, Todd]

Hello:

We have an updated patch with documentation for this.

Github link:
https://github.com/akamai/openssl/commit/e431afa72e77da4463c8cdcac8893336b9b32b04

And attachment.

Thanks,

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

On May 27, 2015, at 4:32 PM, Short, Todd via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add certificate verify data to SSL struct

Add app_verify_callback and app_verify_arg to the SSL structure and add
SSL_SESSION_set_verify_result() API. The values are copied from the
SSL_CTX into the SSL. There is also an SSL_set_cert_verify_callback() API.

Github link:
https://github.com/akamai/openssl/commit/a7d729491c2dacd4dae01eb49e1ca3ff797133ff

And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.”

0017-Add-certificate-verify-data-to-SSL-struct.patch___
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] [openssl.org #3874] [PATCH] Add certificate verify data to SSL struct

[Short, Todd via RT]

Hello:

We have an updated patch with documentation for this.

Github link:
https://github.com/akamai/openssl/commit/e431afa72e77da4463c8cdcac8893336b9b32b04

And attachment.

Thanks,

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

On May 27, 2015, at 4:32 PM, Short, Todd via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add certificate verify data to SSL struct

Add app_verify_callback and app_verify_arg to the SSL structure and add
SSL_SESSION_set_verify_result() API. The values are copied from the
SSL_CTX into the SSL. There is also an SSL_set_cert_verify_callback() API.

Github link:
https://github.com/akamai/openssl/commit/a7d729491c2dacd4dae01eb49e1ca3ff797133ff

And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.”

0017-Add-certificate-verify-data-to-SSL-struct.patch___
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] [openssl.org #3873] [PATCH] Add traffic counters

[Short, Todd via RT]

Hello,

We have an updated patch for this: includes documentation.

Github link:
https://github.com/akamai/openssl/commit/956053b4b4a6f374df939c3d830cb1a095428ac9

And attachment.

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

On May 27, 2015, at 4:32 PM, Short, Todd via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add traffic counters

Add data counters to SSL structure bytes_written and bytes_read
Includes SSL_get_byte_counters() API.

Github link:
https://github.com/akamai/openssl/commit/517559c8637cda3750b39017685742590f1b692e

And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.”

0016-Add-traffic-counters.patch___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev





0016-RT3873-Add-traffic-counters.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3883] [PATCH] Add IPv4/IPv6:port-based client cache

[Short, Todd via RT]

Yup, we noticed that too. 

--
-Todd Short
// tsh...@akamai.com
// Sent from my iPhone
// One if by land, two if by sea, three if by the Internet.


 On Jun 5, 2015, at 5:27 PM, Jonathan Larmour via RT r...@openssl.org wrote:
 
 On 01/06/15 15:22, Short, Todd via RT wrote:
 Re: copyrights:
 
 Planning to copy the (109-line) main copyright from another source file and 
 append to it:
 
 /* 
 * Copyright (C) 2015 Akamai Technologies. ALL RIGHTS RESERVED.
 * This code was originally developed by Akamai Technologies and
 * and contributed to the OpenSSL project.
 */
 
 Acceptable?
 
 Just a little thing I noticed, but your text has and and (separated by a
 newline).
 
 Jifl
 
 


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

Re: [openssl-dev] [openssl.org #3882] [BUGFIX] lh_SSL_SESSION_delete() not checked

[Short, Todd]

Depending on how the comparison function was implemented, the insert could 
still succeed at the point mentioned.

In the case of the patch sent for RT 3883, the original implementation of the 
comparison function always failed if the client IP address was not set (given 
that RT 3883 does not require the IP address to be set before adding to the 
session database, this made sense - a NULL address should never match any other 
address, even a NULL address). Thus we would end up in a situation where no 
match was found in the lhash, but still deleting the structure from the list, 
causing an inconsistency. The compare function was repaired to always match 
itself, preventing this occurrence.

The patch makes the code in timeout_doall_arg() match the remove_session_lock() 
function, which does an lh_SESSION_retrieve() followed by 
lh_SSL_SESSION_delete() and SSL_SESSION_list_remove() if the retrieve() is 
successful.

Fundamentally, this patch is to keep the SSL_SESSION database in a consistent 
state, regardless of the behavior of the compare and hash functions. I consider 
that a “good” thing.

One could replace most of timeout_doall_arg() with remove_session_lock(lck=0) 
and have the same effect - but that won’t necessarily work with RT 3883’s patch 
since it does not set the session_id_length for client-side SSL_SESSIONs.

static void timeout_doall_arg(SSL_SESSION *s, TIMEOUT_PARAM *p)
{
if ((p-time == 0) || (p-time  (s-time + s-timeout))) { /* timeout */
/*
 * The reason we don't call SSL_CTX_remove_session() is to save on
 * locking overhead
 */
(void)remove_session_lock(p-ctx, s, 0);
}
}

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

On May 31, 2015, at 4:46 PM, Salz, Rich via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hmm, but does it? If you look for the comment '/* We *are* in trouble ... */'
in ssl_sess.c, you'll see that there is a similar kind of protection in place
already at the time of insert. So quite frankly and with all respect, I'm not
sure if this particular fix does anything of value any longer.

On Sun May 31 22:28:18 2015, tsh...@akamai.commailto:tsh...@akamai.com wrote:
We (Akamai) had a bad session compare function at one point; the
compare was fixed, but also added this change to protect the LHASH.

So, yes, this can only really happen if one has a bad comparison
function.

--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// Sent from my iPhone
// One if by land, two if by sea, three if by the Internet.


On May 31, 2015, at 4:22 PM, Richard Levitte via RT 
r...@openssl.orgmailto:r...@openssl.org
wrote:

I'm not sure how that can happen, as each SSL_SESSION in that lhash
will have
unique content. This is assured by the way lh_insert functions and
by
ssl_session_cmp (which gets called by getrn in lhash.c, via the
function
pointer cf).

So while your suggestion will most probably work as a band aid, I'm
thinking
you've really found a bug in ssl_session_cmp or in the lhash code
itself. Could
you verify?

On Sun May 31 21:24:04 2015, tsh...@akamai.commailto:tsh...@akamai.com wrote:
No,

The second code sample removes a matching instance, but not
necessarily the same instance. If they are not the same instance,
then
it would need to be re-inserted in and else clause.

This is a fine distinction.

This would leave to having the list and hash not contain the same
contents: Either the number of items is different, or the two sets
of
items are different.

There's a similar example in the code, I believe, but I'd have to
search for it.

--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// Sent from my iPhone
// One if by land, two if by sea, three if by the Internet.


On May 31, 2015, at 12:43 PM, Richard Levitte via RT
r...@openssl.orgmailto:r...@openssl.org wrote:

You solution does the following:

if (lh_SSL_SESSION_retrieve(p-cache, s) == s) {
(void)lh_SSL_SESSION_delete(p-cache, s);
...

Would you agree that the following does the same?

if (lh_SSL_SESSION_delete(p-cache, s) == s) {
...


On Sat May 30 09:48:06 2015, tsh...@akamai.commailto:tsh...@akamai.com wrote:
Hello OpenSSL Org:

This is a change that Akamai has made to its
implementation of OpenSSL.

Version: master branch
Description:
lh_SSL_SESSION_delete() not checked

Fix an OpenSSL issue where the
return code of lh_SSL_SESSION_delete()
is not checked, causing a
stale reference in the lhash.

Github link:


https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc
And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.”


--
Richard Levitte
levi...@openssl.org


--
Richard Levitte
levi...@openssl.org




--
Richard Levitte
levi...@openssl.org


___
openssl-dev mailing list
To unsubscribe: 

Re: [openssl-dev] [openssl.org #3883] [PATCH] Add IPv4/IPv6:port-based client cache

[Short, Todd via RT]

Re: copyrights:

Planning to copy the (109-line) main copyright from another source file and 
append to it:

/* 
 * Copyright (C) 2015 Akamai Technologies. ALL RIGHTS RESERVED.
 * This code was originally developed by Akamai Technologies and
 * and contributed to the OpenSSL project.
 */

Acceptable?
--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.

On May 31, 2015, at 9:27 AM, Salz, Rich via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:


(Documentation is in the source files, not a .pod)

Do you have code to produce usable manpages from the embedded
documentation?  We can't ask users to read the source.

I believe Todd meant for the test program.


   * The copyright notice does not refer to any license that would allow
 inclusion in OpenSSL.

Sigh.  We'll fix that to just submit with the akamai copyright and openssl 
license.





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

Re: [openssl-dev] [openssl.org #3882] [BUGFIX] lh_SSL_SESSION_delete() not checked

[Short, Todd via RT]

Depending on how the comparison function was implemented, the insert could 
still succeed at the point mentioned.

In the case of the patch sent for RT 3883, the original implementation of the 
comparison function always failed if the client IP address was not set (given 
that RT 3883 does not require the IP address to be set before adding to the 
session database, this made sense - a NULL address should never match any other 
address, even a NULL address). Thus we would end up in a situation where no 
match was found in the lhash, but still deleting the structure from the list, 
causing an inconsistency. The compare function was repaired to always match 
itself, preventing this occurrence.

The patch makes the code in timeout_doall_arg() match the remove_session_lock() 
function, which does an lh_SESSION_retrieve() followed by 
lh_SSL_SESSION_delete() and SSL_SESSION_list_remove() if the retrieve() is 
successful.

Fundamentally, this patch is to keep the SSL_SESSION database in a consistent 
state, regardless of the behavior of the compare and hash functions. I consider 
that a “good” thing.

One could replace most of timeout_doall_arg() with remove_session_lock(lck=0) 
and have the same effect - but that won’t necessarily work with RT 3883’s patch 
since it does not set the session_id_length for client-side SSL_SESSIONs.

static void timeout_doall_arg(SSL_SESSION *s, TIMEOUT_PARAM *p)
{
if ((p-time == 0) || (p-time  (s-time + s-timeout))) { /* timeout */
/*
 * The reason we don't call SSL_CTX_remove_session() is to save on
 * locking overhead
 */
(void)remove_session_lock(p-ctx, s, 0);
}
}

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

On May 31, 2015, at 4:46 PM, Salz, Rich via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hmm, but does it? If you look for the comment '/* We *are* in trouble ... */'
in ssl_sess.c, you'll see that there is a similar kind of protection in place
already at the time of insert. So quite frankly and with all respect, I'm not
sure if this particular fix does anything of value any longer.

On Sun May 31 22:28:18 2015, tsh...@akamai.commailto:tsh...@akamai.com wrote:
We (Akamai) had a bad session compare function at one point; the
compare was fixed, but also added this change to protect the LHASH.

So, yes, this can only really happen if one has a bad comparison
function.

--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// Sent from my iPhone
// One if by land, two if by sea, three if by the Internet.


On May 31, 2015, at 4:22 PM, Richard Levitte via RT 
r...@openssl.orgmailto:r...@openssl.org
wrote:

I'm not sure how that can happen, as each SSL_SESSION in that lhash
will have
unique content. This is assured by the way lh_insert functions and
by
ssl_session_cmp (which gets called by getrn in lhash.c, via the
function
pointer cf).

So while your suggestion will most probably work as a band aid, I'm
thinking
you've really found a bug in ssl_session_cmp or in the lhash code
itself. Could
you verify?

On Sun May 31 21:24:04 2015, tsh...@akamai.commailto:tsh...@akamai.com wrote:
No,

The second code sample removes a matching instance, but not
necessarily the same instance. If they are not the same instance,
then
it would need to be re-inserted in and else clause.

This is a fine distinction.

This would leave to having the list and hash not contain the same
contents: Either the number of items is different, or the two sets
of
items are different.

There's a similar example in the code, I believe, but I'd have to
search for it.

--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// Sent from my iPhone
// One if by land, two if by sea, three if by the Internet.


On May 31, 2015, at 12:43 PM, Richard Levitte via RT
r...@openssl.orgmailto:r...@openssl.org wrote:

You solution does the following:

if (lh_SSL_SESSION_retrieve(p-cache, s) == s) {
(void)lh_SSL_SESSION_delete(p-cache, s);
...

Would you agree that the following does the same?

if (lh_SSL_SESSION_delete(p-cache, s) == s) {
...


On Sat May 30 09:48:06 2015, tsh...@akamai.commailto:tsh...@akamai.com wrote:
Hello OpenSSL Org:

This is a change that Akamai has made to its
implementation of OpenSSL.

Version: master branch
Description:
lh_SSL_SESSION_delete() not checked

Fix an OpenSSL issue where the
return code of lh_SSL_SESSION_delete()
is not checked, causing a
stale reference in the lhash.

Github link:


https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc
And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.”


--
Richard Levitte
levi...@openssl.org


--
Richard Levitte
levi...@openssl.org




--
Richard Levitte
levi...@openssl.org



___
openssl-dev mailing list
To unsubscribe: 

Re: [openssl-dev] [openssl.org #3883] [PATCH] Add IPv4/IPv6:port-based client cache

[Short, Todd via RT]

Note that this (almost) is identical to the Sun Microsystems contribution 
copyright in s3_both.c, s3_clnt.c s3_lib.c s3_srvr.c, ssl_cert.c ssl_ciph.c, 
ssl_lib.c and ssl_locl.h…

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

On Jun 1, 2015, at 10:22 AM, Short, Todd via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Re: copyrights:

Planning to copy the (109-line) main copyright from another source file and 
append to it:

/* 
* Copyright (C) 2015 Akamai Technologies. ALL RIGHTS RESERVED.
* This code was originally developed by Akamai Technologies and
* and contributed to the OpenSSL project.
*/

Acceptable?
--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.commailto:tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.

On May 31, 2015, at 9:27 AM, Salz, Rich via RT 
r...@openssl.orgmailto:r...@openssl.orgmailto:r...@openssl.org wrote:


(Documentation is in the source files, not a .pod)

Do you have code to produce usable manpages from the embedded
documentation?  We can't ask users to read the source.

I believe Todd meant for the test program.


  * The copyright notice does not refer to any license that would allow
inclusion in OpenSSL.

Sigh.  We'll fix that to just submit with the akamai copyright and openssl 
license.





___
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] [openssl.org #3882] [BUGFIX] lh_SSL_SESSION_delete() not checked

[Short, Todd via RT]

No,

The second code sample removes a matching instance, but not necessarily the 
same instance. If they are not the same instance, then it would need to be 
re-inserted in and else clause. 

This is a fine distinction. 

This would leave to having the list and hash not contain the same contents: 
Either the number of items is different, or the two sets of items are 
different. 

There's a similar example in the code, I believe, but I'd have to search for 
it. 

--
-Todd Short
// tsh...@akamai.com
// Sent from my iPhone
// One if by land, two if by sea, three if by the Internet.


 On May 31, 2015, at 12:43 PM, Richard Levitte via RT r...@openssl.org wrote:
 
 You solution does the following:
 
 if (lh_SSL_SESSION_retrieve(p-cache, s) == s) {
 (void)lh_SSL_SESSION_delete(p-cache, s);
 ...
 
 Would you agree that the following does the same?
 
 if (lh_SSL_SESSION_delete(p-cache, s) == s) {
 ...
 
 
 On Sat May 30 09:48:06 2015, tsh...@akamai.com wrote:
 Hello OpenSSL Org:
 
 This is a change that Akamai has made to its
 implementation of OpenSSL.
 
 Version: master branch
 Description:
 lh_SSL_SESSION_delete() not checked
 
 Fix an OpenSSL issue where the
 return code of lh_SSL_SESSION_delete()
 is not checked, causing a
 stale reference in the lhash.
 
 Github link:
 https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc
 And attachment.
 
 Thank you.
 --
 -Todd Short
 // tsh...@akamai.com
 // “One if by land, two if by sea, three if by the Internet.”
 
 
 --
 Richard Levitte
 levi...@openssl.org
 


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

Re: [openssl-dev] [openssl.org #3882] [BUGFIX] lh_SSL_SESSION_delete() not checked

[Short, Todd via RT]

We (Akamai) had a bad session compare function at one point; the compare was 
fixed, but also added this change to protect the LHASH.

So, yes, this can only really happen if one has a bad comparison function. 

--
-Todd Short
// tsh...@akamai.com
// Sent from my iPhone
// One if by land, two if by sea, three if by the Internet.


 On May 31, 2015, at 4:22 PM, Richard Levitte via RT r...@openssl.org wrote:
 
 I'm not sure how that can happen, as each SSL_SESSION in that lhash will have
 unique content. This is assured by the way lh_insert functions and by
 ssl_session_cmp (which gets called by getrn in lhash.c, via the function
 pointer cf).
 
 So while your suggestion will most probably work as a band aid, I'm thinking
 you've really found a bug in ssl_session_cmp or in the lhash code itself. 
 Could
 you verify?
 
 On Sun May 31 21:24:04 2015, tsh...@akamai.com wrote:
 No,
 
 The second code sample removes a matching instance, but not
 necessarily the same instance. If they are not the same instance, then
 it would need to be re-inserted in and else clause.
 
 This is a fine distinction.
 
 This would leave to having the list and hash not contain the same
 contents: Either the number of items is different, or the two sets of
 items are different.
 
 There's a similar example in the code, I believe, but I'd have to
 search for it.
 
 --
 -Todd Short
 // tsh...@akamai.com
 // Sent from my iPhone
 // One if by land, two if by sea, three if by the Internet.
 
 
 On May 31, 2015, at 12:43 PM, Richard Levitte via RT
 r...@openssl.org wrote:
 
 You solution does the following:
 
 if (lh_SSL_SESSION_retrieve(p-cache, s) == s) {
 (void)lh_SSL_SESSION_delete(p-cache, s);
 ...
 
 Would you agree that the following does the same?
 
 if (lh_SSL_SESSION_delete(p-cache, s) == s) {
 ...
 
 
 On Sat May 30 09:48:06 2015, tsh...@akamai.com wrote:
 Hello OpenSSL Org:
 
 This is a change that Akamai has made to its
 implementation of OpenSSL.
 
 Version: master branch
 Description:
 lh_SSL_SESSION_delete() not checked
 
 Fix an OpenSSL issue where the
 return code of lh_SSL_SESSION_delete()
 is not checked, causing a
 stale reference in the lhash.
 
 Github link:
 https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc
 And attachment.
 
 Thank you.
 --
 -Todd Short
 // tsh...@akamai.com
 // “One if by land, two if by sea, three if by the Internet.”
 
 
 --
 Richard Levitte
 levi...@openssl.org
 
 
 --
 Richard Levitte
 levi...@openssl.org
 


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

Re: [openssl-dev] [openssl.org #3882] [BUGFIX] lh_SSL_SESSION_delete() not checked

[Short, Todd]

No,

The second code sample removes a matching instance, but not necessarily the 
same instance. If they are not the same instance, then it would need to be 
re-inserted in and else clause. 

This is a fine distinction. 

This would leave to having the list and hash not contain the same contents: 
Either the number of items is different, or the two sets of items are 
different. 

There's a similar example in the code, I believe, but I'd have to search for 
it. 

--
-Todd Short
// tsh...@akamai.com
// Sent from my iPhone
// One if by land, two if by sea, three if by the Internet.


 On May 31, 2015, at 12:43 PM, Richard Levitte via RT r...@openssl.org wrote:
 
 You solution does the following:
 
 if (lh_SSL_SESSION_retrieve(p-cache, s) == s) {
 (void)lh_SSL_SESSION_delete(p-cache, s);
 ...
 
 Would you agree that the following does the same?
 
 if (lh_SSL_SESSION_delete(p-cache, s) == s) {
 ...
 
 
 On Sat May 30 09:48:06 2015, tsh...@akamai.com wrote:
 Hello OpenSSL Org:
 
 This is a change that Akamai has made to its
 implementation of OpenSSL.
 
 Version: master branch
 Description:
 lh_SSL_SESSION_delete() not checked
 
 Fix an OpenSSL issue where the
 return code of lh_SSL_SESSION_delete()
 is not checked, causing a
 stale reference in the lhash.
 
 Github link:
 https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc
 And attachment.
 
 Thank you.
 --
 -Todd Short
 // tsh...@akamai.com
 // “One if by land, two if by sea, three if by the Internet.”
 
 
 --
 Richard Levitte
 levi...@openssl.org
 
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev