Re: [openssl-dev] Enhancing ssltest_old.c?

[Bill Cox]

Sorry... stupid auto-send still happens on my Goobuntu latptop, even with
tap-click disabled on the still poorly supported touchpad.

Here's the current PR:  https://github.com/openssl/openssl/pull/1538

My feeling is that if we put in the effort to upgrade the new SSL test
harness to understand custom extensions, it might also be a good time to
upgrade the custom extension API.  There are a couple of enhancements that
likely have been considered here before:

-  Add a way for custom extensions to save/restore state to the streamed
session
- Add a way for custom extensions to see what other extensions have been
negotiated or not.

Right now, custom extensions cannot save state between connections.  This
makes many simple extensions impossible to implement using the custom
extension API.  Often the server needs to remember the outcome of the
original extension negotiation.

Another issue is that custom extensions get zero knowledge of other
extensions.  This makes some things hard to implement.  For example, we
would like to stop including a version field in the token binding
extension, and instead just issue a new extension if the binary format
needs to be updated in an incompatible way.  What happens if version 1.0
gets rewritten as a native extension, and we later write a new custom
extension to override it?  Right now, there is no way to do that, giving
weight to the argument for keeping the version number in the extension.  It
is also not possible to ensure that extended-master-secret has been
negotiated before the server add-callback has to commit to sending the
token-binding extension in the server hello, meaning the client must check
both extensions after the handshake completes, which is a bit goofy.

So, what would you think about going forward with a simple upgrade similar
to my PR, while working out what an improved custom extension API should
look llike?

Bill

On Mon, Sep 5, 2016 at 7:12 PM, Bill Cox  wrote:

> I took a quick look through the new SSL test framework, which looks pretty
> good.  I created this pull request to show what I currently propose:
>
>
> On Mon, Sep 5, 2016 at 2:22 PM, Richard Levitte 
> wrote:
>
>> I think it makes more sense to extend the new SSL test framework...
>>
>> Cheers
>> Richard
>>
>> Bill Cox  skrev: (5 september 2016 19:14:22 CEST)
>> >I wrote a simple change to custom extensions so that they can be
>> >negotiated
>> >on resume, which is needed by token binding.  I put the test for this
>> >change in test/ssltest_old.c, which seems weird, but there are no
>> >custom
>> >extension tests in the new SSL tests AFAIK.  Do we still extend the old
>> >tests when there are no equivalent new tests?
>> >
>> >Bill
>> >
>> >
>> >
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> --
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>
>
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Enhancing ssltest_old.c?

[Bill Cox]

I took a quick look through the new SSL test framework, which looks pretty
good.  I created this pull request to show what I currently propose:


On Mon, Sep 5, 2016 at 2:22 PM, Richard Levitte  wrote:

> I think it makes more sense to extend the new SSL test framework...
>
> Cheers
> Richard
>
> Bill Cox  skrev: (5 september 2016 19:14:22 CEST)
> >I wrote a simple change to custom extensions so that they can be
> >negotiated
> >on resume, which is needed by token binding.  I put the test for this
> >change in test/ssltest_old.c, which seems weird, but there are no
> >custom
> >extension tests in the new SSL tests AFAIK.  Do we still extend the old
> >tests when there are no equivalent new tests?
> >
> >Bill
> >
> >
> >
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Enhancing ssltest_old.c?

[Richard Levitte]

I think it makes more sense to extend the new SSL test framework... 

Cheers 
Richard 

Bill Cox  skrev: (5 september 2016 19:14:22 CEST)
>I wrote a simple change to custom extensions so that they can be
>negotiated
>on resume, which is needed by token binding.  I put the test for this
>change in test/ssltest_old.c, which seems weird, but there are no
>custom
>extension tests in the new SSL tests AFAIK.  Do we still extend the old
>tests when there are no equivalent new tests?
>
>Bill
>
>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Enhancing ssltest_old.c?

[Bill Cox]

I wrote a simple change to custom extensions so that they can be negotiated
on resume, which is needed by token binding.  I put the test for this
change in test/ssltest_old.c, which seems weird, but there are no custom
extension tests in the new SSL tests AFAIK.  Do we still extend the old
tests when there are no equivalent new tests?

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

Re: [openssl-dev] FIPS validation

[Steve Marquess]

On 09/05/2016 02:09 AM, Leon Brits wrote:
> The FIPS validation company says:
> 
>  
> 
> “The tests I am most interested in are the failure cases, where you
> induce an error in each of the power-on self-tests and conditional tests
> (i.e, continuous RNG test, pairwise consistency test).”
> 
>  
> 
> Can anybody tell me how I can induce these errors?
> 
>  
> 
> I do run the FIPS_selftest() function on demand and the POST has never
> failed when I switch to FIPS mode with FIPS_mode_set().
> 
>  
> 
> Thanks
> 
> LJB
> 
> 
> 

So you're trying to obtain your own copycat validation based on the
OpenSSL FIPS Object Module code (as many vendors have done).

Since that has been done so many times your unnamed FIPS validation
consultant or test lab should already be familiar enough with the
OpenSSL FIPS module code to immediately know the answer to this
question, rather than asking it of you (that's a hint).

Most labs or consultants would direct you to the "fips_test_suite" test
harness (also called from fips_algvs), which is included in the OpenSSL
FIPS module tarballs and documented in the User Guide:

  https://www.openssl.org/docs/fips/UserGuide-2.0.pdf

Test labs typically just run "fips_algv fips_test_suite" for the
functional testing, as it was designed for exactly that purpose.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org beetle 4668] Enhancement request: website: support proper titles

[Steffen Nurpmeso]

"Salz, Rich"  wrote:
 |> Maybe you like it.  I haven't tried it, but see no reason why it
 |> shouldn't work.  It also adjusts headline tags in secpolicy.html, \
 |> which don't
 |> comply to the rest of the site yet.
 |
 |It's good enough.  None of us our web developers.  I just pushed the \
 |updated repo to https://github.com/openssl/web

A 42 KB patch, and you and i both have seen it.

 |If you have improvements, plelase make a PR :o)

I think less professionalism is better much often than not.  (Just
take these assembly lines of death for supermarket etc. meat.)
As a natural born german i hate missing end tags etc. nonetheless.
That must be said.  Then again, browsers are used to swallow ...
Ciao.

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

Re: [openssl-dev] Certificate torture test

[David Woodhouse]

On Fri, 2016-09-02 at 20:20 +, Salz, Rich wrote:
> > I've started collecting a certificate torture test suite at
> > http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am
> 
> I think this is cool, and splitting it off is a good idea.  I think
> some IETF folks would be interested, too.

I'm tempted to split off the code with it. There's no way that
applications should have to have *hundreds* of lines of their own code
just to persuade the crypto library to use a cert/key pair specified by
the user.

Basically everything between
http://git.infradead.org/users/dwmw2/openconnect.git/blob/e048030f8:/openssl.c#l278
and
http://git.infradead.org/users/dwmw2/openconnect.git/blob/e048030f8:/openssl.c#l1012

... and the *whole* of openssl-pkcs11.c, is code I just don't want to
have in the *application*. I could just BSD-license it and put it out
there for people to use in the short term. In the (slightly) longer
term, of course, OpenSSL should do it all. Including PKCS#11.

FWIW, the torture test is now causing OpenSSL to crash because it
assumes all EC *private* keys will also have the public key available,
which isn't necessarily true when the key is in a hardware engine.
  https://github.com/openssl/openssl/issues/1532

-- 
dwmw2

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

[openssl-dev] FIPS validation

[Leon Brits]

The FIPS validation company says:

"The tests I am most interested in are the failure cases, where you induce an 
error in each of the power-on self-tests and conditional tests (i.e, continuous 
RNG test, pairwise consistency test)."

Can anybody tell me how I can induce these errors?

I do run the FIPS_selftest() function on demand and the POST has never failed 
when I switch to FIPS mode with FIPS_mode_set().

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