From rt at openssl.org Sat Oct 1 00:39:26 2016 From: rt at openssl.org (nwarner via RT) Date: Sat, 01 Oct 2016 00:39:26 +0000 Subject: [openssl-dev] [openssl.org #4691] Not sure where to report this... In-Reply-To: <57EEDA65.2856@datastar.com> References: <57EEDA65.2856@datastar.com> Message-ID: Trying to upgrade to 1.1.0b (from 1.0.2h) OS:FreeBSD 8.4 p4 Is this a show-stopper? [by the way, let me know if there's a better venue for report install issues] Test Summary Report ------------------- ../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=86, Tests=463, 173 wallclock secs ( 2.88 usr 0.66 sys + 154.93 cusr 20.34 csys = 178.80 CPU) Result: FAIL Failed 1/86 test programs. 1/463 subtests failed. *** Error code 255 Stop in /usr/src/openssl-1.1.0b. *** Error code 1 Stop in /usr/src/openssl-1.1.0b. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4691 Please log in as guest with password guest if prompted From rt at openssl.org Sat Oct 1 11:02:54 2016 From: rt at openssl.org (Kent Peacock via RT) Date: Sat, 01 Oct 2016 11:02:54 +0000 Subject: [openssl-dev] [openssl.org #4693] Change EVP_aes_xxx_wrap to use FIPS crypto module in FIPS mode In-Reply-To: <57EF15F4.3010508@nimblestorage.com> References: <57EF15F4.3010508@nimblestorage.com> Message-ID: The FIPS certified 2.0.x crypto module does not incorporate the key wrap modes within the module boundary, and calls the local AES_{encrypt,decrypt} functions (which is, strictly speaking, a no-no). So, it's not using FIPS validated crypto. This patch provides a modification to use the appropriate underlying FIPS EVP_aes_..._ecb APIs which FIPS module to do the actual block-at-a-time encryption/decryption. Kent -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4693 Please log in as guest with password guest if prompted -------------- next part -------------- --- crypto/evp/e_aes.c.orig 2016-09-30 16:35:00.973857408 -0700 +++ crypto/evp/e_aes.c 2016-09-30 16:34:20.579119933 -0700 @@ -1920,10 +1920,7 @@ EVP_CIPH_FLAG_FIPS | CUSTOM_FLAGS) #endif typedef struct { - union { - double align; - AES_KEY ks; - } ks; + EVP_CIPHER_CTX aes_ctx; /* Indicates if IV has been set */ unsigned char *iv; } EVP_AES_WRAP_CTX; @@ -1935,10 +1932,22 @@ if (!iv && !key) return 1; if (key) { - if (ctx->encrypt) - AES_set_encrypt_key(key, ctx->key_len * 8, &wctx->ks.ks); - else - AES_set_decrypt_key(key, ctx->key_len * 8, &wctx->ks.ks); + const EVP_CIPHER *cipher; + switch (ctx->key_len * 8) { + case 128: + cipher = EVP_aes_128_ecb(); + break; + case 192: + cipher = EVP_aes_192_ecb(); + break; + case 256: + cipher = EVP_aes_256_ecb(); + break; + default: + return 0; + } + EVP_CipherInit(&wctx->aes_ctx, cipher, key, NULL, ctx->encrypt); + EVP_CIPHER_CTX_set_padding(&wctx->aes_ctx, 0); if (!iv) wctx->iv = NULL; } @@ -1949,6 +1958,20 @@ return 1; } +static block128_f +aes_wrap_encrypt(const unsigned char *in, unsigned char *out, const void *key) +{ + int outlen; + return EVP_EncryptUpdate(key, out, &outlen, in, 16); +} + +static block128_f +aes_wrap_decrypt(const unsigned char *in, unsigned char *out, const void *key) +{ + int outlen; + return EVP_DecryptUpdate(key, out, &outlen, in, 16); +} + static int aes_wrap_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out, const unsigned char *in, size_t inlen) { @@ -1969,14 +1992,27 @@ return inlen - 8; } if (ctx->encrypt) - rv = CRYPTO_128_wrap(&wctx->ks.ks, wctx->iv, out, in, inlen, - (block128_f) AES_encrypt); + rv = CRYPTO_128_wrap(&wctx->aes_ctx, wctx->iv, out, in, inlen, + (block128_f) aes_wrap_encrypt); else - rv = CRYPTO_128_unwrap(&wctx->ks.ks, wctx->iv, out, in, inlen, - (block128_f) AES_decrypt); + rv = CRYPTO_128_unwrap(&wctx->aes_ctx, wctx->iv, out, in, inlen, + (block128_f) aes_wrap_decrypt); return rv ? (int)rv : -1; } +static int aes_wrap_cleanup(EVP_CIPHER_CTX *c) +{ + EVP_AES_WRAP_CTX *wctx = c->cipher_data; + + if (wctx) { + EVP_CIPHER_CTX_cleanup(&wctx->aes_ctx); + OPENSSL_cleanse(c->cipher_data, c->cipher->ctx_size); + OPENSSL_free(c->cipher_data); + } + memset(c, 0, sizeof(EVP_CIPHER_CTX)); + return 1; +} + #define WRAP_FLAGS (EVP_CIPH_WRAP_MODE \ | EVP_CIPH_CUSTOM_IV | EVP_CIPH_FLAG_CUSTOM_CIPHER \ | EVP_CIPH_ALWAYS_CALL_INIT | EVP_CIPH_FLAG_DEFAULT_ASN1) @@ -1985,7 +2021,7 @@ NID_id_aes128_wrap, 8, 16, 8, WRAP_FLAGS, aes_wrap_init_key, aes_wrap_cipher, - NULL, + aes_wrap_cleanup, sizeof(EVP_AES_WRAP_CTX), NULL, NULL, NULL, NULL }; @@ -1999,7 +2035,7 @@ NID_id_aes192_wrap, 8, 24, 8, WRAP_FLAGS, aes_wrap_init_key, aes_wrap_cipher, - NULL, + aes_wrap_cleanup, sizeof(EVP_AES_WRAP_CTX), NULL, NULL, NULL, NULL }; @@ -2013,7 +2049,7 @@ NID_id_aes256_wrap, 8, 32, 8, WRAP_FLAGS, aes_wrap_init_key, aes_wrap_cipher, - NULL, + aes_wrap_cleanup, sizeof(EVP_AES_WRAP_CTX), NULL, NULL, NULL, NULL }; From rt at openssl.org Sat Oct 1 11:02:54 2016 From: rt at openssl.org (Kent Peacock via RT) Date: Sat, 01 Oct 2016 11:02:54 +0000 Subject: [openssl-dev] [openssl.org #4692] Change EVP_aes_xxx_wrap to use FIPS crypto module in FIPS mode In-Reply-To: <57EF1632.7000705@nimblestorage.com> References: <57EF1632.7000705@nimblestorage.com> Message-ID: The FIPS certified 2.0.x crypto module does not incorporate the key wrap modes within the module boundary, and calls the local AES_{encrypt,decrypt} functions (which is, strictly speaking, a no-no). So, it's not using FIPS validated crypto. This patch provides a modification to use the appropriate underlying FIPS EVP_aes_..._ecb APIs which use the FIPS module to do the actual block-at-a-time encryption/decryption. Kent -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4692 Please log in as guest with password guest if prompted -------------- next part -------------- --- crypto/evp/e_aes.c.orig 2016-09-30 16:35:00.973857408 -0700 +++ crypto/evp/e_aes.c 2016-09-30 16:34:20.579119933 -0700 @@ -1920,10 +1920,7 @@ EVP_CIPH_FLAG_FIPS | CUSTOM_FLAGS) #endif typedef struct { - union { - double align; - AES_KEY ks; - } ks; + EVP_CIPHER_CTX aes_ctx; /* Indicates if IV has been set */ unsigned char *iv; } EVP_AES_WRAP_CTX; @@ -1935,10 +1932,22 @@ if (!iv && !key) return 1; if (key) { - if (ctx->encrypt) - AES_set_encrypt_key(key, ctx->key_len * 8, &wctx->ks.ks); - else - AES_set_decrypt_key(key, ctx->key_len * 8, &wctx->ks.ks); + const EVP_CIPHER *cipher; + switch (ctx->key_len * 8) { + case 128: + cipher = EVP_aes_128_ecb(); + break; + case 192: + cipher = EVP_aes_192_ecb(); + break; + case 256: + cipher = EVP_aes_256_ecb(); + break; + default: + return 0; + } + EVP_CipherInit(&wctx->aes_ctx, cipher, key, NULL, ctx->encrypt); + EVP_CIPHER_CTX_set_padding(&wctx->aes_ctx, 0); if (!iv) wctx->iv = NULL; } @@ -1949,6 +1958,20 @@ return 1; } +static block128_f +aes_wrap_encrypt(const unsigned char *in, unsigned char *out, const void *key) +{ + int outlen; + return EVP_EncryptUpdate(key, out, &outlen, in, 16); +} + +static block128_f +aes_wrap_decrypt(const unsigned char *in, unsigned char *out, const void *key) +{ + int outlen; + return EVP_DecryptUpdate(key, out, &outlen, in, 16); +} + static int aes_wrap_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out, const unsigned char *in, size_t inlen) { @@ -1969,14 +1992,27 @@ return inlen - 8; } if (ctx->encrypt) - rv = CRYPTO_128_wrap(&wctx->ks.ks, wctx->iv, out, in, inlen, - (block128_f) AES_encrypt); + rv = CRYPTO_128_wrap(&wctx->aes_ctx, wctx->iv, out, in, inlen, + (block128_f) aes_wrap_encrypt); else - rv = CRYPTO_128_unwrap(&wctx->ks.ks, wctx->iv, out, in, inlen, - (block128_f) AES_decrypt); + rv = CRYPTO_128_unwrap(&wctx->aes_ctx, wctx->iv, out, in, inlen, + (block128_f) aes_wrap_decrypt); return rv ? (int)rv : -1; } +static int aes_wrap_cleanup(EVP_CIPHER_CTX *c) +{ + EVP_AES_WRAP_CTX *wctx = c->cipher_data; + + if (wctx) { + EVP_CIPHER_CTX_cleanup(&wctx->aes_ctx); + OPENSSL_cleanse(c->cipher_data, c->cipher->ctx_size); + OPENSSL_free(c->cipher_data); + } + memset(c, 0, sizeof(EVP_CIPHER_CTX)); + return 1; +} + #define WRAP_FLAGS (EVP_CIPH_WRAP_MODE \ | EVP_CIPH_CUSTOM_IV | EVP_CIPH_FLAG_CUSTOM_CIPHER \ | EVP_CIPH_ALWAYS_CALL_INIT | EVP_CIPH_FLAG_DEFAULT_ASN1) @@ -1985,7 +2021,7 @@ NID_id_aes128_wrap, 8, 16, 8, WRAP_FLAGS, aes_wrap_init_key, aes_wrap_cipher, - NULL, + aes_wrap_cleanup, sizeof(EVP_AES_WRAP_CTX), NULL, NULL, NULL, NULL }; @@ -1999,7 +2035,7 @@ NID_id_aes192_wrap, 8, 24, 8, WRAP_FLAGS, aes_wrap_init_key, aes_wrap_cipher, - NULL, + aes_wrap_cleanup, sizeof(EVP_AES_WRAP_CTX), NULL, NULL, NULL, NULL }; @@ -2013,7 +2049,7 @@ NID_id_aes256_wrap, 8, 32, 8, WRAP_FLAGS, aes_wrap_init_key, aes_wrap_cipher, - NULL, + aes_wrap_cleanup, sizeof(EVP_AES_WRAP_CTX), NULL, NULL, NULL, NULL }; From rt at openssl.org Sun Oct 2 10:13:39 2016 From: rt at openssl.org (ldcsaa@163.com via RT) Date: Sun, 02 Oct 2016 10:13:39 +0000 Subject: [openssl-dev] [openssl.org #4694] bug report openssl-1.1.0b (ssl_rsa.c) In-Reply-To: <201610021134066170587@163.com> References: <201610021134066170587@163.com> Message-ID: hello, should the following problem were BUGS ? SSL_use_PrivateKey_file SSL_use_certificate_file SSL_use_RSAPrivateKey_file for example: SSL_use_PrivateKey_file ----------------------------------------------------------------------------- int SSL_use_PrivateKey_file(SSL *ssl, const char *file, int type) { int j, ret = 0; BIO *in; EVP_PKEY *pkey = NULL; in = BIO_new(BIO_s_file()); if (in == NULL) { SSLerr(SSL_F_SSL_USE_PRIVATEKEY_FILE, ERR_R_BUF_LIB); goto end; } if (BIO_read_filename(in, file) <= 0) { SSLerr(SSL_F_SSL_USE_PRIVATEKEY_FILE, ERR_R_SYS_LIB); goto end; } if (type == SSL_FILETYPE_PEM) { j = ERR_R_PEM_LIB; pkey = PEM_read_bio_PrivateKey(in, NULL, ssl->ctx->default_passwd_callback, ssl-> ctx->default_passwd_callback_userdata); } else if (type == SSL_FILETYPE_ASN1) { j = ERR_R_ASN1_LIB; pkey = d2i_PrivateKey_bio(in, NULL); } else { SSLerr(SSL_F_SSL_USE_PRIVATEKEY_FILE, SSL_R_BAD_SSL_FILETYPE); goto end; } if (pkey == NULL) { SSLerr(SSL_F_SSL_USE_PRIVATEKEY_FILE, j); goto end; } ret = SSL_use_PrivateKey(ssl, pkey); EVP_PKEY_free(pkey); end: BIO_free(in); return (ret); } ----------------------------------------------------------------------------- were the red lines wrong? perhaps use this : pkey = PEM_read_bio_PrivateKey(in, NULL, ssl->default_passwd_callback, ssl->default_passwd_callback_userdata); ldcsaa at 163.com -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4694 Please log in as guest with password guest if prompted From jakub.openssl at gmail.com Sun Oct 2 18:18:19 2016 From: jakub.openssl at gmail.com (Jakub Zelenka) Date: Sun, 2 Oct 2016 19:18:19 +0100 Subject: [openssl-dev] X509_PUBKEY_set pkey breaking changes in 1.1 Message-ID: Hi, I've ported PHP to work with OpenSSL 1.1 which is part of upcoming 7.1 release. Everything seems to work fine, we have got just last 2 failing tests in openssl extension. One of them is caused changes in X509_PUBKEY_set. We have got a function to create a cert request (X509_REQ) called openssl_csr_new which except other things set a supplied private key using X509_REQ_set_pubkey which basically just passes it to X509_PUBKEY_set. The break for us then happen when a user calls openssl_csr_get_public_key which calls X509_REQ_get_pubkey . The reason for that is that OpenSSL 1.1 stores a supplied pkey instead of just decoding it to pubkey which was done previously. The change is in this commit: https://goo.gl/FvOnjn The question that I have is if this change has been done on purpose and from version 1.1, we must pass just the pub key (basically extract it from private key) if we don't want to show private key later? The reason why I'm asking is that the only note about that in CHANGES is from 0.9.5 when it was introduced: *) Modernise PKCS12_parse() so it uses STACK_OF(X509) for its ca argument fix a leak when the ca argument was passed as NULL. Stop X509_PUBKEY_set() using the passed key: if the passed key was a private key the result of X509_print(), for example, would be to print out all the private key components. [Steve Henson] Thanks Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at multitalents.net Mon Oct 3 02:02:58 2016 From: tim at multitalents.net (Tim Rice) Date: Sun, 2 Oct 2016 19:02:58 -0700 (PDT) Subject: [openssl-dev] 1.0.2j on solaris 10 sparc Message-ID: I did a 64 bit build of 1.0.2j on my solaris 10 box and to my suprise the tests failed. Looks like an issue with bad_dtls_test.c ......... $ dbx ./bad_dtls_test For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading bad_dtls_test Reading ld.so.1 Reading libssl.so.1.0 Reading libcrypto.so.1.0 Reading libsocket.so.1 Reading libnsl.so.1 Reading libdl.so.1 Reading libz.so.1 Reading libc.so.1 (dbx) run Running: bad_dtls_test (process id 17346) Reading libc_psr.so.1 signal BUS (invalid address alignment) in _time at 0xffffffff7e5c1944 0xffffffff7e5c1944: _time+0x0014: stx %o0, [%i0] Current function is main (optimized) 776 time((void *)server_random); (dbx) ......... Except for that, the tests are fine. -- Tim Rice Multitalents tim at multitalents.net From rt at openssl.org Mon Oct 3 02:25:38 2016 From: rt at openssl.org (Kent Peacock via RT) Date: Mon, 03 Oct 2016 02:25:38 +0000 Subject: [openssl-dev] [openssl.org #4693] Re: [openssl.org #4692] AutoReply: Change EVP_aes_xxx_wrap to use FIPS crypto module in FIPS mode In-Reply-To: <47f6c8d8-e3ee-ac88-72f1-28104a71bd9f@nimblestorage.com> References: <57EF1632.7000705@nimblestorage.com> <47f6c8d8-e3ee-ac88-72f1-28104a71bd9f@nimblestorage.com> Message-ID: Recommemded change to the previous diff in aes_wrap_cleanup, since cipher data and the context are cleaned up by the caller (avoids a double free): if (wctx) { EVP_CIPHER_CTX_cleanup(&wctx->aes_ctx); - OPENSSL_cleanse(c->cipher_data, c->cipher->ctx_size); - OPENSSL_free(c->cipher_data); } - memset(c, 0, sizeof(EVP_CIPHER_CTX)); On 10/01/2016 04:02 AM, The default queue via RT wrote: > > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "Change EVP_aes_xxx_wrap to use FIPS crypto module in FIPS mode", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [openssl.org #4692]. > > Please include the string: > > [openssl.org #4692] > > in the subject line of all future correspondence about this issue. To do so, > you may reply to this message. > > Thank you, > rt at openssl.org > > ------------------------------------------------------------------------- > The FIPS certified 2.0.x crypto module does not incorporate the key wrap > modes within the module boundary, and calls the local > AES_{encrypt,decrypt} functions (which is, strictly speaking, a no-no). > So, it's not using FIPS validated crypto. This patch provides a > modification to use the appropriate underlying FIPS EVP_aes_..._ecb APIs > which use the FIPS module to do the actual block-at-a-time > encryption/decryption. > > Kent > > > ------------------------------------------------------------------------- > http://rt.openssl.org/Ticket/Display.html?id=4692&user=guest&pass=guest > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4693 Please log in as guest with password guest if prompted From rsalz at akamai.com Mon Oct 3 06:00:42 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 3 Oct 2016 06:00:42 +0000 Subject: [openssl-dev] 1.0.2j on solaris 10 sparc In-Reply-To: References: Message-ID: > signal BUS (invalid address alignment) in _time at 0xffffffff7e5c1944 > 0xffffffff7e5c1944: _time+0x0014: stx %o0, [%i0] > Current function is main (optimized) > 776 time((void *)server_random); We have a fix that will go in shortly. From rt at openssl.org Mon Oct 3 07:00:27 2016 From: rt at openssl.org (Geoffrey Coram via RT) Date: Mon, 03 Oct 2016 07:00:27 +0000 Subject: [openssl-dev] [openssl.org #4695] calloc issue in crypto\LPdir_win.c In-Reply-To: <20161003011359.A4AC0D50.gjcoram@gmail.com> References: <20161003011359.A4AC0D50.gjcoram@gmail.com> Message-ID: Hi - I had a link failure due to an unresolved external "calloc" when trying to build a WindowsCE application using OpenSSL 1.0.2j. calloc appears in crypto\LPdir_win.c on line 98. I think one is supposed to use LocalAlloc for WindowsCE instead of malloc or calloc. I didn't get a link error for malloc that appears on line 72 of that file (on line 77, that memory is zeroed out), so it seems like a fix for me would be to use a malloc and memset instead of calloc. calloc also appears in ssl\kssl.c, though my application does not use functions from that file. I was puzzled to see calls to "calloc" and also "kssl_calloc" -Geoffrey -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4695 Please log in as guest with password guest if prompted From stevenx.linsell at intel.com Mon Oct 3 11:41:36 2016 From: stevenx.linsell at intel.com (Linsell, StevenX) Date: Mon, 3 Oct 2016 11:41:36 +0000 Subject: [openssl-dev] [openssl.org #4683] [BUG] Failure running openssl speed ecdh in master branch Message-ID: > Date: Thu, 22 Sep 2016 15:39:13 +0000 > From: "Linsell, StevenX via RT" > Running against master branch (commit > 39c136cc53d7b6fafdd1a0b52c035fd24358e01c - Updates CHANGES and NEWS > for new release) we see a failure when running openssl speed with the ecdh > parameter: > > ./openssl speed ecdh [SNIP] > ECDH failure. > 140194445354752:error:100AE081:elliptic curve > routines:EC_GROUP_new_by_curve_name:unknown > group:crypto/ec/ec_curve.c:3100: > 140194445354752:error:100AE081:elliptic curve > routines:EC_GROUP_new_by_curve_name:unknown > group:crypto/ec/ec_curve.c:3100: > OpenSSL 1.1.1-dev xx XXX xxxx I've had a bit more time to investigate this bug. The issue was introduced by commit: bc7bfb83b7189c052bf2898bd6b82f8e4b4fd3f6 Remove old EC based X25519 code. Committed on August 11th And is present in both OpenSSL_1_1_0-stable and master branch. OpenSSL speed uses the EC methods to measure ECDH_compute_key operations including support for the X25519 curve. Since the commit above the EC_KEY_new_by_curve_name call fails as X25519 is no longer supported. I would like to work on a fix for this but I would like some feedback on the direction to take. There are several options which have varying impacts on what speed would actually be measuring, I'll outline them below: 1) I just remove X25519 support from OpenSSL speed. This is the easiest fix but means nobody can use speed to measure performance with the X25519 curve anymore. This would be undesirable as the curve is becoming increasingly popular and well supported as an alternative to NIST curves. 2) I add a special case to the ECDH measurement function that uses the EVP_PKEY_* interfaces just for the X25519 curve. This adds complexity to speed and means X25519 is technically not really comparable with the other curves due to a different API entry point at a higher level. 3) I move all the ECDH curves in speed over to use the EVP_PKEY_* interfaces. This will make the curve measurement comparable but not with historical data from earlier openssl versions (this may not be important anyway). 4) I go the whole hog and move all the pkey operations that I can in speed over to use the EVP_PKEY_* interfaces. Again this would break historical comparisons. Personally I would favour option 3 or possibly 4 depending on time constraints but I don't know if there is a historical reason why speed uses the low level API's? Is it so the speed measurements are focused tightly on the algorithm they are measuring or is it just they were written that way and nobody has had the need to change them? Any comments would be appreciated before I spend time on this. Kind Regards, Steve Linsell Intel Shannon DCG/CID Software Development Team Stevenx.Linsell at intel.com -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From rsalz at akamai.com Mon Oct 3 14:52:57 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 3 Oct 2016 14:52:57 +0000 Subject: [openssl-dev] OpenSSL F2F Message-ID: Sorry, we didn't think to put this out earlier... The OpenSSL dev team is having a face-to-face meeting this week in Berlin, co-located with LinuxCon. If you're in the area, feel free to stop by. In particular, on Tuesday from 16:50-17:40 - "Members of the openssl development team will be available to help with porting applications to 1.1.0, help guide how people can contribute to the project, and be available to discuss other technical issues. Downstream distributions and embedded applications developers should also stop by to introduce themselves" If you're not available during that time, but want to chat, please let us know. /r$ -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Oct 3 18:03:11 2016 From: rt at openssl.org (Nicola Tuveri via RT) Date: Mon, 03 Oct 2016 18:03:11 +0000 Subject: [openssl-dev] [openssl.org #4683] [BUG] Failure running openssl speed ecdh in master branch In-Reply-To: References: Message-ID: > > There are several options which have varying impacts on what speed would > actually be measuring, I'll outline them below: > 1) I just remove X25519 support from OpenSSL speed. This is the easiest > fix but means nobody can use speed to measure performance with the X25519 > curve anymore. This would be undesirable as the curve is becoming > increasingly popular and well supported as an alternative to NIST curves. > 2) I add a special case to the ECDH measurement function that uses the > EVP_PKEY_* interfaces just for the X25519 curve. This adds complexity to > speed and means X25519 is technically not really comparable with the other > curves due to a different API entry point at a higher level. > 3) I move all the ECDH curves in speed over to use the EVP_PKEY_* > interfaces. This will make the curve measurement comparable but not with > historical data from earlier openssl versions (this may not be important > anyway). > 4) I go the whole hog and move all the pkey operations that I can in speed > over to use the EVP_PKEY_* interfaces. Again this would break historical > comparisons. I just noticed this thread: I was already working on option number 3 for a side project where I had the need to compare benchmarks of ECDH with different curves, including X25519, so [here is a pull request][0] to start from if we want to revise which interface to use to access EC crypto in apps/speed. Hope this might save some time! Kind regards, Nicola Tuveri [0] https://github.com/openssl/openssl/pull/1658 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4683 Please log in as guest with password guest if prompted From dwmw2 at infradead.org Tue Oct 4 12:14:36 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 04 Oct 2016 13:14:36 +0100 Subject: [openssl-dev] OpenSSL F2F In-Reply-To: References: Message-ID: <1475583276.45169.863.camel@infradead.org> On Mon, 2016-10-03 at 14:52 +0000, Salz, Rich wrote: > Sorry, we didn?t think to put this out earlier? > ? > The OpenSSL dev team is having a face-to-face meeting this week in > Berlin, co-located with LinuxCon.? If you?re in the area, feel free > to stop by. In particular, on Tuesday from 16:50-17:40 ? ?Members of > the openssl development team will be available to help with porting > applications to 1.1.0, help guide how people can contribute to the > project, and be available to discuss other technical issues. > Downstream distributions and embedded applications developers should > also stop by to introduce themselves? > ? > If you?re not available during that time, but want to chat, please > let us know. Hm, not *quite* enough time for me to get a flight to Berlin today... and I'd have a three-year-old in tow. I would dearly have loved to make it, because I'd like to get some more detailed consensus on adding PKCS#11 support. In the past we've provisionally agreed on "let's do it after 1.1"... so now we should be looking at a slightly more detailed plan. I *can* just start throwing patches over the wall, but a high-level consensus on the architecture might have been useful. And we're all busy enough that it just seems easier to do it face-to-face while we're in the same time zone. I would also love to get feedback on, and do some?proselytism for, http://david.woodhou.se/draft-woodhouse-cert-best-practice.html ? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From tmraz at redhat.com Tue Oct 4 12:31:12 2016 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 04 Oct 2016 14:31:12 +0200 Subject: [openssl-dev] OpenSSL F2F In-Reply-To: <1475583276.45169.863.camel@infradead.org> References: <1475583276.45169.863.camel@infradead.org> Message-ID: <1475584272.24139.19.camel@redhat.com> On ?t, 2016-10-04 at 13:14 +0100, David Woodhouse wrote: > On Mon, 2016-10-03 at 14:52 +0000, Salz, Rich wrote: > > > > Sorry, we didn?t think to put this out earlier? > > ? > > The OpenSSL dev team is having a face-to-face meeting this week in > > Berlin, co-located with LinuxCon.? If you?re in the area, feel free > > to stop by. In particular, on Tuesday from 16:50-17:40 ? ?Members > > of > > the openssl development team will be available to help with porting > > applications to 1.1.0, help guide how people can contribute to the > > project, and be available to discuss other technical issues. > > Downstream distributions and embedded applications developers > > should > > also stop by to introduce themselves? > > ? > > If you?re not available during that time, but want to chat, please > > let us know. > Hm, not *quite* enough time for me to get a flight to Berlin today... > and I'd have a three-year-old in tow. I have a similar problem although I could reach Berlin by train which is a little bit easier and cheaper. I would be very happy to meet with OpenSSL developers in person. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) From kurt at roeckx.be Tue Oct 4 20:29:32 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 4 Oct 2016 22:29:32 +0200 Subject: [openssl-dev] OpenSSL F2F In-Reply-To: <1475583276.45169.863.camel@infradead.org> References: <1475583276.45169.863.camel@infradead.org> Message-ID: <20161004202931.mkqofxwytbe3ktyj@roeckx.be> On Tue, Oct 04, 2016 at 01:14:36PM +0100, David Woodhouse wrote: > > I would dearly have loved to make it, because I'd like to get some more > detailed consensus on adding PKCS#11 support. > > In the past we've provisionally agreed on "let's do it after 1.1"... so > now we should be looking at a slightly more detailed plan. I *can* just > start throwing patches over the wall, but a high-level consensus on the > architecture might have been useful. And we're all busy enough that it > just seems easier to do it face-to-face while we're in the same time > zone. That is at least already on the agenda we have. But it's a very long agenda, not sure if we're going to have time to go over everything. So there are clearly people interested in doing it, and we might talk about a plan. Kurt From dwmw2 at infradead.org Tue Oct 4 23:39:51 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Oct 2016 00:39:51 +0100 Subject: [openssl-dev] Calculating DTLS payload MTU Message-ID: <1475624391.45169.890.camel@infradead.org> I have the link MTU (typically 1500 bytes), and a DTLS session is established. I call DTLS_set_link_mtu() to set the link MTU. I need to know the DTLS data MTU ? the maximum payload size, which depends on the cipher in use. For example for AES-128-GCM-SHA256 we'd start with 1500 and subtract: ?- 20 bytes for a Legacy IP header. ?- 8 bytes for UDP header. ?- 13 bytes for DTLS header ?- 16 bytes for the hash ?- 8 bytes for nonce ... and be left with 1435 bytes. In GnuTLS this is fairly trivial; I call gnutls_dtls_set_mtu() followed by gnutls_dtls_get_data_mtu(). How do I do it in OpenSSL? Do I need to build a big table of the overhead of all ciphers and calculate it for myself? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rt at openssl.org Wed Oct 5 04:54:07 2016 From: rt at openssl.org (Llewelyn Thomas via RT) Date: Wed, 05 Oct 2016 04:54:07 +0000 Subject: [openssl-dev] [openssl.org #4696] BUG: openssl1.0.2j Solaris-Sparc : ../util/shlib_wrap.sh ./bad_dtls_test - core dump In-Reply-To: References: Message-ID: $ uname -a SunOS orl-rpd-sunbld1 5.10 Generic_141444-09 sun4v sparc SUNW,SPARC-Enterprise-T5120 $ echo $PATH /opt/sunstudio12.1/bin:/usr/ccs/bin:/usr/bin:/usr/openwin/bin test_bad_dtls ../util/shlib_wrap.sh ./bad_dtls_test *** Signal 10 - core dumped make: Fatal error: Command failed for target `test_bad_dtls' Current working directory /apps/llew/openssl-1.0.2j/test *** Error code 1 The following command caused the error: (cd test && echo "testing..." && \ TOP= && unset TOP ${LIB+LIB} ${LIBS+LIBS} ${INCLUDE+INCLUDE} ${INCLUDES+INCLUDES} ${DIR+DIR} ${DIRS+DIRS} ${SRC+SRC} ${LIBSRC+LIBSRC} ${LIBOBJ+LIBOBJ} ${ALL+ALL} ${EXHEADER+EXHEADER} ${HEADER+HEADER} ${GENERAL+GENERAL} ${CFLAGS+CFLAGS} ${ASFLAGS+ASFLAGS} ${AFLAGS+AFLAGS} ${LDCMD+LDCMD} ${LDFLAGS+LDFLAGS} ${SCRIPTS+SCRIPTS} ${SHAREDCMD+SHAREDCMD} ${SHARE DFLAGS+SHAREDFLAGS} ${SHARED_LIB+SHARED_LIB} ${LIBEXTRAS+LIBEXTRAS} && make -e LC_ALL=C PLATFORM='solaris64-sparcv9-cc' PROCESSOR='' CC ='cc' CFLAG='-KPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -m64 -xO5 -xstrconst -xdepen d -Xa -DB_ENDIAN -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM' AS='cc' ASFLAG='-KPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -m64 -xO5 -xst rconst -xdepend -Xa -DB_ENDIAN -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_A SM -c' AR='ar r' NM='nm' RANLIB='/usr/ccs/bin/ranlib' RC='windres' CROSS_COMPIL E='' PERL='/usr/bin/perl' ENGDIRS='ccgost' SDIRS='objects md4 md5 sha hmac ripemd whrlpool des aes rc2 rc4 idea bf cast ca mellia seed modes bn ec rsa dsa ecdsa dh ecdh dso engine buffer bio stack lhash rand err evp asn1 pem x509 x509v3 conf txt_db pkcs7 pkcs12 comp ocsp ui krb5 cms pqueue ts srp cmac' LIBRPATH='/apps/openssl-1.0.2j-bin/lib' INSTALL_PREFIX='' INSTALLTOP='/apps/o penssl-1.0.2j-bin' OPENSSLDIR='/apps/openssl-1.0.2j-bin/ssl' LIBDIR='lib' MAKEDEPEND='$${TOP}/util/domd $$ {TOP} -MD makedepend' DEPFLAG='-DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_LIB UNBOUND -DOPENSSL_NO_MD2 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_SSL2 - DOPENSSL_NO_STORE -DOPENSSL_NO_UNIT_TEST -DOPENSSL_NO_WEAK_SSL_CIPHERS' MAKEDEPPROG='makedepend' SHARED_LDFLAGS= '-m64 -G -dy -z text' KRB5_INCLUDES='' LIBKRB5='' ZLIB_INCLUDE='-I/apps/zlib-1.2.3-bin//include' LIBZLIB='/apps/zlib-1.2.3-bin //solaris10-sparc64/lib' EXE_EXT='' SHARED_LIBS='libcrypto.so.1.0.0 libssl.so.1.0.0' SHLIB_EXT='.so.1.0.0' SHLIB_TARGET='solaris-share d' PEX_LIBS='' EX_LIBS='-lsocket -lnsl -ldl -L/apps/zlib-1.2.3-bin//solaris10-sparc64/lib -lz' CPUID_OBJ='sparcv9cap.o sparccpuid.o' BN_ASM='bn-sparcv9.o sparcv9-mont.o sparcv9a-mont.o vis3-mont.o sparct4-mont.o sparcv9-gf2m.o' EC_ASM='' DES_ENC='des_enc-sparc.o fcrypt_b .o dest4-sparcv9.o' AES_ENC='aes_core.o aes_cbc.o aes-sparcv9.o aest4-sparcv9.o' CMLL_ENC='camellia.o cmll_misc.o cmll_cbc.o cmllt4- sparcv9.o' BF_ENC='bf_enc.o' CAST_ENC='c_enc.o' RC4_ENC='rc4_enc.o rc4_skey.o' RC5_ENC='rc5_enc.o' SHA1_ASM_OBJ='sha1-sparcv9.o sha256-sparcv9.o sha512-sparcv9.o' MD5_ASM_OBJ='md5-sparcv9.o' RMD160_ASM_OBJ='' WP _ASM_OBJ='wp_block.o' MODES_ASM_OBJ='ghash-sparcv9.o' ENGINES_ASM_OBJ='' PERLASM_SCHEME= 'void' FIPSLIBDIR='' FIPSDIR='/usr/local/ssl/fips-2.0' FIPSCANLIB="${FIPSCANLIB:-}" THIS=${THIS:-tests} MAKEFILE=Makefile MAKEOVERRIDES= TOP=.. TESTS='alltests' OPENSSL_DEBUG_MEMORY=on OPENSSL_CONF=../apps/openssl.cnf tes ts ); make: Fatal error: Command failed for target `tests' $ pstack test/core core 'test/core' of 17356: ./bad_dtls_test ffffffff7e5c1944 time (100104adc, 25400, 1, 0, fffffffffffffc0b, 5) + 14 0000000100002cbc main (0, 0, 0, 18, 0, 100104a8c) + dc 0000000100001c1c _start (0, 0, 0, 0, 0, 0) + 17c Configure command used: $ ./Configure solaris64-sparcv9-cc --prefix=$OPENSSL_HOME threads zlib --with-zlib-lib=$ZLIB_HOME/solaris10-sparc64/lib --with-zlib-include=$ZLIB_HOME/include shared no-mdc2 no-rc5 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4696 Please log in as guest with password guest if prompted From rt at openssl.org Wed Oct 5 07:05:06 2016 From: rt at openssl.org (Sergey G Brazhnikov via RT) Date: Wed, 05 Oct 2016 07:05:06 +0000 Subject: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases) In-Reply-To: References: Message-ID: Hi, guys. Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be decrypted with previous releases and vice versa. Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and 0.9.8(cast5-cfb only) All built without errors, passed all tests. Configuration VC-WIN32, os Windows 8.1 Pro x64, compiler vs2015. Regards, Sergey. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4697 Please log in as guest with password guest if prompted From openssl-users at dukhovni.org Wed Oct 5 07:17:14 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 5 Oct 2016 07:17:14 +0000 Subject: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases) In-Reply-To: References: Message-ID: <20161005071714.GE4670@mournblade.imrryr.org> On Wed, Oct 05, 2016 at 07:05:06AM +0000, Sergey G Brazhnikov via RT wrote: > Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be > decrypted with previous releases and vice versa. > Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and > 0.9.8(cast5-cfb only) > > All built without errors, passed all tests. > Configuration VC-WIN32, os Windows 8.1 Pro x64, compiler vs2015. Especially on Windows systems you have to be mindful of the character-set encoding of the passphrase. Try setting OPENSSL_WIN32_UTF8=1 in your environment and see if that helps. For interoperable password-based encryption the password character-set needs to be standard. -- Viktor. From dwmw2 at infradead.org Wed Oct 5 07:42:01 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Oct 2016 08:42:01 +0100 Subject: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases) In-Reply-To: <20161005071714.GE4670@mournblade.imrryr.org> References: <20161005071714.GE4670@mournblade.imrryr.org> Message-ID: <1475653321.45169.903.camel@infradead.org> On Wed, 2016-10-05 at 07:17 +0000, Viktor Dukhovni wrote: > On Wed, Oct 05, 2016 at 07:05:06AM +0000, Sergey G Brazhnikov via RT wrote: > > > > > Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be > > decrypted with previous releases and vice versa. > > Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and > > 0.9.8(cast5-cfb only) > > > > All built without errors, passed all tests. > > Configuration VC-WIN32, os Windows 8.1 Pro x64, compiler vs2015. > > Especially on Windows systems you have to be mindful of the > character-set encoding of the passphrase. > > Try setting OPENSSL_WIN32_UTF8=1 in your environment and see if > that helps. For interoperable password-based encryption the password > character-set needs to be standard. Wait a minute. Yes, the character-set needs to be standard. It is a bug in OpenSSL that we don't convert from the locale character set *to* something standard, before key derivation. And the *only* justification for the fact that bug continues to exist ? and in fact we introduced a *new* bug in OpenSSL 1.1 instead of fixing it ? is for backward compatibility with older releases. So how can we be so sanguine about the above failure report? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From dwmw2 at infradead.org Wed Oct 5 07:49:08 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Oct 2016 08:49:08 +0100 Subject: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases) In-Reply-To: References: Message-ID: <1475653748.45169.906.camel@infradead.org> On Wed, 2016-10-05 at 07:05 +0000, Sergey G Brazhnikov via RT wrote: > > Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be > decrypted with previous releases and vice versa. > Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and > 0.9.8(cast5-cfb only) What files? Do you mean private key files? If so, in what form? Encrypted PEM, PKCS#8, PKCS#12? All could have different character set behaviour. I'm assuming the passphrase has non-ASCII characters in it? What is the local character set (chcp) when the file is created, and when it is used? You're doing this on the same machine? Can you show an example? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rt at openssl.org Wed Oct 5 07:49:13 2016 From: rt at openssl.org (David Woodhouse via RT) Date: Wed, 05 Oct 2016 07:49:13 +0000 Subject: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases) In-Reply-To: <1475653748.45169.906.camel@infradead.org> References: <1475653748.45169.906.camel@infradead.org> Message-ID: On Wed, 2016-10-05 at 07:05 +0000, Sergey G Brazhnikov via RT wrote: > > Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be > decrypted with previous releases and vice versa. > Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and > 0.9.8(cast5-cfb only) What files? Do you mean private key files? If so, in what form? Encrypted PEM, PKCS#8, PKCS#12? All could have different character set behaviour. I'm assuming the passphrase has non-ASCII characters in it? What is the local character set (chcp) when the file is created, and when it is used? You're doing this on the same machine? Can you show an example? -- dwmw2 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4697 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rsalz at akamai.com Wed Oct 5 08:03:50 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 5 Oct 2016 08:03:50 +0000 Subject: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases) In-Reply-To: <1475653321.45169.903.camel@infradead.org> References: <20161005071714.GE4670@mournblade.imrryr.org> <1475653321.45169.903.camel@infradead.org> Message-ID: <1e04db7b512848fda152d62a0ea762e8@usma1ex-dag1mb1.msg.corp.akamai.com> > And the *only* justification for the fact that bug continues to exist ? and in > fact we introduced a *new* bug in OpenSSL 1.1 instead of fixing it ? is for > backward compatibility with older releases. > > So how can we be so sanguine about the above failure report? Because backward compatibility is very important. From matt at openssl.org Wed Oct 5 09:04:21 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 5 Oct 2016 10:04:21 +0100 Subject: [openssl-dev] Calculating DTLS payload MTU In-Reply-To: <1475624391.45169.890.camel@infradead.org> References: <1475624391.45169.890.camel@infradead.org> Message-ID: <23363bd2-30de-2754-b21f-4ede5b38e890@openssl.org> On 05/10/16 00:39, David Woodhouse wrote: > I have the link MTU (typically 1500 bytes), and a DTLS session is > established. > > I call DTLS_set_link_mtu() to set the link MTU. > > I need to know the DTLS data MTU ? the maximum payload size, which > depends on the cipher in use. > > For example for AES-128-GCM-SHA256 we'd start with 1500 and subtract: > - 20 bytes for a Legacy IP header. > - 8 bytes for UDP header. > - 13 bytes for DTLS header > - 16 bytes for the hash > - 8 bytes for nonce > > ... and be left with 1435 bytes. > > In GnuTLS this is fairly trivial; I call gnutls_dtls_set_mtu() followed > by gnutls_dtls_get_data_mtu(). > > How do I do it in OpenSSL? Do I need to build a big table of the > overhead of all ciphers and calculate it for myself? I don't think there is a simple way to do this. You can ask the underlying BIO to give you the transport protocol overhead using BIO_dgram_get_mtu_overhead(). DTLS1_RT_HEADER_LENGTH gives you the DTLS header value. You can find out features of the ciphersuite using SSL_get_cipher(). Matt From dwmw2 at infradead.org Wed Oct 5 09:05:47 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Oct 2016 10:05:47 +0100 Subject: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases) In-Reply-To: <1e04db7b512848fda152d62a0ea762e8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20161005071714.GE4670@mournblade.imrryr.org> <1475653321.45169.903.camel@infradead.org> <1e04db7b512848fda152d62a0ea762e8@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <1475658347.45169.922.camel@infradead.org> On Wed, 2016-10-05 at 08:03 +0000, Salz, Rich wrote: > > > And the *only* justification for the fact that bug continues to exist ? and in > > fact we introduced a *new* bug in OpenSSL 1.1 instead of fixing it ? is for > > backward compatibility with older releases. > > > > So how can we be so sanguine about the above failure report? > > Because backward compatibility is very important. Absolutely. But Sergey is reporting a *failure* in backwards compatibility, and Viktor's response seemed remarkably sanguine about that... I understand "let's not fix the bugs because backwards compatibility", although I wish we'd done it without introducing a *new* bug in the process. But RT#4697 makes it look like we lost backward compatibility *anyway*, but *without* fixing it to do the right thing. Giving us the worst of both worlds :) -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rt at openssl.org Wed Oct 5 09:08:54 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 05 Oct 2016 09:08:54 +0000 Subject: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases) In-Reply-To: References: <20161005071714.GE4670@mournblade.imrryr.org> <1475653321.45169.903.camel@infradead.org> <1e04db7b512848fda152d62a0ea762e8@usma1ex-dag1mb1.msg.corp.akamai.com> <1475658347.45169.922.camel@infradead.org> Message-ID: I think you are reading too much into Viktor's words. From my perspective he was proposing a work-around, nothing more. Yeah, what we did is sub-optimal. Not the first time, won't be the last :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4697 Please log in as guest with password guest if prompted From dwmw2 at infradead.org Wed Oct 5 10:24:46 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Oct 2016 11:24:46 +0100 Subject: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases) In-Reply-To: References: <20161005071714.GE4670@mournblade.imrryr.org> <1475653321.45169.903.camel@infradead.org> <1e04db7b512848fda152d62a0ea762e8@usma1ex-dag1mb1.msg.corp.akamai.com> <1475658347.45169.922.camel@infradead.org> Message-ID: <1475663086.113484.10.camel@infradead.org> On Wed, 2016-10-05 at 09:08 +0000, Salz, Rich via RT wrote: > I think you are reading too much into Viktor's?words.? From my > perspective he was proposing a work-around, nothing more. OK, that makes sense. > Yeah, what we did is sub-optimal.? Not the first time, won't be the > last :) :) -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rt at openssl.org Wed Oct 5 11:24:48 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 05 Oct 2016 11:24:48 +0000 Subject: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases) In-Reply-To: References: Message-ID: On Wed Oct 05 07:05:06 2016, sgbrazhnikov at gmail.com wrote: > Hi, guys. > > Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be > decrypted with previous releases and vice versa. > Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and > 0.9.8(cast5-cfb only) > > All built without errors, passed all tests. > Configuration VC-WIN32, os Windows 8.1 Pro x64, compiler vs2015. > In case you're referring to files encrypted using the "enc" utility this is because the default digest used for key derivation was changed from MD5 to SHA256 in OpenSSL 1.1.0. You can change this using the -md option. So supplying "-md md5" should retain compatibility. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4697 Please log in as guest with password guest if prompted From rt at openssl.org Wed Oct 5 11:38:50 2016 From: rt at openssl.org (Timothe Litt via RT) Date: Wed, 05 Oct 2016 11:38:50 +0000 Subject: [openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser In-Reply-To: <4c1a748f-94f7-efed-b63b-d4328fc318dd@acm.org> References: <4c1a748f-94f7-efed-b63b-d4328fc318dd@acm.org> Message-ID: PEM consists of base64 inside a header and trailer line. OpenSSL crashes with embedded newlines. This was mentioned to me by the OpenXPKI project. See RFC 7468 section 2: Data before the encapsulation boundaries are permitted, and parsers MUST NOT malfunction when processing such data. Furthermore, parsers SHOULD ignore whitespace and other non- base64 characters and MUST handle different newline conventions. Reproducible with the attached PEM certificate request and OpenSSL 1.02h (linux). openssl req -text -in t/csr1.pem unable to load X509 request 3086379164:error:0906D066:PEM routines:PEM_read_bio:bad end line:pem_lib.c:809: This request is valid - although it (intentionally) also exceeds the standard line length. Note that OpenSSL will accept it if re-formatted: | perl -Mwarnings -Mstrict -MMIME::Base64 -e'local $/; my $x = ; $x =~ s/.*^(-----BEGIN CERTIFICATE REQUEST-----\r?\n)(.*)^(-----END CERTIFICATE REQUEST-----).*/$1 . encode_base64(decode_base64( $2 )) . $3/ems; print $x' From rt at openssl.org Wed Oct 5 11:52:23 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 05 Oct 2016 11:52:23 +0000 Subject: [openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser In-Reply-To: References: <4c1a748f-94f7-efed-b63b-d4328fc318dd@acm.org> Message-ID: Well, it is a SHOULD not a MUST. But point taken it could be (much) better :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4698 Please log in as guest with password guest if prompted From rt at openssl.org Wed Oct 5 12:02:54 2016 From: rt at openssl.org (Timothe Litt via RT) Date: Wed, 05 Oct 2016 12:02:54 +0000 Subject: [openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser In-Reply-To: <68593d3e-4f85-baf8-0ed1-5bc305fb44b0@acm.org> References: <4c1a748f-94f7-efed-b63b-d4328fc318dd@acm.org> <68593d3e-4f85-baf8-0ed1-5bc305fb44b0@acm.org> Message-ID: On 05-Oct-16 07:52, Salz, Rich via RT wrote: > Well, it is a SHOULD not a MUST. But point taken it could be (much) better :) > > It's an important SHOULD. Whitespace introduction happens in the wild. This is the quote from the OpenXPKI folks: > I just saw this today at a customer install that a user uploaded a > PCSK10 request with extra newlines, anything based on Crypt::PKCS10 is > happy with it but openssl crashes when it tries to sign. See https://github.com/openxpki/openxpki/issues/437 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4698 Please log in as guest with password guest if prompted From rt at openssl.org Wed Oct 5 12:56:26 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 05 Oct 2016 12:56:26 +0000 Subject: [openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser In-Reply-To: References: <4c1a748f-94f7-efed-b63b-d4328fc318dd@acm.org> <68593d3e-4f85-baf8-0ed1-5bc305fb44b0@acm.org> Message-ID: To be noted, there's more in section 2: Most extant parsers ignore blanks at the ends of lines; blanks at the beginnings of lines or in the middle of the base64-encoded data are far less compatible. These observations are codified in Figure 1. The most lax parser implementations are not line-oriented at all and will accept any mixture of whitespace outside of the encapsulation boundaries (see Figure 2). Such lax parsing may run the risk of accepting text that was not intended to be accepted in the first place (e.g., because the text was a snippet or sample). I haven't looked enough in our code recently to remember if we're doing "standard" (figure 1) or "strict" (figure 3) parsing... what I hear is a request for us to move to "lax" (figure 2) parsing. Cheers, Richard On Wed Oct 05 12:02:54 2016, litt at acm.org wrote: > On 05-Oct-16 07:52, Salz, Rich via RT wrote: > > > Well, it is a SHOULD not a MUST. But point taken it could be (much) > > better :) > > > > > It's an important SHOULD. Whitespace introduction happens in the > wild. > > This is the quote from the OpenXPKI folks: > > I just saw this today at a customer install that a user uploaded a > > PCSK10 request with extra newlines, anything based on Crypt::PKCS10 > > is > > happy with it but openssl crashes when it tries to sign. > > See https://github.com/openxpki/openxpki/issues/437 -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4698 Please log in as guest with password guest if prompted From rt at openssl.org Wed Oct 5 13:10:44 2016 From: rt at openssl.org (Llewelyn Thomas via RT) Date: Wed, 05 Oct 2016 13:10:44 +0000 Subject: [openssl-dev] [openssl.org #4696] Resolved: BUG: openssl1.0.2j Solaris-Sparc : ../util/shlib_wrap.sh ./bad_dtls_test - core dump In-Reply-To: References: , Message-ID: Confirmed - thanks for the reply! ________________________________ From: Rich Salz via RT Sent: 05 October 2016 08:09:49 To: Llewelyn Thomas Subject: [openssl.org #4696] Resolved: BUG: openssl1.0.2j Solaris-Sparc : ../util/shlib_wrap.sh ./bad_dtls_test - core dump According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4696 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4696 Please log in as guest with password guest if prompted From dwmw2 at infradead.org Wed Oct 5 13:40:15 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Oct 2016 14:40:15 +0100 Subject: [openssl-dev] Calculating DTLS payload MTU In-Reply-To: <23363bd2-30de-2754-b21f-4ede5b38e890@openssl.org> References: <1475624391.45169.890.camel@infradead.org> <23363bd2-30de-2754-b21f-4ede5b38e890@openssl.org> Message-ID: <1475674815.113484.21.camel@infradead.org> On Wed, 2016-10-05 at 10:04 +0100, Matt Caswell wrote: > > > For example for AES-128-GCM-SHA256 we'd start with 1500 and subtract: > >? - 20 bytes for a Legacy IP header. > >? - 8 bytes for UDP header. > >? - 13 bytes for DTLS header > >? - 16 bytes for the hash > >? - 8 bytes for nonce > > > > ... and be left with 1435 bytes. > > > > In GnuTLS this is fairly trivial; I call gnutls_dtls_set_mtu() followed > > by gnutls_dtls_get_data_mtu(). > > > > How do I do it in OpenSSL? Do I need to build a big table of the > > overhead of all ciphers and calculate it for myself? > > I don't think there is a simple way to do this. > > You can ask the underlying BIO to give you the transport protocol > overhead using BIO_dgram_get_mtu_overhead(). DTLS1_RT_HEADER_LENGTH > gives you the DTLS header value. You can find out features of the > ciphersuite using SSL_get_cipher(). Right, it's the "features of the ciphersuite" which is the fun part.? Specifically, the size of the nonce/IV, the size of the hash, and the block size for block ciphers where we need to round up the sizes. SSL_get_cipher() gives me a string, and I could implement a big lookup table ? but we recently moved to using PSK and "proper" DTLS negotiation precisely to *avoid* having to have ciphersuite-specific knowledge in the client. How's this for a start... how is it that the more I work on this stuff, the more I realise how *utterly* clueless about it I am? :) Specific questions I *know* I need to focus on include which *other* modes other than CBC/CCM/GCM I might need to handle, and fairly much everything about the CCM case. Can we add something to OpenSSL 1.2 which means I don't need to keep doing this in the application, please? /* sets the DTLS MTU and returns the actual tunnel MTU */ unsigned dtls_set_mtu(struct openconnect_info *vpninfo, unsigned mtu) { int tun_mtu; int ivlen, maclen, blocksize = 1, pad = 0; #if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER) /* OpenSSL <= 1.0.2 only supports CBC ciphers with PSK */ ivlen = EVP_CIPHER_iv_length(EVP_CIPHER_CTX_cipher(vpninfo->dtls_ssl->enc_write_ctx)); maclen = EVP_MD_CTX_size(vpninfo->dtls_ssl->write_hash); blocksize = ivlen; pad = 1; #else /* Now it gets more fun... */ const SSL_CIPHER *s_ciph = SSL_get_current_cipher(vpninfo->dtls_ssl); const EVP_CIPHER *e_ciph; const EVP_MD *e_md; e_ciph = EVP_get_cipherbynid(SSL_CIPHER_get_cipher_nid(s_ciph)); switch (EVP_CIPHER_mode(e_ciph)) { case EVP_CIPH_GCM_MODE: ivlen = EVP_GCM_TLS_EXPLICIT_IV_LEN; maclen = EVP_GCM_TLS_TAG_LEN; blocksize = 1; pad = 0; break; case EVP_CIPH_CCM_MODE: ivlen = EVP_CCM_TLS_EXPLICIT_IV_LEN; /* What is the tag size for CCM? */ maclen = blocksize = EVP_CIPHER_block_size(e_ciph); /* Padding same as CBC? */ pad = 1; break; case EVP_CIPH_CBC_MODE: e_md = EVP_get_digestbynid(SSL_CIPHER_get_digest_nid(s_ciph)); blocksize = EVP_CIPHER_block_size(e_ciph); ivlen = EVP_CIPHER_iv_length(e_ciph); pad = 1; maclen = EVP_MD_size(e_md); break; default: // XXX ; } #endif /* Take off the explicit IV and the MAC (XXX: overflow!) */ printf("iv %d mac %d blk %d\n", ivlen, maclen, blocksize); tun_mtu = mtu - DTLS1_RT_HEADER_LENGTH - ivlen - maclen; /* For block cipher modes round down to blocksize */ printf("tun %d & 0x%x == %d\n", tun_mtu, ~(blocksize-1), tun_mtu & (~(blocksize-1))); tun_mtu &= ~(blocksize-1); /* ... and CBC modes require at least one byte to indicate padding length */ tun_mtu -= pad; DTLS_set_link_mtu(vpninfo->dtls_ssl, mtu); /* We already set the link MTU, but hopefully by the time we * finish it, this function will be better at working out the * actual tunnel MTU than OpenSSL is. So do that too... */ SSL_set_mtu(vpninfo->dtls_ssl, tun_mtu); return tun_mtu; } -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rt at openssl.org Wed Oct 5 13:49:01 2016 From: rt at openssl.org (Sergey G Brazhnikov via RT) Date: Wed, 05 Oct 2016 13:49:01 +0000 Subject: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases) In-Reply-To: References: Message-ID: Yes, Steve, you're right! Thank you. I'm sorry for imprecise wording. Sergey. 2016-10-05 16:24 GMT+05:00 Stephen Henson via RT : > On Wed Oct 05 07:05:06 2016, sgbrazhnikov at gmail.com wrote: > > Hi, guys. > > > > Just figured out that files encrypted with OpenSSL 1.1.0-stable can not > be > > decrypted with previous releases and vice versa. > > Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and > > 0.9.8(cast5-cfb only) > > > > All built without errors, passed all tests. > > Configuration VC-WIN32, os Windows 8.1 Pro x64, compiler vs2015. > > > > In case you're referring to files encrypted using the "enc" utility this is > because the default digest used for key derivation was changed from MD5 to > SHA256 in OpenSSL 1.1.0. > > You can change this using the -md option. So supplying "-md md5" should > retain > compatibility. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4697 > Please log in as guest with password guest if prompted > > -- ? ??., ????????? ?. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4697 Please log in as guest with password guest if prompted From rt at openssl.org Wed Oct 5 13:58:12 2016 From: rt at openssl.org (Timothe Litt via RT) Date: Wed, 05 Oct 2016 13:58:12 +0000 Subject: [openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser In-Reply-To: References: <4c1a748f-94f7-efed-b63b-d4328fc318dd@acm.org> <68593d3e-4f85-baf8-0ed1-5bc305fb44b0@acm.org> Message-ID: On 05-Oct-16 08:56, Richard Levitte via RT wrote: > To be noted, there's more in section 2: > > Most extant parsers ignore blanks at the ends of lines; blanks at the > beginnings of lines or in the middle of the base64-encoded data are > far less compatible. These observations are codified in Figure 1. > The most lax parser implementations are not line-oriented at all and > will accept any mixture of whitespace outside of the encapsulation > boundaries (see Figure 2). Such lax parsing may run the risk of > accepting text that was not intended to be accepted in the first > place (e.g., because the text was a snippet or sample). > > I haven't looked enough in our code recently to remember if we're doing > "standard" (figure 1) or "strict" (figure 3) parsing... what I hear is a > request for us to move to "lax" (figure 2) parsing. Yes. Actually, the text is even more lax than the BNF; it says in paragraph 1 that parsers SHOULD ignore whitespace and other non- base64 characters That is, anything but A-Za-z0-9+/ and = at the end (as pad) should be ignored between the header and the footer. Many decoders do that silently, some warn if the junk isn't whitespace. Let's step back a bit from the letter of the RFCs and consider what brought this up: The real-word issues that drive this are cases like cut and paste of a CSR, certificate, or key from a webpage, terminal window or e-mail. All may re-wrap such that whitespace is introduced or lost. Further, especially with long keys, the text may not all be visible at once, so one ends up scrolling and/or copy/pasting in sections. Again introducing and/or losing white space. And exactly how textboxes on web pages represent EOL and interact with copy/paste varies. Lost newlines can produce long lines, and many base64 encoders (e.g. Perl's MIME::Base64) produce PEM that's longer than 64 characters (e.g. the 72 characters recommended for MIME.) CSRs/Certificates/Keys appear on webpages generated by embedded devices (think NAS, routers), as well as CAs and terminal windows. So while one would like to think that they're never touched by human hands, the reality is that they are. I'm not as concerned about "accepting text that was not intended to be accepted in the first place" because validation of the data will occur. CSRs and certificates are signed, and will fail validation if corrupt. Keys won't work if corrupt. All have to pass ASN.1 parsing, which also will catch many forms of corruption. OpenSSL should accept the CSR that I posted as a test case. Whether to also ignore non-base64 characters is debatable. I vote for warning (e.g. a distinct SUCCESS code that the caller can elect to report or ignore). What's fixed is that there must be a "-----BEGIN" line, and there's little excuse for not having a "-----END" line, though the newline after the "-----END" may be optional. Embedded whitespace must be ignored - which includes that line length is unrestricted. This is something that both humans with a mouse and software can comprehend... The approach I use is to discard all whitespace, check for only base64 + optional pad & ensure that the length, including 0-2 pad (=) at the end is an even multiple of 4 characters long. Otherwise, (non-base64 or not a sane length) I warn but process the input. (A Perl implementation is in the OpenXPKI issue that I cited.) Naturally, I am NOT arguing that PEM can be produced in lax form; this is only about making the input parsing compatible with (RFC-compliant) cases common in the real world. I hope this provides context for your decisions... Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4698 Please log in as guest with password guest if prompted From rt at openssl.org Wed Oct 5 14:15:41 2016 From: rt at openssl.org (Kaduk, Ben via RT) Date: Wed, 05 Oct 2016 14:15:41 +0000 Subject: [openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser In-Reply-To: <32a7d496-b1fc-b4eb-8165-1fe0b15ab951@akamai.com> References: <4c1a748f-94f7-efed-b63b-d4328fc318dd@acm.org> <68593d3e-4f85-baf8-0ed1-5bc305fb44b0@acm.org> <32a7d496-b1fc-b4eb-8165-1fe0b15ab951@akamai.com> Message-ID: On 10/05/2016 07:56 AM, Richard Levitte via RT wrote: > To be noted, there's more in section 2: > > Most extant parsers ignore blanks at the ends of lines; blanks at the > beginnings of lines or in the middle of the base64-encoded data are > far less compatible. These observations are codified in Figure 1. > The most lax parser implementations are not line-oriented at all and > will accept any mixture of whitespace outside of the encapsulation > boundaries (see Figure 2). Such lax parsing may run the risk of > accepting text that was not intended to be accepted in the first > place (e.g., because the text was a snippet or sample). > > I haven't looked enough in our code recently to remember if we're doing > "standard" (figure 1) or "strict" (figure 3) parsing... what I hear is a > request for us to move to "lax" (figure 2) parsing. > If I remember correctly, it's somewhere in between. The core PEM-parsing code is vintage EAY, and contains some "interesting" behavior, like going to the end of the line/buffer that was read, backtracking past any characters with ASCII value less than or equal to that of , and writing \n\0. So, it seems like trailing whitespace would be ignored, but leading whitespace would trip up the "len == 65" check later on. I refactored this stuff a while ago to add a flags field that would force the temporary read buffer to be allocated from the secure heap; I should really dig it up and clean it up for master. -Ben -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4698 Please log in as guest with password guest if prompted From dwmw2 at infradead.org Wed Oct 5 14:37:18 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Oct 2016 15:37:18 +0100 Subject: [openssl-dev] Calculating DTLS payload MTU In-Reply-To: <1475674815.113484.21.camel@infradead.org> References: <1475624391.45169.890.camel@infradead.org> <23363bd2-30de-2754-b21f-4ede5b38e890@openssl.org> <1475674815.113484.21.camel@infradead.org> Message-ID: <1475678238.113484.24.camel@infradead.org> On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote: > How's this for a start... Now I think I have it right for CCM too, although having to use strstr() for that makes me *very* sad. Next up, Chacha20-Poly1305... and then maybe I can stop worrying about new modes and ciphersuites because those won't be added in OpenSSL 1.1 and we can get OpenSSL do to this for itself before 1.2? :) /* sets the DTLS MTU and returns the actual tunnel MTU */ unsigned dtls_set_mtu(struct openconnect_info *vpninfo, unsigned mtu) { int tun_mtu; int ivlen, maclen, blocksize = 1, pad = 0; #if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER) /* OpenSSL <= 1.0.2 only supports CBC ciphers with PSK */ ivlen = EVP_CIPHER_iv_length(EVP_CIPHER_CTX_cipher(vpninfo->dtls_ssl->enc_write_ctx)); maclen = EVP_MD_CTX_size(vpninfo->dtls_ssl->write_hash); blocksize = ivlen; pad = 1; #else /* Now it gets more fun... */ const SSL_CIPHER *s_ciph = SSL_get_current_cipher(vpninfo->dtls_ssl); const EVP_CIPHER *e_ciph; const EVP_MD *e_md; char wtf[128]; e_ciph = EVP_get_cipherbynid(SSL_CIPHER_get_cipher_nid(s_ciph)); switch (EVP_CIPHER_mode(e_ciph)) { case EVP_CIPH_GCM_MODE: ivlen = EVP_GCM_TLS_EXPLICIT_IV_LEN; maclen = EVP_GCM_TLS_TAG_LEN; blocksize = 1; pad = 0; break; case EVP_CIPH_CCM_MODE: ivlen = EVP_CCM_TLS_EXPLICIT_IV_LEN; SSL_CIPHER_description(s_ciph, wtf, sizeof(wtf)); if (strstr(wtf, "CCM8")) maclen = 8; else maclen = 16; blocksize = 1; pad = 0; break; case EVP_CIPH_CBC_MODE: e_md = EVP_get_digestbynid(SSL_CIPHER_get_digest_nid(s_ciph)); blocksize = EVP_CIPHER_block_size(e_ciph); ivlen = EVP_CIPHER_iv_length(e_ciph); pad = 1; maclen = EVP_MD_size(e_md); break; case EVP_CIPH_STREAM_CIPHER: /* Seen with PSK-CHACHA20-POLY1305 */ default: printf("wtf mode %d\n", EVP_CIPHER_mode(e_ciph)); // XXX ; } #endif /* Take off the explicit IV and the MAC (XXX: overflow!) */ printf("iv %d mac %d blk %d\n", ivlen, maclen, blocksize); tun_mtu = mtu - DTLS1_RT_HEADER_LENGTH - ivlen - maclen; /* For block cipher modes round down to blocksize */ printf("tun %d & 0x%x == %d\n", tun_mtu, ~(blocksize-1), tun_mtu & (~(blocksize-1))); tun_mtu -= tun_mtu % blocksize; /* ... and CBC modes require at least one byte to indicate padding length */ tun_mtu -= pad; DTLS_set_link_mtu(vpninfo->dtls_ssl, mtu); /* We already set the link MTU, but hopefully by the time we * finish it, this function will be better at working out the * actual tunnel MTU than OpenSSL is. So do that too... */ SSL_set_mtu(vpninfo->dtls_ssl, tun_mtu); return tun_mtu; } -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rt at openssl.org Wed Oct 5 18:38:49 2016 From: rt at openssl.org (Timothe Litt via RT) Date: Wed, 05 Oct 2016 18:38:49 +0000 Subject: [openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser In-Reply-To: <1f2861fa-3da4-5926-b557-2b48ff1f1bb0@acm.org> References: <4c1a748f-94f7-efed-b63b-d4328fc318dd@acm.org> <68593d3e-4f85-baf8-0ed1-5bc305fb44b0@acm.org> <1f2861fa-3da4-5926-b557-2b48ff1f1bb0@acm.org> Message-ID: One more reference: https://tools.ietf.org/html/rfc4648#section-3.3 describes the considerations for 'non-base64 characters'. Short form: MIME requires that they be ignored. 7468 says SHOULD. 4648 says 'reject, unless the referencing spec says otherwise' (which 7468 does.) I wrote previously that MIME's limit on line length is 72; according to 4648 3.1 it's actually 76. Sorry. The point is, it's NOT 64 (which is what PEM specifies.). (65 in OpenSSL must include the end-of-line.) Note that all 3 constants are (deliberately) a multiple of 4, meaning that the decoding of a byte can't span lines. However, this is not true in the wild; end-of-line can appear anywhere. (Again, wrapping by MUAs, web browsers and embedded devices are the most frequent offenders.) Here's the full text of 3.3: > Base encodings use a specific, reduced alphabet to encode binary > data. Non-alphabet characters could exist within base-encoded data, > caused by data corruption or by design. Non-alphabet characters may > be exploited as a "covert channel", where non-protocol data can be > sent for nefarious purposes. Non-alphabet characters might also be > sent in order to exploit implementation errors leading to, e.g., > buffer overflow attacks. > > Implementations MUST reject the encoded data if it contains > characters outside the base alphabet when interpreting base-encoded > data, unless the specification referring to this document explicitly > states otherwise. Such specifications may instead state, as MIME > does, that characters outside the base encoding alphabet should > simply be ignored when interpreting data ("be liberal in what you > accept"). Note that this means that any adjacent carriage return/ > line feed (CRLF) characters constitute "non-alphabet characters" and > are ignored. Furthermore, such specifications MAY ignore the pad > character, "=", treating it as non-alphabet data, if it is present > before the end of the encoded data. If more than the allowed number > of pad characters is found at the end of the string (e.g., a base 64 > string terminated with "==="), the excess pad characters MAY also be > ignored. > Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4698 Please log in as guest with password guest if prompted From matt at openssl.org Wed Oct 5 19:46:49 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 5 Oct 2016 20:46:49 +0100 Subject: [openssl-dev] Calculating DTLS payload MTU In-Reply-To: <1475678238.113484.24.camel@infradead.org> References: <1475624391.45169.890.camel@infradead.org> <23363bd2-30de-2754-b21f-4ede5b38e890@openssl.org> <1475674815.113484.21.camel@infradead.org> <1475678238.113484.24.camel@infradead.org> Message-ID: <12e38ff6-b2d0-39f3-2cd7-8449cd23cca4@openssl.org> On 05/10/16 15:37, David Woodhouse wrote: > On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote: >> How's this for a start... > > Now I think I have it right for CCM too, although having to use > strstr() for that makes me *very* sad. Next up, Chacha20-Poly1305... > and then maybe I can stop worrying about new modes and ciphersuites > because those won't be added in OpenSSL 1.1 and we can get OpenSSL do > to this for itself before 1.2? :) Or even 1.1.1! Why don't you pull this together into a github PR? Matt > > /* sets the DTLS MTU and returns the actual tunnel MTU */ > unsigned dtls_set_mtu(struct openconnect_info *vpninfo, unsigned mtu) > { > int tun_mtu; > int ivlen, maclen, blocksize = 1, pad = 0; > > #if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER) > /* OpenSSL <= 1.0.2 only supports CBC ciphers with PSK */ > ivlen = EVP_CIPHER_iv_length(EVP_CIPHER_CTX_cipher(vpninfo->dtls_ssl->enc_write_ctx)); > maclen = EVP_MD_CTX_size(vpninfo->dtls_ssl->write_hash); > blocksize = ivlen; > pad = 1; > #else > /* Now it gets more fun... */ > const SSL_CIPHER *s_ciph = SSL_get_current_cipher(vpninfo->dtls_ssl); > const EVP_CIPHER *e_ciph; > const EVP_MD *e_md; > char wtf[128]; > > e_ciph = EVP_get_cipherbynid(SSL_CIPHER_get_cipher_nid(s_ciph)); > > switch (EVP_CIPHER_mode(e_ciph)) { > case EVP_CIPH_GCM_MODE: > ivlen = EVP_GCM_TLS_EXPLICIT_IV_LEN; > maclen = EVP_GCM_TLS_TAG_LEN; > blocksize = 1; > pad = 0; > break; > > case EVP_CIPH_CCM_MODE: > ivlen = EVP_CCM_TLS_EXPLICIT_IV_LEN; > SSL_CIPHER_description(s_ciph, wtf, sizeof(wtf)); > if (strstr(wtf, "CCM8")) > maclen = 8; > else > maclen = 16; > blocksize = 1; > pad = 0; > break; > > case EVP_CIPH_CBC_MODE: > e_md = EVP_get_digestbynid(SSL_CIPHER_get_digest_nid(s_ciph)); > blocksize = EVP_CIPHER_block_size(e_ciph); > ivlen = EVP_CIPHER_iv_length(e_ciph); > pad = 1; > maclen = EVP_MD_size(e_md); > break; > > case EVP_CIPH_STREAM_CIPHER: > /* Seen with PSK-CHACHA20-POLY1305 */ > default: > printf("wtf mode %d\n", EVP_CIPHER_mode(e_ciph)); > // XXX > ; > } > #endif > > > /* Take off the explicit IV and the MAC (XXX: overflow!) */ > printf("iv %d mac %d blk %d\n", ivlen, maclen, blocksize); > tun_mtu = mtu - DTLS1_RT_HEADER_LENGTH - ivlen - maclen; > /* For block cipher modes round down to blocksize */ > printf("tun %d & 0x%x == %d\n", tun_mtu, ~(blocksize-1), tun_mtu & (~(blocksize-1))); > tun_mtu -= tun_mtu % blocksize; > /* ... and CBC modes require at least one byte to indicate padding length */ > tun_mtu -= pad; > > DTLS_set_link_mtu(vpninfo->dtls_ssl, mtu); > > /* We already set the link MTU, but hopefully by the time we > * finish it, this function will be better at working out the > * actual tunnel MTU than OpenSSL is. So do that too... */ > SSL_set_mtu(vpninfo->dtls_ssl, tun_mtu); > > return tun_mtu; > } > From dwmw2 at infradead.org Wed Oct 5 19:59:38 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 5 Oct 2016 19:59:38 -0000 Subject: [openssl-dev] Calculating DTLS payload MTU In-Reply-To: <12e38ff6-b2d0-39f3-2cd7-8449cd23cca4@openssl.org> References: <1475624391.45169.890.camel@infradead.org> <23363bd2-30de-2754-b21f-4ede5b38e890@openssl.org> <1475674815.113484.21.camel@infradead.org> <1475678238.113484.24.camel@infradead.org> <12e38ff6-b2d0-39f3-2cd7-8449cd23cca4@openssl.org> Message-ID: <029d826b44730e2ccfa06c5f0a1aab99.squirrel@twosheds.infradead.org> > > > On 05/10/16 15:37, David Woodhouse wrote: >> On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote: >>> How's this for a start... >> >> Now I think I have it right for CCM too, although having to use >> strstr() for that makes me *very* sad. Next up, Chacha20-Poly1305... >> and then maybe I can stop worrying about new modes and ciphersuites >> because those won't be added in OpenSSL 1.1 and we can get OpenSSL do >> to this for itself before 1.2? :) > > Or even 1.1.1! Why don't you pull this together into a github PR? Sure. Any thoughts on what you want it to look like? Not just SSL_CIPHER_get_overhead() because it'seems not constant -- you have to account for blocksize rounding and padding in CBC ciphers. So just SSL_CIPHER_get_data_mtu(int link_mtu)? Or are there other use cases we want it for, and we *should* try returning a full set of three "add this, round up to this, add this" integers? As for the actual numbers... am I on the right track so far? -- dwmw2 From matt at openssl.org Wed Oct 5 20:29:39 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 5 Oct 2016 21:29:39 +0100 Subject: [openssl-dev] Calculating DTLS payload MTU In-Reply-To: <029d826b44730e2ccfa06c5f0a1aab99.squirrel@twosheds.infradead.org> References: <1475624391.45169.890.camel@infradead.org> <23363bd2-30de-2754-b21f-4ede5b38e890@openssl.org> <1475674815.113484.21.camel@infradead.org> <1475678238.113484.24.camel@infradead.org> <12e38ff6-b2d0-39f3-2cd7-8449cd23cca4@openssl.org> <029d826b44730e2ccfa06c5f0a1aab99.squirrel@twosheds.infradead.org> Message-ID: <3d90bf91-296e-d5a6-8362-2f79bbe45fdc@openssl.org> On 05/10/16 20:59, David Woodhouse wrote: > >> >> >> On 05/10/16 15:37, David Woodhouse wrote: >>> On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote: >>>> How's this for a start... >>> >>> Now I think I have it right for CCM too, although having to use >>> strstr() for that makes me *very* sad. Next up, Chacha20-Poly1305... >>> and then maybe I can stop worrying about new modes and ciphersuites >>> because those won't be added in OpenSSL 1.1 and we can get OpenSSL do >>> to this for itself before 1.2? :) >> >> Or even 1.1.1! Why don't you pull this together into a github PR? > > Sure. Any thoughts on what you want it to look like? Not just > SSL_CIPHER_get_overhead() because it'seems not constant -- you have to > account for blocksize rounding and padding in CBC ciphers. So just > SSL_CIPHER_get_data_mtu(int link_mtu)? Hmmmm....well its not constant even by cipher. It depends on the transport (IPv6 has a bigger overhead than IPv4). We already have: DTLS_set_link_mtu(SSL *s, int mtu) So why not: DTLS_get_data_mtu(SSL *s) > > Or are there other use cases we want it for, and we *should* try returning > a full set of three "add this, round up to this, add this" integers? > > As for the actual numbers... am I on the right track so far? > I've not thought about it in great detail, but it looks ok at first glance. Matt From matt at openssl.org Wed Oct 5 20:31:56 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 5 Oct 2016 21:31:56 +0100 Subject: [openssl-dev] Calculating DTLS payload MTU In-Reply-To: <1475678238.113484.24.camel@infradead.org> References: <1475624391.45169.890.camel@infradead.org> <23363bd2-30de-2754-b21f-4ede5b38e890@openssl.org> <1475674815.113484.21.camel@infradead.org> <1475678238.113484.24.camel@infradead.org> Message-ID: <7e1ede07-8073-b3dc-a9dc-2bfbee0ef8c0@openssl.org> On 05/10/16 15:37, David Woodhouse wrote: > DTLS_set_link_mtu(vpninfo->dtls_ssl, mtu); > > /* We already set the link MTU, but hopefully by the time we > * finish it, this function will be better at working out the > * actual tunnel MTU than OpenSSL is. So do that too... */ > SSL_set_mtu(vpninfo->dtls_ssl, tun_mtu); This is pointless. The link mtu setting will take precedence. Matt From dwmw2 at infradead.org Wed Oct 5 21:28:53 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Oct 2016 22:28:53 +0100 Subject: [openssl-dev] Calculating DTLS payload MTU In-Reply-To: <7e1ede07-8073-b3dc-a9dc-2bfbee0ef8c0@openssl.org> References: <1475624391.45169.890.camel@infradead.org> <23363bd2-30de-2754-b21f-4ede5b38e890@openssl.org> <1475674815.113484.21.camel@infradead.org> <1475678238.113484.24.camel@infradead.org> <7e1ede07-8073-b3dc-a9dc-2bfbee0ef8c0@openssl.org> Message-ID: <1475702933.28198.70.camel@infradead.org> On Wed, 2016-10-05 at 21:31 +0100, Matt Caswell wrote: > > > On 05/10/16 15:37, David Woodhouse wrote: > >???????DTLS_set_link_mtu(vpninfo->dtls_ssl, mtu); > >? > >???????/* We already set the link MTU, but hopefully by the time we > >??????? * finish it, this function will be better at working out the > >??????? * actual tunnel MTU than OpenSSL is. So do that too... */ > >???????SSL_set_mtu(vpninfo->dtls_ssl, tun_mtu); > > This is pointless. The link mtu setting will take precedence. Hm, thanks. It's also wrong. There are *three* MTU values, and I had conflated them. Firstly there is the the link MTU (d1->link_mtu, e.g. 1500). Secondly there is the DTLS record MTU without the IP/UDP overhead (d1->mtu, e.g. 1472). Finally there's the one I need to find, the data payload MTU (with AES128-GCM e.g. 1434). The code you saw was using DTLS_set_link_mtu(1472) where it should be using SSL_set_mtu(1472). I shouldn't be calling DTLS_set_link_mtu() at all. --? dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From dwmw2 at infradead.org Wed Oct 5 21:51:06 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 05 Oct 2016 22:51:06 +0100 Subject: [openssl-dev] Calculating DTLS payload MTU In-Reply-To: <3d90bf91-296e-d5a6-8362-2f79bbe45fdc@openssl.org> References: <1475624391.45169.890.camel@infradead.org> <23363bd2-30de-2754-b21f-4ede5b38e890@openssl.org> <1475674815.113484.21.camel@infradead.org> <1475678238.113484.24.camel@infradead.org> <12e38ff6-b2d0-39f3-2cd7-8449cd23cca4@openssl.org> <029d826b44730e2ccfa06c5f0a1aab99.squirrel@twosheds.infradead.org> <3d90bf91-296e-d5a6-8362-2f79bbe45fdc@openssl.org> Message-ID: <1475704266.28198.86.camel@infradead.org> On Wed, 2016-10-05 at 21:29 +0100, Matt Caswell wrote: > Hmmmm....well its not constant even by cipher. It depends on the > transport (IPv6 has a bigger overhead than IPv4). That is included in d1->link_mtu (DTLS_set_link_mtu()) but is not included in d1->mtu (SSL_set_mtu()). Even when we let DTLS autodetect by using BIO_CTRL_DGRAM_QUERY_MTU, it gets a value without the (assumed) IP/UDP overhead, which goes straight into d1->mtu. The "link MTU" thing is purely a special case for application convenience. AFAICT we only *ever* use it by subtracting the BIO_CTRL_DGRAM_GET_MTU_OVERHEAD value (which again assumes UDP not SCTP) and then dealing with d1->mtu thereafter. So let's forget all about the "link MTU" and the IP/UDP overhead for now. They are an orthogonal issue. > So why not: > > DTLS_get_data_mtu(SSL *s) Yeah. OK. And I don't think we need a DTLS_set_data_mtu(). If the application knows the largest data payload it'll ever send... who cares about telling OpenSSL the MTU? Just call SSL_set_mtu(s, 65536) and then send what you like. > I've not thought about it in great detail, but it looks ok at first > glance. Thanks. I'll use that as a basis for DTLS_get_data_mtu() then. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From matt at openssl.org Wed Oct 5 21:57:38 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 5 Oct 2016 22:57:38 +0100 Subject: [openssl-dev] Calculating DTLS payload MTU In-Reply-To: <1475704266.28198.86.camel@infradead.org> References: <1475624391.45169.890.camel@infradead.org> <23363bd2-30de-2754-b21f-4ede5b38e890@openssl.org> <1475674815.113484.21.camel@infradead.org> <1475678238.113484.24.camel@infradead.org> <12e38ff6-b2d0-39f3-2cd7-8449cd23cca4@openssl.org> <029d826b44730e2ccfa06c5f0a1aab99.squirrel@twosheds.infradead.org> <3d90bf91-296e-d5a6-8362-2f79bbe45fdc@openssl.org> <1475704266.28198.86.camel@infradead.org> Message-ID: <8b82c53a-c93c-66d5-c0ef-aa58dea82c6e@openssl.org> On 05/10/16 22:51, David Woodhouse wrote: > On Wed, 2016-10-05 at 21:29 +0100, Matt Caswell wrote: >> Hmmmm....well its not constant even by cipher. It depends on the >> transport (IPv6 has a bigger overhead than IPv4). > > That is included in d1->link_mtu (DTLS_set_link_mtu()) but is not > included in d1->mtu (SSL_set_mtu()). > > Even when we let DTLS autodetect by using BIO_CTRL_DGRAM_QUERY_MTU, it > gets a value without the (assumed) IP/UDP overhead, which goes straight > into d1->mtu. > > The "link MTU" thing is purely a special case for application > convenience. AFAICT we only *ever* use it by subtracting the > BIO_CTRL_DGRAM_GET_MTU_OVERHEAD value (which again assumes UDP not > SCTP) and then dealing with d1->mtu thereafter. That is not correct. It *is* defined for SCTP. It's just defined to be zero (because SCTP allows fragmentation so MTUs are kind of irrelevant anyway). > > So let's forget all about the "link MTU" and the IP/UDP overhead for > now. They are an orthogonal issue. > >> So why not: >> >> DTLS_get_data_mtu(SSL *s) > > Yeah. OK. And I don't think we need a DTLS_set_data_mtu(). If the > application knows the largest data payload it'll ever send... who cares > about telling OpenSSL the MTU? Just call SSL_set_mtu(s, 65536) and then > send what you like. Fair enough. Matt From dwmw2 at infradead.org Wed Oct 5 23:55:39 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 06 Oct 2016 00:55:39 +0100 Subject: [openssl-dev] Calculating DTLS payload MTU In-Reply-To: <12e38ff6-b2d0-39f3-2cd7-8449cd23cca4@openssl.org> References: <1475624391.45169.890.camel@infradead.org> <23363bd2-30de-2754-b21f-4ede5b38e890@openssl.org> <1475674815.113484.21.camel@infradead.org> <1475678238.113484.24.camel@infradead.org> <12e38ff6-b2d0-39f3-2cd7-8449cd23cca4@openssl.org> Message-ID: <1475711739.28198.97.camel@infradead.org> On Wed, 2016-10-05 at 20:46 +0100, Matt Caswell wrote: > > Or even 1.1.1! Why don't you pull this together into a github PR? https://github.com/openssl/openssl/pull/1666 Not complete, but good enough for you to heckle at the approach, and it'll be a whole lot simpler for someone with more clue to finish filling in my SSL_CIPHER_get_overhead() function. I'm all done reading ciphersuite RFCs for tonigh^Wthis morning. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rt at openssl.org Thu Oct 6 07:15:52 2016 From: rt at openssl.org (Valentin B via RT) Date: Thu, 06 Oct 2016 07:15:52 +0000 Subject: [openssl-dev] [openssl.org #4699] Bug in OpenSSL 1.0.2j-fips 26 Sep 2016 or maybe affects all In-Reply-To: <890b9e82-eaa7-fb9f-64e3-3ff1ce154f60@astro.rug.nl> References: <890b9e82-eaa7-fb9f-64e3-3ff1ce154f60@astro.rug.nl> Message-ID: Hi, While playing around with prime number generation I noticed that the following generates a core dump. I think this is definitely a bug. How to reproduce: $ openssl prime '' Segmentation fault (core dumped) I haven't included any strace output but this can be reproduced by you as well. Kind regards, -- Valentin Bajrami Kapteyn Astronomical Institute University of Groningen Postbus 800 NL-9700 AV Groningen The Netherlands Phone: +31-(0)50-3634068 PGP Fingerprint: 50D7 E233 C2E0 1C81 BB7F F8D8 E51B CF89 A52E 5271 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4699 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Thu Oct 6 07:37:30 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Thu, 06 Oct 2016 07:37:30 +0000 Subject: [openssl-dev] [openssl.org #4699] Bug in OpenSSL 1.0.2j-fips 26 Sep 2016 or maybe affects all In-Reply-To: <890b9e82-eaa7-fb9f-64e3-3ff1ce154f60@astro.rug.nl> References: <890b9e82-eaa7-fb9f-64e3-3ff1ce154f60@astro.rug.nl> Message-ID: It affects all 1.0.2 variants. I've a fix on github: https://github.com/openssl/openssl/pull/1668 Cheers, Richard On Thu Oct 06 07:15:52 2016, valentin at astro.rug.nl wrote: > Hi, > > While playing around with prime number generation I noticed that the > following generates a core dump. I think this is definitely a bug. > > How to reproduce: > > $ openssl prime '' > Segmentation fault (core dumped) > > I haven't included any strace output but this can be reproduced by you > as well. > > > Kind regards, -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4699 Please log in as guest with password guest if prompted From rt at openssl.org Thu Oct 6 09:08:58 2016 From: rt at openssl.org (Valentin B via RT) Date: Thu, 06 Oct 2016 09:08:58 +0000 Subject: [openssl-dev] [openssl.org #4699] Bug in OpenSSL 1.0.2j-fips 26 Sep 2016 or maybe affects all In-Reply-To: <8c18584a-e6a2-6f8d-2191-ba563f3e06ce@astro.rug.nl> References: <890b9e82-eaa7-fb9f-64e3-3ff1ce154f60@astro.rug.nl> <8c18584a-e6a2-6f8d-2191-ba563f3e06ce@astro.rug.nl> Message-ID: Hi Richard, Just saw the patch. Thanks for the quick response. Valentin On 10/06/2016 09:37 AM, Richard Levitte via RT wrote: > It affects all 1.0.2 variants. I've a fix on github: > https://github.com/openssl/openssl/pull/1668 > > Cheers, > Richard > > On Thu Oct 06 07:15:52 2016, valentin at astro.rug.nl wrote: >> Hi, >> >> While playing around with prime number generation I noticed that the >> following generates a core dump. I think this is definitely a bug. >> >> How to reproduce: >> >> $ openssl prime '' >> Segmentation fault (core dumped) >> >> I haven't included any strace output but this can be reproduced by you >> as well. >> >> >> Kind regards, > > > -- > Richard Levitte > levitte at openssl.org > -- Valentin Bajrami Kapteyn Astronomical Institute University of Groningen Postbus 800 NL-9700 AV Groningen The Netherlands Phone: +31-(0)50-3634068 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4699 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From rt at openssl.org Fri Oct 7 11:35:47 2016 From: rt at openssl.org (Wyss, Felix via RT) Date: Fri, 07 Oct 2016 11:35:47 +0000 Subject: [openssl-dev] [openssl.org #4700] fprintf(stderr, ...) in d1_both.c In-Reply-To: <37DB69B3-6B3C-4D81-BF03-738E898E4EB9@inin.com> References: <37DB69B3-6B3C-4D81-BF03-738E898E4EB9@inin.com> Message-ID: Good Morning, Inspecting some code in the OpenSSL DTLS implementation, I noticed three places in the file ?d1_both.c? where error conditions result in an sprintf to stderr: Line 1071 in function dtls1_read_failed Line 1143 in function dtls1_retransmit_buffered_messages Line 1243 in function dtls1_retransmit_message We?re using version 1.0.2j. It should be obvious why it?s rather inappropriate for a library like OpenSSL to write to stderr instead of reporting errors to the application. Even more so considering that OpenSSL already has a sophisticated error reporting mechanism. Regards, --Felix Wyss -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4700 Please log in as guest with password guest if prompted From rt at openssl.org Fri Oct 7 18:01:58 2016 From: rt at openssl.org (noloader@gmail.com via RT) Date: Fri, 07 Oct 2016 18:01:58 +0000 Subject: [openssl-dev] [openssl.org #4701] Some OpenSSL 1.1.0 does not decode FIPS error codes In-Reply-To: References: Message-ID: I'm working with a non-capable version of the library (I need to gt it updated since release): $ openssl version OpenSSL 1.1.0-pre6-dev xx XXX xxxx Looking at a question on another site, the OP provides: With FIPS, compilation goes fine, but generates the following when run: 139686960322208:error:2D0A0086:FIPS routines:FIPS_cipher:selftest failed:fips_enc.c:336: 139686960322208:error:2D0A0086:FIPS routines:FIPS_cipher:selftest failed:fips_enc.c:336: Trying to decode the error on this machine results in: $ openssl errstr 0x2D0A0086 error:2D0A0086:FIPS routines:func(160):reason(134) It seems some versions of the library don't have the necessary error codes available to them. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4701 Please log in as guest with password guest if prompted From rt at openssl.org Mon Oct 10 14:14:57 2016 From: rt at openssl.org (Jose Carlos de Oliveira via RT) Date: Mon, 10 Oct 2016 14:14:57 +0000 Subject: [openssl-dev] [openssl.org #4702] OPENSSL: Linux SLESS11 In-Reply-To: <000701d222df$51833390$f4899ab0$@oliveira@grupoicts.com.br> References: <000701d222df$51833390$f4899ab0$@oliveira@grupoicts.com.br> Message-ID: Hi, I have downloaded and builded last tree openssl versions for linux: 1) openssl-1.0.1u.tar.gz 2) openssl-1.0.2j.tar.gz 3) openssl-1.1.0b.tar.gz I successful followed all steps found at file INSTALL By the way, when I try to use it I have the bellow messages: undefined reference to ?EVP_CIPHER_CTX_init? undefined reference to ?EVP_CIPHER_CTX_cleanup? The OS I?m using is a Linux SLESS11 desktop 32 bits: kernel 3.0.13-0.27-default Regards, Jos? Carlos de Oliveira (Oliveira) Pesquisador / Desenvolvedor - Grupo ICTS Brasilia - DF - Asa Norte SCN Q05 - Brasilia Shopping - Torre Norte Sala 917 Fone:+5561-3246.7089 Cel:+5561-99311.9226 Site: www.grupoicts.com.br -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4702 Please log in as guest with password guest if prompted From matt at openssl.org Mon Oct 10 14:24:44 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 10 Oct 2016 15:24:44 +0100 Subject: [openssl-dev] [openssl.org #4702] OPENSSL: Linux SLESS11 In-Reply-To: References: <000701d222df$51833390$f4899ab0$@oliveira@grupoicts.com.br> Message-ID: On 10/10/16 15:14, Jose Carlos de Oliveira via RT wrote: > Hi, > I have downloaded and builded last tree openssl versions for linux: > 1) openssl-1.0.1u.tar.gz > 2) openssl-1.0.2j.tar.gz > 3) openssl-1.1.0b.tar.gz Any particular reason why you need all three? > > I successful followed all steps found at file INSTALL > > By the way, when I try to use it I have the bellow messages: > undefined reference to ?EVP_CIPHER_CTX_init? > undefined reference to ?EVP_CIPHER_CTX_cleanup? What was the exact command you issued to see the above? EVP_CIPHER_CTX_cleanup() no longer exists in OpenSSL 1.1.0. EVP_CIPHER_CTX_init() is just a macro for EVP_CIPHER_CTX_reset() in 1.1.0. Matt > > The OS I?m using is a Linux SLESS11 desktop 32 bits: kernel > 3.0.13-0.27-default > > Regards, > > > Jos? Carlos de Oliveira (Oliveira) > Pesquisador / Desenvolvedor - Grupo ICTS > Brasilia - DF - Asa Norte > SCN Q05 - Brasilia Shopping - Torre Norte Sala 917 > Fone:+5561-3246.7089 > Cel:+5561-99311.9226 > Site: www.grupoicts.com.br > > > > From rt at openssl.org Mon Oct 10 14:24:46 2016 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 10 Oct 2016 14:24:46 +0000 Subject: [openssl-dev] [openssl.org #4702] OPENSSL: Linux SLESS11 In-Reply-To: References: <000701d222df$51833390$f4899ab0$@oliveira@grupoicts.com.br> Message-ID: On 10/10/16 15:14, Jose Carlos de Oliveira via RT wrote: > Hi, > I have downloaded and builded last tree openssl versions for linux: > 1) openssl-1.0.1u.tar.gz > 2) openssl-1.0.2j.tar.gz > 3) openssl-1.1.0b.tar.gz Any particular reason why you need all three? > > I successful followed all steps found at file INSTALL > > By the way, when I try to use it I have the bellow messages: > undefined reference to ?EVP_CIPHER_CTX_init? > undefined reference to ?EVP_CIPHER_CTX_cleanup? What was the exact command you issued to see the above? EVP_CIPHER_CTX_cleanup() no longer exists in OpenSSL 1.1.0. EVP_CIPHER_CTX_init() is just a macro for EVP_CIPHER_CTX_reset() in 1.1.0. Matt > > The OS I?m using is a Linux SLESS11 desktop 32 bits: kernel > 3.0.13-0.27-default > > Regards, > > > Jos? Carlos de Oliveira (Oliveira) > Pesquisador / Desenvolvedor - Grupo ICTS > Brasilia - DF - Asa Norte > SCN Q05 - Brasilia Shopping - Torre Norte Sala 917 > Fone:+5561-3246.7089 > Cel:+5561-99311.9226 > Site: www.grupoicts.com.br > > > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4702 Please log in as guest with password guest if prompted From rt at openssl.org Mon Oct 10 16:56:51 2016 From: rt at openssl.org (Jose Carlos de Oliveira via RT) Date: Mon, 10 Oct 2016 16:56:51 +0000 Subject: [openssl-dev] RES: [openssl.org #4702] OPENSSL: Linux SLESS11 In-Reply-To: <003401d22314$476d28e0$d6477aa0$@oliveira@grupoicts.com.br> References: <000701d222df$51833390$f4899ab0$@oliveira@grupoicts.com.br> <003401d22314$476d28e0$d6477aa0$@oliveira@grupoicts.com.br> Message-ID: Thank you! Jos? Carlos de Oliveira (Oliveira) Pesquisador / Desenvolvedor - Grupo ICTS Brasilia - DF - Asa Norte SCN Q05 - Brasilia Shopping - Torre Norte Sala 917 Fone:+5561-3246.7089 Cel:+5561-99311.9226 Site: www.grupoicts.com.br -----Mensagem original----- De: Matt Caswell via RT [mailto:rt at openssl.org] Enviada em: segunda-feira, 10 de outubro de 2016 11:25 Para: jose.oliveira at grupoicts.com.br Cc: openssl-dev at openssl.org Assunto: Re: [openssl-dev] [openssl.org #4702] OPENSSL: Linux SLESS11 On 10/10/16 15:14, Jose Carlos de Oliveira via RT wrote: > Hi, > I have downloaded and builded last tree openssl versions for linux: > 1) openssl-1.0.1u.tar.gz > 2) openssl-1.0.2j.tar.gz > 3) openssl-1.1.0b.tar.gz Any particular reason why you need all three? > > I successful followed all steps found at file INSTALL > > By the way, when I try to use it I have the bellow messages: > undefined reference to ?EVP_CIPHER_CTX_init? > undefined reference to ?EVP_CIPHER_CTX_cleanup? What was the exact command you issued to see the above? EVP_CIPHER_CTX_cleanup() no longer exists in OpenSSL 1.1.0. EVP_CIPHER_CTX_init() is just a macro for EVP_CIPHER_CTX_reset() in 1.1.0. Matt > > The OS I?m using is a Linux SLESS11 desktop 32 bits: kernel > 3.0.13-0.27-default > > Regards, > > > Jos? Carlos de Oliveira (Oliveira) > Pesquisador / Desenvolvedor - Grupo ICTS Brasilia - DF - Asa Norte SCN > Q05 - Brasilia Shopping - Torre Norte Sala 917 > Fone:+5561-3246.7089 > Cel:+5561-99311.9226 > Site: www.grupoicts.com.br > > > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4702 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4702 Please log in as guest with password guest if prompted From rt at openssl.org Tue Oct 11 16:15:23 2016 From: rt at openssl.org (Stefan Lahner via RT) Date: Tue, 11 Oct 2016 16:15:23 +0000 Subject: [openssl-dev] [openssl.org #4703] Fix: Merge commit fe2d149 (RT2867: des_ede3_cfb1 ignored "size in bits" flag) to OpenSSL_1_0_2-stable In-Reply-To: <0ea44946-2535-0305-d06e-27057038b004@isis-papyrus.com> References: <0ea44946-2535-0305-d06e-27057038b004@isis-papyrus.com> Message-ID: Hello, the fix for "RT2867: des_ede3_cfb1 ignored "size in bits" flag " (commit fe2d149119063ec3c89fd6db9af8a6970e3e6032) was only committed for master (1.1.0) but not for the still supported 1.0.2 (and 1.0.1) branch. Would it be possible to merge it to OpenSSL_1_0_2-stable (and maybe also OpenSSL_1_0_1-stable)? Regards, Stefan -- Stefan Lahner, ISIS Papyrus Europe AG, DEV, T: +43-2236-27551-336 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4703 Please log in as guest with password guest if prompted From rt at openssl.org Tue Oct 11 16:15:24 2016 From: rt at openssl.org (Simone Sgualdini via RT) Date: Tue, 11 Oct 2016 16:15:24 +0000 Subject: [openssl-dev] [openssl.org #4704] Memory leak in rsa_new/rsa_free In-Reply-To: References: Message-ID: Hi, I'm writing a c++ server application that calls thounsands of times per hour the rsa_new() and rsa_free() openssl functions. After debugging a lot I discovered that "sometimes" (I'm not able to tell a precise number) the rsa_free does not release properly the memory allocated by the rsa_new. In order to prove this I created the simple program below. If i run it, i see the related working set going bigger and bigger, 4KB per second. I'm using the 1.0.2.8 version of libeay32.dll and ssleay32.ddl under windows 7 64 bit. It this a known bug? I'm forgetting something? Thanks in advance Simone Sgualdini Italy //--------------------------------------------------------------------------- #include #ifdef _cplusplus extern "C" { #endif #include #include #include #include #include #ifdef _cplusplus } #endif #pragma hdrstop HMODULE libeay32DLL = NULL; HMODULE ssleay32DLL = NULL; typedef RSA * (CALLBACK *myRSA_new) (void); typedef void (CALLBACK *myRSA_free) (RSA *r); typedef int (CALLBACK *mySSL_library_init) (void); myRSA_new _RSA_new = NULL; myRSA_free _RSA_free = NULL; mySSL_library_init _SSL_library_init; //--------------------------------------------------------------------------- #pragma argsused int main(int argc, char* argv[]) { RSA *rsa; unsigned long count = 0; libeay32DLL = LoadLibrary("libeay32.dll"); ssleay32DLL = LoadLibrary("ssleay32.dll"); if(libeay32DLL && ssleay32DLL) { _RSA_new = (myRSA_new) GetProcAddress(libeay32DLL,"RSA_new"); _RSA_free = (myRSA_free) GetProcAddress(libeay32DLL,"RSA_free"); _SSL_library_init = (mySSL_library_init) GetProcAddress(ssleay32DLL,"SSL_library_init"); } _SSL_library_init(); while(1) { if(++count %100 == 0) // whitout this, I get a stack overflow immediately Sleep(1); *_RSA_free(_RSA_new());* } return 0; } -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4704 Please log in as guest with password guest if prompted From rt at openssl.org Wed Oct 12 16:32:27 2016 From: rt at openssl.org (Kaduk, Ben via RT) Date: Wed, 12 Oct 2016 16:32:27 +0000 Subject: [openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser In-Reply-To: <8a3ef127-d334-bdc8-c1c5-581106ab3387@akamai.com> References: <4c1a748f-94f7-efed-b63b-d4328fc318dd@acm.org> <68593d3e-4f85-baf8-0ed1-5bc305fb44b0@acm.org> <32a7d496-b1fc-b4eb-8165-1fe0b15ab951@akamai.com> <8a3ef127-d334-bdc8-c1c5-581106ab3387@akamai.com> Message-ID: On 10/05/2016 09:15 AM, Kaduk, Ben via RT wrote: > I refactored this stuff a while ago to add a flags field that would > force the temporary read buffer to be allocated from the secure heap; I > should really dig it up and clean it up for master. That's https://github.com/openssl/openssl/pull/1700 , FWIW. -Ben -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4698 Please log in as guest with password guest if prompted From rsalz at openssl.org Wed Oct 12 21:25:45 2016 From: rsalz at openssl.org (Rich Salz) Date: Wed, 12 Oct 2016 17:25:45 -0400 Subject: [openssl-dev] Some policy changes: RT retiring; use GitHub Message-ID: <20161012212545.GA8928@openssl.org> A new blog post gives more details: https://www.openssl.org/blog/blog/2016/10/12/f2f-rt-github/ Effective immediately, RT is being retired, please create GitHub issues instead. The website has been update; the README and CONTRIBUTING files in each release branch will be done soon. There'll be another post on closing old tickets soon. GitHub pull requests are also now the only real way to request changes. In addition, the dev team will use GitHub for all its own PR's. Our private repo will only be done for security fixes that cannot start out immediately "in public." We're excited by these changes, and hope that they provide increased transparency, and increased engagement with our community. We hope you're excited too! -Rich Salz, Dev Team Member From dwmw2 at infradead.org Thu Oct 13 10:45:53 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 13 Oct 2016 11:45:53 +0100 Subject: [openssl-dev] DTLS encrypt-then-mac Message-ID: <1476355553.16627.223.camel@infradead.org> ... is broken in 1.1. We negotiate it, then don't actually *do* it. https://github.com/openssl/openssl/pull/1705?contains a patch to disable it unconditionally for DTLS, on both server and client. In that same PR there's also a patch to actually implement EtM for DTLS ? so that if it ever *stops* being disabled, it would actually work. That second patch is tested (by reverting the first) against a GnuTLS server both with and without EtM. What remains is to have a conversation about how, if ever, we can turn EtM back on again. There are a few mitigating factors: ?? OpenSSL 1.1 is the only version which has this problem. ?? OpenSSL 1.1 supports DTLSv1.2 and AEAD ciphers, which disable EtM. However, the problem still exists for applications using OpenSSL 1.1 with DTLSv1.0, where they *will* end up using a CBC cipher. I don't think it makes much sense just to leave EtM disabled ? depending on how you look at things, that's either not necessary (who cares about OpenSSL 1.1.0[ab]; just upgrade to 1.1.0c!), or not sufficient (1.1.0[ab] are still broken when talking to e.g. GnuTLS anyway, and *everyone* would need to stop doing DTLS+EtM). So I think in the process of typing this mail, I've persuaded at least *myself* that the PR above should be refactored to include *only* the second patch; to *fix* EtM without disabling it. Any dissenting opinions? It really would be nice to have a way to disable EtM voluntarily though; especially for the DTLS_get_data_mtu() test cases that I've added in PR#1666. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From etksubs at gmail.com Thu Oct 13 13:57:07 2016 From: etksubs at gmail.com (etksubs at gmail.com) Date: Thu, 13 Oct 2016 09:57:07 -0400 Subject: [openssl-dev] Accessing the TLS PRF Message-ID: <5358BCC8-C5E4-433D-A9A7-559FE7B26EE2@gmail.com> I see that OpenSSL now supports the exported keying material functionality via SSL_export_keying_material. I also need to access the negotiated TLS PRF, is there a public mechanism for this or do I have to go find the algorithm via the SSL structure and implement the PRF myself? Thanks, Erik From rt at openssl.org Thu Oct 13 16:53:28 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 13 Oct 2016 16:53:28 +0000 Subject: [openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser In-Reply-To: <4c1a748f-94f7-efed-b63b-d4328fc318dd@acm.org> References: <4c1a748f-94f7-efed-b63b-d4328fc318dd@acm.org> Message-ID: no need to keep this ticket, tracking the PR on github. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4698 Please log in as guest with password guest if prompted From rsalz at openssl.org Thu Oct 13 18:42:48 2016 From: rsalz at openssl.org (Rich Salz) Date: Thu, 13 Oct 2016 14:42:48 -0400 Subject: [openssl-dev] OpenSSL RT tickets Message-ID: <20161013184248.GA31459@openssl.org> Hello. This is an automated email; sorry if it's an intrusion or you think it's spam. We are closing old RT tickets that, frankly, we are unlikely to ever get to. For more details, see https://www.openssl.org/blog/blog/2016/10/12/f2f-rt-github/ Anyhow, you reported the following tickets which we are going to close. If you still think it is important for us to consider, please open an issue on GitHub. Don't be shy! We are closing issues based purely on the date, and the fact that despite several passes through our RT tickets, we haven't closed them yet. Replies to this email will go to the openssl-dev list. Thanks very much for all your (prior) interest in OpenSSL, and we're sorry we couldn't get around to fixing everything in a reasonable time. We hope this action will give us better focus on what's important. 2818: [PATCH] Cipher list TLSv1.2 as token; ciphers(1) update From rsalz at openssl.org Thu Oct 13 18:42:48 2016 From: rsalz at openssl.org (Rich Salz) Date: Thu, 13 Oct 2016 14:42:48 -0400 Subject: [openssl-dev] OpenSSL RT tickets Message-ID: <20161013184248.GA31515@openssl.org> Hello. This is an automated email; sorry if it's an intrusion or you think it's spam. We are closing old RT tickets that, frankly, we are unlikely to ever get to. For more details, see https://www.openssl.org/blog/blog/2016/10/12/f2f-rt-github/ Anyhow, you reported the following tickets which we are going to close. If you still think it is important for us to consider, please open an issue on GitHub. Don't be shy! We are closing issues based purely on the date, and the fact that despite several passes through our RT tickets, we haven't closed them yet. Replies to this email will go to the openssl-dev list. Thanks very much for all your (prior) interest in OpenSSL, and we're sorry we couldn't get around to fixing everything in a reasonable time. We hope this action will give us better focus on what's important. 2880: Modification of the capi engine to support loading key from CERT_SYSTEM_STORE_LOCAL_MACHINE 2902: [PATCH] add strings for SSL state related to Next Protocol Negotiation From rsalz at openssl.org Thu Oct 13 18:51:04 2016 From: rsalz at openssl.org (Rich Salz) Date: Thu, 13 Oct 2016 14:51:04 -0400 Subject: [openssl-dev] Closing old tickets Message-ID: <20161013185104.GA32050@openssl.org> Here is the list of old RT tickets that we are closing. We sent email to all of the originators, and it included the following text: If you still think it is important for us to consider, please open an issue on GitHub. Don't be shy! We are closing issues based purely on the date, and the fact that despite several passes through our RT tickets, we haven't closed them yet. 480 Support for local ip address binding for connect BIO's. 1052 openssl ca: generate subjectAltName from config 1416 [PATCH] display UPN if in subjectAltName 1425 Request: make X509_NAME_oneline() use same formatter as X509_NAME_print_ex() 1482 [PATCH] add "ciphertext stealing" support to the EVP library 1518 [PATCH] Securing private RSA keys 1927 [PATCH] openssl ocsp app to autodetect ocsp_uri and issuer 1928 interface bug on Windows 64 1975 [PATCH 13/14] Add support for CPU usage reporting. 2288 [PATCH] Support optional caching of the certificate chain when using external session caching 2298 Build failure on WinCE platform openssl-1.0.0 & 1.0.0a 2330 No debug-mingw build target. just mingw and ming64. 2365 Limitations of ENGINE interface hamper performance on modern hardware 2389 [PATCH] Supporting the -md and -sigopt options in OCSP utility 2408 Enhancement: Additions to timestamp support 2415 possible insignificant bugs in md_rand.c? 2436 pkcs12 enhancements 2463 [PATCH]: OpenSSL 1.0.0d: Add abbility to load server certificate by ENGINE. 2525 [PATCH] Enhancement: Output Format for req Keys 2552 [PATCH] add ability to print root certificate 'issuer' field when using openssl verify 2562 Adding cfi/fpo records to asm (fix backtrace when debugging) 2568 enhancement request: remove ECC engine support's limitation 2574 [PATCH] ECC point coordinate blinding 2582 [PATCH] Efficient and side channel analysis resistant 512-bit and 1024-bit modular exponentiation for optimizing RSA1024 and RSA2048 on x86_64 platforms") 2595 Capitalize X509 subject key STREET according to rfc1779 2599 Support for SHA256 and other MDs in X509 SubjectKeyIdentifier - PATCH 2601 Support for use of sha256 for certificate comparisons - PATCH 2617 pkeyutl fails depending on order of options - PATCH 2635 1/n-1 record splitting technique for CVE-2011-3389 2641 Move the libraries needed for static linking to Libs.private 2659 Problem with DH Exchange with the Oakley Groups (RFC 2412) 2665 s_client support for starttls ldap 2666 Enhancement request/Bug request (bit of both) 2752 objects.txt - update of extended key usage 2753 [PATCH] let application explicitly seed RNG on Unix 2754 Ugly interaction of (openssl x509)'s option -x509toreq with -outform/-text/-noout 2766 TLS 1.2 Compliance - IDEA cipher not disabled 2768 Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE 2770 openssl cryptodev fixes 2784 [PATCH] Eefficient implementations of SHA256 and SHA512, using the Simultaneous Message Scheduling method 2787 [PATCH] enc: compress before compress/base64 is applied 2818 [PATCH] Cipher list TLSv1.2 as token; ciphers(1) update 2833 BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use 2834 bug report: i2d(sign(10)) results in 2573 encoded 2850 [PATCH] Efficient and side channel analysis resistant 1024-bit modular exponentiation, for optimizing RSA2048 on AVX2 capable x86_64 platforms 2851 cms command - Request to handle S/MIME v3.2 mail 2868 [PATCH] CA - change order of gencrl and revoke 2873 -noemailDN only affects Subject DN 2878 [PATCH] s_client -fd 2880 Modification of the capi engine to support loading key from CERT_SYSTEM_STORE_LOCAL_MACHINE 2881 [PATCH] TLS 1 & 1.1 client ciphersuites incorrectly truncated 2884 bug in eng_cryptodev? 2886 openssl cms cmsout serial number output format 2902 [PATCH] add strings for SSL state related to Next Protocol Negotiation 2913 Incorrect salt length indication for RSA-PSS signatures 2924 X509_verify_cert() fails unsafe if check_issued() fails 2927 Domain names that exceed 61 characters 2933 Days wrong if -enddate is passed to openssl ca 2947 leap year date handling 2953 s_server to show connection duration and transfer speed 2957 genpkey for DH key generation does not honor recommended private length 2961 [PATCH] Enhance DH Paramgen to allow setting of "recommended private key size" 2965 [PATCH] dgst: Prepend digest type when reading from stdin, too 2976 openssl x509 is hardcoded to require CSR in PEM format 2987 "openssl speed" bug with the -multi option on multi-core/processor environments 2990 Bug Report:openssl timezone issue 2995 [PATCH] - Added ability to set the iteration count for the enc function of the openssl commandline tool. 3010 Dynamic engine error handling crash 3012 bug report - excess free 3015 Bug with encoding / decoding Implicitly tagged, Optional GENERAL_NAMEs?? 3032 Possible openssl bug - EVP_CIPHER_CTX_iv_length dont report correct value after EVP_CTRL_GCM_SET_IVLEN 3043 Bug Report d2i_PKCS8PrivateKey_bio() doesn't work for DH keys 3045 bug report: AES XTS fails for data unit size > 4KB 3050 x509 PEM certificate input parsing bug 3054 [PATCH] Efficient and side channel analysis resistant 1024-bit and 2048-bit modular exponentiation, optimizing RSA, DSA and DH of compatible sizes, for AVX2 capable x86_64 platforms 3056 Add secure DSA nonce flag. 3064 [PATCH] small_prime_generation 3069 An enhancement to EC key generation to enable compact point representation 3088 openssl crl - verify a CRL signature 3101 [PATCH] Add CMP (RFC 4210) implementation 3113 OpenSSL???s DH implementation uses an unnecessarily long exponent, leading to significant performance loss 3117 [PATCH] A fast vectorized implementation of binary elliptic curves on x86-64 processors 3135 Not all items displayed by list-cipher-commands are in OBJ_sn2nid() 3153 Native issetugid function not used under Solaris 3166 RE: Possible bug/leak in OpenSSL ssl/bio_ssl.c:ssl_ctrl(BIO_CTRL_POP) 3168 PKCS12 bug when using same file for export password and key passphrase 3183 SSL_set_SSL_CTX() should apply more settings from the SSL_CTX being switched to 3222 [PATCH] asn1,evp: Add delete functions for app methods 3226 [PATCH] crypto/srp/srp_lib.c: add/correct some error handling 3240 [PATCH] Efficient 1024-bit and 2048-bit modular exponentiation for AVX512 capable x86_64 processors 3256 [PATCH] RSA512+SHA512 incompatibility results in errors 3258 Enable large Discrete Logarithm Diffie-Hellman groups 3266 [PATCH] Add the SYSTEM cipher keyword 3276 Possible Bug/Opportunity for Improvement when loading ECDSA Key/Cert (Feature Request?) 3282 [PATCH] Fix PKCS8/PKCS12 EncryptedPrivateKeyInfo decryption when password is empty 3349 Bug report: X509_check_akid() identifies non-self-signed certificate as its own issuer 3391 [PATCH] NULL function pointer call in n_ssl3_mac (ssl/s3_enc.c) 3421 [PATCH] return appropriate error if RDRAND not available 3427 crypto/bio/b_print.c: 2 useless if conditions ? 3451 [PATCH] Validity period in hours for x509 3463 [PATCH] Add support of no_application_protocol alert in ALPN protocol selection 3464 openssl s_client waiting for input on Windows 3471 [PATCH] md5-asm-aarch64-29regs 3477 [PATCH] RFC3447 multi-prime RSA functionality and additional acceleration via AVX2 instructions 3491 Cert signing request verification false positive. 3502 nameConstraints bypass bug 3507 [PATCH] Fix memory leaks. 3513 bug report - 1.0.1i x509req challenge password 3514 BUG: openssl fails to downgrade tls protocol version during SSL handshake, when client tries to resume tls1.2 session 3517 Cipher suites should be case-insensitive 3518 Move RC4 and MD5 ciphers to LOW, post-1.0.2 3523 bug report: s_client writes to STDERR 3529 [PATCH] ASN1 generation: allow bit strings ending with zero regardless of length 3553 AES Key Wrapping with Inverse Functions 3555 OCSP Stapling Enhancement (diff included) 3561 bug report: openssl prints wrong pre_master secret in debug mode 3578 Bug report, verify using CApath not working any more 3590 [PATCH] Fast modular exponentiation with the new VPMADD52 instructions 3591 [PATCH v2] Implement Maximum Fragment Length Negotiation (RFC 4366). 3598 Windows Phone & OpenSSL. 3604 [PATCH] User can specify the public exponent in genrsa 3624 Unify SSL_CONF_* interface to be SSL_CONF_CTX_*, with patch against [master/33d5ba8] 3627 Enhancement request: add more "Protocol" options for SSL_CONF_CTX 3632 Enhancement request: CONF_modules_load_file(): please include filename in error message 3633 Enhancement request: CONF_modules_load_file(): please add a CONF_MFLAGS_LOAD_USER_FILE 3636 BIO_read() (enc_read()) with 0 length 3641 [PATCH] EC_KEY_generate always overwrites private key All OS 1.0.1j 3644 Encoding of EC private key is broken in all version 3648 BUG: Undefined behavior in easy_tls.c 3649 Unnecessary engine lookup in EVP_DigestInit_ex 3655 Inconsistency in d2i_SSL_SESSION 3659 BUG: EVP_DigestVerifyFinal does not take a const pointer 3660 Memory leak in s_server.c 3667 [PATCH] Faster GLV elliptic curves 3679 Memory leak in ssl_cert_dup (ssl/ssl_cert.c) 3681 function pointers in BIO set_callback 3697 Bug in s_client with loading of default certificates 3698 Bug: Ref count issue in SSL_new may cause a crash in SSL_free if REF_CHECK is defined 3702 openssl verify improvement 3712 TLS Renegotiation with Java is broken 3721 [PATCH] Additional checking of self-signed certificates 3729 [PATCH] Add support for iovec-based IO in OpenSSL 3736 [PATCH] fix parallel install with dir creation 3737 [PATCH] fix parallel generation of obj headers 3741 [PATCH] Better side-channel security for ECC table lookups 3743 [PATCH] Make it possible to only install libs 3746 -nameopt utf8 alone does not work , problem is tht crypto/asn1/a_strex.c returns -1 3748 do_name_ex in crypto/asn1/a_strex.c does not treat case 0 in XN_FLAG_SEP_MASK 3762 bug report: x509 -x509toreq does not copy extensions 3763 bug report: pkeyutl option order 3764 Missing message Alert on ssl23_get_server_hello negotiation failure 3765 Crash in PEM write functions with generated EC_KEY on Windows 3791 Problems configuring for OSX 10.8.5 (x86_64) 3794 Missing symbols for padlock_aes_block during link in Master 3797 [PATCH] evp: fix memory corruption on absent payload From rt at openssl.org Thu Oct 13 18:51:33 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 13 Oct 2016 18:51:33 +0000 Subject: [openssl-dev] [openssl.org #2818] Resolved: [PATCH] Cipher list TLSv1.2 as token; ciphers(1) update References: Message-ID: According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2818 Please log in as guest with password guest if prompted From rt at openssl.org Thu Oct 13 18:51:37 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 13 Oct 2016 18:51:37 +0000 Subject: [openssl-dev] [openssl.org #2902] Resolved: [PATCH] add strings for SSL state related to Next Protocol Negotiation References: Message-ID: According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2902 Please log in as guest with password guest if prompted From rt at openssl.org Thu Oct 13 18:51:36 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 13 Oct 2016 18:51:36 +0000 Subject: [openssl-dev] [openssl.org #2880] Resolved: Modification of the capi engine to support loading key from CERT_SYSTEM_STORE_LOCAL_MACHINE References: Message-ID: According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2880 Please log in as guest with password guest if prompted From matt at openssl.org Thu Oct 13 22:48:50 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 13 Oct 2016 23:48:50 +0100 Subject: [openssl-dev] DTLS encrypt-then-mac In-Reply-To: <1476355553.16627.223.camel@infradead.org> References: <1476355553.16627.223.camel@infradead.org> Message-ID: <5eadf0d4-a5bd-b94f-510e-b599b9f48cc9@openssl.org> On 13/10/16 11:45, David Woodhouse wrote: > ... is broken in 1.1. We negotiate it, then don't actually *do* it. > > https://github.com/openssl/openssl/pull/1705 contains a patch to > disable it unconditionally for DTLS, on both server and client. > > In that same PR there's also a patch to actually implement EtM for DTLS > ? so that if it ever *stops* being disabled, it would actually work. > That second patch is tested (by reverting the first) against a GnuTLS > server both with and without EtM. > > What remains is to have a conversation about how, if ever, we can turn > EtM back on again. > > There are a few mitigating factors: > ? OpenSSL 1.1 is the only version which has this problem. > ? OpenSSL 1.1 supports DTLSv1.2 and AEAD ciphers, which disable EtM. > > However, the problem still exists for applications using OpenSSL 1.1 > with DTLSv1.0, where they *will* end up using a CBC cipher. > > I don't think it makes much sense just to leave EtM disabled ? > depending on how you look at things, that's either not necessary (who > cares about OpenSSL 1.1.0[ab]; just upgrade to 1.1.0c!), or not > sufficient (1.1.0[ab] are still broken when talking to e.g. GnuTLS > anyway, and *everyone* would need to stop doing DTLS+EtM). > > So I think in the process of typing this mail, I've persuaded at least > *myself* that the PR above should be refactored to include *only* the > second patch; to *fix* EtM without disabling it. > > Any dissenting opinions? Not from me. It's broken. Lets fix it. Matt > > It really would be nice to have a way to disable EtM voluntarily > though; especially for the DTLS_get_data_mtu() test cases that I've > added in PR#1666. > > > From dwmw2 at infradead.org Fri Oct 14 00:27:05 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 14 Oct 2016 01:27:05 +0100 Subject: [openssl-dev] DTLS encrypt-then-mac In-Reply-To: <5eadf0d4-a5bd-b94f-510e-b599b9f48cc9@openssl.org> References: <1476355553.16627.223.camel@infradead.org> <5eadf0d4-a5bd-b94f-510e-b599b9f48cc9@openssl.org> Message-ID: <1476404825.16627.249.camel@infradead.org> On Thu, 2016-10-13 at 23:48 +0100, Matt Caswell wrote: > > > Any dissenting opinions? > > Not from me. It's broken. Lets fix it. Thanks. https://github.com/openssl/openssl/pull/1705 updated accordingly. With that fixed, I think https://github.com/openssl/openssl/pull/1666 is now ready to be merged too (it contains the fixes from #1705, which it depends on). The only bit I wasn't sure about in #1666 was the addition of the DTLS cipher tests to ssl_test_old ? which is redundant now I've written a completely new test to do an MTU torture test on every cipher suite (both with an without EtM, for CBC suites). So I took it out. But I've submitted that part separately anyway, since part of it might be useful ? in order for the test recipe to *get* the list of DTLS ciphersuites, I had to make 'openssl ciphers DTLSv1' work. Which might be worth keeping, although it wants careful review: https://github.com/openssl/openssl/pull/1710 -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From martin at lispworks.com Mon Oct 17 14:49:16 2016 From: martin at lispworks.com (Martin Simmons) Date: Mon, 17 Oct 2016 15:49:16 +0100 Subject: [openssl-dev] [openssl.org #4704] Memory leak in rsa_new/rsa_free In-Reply-To: (message from Simone Sgualdini via RT on Tue, 11 Oct 2016 16:15:24 +0000) References: Message-ID: <201610171449.u9HEnGxV027319@higson.cam.lispworks.com> I think your problem (and the stack overflow) is caused by using "CALLBACK" in the 3 function typedefs. Try using __cdecl instead of CALLBACK. __Martin >>>>> On Tue, 11 Oct 2016 16:15:24 +0000, Simone Sgualdini via RT said: > > > Hi, > > > I'm writing a c++ server application that calls thounsands of times per > hour the rsa_new() > and rsa_free() openssl functions. > > After debugging a lot I discovered that "sometimes" (I'm not able to > tell a precise number) the rsa_free > does not release properly the memory allocated by the rsa_new. > In order to prove this I created the simple program below. If i run it, > i see the related working set > going bigger and bigger, 4KB per second. > > I'm using the 1.0.2.8 version of libeay32.dll and ssleay32.ddl under > windows 7 64 bit. > > It this a known bug? I'm forgetting something? > > Thanks in advance > > Simone Sgualdini > Italy > > > //--------------------------------------------------------------------------- > > #include > > > #ifdef _cplusplus > extern "C" > { > #endif > #include > #include > #include > #include > #include > #ifdef _cplusplus > } > #endif > #pragma hdrstop > > HMODULE libeay32DLL = NULL; > HMODULE ssleay32DLL = NULL; > > typedef RSA * (CALLBACK *myRSA_new) (void); > typedef void (CALLBACK *myRSA_free) (RSA *r); > typedef int (CALLBACK *mySSL_library_init) (void); > > myRSA_new _RSA_new = NULL; > myRSA_free _RSA_free = NULL; > mySSL_library_init _SSL_library_init; > > //--------------------------------------------------------------------------- > > #pragma argsused > > int main(int argc, char* argv[]) > { > RSA *rsa; > unsigned long count = 0; > > libeay32DLL = LoadLibrary("libeay32.dll"); > ssleay32DLL = LoadLibrary("ssleay32.dll"); > > if(libeay32DLL && ssleay32DLL) > { > _RSA_new = (myRSA_new) > GetProcAddress(libeay32DLL,"RSA_new"); > _RSA_free = (myRSA_free) > GetProcAddress(libeay32DLL,"RSA_free"); > _SSL_library_init = (mySSL_library_init) > GetProcAddress(ssleay32DLL,"SSL_library_init"); > } > > _SSL_library_init(); > > while(1) > { > > if(++count %100 == 0) // whitout this, I get a stack overflow > immediately > Sleep(1); > > *_RSA_free(_RSA_new());* > } > > return 0; > } > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4704 > Please log in as guest with password guest if prompted > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From ca+ssl-dev at esmtp.org Fri Oct 21 03:01:38 2016 From: ca+ssl-dev at esmtp.org (Claus Assmann) Date: Thu, 20 Oct 2016 20:01:38 -0700 Subject: [openssl-dev] "typo" in SSL_CTX_set_min_proto_version.pod Message-ID: <20161021030138.GA20723@x2.esmtp.org> Seems there are 4 functions, so don't explicitly mention the number: diff --git a/doc/ssl/SSL_CTX_set_min_proto_version.pod b/doc/ssl/SSL_CTX_set_min_proto_version.pod index 8878514..3e9fe80 100644 --- a/doc/ssl/SSL_CTX_set_min_proto_version.pod +++ b/doc/ssl/SSL_CTX_set_min_proto_version.pod @@ -34,7 +34,7 @@ B for DTLS. =head1 RETURN VALUES -Both functions return 1 on success and 0 on failure. +These functions return 1 on success and 0 on failure. =head1 NOTES From rsalz at akamai.com Fri Oct 21 10:17:20 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 21 Oct 2016 10:17:20 +0000 Subject: [openssl-dev] "typo" in SSL_CTX_set_min_proto_version.pod In-Reply-To: <20161021030138.GA20723@x2.esmtp.org> References: <20161021030138.GA20723@x2.esmtp.org> Message-ID: <54d28a8b6e53490fb953629593b86dad@usma1ex-dag1mb1.msg.corp.akamai.com> https://github.com/openssl/openssl/pull/1762 From bkaduk at akamai.com Fri Oct 21 23:00:36 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 21 Oct 2016 18:00:36 -0500 Subject: [openssl-dev] Why is libefence needed for 32-bit debug (linux-elf) builds? Message-ID: During some testing today, I ended up trying to do a build of 1.1.0b configured for linux-elf --debug (with no-asm to work around some issue that was not my primary concern at the time), which failed due to a missing -lefence. The corresponding linux-x86_64 build on the same machine succeeds. It seems that this happened as a result of commit 7910044064e106073c097a6940d25fe36401266b, "Find debug- targets that can be combined with their non-debug counterparts", which ended up moving the contents of the debug-linux-elf target from 90-team.conf to 10-main.conf where the linux-elf target lives. Having electric fence enabled in a team-only configuration seems reasonable, but it's less clear that it's the right thing to do for a target in 10-main.conf, even when --debug is used. (There is an explicit debug-linux-elf-noefence target in 90-team.conf, for what it's worth.) Should the efence build be moved to a different target in 90-team.conf leaving the debug-version of linux-elf buildable in a more generic set of environments? -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Oct 21 23:14:43 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 21 Oct 2016 23:14:43 +0000 Subject: [openssl-dev] Why is libefence needed for 32-bit debug (linux-elf) builds? In-Reply-To: References: Message-ID: <21c4f180c97a4da6b716f852ac4d405c@usma1ex-dag1mb1.msg.corp.akamai.com> Is electric fence even available any more? Just kill it. From levitte at openssl.org Fri Oct 21 23:13:30 2016 From: levitte at openssl.org (Richard Levitte) Date: Sat, 22 Oct 2016 01:13:30 +0200 (CEST) Subject: [openssl-dev] Why is libefence needed for 32-bit debug (linux-elf) builds? In-Reply-To: References: Message-ID: <20161022.011330.734091478303774540.levitte@openssl.org> Actually, -lefence comes from much further back in time. If you look at the configuration strings in Configure in version 1.0.2, you'll find debug-linux-elf, with that dreaded -lefence. Back in that version, ./config treats -d by prefixing the desired target with 'debug-', so 'debug-linux-elf' is the official debugging target for 'linux-elf'. This was transferred to the new configuration hash by merging all debug-FOO targets with their corresponding FOO targets and make debugging and non-debugging variants of a number of settings. Not sure that I remember if or why 'debug-linux-elf' ended up in 90-team.conf... Anyway, I assume that what you're really asking is if libefence should be viewed as antique. If nothing else, we could be a bit more consistent (there is a lack of consistency between configuration targets!)... Me, I have no issues, removing -lefence from the debug settings of 'linux-elf' and replace 'debug-linux-elf-noefence' with 'debug-linux-elf-efence'. Cheers, Richard In message on Fri, 21 Oct 2016 18:00:36 -0500, Benjamin Kaduk said: bkaduk> During some testing today, I ended up trying to do a build of 1.1.0b bkaduk> configured for linux-elf --debug (with no-asm to work around some bkaduk> issue that was not my primary concern at the time), which failed due bkaduk> to a missing -lefence. The corresponding linux-x86_64 build on the bkaduk> same machine succeeds. bkaduk> bkaduk> It seems that this happened as a result of commit bkaduk> 7910044064e106073c097a6940d25fe36401266b, "Find debug- targets that bkaduk> can be combined with their non-debug counterparts", which ended up bkaduk> moving the contents of the debug-linux-elf target from 90-team.conf to bkaduk> 10-main.conf where the linux-elf target lives. Having electric fence bkaduk> enabled in a team-only configuration seems reasonable, but it's less bkaduk> clear that it's the right thing to do for a target in 10-main.conf, bkaduk> even when --debug is used. (There is an explicit bkaduk> debug-linux-elf-noefence target in 90-team.conf, for what it's worth.) bkaduk> bkaduk> Should the efence build be moved to a different target in 90-team.conf bkaduk> leaving the debug-version of linux-elf buildable in a more generic set bkaduk> of environments? bkaduk> bkaduk> -Ben From levitte at openssl.org Fri Oct 21 23:21:55 2016 From: levitte at openssl.org (Richard Levitte) Date: Sat, 22 Oct 2016 01:21:55 +0200 (CEST) Subject: [openssl-dev] Why is libefence needed for 32-bit debug (linux-elf) builds? In-Reply-To: <21c4f180c97a4da6b716f852ac4d405c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <21c4f180c97a4da6b716f852ac4d405c@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20161022.012155.944333974616925164.levitte@openssl.org> In message <21c4f180c97a4da6b716f852ac4d405c at usma1ex-dag1mb1.msg.corp.akamai.com> on Fri, 21 Oct 2016 23:14:43 +0000, "Salz, Rich" said: rsalz> Is electric fence even available any more? Just kill it. I just looked around, and it looks like you're right. Awright, I'll do the kill. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Fri Oct 21 23:25:48 2016 From: levitte at openssl.org (Richard Levitte) Date: Sat, 22 Oct 2016 01:25:48 +0200 (CEST) Subject: [openssl-dev] Why is libefence needed for 32-bit debug (linux-elf) builds? In-Reply-To: <20161022.012155.944333974616925164.levitte@openssl.org> References: <21c4f180c97a4da6b716f852ac4d405c@usma1ex-dag1mb1.msg.corp.akamai.com> <20161022.012155.944333974616925164.levitte@openssl.org> Message-ID: <20161022.012548.1383862012016022896.levitte@openssl.org> In message <20161022.012155.944333974616925164.levitte at openssl.org> on Sat, 22 Oct 2016 01:21:55 +0200 (CEST), Richard Levitte said: levitte> In message <21c4f180c97a4da6b716f852ac4d405c at usma1ex-dag1mb1.msg.corp.akamai.com> on Fri, 21 Oct 2016 23:14:43 +0000, "Salz, Rich" said: levitte> levitte> rsalz> Is electric fence even available any more? Just kill it. levitte> levitte> I just looked around, and it looks like you're right. Awright, I'll levitte> do the kill. https://github.com/openssl/openssl/pull/1768 Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Fri Oct 21 23:26:36 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 21 Oct 2016 23:26:36 +0000 Subject: [openssl-dev] anonymous bug report Message-ID: <95f5d2a40a434b418719d2b6009513c4@usma1ex-dag1mb1.msg.corp.akamai.com> (came in via mixmaster anonymous remailer) $ openssl version OpenSSL 1.0.2j 26 Sep 2016 Typo in NEWS file: Major changes between OpenSSL 1.0.2g and OpenSSL 1.0.2h [3 May 2016] ... o Remove LOW from the DEFAULT cipher list. This removes singles DES from the default. Replace "singles" with "single". By the way, a huge thank you to everyone writing/maintaining such a great and important piece of software. Our lives (physical, financial, social) literally depend on it! -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssx at av8n.com Fri Oct 21 23:22:19 2016 From: ssx at av8n.com (John Denker) Date: Fri, 21 Oct 2016 16:22:19 -0700 Subject: [openssl-dev] status of libefence (electric fence) In-Reply-To: <21c4f180c97a4da6b716f852ac4d405c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <21c4f180c97a4da6b716f852ac4d405c@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <329d9182-ffae-224d-843d-f3db5d1598ef@av8n.com> On 10/21/2016 04:14 PM, Salz, Rich asked: > Is electric fence even available any more? It's bundled with current Debian and Ubuntu. >From the README: "This version should run on all systems that support POSIX mmap() and mprotect(). This includes Linux, Unix, and I think even BeOS." From anirudhp at avaya.com Mon Oct 24 06:02:15 2016 From: anirudhp at avaya.com (Patel, Anirudh (Anirudh)) Date: Mon, 24 Oct 2016 06:02:15 +0000 Subject: [openssl-dev] Query related to API SSL_set_SSL_CTX Message-ID: Hi Guys, I have create a shared ssl ctx as below: boost::shared_ptr SharedSslCtx; mSslCtx = SharedSslCtx(SSL_CTX_new(meth), ctx_deleter) I have a copy of the above mSslCtx in a separate class under another shared pointer mCtx. Once I get the incoming TLS connection an SSL object is created as below: mSSL = SSL_new(mCtx.get()); Now, after every CRL I download SSL_CTX is updated again (mSslCtx = old one is deleted and a new is created). But, currently I do not update mCtx object of the other class. To update mCtx and the SSL object with the newly updated SSL_CTX I am doing the following: mCtx = mSslCtx; SSL_set_SSL_CTX(mSSL, mCtx.get()); I am in no desperate need of updating mCtx but just to be in sync I did the above. Could you please let me know if using the above API might have some adverse effects or should I skip using it or is there a better way to do it? Thanks & Regards, Anirudh Patel -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory at lukasa.co.uk Mon Oct 24 15:50:22 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Mon, 24 Oct 2016 16:50:22 +0100 Subject: [openssl-dev] Possible OpenSSL security report Message-ID: <339A03ED-0E03-4132-862D-8F665ED1C0D9@lukasa.co.uk> -----BEGIN PGP MESSAGE----- hQIMA3D+F/imQ+FbARAA1J1imWLDHkOHslC2nHB5vI7fAltwGuoeTOAqTj2hL2AH 27LN0f1D166u36pohrI722oHTBkwUgKWIn54qciCQxCpxu8uOJAa20IrWbtOZZYI A1fyKMOJ1S0NODgcWtoTLK2PFhKJFHtioBeNt5qlThqiUwZYMuu+QKp0Nx4uL0VB rwPYOAVoqiFGpzCLc1BRHO5ZP664ytF0i05adRGMotFwqeO6aayCduT6sMPmriuQ +hLGEdlgTlsQ2EynjtadCPqENJLOAWxW/LCFbTP+fVjuCawtW3uwyaB8+I7qFg+3 ySQtt+LMMCTU1mzfxGoCsB5t87k15uXtBK0BhGUBY4M4RlTs/fcAByoYJrrO90LZ 063AsIyTwpOtRtsFysQGLE1ZW2xHV4j3sThzfR3xAtiAxqTqorqrOwg0HG/3AqWp qEhb6U0ukmfcz1k3IMRiUhaZmUirlCB/EDGdz7s/lUwfu18Mya5SXmAMyLs5Gpmt V5YZ/1fUUFfCi5joXVQNunWWZcF3LWVgNNB/v9EFS4nlUQluKhmZJw8mUforljns JxoZA/kCZFQ67KK8YIttowXHGsWMqVwrHkZFtk01mczc+QNInr4QRiM8T6cb/gt6 q2ORtjFJKuy3oUYpd+aigu+uK/VxCITkIfLrME7bjdH5nfEwMxxXufhvwCxdtUWF AgwDbwJGFC5K/iABD/4rs5iZfJi8iN7OGSlvXiQqIK7kwQcsK9sxJoNmQlu7juN1 ViJli+g+LjmJcw0x8bPhGPlb2igZ1yI4zDPOonGZcTil3P1Zh7QBPalhkX0PAyOv ++pO1bXjBbuWWqEcEvjOe3Ky/uCOdR1Tm+VglmYY5OqDghHUfI+soLf7tGYKupfm QVXVAO+bwbtnUxrY5ULtrmylMmFi8v9Qi5lDe6cvaoMf7mMbwiYI4a9GUOWjmOVE aA2tWIqIja4Mho9oiYCYlTjdR5c3mH5XPXl5OsGIC+4ltPQXUIWoVpstFVf4JFn/ vHbnxygRb8opHPjEYSahAhlMzYurjbQfBa4wrBH1lrTgpLsFKW3ZPISFS/VbN7pn WZvUhAKWkK2bgm4yCaxTNKYqh9ReB/f3mIRmC9Hqyz3L6hUOjxU+534I1/ALfeLE AhSsKtUtT40XHR2cWtkufO9WzU682rND/utFfhfk3+plYRGbLVK0wf9cyJfSnkvP V/xAiMPFo4DHa9SDSu+Kx5pqQ4/2RsHjnzoDpG5DXGRtPdbZSW9e+bhnpqMilyoj ydoQaJntk784nAOXcXNmRkTztAbLV3ixI+g2LXDs66MDZIK6JB8PzJroYCIiwOhX hbIrXbnE5foSmvpO708IRa2lZ0pUw8p9V0SMTQjqjhfCa5UMxfcAw4M4Zq+XVtLr AViQS1uoIpx9K0qFuiSlrXYXO+d8V/FlNabaI9v+440oCBR3A/Bk7lnZni0KlM9z X5D8p0knLImEtSU5E3FDvzf5MVnCIg+OquSYugUkeek1xZ7lTe8zUf4q34ZHdMdb Z8SxINwDzaT38UhnEmDESQPj1xdPVYVDlnEmVclppRdBnsTMOxSGcW/rqXAYYV3w j+AMasIeeLZz5nOkbGP64HffAGQndT8OhRQ3I15cARnfD6lVGchUkM4QnyS0um4k wKDsjawZJGIerGaw+S7HZb18SjW1L4P/O1qZKlh3s5FGJ1HhR1Jdc6IWmEJNmyH6 dRjuYFHerplxQmweqW3JhxFvSOpNqPxSR3UutGzDgZrKUIDyW0ovHwjQ3jVzVZyF k2SmxxmpsrJCBlkQOgWLVh1BjI8LQ0zw/ZIxWIKSILXQoFjRHjm1xkUkzLkmcd6X me8pvp6wd8kQLutHTe8hUhgjX/c9LI4g3XV04++rdzx4es9SyVIBn4f2KhoEHLU+ F98iE1B3L1lXhnesstGdSmOsurjL5M+OoyZFXWZC++ycIvT6S84B/o5pHnNILHKm 9pzjfC38AT1j/JGS8PxwONWX6SAV17ugRuEF9efKeXgGs2h9/MgK6ViXY13tL/11 cLKXHMcUh0Ft3rnfoXYpT/guxqWS85E8xdDe3mm9KsNThemAm/7VNDVS8OGYZCCx M8tVJSPDzNOkNTOYiRrk+DbsjfB1sB2oHVUiFqHff30uDIttsbaXTn3DESlD2ylJ QQGmxYJt8stI1Msj34UShmZracWA16tJJwLyPUvus9L1qcBU1uslZv0Czvj8Ox6M dKsFwh6W4Q3xJqADTFA3N2l1E3OmRbjQPa7df2iZl6a5u88ZYISYgz2aAi5DTxZL LUMV+y20LyewdnNsRbruByamhajd5COFLM7CLRJplQAKCBwFC54hUce9RCeeG7gX T/Ry4fG7WyGCu/FrY8p7Dd+pDLZ1fhAiOVW+aYIrpRgd9nWjMGEmR7paXHC4olDo 5yIaADIj/oP4tvWpkpu3sx1z0tFlJUnK7sJXoaEQ80HZFsBAWXXux1slifat6vEs KLkqAJ4ongpgpcGnii5XlHxjfExp9hKgBYqcd9sTM8c9uCNR3Ok+TPYtxY7btqPs HqjqIjHvoEbJYPayPBPVZ3GTK1NkxWmVpGku185VNZRKnAZqmWC/We5ep9CdFn3E Eh02+iwz0FhdJ15F8HkWz83atZVLyXh2cNEyb7L+yFROtrX5z5mHCkoeaDCgXnuQ 95AAJzNiBJ/5lSwcp5LXgsvnejTEmrzK6Sw7+ou457BuvYFK5cjTjmcZ5cjYLRpc 6ZI0K+bkOQq5XdiqRIuS+zk9N7Pf4w6hspsWIxb9EbRTtPdPl8N9ZMnNS9CbrAcm pvB6LEJXckuxSsAC6bIkw7LxDqwZc2LJYkj8CZ+t5uE4aWVYDFLBaF3JQkgWber0 c946dr0c7cm8rz5iPZGdbXZgAOMXXz2Ose09YdQyv2iQAaO6bDtJJxbhb8MtHCEU pzPsy52W+2pzkBNVDug1tmI967gZ8SyrWDzIna193LrvDTdiMl3TxALTfMNJPpXl q3IVn8pzVoexZpEfknuHzEhKhRWGW7Oy+Bg6tOS72To2JcS2iCYpT1TyWba08aBK hrDj0Ho7JovcEH799dcRysogXM9KDdc9MLDVSQ46dqlDKc2D5tPjh9bIWS5Ja7Y4 X72ODLUgrZ2XM/5yKUZK1xqvlofVmrtrHI1IthtuqvF2FuMoIDhRiaKLR7gXkhDN fLt1BoIpByEaPBMR6KjNzvLb5T2uAdC8cZEGbgOIjRUZu7QoTeVKNMUi0spMNv7R eo45d8uKN10Y4/69r/lZFdHaitJ94cGcA2ueNwc4EsvHVw7gWtr1yD/K1krJWH/V LFoMNDBav2CYCm0/XVE/JR3NJV8FyVfuVgzEtzOFHXobB1kO65dCl2/nEtn+PZCm yiezDA62iloROZZfeLAjYnFBJKmor3GYXyrxhJL95ZU8vGTAGLzE6FkPzLOt8KmB yg3onN+QBnn3dsmQQ2qsEqm3lry1C71tTSY5hjF+Wd6yqlfppw1a0FC92D429g8d ShVuDJlrJrOwefHh0sjJllIy6BiGomh5DHfb3P+Jj+7/8gBROsdMwqVhMu0OHVAs s49AqDPAyKAlsUlFK3g3GKePLmHHw0fElq+uZGKd5Ff3iISemblcziE2XX2Sb0e+ FdTpq8WIWRvzeWWPXfjeBZTeRrEVTcnd885mih8JF+T7A0o4HSvjO0YtgMS9Xg9+ gJAT5ZHfhrCB7qBufmbepm9o6FDSfhsxT1yfBugu9PdMxpRPpWhPzITZMA7hw94L b6bM4TJ2ikN2tmIYTpdbNNymb53bHIEtrBR0Dg3m5uCj0k9Fz+AZZDUroBvtVL7w MXD6pi7hBzNBWI1XwS1dlRxNxC2hxHV3oS8HgHtWgQyKd9JXYqRZxQG8yyS3tLuF ZnlhBN9lfJ1liGTqVHUOi7tgg+rkDEZ20+ebYOb3wzZ9xyJPFR7vB4TAVBoAx0pt 3KQ4rw/nMyL9OpIJXViQIBtd5Mo75vlXyaG1/4qh3+c4beEwuBpCC7gxFJ/Nx51l X+jorroZnY3k4gfQTZ3l+oAg1me5tZwe6u4smv3w2DSIPcumjwqWLNWFP65/eIcI HZ8Sp6BB7ObRBywpN8wjGGyIsOw1qzyCmp60z3z7DfXpFMu0skGDR7GbMjWmg6Eg bxTa9jXinFnzxow2R+DO8YDXAeZa3m6t0KGDE9nCGHrj2QXPyTlIo5aW42LgHbbP pRlP4c9Q+z87YWNaJ/9h1UGRNff4IiCOOyR2drYLEEFLPzOqLa64N937+R1BfBEC 77f2JW1vqSUUXtVTMjnaJLh7BSF26DnzXAF5V+LeiPS9O+dR94eLnGhfiDnaXlze ywigTrE91vDSFLXJluHI/6HzkyzfsK0aWqakZAL6K9wX3DTc0lEukX99LEyTSuFj i5r2JJ5HAHKewrzjwni5qY7kBK/TqRGJMslCU9JHodPe7F1sisoKTBHrrEn/p3KQ OmqbuDaFMO3gUQoeHsVyR2U9M0uTFeumwc9LE9wBCdUnDW6GVZmuXwTzPopU1MUf Fq5O9W0PXIxUia7BOa+0yLgvduYAsm6ShuCG7tuIy+2iRE7SznGQfjm/RPtMnXhr 7MoFUQ4Yet85IuIV5sL21nJ/FH0kneQ4MGCX6dvY7w5S3E3IOiImQV/FUTufDUDi 0iojYi2cWGXc5SKOFabXBbUzJT5VgHvN0JWmZ0VfbX/VX3ycGflmi926XXJhqJU4 i48RFa+szTXUg6J29OKxTEZ1o3KRmSFCKo4qUd/tKXkMFsUKZF+LFeAoEeUUq/jK 4jocqJ93OoUnH89etQbFPBTAG3px/QS0AZa6YQbrDSOGBDGuuPCLtiJeyXVIX+w9 L800upCCraYd7v7QUWChznBu1hZWyfZIy9uqwlApGEBLNY8k1zlrgTGvVjunkb4v sDcY8OrPkVemeQaqzqnO1EYaH1ElTXhNT/79q7Eqn2GST8x358nqWilYj50CijL3 0djtd3r4fw4+hjUFvGzJx80vlwUPqWknI5ajipml5w18yercYW8lFMztFFgEttSS RBsZ83e+S7CCDu29t/J/61Guhx1vwsPhFIU8oV7Q5jRKsFQZxcrY8DDlzISq0w== =sZnA -----END PGP MESSAGE?? From anirudhp at avaya.com Tue Oct 25 05:45:50 2016 From: anirudhp at avaya.com (Patel, Anirudh (Anirudh)) Date: Tue, 25 Oct 2016 05:45:50 +0000 Subject: [openssl-dev] Query related to API SSL_set_SSL_CTX In-Reply-To: References: Message-ID: Guys, any suggestions that you might have :) Regards, Anirudh From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Patel, Anirudh (Anirudh) Sent: Monday, October 24, 2016 11:32 AM To: openssl-dev at openssl.org Subject: [openssl-dev] Query related to API SSL_set_SSL_CTX Hi Guys, I have create a shared ssl ctx as below: boost::shared_ptr SharedSslCtx; mSslCtx = SharedSslCtx(SSL_CTX_new(meth), ctx_deleter) I have a copy of the above mSslCtx in a separate class under another shared pointer mCtx. Once I get the incoming TLS connection an SSL object is created as below: mSSL = SSL_new(mCtx.get()); Now, after every CRL I download SSL_CTX is updated again (mSslCtx = old one is deleted and a new is created). But, currently I do not update mCtx object of the other class. To update mCtx and the SSL object with the newly updated SSL_CTX I am doing the following: mCtx = mSslCtx; SSL_set_SSL_CTX(mSSL, mCtx.get()); I am in no desperate need of updating mCtx but just to be in sync I did the above. Could you please let me know if using the above API might have some adverse effects or should I skip using it or is there a better way to do it? Thanks & Regards, Anirudh Patel -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Thu Oct 27 16:04:13 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 27 Oct 2016 11:04:13 -0500 Subject: [openssl-dev] per-file or -module flags in build.info? Message-ID: <9c8b7283-745f-1b33-dab3-b79cfca84a73@akamai.com> Is it possible in the unified build system to apply certain compiler (or linker) flags only to a specific file or set of files? This could make some scenarios easier when one is willing to patch the tree (e.g., build some things with -O3 and others with -O0 -ggdb3). Given that the unified build outputs a single unified Makefile to build everything, it seems unlikely, but I just wanted to check. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Oct 27 16:42:50 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 27 Oct 2016 18:42:50 +0200 (CEST) Subject: [openssl-dev] per-file or -module flags in build.info? In-Reply-To: <9c8b7283-745f-1b33-dab3-b79cfca84a73@akamai.com> References: <9c8b7283-745f-1b33-dab3-b79cfca84a73@akamai.com> Message-ID: <20161027.184250.1069686233325744847.levitte@openssl.org> The only way is to use raw lines for your platform, something like this for Unix: OVERRIDES=foo.o BEGINRAW[Makefile(unix)] foo.o: foo.c $(CC) $(CFLAGS) -O3 -c -o $@ $< ENDRAW[Makefile(unix)] The reason for this is that as soon as you want to add compiler specific flags, you also walk away from build.info's general platform independence. BEGINRAW / ENDRAW is your escape from that independence. That being said, I wouldn't recommend mixing object files with and without debugging information. Configure has the option --debug (-d to config) to enable debugging, the rest is (hopefully) in the config target in Configurations/10-main.conf. Cheers, Richard In message <9c8b7283-745f-1b33-dab3-b79cfca84a73 at akamai.com> on Thu, 27 Oct 2016 11:04:13 -0500, Benjamin Kaduk said: bkaduk> Is it possible in the unified build system to apply certain compiler bkaduk> (or linker) flags only to a specific file or set of files? This could bkaduk> make some scenarios easier when one is willing to patch the tree bkaduk> (e.g., build some things with -O3 and others with -O0 -ggdb3). bkaduk> bkaduk> Given that the unified build outputs a single unified Makefile to bkaduk> build everything, it seems unlikely, but I just wanted to check. bkaduk> bkaduk> Thanks, bkaduk> bkaduk> Ben From doctor at doctor.nl2k.ab.ca Sun Oct 30 11:39:07 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 30 Oct 2016 05:39:07 -0600 Subject: [openssl-dev] openssl-1.0.2-stable-SNAP-20161030 isue test failures Message-ID: <20161030113907.GA80336@doctor.nl2k.ab.ca> make test yield Test X509v3_check_* ../util/shlib_wrap.sh ./v3nametest ../util/shlib_wrap.sh ./heartbeat_test test_dtls1_not_bleeding failed: expected return value 0, received -1 ** test_dtls1_not_bleeding failed ** -------- test_dtls1_not_bleeding_empty_payload failed: expected return value 0, received -1 ** test_dtls1_not_bleeding_empty_payload failed ** -------- test_tls1_not_bleeding failed: expected return value 0, received -1 ** test_tls1_not_bleeding failed ** -------- test_tls1_not_bleeding_empty_payload failed: expected return value 0, received -1 ** test_tls1_not_bleeding_empty_payload failed ** -------- 4 tests failed *** Error code 1 not present in openssl-1.0.2-stable-SNAP-20161029 . Please fix. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Time for the USA to hold a referendum on its republic and vote to dissolve!! From doctor at doctor.nl2k.ab.ca Mon Oct 31 14:29:38 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 31 Oct 2016 08:29:38 -0600 Subject: [openssl-dev] Still seeing test failure in openssl 1.0.2 SNAPHOT 20161031 Message-ID: <20161031142938.GA97772@doctor.nl2k.ab.ca> I saw this yesterday as well ../util/shlib_wrap.sh ./heartbeat_test test_dtls1_not_bleeding failed: expected return value 0, received -1 ** test_dtls1_not_bleeding failed ** -------- test_dtls1_not_bleeding_empty_payload failed: expected return value 0, received -1 ** test_dtls1_not_bleeding_empty_payload failed ** -------- test_tls1_not_bleeding failed: expected return value 0, received -1 ** test_tls1_not_bleeding failed ** -------- test_tls1_not_bleeding_empty_payload failed: expected return value 0, received -1 ** test_tls1_not_bleeding_empty_payload failed ** -------- 4 tests failed *** Error code 1 Stop. make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161031/test *** Error code 1 Please fix -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Time for the USA to hold a referendum on its republic and vote to dissolve!!