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

[Emilia Käsper]

This is happening NOW :)

https://github.com/openssl/openssl/pulls?q=is%3Apr%20label%3Acode-health

On Mon, Feb 27, 2017 at 4:24 PM Richard Levitte <levi...@openssl.org> wrote:

> I'd suggest prefixing the PR subject with "code-health:" or
> "[code-health]", just like work in progress is prefixed "WIP:" or
> "[WIP]"
>
> Cheers,
> Richard
>
> In message <9ecbf19a-3239-440c-b874-b959b6bb9...@akamai.com> on Mon, 27
> Feb 2017 14:54:09 +, "Short, Todd" <tsh...@akamai.com> said:
>
> tshort> I’m not sure us mere mortals can add a label to a PR...
> tshort> --
> tshort> -Todd Short
> tshort> // tsh...@akamai.com
> tshort> // "One if by land, two if by sea, three if by the Internet."
> tshort>
> tshort> On Feb 27, 2017, at 5:04 AM, Emilia Käsper <emi...@openssl.org
> >
> tshort> wrote:
> tshort>
> tshort>
> tshort>
> tshort>
> tshort> Hi OpenSSL developers!
> tshort>
> tshort> We’re always looking for ways to improve code quality and pay
> our
> tshort> technical debt. This week we thought we’d run a little
> experiment.
> tshort>
> tshort> We declare this Tuesday (Feb 28th) Code Health Tuesday. We’ll
> be
> tshort> setting some time aside to do cleanups in the codebase. The
> theme
> tshort> is “Delete”: we’ll be cleaning up unused files, dead code, and
> tshort> obsolete hacks. We invite you all to participate on Github!
> tshort>
> tshort>
> tshort> Cheers,
> tshort> Emilia
> tshort>
> tshort> FAQ:
> tshort>
> tshort> Q: How do I participate?
> tshort> A: Find something to delete. Create a Github pull request and
> add
> tshort> the “code-health” label. We’ll be monitoring Github for quick
> tshort> turnaround.
> tshort>
> tshort> Q: Which branches should I target?
> tshort> A: You should target master. In stable branches, code churn
> comes
> tshort> with a cost, so let’s focus on the next release.
> tshort>
> tshort> Q: What can I delete?
> tshort> A: Normal compatibility rules apply. You cannot delete anything
> tshort> from public headers, remove command-line tool options or prune
> tshort> supported platform configurations. You can delete dead code,
> tshort> obsolete workarounds (16-bit platforms!) and outdated
> tshort> documentation. If you’re not sure about a particular
> tshort> functionality, open a Github issue and add the “code health”
> tshort> label.
> tshort>
> tshort> Q: Do you have any tools to find what to delete?
> tshort> A: We have a coverage report:
> tshort> https://coveralls.io/github/openssl/openssl
> tshort> We’ll also be setting up a tools repo where you can share any
> tshort> tools that you build.
> tshort>
> tshort> Q: Will you do it again?
> tshort> A: We hope so! This is an experiment but we’ll be looking into
> tshort> making it a habit. We have a list of ideas for themed Tuesdays
> tshort> lined up: Document, Test, Refactor, ...
> tshort>
> tshort> Q: How did you come up with this idea?
> tshort> A: We were looking at this file…
> tshort>
> https://github.com/openssl/openssl/blob/master/crypto/pkcs7/pk7_dgst.c
> tshort>
> tshort> --
> tshort> openssl-dev mailing list
> tshort> To unsubscribe:
> tshort> https://mta.openssl.org/mailman/listinfo/openssl-dev
> tshort>
> 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] Participate in Code Health Tuesday (tomorrow, Feb 28th)

[Emilia Käsper]

Ah... Well, just add "Code Health" to your PR title, and we'll do the
labeling.

On Mon, Feb 27, 2017 at 3:54 PM Short, Todd <tsh...@akamai.com> wrote:

> 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 <emi...@openssl.org> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__coveralls.io_github_openssl_openssl=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=13nqmVuCNoNG9k4QVgE5mgd1cfBW9qihs8MSZ8JrXIM=MyxZLYoIPNgIVwojq5YuUwF4zW5oHhuq79iGx-CpFNE=>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_blob_master_crypto_pkcs7_pk7-5Fdgst.c=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik=13nqmVuCNoNG9k4QVgE5mgd1cfBW9qihs8MSZ8JrXIM=X7rAKijz4Sb6PLyqD87MXKi1Xrs3vJN7bFdk2ZJT2RY=>*
>
> --
> 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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Emilia Käsper]

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] [openssl.org #4242] OpenSSL ECC coordinate functions accept invalid curve points

[Emilia Käsper via RT]

Done in 1e2012b7ff4a5f12273446b281775faa5c8a1858, thanks for the nudge.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4242
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 #4393] [PATCH] Call EC_GROUP_order_bits in priv2opt.

[Emilia Käsper via RT]

Merge RT4241 here as these are best handled together.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4393
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 #4506] Add SSL_CTX_get_ciphers() [GitHub PR #957]

[Emilia Käsper via RT]

Resolving, this has been merged.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4506
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 #4433] Memory leak in X509_REQ_to_X509

[Emilia Käsper via RT]

X509_REQ_to_X509 returns a newly allocated X509 structure.

If you believe that it leaks somewhere else, then please reopen this ticket
with fully self-contained code, and a trace (e.g., from valgrind) showing where
the leak happens.

Emilia

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4433
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 #4393] [PATCH] Call EC_GROUP_order_bits in priv2opt.

[Emilia Käsper via RT]

Merged. (Please reopen if you think we should also follow up in the other
direction.)

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4393
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 #4393] [PATCH] Call EC_GROUP_order_bits in priv2opt.

[Emilia Käsper via RT]

While we're at this, shouldn't we then also check the length in oct2priv? (And
either reject or reduce mod n.) Afaics it accepts arbitrary BNs currently,
which means some keys can be parsed but cannot be re-encoded?

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4393
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] Running against BoringSSL's SSL test suite

[Emilia Käsper]

FYI for easier use, this patch now lives at
https://github.com/google/openssl-tests, rebased against BoringSSL latest
(thanks David!) and OpenSSL-1.1.0-pre4 (Beta 1). I've also checked in a log
from Beta 1.

Cheers,
Emilia

On Thu, Mar 10, 2016 at 4:33 PM David Benjamin  wrote:

> On Thu, Mar 10, 2016 at 1:30 AM Kanaka Kotamarthy 
> wrote:
>
>> And also Openssl fails with Resume-Client-NoResume cases. Do you have
>> any report on which test cases do fail and reasons for the failure?
>>
>>
>> RT tickets 4387 through 4395 were the failures I've triaged. I'm sure
>> there's more things in there to look through.
>>
>> I don't believe Resume-Client-NoResume fails for me. Perhaps something
>> was fixed between master and 1.1.0-pre2.
>>
>>
>> Openssl doesn't gives any error. For Resume-Client-NoResume-SSL3-TLS11
>> test case, we expect the new session's handshake to be done with TLS11. But
>> with Openssl handshake is done using SSL3. As in ssl3_clear, we set back
>> s->version to s->method->version.
>>
>
> Oh, sorry, I keep forgetting our runner doesn't make it clear when a -test
> option fails to match anything. (I should fix that...) I looked
> for Resume-Client-NoResume without noticing it had suffixes. :-)
>
> I would expect most things addResumptionVersionTests to fail. See
> https://github.com/openssl/openssl/pull/603
>
> David
>
>
>> Thank you
>> Durga.
>>
>> On Wed, Mar 9, 2016 at 10:38 PM, David Benjamin 
>> wrote:
>>
>>> On Wed, Mar 9, 2016 at 5:07 AM Kanaka Kotamarthy 
>>> wrote:
>>>
 Hi

 I am even testing OpenSSL with BoringSSL's test cases using
 Openssl-1.1.0-pre2. Trying to find out reasons of OpenSSL's failures
 for particular cases.

 DTLS 1.0 session resumption has some thing wrong. If s_server started
 with -dtls and s_client -dtls1 -reconnect , session resumption is not
 being done. The reason for this may be, version negotiation for DTLS
 is done after loading previous session and check for s->version and
 s->session->version fails in tls_process_client_hello.

>>>
>>> See RT #4392.
>>> https://rt.openssl.org/Ticket/Display.html?id=4392
>>>
>>>
 And also Openssl fails with Resume-Client-NoResume cases. Do you have
 any report on which test cases do fail and reasons for the failure?

>>>
>>> RT tickets 4387 through 4395 were the failures I've triaged. I'm sure
>>> there's more things in there to look through.
>>>
>>> I don't believe Resume-Client-NoResume fails for me. Perhaps something
>>> was fixed between master and 1.1.0-pre2.
>>>
>>> David
>>>
>>>
 Thank you
 Durga.

 On Tue, Mar 8, 2016 at 3:19 AM, David Benjamin 
 wrote:
 > Hi folks,
 >
 > So, we've by now built up a decent-sized SSL test suite in BoringSSL.
 I was
 > bored and ran it against OpenSSL master. It revealed a number of
 bugs. One
 > is https://github.com/openssl/openssl/pull/603. I'll be filing
 tickets
 > shortly for the remaining ones I've triaged, but I thought I'd send
 this
 > separately rather than duplicate it everywhere.
 >
 > Emilia also suggested there may be room to collaborate on testing. If
 > nothing else, just borrowing ideas or porting tests to/from your
 TLSProxy
 > setup. (Like, say, the ones that caught the bugs I'll be reporting.
 :-) )
 > So, here's an introduction on how it all works:
 >
 > To run the tests on OpenSSL, clone BoringSSL:
 > https://boringssl.googlesource.com/boringssl/
 > Then patch in this change. (Click the "Download" in the upper-right
 for
 > options.)
 > https://boringssl-review.googlesource.com/#/c/7332/
 > Then follow the instructions in the commit message.
 >
 > The tests themselves and the runner logic live in
 ssl/test/runner/runner.go:
 >
 https://boringssl.googlesource.com/boringssl/+/22ce9b2d08a52e399bf2ab86851952d727be034d/ssl/test/runner/runner.go#922
 >
 > They work by running an unmodified TLS stack in a shim binary against
 a copy
 > of Go's. We patch our copy with options for weird behavior to test
 against:
 >
 https://boringssl.googlesource.com/boringssl/+/22ce9b2d08a52e399bf2ab86851952d727be034d/ssl/test/runner/common.go#414
 >
 > Go and shim communicate entirely with sockets and (tons of)
 command-line
 > flags, though it is slightly overfit to BoringSSL's behavior and
 checks
 > error strings a lot. The shim also has options like -async mode which
 we use
 > on a subset of tests to stress state machine resumption. (This has
 saved me
 > from state machine bugs so many times.)
 >
 https://boringssl.googlesource.com/boringssl/+/22ce9b2d08a52e399bf2ab86851952d727be034d/ssl/test/runner/runner.go#2770
 >
 

Re: [openssl-dev] Please consider delaying the Beta-1 freeze for a week or two

[Emilia Käsper]

Returning to the issue at hand:

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

On Fri, Mar 11, 2016 at 7:24 PM Erik Forsberg  wrote:

> add Solaris to the platforms that are not at beta-level yet.
> Richard Levitte and myself are helping each other out though, so we should
> be close
>
> >-- Original Message --
> >
> >> noloader> Testing master on real hardware is showing some minor issues
> on a few
> >> noloader> platforms, including ARM32, ARM64, PowerPC and i686. In
> addition,
> >> noloader> there seems to be one-off issues on other combinations, like
> VIA's C7
> >> noloader> processor on Linux.
> >> noloader>
> >> noloader> In addition to the base issues, there are other minor issues
> like
> >> noloader> failing to configure and compile with 'no-comp'. Other
> configuration
> >> noloader> dependent issues include failed self tests under PowerPC in a
> shared
> >> noloader> configuration.
> >> noloader>
> >> noloader> Please consider delaying the freeze for a week or two while
> the issues
> >> noloader> are being ironed out.
> >>
> >> The upcoming release is the first beta of two planned, and we've
> >> already delayed the first for a few extra days.  It is not a final
> >> release, so there's still time to fix things like these.
> >>
> >> Please see the bottom of the release strategy for the planned dates:
> >>
> >> http://openssl.org/policies/releasestrat.html
> >
> >Well, would it be possible to survey supported platforms and see if it
> >makes sense to move forward at this point? Does the library maintain a
> >matrix of test platforms and results?
> >
> >Releasing a Beta-1 seems like its missing the point if the the point
> >of the beta is to test it. There are issues in {configure|build|test}
> >on ARM32, ARM64, OpenBSD, Windows and some Linux i686 and x86_64
> >targets/configurations. I'm also wondering about MIPS, NetBSD, FreeBSD
> >and Gentoo.
> >
> >Maybe something else to ponder in the big picture of release
> >engineering... Why are the breaks occurring and not being caught? Why
> >is the engineering process not catching them?
> >
> >(I think its OK to break things on occasion. You can't make an omelet
> >without breaking eggs. But the idea is you have to catch them quickly
> >and early before the user experiences the pain point. If the break is
> >fixed before the user experiences the pain, then it "no blood, no
> >foul" in my book).
> >
> >There's no need to rush the process. OpenSSL does not answer to anyone
> >except its own quality standards. It seems like stepping back, coming
> >up for some air, catching your breath and then diving back in will
> >produce better results in the end.
> >
> >Jeff
> >--
> >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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[Emilia Käsper via RT]

Yep, there is no need to clean up early here (we don't guarantee that errored
calls leave everything in a pristine unmodified state). Plus this does indeed
forget to zero the pointer. Closing. Thanks for submitting, though, and thanks
David for the review!

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
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] cipher order

[Emilia Käsper]

On Fri, Mar 4, 2016 at 11:00 PM Viktor Dukhovni <openssl-us...@dukhovni.org>
wrote:

>
> > On Mar 4, 2016, at 3:57 PM, Emilia Käsper <emi...@openssl.org> wrote:
> >
> > I've updated the pull to do a much more substantial cleanup.
>
> What will @STRENGTH mean in this context?  Will ignore
> the distinction between AES256 and AES128?


@STRENGTH will sort it back by symmetric encryption key strength. Which is
a bit of a bummer but I have no good answer for how to avoid it, because
this is what @STRENGTH's contract promises to do.

What does this
> do to the @SECLEVEL interface which tries to provide
> NIST-compatible bit strengths across multiple features?
>

@SECLEVEL will continue to work as expected, i.e., it will filter out the
ones that don't meet the level.

(@SECLEVEL operates directly on the cert, and does nothing to the
cipherlist alone. Which results in misleading output from the 'ciphers'
app, but that is a separate bug.)


>
> Or we just changing the default order, and allowing
> @STRENGTH to perturb it back, and @SECLEVEL to prune-away
> 128 leaving just 256, ...
>
> In other words how does this fit into the larger picture?


The ordering affects lists built from the predefined groups - ALL, DEFAULT,
HIGH, MEDIUM, LOW etc. More generally, it sorts each cipher group separated
by the ':'.

For example, if you do 'CAMELLIA:AES' then you get CAMELLIA ciphers sorted
by this preference, followed by AES ciphers sorted by this preference., and
if you do 'CAMELLIA:AES@STRENGTH' then - sadly - you get the symmetric
strength-sort back.

We could add a variant of @STRENGTH that re-sorts by our internal implicit
preferences (which we're allowed to change at any time), but that's not
going to happen for 1.1.0.

It is, however, possible, to achieve the same effect in multiple ways
already:
- start from DEFAULT, and remove more ciphers, e.g.

"DEFAULT:!3DES:!AES128"

- Or, if you want a superset of DEFAULT, start from ALL, and remove some
ciphers:

"ALL:!MEDIUM:!LOW:!aNULL:!eNULL:!IDEA:!SEED"

Both of these operations will preserve the preferences.

Anyway, the goal here is to improve the situation *if the user does
nothing*. It does not solve all the other problems of the API, but it does
not make them worse.

Emilia



> --
> 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] cipher order

[Emilia Käsper]

I've updated the pull to do a much more substantial cleanup.

On Thu, Mar 3, 2016 at 6:16 PM Emilia Käsper <emi...@openssl.org> wrote:

> Hm, I think that I actually agree. But David's done enough, so I'll have a
> look myself.
>
> On Thu, Mar 3, 2016 at 5:33 PM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
>> On 3/3/16, 11:30 , "openssl-dev on behalf of Hanno Böck"
>> <openssl-dev-boun...@openssl.org on behalf of ha...@hboeck.de> wrote:
>>
>> >On Thu, 03 Mar 2016 16:18:57 + Emilia Käsper <emi...@openssl.org>
>> >wrote:
>> >>https://github.com/openssl/openssl/pull/783
>> >
>> >This is different from what I had in mind.
>> >...
>> >I would argue that cbc/hmac is so fragile that it's always preferrable
>> >to have aead before cbc/hmac. The security difference between 128 and
>> >256 bit aes is imho mostly irrelevant in practice.
>>
>> Again, +1
>>
>> Perhaps David can do his magic again? :-)
>> --
>> 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 #4362] chacha-x86.pl has stricter aliasing requirements than other files

[Emilia Käsper]

On Fri, Mar 4, 2016 at 12:48 PM Andy Polyakov via RT  wrote:

> > If the other EVP ciphers universally allow this then I think we must
> treat this
> > as a bug, because people may be relying on this behaviour. There is also
> > sporadic documentation in lower-level APIs (AES source and des.pod) that
> the
> > buffers may overlap.
> >
> > If it's inconsistent then, at the very least, we must document that it
> is not
> > allowed.
>
> I'd like to argue that EVP is not place to provide any guarantees about
> partially overlapping buffers. Even though all current ciphers process
> data in ascending address order, we shouldn't make assumption that there
> won't be one that processes data in reverse order.


I'm afraid that, since we haven't documented it, the world may already have
made that assumption.


> I'd even argue that
> not providing such guarantee is natural, i.e. can be naturally
> *implied*. Just like you may not expect a tablet to work after you glued
> wheels to it to make a skateboard, arguing that nowhere does it say that
> it's not a viable idea. It might work, and apparently did for somebody,
> but you may not *expect* it to, neither as tablet or skateboard. And
> tablet manufacturer has no obligation to disclaim it in writing.
>
> I'm not saying that this particular problem can't/won't be addressed,
> though I consider it kind of bad style. Because it kind of sets a
> precedent of creating an undesired illusion. BTW, further measurements
> have shown that unlike others, Core2 suffers 20% performance regression.
> Well, one can argue that nobody cares about Core2, but what if it was
> contemporary processor?
>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362
> 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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] cipher order

[Emilia Käsper]

Hm, I think that I actually agree. But David's done enough, so I'll have a
look myself.

On Thu, Mar 3, 2016 at 5:33 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> On 3/3/16, 11:30 , "openssl-dev on behalf of Hanno Böck"
> <openssl-dev-boun...@openssl.org on behalf of ha...@hboeck.de> wrote:
>
> >On Thu, 03 Mar 2016 16:18:57 + Emilia Käsper <emi...@openssl.org>
> >wrote:
> >>https://github.com/openssl/openssl/pull/783
> >
> >This is different from what I had in mind.
> >...
> >I would argue that cbc/hmac is so fragile that it's always preferrable
> >to have aead before cbc/hmac. The security difference between 128 and
> >256 bit aes is imho mostly irrelevant in practice.
>
> Again, +1
>
> Perhaps David can do his magic again? :-)
> --
> 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] cipher order

[Emilia Käsper]

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

Courtesy of David Benjamin.

On Thu, Mar 3, 2016 at 4:34 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

> +1
>
> Sent from my BlackBerry 10 smartphone on the
> Verizon Wireless 4G LTE network.
>   Original Message
> From: Hanno Böck
> Sent: Thursday, March 3, 2016 07:28
> To: openssl-dev@openssl.org
> Reply To: openssl-dev@openssl.org
> Subject: [openssl-dev] cipher order
>
> Hi,
>
> Last year I proposed to change the ciphering order in OpenSSL to always
> prefer AEAD cipher suites before CBC/HMAC-based ones:
> https://mta.openssl.org/pipermail/openssl-dev/2015-January/000421.html
>
> I just checked openssl 1.1.0 alpha and it still orders ciphers in an
> imho problematic way.
>
> Browsers have largely decided to implement GCM-modes only with AES128.
> Chrome is now about to change that. Not sure if other browsers will
> follow.
>
> Right now if you configure a server with openssl's cipher suite
> ordering it is likely that a connection will happen with AES256 in CBC
> mode instead of the (most likely more secure) AES128 in GCM mode.
>
> Can this be changed before 1.1.0 gets out?
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: BBB51E42
>
> --
> 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 #4362] chacha-x86.pl has stricter aliasing requirements than other files

[Emilia Käsper via RT]

If the other EVP ciphers universally allow this then I think we must treat this
as a bug, because people may be relying on this behaviour. There is also
sporadic documentation in lower-level APIs (AES source and des.pod) that the
buffers may overlap.

If it's inconsistent then, at the very least, we must document that it is not
allowed.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362
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 #3854] openssl.cnf in openssl-1.0.1m still uses default_bits=1024

[Emilia Käsper via RT]

We cleaned this up a little:

- crypto/conf/ssleay.cnf was obsolete and is gone from the master branch.
- the req app now uses 2048 bits as a default if no other defaults are given.

ssleay.txt is already gone from the master branch, and the test/ ones are used
in tests.

Cheers,
Emilia

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3854
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 #3095] Incorrect result in HMAC functions when key is null

[Emilia Käsper via RT]

Fixed in master now, commit b1413d9bd9d823ca1ba2d6cdf4849e635231

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

[openssl-dev] [openssl.org #3234] [bug] openssl defaults to using tls compression

[Emilia Käsper via RT]

1.1.0 now defaults to no compression: dc5744cb78da6f2bcafeeefe22c604a51b52dfc5.

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

[openssl-dev] [openssl.org #4148] PCKS1 type 1 Padding check error

[Emilia Käsper via RT]

Resolved in ba2de73b185016e0a98e62f75b368ab6ae673919 for master (1.1.0). This
isn't really a bug so we won't be backporting to stable branches, though.

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

[openssl-dev] [openssl.org #4078] remove MDC2 support (1.1 dev branch)

[Emilia Käsper via RT]

This was rejected by the team.

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

[openssl-dev] [openssl.org #3854] openssl.cnf in openssl-1.0.1m still uses default_bits=1024

[Emilia Käsper via RT]

1.0.1m predates Logjam. We changed DH key generation to use 2048 bits by
default in OpenSSL 1.0.1n which is the first 1.0.1 release after.

The default_bits in apps/openssl.cnf is a sample certificate request
configuration and isn't really related to Logjam. But we changed it as well as
other key generation apps to use 2048 bits more comprehensively in 1.0.2.

More context:
https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/

All these other conf files look like very old demo examples. They should
probably be cleaned up. I'm leaving this ticket open to remind us.

Cheers,
Emilia

___
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

[Emilia Käsper]

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

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

Emilia

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

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

[Emilia Käsper]

On Tue, Nov 17, 2015 at 11:12 AM, Jeffrey Walton  wrote:

> > MD2 - (The argument that someone somewhere may want to keep verifying old
> > MD2 signatures on self-signed certs doesn't seem like a compelling enough
> > reason to me. It's been disabled by default since OpenSSL 1.0.0.)
> > ...
> Apple still provides two Verisign certificates using
> md2WithRSAEncryption. Confer,
> https://support.apple.com/en-us/HT203065.
>

Setting aside the debate of whether verifying trust store signatures is
useful, whether verifying MD2 signatures has any practical security value,
or whether OpenSSL + iOS is a meaningful combination:

This is iOS7. The current release is iOS9 (trust store here:
https://support.apple.com/en-us/HT205205, MD2 certs are gone).

Arguments like this illustrate a fundamental misunderstanding in this
thread. We are not pulling the carpet from any users TODAY. We are asking
whether there are applications that will need this code 2..3..5 years down
the line. When I referred to the fact that users of 1.1 will have to
recompile, I didn't mean that errors would be revealed by recompilation. I
meant that you would have to be an actively maintained application or
library, and be doing a new release, and be stuck using an old algorithm,
to even be impacted by this change.




> Jeff
> ___
> 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] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Emilia Käsper]

Thanks all for your feedback!

I asked for mainstream use-cases for algorithms whose removal could cause
widespread pain. Some individual users, undoubtedly, will be hit by this,
and I acknowledge that they may not be reading this list. But I wanted to
know if I'd missed something endemic. I also asked elsewhere: Adam Langley
pointed me to the MD4 use-case and Steve confirmed that RC2 must stay.

There is a tradeoff: by attempting to accommodate every single use-case, we
will weaken the library for a substantial amount of our user base, by
offering them bad defaults, or simply by virtue of the fact that our
developer resources are not infinite. (Near)-dead code is a liability.

So far, excluding suspicions that something may be used somewhere, I've
received one clear argument, for RC5. And, while I'm sympathetic to the
cause, I believe this is the case where we have to balance one user's needs
against everyone else's.

As for specific deprecation strategies:
- Don't forget that all applications will have to recompile against 1.1.

- Disabling algorithms doesn't work well for us as it's just pushing the
decision on the distros. It also wouldn't win us any resources as we'd
still be responsible for keeping the code bug-free. The only win would be
in default compiled code size.

- We can leave OPENSSL_NO_XXX defines around so wrapper libraries (Python,
PHP etc) who correctly account for the fact that an implementation may be
missing (which they have to, anyway) will continue to work.

- Removing assembly support is a GREAT suggestion to simplify the
complexity, and I think we should do this for anything we end up leaving
in, and perhaps even for some things not yet on the hit list (RC4?).

- I appreciate OpenSSL's role as a "Swiss army knife" research tool but
research needs shouldn't prevail over those of real applications. We are
generally not on the frontline of deprecating things - RC4 isn't yet on the
list. SSLv3 isn't yet on the list, etc. But we can't become the Internet
Archive of All Old Crypto either, and there's some cleanup to do that's
long overdue.

- I believe that the OpenSSL community generally tends to overlook the
positive impact of change when trying to round up the negative impact of
breakage. Applications are generally able to move along and fix things when
presented with the right incentives. Applications that aren't generally
able to move along are rather unlikely to jump onto OpenSSL 1.1, and all
these algorithms will be supported as part of OpenSSL 1.0.2 until 2020 for
them. Finally, removing support for these algorithms from OpenSSL doesn't
render your encrypted storage inaccessible. You can always use another
implementation to decrypt/re-encrypt your data, and I fully believe in the
power of the community in providing such tools where necessary.

- Recent anecdotal evidence: OpenSSL's Logjam protection caused pretty
widespread MySQL breakage. That made MySQL backport a change increasing the
DH key length from 512 to 2048 bits. For end user security, it's a win. I
would prefer that we start cashing in these improvements before the next
Logjam happens. (This is my view; as you can see views differ even within
the team.)

- On binary elliptic curves: with recent cryptographic advances, I believe
these are now firmly planted in the "internet archive" category, even if
not practically broken yet. The other reason for removing these is that our
implementations are crappy. They're not constant-time, and they've been
shown to contain bugs. Improving upon these implementations is not a good
use of dev time imo, given their decreasing credibility.

Here's the list of algorithms gone from BoringSSL:

IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves

This isn't of course entirely representative of widespread usage. However
Google's multi-billion line codebase now builds against BoringSSL and
therefore largely does not depend on these algorithms. Those billions of
lines aren't all new and shiny code written in 2015, and some of it does
have to interoperate with the outside world.

And here's the list gone from LibreSSL, from what I can tell:

MD2, MDC2, RC5, SEED

Neither have removed CAST, and there is presumably a good reason for that.
(PGP?)

It seems to me that these can pretty safely go:

MD2 - (The argument that someone somewhere may want to keep verifying old
MD2 signatures on self-signed certs doesn't seem like a compelling enough
reason to me. It's been disabled by default since OpenSSL 1.0.0.)
MDC2
SEED
RC5

These could probably stay (C only):

CAST
IDEA
RIPEMD (used in Bitcoin?)
WHIRLPOOL

as well as

BLOWFISH
MD4
RC2

I am on the fence about the binary curves: I am not aware of any usage,
really, and it's not about to pick up now.

Cheers,
Emilia

On Mon, Nov 16, 2015 at 2:21 PM, Hubert Kario <hka...@redhat.com> wrote:

> On Friday 13 November 2015 14:40:33 Emilia Käsper wrote:
> > Hi all,
> >
> > We are considering rem

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

[Emilia Käsper]

One more time,

I know that someone, somewhere is probably using any given feature of
OpenSSL. I am looking to gather information about concrete, actively
maintained applications that may be using one of those algorithms, to build
a more complete picture.

If you are aware of a concrete use of MD2 or any of the other algorithms,
please let us know!

Thanks,
Emilia

On Mon, Nov 16, 2015 at 7:25 PM, Hubert Kario <hka...@redhat.com> wrote:

> On Monday 16 November 2015 16:51:10 Emilia Käsper wrote:
> > IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves
> >
> > This isn't of course entirely representative of widespread usage.
> > However Google's multi-billion line codebase now builds against
> > BoringSSL and therefore largely does not depend on these algorithms.
> > Those billions of lines aren't all new and shiny code written in
> > 2015, and some of it does have to interoperate with the outside
> > world.
> >
> > And here's the list gone from LibreSSL, from what I can tell:
> >
> > MD2, MDC2, RC5, SEED
> >
> > Neither have removed CAST, and there is presumably a good reason for
> > that. (PGP?)
> >
> > It seems to me that these can pretty safely go:
> >
> > MD2 - (The argument that someone somewhere may want to keep verifying
> > old MD2 signatures on self-signed certs doesn't seem like a
> > compelling enough reason to me. It's been disabled by default since
> > OpenSSL 1.0.0.) MDC2
> > SEED
> > RC5
> >
> > These could probably stay (C only):
> >
> > CAST
> > IDEA
> > RIPEMD (used in Bitcoin?)
> > WHIRLPOOL
> >
> > as well as
> >
> > BLOWFISH
> > MD4
> > RC2
> >
> > I am on the fence about the binary curves: I am not aware of any
> > usage, really, and it's not about to pick up now.
>
> I'm afraid you're too focused on TLS/SSL use case. And while it is
> important it's not the only use case the OpenSSL does serve.
>
> And for what it's worth, I'm very much *for* removing as much (and as
> fast as possible) support for the old junk (or unused stuff - like
> curves < 256 bit) in TLS. Search the archives for "Insecure DEFAULT
> cipher set" for an example.
>
> But stuff like this:
>
> > The argument that someone somewhere may want to keep verifying
> > old MD2 signatures on self-signed certs
>
> is not true. I was talking about document signatures, time stamps, CRL
> signatures and certificate signatures in general. Not the trust anchors
> or their self-signatures.
>
> --
> 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

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

[Emilia Käsper]

Hi all,

We are considering removing from OpenSSL 1.1 known broken or outdated
cryptographic primitives. As you may know the forks have already done this
but I'd like to seek careful feedback for OpenSSL first to ensure we won't
be breaking any major applications.

These algorithms are currently candidates for removal:

CAST
IDEA
MDC2
MD2 [ already disabled by default ]
RC5 [ already disabled by default ]
RIPEMD
SEED
WHIRLPOOL
ALL BINARY ELLIPTIC CURVES

My preference would be to remove these algorithms completely (as in, delete
the code). Disabled-by-default code will either be re-enabled by distros
(if there's widespread need for it - in which case we might as well leave
it in) or will be poorly tested and is likely to just silently rot and
break. This code is bloat and maintentance burden for us - my hope is that
much of this code is effectively dead and can be removed.

*Are you aware of any mainstream need to continue supporting these
algorithms in OpenSSL 1.1?* Note that an older OpenSSL library or binary,
or a standalone implementation or another crypto toolkit can always be used
to continue supporting a legacy standalone application, or to decrypt
ciphertext from the distant past. I am looking for use cases that could
cause e.g. interop breakage between new and old peers, or major pain to
distro end-users.

These algorithms are obsolete but removing them doesn't look feasible:

BLOWFISH - probably still in use though I don't know where exactly?
MD4 - used in NTLM
RC2 - used in PKCS#12

*Did I miss anything from the list?*

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

[openssl-dev] [openssl.org #3645] openssl-1.0.1h-cmp - Linking issue

[Emilia Käsper via RT]

Thanks Martin. (Re-closing the ticket.)

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

[openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

[Emilia Käsper via RT]

Given OpenSSL's eternal type confusion, this check is meant to trap callers
that get an error return (typically -1) from some API returning signed values
and pass that on to PACKET_buf_init as a size_t. For example, ssl3_get_message
returns a long to signal buffer length, and that makes me nervous.

Except, yeah, it relies on undefined behaviour. OTOH as you note we do have a
test for this and we've not seen it fail on any compiler.

I agree the check is pointless if your sizes are correctly represented as
size_t throughout, but perhaps marginally useful for OpenSSL in its current
state. I don't feel too strongly about keeping or removing it - what do others
think?

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

[openssl-dev] [openssl.org #3138] 80-bit Elliptic Curves with !MEDIUM !LOW !EXP cipher list

[Emilia Käsper via RT]

Curves aren't negotiated with the ciphersuite, but rather via a separate
extension. Since OpenSSL 1.0.2, there are
SSL_CTX_set1_curves and SSL_CTX_set1_curves_list to configure supported curves:

https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_ecdh_auto.html

OpenSSL 1.1 also has a security levels API in the works to make this sort of
configuration easier.

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

[openssl-dev] [openssl.org #3645] openssl-1.0.1h-cmp - Linking issue

[Emilia Käsper via RT]

 openssl-1.0.1h-cmp isn't an official OpenSSL version. You should seek help
with whoever provides this library for you.

Cheers,
Emilia

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

[openssl-dev] [openssl.org #3013] Sending SCSV when TLS extensions are disabled

[Emilia Käsper via RT]

Rejecting - SCSV is not a TLS extension.

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

[openssl-dev] [openssl.org #3731] BUG darwin FIPS openssl-1.0.2 ssl/t1_lib.c line 472

[Emilia Käsper via RT]

This was fixed in January: 6fa805f516f5a6ff3872f1d1014a3dc9de460b99

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

[openssl-dev] [openssl.org #4095] X509_STORE_get_by_subject crash

[Emilia Käsper via RT]

This sounds like an application problem.
1) Did you recompile your source? 0.9.7 and 1.0.1 are not binary-compatible.
2) The certificate hash format has changed between 1.0.1 and 0.9.7, which could
explain why the lookup no longer works:
https://www.openssl.org/docs/manmaster/apps/rehash.html

If the above isn't helpful, try asking for help on openssl-users@. Rejecting
the ticket (though please reopen if you find new evidence that this is a bug
within OpenSSL).

Cheers,
Emilia

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

[openssl-dev] [openssl.org #3896] unable to install to openssldir

[Emilia Käsper via RT]

Nope, not doing anything wrong. makedepend is bust and can't find the headers.
Our clang and OS/X configurations were a bit off - I've changed them to use
clang for 'make depend' as well when clang is the compiler, see commit
c97c7f8d53dda12f4fda24fc7542281999df97f6.

Cheers,
Emilia

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

[openssl-dev] [openssl.org #2923] X509_cmp() introduces unnecessary dependency on SHA1

[Emilia Käsper via RT]

Thanks for the report. This has now been addressed in 1.0.1+, see commit
bfc19297cddd5bc2192c02c7f8896d804b0456cb.

Cheers,
Emilia

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

[openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c)

[Emilia Käsper via RT]

Closing, not an OpenSSL defect.

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

[openssl-dev] [openssl.org #3987] Bug report about crash related to ASN1_primitive_free

[Emilia Käsper via RT]

I'm afraid we can't tell from your report whether the bug is in OpenSSL or in
your application code. We need a reproducible report - for example, a
standalone code snippet, or a sample input to the openssl command-line tool.

Cheers,
Emilia

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

[openssl-dev] [openssl.org #4060] a crash happened inside SSL_Connect function

[Emilia Käsper via RT]

Closing, because it's not an OpenSSL defect, but feel free to continue the
discussion on openssl-users.

Cheers,
Emilia

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

[openssl-dev] [openssl.org #4078] remove MDC2 support (1.1 dev branch)

[Emilia Käsper via RT]

Tracking ticket - if anyone has any concerns, please voice them now.

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

[openssl-dev] [openssl.org #2772] Bug w/ patch: OpenSSL 1.0.1 rejects empty NewSessionTicket

[Emilia Käsper via RT]

You're spot on, thanks for the report! The fix ended up being slightly
different, but this is now fixed in 1.0.1+.

Cheers,
Emilia

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

[openssl-dev] [openssl.org #3757] OpenSSL decodes malformed base64 encoded inputs

[Emilia Käsper via RT]

Wow, thanks for the thorough report. This was so broken that I had to go for a
pretty major rewrite. Please take a look at commits
3cdd1e94b1d71f2ce3002738f9506da91fe2af45 and
b785504a10310cb2872270eb409b70971be5e76e. (Also cherry-picked to 1.0.2 and
1.0.1.)

All your test cases now pass so I'm resolving this ticket; if you find anything
else, responding to this ticket will reopen it.

Cheers,
Emilia

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

[openssl-dev] [openssl.org #4043] monitoring software depending on openssl not working on cloudflare ssl websites

[Emilia Käsper via RT]

Thanks Rob! Resolving.

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

[openssl-dev] [openssl.org #3754] [OpenSSL bug-report] if malloc failed on EVP_PKEY_new_mac_key() ?

[Emilia Käsper via RT]

Fixed now in OpenSSL 1.0.1+, thanks for the report!

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

[openssl-dev] [openssl.org #3124] potential bug in ssl/s3_cbc.c

[Emilia Käsper via RT]

In the is_sslv3 case, the header length is recomputed to be large enough.

I also note that we've recently added a sanity check to make this explicit, see
commit
29b0a15a480626544dd0c803d5de671552544de6

Sorry that we didn't acknowledge your report!

Cheers,
Emilia

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

[openssl-dev] [openssl.org #3496] report :CVE-2014-0224 security issue not fixed in openssl 1.0.1h

[Emilia Käsper via RT]

CVE-2014-0224 was fixed in 1.0.1h.

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

[openssl-dev] [openssl.org #3484] s3_pkt.c build failure for openssl-SNAP-20140804

[Emilia Käsper via RT]

It's been fixed.

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

[openssl-dev] [openssl.org #2524] openssl 1.0.0d bug report/ query

[Emilia Käsper via RT]

Whatever it was, it's no longer reproducible.

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

[openssl-dev] [openssl.org #3164] [PATCH] require DH group of 1024 bits

[Emilia Käsper via RT]

How prophetic! We now require 768 and will do another bump to 1024 in the near
future, so I'm resolving this ticket.

Cheers,
Emilia

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

[openssl-dev] [openssl.org #2487] Possible bug

[Emilia Käsper via RT]

No evidence that it's an OpenSSL bug. You can try openssl-users@ though I'm
afraid there's not enough detail to resolve the problem there either.

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

[openssl-dev] [openssl.org #3404] Bug report

[Emilia Käsper via RT]

We didn't hear back and there's not enough info to repro; closing.

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

[openssl-dev] [openssl.org #2968] Possible bug report

[Emilia Käsper via RT]

Chain building is complicated, because the issuance graph is complicated: certs
get recertified, cross-signed, etc. Different clients have different trust
stores, and will build different paths.

We recently improved OpenSSL chain building to try more paths:
see https://rt.openssl.org/Ticket/Display.html?id=3621

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

[openssl-dev] [openssl.org #3494] Possible sign bit bug in openssl 1.0.1i handling of 128-bit serial numbers

[Emilia Käsper via RT]

As Rich said, this is according to ASN.1 DER spec. Serial numbers are integral,
and you need 17 bytes to represent this serial number in two's complement form.

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

[openssl-dev] [openssl.org #3092] BUG: Verify return code: 20 (unable to get local issuer certificate) with openssl 1.0.1

[Emilia Käsper via RT]

Probably same as https://rt.openssl.org/Ticket/Display.html?id=2968. We
improved this.

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

[openssl-dev] [openssl.org #3936] Bug (maybe) report

[Emilia Käsper via RT]

OpenSSL attempts to load the master/default conf before diving into the
subcommand and overriding the conf with the config in -config. It'll bail when
it can't read the file, but only warn if the file does not exist.

This seems wrong, and is a regression compared to 0.9.8, so I'm going to leave
this ticket open.

Meanwhile, you can work around it by setting the OPENSSL_CONF environment
variable.

Cheers,
Emilia

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

[openssl-dev] [openssl.org #955] Implementation of SSL_SESSION_get_session_id

[Emilia Käsper via RT]

OpenSSL has SSL_SESSION_get_id since 0.9.8, so resolving this ticket just
before its 11th anniversary.

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

[openssl-dev] [openssl.org #2327] bug report

[Emilia Käsper via RT]

It's been 5 years and we never heard back with more details, so rejecting this
ticket. I suppose it could be CVE-2014-3509, though I can't tell.

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

[openssl-dev] [openssl.org #3727] Question about ECC Patent

[Emilia Käsper via RT]

We can't help you with legal matters:
https://www.openssl.org/docs/faq.html#LEGAL1

Please note that this tracker is for bug reports.

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

[openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2

[Emilia Käsper via RT]

The fix was committed in 995207bedcc58f2fa1bd7c460ee530b92c7dfbfe, so I think
we can resolve this ticket.

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

[openssl-dev] [openssl.org #4021] Openssl. Responding to request tracker: "#502: TXT_DB error number 2" http://rt.openssl.org/Ticket/Display.html?id=502#txn-42752

[Emilia Käsper via RT]

There doesn't seem to be an open action item for OpenSSL here, so resolving
this ticket.

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

[openssl-dev] [openssl.org #4011] OpenSSL: Hanging up with facebook protocol in MirandaNG

[Emilia Käsper via RT]

Hi Pavel,

I'm closing this ticket because there isn't sufficient detail to conclude that
it's an OpenSSL bug, and not a problem with the plugin, or your environment.

You can try asking for help on openssl-users@, though it looks more like a
question for the Miranda NG community.

Emilia

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

[openssl-dev] [openssl.org #3942] Patch to fix issue with HMAC_init_ex in 1.0.1

[Emilia Käsper via RT]

Hm.

You pass in a NULL key. The docs say that a NULL key indicates that we should
reuse the existing key. With a new CTX, there is nothing to reuse, so it seems
reasonable that the call should fail.

If you actually wanted to set up the context with an empty key, you'd have to
pass in a dummy key buffer with a 0 length. This is awkward, otoh, I'm not
really sure why you'd want to do that in practice, so perhaps it's not terribly
important?

It's not a great API but we're bound by the documented contract. So I'm closing
this as Working As Intended. If you think I got it wrong, please reopen.

Cheers,
Emilia

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

Re: [openssl-dev] Minor bug in custom TLS extensions

[Emilia Käsper]

On Wed, Sep 2, 2015 at 3:00 AM, Bill Cox <waywardg...@google.com> wrote:

> On Tue, Sep 1, 2015 at 2:50 PM, Emilia Käsper <emi...@openssl.org> wrote:
>
>> It's not quite clear to me why you'd have to resend parameters on
>> resumption. After all, they are definitive for the session. Best if the
>> draft explicitly specifies resumption behaviour.
>>
>
> I agree the draft should be enhanced to address resumption.  I'll ping the
> ietf list.
>
>
>> It's also not clear to me that the serialized TLS session is the place to
>> store the parameters. Shouldn't they rather be stored at the application
>> level, alongside with the eventual token?
>>
>
> I think everyone is opposed to storing state from the Token Binding
> extension in the TLS session state.  I agree it could be saved higher in
> the application stack in the client, but what if the resumption is with a
> server that does not support Token Binding for some reason?  In that case
> the server ignores the extension and the client knows to disable Token
> Binding because it did not receive the extension from the server.  This is
> how I implemented it locally, but I think this behavior should be clarified
> in the spec.
>

Ah right. Yes, the spec should spell that out.


>
>
>> But setting that aside, the interaction with extended master secret makes
>> using custom extensions for this purpose tricky anyway. Custom extensions
>> don't really support interaction with other extensions; there's no
>> guarantee that you'll end up processing them in the right order.
>>
>> (But I've only skimmed the docs so it's possible I got it all wrong.)
>>
>
> In this case I am lucky.  EMS is baked-in with native support, and all
> native extensions are parsed before all custom extensions.  However, I
> realize this is not gaurenteed behavior.  I should add a test for it...
>

As far as I can see, the OpenSSL client processes extensions in the order
they come in. But nothing is guaranteed.


>
> I do think this is a good candidate for custom extensions.
>
> Thanks,
> Bill
>
> ___
> 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 #3781] Possible bug

[Emilia Käsper via RT]

I am afraid that there is not enough information here to diagnose the problem.
We'd need to see a more detailed trace and/or the ClientHello contents.

This could be https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0291,
which was fixed in 1.0.2b, but I can't tell.

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

[openssl-dev] [openssl.org #3984] [PATCH] Fix clang compiler warning where %ld is used for uint64_t on Mac OS X

[Emilia Käsper via RT]

Committed in fb029cebaeb6b0dbdb05a26a515e38a52a3c0fa1.

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

[openssl-dev] [openssl.org #3493] Fix rsa_test

[Emilia Käsper via RT]

Fixed in 25d6b3401ca40c9a2cbe5080449c1c2a3703.

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

[openssl-dev] [openssl.org #4002] Bug in branch master, file evp_pbe.c

[Emilia Käsper via RT]

I believe this can't happen, but addressed in
394f7b6fcc38132b8ccff0a3253b9dd15640cfc0 anyway.

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

Re: [openssl-dev] Minor bug in custom TLS extensions

[Emilia Käsper]

On Fri, Aug 28, 2015 at 2:21 AM, Bill Cox <waywardg...@google.com> wrote:

> On Thu, Aug 27, 2015 at 5:00 PM, Emilia Käsper <emi...@openssl.org> wrote:
>
>> A client should (SHOULD) always repeat extensions on resumption though,
>> as it can't know whether the resumption will be accepted.
>>
>> Do you have a specific example where you need to save custom extension
>> state? We can think about extending the API, even though I imagine that
>> anything that does need to keep state will be too complex and hairy to be
>> handled by the generic extension mechanism.
>>
>> Cheers,
>> Emilia
>>
>>
> Yes, I need it for the Token Binding Negotiation
> <https://tools.ietf.org/html/draft-popov-tokbind-negotiation-00>
> extension.  We negotiate acceptable Token Binding key parameters in this
> TLS extension.  On resumption, the negotiation fails because the server
> does not include the custom extension in it's server hello.  At this point,
> the client loses the ability to use channel bound tokens.
>

It's not quite clear to me why you'd have to resend parameters on
resumption. After all, they are definitive for the session. Best if the
draft explicitly specifies resumption behaviour.

It's also not clear to me that the serialized TLS session is the place to
store the parameters. Shouldn't they rather be stored at the application
level, alongside with the eventual token?

But setting that aside, the interaction with extended master secret makes
using custom extensions for this purpose tricky anyway. Custom extensions
don't really support interaction with other extensions; there's no
guarantee that you'll end up processing them in the right order.

(But I've only skimmed the docs so it's possible I got it all wrong.)

Cheers,
Emilia


> Thanks,
> Bill
>
> ___
> 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 #3977] bug report : Ubutu 12.0.4 : Openssl 1.0.1p : allowing connections with EXP cipher

[Emilia Käsper via RT]

Everything seems to be working as intended; closing this ticket.

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

[openssl-dev] [openssl.org #4007] Segmantation fault in OpenSSL 1.0.2a

[Emilia Käsper via RT]

Please see https://rt.openssl.org/Ticket/Display.html?id=3439

Your symptoms match, so it looks like unfortunately you were relying on an
OpenSSL bug to get the desired application behaviour.

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

[openssl-dev] [openssl.org #3956] SSL_accept() crashed in SSLv3 processing

[Emilia Käsper via RT]

Resolving - this was fixed in 1.0.1k.

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

[openssl-dev] [openssl.org #3911] 1.0.2c: some kind of regression - fails to connect to server where 1.0.2a works fine

[Emilia Käsper via RT]

Working as intended on the OpenSSL side. Marking resolved.

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

[openssl-dev] [openssl.org #3926] [PATCH] Fix -evp option in openssl speed command

[Emilia Käsper via RT]

Resolving: seems that this was fixed in
dfba17b4f3b2f87b50f2251a608d1911bfd202bc

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

[openssl-dev] [openssl.org #3815] Issue with X509_NAME_hash in 0.9.8zb

[Emilia Käsper via RT]

Yes, this is intentional. See also the issuer_hash_old and subject_hash_old
options in the x509 utility:
https://www.openssl.org/docs/manmaster/apps/x509.html

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

Re: [openssl-dev] Minor bug in custom TLS extensions

[Emilia Käsper]

It's not really a bug. The behaviour upon resumption is extension-specific.
Most extensions are only needed for establishing the session; they're
ignored during resumption, and aren't stored in the session state. So it's
rather that the custom extensions API doesn't support stateful extensions.

A client should (SHOULD) always repeat extensions on resumption though, as
it can't know whether the resumption will be accepted.

Do you have a specific example where you need to save custom extension
state? We can think about extending the API, even though I imagine that
anything that does need to keep state will be too complex and hairy to be
handled by the generic extension mechanism.

Cheers,
Emilia

On Tue, Aug 25, 2015 at 7:26 PM, Bill Cox waywardg...@google.com wrote:

 This seems like a bug to me:

 /*
  * If this ClientHello extension was unhandled and this is a
  * nonresumed connection, check whether the extension is a custom
  * TLS Extension (has a custom_srv_ext_record), and if so call the
  * callback and record the extension number so that an appropriate
  * ServerHello may be later returned.
  */
 else if (!s-hit) {
 if (custom_ext_parse(s, 1, type, data, size, al) = 0)
 return 0;
 }

 This is in t1_lib.c, in function ssl_scan_clienthello_tlsext.  It looks
 like the check for !s-hit will cause the server to ignore all custom
 extensions on resumed sessions.  At the same time, we do not have a
 mechanism for saving custom extension state in the session.  As a result,
 the server will lose all knowledge of the existence of a custom extension
 after resumption.  Some extensions are only needed during the initial
 handshake, but others set state on the connection that should persist.
 Also, there seems to be no code to keep the client from sending custom
 extensions on resumption, so when OpenSSL talks to OpenSSL with identical
 custom extensions, we're sending TLS extensions on resumption which are
 ignored by the server.

 I think the one-line fix is to change the else if (!s-hit) { to else
 {.  Would you guys agree?

 Any existing custom extensions that depend on the old behavior need to
 check SSL_session_reused(ssl) to disable custom TLS extensions on
 resumption.  On the positive side, this will reduce the current overhead
 caused by the client sending these extensions on resumption.

 Thanks,
 Bill

 ___
 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] tls_session_secret_cb method return value

[Emilia Käsper]

Hi Ian,

Thanks for the report!

Your colleague John Foley suggested to treat this error as unrecoverable:
https://mta.openssl.org/pipermail/openssl-dev/2015-March/001030.html

The error is set while processing the ServerHello, at which point the PAC
has already been sent to the server in the ticket in the ClientHello, and
it's the server's call whether it'll be resuming. So either
(a) we make the assumption that the server would agree that the PAC has
expired and not attempt a resumption - and we make the resumption attempt
an internal error; or
(b) the client-side check for expiration would have to be moved to an
earlier place in the handshake.

I am afraid that you know better than me what the intended behaviour is.
How about you describe the complete correct flow and propose a patch?

Cheers,
Emilia

On Mon, Aug 10, 2015 at 5:34 PM, Ian McFadries (imcfadri) 
imcfa...@cisco.com wrote:



 I am trying to determine if the tls_session_secret_cb return value is used
 to indicate an unrecoverable error has been encountered

 (i.e. bad pointer for data needed to calculate secret) or if it is
 intended to be an indicator that the session secret is deemed

 invalid (EAP-FAST PAC expired resulting in new session therefore determine
 that secret should not be calculated).



 The code I am working on is using the tls_session_secret_cb return value
 as the latter specified above, and that resulted in our

 implementation of EAP-FAST to break when a PAC expires after we picked up
 release 1.0.1l of OpenSSL.  A change was made in s3_clnt.c

 ssl3_get_server_hello method at line 889.  Previously, if
 tls_session_secret_cb returned 0 no action was taken, but the change

 resulted in SSLErr if tls_session_secret_cb returned 0.



 I believe that we should treat the tls_session_secret_cb return value to
 indicate an unrecoverable error only.  Then in the scenario

 where the PAC expires, although we would not calculate the secret, it will
 work fine since the secret will be calculated later in

 OpenSSL when servicing the client key exchange.

 ___
 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 #3871] Patch for latest git master to fix crypto/ec build errors (OSX)

[Emilia Käsper via RT]

Fixed in 88f4c6f3d2f884715f8f5f8eb81f0a96cbec8cef, thanks for spotting!

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

Re: [openssl-dev] ecp_nistz256 correctness/constant-timedness

[Emilia Käsper]

On Sun, Apr 26, 2015 at 10:37 PM, Brian Smith br...@briansmith.org wrote:

 On Fri, Apr 24, 2015 at 5:54 AM, Emilia Käsper emi...@openssl.org wrote:

 commit c028254b12 fixes 1., 2. and 3. (also applied to 1.0.2).
 commit 53dd4ddf71 fixes 5 and some of 4.

 Still ploughing my way through the rest of error checking.



 Great.

 I want to call your attention to one particularly non-obvious failure to
 handle errors correctly:

 static void ecp_nistz256_windowed_mul([...], P256_POINT *r, [...])
 {
 [...]

 if ((num * 16 + 6)  OPENSSL_MALLOC_MAX_NELEMS(P256_POINT)
 || (table_storage =
 OPENSSL_malloc((num * 16 + 5) * sizeof(P256_POINT) + 64)) ==
 NULL
 || (p_str =
 OPENSSL_malloc(num * 33 * sizeof(unsigned char))) == NULL
 || (scalars = OPENSSL_malloc(num * sizeof(BIGNUM *))) == NULL) {
 ECerr(EC_F_ECP_NISTZ256_WINDOWED_MUL, ERR_R_MALLOC_FAILURE);
 goto err;
 }

 [...]

 err:
 [...]
 }

 ecp_nistz256_windowed_mul checks for errors, but it doesn't report the
 fact that an error occurred to the caller, because it has return type
 |void|. And, the caller doesn't check that ecp_nistz256_windowed_mul
 failed; it can't because of the void return type.


Thanks again, I would have missed that!

I hope I got it all now. Scroll past commit 5956b110e3 (master) or
07977739f0 (1.0.2) for all the changes.

Cheers,
Emilia



 Cheers,
 Brian


 ___
 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] ecp_nistz256 correctness/constant-timedness

[Emilia Käsper]

On Fri, Apr 24, 2015 at 3:00 PM, Emilia Käsper emi...@openssl.org wrote:

 Thanks for the report! Let me clarify a few points, and then I'll fix it.

 On Thu, Apr 23, 2015 at 11:07 PM, Brian Smith br...@briansmith.org
 wrote:

 Hi,

 I have some questions regarding this implementation.


 https://github.com/openssl/openssl/blob/e0e920b1a063f14f36418f8795c96f2c649400e1/crypto/ec/ecp_nistz256.c

 1. In ecp_nistz256_points_mul, we have this code:

 if ((BN_num_bits(scalar)  256) {
 ...
 if (!BN_nnmod(tmp_scalar, scalar, group-order, ctx)) {...}
 scalar = tmp_scalar;
 }

 I think it would be useful to add a comment about why this is OK in terms
 of the constant-time-correctness of the code, because it isn't obvious.


 Yes, this needs a comment. Basically we treat overlong scalars as
 malformed, and don't guarantee constant-timeness for them. (It'd be too
 hard.) In the ecp_nistp***.c modules, this is commented.



 2. Later in the same function, we have this code:

 bn_correct_top(r-X);
 bn_correct_top(r-Y);
 bn_correct_top(r-Z);

 Again, it isn't clear why it is OK to call bn_correct_top given that
 bn_correct_top isn't a constant-time function. I think either this code
 should be changed so that it is constant time, or a comment should be added
 explaining why it doesn't need to be.


 I think that's fine and just needs a comment. It happens in the end and
 basically strips leading zero-words from the (presumably public) output.
 The ecp_nistp***.c code just calls
 EC_POINT_set_Jprojective_coordinates_GFp() at this point.



 3. When doing the initial adaptation of the code to get it working inside
 of BoringSSL, I had to make this change:

 bn_correct_top(r-X);
 bn_correct_top(r-Y);
 bn_correct_top(r-Z);
 +  r-Z_is_one = is_one(p.p.Z);

 (Alternatively, maybe one can change BoringSSL's implementation
 of EC_POINT_is_at_infinity to ignore r-Z_is_one like OpenSSL's
 implementation does.)


 Yep, that's a bug because r-Z_is_one may remain incorrectly set.

 I don't know why BoringSSL does that extra check in
 EC_POINT_is_at_infinity, though; it precedes their public git history. I'll
 check with the authors.
 I agree with you that this appears an optimization flag, so what should
 always be guaranteed is that point-Z_is_one = BN_is_one(point-Z). But
 !point-Z_is_one = inconclusive.


Oh, I think it's just an optimization on their end.






 Looking at the OpenSSL code, I can see that Z_is_one is only used for
 optimization purposes in the simple ECC implementation. Even ignoring
 BoringSSL being different, I found it confusing that sometimes Z_is_one
 *must* be set correctly and other times it *must* be ignored. Perhaps it is
 worth renaming this member to simple_Z_is_one and/or documenting more
 clearly when it is maintained and when it can and cannot be used.

 Alternatively, I noticed that BN_is_one is not a very expensive function,
 and probably can be made even less expensive, so the optimization of using
 the Z_is_one flag instead of just calling BN_is_one may not be worthwhile.
 Perhaps it would be better to remove it completely?


 Quite likely! This'll go on a TODO list somewhere...



 4. There seems to be quite a bit of missing error checking in this code.
 For example, the return values of calls to bn_wexpand are not checked in
 multiple functions. Further, a lot of the error checking in the
 probably-never-used ecp_nistz256_mult_precompute function is missing, e.g.
 calls to EC_POINT_new, EC_POINT_copy, and
 ec_GFp_simple_{add,dbl,make_affine}. I think this whole file needs to be
 combed for missing error checks.

 5. In ecp_nistz256_mult_precompute, if the ctx parameter is null, a new
 context will be created with BN_CTX_new but BN_CTX_free is not called
 anywhere in the file.


 Yep, these need fixing.

 Cheers,
 Emilia


 All that aside, this code is very fast, and it is awesome that it got
 adapted to non-X64 platforms already!

 Cheers,
 Brian

 ___
 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] ecp_nistz256 correctness/constant-timedness

[Emilia Käsper]

Thanks for the report! Let me clarify a few points, and then I'll fix it.

On Thu, Apr 23, 2015 at 11:07 PM, Brian Smith br...@briansmith.org wrote:

 Hi,

 I have some questions regarding this implementation.


 https://github.com/openssl/openssl/blob/e0e920b1a063f14f36418f8795c96f2c649400e1/crypto/ec/ecp_nistz256.c

 1. In ecp_nistz256_points_mul, we have this code:

 if ((BN_num_bits(scalar)  256) {
 ...
 if (!BN_nnmod(tmp_scalar, scalar, group-order, ctx)) {...}
 scalar = tmp_scalar;
 }

 I think it would be useful to add a comment about why this is OK in terms
 of the constant-time-correctness of the code, because it isn't obvious.


Yes, this needs a comment. Basically we treat overlong scalars as
malformed, and don't guarantee constant-timeness for them. (It'd be too
hard.) In the ecp_nistp***.c modules, this is commented.



 2. Later in the same function, we have this code:

 bn_correct_top(r-X);
 bn_correct_top(r-Y);
 bn_correct_top(r-Z);

 Again, it isn't clear why it is OK to call bn_correct_top given that
 bn_correct_top isn't a constant-time function. I think either this code
 should be changed so that it is constant time, or a comment should be added
 explaining why it doesn't need to be.


I think that's fine and just needs a comment. It happens in the end and
basically strips leading zero-words from the (presumably public) output.
The ecp_nistp***.c code just calls
EC_POINT_set_Jprojective_coordinates_GFp() at this point.



 3. When doing the initial adaptation of the code to get it working inside
 of BoringSSL, I had to make this change:

 bn_correct_top(r-X);
 bn_correct_top(r-Y);
 bn_correct_top(r-Z);
 +  r-Z_is_one = is_one(p.p.Z);

 (Alternatively, maybe one can change BoringSSL's implementation
 of EC_POINT_is_at_infinity to ignore r-Z_is_one like OpenSSL's
 implementation does.)


Yep, that's a bug because r-Z_is_one may remain incorrectly set.

I don't know why BoringSSL does that extra check in
EC_POINT_is_at_infinity, though; it precedes their public git history. I'll
check with the authors.
I agree with you that this appears an optimization flag, so what should
always be guaranteed is that point-Z_is_one = BN_is_one(point-Z). But
!point-Z_is_one = inconclusive.




 Looking at the OpenSSL code, I can see that Z_is_one is only used for
 optimization purposes in the simple ECC implementation. Even ignoring
 BoringSSL being different, I found it confusing that sometimes Z_is_one
 *must* be set correctly and other times it *must* be ignored. Perhaps it is
 worth renaming this member to simple_Z_is_one and/or documenting more
 clearly when it is maintained and when it can and cannot be used.

 Alternatively, I noticed that BN_is_one is not a very expensive function,
 and probably can be made even less expensive, so the optimization of using
 the Z_is_one flag instead of just calling BN_is_one may not be worthwhile.
 Perhaps it would be better to remove it completely?


Quite likely! This'll go on a TODO list somewhere...



 4. There seems to be quite a bit of missing error checking in this code.
 For example, the return values of calls to bn_wexpand are not checked in
 multiple functions. Further, a lot of the error checking in the
 probably-never-used ecp_nistz256_mult_precompute function is missing, e.g.
 calls to EC_POINT_new, EC_POINT_copy, and
 ec_GFp_simple_{add,dbl,make_affine}. I think this whole file needs to be
 combed for missing error checks.

 5. In ecp_nistz256_mult_precompute, if the ctx parameter is null, a new
 context will be created with BN_CTX_new but BN_CTX_free is not called
 anywhere in the file.


Yep, these need fixing.

Cheers,
Emilia


 All that aside, this code is very fast, and it is awesome that it got
 adapted to non-X64 platforms already!

 Cheers,
 Brian

 ___
 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] ecp_nistz256 correctness/constant-timedness

[Emilia Käsper]

commit c028254b12 fixes 1., 2. and 3. (also applied to 1.0.2).
commit 53dd4ddf71 fixes 5 and some of 4.

Still ploughing my way through the rest of error checking.

Cheers,
Emilia

On Fri, Apr 24, 2015 at 3:15 PM, Emilia Käsper emi...@openssl.org wrote:



 On Fri, Apr 24, 2015 at 3:00 PM, Emilia Käsper emi...@openssl.org wrote:

 Thanks for the report! Let me clarify a few points, and then I'll fix it.

 On Thu, Apr 23, 2015 at 11:07 PM, Brian Smith br...@briansmith.org
 wrote:

 Hi,

 I have some questions regarding this implementation.


 https://github.com/openssl/openssl/blob/e0e920b1a063f14f36418f8795c96f2c649400e1/crypto/ec/ecp_nistz256.c

 1. In ecp_nistz256_points_mul, we have this code:

 if ((BN_num_bits(scalar)  256) {
 ...
 if (!BN_nnmod(tmp_scalar, scalar, group-order, ctx)) {...}
 scalar = tmp_scalar;
 }

 I think it would be useful to add a comment about why this is OK in
 terms of the constant-time-correctness of the code, because it isn't
 obvious.


 Yes, this needs a comment. Basically we treat overlong scalars as
 malformed, and don't guarantee constant-timeness for them. (It'd be too
 hard.) In the ecp_nistp***.c modules, this is commented.



 2. Later in the same function, we have this code:

 bn_correct_top(r-X);
 bn_correct_top(r-Y);
 bn_correct_top(r-Z);

 Again, it isn't clear why it is OK to call bn_correct_top given that
 bn_correct_top isn't a constant-time function. I think either this code
 should be changed so that it is constant time, or a comment should be added
 explaining why it doesn't need to be.


 I think that's fine and just needs a comment. It happens in the end and
 basically strips leading zero-words from the (presumably public) output.
 The ecp_nistp***.c code just calls
 EC_POINT_set_Jprojective_coordinates_GFp() at this point.



 3. When doing the initial adaptation of the code to get it working
 inside of BoringSSL, I had to make this change:

 bn_correct_top(r-X);
 bn_correct_top(r-Y);
 bn_correct_top(r-Z);
 +  r-Z_is_one = is_one(p.p.Z);

 (Alternatively, maybe one can change BoringSSL's implementation
 of EC_POINT_is_at_infinity to ignore r-Z_is_one like OpenSSL's
 implementation does.)


 Yep, that's a bug because r-Z_is_one may remain incorrectly set.

 I don't know why BoringSSL does that extra check in
 EC_POINT_is_at_infinity, though; it precedes their public git history. I'll
 check with the authors.
 I agree with you that this appears an optimization flag, so what should
 always be guaranteed is that point-Z_is_one = BN_is_one(point-Z). But
 !point-Z_is_one = inconclusive.


 Oh, I think it's just an optimization on their end.






 Looking at the OpenSSL code, I can see that Z_is_one is only used for
 optimization purposes in the simple ECC implementation. Even ignoring
 BoringSSL being different, I found it confusing that sometimes Z_is_one
 *must* be set correctly and other times it *must* be ignored. Perhaps it is
 worth renaming this member to simple_Z_is_one and/or documenting more
 clearly when it is maintained and when it can and cannot be used.

 Alternatively, I noticed that BN_is_one is not a very expensive
 function, and probably can be made even less expensive, so the optimization
 of using the Z_is_one flag instead of just calling BN_is_one may not be
 worthwhile. Perhaps it would be better to remove it completely?


 Quite likely! This'll go on a TODO list somewhere...



 4. There seems to be quite a bit of missing error checking in this code.
 For example, the return values of calls to bn_wexpand are not checked in
 multiple functions. Further, a lot of the error checking in the
 probably-never-used ecp_nistz256_mult_precompute function is missing, e.g.
 calls to EC_POINT_new, EC_POINT_copy, and
 ec_GFp_simple_{add,dbl,make_affine}. I think this whole file needs to be
 combed for missing error checks.

 5. In ecp_nistz256_mult_precompute, if the ctx parameter is null, a new
 context will be created with BN_CTX_new but BN_CTX_free is not called
 anywhere in the file.


 Yep, these need fixing.

 Cheers,
 Emilia


 All that aside, this code is very fast, and it is awesome that it got
 adapted to non-X64 platforms already!

 Cheers,
 Brian

 ___
 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] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

[Emilia Käsper]

On Wed, Apr 1, 2015 at 10:53 PM, Brian Smith br...@briansmith.org wrote:

 Emilia Käsper emi...@openssl.org wrote:
  On Fri, Mar 27, 2015 at 10:40 PM, Brian Smith br...@briansmith.org
 wrote:
  If OpenSSL's client code were changed to always use an empty session
  ID when attempting resumption using a session ticket, then the
  EAP-FAST case wouldn't be different from the general session ticket
  resumption case. I think that this is a cleaner approach.
 
  1)  The way EAP-FAST diverges from 5246 and 5077 is indeed quite
  unfortunate. The lookahead is messy, and hard to get right - I don't want
  another early CCS due to lack of determinism in the state machine.
 Setting
  the session ID is much cleaner. So, I'd rather put in a workaround that
 is
  specific to EAP-FAST and doesn't affect regular handshakes.

 The added complexity of having a special case for EAP-FAST seems worse
 to me. After all, it's not OK to have EAP-FAST be non-secure, and so
 it is important to have the no-session-ID case be correct regardless.


This has now been fixed in commit 6e3d015363ed09c4eff5c02ad41153387ffdf5af
and cherry-picked to stable branches.

I certainly hope it's correct! I've done my best to make it so.

Cheers,
Emilia


  2) Removing the session ID upon resumption would be a big change in
  behaviour that I don't think would qualify for a stable branch anyway
 unless
  there was a security or regression  issue behind it.

 Fair enough. I have no idea what the compatibility problems might
 arise. If I have some time, I might try to change one of the web
 browsers to do this, to see what happens. If I do, I'll report back.


 Cheers,
 Brian
 ___
 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] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

[Emilia Käsper]

On Fri, Mar 27, 2015 at 7:19 PM, Erik Tkal etks...@gmail.com wrote:

 Hi Emelia,

 I’m not sure that will work as presently designed, as it keys off of the
 session object:

 -if (s-version = TLS1_VERSION  s-tls_session_secret_cb) {
 +if (s-version = TLS1_VERSION  s-tls_session_secret_cb 
 +s-session-tlsext_tick) {

 Our client uses the public API SSL_set_session_ticket_ext(), which
 populates the SSL-tls_session_ticket, and not the SSL-session copy.


Yes, I know - but that would get copied to the session when the extension
is first sent.

Do you have a way of testing the patch?



   Erik


 On 27 Mar 2015, at 12:33 PM, Emilia Käsper emi...@openssl.org wrote:

 John, Erik,

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

 Can you verify whether this resolves the problem? (And also, does not
 create any new problems.)

 Note this is pending team review so is not a definitive fix. But since
 we're maintaining this feature more or less blind, we'd appreciate your
 help testing the fix.

 Thanks,
 Emilia

 On Thu, Mar 26, 2015 at 9:02 PM, John Foley fol...@cisco.com wrote:

  Someone that understands EAP better than myself should probably provide
 input.  But my limited understand of EAP-FAST is it contributes to the
 master secret calculation used for the TLS session.  See section RFC 4851
 Section 5.1. My understanding is this logic applies to both new and resumed
 sessions.  Hence, tls_session_secret_cb() is always in play for EAP-FAST.



 On 03/26/2015 02:13 PM, Emilia Käsper wrote:



 On Tue, Mar 24, 2015 at 2:01 PM, John Foley fol...@cisco.com wrote:

  Trying again w/o PGP...  :-)

 Thanks for taking a look at this problem.  Regarding how to handle a
 failure in the session secret callback, the legacy logic would likely
 result in a bad record mac error because the master secrets on the
 client/server do not match.


  But only in case we are actually resuming - no? Does the client always
 have a PAC available - I would guess not? Seems the legacy logic is such
 that it happens to work, but I'd like to clear it up.


   It would be good to trigger an internal error to aid with
 troubleshooting.  Maybe something like:

 SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
 goto err;

 It's debatable whether the alert needs to be sent to the server.  Since
 this is an internal error, it should be safe to send the alert.  Therefore,
 maybe you would actually want to do something like:

 SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
 al = SSL_AD_INTERNAL_ERROR;
 goto f_err;




 On 03/23/2015 09:17 PM, Emilia Käsper wrote:



 On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) fol...@cisco.com
 wrote:

 We've found a way to recreate the scenario using s_client/s_server.
 We're using the -no_ticket option on the server.  Therefore, the
 ServerHello doesn't contain the session ticket extension.  It also doesn't
 send the NewSessionTicket message.

 To summarize the problem, when the client side is using
 SSL_set_session_secret_cb() and including a valid ticket in the ClintHello,
 then the logic in ssl3_get_server_hello() assumes the server is doing
 session resumption.  This puts the client-side state machine into the
 SSL3_ST_CR_FINISHED_A.  However, since the server side is configured to not
 do resumption via the -no_ticket option, the server continues with a normal
 handshake by sending the Certificate message.  The client aborts the
 handshake when it receives the Certificate message while in the
 SSL3_ST_CR_FINISHED_A state.


 As Erik identified earlier in the thread, the cause of this appears to
 be the addition of setting s-hit in the following code:

 if (s-version = TLS1_VERSION  s-tls_session_secret_cb) {
 SSL_CIPHER *pref_cipher = NULL;
 s-session-master_key_length = sizeof(s-session-master_key);
 if (s-tls_session_secret_cb(s, s-session-master_key,
  s-session-master_key_length,
  NULL, pref_cipher,
  s-tls_session_secret_cb_arg)) {
 s-session-cipher = pref_cipher ?
 pref_cipher : ssl_get_cipher_by_char(s, p + j);
 s-hit = 1;
 }
 }

 Why does the client-side now assume the server is doing session
 resumption simply because the session secret callback facility is being
 used?


  Because a developer (me) introduced a bug. With OpenSSL client
 behaviour, peeking ahead is only required for EAP-FAST. I got rid of the
 peeking while tightening up the ChangeCipherSpec handling and in the
 process, got it wrong for EAP-FAST. Anyway, apologies, I see the problem
 and am working on a patch.

  While we're at it, you may be able to help me with the following
 question: how should the client handle callback failure? The old code (pre
 my refactoring which introduced the bug) did this

  #ifndef OPENSSL_NO_TLSEXT
 /* check if we want

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

[Emilia Käsper]

On Fri, Mar 27, 2015 at 10:40 PM, Brian Smith br...@briansmith.org wrote:

 Brian Smith br...@briansmith.org wrote:
  Although the RFC4851 (an informational RFC documenting EAP-FAST) does
  not require the server to send the session ticket extension during
  resumption, it is based on RFC4507/RFC5077 (which are on the standards
  track), which *does* require the server to send the extension. So,
  this is a bug in the non-conformant servers, not in the openssl
  client.

 Sorry. It seems I am wrong about this. RFC 5077 says It is also
 permissible to have an exchange similar to Figure 3 using the
 abbreviated handshake defined in Figure 2 of RFC 4346, where the
 client uses the SessionTicket extension to resume the session, but the
 server does not wish to issue a new ticket, and therefore does not
 send a SessionTicket extension.

 AFAICT this means that, even outside of EAP-FAST, it is allowed for
 the server to resume a session using a session ticket without sending
 the session ticket extension in its ServerHello message.


Correct, but outside EAP-FAST we use the session ID to detect if we're
resuming. Honouring the synthetic session ID is a MUST in RFC5077.

I have asked, in a separate thread with Erik, whether EAP-FAST servers
would honour the session ID (so we could set it and detect resumption based
on that) but the answer appears to be no.


 Also, note that RFC 5077 section 3.4 allows the client to use a
 session ticket and an empty session ID to resume a session, instead of
 generating a fake session ID for the session ticket: Alternatively,
 the client MAY include an empty Session ID in the ClientHello.  In
 this case, the client ignores the Session ID sent in the ServerHello
 and determines if the server is resuming a session by the subsequent
 handshake messages.

 If OpenSSL's client code were changed to always use an empty session
 ID when attempting resumption using a session ticket, then the
 EAP-FAST case wouldn't be different from the general session ticket
 resumption case. I think that this is a cleaner approach.


1)  The way EAP-FAST diverges from 5246 and 5077 is indeed quite
unfortunate. The lookahead is messy, and hard to get right - I don't want
another early CCS due to lack of determinism in the state machine.
Setting the session ID is much cleaner. So, I'd rather put in a workaround
that is specific to EAP-FAST and doesn't affect regular handshakes.

2) Removing the session ID upon resumption would be a big change in
behaviour that I don't think would qualify for a stable branch anyway
unless there was a security or regression
issue behind it.

But thanks a lot for diving into the RFCs!  A second pair of eyes is very
much needed here.

Cheers,
Emilia



 Note that RFC4851 would likely still need to be updated, because TLS
 1.3 will most likely remove the ChangeCipherSpec messages, and
 RFC4851's recommended resumption detection is based on detecting
 ChangeCipherSpec messages.


 Cheers,
 Brian
 ___
 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] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

[Emilia Käsper]

John, Erik,

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

Can you verify whether this resolves the problem? (And also, does not
create any new problems.)

Note this is pending team review so is not a definitive fix. But since
we're maintaining this feature more or less blind, we'd appreciate your
help testing the fix.

Thanks,
Emilia

On Thu, Mar 26, 2015 at 9:02 PM, John Foley fol...@cisco.com wrote:

  Someone that understands EAP better than myself should probably provide
 input.  But my limited understand of EAP-FAST is it contributes to the
 master secret calculation used for the TLS session.  See section RFC 4851
 Section 5.1. My understanding is this logic applies to both new and resumed
 sessions.  Hence, tls_session_secret_cb() is always in play for EAP-FAST.



 On 03/26/2015 02:13 PM, Emilia Käsper wrote:



 On Tue, Mar 24, 2015 at 2:01 PM, John Foley fol...@cisco.com wrote:

  Trying again w/o PGP...  :-)

 Thanks for taking a look at this problem.  Regarding how to handle a
 failure in the session secret callback, the legacy logic would likely
 result in a bad record mac error because the master secrets on the
 client/server do not match.


  But only in case we are actually resuming - no? Does the client always
 have a PAC available - I would guess not? Seems the legacy logic is such
 that it happens to work, but I'd like to clear it up.


   It would be good to trigger an internal error to aid with
 troubleshooting.  Maybe something like:

 SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
 goto err;

 It's debatable whether the alert needs to be sent to the server.  Since
 this is an internal error, it should be safe to send the alert.  Therefore,
 maybe you would actually want to do something like:

 SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
 al = SSL_AD_INTERNAL_ERROR;
 goto f_err;




 On 03/23/2015 09:17 PM, Emilia Käsper wrote:



 On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) fol...@cisco.com
 wrote:

 We've found a way to recreate the scenario using s_client/s_server.
 We're using the -no_ticket option on the server.  Therefore, the
 ServerHello doesn't contain the session ticket extension.  It also doesn't
 send the NewSessionTicket message.

 To summarize the problem, when the client side is using
 SSL_set_session_secret_cb() and including a valid ticket in the ClintHello,
 then the logic in ssl3_get_server_hello() assumes the server is doing
 session resumption.  This puts the client-side state machine into the
 SSL3_ST_CR_FINISHED_A.  However, since the server side is configured to not
 do resumption via the -no_ticket option, the server continues with a normal
 handshake by sending the Certificate message.  The client aborts the
 handshake when it receives the Certificate message while in the
 SSL3_ST_CR_FINISHED_A state.


 As Erik identified earlier in the thread, the cause of this appears to
 be the addition of setting s-hit in the following code:

 if (s-version = TLS1_VERSION  s-tls_session_secret_cb) {
 SSL_CIPHER *pref_cipher = NULL;
 s-session-master_key_length = sizeof(s-session-master_key);
 if (s-tls_session_secret_cb(s, s-session-master_key,
  s-session-master_key_length,
  NULL, pref_cipher,
  s-tls_session_secret_cb_arg)) {
 s-session-cipher = pref_cipher ?
 pref_cipher : ssl_get_cipher_by_char(s, p + j);
 s-hit = 1;
 }
 }

 Why does the client-side now assume the server is doing session
 resumption simply because the session secret callback facility is being
 used?


  Because a developer (me) introduced a bug. With OpenSSL client
 behaviour, peeking ahead is only required for EAP-FAST. I got rid of the
 peeking while tightening up the ChangeCipherSpec handling and in the
 process, got it wrong for EAP-FAST. Anyway, apologies, I see the problem
 and am working on a patch.

  While we're at it, you may be able to help me with the following
 question: how should the client handle callback failure? The old code (pre
 my refactoring which introduced the bug) did this

  #ifndef OPENSSL_NO_TLSEXT
  /* check if we want to resume the session based on external pre-shared 
 secret */
  if (s-version = TLS1_VERSION  s-tls_session_secret_cb)
  {
  SSL_CIPHER *pref_cipher=NULL;
  s-session-master_key_length=sizeof(s-session-master_key);
  if (s-tls_session_secret_cb(s, s-session-master_key,
   s-session-master_key_length,
   NULL, pref_cipher,
   s-tls_session_secret_cb_arg))
  {
  s-session-cipher = pref_cipher ?
  pref_cipher : ssl_get_cipher_by_char(s, p+j

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

[Emilia Käsper]

On Tue, Mar 24, 2015 at 2:01 PM, John Foley fol...@cisco.com wrote:

  Trying again w/o PGP...  :-)

 Thanks for taking a look at this problem.  Regarding how to handle a
 failure in the session secret callback, the legacy logic would likely
 result in a bad record mac error because the master secrets on the
 client/server do not match.


But only in case we are actually resuming - no? Does the client always have
a PAC available - I would guess not? Seems the legacy logic is such that it
happens to work, but I'd like to clear it up.


   It would be good to trigger an internal error to aid with
 troubleshooting.  Maybe something like:

 SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
 goto err;

 It's debatable whether the alert needs to be sent to the server.  Since
 this is an internal error, it should be safe to send the alert.  Therefore,
 maybe you would actually want to do something like:

 SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
 al = SSL_AD_INTERNAL_ERROR;
 goto f_err;




 On 03/23/2015 09:17 PM, Emilia Käsper wrote:



 On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) fol...@cisco.com
 wrote:

 We've found a way to recreate the scenario using s_client/s_server.
 We're using the -no_ticket option on the server.  Therefore, the
 ServerHello doesn't contain the session ticket extension.  It also doesn't
 send the NewSessionTicket message.

 To summarize the problem, when the client side is using
 SSL_set_session_secret_cb() and including a valid ticket in the ClintHello,
 then the logic in ssl3_get_server_hello() assumes the server is doing
 session resumption.  This puts the client-side state machine into the
 SSL3_ST_CR_FINISHED_A.  However, since the server side is configured to not
 do resumption via the -no_ticket option, the server continues with a normal
 handshake by sending the Certificate message.  The client aborts the
 handshake when it receives the Certificate message while in the
 SSL3_ST_CR_FINISHED_A state.


 As Erik identified earlier in the thread, the cause of this appears to be
 the addition of setting s-hit in the following code:

 if (s-version = TLS1_VERSION  s-tls_session_secret_cb) {
 SSL_CIPHER *pref_cipher = NULL;
 s-session-master_key_length = sizeof(s-session-master_key);
 if (s-tls_session_secret_cb(s, s-session-master_key,
  s-session-master_key_length,
  NULL, pref_cipher,
  s-tls_session_secret_cb_arg)) {
 s-session-cipher = pref_cipher ?
 pref_cipher : ssl_get_cipher_by_char(s, p + j);
 s-hit = 1;
 }
 }

 Why does the client-side now assume the server is doing session
 resumption simply because the session secret callback facility is being
 used?


  Because a developer (me) introduced a bug. With OpenSSL client
 behaviour, peeking ahead is only required for EAP-FAST. I got rid of the
 peeking while tightening up the ChangeCipherSpec handling and in the
 process, got it wrong for EAP-FAST. Anyway, apologies, I see the problem
 and am working on a patch.

  While we're at it, you may be able to help me with the following
 question: how should the client handle callback failure? The old code (pre
 my refactoring which introduced the bug) did this

  #ifndef OPENSSL_NO_TLSEXT
   /* check if we want to resume the session based on external pre-shared 
 secret */
   if (s-version = TLS1_VERSION  s-tls_session_secret_cb)
   {
   SSL_CIPHER *pref_cipher=NULL;
   s-session-master_key_length=sizeof(s-session-master_key);
   if (s-tls_session_secret_cb(s, s-session-master_key,
s-session-master_key_length,
NULL, pref_cipher,
s-tls_session_secret_cb_arg))
   {
   s-session-cipher = pref_cipher ?
   pref_cipher : ssl_get_cipher_by_char(s, p+j);
   }
   }
 #endif /* OPENSSL_NO_TLSEXT */

 This is surely wrong as it's just ignoring the failure?

 Thanks,

 Emilia

  
 From: openssl-dev [openssl-dev-boun...@openssl.org] on behalf of Dr.
 Stephen Henson [st...@openssl.org]
 Sent: Thursday, March 19, 2015 11:49 AM
 To: openssl-dev@openssl.org
 Subject: Re: [openssl-dev] s3_clnt.c changes regarding external
 pre-shared secret seem to break EAP-FAST

 On Thu, Mar 19, 2015, Erik Tkal wrote:

 
  If I do not send a sessionID in the clientHello but do send a valid
  sessionTicket extension, the server goes straight to changeCipherSpec
 and
  the client generates an UnexpectedMessage alert.
 

 Does the server send back an empty session ticket extension?

 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

[Emilia Käsper]

On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) fol...@cisco.com
wrote:

 We've found a way to recreate the scenario using s_client/s_server.  We're
 using the -no_ticket option on the server.  Therefore, the ServerHello
 doesn't contain the session ticket extension.  It also doesn't send the
 NewSessionTicket message.

 To summarize the problem, when the client side is using
 SSL_set_session_secret_cb() and including a valid ticket in the ClintHello,
 then the logic in ssl3_get_server_hello() assumes the server is doing
 session resumption.  This puts the client-side state machine into the
 SSL3_ST_CR_FINISHED_A.  However, since the server side is configured to not
 do resumption via the -no_ticket option, the server continues with a normal
 handshake by sending the Certificate message.  The client aborts the
 handshake when it receives the Certificate message while in the
 SSL3_ST_CR_FINISHED_A state.


 As Erik identified earlier in the thread, the cause of this appears to be
 the addition of setting s-hit in the following code:

 if (s-version = TLS1_VERSION  s-tls_session_secret_cb) {
 SSL_CIPHER *pref_cipher = NULL;
 s-session-master_key_length = sizeof(s-session-master_key);
 if (s-tls_session_secret_cb(s, s-session-master_key,
  s-session-master_key_length,
  NULL, pref_cipher,
  s-tls_session_secret_cb_arg)) {
 s-session-cipher = pref_cipher ?
 pref_cipher : ssl_get_cipher_by_char(s, p + j);
 s-hit = 1;
 }
 }

 Why does the client-side now assume the server is doing session resumption
 simply because the session secret callback facility is being used?


Because a developer (me) introduced a bug. With OpenSSL client behaviour,
peeking ahead is only required for EAP-FAST. I got rid of the peeking while
tightening up the ChangeCipherSpec handling and in the process, got it
wrong for EAP-FAST. Anyway, apologies, I see the problem and am working on
a patch.

While we're at it, you may be able to help me with the following question:
how should the client handle callback failure? The old code (pre my
refactoring which introduced the bug) did this

#ifndef OPENSSL_NO_TLSEXT
/* check if we want to resume the session based on external
pre-shared secret */
if (s-version = TLS1_VERSION  s-tls_session_secret_cb)
{
SSL_CIPHER *pref_cipher=NULL;
s-session-master_key_length=sizeof(s-session-master_key);
if (s-tls_session_secret_cb(s, s-session-master_key,
 s-session-master_key_length,
 NULL, pref_cipher,
 s-tls_session_secret_cb_arg))
{
s-session-cipher = pref_cipher ?
pref_cipher : ssl_get_cipher_by_char(s, p+j);
}
}
#endif /* OPENSSL_NO_TLSEXT */

This is surely wrong as it's just ignoring the failure?

Thanks,

Emilia


 From: openssl-dev [openssl-dev-boun...@openssl.org] on behalf of Dr.
 Stephen Henson [st...@openssl.org]
 Sent: Thursday, March 19, 2015 11:49 AM
 To: openssl-dev@openssl.org
 Subject: Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared
 secret seem to break EAP-FAST

 On Thu, Mar 19, 2015, Erik Tkal wrote:

 
  If I do not send a sessionID in the clientHello but do send a valid
  sessionTicket extension, the server goes straight to changeCipherSpec and
  the client generates an UnexpectedMessage alert.
 

 Does the server send back an empty session ticket extension?

 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 ___
 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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl.org #3602] [PATCH]

[Emilia Käsper via RT]

Error codes aren't part of the API. It's a bit of a grey area in some cases,
but for EVP_DecryptFinal_ex, you really should be checking the return value and
not relying on errors left on stack. In particular, reporting detailed
decryption errors was a historical mistake that has led to serious attacks;
it's a coding pattern we should eradicate. This particular change was made to
avoid a timing leak and provide callers an opportunity to proceed in constant
time. (But most callers won't care, it only affects mac-then-encrypt.)

In your case, it sounds like the right thing to do is fix the unittest to be
more robust. I'm going to reject this for now; I'll revisit if we get reports
that this is causing more widespread problems, though.

Cheers,
Emilia

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3547] [PATCH] Add missing static qualifier

[Emilia Käsper via RT]

Applied to all branches, thanks!

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3568] Bug: Compiling openssl-1.0.1j on AIX 7.1

[Emilia Käsper]

I've now pushed the missing commits to stable branches as well. For 0.9.8,
they are

af32df0a8e662914f78c93736466c746f83dfe84
and
9880f63038a5b9bb8bf5becc18360378cfe7806d

Emilia

On Fri, Oct 17, 2014 at 9:30 PM, Kyle Chapman kyle.chap...@pb.com wrote:

 You can either patch e_os.h or when configuring on aix do:
 [ ./Configure platform | ./config ]  your options -qkeyword=inline

 So as a workaround,  add the -qkeyword.  -qlanglvl=extc99  works as well
 I use: ./config shared threads -qkeyword=inline
 Until I patched e_os.h

 Refer to this for the changed to e_os.h

 http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=40155f408985aff2e9f1b61b7cb04a3e518633a1

 thanks to emilia for pointing to that commit.

 -Original Message-
 From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org]
 On Behalf Of Peter Bruderer via RT
 Sent: Friday, October 17, 2014 3:17 PM
 Cc: openssl-dev@openssl.org
 Subject: [openssl.org #3568] Bug: Compiling openssl-1.0.1j on AIX 7.1

 Hi there


 when I compile openssl-1.0.1j on AIX 7.1 I the the following error:

 cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include
 -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q64
 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -DOPENSSL_BN_ASM_MONT
 -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -c rsa_pk1.c
 ../constant_time_locl.h, line 84.15: 1506-277 (S) Syntax error: possible
 missing ';' or ','?
 make: 1254-004 The error code from the last command is 1.



 have fun ...
 Peter Bruderer
 --
   Bruderer Research GmbH
   CH-8200 Schaffhausen
   +41 52 620 26 53
   peter.brude...@brg.ch



 

[openssl.org #3568] Bug: Compiling openssl-1.0.1j on AIX 7.1

[Emilia Käsper via RT]

Resolved - please see #3567 for details.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3067] [PATCH] premaster_constant_time

[Emilia Käsper via RT]

FYI,

https://rt.openssl.org/Ticket/Display.html?id=3558 may also be of interest.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: 1.0.2 head doesn't build...

[Emilia Käsper]

Appears to be a bad git merge on my side. I'm on it.

On Thu, Sep 25, 2014 at 1:23 PM, Ben Laurie b...@links.org wrote:

 Workaround (I wasn't sure if the functions were intended to be used
 somewhere, so not deleted yet):

 diff --git a/crypto/constant_time_test.c b/crypto/constant_time_test.c
 index 1b4b18d..78e7fca 100644
 --- a/crypto/constant_time_test.c
 +++ b/crypto/constant_time_test.c
 @@ -195,7 +195,7 @@ static int test_select_int(int a, int b)
 }
 return 0;
 }
 -
 +/*
  static int test_eq_int(int a, int b)
 {
 unsigned int equal = constant_time_eq_int(a, b);
 @@ -235,7 +235,7 @@ static int test_eq_int_8(int a, int b)
 }
 return 0;
 }
 -
 +*/
  static unsigned int test_values[] = {0, 1, 1024, 12345, 32000,
 UINT_MAX/2-1,
   UINT_MAX/2, UINT_MAX/2+1, UINT_MAX-1,
   UINT_MAX};
 __
 OpenSSL Project http://www.openssl.org
 Team Mailing List openssl-t...@openssl.org
 Automated List Manager   majord...@openssl.org

Re: 1.0.2 head doesn't build...

[Emilia Käsper]

Fixed in fdc35a9d3e8cf4cfd9330d5df9883f42cf5648ad. Sorry about that,

Emilia

On Thu, Sep 25, 2014 at 1:28 PM, Emilia Käsper emi...@silkandcyanide.net
wrote:

 Appears to be a bad git merge on my side. I'm on it.

 On Thu, Sep 25, 2014 at 1:23 PM, Ben Laurie b...@links.org wrote:

 Workaround (I wasn't sure if the functions were intended to be used
 somewhere, so not deleted yet):

 diff --git a/crypto/constant_time_test.c b/crypto/constant_time_test.c
 index 1b4b18d..78e7fca 100644
 --- a/crypto/constant_time_test.c
 +++ b/crypto/constant_time_test.c
 @@ -195,7 +195,7 @@ static int test_select_int(int a, int b)
 }
 return 0;
 }
 -
 +/*
  static int test_eq_int(int a, int b)
 {
 unsigned int equal = constant_time_eq_int(a, b);
 @@ -235,7 +235,7 @@ static int test_eq_int_8(int a, int b)
 }
 return 0;
 }
 -
 +*/
  static unsigned int test_values[] = {0, 1, 1024, 12345, 32000,
 UINT_MAX/2-1,
   UINT_MAX/2, UINT_MAX/2+1,
 UINT_MAX-1,
   UINT_MAX};
 __
 OpenSSL Project http://www.openssl.org
 Team Mailing List openssl-t...@openssl.org
 Automated List Manager   majord...@openssl.org

[openssl.org #3066] [PATCH] constant_time_rsa_padding

[Emilia Käsper via RT]

Thanks!

This is now in all branches in somewhat modified form (using the common
constant-time header), see commit

294d1e36c2495ff00e697c9ff622856d3114f14f

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3067] [PATCH] premaster_constant_time

[Emilia Käsper via RT]

And thanks once again!

This has now been backported from master commit

adb46dbc6dd7347750df2468c93e8c34bcb93a4b

to all other branches. Note that I rewrote the constant-time ops in the
follow-up commit

455b65dfab0de51c9f67b3c909311770f2b3f801

If you'd like to verify that I didn't mess up the rewrite, that'd be great!

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3425] Potential padding oracle in evp_enc.c

[Emilia Käsper via RT]

Thanks for reporting!

The leak would only be meaningful if the caller is doing mac-then-encrypt and
is attempting to proceed with the mac-check in constant-time following a call
to EVP_DecryptInit_ex. It also doesn't affect TLS mac-then-encrypt because TLS
uses a different padding scheme, and a different, constant-time code path in
OpenSSL.

We also don't have evidence that the leak is large enough to be exploitable.
However, it's best to be careful so I've rewritten the code to do the padding
check in constant time. See commit

4aac102f75b517bdb56b1bcfd0a856052d559f6e

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3063] [PATCH] exp_zero_mod_one

[Emilia Käsper via RT]

Thanks! This has now been applied to all branches.
(Original commit 2b0180c37fa6ffc48ee40caa831ca398b828e680)

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org