FIPS certification for openssl

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

FIPS certification for openssl

Sandeep Umesh-2

Hello

As per this blog:
https://www.openssl.org/blog/blog/2017/10/27/steve-marquess/

Steve who is instrumental in handling FIPS certification for openssl object module is no more associated with OSF.
How can we proceed for future FIPS certification ? Is there any other contact person to perform FIPS certification for openssl object module ?
Thanks

Regards
Sandeep



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

Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of Sandeep Umesh
> Sent: Wednesday, November 29, 2017 07:30
> To: [hidden email]; [hidden email]

> As per this blog:
> https://www.openssl.org/blog/blog/2017/10/27/steve-marquess/

Thanks for pointing that out. I somehow hadn't even noticed there was an official OpenSSL blog (I'm now subscribed). I see from it that Steve Henson is also leaving (or has left) the project.

> Steve who is instrumental in handling FIPS certification for openssl object module is no more associated with OSF.
> How can we proceed for future FIPS certification ? Is there any other contact person to perform FIPS certification for
> openssl object module ?

In homage to Steve, I'd like to point out that there's no such thing as "FIPS certification". Presumably you mean FIPS validation.

I assume that the OpenSSL Management Committee will find someone else to take on the various roles Steve Marquess filled over the years, including shepherding the FIPS validations through. Now that the OpenSSL Project is bigger and better-funded, it's quite possible FIPS validation, and other aspects, won't be as closely associated with a single person as they historically were.

And that's good, generally speaking; they should be owned by the Project and the OMC. While I'm sure we're all grateful to Steve M for his work with OpenSSL over the years - and I for one will miss hearing from him on this list, on matters FIPS-related and others - for a project as important as OpenSSL it's not really healthy for users to see aspects of it as tied to an individual.

That said, it wouldn't hurt for the OMC to post a message to the list stating that business will continue as planned, since two very key figures have left the project.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

OpenSSL - User mailing list
In reply to this post by Sandeep Umesh-2

We are no longer doing additional platforms for the existing certifications.

 

We are working on a plan for future FIPS validation, based on the 1.1.x line.

 

From: Sandeep Umesh <[hidden email]>
Reply-To: openssl-users <[hidden email]>
Date: Wednesday, November 29, 2017 at 7:30 AM
To: openssl-users <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: [openssl-users] FIPS certification for openssl

 

Hello

As per this blog:
https://www.openssl.org/blog/blog/2017/10/27/steve-marquess/

Steve who is instrumental in handling FIPS certification for openssl object module is no more associated with OSF.
How can we proceed for future FIPS certification ? Is there any other contact person to perform FIPS certification for openssl object module ?
Thanks

Regards
Sandeep


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

Jakob Bohm-7
In reply to this post by Michael Wojcik
On 29/11/2017 14:58, Michael Wojcik wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf Of Sandeep Umesh
>> Sent: Wednesday, November 29, 2017 07:30
>> To: [hidden email]; [hidden email]
>> As per this blog:
>> https://www.openssl.org/blog/blog/2017/10/27/steve-marquess/
> Thanks for pointing that out. I somehow hadn't even noticed there was an official OpenSSL blog (I'm now subscribed). I see from it that Steve Henson is also leaving (or has left) the project.
>
>> Steve who is instrumental in handling FIPS certification for openssl object module is no more associated with OSF.
>> How can we proceed for future FIPS certification ? Is there any other contact person to perform FIPS certification for
>> openssl object module ?
> In homage to Steve, I'd like to point out that there's no such thing as "FIPS certification". Presumably you mean FIPS validation.
>
> I assume that the OpenSSL Management Committee will find someone else to take on the various roles Steve Marquess filled over the years, including shepherding the FIPS validations through. Now that the OpenSSL Project is bigger and better-funded, it's quite possible FIPS validation, and other aspects, won't be as closely associated with a single person as they historically were.
>
> And that's good, generally speaking; they should be owned by the Project and the OMC. While I'm sure we're all grateful to Steve M for his work with OpenSSL over the years - and I for one will miss hearing from him on this list, on matters FIPS-related and others - for a project as important as OpenSSL it's not really healthy for users to see aspects of it as tied to an individual.
>
> That said, it wouldn't hurt for the OMC to post a message to the list stating that business will continue as planned, since two very key figures have left the project.
>
Indeed, over the past few years I have seen an increasing tendency
to hide monumental news in the blog, in press releases etc. Anywhere
but the well established and independently archived public mailing lists.

One really has to wonder if this is still OpenSSL that the world has
known and loved for 20 years, or just some expensive imitation.

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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

OpenSSL - User mailing list
> That said, it wouldn't hurt for the OMC to post a message to the list stating that business will continue as planned, since two very key figures have left the project.

I have two reactions, just my personal view.  First, it’s premature to say anything, we’re still figuring things out. Second, what open source project can guarantee that things will continue as they were after people left?  Or the larger question, what guarantees can any project really make?

➢ Indeed, over the past few years I have seen an increasing tendency to hide monumental news in the blog, in press releases etc.

To pick a nit, it’s just the blog.  The press release was copied to the blog, and I don’t know of anything that would qualify as “etc” -- can you remind me?  We started using the blog because we thought it would be a better way to get higher-quality information out, without being swallowed up by the volume of email messages.

➢  Anywhere but the well established and independently archived public mailing lists.
   
It’s not the same Internet that it used to be…  Lots of discussion happens on GitHub issues these days, which I’m not thrilled with either.  (Hey you kids, get off my lawn.)   It seems that posting a note to the lists would be useful whenever we post a blog entry?  

>    One really has to wonder if this is still OpenSSL that the world has known and loved for 20 years, or just some expensive imitation.

I am biased, but I believe the project is better, by almost any metric, then it used to be.  If you have specific suggestions for how you think it could be improved, it would be great to see them.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

Mark Minnoch
In reply to this post by Sandeep Umesh-2
If you need a FIPS resource for the OpenSSL FIPS Object Module -- my business partner (Steve Weymann) and I worked with Steve Marquess when we were at a FIPS Testing Lab to achieve the FIPS 140-2 Cert. #1747 for the OpenSSL FIPS Object Module.

We are now helping technology companies that need FIPS testing of the OpenSSL FOM on specific operating systems. We also perform Private Label validations to rebrand the OpenSSL FOM for our clients.

Mark J. Minnoch
Co-Founder, CISSP, CISA
KeyPair Consulting
+1 (805) 550-3231 mobile

We expertly guide technology companies in achieving their FIPS 140 goals

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

Michael Wojcik
In reply to this post by OpenSSL - User mailing list
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Salz, Rich via openssl-users
> Sent: Wednesday, November 29, 2017 11:54
> To: [hidden email]
> Subject: Re: [openssl-users] FIPS certification for openssl
>

[I wrote:]
 > > That said, it wouldn't hurt for the OMC to post a message to the list stating
> > that business will continue as planned, since two very key figures have left
> > the project.
>
> I have two reactions, just my personal view.  First, it’s premature to say
> anything, we’re still figuring things out. Second, what open source project
> can guarantee that things will continue as they were after people left?  Or
> the larger question, what guarantees can any project really make?

That's fair. And on further consideration I'll withdraw the "to the list" part.

[Jakob wrote:]

> >  Anywhere but the well established and independently archived public
> > mailing lists.
>
> It’s not the same Internet that it used to be…  Lots of discussion happens on
> GitHub issues these days, which I’m not thrilled with either.  (Hey you kids,
> get off my lawn.)   It seems that posting a note to the lists would be useful
> whenever we post a blog entry?

I can't speak for Jakob, of course. I was surprised to learn of the blog posts, because I hadn't been following the blog; if I knew it existed at some point, I'd forgotten. But I'm following it now.

It probably wouldn't hurt to post something to the lists when there's a blog post with news like this  - items that subscribers would likely feel is important. Blog posts like the recent "OpenSSL in China" series probably don't need to be mentioned on the lists. But it's subjective, and I wouldn't want to create more work for anyone.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

OpenSSL - User mailing list
➢ It probably wouldn't hurt to post something to the lists when there's a blog post with news like this  - items that subscribers would likely feel is important. Blog posts like the recent "OpenSSL in China" series probably don't need to be mentioned on the lists. But it's subjective, and I wouldn't want to create more work for anyone.
   
It’s a lot easier than writing the blog posts (

We should have been doing this from the very beginning, oops.  We’ll try to do better.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

JordanBrown
In reply to this post by OpenSSL - User mailing list
On 11/29/2017 8:53 AM, Salz, Rich via openssl-users wrote:
I am biased, but I believe the project is better, by almost any metric, then it used to be. If you have specific suggestions for how you think it could be improved, it would be great to see them.


My number one complaint is that it seems like the defaults are generally set up to do the wrong things, and the application has to either explicitly set "yes, you should be secure" options or do stuff on its own.  This seems to have been getting better - gaining hostname validation, for instance - but really a client should be able to say "give me a secure connection to host:port" and have sensible and secure things happen with a single call.  Maybe two, one to create a handle and the other to actually set up the connection (to allow for intervening calls that customize the connection).

-- 
Jordan Brown, Oracle Solaris

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

OpenSSL - User mailing list

> My number one complaint is that it seems like the defaults are generally set up to do the wrong things, and the application has to either explicitly set "yes, you should be secure" options or do stuff on its own.  This seems to have been getting better - gaining hostname validation, for instance - but really a client should be able to say "give me a secure connection to host:port" and have sensible and secure things happen with a single call.  Maybe two, one to create a handle and the other to actually set up the connection (to allow for intervening calls that customize the connection).

I agree with you, but a problem is that “safe and secure” changes over time when new  crypto and other new features are added. And then users get upset when their connections no longer work.

I think the right approach is to be able to specify a policy, then at least you know what you’re signing up for. Right now it’s a collection of low-level things.  And the policy is “SECLEVEL” which ain’t great.

 

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

JordanBrown
On 11/29/2017 6:13 PM, Salz, Rich via openssl-users wrote:
I agree with you, but a problem is that “safe and secure” changes over time when new  crypto and other new features are added. And then users get upset when their connections no longer work.

Agreed, that's a tough trade-off.

Still, I'd rather have compatibility problems - as long as there's a way to explicitly request the less-secure option - than silently be insecure.

Having per-user or system-wide configuration files that are consulted under the covers would help, since then the user could revert to less-secure settings without needing the application source.  Maybe have the "create handle" function take an application name as an argument, so that individual applications could be managed separately.

Looking at it another way:  browsers manage to do it...

-- 
Jordan Brown, Oracle Solaris

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of Jordan Brown
> Sent: Thursday, November 30, 2017 00:34

> On 11/29/2017 6:13 PM, Salz, Rich via openssl-users wrote:
> > I agree with you, but a problem is that “safe and secure” changes over time when new  crypto and other new features
> > are added. And then users get upset when their connections no longer work.

That, and many applications will reasonably disagree on what an appropriate default is.

> Still, I'd rather have compatibility problems - as long as there's a way to explicitly request the less-secure option - than
> silently be insecure.

But some other people would not prefer compatibility problems.

There are a great many OpenSSL consumers. Making radical changes to the default behavior of the API would break many applications - and so it's likely those applications would stop updating their OpenSSL builds.

> Having per-user or system-wide configuration files that are consulted under the covers would help,

For many applications, no, it really wouldn't. It would be a huge mess.

> since then the user could revert to less-secure settings without needing the application source.

If the application is well-written, the user doesn't need the application source now. If the application isn't well-written, being able to change "settings" is not one of your bigger problems.

> Maybe have the "create handle" function take an application name as an argument, so that individual applications
> could be managed separately.

And we have another namespace problem. No thanks.

> Looking at it another way:  browsers manage to do it...

Manage to do what, exactly? And how are browsers a good model for the vast range of OpenSSL applications? They're just one type of client that nearly always uses a very particular PKI model.

Not all the world's a VAX.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

JordanBrown
On 11/30/2017 5:41 AM, Michael Wojcik wrote:
There are a great many OpenSSL consumers. Making radical changes to the default behavior of the API would break many applications - and so it's likely those applications would stop updating their OpenSSL builds.

Yes, compatibility is a concern.  So make the "default to secure" options be new functions.

If the application is well-written, the user doesn't need the application source now. If the application isn't well-written, being able to change "settings" is not one of your bigger problems.

You really think that most applications handle all this stuff right?  See below.

Looking at it another way:  browsers manage to do it...
Manage to do what, exactly? And how are browsers a good model for the vast range of OpenSSL applications? They're just one type of client that nearly always uses a very particular PKI model.

Manage to make reasonably secure connections with a minimum of user hassle.

Is it really right that a basic client (from the O'Reilly book) is over 300 lines long?  (client3.c, common.c, reentrant.c)

But the really dangerous thing is that if you miss a step, what you get is a silently insecure connection rather than a failure.

Do you really like having OpenSSL featured in papers like this?
The most dangerous code in the world: validating SSL certificates in non-browser software
-- 
Jordan Brown, Oracle Solaris

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

Michael Wojcik
> From: Jordan Brown [mailto:[hidden email]]
> Sent: Friday, December 01, 2017 17:18

> On 11/30/2017 5:41 AM, Michael Wojcik wrote:

> > There are a great many OpenSSL consumers. Making radical changes to the default behavior of the API would break
> > many applications - and so it's likely those applications would stop updating their OpenSSL builds.

> Yes, compatibility is a concern.  So make the "default to secure" options be new functions.

That's certainly better than what you proposed in your previous messages. It's still not where I'd want to see the core OpenSSL developers spending their time, though.

Of course, anyone's free to write their own API on top of what OpenSSL provides, and even make a pull request to contribute it to the project.

> > If the application is well-written, the user doesn't need the application source now. If the application isn't well-written,
> > being able to change "settings" is not one of your bigger problems.

> You really think that most applications handle all this stuff right?  See below.

No. That's not what I wrote.

> > > Looking at it another way:  browsers manage to do it...
> > Manage to do what, exactly? And how are browsers a good model for the vast range of OpenSSL applications? They're
> >  just one type of client that nearly always uses a very particular PKI model.

> Manage to make reasonably secure connections with a minimum of user hassle.

Still just one type of client.

> Is it really right that a basic client (from the O'Reilly book) is over 300 lines long?  (client3.c, common.c, reentrant.c)

As I said: nothing is stopping anyone from wrapping that up in an API.

> But the really dangerous thing is that if you miss a step, what you get is a silently insecure connection rather than a
>  failure.

Depends on what step you miss.

Look, I'm well aware this is a problem. I just gave an internal presentation to a roomful of developers on this very subject in October. But I don't think changing OpenSSL to consult "per-user or system-wide configuration files" by default - which is what you appeared to propose in the note I was responding to - is the right solution. Nor, as I said above, do I think it's where the OpenSSL Project developers should be focussing their efforts at this time. If someone else wants to, fine - though I think it's a much harder problem than you're making it out to be.

> Do you really like having OpenSSL featured in papers like this?
> The most dangerous code in the world: validating SSL certificates in non-browser software

Better than being omitted. And I'm well aware of that paper (an old [well, since 2012] favorite); I discussed it in the talk I mentioned above.

Frankly, what I'd like is fewer people using OpenSSL at all. Not necessarily fewer applications, but fewer *people*. Cryptography and security are inherently difficult; TLS is particularly bad, because of its history, configurability, interoperability demands, and horrendously broken PKI. It's an area for experts. I'd like the barrier to entry to be *higher*, so we'd see fewer people posting messages like "I tried to write a server using OpenSSL but I don't understand cipher suites".

Hell, as the "Most Dangerous Code" paper itself points out at some length, JSSE tried for "secure by default", but many JSSE-based applications use the wrong APIs and unwittingly bypass certificate validation. Secure-by-default is extremely difficult with TLS.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

JordanBrown
On 12/1/2017 2:57 PM, Michael Wojcik wrote:
Yes, compatibility is a concern.  So make the "default to secure" options be new functions.
That's certainly better than what you proposed in your previous messages.

Sorry, I wasn't trying to propose any particular concrete interfaces.  I was trying to speak abstractly:  "a client should be able to say 'give me a secure connection to host:port' and have sensible and secure things happen with a single call.  Maybe two, one to create a handle and the other to actually set up the connection (to allow for intervening calls that customize the connection)."  (OK, yeah, I did get a bit more concrete later, but I never said "change the existing functions".)

Of course, anyone's free to write their own API on top of what OpenSSL provides, and even make a pull request to contribute it to the project.

If only I had the time.  I do greatly respect the work that people do on FOSS projects.  I just wish more would focus on getting the common cases to be easy and bulletproof, and less on being all things to all people.

Looking at it another way:  browsers manage to do it...
Manage to do what, exactly? And how are browsers a good model for the vast range of OpenSSL applications? They're
 just one type of client that nearly always uses a very particular PKI model.

      
Manage to make reasonably secure connections with a minimum of user hassle.
Still just one type of client.

Maybe I just don't have a big enough picture, but in my TLS-related work (mostly client LDAP, but some other stuff) I keep coming back to a browser as the behavior that I should emulate.

Frankly, what I'd like is fewer people using OpenSSL at all. Not necessarily fewer applications, but fewer *people*. Cryptography and security are inherently difficult; TLS is particularly bad, because of its history, configurability, interoperability demands, and horrendously broken PKI. It's an area for experts. I'd like the barrier to entry to be *higher*, so we'd see fewer people posting messages like "I tried to write a server using OpenSSL but I don't understand cipher suites".

What should they use instead?

What *should* core OpenSSL developers be focused on?

And why should callers have to understand cipher suites at any deep level?  Why should they need to know any more than "there are multiple algorithms, and new algorithms are introduced occasionally, and old algorithms are defeated occasionally, but you may need old algorithms for interoperability, so you need to have a way to select which algorithms you accept"?  That's pretty much the limits of my mental model; what am I missing?

-- 
Jordan Brown, Oracle Solaris

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

debbie10t
In reply to this post by OpenSSL - User mailing list
Hi there,

long time lurker ..

This sort of thing is a Remarkably Unique Occasion ...

Personally, I do subscribe here for genuine, up to date,
informative and even humorous (on occasion) information.

I do not expect this to be the sole source of my knowledge.

But .. I did learn of the impending and drastic changes
via this list *and not as an official notice but rather
by accident.

Personally, I would like to see such critical changes
flood the openssl chambers .. but I do also respect that
the people involved may have made their own personal choices
regarding their actions ... I guess it is very complicatted....

I would say "Good ~/Luck and Thank You" to those we loose
And (personally) "Thank You for stepping Into the breach"
those who choose to .. because they can ! .. I could not

God damn that Single Malt !




On 29/11/17 23:01, Salz, Rich via openssl-users wrote:
> ➢ It probably wouldn't hurt to post something to the lists when there's a blog post with news like this  - items that subscribers would likely feel is important. Blog posts like the recent "OpenSSL in China" series probably don't need to be mentioned on the lists. But it's subjective, and I wouldn't want to create more work for anyone.
>      
> It’s a lot easier than writing the blog posts (
>
> We should have been doing this from the very beginning, oops.  We’ll try to do better.
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

Michael Wojcik
In reply to this post by JordanBrown
> From: Jordan Brown [mailto:[hidden email]]
> Sent: Friday, December 01, 2017 19:48

> On 12/1/2017 2:57 PM, Michael Wojcik wrote:

> > Of course, anyone's free to write their own API on top of what OpenSSL provides, and even make a pull request to
> > contribute it to the project.

> If only I had the time.  I do greatly respect the work that people do on FOSS projects.  I just wish more would focus on
> getting the common cases to be easy and bulletproof, and less on being all things to all people.

Well, I suppose this is the core of our disagreement. I don't think that should be at the top of the priority list, or indeed high enough to make it likely to happen any time soon.

My personal priority list for OpenSSL is bug fixes and code cleanup (static and dynamic analysis of the 1.1.x codebase would be good, and one of these days I'll get around to doing it myself), and continuing the TLSv1.3 implementation until that standard finally settles down. (I'm not much of a TLSv1.3 fan, but customers will demand it.) If there's spare time, the docs always need work. PKCS#12 support could be improved (though maybe it's better in 1.1.x).

Reasonable people can of course disagree. I don't think your position is indefensible; I just don't agree with it.

As I said, I recognize the utility ofa simple client library. I wrote one that does secure-by-default myself. It's in a commercial product and I don't control the IP, so it's not open source - but it really wasn't that difficult or time-consuming. Which is probably why a bunch of other people have done it too: libcurl, OpenLDAP (OK, OpenLDAP is a shambling horror), TLS modules for various languages and frameworks, ...

And for the server side, the best answer is often "use an existing server". Sure, there are plenty of use cases where that's not feasible, but I also see a fair bit of people writing server-side TLS code when they could simply hang their application off an existing server.

A better question might be "why are the common cases common at all?". Why are so many people writing code that calls the OpenSSL API?

> Maybe I just don't have a big enough picture, but in my TLS-related work (mostly client LDAP, but some other stuff) I
> keep coming back to a browser as the behavior that I should emulate.

Yes, I'd have to call that a pretty limited use case. It doesn't cover the server side at all. It doesn't do much for client certificates (which browsers do not handle well). For that matter, browsers don't do a very good job with PKI; they basically say "hey, we've decided to trust this collection of public, commercial CAs, and for anything beyond that you're either going to have to know something about X.509 hierarchical PKI, or someone who does will have to hold your hand". They require user interaction when anything out of the ordinary happens, and the UX and UIM for that interaction has historically been a disaster (basically training users to click through warnings). Of late browsers have moved to failling safe with override provisions, but it's still not great UIM.

That's fine for some things, but it doesn't help with servers and it falls over for non-interactive use (or even interactive but non-GUI), or for anything where PKI gets more complicated.

> > Frankly, what I'd like is fewer people using OpenSSL at all. Not necessarily fewer applications, but fewer *people*.
> > Cryptography and security are inherently difficult; TLS is particularly bad, because of its history, configurability,
> > interoperability demands, and horrendously broken PKI. It's an area for experts. I'd like the barrier to entry to be
> > *higher*, so we'd see fewer people posting messages like "I tried to write a server using OpenSSL but I don't
> > understand cipher suites".

> What should they use instead?

Libraries and programs written by people who *do* understand cryptography.

There are plenty of car manufacturers who don't design and build their own engines. House builders rarely mill their own wood or construct their own windows and doors. Surgeons aren't responsible for building their own X-ray machines or even sharpening their own scalpels. Few authors build their own computers or write their own word processors. Why do programmers need to be in control of so much of their own software stacks?

> And why should callers have to understand cipher suites at any deep level?

For the same reason electricians need to understand electricity.

I don't know how long you've been reading openssl-users. I've been subscribed to it since 2000. I've read a lot of messages from people who understood very little about SSL/TLS. They didn't understand what cipher suites *are* (I'm not asking for any "deep" understanding of the ciphers themselves - though familiarity with known vulnerabilities should be required). They didn't understand the SSL/TLS protocols. They didn't understand X.509 and the hierarchical PKI that's nearly always used with TLS. Often, they didn't understand TCP, which is itself a problem. They weren't keeping up with TLS-related news, which is a *big* problem, and even if they did, they wouldn't know enough to understand it.

Those people should not have been using OpenSSL.

Those are all correctable problems, of course; most of those people were, presumably, completely capable of learning those things. But they didn't, probably because they didn't understand that it's a necessary part of the job if you want to write code that calls OpenSSL. Or if they did, they weren't given the resources to do so. Or they were lazy, human nature being what it is.

> Why should they need to know any more than "there are multiple algorithms, and new algorithms are introduced
> occasionally, and old algorithms are defeated occasionally, but you may need old algorithms for interoperability, so
> you need to have a way to select which algorithms you accept"?  That's pretty much the limits of my mental model;
> what am I missing?

Urgh. I don't really have room (or permission) to post all of Ivan Ristic's /Bulletproof TLS/ book here.

Let's try this. "The C language has various operators and standard library functions, and new functions are introduced occasionally, and old functions are deprecated occasionally, but you may have code that uses old functions, so you need to pick what functions you'll use." Is that a good mental model for writing C programs?

TLS is hard. The OpenSSL API is hard. Making (relatively small) parts of TLS and OpenSSL easier by wrapping them in a client API or hosting applications in a third-party server is entirely possible, since many people (including me) have done it. But I don't see a lot of value in pushing that Easy Mode into OpenSSL itself. That's not where it belongs - layer abstractions and separate concerns. And it encourages the wrong behavior, which is using the OpenSSL API in the first place. That should be left to people who have the luxury (and exercise it) of studying the subject at length.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

OpenSSL - User mailing list

>    My personal priority list for OpenSSL is bug fixes and code cleanup (static and dynamic analysis of the 1.1.x codebase would be good, and one of these days I'll get around to doing it myself),

We do run coverity weekly, and anyone can sign up to see the results BTW

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

JordanBrown
In reply to this post by Michael Wojcik
On 12/2/2017 6:35 AM, Michael Wojcik wrote:
My personal priority list for OpenSSL is bug fixes and code cleanup (static and dynamic analysis of the 1.1.x codebase would be good, and one of these days I'll get around to doing it myself), and continuing the TLSv1.3 implementation until that standard finally settles down. (I'm not much of a TLSv1.3 fan, but customers will demand it.) If there's spare time, the docs always need work. PKCS#12 support could be improved (though maybe it's better in 1.1.x).

I would never, ever, object to putting bug fixes at the top of the list.

But at the same time we're talking about trying to prevent bugs in the callers, and that's valuable too.

A better question might be "why are the common cases common at all?". Why are so many people writing code that calls the OpenSSL API?

Because they know they need a secure connection, and they know that that means TLS/SSL, and they know that the leading library for TLS/SSL is OpenSSL, and nothing says "you should be using libFOO instead".  You look for the key under the street light, because that's where the light is.

[Emulating a browser is] fine for some things, but it doesn't help with servers and it falls over for non-interactive use (or even interactive but non-GUI), or for anything where PKI gets more complicated.

And yet it's probably better than 95% of what you'll get from non-experts rolling their own.

My work is almost entirely non-interactive during production.  So far, I've been pretty happy with a model that says "emulate a browser during initial interactive configuration, then use those settings during production and light a yellow light when anything goes wrong".

(And yes, of course browsers aren't servers... there I'd say "Emulate Apache httpd".)

What should they use instead [of OpenSSL]?
Libraries and programs written by people who *do* understand cryptography.

It seems like our only disagreement is in who should supply those libraries, whether OpenSSL should supply one or should leave it to others.

Why do programmers need to be in control of so much of their own software stacks?

Totally agreed, they shouldn't.  They need to be guided into doing the right thing.  It should be hard to do the wrong thing.  Everybody will be happier.

Why should they need to know any more than "there are multiple algorithms, and new algorithms are introduced
occasionally, and old algorithms are defeated occasionally, but you may need old algorithms for interoperability, so
you need to have a way to select which algorithms you accept"?  That's pretty much the limits of my mental model;
what am I missing?
Urgh. I don't really have room (or permission) to post all of Ivan Ristic's /Bulletproof TLS/ book here.

Let's try this. "The C language has various operators and standard library functions, and new functions are introduced occasionally, and old functions are deprecated occasionally, but you may have code that uses old functions, so you need to pick what functions you'll use." Is that a good mental model for writing C programs?

I have a simplistic viewpoint, but the operators in C are mostly distinct and do different things, while the cipher suites all do the same things, differing only internally.  I don't know, nor do I want to know, how algorithm X is different from algorithm Y, or what key lengths are considered adequate this week.  If I write my application to incorporate any of that knowledge, it will be wrong next year.  My application needs to not care which algorithms it's using, and to be trivially adaptable (preferably at runtime) as the situation changes over the years.  Anything that I know about the actual algorithms will probably make that picture worse, not better.  As you say, those decisions need to be made by people who *do* understand these things... which excludes 99% of developers.

Thanks for the thoughtful discussion.  I really appreciate it.

-- 
Jordan Brown, Oracle Solaris

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: FIPS certification for openssl

Michael Wojcik
In reply to this post by OpenSSL - User mailing list
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Salz, Rich via openssl-users
> Sent: Saturday, December 02, 2017 11:42
>
> >    My personal priority list for OpenSSL is bug fixes and code cleanup (static
> > and dynamic analysis of the 1.1.x codebase would be good, and one of these
> > days I'll get around to doing it myself),
>
> We do run coverity weekly, and anyone can sign up to see the results BTW

Oh, that's right. I knew that at one time (probably when it was announced), but I forgot.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


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