Re: [openssl-dev] License compatibility: OpenSSL and Apache v2
This is something I would like to be contributed to OpenSSL. Sure, I'm talking about new engine and new files. And I agree that using the same license as OpenSSL itself would be the best solution. But, if for some reasons licensing of it will be possible under Apache v2 only - what issues could it cause? On 10 December 2014 at 05:54, Salz, Rich rs...@akamai.com wrote: Let's imagine someone develop extension module to OpenSSL, and release it under Apache v2 license. Do you see any possible issues with using this extension module as a part of OpenSSL? Are you writing an extension that you are going to distribute, or is it something you want to contribute to OpenSSL? You cannot change the license on openssl files, and any work derived from them such as modifications to those source files, must have the same license. And if you want to to contribute it to the project, it is easiest for us if the license is the same. But if it is your own code, and you are distributing it, then you can do anything you want :) ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl-dev] More POODLE issues
Now POODLE is hitting TLS http://www.computerworld.com/article/2857274/security0/poodle-flaw-tls-itbwcw.html Any fixes in the works? -- 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 Merry Christmas 2014 and Happy New Year 2015 ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2
On Mon Dec 08 19:58:31 2014, sdao...@yandex.com wrote: Commit [45f55f6] (Remove SSLv2 support, 2014-11-30) completely removed SSLv2 support and the commit message states The only support for SSLv2 left is receiving a SSLv2 compatible client hello. If people start using SSL_CONF_CTX as they are supposed to with v1.0.2, then it can be expected that users start using strings like, e.g. (from my thing), set ssl-protocol=ALL,-SSLv2 This results in the obvious problem that when they (get) upgrade(d) their OpenSSL library they will see a completely intransparent error message that no normal user will understand: SSL_CONF_CTX_cmd() failed:\ error:1414E180:SSL routines:SSL_CONF_CTX_cmd:bad value (Ah ja, my _CTX_ diff also works in practice.) I think it would be much better if at least a user request to explicitly disable SSLv2 is silently ignored. Another option would be to enhance the error message, of course... If you print out the additional error data it should also indicate which command and value it is objecting to, though it will only say it doesn't like the whole string and not the specific part of it it is rejecting. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug?
Sorry. Line 1244 is OPENSSL_assert(s-d1-w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH == (unsigned int)s-init_num); 2014-12-10 11:05 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: (gdb) p s-d1-w_msg_hdr.msg_len $2 = 0 (gdb) p s-init_num $3 = 0 2014-12-10 10:59 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Get again ASSERT in d1_both.c:1244 OPENSSL_assert(s-d1-w_msg_hdr.msg_len + ((s-version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned int)s-init_num); } 2014-12-10 6:32 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Hello. I begin test you patch. I attach to mail patched version of you patch wthat may clear added current SRPM of Centos 6 2014-12-03 5:16 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Thanks! I need time to test it... i will try answer at this week 2014-12-02 19:37 GMT+03:00 Matt Caswell via RT r...@openssl.org: On Tue Dec 02 17:31:05 2014, v.badal...@open-bs.ru wrote: if you send patch i can add it to SRPM build and try results The patch is attached. However you may have problems with this approach. I have built the patch for 1.0.1e (which is the version you originally said you were running). However any additional patches that have been applied to the SRPM could cause the patch to fail to apply (and it is quite a large patch). I can also supply a patch against the latest 1.0.1j or OpenSSL_1_0_1-stable from git if you prefer. Matt -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext
Excellent. My summary is: - valgrind complaints about 1.0.1 OpenSLL are extremely unlikely to affect my program in operation (you will probably say will not affect) - when OpenSLL 1.0.2 eventually percolates through to Ubuntu and Fedora valgrind will stop complaining. That's good, because I'm seeing a significant speed increase over CryptoPP in my test code and my program is currently CPU bound in the crypto code. Hopefully this will push the performance bottleneck somewhere else for a while :) Thanks for your helpChris From: Andy Polyakov via RT r...@openssl.org To: prwh...@yahoo.com.au Cc: openssl-dev@openssl.org Sent: Tuesday, 9 December 2014, 21:02 Subject: Re: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext The demo program actually allocates a whole extra block for the output, so there should always be extra space available. Yes, which is why I said as for alleged buffer overruns in *your* program. I mean you said I discovered this [suspected buffer overrun] in my real code and as you didn't present it, I found it appropriate to remind that strlen-based allocations are prone to overruns, and if it would be case, it would be something for you to address. My real program uses manually padded, known-size binary packets Excellent! If you would have clarified this from beginning, we wouldn't have this digression :-) I've just re-tested, pasting the code in to both C and C++ netbeans projects (since that's what my main project uses) and fixing the C++ convert-from-const errors as well as adding aes.h. Both give the same valgrind issues for me. I'm using gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) and valgrind-3.10.0.SVN if that might make a difference. Experimentation shows that the magic length is 96 bytes - strlen()=94 works fine on my machine, strlen()=95 produces the valgrind complaints. That means input length of 96, since the code uses strlen()+1. What's magic about a 96 byte input size? (other than being 6 AES128 blocks) Since I have a new Fedora 20 virtual machine handy I have also run on that with the same result:Using OpenSSL version OpenSSL 1.0.1e-fips 11 Feb 2013 ==2793== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ... ==2793== Conditional jump or move depends on uninitialised value(s) ==2793== at 0x4C2A79E: strncmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==2793== by 0x400FA1: main (in /home/digidev/test/a.out) ==2793== Uninitialised value was created by a stack allocation ==2793== at 0x4EC0DB7: aesni_cbc_encrypt (in /usr/lib64/libcrypto.so.1.0.1e) ... OK. Keyword here is that it's 1.0.1 (I was testing against development branch, master and 1.0.2). 1.0.1 is actually known to upset valgrind (see RT#2862), but it looks more like valgrind bug. Well, it's somewhat in between: one can argue that valgrind has formal right to complain, but at the same time aesni_cbc_encrypt doesn't actually violate ABI constrains. Latter means that result is always correct and code in question doesn't actually overrun any buffers nor uses uninitialized values. The reason for why I failed to initially reproduce it in master and 1.0.2 is that module in question was updated after 1.0.1 release to not rely on red zone (the thing valgrind is complaining about). But this was done for reason other than appeasing valgrind. In case you wonder why problem pops up with longer lengths. This is because with shorter lengths it's possible to keep everything in processor registers. And with longer length it has to spill one value to stack. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On 9 December 2014 at 11:35, Steffen Nurpmeso sdao...@yandex.com wrote: Richard Moore richmoor...@gmail.com wrote: |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote: | and finally i propose three new values for the Protocol slot of | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |In Qt we've added an enum value for TLS versions that is SecureProtocols so |that we could remove versions as required without requiring apps to be |updated. It's an open question which is more likely to get updated - Qt or |the apps of course. For Qt 5.4 which is due out this week we've removed |SSL3 from this enum so apps will silently get updated to drop support for |it. I see. And i think this is the most impressive or, lesser enthusiastic, important feature of the slow _CONF_ interface: that users can use strings and that those are directly swallowed by the OpenSSL library, so that neither recompilation nor understanding is necessary on the program side in order to upgrade to a new level of security. The API we offer in Qt isn't tied to openssl so we can't do that. We also support a Windows RT backend and a SecureTransport backend is under development too. (As a side note: SecureProtocols is such a Volvo wording... Doesn't vulnerable energises a deeper feeling of insecurity? I think Hitchcock would have used the naked and bare vulnerable.) That's partly due to the API naming conventions for enums. :-) Rich. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Richard Moore richmoor...@gmail.com wrote: |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org wrote: | and finally i propose three new values for the Protocol slot of | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |In Qt we've added an enum value for TLS versions that is SecureProtocols so |that we could remove versions as required without requiring apps to be |updated. It's an open question which is more likely to get updated - Qt or |the apps of course. For Qt 5.4 which is due out this week we've removed |SSL3 from this enum so apps will silently get updated to drop support for |it. I see. And i think this is the most impressive or, lesser enthusiastic, important feature of the slow _CONF_ interface: that users can use strings and that those are directly swallowed by the OpenSSL library, so that neither recompilation nor understanding is necessary on the program side in order to upgrade to a new level of security. (As a side note: SecureProtocols is such a Volvo wording... Doesn't vulnerable energises a deeper feeling of insecurity? I think Hitchcock would have used the naked and bare vulnerable.) Ciao, --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug?
Looks like need add some check to return code len
2014-12-10 11:06 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru:
Sorry. Line 1244 is
OPENSSL_assert(s-d1-w_msg_hdr.msg_len +
DTLS1_HM_HEADER_LENGTH == (unsigned
int)s-init_num);
2014-12-10 11:05 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru:
(gdb) p s-d1-w_msg_hdr.msg_len
$2 = 0
(gdb) p s-init_num
$3 = 0
2014-12-10 10:59 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru:
Get again ASSERT in d1_both.c:1244
OPENSSL_assert(s-d1-w_msg_hdr.msg_len +
((s-version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned
int)s-init_num);
}
2014-12-10 6:32 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru:
Hello. I begin test you patch. I attach to mail patched version of you
patch wthat may clear added current SRPM of Centos 6
2014-12-03 5:16 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru:
Thanks! I need time to test it... i will try answer at this week
2014-12-02 19:37 GMT+03:00 Matt Caswell via RT r...@openssl.org:
On Tue Dec 02 17:31:05 2014, v.badal...@open-bs.ru wrote:
if you send patch i can add it to SRPM build and try results
The patch is attached. However you may have problems with this
approach. I have
built the patch for 1.0.1e (which is the version you originally said
you were
running). However any additional patches that have been applied to
the SRPM
could cause the patch to fail to apply (and it is quite a large
patch). I can
also supply a patch against the latest 1.0.1j or OpenSSL_1_0_1-stable
from git
if you prefer.
Matt
--
С уважением,
Бадалян Вячеслав Борисович
ООО Открытые бизнес-решения
Технический директор
+7 (495) 666-0-111
http://www.open-bs.ru
--
С уважением,
Бадалян Вячеслав Борисович
ООО Открытые бизнес-решения
Технический директор
+7 (495) 666-0-111
http://www.open-bs.ru
--
С уважением,
Бадалян Вячеслав Борисович
ООО Открытые бизнес-решения
Технический директор
+7 (495) 666-0-111
http://www.open-bs.ru
--
С уважением,
Бадалян Вячеслав Борисович
ООО Открытые бизнес-решения
Технический директор
+7 (495) 666-0-111
http://www.open-bs.ru
--
С уважением,
Бадалян Вячеслав Борисович
ООО Открытые бизнес-решения
Технический директор
+7 (495) 666-0-111
http://www.open-bs.ru
--
С уважением,
Бадалян Вячеслав Борисович
ООО Открытые бизнес-решения
Технический директор
+7 (495) 666-0-111
http://www.open-bs.ru
--- a/ssl/d1_srvr.c`2014-12-10 11:12:43.570309059 +0300
+++ b/ssl/d1_srvr.c 2014-12-10 11:13:53.418025227 +0300
@@ -1593,7 +1593,9 @@
}
}
- l=dtls1_output_cert_chain(s,x);
+ if ((l=dtls1_output_cert_chain(s,x)) = 0){
+ return -1;
+ }
s-state=SSL3_ST_SW_CERT_B;
s-init_num=(int)l;
s-init_off=0;
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug?
Hello. I begin test you patch. I attach to mail patched version of you
patch wthat may clear added current SRPM of Centos 6
2014-12-03 5:16 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru:
Thanks! I need time to test it... i will try answer at this week
2014-12-02 19:37 GMT+03:00 Matt Caswell via RT r...@openssl.org:
On Tue Dec 02 17:31:05 2014, v.badal...@open-bs.ru wrote:
if you send patch i can add it to SRPM build and try results
The patch is attached. However you may have problems with this approach.
I have
built the patch for 1.0.1e (which is the version you originally said you
were
running). However any additional patches that have been applied to the
SRPM
could cause the patch to fail to apply (and it is quite a large patch). I
can
also supply a patch against the latest 1.0.1j or OpenSSL_1_0_1-stable
from git
if you prefer.
Matt
--
С уважением,
Бадалян Вячеслав Борисович
ООО Открытые бизнес-решения
Технический директор
+7 (495) 666-0-111
http://www.open-bs.ru
--
С уважением,
Бадалян Вячеслав Борисович
ООО Открытые бизнес-решения
Технический директор
+7 (495) 666-0-111
http://www.open-bs.ru
From a0473d82c6ad0d4f5f1e2f778a20ae374317720a Mon Sep 17 00:00:00 2001
From: Matt Caswell m...@openssl.org
Date: Mon, 1 Dec 2014 11:10:38 +
Subject: [PATCH] MTU fixes patch
---
apps/s_client.c| 16 +++-
apps/s_server.c| 18 -
crypto/bio/bio.h | 4 ++
crypto/bio/bss_dgram.c | 46 --
ssl/d1_both.c | 103 +++--
ssl/d1_lib.c | 32 +--
ssl/dtls1.h| 4 ++
ssl/ssl.h | 8
ssl/ssl_lib.c | 13 ---
ssl/ssl_locl.h | 3 +-
10 files changed, 184 insertions(+), 63 deletions(-)
diff --git a/apps/s_client.c b/apps/s_client.c
index 3ba6605..9f4be61 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -1307,10 +1307,22 @@ re_start:
BIO_ctrl(sbio, BIO_CTRL_DGRAM_SET_SEND_TIMEOUT, 0,
timeout);
}
- if (socket_mtu 28)
+ if (socket_mtu)
{
+ if(socket_mtu DTLS_get_link_min_mtu(con))
+ {
+ BIO_printf(bio_err,MTU too small. Must be at
least %d\n,
+ DTLS_get_link_min_mtu(con));
+ BIO_free(sbio);
+ goto shut;
+ }
SSL_set_options(con, SSL_OP_NO_QUERY_MTU);
- SSL_set_mtu(con, socket_mtu - 28);
+ if(!DTLS_set_link_mtu(con, socket_mtu))
+ {
+ BIO_printf(bio_err, Failed to set MTU\n);
+ BIO_free(sbio);
+ goto shut;
+ }
}
else
/* want to do MTU discovery */
diff --git a/apps/s_server.c b/apps/s_server.c
index 8198d7f..a6f090b 100644
--- a/apps/s_server.c
+++ b/apps/s_server.c
@@ -2035,10 +2035,24 @@ static int sv_body(char *hostname, int s, unsigned char
*context)
BIO_ctrl(sbio, BIO_CTRL_DGRAM_SET_SEND_TIMEOUT, 0,
timeout);
}
- if (socket_mtu 28)
+ if (socket_mtu)
{
+ if(socket_mtu DTLS_get_link_min_mtu(con))
+ {
+ BIO_printf(bio_err,MTU too small. Must be at
least %d\n,
+ DTLS_get_link_min_mtu(con));
+ ret = -1;
+ BIO_free(sbio);
+ goto err;
+ }
SSL_set_options(con, SSL_OP_NO_QUERY_MTU);
- SSL_set_mtu(con, socket_mtu - 28);
+ if(!DTLS_set_link_mtu(con, socket_mtu))
+ {
+ BIO_printf(bio_err, Failed to set MTU\n);
+ ret = -1;
+ BIO_free(sbio);
+ goto err;
+ }
}
else
/* want to do MTU discovery */
diff --git a/crypto/bio/bio.h b/crypto/bio/bio.h
index 05699ab..32eba71 100644
--- a/crypto/bio/bio.h
+++ b/crypto/bio/bio.h
@@ -175,6 +175,8 @@ extern C {
#define BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT 45 /* Next DTLS handshake timeout to
* adjust socket timeouts */
+#define BIO_CTRL_DGRAM_GET_MTU_OVERHEAD 49
+
#ifndef OPENSSL_NO_SCTP
/* SCTP stuff */
#define BIO_CTRL_DGRAM_SCTP_SET_IN_HANDSHAKE 50
@@ -607,6 +609,8 @@ int
Re: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug?
After add check get crash 2014-12-10 11:18 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Looks like need add some check to return code len 2014-12-10 11:06 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Sorry. Line 1244 is OPENSSL_assert(s-d1-w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH == (unsigned int)s-init_num); 2014-12-10 11:05 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: (gdb) p s-d1-w_msg_hdr.msg_len $2 = 0 (gdb) p s-init_num $3 = 0 2014-12-10 10:59 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Get again ASSERT in d1_both.c:1244 OPENSSL_assert(s-d1-w_msg_hdr.msg_len + ((s-version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned int)s-init_num); } 2014-12-10 6:32 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Hello. I begin test you patch. I attach to mail patched version of you patch wthat may clear added current SRPM of Centos 6 2014-12-03 5:16 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Thanks! I need time to test it... i will try answer at this week 2014-12-02 19:37 GMT+03:00 Matt Caswell via RT r...@openssl.org: On Tue Dec 02 17:31:05 2014, v.badal...@open-bs.ru wrote: if you send patch i can add it to SRPM build and try results The patch is attached. However you may have problems with this approach. I have built the patch for 1.0.1e (which is the version you originally said you were running). However any additional patches that have been applied to the SRPM could cause the patch to fail to apply (and it is quite a large patch). I can also supply a patch against the latest 1.0.1j or OpenSSL_1_0_1-stable from git if you prefer. Matt -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru #0 _int_malloc (av=0x7fff4c20, bytes=value optimized out) at malloc.c:4476 iters = value optimized out nb = 6496 idx = 103 bin = value optimized out victim = 0x7fff4c007d70 size = 8016 victim_index = value optimized out remainder = value optimized out remainder_size = value optimized out block = value optimized out bit = value optimized out map = value optimized out fwd = value optimized out bck = 0x0 errstr = 0x0 #1 0x0037c9e7a6b1 in __libc_malloc (bytes=6488) at malloc.c:3664 ar_ptr = 0x7fff4c20 victim = value optimized out hook = value optimized out #2 0x7780bd36 in CRYPTO_realloc_clean (str=0x7fff4c026ca0, old_len=4780, num=6488, file=0x77912c9b buffer.c, line=166) at mem.c:372 ret = 0x0 #3 0x7787bae6 in BUF_MEM_grow_clean (str=0x7fff3c034870, len=4864) at buffer.c:166 ret = value optimized out n = 6488 #4 0x7787d513 in mem_write (b=value optimized out, in=0x7fff4c0231b0 \026\376\377, inl=256) at bss_mem.c:189 ret = -1 blen = 4608 bm = 0x7fff3c034870 #5 0x7787c747 in BIO_write (b=0x7fff3c033a60, in=0x7fff4c0231b0, inl=256) at bio_lib.c:247 i = value optimized out cb = 0 #6 0x7787f871 in buffer_ctrl (b=0x7fff4c012fd0, cmd=value optimized out, num=0, ptr=0x0) at bf_buff.c:404 dbio = value optimized out ctx = 0x7fff4c018a70 ret = 1 p1 = value optimized out p2 = value optimized out r = value optimized out i = value optimized out ip = value optimized out ibs = value optimized out obs = value optimized out #7 0x77bc2b0d in dtls1_do_write (s=0x7fff3c0335f0, type=22) at d1_both.c:318 ret = value optimized out curr_mtu = -13 retry = 1 len = value optimized out frag_off = 3816 mac_size = 0 blocksize = 0 #8 0x77bbbdf7 in dtls1_accept (s=0x7fff3c0335f0) at d1_srvr.c:426 buf = value optimized out Time = 1418200173 cb = 0 alg_k = value optimized out ret =
Re: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug?
(gdb) p s-d1-w_msg_hdr.msg_len $2 = 0 (gdb) p s-init_num $3 = 0 2014-12-10 10:59 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Get again ASSERT in d1_both.c:1244 OPENSSL_assert(s-d1-w_msg_hdr.msg_len + ((s-version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned int)s-init_num); } 2014-12-10 6:32 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Hello. I begin test you patch. I attach to mail patched version of you patch wthat may clear added current SRPM of Centos 6 2014-12-03 5:16 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Thanks! I need time to test it... i will try answer at this week 2014-12-02 19:37 GMT+03:00 Matt Caswell via RT r...@openssl.org: On Tue Dec 02 17:31:05 2014, v.badal...@open-bs.ru wrote: if you send patch i can add it to SRPM build and try results The patch is attached. However you may have problems with this approach. I have built the patch for 1.0.1e (which is the version you originally said you were running). However any additional patches that have been applied to the SRPM could cause the patch to fail to apply (and it is quite a large patch). I can also supply a patch against the latest 1.0.1j or OpenSSL_1_0_1-stable from git if you prefer. Matt -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Richard Moore richmoor...@gmail.com wrote: |On 9 December 2014 at 11:35, Steffen Nurpmeso sdao...@yandex.com wrote: | Richard Moore richmoor...@gmail.com wrote: ||On 8 December 2014 at 19:20, Steffen Nurpmeso via RT r...@openssl.org | wrote: || and finally i propose three new values for the Protocol slot of || SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. || ||In Qt we've added an enum value for TLS versions that is SecureProtocols | so ||that we could remove versions as required without requiring apps to be ||updated. It's an open question which is more likely to get updated - Qt | or ||the apps of course. For Qt 5.4 which is due out this week we've removed ||SSL3 from this enum so apps will silently get updated to drop support for ||it. | | I see. And i think this is the most impressive or, lesser | enthusiastic, important feature of the slow _CONF_ interface: that | users can use strings and that those are directly swallowed by the | OpenSSL library, so that neither recompilation nor understanding | is necessary on the program side in order to upgrade to a new | level of security. | |The API we offer in Qt isn't tied to openssl so we can't do that. We also |support a Windows RT backend and a SecureTransport backend is under |development too. Well, of course. Implementing a simple fixed-string wrapper isn't hard to do shall there be desire, however, i've done the mine in about two hours in 43 lines plus the mapping array and some testing (a n_strsep() already existed). And it can be hoped that other libraries follow with their interfaces, functions like SSLSetProtocolVersionMin() or Ssl3AllowWeakEncryption SocketProtectionLevel constants are really inflexible and hard to use. And result in ugly mail paragraph formatting. And do i think most of the time not really describe what is desired (a secure transport, or SecureProtocols in your QT world). But not that i wouldn't prefer compile-checks in favour of intransparent strings. That makes me think that some prodding by you could possibly get the ball rolling. It needn't be _that_ flexible.. | (As a side note: SecureProtocols is such a Volvo wording... | Doesn't vulnerable energises a deeper feeling of insecurity? | I think Hitchcock would have used the naked and bare vulnerable.) | | |That's partly due to the API naming conventions for enums. :-) Yet that only describes the lesser part :) --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Kurt Roeckx via RT r...@openssl.org wrote: |On Mon, Dec 08, 2014 at 08:20:44PM +0100, Steffen Nurpmeso via RT wrote: | and finally i propose three new values for the Protocol slot of | SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |I actually find the option unfortunate and I think it should have |been one that sets the minimum and maximum version. But I think |we're too late 1.0.2 process to still change this. A good benefit for a three line patch. Being able to say -ALL,=TLSv1.1 etc. is surely on the list of many, and much more complicated to implement than that. --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #2595] Capitalize X509 subject key STREET according to rfc1779
Test, please ignore ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2
Kurt Roeckx via RT r...@openssl.org wrote:
|On Mon, Dec 08, 2014 at 07:58:31PM +0100, Steffen Nurpmeso via RT wrote:
| set ssl-protocol=ALL,-SSLv2
|
| This results in the obvious problem that when they (get)
| upgrade(d) their OpenSSL library they will see a completely
| intransparent error message that no normal user will understand:
|
|It was actually my intention to keep supporting that, but I seem
|to have removed that line. I think the following patch should fix
|that:
|--- a/ssl/ssl_conf.c
|+++ b/ssl/ssl_conf.c
|@@ -333,6 +333,7 @@ static int cmd_Protocol(SSL_CONF_CTX *cctx,
|const char *value)
|static const ssl_flag_tbl ssl_protocol_list[] =
|{
|SSL_FLAG_TBL_INV(ALL, SSL_OP_NO_SSL_MASK),
|+ SSL_FLAG_TBL_INV(SSLv2, SSL_OP_NO_SSLv2),
|SSL_FLAG_TBL_INV(SSLv3, SSL_OP_NO_SSLv3),
|SSL_FLAG_TBL_INV(TLSv1, SSL_OP_NO_TLSv1),
|SSL_FLAG_TBL_INV(TLSv1.1, SSL_OP_NO_TLSv1_1),
Sure, since SSL_OP_NO_SSLv2 still exists as 0x0L as i see know.
--steffen
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug?
Get again ASSERT in d1_both.c:1244
OPENSSL_assert(s-d1-w_msg_hdr.msg_len +
((s-version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned
int)s-init_num);
}
2014-12-10 6:32 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru:
Hello. I begin test you patch. I attach to mail patched version of you
patch wthat may clear added current SRPM of Centos 6
2014-12-03 5:16 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru:
Thanks! I need time to test it... i will try answer at this week
2014-12-02 19:37 GMT+03:00 Matt Caswell via RT r...@openssl.org:
On Tue Dec 02 17:31:05 2014, v.badal...@open-bs.ru wrote:
if you send patch i can add it to SRPM build and try results
The patch is attached. However you may have problems with this approach.
I have
built the patch for 1.0.1e (which is the version you originally said you
were
running). However any additional patches that have been applied to the
SRPM
could cause the patch to fail to apply (and it is quite a large patch).
I can
also supply a patch against the latest 1.0.1j or OpenSSL_1_0_1-stable
from git
if you prefer.
Matt
--
С уважением,
Бадалян Вячеслав Борисович
ООО Открытые бизнес-решения
Технический директор
+7 (495) 666-0-111
http://www.open-bs.ru
--
С уважением,
Бадалян Вячеслав Борисович
ООО Открытые бизнес-решения
Технический директор
+7 (495) 666-0-111
http://www.open-bs.ru
--
С уважением,
Бадалян Вячеслав Борисович
ООО Открытые бизнес-решения
Технический директор
+7 (495) 666-0-111
http://www.open-bs.ru
#0 0x0037c9e32625 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
resultvar = 0
pid = value optimized out
selftid = 19173
#1 0x0037c9e33e05 in abort () at abort.c:92
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x8f91b0
stderr@@GLIBC_2.2.5, sa_sigaction = 0x8f91b0 stderr@@GLIBC_2.2.5}, sa_mask
= {__val = {140737349776136, 140735810636400, 140735676423408, 0, 0,
239610129240,
140737351974912, 140734669926416, 4294967295, 206158430240, 5,
4001896, 0, 8512, 3, 140737345359872}}, sa_flags = -912203712, sa_restorer =
0x7fff0005}
sigs = {__val = {32, 0 repeats 15 times}}
#2 0x7780ae3f in OpenSSLDie (file=value optimized out, line=value
optimized out, assertion=value optimized out) at cryptlib.c:923
No locals.
#3 0x77bc165e in dtls1_buffer_message (s=0x7fff58023010, is_ccs=0) at
d1_both.c:1244
item = value optimized out
frag = 0x7fff94001cf0
seq64be = \020\060\002X\377\177\000
#4 0x77bb9fd0 in dtls1_send_server_certificate (s=0x7fff58023010) at
d1_srvr.c:1602
l = value optimized out
x = value optimized out
#5 0x77bbbdf7 in dtls1_accept (s=0x7fff58023010) at d1_srvr.c:426
buf = value optimized out
Time = 1418197945
cb = 0
alg_k = value optimized out
ret = value optimized out
new_state = value optimized out
state = 8512
skip = 0
listen = 0
#6 0x7fff9e282999 in dtls_perform_handshake (instance=0x7fff58014dd8,
dtls=0x7fff5800fbb0, rtcp=0) at res_rtp_asterisk.c:1584
rtp = 0x7fff5800ce10
#7 0x7fff9e282a8a in ast_rtp_on_ice_complete (ice=0x7fff5801db58,
status=0) at res_rtp_asterisk.c:1610
instance = 0x7fff58014dd8
rtp = 0x7fff5800ce10
#8 0x7fff9e294dad in on_timer () from
/usr/lib/asterisk/modules/res_rtp_asterisk.so
No symbol table info available.
#9 0x7fff9e2c3b6e in pj_timer_heap_poll () from
/usr/lib/asterisk/modules/res_rtp_asterisk.so
No symbol table info available.
#10 0x7fff9e282d59 in timer_worker_thread (data=0x0) at
res_rtp_asterisk.c:1696
delay = {sec = 0, msec = 10}
ioqueue = 0x7fff940008e8
#11 0x7fff9e2b509b in thread_main () from
/usr/lib/asterisk/modules/res_rtp_asterisk.so
No symbol table info available.
#12 0x0037ca2079d1 in start_thread (arg=0x7fff9c001700) at
pthread_create.c:301
__res = value optimized out
pd = 0x7fff9c001700
now = value optimized out
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140735810639616,
179920719414352890, 140737488340608, 140735810640320, 0, 3,
-180129756062360582, 148795465936985082}, mask_was_saved = 0}}, priv = {pad =
{0x0, 0x0, 0x0, 0x0},
data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = value optimized out
pagesize_m1 = value optimized out
sp = value optimized out
freesize = value optimized out
#13 0x0037c9ee89dd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
|Kurt Roeckx via RT r...@openssl.org wrote: ||been one that sets the minimum and maximum version. But I think ||we're too late 1.0.2 process to still change this. Attached a git format-patch MBOX for 1.0.2 (on top of [6806b69]). It boils anything down into two changesets (SSL_CONF_CTX and pseudo protocols). Remarks: - I've adjusted anything for SSLv2 (in the PODs, as OLDEST, in VULNERABLE). - s_client.pod and s_server.pod did not yet state that they support the SSL_CONF_CTX arguments, so i've added that (which s_cb.c seems to support already). - make make test work, rest yet just installed. Let me know if you want the same for [master] again. I really hope you do that, and Ciao from Germany --steffen ossl-1_0_2.mbox Description: application/mbox ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3607] nistz256 is broken.
On Fri, Dec 5, 2014 at 6:33 AM, Andy Polyakov via RT r...@openssl.org wrote: Attached. A little bit worse performance on some CPUs. I also took opportunity to harmonize ecp_nistz256_from_mont by applying same pattern for reduction. The patch is cumulative, i.e. is not incremental to previously posted one[s], and addresses both problems, originally reported one and discovered in the course. Patch to ecp_nistz256.c referred above doesn't matter. When applying just that patch, the original test case fails. Specially this test code (C++): BIGNUM *n = nullptr, *X = nullptr, *Y = nullptr, *Z = nullptr; BIGNUM *x = BN_new(); BIGNUM *y = BN_new(); ASSERT_NE(BN_hex2bn(n, 2269520AFB46450398DE95AE59DDBDC1D42B8B7030F81BCFEF12D819C1D678DD), 0); ASSERT_NE(BN_hex2bn(X, C4EB2994C09557B400FF6A543CFB257F945E86FE3DF1D32A8128F32927666A8F), 0); ASSERT_NE(BN_hex2bn(Y, 3D5283F8F10F559AE5310005005F321B28D2D699F3E01F179F91AC6660013328), 0); ASSERT_NE(BN_hex2bn(Z, F97FD7E6757991A2C7E0C2488FF3C54E58030BCACF3FB95954FD3EF211C24631), 0); EC_GROUP *group = EC_GROUP_new_by_curve_name(NID_X9_62_prime256v1); EC_POINT *p = EC_POINT_new(group); BN_CTX *ctx = BN_CTX_new(); ASSERT_EQ(1, EC_POINT_set_Jprojective_coordinates_GFp(group, p, X, Y, Z, ctx)); EC_POINT *r = EC_POINT_new(group); // Set r = 핡×n. ASSERT_EQ(1, EC_POINT_mul(group, r, NULL, p, n, ctx)); ASSERT_EQ(1, EC_POINT_get_affine_coordinates_GFp(group, r, x, y, ctx)); char *x_out = BN_bn2hex(x); char *y_out = BN_bn2hex(y); EXPECT_STREQ(C2910AA0216D12DE30C5573CCFC4116546E3091DC1E9EC8604F634185CE40863, x_out); EXPECT_STREQ(C9071E13D688C305CE179C6168DD9066657BC6CDC1639A44B68DF7F1E0A40EDF, y_out); free(x_out); free(y_out); BN_free(x); BN_free(y); BN_free(X); BN_free(Y); BN_free(Z); BN_free(n); EC_POINT_free(r); EC_POINT_free(p); BN_CTX_free(ctx); EC_GROUP_free(group); Just to check that I'm not doing anything stupid (which is always a distinct possibility), here are the .pl[1] and resulting .s[2] file that I ended up with. [1] https://drive.google.com/file/d/0B_OzbbAp1CG5OVdVc196QmV3bG8/view?usp=sharing [2] https://drive.google.com/file/d/0B_OzbbAp1CG5Z3NoZzBqU09scFE/view?usp=sharing Cheers AGL ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Salz, Rich rs...@akamai.com wrote: |I think magic names -- shorthands -- are a very bad idea. \ I _completely_ disagree. | They are point-in-time statements whose meaning evolves, \ |if not erodes, over time. Because i don't think that a normal user, or even normal administrators and programmers is and are willing or even capable to understand what they are doing. How many people have read all the RFCs that are involved? And how many people have sufficient knowledge to _really_ understand the mathematical concepts and actual algorithms? Personally i am willing to put enough trust in the OpenSSL team *even insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE' and leave the task of deciding what is VULNERABLE up to you. Imagine that. I have already implemented the necessary _CONF_ wrapper for OpenSSL v1.0.1 and it'll gave you a hand (shall the list receive this message). --steffen ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug?
Also valgrind output ==17767== Thread 37: ==17767== Source and destination overlap in memcpy(0x253bfcbd, 0x7e9c51b, 4294967209) ==17767==at 0x4A09A48: memcpy (vg_replace_strmem.c:916) ==17767==by 0x4E5A2B6: do_dtls1_write (d1_pkt.c:1592) ==17767==by 0x4E5DA69: dtls1_do_write (d1_both.c:359) ==17767==by 0x4E56DF6: dtls1_accept (d1_srvr.c:426) ==17767==by 0x4E5B85C: dtls1_read_bytes (d1_pkt.c:787) ==17767==by 0x4E45ECF: ssl3_read_internal (s3_lib.c:4273) ==17767==by 0x215E3EF4: __rtp_recvfrom (res_rtp_asterisk.c:2019) ==17767==by 0x215E431E: rtp_recvfrom (res_rtp_asterisk.c:2094) ==17767==by 0x215ED620: ast_rtp_read (res_rtp_asterisk.c:4127) ==17767==by 0x5529D2: ast_rtp_instance_read (rtp_engine.c:314) ==17767==by 0x114A7838: sip_rtp_read (chan_sip.c:8198) ==17767==by 0x114A7FE7: sip_read (chan_sip.c:8295) ==17767==by 0x47D254: __ast_read (channel.c:4054) ==17767==by 0x47EFFD: ast_read (channel.c:4408) ==17767==by 0x476B8F: ast_safe_sleep_conditional (channel.c:1702) ==17767== ==17767== Invalid read of size 2 ==17767==at 0x4A09C4C: memcpy (vg_replace_strmem.c:916) ==17767==by 0x4E5A2B6: do_dtls1_write (d1_pkt.c:1592) ==17767==by 0x4E5DA69: dtls1_do_write (d1_both.c:359) ==17767==by 0x4E56DF6: dtls1_accept (d1_srvr.c:426) ==17767==by 0x4E5B85C: dtls1_read_bytes (d1_pkt.c:787) ==17767==by 0x4E45ECF: ssl3_read_internal (s3_lib.c:4273) ==17767==by 0x215E3EF4: __rtp_recvfrom (res_rtp_asterisk.c:2019) ==17767==by 0x215E431E: rtp_recvfrom (res_rtp_asterisk.c:2094) ==17767==by 0x215ED620: ast_rtp_read (res_rtp_asterisk.c:4127) ==17767==by 0x5529D2: ast_rtp_instance_read (rtp_engine.c:314) ==17767==by 0x114A7838: sip_rtp_read (chan_sip.c:8198) ==17767==by 0x114A7FE7: sip_read (chan_sip.c:8295) ==17767==by 0x47D254: __ast_read (channel.c:4054) ==17767==by 0x47EFFD: ast_read (channel.c:4408) ==17767==by 0x476B8F: ast_safe_sleep_conditional (channel.c:1702) ==17767== Address 0x107e9c4c2 is not stack'd, malloc'd or (recently) free'd ==17767== ==17767== ==17767== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==17767== Access not within mapped region at address 0x107E9C4C2 ==17767==at 0x4A09C4C: memcpy (vg_replace_strmem.c:916) ==17767==by 0x4E5A2B6: do_dtls1_write (d1_pkt.c:1592) ==17767==by 0x4E5DA69: dtls1_do_write (d1_both.c:359) ==17767==by 0x4E56DF6: dtls1_accept (d1_srvr.c:426) ==17767==by 0x4E5B85C: dtls1_read_bytes (d1_pkt.c:787) ==17767==by 0x4E45ECF: ssl3_read_internal (s3_lib.c:4273) ==17767==by 0x215E3EF4: __rtp_recvfrom (res_rtp_asterisk.c:2019) ==17767==by 0x215E431E: rtp_recvfrom (res_rtp_asterisk.c:2094) ==17767==by 0x215ED620: ast_rtp_read (res_rtp_asterisk.c:4127) ==17767==by 0x5529D2: ast_rtp_instance_read (rtp_engine.c:314) ==17767==by 0x114A7838: sip_rtp_read (chan_sip.c:8198) ==17767==by 0x114A7FE7: sip_read (chan_sip.c:8295) ==17767==by 0x47D254: __ast_read (channel.c:4054) ==17767==by 0x47EFFD: ast_read (channel.c:4408) ==17767==by 0x476B8F: ast_safe_sleep_conditional (channel.c:1702) 2014-12-10 11:38 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: After add check get crash 2014-12-10 11:18 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Looks like need add some check to return code len 2014-12-10 11:06 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Sorry. Line 1244 is OPENSSL_assert(s-d1-w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH == (unsigned int)s-init_num); 2014-12-10 11:05 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: (gdb) p s-d1-w_msg_hdr.msg_len $2 = 0 (gdb) p s-init_num $3 = 0 2014-12-10 10:59 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Get again ASSERT in d1_both.c:1244 OPENSSL_assert(s-d1-w_msg_hdr.msg_len + ((s-version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned int)s-init_num); } 2014-12-10 6:32 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Hello. I begin test you patch. I attach to mail patched version of you patch wthat may clear added current SRPM of Centos 6 2014-12-03 5:16 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Thanks! I need time to test it... i will try answer at this week 2014-12-02 19:37 GMT+03:00 Matt Caswell via RT r...@openssl.org: On Tue Dec 02 17:31:05 2014, v.badal...@open-bs.ru wrote: if you send patch i can add it to SRPM build and try results The patch is attached. However you may have problems with this approach. I have built the patch for 1.0.1e (which is the version you originally said you were running). However any additional patches that have been applied to the SRPM could cause the patch to fail to apply (and it is quite a large patch). I can also supply a patch against the latest 1.0.1j or OpenSSL_1_0_1-stable from git if you prefer. Matt -- С уважением,
Re: [openssl-dev] License compatibility: OpenSSL and Apache v2
This is something I would like to be contributed to OpenSSL. Sure, I'm talking about new engine and new files. Great, thanks. But, if for some reasons licensing of it will be possible under Apache v2 only - what issues could it cause? Impossible to say for sure. Maybe no issues. Maybe a hassle. The devil is in the details, as the old saying goes. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] More POODLE issues
Now POODLE is hitting TLS http://www.computerworld.com/article/2857274/security0/poodle-flaw-tls- itbwcw.html Any fixes in the works? As has already been covered in the openssl-dev list. OpenSSL does not have this defect. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] More POODLE issues
On Wed, Dec 10, 2014 at 09:51:15AM -0700, The Doctor wrote: Now POODLE is hitting TLS http://www.computerworld.com/article/2857274/security0/poodle-flaw-tls-itbwcw.html Any fixes in the works? As already said previously, openssl is not affected by this. kurt ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] More POODLE issues
On 10/12/14 16:51, The Doctor wrote: Now POODLE is hitting TLS http://www.computerworld.com/article/2857274/security0/poodle-flaw-tls-itbwcw.html Any fixes in the works? See my response to this yesterday on openssl-users: https://mta.opensslfoundation.net/pipermail/openssl-users/2014-December/33.html In summary OpenSSL is not vulnerable to this. Matt ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext
Excellent. My summary is: - valgrind complaints about 1.0.1 OpenSLL are extremely unlikely to affect my program in operation (you will probably say will not affect) Well, as there is suggestion of what I would say, I would only say that it's false positive. - when OpenSLL 1.0.2 eventually percolates through to Ubuntu and Fedora valgrind will stop complaining. Another alternative is that they recognize it as bug worthy fixing, valgrind or OpenSSL. Even though I argue that it's valgrind bug, I'm ready to assist in addressing the issue on OpenSSL side. In other words try to report it to your favorite distro vendor. Refer to this ticket. But for now, I'm dismissing the case. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
Personally i am willing to put enough trust in the OpenSSL team *even insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE' and leave the task of deciding what is VULNERABLE up to you. That is not a responsibility we want. No how, no way. It is enough to be responsible for the code. There are better alternatives, including bettercrypto.org and another proposal from RedHat to have site/distro-specific 'profiles' ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT r...@openssl.org wrote: Salz, Rich rs...@akamai.com wrote: |I think magic names -- shorthands -- are a very bad idea. \ I _completely_ disagree. | They are point-in-time statements whose meaning evolves, \ |if not erodes, over time. Because i don't think that a normal user, or even normal administrators and programmers is and are willing or even capable to understand what they are doing. You are almost certainly far better qualified to make this decision than most administrators. Nevertheless, if upgrading OpenSSL from version X to version Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, there are going to be angry phone calls from users whose browser or application has stopped working. It is the administrator who is going to get those phone calls, not you, and the decision of whether to enable an obsolete ciphersuite or to force the user/programmer to update is a political decision that you can’t make on their behalf. So there’s bettercrypto.org and there’s Qualys and there’s this BCP document that the UTA working group at the IETF is writing, but ultimately we can’t shove security down people’s throat - just make good tools for them and provide (hopefully) good advice. Yoav ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT r...@openssl.org wrote: Salz, Rich rs...@akamai.com wrote: |I think magic names -- shorthands -- are a very bad idea. \ I _completely_ disagree. | They are point-in-time statements whose meaning evolves, \ |if not erodes, over time. Because i don't think that a normal user, or even normal administrators and programmers is and are willing or even capable to understand what they are doing. You are almost certainly far better qualified to make this decision than most administrators. Nevertheless, if upgrading OpenSSL from version X to version Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, there are going to be angry phone calls from users whose browser or application has stopped working. It is the administrator who is going to get those phone calls, not you, and the decision of whether to enable an obsolete ciphersuite or to force the user/programmer to update is a political decision that you can’t make on their behalf. So there’s bettercrypto.org and there’s Qualys and there’s this BCP document that the UTA working group at the IETF is writing, but ultimately we can’t shove security down people’s throat - just make good tools for them and provide (hopefully) good advice. Yoav ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3607] nistz256 is broken.
Attached. A little bit worse performance on some CPUs. I also took
opportunity to harmonize ecp_nistz256_from_mont by applying same pattern
for reduction. The patch is cumulative, i.e. is not incremental to
previously posted one[s], and addresses both problems, originally
reported one and discovered in the course. Patch to ecp_nistz256.c
referred above doesn't matter.
When applying just that patch, the original test case fails. Specially
this test code (C++):
...
Just to check that I'm not doing anything stupid (which is always a
distinct possibility), here are the .pl[1] and resulting .s[2] file
that I ended up with.
[1]
https://drive.google.com/file/d/0B_OzbbAp1CG5OVdVc196QmV3bG8/view?usp=sharing
[2]
https://drive.google.com/file/d/0B_OzbbAp1CG5Z3NoZzBqU09scFE/view?usp=sharing
Patching went wrong for you. As you seem to operate in 1.0.2 context
attached is corresponding ecp_nistz256.pl.
#!/usr/bin/env perl
##
##
# Copyright 2014 Intel Corporation #
##
# Licensed under the Apache License, Version 2.0 (the License);#
# you may not use this file except in compliance with the License. #
# You may obtain a copy of the License at#
##
#http://www.apache.org/licenses/LICENSE-2.0 #
##
# Unless required by applicable law or agreed to in writing, software#
# distributed under the License is distributed on an AS IS BASIS, #
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. #
# See the License for the specific language governing permissions and#
# limitations under the License. #
##
##
##
# Developers and authors: #
# Shay Gueron (1, 2), and Vlad Krasnov (1) #
# (1) Intel Corporation, Israel Development Center #
# (2) University of Haifa #
# Reference:#
# S.Gueron and V.Krasnov, Fast Prime Field Elliptic Curve Cryptography with#
# 256 Bit Primes #
##
##
# Further optimization by ap...@openssl.org:
#
# this/original
# Opteron +12-49%
# Bulldozer +14-45%
# P4 +18-46%
# Westmere +12-34%
# Sandy Bridge +9-35%
# Ivy Bridge +9-35%
# Haswell +8-37%
# Broadwell +18-58%
# Atom +15-50%
# VIA Nano +43-160%
#
# Ranges denote minimum and maximum improvement coefficients depending
# on benchmark.
$flavour = shift;
$output = shift;
if ($flavour =~ /\./) { $output = $flavour; undef $flavour; }
$win64=0; $win64=1 if ($flavour =~ /[nm]asm|mingw64/ || $output =~ /\.asm$/);
$0 =~ m/(.*[\/\\])[^\/\\]+$/; $dir=$1;
( $xlate=${dir}x86_64-xlate.pl and -f $xlate ) or
( $xlate=${dir}../../perlasm/x86_64-xlate.pl and -f $xlate) or
die can't locate x86_64-xlate.pl;
open OUT,| \$^X\ $xlate $flavour $output;
*STDOUT=*OUT;
if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 21`
=~ /GNU assembler version ([2-9]\.[0-9]+)/) {
$avx = ($1=2.19) + ($1=2.22);
$addx = ($1=2.23);
}
if (!$addx $win64 ($flavour =~ /nasm/ || $ENV{ASM} =~ /nasm/)
`nasm -v 21` =~ /NASM version ([2-9]\.[0-9]+)/) {
$avx = ($1=2.09) + ($1=2.10);
$addx = ($1=2.10);
}
if (!$addx $win64 ($flavour =~ /masm/ || $ENV{ASM} =~ /ml64/)
`ml64 21` =~ /Version ([0-9]+)\./) {
$avx = ($1=10) + ($1=11);
$addx = ($1=12);
}
if (!$addx `$ENV{CC} -v 21` =~ /(^clang version|based on LLVM) ([3-9])\.([0-9]+)/) {
my $ver = $2 + $3/100.0; # 3.1-3.01, 3.10-3.10
$avx = ($ver=3.0) + ($ver=3.01);
$addx = ($ver=3.03);
}
$code.=___;
.text
.extern OPENSSL_ia32cap_P
# The polynomial
.align 64
.Lpoly:
.quad 0x, 0x, 0x, 0x0001
# 2^512 mod P precomputed for NIST P256 polynomial
.LRR:
.quad 0x0003, 0xfffb, 0xfffe, 0x0004fffd
.LOne:
.long 1,1,1,1,1,1,1,1
.LTwo:
.long 2,2,2,2,2,2,2,2
.LThree:
.long 3,3,3,3,3,3,3,3
.LONE_mont:
.quad 0x0001, 0x,
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On 12/10/2014 12:59 PM, Salz, Rich via RT wrote: Personally i am willing to put enough trust in the OpenSSL team *even insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE' and leave the task of deciding what is VULNERABLE up to you. That is not a responsibility we want. No how, no way. It is enough to be responsible for the code. this is disappointing. The OpenSSL team is in the best position to provide sane and simple defaults/profiles, and to have those mechanisms be upgraded smoothly without applications or admins needing to know about them. Requiring administrators to tweak every application that uses TLS is a losing battle, and pretty much guarantees that we'll be keeping users with less-secure or outdated configurations. Programs which use the OpenSSL library generally just want to flip a switch and know that they've turned on security, instead of trying to expose dozens of complex controls to the user or administrator. The closer OpenSSL can come to that ideal, the more likely its users will have reasonably strong crypto without having to learn the dirty dirty details and history of TLS and its predecessors. There are better alternatives, including bettercrypto.org and another proposal from RedHat to have site/distro-specific 'profiles' I am happy that both of these things exist, but they don't preclude OpenSSL providing something and they shouldn't need to be as complex as they are. The configuration recommendations in bettercrypto.org are *at best* an ugly workaround to the lack of sane and simple mechanisms in the projects it supports. I'd love to see a version of bettercrypto.org that only has to say to configure OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE --dkg signature.asc Description: OpenPGP digital signature ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On 12/10/2014 12:59 PM, Salz, Rich via RT wrote: Personally i am willing to put enough trust in the OpenSSL team *even insofar* as i now do 'set ssl-protocol=ALL,-VULNERABLE' and leave the task of deciding what is VULNERABLE up to you. That is not a responsibility we want. No how, no way. It is enough to be responsible for the code. this is disappointing. The OpenSSL team is in the best position to provide sane and simple defaults/profiles, and to have those mechanisms be upgraded smoothly without applications or admins needing to know about them. Requiring administrators to tweak every application that uses TLS is a losing battle, and pretty much guarantees that we'll be keeping users with less-secure or outdated configurations. Programs which use the OpenSSL library generally just want to flip a switch and know that they've turned on security, instead of trying to expose dozens of complex controls to the user or administrator. The closer OpenSSL can come to that ideal, the more likely its users will have reasonably strong crypto without having to learn the dirty dirty details and history of TLS and its predecessors. There are better alternatives, including bettercrypto.org and another proposal from RedHat to have site/distro-specific 'profiles' I am happy that both of these things exist, but they don't preclude OpenSSL providing something and they shouldn't need to be as complex as they are. The configuration recommendations in bettercrypto.org are *at best* an ugly workaround to the lack of sane and simple mechanisms in the projects it supports. I'd love to see a version of bettercrypto.org that only has to say to configure OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE --dkg signature.asc Description: PGP signature ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
I'd love to see a version of bettercrypto.org that only has to say to configure OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE That can happen but not by embedding magic strings into code. See http://rt.openssl.org/Ticket/Display.html?id=3266 http://rt.openssl.org/Ticket/Display.html?id=3299 ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On Dec 10, 2014, at 9:31 PM, Daniel Kahn Gillmor via RT r...@openssl.org wrote: I'd love to see a version of bettercrypto.org that only has to say to configure OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE” I’d be much happier if that string was called “best_practice_2015”, and when a future version of OpenSSL added “best_practice_2017”, there would also be a wiki (or a site like bettercrypto) telling administrators what might happen if they switch (“you’ll lose support for all versions of Chrome below 52”) ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On Dec 10, 2014, at 9:31 PM, Daniel Kahn Gillmor via RT r...@openssl.org wrote: I'd love to see a version of bettercrypto.org that only has to say to configure OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE” I’d be much happier if that string was called “best_practice_2015”, and when a future version of OpenSSL added “best_practice_2017”, there would also be a wiki (or a site like bettercrypto) telling administrators what might happen if they switch (“you’ll lose support for all versions of Chrome below 52”) ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl-dev] invalid certificate setup for mta.opensslfoundation.net
Kind of humorous that I get cert errors when connecting to https://mta.opensslfoundation.net/ URLs. The cert itself looks to be very poorly formed (like someone who doesn't understand how to create certs set it up). Cert information: CN: mta O: NONE OU: NONE Issued by: CN: mta O: mta OU: NONE --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3628] [PATCH] NDEBUG macro and redundant strings
During the development process we found that libcrypto contains a lot of redundant strings in the final binary even when it was built with Debugging turned off. These strings undesirably reveal absolute paths to the source files of libcrypto. The paths usually contain private information, e.g. /Users/john.johnson/Projects/libssl/crypto/evp/encode.c. That happens because several macros, like OPENSSL_malloc(), OPENSSL_assert() etc., pass __FILE__ as an operand to the underlying routines. I'd like to propose a new macro, NDEBUG, which turns on/off passing __FILE__ as an argument. Thanks, Alex Komnin. openssl-ndebug.patch Description: Binary data ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] invalid certificate setup for mta.opensslfoundation.net
Kind of humorous that I get cert errors when connecting to https://mta.opensslfoundation.net/ Glad you appreciate the humor :) We didn't want to wait for the CA to reply before making the switch. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl-dev] Any way to create a large encrypted finish message?
Hi I am working on issue involving openssl TLS 1.2 finish message decryption. I was wondering if anyone can tell me how I can generate encrypted handshake message (client finish message) larger than 64 bytes (using RSA AES256-SHA/ AES128-SHA/DES-CBC3-SHA). You suggestion is greatly appreciated. Thank you Vyas ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] More POODLE issues
Purely to give an independent answer - I'm not one of the openssl developers and I've tested this. As expected the ssl3 implementation allows any padding but the invalid padding is rejected with an alert when using TLS. So as Matt has said, it's not a problem for openssl. Cheers Rich. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On 10 December 2014 at 19:26, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: Programs which use the OpenSSL library generally just want to flip a switch and know that they've turned on security, instead of trying to expose dozens of complex controls to the user or administrator. The closer OpenSSL can come to that ideal, the more likely its users will have reasonably strong crypto without having to learn the dirty dirty details and history of TLS and its predecessors. My experience suggests that while that might be what some developers want, that's not what users want. They expect that if it works in the browser it should work everywhere - even when the browser is jumping through hoops like fetching missing intermediate certificates, downgrading security etc. If the world were perfect and the browsers didn't do this then life would be a lot easier. Cheers Rich. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3627] Enhancement request: add more Protocol options for SSL_CONF_CTX
On 10 December 2014 at 19:26, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: Programs which use the OpenSSL library generally just want to flip a switch and know that they've turned on security, instead of trying to expose dozens of complex controls to the user or administrator. The closer OpenSSL can come to that ideal, the more likely its users will have reasonably strong crypto without having to learn the dirty dirty details and history of TLS and its predecessors. My experience suggests that while that might be what some developers want, that's not what users want. They expect that if it works in the browser it should work everywhere - even when the browser is jumping through hoops like fetching missing intermediate certificates, downgrading security etc. If the world were perfect and the browsers didn't do this then life would be a lot easier. Cheers Rich. ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3543] Remove #ifdef LINT fluff
master 5cf3795 RT3543: Remove #ifdef LINT Author: Rich Salz rs...@openssl.org Date: Tue Sep 23 13:23:09 2014 -0400 RT3543: Remove #ifdef LINT I also replaced some exit/return wrappers in various programs (from main) to standardize on return. Reviewed-by: Richard Levitte levi...@openssl.org -- Rich Salz, OpenSSL dev team; rs...@openssl.org ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
