Re: Fwd: Requesting to share OpenSSL commands to increase G Pramaeter length in DHE Cipher.

[Kurt Roeckx]

On Wed, Mar 03, 2021 at 04:14:17PM +0530, Vadivel P wrote:
> Hi OpenSSL team,
> 
> We are looking for the command line option or any other way to increase the
> DHE G Parameter length to 256 bytes, by default it's 2 now, we need to
> modify it as 256 byte on the server side for our testing either by command
> line or with any other option.we need it for our local server bring up.
> Please support us.

The default generator is the value 2, not 2 bytes. And if you
really need to generate your own DHE keys, using the generator 2
makes perfect sense. Using a larger generator does not add any
security, it just makes it slower.

But I really suggest that you use standardized parameters like the
ones from RFC7919. Note that all the generators in that RFC also
use 2 as the generator.

OpenSSL has no support for generating safe primes with a 256
byte/2048 bit generator.

Re: Question about SSL_ERROR_WANT_WRITE

[Kurt Roeckx]

On Thu, Dec 10, 2020 at 05:14:00PM +0200, Cosmin Apreutesei wrote:
> Hello,
> 
> I have a question regarding SSL_write() and returning SSL_ERROR_WANT_WRITE
> from the write callback.
> 
> _After_ SSL_write() returns with SSL_ERROR_WANT_WRITE (because my write
> callback returned  SSL_ERROR_WANT_WRITE), can I _then_ send the data given
> to the calback and then call SSL_write() again (with the same arguments)
> and then in the second call to the callback return the number of bytes
> written? Is that a supported use of the API? (I'm asking because that's the
> only way I can use the API, I can't send the data inside the callback, I
> need to send it outside the callback, see below for why).
> 
> In other words, is it guaranteed that on that second call to  SSL_write(),
> SSL will want to send the exact same data that it tried before when it
> failed, and not change its mind about it wants to send? Because
> technically, since SSL_ERROR_WANT_WRITE implies that "no data was sent",
> the state machine might as well advance and send something different at a
> later time (because it received data or something inside expired or
> whatever).

I don't fully understand your question, but the manpage says:

WARNINGS
   When a write function call has to be repeated because
SSL_get_error(3) returned SSL_ERROR_WANT_READ or
SSL_ERROR_WANT_WRITE, it must be repeated with the same arguments.
The data that was passed might have been partially processed.
When SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER was set using
SSL_CTX_set_mode(3) the pointer can be different, but the data and
length should still be the same.

Does that answer your question?


Kurt

Re: Testing TLS 1.0 with OpenSSL master

[Kurt Roeckx]

On Mon, Aug 24, 2020 at 01:38:41PM -0700, John Baldwin wrote:
> On 8/18/20 9:49 AM, Matt Caswell wrote:
> > 
> > 
> > On 17/08/2020 18:55, John Baldwin wrote:
> >> 1) Is 'auth_level' supposed to work for this?  The CHANGES.md change
> >>references SSL_CTX_set_security_level and openssl(1) claims that
> >>'-auth_level' changes this?  Is the CHANGES.md entry wrong and only
> >>SECLEVEL=0 for the ciphers work by design?
> > 
> > openssl(1) says this about auth_level:
> > 
> > "Set the certificate chain authentication security level to I.
> > The authentication security level determines the acceptable signature
> > and public key strength when verifying certificate chains."
> > 
> > However, the problem you are seeing is about *handshake* signatures
> > using SHA1 - so auth_level is not appropriate.
> 
> I think what I found confusing is that later in the text it says this:
> 
> "See SSL_CTX_set_security_level(3) for the definitions of the available
>  levels."
> 
> so I had assumed it was calling that function.

It calls X509_VERIFY_PARAM_set_auth_level(), which also says to
look at SSL_CTX_set_security_level().

If you call SSL_CTX_set_security_level(),
X509_VERIFY_PARAM_set_auth_level() will be called with the same
value.


Kurt

Re: Lack of documentation for OPENSSL_ia32cap_P

[Kurt Roeckx]

On Thu, Jul 23, 2020 at 02:35:28AM +0200, Jakob Bohm via openssl-users wrote:
> The OPENSSL_ia32cap_P variable, its bitfields and the code that sets
> it (in assembler) seemto have no clear documentation.

Have you seen the OPENSSL_ia32cap manpage?


Kurt

Re: Order of protocols in MinProtocol

[Kurt Roeckx]

On Sun, Jul 12, 2020 at 12:29:43AM -0400, Viktor Dukhovni wrote:
> 
> The main outstanding issue for which I'm authoring a new PR, is that
> each of the above results in SSL_CONF_cmd() returning an error for
> contexts of the other type or for contexts that are for a specific fixed
> version of TLS or DTLS, and perhaps these errors are not ignored and
> cause issues with context initialisation?  The update I'm writing will
> be more forgiving and silently report success when the setting is not
> applicable.

Looking at openconnect's code, it now supports 3 ways:
- DTLSv1_client_method() with DTLS1_BAD_VER.
- DTLS_client_method() with DTLS1_2_VERSION
- A PSK

The first 2 options will overwrite the protocol min and max version,
so whatever is in the config file will not have any effect.


Kurt

Re: Goodbye

[Kurt Roeckx]

On Fri, Jul 03, 2020 at 12:51:19PM +, Salz, Rich via openssl-users wrote:
>   *   topic: Change some words by accepting PR#12089
> 
>   *
> 
>   *   4 against, 3 for, no absensions
> 
> I am at a loss for words.
> 
> I can’t contribute to a project that feels this way.

I would like to point out that the only thing that was voted on
was to accept the pull request as a whole.

A new pull request that removes the word slave has made and has been
approved.


Kurt

Re: CMAC timings

[Kurt Roeckx]

On Thu, Jun 18, 2020 at 07:24:39PM +0200, Kurt Roeckx wrote:
> 
> Now that a large fraction of the cost has been found, I can look
> again to see where the biggest cost in 3.0 comes from now and if we
> can do something about it.

So a code path that I've noticed before when looking at the
profile is:
/* TODO(3.0): Remove this eventually when no more legacy */
if (ctx->op.sig.sigprovctx == NULL)
return EVP_PKEY_CTX_ctrl(ctx, -1, EVP_PKEY_OP_TYPE_SIG,
 EVP_PKEY_CTRL_MD, 0, (void *)(md));

I think that is now actually causing most of the CPU usage.

This currently ends up doing an EVP_MAC_dup_ctx(), and I'm
currently not sure why, and what the effect is going to be
when sigprovctx != NULL. I think it might be better to wait until
someone fixes that before I look at that again.


Kurt

Re: CMAC timings

[Kurt Roeckx]

On Thu, Jun 18, 2020 at 02:12:56PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> I think that the default behavior should change for 3.0, and the API change 
> described in the Release Notes. I find that alternative less impacting that 
> this silent sudden performance deterioration.

Note that I was just looking at why the EVP PKEY API was slow, and
the first thing I found was the EVP_MD_CTX_FLAG_FINALISE's impact.
This also has a big impact in the 1.1.1 version:
CMAC API:
 AES-128  16 48 16410   0.410  475ac1c053379e7dbd4ce80b87d2178e
EVP_PKEY:
 AES-128  16 48 16739   0.739  475ac1c053379e7dbd4ce80b87d2178e
EVP_PKEY adding EVP_MD_CTX_FLAG_FINALISE:
 AES-128  16 48 16291   0.291  475ac1c053379e7dbd4ce80b87d2178e

The same with AESNI disabled:
CMAC API:
 AES-128  16 48 16584   0.584  475ac1c053379e7dbd4ce80b87d2178e
EVP_PKEY:
 AES-128  16 48 16823   0.823  475ac1c053379e7dbd4ce80b87d2178e
EVP_PKEY adding EVP_MD_CTX_FLAG_FINALISE:
 AES-128  16 48 16387   0.387  475ac1c053379e7dbd4ce80b87d2178e

Now that a large fraction of the cost has been found, I can look
again to see where the biggest cost in 3.0 comes from now and if we
can do something about it.

I think changing the default is going to break applications, which
is what we want to avoid. I think we should document that this can
overhead can be large if you do small packets and that the
behavioru can be changed with that option.


Kurt

Re: CMAC timings

[Kurt Roeckx]

On Thu, Jun 18, 2020 at 10:41:40AM +0200, Tomas Mraz wrote:
> > I question the default behaviour, I think most people don't need
> > that support.
> 
> Unfortunately that would be an API break that could be very hard to
> discover, so I do not think we can change this even in 3.0.

But I think the old CMAC API didn't support that, and so we can
change the internal calls to use the flag now (if needed). The
EVP_MAC API probably supports this too, and we can consider
changing the default there.


Kurt

Re: CMAC timings

[Kurt Roeckx]

On Wed, Jun 17, 2020 at 03:50:05AM -0700, Hal Murray wrote:
> levi...@openssl.org said:
> > What does surprise me, though, is that direct EVP_MAC calls would be slower
> > than going through the PKEY bridge.  I would very much like to see your code
> > to see what's going on. 
> 
> Over on an ntpsec list, Kurt Roeckx reported that he was still waiting...
> 
> Richard's message said "I", so I sent him a copy off list.  Correcting that...

So I took a look at at the EVP_PKEY case, and it seems we spend most
of our time doing:
- alloc/free. 12 alloc and 16 free calls per signature
- OPENSSL_cleanse: 10 calls per signature
- EVP_CIPHER_CTX_reset: 6 calls per signature

Most of the time is spent in those functions.

The manpage documents:
The call to EVP_DigestSignFinal() internally finalizes a
copy of the digest context. This means that calls to
EVP_DigestSignUpdate() and EVP_DigestSignFinal() can be called
later to digest and sign additional data.

And:
   EVP_MD_CTX_FLAG_FINALISE
   Some functions such as EVP_DigestSign only finalise
   copies of internal contexts so additional data can be
   included after the finalisation call. This is
   inefficient if this functionality is not required, and
   can be disabled with this flag.

(A reference to the EVP_MD_CTX_set_flags manpage would have been
useful.)

So after the EVP_MD_CTX_new(), I added an:
EVP_MD_CTX_set_flags(ctx, EVP_MD_CTX_FLAG_FINALISE);

For me it changed things with 3.0 from:
 AES-128  16 48 16   1696   1.696  475ac1c053379e7dbd4ce80b87d2178e
to:
 AES-128  16 48 16754   0.754  475ac1c053379e7dbd4ce80b87d2178e

While 1.1 gives me this without the change:
 AES-128  16 48 16739   0.739  475ac1c053379e7dbd4ce80b87d2178e
and with the change:
 AES-128  16 48 16291   0.291  475ac1c053379e7dbd4ce80b87d2178e

I question the default behaviour, I think most people don't need
that support.


Kurt

Re: How to help with getting KTLS patches merged

[Kurt Roeckx]

On Thu, Jun 04, 2020 at 09:00:08AM -0700, John Baldwin wrote:
> At the moment there are 3 open PRs related to Kernel TLS offload
> support that I'm aware of:
> 
> - 11589 adds TLS1.3 for Linux, has one approval from Matt Caswell
> - 10626 adds TLS1.3 for FreeBSD, from which 11589 is derived, but will
>   need to be rebased on top of 11589 once it is merged
> - 11679 adds TLS1.[012] RX offload for FreeBSD, but would conflict
>   a bit with 11589
> 
> Matt has already approved 11589, and I think 11589 looks ok from
> my vantage point (I'm more familiar with the KTLS infrastructure
> in FreeBSD rather than Linux).  Given that 11589 has received the
> most review, I think it is probably prudent for it to be merged
> first at for me to then rebase the other two PRs on top of that
> and resolve conflicts, etc.

11589 has now been merged.


Kurt

Re: OpenSSL version 3.0.0-alpha1 published

[Kurt Roeckx]

On Fri, Apr 24, 2020 at 01:26:05PM +0200, Yann Ylavic wrote:
> 
> - DH_bits(dh) (used for logging only in httpd)
> Replaced by BN_num_bits(DH_get0_p(dh)).
> Not sure this one should be deprecated, it seems to be used in several
> places in openssl codebase still, no replacement?

I think the replacement is using the EVP_PKEY API and then use
EVP_PKEY_bits()


Kurt

Re: opensssl 1.1.1g test failure(s)

[Kurt Roeckx]

On Wed, Apr 22, 2020 at 11:02:47AM +0200, Michael Tuexen wrote:
> > On 22. Apr 2020, at 10:38, Matt Caswell  wrote:
> > 
> > 
> > 
> > On 21/04/2020 23:45, Michael Tuexen wrote:
> >>> Looks like the failing call is here:
> >>> 
> >>>   if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY,
> >>>  (const void *), sizeof(on)) != 0) {
> >> Can you provide a pointer to the code?
> > 
> > Yes, its here:
> > 
> > https://github.com/openssl/openssl/blob/fa555aa8970260c3e198d91709b2d4b3e40f8fa8/crypto/bio/b_sock2.c#L267-L282
> OK. Thanks.
> 
> Could it be that on == 0, when you do the setsockopt() call? Disabling 
> IPV6_V6ONLY seems not to be supported
> on OpenBSD:

Yes:
if (BIO_ADDR_family(addr) == AF_INET6) {
/*
 * Note: Windows default of IPV6_V6ONLY is ON, and Linux is OFF.
 * Therefore we always have to use setsockopt here.
 */
on = options & BIO_SOCK_V6_ONLY ? 1 : 0;
if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY,
   (const void *), sizeof(on)) != 0) {

So something is calling BIO_listen without setting BIO_SOCK_V6_ONLY
in options. All calling functions really should set BIO_SOCK_V6_ONLY
if they actually support multiple sockets, and they should.


Kurt

Re: opensssl 1.1.1g test failure(s)

[Kurt Roeckx]

On Tue, Apr 21, 2020 at 10:49:25PM +0100, Matt Caswell wrote:
> 
> Looks like the failing call is here:
> 
> if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY,
>(const void *), sizeof(on)) != 0) {
> 
> To which we get an errno indicating "Invalid argument". So it looks like
> your host has the relevant IPV6 macros defined (otherwise we would have
> got a compilation failure) - but doesn't understand them when used.

OpenBSD is really weird in this regard. They always use the
behavior of IPV6_V6ONLY set to on. But if you actually try to set
it on, they return an error. They should instead return an error
when you try to set it off.


Kurt

Re: Question about handshake error

[Kurt Roeckx]

On Wed, Mar 11, 2020 at 12:15:32PM +, Matt Caswell wrote:
> 
> Debian 10 omits all the SHA1 entries from the above list. Note that
> Debian 10 will only allow SHA1 if the security level is explicitly set
> to 0 (via the -cipher "DEFAULT:@SECLEVEL=0" command line arg). Probably
> because the debian patch is the same as this one:
> 
> https://github.com/openssl/openssl/pull/10786

That patch is not applied. I assume that SECLEVEL=1 will allow
SHA1, but the default in Debian is SECLEVEL=2


Kurt

Re: Question about handshake error

[Kurt Roeckx]

On Wed, Mar 11, 2020 at 12:15:32PM +, Matt Caswell wrote:
> 
> I *think* what is happening is the server is checking the chain it has
> been configured with, spotting that it includes a SHA1 based signature
> and therefore refusing to respond at all because the client has not
> indicated SHA1 support. IIRC openssl is a little less strict in this
> regards and would send the certificate anyway if it doesn't have a
> better alternative.

That seems to be the same as:
https://github.com/openssl/openssl/issues/11236



Kurt

Re: Clutter in log files, bogus connections

[Kurt Roeckx]

On Sat, Nov 23, 2019 at 04:42:50PM -0800, Hal Murray wrote:
> 
> I see a lot of clutter in log files from things like
>   error:1408F10B:SSL routines:ssl3_get_record:wrong version number
> I assume they are from bad guys probing for openings.
> 
> Is the error code returned by ERR_get_error() constant across releases?  Can 
> I 
> compile magic constants like 1408F10B into my code?  If not, is there a 
> suggested approach?

Use ERR_GET_LIB(error) == ERR_LIB_SSL && ERR_GET_REASON(error) == 
SSL_R_WRONG_VERSION_NUMBER.


Kurt

Re: Remove All Software Generators

[Kurt Roeckx]

On Wed, Oct 30, 2019 at 02:12:19PM -, Frederick Gotham wrote:
> 
> It appears that OpenSSL will kick and scream and refuse to die not 
> matter how hard you hit it. If I try to generate a random number like 
> this:
> 
> openssl rand -hex 8
> 
> Then it seems it will try in this order:
> 
> 1) The TPM2 chip
> 2) The software simulator of the TPM2 chip
> 3) The built-in RDRAND number
> 4) Another one that I can't find

Which version of OpenSSL are you using?

> I have recompiled OpenSSL with the flag OPENSSL_NO_RDRAND to get rid of 
> the in-built engine. I have even done "rm /dev/random" and "rm 
> /dev/urandom", but SOME HOW, SOME WAY, I'm still getting output when I 
> run openssl rand -hex 8.

Depending on the version of OpenSSL and the kernel, you might also
use the getentropy()/getrandom() cal.

Since 1.1.0 we Configure supports the --with-rand-seed=none
option.


Kurt

Re: failing in reproducing .so files

[Kurt Roeckx]

On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
> */usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2:

There seems to be a problem generating the libcrypto.map file for
you. What does the file look like? Which perl version are you
using? Which libc do you use?


Kurt

Re: Since I switched to OpenSSL 1.1.1c, I've found -Dpurify is not working

[Kurt Roeckx]

On Fri, Jun 07, 2019 at 05:14:23PM -0400, Lewis G. Pringle, Jr. wrote:
> When I run valgrind, I get thousands of errors (exactly like I used to get
> before I turned on -Dpurify).

You probably need commit 15d7e7997e219fc5fef3f6003cc6bd7b2e7379d4


Kurt

Re: [openssl-users] OpenSSL 1.1.1 Support for DH Ciphers?

[Kurt Roeckx]

On Tue, Jan 29, 2019 at 02:42:48PM -0500, Viktor Dukhovni wrote:
> > On Jan 29, 2019, at 2:23 PM, Rich Fought  wrote:
> > 
> > The OpenSSL 1.1.1 ciphers manpage claims that some non-ephemeral DH ciphers 
> > are supported:
> > 
> > TLS1.0:
> > DH-RSA-AES128-SHA
> > DH-RSA-AES256-SHA
> 
> The static DH and ECDH ciphers have been removed.
> 
> > TLS1.2:
> > DH-RSA-AES128-SHA256
> > DH-RSA-AES256-SHA256
> > DH-RSA-AES128-GCM-SHA256
> > DH-RSA-AES256-GCM-SHA256
> > 
> > However, I am unable to see them with openssl ciphers command
> > 
> > > openssl ciphers -v -s DH
> > 
> > All I see are DHE ciphers.  DH is needed for compatibility with legacy 
> > servers.
> 
> They are NOT needed for compatibility with legacy servers.

To clarify, the static DH has fixed DH parameters in the
certificate. Instead of generating the parameters on each
connection, it's fixed in the certificate. It's higly unlikely
that you have such certificates. They're very difficult to
actually generate. Other then some test certificates, I have never
seen any actual such certificate.

Even if you somehow managed to generate such certificate, both the
client and server would actually need to be set up to work with
static DH, and only static DH, which also seems unlikely. 


Kurt

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

Re: [openssl-users] SSL_read() returns -1, and SSL_read_ex does not update readbytes where a record containing a session ticket is being read (TLS 1.3)

[Kurt Roeckx]

On Thu, Jan 24, 2019 at 11:09:40PM +0700, Arran Cudbard-Bell wrote:
> We could use this to determine what SSL_ERROR_WANT_READ is indicating.  As it 
> seems  SSL_ERROR_WANT_READ could indicate two conditions in this scenario:
> 
> 1) No pending bytes - Additional handshake messages were processed, there's 
> an expectation of additional application_data, but no hint that more 
> application_data will be forthcoming.
> 2) Pending bytes - There is an incomplete record that needs processing.  
> Additional data should be fed into the BIO.

If you call SSL_read() and you get SSL_ERROR_WANT_READ it means
we can't return any application data at this time. Try again later.

With SSL_MODE_AUTO_RETRY off, it could be that calling it directly
again can now return application data. If it's on, it means it
wasn't available yet and you need to wait for it to arrive.

If you use an fd BIO and select(), SSL_ERROR_WANT_READ just means
you should wait with select() for more data.


Kurt

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

Re: [openssl-users] Dealing with RFC2553 and RFC3493 where NI_MAXHOST and NI_MAXSERV no longer exist

[Kurt Roeckx]

On Fri, Jan 18, 2019 at 06:40:05PM -0500, Dennis Clarke wrote:
> On 1/18/19 1:53 AM, Dennis Clarke wrote:
> > 
> > Going in circles trying to compile 1.1.1a with strict C99 and no
> > optimizations and with a ready to debug and single step resultant
> > library.
> 
> Ignore all this.  Thou shalt not C99 here.

Our code base is currently C89/C90, with some extenions, but things
like gcc default to something like "gnu99", "gnu11" or "gnu17".
And we actually make use of some of those extensions not in C89.

The ones I know about:
- asm(): Most of those should go away if you define PEDANTIC. I
  think the only exception is code we compile when gcc is used.
- strdup() and strcasecmp() which are in POSIX, but not in C
- Setting the mutex type, which seems to be UNIX98 or XOPEN2K8
- isascii: XOPEN
- usleep: Was in POSIX, has been replaced by nanosleep
- long long: Since C99

Then we also use things like int32_t, but define the type ourself
if the compiler is C89. We detect C11 support for atomics.

Anyway, if you have a good patch to remove things that are no
longer in a standard, and it also works with older systems, I suggest
submit a patch.


Kurt

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

Re: [openssl-users] RNG behavior by default

[Kurt Roeckx]

On Sat, Jan 05, 2019 at 08:33:18PM +0100, Steffen Nurpmeso wrote:
> 
> (I am also really interested and will look into OpenSSL to see if
> the abort() that seems to happen if the initial seed fails is in
> a linker-resolved constructor, and if not, why later failures do
> not also abort.

We do not call abort(). A function like RAND_bytes() or
RAND_status() will just return an error.

> Yes, while i am going, the full truth is that
> i do not like it, i do not like that possibly a constructor call
> is made for something that is possibly not needed, if it is done
> like that, that someone simply aborts because of a some internal
> PRNG, especially so if it is not in a constructor call and if
> errors can and are expected to be handled by PRNG users anyway,

RAND_bytes() has always documented that it can fail. Most function
calls can return errors for various reasons. Not checking for such
errors is in my opinion a bad style.

> i do not like that the stuff is instantiated in all threads

It's only created in each thread that tries to the RNG. I'm not
sure what exactly your problem with it is. Either we need a global
lock, or we need an RNG per thread. We went with the per thread
RNG.

We have a master DRBG that you can get with
RAND_DRBG_get0_master(). I recommend that you do not use it. It
requires that you take an external lock to use it. Internally we
lock it, but there is no way for you to use the same lock.

> which
> in addition requires forks handlers to be installed all over the
> place.

OpenSSL adds it's own fork handler now. You should not need to do
anything on fork related to OpenSSL.

> the Linux kernel that drives
> the world from smallest to hugest has one internal entropy pool
> that feeds two public pools, whereas i the lucent little hobby
> server from user space get an armada of these.  Wow.

Linux has a master pool, and a pool per core for the very same
reason as we also have a master DRBG and per thread DRBG.


Kurt

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

Re: [openssl-users] RNG behavior by default

[Kurt Roeckx]

On Sat, Jan 05, 2019 at 08:45:37AM +1000, Dr Paul Dale wrote:
> I’m not sure about the quality of Android’s sources, but would expect them to 
> be decent.

Android is just a Linux kernel. It always had /dev/urandom. Oreo
(8.0) requires at least Linux kernel 4.4. There were no
requirements for the kernel version before this. Some devices with
Marshmallow (6.0) will run a Linux kernel with 3.18, but not all
of them.


Kurt

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

Re: [openssl-users] RNG behavior by default

[Kurt Roeckx]

On Fri, Jan 04, 2019 at 02:48:48PM +0100, Steffen Nurpmeso wrote:
> Dr. Matthias St. Pierre wrote in <450169f8ca7c43d1841c4c8052e78c72@Ex13.\
> ncp.local>:
>  |> So my concerns are:
>  |> 1. Whether I really can count on getting a high-entropy PRNG across \
>  |> these various platforms, without any explicit initialization.
>  |
>  |Yes, for the mentioned platforms, the default configuration is `--with-r\
>  |and-seed=os`, which means the DRBG automatically seeds
>  |and reseeds using os entropy sources.
>  |
>  |2. If something goes wrong with PRNG initialization, that it will fail \
>  |hard rather than fall back to something less secure. And if so how \
>  |I detect such a failure.
>  |
>  |If the (re-)seeding fails, the DRBG enters an error state. When you \
>  |try to generate random bytes it will detect the error state and try
>  |automatically to heal the error state by reinstantiating. But if reseeding \
>  |fails, it will return and error code and not generate any pseudo random \
>  |bytes.
>  |
>  |Citing from the manual pages:
>  ...
>  | As a normal application developer, you do not have to worry about \
>  | any details, just use RAND_bytes(3)
>  | to obtain random data. Having said that, there is one important rule \
>  | to obey: Always check the error
>  | return value of RAND_bytes(3) and do not take randomness for granted.
>  |
>  | https://www.openssl.org/docs/man1.1.1/man7/RAND.html
> 
> That is new however, _imho_.  The wording of RAND_bytes(3) (still)
> says that "an error occurs [.if.] not [been] seeded with enough
> [data]", and RAND_status(3) returns 1 if the PRNG "has been seeded
> with enough data".  So if it is seeded it is seeded, in my
> understanding anything further on up the road only mixes in noise
> (which likely will undergo further maths and be stirred into the
> pool, i have not looked, actually).  I do not test RAND_bytes(3)
> return (yet), because i have ensured the PRNG is sufficiently
> seeded, and RAND_status(3) returns success, before RAND_bytes(3)
> is used the first time.

For 1.1.0 and older that works, because they do not reseed. Since
1.1.1 it does reseed, and if the reseed fails, it will go to an
error state. So yes, this is new behavior.

The RAND_bytes and RAND_status manpages can clearly be improved.
Since you always have to check RAND_bytes's return value now,
RAND_status is mostly useless.


Kurt

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

Re: [openssl-users] RFC 7919 DH parameters and OpenSSL DH_check()

[Kurt Roeckx]

On Thu, Jan 03, 2019 at 12:18:05PM -0800, Andy Schmidt wrote:
> I am adding the RFC 7919 Diffie-Hellman parameters to our TLS servers, and
> I've found that these parameters won't pass OpenSSL's Diffie Hellman
> parameter check function DH_check(). The return code is
> DH_NOT_SUITABLE_GENERATOR. Looking at the source code, it appears to fail
> because the remainder of the prime divided by 24 is not 11. That its, p mod
> 24 != 11. I have a couple of questions:
> 
> What relationship between the prime p and the generator g is this checking
> for? I thought that since p was a safe prime, as long as the generator g
> wasn't 1 the only choice is between the full group and the subgroup of the
> squares?
> 
> I would like to use DH_check() to attempt to ensure that Diffie Hellman
> parameters haven't been tampered on operating systems that don't have
> digital signatures for executable binaries.

See:
https://crypto.stackexchange.com/questions/12961/diffie-hellman-parameter-check-when-g-2-must-p-mod-24-11


Kurt

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

Re: [openssl-users] RNG behavior by default

[Kurt Roeckx]

On Thu, Jan 03, 2019 at 11:03:01AM -0500, Mike Blaguszewski wrote:
> I am using the EVP API (version 1.1.1) for performing public key and 
> symmetric key operations across a variety of platforms (macOS, Windows, 
> Linux, iOS and Android). I am currently not doing anything to explicitly seed 
> OpenSSL’s random number generator. My understanding is that the default 
> behavior  should be 
> cryptographically secure.
> 
> So my concerns are:
> 1. Whether I really can count on getting a high-entropy PRNG across these 
> various platforms, without any explicit initialization.
> 2. If something goes wrong with PRNG initialization, that it will fail hard 
> rather than fall back to something less secure. And if so how I detect such a 
> failure.
> 
> Our current implementation uses libsodium, which relies on the usual system 
> calls to generate entropy, so if I can count on OpenSSL always doing this 
> then I’m happy. 

It will make use of system calls when available. Those are known
to provide system calls:
- Linux since 3.17
- Darwin since 16 (OSX 10.12, IOS 10.0).
- Solaris since 11.3
- OpenBSD since 5.6
- FreeBSD since 12.0 (1200061)

By default it will fall back to use something like /dev/urandom if
the system call is not available or returns an error.

On Windows we are also using the system provided entropy by using
function calls.

You do not need to do anything to initialize RNG. It will
automatically initiailze on first use.

It will hard fail when it's not able to get entropy.

Since it now reseeds from time to time, it can actually start to
fail after having run succesfully for some time. But it's very
unlikely that you would run into that, by default we should make
sure that we can always get entropy.


Kurt

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

Re: [openssl-users] Authentication over ECDHE

[Kurt Roeckx]

On Mon, Dec 31, 2018 at 02:11:56PM +, Matt Caswell wrote:
> 
> Well, you have vocally complained about the state of the documentation. You 
> have
> the benefit of being a new OpenSSL user. You know what things were confusing 
> or
> unclear in the documentation. More experienced OpenSSL coders often don't have
> the perspective - because some things are just "obvious" to them. So help with
> pull requests to improve the documentation.

Or you could just file a bug pointing out the areas that are
unclear.


Kurt

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

Re: [openssl-users] OpenSSL 1.0.2: CVE-2018-0735

[Kurt Roeckx]

On Tue, Nov 06, 2018 at 04:19:36PM -0600, Misaki Miyashita wrote:
> Hi,
> 
> According to the vulnerabilities website[1], OpenSSL 1.1.i and earlier and
> 1.1.1 are affected by CVE-2018-0735.
> Is it safe to assume that OpenSSL 1.0.2 is not affected by the CVE?

My understanding is that the code was not present in 1.0.2. To
address CVE-2018-5407, that code was backported to 1.0.2, but the
fixed version was used.


Kurt

-- 
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

[Kurt Roeckx]

On Tue, Sep 18, 2018 at 05:11:42PM +, Salz, Rich via openssl-users wrote:
> >My point was about the likelihood of last-draft browsers lingering
> on in the real world for some time (like 1 to 3 years) after the
> TLS1.3-final browser versions ship.
> 
> I do not think this is a concern.  Chrome and FF auto-update and get almost 
> full coverage within a month or two, for example.  Edge hasn't shipped TLS 
> 1.3 yet. Safari encourages auto-update.  That's most of the browser market.

I think chrome and firefox cover all browsers that ever enabled a
draft version.


Kurt

-- 
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

[Kurt Roeckx]

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?

Draft versions really should die as soon as possible. If we ever put
it in a released version, it will still be in use in 10 years,
which really isn't something we want.

On the other hand, in a few weeks browsers will stop using those
draft versions, so I really don't see the point.


Kurt

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

Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server

[Kurt Roeckx]

On Tue, Sep 11, 2018 at 08:10:01PM +0200, Kurt Roeckx wrote:
> On Tue, Sep 11, 2018 at 04:59:45PM +0200, Juan Isoza wrote:
> > Hello,
> > 
> > What is the better way, for anyone running, by example, Apache or nginx on
> > a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS
> > 1.3 ?
> > 
> > Waiting package update to have openssl 1.1.1 ? probably a lot of time
> > 
> > Recompile openssl dynamic library and replace system library ? We must be
> > sure we don't broke the system
> > 
> > Recompile Apache or NGinx with openssl statically linked ? probably complex
> 
> Note that you most likely need an update of both nginx/apache and
> openssl.
> 
> I will very likely make 1.1.1 available in Debian backports. I hope that
> the nginx maintainer will also make a version that works with 1.1.1.

Looking at stretch-backports, it already has an nginx version that is
recent enough, so you would just need a new openssl. I can only do
an openssl upload to backports after it has reached testing.


Kurt

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

Re: [openssl-users] Migrating to openssl 1.1.1 in real life linux server

[Kurt Roeckx]

On Tue, Sep 11, 2018 at 04:59:45PM +0200, Juan Isoza wrote:
> Hello,
> 
> What is the better way, for anyone running, by example, Apache or nginx on
> a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS
> 1.3 ?
> 
> Waiting package update to have openssl 1.1.1 ? probably a lot of time
> 
> Recompile openssl dynamic library and replace system library ? We must be
> sure we don't broke the system
> 
> Recompile Apache or NGinx with openssl statically linked ? probably complex

Note that you most likely need an update of both nginx/apache and
openssl.

I will very likely make 1.1.1 available in Debian backports. I hope that
the nginx maintainer will also make a version that works with 1.1.1.

But this is most likely going to take a while. We first want to make
things work properly in testing. In the mean time buillding things
yourself seems like the easiest solution. If using Debian you can
just take the versions of the packages currently in unstable and
build them on stable.


Kurt

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

Re: [openssl-users] Version negotiation failure failure?

[Kurt Roeckx]

On Fri, Aug 31, 2018 at 06:14:25PM -0700, Jordan Brown wrote:
> We're trying to nail down error reporting for TLS version mismatches,
> and we're seeing a couple of puzzling behaviors.
> 
> First, and most puzzling... assume these two command lines:
> 
> $ openssl s_server -cert 2018.08.31.a.pem -key 2018.08.31.a.key -no_tls1
> 
> $ openssl s_client -connect zel.us.oracle.com:4433 -tls1
> 
> That is, I have a server that won't accept TLSv1.0, and a client that
> will only accept TLSv1.0.
> 
> On the server side I see
> 
> 1:error:14076102:SSL routines:SSL23_GET_CLIENT_HELLO:unsupported
> protocol:s23_srvr.c:605:
> 
> which makes perfect sense.  On the client side I see
> 
> 4294956672:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl
> handshake failure:s3_pkt.c:659:
> 
> which isn't as good, but is still sort of sensible.  But when I look at
> the packets exchanged, I see that the client sends a Client Hello, and
> the server responds with an ACK and then a FIN-ACK, with no data.  It
> just hangs up the phone.  This seems to violate RFC 5246 section E.1: 
> "If server supports (or is willing to use) only versions greater than
> client_version, it MUST send a "protocol_version" alert message and
> close the connection.".  Where's my protocol version alert?
> 
> Of course my real case does not involve the sample client and server -
> it involves my own clients and servers - but I seem to see the same
> behavior with several servers (notably including the Apache httpd).
> 
> This looks like it's the same as
> https://rt.openssl.org/Ticket/Display.html?id=2777 .  I'm using 1.0.2o. 
> (But I don't see anything relevant-looking in the 1.0.2p changes.)  I've
> seen similar behavior from 1.0.2o-fips.

I can not reproduce this in 1.0.1, 1.0.2, 1.1.0 or 1.1.1. I
believe this was fixed in all branches. I've tried 1.0.2o too, and
I still get the alert back.

> And then, on the client side...
> 
> SSL_connect returns zero.  Exactly how that failure differs from a
> less-than-zero error is not clear, but OK.  The docs say to call
> SSL_get_error().  SSL_get_error() returns 5, SSL_ERROR_SYSCALL.  (That
> seems a little strange, since I don't think there's any system call
> errors here.)  The docs say to consult the error queue and errno. 
> ERR_peek_last_error( ) returns zero.  Errno is zero.  It failed, but
> nobody will tell me why.

I assume that it returns SSL_ERROR_SYSCALL because something is
not properly setting an error, and SSL_get_error() returns
SSL_ERROR_SYSCALL when it doesn't know what else to return.
If the peer just closes the connection, you should have gotten
SSL_ERROR_SSL. I assume read() returned 0 because of EOF, which is
not an error for read() so it does not set errno, but OpenSSL
should have set an error instead.


Kurt

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

Re: [openssl-users] using NULL ciphers

[Kurt Roeckx]

On Wed, Aug 22, 2018 at 02:08:42PM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Aug 22, 2018, at 1:56 PM, Qi Zeng  wrote:
> > 
> > I’m trying to use NULL cipher such as ECDHE-ECDSA-NULL-SHA for debugging 
> > purpose. With OpenSSL version 1.0.2p, I was able to make it work. However  
> > with version 1.1.0i or 1.1.1 prev 9, SSL_CTX_set_cipher_list(ctx, 
> > "ECDHE-ECDSA-NULL-SHA") succeeded but SSL_Connect () failed. Is there any 
> > way to enable NULL ciphers with version 1.1.0i or later?
> 
> Yes, you need to use:
> 
>"ECDHE-ECDSA-NULL-SHA:@SECLEVEL=0"
> 
> at present there are no separate controls to distinguish between the
> authentication security level and the encryption security level, so
> this also removes floors on the keys used in the certificates, but
> for debugging that should not be an obstacle...

With 1.1.1 pre 9 you also might try to be using TLS 1.3, and that
does not support a NULL cipher.


Kurt

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

Re: [openssl-users] Anonymous DH (ADH) in real world applications

[Kurt Roeckx]

On Sun, Aug 19, 2018 at 02:36:30PM +0200, Anton wrote:
> Hello
> 
> Does anyone know some examples of applications using
> ADH ciphersuites for TLS connections in production
> environment?

At least postfix can use it for SMTP.


Kurt

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

Re: [openssl-users] [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves?

[Kurt Roeckx]

On Sat, Aug 18, 2018 at 07:48:21PM +0200, Juan Isoza wrote:
> What is the difference between draft 28 and rfc for tls 1.3 ?

The drafts used a version that said which draft version it was.
The RFC version has a different version. So the version that's
send in ClientHello is different, and a draft version will not
talk to an RFC version using the TLS 1.3 protocol.


Kurt

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

Re: [openssl-users] Shutdown details

[Kurt Roeckx]

On Sun, Aug 12, 2018 at 08:49:35PM +0200, Kurt Roeckx wrote:
> In -pre8 we even have tests covering this behaviour, and the
> manpages have been update to say that it's possible. See
> https://www.openssl.org/docs/manmaster/man3/SSL_shutdown.html

I think this was actually commited after pre8.


Kurt

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

Re: [openssl-users] Shutdown details

[Kurt Roeckx]

On Wed, Aug 01, 2018 at 09:46:37PM +0200, Alex H wrote:
> 
> > If your question is whether you can still read any data that may have
> been in flight when you send your close_notify, I believe the answer
> is no.  Further data received from the peer is discarded after a
> close_notify is sent.
> 
> I also believe so, especially since SSL_shutdown docs seem to hint that
> once SSL_shutdown is called, it should be called again until fully done
> (serving SSL_WANT_READ/WRITE as needed). In other words, SSL_shutdown
> becomes the only function called until the SSL connection is fully closed,
> no more SSL_read is called and thus it cannot report any received data.
> SSL_shutdown does not return with any data.

You are probably reading old documentation. The documentation has
been updated say that it's adviced to call SSL_read() until you
get SSL_ERROR_ZERO_RETURN.


Kurt

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

Re: [openssl-users] Shutdown details

[Kurt Roeckx]

On Wed, Aug 01, 2018 at 08:27:38AM +0200, Alex H wrote:
> Hi,
> 
> I have trouble understanding the details of TLS shutdown. I get the basics
> but,
> 
> Is it possible to receive data after calling SSL_shutdown? Reading the
> specs and docs leaves this rather blurry.
> 
> That is, after sending a close_notify, can I receive data before getting my
> client_notify response?
> 
> The sources of SSL_write checks for SSL_SENT_SHUTDOWN state and returns
> with error if set, but does not check for SSL_RECEIVED_SHUTDOWN. This
> indicates somehow I'm allowed to still send data after received a
> close_notify?

TLS 1.3 makes it explicit that after you've send a close_notify,
the peer is still allowed to send data, so you can still read
data. It only closes the connection in one direction.

As far as I know, OpenSSL has always supported this, even when the
RFC said that the other side needs to send the close_notify back
on receiving it.

In -pre8 we even have tests covering this behaviour, and the
manpages have been update to say that it's possible. See
https://www.openssl.org/docs/manmaster/man3/SSL_shutdown.html


Kurt

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

Re: [openssl-users] The new BN_num_bits_word in 1.0.2o triggers bug in MS C 14.00.60131 for ARM

[Kurt Roeckx]

On Mon, Aug 06, 2018 at 04:30:54PM +0200, Jakob Bohm wrote:
> The patch below works around this, porting this to OpenSSL 1.1.x
> is left as an exercise for the reader:

Can you please open a pull request on github for that?


Kurt

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

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

[Kurt Roeckx]

On Sun, Apr 29, 2018 at 10:05:39PM -0400, Dennis Clarke wrote:
> On 29/04/18 06:43 AM, Kurt Roeckx wrote:
> > The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> > 1.3 brings a lot of changes that might cause incompatibility. For
> > an overview see https://wiki.openssl.org/index.php/TLS1.3
> 
> Looking at https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites
> there are five pure TLSv1.3 ciphersuites listed. At the moment the
> OpenSSL 1.1.1-pre5 utters :
> 
> n0$ LD_LIBRARY_PATH=`pwd` apps/openssl ciphers -v | grep " TLSv1\.3 "
> TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any  Au=any  Enc=AESGCM(256) Mac=AEAD
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any  Au=any
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any  Au=any  Enc=AESGCM(128) Mac=AEAD
> n0$

Yes, by default only 3 are anbled, but there are also 2 other
supported included in ALL.

> So using a client connect test to apache means build up a separate
> instance ( and toolchain perhaps ) running with pre4 beta only and a
> self cert and then ... isolate to only TLS_AES_256_GCM_SHA384 ( for
> example ) in the apache ssl config. This will take some days just for
> an initial test framework and then try :

Note that Apache requires a patch that was commited 4 weeks ago to
support TLS 1.3. It just seems to make TLS 1.3 known to the
configuration files and things like that, I'm not sure why that was
needed in the first place.


Kurt

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

[openssl-users] Call for testing TLS 1.3

[Kurt Roeckx]

The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
1.3 brings a lot of changes that might cause incompatibility. For
an overview see https://wiki.openssl.org/index.php/TLS1.3

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.

When testing this, it's important that both sides of the
connection support the same TLS 1.3 draft version. OpenSSL
currently implements draft 26. We would like to see tests
for OpenSSL acting as client and server.

https://github.com/tlswg/tls13-spec/wiki/Implementations lists
other TLS 1.3 implementations and the draft they currently
support. Note that the versions listed there might not be for the
latest release. It also lists some https test servers.

We would really like to see a diverse set of applictions being
tested. Please report any results you have to us.


Kurt

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

Re: [openssl-users] Question as to best options....

[Kurt Roeckx]

On Tue, Dec 26, 2017 at 01:42:57PM -0600, Karl Denninger wrote:
> 
> On 12/26/2017 13:14, Salz, Rich via openssl-users wrote:
> >
> > So if you put locks around the SSL_CTX object when it’s used, then you
> > can use the set private key call to update the key; and then all
> > SSL_new objects afterwards will use the new credentials.  Does that
> > meet your need?
> >
> Yes, that I already know how to do.  The issue is how to get the key
> from a PEM file into a format that I can feed it with set private key. 
> There doesn't appear to be a means to "un-file-ify" the set private key
> functions.

You can use the d2i_PrivateKey and i2d_PrivateKey functions to read
and write the file.

> > > "is there a decent way to convert a PEM or DER private key file into
> > ASN.1" using OpenSSL calls (from a "C" program, not from the command
> > line; we'll assume I have the key and cert files already.)
> >
> > I assume you mean “native C structure” and not ASN1?  Because DER is
> > just the ASN1 serialized, and PEM is base64 encoded DER with marker
> > lines. …
> >
> >
> >
> So if I take a PEM private key file, strip the markers, and turn the
> actual key's base64 into binary (assuming an RSA key, so there's no "EC
> parameter" block in front) I now have an "opaque" unsigned character
> array of length "len" (the decoded Base64) which
> SSL_CTX_use_privateKey_ASN1 will accept?  (Assuming the key file is
> unencrypted, of course.)
> 
> What is the parameter "pk" passed to the call in that instance (it's not
> in the man page)

From the manpage:
SSL_CTX_use_PrivateKey_ASN1() adds the private key of type _pk_

So you would need to know that it's an RSA or EC key. If you used
d2i_AutoPrivateKey you don't need to know the type and get an
EVP_PKEY.


Kurt

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

Re: [openssl-users] Question as to best options....

[Kurt Roeckx]

On Tue, Dec 26, 2017 at 12:38:32PM -0600, Karl Denninger wrote:
> 
> What I'm trying to figure out is the "best" way to handle this. 
> SSL_CTX_use_PrivateKey accepts a EVP_PKEY pointer,
> SSL_CTX_use_PrivateKey_ASN1 takes an ASN1 structure of length len, but
> what is parameter "pk" (not explained in the man page) and this assumes
> I have an ASN.1.

I assume you send the file in DER or PEM format over the SSL
connection. You then probably want to use d2i_PrivateKey() or
d2i_AutoPrivateKey() to turn that into an EVP_PKEY.


Kurt

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

Re: [openssl-users] OpenSSL SHA algorithm

[Kurt Roeckx]

On Mon, Dec 25, 2017 at 07:44:58PM -0800, Swapnil Deshpande wrote:
> Hi all,
> 
> Noob here. I recently discovered that the "-sha1" and "-sha" flags in the
> "openssl dgst" command produce different outputs. I thought those were the
> same algorithms but turns out they are not:
> 
> $ echo -n "password" | openssl dgst -sha
> 
> 80072568beb3b2102325eb203f6d0ff92f5cef8e
> 
> 
> $ echo -n "password" | openssl dgst -sha1
> 
> 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8
> 
> 
> I am aware of SHA1 and the SHA-128 algorithm.
> 
> 
> 1. What algorithm is used to generate hash when I use the "-sha" option?

It's the original SHA algorithm, which people will now refer to as
SHA-0. It has some minor but important changes compared to SHA-1.

> 2. What could I have done to get this answer to #1 in a better way? I am
> asking this because I tried to find what algorithm is being used through
> the "help" option as well as trying to search via "man openssl" but
> couldn't find anything. I also did a basic search for "openssl sha vs sha1"
> and couldn't find any relevant results. If there was a better way to know
> more about this option (say by reading some documentation), I'd be glad to
> know about it.

I started a pull request:
https://github.com/openssl/openssl/pull/4979

There are probably other changes that should happen.


Kurt

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

Re: [openssl-users] [openssl-dev] Is X509_free(NULL) ok?

[Kurt Roeckx]

On Fri, Dec 22, 2017 at 09:30:19AM -0500, Ken Goldman wrote:
> On 12/22/2017 9:24 AM, Salz, Rich via openssl-users wrote:
> > >   if (ptr!= NULL) free(ptr);
> > That shouldn’t be necessary for OpenSSL.  If you find places where it is, 
> > please open an issue.
> 
> OK.  I'll mention a few, but it's a global issue.
> 
> The code may handle NULL.  However, conservative users won't go by what the
> code happens to do today.  We have to go by the API documentation, which is
> the contract between the library and the user.  If the API is silent, we
> cautiously assume it's not guaranteed, and can change in the future.

So feel free to document it as being able to handle NULL.


Kurt

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

Re: [openssl-users] [openssl-dev] Is X509_free(NULL) ok?

[Kurt Roeckx]

On Fri, Dec 22, 2017 at 01:06:20PM +, Salz, Rich via openssl-dev wrote:
> Our intent is that all FREE functions can handle NULL.  If you find things 
> missing or undocumented, please open an issue on GitHub.  Thanks!

I think we fixed all such cases in 1.1.0, all *_free() functions
should handle NULL. I don't think we backported to changes to 1.0.2.


Kurt

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

Re: [openssl-users] [openssl-dev] OpenSSL Project Bylaws

[Kurt Roeckx]

On Tue, Feb 14, 2017 at 09:30:31AM +, Matt Caswell wrote:
> I am pleased to be able to announce the publication of our new Project
> Bylaws. I have written a short blog post about what we are hoping to
> achieve and some of the thinking that went into these here:
> 
> https://www.openssl.org/blog/blog/2017/02/13/bylaws/
> 
> The bylaws themselves are available here:
> 
> https://www.openssl.org/policies/bylaws.html
> 
> The Project Bylaws describe how the OpenSSL Project operates, what the
> different project roles are and how decisions are made. Incidentally
> these project bylaws should not be confused with the OpenSSL Software
> Foundation (OSF) Bylaws which were also recently published and describe
> how that legal entity operates.

We have also published a guideline for commiters here:
https://www.openssl.org/policies/committers.html


Kurt

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

Re: [openssl-users] [openssl-dev] After building 1.0.2h , ldd output shows current version as 1.0.0. How to CHange this , Why is this so ?

[Kurt Roeckx]

On Thu, Nov 03, 2016 at 01:53:56PM +0100, Richard Levitte wrote:
> Hi,
> 
> I'm curious.  Why exactly do you want to change the shared library
> version?

I had to change the soname in Debian (because I dropped all SSLv2  
and SSLv3 symbols) and changed it to 1.0.2.


Kurt

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

Re: [openssl-users] how to unsubscribe

[Kurt Roeckx]

On Sun, Jul 03, 2016 at 07:42:44AM -0700, Igenyar Saharam wrote:
> Hi,
> 
> 
> Sorry to bother. The suggestion I found is to send email to openssl-users
> with one line message of "unsubscribe openssl-users". I did that but it
> still keeps coming. Could someone kindly instruct me the right way?

Every message to this list contains the instructions.  There are
are 2 options:
- Go to https://mta.openssl.org/mailman/options/openssl-users
- Mail openssl-users-requ...@openssl.org with subject unsubscribe


Kurt

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

Re: [openssl-users] DSA with OpenSSL-1.1

[Kurt Roeckx]

On Fri, Jul 01, 2016 at 05:17:35PM +0100, Matt Caswell wrote:
> 
> "ALL:!COMPLEMENTOFDEFAULT:!eNULL"

Maybe we should use "-" instead of "!"?


Kurt

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

Re: [openssl-users] DSA with OpenSSL-1.1

[Kurt Roeckx]

On Fri, Jul 01, 2016 at 03:54:45PM +, Salz, Rich wrote:
> 
> > In short: Removing support for DSA in OpenSSL would prevent some of our
> > products from updating to 1.1.x for a significant length of time, probably
> > years.
> 
> We have no plans to do that.

But we do change defaults, and it no longer works by default.


Kurt

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

Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

[Kurt Roeckx]

And using -O0?

Which version of openssl are you using?


Kurt

On Tue, Mar 01, 2016 at 06:07:23PM +, Nounou Dadoun wrote:
> I changed it to -O2 and got exactly the same result for the sha512t test ... N
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> Office: 604.629.5182 ext 2632 
> Support: 888.281.5182  |  avigilon.com
> 
> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Kurt Roeckx
> Sent: Tuesday, March 01, 2016 12:16 AM
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with 
> error 67702888--bad signature
> 
> On Tue, Mar 01, 2016 at 12:38:20AM +, Nounou Dadoun wrote:
> > Is it sufficient to change -O3 to -O2 it in the Configure file or is there 
> > somewhere else it needs to be changed?
> 
> Yes, in Configure should be enough.
> 
> Kurt
> -- 
> 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] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

[Kurt Roeckx]

On Tue, Mar 01, 2016 at 12:38:20AM +, Nounou Dadoun wrote:
> Is it sufficient to change -O3 to -O2 it in the Configure file or is there 
> somewhere else it needs to be changed?

Yes, in Configure should be enough.


Kurt

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

Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

[Kurt Roeckx]

On Mon, Feb 29, 2016 at 10:48:22PM +, Nounou Dadoun wrote:
> But this demonstrates that my headaches have been coming from the fact that 
> sha384 and sha512 are broken in our build somehow.  The no-asm configure 
> directive didn't make a difference so maybe a compiler bug or something?

I'm assuming you build using -O3.  Can you try different levels?
I don't know of any problems on Debian using -O2.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

[Kurt Roeckx]

The cipher is using SHA256, there is also a signature using SHA512
for the verification of the client certificate.  I think we've
already pointed out how to disable that.


Kurt

On Mon, Feb 29, 2016 at 08:55:34PM +, Nounou Dadoun wrote:
> And I should add a reminder that the negotiated cipher that's failing is 
> actually TLS_RSA_WITH_AES_256_CBC_SHA256
> 
> Which does seem a little odd with sha256t passing and sha512t failing ... N
> 
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> Office: 604.629.5182 ext 2632 
> 
> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Nounou Dadoun
> Sent: Monday, February 29, 2016 12:41 PM
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with 
> error 67702888--bad signature
> 
> Sorry, that may be the name of one of the associated libraries, in any event 
> it's a Linaro arm toolchain version 4.9.1 running on a linux x-64 vm ... N
> 
> 
> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Nounou Dadoun
> Sent: Monday, February 29, 2016 12:31 PM
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with 
> error 67702888--bad signature
> 
> It's arm-linux-gnueabihf-4.9.1
> 
> ... N
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> 
> Office: 604.629.5182 ext 2632 
> 
> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Kurt Roeckx
> Sent: Monday, February 29, 2016 12:23 PM
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with 
> error 67702888--bad signature
> 
> Which compiler and version are you using?
> 
> Kurt
> 
> On Mon, Feb 29, 2016 at 08:12:10PM +, Nounou Dadoun wrote:
> > For the record, I added no-asm to the config options and got exactly 
> > the same result on the sha512t test.  Open to other suggestions ... N
> > 
> > 
> > Nou Dadoun
> > Senior Firmware Developer, Security Specialist
> > 
> > 
> > Office: 604.629.5182 ext 2632
> > 
> > -Original Message-
> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
> > Behalf Of Nounou Dadoun
> > Sent: Monday, February 29, 2016 11:39 AM
> > To: openssl-users@openssl.org
> > Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> > with error 67702888--bad signature
> > 
> > Back in the office today - the sha1 and sha256 tests passed but the sha512 
> > failed immediately as below.
> > 
> > # ./sha1test
> > test 1 ok
> > test 2 ok
> > test 3 ok
> > # ./sha256t
> > Testing SHA-256 ... passed.
> > Testing SHA-224 ... passed.
> > # ./sha512t
> > Testing SHA-512
> > TEST 1 of 3 failed.
> > #
> > 
> > Took a quick look at the code and it looks pretty straightforward, do you 
> > have a version you'd like me to run that dumps the result over and above 
> > doing a straight memcmp (funny that it doesn't do that anyway on failure) 
> > or just let me know what you'd like dumped and what format you'd like it 
> > in.  And maybe remove the returns so it goes through all the tests?  
> > 
> > Happy to help root cause this issue if I can.
> > 
> > Haven't tried the no-asm option yet, I might try that next.
> > 
> > Nou Dadoun
> > Senior Firmware Developer, Security Specialist
> > 
> > Office: 604.629.5182 ext 2632
> > 
> > -Original Message-
> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
> > Behalf Of Dr. Stephen Henson
> > Sent: Sunday, February 28, 2016 4:58 AM
> > To: openssl-users@openssl.org
> > Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake 
> > with error 67702888--bad signature
> > 
> > On Sun, Feb 28, 2016, Nounou Dadoun wrote:
> > 
> > > 
> > > We're cross-compiling on a linux x86 vm, does "make test" produce 
> > > something that I can run on the target?
> > 
> > "make test" wont be very useful then. The binary test/sha512t you can copy 
> > to the target and run it. I'd be interested in the output.
> > 
> > Steve.
> > --
> > Dr Stephen N. Henson. OpenSSL project core developer.
> > Commercial tech support now available see: http://www.openssl.org
> --
> 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
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

[Kurt Roeckx]

Which compiler and version are you using?


Kurt

On Mon, Feb 29, 2016 at 08:12:10PM +, Nounou Dadoun wrote:
> For the record, I added no-asm to the config options and got exactly the same 
> result on the sha512t test.  Open to other suggestions ... N
> 
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> 
> Office: 604.629.5182 ext 2632 
> Support: 888.281.5182  |  avigilon.com
> Follow Twitter  |  Follow LinkedIn
> 
> 
> This email, including any files attached hereto (the "email"), contains 
> privileged and confidential information and is only for the intended 
> addressee(s). If this email has been sent to you in error, such sending does 
> not constitute waiver of privilege and we request that you kindly delete the 
> email and notify the sender. Any unauthorized use or disclosure of this email 
> is prohibited. Avigilon and certain other trade names used herein are the 
> registered and/or unregistered trademarks of Avigilon Corporation and/or its 
> affiliates in Canada and other jurisdictions worldwide.
> 
> 
> 
> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Nounou Dadoun
> Sent: Monday, February 29, 2016 11:39 AM
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with 
> error 67702888--bad signature
> 
> Back in the office today - the sha1 and sha256 tests passed but the sha512 
> failed immediately as below.
> 
> # ./sha1test
> test 1 ok
> test 2 ok
> test 3 ok
> # ./sha256t
> Testing SHA-256 ... passed.
> Testing SHA-224 ... passed.
> # ./sha512t
> Testing SHA-512
> TEST 1 of 3 failed.
> #
> 
> Took a quick look at the code and it looks pretty straightforward, do you 
> have a version you'd like me to run that dumps the result over and above 
> doing a straight memcmp (funny that it doesn't do that anyway on failure) or 
> just let me know what you'd like dumped and what format you'd like it in.  
> And maybe remove the returns so it goes through all the tests?  
> 
> Happy to help root cause this issue if I can.
> 
> Haven't tried the no-asm option yet, I might try that next.
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> Office: 604.629.5182 ext 2632 
> 
> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Dr. Stephen Henson
> Sent: Sunday, February 28, 2016 4:58 AM
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with 
> error 67702888--bad signature
> 
> On Sun, Feb 28, 2016, Nounou Dadoun wrote:
> 
> > 
> > We're cross-compiling on a linux x86 vm, does "make test" produce something 
> > that I can run on the target?
> 
> "make test" wont be very useful then. The binary test/sha512t you can copy to 
> the target and run it. I'd be interested in the output.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> 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
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

[Kurt Roeckx]

On Sat, Feb 27, 2016 at 07:45:18PM +, Nounou Dadoun wrote:
> PLATFORM=VC-WIN64A 

Can you try a build with no-asm?


Kurt

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

Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

[Kurt Roeckx]

On Sat, Feb 27, 2016 at 06:23:43PM +, Dr. Stephen Henson wrote:
> On Sat, Feb 27, 2016, Nounou Dadoun wrote:
> 
> > Thanks for the response,
> > 
> > I'm not sure what you're saying here other than TLS 1.2 client cert auth
> > processing is different from TLS x (where x<1.2); I would assume that the
> > range of mechanisms would expand to include more robust algorithms as time
> > goes on.  However, here something is breaking backward compatibility with a
> > client certificate that is still valid and otherwise correct as far as I can
> > tell.  Our (many) deployed clients support TLSv1.2 and this certificate is
> > widely distributed - we are trying to upgrade the server side from TLSv1 to
> > TLSv1.2 and this appears to be a blocker.
> > 
> > Any recommendations?  I'm still not clear what it is about this certificate
> > that fails in TLSv1.2; I would define a server callback for the certificate
> > verification (I might experiment with that anyway) but it's not clear to me
> > that it would call the callback if the signature is failing.
> > 
> 
> Well which version of OpenSSL is being used by the server and what software is
> the client using?

>From looking at the packet captures, I would guess that both sides
are OpenSSL.

> When client auth is enabled the client presents its certificate chain to the
> server. It also signs some data using the private key corresponsing to the
> public key in the client certificate and the server verifies that signature.
> 
> It looks like it is this latter signature which is causing the problems and
> nothing to do with the certificates (though they have some odd fields in there
> OpenSSL wouldn't reject them). As I mentioned the type of signature a client
> generates during client auth changed in TLS 1.2. It is possible that the
> client is sending an invalid signature which the server is rejecting while
> the different form used for TLS 1.1 and earlier is fine.

It's using RSA/SHA512 (0x0601), which the server offered.


Kurt

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

Re: [openssl-users] Warning OPENSSL_1.0.0 not found (custom build OpenSSL library)

[Kurt Roeckx]

On Sun, Feb 21, 2016 at 04:15:45PM +, Sandra Schreiner wrote:
> Hello,
> 
> I am currently developing a C++ application with Boost Asio SSL Sockets. 
> Boost Asio uses OpenSSL for it's TLS support. My application will be ported 
> to Android in the future so I tried to build OpenSSL by myself for my current 
> architecture (Linux, Debian, 64bit, VM) in the first run and link it to my 
> application. Everything went well until I ran the application. At first I 
> received a warning 'no version information found' for OpenSSL. 
> I fixed this by providing a version info file like descripted here: 
> http://stackoverflow.com/questions/18390833/no-version-information-available. 
> I changed the version to 1.0.1, because I use OpenSSL 1.0.1f:
> 
> OPENSSL_1.0.1 {
> global:
> *;
> };

I suggest you use the version script from the package you're
trying to replace.


Kurt

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

Re: [openssl-users] Working around servers requiring SSL 2/3 record layer, and using TLS 1.2?

[Kurt Roeckx]

On Wed, Feb 10, 2016 at 09:03:35PM -0500, Jeffrey Walton wrote:
> As far as I know, there are no constants for TLS 1.0 and 1.1, so we
> can't extend this in clients:
> 
> const SSL_METHOD* method = SSLv23_method();
> ctx = SSL_CTX_new(method);
> ...
> 
> const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 |
> SSL_OP_NO_COMPRESSION;
> SSL_CTX_set_options(ctx, flags);

The constant for TLS 1.0, 1.1 and 1.2 exist too.  But I don't
think they're all documented in the 1.0.2 branch.

# define SSL_OP_NO_SSLv2 0x0100L
# define SSL_OP_NO_SSLv3 0x0200L
# define SSL_OP_NO_TLSv1 0x0400L
# define SSL_OP_NO_TLSv1_2   0x0800L
# define SSL_OP_NO_TLSv1_1   0x1000L



Kurt

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

Re: [openssl-users] Extra EPOLLIN event at end of SSL connection

[Kurt Roeckx]

On Mon, Feb 08, 2016 at 07:43:00AM -0700, counterpoint wrote:
> Working on a multi-threaded system that is providing an SSL server
> capability, I am running into an odd problem at the end of a connection.
> There seems no functional downside, in that it appears all data is handled
> correctly. The trouble is errors are being logged.
> 
> What seems to happen is that the connection works fine up to the point where
> it comes to an end. The client uses the application protocol (MySQL) to send
> a message saying it wants to disconnect. However, it seems that there is an
> EPOLLIN event that occurs after this.

TLS also does a shutdown of the connection, in which no
application data is send anymore but at the TLS level packets
still get send.  Is that what you mean?


Kurt

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

Re: [openssl-users] Updating TLS1.1 to TLS1.2

[Kurt Roeckx]

On Sat, Jan 16, 2016 at 10:57:46AM +, Diganta Bhattacharjee wrote:
> 
> I am looking at (query about) updating a TLS 1.1 solution based on OpenSSL 
> 1.0.1b to TLS 1.2. I understand the latest OpenSSL 1.0.2 supports TLS 1.2. At 
> first look I believe if we replace the OpenSSL 1.0.1 with OpenSSL 1.0.2 it 
> should automatically update the TLS to 1.2 versions. That is there should not 
> be any need to do any code changes in application as there is no major 
> changes in API between OpenSSL version 1.0.1 and 1.0.2.
> Can anyone please comment on my above understanding? I am new at OpenSSL and 
> do not have hands-on experience on using OpenSSL for TLS hence looking for 
> comments to understand what the risks in such update.

The 1.0.1 versions already supported TLS 1.2.  If you're getting
TLS 1.1 it might mean that you compiled it with the option not to
support TLS 1.2 as client.  At the time there were servers that
had a problem with clients that supported TLS 1.2, but most of
that should have been fixed.

Upgrading to the 1.0.2 version should also just work because the
API is compatible.

I would also recommend that you keep more up to date with OpenSSL
versions, the 1.0.1b version has various securities issues in it
that were fixed in later versions.


Kurt

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

Re: [openssl-users] libssl.so.1.0.0

[Kurt Roeckx]

On Tue, Jan 12, 2016 at 04:03:42PM -0500, Jeff Archer wrote:
> I am building from source that came from openssl-1.0.2e.tar.gz but it
> appears to be producing output of libssl.so.1.0.0.  Is this what I should
> expect?

Yes.  That is the correct soname for all 1.0.X releases.


Kurt

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

Re: [openssl-users] openSSL and SLOTH attack

[Kurt Roeckx]

On Mon, Jan 11, 2016 at 09:38:05PM +0100, Jakob Bohm wrote:
> On 08/01/2016 18:43, Salz, Rich wrote:
> >Are you going to keep posting and posting until you get a response? :(
> >
> >Master branch, 1.1, is not released but will not be vulnerable (may already 
> >be fixed)
> >1.0.2 is not vulnerable.
> >1.0.1f and later are not vulnerable.
> >1.0.0 might be, and is end of life anyway so you should move of that.
> >0.9.8 is also end of life, but does not do TLS 1.2 so is not vulnerable.
> If you read the description of SLOTH (linked in the OP), you
> will see that it is not limited to TLS 1.2 and probably
> affects the TLS/SSL versions implemented by older (end of
> life) OpenSSL versions such as 0.9.8.
> 
> Basically, it is a laundry list of ways that backward
> compatible hash uses in the SSL/TLS protocols are weaker
> than some people assume.  Their summary list doesn't even
> consider the possibility that some people still need to use
> TLS 1.1 or older, so barely mentions those.
> 
> This also means that completely protecting an
> implementation against SLOTH is not possible without
> breaking interoperability with implementations that
> are not or cannot be updated to the latest protocol
> versions and features (This happens to include some
> widely deployed embedded operating systems).
> 
> Now it so happens that SLOTH also includes an attack on
> implementation bugs that can be tricked into
> using/accepting MD5-based signatures when they shouldn't.
>  That *particular* aspect of SLOTH was apparently fixed
> in 1.0.1f and 1.0.2.
> 
> The entire discussion would have been easier if the SLOTH
> team at INRIA had given specific names and CVE ids for
> each of the issues in their report, such that one might say
> "SLOTH-1: Never vulnerable, SLOTH-2: Fixed in 1.0.1f, SLOTH-3:
> hypothetical for now, can be fixed with a cipher string
> setting, etc. etc."  But no such names exist.

So here are the things mentioned in the paper:
1) Some things that were believed to require preimage resistance
   need collision resistance.  This by itself reduces security bits
   of the hashes by a factor 2.  Assuming MD5 and SHA1 didn't have
   any problem with collision resistance it would be reduced from
   128 and 160 bit to 64 and 80.  But they have a problem with
   collision resistance and so it's worse, specially for MD5.
2) Some implementations support MD5 based signatures in TLS 1.2
3) Some implementations accept the MD5 based signatures in TLS 1.2
   while it would appear they didn't.   

SLOTH really is just about 1).  It says that you should stop using
MD5 and really look at stopping to use SHA1.  And so 2) and 3) are
just 2 cases where MD5 is used.

But just fixing 2) and 3) is just fixing the problem with MD5,
while we should also look at stopping SHA1.  TLS 1.0 and 1.1 use
MD5 + SHA1, so while those are enabled we're stuck at the level of
SHA1.


Kurt

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

Re: [openssl-users] OPenssl and dependencies such as openssh

[Kurt Roeckx]

On Tue, Jan 05, 2016 at 03:40:03PM -0700, The Doctor wrote:
> tls.o(.text+0xf32): undefined reference to `SSLv23_server_method'

Are you sure it's finding the correct headers?


Kurt

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

Re: [openssl-users] Openssl not sending "client hello" request

[Kurt Roeckx]

On Tue, Dec 29, 2015 at 08:35:49PM +0100, Felix Rubio Dalmau wrote:
> Hi all,
> 
>   I  have been searching for some time for a solution and I can not 
> manage to 
> solve my problem. I have a computer that can not connect to some sites, e.g. 
> github, by using openssl. I am running a debian testing with all the updates 
> available as of today, and libssl used is v1.0.2. If I execute:
> 
> > openssl s_client -connect github.com:443

The trace file you attached, which claims to go github.com:443,
did send a Client Hello.  However the reply is a plain text
"400 Bad Request".  It looks like you connected to port 80 and not
443 for some reason.  I suspect something is broken in your network.


Kurt

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

Re: [openssl-users] Find size of available data prior to ssl_read

[Kurt Roeckx]

On Wed, Dec 16, 2015 at 06:23:25PM +, Martin Brampton wrote:
> Is there a way to obtain the amount of data available to be read?
> 
> I'm working with a system that operates in non-blocking mode using epoll.
> When an EPOLLIN event is received the aim is to read the data. For the
> non-SSL case, the amount of data can be obtained using ioctl FIONREAD.  This
> is used to malloc a suitable sized buffer, followed by read the data into
> the buffer.
> 
> How should the SSL version of our code work?  At present it is using the sum
> of the number obtained from ioctl FIONREAD (which seems suspect when SSL is
> in use and appears to be always too large) and the number from ssl_pending
> (which seems to be zero).  The buffer then has to be truncated.

Please note that SSL_pending() returns the data about already
processed / decrypted TLS records.  If the record is not complete
it's not processed and we won't tell how big it is.  This means
that it's possible for SSL_pending() to return 0 and that
receiving a single byte for the kernel might make the whole packet
available.

If you then go and only read 1 byte, calling SSL_pending() will
actually tell you how many other bytes are still has available for
you that already passed all the checks.

So the library can have unprocessed bytes from a TLS record in
it's internal buffer, but it's not going to tell you much about
it.

SSL / TLS also has overhead, the data might also not even be
application data.  Also, some ciphers work in blocks so there
might be added padding for those blocks.  So there are various
reasons why you might receive less data too.

If you always call SSL_read() on the boundaries of the records
you'll always get less data, but there is really no way for you to
see that.  It might be that in your application this is always
what happens, but I wouldn't rely on it.

If you don't call in on the boundaries there is little
you can predict about the size you're going to get.


Kurt

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

Re: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16)

[Kurt Roeckx]

On Sat, Dec 12, 2015 at 10:23:38PM +0100, Dominik Mahrer (Teddy) wrote:
> Hi everyone
> 
> My question is:
> How can I set up a bundle of commercial root CA certificates?
> Exactly this the same question I found as FAQ # 16 (User). But as answer
> there is only explained that openssl will not serve a bundle. But it is not
> explained how to set up a bundle - but exactly this I would like to know.

Why do you think you need a bundle?  How will this bundle then be
used?

An answer could be that you just cat all the pem files into 1
large file.


Kurt

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Kurt Roeckx]

On Wed, Dec 09, 2015 at 05:13:32PM -0600, Benjamin Kaduk wrote:
> C does not make such a guarantee, though recent-ish POSIX does.  (This
> system is a windows one, thought, right?)

There are DSPs that only support 32 bit, they don't have a concept
of 8 bit.  But I think there is various code that assumes that
char is 8 bit, and I doubt you can get OpenSSL working on such a
system.


Kurt

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

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Kurt Roeckx]

On Thu, Dec 10, 2015 at 04:55:29AM -0700, Jayalakshmi bhat wrote:
> Hi Matt,
> 
> Thanks for the patch. Unfortunately patch did not work. I continued
> debugging and found that issue was in constant_time_msb.
> 
> static inline unsigned int constant_time_msb(unsigned int a) {
> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
> }

This looks a revert of commit
d2fa182988afa33d9e950358de406cc9fb36d000

It was changed because of the implementation defined behaviour,
and we would like to avoid that.  See RT ticket #3558.


Kurt

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

Re: [openssl-users] long (~2.5 minute) delay in TLS handshake

[Kurt Roeckx]

On Mon, Nov 30, 2015 at 10:46:45PM +, Michael Wojcik wrote:
> I'm curious if anyone has seen anything like this before.
> 
> We have a situation at one customer site. They see it happen every few days. 
> No one else has reported it, and we can't reproduce it.

Have you considered that this might be a path MTU discovery issue
and that the TCP layer is just resending the (too large) packet
without it reaching the other side?


Kurt

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

[openssl-users] 1.0.2 long term support

[Kurt Roeckx]

1.0.2 long term support
===

The OpenSSL project team would like to announce that the 1.0.2
version will be supported until 2019-12-31.

Further details about the OpenSSL Release Strategy can be found here:
https://www.openssl.org/about/releasestrat.html

The OpenSSL Project Team



signature.asc
Description: Digital signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-1.0.2d] default SSL handshake fails

[Kurt Roeckx]

On Sat, Aug 01, 2015 at 06:56:16AM +0200, Jakob Bohm wrote:
 
 The old team would have gone out of their way to make sure
 the standard OpenSSL code would generate backward compatible
 hello records by default

So it's my understanding that you suggest the default OpenSSL
client should:
- Only support SSLv2, SSLv3 and TLS1.0 because things break when
  we we try to talk to some sites indicating we support TLS 1.1
  and/or 1.2?  Maybe we should even disable TLS 1.0 and SSLv3?
- Don't send any TLS extentions, since some sites don't support
  it?
- Don't send any cipher strings with the first byte different from
  0 because some implemantation don't look at the first byte and
  might then select a cipher we didn't announce?
- Enable all the work arounds for broken implementations again,
  even when they can be exploited?
- Give RC4 such a priority by default that it's in the list before
  much stronger ciphers because that's the only cipher from our
  default list that works with some implementations, even when the
  RFCs say we should disable RC4 by default?

I guess we should just stop trying to improve in general.


Kurt

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

Re: [openssl-users] CVE-2015-1793 only on cert-based client auth?

[Kurt Roeckx]

On Mon, Jul 13, 2015 at 01:03:09PM -0400, Colin Edwards wrote:
 I've been reading/hearing different opinions on the recent vulnerability
 for cert chain forging that was patched (CVE-2015-1793).
 
 Some people are saying the vulnerability only exists if a system is using
 certificate-based client authentication (mutual auth, where both server and
 client are authenticated).  `Basically, that the chain forging can only be
 done on the client side.
 
 Others are saying certs can be forged on the server, on implementations
 that use only server-side authentication, and if the client is using
 OpenSSL it will verify/accept the forged chain.  The could effectively
 result in MitM against OpenSSL clients.

It's whenever a certificate is received (and validated).  This
means either:
- A client is authenticating a server (server authentication)
- A server is authenticating a client (client authentication)

Of course both could be happening for the same connection.

It's much more common that the client authenticates the server.
Certainly for https client authentication is uncommon.  Also, for
https the client ussually isn't OpenSSL based, except for android.


Kurt

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

Re: [openssl-users] CVE-2015-1793 only on cert-based client auth?

[Kurt Roeckx]

On Tue, Jul 14, 2015 at 01:23:52PM -0400, Colin Edwards wrote:
 Thank you, Kurt.  The information I was getting (from some sources) was that
 the vulnerability was only present in configurations where the server was
 authenticating a client certificate.  The fact is, the vulnerability applies
 to certificate validation regardless of if it's on the client or server
 side.

Right, and validation doesn't even have to be about TLS either.
It's about any check of a certificate chain.


Kurt

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

Re: [openssl-users] Alternatives to flat text file database back-end?

[Kurt Roeckx]

On Wed, Jul 01, 2015 at 01:38:28PM +0300, Ikonta wrote:
 Hi everybody,
 
 Possibly stupid question:
 The default and only known for me OpenSSL database format is flat text file 
 (afair index.txt in default openssl.cnf).
 Was ever suggested an idea to provide some alternatives (maybe relational 
 (SQL) database server, or sqlite, or LDAP)?
 What can I read (or at least what keywords use to search) about it?

You might want to look at:
https://pki.openca.org/
http://www.ejbca.org/

Others are:
http://xca.sourceforge.net/
tinyca (website doesn't seem to work anymore, it's probably not
what you want.)

There is also https://github.com/letsencrypt/boulder, but that's
probably not what you're looking for.


Kurt

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

Re: [openssl-users] Query on TLS1.2 and use of DES ciphers

[Kurt Roeckx]

On Mon, Jun 29, 2015 at 05:48:05AM +, Srinivas wrote:
 Thanks. Makes sense.
 
 But then why are the DES ciphers not listed in the supported cipher list for 
 TLSv1.2 
 here?https://www.openssl.org/docs/apps/ciphers.html#TLS-v1.2-cipher-suites

Those are all ciphers that require at least TLS 1.2.


Kurt

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

Re: [openssl-users] Vulnerability logjam downgrades TLS connections to 512 Bit

[Kurt Roeckx]

On Wed, May 20, 2015 at 03:47:33PM +, Scott Neugroschl wrote:
 Is OpenSSL vulnerable to Logjam?

See
http://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/


Kurt

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

Re: [openssl-users] OpenSSL Behaviour under low bandwidth

[Kurt Roeckx]

On Fri, May 15, 2015 at 12:44:03PM +0100, Martin Beynon wrote:
 
 That is right from 100Mbps down to 150 kpbs everything works as expected.
 As I continue tuning down the bandwidth below 150kbps openssl starts to
 stop sending data. It becomes very bursty and there are whole periods of
 seconds where no data is sent from openssl even though it's 17KB TLS buffer
 is full and pings, for example, can be sent and received normally.
 
 There appears to be some relation to the size of this buffer and the
 minimum achievable throughput we can get.. Unless my maths is off; 140 Kbps
 would give about 17KB/s throughput.. Coincidence?

Do you send packets to OpenSSL in blocks of 17 KB?  Is that
blocking or non-blocking?


Kurt

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

Re: [openssl-users] [openssl-dev] openssl-1.0.2-stable-SNAP-20150504 error

[Kurt Roeckx]

On Mon, May 04, 2015 at 07:21:11AM -0600, The Doctor wrote:
 This also occured in openssl-1.0.2-stable-SNAP-20150503

This will most likely be fixed in the next snapshot.


Kurt

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

Re: [openssl-users] Working with large DH parameters

[Kurt Roeckx]

On Mon, May 04, 2015 at 09:00:21AM -0500, jack seth wrote:
  There is a limit of 1:
  #define OPENSSL_DH_MAX_MODULUS_BITS 1
 
  I suggest you do not change this. It just gets slower without
  adding security.
 
  I have no idea why it would freeze with something larger than
  13824.
 
  I'm not sure what is logging the size, but it might be using
  DH_size()*8 to log it. I don't think their currently is an API
  that returns it in bits.
 
 
  Kurt
 
 Thanks for the response.  Could you elaborate on why a larger size doesn't 
 add security?  For the sake of discussion, lets ignore how slow it would be.  
 According to section 5.6.1 of 
 http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf
   you would need 15360+ bit to have security equal to AES256.   Is NIST wrong 
 here?  If so, why?

Everything in the chain would need to be providing 256 bit of
security, there are no ciphers that support more than 192 as far
as I know.

Once you're at 128 or above it's also far more likekly that
something other than the crypto is the weakest part, like a human.


Kurt

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

Re: [openssl-users] Regarding the Support for TLS 1.3

[Kurt Roeckx]

On Mon, May 04, 2015 at 03:12:17PM +, Salz, Rich wrote:
  I would like to know whether OpenSSL supports TLS 1.3, if supported from 
  which version of OpenSSL the implementation started. 
 
 Since TLS 1.3 is not even done yet, no.  If I had to guess, I'd say it won't 
 be done for at least six months.

I would say that TLS 1.3 is just a bunch of ideas at this point.
There is nothing we can really do to even prepare for it.


Kurt

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

Re: [openssl-users] Working with large DH parameters

[Kurt Roeckx]

On Tue, Apr 28, 2015 at 09:26:25AM -0500, jack seth wrote:
 Ok I have been doing some experiments with OpenVPN and I can connect using 
 1 bit DH parameters.  Any bigger than that up to at least 13824 I get the 
 following 'modulus too large' error on the client log:
 
 TLS_ERROR: BIO read tls_read_plaintext error: error:05066067:Diffie-Hellman 
 routines:COMPUTE_KEY:modulus too large: error:14098005:SSL 
 routines:SSL3_SEND_CLIENT_KEY_EXCHANGE:DH lib
 Wed Apr 22 07:08:58 2015 TLS Error: TLS object - incoming plaintext read 
 error
 Wed Apr 22 07:08:58 2015 TLS Error: TLS handshake failed
 
 Something interesting/weird also happened.  I tried to test 10001, 10002, and 
 10004 bit DH to find the exact place I would get the 'modulus too large' 
 error.  But the server log reported the DH parameters being 10008 instead.  I 
 did a test at 15104 that gave the same error but then I tried two more times 
 and the client just sat at the 'initial packet point' like it does with the 
 16384 bit parameters.  So somewhere between 13824 and 16384 it switches 
 between the error above and just sitting there 'frozen'.
 
 Questions: 1. Can the modulus error be cured?  2. Do you think the same 
 modulus error is going on when the client appears to freeze with parameters 
 larger than 13824 or is something else going (i.e. why does it freeze instead 
 of giving the 'modulus error')?  3. Why does the server log report 10001, 
 10002, 10004 bit DH as 10008?   

There is a limit of 1:
#define OPENSSL_DH_MAX_MODULUS_BITS1

I suggest you do not change this.  It just gets slower without
adding security.

I have no idea why it would freeze with something larger than
13824.

I'm not sure what is logging the size, but it might be using
DH_size()*8 to log it.  I don't think their currently is an API
that returns it in bits.


Kurt

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

Re: [openssl-users] Trying to understand DTLS (as it applies to webrtc)

[Kurt Roeckx]

On Fri, May 01, 2015 at 09:01:47PM +0100, Matt Caswell wrote:
 
 
 On 01/05/15 20:09, faraz khan wrote:
  Matt,
  Thanks again! To be precise webrtc is using boringssl (Google's fork of
  openssl). From the commits it seems VERY recent but I'm unable to figure
  out the last openssl merge-in. You think this could be the issue? Should
  I try both with boringSSL (its kinda hard to compile webrtc with openSSL
  now since after the move to boringSSL)
 
 Ahhh. BoringSSL. That means a slightly different list of potential
 causes (they forked OpenSSL 1.0.2, and have continued to make changes
 since then). I've just checked the latest dev version, and that means
 possible causes:
 
 - digest check failed processing the Finished message
 - CRL signature failure processing the client Certificate
 - Overly short RSA key
 - Bad RSA decrypt/signature processing the CertificateVerify
 
 To be honest I am more inclined to believe it is a problem on the client
 side rather than the WebRTC side. The fact that it goes away after you
 restart the client suggests to me that the client is getting itself into
 a strange state. Perhaps some kind of memory corruption (either through
 client application or openssl bug)?
 
 Anyway I'd suggest two things as next steps:
 - Try and figure out how to get more logging out of WebRTC to find out
 more specifically what it is complaining about
 - Upgrade your OpenSSL version to 1.0.1m

He could also try to use something like valgrind to see if memory
gets corrupted, or use build it using address sanitizer.


Kurt

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

Re: [openssl-users] Can't connect to site, OpenSSL returns error

[Kurt Roeckx]

On Mon, Apr 27, 2015 at 02:39:08PM +, Salz, Rich wrote:
  It is weird that it worked for you. Anyway I found a way how to fix it (if 
  I can
  call it a fix). The key is to provide a flag -servername
  to enable SNI (Server Name Indication).
 
 It's not wrong to call it a fix.  The server you are talking to is configured 
 to require SNI, apparently.

So why does it work for me?

 This is not an openssl issue/bug.

Right, the other end is sending that it has an internal error.
There is little we can do about that.


Kurt

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

Re: [openssl-users] Can't connect to site, OpenSSL returns error

[Kurt Roeckx]

On Sun, Apr 26, 2015 at 07:05:11PM +0200, hub...@seznam.cz wrote:
 I tried this command
 openssl.exe s_client -connect ezfile.ch:443
 
 And it returns this kind of error
 error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal
 error

I can not reproduce this.  What version are you using?

There is nothing wrong with that server, so it's most likely a
problem with whatever you're using.



Kurt

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

Re: [openssl-users] [openssl-dev] removing compression?

[Kurt Roeckx]

On Fri, Apr 03, 2015 at 07:53:59PM +, Salz, Rich wrote:
 
 And the best practice these days is to do it at the application
 layer, and feed the compressed bytes down to TLS.

The BREACH attack makes use of that.


Kurt

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

Re: [openssl-users] SNAPSHOT updates

[Kurt Roeckx]

On Fri, Mar 13, 2015 at 11:14:18AM -0600, The Doctor wrote:
 What is happening?
 
 In the Moutain Time Zone:
 
 It was at 22:22 MST then 23:22 MDT then 00:22 MDT !!

Do you mean when the snapshot is made?  The machine runs in UTC,
and the files seem to be made at 6:22 UTC.


Kurt

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

Re: [openssl-users] Delay of email delivery for the list

[Kurt Roeckx]

On Tue, Mar 10, 2015 at 10:23:41PM +0300, Serj Rakitov wrote:
 Hello,
 
 I see some delay about 30-40 min for my emails. They arrive and I see them in 
 the incoming messages in the list only after 30-40 min.  And one email was 
 delivered for 2 hours. Is it normal for the openssl-users@openssl.org?
 
 Some time ago I see an email with message: Welcome to the 
 openssl-us...@mta.opensslfoundation.net mailing list!
 
 Maybe now when something have changed we must send emails to the 
 openssl-us...@mta.opensslfoundation.net not to the openssl-users@openssl.org?

The mta.opensslfoundation.net was only very temporary and should
not be used.  openssl-users@openssl.org works just fine and
doesn't have any delay for me.  You can always check the headers
why or where it has any delay.


Kurt

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

Re: [openssl-users] SSL_read preserving message boundaries.

[Kurt Roeckx]

On Sat, Mar 07, 2015 at 11:47:12AM +, Salz, Rich wrote:
 
  So this is preserving message boundaries. How do I get the complete
  message just like with TCP?
 
 No, it just happened that way.  TLS does not preserve message boundaries.

As far as I know SSL_read will only return data from 1 record.


Kurt

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

Re: [openssl-users] Intermediate certificates

[Kurt Roeckx]

On Tue, Jan 27, 2015 at 11:42:51PM +0300, Serj wrote:
 
  It is unfortunate that browsers lend a helping hand to such sites.
 So, you want to say that browsers trust connections that don't provide 
 intermediate certs during SSL handhake?
 As I know most browsers have also intermediate certs in their stores as 
 builtin objects and also as received during handshakes.
 That's why any documentation how to set intermediate certificates for my SSL 
 connections will be very needed.

What browsers do is cache the intermediate certificates.  If a
sites fails to send them, the browser can still find it in it's
cache and use those cached intermediate certificates to do the
validation.

If the missing intermediate certificate is not cached the site
will not work in the browser.  But if you then visit a site that
has the same intermediate certificate that does send it, and then
go back to the broken site it will suddenly work.

Browsers have too many work arounds for broken sites which results
in those sites not actually getting fixed.


Kurt

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

Re: [openssl-users] Handle Leaks - shmem-win32.c shmem.c - OpenSSL 1.0.1l

[Kurt Roeckx]

On Sat, Jan 24, 2015 at 04:34:14PM -0500, Avery A. Tarasov wrote:
 
 Important findings:
 
 *1) * IfSSL_library_init() and SSL_load_error_strings() are *removed*
 (which are the only 2 OpenSSL functions I'm using) the handle leaks go
 away..
 
 *2)*  IfSSL_library_init() and SSL_load_error_strings() are *kept* but
 the creation of the thread is *removed* -- no more handle leaks..

And that thread is clean up?  You know a thread has a handle too?


Kurt

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

Re: [openssl-users] Does CVE-2014-3569 apply without the no-ssl3 build option

[Kurt Roeckx]

On Mon, Dec 29, 2014 at 10:37:49AM -0700, Zeke Evans wrote:
 Is an OpenSSL 1.0.1j build that does not use the no-ssl3 build option
 still vulnerable to CVE-2014-3569?  It seems the SSLv3 handshake to a
 no-ssl3 application scenario is just one way to exploit this and that
 the ssl23_get_client_hello function causes this issue for any
 unsupported or unrecognized version.

The can return NULL in case of no-ssl2 or no-ssl3 when receiving
SSLv2 or SSLv3.  But in case of SSLv2 that function isn't called,
it directly sets the method to SSLv2_server_method() in that case
if the previous if block.

Please note that s-verion can't be set to a unknown value but can
be set to an unsupported value.  SSL2_VERSION and SSL3_VERSION are
the only 2 options that are known but can be unsupported.  But as
stated above this doesn't affect SSLv2.

So in summary this only has an effect when build using no-ssl3.


Kurt

___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL Release Strategy and Blog

[Kurt Roeckx]

On Sun, Dec 28, 2014 at 01:31:38AM +0100, Jakob Bohm wrote:
 3. The 1.0.x binary compatibility promise seems to not have been
  completely kept.  As recently as just this December, As a practical
  example: I had an OS upgrade partially fail due to the presence of
  a self-compiled up to date 1.0.1* library that conflicted with an
  OS supplied 1.0.x library that was frozen earlier while relying on
  your promise.

Can you give more details about this?  Please note the binary
compatibility will only work if you used the same options to build
the library.  (This is one of the reasons to make more structures
opaque.)

   Also the 1.0.1 changelog includes at least one change of binary
  flag values to get a different compatibility behavior than
  previous 1.0.1 releases, thus there is not even binary
  compatibility within 1.0.1 .

I assume you're talking about SSL_OP_NO_TLSv1_1?  It's unfortunate
that SSL_OP_ALL already contained that in 1.0.0 while 1.0.0
doesn't even know anything about TLS 1.1.  But that only affects
people who compiled with 1.0.1 or 1.0.1a headers.

  must choose one of the stabilized 1.0.x releases (1.0.0 or 1.0.1)
  as the new LTS release, and you need to deal with the fact that
  since the 0.9.8 end-of-life announcement, you have been unclear
  which of the two existing 1.0.x releases would be LTS-security,
  causing some projects (not mine, fortunately) to irreversibly
  pick a different one than you did.

I think people should stop using both 0.9.8 and 1.0.0 as soon as
possible since they do not support TLS 1.2.  You really want to use
TLS 1.2.

   The best you can do is to split libcrypt into two or tree well
  defined layers, that can be mixed in applications but do not break
  their layering internally.  These could be: rawalgs (non-opaque
  software primitives, bignums etc.  with CPU acceleration but
  nothing more fancy)

I don't think we intend to remove functions like AES_* yet but
might deprecate them in favour APIs that exist for a very long
time.  Please note that for instance using the AES functions you
do not have AESNI acceleration but by using the EVP interfance you
do.


Kurt

___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL performance issue

[Kurt Roeckx]

On Fri, Dec 19, 2014 at 02:30:07AM +0530, Prabhat Puroshottam wrote:
 ***
 This is for *Client - Agent*
 ***
[...]
     Version 3.1
[...]
     cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA
[...]
 ***
 This is for *Client - Proxy Server*
 ***
     cipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA

So the differnce here is that jave picks a DHE ciphersuite while
otherwise you didn't.  DHE gives you forward secrecy but is
slower.

You're also not using session resumption which might speed up the
whole process.  It at least looks like that proxy server might
support that.

You also seem to be using an old version of openssl that only
supports TLSv1, I suggest you upgrade.


Kurt

___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] More POODLE issues

[Kurt Roeckx]

On Wed, Dec 10, 2014 at 09:51:15AM -0700, The Doctor wrote:
 Now POODLE  is hitting  TLS
 
 http://www.computerworld.com/article/2857274/security0/poodle-flaw-tls-itbwcw.html
 
 Any fixes in the works?

As already said previously, openssl is not affected by this.


kurt

___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Re: [openssl-users] Freeze to mailing list memberships

[Kurt Roeckx]

On Sat, Dec 06, 2014 at 10:08:30AM +0100, Walter H. wrote:
 On 05.12.2014 23:08, Kurt Roeckx wrote:
 On Fri, Dec 05, 2014 at 02:50:00PM -0700, Philip Prindeville wrote:
 On Dec 5, 2014, at 1:57 PM, Walter H.walte...@mathemainzel.info  wrote:
 
 On 05.12.2014 21:46, Kurt Roeckx wrote:
 On Fri, Dec 05, 2014 at 07:34:13PM +, TJ wrote:
 On 26/11/14 02:05, Salz, Rich wrote:   We will soon be freezing the 
 mailing list memberships for a couple of days.
 We are moving to a new server and upgrading the mail infrastructure
 Are you aware that the headers for the mailman configuration are 
 inconsistent; some specify the previous
 openssl.org email addresses whilst others use the 
 mta.opensslfoundation.net address.
 They should all have been changed from mta.opensslfoundation.net
 to openssl.org.
 
 now, what is the email adress in the To for List
 which I can use to sort in at my IMAP server?
 
 I would use the List-Id: value, actually.
 
 openssl-users.openssl.org
 openssl-users.mta.opensslfoundation.net
 
 Sometimes multiple lists are copied, sometimes the list is Bcc'd.
 The 2nd one was temporary, use the first one.
 
 
 Kurt
 then have a try;
 
 by the way: some mails that were sent/received by some through this list,
 don't contain the List-Id ...

We just changed from majordomo that doesn't support List-Id's to
mailman that does.  All the mails since the move to mailman should
have had a List-Id, but at some point it contained
mta.opensslfoundation.net and was changed to openssl.org


Kurt

___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users