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
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
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
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
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
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,
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
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
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
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 +
(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
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
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
Test, please ignore
___
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
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
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
|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
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
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
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
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
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:
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
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:
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
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.
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.
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.
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
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.
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.
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
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
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
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:
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.
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
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.
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.
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
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
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
--
42 matches
Mail list logo
