Re: [openssl-users] explicitly including other ciphers.

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Jakob Bohm > Sent: Thursday, December 03, 2015 21:11 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] explicitly including other ciphers. > > On 04/12/2015 03:03, Michael Wojcik wrote: > > So rather than

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

Hi All, Recently we have ported OpenSSL 1.0.2d. Everything works perfect except the below explained issue. When we enable only TLS 1.0 protocol and select CBC ciphers, TLS handshake fails with the error "bad record mac". Error is in function static int ssl3_get_record(SSL *s). Error

Re: [openssl-users] Response from server is lost on close

Hi, yes, tcp is free to discard receive buffer on receiving RST however after looking through the source code of linux kernel, it seems that process just set state of socket, not discard data in receive buffer. 1. tcp_validate_incoming 5184 /* Step 2: check RST bit */ 5185 if

[openssl-users] Compiling up 1.0.2e - missing files

Anyone else seeing these two issues... ./Configure shared linux-elf make make test [...] This test will take some time123456789ABCDEF ok ../util/shlib_wrap.sh ./randtest test 1 done test 2 done test 3 done test 4 done make[1]: *** No rule to make target `bctest', needed by `test_bn'.

Re: [openssl-users] Symlinks broken in 1.0.2e ?

On Thu, Dec 03, 2015 at 04:59:56PM +, Viktor Dukhovni wrote: > $ tar zxf openssl-1.0.2e.tar.gz > > # Clean up > $ find openssl-1.0.2e -name openssl-1.0.2e -type l -print0 | xargs -0 rm Sorry, to be clear, the "cleanup" is not something you can do until after you've built the

Re: [openssl-users] Symlinks broken in 1.0.2e ?

On Thu, Dec 03, 2015 at 08:47:11AM -0800, Norm Green wrote: > It looks like symlinks are broken in 1.0.2e. A relative path was used in > 1.0.2d but not 1.0.2e. Oops... Work-around below: > How can I resolve this? # Create parent directories for missing "openssl-1.0.2e" nodes $ tar

Re: [openssl-users] Verify callback to ignore certificate expiry

Calling X509_STORE_CTX_set_error(ctx, X509_V_OK); Is actually what I'm doing already but I was worried that it would then ignore any other errors (e.g. bad signature etc.); I'd actually thought the errors might be ORed together but that doesn't look like the case. So does it invoke the

Re: [openssl-users] Verify callback to ignore certificate expiry

Thanks for your help, I posted the sample (which I guess is a little misleading given that it's taken straight off the OpenSSL page I noted) and not what it currently does which is very close to what you've suggested. So that's one problem I don't have to worry about! Thanks again ... N

Re: [openssl-users] Symlinks broken in 1.0.2e ?

Hi Viktor, Thanks for the workaround. After running your code I now see this: cast.h -> openssl-1.0.2e/../../crypto/cast/cast.h openssl-1.0.2e -> . Which is still different than 1.0.2d: cast.h -> ../../crypto/cast/cast.h Are these new symlinks here to stay or were they included in the in

[openssl-users] stunnel 5.27 released

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Users, I have released version 5.27 of stunnel. The ChangeLog entry: Version 5.27, 2015.12.03, urgency: MEDIUM * Security bugfixes - OpenSSL DLLs updated to version 1.0.2e. https://www.openssl.org/news/secadv_20151203.txt * New

Re: [openssl-users] Verify callback to ignore certificate expiry

On Thu, Dec 03, 2015 at 05:00:12PM +, Nounou Dadoun wrote: > Calling > X509_STORE_CTX_set_error(ctx, X509_V_OK); > Is actually what I'm doing already but I was worried that it would then > ignore any other errors (e.g. bad signature etc.); No, because is error is reported separately,

[openssl-users] Latest tarballs; symlink errors

Hello, (0.9.8zh, 1.0.0t, 1.0.1q, 1.0.2e) I try to extract the tarballs and receive errors like: tar: openssl-1.0.2e/apps/md4.c: Cannot create symlink to `openssl-1.0.2e/../crypto/md4/md4.c': No such file or directory tar: Exiting with failure status due to previous errors $ gpg

[openssl-users] Symlinks broken in 1.0.2e ?

It looks like symlinks are broken in 1.0.2e. A relative path was used in 1.0.2d but not 1.0.2e. Here's an example compared with 1.0.2d: normg@bunk>tar -ztvf openssl-1.0.2e.tar.gz |grep cast.h -rw-rw-r-- openssl/openssl 4659 2015-12-03 06:04 openssl-1.0.2e/crypto/cast/cast.h lrwxrwxrwx

Re: [openssl-users] Symlinks broken in 1.0.2e ?

On Thu, Dec 03, 2015 at 09:34:03AM -0800, Norm Green wrote: > Thanks for the workaround. After running your code I now see this: > > cast.h -> openssl-1.0.2e/../../crypto/cast/cast.h > openssl-1.0.2e -> . > > Which is still different than 1.0.2d: > > cast.h -> ../../crypto/cast/cast.h > >

[openssl-users] OpenSSL version 0.9.8zh released

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 0.9.8zh released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8zh of our open

[openssl-users] OpenSSL version 1.0.2e released

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.2e released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2e of our open source

Re: [openssl-users] Verify callback to ignore certificate expiry

On Thu, Dec 03, 2015 at 06:01:36AM +, Nounou Dadoun wrote: > Another quick question, I'm setting up a server ssl handshake on a device on > which the certificate verification will sometimes fail not because the > certificate is bad but because the time is not set properly on the device. >

Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses

Thank you Steve, This is very useful information. >>I'm getting private queries about this (why is there is such reluctance to discuss the delights of FIPS 140-2 in public?). I've noticed technical questions related to private FIPS certifications never get answered, at least not on this

[openssl-users] OpenSSL version 1.0.0t released

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.0t released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.0t of our open source

[openssl-users] OpenSSL version 1.0.1q released

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.1q released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1q of our open source

Re: [openssl-users] FIPS 140-2 X9.31 RNG transition expenses

On 12/03/2015 10:41 AM, R C Delgado wrote: > ... > > BTW, I had guessed why FIPS certification questions don't get answered: > it's all about funding, but thank you for explaining it in your email. >>>... FIPS validation business; it has gone > from economically marginal to unsustainable and as a

[openssl-users] OpenSSL Security Advisory

. References == URL for this Security Advisory: https://www.openssl.org/news/secadv/20151203.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/about

[openssl-users] OpenSSL version 1.0.2e released (corrected download)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 1.0.2e released

[openssl-users] OpenSSL version 1.0.1q released (corrected download)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 1.0.1q released

[openssl-users] OpenSSL version 1.0.0t released (corrected download)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 1.0.0t released

[openssl-users] OpenSSL version 0.9.8zh released (corrected download)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Due to an error in the release process the original distribution downloads were failing to build. New downloads have now been made available on the website. Corrected checksums are given below. OpenSSL version 0.9.8zh released

Re: [openssl-users] explicitly including other ciphers.

What about openssl? (little confused here).. I would expect openssl being the one that needs to be rebuild, not apache. On 12/03/2015 11:15 AM, Wall, Stephen wrote: So in general, I would have to build apache before I could use null ciphers? That is correct. -spw

[openssl-users] Symlinks STILL broken in 1.0.2e

There are still many broken symbolic links in the new 1.0.2e tarball: Example: >ls -l ./test/ecdsatest.c lrwxrwxrwx 1 normg smalltalk 42 Dec 3 06:44 ./test/ecdsatest.c -> openssl-1.0.2e/../crypto/ecdsa/ecdsatest.c >cat ./test/ecdsatest.c cat: ./test/ecdsatest.c: No such file or directory

Re: [openssl-users] explicitly including other ciphers.

On 12/03/2015 01:50 PM, Richard Moore wrote: ​If network is fully isolated you could use plain text. Using 'https' and null encryption is basically just pretending to do security. I've never done any work with the eNULL ciphers, so please correct me if I'm wrong, but wouldn't they still

Re: [openssl-users] explicitly including other ciphers.

On 2 December 2015 at 17:53, Ron Croonenberg wrote: > So the idea is to use an object store on an isolated network and push and > get objects out of it using https. > > ​If network is fully isolated you could use plain text. Using 'https' and null encryption is basically just

Re: [openssl-users] explicitly including other ciphers.

> What about openssl? (little confused here).. I would expect openssl > being the one that needs to be rebuild, not apache. As Viktor previously stated, openssl has the NULL ciphers built in by default. Your reply to Rich seemed to confirm that your version of openssl does include them:

Re: [openssl-users] Symlinks STILL broken in 1.0.2e

Are these sym links going to remain this way in subsequent releases? Or will they revert back to the way they were in 1.0.2d? Merging changes like this into svn is a pain because it causes conflicts. Norm Green On 12/3/15 13:31, Matt Caswell wrote: On 03/12/15 21:27, Norm Green wrote:

Re: [openssl-users] Symlinks STILL broken in 1.0.2e

On 03/12/15 21:37, Norm Green wrote: > Are these sym links going to remain this way in subsequent releases? Or > will they revert back to the way they were in 1.0.2d? Merging changes > like this into svn is a pain because it causes conflicts. They won't remain broken. It's undecided whether

Re: [openssl-users] Symlinks STILL broken in 1.0.2e

On 03/12/15 21:27, Norm Green wrote: > There are still many broken symbolic links in the new 1.0.2e tarball: > > Example: >>ls -l ./test/ecdsatest.c > lrwxrwxrwx 1 normg smalltalk 42 Dec 3 06:44 ./test/ecdsatest.c -> > openssl-1.0.2e/../crypto/ecdsa/ecdsatest.c >>cat ./test/ecdsatest.c > cat:

Re: [openssl-users] explicitly including other ciphers.

1: correct: you could still evesdrop on the connection, BUT we know who is on there since we authenticated. (It is a storage system, not on a public network and has an internal network for communicating between the node (approx 30PB and 50 servers) We know exactly who are on there and

Re: [openssl-users] explicitly including other ciphers.

The network is isolated from the outside worl, BUT we still need authentication because different users are using it. So what I preferably want is sort of a set up where, authentication is done the "standard way" and after that just use the https connection without the overhead of actually

Re: [openssl-users] explicitly including other ciphers.

So in general, I would have to build apache before I could use null ciphers? On 12/02/2015 11:06 AM, Wall, Stephen wrote: Encryption in https/apache is handled by mod_ssl. does that means, since there are NULL ciphers I can just use them in apache/mod_ssl by just changing a setting like:

Re: [openssl-users] Latest tarballs; symlink errors

Hello, I still have symlink errors with 4 latest uploads. $ gpg --verify openssl-1.0.2e.tar.gz.asc openssl-1.0.2e.tar.gz gpg: Signature made 12/03/15 12:01:26 gpg:using RSA key 0xD5E9E43F7DF9EE8C gpg: Good signature from "Richard Levitte " Primary key

Re: [openssl-users] explicitly including other ciphers.

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Ron Croonenberg > Sent: Thursday, December 03, 2015 18:35 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] explicitly including other ciphers. > > The network is isolated from the outside worl, BUT we

Re: [openssl-users] explicitly including other ciphers.

On 04/12/2015 03:03, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Ron Croonenberg Sent: Thursday, December 03, 2015 18:35 To: openssl-users@openssl.org Subject: Re: [openssl-users] explicitly including other ciphers. The network is isolated

Re: [openssl-users] explicitly including other ciphers.

Since the network is (as I understand it) physically secure against wiretapping, how about using plain http with http auth? Or are you trying to protect against TCP connection hijacks by other computers/processes on the "secure" network? On 04/12/2015 00:35, Ron Croonenberg wrote: The network

[openssl-users] PKEY signing failing in fips mode

Hi, I'm trying to change the ssh-rsa.c to be fips compliant. So, after some investigation I added the following code to to ssh_rsa_sign function to make it fips compliant. == signing_key = EVP_PKEY_new();

Re: [openssl-users] explicitly including other ciphers.

> So in general, I would have to build apache before I could use null > ciphers? That is correct. -spw ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users