Re: Question About OpenSSL 3.0, FIPS and Solaris Support

[Dr Paul Dale]

The "unadopted" category is not the same as "unsupported".  We'll make 
an effort but if access to a physical machine is required, we will have 
to stop.  Whoever reports a problem will like have to assist with fixing 
it.  Be that by doing builds or writing code.


The platform policy page categories are defined but the OpenSSL 
project's access to hardware.  We do not have access to Solaris boxes 
and no community member has offered to help either with support or 
provision of hardware.  This is why it is in the "unadopted" category.


Oracle, as one of the FIPS project sponsors, was entitled to having 
platforms validated.



Pauli


On 8/12/21 4:55 am, David Dillard via openssl-users wrote:


Hi,

I’m hoping someone can shed some light on something that’s confusing 
me.  In the blog post about the FIPS submission 
 
it states that one of the platforms that’s being tested is “Oracle 
Solaris 11.4 on Oracle SPARC M8-1”.  However, on the platform policy 
page  it lists a 
number of Solaris platforms, all of which are currently “unadopted”.  
How should people interpret that?  That the initial release of OpenSSL 
3.0 was supported on Solaris, but no releases after that are?  Or 
something else?


Thanks,

David

Re: Enumerating TLS protocol versions and ciphers supported by the peer

[Mark Hack]

Look at https://testssl.sh/
That is an openssl wrapper which enumerates ciphers and protocols ( and
a whole lot more)
Hexcode  Cipher Suite Name
(OpenSSL)   KeyExch.   Encryption  Bits Cipher Suite Name
(IANA/RFC)-

SSLv2  SSLv3  TLS 1  TLS 1.1  TLS 1.2   xc030   ECDHE-RSA-AES256-GCM-
SHA384   ECDH
521   AESGCM  256  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384   
xc02f   ECDHE-RSA-AES128-GCM-SHA256   ECDH
521   AESGCM  128  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   
   TLS 1.3   x1302   TLS_AES_256_GCM_SHA384ECDH
521   AESGCM  256  TLS_AES_256_GCM_SHA384  
x1303   TLS_CHACHA20_POLY1305_SHA256  ECDH
521   ChaCha20256  TLS_CHACHA20_POLY1305_SHA256
x1301   TLS_AES_128_GCM_SHA256ECDH
521   AESGCM  128  TLS_AES_128_GCM_SHA256 

On Mon, 2021-12-06 at 15:06 +, Michael Wojcik wrote:
> > From: Dr. Matthias St. Pierre 
> > Sent: Monday, 6 December, 2021 07:53
> > To: Michael Wojcik ; openssl-
> > 
> > 
> > > "Comparable elegant" is underspecified.
> > 
> > (I guess, "Comparably elegant" would have been grammatically more
> > correct.)
> 
> I just meant that elegance is in the eye of the beholder.
> 
> Many people might agree that having a single command line return the
> list of what suites the server supports is elegant, at least for the
> user. Others prefer the original UNIX philosophy of simpler tools
> which are scripted to perform more complex operations; that's the
> testssl.sh approach, and it's more elegant in the sense of being
> composed in a visible (and modifiable) way from smaller pieces.
> 
> A command-line option to s_client to do this sort of server profiling
> is conceivable, but it would be a significant departure from what
> s_client does now, since it would conflict with some other options
> and would involve making multiple connections. That doesn't mean it
> shouldn't be implemented, necessarily, just that it's not parallel to
> most of the other things s_client options do.
> 
> -- 
> Michael Wojcik

Forthcoming OpenSSL Releases

[Matt Caswell]

The OpenSSL project team would like to announce the forthcoming
release of OpenSSL versions 1.1.1m and 3.0.1.

These releases will be made available on Tuesday 14th December 2021
between 1300-1700 UTC.

OpenSSL 3.0.1 is a security and bug fix release. The highest severity 
issue fixed in this release is MODERATE:

https://www.openssl.org/policies/secpolicy.html#moderate

OpenSSL 1.1.1m is a bug fix release. There are no security issues 
addressed in this release.


Yours

The OpenSSL Project Team


OpenPGP_0xD9C4D26D0E604491.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Question About OpenSSL 3.0, FIPS and Solaris Support

[David Dillard via openssl-users]

Hi,

I'm hoping someone can shed some light on something that's confusing me.  In 
the blog post about the FIPS 
submission
 it states that one of the platforms that's being tested is "Oracle Solaris 
11.4 on Oracle SPARC M8-1".  However, on the platform policy 
page it lists a number of 
Solaris platforms, all of which are currently "unadopted".  How should people 
interpret that?  That the initial release of OpenSSL 3.0 was supported on 
Solaris, but no releases after that are?  Or something else?


Thanks,

David

Re: Enumerating TLS protocol versions and ciphers supported by the peer

[Hubert Kario]

On Monday, 6 December 2021 15:52:30 CET, Dr. Matthias St. Pierre wrote:



"Comparable elegant" is underspecified.


(I guess, "Comparably elegant" would have been grammatically more correct.)

Perhaps try testssl.sh (https://testssl.sh/)? It has various 
options for reducing the number and types of tests it runs. 
We've used it for

profiling internal TLS-enabled servers.


My question was mainly for educational purpose (since the 
'nmap' tool already satisfies my needs), but I wanted to know 
whether the openssl tool
can do same thing with a comparable effort. By this I mean a 
simple shell one-liner (or failing that just a few lines of 
shell script) utilizing `openssl s_client`.

Thanks for the weblink nevertheless.


No, it can't.

As what's necessary is to connect to server, note the used cipher,
exclude that cipher from ClientHello and see what is the next cipher that
server selects, repeat until connection rejected.
That's not simple to do in bash (for a way to do it look at 
mozilla/cipherscan)


The big problem is that this approach works only for ciphers supported and
enabled in openssl. If a cipher is unsupported by openssl, it will not be
detected as enabled on server side.
Given that there is no version of openssl that simultaneously supports 
SSLv2

and TLS 1.3, you can't reliably test arbitrary servers using openssl, even
if the server uses openssl too.

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

Re: OpenSSL 1.1 on OSX

[Grahame Grieve]

So I did end up statically binding openSSL into my application - thanks for
the suggestion.

Still, it seems to me that a note in the install/build instructions under
macos saying that the default dylibs are not compatible with the rules for
hardened applications would be a nice thing for developers like me, who
have no idea about all this stuff.

Grahame


On Sat, Dec 4, 2021 at 12:02 AM Jakob Bohm via openssl-users <
openssl-users@openssl.org> wrote:

> Which is indeed what I do in our notarized MacOsX and iOS applications.
> However to do so, I have historically needed to clean up OpenSSL source
> code to actually behave as a proper static library where only used
> functions are linked in.  Most notably, the source files named xxx_lib.c
> tend to cause the opposite behavior by bundling used and unused code
> into a single .o file, so I had to do thematic splitting of those source
> files, to not only avoid the unused functions getting linked in, but
> also the unused .o files referenced by those unused functions.  This
> problem is fully cross platform, although some more detail work had to
> be done to ensure compatibility of certain source files with XCode
> bundled tool chains (In particular the optimized assembler files).
>
> On 2021-11-20 07:47, Dr Paul Dale wrote:
> > An alternative would be to statically link libssl and libcrypto.  No
> > more dependencies.
> >
> >
> > Pauli
> >
> > On 20/11/21 3:48 pm, Viktor Dukhovni wrote:
> >> On Sat, Nov 20, 2021 at 01:38:39PM +1100, Grahame Grieve wrote:
> >>
> >>> I agree it's sure not a core openSSL issue. But surely lots of people
> >>> want to use openSSL in cross platform apps and openSSL is interested
> >>> in adoption issues?
> >> Most of the users here are building applications that are not notarised,
> >> and so work with the upstream builds.
> >>
> >>> Anyway, it looks like I now have to figure out how to maintain a
> >>> custom build of openSSL :-(
> >> It shouldn't be too difficult to execute the build, once you've figured
> >> out the actual requirements.  Apparently you need to make sure that
> >> signed code has very explicit dependencies, which makes some sense, so
> >> the libraries bundled with the application need to be built in a way
> >> that can be verified along with the application.
> >>
> >> My best guess is that Apple are not specifically picking on OpenSSL
> >> here, and similar issues would arise with any other libraries you'd
> >> want to package with your application.  Good luck.
> >>
> >> Feel free to share your findings.  Perhaps someone will then help
> >> you find a way to improve on them, or to add a template to the
> >> build to support this going forward...
> >>
> >
> 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
>
>

-- 
-
http://www.healthintersections.com.au / grah...@healthintersections.com.au
/ +61 411 867 065
Benson & Grieve:   Principles of Health Interoperability (Health
Information Technology Standards), 4th ed -
http://www.springer.com/978-3-030-56882-5