Re: [openssl-dev] [openssl-master 0/1] AFALG: Support AES GCM

[Kurt Roeckx]

On Mon, Feb 05, 2018 at 12:08:38PM +0530, Atul Gupta wrote:
> The objective of this patch is to add AEAD cipher aes-gcm
> to afalg. Portion of code is borrowed from e_aes.c. The AEAD
> auth size is set to program the TAG length. AAD (additional
> authenc data) is sent in iov along with data[in].

Please open a pull request on github.


Kurt

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

Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface

[Kurt Roeckx]

On Thu, Jan 18, 2018 at 05:34:05PM +0100, Patrick Steuer wrote:
> 
> Though aead is in some sense more than a cipher mode of operation. Providing
> a dedicated api would have some advantages but i see that maybe i reopen a
> discussion:
> 
> "We are also evaluating the following new features. -New AEAD API [...]"
> https://www.openssl.org/policies/roadmap.html#forthcoming
> 
> Was this already evaluated? If yes, what was the result ?

Nobody has had time for this, feel free to make a proposal.


Kurt

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

Re: [openssl-dev] Is X509_free(NULL) ok?

[Kurt Roeckx]

On Fri, Dec 22, 2017 at 09:30:19AM -0500, Ken Goldman wrote:
> On 12/22/2017 9:24 AM, Salz, Rich via openssl-users wrote:
> > >   if (ptr!= NULL) free(ptr);
> > That shouldn’t be necessary for OpenSSL.  If you find places where it is, 
> > please open an issue.
> 
> OK.  I'll mention a few, but it's a global issue.
> 
> The code may handle NULL.  However, conservative users won't go by what the
> code happens to do today.  We have to go by the API documentation, which is
> the contract between the library and the user.  If the API is silent, we
> cautiously assume it's not guaranteed, and can change in the future.

So feel free to document it as being able to handle NULL.


Kurt

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

Re: [openssl-dev] Is X509_free(NULL) ok?

[Kurt Roeckx]

On Fri, Dec 22, 2017 at 01:06:20PM +, Salz, Rich via openssl-dev wrote:
> Our intent is that all FREE functions can handle NULL.  If you find things 
> missing or undocumented, please open an issue on GitHub.  Thanks!

I think we fixed all such cases in 1.1.0, all *_free() functions
should handle NULL. I don't think we backported to changes to 1.0.2.


Kurt

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

Re: [openssl-dev] Certificate Limitation Profile

[Kurt Roeckx]

On Mon, Nov 27, 2017 at 07:56:00PM +0300, Dmitry Belyavsky wrote:
> Here is the link to the draft:
> https://datatracker.ietf.org/doc/draft-belyavskiy-certificate-limitation-policy/

I'm wondering how you think that policy will be distributed and
why it needs signed. I expect that there will always be some way
of authenticating the document if you download it without requiring
that the document is signed itself. For instance it might come
as part of some software distribution (like a browser), and either
you trust all the files in that distribution or you don't.

If it's signed, who will be signing it, and how does the
application know which key to use to verify the signature?

I can also imagine that users might wish to modify that file,
for instance add an internal CA or certificate, not trust some
CA, ... They could of course generate their own key, and tell the
software to use that key.


Kurt

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

Re: [openssl-dev] Systemwide configurability of OpenSSL

[Kurt Roeckx]

On Wed, Oct 25, 2017 at 05:19:23PM +0200, Tomas Mraz wrote:
> 
> The problem is that by default the applications do not read the file and
> do not apply the defaults. Even the openssl s_client/s_server does not
> seem to work, but I might be doing something wrong.
> 
> What I would like to see is applying the defaults unconditionally or
> maybe with some possibility to opt-out of it by application but not opt-in.
> 
> Can I please get at least some response from the openssl team? Should I
> open an issue on github for that feature?

I would like to see something like that happen.


Kurt

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

Re: [openssl-dev] how to static compile ssl engine into openssl

[Kurt Roeckx]

On Tue, Sep 26, 2017 at 07:32:06AM +0200, Richard Levitte wrote:
> 
> You mean to have nginx use the shared OpenSSL libraries, which also
> enables dynamic engines?  Yes, that's the usual way to go about these
> things.

Do we support dynamic engines with a static build?


Kurt

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

Re: [openssl-dev] libcrypto.pc needs to list libpthread as a dependency

[Kurt Roeckx]

On Sun, Sep 17, 2017 at 08:04:10AM +0100, Matt Caswell wrote:
> On Sat, 16 Sep 2017 22:26:10 +0100
> Howard Chu via openssl-dev  wrote:
> 
> > In OpenSSL 1.1 on Linux (at least) libcrypto now has a dependency on 
> > libpthread but this is not reflected in the pkgconfig file. As a result, 
> > tools 
> > like CMake fail to detect libcrypto properly when linking against the 
> > static 
> > library. libpthread should be added to the Libs.private line of the 
> > pkgconfig 
> 
> Hmmm - there is no pkgconfig file at all in 1.1.0. It was removed because it 
> was felt this was better added by OS specific packages. If you have one it 
> probably came from the package for your specific distro not the openssl 
> project itself.

The .pc files are still in master.


Kurt

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

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

[Kurt Roeckx]

On Tue, Aug 29, 2017 at 08:38:09PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> > If, based on its value, OpenSSL may decide that it now got “enough” entropy 
> > and doesn’t need to
> > pull more from other sources before serving randomness to requestors – then 
> > it is harmful.
> > “Over-confidence” in this value by the caller can negatively impact the 
> > quality of the produced
> > random numbers.
> 
> As long as you have sources that don't provide 1 bit of randomness
> per bit that you provide you need to have an estimate of how much
> randomness it really contains. And you should probably seriously
> underestimate it so that you're sure that you collect enough.
> 
> So let me underestimate it to 0. ;-)  
>   
> The problem with ignoring an existing parameter is that people
> could be calling it with for instance the value of 0, knowing it
> contains as good as none entropy. Or they could feed the unwithened
> output of an TRNG in that with an estimate of randomness it provides.
> And OpenSSL used to do the right thing with that.
> 
> I *don’t want* OpenSSL to make *any* estimation of the amount of provided 
> entropy. All I want it to do is to mix these bits into the RNG state. It’s 
> *my* business how much entropy I’m providing – but I don’t want OpenSSL to 
> make any decision regarding pull from other entropy sources based on my input.
> 
> Does it sound reasonable? (He, it does to me ;)

But that is not the API that RAND_add() provides. It's a push not
a pull API. With the DRBG you can do this, assuming using it's an
extraction / derivative function.

One of the suggestions I did before is to have RAND_poll_ex() take
a parameter about how much randomness is needed, but I think it's
also a wrong API and I'm thinking about removing it.

> But now we just ignore it and assume every bit with get contains 1
> bit of randomness and we're sundenly seriously overestimating the
> amount of randomness we're getting.
> 
> If I had my way, you’d assume that every bit contains 0 bits of entropy, but 
> mix it in regardless because that’s what the user is asking you to do.

Which is why I suggested we use this for the additional data. But
I think that as long as we have both APIs we might actually need
it for the entropy input. If there is no other way to add
randomness, RAND_add() is our current documented way to add it,
and it will need to keep working.


Kurt

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

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

[Kurt Roeckx]

On Tue, Aug 29, 2017 at 06:50:37PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> On 8/29/17, 12:45, "openssl-dev on behalf of Salz, Rich via openssl-dev" 
>  wrote:
> 
> ➢ An other problem with the current implemenation is that the
> ➢ randomness parameter that's now given to RAND_add() is just
> ➢ ignored, it assumes it's the same as the length.
> 
> For what it’s worth, this was done deliberately, make RAND_add and 
> RAND_seed equivalent.
> 
> I am skeptical of the ability to get that estimate correct.
> 
> Someone on GH there is a conversation thread about turning that into a 
> percentage, which seems like the best thing to do for any new API.
> 
> 
>  What’s the point of having this potentially harmful parameter? If it weren’t 
> ignored – how would OpenSSL use it?
> 
> If, based on its value, OpenSSL may decide that it now got “enough” entropy 
> and doesn’t need to pull more from other sources before serving randomness to 
> requestors – then it is harmful. “Over-confidence” in this value by the 
> caller can negatively impact the quality of the produced random numbers.

As long as you have sources that don't provide 1 bit of randomness
per bit that you provide you need to have an estimate of how much
randomness it really contains. And you should probably seriously
underestimate it so that you're sure that you collect enough.

The problem with ignoring an existing parameter is that people
could be calling it with for instance the value of 0, knowing it
contains as good as none entropy. Or they could feed the unwithened
output of an TRNG in that with an estimate of randomness it provides.
And OpenSSL used to do the right thing with that.

But now we just ignore it and assume every bit with get contains 1
bit of randomness and we're sundenly seriously overestimating the
amount of randomness we're getting. This is a documented public API,
you can't just go and ignore this parameter.


Kurt

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

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

[Kurt Roeckx]

On Tue, Aug 29, 2017 at 01:05:21PM +, Dr. Matthias St. Pierre wrote:
> 
> Currently it's only possible to customize the callbacks but not the 
> deterministic algorithm. IMHO this is sufficient for the needs of a standard 
> OpenSSL user who only wants control over the entropy source. A true new 
> algorithm (like e.g. CHACHA2_DRBG) should be implemented by experts and added 
> mainstream. So I don't see any advantage of having an engine over using the 
> 'vtable' approach from the FIPS DRBG, which has been removed.

I've been looking at implementing a chacha20 based DRBG, which
isn't that hard. But there are various choices you can make, and
every chacha20 RNG that I've seen seems to take a random set of
those choices. I really wish there was some standardized version.


Kurt

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

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

[Kurt Roeckx]

On Tue, Aug 29, 2017 at 11:31:03AM +, Dr. Matthias St. Pierre wrote:
> > -Ursprüngliche Nachricht-
> > Von: openssl-dev [mailto:openssl-dev-boun...@openssl.org] Im Auftrag von 
> > Matt Caswell
> > Gesendet: Dienstag, 29. August 2017 12:17
> > An: openssl-dev@openssl.org
> > Betreff: Re: [openssl-dev] Plea for a new public OpenSSL RNG API
> > 
> > 
> > On 29/08/17 10:45, Dr. Matthias St. Pierre wrote
> > > ...
> > > The 'RAND_add()/RAND_bytes()' pattern is broken
> > > ===
> > >
> > > In OpenSSL, the classical way for the RNG consumer to add his own
> > > randomness is to call 'RAND_add()' before calling 'RAND_bytes()'. If
> > > the new 'RAND_OpenSSL()' method (the "compatibility layer" hiding the
> > > public RAND_DRBG instance)  is the default, then this does not work
> > > as expected anymore:
> > > ...
> > 
> > Is there a potential security vulnerability here? Applications using the
> > "old" APIs expect RAND_add() to behave in a particular way. If we have
> > silently changed this behaviour in 1.1.1 are they exposed?
> 
> Don't worry, this issue is new, the global 'rand_bytes' buffer has only been 
> introduced by the DRBG port to master in August. I don't think it's a big 
> deal to fix it. The reason I mentioned it here was to emphasize, that it is 
> really hard to get the different philosophies (push vs. pull) of the two APIs 
> working together correctly. The code was reviewed by several people and 
> nobody noticed it. By the way: the approach using the fixed size global 
> 'rand_bytes' buffer has another issue, which I will try to write down on 
> GitHub within the next days.

I've actually noticed how this works and I have already partially
rewritten it, but I'm still not very happy about it. I think by
RAND_add() should not be called internally. But the question then
is what to do when an application calls RAND_add(), we should be
doing something with the buffer that's given. I think the best way
to deal with it is with the DRBG API is used, RAND_add() is used for
additional data.

We now have 2 global DRBGs, and I think I want to have 1 of them
chain to the other. RAND_add() could then be used for the master.

An other problem with the current implemenation is that the
randomness parameter that's now given to RAND_add() is just
ignored, it assumes it's the same as the length.


Kurt

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

Re: [openssl-dev] Plea for a new public OpenSSL RNG API

[Kurt Roeckx]

I actually plan to work on most of not all the things you mention.
This will probably result in the API changing before it's made
public. I'm probably slow, so please be patient.


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Thu, Aug 24, 2017 at 05:47:55PM +, Salz, Rich via openssl-dev wrote:
> 
> >This is why I want to add things like that by default in the
> >additional data.
>   
> On reseed or generate?

Mostly on generate, but I see little point in not doing it on
reseed.


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Thu, Aug 24, 2017 at 05:32:15PM +, Salz, Rich via openssl-dev wrote:
> 
> >An idea that I had was to default to reseed on fork if we know we
> >have a working syscall.

... to get entropy

>   
> Or /dev device too?

The point is that you can't be sure that /dev is still going to be
available, we need to be sure we still have a source available.


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Thu, Aug 24, 2017 at 08:07:54AM +1000, Peter Waltenberg wrote:
> The bad case I'm aware of is the fork() one as it's critical that the RNG 
> state diverge on fork(). Without that you can get some very nasty 
> behaviour in things like TLS servers. Some of which have a thread pool + 
> fork() model to handle increasing load.
> 
> While ideally you'd do a complete reseed, just different state in each RNG 
> is a LOT better than nothing, and even PID + whatever else you can 
> scrounge up will help a lot. Even the high res counters available on most 
> current CPU's would help there because forking multiple processes isn't 
> quite synchronous.

This is why I want to add things like that by default in the
additional data.


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Wed, Aug 23, 2017 at 05:12:56PM -0400, Paul Kehrer wrote:
> On August 19, 2017 at 2:48:19 AM, Salz, Rich via openssl-dev (
> openssl-dev@openssl.org) wrote:
> 
> 
> I think the safest thing is for us to not change the default. Programs that
> know they are going to fork can do the right/safe thing. It would be nicer
> if we could automatically always do the right thing, but I don’t think it’s
> possible.
> 
> 
> It appears the current position is that since there will be edge cases
> where a reseed would fail (thus either halting the RNG or silently not
> reseeding it) that we should not attempt to reseed? I would argue it is
> better to attempt to reseed and document that edge cases may need to reseed
> themselves. This dramatically narrows the window from "everybody needs to
> do it" to "users in certain scenarios that are becoming rarer by the day
> need to do it". Given that backwards compatibility is a concern maybe
> failure to reseed on fork should only drop an error on the child process's
> error queue though? That behavior could potentially be a separate flag that
> OpenSSL uses by default (OPENSSL_TRY_TO_INIT_ATFORK), and then
> OPENSSL_INIT_ATFORK can be more strict about reseed failures if desired.

An idea that I had was to default to reseed on fork if we know we
have a working syscall.


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Mon, Aug 21, 2017 at 06:12:16PM +0200, Kurt Roeckx wrote:
> So I guess you want an interface that can both add things to the
> "entropy" pool, and to the "additional data" pool? It shouldn't
> be that hard, I'll try to come up with some proposal soon.

I was thinking about adding 2 callbacks. One that is called when we
want to have entropy, the other that is called when we can use
additional data. The first would only be called by the global
DRBGs, the second by all DRBGs.

The DRBG now actually already uses callbacks to get entropy (and
a nonce), but none of that is exposed. So it would require
additional callbacks for additional data. We should probably just
add functions to set the defaults or something.


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Mon, Aug 21, 2017 at 03:56:29PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> >> P.S. I wonder if it's feasible to have a configuration parameter that 
> >> would allow me to tell the TLS code to invoke RAND_add_ex() before 
> >> generating session keys?
> >
> > Either you accept that NIST SP 90A is right, or you just bypass it 
> > completely.  We’re in the first camp.  
> 
> You mean NIST SP 800-90A, released Jan 2012 and withdrawn Jun 2015? With Rev 
> 1 *draft* currently available (released Jun 2015)?  ;-)
> 
> I’m glad you agree that “it is right”, because in our argument it supports my 
> side over yours. Let’s go through the 90A Rev 1 draft 
> http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf:
> 
> Page 11 Section 7 provides a functional model of a DRBG (Figure 1), clearly 
> showing “additional input” for both the Reseed Function and the Generate 
> Function.  The text says “… and may include additional optional sources, 
> including … additional input.”

I at least have a plan to add additional data, but probably not in
the current idea was probably not the way you would like to see it.
My idea was to query at least various sources that we don't
attribute any entropy to, like getpid(), gettimeofday(),
clock_gettime(), the TSC, ... It might also use things like RDRAND
/ RDSEED which we don't trust.

So I guess you want an interface that can both add things to the
"entropy" pool, and to the "additional data" pool? It shouldn't
be that hard, I'll try to come up with some proposal soon.


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Fri, Aug 18, 2017 at 09:22:48AM +0200, Tomas Mraz wrote:
> On Thu, 2017-08-17 at 22:11 +0200, Kurt Roeckx wrote:
> > On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote:
> > > On Thu, 2017-08-17 at 12:22 +, Salz, Rich via openssl-dev
> > > wrote:
> > > > I understand the concern.  The issue I am wrestling with is
> > > > strict
> > > > compatibility with the existing code.  Does anyone really *want*
> > > > the
> > > > RNG’s to not reseed on fork?  It’s hard to imagine, but maybe
> > > > somewhere someone is.  And then it’s not about just reseeding,
> > > > but
> > > > what about when (if) we add other things, like whether or not the
> > > > secure arena gets zero’d in a child?
> > > > 
> > > > So let me phrase it this way:  does anyone object to changing the
> > > > default so NO_ATFORK must be used to avoid the reseeding and
> > > > other
> > > > things we might add later?
> > > 
> > > I can hardly see anyone would be broken if the default is to reseed
> > > RNG on fork. However that might not be true for other atfork
> > > functionalities so perhaps there is a need to make each of these
> > > future
> > > atfork functions configurable and either on or off by default
> > > individually and not as a whole.
> > 
> > There might be cases where after fork you're not able to get to
> > /dev/urandom anymore.
> 
> I do not think so. Which particular cases do you have on mind? Yes,
> after fork+exec you could for example switch SELinux domain and won't
> be able to access something but immediately after fork it should not be
> so. Also perhaps the reseeding after fork can be made less strict in
> regards to failures reading /dev/urandom or so.

It seems to me this all depends on the order of things you do to
create a daemon. You could make sure the RNG is inited, chroot,
and then fork for instance. And I suspect there are actually
programs that do it in that order.


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Thu, Aug 17, 2017 at 02:34:49PM +0200, Tomas Mraz wrote:
> On Thu, 2017-08-17 at 12:22 +, Salz, Rich via openssl-dev wrote:
> > I understand the concern.  The issue I am wrestling with is strict
> > compatibility with the existing code.  Does anyone really *want* the
> > RNG’s to not reseed on fork?  It’s hard to imagine, but maybe
> > somewhere someone is.  And then it’s not about just reseeding, but
> > what about when (if) we add other things, like whether or not the
> > secure arena gets zero’d in a child?
> > 
> > So let me phrase it this way:  does anyone object to changing the
> > default so NO_ATFORK must be used to avoid the reseeding and other
> > things we might add later?
> 
> I can hardly see anyone would be broken if the default is to reseed
> RNG on fork. However that might not be true for other atfork
> functionalities so perhaps there is a need to make each of these future
> atfork functions configurable and either on or off by default
> individually and not as a whole.

There might be cases where after fork you're not able to get to
/dev/urandom anymore.


Kurt

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

Re: [openssl-dev] Windows system cert store

[Kurt Roeckx]

On Sun, Jul 09, 2017 at 09:15:32AM +0200, Richard Levitte wrote:
> In message 
> 

Re: [openssl-dev] Compiler requirements

[Kurt Roeckx]

On Tue, Jul 04, 2017 at 05:42:42PM +0200, Richard Levitte wrote:
> In message 
> <2f548b68de1c47dfaa6a3b0107080...@usma1ex-dag1mb1.msg.corp.akamai.com> on 
> Tue, 4 Jul 2017 15:05:06 +, "Salz, Rich via openssl-dev" 
>  said:
> 
> openssl-dev> > beldmit> What is the minimal version of the compiler to build 
> openssl?
> openssl-dev> > beldmit> Is it still required C89 compatibility or C99 
> standard can be used?
> openssl-dev> > beldmit>
> openssl-dev> > beldmit> Unfortunately, I did not find these requirements in 
> documentation.
> openssl-dev> > 
> openssl-dev> > At the beginning of INSTALL, you will find a set of 
> requirements.  On of them
> openssl-dev> > is "an ANSI C compiler".
> openssl-dev> 
> openssl-dev> That doesn't answer the question :)  Which version of ANSI C?
> 
> Ah, you're right, "ANSI C" is a bit of a loose target depending on who
> you ask.  As far as I know, we refer to C89/C90 (they are essentially
> the same for our intents and purposes).
> 
> openssl-dev> I believe C89 is written down somewhere.
> 
> C89 is written nowhere in the source at least, nor is C90.  We should
> probably clarify that.
> 
> 
> Speculating a bit, it's probably safe to say that C95 compiler is fine
> as well.  C99, not so much, there's too much risk that we start
> excluding some platforms if we start using its features.  Anyway, I
> don't think it's safe to upgrade our minimum expectations now.
> OpenSSL 1.2.0 would be a good time for such re-evaluations.

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

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


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Wed, Jun 28, 2017 at 12:01:29PM -0500, Benjamin Kaduk via openssl-dev wrote:
> 
> I'm not sure what you mean by "draining the kernel's entropy pools". 
> That is, if you are adhering to the belief that taking random bits out
> of a generator removes entropy from it that must be replenished, does
> that not apply also to any generator/pool we write for ourselves?  Or
> maybe you just refer to the behavior of linux /dev/random, in which case
> I would point out Ted (the author/maintainer of linux /dev/random)'s
> suggestion to just use (getrandom or) /dev/random and tacit agreement
> that the behavior of reducing the entropy count on reads from
> /dev/random is not really needed anymore.

Replace all /dev/random with /dev/urandom.

> At boot time *all* pools are empty.  FreeBSD has a random seed file on
> disk to be loaded on next boot that helps with this (I didn't check
> linux),

It depends on the distro, but they should all be doing this. On
systems using systemd that file is probably
/var/lib/systemd/random-seed.


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Tue, Jun 27, 2017 at 11:56:04AM -0700, John Denker via openssl-dev wrote:
> On 06/27/2017 02:28 AM, Matt Caswell wrote:
> >>
> >> I also agree that, by default, using the OS provided source makes a lot
> >> of sense.
> 
> Reality is more complicated than that;  see below.
> 
> On 06/27/2017 11:50 AM, Benjamin Kaduk via openssl-dev wrote:
> 
> > Do you mean having openssl just pass through to
> > getrandom()/read()-from-'/dev/random'/etc. or just using those to seed
> > our own thing?
> > 
> > The former seems simpler and preferable to me (perhaps modulo linux's
> > broken idea about "running out of entropy")
> 
> That's a pretty big modulus.  As I wrote over on the crypto list:
> 
> The xenial 16.04 LTS manpage for getrandom(2) says quite explicitly:
> 
> >> Unnecessarily reading large quantities  of data will have a
> >> negative impact on other users of the /dev/random and /dev/urandom
> >> devices.
> 
> And that's an understatement.  Whether unnecessary or not, reading
> not-particularly-large quantities of data is tantamount to a
> denial of service attack against /dev/random and against its
> upstream sources of randomness.
> 
> No later LTS is available.  Reference:
>   http://manpages.ubuntu.com/manpages/xenial/man2/getrandom.2.html
> 
> Recently there has been some progress on this, as reflected in in
> the zesty 17.04 manpage:
>   http://manpages.ubuntu.com/manpages/zesty/man2/getrandom.2.html
> 
> However, in the meantime openssl needs to run on the platforms that
> are out there, which includes a very wide range of platforms.

And I think it's actually because of changes in the Linux RNG that
the manpage has been changed, but they did not document the
different behavior of the kernel versions.

In case it wasn't clear, I think we should use the OS provided
source as a seed. By default that should be the only source of
randomness.


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Tue, Jun 27, 2017 at 02:42:52PM +0200, Matthias St. Pierre wrote:
> 
> So I have two questions:
> 
> - Do you intend to continue supporting RAND_set_rand_method() or will there 
> only be one 'perfect' random generator and no choice anymore?

I think we should have a default one, but an option to have a
different one.

> - Do you consider the SP800-90A DRBG outdated or will there be a chance that 
> it will be added to the OpenSSL master as
>   officially supported RAND method?

I think we should have at least 1 that follows SP800-90A, it's
clearly something some people will need.

> - Will the new OpenSSL RNG support a way to configure reseed intervals and 
> external entropy sources in a similar fashion
>   as the FIPS DRBG did?

It should at least reseed by default. Having an option to change
the default interval might make sense.

There clearly should be a way to use a source other than the one
provided by the kernel, which I think it needed for SP800-90A.


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Mon, Jun 26, 2017 at 09:39:47PM -0700, John Denker via openssl-dev wrote:
> 
> I'm not mentioning any names, but some people are *unduly*
> worried about recovery following compromise of the PRNG
> internal state, so they constantly re-seed the PRNG, to
> the point where it becomes a denial-of-service attack
> against the upstream source of randomness.
> 
> This is also mostly pointless, because any attack that
> compromises the PRNG state will likely compromise so many
> other things that recovery will be very difficult.  All
> future outputs will be suspect.
> 
> So please let's not go overboard in that direction.
> 
> On the other hand, it seems reasonable to insist on /forward/
> secrecy.  That is, we should insist that /previous/ outputs
> should not be compromised.  This is achievable at small but
> not-quite-zero cost.

I think that's named backward secrecy?


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Mon, Jun 26, 2017 at 01:18:58PM -0700, John Denker via openssl-dev wrote:
> On 06/26/2017 12:41 PM, Salz, Rich wrote:
> 
> > Suppose the chip supports RDRAND but the runtime doesn't have
> > getrandom or /dev/random?
> 
> That's an easy one!
> 
> Check the feature-test bit and then call RDRAND yourself.
> Code to do this exists, e.g.
>   
> https://en.wikipedia.org/wiki/RdRand#Sample_x86_asm_code_to_check_upon_RDRAND_instruction
> 
> A version of that for 64-bit architecture exists somewhere, too.

We already have code to detect it.


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Mon, Jun 26, 2017 at 11:29:19AM -0700, John Denker via openssl-dev wrote:
> What's your threat model?  I know that sounds like a cliché,
> but it's actually important.
> 
> In particular, in my world the #1 threat against any PRNG
> is improper seeding. 
>  --  If you trust the ambient OS to provide a seed, why not
>   trust it for everything, and not bother to implement an
>   openssl-specfic RNG at all?

As I understand it, the main reason to provide our own one is
speed. Related to it, it might not be able to provide the amount
of random data that we would like to use.

I see no other reasons not to use the OS provided one.

> And (!) what do you propose to do when a suitable seed is not
> available at the moment but might be available later?

The current API returns an error, but it would be better
that it would block until it's available.

> Are you designing to resist an output-text-only attack?  Or do
> you also want "some" ability to recover from a compromise of
> the PRNG internal state?

I think at least some people seem to want to deal with a
compromised internal state, but I have to wonder how it would
get compromised in the first place and if you can really fix it.

> Is there state in a persistent file, or only in memory?

We currently have a ~/.rnd file. We should probably get rid of it.

>   “Recommendation for Random Number Generation Using Deterministic Random Bit 
> Generators”
>   http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf
> 
> That design may look complicated, but if you think you can
> leave out some of the blocks in their diagram, proceed with
> caution.  Every one of those blocks is there for a reason.

SP800-90A (or revision 1) can clearly be used as reference on how
to implement it, even if we don't use an approved algorithm from
it. And I really think we should look at that document when
implementing it.

There should probably also be an option to use an RNG that
conforms to it.

> > Randomness should be whitened.
> 
> Whitening at the input is neither difficult nor necessary nor sufficient.
> The hard part is obtaining a reliable lower bound on the amount of
> useful randomness in the bit-blob when it appears at the input.  Where
> did the bits come from?  Where did the bound come from?  Do you trust
> the generic openssl user, who knows nothing about cryptology, to provide
> either one?

I think it should by default be provided by the OS, and I don't
think any OS is documenting how much randomness it can provide.

> >> Do you think we need to use multiple sources of randomness?
> 
> Quality is more important than quantity.
> 
> N reliable sources is marginally better than N-1 reliable sources.
> One reliable source is immeasurably better than any number of
> unreliable sources.
> 
> Combining many lousy sources and hoping that one of them will do
> the job is not good engineering practice.

The OS should already be using all the different sources. I don't
think OpenSSL also using those sources is adding anything, I think
it will only make the code harder for no good reason.


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Mon, Jun 26, 2017 at 04:17:41PM +, Salz, Rich via openssl-dev wrote:
>  
> > > Is it worth reposting my thoughts with your suggested wording changes?
> > 
> > OK.  Off-list or on.  This stuff is important.
> 
> Reposting.
> 
> My thoughts.
> 
> Randomness should be whitened.  Anything feed into an randomness pool, should 
> be mixed in and run through SHA256.
> pool = SHA256(pool || new-randomness)

Do you think we need to use multiple sources of randomness? I
think we should only use the one source, the one provided by the
kernel. All sources of randomness already go in it, there is no
need for us to try add any other source that it's already using.

So there should be no need to do any whitening.

> Each pool should have an atomic counter that is incremented when randomness 
> is added.  Descendant pools can compare counters and mix in their parent when 
> the counters don’t match.  Then when RAND_poll is called, or perhaps a new 
> routine RAND_poll_system, it goes into the global pool and eventually all 
> other pools will get it (whitened with their current state).  RAND_poll isn’t 
> documented.

The only thing the pool should care about is that it's been
initialized or not, and if it needs to add more data to it or not.

> Then to generate random bytes use ChaCha.  See, for example, 
> http://gitweb.dragonflybsd.org/dragonfly.git/blob/2aa3f894bd9b5b8f58a1526adb26663405b91679:/sys/kern/subr_csprng.c
>   My first thoughts on reading that code were, wow, is it really that easy?

You might also want to take a look at something like:
https://github.com/smuellerDD/chacha20_drng/blob/master/chacha20_drng.c

> We want to be able to save the current global state – write to a BIO – and 
> restore it – read from a BIO.  This will let us reasonably work in 
> low-randomness situations like system boot.

Ideally we should refuse to operate in a situation where the kernel
didn't initialize it's RNG yet. I only know about Linux being broken
in this regard, and getrandom() / getentropy() really should be
available on them by now. I don't think we should add a workaround
by reading 1 byte from /dev/random if getrandom() isn't available.


Kurt

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

Re: [openssl-dev] Work on a new RNG for OpenSSL

[Kurt Roeckx]

On Mon, Jun 26, 2017 at 08:58:21AM -0700, John Denker via openssl-dev wrote:
> In the context of:
> 
> >> If you mean for something to be hard for the attacker to guess,
> >> the word "adamance" can be used.
> 
> On 06/26/2017 08:32 AM, Salz, Rich wrote:
> 
> > All my attempts to look up a definition of this word came up with a noun 
> > for for adamant.
> 
> The word "adamance", meaning hardness (as in hard to guess),
> was coined for this purpose.
> 
> The allusion to "adamance", meaning hardness (as in rheologically
> hard), is not a coincidence.
> 
> Can anybody suggest a better term?

unpredictable?


Kurt

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

Re: [openssl-dev] discussion venue policy

[Kurt Roeckx]

On Mon, Jun 26, 2017 at 07:30:52AM -0700, John Denker via openssl-dev wrote:
> On 06/26/2017 05:49 AM, Salz, Rich wrote:
> 
> > Please take a look at GitHub pull request
> 
> Is the RNG topic going to be discussed on github, or on openssl-dev?
> What about other topics?
> 
> Having some topics one place and some another seems like a Bad Idea™
> Having a single topic split across multiple venues seems even worse.

I think general discussion about a topic should be here,
discussion about a specific patch should be on github.


Kurt

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

Re: [openssl-dev] [RFC 0/4] Kernel TLS socket API

[Kurt Roeckx]

On Thu, Jun 08, 2017 at 10:43:15AM +0200, Hannes Frederic Sowa wrote:
> 
> we have discussed this in the past on net...@vger.kernel.org but I just
> want to point out here again, that renewing the symmetric crypto keys is
> not supported in the kernel part (for the time being).
> 
> So in case the application depends on renegotiation (TLS1.2, which is
> the only version supported right now by the kernel AFAIK) as well key
> updates in TLS1.3 won't work.

It might be useful to be able to transfer the state in both
directions, so that those things are possible.

> Because this feature is not transparent yet, I think it definitely needs
> a switch for applications to control it.

We will probably also at least need to have way to find out if a
cipher is supported by the kernel we're running on or not.


Kurt

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

Re: [openssl-dev] [RFC 0/4] Kernel TLS socket API

[Kurt Roeckx]

On Wed, Jun 07, 2017 at 03:35:45PM +0300, Boris Pismenny wrote:
> Hello all,
> 
> I would like to introduce you to the new kernel API for TLS transmit-side
> data-path, and open a discussion regarding its support in OpenSSL.

So my understanding is that there are really 2 parts in the kernel
that change:
- The kernel is aware of TLS and can do the symmetric encryption
- The kernel can offload the symmetric encryption to the NIC

And I guess you're mostly interested in the combination of the two
where you would end up with the unencrypted data going go the NIC
and that you might get speeds close to what you can do
unencrypted. The performance gains would come from avoiding making
copies and not doing the encryption on the CPU.

My understanding from the old data is that moving the encryption
to the kernel had a negative performance impact. So this at least
looks like something we do not always want to enable. It might be
useful to have an API where we can check that the offload is
supported, or that we have an option to enable moving it to the
kernel.


Kurt

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

[openssl-dev] Google OSS-Fuzz reward

[Kurt Roeckx]

Google awarded us 1000 USD for the initial integration with
OSS-Fuzz. See 
https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html

I have asked Google to donate it to European Digital Rights (EDRi,
https://edri.org/). Google doubles the amount if you donate it to
a non-profit organization, so they should be receiving 2000 USD.


Kurt

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

Re: [openssl-dev] OpenSSL Project Bylaws

[Kurt Roeckx]

On Tue, Feb 14, 2017 at 09:30:31AM +, Matt Caswell wrote:
> I am pleased to be able to announce the publication of our new Project
> Bylaws. I have written a short blog post about what we are hoping to
> achieve and some of the thinking that went into these here:
> 
> https://www.openssl.org/blog/blog/2017/02/13/bylaws/
> 
> The bylaws themselves are available here:
> 
> https://www.openssl.org/policies/bylaws.html
> 
> The Project Bylaws describe how the OpenSSL Project operates, what the
> different project roles are and how decisions are made. Incidentally
> these project bylaws should not be confused with the OpenSSL Software
> Foundation (OSF) Bylaws which were also recently published and describe
> how that legal entity operates.

We have also published a guideline for commiters here:
https://www.openssl.org/policies/committers.html


Kurt

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

Re: [openssl-dev] ETA: TLS 1.3 release

[Kurt Roeckx]

On Wed, Apr 19, 2017 at 02:57:13PM +0200, Stefan Eissing wrote:
> 
> > Am 19.04.2017 um 14:14 schrieb Salz, Rich via openssl-dev 
> > :
> > 
> >> Out of curiosity, what's the ETA for TLS 1.3?
> >> [1] mentions April 5 as the release date (which was two weeks ago).
> >> 
> >> [1]: https://blogs.akamai.com/2017/01/tls-13-ftw.html
> > 
> > That's an akamai blog, not an openssl statement :)  And that post is 
> > misleading, it should have said "available" not "released."
> 
> Ok, let me announce then that Apache httpd then also has TLSv1.3 support 
> "available". But our code is in trunk and 2.4.x.

And when can we expect a release of that? :)

(As in a release that supports OpenSSL 1.1)


Kurt

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

Re: [openssl-dev] License change agreement

[Kurt Roeckx]

On Fri, Mar 24, 2017 at 12:22:14PM -0700, James Bottomley wrote:
> 
> This is my understanding as well.  From the GPL side, for both dynamic
> and static linking of openssl to GPLv2 code, the section 3 system
> exception applies.

Not everybody agrees that it applies.


Kurt

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

Re: [openssl-dev] License change agreement

[Kurt Roeckx]

On Fri, Mar 24, 2017 at 08:02:25PM +0100, Florian Weimer wrote:
> * Quanah Gibson-Mount:
> 
> > Zero people that I know of are saying to switch to the GPL.  What is
> > being pointed out is that the incompatibility with the current
> > OpenSSL license with the GPLv2 has been a major problem.
> 
> The alleged incompatibility of OpenSSL with the GPLv2 has been used to
> promote GNUTLS in the past (and to a much lesser extent, a certain
> crypto consolidation effort intending to switch everything to NSS).
> But GNUTLS has since left the GNU project, and I'm not aware of anyone
> on the distribution side still saying that the old OpenSSL license
> (particular when used as a dynamically-linked system library) and the
> GPLv2 are incompatible.  It's just not considered a problem anymore.

As far as I know, for Debian it's still a problem that a GPL
application links to openssl.

A few examples:
- We have multiple curl versions, linked to openssl, gnutls, nss.
  And you then have to build against the correct one for license
  reasons.
- QT (which is LGPL?) does not itself link to libssl but can
  dynamically load it so that GPL applications can use QT assuming
  they don't use SSL.
- We have asked upstream projects to add an openssl exception to
  their GPL license.


Kurt

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

Re: [openssl-dev] License change agreement

[Kurt Roeckx]

On Fri, Mar 24, 2017 at 11:43:17AM -0700, Quanah Gibson-Mount wrote:
> --On Friday, March 24, 2017 7:47 PM +0100 Kurt Roeckx <k...@roeckx.be>
> wrote:
> 
> > On Fri, Mar 24, 2017 at 10:18:40AM -0700, Quanah Gibson-Mount wrote:
> > > --On Friday, March 24, 2017 6:12 PM + "Salz, Rich" <rs...@akamai.com>
> > > wrote:
> > > 
> > > > > Thanks Rich, that's a more useful starting point.  Has dual licensing
> > > > > been considered?  Both in 2015 and now, the lack of GPLv2
> > > > > compatibility has shown to be a serious drawback to the APLv2.
> > > >
> > > > Dual licensing means that it is also available under a
> > > > no-patent-protection license which is an issue for us.
> > > 
> > > APLv2 and MPLv2 both have patent protections.  How would a dual license
> > > of APL+MPL result in a no-patent-protection license?
> > 
> > As far as I understand the MPLv2 is only compatible with the GPLv2
> > in a very specific case which makes it not useful for people that
> > would actually want to link their application with it.
> 
> Reference?  I certainly don't see that in
> <https://www.mozilla.org/en-US/MPL/2.0/FAQ/>

Then I suggest you read that FAQ again.


Kurt

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

Re: [openssl-dev] License change agreement

[Kurt Roeckx]

On Fri, Mar 24, 2017 at 10:18:40AM -0700, Quanah Gibson-Mount wrote:
> --On Friday, March 24, 2017 6:12 PM + "Salz, Rich" 
> wrote:
> 
> > > Thanks Rich, that's a more useful starting point.  Has dual licensing
> > > been considered?  Both in 2015 and now, the lack of GPLv2 compatibility
> > > has shown to be a serious drawback to the APLv2.
> > 
> > Dual licensing means that it is also available under a
> > no-patent-protection license which is an issue for us.
> 
> APLv2 and MPLv2 both have patent protections.  How would a dual license of
> APL+MPL result in a no-patent-protection license?

As far as I understand the MPLv2 is only compatible with the GPLv2
in a very specific case which makes it not useful for people that
would actually want to link their application with it.


Kurt

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

Re: [openssl-dev] License change agreement

[Kurt Roeckx]

On Fri, Mar 24, 2017 at 08:36:02AM +0100, Otto Moerbeek wrote:
> On Fri, Mar 24, 2017 at 08:21:49AM +0100, Marcus Meissner wrote:
> 
> > On Fri, Mar 24, 2017 at 07:48:58AM +0100, Otto Moerbeek wrote:
> > > On Fri, Mar 24, 2017 at 04:11:48AM +, Blumenthal, Uri - 0553 - MITLL 
> > > wrote:
> > > 
> > > > Apache license is fine for me, while GPL could be problematic. 
> > > > Incompatibility with GPLv2 is not a problem for us. 
> > > > 
> > > > If it is a problem for somebody - feel free to explain the details. 
> > > > Though I think the decision has been made, and the majority is OK with 
> > > > it. 
> > > 
> > > I like to mention that any license change cannot be made based on a
> > > majority vote or any other method other than getting each author (or
> > > its legal representative) to *explicitly* allow the change. The method
> > > of "nothing heard equals consent" is not valid in any jurisdiction I
> > > know of.
> > > 
> > > While I'm not a contributor (I think I only sent in a small diff years
> > > ago), I would like to stress that the planned relicensing procedure is
> > > not legal and can be challenged in court.
> > 
> > Well, emails were sent yesterday out to _all_ contributors for ack/deny the 
> > change.
> 
> Read the last line of the mail, it says the no reactions equals
> consent. That is the illegal part.

The legal advice we got said that we should do our best to contact
people. If we contacted them, they had the possibility to say no.
We will give them time and go over all people that didn't reply to
try to reach them.

But if they don't reply, as said, we will assume they have no
problem with the license change. If at some later point in time
they do come forward and say no, we will deal with that at that
time.


Kurt

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

Re: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release

[Kurt Roeckx]

On Mon, Mar 20, 2017 at 10:41:12PM +, Jason Vas Dias wrote:
> Hi - much thanks for many years of great OpenSSL releases,
> but this 1.1.0 branch, IMHO, should not be put above the 1.0.2k
> release on the website as the 'latest / best OpenSSL release' - this just
> wastes everybody's time .  No using software can use this release,
> such as the latest releases of OpenSSH,  ISC BIND (named) / ISC DHCP,  ntpd
> (... the list can go on and on - does the latest httpd  compile with it? )

I have send patches for all of those that you just mentioned so
that they can get build using both 1.0.2 and 1.1.0.

> I did waste a few hours today getting ISC BIND 9.11.0-P3 & DHCP 4.3.5
> & ntpd 4.3.93 to use 1.1.0e , (I can generate & send the patches for
> them to anyone who wants them),

DHCP 4.3.5 seems to work just fine with 1.1.0.

The latest ntp release is 4.2.8p9 which should just work with
openssl 1.1.0. (I have no idea why they don't list it on their
download page now, or why the development version is so old.)

bind has applied patches, I'm just not sure in which branches.

> the latest version of OpenSSH (v7.4.P1) to at least compile with it,
> but that version of OpenSSH is broken in so many ways because of
> openssl 1.1.0  - it can't even read or write its ED25519
> /etc/ssh_host_ed25519.key file.

The ed25519 support in openssh doesn't even come from openssl. 

> which mainly
> involved including the '*_lo?cl.h' & '*_int.h'  headers

Including the internal headers is not a good patch. This will
break.


Kurt

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

Re: [openssl-dev] Travis [extended tests] tag

[Kurt Roeckx]

On Sun, Feb 26, 2017 at 11:23:42PM +0100, Andy Polyakov wrote:
> In order to improve CI turn-around times Travis config in master branch
> was tweaked to minimize the time it takes to process pull requests. This
> is done by "short-circuiting" most expensive tests: sanitizers,
> coverage, wine-based tests. Thing to keep in mind is that
> "short-circuited" test come out as passed/green. Rationale is that if
> minimum tests pass, the build should still be marked green on github.
> Even though it gives somewhat deceiving picture, in sense that you get
> green check mark for test that might have failed otherwise. Expensive
> tests are marked with "EXTENDED_TEST=yes" on the build page, and one can
> easily see if it was skipped by looking at time it took to skip it, it
> should be ~1 minute.
> 
> At the same time it would be inappropriate to deny the mere possibility
> to exercise complete test set even on per-pull-request basis. [Note that
> complete tests are always executed for each repo-push.] For this reason
> possibility to "opt-in" for expensive tests was arranged by adding
> "[extended tests]" tag to *last* commit. If forgotten (in case you
> reckoned that request is "worthy" extended tests), or claimed desired
> afterwards, it's possible to simply amend the last commit, add the tag
> and force push. In such case minimal tests would be effectively wasted
> (because they will be executed twice), but overall it should still be
> resource saving, since majority of pull requests won't require extended
> testing.
> 
> And in the context it's worth keeping in mind that it's possible to skip
> CI tests altogether by tagging commit with "[skip ci]". This option is
> appropriate for commentary or documentation typo fixes, readme updates,
> non-x86 code updates...

Can you explain how to tag it?


Kurt

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

Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

[Kurt Roeckx]

On Sun, Feb 26, 2017 at 09:26:06AM +0300, Andrey Ponomarenko wrote:
> 31.01.2017, 10:21, "Nikos Mavrogiannopoulos":
> > On Fri, 2017-01-27 at 10:54 -0600, Benjamin Kaduk via openssl-dev
> > wrote:
> >>  [moving from github to -dev]
> >>
> >>  On 01/27/2017 07:36 AM, mattcaswell wrote:
> >>  > 1.0.2 is the software version.
> >>  > The numbers on the end of lbssl.so.1.0.0 refer to the ABI version -
> >>  > which is different. Software version 1.0.2 is a drop in replacement
> >>  > for 1.0.1, which is a drop in replacement for 1.0.0 - hence they
> >>  > all have the same ABI version.
> >>  >
> >>
> >>  There was some discussion about 1.0.1 being EoL on a FreeBSD list
> >>  [0], and whether it would make sense to move to 1.0.2 on their stable
> >>  branch, which led to someone making the claim that 1.0.2 has removed
> >>  4 symbols compared to 1.0.1, and thus is not strictly ABI compatible,
> >>  linking to https://abi-laboratory.pro/tracker/timeline/openssl/ .  If
> >>  I start semi-randomly clicking around, I can find a page [1] that
> >>  seems to claim the missing symbols are:
> >>  ASN1_STRING_clear_free()
> >>  ENGINE_load_rsax()
> >>  SRP_user_pwd_free()
> >>  SRP_VBASE_get1_by_user()

It's normal that you might see some symbols removed if you compare
something like 1.0.1t against 1.0.2, but it shouldn't when compared
to 1.0.2k.

CRYPTO_memcmp was added in 1.0.1d.

ASN1_STRING_clear_free was added in 1.0.1m and 1.0.2a

In 1.0.1s and 1.0.2g the following were added (for CVE-2016-0798):
SRP_VBASE_get1_by_user;
SRP_user_pwd_free;

ENGINE_load_rsax seems to have been removed because it didn't
compile? That looks like the only symbol that has been removed,
and it probably shouldn't have.


Kurt

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

[openssl-dev] MD5 speed

[Kurt Roeckx]

I had some surprising results of the speed command when testing the
md5 speed on the 1.1.0-stable branch (for both a shared and a static
build):
openssl speed md5 returns:
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes  
16384 bytes
md5 115869.46k   268237.29k   473617.41k   589905.92k   636772.35k  
 639429.29k

openssl speed -evp md5 returns:
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes  
16384 bytes
md5  53991.08k   160454.36k   364985.86k   537559.38k   624238.59k  
 633066.84k

On the other hand, with 1.0.1 and 1.0.2-stable using a static build I get:
md5  38045.25k   123423.76k   310729.30k   505120.09k   620333.74k
md5  43182.80k   135651.38k   331369.48k   518042.97k   622193.32k

Using a shared build I get:
md5  57529.01k   169850.56k   376685.74k   545938.09k   626952.87k
md5  65634.19k   186133.65k   397608.96k   558070.78k   629697.19k

So was surprised me is that speed for small packets seems to be a
lot better in 1.1.0 when not using the EVP interface, but worse when
using it compared to 1.0.2. It this expected behaviour?

Sha1 doesn't seem to have this difference for instance.


Kurt

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

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[Kurt Roeckx]

On Mon, Jan 02, 2017 at 08:50:24AM -0800, James Bottomley wrote:
> On Mon, 2017-01-02 at 17:38 +0100, Kurt Roeckx wrote:
> > On Sat, Dec 31, 2016 at 02:52:43PM -0800, James Bottomley wrote:
> > > This patch adds RSA signing for TPM2 keys.  There's a limitation to 
> > > the way TPM2 does signing: it must recognise the OID for the 
> > > signature.  That fails for the MD5-SHA1 signatures of the TLS/SSL 
> > > certificate verification protocol, so I'm using RSA_Decrypt for 
> > > both signing (encryption) and decryption ... meaning that this only 
> > > works with TPM decryption keys.  It is possible to use the prior 
> > > code, which preserved the distinction of signing and decryption 
> > > keys, but only at the expense of not being able to support SSL or
> > > TLS lower than 1.2
> > 
> > Please submit patches via github.
> 
> Um, that's not really possible given that openssl_tpm_engine is a
> sourceforge project.

I obviously didn't look at it and assumed it was for openssl, not
some other project.


Kurt

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

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

[Kurt Roeckx]

On Sat, Dec 31, 2016 at 02:52:43PM -0800, James Bottomley wrote:
> This patch adds RSA signing for TPM2 keys.  There's a limitation to the
> way TPM2 does signing: it must recognise the OID for the signature. 
>  That fails for the MD5-SHA1 signatures of the TLS/SSL certificate
> verification protocol, so I'm using RSA_Decrypt for both signing
> (encryption) and decryption ... meaning that this only works with TPM
> decryption keys.  It is possible to use the prior code, which preserved
> the distinction of signing and decryption keys, but only at the expense
> of not being able to support SSL or TLS lower than 1.2

Please submit patches via github.


Kurt

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

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

[Kurt Roeckx]

On Thu, Nov 03, 2016 at 03:11:10PM -0500, Benjamin Kaduk wrote:
> To revitalize an old thread (quoted below but summarized here), some
> applications may desire source-code compatibility between the 1.0.2 API
> and the 1.1.0 API.  It seems like the sense of the team is that such
> accessor functions (or macros) should not be committed into the official
> 1.0.2 tree, but that the community could maintain an external
> compatibility shim.  Is that correct?
> 
> Does anyone already have such a compatibility header, or thoughts about
> where it should/could reside?

I put a bunch I've used before on the wiki, which might not be
ideal.


Kurt

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

Re: [openssl-dev] openssl enc changed behaviour between 1.1.0 and earlear

[Kurt Roeckx]

On Fri, Nov 04, 2016 at 09:59:33PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-03 22:12:44 [+0100], Richard Levitte wrote:
> > 
> > That would be quite a job.  The correctness of the key can't be
> > discovered before the last encrypted block, where the decrypted
> > padding will either be correct (because it was the right key) or not
> > (because it was the wrong key).  Take into account a pipe with a 10MB
> > file, I'm sure you see where that takes us.
> > 
> > The solution in that bug report seems sane, even though unfortunate.
> okay. And since the encrypted file has no header there is nothing we
> could hide. And if we add one now then it won't work with older openssl.
> 
> So I will try to put this in the release notes for the Debian package.
> Do you have an idea where this would fit best in the Wiki? A new page
> with one entry does not make sense and it does not look like it belongs
> to

Would it be useful to document this in the manpage?

Are there other places we should document it?


Kurt

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

Re: [openssl-dev] After building 1.0.2h , ldd output shows current version as 1.0.0. How to CHange this , Why is this so ?

[Kurt Roeckx]

On Thu, Nov 03, 2016 at 01:53:56PM +0100, Richard Levitte wrote:
> Hi,
> 
> I'm curious.  Why exactly do you want to change the shared library
> version?

I had to change the soname in Debian (because I dropped all SSLv2  
and SSLv3 symbols) and changed it to 1.0.2.


Kurt

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

Re: [openssl-dev] OpenSSL F2F

[Kurt Roeckx]

On Tue, Oct 04, 2016 at 01:14:36PM +0100, David Woodhouse wrote:
> 
> I would dearly have loved to make it, because I'd like to get some more
> detailed consensus on adding PKCS#11 support.
> 
> In the past we've provisionally agreed on "let's do it after 1.1"... so
> now we should be looking at a slightly more detailed plan. I *can* just
> start throwing patches over the wall, but a high-level consensus on the
> architecture might have been useful. And we're all busy enough that it
> just seems easier to do it face-to-face while we're in the same time
> zone.

That is at least already on the agenda we have. But it's a very
long agenda, not sure if we're going to have time to go over
everything. So there are clearly people interested in doing it,
and we might talk about a plan.


Kurt

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

[openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse

[Kurt Roeckx via RT]

Hi,

Please read:
http://www.metzdowd.com/pipermail/cryptography/2016-September/030151.html

We use the same construct for our OPENSSL_cleanse, but I think we
also have assmebler versions.


Kurt


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

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

Re: [openssl-dev] [openssl.org #4256] CA.pl usage() does not mention -signcert

[Kurt Roeckx via RT]

On Tue, Jan 19, 2016 at 07:25:04PM +, Kaduk, Ben via RT wrote:
> Part of the patch submitted to RT #844 includes a patch to the usage
> message of CA.pl.  Although the functionality itself of CA.pl was
> rewritten for 1.1 (so that #844 was closed), the usage message remains
> incomplete, and Debian continues to apply a local patch to add the usage.
> 
> So, as mentioned in the closing message of #844, this is a new ticket
> for this lingering issue.

It seems this was partially fixed in the 1.0.2 version.  But there
are 2 places it shows the usage, and only 1 of the 2 was updated.


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4256
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] Partially- vs. full- reduced inputs to ecp_nistz256_neg

[Kurt Roeckx]

On Thu, Aug 18, 2016 at 04:24:56PM +0200, Andy Polyakov wrote:
> >> I think you are assuming that ret is in the range [0, 2P), so that if
> >> you subtract P, the result would be in the range [0, P). That is the
> >> case in normal Montgomery multiplication, where the inputs are in the
> >> range [0, P). But, my understanding is that if the inputs are in the
> >> range [P, 2**256), e.g. they are the result of ecp_nistz256_add, then
> >> that assumption doesn't necessarily hold.
> > 
> > Looks like you are right. I mean it indeed appears to be possible for
> > multiplication (and squaring) subroutine to return partially reduced
> > result. But *only* if input was partially reduced. I.e. if input is
> > fully reduced, the output *shall* be too. And if input is not fully
> > reduced, then output *can* be.
> 
> It appears to me that with multiplication, squaring, subtraction,
> negation, halving *preserving* property of being fully reduced (i.e. if
> inputs are fully reduced, then output is too), we only have to watch out
> for mul_by_[23], i.e. ensure that their outputs are fully reduced. This
> would ensure that output will always be fully reduced.

Can you document some of those things?


Kurt

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

Re: [openssl-dev] weird linker warnings on solaris 11

[Kurt Roeckx]

On Sat, Aug 13, 2016 at 08:27:30PM -0700, Erik Forsberg wrote:
> 
> just updated to developer studio 12.5 on Solaris 11.3
> I see lot of warnings when linking OpenSSL 1.1
> looking like these
> 
> link_app.solaris-shared
> LD_LIBRARY_PATH=.: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS 
> -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM 
> -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM 
> -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" 
> -DENGINESDIR="/usr/local/lib/amd64/engines-1.1" -xc99 -m64 -xarch=gen
> eric -xstrconst -DL_ENDIAN -xO5 -xdepend -xbuiltin -D_REENTRANT -DFILIO_H -mt 
> -R /usr/local/lib/amd64 -o apps/openssl apps/app_rand.o apps/apps.o 
> apps/asn1pars.o apps/ca.o apps/ciphers.o apps/cms.o apps/crl.o apps/c
> rl2p7.o apps/dgst.o apps/dhparam.o apps/dsa.o apps/dsaparam.o apps/ec.o 
> apps/ecparam.o apps/enc.o apps/engine.o apps/errstr.o apps/gendsa.o 
> apps/genpkey.o apps/genrsa.o apps/nseq.o apps/ocsp.o apps/openssl.o apps/op
> t.o apps/passwd.o apps/pkcs12.o apps/pkcs7.o apps/pkcs8.o apps/pkey.o 
> apps/pkeyparam.o apps/pkeyutl.o apps/prime.o apps/rand.o apps/rehash.o 
> apps/req.o apps/rsa.o apps/rsautl.o apps/s_cb.o apps/s_client.o apps/s_ser
> ver.o apps/s_socket.o apps/s_time.o apps/sess_id.o apps/smime.o apps/speed.o 
> apps/spkac.o apps/srp.o apps/ts.o apps/verify.o apps/version.o apps/x509.o 
> -L. -lssl -L. -lcrypto -lresolv -lsocket -lnsl -ldl -lpthread
> ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol 
> PBEPARAM_it: relocation bound to a symbol with STV_PROTECTED visibility
> ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol 
> PBE2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility
> ld: warning: relocation warning: R_AMD64_COPY: file ./libcrypto.so: symbol 
> PBKDF2PARAM_it: relocation bound to a symbol with STV_PROTECTED visibility

I'm not sure why those symbols are marked as protected.  The only
thing we seem to be doing with visibilit is this:
./crypto/sparcv9cap.c:__attribute__ ((visibility("hidden")))

And you're not on sparc.

> seems the common thing here is that libcrypto.num does this, not sure what
> the implied effect is, but seems contradictory to me, one line says export as 
> function
> the other one says ! (export as variable instead)
> 
> PBEPARAM_it 13071_1_0   
> EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
> PBEPARAM_it 13071_1_0   
> EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:

As far as I know, this is a windows only thing.  For ELF files
everything is just a symbol.

Anyway, from what I understand, it should be a harmless warning,
those variables should be read only and be in the .data.rel.ro
section.  But for some reason the solaris linker wants to make a
copy of it, so you'll end up with the same (read only) variable
twice.


Kurt

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

Re: [openssl-dev] DRBG entropy

[Kurt Roeckx]

On Thu, Jul 28, 2016 at 09:08:32AM -0700, John Denker wrote:
> 
> That means the chip design is broken in ways that the manufacturer
> does not understand.  The mfgr data indicates it "should" be much
> better than that:
>   http://www.fdk.com/cyber-e/pdf/HM-RAE103.pdf

Reading that, you don't seem to have access to the raw entropy
and the tests you are doing are meaningless.  It really should
always give you a perfect score since it should already be at
least whitened.

I have a feeling that there is at least a misunderstanding of what
that draft standard is saying and that it's isn't being followed.

But if the tests still give you such a low score something seems
to be wrong, which might either be the hardware or software.

Have you tried running NIST's software
(https://github.com/usnistgov/SP800-90B_EntropyAssessment)
yourself?  Can you run it in verbose mode and give the results of
all the tests it ran?


Kurt

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

Re: [openssl-dev] DRBG entropy

[Kurt Roeckx]

On Thu, Jul 28, 2016 at 03:40:38PM -0700, Paul Dale wrote:
> I probably should have mentioned this in my earlier message, but the 
> exponential example is valid for the NSIT SP800-90B non-IID tests too: 
> 5.74889 bits per byte of assessed entropy.  Again about as good a result as 
> the tests will ever produce given the ceiling of six on the output.  There is 
> still zero actual entropy in the data.  The tests have massively over 
> estimated.

Tests are never perfect.  There are various things you can do that
will let the result in giving a higher entropy estimate that what
it really has.  You should really know what your testing and input
something from a real noise source.

Some examples of things that will probably give a very high score:
- Any complex sequence of numbers, including things like pi, e,
  the output of a PRNG, ...
- Add 1 bit of entropy (or even less) into a hash function for
  every byte that you pull out of it.

I think it's important to have a model of your noise source and
check that the noise you get actually matches that model.  This
model should also include the expected entropy you get out of your
noise source.


Kurt

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

Re: [openssl-dev] DRBG entropy

[Kurt Roeckx]

On Wed, Jul 27, 2016 at 05:32:49PM -0700, Paul Dale wrote:
> John's spot on the mark here.  Testing gives a maximum entropy not a minimum. 
>  While a maximum is certainly useful, it isn't what you really need to 
> guarantee your seeding.

Fom what I've read, some of the non-IID tests actually underestimate
the actual entropy.  Which is of course better the overestimating
it, but it's also annoying.

It will also never give a value higher than 6, since one of the
tests only uses 6 bits of the input.

> IID is a statistical term meaning independent and identically distributed 
> which in turn means that each sample doesn't depend on any of the other 
> samples (which is clearly incorrect)

You shouldn't run the IID tests when you clearly know it's not an
IID.  If fact, if you're not sure it's an IID you should use the
non-IID tests.


Kurt

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

Re: [openssl-dev] [openssl.org #4623] OpenSSL master regression in handling malformed Client Key Exchange messages in RSA key exchange

[Kurt Roeckx via RT]

On Fri, Jul 22, 2016 at 10:16:16PM +, David Benjamin via RT wrote:
> On Fri, Jul 22, 2016 at 7:30 PM Hubert Kario via RT  wrote:
> 
> > On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote:
> > > On Fri Jul 22 14:56:11 2016, hka...@redhat.com wrote:
> > > > the issue is present in master 0ed26acce328ec16a3aa and looks to have
> > > > been
> > >
> > > > introduced in commit:
> > > I tried what I thought was a fix for this which is to simply delete the
> > > lines:
> > >
> > > if (decrypt_len < 0)
> > > goto err;
> > >
> > > from ssl/statem/statem_srvr.c
> > >
> > > However your reproducer still indicates errors. I checked the message
> > logs
> > > and it should be now sending as many alerts as the original. The
> > difference
> > > however is that some of them will be sent immediately whereas originally
> > > they would be at the end of the handshake.
> > >
> > > Could your reproducer possibly not be expecting this?
> >
> >
> > sorry, I copied this part:
> >
> > > when the OpenSSL receives a Client Key Exchange message that has the
> > > encrypted
> > > premaster secret comprised only of zero bytes, or equal to server's
> > modulus,
> > > the server just aborts the connection without sending an Alert message
> >
> > from the DHE/ECDHE bug reports
> >
> > the expected behaviour is to continue the connection, but the server should
> > select a premaster secret that was not provided by the client, instead
> > OpenSSL
> > just closes the connection
> >
> 
> I don't believe this test is correct if the encrypted premaster is equal to
> the server's modulus. Such an encrypted premaster is a publicly invalid RSA
> ciphertext. It is perfectly reasonable to reject it early, should unpadded
> RSA_decrypt fail. The timing sensitive portion is the padding check itself,
> which this code should correctly defer failure of, to avoid the padding
> oracle.

I think that the test suite should allow for either of 2
behaviours in case of the public failures:
- It continues with a random premaster secret.
- It generates an error.

>From what I understand it now complains that we don't do the first,
so I think it should get changed to allow both behaviours.

> It is true that it no longer sends an alert on public failures. Probably
> worth fixing. Meh.

I don't care for which behaviour we go, and I guess that if we go
for generating an error we should send an alert.

I don't see the point in wasting time for what most likely seems
to be an attack.

What I don't understand currently is that it also rejected a
ciphertext with all 0's?  Were it too many 0's?


Kurt



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

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

Re: [openssl-dev] [openssl.org #4623] OpenSSL master regression in handling malformed Client Key Exchange messages in RSA key exchange

[Kurt Roeckx]

On Fri, Jul 22, 2016 at 10:16:16PM +, David Benjamin via RT wrote:
> On Fri, Jul 22, 2016 at 7:30 PM Hubert Kario via RT  wrote:
> 
> > On Friday, 22 July 2016 17:14:43 CEST Stephen Henson via RT wrote:
> > > On Fri Jul 22 14:56:11 2016, hka...@redhat.com wrote:
> > > > the issue is present in master 0ed26acce328ec16a3aa and looks to have
> > > > been
> > >
> > > > introduced in commit:
> > > I tried what I thought was a fix for this which is to simply delete the
> > > lines:
> > >
> > > if (decrypt_len < 0)
> > > goto err;
> > >
> > > from ssl/statem/statem_srvr.c
> > >
> > > However your reproducer still indicates errors. I checked the message
> > logs
> > > and it should be now sending as many alerts as the original. The
> > difference
> > > however is that some of them will be sent immediately whereas originally
> > > they would be at the end of the handshake.
> > >
> > > Could your reproducer possibly not be expecting this?
> >
> >
> > sorry, I copied this part:
> >
> > > when the OpenSSL receives a Client Key Exchange message that has the
> > > encrypted
> > > premaster secret comprised only of zero bytes, or equal to server's
> > modulus,
> > > the server just aborts the connection without sending an Alert message
> >
> > from the DHE/ECDHE bug reports
> >
> > the expected behaviour is to continue the connection, but the server should
> > select a premaster secret that was not provided by the client, instead
> > OpenSSL
> > just closes the connection
> >
> 
> I don't believe this test is correct if the encrypted premaster is equal to
> the server's modulus. Such an encrypted premaster is a publicly invalid RSA
> ciphertext. It is perfectly reasonable to reject it early, should unpadded
> RSA_decrypt fail. The timing sensitive portion is the padding check itself,
> which this code should correctly defer failure of, to avoid the padding
> oracle.

I think that the test suite should allow for either of 2
behaviours in case of the public failures:
- It continues with a random premaster secret.
- It generates an error.

>From what I understand it now complains that we don't do the first,
so I think it should get changed to allow both behaviours.

> It is true that it no longer sends an alert on public failures. Probably
> worth fixing. Meh.

I don't care for which behaviour we go, and I guess that if we go
for generating an error we should send an alert.

I don't see the point in wasting time for what most likely seems
to be an attack.

What I don't understand currently is that it also rejected a
ciphertext with all 0's?  Were it too many 0's?


Kurt


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

Re: [openssl-dev] [Pkg-openssl-devel] Bug#829272: Fwd: [openssl.org #4602] Missing accessors

[Kurt Roeckx via RT]

On Mon, Jul 11, 2016 at 02:53:05PM +0200, Mischa Salle wrote:
> Hi Richard, Mattias, others,
> 
> I agree with you that it would be nice if OpenSSL could figure out
> itself whether a cert needs to be treated as a proxy, but currently that
> doesn't work reliably as far as I know.
> The flag is certainly needed in the case of non-RFC3820 proxies, also
> known as legacy proxies. Unfortunately these are still very widely used
> (majority of the proxies actually) and hence our code must be able to
> handle them correctly.

Is there a way to recoginize those non-RFC3820 proxies?



Kurt


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

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

Re: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures

[Kurt Roeckx via RT]

On Mon, Jul 11, 2016 at 05:48:06PM +, Salz, Rich via RT wrote:
> Previously we've changed return-types from void to int.  If there's still 
> time, that seems like the thing to do here.

I've pushed a branched on github that at least does some of the
things.  See github #1330.


Kurt


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

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

Re: [openssl-dev] [openssl.org #4614] pthread_once and malloc failures

[Kurt Roeckx]

On Mon, Jul 11, 2016 at 05:48:06PM +, Salz, Rich via RT wrote:
> Previously we've changed return-types from void to int.  If there's still 
> time, that seems like the thing to do here.

I've pushed a branched on github that at least does some of the
things.  See github #1330.


Kurt

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

Re: [openssl-dev] [openssl.org #4591] asynctest: double free or corruption on hppa

[Kurt Roeckx via RT]

On Tue, Jul 19, 2016 at 02:12:41PM +, Matt Caswell via RT wrote:
> 
> Is this still an issue? And if so are you able to provide a backtrace?

This might be a combination of kernel, glibc and gcc bugs, some of
which might have been fixed.  In any case, I don't think it's an
openssl problem.

See the thread starting at:
https://lists.debian.org/debian-hppa/2016/06/msg00046.html


Kurt


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

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

Re: [openssl-dev] [openssl.org #4591] asynctest: double free or corruption on hppa

[Kurt Roeckx]

On Tue, Jul 19, 2016 at 02:12:41PM +, Matt Caswell via RT wrote:
> 
> Is this still an issue? And if so are you able to provide a backtrace?

This might be a combination of kernel, glibc and gcc bugs, some of
which might have been fixed.  In any case, I don't think it's an
openssl problem.

See the thread starting at:
https://lists.debian.org/debian-hppa/2016/06/msg00046.html


Kurt

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

[openssl-dev] [openssl.org #4614] pthread_once and malloc failures

[Kurt Roeckx via RT]

Hi,

When trying to check what happens if we simulate malloc()
returning NULL I'm running into a problem that I'm not sure how to
deal with.

We have CRYPTO_THREAD_run_once(), which takes an init() function
that returns void, so it can't return failures.  At least the
pthread_once() function also has it as void.

But if those functions call malloc() and that returns NULL, we now
don't catch that error, and later just try to use a NULL pointer.

Anybody a good idea how to solve this?


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4614
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] MGF1-OAEP with SHA2

[Kurt Roeckx]

On Sat, Jul 09, 2016 at 08:42:39PM +0200, c.hol...@ades.at wrote:
> Hi!
> 
> I tried with Openssl 1.0.1t from current Debian testing.
> But I get
> undefined symbol: EVP_PKEY_CTX_set_rsa_oaep_md

1.0.1t is in stable, not testing.

1.0.1 doesn't have that function, 1.0.2 does.


Kurt

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

Re: [openssl-dev] [PATCH] Add support for minimum and maximum protocol version supported by a cipher

[Kurt Roeckx]

On Fri, Jul 08, 2016 at 05:43:21PM +0100, David Woodhouse wrote:
> 
> This broke the OpenConnect VPN client, which now fails thus:
> 
> DTLS handshake failed: 1
> 67609664:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers 
> available:ssl/statem/statem_clnt.c:927:
> 
> I tried the naïvely obvious step of changing all instances of
> DTLS1_VERSION as the minimum, to DTLS1_BAD_VER. That didn't help.

Can you describe how DTLS1_BAD_VER is supposed to work?  Is this
version send over the wire?  Is it negotiated?

We have no test suite coverage doing anything with DTLS1_BAD_VER
and I think the OpenConnect VPN is the only user of it.


Kurt

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

Re: [openssl-dev] [openssl.org #4602] Missing accessors

[Kurt Roeckx via RT]

On Thu, Jul 07, 2016 at 09:40:24PM +, Richard Levitte via RT wrote:
> On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> > /* Add to include/openssl/x509v3.h */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
> >
> >
> > /* Add to crypto/x509v3/v3_purp.c */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags |= ex_flags;
> > }
> >
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags &= ~ex_flags;
> > }
> 
> This gives me the heebie jeebies. ex_flags is used a lot internally, and I
> can't begin to imagine the consequences of letting external code manipulate
> this. I understand that in some cases, it seems easy and quick, but...
> 
> So, if someone else wants to have a go at this and can make something 
> sensible,
> please be my guest. Me, I'm backing off from this particular idea.

Mattias,

Can you explain why this is needed, what the code is trying to do?


Kurt


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

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

Re: [openssl-dev] [openssl.org #4602] Missing accessors

[Kurt Roeckx]

On Thu, Jul 07, 2016 at 09:40:24PM +, Richard Levitte via RT wrote:
> On Sat Jul 02 10:59:38 2016, k...@roeckx.be wrote:
> > /* Add to include/openssl/x509v3.h */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
> >
> >
> > /* Add to crypto/x509v3/v3_purp.c */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags |= ex_flags;
> > }
> >
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags &= ~ex_flags;
> > }
> 
> This gives me the heebie jeebies. ex_flags is used a lot internally, and I
> can't begin to imagine the consequences of letting external code manipulate
> this. I understand that in some cases, it seems easy and quick, but...
> 
> So, if someone else wants to have a go at this and can make something 
> sensible,
> please be my guest. Me, I'm backing off from this particular idea.

Mattias,

Can you explain why this is needed, what the code is trying to do?


Kurt

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

[openssl-dev] [openssl.org #4605] OCSP accessors

[Kurt Roeckx via RT]

In https://bugs.debian.org/828254, for the software "bro"

I got a request for accessors to:
- For OCSP_RESPID *rid:
  - rid->type
  - rid->value.byKey->length
  - rid->value.byKey->data


- For OCSP_BASICRESP *basic:
  - basic->certs
  - basic->tbsResponseData->responderId


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4605
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 #4603] HMAC_Init_ex incompatible change (possibly doc bug)

[Kurt Roeckx via RT]

Hi,

I received the following bug:
https://bugs.debian.org/829108

the HMAC manpage states:

   HMAC_Init_ex() initializes or reuses a HMAC_CTX structure to use the
   function evp_md and key key. Either can be NULL, in which case the
   existing one will be reused.

However, the current code does not allow the key to be zero when evp_md is
non-zero in all cases:

/* If we are changing MD then we must have a key */
if (md != NULL && md != ctx->md && (key == NULL || len < 0))
return 0;

That means contrary to the documentation, the existing salt isn't reused
when the md argument is non-zero (and changes).

The issue is corrobated by the fact that HMAC_init_ex only relatively
recently gained a status return, so older programs won't check the return
value and will continue on, getting wrong results.

This particular line was introduced with this change:

https://github.com/openssl/openssl/commit/4b464e7b46682f568a5df550426b0cf4b22e2485

Although I don't know whether this just reworks the logic or introduces
the problem in the first place.

One program that might to be affected is GVPE - I opened a bug report
about it no longer working, although I can't find it at the moment. It
is possible (but not certain) that this is the reason for it no longer
working. Even though GVPE has had return code checking, due to a glitch
it wasn't enabled before openssl 1.1.0, so would not trigger with 1.0.x
builds.

So, either:

a) this is an incompatible and unintended change. in this case, there is 
potential
   for programs silently failing to compute correct hmacs now.
b) this is an incompatible but intended change, in which case this is a 
documentation
   bug.
c) this is not an incompatible recent change, in which case the logic always
   was like this but was reworked. in this case it is a documentation bug as 
well.
d) it is intended behaviour and the previous behaviour
   wasn't correct (e.g. it didn't reuse the key, but did something else).
   also a documentation bug in this case.

If this is an unintended behaviour change, maybe the large scale API
breakage in 1.1.0 would be a good moment to also rename HMAC_init_ex, so
programs have a chance to adaot.



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4603
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 #4602] Missing accessors

[Kurt Roeckx via RT]

Hi,

I received the following bug in debian:
https://bugs.debian.org/829272


I got a lot of bugs filed about packages FTBFS with openssl 1.1.0.
I started to look at some of them, and many of them are due too
structures having been made opaque. In many cases accessors already
exists, but definitely not for all.

Here is a list of accessors I so far have identified as missing. The
filenames given in the "Add to ..." comments below are suggestions
based on where similar functions are defined and implemented.


/* Add to include/openssl/x509_vfy.h : */

typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer, X509_STORE_CTX *ctx, 
X509 *x);
typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx, X509 *x, X509 
*issuer);

void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
   X509_STORE_CTX_get_issuer get_issuer);
X509_STORE_CTX_get_issuer X509_STORE_CTX_get_get_issuer(X509_STORE_CTX *ctx);
void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
 X509_STORE_CTX_check_issued check_issued);
X509_STORE_CTX_check_issued X509_STORE_CTX_get_check_issued(X509_STORE_CTX 
*ctx);


/* Add to crypto/x509/x509_vfy.c : */

void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
   X509_STORE_CTX_get_issuer get_issuer)
{
ctx->get_issuer = get_issuer;
}

X509_STORE_CTX_get_issuer X509_STORE_CTX_get_get_issuer(X509_STORE_CTX *ctx)
{
return ctx->get_issuer;
}

void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
 X509_STORE_CTX_check_issued check_issued)
{
ctx->check_issued = check_issued;
}

X509_STORE_CTX_check_issued X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx)
{
return ctx->check_issued;
}


/* Add to include/openssl/x509v3.h */

void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);


/* Add to crypto/x509v3/v3_purp.c */

void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
{
x->ex_flags |= ex_flags;
}

void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
{
x->ex_flags &= ~ex_flags;
}


Regarding the new locking. Do I understand it correctly that e.g.

  CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);

should be replaced by something like

  CRYPTO_THREAD_write_lock(X509_STORE_get_lock(ctx));

But then the accessors to get hold of the lock objects in the opaque
structs are missing. E.g.

/* Add to some header file */

CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *ctx);

/* Add to some implementation file */

/* Add to crypto/x509/x509_lu.c */

CRYPTO_RWLOCK *X509_STORE_get_lock(X509_STORE *v)
{
return v->lock;
}

Repeat for other relevant classes with locks.

Mattias


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

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

Re: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible

[Kurt Roeckx via RT]

On Mon, Jun 27, 2016 at 08:50:43PM +, Thomas Waldmann via RT wrote:
> I didn't ask where to get the missing code from, I asked whether you
> maybe want to make life simpler for people by adding this to 1.0.x
> rather than having a thousand software developers copy and pasting it
> into their projects.

I think this will not actually make life easier.  People using a
1.0.x version are not always using the latest 1.0.x version.

Or are you happy to say that they either need a certain version of
the 1.0.x branch or the 1.1 branch?  Then why not just say they
need the 1.1 branch?

I know it's annoying, but I don't see this solving anything, nor
do I see a good way to avoid it.

But adding things to master to make it easier to upgrade are
clearly things we do want to do.


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589
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 #4591] asynctest: double free or corruption on hppa

[Kurt Roeckx via RT]

Hi,

My last upload of openssl to experimental show this on hppa:
*** Error in `./asynctest': double free or corruption (out): 0x007307d8 ***
../util/shlib_wrap.sh ./asynctest => 134

#   Failed test 'running asynctest'
#   at ../test/testlib/OpenSSL/Test/Simple.pm line 77.
# Looks like you failed 1 test of 1.

A full log can be seen at:
https://buildd.debian.org/status/fetch.php?pkg=openssl=hppa=1.1.0~pre5-4=1466951184

This is with commit c32bdbf171ce6650ef045ec47b5abe0de7c264db

The previous upload was succesful, the log of that is:
https://buildd.debian.org/status/fetch.php?pkg=openssl=hppa=1.1.0~pre5-3=1465602753

That was with commit 5000a6d1215ea7d6ed6179d0bcd44263f6e3c26b


I'm not sure if this is reproducible or not, I can try a new build
if needed.


Kurt


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

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

Re: [openssl-dev] [openssl.org #4551] TCP re-transmissions are seen for every transfer with the Openssl version OpenSSL 1.0.2g

[Kurt Roeckx]

On Tue, May 31, 2016 at 04:21:13PM +, ajai.mat...@wipro.com via RT wrote:
> Hi,
> We are facing  an issue from the OpenSSL 1.0.2g ,after upgraded from OpenSSL 
> 1.0.0s . [Linux version 2.6.24]
> When a https file transfer started with a Windows 7 application, we notice 
> many TCP re-transmission request from Linux and finally the file transfer 
> getting failed.
> we are yet to get the OpenSSL logs for this issue. But would like to ask if 
> any similar issues were reported
> And the issue resolved by reverting to the old version OpenSSL 1.0.0s .

My guess is that there is a firewall that has a problem with TLS
1.2 or the size of the packet being sent.


Kurt

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

Re: [openssl-dev] [openssl.org #4550] hppa assembler problem

[Kurt Roeckx via RT]

On Mon, May 30, 2016 at 08:37:56PM +, Andy Polyakov via RT wrote:
> > I'm getting assembler errors on hppa that look like:
> > crypto/aes/aes-parisc.s: Assembler messages:
> > crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
> > crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt'
> > crypto/aes/aes-parisc.s:11: Error: Missing function name for .PROC
> > crypto/aes/aes-parisc.s:12: Error: Missing function name for .PROC
> > 
> > I'm guessing I'm doing something wrong, but hppa never had
> > assembler enabled in Debian before.
> > 
> > The configuration I use is:
> > my $debian_cflags = `dpkg-buildflags --get CFLAGS` .  `dpkg-buildflags 
> > --get CPPFLAGS` . "-Wa,--noexecstack -Wall";
> > $debian_cflags =~ s/\n/ /g;
> > my $debian_ldflags = `dpkg-buildflags --get LDFLAGS`;
> > $debian_ldflags =~ s/\n/ /g;
> > 
> > 
> > %targets = (
> >"debian" => {
> >cflags => $debian_cflags,
> >lflags => add($debian_ldflags, "-pthread"),
> >},
> > [...]
> >"debian-hppa" => {
> >inherit_from => [ "linux-generic32", "debian", 
> > asm("parisc11_asm") ],
> >},
> > 
> > Is that assembler supposed to work?  Is it the right assembler that
> > I'm using?
> 
> PA-RISC assembly modules were tested *only* on HP-UX. While it works
> with GNU assembler, it's still one for HP-UX. Special thing about it is
> that run-time format is not ELF, and supposedly that's what those
> failing directives are about. I mean they are meant to make sense to
> specifically HP-UX assemblers. I suppose it means that Linux support
> would require extra work, adapting all modules to recognize additional
> "perlasm flavour". It's not unlike that it's not about simple
> decorations, ABI-specific adjustments might be required too... I don't
> think I've actually seen PA-RISC ELF calling convention...

Then I suggest you forget about it.  hppa isn't officially in
Debian anymore, I'll just drop the assembler support.


Kurt


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

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

Re: [openssl-dev] [openssl.org #4550] hppa assembler problem

[Kurt Roeckx]

On Mon, May 30, 2016 at 08:37:56PM +, Andy Polyakov via RT wrote:
> > I'm getting assembler errors on hppa that look like:
> > crypto/aes/aes-parisc.s: Assembler messages:
> > crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
> > crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt'
> > crypto/aes/aes-parisc.s:11: Error: Missing function name for .PROC
> > crypto/aes/aes-parisc.s:12: Error: Missing function name for .PROC
> > 
> > I'm guessing I'm doing something wrong, but hppa never had
> > assembler enabled in Debian before.
> > 
> > The configuration I use is:
> > my $debian_cflags = `dpkg-buildflags --get CFLAGS` .  `dpkg-buildflags 
> > --get CPPFLAGS` . "-Wa,--noexecstack -Wall";
> > $debian_cflags =~ s/\n/ /g;
> > my $debian_ldflags = `dpkg-buildflags --get LDFLAGS`;
> > $debian_ldflags =~ s/\n/ /g;
> > 
> > 
> > %targets = (
> >"debian" => {
> >cflags => $debian_cflags,
> >lflags => add($debian_ldflags, "-pthread"),
> >},
> > [...]
> >"debian-hppa" => {
> >inherit_from => [ "linux-generic32", "debian", 
> > asm("parisc11_asm") ],
> >},
> > 
> > Is that assembler supposed to work?  Is it the right assembler that
> > I'm using?
> 
> PA-RISC assembly modules were tested *only* on HP-UX. While it works
> with GNU assembler, it's still one for HP-UX. Special thing about it is
> that run-time format is not ELF, and supposedly that's what those
> failing directives are about. I mean they are meant to make sense to
> specifically HP-UX assemblers. I suppose it means that Linux support
> would require extra work, adapting all modules to recognize additional
> "perlasm flavour". It's not unlike that it's not about simple
> decorations, ABI-specific adjustments might be required too... I don't
> think I've actually seen PA-RISC ELF calling convention...

Then I suggest you forget about it.  hppa isn't officially in
Debian anymore, I'll just drop the assembler support.


Kurt

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

[openssl-dev] [openssl.org #4550] hppa assembler problem

[Kurt Roeckx via RT]

Hi,

I'm getting assembler errors on hppa that look like:
crypto/aes/aes-parisc.s: Assembler messages:
crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt'
crypto/aes/aes-parisc.s:11: Error: Missing function name for .PROC
crypto/aes/aes-parisc.s:12: Error: Missing function name for .PROC

I'm guessing I'm doing something wrong, but hppa never had
assembler enabled in Debian before.

The configuration I use is:
my $debian_cflags = `dpkg-buildflags --get CFLAGS` .  `dpkg-buildflags --get 
CPPFLAGS` . "-Wa,--noexecstack -Wall";
$debian_cflags =~ s/\n/ /g;
my $debian_ldflags = `dpkg-buildflags --get LDFLAGS`;
$debian_ldflags =~ s/\n/ /g;


%targets = (
   "debian" => {
   cflags => $debian_cflags,
   lflags => add($debian_ldflags, "-pthread"),
   },
[...]
   "debian-hppa" => {
   inherit_from => [ "linux-generic32", "debian", 
asm("parisc11_asm") ],
   },

Is that assembler supposed to work?  Is it the right assembler that
I'm using?

A full log can bee seen at:
buildd.debian.org/status/fetch.php?pkg=openssl=hppa=1.1.0~pre5-1=1464595947


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4550
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 #4549] powerpc test problem: missing symbols

[Kurt Roeckx via RT]

Hi,

I'm seeing this on powerpc:
../test/recipes/01-test_ordinals.t . ok

#   Failed test 'check that there are no missing symbols in libcrypto.so'
#   at ../test/recipes/01-test_symbol_presence.t line 112.
# Looks like you failed 1 test of 4.
../test/recipes/01-test_symbol_presence.t .. 
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/4 subtests 

I a full log is at:
https://buildd.debian.org/status/fetch.php?pkg=openssl=powerpc=1.1.0~pre5-1=1464595346

If I find time I'll try to look in the the real cause.


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4549
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 #4548] s390x build problem

[Kurt Roeckx via RT]

Hi,

I'm getting:
crypto/chacha/chacha-s390x.S: Assembler messages:
crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije'


A full build log is available on:
https://buildd.debian.org/status/fetch.php?pkg=openssl=s390x=1.1.0~pre5-1=1464594754


Kurt


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

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

Re: [openssl-dev] [openssl.org #4524] [BUG] TLS 1.2 handshake hangs for TLS 1.0 only hosts

[Kurt Roeckx via RT]

On Sat, Apr 30, 2016 at 08:59:46PM +, Matt Caswell via RT wrote:
> 
> This is not a bug in OpenSSL. The problem here is that the server is behaving
> incorrectly when receiving large ClientHello messages. The ClientHello is the
> first message that is sent from the client to the server. If a large
> ClientHello is received then the server just hangs. The reason that this
> impacts TLSv1.2 and not other versions is that there are more ciphersuites
> available for that protocol version and therefore the ClientHello is bigger.

This is a know problem in old versions of F5 BIG-IP product.

See:
https://support.f5.com/kb/en-us/solutions/public/14000/700/sol14758.html


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4524
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] Getting raw ASN1 data from X509 certificate

[Kurt Roeckx]

Hi,

I'm working on a tool that checks various things related to X509
certificates.  I want to check that the encoding is actually
correct DER.  With things like ASN1_TIME is seems easy to get to
the raw data, it just seems to contain it.  But when I try it with
an ASN1_INTEGER it doesn't seem to contain all the data.  For
instance, if it's a number that starts with a byte >= 0x80, the
encoding should have a 0x00 in front of it.  But in the
ASN1_INTEGER it already seems to have removed that 0x00.

Is there a way I can get to raw encoding?  Or do I need to write
my own parser (or use an other existing one) to be able to get to
it?


Kurt

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

Re: [openssl-dev] [openssl.org #4392] [PATCH] Resolve DTLS cookie and version before session resumption.

[Kurt Roeckx via RT]

On Mon, Mar 07, 2016 at 10:03:20PM +, David Benjamin via RT wrote:
> Session resumption involves a version check, so version negotiation must
> happen first. Currently, the DTLS implementation cannot do session
> resumption in DTLS 1.0 because the ssl_version check always checks against
> 1.2.
> 
> Switching the order also removes the need to fixup ssl_version in DTLS
> version negotiation.

This has been fixed in the master branch.  The 1.0.x branches
look like they're affected too, so I'll leave this open.


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4392
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] OS X 10.8, x86_64: 01-test_abort.t... sh: line 1: 71522 Abort trap: 6

[Kurt Roeckx]

On Sat, Mar 19, 2016 at 07:41:28PM -0400, Jeffrey Walton wrote:
> On Sat, Mar 19, 2016 at 7:31 PM, Richard Levitte  wrote:
> > In message  on Sat, 19 
> > Mar 2016 23:08:17 +, "noloa...@gmail.com via RT"  
> > said:
> >
> > rt> On Sat, Mar 19, 2016 at 6:44 AM, Richard Levitte via RT 
> >  wrote:
> > rt> > I think that's a discussion that deserves its own new thread on 
> > openssl-dev.
> > rt> >
> > rt> > A RT ticket is *not* the right place for a philosophical discussion. 
> > Closing
> > rt> > this. Please don't respond on this message, create a new thread 
> > instead.
> > rt>
> > rt> Thanks Richard.
> > rt>
> > rt> For me, its not open for debate. Its a point of data egress, so it
> > rt> must not occur. What others do is there business.
> > rt>
> > rt> I'll configure without the "data loss" feature, and others can do what
> > rt> they want :)
> >
> > Well, how about you go after the calls then.  Complaining about the
> > existence of OPENSSL_die or OPENSSL_assert is about as fruitful as
> > complaining about the existence of abort() or assert()...  That's how
> > this "philosophical discussion" started out that that's your
> > complaint, isn't it?  If not, I'd like you to clarify.
> 
> Allowing a library to make policy decisions for the application is a
> philosophical debate.

At least a few of us don't want asserts in the library in the
normal version and think that it should be up to the
application to decide what to do.

I think we need something that for a debug build it triggers an
abort (or whatever), but that for normal builds returns an error
instead.

> Allowing data to egress from the security boundary violates security
> policies, and its not philosophical.

I hope that core files aren't just send to a third party without
at least asking the user.  But I understand that at least Windows
is doing this by default now without being able to turn it off.

If the assert we added actually sees that things are in such a bad
state that we'll likely crash soon anyway, it doesn't change much.

And I guess the question is if the error is something we can
recover from or not.


Kurt

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

Re: [openssl-dev] [openssl.org #4445] Configure does not honor enable-afalgeng

[Kurt Roeckx via RT]

On Fri, Mar 18, 2016 at 01:18:04PM +, Matt Caswell wrote:
> 
> 
> On 18/03/16 12:52, noloa...@gmail.com via RT wrote:
> > I've configured with:
> > 
> > ./config enable-afalgeng
> > 
> > When I run the self tests, I see:
> > 
> >   ../test/recipes/30-test_afalg.t ... skipped: test_afalg not
> > supported for this build
> 
> You should not need to use enable-afalgeng at all. It is enabled by
> default unless for some reason it is not supported by your system.
> Reasons that it might not be supported:
> 
> - You are not running Linux
> - You are not building "shared" or have otherwise disabled dynamic-engines
> - uname reports a kernel version less than 4.1.0
> - Your linux headers are less than 4.1.0

Please note that the kernel something is build on might not be the
same as it's going to run on, so checking the current running
kernel version doesn't make sense for compiling it.  Is there some
runtime detection of support in the kernel?


Kurt


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

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

Re: [openssl-dev] [openssl.org #4424] openssl 1.0.2.g and Indy-Procjet

[Kurt Roeckx via RT]

On Sun, Mar 13, 2016 at 02:09:34PM +, Olaf Kirfel via RT wrote:
> Hallo
> I am using Embarcadero/Borland C++-Builder for my personal interest and 
> I have the problem, that after the update to openssl 1.0.2g the 
> indy-components are not working.
> They are delivering an error message like "ssl-security library could 
> not be loaded" (I tried to translate it, sorry).
> 
> I read, that the reason might be, that you turn off the support for SSL2.
> I guess, the problem seems to be, that you removed some functions from 
> the library, so older software seems not to be able to load the dll, 
> even though one is trying to use SSL3.
> 
> Is there a way that you just add the old function-bodies and let them 
> return an error-code?
> By that one would be able to use the old indy-components with SSL3.

The SSLv2 functions were removed, but they should come back in the
next version.  You could use a current git snapshot for this.

Also, you should stop using SSLv3.  You want to use TLS 1.2.


Kurt


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

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

Re: [openssl-dev] [openssl.org #4422] OS X 32-bit PowerPC: blake2b.c:27: warning: integer constant is too large for 'unsigned long' type

[Kurt Roeckx via RT]

On Sun, Mar 13, 2016 at 11:27:23AM +, noloa...@gmail.com via RT wrote:
> >> static const uint64_t blake2b_IV[8] =
> >> {
> >> 0x6a09e667f3bcc908U, 0xbb67ae8584caa73bU,
> >> 0x3c6ef372fe94f82bU, 0xa54ff53a5f1d36f1U,
> >> 0x510e527fade682d1U, 0x9b05688c2b3e6c1fU,
> >> 0x1f83d9abfb41bd6bU, 0x5be0cd19137e2179U
> >> };
> >>
> >> I've run into this before, but in C++. I think you need ULL, and not
> >> U. But I don't know if it will adversely affect other compilers and
> >> platforms.
> >
> > So I guess where in the situation where "U" is not supported by
> > some compilers and "ULL" not by others, where both should be
> > valid.
> 
> I'm guessing GCC 4.0.1 is using an intermediate 32-bit value when it
> encounters the U. Its triggering a warning, but its not causing a
> failure of the self test (presuming there's good code coverage).
> 
> Also see http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html.

If you look at:
http://en.cppreference.com/w/c/language/integer_constant

You'll see that "U" can be "unsigned int", "unsigned long int"
or "unsigned long long int".  "ULL" just forces it to an unsigned
long long.

It might be that in C89/C90 mode it gives a warning about it and
that in C99 it should work, don't know enough about this.

But since this compiles and passes the test suite for you I think
I'll ignore it.


Kurt


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

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

Re: [openssl-dev] [openssl.org #4422] OS X 32-bit PowerPC: blake2b.c:27: warning: integer constant is too large for 'unsigned long' type

[Kurt Roeckx via RT]

On Sun, Mar 13, 2016 at 07:15:52AM -0400, Jeffrey Walton wrote:
> On Sun, Mar 13, 2016 at 6:57 AM, Kurt Roeckx via RT <r...@openssl.org> wrote:
> > On Sun, Mar 13, 2016 at 10:30:54AM +, noloa...@gmail.com via RT wrote:
> >> crypto/blake2/blake2b.c:27: warning: integer constant is too large for
> >> 'unsigned long' type
> >
> > That's a uint64_t.  Why do you have an "unsigned long" as 64 bit
> > uint64_t?
> >
> 
> Hmmm... Not sure.
> 
> Looking at the declaration:
> 
> static const uint64_t blake2b_IV[8] =
> {
> 0x6a09e667f3bcc908U, 0xbb67ae8584caa73bU,
> 0x3c6ef372fe94f82bU, 0xa54ff53a5f1d36f1U,
> 0x510e527fade682d1U, 0x9b05688c2b3e6c1fU,
> 0x1f83d9abfb41bd6bU, 0x5be0cd19137e2179U
> };
> 
> I've run into this before, but in C++. I think you need ULL, and not
> U. But I don't know if it will adversely affect other compilers and
> platforms.

So I guess where in the situation where "U" is not supported by
some compilers and "ULL" not by others, where both should be
valid.


Kurt


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

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

Re: [openssl-dev] [openssl.org #4422] OS X 32-bit PowerPC: blake2b.c:27: warning: integer constant is too large for 'unsigned long' type

[Kurt Roeckx]

On Sun, Mar 13, 2016 at 07:15:52AM -0400, Jeffrey Walton wrote:
> On Sun, Mar 13, 2016 at 6:57 AM, Kurt Roeckx via RT <r...@openssl.org> wrote:
> > On Sun, Mar 13, 2016 at 10:30:54AM +, noloa...@gmail.com via RT wrote:
> >> crypto/blake2/blake2b.c:27: warning: integer constant is too large for
> >> 'unsigned long' type
> >
> > That's a uint64_t.  Why do you have an "unsigned long" as 64 bit
> > uint64_t?
> >
> 
> Hmmm... Not sure.
> 
> Looking at the declaration:
> 
> static const uint64_t blake2b_IV[8] =
> {
> 0x6a09e667f3bcc908U, 0xbb67ae8584caa73bU,
> 0x3c6ef372fe94f82bU, 0xa54ff53a5f1d36f1U,
> 0x510e527fade682d1U, 0x9b05688c2b3e6c1fU,
> 0x1f83d9abfb41bd6bU, 0x5be0cd19137e2179U
> };
> 
> I've run into this before, but in C++. I think you need ULL, and not
> U. But I don't know if it will adversely affect other compilers and
> platforms.

So I guess where in the situation where "U" is not supported by
some compilers and "ULL" not by others, where both should be
valid.


Kurt

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

Re: [openssl-dev] [openssl.org #4422] OS X 32-bit PowerPC: blake2b.c:27: warning: integer constant is too large for 'unsigned long' type

[Kurt Roeckx via RT]

On Sun, Mar 13, 2016 at 10:30:54AM +, noloa...@gmail.com via RT wrote:
> crypto/blake2/blake2b.c:27: warning: integer constant is too large for
> 'unsigned long' type

That's a uint64_t.  Why do you have an "unsigned long" as 64 bit
uint64_t?


Kurt


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

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

Re: [openssl-dev] [openssl.org #4411] VIA C7-D processor: Hang in 30-test_afalg.t

[Kurt Roeckx via RT]

On Sun, Mar 13, 2016 at 06:29:14AM +, noloa...@gmail.com via RT wrote:
> >> It looks like the hang is still present as of 603358d.
> >>
> >> When the following runs:
> >>
> >> ../test/recipes/30-test_afalg.t
> >>
> >> What is actually running? How can I get it under a debugger?
> >
> >
> > $ ./config -d
> > $ make
> > $ make test/afalgtest
> > $ cd test
> > $ OPENSSL_ENGINES=../engines/afalg gdb ./afalgtest
> 
> OK, I've got two hung processes from two attempts to debug this:
> 
> $ ps -A | grep afalgtest
>  1030 pts/000:00:00 afalgtest
>  1196 pts/000:00:00 afalgtest
> 
> Both appear to be hanging in syscall 248:

So that appears to be:
./engines/afalg/e_afalg.c:return syscall(__NR_io_submit, ctx, n, iocb);


Kurt


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

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

Re: [openssl-dev] [openssl.org #4355] OpenSSL 1.0.2 branch fails to build with MSVC

[Kurt Roeckx via RT]

On Sun, Feb 28, 2016 at 02:33:34PM +, Simon Richter via RT wrote:
> Hi,
> 
> I just got this from our Jenkins instance that follows OpenSSL 1.0.2:

That should have been fixed some time ago, but it seems your mail
only got here today.


Kurt


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

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

Re: [openssl-dev] [openssl.org #4369] OS X 10.5, 32-bit PPC, and "passing argument 2 of 'cmov' discards qualifiers from pointer target type"

[Kurt Roeckx via RT]

On Wed, Mar 02, 2016 at 04:16:37PM +, noloa...@gmail.com via RT wrote:
> curve25519.c: In function 'table_select':
> curve25519.c:3323: warning: passing argument 2 of 'cmov' discards

That should be fixed shortly.


Kurt


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

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

Re: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity

[Kurt Roeckx]

On Sun, Feb 28, 2016 at 12:17:41PM -0500, Jeffrey Walton wrote:
> On Sun, Feb 28, 2016 at 12:18 AM, Viktor Dukhovni
>  wrote:
> >
> >> On Feb 27, 2016, at 7:42 PM, Jeffrey Walton  wrote:
> >>
> >> Please ensure this is documented somewhere. I'm having trouble finding
> >> information on the new rules.
> >>
> >> There's 15 or 20 years of using capitol and lower case identifiers to
> >> denote public and private APIs with OpenSSL. For example, see
> >> https://marc.info/?l=openssl-users=102683340223621 .
> >>
> >> I'm happy to tell folks that no longer applies, but we need to know
> >> what the new rules are is and when the cut-over occured.
> >
> > There are no new *rules*, just new goals I'm promoting in this thread.
> > If it is not documented it is not a fully implemented public interface.
> > The documentation is part of what it takes to be a first-class
> > public interface.  New code must be documented, and patches to
> > existing code should bring the documentation up to date.  In good
> > part because it is hard to know whether a patch is correct when
> > updating undocumented code, and the exercise of documenting it makes
> > one think harder about the requisite semantics.
> >
> > The upper-case lower-case thing is a legacy crutch, that is likely
> > to continue to be adhered to for some time, but increasingly it is
> > the documentation that must delineate between public and internal
> > interfaces.
> 
> Thanks Viktor.
> 
> Here's the practical problem I am trying to solve. Its a policy and
> procedure problem.
> 
> Suppose an organization has a rule that says, "no private APIs shall
> be used". How do I tell an organization to differentiate between
> public and private APIs to ensure compliance with the policy? What do
> I tell QA to verify compliance with the policy?
> 
> In the past, we knew from the upper-case lower-case thing. I'm
> guessing that held until OpenSSL 1.0.2. I'm also guessing that's is
> going to change at 1.1.x.
> 
> What do we use now? What are the actionable items or prescriptive
> items we can pivot on?

Those that are in the public headers files are the ones that are
(probably) meant to be public.  They also end up in the .num files
and are now the only exported functions on platforms that support
that.

But before you use those functions that are meant to be public
check that they are actually documented.  If they're not
documented, try to get them documented before you use them.  If
you already use them but they're not documented, try to get them
documented or avoid using them.


Kurt

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

Re: [openssl-dev] openssl-1.0.2-stable-SNAP-20160228

[Kurt Roeckx]

On Sun, Feb 28, 2016 at 06:20:42AM -0700, The Doctor wrote:
> This cropped up this morning in

That was fixed an hour ago.


Kurt

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

Re: [openssl-dev] [openssl.org #4352] Failed test 'Duplicate ClientHello extension' when testing under Clang undefined behavior sanitizer

[Kurt Roeckx via RT]

On Sat, Feb 27, 2016 at 01:58:26AM +, noloa...@gmail.com via RT wrote:
> Platform is Linux, x86_64. The failure occurs under Clang with the
> sanitizer. GCC is fine.
> 
> I'm guessing the error output from the Undefined Behavior sanitizer is
> causing the test to be interpreted as a fail.

It has 2 of them:
apps/s_cb.c:1077:41: runtime error: index 18446744073709551614 out of bounds 
for type 'const unsigned char [3]'


I've already fixed this, it's been reviewed, it's just not in
master yet.

Then there is also:
crypto/include/internal/md32_common.h:380:5: runtime error: store to misaligned 
address 0x0210b5fd for type 'unsigned int', which requires 4 byte alignment

That seems to go away when using -DPEDANTIC


Kurt


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4352
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] Failed TLSv1.2 handshake with error 67702888--bad signature

[Kurt Roeckx]

I can only find 1 place in the server that generates an
SSL_R_BAD_SIGNATURE and that's in ssl3_get_cert_verify, in the
case of signature algorithms are used, which is new in TLS 1.2.

I don't see anything obviously wrong, and as far as I know the
test suite also tests client authentication.


Kurt


On Fri, Feb 26, 2016 at 05:34:16PM +, Nounou Dadoun wrote:
> Trying to upgrade from TLSv1 to TLSv1.1 and 1.2 has been more problematic 
> than I might have suspected.
> I have a TLS server using openssl 1.0.2d  doing mutual authentication and a 
> one line change from TLSv1 (only) to TLSv1.2 breaks the connection where in 
> the latter the server rejects the client certificate with "error 
> 67702888--bad signature" (and the former happily accepts it).  
> 
> Given that description (and the fact that it's literally a one-line change), 
> it's hard to believe that I'm doing something wrong.
> 
> Can anyone tell me why TLSv1 accepts it and TLSv1.2 doesn't?  Packet capture 
> attached and more details below, certificate is in the packet capture but I 
> can provide it separately if it will help, thanks ... N
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> 
> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Nounou Dadoun
> Sent: Thursday, February 25, 2016 5:44 PM
> To: openssl-us...@openssl.org
> Subject: Re: [openssl-users] Failed TLSv1.2 handshake with error 
> 67702888--bad signature
> 
> Curiouser and curiouser - I have attached two minimal packet captures in 
> which the only difference in the server build was a change in one line (using 
> boost with openssl):
>: m_context(pIoService->GetNative(), 
> boost::asio::ssl::context::tlsv1) 
> to
>: m_context(pIoService->GetNative(), 
> boost::asio::ssl::context::sslv23)
> 
> They both disable sslv2 and sslv3.
> The former resulted in a handshake that completed, the latter failed with the 
> aforementioned "67702888--bad signature" logged error.  The respective packet 
> captures are attached.
> 
> This one has me pretty puzzled, any idea why tls1 succeeds and tls1.2 fails?
> 
> Is tls1.2 more strict about accepting the client certificate since it's 
> complaining about a "bad signature" where tlsv1 doesn't?
> 
> Anybody have any ideas? ... N
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> 
> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Nounou Dadoun
> Sent: Thursday, February 25, 2016 2:42 PM
> To: openssl-us...@openssl.org
> Subject: [openssl-users] Failed TLSv1.2 handshake with error 67702888--bad 
> signature
> 
>   I'm trying to troubleshoot some development code which is enabling TLSv1.1 
> and 1.2 and failing. Have an odd tls handshake failure, with an error number 
> that I can find any documentation about (is there any?) that indicates 
> "67702888--bad signature" which is being logged on the server side; and I'm 
> trying to see where in the handshake things are falling apart.
> 
> Looks like it's negotiating tls1.2 and agreeing on 
> TLS_RSA_WITH_AES_256_CBC_SHA256 but the client seems to be sending a 
> certificate although I don't see it requesting mutual authentication.
> 
> I've attached a very short wireshark capture - does anyone know what that 
> error code might be related to or can give me a hint as to what's going awry 
> here?  Thanks ... N
> 
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> 
> Office: 604.629.5182 ext 2632
> Support: 888.281.5182  |  avigilon.com
> Follow Twitter  |  Follow LinkedIn
> 
> 
> This email, including any files attached hereto (the "email"), contains 
> privileged and confidential information and is only for the intended 
> addressee(s). If this email has been sent to you in error, such sending does 
> not constitute waiver of privilege and we request that you kindly delete the 
> email and notify the sender. Any unauthorized use or disclosure of this email 
> is prohibited. Avigilon and certain other trade names used herein are the 
> registered and/or unregistered trademarks of Avigilon Corporation and/or its 
> affiliates in Canada and other jurisdictions worldwide.
> 
> 



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

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

Re: [openssl-dev] [openssl.org #4343] master: EC_KEY_priv2buf (): check parameter sanity

[Kurt Roeckx]

On Fri, Feb 26, 2016 at 05:34:14PM +, Viktor Dukhovni wrote:
> On Fri, Feb 26, 2016 at 05:29:26PM +, Salz, Rich wrote:
> 
> > As just about the only team member who trolls through RT and closes things
> > with any quantity, I am not sure that I agree that fixing a bug requires
> > documentation if the API isn't already documented.
> 
> Focus on fixing bugs in documented interfaces first, and even then review
> the documentation, to make sure the fix comports with the documentation and
> that the latter is not stale.
> 
> Once all the bugs in documented interfaces are fixed, I'm afraid
> we really must start documenting the code we're updating.  Otherwise,
> there's no way to know we're doing it right, and we're digging the
> hole deeper.  New code needs to be documented as it is written,
> old code also, but at a slower pace.

I have to agree with Viktor.  I've also been requesting minimal
documentation for the new non-public functions.  If I'm changing
something in any non-documented function I try documenting it,
but sometimes I might forget that, and I hope someone would remind
me in that case.


Kurt

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