s_server/s_client on checking middlebox compatibility

[John Jiang]

Is it possible to check if peer implements middlebox compatibility by
s_server/s_client?
It looks the test tools don't care this point.
For example, if a server doesn't send change_cipher_spec after
HelloRetryRequest, s_client still feels fine.That's not bad. But can I
setup these tools to check middlebox compatibility?

Re: [openssl-project] OpenSSL 3.0 and FIPS Update

[Richard Levitte]

On Sat, 23 Feb 2019 21:47:00 +0100,
Dmitry Belyavsky wrote:
> 
> 
> Dear Richard, 
> 
> On Sat, Feb 23, 2019 at 8:47 AM Richard Levitte  wrote:
> 
> Since our RAND API is separate from the EVP API, I'm unsure how we
> plan on getting custom RAND_methods from providers.
>
> Please note that we can add RAND to the list of provider backed APIs,
> and given a foundation that we're currently building, it may even be
> quite easy.  However, no one has said explicitly that we would do so.
>
> The other option is, of course, to move the RAND API to EVP somehow,
> but that will probably be more challenging.
> 
> I do not think it is really necessary to move RAND to EVP.
> Current architecture suits our requirements, but if the possibility to 
> overwrite
> the RAND_METHOD is removed, it will cause problems for us.

So it turns out that some of my collegues were assuming that the RAND
API would be provider backed.  I simply hadn't caught on to that...

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: [openssl-project] OpenSSL 3.0 and FIPS Update

[Richard Levitte]

On Mon, 25 Feb 2019 00:40:51 +0100,
Michael Richardson wrote:
> I think that the #define/enum of NIDs should be made internal-only,
> available as optimization to internal code only.

Having asked around a bit on this, that was the original intention...
However, in an old era of having everything in public headers (or at
least everything that was of interest to the public *plus* everything
that libssl might want to use), they slipped out.

NID literally means "numeric identity" and really has no inherent
meaning other than quick access, like you say.

The public interface was meant to be getting stuff by name (string) or
possibly special functions such as EVP_aes_128_cbc()...

> Your question then becomes, "are engines internal users", and I'd like the
> answer to be no. I think that the openssl 3 changes suggest the same thing.

Yup.

> All other users can call OBJ_obj2nid() or OBJ_txt2nid() to get a NID,
> and we can figure out how to allocate things dynamically if this makes
> sense.  I don't know which APIs are currently NID-only.

There are some new APIs in master that add such functions:

EVP_MAC_CTX_new_id()
EVP_KDF_CTX_new_id()

I'm currently thinking that's a mistake.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Missing accessor for the EVP_PKEY.engine

[Dmitry Belyavsky]

On Mon, Feb 25, 2019 at 5:23 PM Matt Caswell  wrote:

>
>
> On 25/02/2019 13:28, Dmitry Belyavsky wrote:
> > Hello,
> >
> > We've started porting our 1.0.2 application to 1.1.1.
> > What is a way to get an engine reference? I did not find a function like
> > EVP_PKEY_get1_engine
>
> Seems to be a missing accessor.
>

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

-- 
SY, Dmitry Belyavsky

Re: OpenSSL hash memory leak

[Jakob Bohm via openssl-users]

On 25/02/2019 15:05, Hubert Kario wrote:

On Sunday, 24 February 2019 11:34:18 CET prithiraj das wrote:

If it helps, sometimes I do get the following errors for the same and
subsequent reboot:

Alignment trap: sh (601) PC=0xb6e008f8 Instr=0x4589c0d7 Address=0x00d7
FSR 0x801
Alignment trap: login (584) PC=0xb6e6ab00 Instr=0xe5951000
Address=0xd27cdc63 FSR 0x001
Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b

that doesn't look like openssl problem at all, openssl may trigger it, but
only because it's using the system to its fullest potential, not because there
are issues in openssl

I'd suggest trying memtest86 and trying to capture full kernel stacktrace with
netconsole, in this order. But this mailing list is not a good place for
follow up on this.


Just FYI.  "Alignment trap" is not usually a hardware issue.  It
is virtually always a software error (specifically, accessing a
16, 32, 64, 80 or 128 bit value through an insufficiently aligned
pointer).

A stack trace is needed to determine if this is a kernel or user
mode issue, and if so where.

Of cause there is the remote possibility that a hardware error
caused a pointer to have a value it shouldn't have according to
the code.

However unless the error is actually in OpenSSL code, there is
little that this list can do to fix the problem.

Given the specific text of the other error message, I hope you
are not somehow running OpenSSL itself as process 1 (init), as
that would be highly unusual.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: Missing accessor for the EVP_PKEY.engine

[Matt Caswell]

On 25/02/2019 13:28, Dmitry Belyavsky wrote:
> Hello,
> 
> We've started porting our 1.0.2 application to 1.1.1. 
> What is a way to get an engine reference? I did not find a function like
> EVP_PKEY_get1_engine

Seems to be a missing accessor.

Matt

Re: OpenSSL hash memory leak

[Hubert Kario]

On Sunday, 24 February 2019 11:34:18 CET prithiraj das wrote:
> If it helps, sometimes I do get the following errors for the same and
> subsequent reboot:
> 
> Alignment trap: sh (601) PC=0xb6e008f8 Instr=0x4589c0d7 Address=0x00d7
> FSR 0x801
> Alignment trap: login (584) PC=0xb6e6ab00 Instr=0xe5951000
> Address=0xd27cdc63 FSR 0x001
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b

that doesn't look like openssl problem at all, openssl may trigger it, but 
only because it's using the system to its fullest potential, not because there 
are issues in openssl

I'd suggest trying memtest86 and trying to capture full kernel stacktrace with 
netconsole, in this order. But this mailing list is not a good place for 
follow up on this.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.

Missing accessor for the EVP_PKEY.engine

[Dmitry Belyavsky]

Hello,

We've started porting our 1.0.2 application to 1.1.1.
What is a way to get an engine reference? I did not find a function like
EVP_PKEY_get1_engine

Thank you!

-- 
SY, Dmitry Belyavsky

TLS v HSTS v T.O.L.A.

[open...@foocrypt.net]

Hi

The current PJCIS is due to report early April.

And just to relieve some the seriousness of the T.O.L.A. impacts whilst 
scribbling together another 10 pages for a PJCIS, I’ve put together the 
following subdomain.

https://WeTheAustralianGovernemntApologizeForCausingTheCryptopocalypse.AUGov.FooCrypt.Net
 


Does any one know how to fix the TLS v HSTS v TOLA problem ?




-- 

Regards,

Mark A. Lane   

Cryptopocalypse NOW 01 04 2016

Volumes 0.0 -> 10.0 Now available through iTunes - iBooks @ 
https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11
© Mark A. Lane 1980 - 2019, All Rights Reserved.
© FooCrypt 1980 - 2019, All Rights Reserved.
© FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2019, All Rights 
Reserved.
© Cryptopocalypse 1980 - 2019, All Rights Reserved.

Re: [openssl-project] OpenSSL 3.0 and FIPS Update

[Dmitry Belyavsky]

Dear Dr Paul,

I think this change is somewhere in a gray zone.

On Mon, Feb 25, 2019 at 1:37 PM Dr Paul Dale  wrote:

> I don’t think that that new OIDs or NIDs are considering breaking.
> Changing existing ones definitely is, but that’s an entirely different
> proposition.
>
>
> Pauli
> --
> Dr Paul Dale | Cryptographer | Network Security & Encryption
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
> On 25 Feb 2019, at 5:02 pm, Dmitry Belyavsky  wrote:
>
>
>
> On Sun, Feb 24, 2019 at 11:31 PM Viktor Dukhovni <
> openssl-us...@dukhovni.org> wrote:
>
>> On Thu, Feb 21, 2019 at 04:20:53PM +, Matt Caswell wrote:
>>
>> > > 2. Can we do something with a bunch of hard-linked non-extendable
>> lists of
>> > > internal NIDs?
>> >
>> > > For example, providing GOST algorithms always requires a patch to
>> extend 3-5
>> > > internal lists.
>> > > If it could be done dynamically, it will be great.
>>
>> The simplest solution is to submit a PR to add your OIDs to OpenSSL,
>> so that no furher out of tree patches are required.
>>
>
> This is a way we go here and now. It is inevitable for libssl, but can be
> significantly reduced for libcrypto.
> Some examples are available in my response to Richard.
>
> And here we get a second problem, relatively small. If I remember
> correctly,
> adding new OIDs/NIDs is treated as breaking the binary compatibility so we
> have to wait for a major release.
>
>
>> Dynamic NIDs don't fit very well into the design, because NIDs are
>> expected to be stable compile-time constants.  We could perhaps
>> reserve a range for "private-use", and "engines" could allocate new
>> NIDs in the private space at runtime.  The key question is whether
>> such NIDs are global or valid only if returned to the same engine
>> (provider, ...).  If not global, the allocation might be static
>> within the engine, and not require any locks.
>>
>
> Totally agree. OBJ_create() and similar functions exist, but do not solve
> our problems.
>
> --
> SY, Dmitry Belyavsky
>
>
>

-- 
SY, Dmitry Belyavsky

Re: [openssl-project] OpenSSL 3.0 and FIPS Update

[Dr Paul Dale]

I don’t think that that new OIDs or NIDs are considering breaking.  Changing 
existing ones definitely is, but that’s an entirely different proposition.


Pauli
-- 
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia



> On 25 Feb 2019, at 5:02 pm, Dmitry Belyavsky  wrote:
> 
> 
> 
> On Sun, Feb 24, 2019 at 11:31 PM Viktor Dukhovni  > wrote:
> On Thu, Feb 21, 2019 at 04:20:53PM +, Matt Caswell wrote:
> 
> > > 2. Can we do something with a bunch of hard-linked non-extendable lists of
> > > internal NIDs?
> >
> > > For example, providing GOST algorithms always requires a patch to extend 
> > > 3-5
> > > internal lists.
> > > If it could be done dynamically, it will be great.
> 
> The simplest solution is to submit a PR to add your OIDs to OpenSSL,
> so that no furher out of tree patches are required.
> 
> This is a way we go here and now. It is inevitable for libssl, but can be 
> significantly reduced for libcrypto.
> Some examples are available in my response to Richard.
> 
> And here we get a second problem, relatively small. If I remember correctly, 
> adding new OIDs/NIDs is treated as breaking the binary compatibility so we 
> have to wait for a major release.
>  
> Dynamic NIDs don't fit very well into the design, because NIDs are
> expected to be stable compile-time constants.  We could perhaps
> reserve a range for "private-use", and "engines" could allocate new
> NIDs in the private space at runtime.  The key question is whether
> such NIDs are global or valid only if returned to the same engine
> (provider, ...).  If not global, the allocation might be static
> within the engine, and not require any locks.
> 
> Totally agree. OBJ_create() and similar functions exist, but do not solve our 
> problems. 
> 
> -- 
> SY, Dmitry Belyavsky