Re: [External] : Re: BIO_read() crash

[Benjamin Kaduk via openssl-users]

On Mon, Dec 05, 2022 at 11:31:18AM -0800, Thomas Dwyer III wrote:
> Why does EVP_get_digestbyname("md4") return non-NULL if the legacy provider
> isn't loaded? Similarly, why does it return non-NULL for "md5" after doing
> EVP_set_default_properties(NULL, "fips=yes")? This seems unintuitive. Legacy
> code that does not know about EVP_MD_fetch() checks the return value of
> EVP_get_digestbyname(). Isn't that where the error should be detected? Why
> let it get all the way to BIO_set_md() (or EVP_DigestInit() or whatever)
> before the error is detected?

To do so would introduce a time-of-check/time-of-use race, as the set of
providers available may change in the intervening period.

-Ben

Re: TLS 1.3 Early data

[Benjamin Kaduk via openssl-users]

On Sat, Nov 05, 2022 at 11:50:18AM +0100, Dirk Menstermann wrote:
> Hello,
> 
> I did few experiments with early data but was not successful in solving my
> exotic use case: "Using early data dependent on the SNI"
> 
> I control the server (linux, supports http2) based on OpenSSL 111q and use a
> recent firefox as client:
> 
> 1) Setting SSL_CTX_set_max_early_data in the SSL_CTX* works (FF sends early 
> data)
> 2) Setting SSL_set_max_early_data on the just created SSL* works (FF sends 
> early
> data)
> 3) Setting SSL_set_max_early_data in the SNI callback during the handshake 
> does
> not work (FF does not send early data)
> 
> I guess there is a dirty way to "peek" into the client hello and parse it
> without OpenSSL, extracting the SNI and make it then like in 2), but I wonder 
> if
> there is a better way.
> 
> Any idea?

The SNI callback runs far too late for this purpose (and, to be honest, a lot of
other purposes).  You should be able to use the client_hello callback for it,
though 
(https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_client_hello_cb.html).

Note that SSL_get_servername() does not provide something useful within the
client hello callback execution and you'll have to do something like
https://github.com/openssl/openssl/blob/master/test/helpers/handshake.c#L146-L198
in order to access the provided SNI value from the client.

-Ben

Re: Query reg. using certificates bigger than 4k for EAP-TLS

[Benjamin Kaduk via openssl-users]

I'm also a bit confused at how this became the limiting factor for the 
application
in question.

https://datatracker.ietf.org/doc/html/draft-ietf-emu-eaptlscert-08 has some
discussion of how large certificates can cause issues for EAP (as well as some
guidance to EAP deployments as to how to reduce the scale of the issues), which
suggests that most of the time there is already some buffering going on at
a 1-2k chunk size just based on the limits of the EAP exchange's MTU.  (The
parties in the exchange have to transmit one chunk at a time and get an ACK
back before transmitting the next chunk, and once that handshake flight is
finished the process is reversed with the other party sending a chunk at a 
time.)
A BIO-layer buffer would be between that and the libssl handshake buffering,
and as you describe, it should still get the data through, just maybe with
a slight inefficiency.

-Ben

On Wed, Oct 20, 2021 at 02:30:19PM +0100, Matt Caswell wrote:
> Your scenario is still not quite clear to me.
> 
> It sounds like you are using a BIO_f_buffer() BIO to buffer data. This is on
> the server side right? Are you encountering this problem for server writes?
> Since you are talking about the certificate chain, I assume you are
> referring to the server writing that chain.
> 
> libssl itself also uses a BIO_f_buffer() internally for writes during the
> handshake. It's not clear to me whether you are referring to the internal
> libssl buffering BIO, or one that you have created?
> 
> Either way, the effect of the buffering BIO during writes is that a 4k
> buffer is used by default. If data is written that is less than 4k in length
> then it is held in the buffer until either the BIO is "flushed" or the
> buffer is filled. In the event the buffer gets filled then it is
> automatically flushed, and any remaining data gets buffered.
> 
> The only effect of changing the buffer size should be to decrease the
> frequency that the buffer gets filled and automatic flushes occur. It sounds
> like by trying to increase the buffer size you are seeking to avoid "parial"
> writes where only part of the data is flushed and the remainder is held back
> for sending later when the buffer is next filled or flushed. This should not
> normally make any difference to the correct operation of the protocol
> (except for efficiency) although it does depend on what happens "downstream"
> of the buffering bio and how partial writes get sent to the peer.
> 
> It sounds like things are not quite working correctly for you when "partial"
> writes occur. This sounds like a potential problem in the BIO chain
> downstream of libssl (i.e. in your application).
> 
> Matt
> 
> On 20/10/2021 12:34, Vishal Sinha wrote:
> > Hi Matt
> > 
> > The certificate is not large as such. But since it's a chain, the
> > overall size crosses 4k. We used BIO_set_write_buffer_size() API to
> > increase the size from 4k to 8k of the BIO buffer in SSL context.
> > 
> > Regards
> > Vishal
> > 
> > 
> > On Wed, Oct 20, 2021 at 3:26 PM Vishal Sinha  > > wrote:
> > 
> > Hi
> > 
> > We are using openssl 1.1.1c version on our client and server. Client
> > and Server are doing EAP-TLS authentication using certificates which
> > are more than 4k in size (using 1 root CA and 2 intermediate CAs).
> > We noticed that the server is not able to handle it gracefully due
> > to insufficient buffer size during SSL handshake and hence
> > authentication fails. To solve this issue, we increased the buffer
> > size to 8k programmatically and authentication passed. Is there any
> > other way to solve this problem?
> > 
> > Regards
> > Vishal
> > 

Re: Will TLSv1.3 always send session ticket?

[Benjamin Kaduk via openssl-users]

On Thu, Sep 16, 2021 at 12:40:55PM -0400, Viktor Dukhovni wrote:
> On Thu, Sep 16, 2021 at 09:30:18AM -0700, Benjamin Kaduk via openssl-users 
> wrote:
> > On Thu, Sep 16, 2021 at 12:20:05PM -0400, Viktor Dukhovni wrote:
> > > 
> > > I don't recall whether OpenSSL makes any effort to or supports deferring
> > > the transmission of session tickets until just before the first
> > > application data transmission from server to client (or else perhaps
> > > just before responding to a received close-notify with a reciprocal
> > > close-notify)
> > 
> > It's not the default behavior, but is supported: you can configure the
> > SSL/SSL_CTX to send zero tickets by default and then manually call
> > SSL_new_session_ticket(), which defers the transmission until there is 
> > another
> > write or explicit SSL_do_handshake() call.
> 
> So nothing built-in...  What I had in mind was a built-in behaviour of
> the library to delay session ticket transmission until there's a first
> opportunity to send some application data, which the client application
> can be reasonably expected to read at that point.

While I'm not opposed to having some turnkey solution built in, I do think
that the current default of sending tickets immediately after the handshake
is the correct *default* behavior.  That makes the new session (with ticket
and resumption capability) available to clients right after the handshake,
instead of needing to wait until some actual data from the server arrives.

I'd be interested in hearing your thoughts about what an API/config would look
like to enable the delayed-send behavior.


-Ben

Re: Will TLSv1.3 always send session ticket?

[Benjamin Kaduk via openssl-users]

On Thu, Sep 16, 2021 at 12:20:05PM -0400, Viktor Dukhovni wrote:
> 
> I don't recall whether OpenSSL makes any effort to or supports deferring
> the transmission of session tickets until just before the first
> application data transmission from server to client (or else perhaps
> just before responding to a received close-notify with a reciprocal
> close-notify)

It's not the default behavior, but is supported: you can configure the
SSL/SSL_CTX to send zero tickets by default and then manually call
SSL_new_session_ticket(), which defers the transmission until there is another
write or explicit SSL_do_handshake() call.

-Ben

Re: Getting SSL_SESSION remaining lifetime

[Benjamin Kaduk via openssl-users]

On Thu, Sep 16, 2021 at 04:57:03PM +0200, Hubert Kario wrote:
> On Thursday, 16 September 2021 16:28:47 CEST, Benjamin Kaduk wrote:
> > On Thu, Sep 16, 2021 at 04:11:49PM +0200, Hubert Kario wrote:
> > > On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote:
> > > > 
> > > > I am trying to get the remaining lifetime of the ticket so that server
> > > > can decide to renew ticket or not
> > > 
> > > TLS 1.3 tickets are single use. If the ticket was used by a client, and
> > > you expect it to make a connection in the future, server needs to
> > > send a new
> > > one.
> > 
> > Single-use tickets are only a protocol requirement when 0-RTT data is used.
> > The OpenSSL implementation even allows the libssl-internal enforcement of
> > single-use to be disabled (see SSL_OP_NO_ANTI_REPLAY at
> > https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html__;!!GjvTz_vk!GxR4URFTB0lwkM5nlYZdtn3DUdeaujsu1sHMYc_nRTUpkmLQP8-zz_b4HS_rcA$
> >  ).
> > OpenSSL as a client also has some measures to encourate single-use tickets,
> > which I have a PR open to provide a knob to disable:
> > https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/16598__;!!GjvTz_vk!GxR4URFTB0lwkM5nlYZdtn3DUdeaujsu1sHMYc_nRTUpkmLQP8-zz_YPrcg6yw$
> >   .
> 
> They're single use not only because of replay but also because of privacy
> reasons, as reuse of a ticket indicates that the same client did send it.

Yes.
But the protocol itself only encourages single-use for privacy reasons.
The protocol does not *require* single-use in that case.

-Ben

Re: Getting SSL_SESSION remaining lifetime

[Benjamin Kaduk via openssl-users]

On Thu, Sep 16, 2021 at 04:11:49PM +0200, Hubert Kario wrote:
> On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote:
> > 
> > I am trying to get the remaining lifetime of the ticket so that server
> > can decide to renew ticket or not
> 
> TLS 1.3 tickets are single use. If the ticket was used by a client, and
> you expect it to make a connection in the future, server needs to send a new
> one.

Single-use tickets are only a protocol requirement when 0-RTT data is used.
The OpenSSL implementation even allows the libssl-internal enforcement of
single-use to be disabled (see SSL_OP_NO_ANTI_REPLAY at
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html).
OpenSSL as a client also has some measures to encourate single-use tickets,
which I have a PR open to provide a knob to disable:
https://github.com/openssl/openssl/pull/16598 .

-Ben

Re: OpenSSL 3.0.0 two tests fail on Solaris 10 SPARC64 ( Oracle/Fujitsu )

[Benjamin Kaduk via openssl-users]

On Sat, Sep 11, 2021 at 10:29:07PM -0400, Dennis Clarke via openssl-users wrote:
> 
> This is slightly better than the beta release :
> 
> Test Summary Report
> ---
> 03-test_internal_modes.t (Wstat: 256 Tests: 1 Failed: 1)
>   Failed test:  1
>   Non-zero exit status: 1
> 90-test_ige.t(Wstat: 256 Tests: 1 Failed: 1)
>   Failed test:  1
>   Non-zero exit status: 1
> 
> 
> What can I dig into here to get more information and perhaps we solve
> these two little tests fails?

`make V=1 TESTS="test_internal_modes test_ige" test`

-Ben

Re: Congratulations! Missing 3.0.0 tag?

[Benjamin Kaduk via openssl-users]

On Thu, Sep 09, 2021 at 01:03:28AM +0200, Steffen Nurpmeso wrote:
> But if i use
> 
>   #?0|kent:tls-openssl.git$ alias gl1
>   alias gl1='git slpn -1'
>   #?0|kent:tls-openssl.git$ git alias|grep slpn
>   alias.slpn log --show-signature --patch --find-renames --stat 
> --no-abbrev-commit
>   #?0|kent:tls-openssl.git$ gl1 openssl-3.0.0
>   commit 89cd17a031e022211684eb7eb41190cf1910f9fa (tag: 
> refs/tags/openssl-3.0.0)
>   ...
> 
> i do not.  Hm, maybe i need to relearn git again, looking around
> i see a couple of projects for which this is true (Linux,
> wireguard-tools), for others it is not (my own project, nghttp2).
> Eg "alias.slo log --show-signature --oneline --graph":

I think (off the top of my head, i.e., without consulting a reference)
that `git log` (which your aliases end up at) will only display
signatures on commits, but will not show the tag objects themselves.
`git show` does display the tag object, and for openssl only the tag
object is what is signed; the commits themselves are not signed.

-Ben

Re: Congratulations! Missing 3.0.0 tag?

[Benjamin Kaduk via openssl-users]

On Thu, Sep 09, 2021 at 12:15:44AM +0200, Steffen Nurpmeso wrote:
> 
> P.S.: maybe at least release commits and tags could be signed?
> And/or HTTPS access to the repository ... but then i get the gut
> feeling that the answer to this will be "use github" or something.

tag openssl-3.0.0
Tagger: Richard Levitte 
Date:   Tue Sep 7 13:46:40 2021 +0200

OpenSSL 3.0.0 release tag
-BEGIN PGP SIGNATURE-

iFwEABECAB0WIQTEyrdJw09/TMBP2smnr5549wlFOwUCYTdRIAAKCRCnr5549wlF
O7wEAJ90wRuQnQYdf7RrzD7p2tf2eZhP4QCXeXX3a1IgbIgfU7WuLZ44BbXF7w==
=pGf9
-END PGP SIGNATURE-

looks signed to me.

-Ben

Re: client authentication status

[Benjamin Kaduk via openssl-users]

On Wed, Sep 01, 2021 at 03:36:36PM +, Zeke Evans wrote:
> Hi,
> 
> Is there any way to check the status of client authentication sent in a TLS 
> 1.3 handshake after SSL_connect returns?  With TLS 1.2 SSL_connect seems to 
> always capture the status and return an error code if it failed but not TLS 
> 1.3.  I haven't been able to find a good way to do this after SSL_connect 
> returns.  I have to handle blocking and non-blocking sockets so calling 
> SSL_read or SSL_peek isn't an option since those could block.  If client 
> authentication happened to fail then calling those methods would work because 
> they will return an error but if it didn't fail then they could block.

Note that the server is allowed to ignore a client cert that it doesn't like, 
proceeding with the connection as if the client was unauthenticated.  If you 
need a specific signal that the server believes the client successfully 
authenticated, that has to be at the application layer.

Did you try a zero-length SSL_read()?  My recollection is that that gets far 
enough into the library to see if there are pending alert messages to process.

-Ben

Re: Can OpenSSL handle multiple authentication mechanisms on the same SSL context?

[Benjamin Kaduk via openssl-users]

On Tue, Jun 22, 2021 at 04:18:25AM +, Revestual, Raffy [AUTOSOL/PSS/MNL] 
wrote:
> Also asked this question in stackoverflow.com
> 
> https://urldefense.com/v3/__https://stackoverflow.com/questions/68077419/can-openssl-handle-multiple-authentication-mechanisms-on-the-same-ssl-context__;!!GjvTz_vk!DeBGhsJS1c6OIusGcUpz3NpRsG2S3kReo2omn1ch1-B6mJ1ZvmGuj5awlkmShw$
>  
> 
> We are trying to support a server that would support PSK and SRP 
> authentication mechanisms. However, when we run to try to run callbacks for 
> both on the same context, only the PSK callbacks are being detected:
> 
> SSL_CTX_set_psk_server_callback(m_ctx, psk_out_of_bound_serv_cb);
> 
> SSL_CTX_set_srp_username_callback(m_ctx, srp_server_param_cb);
> 
> SRP and PSK works currently in our code if you only set one callback or the 
> other. I tried to register SRP first but doing this didn't change the fact 
> the only PSK was working. So an alternative would be to set these 
> individually on the SSL context. I have also confirmed that SRP and PSK 
> cipher suites when combined when being set is a non-issue.
> 
> Would multiple callbacks for different mechanisms work simultaneously on the 
> same SSL context?

The situation is somewhat different between TLS 1.3 and prior versions (e.g., 
TLS 1.2).
Since there isn't currently a defined SRP option for TLS 1.3, I assume you are 
targeting TLS 1.2

I think you need to say more about your testing -- whether SRP or PSK is being 
attempted
for TLS 1.2 is at the control of the client, as the ClientKeyExchange protocol 
message will
have a different structure for using SRP vs using PSK.  If your client is never 
trying
SRP, then of course your SRP callback will never be called.

So, how are you testing the various scenarios?

-Ben

Re: 3.0 beta1 feedback about (shared) library names

[Benjamin Kaduk via openssl-users]

On Mon, Jun 21, 2021 at 10:23:06PM -0400, Michael Richardson wrote:
> 
> I downloaded and compiled opensssl 3.0.0-beta1 from git today.
> I installed into a private prefix.
> 
> While my debian desktop system has:
> 
> %ls -l /usr/lib/x86_64-linux-gnu/libssl*
> -rw-r--r-- 1 root root  357056 Jul  8  2020 
> /usr/lib/x86_64-linux-gnu/libssl3.so
> -rw-r--r-- 1 root root 1000534 Feb 16 17:08 /usr/lib/x86_64-linux-gnu/libssl.a
> lrwxrwxrwx 1 root root  13 Feb 16 17:08 
> /usr/lib/x86_64-linux-gnu/libssl.so -> libssl.so.1.1
> -rw-r--r-- 1 root root  435704 Jul  4  2017 
> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
> -rw-r--r-- 1 root root  431232 Dec 23  2019 
> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
> -rw-r--r-- 1 root root  593696 Feb 16 17:08 
> /usr/lib/x86_64-linux-gnu/libssl.so.1.1
> 
> %ls -l /usr/lib/x86_64-linux-gnu/libcrypto*
> -rw-r--r-- 1 root root 5399144 Feb 16 17:08 
> /usr/lib/x86_64-linux-gnu/libcrypto.a
> lrwxrwxrwx 1 root root  16 Feb 16 17:08 
> /usr/lib/x86_64-linux-gnu/libcrypto.so -> libcrypto.so.1.1
> -rw-r--r-- 1 root root 2494464 Jul  4  2017 
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> -rw-r--r-- 1 root root 2504576 Dec 23  2019 
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2
> -rw-r--r-- 1 root root 3031904 Feb 16 17:08 
> /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
> 
> WTF is libssl3.so?  I still don't know, but:
> 
> %dpkg -S /usr/lib/x86_64-linux-gnu/libssl3.so
> libnss3:amd64: /usr/lib/x86_64-linux-gnu/libssl3.so
> something up there that should be concerning, because maybe it will cause 
> confusion.

NSS is the mozilla TLS stack, used by firefox/etc.

> My newly installed openssl 3 has:
> 
> %ls -l /sandel/3rd/openssl3/lib
> total 16188
> drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 engines-3/
> -rw-r--r-- 1 mcr mcr 9307420 Jun 21 21:29 libcrypto.a
> lrwxrwxrwx 1 mcr mcr  14 Jun 21 21:29 libcrypto.so -> libcrypto.so.3*
> -rwxr-xr-x 1 mcr mcr 5205856 Jun 21 21:29 libcrypto.so.3*
> -rw-r--r-- 1 mcr mcr 1251782 Jun 21 21:29 libssl.a
> lrwxrwxrwx 1 mcr mcr  11 Jun 21 21:29 libssl.so -> libssl.so.3*
> -rwxr-xr-x 1 mcr mcr  794496 Jun 21 21:29 libssl.so.3*
> drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 ossl-modules/
> drwxr-xr-x 2 mcr mcr4096 Jun 21 21:29 pkgconfig/
> 
> So I see that the versioned .so file will be somewhat related to the version.
> Distros will be able to ship openssl1.x and openssl3.x shared libraries at
> the same time.
> 
> But, having both "libssl-dev" and "libssl3-dev" installed at the same time is
> going to be a problem.

This is typically solved at the distro layer, not by "upstream" ... often by
just saying you only get to have one installed at a time, and making you swap
back and forth.

Other times the packages will create "-multidev" libraries that install into
a subdirectory, e.g., krb5-multidev installs into /usr/lib/{triple}/mit-krb5
and there's a libkrb5-dev that makes symlinks from the parent directory.

-Ben

> I think that the differences in ABI may be significant enough that you should
> consider calling it "libssl3" and "libcrypto3".  Yeah, maybe that's uncool,
> but it may be pragmatic.
> 
> {ps: I am working on the ruby openssl library next to see what happens}
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 

Re: Symbols X509_set_notAfter and X509_set_notBefore are missing

[Benjamin Kaduk via openssl-users]

They are macros now.  You should still be able to build code that uses them.

-Ben

On Fri, Apr 09, 2021 at 08:03:28PM +, Robert Smith via openssl-users wrote:
> Hello,
> I am porting application from openSSL version 1.0.2u to 1.1.1k and linker 
> complaints that symbols X509_set_notAfter and X509_set_notBefore are missing.
> 
> I've checked both versions 1.0.2u and 1.1.1k and I see that these symbols 
> really are not present in 1.1.1k. 
> user@ubuntu_dev_vm:~/tools/openssl$ nm -D --defined-only 
> 1.0.2u/lib/libcrypto.so.1.0.0 | grep X509_set_not00110994 T 
> X509_set_notAfter001109fc T X509_set_notBefore 
> user@ubuntu_dev_vm:~/tools/openssl$ nm -D --defined-only 
> 1.1.1k/libcrypto.so.1.1 | grep X509_set_not 
> user@ubuntu_dev_vm:~/tools/openssl$ 
> I use default builds with NO limiting defines OPENSSL_API_COMPAT as described 
> in the wiki : 
> https://urldefense.com/v3/__https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes__;!!GjvTz_vk!BsiPUDmweh0jSUO9gmeu60lRgq1aIS7FPk1Q6SJsI7kns9h5ZO64IagBa0aJZA$
>  
> 
> Can anyone clarify how to resolve the issue with X509_set_notAfter and 
> X509_set_notBefore symbols.
> 
> ThanksRobert

Re: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string

[Benjamin Kaduk via openssl-users]

On Tue, Mar 09, 2021 at 02:44:20AM +, Stephen Farrell wrote:
> 
> Hiya,
> 
> On 08/03/2021 02:37, Benjamin Kaduk wrote:
> > Hi Stephen :)
> > 
> > The API you'll want to use is EVP_PKEY_fromdata(); there's
> > a stubbed out example of using it to make an EVP_PKEY with
> > EC group parameters at
> > https://github.com/openssl/openssl/issues/14258#issuecomment-783351031
> > but the translation to also specify OSSL_PKEY_PARAM_PRIV_KEY
> > (and possibly OSSL_PKEY_PARAM_PUB_KEY; I forget if you need
> > to pass both) should be fairly straightforward.
> 
> Thanks for that! I worked around a few things and still need
> to tidy-up but got things working that way without any more
> deprecation warnings.
> 
> > 
> > Let us know if you run into trouble with that route.
> 
> One outstanding issue is that I still need different code
> paths for NIST curves vs. 25519 & 448 - is that just me
> (quite likely:-) or should these new APIs hide differences
> between those different curves?

I would have expected that the API should hide the differences
other than the group name ... but these APIs are still pretty
new to me, too.  If you can point me at your code I might have
more to say.


-Ben

Re: OpenSSL 3.0.0 APIs for creating an EVP_PKEY from a p256 private key octet string

[Benjamin Kaduk via openssl-users]

Hi Stephen :)

The API you'll want to use is EVP_PKEY_fromdata(); there's
a stubbed out example of using it to make an EVP_PKEY with
EC group parameters at
https://github.com/openssl/openssl/issues/14258#issuecomment-783351031
but the translation to also specify OSSL_PKEY_PARAM_PRIV_KEY
(and possibly OSSL_PKEY_PARAM_PUB_KEY; I forget if you need
to pass both) should be fairly straightforward.

Let us know if you run into trouble with that route.

-Ben

On Mon, Mar 08, 2021 at 02:23:36AM +, Stephen Farrell wrote:
> 
> Hiya,
> 
> My question: how does one setup an EVP_PKEY for a NIST
> curve (e.g. p256) key pair when one has the private key
> in an octet string using the latest OpenSSL 3.0.0 high
> level APIs?
> 
> I'm trying to get rid of deprecation warnings from my
> code for HPKE [1] when dealing with NIST curves using
> the new (I guess?) OSSL_PARAM_* approach. I'm failing
> at the moment;-)
> 
> So, given an octet string from a set of test vectors
> (e.g. [2]) what's the proper way to setup an EVP_PKEY
> for that to allow one to validate the test vectors?
> 
> Happy to try produce a stand-alone example for this
> in the next few days if one doesn't exist (I've not
> found one so far).
> 
> Thanks,
> Stephen.
> 
> [1] 
> https://github.com/sftcd/happykey/blob/7d52d34c516ab58ca1433004ff82b2a6a82eea4c/hpke.c#L1263
> [2] https://github.com/cfrg/draft-irtf-cfrg-hpke

pub   RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) 

> sub   RSA 4096/36CB8BB6 2017-12-22
> 

Re: PEM file line size

[Benjamin Kaduk via openssl-users]

On Thu, Feb 25, 2021 at 03:30:43PM -0800, Frank Liu wrote:
> Looking at test cases
> https://urldefense.com/v3/__https://github.com/openssl/openssl/blob/OpenSSL_1_1_1-stable/test/recipes/04-test_pem.t__;!!GjvTz_vk!A42D2c2brOwptas6T1iBt9i7pMWhwehkKAmeCuILgR-6iv5n0TQPQ6tkkVgG9A$
>  
> , openssl indeed is a parser that can handle other line sizes than 64
> chars. If we were to strictly follow RFC, shouldn't we error out none 64
> line size (except last line which could be equal or less than 64)? Leaving
> it "undefined behavior" would invite issues.

If you read RFC 1421 carefully (the ABNF, and the first line of Section
4.3.2.4), the 64 characters per line limitation only applies for encrypted (or
MIC-ONLY) messages.  Other messages can use arbitrary length lines for base64
content.

-Ben

Re: ASN.1 encoding error

[Benjamin Kaduk via openssl-users]

That sounds like the certificate is encoded using ASN.1 BER rules, that openssl
accepts, but the python library is insisting on DER encoding (per the spec).

-Ben

On Thu, Feb 25, 2021 at 05:19:32PM +, John Robson via openssl-users wrote:
> Hi all,
> 
> I'm encountering an error connecting to a device which as far as I can see
> has a reasonable certificate...
> 
> The error coming back (through twisted and python) is:
> 
> > twisted.python.failure.Failure OpenSSL.SSL.Error: [('asn1 encoding
> > routines', 'c2i_ibuf', 'illegal padding'), ('asn1 encoding routines',
> > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('asn1 encoding routines',
> > 'asn1_template_noexp_d2i', 'nested asn1 error'), ('SSL routines',
> > 'tls_process_server_certificate', 'ASN1 lib')]
> 
> 
> However if I run the following:
> # openssl s_client -connect : /dev/null | openssl
> x509 | openssl asn1parse
> 0:d=0  hl=4 l= 733 cons: SEQUENCE
> 4:d=1  hl=4 l= 453 cons: SEQUENCE
> 8:d=2  hl=2 l=   3 cons: cont [ 0 ]
>10:d=3  hl=2 l=   1 prim: INTEGER   :02
>13:d=2  hl=2 l=   4 prim: INTEGER   :00
>19:d=2  hl=2 l=  13 cons: SEQUENCE
>21:d=3  hl=2 l=   9 prim: OBJECT:sha256WithRSAEncryption
>... (continues)
> 
> ...then OpenSSL seems to handle the whole certificate without problem, the
> thing that looks "off" to me is the serial number being defined as
> "00", rather than "00" (which I see on the self signed certificates
> from other devices of this type).
> 
> Is that likely to be causing the issue?  It's ~20 years since I last had to
> deal with ASN.1 properly, so I can't remember if using unnecessarily long
> representations of integers is actually valid.
> 
> The raw ASN.1 looks ok I *think* (although I note that it has four bytes
> specified) "02 04 00 00 00 00"
> 
> 
> I'm at the point where I might just try to get it to generate a new
> certificate and see if it does that with a single byte zero (as per the
> other similar device I've been looking at)
> 
> Am I completely barking up the wrong tree, is there something else that I
> can use other than the asn1parse option to figure out where the error might
> be coming from?
> 
> Cheers,
> 
> John
> 
> -- 
> 
> *John Robson*

Re: Parsing and generating CBOR certificates?

[Benjamin Kaduk via openssl-users]

And again, where do you believe such a conversion is specified?
The IETF internet-draft I reference is a way to do so, but it is (to repeat)
very much a work in progress.

-Ben

On Thu, Jan 21, 2021 at 12:35:24AM +, Blumenthal, Uri - 0553 - MITLL wrote:
> I meant not "CBOR protocol" (which,  in all likelihood, doesn't and shouldn't 
> exist) but CBOR encoding of X.509 certificates (which, hopefully, does 
> exists).
> 
> At least, I'm looking for a tool that would convert between these two 
> encodings (DER and CBOR) for specific objects (X.509-conformant certificates).
> 
> Thanks
> 
> Regards,
> Uri
> 
> > On Jan 20, 2021, at 19:26, Kaduk, Ben  wrote:
> > 
> > No.  OpenSSL does not include any CBOR protocol support.
> > I'm also not sure what you mean by "CBOR-encoded certificate"; I don't
> > know of any such thing other than
> > https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/
> > which is very much still a work in progress.
> > 
> > -Ben
> > 
> > 
> > From: Blumenthal, Uri - 0553 - MITLL 
> > Sent: Wednesday, January 20, 2021 4:22 PM
> > To: openssl-users
> > Subject: Parsing and generating CBOR certificates?
> > 
> > I need to work with CBOR-encoded certificates. Is there any way to use 
> > OpenSSL to parse and/or generate certs in CBOR encoding?
> > 
> > Thanks
> > 
> > Regards,
> > Uri

Re: Fwd: channel binding

[Benjamin Kaduk via openssl-users]

On Mon, Jan 11, 2021 at 10:31:01PM +, Jeremy Harris wrote:
> On 11/01/2021 22:07, Benjamin Kaduk wrote:
> > > Looking at the implementation, SSL_export_keying_material() only
> > > functions for TLS 1.3 .  This is not documented.  Is this a bug?
> > Are you looking at SSL_export_keying_material() or 
> > SSL_export_keying_material_early()?
> 
> Doh.  I was looking at the wrong routine; thanks.
> But, per below, now moot.
> 
> > If you need to interwork with other implementations/an existing protocol,
> > you have to stick with the Finished-based channel bindings; the exporter
> > interface is a new protocol mechanism and the whole protocol/ecosystem has
> > to be expecting to use it.
> 
> Right. So we have implementations out there using it; will the OpenSSL
> project consider promoting it to supported status so that it doesn't
> disappear in some future release?

I think you should treat them as if they are supported interfaces.
They're present in the list of "things that aren't documented but should be",
and do have some documentation-ish commentary in the public header file.

Any API change or removal would be against our support policy (and patches
to add man pages for them would also be welcome).

> > With TLS 1.2 and extended master secret this is not known to be broken (and
> > yes, that is a very carefully phrased statement).
> 
> Understood :)   Like all crypto...

Yes ... though some we are more confident in than others :)

-Ben

Re: Fwd: channel binding

[Benjamin Kaduk via openssl-users]

On Mon, Jan 11, 2021 at 09:26:30PM +, Jeremy Harris wrote:
> On 11/01/2021 08:20, Benjamin Kaduk wrote:
> > Current recommendations are not to use the finished message as the channel
> > binding but instead to define key exporter label for the given usage
> > (see 
> > https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8446*section-7.5__;Iw!!GjvTz_vk!B3BtBNIxiZ3RH6J7rY957VPTQl8bbpbD0JFcnI7yROvCOorpGCJtgFcao40Dug$
> >  ), using SSL_export_keying_material().


> Looking at the implementation, SSL_export_keying_material() only
> functions for TLS 1.3 .  This is not documented.  Is this a bug?

Are you looking at SSL_export_keying_material() or 
SSL_export_keying_material_early()?
For the latter, the man page says:

% SSL_export_keying_material_early() is only usable with TLSv1.3, and derives
% keying material using the F (as defined in the
% TLS 1.3 RFC).

I did try to check that the implementation was available for TLS 1.0 before
recommending it, but only halfheartedly.

> "Only defined for TLS 1.0 and above" says the docs; I can live
> with that.   But if 1.2 doesn't working with it, will SSL_get_finished()
> do so  (I an enforcing Extended-Master-Secret or not-Resumption) ?

> Follow-on question on SSL_export_keying_material() -
> what "label" should I supply?
> 
> I need to interwork with other implementations that are using
> SSL_get_finished() (client side) / SSL_get_peer_finished() (server side).
> Does that imply I should use "client finished"
> (per
> https://urldefense.com/v3/__https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml*exporter-labels__;Iw!!GjvTz_vk!B3BtBNIxiZ3RH6J7rY957VPTQl8bbpbD0JFcnI7yROvCOorpGCJtgFcXtzE4eg$
> )
> as the label?   Does the label length for the SSL_export_keying_material()
> call include the terminating NUL or not?

If you need to interwork with other implementations/an existing protocol,
you have to stick with the Finished-based channel bindings; the exporter
interface is a new protocol mechanism and the whole protocol/ecosystem has
to be expecting to use it.

With TLS 1.2 and extended master secret this is not known to be broken (and
yes, that is a very carefully phrased statement).

And, for completeness, you generally won't include the terminating NUL
in the label length argument, but that will be defined by the protocol spec
that defines the exporter label.

-Ben

Re: Fwd: channel binding

[Benjamin Kaduk via openssl-users]

On Sun, Jan 10, 2021 at 02:44:38PM +, Jeremy Harris wrote:
> Hi,
> 
> What is the status of SSL_get_finidhed() / SSL_get_peer_finished() ?
> 
> I do not find them documented at
>   
> https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man3/__;!!GjvTz_vk!FUYwEktTkE4ZmFeJKSFeBQe32kr0I0dcFxh_MkPMjns_JZ71rpQTYGbTm08g6w$
> 
> but they are exported by the library and seem to be required, for
> application channel-binding.

Current recommendations are not to use the finished message as the channel
binding but instead to define key exporter label for the given usage
(see https://tools.ietf.org/html/rfc8446#section-7.5), using 
SSL_export_keying_material().

-Ben

Re: Help with SSL 8152 SEC_ERROR_INVALID_KEY Intermittent Error (first post please be kind!)

[Benjamin Kaduk via openssl-users]

Hi Craig,

On Wed, Dec 09, 2020 at 08:35:46PM +0900, Craig Henry wrote:
> Hi,
> 
> This is my first post to this list so please be kind!
> 
> Environment - Linux Centos
> SSL - 1.0.2k19-el7
> 
> Connection - CURL (via PHP) with public / private key auth + http basic auth
> 
> We're having an issue where we are seeing intermittent behavior connecting
> to a 3rd party of the key being rejected with a 8152 error - "The key does
> not support the requested operation". Other times it works OK.
> 
> We have another user who is using this 3rd party and same connection type
> but not reported this issue.
> 
> Has anyone got any clue as to what might be causing this type of
> intermittent connection issue ?

As was already noted, this is not an error generated by OpenSSL.
More concretely, RFC 8152 is for CBOR Object Signing and Encryption (COSE), 
which is not really
related to TLS at all.  I suspect the error is not from NSS or CURL either but
rather from a COSE implementation.

-Ben

Re: Question about TLS 1.3 and openssl -cipher aNULL option

[Benjamin Kaduk via openssl-users]

On Thu, Sep 03, 2020 at 11:45:28PM +, Yury Mazin via openssl-users wrote:
> Hello,
> 
> We have a server was originaly using OpenSSL 1.0.2h.
> Server is configured to use SSL ciphers as following
> ALL:!aNULL:!ADH:!EDH:!eNULL:!EXPORT
> When openssl client tries to connect to this server with command
> openssl s_client -connect localhost:8101-cipher aNULL
> it fails, because any aNULL ciphers are not available per server 
> configuration.
> We have now upgraded server to use OpenSSL 1.1.1f.
> The current behavior is this:  client can connect using the same command
> openssl s_client -connect localhost:8101 -cipher aNULL
> or
> openssl s_client -tls1_3 -connect localhost:8101 -cipher aNULL
> 
> while the same connect attempt using TLS1.2 protocol would still fail
> 
> openssl s_client -tls1_2 -connect localhost:8001-cipher aNULL
> 
> Would the fact that I can connect to the server using TLS 1.3 using the 
> following command (specifically, using -cipher aNULL, while server is 
> configured to exclude all aNULL cipher suites) considered a security 
> violation?
> 
> openssl s_client -tls1_3 -connect localhost:8001 -cipher aNULL
> 
> Also, if this a security violation, how this can be addressed in the server 
> configuration?
> Lastly, if this is not a security violation, please explain.

It is not a security violation, because you are using TLS 1.3 ciphers,
and there are not any NULL-encryption TLS 1.3 ciphers.

Configuration of TLS 1.3 ciphers and ciphers for previous versions
of TLS are separate (since, at a protocol level, they serve different roles).
See the documentation for s_client/s_server -ciphersuites for more
information about TLS 1.3 ciphers.

-Ben

Re: Real MTU problems with BIO pair

[Benjamin Kaduk via openssl-users]

On Fri, Aug 21, 2020 at 05:05:51PM +0200, Detlef Vollmann wrote:
> On 2020-08-20 21:44, Detlef Vollmann wrote:
> > 
> > Is there any way to set the maximum fragment size for
> > DTLS handshake with a BIO pair?
> One solution is to set the MTU and the int_bio size to
> exactly the same value.
> Another option would be to use BIO_set_callback_ex() and send
> the data to the socket after each BIO_write() into int_bio,
> but the problem here is that BIO_set_data() cannot be used
> as the ptr is already used for the peer address.

There's always EX_DATA...

-Ben

Re: NULL ciphers

[Benjamin Kaduk via openssl-users]

On Thu, Aug 13, 2020 at 08:19:10PM +0200, Detlef Vollmann wrote:
> Hello,
> 
> with the following commands:
> 
> openssl s_server -accept 18010 -cert srv.crt -key test.key \
> -CAfile testca.crt -debug -cipher 'NULL-SHA256' -dtls1_2
> 
> openssl s_client -connect localhost:18010 -cert clnt.crt \
>  -key test.key -CAfile testca.crt -debug \
>  -cipher 'COMPLEMENTOFALL:eNULL' -dtls1_2
> 
> NULL ciphers work fine with OpenSSL 1.0.2g.
> 
> With OpenSSL 1.1.1g the handshake fails on the server side with
> 140295725053248:error:14102438:SSL routines:dtls1_read_bytes:tlsv1 \
> alert internal error:../ssl/record/rec_layer_d1.c:611:SSL alert number \
> 80
> 
> Even on OpenSSL 1.1.1g 'openssl ciphers -v  NULL' lists NULL-SHA256.
> 
> I'm only using s_server and s_client as tests, but I have the same
> problem in my application if I use
>  SSL_CTX_set_cipher_list(sslCtx, "NULL-SHA256");
> 
> What can I do to get NULL ciphers for no encryption working?

-cipher 'COMPLEMENTOFALL:eNULL@SECLEVEL=0'

Re: 'in_addr_t' in openssl 1.1.1g ??

[Benjamin Kaduk via openssl-users]

Ah, so it really is the "gcc" configure target (I had to look up that such
a thing even existed!).

Unfortunately, 'gcc' implies 32-bit, and your x86_64-fslsdk-linux suggests
that you're targetting a 64-bit system.  Such a mismatch of configurations
could easily cause this sort of compile error due to inconsistent input
to the preprocessor conditionals.  Would linux-x86_64 be more appropriate
for your system?

-Ben

On Thu, Aug 06, 2020 at 02:23:40AM +0530, prudvi raj wrote:
> Another thing ,  'make && make all '  is successful , but the same openssl
> files when compiled during my project's compilation show this error .
> PROJECT DIR  << make project here compiles all files.
> |- ..folder 1.
> |- openssl
> |-...
> Btw, Project uses same CC  -
> "/opt/toolchains/adtn-6/sysroots/x86_64-fslsdk-linux/usr/bin/ppce500v2-fsl-linux-gnuspe/powerpc-fsl-linux-gnuspe-gcc"
> Hope this clears some things up.
> $ ./configdata.pm -d
> 
> Command line (with current working directory = .):
> 
> /usr/bin/perl ./Configure no-threads no-dso no-ct no-shared no-zlib
> no-asm no-engine no-bf no-aria no-blake2 no-camellia no-cast no-md2 no-md4
> no-mdc2 no-ocsp no-rc2 no-rc5 no-hw-padlock no-idea no-srp gcc
> --with-rand-seed=none
> --cross-compile-prefix=/opt/toolchains/adtn-6/sysroots/x86_64-fslsdk-linux/usr/bin/ppce500v2-fsl-linux-gnuspe/powerpc-fsl-linux-gnuspe-
> 
> Perl information:
> 
> /usr/bin/perl
> 5.10.1 for x86_64-linux-thread-multi
> 
> Enabled features:
> 
> async
> autoalginit
> autoerrinit
> autoload-config
> buildtest-c\+\+
> capieng
> chacha
> cmac
> cms
> comp
> deprecated
> des
> dgram
> dh
> dsa
> dtls
> ec
> ec2m
> ecdh
> ecdsa
> err
> filenames
> gost
> hw(-.+)?
> makedepend
> multiblock
> nextprotoneg
> pinshared
> ocb
> poly1305
> posix-io
> psk
> rc4
> rdrand
> rfc3779
> rmd160
> scrypt
> seed
> siphash
> sm2
> sm3
> sm4
> sock
> srtp
> sse2
> ssl
> static-engine
> stdio
> tests
> tls
> ts
> ui-console
> whirlpool
> tls1
> tls1-method
> tls1_1
> tls1_1-method
> tls1_2
> tls1_2-method
> tls1_3
> dtls1
> dtls1-method
> dtls1_2
> dtls1_2-method
> 
> Disabled features:
> 
> afalgeng[cascade]  OPENSSL_NO_AFALGENG
> aria[option]   OPENSSL_NO_ARIA (skip
> crypto/aria)
> asan[default]  OPENSSL_NO_ASAN
> asm [option]   OPENSSL_NO_ASM
> bf  [option]   OPENSSL_NO_BF (skip
> crypto/bf)
> blake2  [option]   OPENSSL_NO_BLAKE2 (skip
> crypto/blake2)
> camellia[option]   OPENSSL_NO_CAMELLIA (skip
> crypto/camellia)
> cast[option]   OPENSSL_NO_CAST (skip
> crypto/cast)
> crypto-mdebug   [default]  OPENSSL_NO_CRYPTO_MDEBUG
> crypto-mdebug-backtrace [default]
>  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
> ct  [option]   OPENSSL_NO_CT (skip
> crypto/ct)
> devcryptoeng[default]  OPENSSL_NO_DEVCRYPTOENG
> dso [option]   OPENSSL_NO_DSO
> dynamic-engine  [cascade]
> ec_nistp_64_gcc_128 [default]
>  OPENSSL_NO_EC_NISTP_64_GCC_128
> egd [default]  OPENSSL_NO_EGD
> engine  [option]   OPENSSL_NO_ENGINE (skip
> crypto/engine, engines)
> external-tests  [default]  OPENSSL_NO_EXTERNAL_TESTS
> fuzz-libfuzzer  [default]  OPENSSL_NO_FUZZ_LIBFUZZER
> fuzz-afl[default]  OPENSSL_NO_FUZZ_AFL
> heartbeats  [default]  OPENSSL_NO_HEARTBEATS
> idea[option]   OPENSSL_NO_IDEA (skip
> crypto/idea)
> md2 [option]   OPENSSL_NO_MD2 (skip
> crypto/md2)
> md4 [option]   OPENSSL_NO_MD4 (skip
> crypto/md4)
> mdc2[option]   OPENSSL_NO_MDC2 (skip
> crypto/mdc2)
> msan[default]  OPENSSL_NO_MSAN
> ocsp[option]   OPENSSL_NO_OCSP (skip
> crypto/ocsp)
> pic [no-shared-target]
> rc2 [option]   OPENSSL_NO_RC2 (skip
> crypto/rc2)
> rc5 [option]   OPENSSL_NO_RC5 (skip
> crypto/rc5)
> sctp[default]  OPENSSL_NO_SCTP
> shared  [option]
> srp [option]   OPENSSL_NO_SRP (skip
> crypto/srp)
> ssl-trace   [default]  OPENSSL_NO_SSL_TRACE
> threads [option]
> ubsan   [default] 

Re: OpenSSL compliance with Linux distributions

[Benjamin Kaduk via openssl-users]

On Wed, Aug 05, 2020 at 10:28:26PM +0200, Patrick Mooc wrote:
> Thank you very much Kyle for your quick and clear answer.
> 
> The reason why I want to upgrade OpenSSL version, is that I encounter a
> problem with 1 frame exchange between client and server.
> 
> This frame is the first packet sent from client to server (Client Hello
> Packet) and the protocol used for this packet is SSLv2.
> I don't understand why, because I force the use of TLSv1 (in ssl.conf file
> as in application software), but only for this first exchange packet, SSLv2
> is used. All other packets are well using TLSv10 as configured.
> 
> I have also searched for forcing the use of TLSv10 ciphers in OpenSSL
> configuration and in application software, but I didn't succeed doing so.
> 
> That's why I had in idea of upgrading OpenSSL version to avoid the use of
> SSLv2 protocol.
> 
> 
> Thus, if you have any idea of how to solve my problem without upgrading
> OpenSSL version or Linux distribution, It would be very nice.

Using an "SSLv2-compatible" ClientHello is rather distinct from actually using
the SSLv2 protocol; I believe that the former is what is happening for you.

IIRC sending any TLS extension with the ClientHello suppresses the use of the
v2-compatible format, so you might be able to do that.  (I don't remember 
offhand
which extensions are implemented in that old of an OpenSSL version, and
whether they're enabled in the default build, though.)

-Ben

Re: 'in_addr_t' in openssl 1.1.1g ??

[Benjamin Kaduk via openssl-users]

On Thu, Aug 06, 2020 at 01:51:35AM +0530, prudvi raj wrote:
> Hi there,
> 
> I got this error during compilation , in file b_addr.c :
> In function 'BIO_lookup_ex':
> /b_addr.c:748:9: error: unknown type name 'in_addr_t'
> 
> I see that "in_addr_t" is defined in "netinet/in.h" & "arpa/inet.h" in
> toolchain (typedef uint32_t in_addr_t;).
> i have even tried to #include<> these files directly but that doesn't seem
> to fix the error. Btw, these files are included already , but under
> conditional #if 's.
> 
> I am surprised why the error persists , even after directly including the
> respective source file ??
> 
> Here's the config options i used :
> ./Configure  no-threads no-dso no-ct no-shared no-zlib no-asm no-engine
> no-bf no-aria no-blake2 no-camellia no-cast no-md2 no-md4 no-mdc2 no-ocsp
> no-rc2 no-rc5 no-hw-padlock no-idea no-srp gcc  --with-rand-seed=none
>  
> --cross-compile-prefix=/opt/toolchains/adtn-6/sysroots/x86_64-fslsdk-linux/usr/bin/ppce500v2-fsl-linux-gnuspe/powerpc-fsl-linux-gnuspe-
> 
> PS : same error without any cross compile prefix , using only gcc.

The `./configdata.pm -d` output might be helpful.

-Ben

Re: Compiling OpenSSL shared libraries with custom name on Unix platforms

[Benjamin Kaduk via openssl-users]

On Tue, Jul 14, 2020 at 09:08:10PM +0200, shivaramakrishna chakravarthula wrote:
> This is exactly similar to what I am looking for. I am using 1.0.2J version
> and there are some changes in the next version onwards that causes problems
> in SSL connections to older versions when DH key = 256 bytes are used. For
> backward compatibility reasons, I need to continue supporting 256 bytes DH
> keys for some more time and hence I want to stay on 1.0.2J version for now.
> 
> Anyways, Thanks for sharing the details.

Ah, thanks for the details.
The change I linked to is not going to be of much use to you, since the build 
system
got completely redone between those versions.

I will note that, at least on some systems, you can use sed to change the SONAME
of the compiled library before/during the installation process, which may
be enough of a workaround for your purposes.

-Ben

Re: Compiling OpenSSL shared libraries with custom name on Unix platforms

[Benjamin Kaduk via openssl-users]

On Tue, Jul 14, 2020 at 04:58:38PM +0200, shivaramakrishna chakravarthula wrote:
> Hi,
> 
> I have compatibility issues for my application with new versions of OpenSSL
> and I want to use the older version of OpenSSL with my application. So, I
> want to link my application with an OpenSSL library built with the custom
> name so that it works fine on all systems and I can be assured of using the
> desired OpenSSL version. I am using RPATH to locate the libraries in
> runtime and I want to make sure my libraries don't conflict with existing
> libraries.

How old is this "older version"?

The functionality you want sounds exactly like the "variant SONAMEs introduced
in commit 
https://github.com/openssl/openssl/commit/822b5e2645a99bea15329bd66c9723c7e7119cdb
but that's only in 1.1.0g and later.

-Ben

Re: Question about SSL_key_update

[Benjamin Kaduk via openssl-users]

On Thu, Jul 09, 2020 at 06:07:41PM +, Andreas Müller wrote:
> Hi,
> 
> I "inherited" our project to support/use TLSv1.3 from a late colleague. We
> have a server written in C++ (Windows, Linux)
> and clients (Windows, Linux, also written in C++ and also a Java client).
> With Java, we use the native SSLSocket implementation, in Windows we use
> Schannel and in Linux we use OpenSSL 1.1.1g. It seems to work and even
> interoperability
> did not show issues on some initial testing.
> 
> I was curious about SSL_key_update. I read that other implementations use it
> automatically, but with OpenSSL I have to
> do it manually. So I added a
> 
> int rc = SSL_key_update(ssl, SSL_KEY_UPDATE_REQUESTED);
> 
> after 1000 I/O operations and looked what happened.
> 
> I started with the Java client and it gets wrong application data in such a
> situation.
> 
> I tested with our Windows implementation (I know it may have
> interoperability issues) and here I can see the
> data I get from the server side and it is the same that I see on server side
> in the callback, but the Windows
> DecryptMessage function fails with SEC_E_INVALID_TOKEN. (I had expected
> something like SEC_I_RENEGOTIATE to
> get the information to put this record into InitializeSecurityContext.)
> 
> The Linux client also aborts the connection, but here I have not yet more
> details, but either the decryption fails
> or the decrypted application data is wrong. Hopefully I can dig in there
> next week.
> 
> Here is what happens on server side:
> 
> 1. I call SSL_key_update (see above)
> 2. I call SSL_write with application data
> 3. The write callback is invoked with this data:
>DATA: 17 03 03 00 16 b6 02 b1 06 87 f2 30 0d 77 35 31 7a 5b 6d 3c c2 aa
> 11 2c 32 95 a9
> 4. The write callback is invoked again with application data provided to
> SSL_write:
>DATA: 17 03 03 00 45 12 24 e5 66 36 2f 28 ea 62 2e 17 4c 62 f0 38 07 7f
> 72 70 87 25 ba 45 ff cf f7 9f 0d 7d 48 ...
> 
> I see these data arrive at the client side (Windows):
>DATA: 17 03 03 00 16 b6 02 b1 06 87 f2 30 0d 77 35 31 7a 5b 6d 3c c2 aa
> 11 2c 32 95 a9
> but get the error described above. In Java I get wrong application data, so
> it seems to decrypt this as application
> data?!
> 
> I saw an additional call to SSL_do_handshake in the apps/s_server.c and
> tried this, but it did not change anything.
> 
> Is there anything else (except calling SSL_key_update) I have to take care of?

Per the documentation 
(https://www.openssl.org/docs/man1.1.1/man3/SSL_key_update.html)
it sounds like you're doing all you need to be.  (In particular, you don't need
to call SSL_do_handshake().)

Probably the fastest way to track down what's happening is to get a full packet
capture and keylog (e.g., with s_client -keylogfile path/to/log, then point 
wireshark
at the trace+keys.

-Ben

Re: Are there any flag that control client finished hash verification

[Benjamin Kaduk via openssl-users]

On Mon, Jun 08, 2020 at 06:53:32PM +, Neil Proctor via openssl-users wrote:
> Hello,
> 
> Specific to OpenSSL v1.0.2p and TLS1.2 are there any flags or options like, 
> SSL_CERT_FLAG_TLS_STRICT, that set whether or not the client handshake 
> finished hash is verified by the server?  Or is this always performed 
> regardless of configuration?
> 
> During some of our testing, it seems that even if the last byte of the client 
> handshake finished hash gets modified, the server will still accept and 
> complete the handshake and the TLS connection.

Full validation of the Finished is supposed to be done always.
Please try to write up some discussion of your test cases; probably a github
issue is best (though mail to this list is okay too).

Thanks,

Ben

Re: 3.0.0-alpha2: openssl ciphers MEDIUM empty?

[Benjamin Kaduk via openssl-users]

On Wed, Jun 03, 2020 at 07:05:32PM +0200, Claus Assmann wrote:
> Just curious: Why is the output of
> openssl ciphers MEDIUM
> "empty" for 3.0.0.a2?

There are no ciphers available by default that are at the MEDIUM
level (which, to be honest, does not make a huge amount of sense at this
point anyway -- there's not a clear spot between "good" and "bad" to
bucket things into).

> Error in cipher list
> 00:00:00:00:error:SSL routines:SSL_CTX_set_cipher_list:no cipher 
> match:ssl/ssl_lib.c:2705:
> 
> Using 1.1.1 lists several, and at least
> TLS_AES_128_GCM_SHA256
> is also listed by
> openssl-3.0.0.a2 ciphers

TLS_* are TLS 1.3 ciphers, which in the parlance of openssl configuration
are known as "ciphersuites" (vs. "cipher list"), and are not affected
by the "cipher list" that you provide via SSL_CTX_set_cipher_list().

My
$ openssl version
OpenSSL 1.1.1  11 Sep 2018
only reports the TLS 1.3 ciphersuites and some SEED ciphers for an
input of MEDIUM, and IIRC the SEED ciphers have been foisted off to the
legacy provider and are not available by default.

> Has the "classification" of ciphers changed?
> I didn't see anything obvious in CHANGES.

This may just be the "legacy provider" bit -- the SEED ciphers are
still listed as "MEDIUM" in the code (and there are some others that
are gated behind ssl-weak-ciphers).

-Ben

Re: SSL_CTX_set_ssl_version changes security level

[Benjamin Kaduk via openssl-users]

On Tue, May 12, 2020 at 05:22:29AM +0900, NAKANO Takuho wrote:
> 2020年5月12日(火) 0:31 Benjamin Kaduk :
> 
> > OS-vendor customization
> 
> Thank you. That's very helpful. I get how to configure (but don't know 
> why...).
> 
> On CentOS 8:
> First result of SSL_CTX_get_security_level depends on
> A: /etc/pki/tls/openssl.cnf .
> 
> To be more precise, set "CipherString = @SECLEVEL=5:..."
> or "CipherString = @SECLEVEL=0:..." in
> B: /etc/crypto-policies/back-ends/opensslcnf.config
> that is included by A.
> 
> *BUT* second result of SSL_CTX_get_security_level depends on
> C: /etc/crypto-policies/back-ends/openssl.config
> (I assume SSL_CTX_set_ssl_version internally refer this file).
> File C has a single line beginning with:
> @SECLEVEL=2:kEECDH:..
> If I change this level, the second result changes.
> Maybe it's on RHEL8 patch (system-cipherlist.patch).

https://src.fedoraproject.org/rpms/openssl/blob/master/f/openssl-1.1.1-system-cipherlist.patch
suggests (the ssl.h chunk) that this patch does force the use of the "system
profile" as the default cipher list.

-Ben

Re: SSL_CTX_set_ssl_version changes security level

[Benjamin Kaduk via openssl-users]

On Mon, May 11, 2020 at 05:01:27PM +0900, NAKANO Takuho wrote:
> Hello,
> 
> I've found SSL_CTX_set_ssl_version changes security level:
> 
> =
> int main(void){
>   int i;
>   struct ssl_ctx_st *ctx = SSL_CTX_new(SSLv23_method());
> 
>   printf("seclevel: %d\n", SSL_CTX_get_security_level(ctx));
>   // 0--5 any
> 
>   i = SSL_CTX_set_ssl_version(ctx, SSLv23_client_method());
>   printf("SSL_CTX_set_ssl_version result: %d\n", i);
>   // i ==1; success
> 
>   printf("seclevel: %d\n", SSL_CTX_get_security_level(ctx));
>   // result 2
> 
>   return 0;
> }
> =
> 
> OS: CentOS 8
> OpenSSL 1.1.1c FIPS  28 May 2019
> 
> Are there any reasons?
> I know SSLv23_method is deprecated. That does not matter.

Note that SSL_CTX_set_ssl_version() has to re-set the cipher list
to filter out ciphers unsupported by the new version.  It uses
the default cipher list as its starting point, which I assume on
EL8 includes the security level in the cipher string.
You can set the cipher list (and security level) back to what you
want afterward, but I note that this behavior is a result of the
OS-vendor customization and not inherent to openssl.

-Ben

Re: openssl 3 alpha 1 test failures on AIX

[Benjamin Kaduk via openssl-users]

On Wed, May 06, 2020 at 05:22:17PM -0700, Norm Green wrote:
> All tests on AIX fail like this.  Is this a known issue?  What debugging
> information is needed?  Should I open an issue on github?
> 
> Also note I had to set LD_LIBRARY_PATH to the SSL build directory to get the
> tests to run at all.
> 
> 
> 
> 
> 
> normg@sky>gmake test
>     make depend && make _tests
>     ( SRCTOP=.  BLDTOP=.
> PERL="/export/localnew/RISC6000.AIX/perl-5.24.0/bin/perl" EXE_EXT= 
> /export/localnew/RISC6000.AIX/perl-5.24.0/bin/perl ./test/run_tests.pl  )
> 01-test_abort.t 
> # The results of this test will end up in test-runs/test_abort
> 1..1
> Use of uninitialized value in concatenation (.) or string at
> ../../util/wrap.pl line 14.
> Use of uninitialized value in concatenation (.) or string at
> ../../util/wrap.pl line 14.
> Unmatched ) in regex; marked by <-- HERE in m/ '') <-- HERE  eq '' && -d
> ../../util/../engines;
>  = ../../util/../providers
>     if ( / at ../../util/wrap.pl line 14.
> ../../util/wrap.pl ../../test/aborttest => 255
> ok 1 - Testing that abort is caught correctly
> ok
> 01-test_sanity.t ...
> # The results of this test will end up in test-runs/test_sanity
> 1..1
> Use of uninitialized value in concatenation (.) or string at
> ../../util/wrap.pl line 14.
> Use of uninitialized value in concatenation (.) or string at
> ../../util/wrap.pl line 14.
> Unmatched ) in regex; marked by <-- HERE in m/ '') <-- HERE  eq '' && -d
> ../../util/../engines;

That looks like your perl is unhappy about something; do you have other versions
of perl available to try?

Thanks,

Ben

Re: How to disable renegation before compiling openssl

[Benjamin Kaduk via openssl-users]

On Tue, Apr 21, 2020 at 09:57:02PM +0200, Mark Windshield wrote:
> Hello,
> 
> I was wondering what I'd have to change in the openssl code/config before
> compiling to have renegation disabled by default, so it won't send the
> Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) when using curl.

This description does not really make it clear whether you just want to prevent
renegotiation or specifically need this SCSV value to not be included in the
ClientHello -- the semantics of TLS_EMPTY_RENEGOTIATION_INFO_SCSV is "if
renegotiation occurs, the client supports the 'secure' variant", but is
otherwise orthogonal to whether renegotiation itself actually occurs.

-Ben

Re: OpenSSL Security Advisory

[Benjamin Kaduk via openssl-users]

On Tue, Apr 21, 2020 at 12:46:43PM -0700, Sam Roberts wrote:
> The announcement claims that this affects SSL_check_chain().
> 
> Is that an exhaustive list? If an application does NOT call that
> function, does this mean the vulnerability is not exploitable?

That is correct (speaking only in terms of public APIs).

> I ask because the the fixed function tls1_check_sig_alg is called by
> tls1_check_chain, and that is called directly by SSL_check_chain, but
> it is also called by tls1_set_cert_validity, and that is called from
> inside the tls state machine, but with different parameters, so its a
> bit hard to see if it is affected or not.

As you note, the valid call chains are a bit convoluted, but the relevant
codepath is only exercised for TLS 1.3 and SSL_check_chain().

-Ben

Re: opensssl 1.1.1g test failure(s)

[Benjamin Kaduk via openssl-users]

On Tue, Apr 21, 2020 at 07:22:38PM +0200, Claus Assmann wrote:
> Note sure whether this is already known (a search didn't bring up
> anything meaningful):
> 
> ../test/recipes/80-test_ssl_old.t .. 
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/6 subtests 
> Test Summary Report
> ---
> ../test/recipes/80-test_ssl_old.t(Wstat: 256 Tests: 6 Failed: 
> 1)

^
this is the number of failed tests

>   Failed test:  2
> ^ Is that supposed to be the number of failed tests?

No, that's the index of the failing test(s).  (I always have to check whether
it's 0-indexed or 1-indexed, though.)

>   If so, I don't see the 2nd test failure
>   (and it should probably  be "Failed test(s):"?)
> 
> Files=155, Tests=1256, 298 wallclock secs ( 0.32 usr  2.07 sys + 126.58 cusr 
> 156.65 csys = 285.62 CPU)
> Result: FAIL

Please run again with `make V=1 TESTS=test_ssl_old test` and post the relevant 
parts of the output?

Thanks,

Ben

Re: empty directory in the 1.1.1 series release tags

[Benjamin Kaduk via openssl-users]

On Tue, Apr 21, 2020 at 10:19:28AM -0700, Quanah Gibson-Mount wrote:
> --On Tuesday, April 21, 2020 11:16 AM -0700 Benjamin Kaduk
>  wrote:
> 
> > The 'krb5' entry in git is a submodule, used for the external tests.
> > It's removed while preparing release tarballs, but I'm not sure what
> > you are doing that's causing conflicts -- are you doing something that
> > involves both tarballs and git?
> 
> I use the git release tags, not the tarballs.

Can't you just leave the empty directory in your local branch and not
have a conflict, then?

-Ben

Re: empty directory in the 1.1.1 series release tags

[Benjamin Kaduk via openssl-users]

On Tue, Apr 21, 2020 at 10:08:39AM -0700, Quanah Gibson-Mount wrote:
> The OpenSSL release tags contain an empty directory "krb5" that does not
> exist in the release tarball.  This is annoying because when I go to merge
> release tags, I constantly get the following:
> 
> CONFLICT (modify/delete): krb5 deleted in HEAD and modified in
> OpenSSL_1_1_1e. Version OpenSSL_1_1_1e of krb5 left in tree.
> 
> Can this please be fixed?

The 'krb5' entry in git is a submodule, used for the external tests.
It's removed while preparing release tarballs, but I'm not sure what
you are doing that's causing conflicts -- are you doing something that
involves both tarballs and git?

-Ben

Re: Regression in 1.1.1 against 1.1.0 in SSL_CTX_new

[Benjamin Kaduk via openssl-users]

On Thu, Apr 16, 2020 at 09:41:23PM +0200, Harald Koch wrote:
> Am 16.04.2020 um 17:54 schrieb Tomas Mraz :
> > 
> > error queue of openSSL stays empty. The same code works with
> >> openSSL with gzip support („./config enable-zlib ...“, for support of
> >> compressed SMIME contents in other application).
> >> Do you call the OPENSSL_init_ssl from the main thread or from the
> >>> TLS
> >>> server thread?
> >> I call it from the TLS server thread (created by pthread_create):
> >> 
> >> if (!OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL))
> >>return;
> >> I tried to do it only once (instead of every started thread): no
> >> difference.
> > I do not see how this error could really happen unless
> > OPENSSL_cleanup() is called.
> > 
> > Could you try to set a breakpoint on that function and see if it is
> > somehow called inadvertently?
> gdb is actually unavailable, so I added a big „printf“ at the beginning of 
> crypto/init.c, recompiled (even without zlib support as I’ve seen there’s 
> much functionality in there), function OPENSSL_cleanup: it’s not called. I’m 
> very sure OPENSSL_cleanup is not called. 
> 
> > In addition, I load random data via /dev/urandom (also tested only
> >> once or every time the server thread starts):
> >>RAND_load_file("/dev/urandom", 256);
> > That call should not be necessary.
> I removed it just in case it may have an influence. No better result. :(
> 
> 
> I have a workaround and possibly it’s the solution, I would like to have your 
> valuable statement here: you asked where I call OPENSSL_init_ssl: it’s done 
> in the thread for TLS server. When I initialize it earlier in the main 
> thread, the subsequent generated (second) thread works as expected! Is this 
> spooky or expected behaviour?

Just to check: what OS is this on?

-Ben

Re: resumption problem

[Benjamin Kaduk via openssl-users]

On Mon, Mar 23, 2020 at 11:46:43PM +, Jeremy Harris wrote:
> OpenSSL 1.1.1  on Centos 8
> Ticket-based resumption
> 
> 
> I'm getting a repeatable error from a client call to SSL_connect()
> of "14228044:SSL routines:construct_ca_names:internal error".
> 
> Packet capture shows an Alert being sent by the client before
> anything is received from the server.
> 
> The error only occurs when the client is trying to resume
> a previous session, and (here's the odd part) only when
> the client is set up to offer a client certificate.
> 
> [I can change the client config to stop it offering this
> client-cert, and the resumption works just fine]
> 
> 
> I *think* possibly also the precise nature of that client cert
> matters; a testcase I set up away from my production
> system failed to induce the error.  The client cert
> is loaded using SSL_CTX_use_certificate_chain_file();
> the file contains a private-key and a 3-element chain
> with a Lets Encrypt cert (leaf, signer, CA-root).
> The CA is sha1/rsa, the other two are sha256/rsa.

Try omitting the (sha1) CA from the file?

-Ben

Re: SSL_set_client_CA_list(ssl, NULL) problem?

[Benjamin Kaduk via openssl-users]

Sorry for the very late response...

On Sun, Nov 24, 2019 at 12:05:34PM +0100, Claus Assmann wrote:
> Seems it is impossible to override the list with NULL for SSL, as
> the code will then use the list from CTX (if my limited understanding
> of the code is correct):
> 
> STACK_OF(X509_NAME) *SSL_get_client_CA_list(const SSL *s)
> {
> ...
> if (s->client_CA != NULL)
> return (s->client_CA);
> else
> return (s->ctx->client_CA);
> 
> Is this intentional? The man pages says:

Yes.

> SSL_set_client_CA_list() sets the list of CAs sent to the client when
> requesting a client certificate for the chosen ssl, overriding the
> setting valid for ssl's SSL_CTX object.
> 
> 
> IMHO there should be some indication (flag) that the value from SSL
> should be used (to distinguish between the ways NULL is used: "this
> is NULL because of the initialization" and "this is explicitly set
> to NULL").

You should be able to set a "zero-length list" (which is a non-NULL pointer
value) in order to get your desired behavior.

-Ben

Re: SNI disable by default on 1.0 and 1.1.0?

[Benjamin Kaduk via openssl-users]

On Mon, Dec 02, 2019 at 09:05:33PM +0100, aeris wrote:
> Hello here,
> 
> I try to compile 1.0.2t and 1.1.0l, but I notice SNI seems disabled by 
> default, when it's enabled by default on 1.1.1d…

Please specify whether you are concerned about the s_client behavior 
specifically
or the libssl library behavior.

> openssl-1.0.2t
> $ ./config enable-tlsext && make
> $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 | ./apps/
> openssl x509 -noout -subject  
> subject= /CN=localhost # No SNI by default, default vhost, bad certificate
> $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 -
> servername blog.imirhil.fr | ./apps/openssl x509 -noout -subject  
> subject= /CN=blog.imirhil.fr # SNI, correct vhost, good certificate
> 
> openssl-1.1.1d
> $ ./config && make
> $ echo -n "" | ./apps/openssl s_client -connect blog.imirhil.fr:443 | ./apps/
> openssl x509 -noout -subject  
> subject= /CN=blog.imirhil.fr # SNI by default, correct vhost, good certificate
> 
> According to changelog, enable-tlsext is available since 0.9.8f and by 
> default 
> since 0.9.8j, but seems something is wrong somewhere…
> The observed behaviour breaks all applications which don't set SNI 
> explicitly, 
> hitting the default vhost and not the real content…
> Is there any way to force SNI activation by default at build time on pre 
> 1.1.1 
> versions, like under 1.1.1d ?

I think your tests are just finding the changes from 
https://github.com/openssl/openssl/pull/2614
but other applications using libssl still need to use the 
SSL_set_tlsext_host_name()
API in order to send the SNI extension.

-Ben

Re: Removing Extensions from Client Hello Header

[Benjamin Kaduk via openssl-users]

On Tue, Nov 12, 2019 at 03:08:19PM -0700, Phil Neumiller wrote:
> I find the comment below about TLS 1.3 troubling.
[...]
> */*
>  * TODO(TLS1.3): These APIs cannot set TLSv1.3 sig algs so we just test
> it
>  * for TLSv1.2 for now until we add a new API.
>  */*
> SSL_CTX_set_max_proto_version(cctx, TLS1_2_VERSION);
> 
> if (testctx) {
> int ret;
> 
> if (curr->list != NULL)
> ret = SSL_CTX_set1_sigalgs(cctx, curr->list, curr->listlen);
> else
> ret = SSL_CTX_set1_sigalgs_list(cctx, curr->liststr);

I don't.
>From SSL_CTX_set1_sigalgs.pod:

% The TLS 1.3 signature scheme names (such as "rsa_pss_pss_sha256") can also
% be used with the B<_list> forms of the API.

The TLS 1.3 schemes don't decompose into SIG+HASH, so this is just a constraint
inherent to the old API, not a bug.

-Ben

Re: Removing Extensions from Client Hello Header

[Benjamin Kaduk via openssl-users]

On Tue, Nov 12, 2019 at 01:13:49PM -0700, Phil Neumiller wrote:
> Thanks for all the useful device.  I was able to get the server to accept
> this client hello message.

If you're willing/able to share, it can be useful for us to know what products
are buggy in that they don't implement extensions in a proper, extensible, 
manner
and need to have the ClientHello extensions adjusted like this.  If we have a
list of "likely suspects" it can make diagnosing future connection issues
easier.

Thanks,

Ben

Re: Removing Extensions from Client Hello Header

[Benjamin Kaduk via openssl-users]

On Mon, Nov 11, 2019 at 12:32:22PM -0700, Phil Neumiller wrote:
> I am speaking TLS 1.3 with openssl to a hardware device that I can't change. 
> I need the client hello header to only support certain  extensions, yet I
> see no way in the SSL API to remove the default extensions in the TLS 1.3
> client hello.  Can I clear them all and just add the ones I want?  What am I
> missing?  Do I have to modify the SSL code to do this?  It seems like there
> should be an orthodox way to do this.

You have to disable them one by one; see SSL_CTX_set_options(3) and (e.g.)
SSL_OP_NO_EXTENDED_MASTER_SECRET.

-Ben

Re: Should SSL_get_servername() depend on SNI callback (no-)ACK?

[Benjamin Kaduk via openssl-users]

There's some (additional?) discussion on this topic in
https://github.com/openssl/openssl/pull/10018 .  A couple comments inline, 
though...

On Tue, Oct 22, 2019 at 02:30:37PM +0200, Yann Ylavic wrote:
> Hi,
> 
> in master (and 1.1.1), SSL_get_servername() returns either
> s->session->ext.hostname (when s->hit == 1), or s->ext.hostname
> (otherwise).
> 
> It seems, according to final_server_name(), that
> s->session->ext.hostname is set only:
> if (sent && ret == SSL_TLSEXT_ERR_OK && (!s->hit || SSL_IS_TLS13(s))) 
> {
> ...
> s->session->ext.hostname = OPENSSL_strdup(s->ext.hostname);
> ...
> }
> that is if a SNI callback exists and returns OK (no callback
> defaulting to NOACK).
> 
> And it _seems_ that browsers (or Chrome only?) don't set a
> tlsext_hostname in their session (ASN1) on resumption, so

I don't understand what you mean by "set a tlsext_hostname in their session 
(ASN1)
on resumption".  Are you saying that browsers do not send the 
server_name_indication
extension in the ClientHello for resumption handshakes?

> s->session->ext.hostname isn't set by that either. Note that this
> leaves s->servername_done = 0 in the below code from
> tls_parse_ctos_server_name():
> if (s->hit) {
> /*
>  * TODO(openssl-team): if the SNI doesn't match, we MUST
>  * fall back to a full handshake.
>  */
> s->servername_done = (s->session->ext.hostname != NULL)
> && PACKET_equal(, s->session->ext.hostname,
> strlen(s->session->ext.hostname));
> 
> if (!s->servername_done && s->session->ext.hostname != NULL)
> s->ext.early_data_ok = 0;
> }
> 
> So it's possible that, on session resumption (s->hit == 1),
> SSL_get_servername() returns NULL (unset s->session->ext.hostname)
> even though an SNI is provided by ClientHello. Shouldn't it return the
> ClientHello's SNI regardless of the presence/return of the callback?
> Something like the below (where s->servername_done is also tested)?

There's something of a philosophical debate; some additional (heated)
discussion can be found in https://github.com/openssl/openssl/pull/7115
but I think the real cause of problems in this space is that
the SSL_get_servername() API contract has been underspecified from the
start.  Note that the documentation for SSL_get_servername() is in
the page for SSL_CTX_set_tlsext_servername_callback() and claims to
return the value from the Client Hello (if present).  Yet, historically,
prior to TLS 1.3 on resumption we did not even look at the ClientHello
to see whether the extension was present; we just resumed and thus the
"Client Hello" in the above would be the *initial* ClientHello.  This
was perhaps tolerable if the servername callback was never called, if
you assume that the API would only be called from that callback, but
that assumption is no longer anywhere close to true.

-Ben

> const char *SSL_get_servername(const SSL *s, const int type)
> {
> if (type != TLSEXT_NAMETYPE_host_name)
> return NULL;
> 
> /*
>  * SNI is not negotiated in pre-TLS-1.3 resumption flows, so fake up an
>  * SNI value to return if we are resuming/resumed.  N.B. that we still
>  * call the relevant callbacks for such resumption flows, and callbacks
>  * might error out if there is not a SNI value available.
>  */
> if (s->hit && s->servername_done)
> return s->session->ext.hostname;
> return s->ext.hostname;
> }
> 
> 
> Regards,
> Yann.

Re: debian openssh issue with openssl 1.1.1d

[Benjamin Kaduk via openssl-users]

On Tue, Oct 08, 2019 at 05:23:56AM -0400, Michael Richardson wrote:
> Salvatore Bonaccorso  wrote:
> > 
> -
> > Debian Security Advisory DSA-4539-2   
> secur...@debian.org
> > https://www.debian.org/security/ Salvatore 
> Bonaccorso
> > October 07, 2019  
> https://www.debian.org/security/faq
> > 
> -
> 
> > Package: openssh
> > Debian Bug : 941663
> 
> > A change introduced in openssl 1.1.1d (which got released as DSA 4539-1)
> > requires sandboxing features which are not available in Linux kernels
> > before 3.19, resulting in OpenSSH rejecting connection attempts if
> 
> I've gone through the changelog for 1.1.1d, but I can't figure out what
> 1.1.1d would have changed that would have caused this.

The RNG uses sysV shm to convey to other processes that /dev/[u]random has been
properly seeded, under some configurations/kernel versions.

-Ben

Re: configuring callbacks (or not) and SNI vs not... no shared cipher from server end

[Benjamin Kaduk via openssl-users]

On Wed, May 08, 2019 at 04:40:07PM -0400, Michael Richardson wrote:
> 
> Viktor Dukhovni  wrote:
> >> Diversionary issue:
> >> 
> https://www.openssl.org/docs/manmaster/man3/SSL_set_tlsext_host_name.html
> >> and:
> >> 
> https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_client_hello_cb.html
> >>
> >> are pretty vague.  I think that SSL_set_tlsext_host_name() is probably
> >> intended to be used on the client to set the SNI, but I'm not sure.
> 
> > Yes, e.g. in the Postfix TLS client:
> 
> > 
> https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1035-L1045
> 
> So, okay.
> Either this URL can go into the man page, or some short code extract could go 
> in.

Probably better to have a code snippet (filing a github issue or sending
a pull request would probably be good).

> >> The legacy cb function returns int, but it's values are not
> >> documented.
> 
> > On the server side I'm using SSL_CTX_set_tlsext_servername_callback():
> 
> > 
> https://github.com/vdukhovni/postfix/blob/2399e9e179ee025d03155fa3637cccab0a23ddce/postfix/src/tls/tls_misc.c#L1040-L1043
> > 
> https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_misc.c#L668
> 
> >> I guess the point is that CB can set the server certificate to
> >> something appropriate, or I think, it could just decide to ignore the
> >> SNI value completely and force the certificate regardless.
> 
> > Yes.
> 
> I can see that the CB provides comprehensive functionality, but I worry about
> applications trying to parse ClientHello extensions themselves and getting it 
> wrong.

It turns out that the server_name TLS extension is something of an
unfortunate exception in terms of the unneeded complexity in its
encoding.  When I wrote the client_hello_cb functionality (at the time,
know as the early_cb), I thought about whether I wanted to add a
dedicated API just for the SNI value, due to the level of complexity
involved.  I ended up not doing so in the initial submission, both
because I figured it could safely be added later as an incremental
change, and because I was worried (IIRC) about being tempted to expose
some of the PACKET_* APIs in the process, which is not really the right
architectural choice for OpenSSL.

There is, however, an existing implementation for extracting the SNI
value in the test code at
https://github.com/openssl/openssl/blob/master/test/handshake_helper.c#L150-L187
that has been successfully extracted and used in a couple places I know
of.

> >> What is the SNI functionality otherwise on the server?
> 
> > You can interpose a secondary "virtual-host-specific" SSL_CTX for for
> > the rest of the handshake.  This carries the server certificate, but
> > also the trust store settings for validating client certificates, the
> > settings to request (or not) client certificates, the verification
> > callbacks, ...  It is a rather heavyweight object, best cached and
> > re-used for multiple connections.
> 
> So, it's okay to change the SSL_CTX for an SSL* after creation.
> That is rather surprising to me, but I guess it's okay.
> I suppose I feel that there ought to be reference counts, but this is C, not 
> Rust.

There *are* reference counts.

> > In Postfix, it is configured with the same settings as the initial
> > SSL_CTX, *but* no server certificates.  During the SNI callback I
> > interpose the certificate-less context, and then set the certificate
> > chain on the connection handle (SSL *) instead.
> 
> okay, I'll use Postfix as my reference :-)

For "how to use and switch SSL_CTXs" I'm sure it's admirable, but my
understanding is that it's still using the legacy server_name callback
(as opposed to the new client_hello_cb), and the new callback has a lot
of advantages for architectural cleanliness and avoiding some surprising
behavior with respect to the ordering of certain processing in the
server.  So for a greenfield application I'd still suggest using the
client_hello_cb (not that I'm entirely unbiased...).

-Ben

> >> Is there any support for picking a certificate based upon the SNI
> >> name?
> 
> > The application does the "picking"...  The application sets one or more
> > certificate chains (one per supported public key algorithm) that best
> > match the SNI name, and then OpenSSL chooses one of these based on the
> > client's advertised supported signature algorithms, ...
> 
> What I was observing (wrongly) was that maybe the server was doing something
> itself if there was no callback, and it was failing.  This was from looking
> at the code around the error code that came out.
> This (see other email) proved to wildly incorrect.
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  

Re: Listing TLS 1.3 Ciphers

[Benjamin Kaduk via openssl-users]

On Wed, Apr 10, 2019 at 12:13:27PM -0400, Dennis Clarke wrote:
> On 4/10/19 7:37 AM, Richard Moore wrote:
> >Hi All,
> >
> >I haven't found a way to list the supported openssl ciphers from the
> >command line (i.e. get the list of potential values for -ciphersuites). I
> >understand that currently there are only 5 options however this could
> >change over time, so I wanted to avoid hard coding the list in a script.
> >Am I missing something?
> >
> >Thanks
> >
> >Rich
> 
> Strangely I only see three :
> 
> nix$ openssl version
> OpenSSL 1.1.1b  26 Feb 2019
> nix$ openssl ciphers -V -tls1_3 -s
>   0x13,0x02 - TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any Au=any
> Enc=AESGCM(256) Mac=AEAD
>   0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
>   0x13,0x01 - TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any Au=any
> Enc=AESGCM(128) Mac=AEAD
> nix$
> 
> Very odd. I thought that there were more at one point.

The ones with truncated (8-byte) authentication tag are not intended for
general use and don't make it into the default list.

-Ben

Re: [openssl-users] SNI callback

[Benjamin Kaduk via openssl-users]

On Wed, Nov 28, 2018 at 08:48:10PM +, Jeremy Harris wrote:
> OpenSSL 1.1.1 FIPS  11 Sep 2018
> RHEL 8.0 beta
> 
> Using SSL_CTX_set_tlsext_servername_callback()
> when the called routine returns SSL_TLSEXT_ERR_NOACK
> I was expecting the handshake to fail.  It carries
> on; am I doing something wrong?

NOACK is basically "pretend that there wasn't a callback here";
you should probably use SSL_TLSEXT_ERR_ALERT_FATAL to abort the
connection if you want the handshake to fail.

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

Re: [openssl-users] Two sessions in a single full handshake

[Benjamin Kaduk via openssl-users]

s_client has -sess_out and -sess_in options that can be used
to save session information to a file and read it in for a subsequent
connection.  Neither is used by default.

-Ben

On Sun, Sep 30, 2018 at 11:06:14AM +0800, John Jiang wrote:
> Does s_client resume any session in the local session file?
> 
> On Sun, Sep 30, 2018 at 3:19 AM Salz, Rich via openssl-users <
> openssl-users@openssl.org> wrote:
> 
> >
> >- The debug logs display two "SSL-Session" blocks in a full handshake.
> >
> > Only one "SSL-Session" block is displayed in a resumption.
> >
> > Why does full handshake has two sessions?
> >
> >
> >
> > This is part of the TLS 1.3 standard.  A server can send back multiple
> > sessions, so that a client may resume with a different session, and
> > therefore prevent an observer from “linking” two different activities.
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> >

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

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

Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working

[Benjamin Kaduk via openssl-users]

On Thu, Sep 13, 2018 at 08:13:41PM +0200, Jakob Bohm wrote:
> On 13/09/2018 09:57, Klaus Keppler wrote:
> >Hi,
> >
> >thank you for all your responses.
> >
> >I've just tested with Firefox Nightly 64.0a1, and both s_server and our
> >own app (using OpenSSL 1.1.1-release) are working fine.
> >
> >The Firefox website is quite confusing:
> >
> >>Firefox 61 is already shipping draft-28, which is essentially the same as 
> >>the final published version (just with a different version number).
> >(https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/)
> >
> >This is quite confusing, as it sounds better than it actually is.
> >(so I've just learned that draft-28 is obviously incompatible with RFC8446)
> >
> >So thank you for your input, will now continue with OpenSSL 1.1.1.
> >The rest will be only a matter of time. :D
> >
> >Best regards
> >
> >-Klaus
> Would it be reasonable for 1.1.1a to add a transitional "bugs" bit (to be
> removed again in a few years) to accept the draft version number of final
> TLS 1.3, if the protocols are otherwise identical?
> 
> This would be similar to the (now historic) bits for known bugs in other
> popular clients.  It also seems to be what Facebook has done for their
> own servers (according to other posts in this discussion).
> 
> Or would it be unproblematic from a real world perspective to just keep
> TLS 1.3 non-functional for draft-28 browsers?

It would be unproblematic.  Such browsers will use TLS 1.2 just fine, and
are going to be auto-updating to a version capable of official TLS 1.3
very soon anyway.

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

Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working

[Benjamin Kaduk via openssl-users]

On Wed, Sep 12, 2018 at 03:50:17PM +0200, Klaus Keppler wrote:
> Hi,
> 
> when I create a TLS-1.3-only "web" server with s_server (from OpenSSL
> 1.1.1-release), Firefox/Chrome can't access it.
> According to all docs I've read so far, the TLS 1.3 implementations both
> from Firefox (62.x) and from Chrome (69.x) should be compatible so far.

You need to check that the browser is implementing the final RFC 8446 version
and not an earlier draft version -- two are incompatible by design
(and OpenSSL 1.1.1 implements the final RFC 8446 version).

IIUC, only Firefox nightly as of approximately today will support the final
RFC 8446 version; I haven't looked into Chrome yet.

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

Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2

[Benjamin Kaduk via openssl-users]

On Tue, Sep 11, 2018 at 03:04:06PM -0600, The Doctor wrote:
> On Tue, Sep 11, 2018 at 02:57:09PM -0500, Benjamin Kaduk via openssl-users 
> wrote:
> > On Tue, Sep 11, 2018 at 10:48:40AM -0600, The Doctor wrote:
> > > On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote:
> > > > Looks likes I found a first bug
> > > > 
> > > > ../test/recipes/70-test_comp.t .
> > > > Proxy started on port [::1]:10789
> > > > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server 
> > > > -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept 
> > > > [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem 
> > > > -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256
> > > > engine "ossltest" set.
> > > > Using default temp DH parameters
> > > > ACCEPT [::1]:39577
> > > > Server responds on [::1]:39577
> > > > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg 
> > > > stack: base=805d16098, sp=805d160e8, hwm=805d160d0
> > > > 
> > > 
> > > Using perl 5.28.1
> > 
> > The test suite needs some modules not included in the core perl 
> > port/package.
> > You should probably list out what p5-* you have installed.
> 
> 
> p5-Archive-Zip-1.63Create, manipulate, read, and write Zip 
> archive files
> p5-Authen-NTLM-1.09_1  Perl5 NTLM authentication module
> p5-Authen-PAM-0.16_2   Perl interface to the PAM library
> p5-Authen-SASL-2.16_1  Perl5 module for SASL authentication
> p5-Business-ISBN-3.004 Work with International Standard Book Numbers
> p5-Business-ISBN-Data-20140910.003 Data pack for Business::ISBN
> p5-CGI-4.40Handle Common Gateway Interface requests and 
> responses
> p5-Class-Inspector-1.32Provides information about classes
> p5-Convert-ASN1-0.27_2 Perl5 module to encode and decode ASN.1 data 
> structures
> p5-Convert-BinHex-1.125Perl module to extract data from Macintosh 
> BinHex files
> p5-Convert-TNEF-0.18_1 Perl module to read TNEF files
> p5-Crypt-OpenSSL-Bignum-0.09   OpenSSL's multiprecision integer arithmetic
> p5-Crypt-OpenSSL-Guess-0.11Guess OpenSSL include path
> p5-Crypt-OpenSSL-RSA-0.30_1Perl5 module to RSA encode and decode strings 
> using OpenSSL
> p5-Crypt-OpenSSL-Random-0.15   Perl5 interface to the OpenSSL pseudo-random 
> number generator
> p5-Crypt-SSLeay-0.72_3 Perl5 interface to allow p5-libwww LWP to make 
> https connections
> p5-DBD-SQLite-1.58 Provides access to SQLite3 databases through 
> the DBI
> p5-DBD-mysql-4.046 MySQL driver for the Perl5 Database Interface 
> (DBI)
> p5-DBI-1.641   Perl5 Database Interface, required for DBD::* 
> modules
> p5-Data-Dump-1.23_1Pretty printing of data structures
> p5-Date-EzDate-1.16Date and time manipulation made easy
> p5-Devel-CheckLib-1.13 Check that a library is available
> p5-Digest-BubbleBabble-0.02_1  Perl5 interface to a fingerprint in "bubble 
> babble" format
> p5-Digest-HMAC-1.03_1  Perl5 interface to HMAC Message-Digest 
> Algorithms
> p5-Digest-SHA1-2.13_1  Perl interface to the SHA-1 Algorithm
> p5-Encode-Detect-1.01_1Encode::Encoding subclass that detects the 
> encoding of data
> p5-Encode-Locale-1.05  Determine the locale encoding
> p5-Error-0.17026   Error/exception handling in object-oriented 
> programming style
> p5-ExtUtils-Depends-0.405  Easily build XS extensions that depend on XS 
> extensions
> p5-ExtUtils-PkgConfig-1.16 Simplistic interface to pkg-config
> p5-File-Listing-6.04_1 Parse directory listings
> p5-File-ShareDir-1.116 Locate per-dist and per-module shared files
> p5-File-ShareDir-Install-0.13  Install read-only data files from a 
> distribution
> p5-Filesys-Df-0.92_1   Perl extension for filesystem space
> p5-Filter-1.59 Number of source filters for perl5 programs
> p5-GD-2.68 Perl5 interface to Gd Graphics Library version2
> p5-GD-Barcode-1.15_6   GD::Barcode - Create barcode image with GD
> p5-GSSAPI-0.28_1   Perl extension providing access to the 
> GSSAPIv2 library
> p5-Geo-IP-1.51 Gets country name by IP or hostname
> p5-Geography-Countries-2009041301_1 Handle ISO-3166 country codes
> p5-Glib2-1.327 This module provides access to Glib and 
> GObject libraries
> p5-HTML-Parser-3.72Perl5 module for parsing HTML document

Re: [openssl-users] openssl 1.1.1 and FreeBSD 11.2

[Benjamin Kaduk via openssl-users]

On Tue, Sep 11, 2018 at 10:48:40AM -0600, The Doctor wrote:
> On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote:
> > Looks likes I found a first bug
> > 
> > ../test/recipes/70-test_comp.t .
> > Proxy started on port [::1]:10789
> > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server 
> > -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept 
> > [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 
> > -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256
> > engine "ossltest" set.
> > Using default temp DH parameters
> > ACCEPT [::1]:39577
> > Server responds on [::1]:39577
> > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: 
> > base=805d16098, sp=805d160e8, hwm=805d160d0
> > 
> 
> Using perl 5.28.1

The test suite needs some modules not included in the core perl port/package.
You should probably list out what p5-* you have installed.
Also, do you have any IPv6 addresses configured?

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

Re: [openssl-users] OpenSSL version 1.1.1 pre release 9 published

[Benjamin Kaduk via openssl-users]

On Mon, Aug 27, 2018 at 04:38:24PM -0400, Robert Moskowitz wrote:
> 
> 
> On 08/27/2018 04:07 PM, Hubert Kario wrote:
> >On Monday, 27 August 2018 20:57:53 CEST Robert Moskowitz wrote:
> >>On 08/27/2018 02:33 PM, Hubert Kario wrote:
> >>>On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote:
> >>
> >>Over the years and in protocol design development, I have heard too many
> >>we can't.  So I set about with, "here is one way."  Since then I have
> >>had a few people actually thank me for making it possible for them to
> >>build an ecdsa pki for their product testing needs.  Just one justifies
> >>my effort.
> >well, I see nothing wrong with providing documentation and how-to's, I just
> >don't see that it should be elevated to an Internet Draft level...

Well, see https://datatracker.ietf.org/doc/draft-wkumari-not-a-draft/ .

> >by its very nature it needs to be constantly updated, so having it in a 
> >static
> >RFC is contrary to that
> 
> that is the value of Internet Drafts that many of us IETFers have figured
> out.  draft versions can just keep on going and the tools will take you to
> the current draft.  IDs have become neat working documents, though there is
> more github work coming along.  More workgroups are doing requirements docs
> that will never be published as RFCs; they will stay as IDs.  Much better
> source of why did the wg do? than plow through the old mailing list
> archives.  The IESG is actually encouraging such a use of IDs.

Yup!  Internet-Draft is a fine terminus for some types of document.
Many TLS registries now have a registration policy that explicitly calls out
an internet-draft that is never published as anything else, as a valid 
specification
for getting a codepoint assignment.

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

Re: [openssl-users] Access clienthello in openssl1.1.0

[Benjamin Kaduk via openssl-users]

On Wed, Jun 13, 2018 at 11:32:11AM -0500, Zeyuan Yu wrote:
> Hi All,
> 
> Is there still a way to access client hello in 1.1.0?
> 
> Before 1.1.0 I can just access the internal `s->init_msg`. And starting
> 1.1.1, APIs are provided for the client hello. But there doesn't seem to be
> similar methods in 1.1.0.

I don't believe so, and it's unclear that this qualifies as a "missing
accessor" that would be eligible to get fixed in 1.1.0 as a bugfix.  So
I think your main option is to move to 1.1.1, at this point.

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

Re: [openssl-users] Call for testing TLS 1.3

[Benjamin Kaduk via openssl-users]

(For those who are not Jouni, there is some spec work needed for
TLS 1.3/EAP integration as well, occurring in the IETF EMU working group.
I assume Jouni is on the mailing list and knows this already)

-Ben

On Mon, May 28, 2018 at 03:28:13PM +0300, Jouni Malinen wrote:
> On Sun, Apr 29, 2018 at 12:43:26PM +0200, Kurt Roeckx wrote:
> > We are considering if we should enable TLS 1.3 by default or not,
> > or when it should be enabled. For that, we would like to know how
> > applications behave with the latest beta release.
> 
> It looks like couple of TLS 1.3 changes result in breaking functionality
> for various EAP methods that are based on TLS unless significant changes
> in both the EAP method definition and implementations are done before
> enabling the new TLS version. This seems to have an impact to at least
> EAP-TLS, EAP-PEAP, EAP-TTLS, and EAP-FAST.
> 
> As far as wpa_supplicant (EAP peer) and hostapd (EAP server)
> implementations are concerned, I've prepared changes to make EAP-TLS
> work with TLS 1.3, but the other EAP methods are still failing for
> various known (and to some extend, unknown) issues. Anyway, I'm
> currently explicitly disabling TLS 1.3 support with OpenSSL by default
> in these application due to these issues and the expected
> interoperability issues and as such, the OpenSSL 1.1.1 release default
> behavior regarding TLS 1.3 support should not have impact for these
> applications. That said, other EAP implementations may want to do
> something similar or face possibility of breaking functionality if
> OpenSSL 1.1.1 does go out with TLS 1.3 enabled by default and both ends
> of the EAP connection have TLS 1.3 enabled.
> 
> -- 
> Jouni MalinenPGP id EFC895FA
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] compilation error with openssl-1.1.0 and DH_get0_key

[Benjamin Kaduk via openssl-users]

On 02/21/2018 10:16 AM, Robert Watson wrote:
> I'm trying to update a crypto library for crtmpserver to work with
> openssl 1.1.0.  The software is no longer actively maintained and my
> c++ skills are somewhat rudimentary but I keep getting a compilation
> error for something that seems trivial.
>
> Here's the code snippet:
> bool DHWrapper::CopyPublicKey(uint8_t *pDst, int32_t dstLength) {
>     if (_pDH == NULL) {
>         FATAL("DHWrapper not initialized");
>         return false;
>     }
>     BIGNUM *_keyPublic,*_keyPrivate;
>     _keyPublic = BN_new();
>     _keyPrivate = BN_new();
>     DH_get0_key( _pDH, *_keyPublic, *_keyPrivate );

Use '&' instead of '*'

-Ben

>     CopyKey(_keyPublic, pDst, dstLength);
>     return true;
> }
>
> Here's the compilation error:
> /build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp:
> In member function ‘bool DHWrapper::CopyPublicKey(uint8_t*, int32_t)’:
> /build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp:92:47:
> error: cannot convert ‘BIGNUM {aka bignum_st}’ to ‘const BIGNUM** {aka
> const bignum_st**}’ for argument ‘2’ to ‘void DH_get0_key(const DH*,
> const BIGNUM**, const BIGNUM**)’
>   DH_get0_key( _pDH, *_keyPublic, *_keyPrivate );
>    ^
> make[2]: *** [common/CMakeFiles/common.dir/build.make:591:
> common/CMakeFiles/common.dir/build/crtmpserver/src/crtmpserver/sources/common/src/utils/misc/crypto.cpp.o]
> Error 1
> make[1]: *** [CMakeFiles/Makefile2:231:
> common/CMakeFiles/common.dir/all] Error 2
> make: *** [Makefile:130: all] Error 2
>
> What am I doing wrong? Thanks,
> Robert
>
>
>

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

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

[Benjamin Kaduk via openssl-users]

On 02/19/2018 02:06 PM, Norm Green wrote:
> Not sure if this is expected on this platform?
>
> Test Summary Report
> ---
> ../test/recipes/04-test_asn1_encode.t    (Wstat: 256 Tests: 1
> Failed: 1)
>   Failed test:  1
>   Non-zero exit status: 1
> ../test/recipes/90-test_secmem.t (Wstat: 256 Tests: 1
> Failed: 1)
>   Failed test:  1
>   Non-zero exit status: 1
> Files=141, Tests=1313, 370 wallclock secs ( 3.42 usr  0.94 sys +
> 266.48 cusr 40.30 csys = 311.14 CPU)
> Result: FAIL
> Makefile:169: recipe for target '_tests' failed

I do not think it is expected.  Could you capture the output of 'make
V=1 TESTS="test_asn1_encode test_secmem"' and make it available? 
(Probably via posting it on the web and linking; the output may be long.)

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

Re: [openssl-users] Confirmation of what I believe to be true from docs and observation

[Benjamin Kaduk via openssl-users]

On 01/10/2018 02:37 PM, Karl Denninger wrote:
> On 1/10/2018 14:07, Benjamin Kaduk wrote:
>> On 01/10/2018 08:41 AM, Karl Denninger wrote:
>>> We start with a context that I load a dhparam file to (so I can take a
>>> DH connection) along with an edh curve, then set an acceptable cipher
>>> list for it to use.
>>>
>> Why not just use AUTO_DH (the only option for 1.1.0, IIRC)?
> That's a reasonable change (and I'll go ahead and make it); the
> dhparam was only there in the first place for those browsers and such
> that can't negotiate EC (which my cipher selection set prefers.)
>>> Assume I next manually load both the CA store (using
>>> X509_STORE_add_cert as many times as necessary to load the
>>> intermediate components and the root of trust) and then load the
>>> cert/key pair (using SSL_CTX_use_certificate/SSL_CTX_use_PrivateKey)
>>>
>>> I then create some number of SSLs from that context to perform
>>> communication with and all is well.
>>>
>>> Now I want to rekey that context for some reason.  It appears that
>>> while I can add things to
>>>
>> Why do you need to rekey the context as opposed to making a new one?
> I could make a new one (or more-specifically, destroy the existing one
> and re-initialize it), but that is more-complicated as the application
> in question is multi-threaded -- and it's not at all clear from the
> documentation if I destroy a context that has SSLs that have been
> generated from it will cause "bad things" to happen (like a deference
> on a freed object!)
>

Each SSL holds a reference on its parent SSL_CTX (and another reference
on its associated session_ctx, which starts out as the same SSL_CTX
object); SSL_CTX_free() does not do any deallocation until the refcount
drops to zero.

So, no "bad things" will happen if you SSL_CTX_free() the handle you
have in your application while SSL objects are still using that object.

> The reason I may want to rekey is that the cert/key pair used for that
> context may have changed.  The user's certificate may have expired for
> example (or been revoked) and I wish to reload it (and the matching
> key) without having to shut down the software and restart it.
>
>> In general, making configuration changes to an SSL_CTX after it has been
>> used to generate SSL objects is a risky proposition -- the locking model
>> does not really account for doing synchronization properly, and there
>> might be some latent race conditions.  In practice, some operations are
>> currently safe, but there is no authoritative list of which ones, and at
>> least my personal recommendation is to not try to rely on it.
> Assuming that there are SSL objects that are in use and I destroy and
> re-generate the CTX from which it was generated, is *THAT* safe?  Or
> do I need to flag all the in-use descendants and wait for them to be
> closed (or force them closed and release them) before I can safely
> destroy the context? 

You do not need to flag and wait, due to the reference counting on the
SSL and SSL_CTX objects.

>>> the CA chain trying to load the same component that is already in
>>> there returns a failure (somewhat-expected; that is, it does not
>>> overwrite but rather adds, and if you try to add what's already there
>>> you get an error back) and there's no call to CLEAR the certificate
>>> validation chain -- if I want to *replace* the validation chain I have
>>> to destroy the context and initialize a new one from scratch.
>>>
>> N.B. that the X509_STORE_add_cert behavior when presented with a
>> duplicate certificate changed in commit
>> c0452248ea1a59a41023a4765ef7d9825e80a62b (from returning an error to
>> doing nothing and returning success); this will be in 1.1.1.
>>
>> As to the desired behavior, there does not seem to be an API to remove
>> an entry from an X509_STORE.  With the above caveat about thread-safety
>> in mind, couldn't you just make a call to SSL_CTX_set{1}_cert_store() to
>> replace the X509_STORE without tearing down the whole SSL_CTX?
> Yeah, I didn't see one either.  I'm not particularly concerned about
> the verification chain being able to be modified while "in-use"; that
> ought not happen except in an extreme circumstance (e.g. the
> intermediate cert's key is compromised and thus both it and the cert
> have to be regenerated and re-distributed.)  If it DOES happen when
> the end-entity cert and key are reloaded (as they've been signed from
> the new intermediate) they'll fail to validate against the old chain
> and the user will get plenty of notice that there's trouble.
>>> It appears, however, that I *can* load over the top of a certificate
>>> and private key of the same type and that's acceptable.  In other
>>> words, if I have an RSA key/cert pair in the context and I load
>>> another one, the first one is replaced.  This *looks* to be working ok
>>> as far as I can tell and it doesn't appear to leak memory doing that
>>> but it's not explicitly stated that this is considered acceptable
>>> (rather than destroying 

Re: [openssl-users] Confirmation of what I believe to be true from docs and observation

[Benjamin Kaduk via openssl-users]

On 01/10/2018 08:41 AM, Karl Denninger wrote:
>
> We start with a context that I load a dhparam file to (so I can take a
> DH connection) along with an edh curve, then set an acceptable cipher
> list for it to use.
>

Why not just use AUTO_DH (the only option for 1.1.0, IIRC)?

> Assume I next manually load both the CA store (using
> X509_STORE_add_cert as many times as necessary to load the
> intermediate components and the root of trust) and then load the
> cert/key pair (using SSL_CTX_use_certificate/SSL_CTX_use_PrivateKey)
>
> I then create some number of SSLs from that context to perform
> communication with and all is well.
>
> Now I want to rekey that context for some reason.  It appears that
> while I can add things to
>

Why do you need to rekey the context as opposed to making a new one?

In general, making configuration changes to an SSL_CTX after it has been
used to generate SSL objects is a risky proposition -- the locking model
does not really account for doing synchronization properly, and there
might be some latent race conditions.  In practice, some operations are
currently safe, but there is no authoritative list of which ones, and at
least my personal recommendation is to not try to rely on it.

> the CA chain trying to load the same component that is already in
> there returns a failure (somewhat-expected; that is, it does not
> overwrite but rather adds, and if you try to add what's already there
> you get an error back) and there's no call to CLEAR the certificate
> validation chain -- if I want to *replace* the validation chain I have
> to destroy the context and initialize a new one from scratch.
>

N.B. that the X509_STORE_add_cert behavior when presented with a
duplicate certificate changed in commit
c0452248ea1a59a41023a4765ef7d9825e80a62b (from returning an error to
doing nothing and returning success); this will be in 1.1.1.

As to the desired behavior, there does not seem to be an API to remove
an entry from an X509_STORE.  With the above caveat about thread-safety
in mind, couldn't you just make a call to SSL_CTX_set{1}_cert_store() to
replace the X509_STORE without tearing down the whole SSL_CTX?

> It appears, however, that I *can* load over the top of a certificate
> and private key of the same type and that's acceptable.  In other
> words, if I have an RSA key/cert pair in the context and I load
> another one, the first one is replaced.  This *looks* to be working ok
> as far as I can tell and it doesn't appear to leak memory doing that
> but it's not explicitly stated that this is considered acceptable
> (rather than destroying and re-creating the context.)
>

The leaf certificate and private key are stored as arrays (for different
types of certificates) of pointers in the associated CERT structure, and
the "set" routines do not currently check for and error out if there is
already one set.

> Is my understanding correct?
>
>

Mostly ... but I am not sure that your desired workflow is wise.

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

Re: [openssl-users] cert chain file ordering question

[Benjamin Kaduk via openssl-users]

On 01/08/2018 06:33 PM, Norm Green wrote:
> This question is regarding OpenSSL 1.1.
>
> Let's say I have this trust hierarchy:
>
> RootCA
> CA1
> CA2
> CA3
> userCert
>
>
> So userCert is signed by CA3, CA3 is signed by CA2, and so on up to
> RootCA, which is a self-signed root cert.
>
> If I combine CA1,CA2,CA3 and userCert into single PEM file, chain.pem,
> the openssl verify command only verifies the chain is correct if the
> order of the file is such that the user cert occurs *last* in the
> chain as follows:
>
> CA1
> CA2
> CA3
> userCert
>
> openssl verify -CAfile RootCA.pem chain.pem
>
>
> What strikes me as odd is the order shown above is the *opposite* of
> what is needed for the SSL_CTX_user_certificate_chain_file() function,
> which requires the highest level CA to appear at the end of the file.
> From the man page:
>
> SSL_CTX_use_certificate_chain_file() loads a certificate chain from
> file into ctx. The certificates must be in PEM format and must be
> sorted starting with the subject's certificate (actual client or
> server certificate), followed by intermediate CA certificates if
> applicable, and ending at the highest level (root) CA.
> SSL_use_certificate_chain_file() is similar except it loads the
> certificate chain into ssl.
>
> Is my understanding of things correct?  Seems like there should be a
> way for the openssl command to verify a chain file which will be used
> with the
> SSL_CTX_use_certificate_chain_file() function.

But the verify command is intended to verify an *individual*
certificate, not a file containing an entire chain -- the specific chain
used is somewhat incidental.

Did you try something like (with a 1.1.0 installation):

openssl verify -CAfile RootCA.pem -untrusted chain.pem chain.pem

with the leaf certificate as the first one in chain.pem?

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Benjamin Kaduk via openssl-users]

On 11/01/2017 09:52 AM, Dave Coombs wrote:
>>> It would be nice, though, if the API provided a way to get the signer's 
>>> certificate.  There is OCSP_resp_get0_signature(), but that only returns 
>>> the bit string.  Comparable functions in other modules (eg: 
>>> X509_get0_signature(), X509_REQ_get0_signature(), 
>>> X509_CRL_get0_signature(), CMS_SignerInfo_get0_algs()) provide a way to get 
>>> any combination of bit string, algorithm, and signer cert.
>> Kind of like https://github.com/openssl/openssl/pull/4573 ?
> Quite a lot like that, yes.  Neat.  Is there any chance this might be 
> included in the 1.1.0 series?
>

Since there have been no reviews yet, it's easy enough for me to add the
"1.1.0" label and see if a reviewer is persuaded that it is relevant there.

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Benjamin Kaduk via openssl-users]

On 10/31/2017 01:05 PM, Dave Coombs wrote:
>>> If I pass in a STACK_OF(X509) *certs with only the signer's cert in it, and 
>>> NULL for X509_STORE *st since it won't be used, then I think I should get 
>>> the desired result, yes, at the cost of ocsp_find_signer(single-entry 
>>> certs) and the internal creation/destruction of an unused X509_STORE_CTX.  
>>> I'd have a small performance hit but it probably wouldn't be too bad.
>> Probably the construction of that ctx is in the wrong place. It should
>> be later in the function. I can't imagine the ocsp_find_signer() hit is
>> too great.
> Having tried this, I now see that my copying the structs from ocsp_lcl.h into 
> the external code masked the fact that the external code is getting the 
> signer's cert beforehand by directly accessing OCSP_BASICRESP->certs (and 
> ->tbsResponseData) anyway, effectively doing what ocsp_find_signer() does.  
> So it is clear that I will need to be rework this, potentially centred around 
> OCSP_basic_verify(), while remaining ignorant of the signer cert.
>
> It would be nice, though, if the API provided a way to get the signer's 
> certificate.  There is OCSP_resp_get0_signature(), but that only returns the 
> bit string.  Comparable functions in other modules (eg: 
> X509_get0_signature(), X509_REQ_get0_signature(), X509_CRL_get0_signature(), 
> CMS_SignerInfo_get0_algs()) provide a way to get any combination of bit 
> string, algorithm, and signer cert.
>

Kind of like https://github.com/openssl/openssl/pull/4573 ?

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

Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0

[Benjamin Kaduk via openssl-users]

On 10/31/2017 10:36 AM, Matt Caswell wrote:
>
> On 31/10/17 13:06, Dave Coombs wrote:
>
>> Either way, I hereby report you've got a few macros in a public
>> header that can't possibly work as things stand. :-)
> Yes - a bug. I'm tempted just to remove them.
>

That seems like the best course of action.  It's not like we're actually
removing them from the public API, since they never worked at all (on
this branch).  They were actually "removed"/desupported in the 1.1.0
release, we just didn't realize it at the time.

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

Re: [openssl-users] Passing custom CFLAGS,LDFLAGS to configure ?

[Benjamin Kaduk via openssl-users]

On 10/27/2017 07:35 AM, David Barishev wrote:
> Hello,
> I am building a custom script for building openssl for android, and i
> want to use unified headers which are enabled by default with ndk r15+.
> For this i need to pass custom CFLAGS and LDFLAGS, which i was able to
> successfully compile openssl when patching the makefile by myself.
> How to do it directly from configure ?
>

The current model is that you just pass the relevant CFLAGS and LDFLAGS
contents directly to Configure and they are "automagically" determined
to be the corresponding CFLAGS/LDFLAGS.

E.g., you could

./Configure --strict-warnings -ggdb3 -L/usr/local/lib -ltinfo
-I/opt/local/include linux-x86_64

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

Re: [openssl-users] Issue with freeing X509

[Benjamin Kaduk via openssl-users]

I thought this had become documented recently (i.e., in master only, not
even in 1.1.0), but can't find any evidence of such documentation.

SSL_CTX_use_PrivateKey() takes a reference on its pkey argument in the
same way as SSL_CTX_use_certificate(); it is safe for the local code to
free its local copy.

-Ben

On 10/17/2017 12:32 PM, Adi Mallikarjuna Reddy V wrote:
> Is this documented some where? 
>
> Also is the same true - with SSL_CTX_use_PrivateKey(ctx, evp_pkey) ?
> where I can free evp_pkey with EVP_PKEY_free()?
>
>
> Thanks
> Adi
>
> On Tue, Oct 17, 2017 at 9:50 AM, Benjamin Kaduk  > wrote:
>
> On 10/17/2017 11:27 AM, Adi Mallikarjuna Reddy V wrote:
>>> I am only worried about the following line. 
>>>
>>> SSL_CTX_use_certificate(ctx, cert)
>>>
>>> After this line is it safe to free cert object while ctx is
>>> still used later on?
>>>
>
> SSL_CTX_use_certificate(ctx, cert), on successful return, takes an
> additional reference on the supplied |cert| argument to account
> for the pointer in |ctx|.  Thus, the caller of
> SSL_CTX_use_certificate() can safely call X509_free(cert) to
> release the caller's local reference, while the |ctx| retains a
> pointer to |cert|.
>
> -Ben
>
>

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

Re: [openssl-users] Issue with freeing X509

[Benjamin Kaduk via openssl-users]

On 10/17/2017 11:27 AM, Adi Mallikarjuna Reddy V wrote:
>> I am only worried about the following line. 
>>
>> SSL_CTX_use_certificate(ctx, cert)
>>
>> After this line is it safe to free cert object while ctx is still
>> used later on?
>>

SSL_CTX_use_certificate(ctx, cert), on successful return, takes an
additional reference on the supplied |cert| argument to account for the
pointer in |ctx|.  Thus, the caller of SSL_CTX_use_certificate() can
safely call X509_free(cert) to release the caller's local reference,
while the |ctx| retains a pointer to |cert|.

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

Re: [openssl-users] Issue with freeing X509

[Benjamin Kaduk via openssl-users]

You only asked about freeing the X509, which is safe in this situation.

It is not safe to free the SSL_CTX if you want to use it again later --
remove this SSL_CTX_free(ctx) call and put one in your program's cleanup
instead.

-Ben

On 10/17/2017 11:08 AM, Adi Mallikarjuna Reddy V wrote:
> Forgot to mention that the ssl_ctx is going to be used by another
> thread later. When I do x509_free, the handshake doesn’t finish.
>
> I see a crash in ssl_accept.
>
> Thanks 
> Adi
>
> On Tue, Oct 17, 2017 at 8:41 AM Benjamin Kaduk  > wrote:
>
> On 10/17/2017 08:39 AM, Adi Mallikarjuna Reddy V wrote:
>> Hi,
>>
>> If I have an X509 object and is created
>> using PEM_read_bio_X509_AUX(), then Can I free X509 right after
>> the completion of PEM_read_bio_X509_AUX()?
>>
>>                                BIO *cert_bio = BIO_new(BIO_s_mem());
>>                                 X509 *cert = X509_new();
>>                                 BIO_puts(cert_bio, cert_str.c_str());
>>                                 cert =
>> PEM_read_bio_X509_AUX(cert_bio, , NULL, NULL);
>>                                 if ( (cert != NULL) &&
>> SSL_CTX_use_certificate(ctx, cert) < 1) {
>>                                         SSL_CTX_free(ctx);
>
> Yes.
>
> -Ben
>
>
>>                                         return NULL;
>>                                 }
>>                                
>>                                 if(cert_bio !=NULL) {
>>                                         BIO_free(cert_bio);
>>                                 }
>>                                 if(cert != NULL) {
>>                                         X509_free(cert); //is it
>> needed?
>>                                 }
>>
>>
>> Thanks
>> Adi
>>
>>
>
> -- 
> Sent from Mobile

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

Re: [openssl-users] Issue with freeing X509

[Benjamin Kaduk via openssl-users]

On 10/17/2017 08:39 AM, Adi Mallikarjuna Reddy V wrote:
> Hi,
>
> If I have an X509 object and is created using PEM_read_bio_X509_AUX(),
> then Can I free X509 right after the completion
> of PEM_read_bio_X509_AUX()?
>
>                                BIO *cert_bio = BIO_new(BIO_s_mem());
>                                 X509 *cert = X509_new();
>                                 BIO_puts(cert_bio, cert_str.c_str());
>                                 cert = PEM_read_bio_X509_AUX(cert_bio,
> , NULL, NULL);
>                                 if ( (cert != NULL) &&
> SSL_CTX_use_certificate(ctx, cert) < 1) {
>                                         SSL_CTX_free(ctx);

Yes.

-Ben

>                                         return NULL;
>                                 }
>                                
>                                 if(cert_bio !=NULL) {
>                                         BIO_free(cert_bio);
>                                 }
>                                 if(cert != NULL) {
>                                         X509_free(cert); //is it needed?
>                                 }
>
>
> Thanks
> Adi
>
>

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

Re: [openssl-users] How to increase the priority of some cipher ?

[Benjamin Kaduk via openssl-users]

I am curious about this statement that "(EC)DHE cost much more resources
than RSA".  In particular, ECDHE is supposed to be less
computation-intensive than RSA for a given security level, so it would
be interesting to hear what your setup is where the reverse is supposed
to be observed.

-Ben

On 09/26/2017 03:44 AM, 李明 wrote:
> just find it, 
>  server respect client's cipher preference  by default,  
>  it selects the suite preferred by client among the cipherlist that
> both the client and server support.
>  so it's not enough to just increase RSA cipher priority on server
> side ,  
>  SSL_OP_CIPHER_SERVER_PREFERENCE will make the server select the suite
> that itself most prefer among the cipherlist that both the client and
> server support.
>
>
> 在 2017-09-26 15:15:10，"李明"  写道：
>
> Hello, 
>    Currently, openssl prefer (EC)DHE handshakes over plain RSA,
> but (EC)DHE cost much more resouces than RSA.
>    In order to get higher performance , I want to  prioritize
> RSA related ciphers, does anyone knows how to do it.
>    
>    I have tried cipherlist "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL" ,
> it looks fine in openssl command line
>    ./openssl ciphers -v 'RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL' 
> AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA 
> Enc=AESGCM(256) Mac=AEAD
> AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA 
> Enc=AESGCM(128) Mac=AEAD
> AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256) 
> Mac=SHA256
> AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128) 
> Mac=SHA256
> AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256) 
> Mac=SHA1
> AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128) 
> Mac=SHA1
> ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA
> Enc=AESGCM(256) Mac=AEAD
>
>  but, after SSL_CTX_set_cipher_list(ctx,
> "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL")  in my application, it
> didn't work, the first choice is still ECDHE-RSA-AES256-GCM-SHA384
>
>
> 【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>
>  
> 
> 
>    
>
>
>
> 【网易自营|30天无忧退货】仅售同款价1/4！MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元>>
>  
> 
>    
>
>

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

Re: [openssl-users] s_server and explicit dhparam

[Benjamin Kaduk via openssl-users]

On 09/21/2017 10:57 PM, Le Van Gong, Hubert wrote:
> Hi Ben,
>
> Ah, good catch. Maybe the doc should be updated to mention that fact.
> Does anyone know if this is on the roadmap?

The documentation could not really get updated more easily than the
code, and I committed the needed fix yesterday, so we're in as good a
shape as we can reasonably expect to be.

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

Re: [openssl-users] s_server and explicit dhparam

[Benjamin Kaduk via openssl-users]

On 09/21/2017 03:30 AM, Le Van Gong, Hubert wrote:
> Hi there,
>
> I'm trying to run opensslin server modeand leverage non-default DH
> params with the following command:
> sudo openssl s_server -cert server_cert.pem -dhparam dhparam_2.pem
> -tls1_3 -accept 443
>
> Where the dhparam_2.pem file contains the 2 DH params I want to use.
> However, I keep getting the following error message: Error with
> command: "-dhparam dhparam_2.pem"
>
> I'm using OpenSSL 1.1.1-dev and see the same behaviour on macOS or linux.
>
> Any idea as to what it is I am missing?

It seems that what is missing is actual support in the code,

diff --git a/apps/s_server.c b/apps/s_server.c
index c45256a..d54909a 100644
--- a/apps/s_server.c
+++ b/apps/s_server.c
@@ -795,6 +795,7 @@ const OPTIONS s_server_options[] = {
 {"pass", OPT_PASS, 's', "Private key file pass phrase source"},
 {"dcert", OPT_DCERT, '<',
  "Second certificate file to use (usually for DSA)"},
+    {"dhparam", OPT_DHPARAM, '<', "DH parameters file to use"},
 {"dcertform", OPT_DCERTFORM, 'F',
  "Second certificate format (PEM or DER) PEM default"},
 {"dkey", OPT_DKEY, '<',


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

Re: [openssl-users] Openssl failed to decrypt certificate without \r\n

[Benjamin Kaduk via openssl-users]

On 09/18/2017 12:59 AM, Viktor Dukhovni wrote:
>> On Sep 17, 2017, at 10:23 PM, Zhang, Lily (USD)  wrote:
>>
>> Would you help me to take a look this certificate issue?
>> In order to send out the file, I added ".txt" in the file name. Please 
>> remove it before test it.
>>
>> Leaf_no_rn.cer doesn't have \r\n in the BASE64 string, it can't be parsed by 
>> openssl.
>> Leaf_with_rn.cer is the same as Leaf_no_rn.cer, but it has \r\n in BASE64 
>> string. 
>> Both the attached two certificates can be parsed by Windows.
> This is expected, the OpenSSL PEM file reader does not support
> input lines with IIRC more than 64 bytes.  PEM files are not
> supposed to have longer lines.
>

The current code in master should not have a particular limit on line
lengths for *certificates* -- in test/recipes/04-test_pem_data we have
files with 1025 characters on a line, and only use a 256-byte buffer
when reading.  The PEM format does specify a
64-(base64-)characters-per-line limit when the additional PEM
encryption/etc. features are used, but certificates do not use that
feature and do not have a line length restriction.  Perhaps Lily should
specify what version of OpenSSL is in use.

-Ben


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

Re: [openssl-users] SSL_CTX_set_cipher_list returns failure for DHE-DSS-AES256-GCM-SHA384

[Benjamin Kaduk via openssl-users]

On 09/06/2017 12:02 AM, mahesh gs wrote:
> Hi All,
>
> I am using openssl version 01.01.00f for providing TLS and DTLS
> security for TCP and SCTP connection for our application. I have query
> regarding the "Ciphers" that are accepted by the
> SSL_CTX_set_cpiher_list API. The list of ciphers that are supported by
> openssl version 01.01.00f that is output of command "openssl ciphers
> -v" is as listed down below. When i try to set these ciphers through
> API "SSL_CTX_set_cipher_list" returns success for some and failure for
> some other ciphers.
>
> For example if i set "ECDHE-RSA-AES256-GCM-SHA384" API returns success
> but if i set "DHE-DSS-AES256-GCM-SHA384" or "RC4-MD5" API returns
> failure. My query is what are the accepted ciphers ? and what is the
> reason behind not accepting some of them?
>

OpenSSL 1.1.0 added a concept of "security level" for ciphers; see
https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_security_level
for which levels correspond to bits of security, prohibited message
digests, etc.

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

Re: [openssl-users] SSL_CTX_set_msg_callback does not invoke for received change_cipher_spec

[Benjamin Kaduk via openssl-users]

On 08/14/2017 11:30 PM, Vakul Garg wrote:
>
> Hi
>
>  
>
> I am using openssl s_server and s_client with ‘-msg’ option to track
> tls1.2 records being exchanged.
>
> I notice that while transmitted change_cipher_spec record gets printed.
>
> But the reception of change_cipher_spec record is not reported.
>
>  
>
> For the received change_cipher_spec record, the callback (registered
> using SSL_set_msg_callback_arg) gets invoked only for record header,
> but not for the record content.
>
> So there is no callback for received SSL3_RT_CHANGE_CIPHER_SPEC. For
> the transmitted change_cipher_spec record, things are fine.
>

There is no variable content in a ChangeCipherSpec message -- a single
byte of value 1.  Are you trying to argue that the callback still ought
to be invoked out of some philosophical sense of consistency? 

In any case, if I remember correctly, ChangeCipherSpec is processed at a
very low layer and isn't propagated up to the layer that invokes the
message callback, and if one looks at the tradeoff between extra
complexity to propagate it up versus not having a message callback event
for it, there are some reasonable reasons to prefer the status quo.

>  
>
> Further, message callback invocation is correct for DTLS1.2 case as well.
>
>

(Just with respect to ChangeCipherSpec?)

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

Re: [openssl-users] session resumption tls1.2/tls1.3

[Benjamin Kaduk via openssl-users]

On 07/25/2017 06:05 PM, Neetish Pathak wrote:
>
>
> Please provide any comments if you have or how I should go about
> debugging it. Correct me if I am doing it wrong
>

I don't really have any good suggestions for debugging it.  It might be
interesting to run in a debugger and collect full backtraces on each
entry to ssl3_write_pending() on the server.

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

Re: [openssl-users] Apache/OpenSSL1.1 sending Fatal, Description: Handshake Failure' packet to WebDAV client

[Benjamin Kaduk via openssl-users]

On 07/27/2017 02:49 PM, Todd Blum wrote:
> SSLv2 Record Layer: Client Hello

SSLv2-compatible ClientHello is pretty old and probably unneeded

> [Version: SSL 2.0 (0x0002)]
> Length: 46
> Handshake Message Type: Client Hello (1)
> Version: SSL 3.0 (0x0300)
> Cipher Spec Length: 21
> Session ID Length: 0
> Challenge Length: 16
> Cipher Specs (7 specs)
> Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x0a)
> Cipher Spec: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13)
> Cipher Spec: TLS_RSA_WITH_RC4_128_SHA (0x05)
> Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x04)
> Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080)
> Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0)
> Cipher Spec: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0xff)
> Challenge

All of those are pretty bad ciphers; can you update the client to use
better ones?

Otherwise you might have to do something like include @SECLEVEL=0 in the
cipher spec on the server to enable the weak ciphers.

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

Re: [openssl-users] EDDSA certificates

[Benjamin Kaduk via openssl-users]

On 07/27/2017 09:18 AM, Robert Moskowitz wrote:
> Rich,
>
> Meant to ask you about this at IETF.
>
> Given draft-ietf-curdle-pkix-05.txt sec 10, is there openssl code to
> produce these???
>

There is code to validate them, per commit
4328dd41582bcdca8e4f51f0a3abadfafa2163ee.  I didn't look hard enough to
find how to generate them, but it ought to be there too.

> And, relatedly, what do you think about CBOR encoding rather than
> ASN.1?  Kill ASN.1 in constrained devices and save on transmission costs?

It seems hard to shift a big ecosystem and introduce risk of
incompatibility, but I haven't really thought about it.

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

Re: [openssl-users] private key difference: openssl genrsa vs opnessl req newkey

[Benjamin Kaduk via openssl-users]

On 07/26/2017 10:13 AM, Michele Mase' wrote:
> During the generation of x509 certificates, both commands give the
> same results:
>
> Command "a": openssl req -nodes -newkey rsa:2048 -keyout example.key
> -out example.csr -subj "/C=GB/ST=London/L=London/O=Global
> Security/OU=IT Department/CN=example.com
> "
> Command "b": openssl genrsa -out example.key
>
> Both commands give me a private key without password, a key that is
> not encrypted.
> To remove the passphrase from private key, I use the
> Command "c":openssl rsa -in example.key -out example2.key
>
> The command "c" against the example.key generated by command "a",
> gives the same private key with different content between --BEGIN RSA
> and --END RSA. Simply, try the following:
> diff example.key example2.key, the files are different.
>
> The command "c" against example.key generate by the command "b"
> produces the same file. No differences.
>
> Why?
> Perhaps I missed something in openssl manual ... :(
> These differenced gave me troubles using custom certificates in some
> software.
> Any suggestion?

The output from openssl req includes an additional layer of encoding and
the rsaEncryption OID around the actual key parameters, as can be seen
using openssl asn1parse.  The conversion with 'openssl rsa' removes that
extra encoding.

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

Re: [openssl-users] session resumption tls1.2/tls1.3

[Benjamin Kaduk via openssl-users]

[Matt's reply is likely to be high latency]

On 07/24/2017 08:53 PM, Neetish Pathak wrote:
>
>
> On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell  > wrote:
>
>
>
> On 18/07/17 22:27, Neetish Pathak wrote:
> > Hi ,
> > thanks Matt, this is helpful
> >
> >
> > One more query on how I can enable 0.5 RTT data from the server
> side. It
> > is mentioned in TLS 1.3 specification. I thought it can be
> implemented
> > by sending early data  from server side after reading the early
> data.
>
> That is correct, and is as documented on this page:
>
> https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html
> 
> 
>
>
>
> Thanks Matt
> To send 0.5 RTT data I m sending the early_data from the server side
> just after the early_read data. But when I see the wire-shark logs, I
> see that the server data is sent only once the complete handshake has
> taken place. (which is the same as using SSL_write after SSL_accept).
> I am performing following steps on client and server respectively as
> per understanding developed from previous discussions
>
> *Pseudocode for client*
> *
> *
> tcp_connect
>
> write_early(data)
>
> ssl_connect
>
> if(early_data_write_failed){
>   ssl_write(data)
> }
>
> ssl_read
>
>
> *Pseudocode for server*
> *
> *
> tcp_accept
> *
> *
> read_early{
>
>  if(read_early_success){
>   write_early(data)
>   }
> }
>
> ssl_accept
>
> if(read_early_fail){
> ssl_read
> ssl_write(data)
> }
>
>
> I am measuring latency on the *client side* from TCP connection start
>  till it completes the read (ssl_read returns) (analogues to making a
> request from client and reading response).
> Please suggest what may be going wrong basically with these queries
>
> 1) Why is there no difference (or negligible) in latencies when i use
> early write and then later ssl_read compared to when I execute normal
> write/read on the client side
>

Maybe I misunderstand the question, but isn't this is just a natural
consequence of the server (mis)behavior in (2)?

> 2) Why does the server not send data (for early write) after the
> server Hello(and other encrypted message) message even when
> early_write succeeds on server side. Why does server wait to finish
> the handshake. I know it waits because I see client sending encrypted
> messages after server hello message before my intended application
> data gets sent from server. These encrypted messages from the client
> side are the usual messages from the client side for handshake completion.
>

>From a quick look through the state machine code, this is supposed to
work.  But someone would probably have to instrument the code (e.g.,
with printf) to tell why the delay is being introduced.  I don't think I
have the availability to do so in the near future, myself.

> 3) Also, the performance of TLS 1.3 using early data or resumption is
> worse than TLS 1.2 resumption on LAN. I see on wire-shark that
> encrypted messages get exchanged in TLS 1.3 during handshake which are
> plaintext in TLS 1.2. I think that causes extra latency. So can we say
> that TLS 1.3 resumption is not recommended for LAN for performance
> enhancement when compared with TLS 1.2 resumption. On WAN, I see TLS
> 1.3 resumption at par with TLS 1.2 resumption and full handshake
> better for TLS 1.3.
>

It seems like it hasn't really sunk in for you that TLS 1.3 is a
seriously different protocol than TLS 1.2, and it provides stronger
security properties, remediating weaknesses of TLS 1.2.  So no, we
should not recommend TLS 1.2 resumption on the LAN -- we should
recommend the more secure option!  If you continue to believe that
latency trumps everything else, you could experiment with
SSL_OP_ALLOW_NO_DHE_KEX to cut out some of the heavier-weight asymmetric
crypto, though it looks like you'd want to patch
ssl/statem/extensions_clnt.c to not send TLSEXT_KEX_MODE_KE_DHE, as I
don't see a way to configure the server to prefer the non-DHE PSK key
exchange.

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

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

[Benjamin Kaduk via openssl-users]

On 06/25/2017 03:06 PM, we...@infotech.de wrote:
> Dear OpenSSSL users,
>
> we recently came across a certificate with OID: id-RSASSA-PSS aka
> rsassaPss in x509 subjects public key AlgorithmIdentifier.
>
> According to rfc4056 it is legitimate to use rsaEncryption or
> id-RSASSA-PSS as OID for the subject public key.
>
> But when listing the certs's contents or during verification, openssl
> v1.0.2h bails out:
>> 12392:error:0609E09C:digital envelope
>> routines:PKEY_SET_TYPE:unsupported algorithm:.\crypto\evp\p_lib.c:231:
>> 12392:error:0B07706F:x509 certificate
>> routines:X509_PUBKEY_get:unsupported
>> algorithm:.\crypto\asn1\x_pubkey.c:148:
> which is caused by failing to assign the proper ameth structure to the
> key.
>
> Later in x_pubkey.c, only the method pub_decode is needed, which seems
> to work for rsassa pubkeys.
> So may we assign the same methods associated to rsaEncryption in this
> case or are we breaking other functionality by doing so?

It might be more interesting to just try using the current OpenSSL
master branch (or a snapshot), which has more proper RSA-PSS support.

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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Benjamin Kaduk via openssl-users]

On 06/19/2017 04:12 PM, Neetish Pathak wrote:
>
>
> On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak  > wrote:
>
> Hi Matt,
> Thanks
> Could you help with following queries
>
> 1) On the blogpost for TLS1.3, you mentions the following in the
> session section
> The specification recommends that applications only use a session
> once (although this is not enforced). For this reason some servers
> send multiple session messages to a client. To enforce the “use
> once” recommendation applications could
> use |SSL_CTX_remove_session()| to mark a session as non-resumable
> (and remove it from the cache) once it has been used.
>
> I am a bit confused here as to why "use once" is recommended. How
> will resumption be ensured then ? I get a PSK in first connection
> and use it again for all the other connections.
>

"use once" is recommended in a limited circumstance, to prevent an
attacker listening on the network from associating the (multiple)
resumed sessions as being derived from the initial session.
This is a new possibility in TLS 1.3, since in TLS 1.2 the session
ticket was given to the client in cleartext (and presented back to the
server in cleartext), so all uses of the ticket were traceable back to
the original connection and linkable to each other.

Using a given ticket more than once in TLS 1.3 just brings things back
to basically the TLS 1.2 state in terms of linkability; it's not a
catastrophic failure or anything like that.

>
> On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  > wrote:
>
>
>
> Yes Matt, when I switch to remote machines and test my application
> programs, I see that TLS 1.3 is faster than TLS 1.2 in the first
> connection (around same time as resumption time in TLS 1.2) itself and
> there is marginal or no improvement in the subsequent connections even
> on using resumption. Does this mean that resumption in TLS 1.3 is
> bringing not much benefit in terms of latency. It makes sense because
> round trips count for resumption or no resumption is 1 in TLS 1.3. 
>
> The only benefit with resumption is that the client can now send
> zero-RTT data. (early data). However, if we consider the overall
> latency in handshake, it is going to be the same equivalent to 1 round
> trip.
> Is my understanding correct ?
>
> Is there any way to enable early data or it gets activated by default
> once the pre-shared keys are available at both the client and server
> ends ?
>

No no no no no, many times no.
You really must not blindly enable early data without a proper protocol
analysis to determine what would happen if an attacker replayed the
early data millions of times, as is possible with the current TLS 1.3
draft specification.  There are a lot of ways to hurt yourself and your
users with it, and I strongly recommend against trying to enable it just
because it looks faster.
(There are separate APIs from the normal read/write APIs to use early
data, to make you explicitly think about whether it's safe when adding
support to an application.)


> I believe session resumption as a concept doesn't hold that much value
> from TLS 1.3 onwards since 1-RTT is directly achieved in TLS 1.3 first
> connection. Do you agree?
>

No.  Resumption saves on transferring (and validating!) certificates and
can be done without incurring the cost of an additional diffie-hellman
exchange, among other things.

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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Benjamin Kaduk via openssl-users]

On 06/16/2017 05:36 PM, Matt Caswell wrote:
>> The security properties of such "external" PSKs are substantially
>> different than the "ephemeral" PSKs used in resumption flows.
> Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE
> based secret (assuming a suitable kex_mode is used). What do you see as
> the concern?

The risk of accidentally using psk_ke instead of psk_dhe_ke is
noticeable, and in terms of concrete differences, there are additional
requirements on external PSKs that the KDF and PSK identity must remain
fixed across uses.  That, combined with the potential for insufficient
entropy during key generation (mentioned in section 2.2 of draft-20)
seem to provide more openings for cryptographic attacks than for the
full resumption flow.  It is probably fine for uses where the other
properties of external PSKs are needed, but I'm not sure that the
risk/reward balance favors using it just to get a speedup -- TLS 1.3
resumption should already be pretty fast.

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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Benjamin Kaduk via openssl-users]

On 06/16/2017 01:58 PM, Neetish Pathak wrote:
> Hello 
> Thanks
> I tried reading  some content from the server side and I observed the
> new_session_cb getting invoked in that case on the client side. I
> understand that may be due to delayed NewSession info transfer from
> server side to client side. But it is helpful for saving the session
> info on the client side. (Thanks Matt for your input)
>
> However, now I have two concerns
>
> 1) I see that latency for handshake with session resumption in TLS 1.3
> has not improved as much as it improves for TLS 1.2
> With TLS 1.3, I observed that resumption brings down the connection
> time from 2.5 ms to 1.2-1.3 ms
> while with TLS 1.2 (using either session IDs or tickets), the
> connection time reduces from 2.5 ms to 0.5-0.6 ms.
>
> The whole code is similar for running the two experiments with only
> max TLS version changed. Can someone comment on the latency
> measurements for the two cases.
> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please
> comment.
>

Are you seeing a HelloRetryRequest in the resumption flow?  That would
add an additional round trip.  (Your numbers in milliseconds are of
course not transferrable to other systems; round-trips is an easier to
understand number.)  RFC 5246 and draft-ietf-tls-tls13-20 both have
message-flow diagrams that show the number of round trips in various
handshake flows.

> 2) PSK (Pre-shared keys) for resumption are highly emphasized in TLS
> 1.3 RFC. How do we generate pre-shared keys in advance even without
> making the first connection. Can someone guide me in the right direction.
>

The security properties of such "external" PSKs are substantially
different than the "ephemeral" PSKs used in resumption flows.  I do not
think I can recommend their use in the general case when resumption
flows are available.
Regardless, external PSK support is still a work in progress:
https://github.com/openssl/openssl/pull/3670

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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Benjamin Kaduk via openssl-users]

On 06/09/2017 07:54 PM, Neetish Pathak wrote:
>
> On Thu, Jun 8, 2017 at 3:45 PM, Matt Caswell  > wrote:
>
>
>
> On 08/06/17 23:12, Neetish Pathak wrote:
> > Thanks.
> > I had one query regarding the TLS 1.3 implementation on server
> side. I
> > have a simple client server program with session resumption
> working with
> > TLS 1.2.
> > When I use TLS 1.3, I see that server hello message has a malformed
> > packet.
>
> How do you know it is malformed? The format of the ServerHello message
> has changed in TLSv1.3, so if you expect it to look like a TLSv1.2
> ServerHello then you will be surprised.
>
>
>
> *I know the ServerHello is malformed from the WIRESHARK LOGS. It shows
> an exception for the ServerHello with malformed packet message.*

It is quite likely that your version of wireshark does not know how to
properly decode the TLS 1.3 ServerHello.  When interpreted as a TLS 1.2
ServerHello, it is expected to show as malformed, because the protocol
formats are different between the two protocols.  This is what Matt was
trying to say.

Someone could look at the raw hex dump of the packet and decode it
manually as a TLS 1.3 ServerHello to confirm whether it is actually
malformed or just a wireshark error.

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

Re: [openssl-users] Using weak ciphers in OpenSSL v 1.1.0e client

[Benjamin Kaduk via openssl-users]

On 06/07/2017 11:13 AM, gerritvn wrote:
> We are using OpenSSL in a terminal emulation product.
> We recently upgraded from OpenSSL v 1.0.2g to OpenSSL v 1.1.0e.
> Some servers we connect to do not support any of the strong ciphers which
> are compiled by default in OpenSSL v 1.1.0e and returns an alert with
> "handshake error". 
> We recompiled with the option "enable-weak-ssl-ciphers", but that does not
> solve the problem.
> With OpenSSL v 1.0.2g one specific server selected the Cipher Suite:
> TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) which is shown as DES-CBC3-SHA by
> OpenSSL
> Listing ciphers with our OpenSSL 1.1.0e "enable-weak-ssl-ciphers" build with
> the command:
> openssl ciphers -v "ALL:@SECLEVEL=0" 
> shows this entry:
> DES-CBC3-SHASSLv3 Kx=RSA  Au=RSA  Enc=3DES(168) Mac=SHA1
> This cipher is, however, not offered in the Client Hello when our client
> opens the connection.
>
> What do we need to add to our program to get our client to offer the weak
> ciphers as well as the strong ones?
>


https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_security_level.html

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

Re: [openssl-users] Dumb question about DES

[Benjamin Kaduk via openssl-users]

On 05/11/2017 03:17 PM, Scott Neugroschl wrote:
>
> So if I’m using 1.0.2, and want to deprecate 3DES, I need to do that
> as part of my build?
>
>

Yes.

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

Re: [openssl-users] Dumb question about DES

[Benjamin Kaduk via openssl-users]

The triple-DES ciphers are not part of DEFAULT in 1.1.0e(what I happened
to check).
Though, the specific list of ciphers there does not quite match with
your list below, so you should double-check if necessary.

-Ben

On 05/11/2017 01:13 PM, Scott Neugroschl wrote:
>
> OK.  Are the 3DES CBC ciphers still part of DEFAULT?
>
>  
>
> *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On
> Behalf Of *Benjamin Kaduk via openssl-users
> *Sent:* Thursday, May 11, 2017 9:18 AM
> *To:* openssl-users@openssl.org
> *Subject:* Re: [openssl-users] Dumb question about DES
>
>  
>
> Those ciphers are triple-DES, not single-DES.  (The "CBC3" gives it
> away ... well, not exactly.)
> The single-DES ciphers were removed in release 1.1.0 (they are
> included in the "40 and 56 bit cipher support removed from libssl"
> item in the release notes), though the raw crypto primitives remain in
> libcrypto.
>
> -Ben
>
> On 05/11/2017 11:07 AM, Scott Neugroschl wrote:
>
> Has DES been deprecated in OpenSSL?  If so, what release?  In
> particular the following ciphers
>
>  
>
>   0.19 EDH-DSS-DES-CBC3-SHA
>
>   0.22 EDH-RSA-DES-CBC3-SHA
>
> 192.13 ECDH-RSA-DES-CBC3-SHA
>
> 192.3  ECDH-ECDSA-DES-CBC3-SHA
>
> 192.18 ECDHE-RSA-DES-CBC3-SHA
>
> 192.8  ECDHE-ECDSA-DES-CBC3-SHA
>
>  
>
>  
>
>  
>
> ---
>
> Scott Neugroschl | XYPRO Technology Corporation
>
> 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone
> 805 583-2874|Fax 805 583-0124 |
>
>  
>
>  
>
>
>
>  
>
>
>

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

Re: [openssl-users] Dumb question about DES

[Benjamin Kaduk via openssl-users]

Those ciphers are triple-DES, not single-DES.  (The "CBC3" gives it away
... well, not exactly.)
The single-DES ciphers were removed in release 1.1.0 (they are included
in the "40 and 56 bit cipher support removed from libssl" item in the
release notes), though the raw crypto primitives remain in libcrypto.

-Ben

On 05/11/2017 11:07 AM, Scott Neugroschl wrote:
>
> Has DES been deprecated in OpenSSL?  If so, what release?  In
> particular the following ciphers
>
>  
>
>   0.19 EDH-DSS-DES-CBC3-SHA
>
>   0.22 EDH-RSA-DES-CBC3-SHA
>
> 192.13 ECDH-RSA-DES-CBC3-SHA
>
> 192.3  ECDH-ECDSA-DES-CBC3-SHA
>
> 192.18 ECDHE-RSA-DES-CBC3-SHA
>
> 192.8  ECDHE-ECDSA-DES-CBC3-SHA
>
>  
>
>  
>
>  
>
> ---
>
> Scott Neugroschl | XYPRO Technology Corporation
>
> 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805
> 583-2874|Fax 805 583-0124 |
>
>  
>
>  
>
>
>

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

Re: [openssl-users] NMAKE error

[Benjamin Kaduk via openssl-users]

On 05/01/2017 10:02 AM, James Condren wrote:
>
> Getting the following error when attempting to make:
>
> NMAKE : fatal error U1073: don't know how to make
> '"crypto\include\internal\bn_conf.h.in"'
>
> Stop.
>
>  
>
> Here’s the lines from the makefile that are creating the error:
>
> crypto\include\internal\bn_conf.h:
> "crypto\include\internal\bn_conf.h.in" "configdata.pm"
>
>"$(PERL)" "-I$(BLDDIR)" -Mconfigdata "util\dofile.pl" \
>
>"-omakefile" "crypto\include\internal\bn_conf.h.in"
> > $@
>
>  
>
>  
>
> If I remove '"crypto\include\internal\bn_conf.h.in"', it then gives me
> the following error:
>
> NMAKE : fatal error U1073: don't know how to make '".\Configure"'
>
> Stop.
>
>


What version of openssl?  What steps did you take prior to running nmake?

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

Re: [openssl-users] Multithreading: Global locks causing bottleneck in parallel SSL_write calls

[Benjamin Kaduk via openssl-users]

On 04/12/2017 05:54 AM, dipakgaigole wrote:
> Hi,
>  
> I have a windows multi-threaded SSL server application which handles
> each client request in a new thread. The Server handles different
> types of requests. One of the request type is like “send file” where
> server thread has to read a file from local filesystem and send the
> content to the client.
> Server configurations:
> FIPS: Enabled
> SSL Protocol: TLSv1.2
> Cipher: AES256-SHA

The OpenSSL PRNG story is currently not so great, yes.
But maybe you should try without FIPS, and also with a different
cipher?  AES256-SHA is both CBC and SHA1, neither of which is really a
current best practice.

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

Re: [openssl-users] [openssl-dev] verify depth behavior change from 1.0.2 to 1.1.0?

[Benjamin Kaduk via openssl-users]

On 04/04/2017 10:39 AM, Viktor Dukhovni wrote:
>> On Apr 4, 2017, at 10:41 AM, Short, Todd via openssl-users 
>>  wrote:
>>
>> Ben Kaduk:
>>
>> Do we know the values that are being passed to SSL_CTX_set_verify_depth()
>> match the -verify_depth argument, or do they differ?  If they differ, do
>> identical arguments to the function behave the same in 1.1.0 and 1.0.2?
> The "-verify_depth" argument to verify(1) just calls 
> SSL_CTX_set_verify_depth(3)
> with the given depth value.  In OpenSSL 1.1.0, this sets a limit on the
> intermediate CA count and returns sensible errors when the depth limit is
> exceeded.

(Pedantic note: the apps call X509_VERIFY_PARAM_set_depth() directly,
and s_client goes on to use SSL_CTX_set1_param().)  But the answer to
the actual question asked is the same, the depth argument used for
verification is just the one passed on the command line.  Behavior
differences stem in the library.

>> Viktor:
>>
>> What we’re getting at here, is that this appears to be a potentially
>> significant behavioral change. We want to understand it better.
> The code no longer returns misleading errors, and is better documented
> in verify(3), but it seems I missed additional requisite documentation
> updates in SSL_CTX_set_verify_depth(3).  It would be great if someone
> volunteered to complete the documentation update.
>

I have it on my list of things to look at if there is free time
available (which is hardly guaranteed).

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

Re: [openssl-users] Query regarding upgrading TLS compatibility

[Benjamin Kaduk via openssl-users]

On 04/03/2017 04:42 AM, Hegde, Harsha wrote:
>
> Hi,
>
> I have an query regarding TLS compatibility used in my application.
> Currently we are using TLS1.2 to connect to a third party sever. Is
> there any way to always use the highest TLS available version without
> modifying or recompiling the application code whenever there is any
> new version of TLS released.
>
>

The closest you can come is to use TLS_method() (or the client- or
server-specific version of it), which will prefer the highest version
supported by the library, but also be able to use older versions if
needed in order to interoperate with the peer.  It's not entirely clear
whether your question was about restricting to specifically the highest
version, to the exclusion of older versions.

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

Re: [openssl-users] openssl-compat patch for OpenSSL 1.0.2 and below?

[Benjamin Kaduk via openssl-users]

On 04/02/2017 07:42 PM, Jeffrey Walton wrote:
> I was looking at Kurt Roeckx 's patches for OpenSSH at
> https://github.com/openssh/openssh-portable/pull/48/files. See
> libcrypto-compat.h and libcrypto-compat.c.
>
> Are the source files distributed by OpenSSL? If so, where is the download?
>
> If not, can the OpenSSL project consider adding them. They are very
> useful for managing projects that depend on older and newer OpenSSL
> libraries. OpenSSL taking on the responsibility would help ensure
> consistency and quality.
>

The topic of backwards-compat headers has come up a few times previously
on the list; with the resolution being a call for some external
contributor to host and maintain them.

So, no, OpenSSL does not distribute such things.

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