Kurt Roeckx via RT | 3 Aug 16:20 2015
Picon

Re: [openssl.org #3977] bug report : Ubutu 12.0.4 : Openssl 1.0.1p : allowing connections with EXP cipher

On Mon, Aug 03, 2015 at 12:03:26PM +0000, sandeep umesh via RT wrote:
> I was expecting that openssl will reject connection request with EXP cipher
> which is not happening as seen above.
> Could you please verify this? Thanks

If you configure it to allow export ciphers or ALL, of course it's
going to allow them.  The export ciphers have been removed from
DEFAULT.

Kurt

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

sandeep umesh via RT | 3 Aug 14:03 2015
Picon

[openssl.org #3977] bug report : Ubutu 12.0.4 : Openssl 1.0.1p : allowing connections with EXP cipher

Hi,

I updated openssl version to 1.0.1p (to address logjam) and configured
sendmail.

To verify the logjam fix, I used openssl s_client and connected to the smtp
server.
---------------
Default log:
----------------
$ openssl s_client -starttls smtp -crlf -connect 127.0.0.1:25 -cipher EXP
CONNECTED(00000003)
140482363598496:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:757:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 443 bytes and written 108 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

$ openssl s_client -starttls smtp -crlf -connect 127.0.0.1:25 -cipher
EXP-EDH-RSA-DES-CBC-SHA
CONNECTED(00000003)
(Continue reading)

Matt Caswell via RT | 3 Aug 09:39 2015
Picon

[openssl.org #3967] Assert hit in the latest 1.0.2d code

On Mon Aug 03 01:55:07 2015, praveen <at> viptela.com wrote:
> Yes that worked. The previous version we were using 1.0.1m.

Commit has been applied to git here:
https://github.com/openssl/openssl/commit/9e43fe9a2bd38f06385b5b721f7c4b3ff0e4163f

Closing ticket.

Matt

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

The Doctor | 1 Aug 17:02 2015
Picon

NEed help

I am trying to compile openssl 1.0.2 SNAP 20150801 

and now I get

if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then  (cd ..; make libcrypto.so.1.0.0);  fi
[ -z "" ] || gcc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2
-march=pentium3 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND
-DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
-DGHASH_ASM -Iinclude  -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso   fips_premain.c
fipscanister.o  libcrypto.a -ldl -lm -lc
/usr/lib/libc.a(sha.o): In function `SHA':
sha.o(.text+0x0): multiple definition of
`SHA'
libcrypto.a(sha_one.o):/usr/source/openssl-1.0.2-stable-SNAP-20150801/crypto/sha/sha_one.c:66:
first defined here
ld: Warning: size of symbol `SHA' changed from 142 to 92 in /usr/lib/libc.a(sha.o)
/usr/lib/libc.a(malloc.o)(.text+0x16): undefined reference to `__progname'
/usr/lib/libc.a(malloc.o)(.text+0xe0): undefined reference to `__progname'
/usr/lib/libc.a(syslog.o): In function `vsyslog':
syslog.o(.text+0x3a5): undefined reference to `__progname'
/usr/lib/libc.a(getenv.o): In function `__findenv':
getenv.o(.text+0x65): undefined reference to `environ'
getenv.o(.text+0x72): undefined reference to `environ'
/usr/lib/libc.a(exec.o): In function `execl':
exec.o(.text+0x103): undefined reference to `environ'
/usr/lib/libc.a(exec.o): In function `execv':
exec.o(.text+0x26b): undefined reference to `environ'
/usr/lib/libc.a(exec.o): In function `execvp':
(Continue reading)

Salz, Rich via RT | 1 Aug 04:14 2015
Picon

Re: [openssl.org #3976] Bug report

My feeling is that you should not be copying an EVP if data is NULL and that the earlier null checks are
erroneous.  But I could be wrong.

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

Stuart, Harold via RT | 1 Aug 04:07 2015
Picon

[openssl.org #3976] Bug report

The cryptographic engineering team at Blue Coat systems is conducting a review of OpenSSL and have found
the following minor bug. We would appreciate your consideration.

Observe the following lines in evp_enc.c:

    if (in->cipher_data && in->cipher->ctx_size) {
        out->cipher_data = OPENSSL_malloc(in->cipher->ctx_size);
        if (!out->cipher_data) {
            EVPerr(EVP_F_EVP_CIPHER_CTX_COPY, ERR_R_MALLOC_FAILURE);
            return 0;
        }
        memcpy(out->cipher_data, in->cipher_data, in->cipher->ctx_size);
    }

    if (in->cipher->flags & EVP_CIPH_CUSTOM_COPY)
        return in->cipher->ctrl((EVP_CIPHER_CTX *)in, EVP_CTRL_COPY, 0, out);

Note that in->cipher data is checked for NULL, which implies that in->cipher_data can be NULL. Now, take a
look at function ads_ccm_ctrl, which is what in->cipher_ctrl points to:

static int aes_ccm_ctrl(EVP_CIPHER_CTX *c, int type, int arg, void *ptr)
{
    EVP_AES_CCM_CTX *cctx = c->cipher_data;
    switch (type) {
    case EVP_CTRL_INIT:
        cctx->key_set = 0;
        cctx->iv_set = 0;
        cctx->L = 8;
        cctx->M = 12;
        cctx->tag_set = 0;
(Continue reading)

Laetitia Baudoin via RT | 31 Jul 19:44 2015
Picon

[openssl.org #3975] The CMS encrypt command uses the wrong ASN.1 encoding for the AES-GCM algorithm parameter.

When using 'openssl cms -encrypt -aes-256-gcm' the algorithm generated is
encoded as:

SEQUENCE(2 elem)
  OBJECT IDENTIFIER2.16.840.1.101.3.4.1.46
  OCTET STRING(12 byte) 000000000000000000000000

But RFC 5084 (Using AES-CCM and AES-GCM Authenticated Encryption in the
Cryptographic Message Syntax (CMS)) specifies the algorithm parameters as:

GCMParameters ::= SEQUENCE {
   aes-nonce        OCTET STRING, -- recommended size is 12 octets
   aes-ICVlen       AES-GCM-ICVlen DEFAULT 12 }

   AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16)

So the openssl version is missing the SEQUENCE tag.

Version tested: openssl 1.0.2d on linux x86_64
Example:
openssl cms -encrypt -in message.txt -out encrypted-openssl-aes-256-gcm.msg
-recip user1_no_cn.pem -aes-256-gcm

Attachment (encrypted-openssl-aes-256-gcm.msg): application/octet-stream, 1229 bytes
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod <at> openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
(Continue reading)

Laetitia Baudoin via RT | 31 Jul 19:35 2015
Picon

[openssl.org #3974] The IV used by the 'openssl cms -encrypt -aes-256-gcm' command is not random (all zeroes).

When encrypting using the 'openssl cms -encrypt -aes-256-gcm' command an
all zero IV is used, this breaks any guarantees provided by the GCM
mode (see NIST Special Publication 800-38D).

Version tested: openssl 1.0.2d on linux x86_64.

Example:
openssl cms -encrypt -in message.txt -out encrypted-openssl-aes-256-gcm.msg
-recip user1_no_cn.pem -aes-256-gcm

When looking at the ASN.1 for the contentEncryptionAlgorithm we get:

SEQUENCE(2 elem)
  OBJECT IDENTIFIER2.16.840.1.101.3.4.1.46
  OCTET STRING(12 byte) 000000000000000000000000  <-- This is the IV

Expectation:
 - If AES-GCM is not supported by the 'openssl cms' command (there is no
clear RFC for it when generating enveloped data, RFC 5084 is for
authenticated enveloped data) the command should show an error.
 -  If AES-GCM is supported it should generate a random IV

Attachment (encrypted-openssl-aes-256-gcm.msg): application/octet-stream, 1229 bytes
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod <at> openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
(Continue reading)

Hubert Kario via RT | 31 Jul 19:07 2015
Picon

[openssl.org #3973] few options in s_client and s_server are missing descriptions

-curves, -sigalgs, -client_sigalgs are not documented in s_client and s_server 
-help messages

fixes:
https://github.com/openssl/openssl/pull/351 (1.0.2)
https://github.com/openssl/openssl/pull/350 (master)
--

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod <at> openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Picon

Re: [openssl.org #3967] Assert hit in the latest 1.0.2d code

Yes that worked. The previous version we were using 1.0.1m.

Thanks for the quick turn around
-Praveen

On Wed, Jul 29, 2015 at 3:35 PM, Matt Caswell via RT <rt <at> openssl.org> wrote:

> On Wed Jul 29 20:30:22 2015, praveen <at> viptela.com wrote:
> > We seem to hit this assert with the latest code. Our sockets are all in
> > non-blocking fashion. I dont see this assert in the previous releases.
>
> What was the last release you tried where this worked? Was this previously
> working on a 1.0.2 release?
>
> >
> > Can somebody throw more light on to this ? It is urgent. As we are not
> able
> > to migrate to this version because of this regression.
>
> Please can you try the attached patch and let me know if that makes any
> difference. There seems to be an issue with DTLS1.2. If the underlying BIO
> write buffers are full DTLS is supposed to drop the packet and clear out
> the
> internal OpenSSL buffer. This code was only testing for DTLS1 not DTLS1 and
> DTLS1.2. If you are using DTLS1.2 then the internal buffer does not get
> cleared
> out, and the next time you try to write some data it falls over because the
> buffer should be empty but it isn't.
>
> Matt
(Continue reading)

Rich Salz via RT | 31 Jul 18:40 2015
Picon

[openssl.org #3972] EVP documentation implicitly recommends the use of single-DES

fixed in master and 1.0.2, thanks.
--
Rich Salz, OpenSSL dev team; rsalz <at> openssl.org

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


Gmane