[[EMAIL PROTECTED] - Fri Jun 7 14:22:15 2002]:
even though Netscape still works, this should be considered a bug
since
IE is now broken when in the past it worked fine
It is a bug in IE, not in OpenSSL. Note that the problem is avoided
when using RC4 ciphersuites, and these are typically
[[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]:
[...]
It appears the openssl guys goofed in 0.97beta. The prototype for the
d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this:
d2i_RSAPrivateKey(RSA **a, unsigned char **pp, long length);
ie., without a const on
If you run 's_client' with the '-debug' option, you will see that
this server (ebmx.extra.daimlerchrysler.com:443) sends a cleartext
string starting with 'HTTP/' when it is supposed to send SSL 3.0
encrypted data. This is where the 'wrong version number' error
message comes from -- 0x54 0x54
The CBC vulnerability countermeasure that cannot be handled by some
broken SSL/TLS implementations can now be disabled with the new
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option, which is also part of
SSL_OP_ALL and thus will be automatically enabled in many OpenSSL
applications designed to be
Status was (automatically?) changed from resolved to open by
additional correspondance. The actual status is resolved.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Not a bug in OpenSSL, should have been sent to openssl-users
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
Not an OpenSSL bug, this should be discussed elsewhere (openssl-users).
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List
Avery Pennarun [EMAIL PROTECTED]:
On Thu, Jun 13, 2002 at 01:26:42PM +0200, Bodo Moeller via RT wrote:
[[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]:
It appears the openssl guys goofed in 0.97beta. The prototype for the
d2i_RSAPrivateKey function in 0.9.6c, which I use, is like
I have totally removed that '#ifdef' condition, now we include
string.h on all systems (which is what we do in most other header
files anyway, so this cannot break anything unless it is broken
elsewhere too).
__
OpenSSL Project
While the AES cipher suites from draft-ietf-tls-ciphersuite-06.txt are
disabled by default and not part of ALL (the AESdraft group alias
can be used to enable them), they might be accidentily enabled by using
cipher suite strings such as RSA. The reason for disabling them
unless explicitly
RFC3268 makes the AES cipher suites official, so the AESdraft problem
no longer exists.
However, it would still be a good idea to create a NONE cipher suite
group alias because it is useful in the other scenarios given in the
problem description.
Martin Sjögren:
When you write a zero-length string with SSL_write, OpenSSL signals a
protocol-violating EOF even though no such thing has happened. My
guess is that a zero returned is misinterpreted somewhere though I have
not had time to dig through the source.
SSL_write() with length 0
Lutz Jaenicke:
I have already worked in the cipher selection routines yesterday with
respect to PR#130. I will add an appropriate NOTDEFAULT selection
keyword that will cover cipher suites not selected by default.
As this is a new feature I intend to only add it to 0.9.7 (and later).
Often, the cert/key directory is not used at all; otherwise it should be
easy to use symbolic links to get the desired effect. Thus it should be
possible to do without the '--certdir' patch.
A reason for *not* introducing '--certdir' is that the
'--prefix'/'--openssldir' situation is already a
In similar configurations with gcc version 2.95.2, I observe none of
these problems. This suggests that the problems may be due to compiler
bugs in your gcc version; please try gcc 2.95.2 or a different newer
release and report if the problems persist.
This is not a report on an actual problem in OpenSSL, and there has been
no updated to the original request since June 25th; so nothing to do for
us about this at the moment.
__
OpenSSL Project
apps/ca.c has now been changed as suggested; thanks for the patch.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
On Fri, Jul 19, 2002 at 10:39:21AM +0200, Martin Sjögren via RT wrote:
Note that it's perfectly valid to call write(2) with an empty string [...]
This is true only for regular files. According to the The Single UNIX
Specification, Version 2, and related write() manual pages on systems
such
On Tue, Jul 30, 2002 at 06:08:46PM +0300, Arne Ansper wrote:
attached is a patch for openssl-0.9.6e that removes the usage of die.
please review it carefully. all changes are localized but the action i
take in some places where error reporting is not possible might be little
bit wrong (i.e.
Patch applied.
Please send unified or context diffs in the future.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List
This problem is fixed in 0.9.6f. (You might prefer to wait for 0.9.6g,
which will be out very soon.)
__
OpenSSL Project http://www.openssl.org
Development Mailing List
On Tue, Aug 13, 2002 at 12:28:06PM +0200, via RT wrote:
Line 14 in util/pod2mantest should read:
try_without_dir=true
otherwise 'first iteration' in the for-loop is never executed.
The code as it currently is doesn't make too much sense
(try_without_dir could be totally abolished), but
We now call pod2man directly if this works (without explicit invocation
of perl).
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Ticket 207 is resolved, too (if pod2mantest finds a working pod2man,
this is now called directly without explicitly invoking perl).
__
OpenSSL Project http://www.openssl.org
Development Mailing
[EMAIL PROTECTED]:
Failure!
[...]
Failed! bc: stack empty
Can you condense the bc test file into a single-line test so that we can
automatically test if bc has this bug?
__
OpenSSL Project
[levitte - Thu Aug 15 16:04:15 2002]:
[guest - Thu Aug 15 14:21:45 2002]:
Since isalist displays the available native instruction sets ordered
in the sense of best performance, I guess the best choice for target
would be the leftmost in the list displayed. Under no circumstances
should the
FIPS PUB 180-2, which defines SHA-256, SHA-384 and SHA-512 in addition
to SHA-1, has been published on August 1:
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf
These new hash algorithms should be added to the 0.9.8-dev branch.
Can you elaborate what you think is buggy?
'make test' still succeeds if you substitute 10 for
SSL3_RT_MAX_PLAIN_LENGTH in ssl3_write_bytes (ssl/s3_pkt.c),
which sort of simulates very long certificate chains.
There is a limit to certificate chains (SSL_MAX_CERT_LIST_DEFAULT by
Please obtain OpenSSL 0.9.6g. OpenSSL 0.9.6d was the last version
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
Thanks, the bug has been fixed now in 0.9.6-stable, 0.9.7-stable and
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List
This SSLeay/OpenSSL behaviour appears to be correct; from RFC 2246:
session_id_length
This field must have a value of either zero or 16. If zero, the
client is creating a new session. If 16, the session_id field
All (most?) similar cases clear the 'init' flag *after* having set up
the data structures appropriately, e.g. see ssl/s3_meth.c.
No locking should be needed because the assignments are idempotent.
__
OpenSSL Project
Sorry, the RFC 2246 quote was incorrect -- the value 16 is for
SSL 2.0 session IDs only, and the SSLeay/OpenSSL interpretation
indeed is buggy.
__
OpenSSL Project http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
On Thu, Sep 19, 2002 at 06:28:16PM -0700, Patrick McCormick wrote:
No locking should be needed because the assignments are idempotent.
However, the assignments are not atomic. The following unprotected
operation:
if (init)
{
memcpy((char *)SSLv3_server_data,(char
On Fri, Sep 20, 2002 at 06:19:48PM -0700, Patrick McCormick wrote:
Here's one step by step scenario.
You are absolutely right about the bug. I somehow had not realized
that the memcpy accesses the same struct as the following assignments.
We need a lock to fix this.
--
Bodo Möller [EMAIL
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
On Tue, Sep 24, 2002 at 03:47:14PM -0700, Patrick McCormick wrote:
Many thanks for putting in a lock. However, the race condition has not been
eliminated.
[...]init must be checked after the lock is entered in order to
prevent the client_data setup from happening twice. So,
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
On Wed, Sep 25, 2002 at 09:22:20PM +0200, Patrick McCormick via RT wrote:
I was looking at some other code in the ssl directory, and the *_method
functions in the *_meth.c files appear to use the same initialization idiom
I believe they need to be thread-protected also.
Fixed.
--
Bodo
The AES library (0.9.7-dev, 0.9.8-dev) abuses assert() to check
for invalid function parameters.
For aes_cbc.c, this includes the case where 'length' is not
a multiple of AES_BLOCK_SIZE. For consistency with other ciphers,
the library should not require 'length' to be a multiple
of the block
Thanks for the report. Actually by coincidence I noticed this typo
(which has been in OpenSSL for quite a while) a couple of days ago and
corrected it.
__
OpenSSL Project http://www.openssl.org
On Fri, Jan 31, 2003 at 08:12:41AM +0100, Cameron Gregory via RT wrote:
for num 15 .. always get the same result.. and it's larger than
expected...
Reason: The internal OpenSSL function 'probable_prime' (in
crypto/bn/bn_prime.c) uses a built-in list of small primes for sieving
out candidate
On Wed, Dec 04, 2002 at 10:16:37AM -0500, Jack Lloyd wrote:
I asked Eric Rescorla, and he agreed the section of the TLS RFC was
definitely unclear, but he wasn't totally sure which way it should go as
far as stripping any leading 0s before using the shared secret to generate
keys. It
In OpenSSL, the 'info_callback' gets a 'const SSL *' argument;
the application in question used 'SSL *', which caused the compiler
warning for 0.9.7 (earlier OpenSSL versions did not declare the
'info_callback' argument list at all).
The problem has been solved by changing the application
Note that SSL_get_error() is not meant to be used on SSL_shutdown()
return values (although it would be good to have some API that behaves
similarly to SSL_read, SSL_write, SSL_do_handshake etc. in this respect).
If SSL_shutdown() always returns 0 when called multiple times, this is
probably
Removing the +Olibcalls option appears to have solved this problem
(apparently some compiler bug, but reportedly the option is deprecated
anyway).
__
OpenSSL Project http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
This is not an OpenSSL bug; you should install gcc, and possibly
remove /usr/ucb from the PATH.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL
On Wed, Feb 19, 2003 at 06:10:13PM +0100, Ralph via RT wrote:
on AIX (64bit) I noticed a major problem with non-blocking sockets.
Methods SSL_connect(), SSL_read() and SSL_write() should return
SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE if they need to complete
their tasks but the socket
Ralph via RT [EMAIL PROTECTED]:
But so far, I can tell you that when SSL_get_error() returns
SSL_ERROR_SYSCALL and you inspect errno, it tells EWOULDBLOCK or EAGAIN.
By repeating the SSL_* call as long as this condition occurs, I can
overcome the problem and the SSL handshake and
Terry Kennedy via RT [EMAIL PROTECTED]:
I downloaded and configured/built/tested 0.9.7a on BSD/OS 4.3.1 with no
problems, using the following commands:
[...]
The tests completed with no errors. I then applied the blinding patch from
http://www.openssl.org//news/secadv_20030317.txt, did
On Mon, Mar 31, 2003 at 03:01:10PM +0200, Richard Levitte via RT wrote:
Could you please download the latest 0.9.6 snapshot and check that
it works for you? As far as I understand, the MT issue has been
adressed, but solved in a different manner.
The latest snapshots have not been fixed,
No patch should be required, not even AIX can be that weird. An
official specification for select() is available at
http://www.opengroup.org/onlinepubs/007908799/xsh/select.html
__
OpenSSL Project
[bodo - Tue Apr 1 16:58:47 2003]:
No patch should be required, not even AIX can be that weird. An
official specification for select() is available at
http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/commtrf1/select.htm
This was the wrong link, I meant the www.opengroup.org
[EMAIL PROTECTED] - Mon Mar 31 17:14:12 2003]:
The latest snapshots have not been fixed, some more patience is
required ...
The next round of snapshots (20030402, to appear at
ftp://ftp.openssl.org/snapshot;type=d in about six hours)
should solve the multi-threading problems. Please test
Tom Wu via RT [EMAIL PROTECTED]:
Bodo Moeller via RT wrote:
The next round of snapshots (20030402, to appear at
ftp://ftp.openssl.org/snapshot;type=d in about six hours)
should solve the multi-threading problems. Please test them when they
are available.
The good news is that the fix
Tom Wu via RT [EMAIL PROTECTED]:
(Bodo Moeller) via RT wrote:
Tom Wu via RT [EMAIL PROTECTED]:
Is there any established wisdom on the security implications of
refreshing the blinding factor? Assuming that the initial blinding
value had sufficient entropy and was unknown to an attacker
Thanks for the report. This has now been corrected in the CVS.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
This transaction appears to have no content
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
[EMAIL PROTECTED] - Mi. 04. Jun. 2008, 08:08:00]:
We have addressed the following issue in Mac OS X:
RSA_padding_check_SSLv23 has a bug in the loop that verifies the
presence of eight consecutive 0x03 padding bytes just before the null
marker signifying the end of the padding. The
On Thu, Jan 8, 2009 at 4:01 PM, Felix von Leitner via RT r...@openssl.org
wrote:
[...] Apart from the inherent
wrongness of doing recursive make (see
http://miller.emu.id.au/pmiller/books/rmch/ and note that the
traditionally cited reason for doing recursive makes, namely being able
to go
[...@mindrot.org - Fr. 30. Jan. 2009, 11:52:17]:
This patch adds a -hex option to the rand app. E.g.
$ openssl rand -hex 8
d203552d5eb39e76
What is the rationale of not having a newline at the end? It's text,
after all?
Bodo
What is the rationale of not having a newline at the end? It's text,
after all?
no rationale, just an oversight.
So ... I was going to add the newline while working on the patch, but
then it occurred to me as you said this comes from OpenBSD CVS I might
be breaking something there. No
we'll cope ;)
Here's my version of the patch. Let me know if it looks OK for you.
Bodo
Index: CHANGES
===
RCS file: /e/openssl/cvs/openssl/CHANGES,v
retrieving revision 1.1468
diff -u -r1.1468 CHANGES
--- CHANGES 28 Jan
Thanks for the correction. This will be in the next snapshot.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List
Thanks, this will be fixed in the next snapshots.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
Thanks, this should be fixed in the next snapshots.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
Current snapshots use a more thorough locking approach that takes into
account inconsistent cache views on multi-processor or multi-core
systems (where consistency can be reached by obtaining locks). The
application has to call CRYPTO_set_id_callback() for OpenSSL to work
properly.
On Sep 6, 2010, at 10:39 AM, Darryl Miles wrote:
The only user of these field(s) is libssl.so itself. The exact
meaning, usage and interpretation of the field(s) is a matter of
implementation detail which is encapsulated and presented to the
application via the document OpenSSL APIs.
I think from the point of view of both interoperability and security, the
original empty-fragment approach is best when a cipher using 8-byte blocks
has been negotiated (usually 3DES), while 1 / n-1 splitting is better for
interoperability and fully adequate for large block sizes (AES).
This issue has been reported in
http://rt.openssl.org/Ticket/Display.html?id=2813 (and fixed).
__
OpenSSL Project http://www.openssl.org
Development Mailing List
This appears to be a duplicate of ticket #2813 (which is fixed, but missed the
1.0.1c release by one day).
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Thanks for the submission!
It seems that the BN_MONT_CTX-related code (used in crypto/ecdsa for
constant-time signing) is entirely independent of the remainder of the patch,
and should be considered separately.
Regarding your reference 'S.Gueron and V.Krasnov, Fast Prime Field Elliptic
Curve
This initialization is used for selecting a code path that would use
ADCX/ADOX
instructions when the processor supports them. The outcome depends only on
the appropriate CPUID bits. Therefore, there is no “thread-safe” issue
(because
any thread would select the same path).
I understand that
Here is an updated version of the patch.
Addressing a) pointer to the function (to select ADCX/ADOX) and b)
multiple points addition
There is (only) ~1% performance deterioration in due to the pointer being
passed now, instead of (originally) being static. You can choose which
style is
While if (functiona==NULL || functionb==NULL) { asssign functiona,
functionb } can be unsafe, I'd argue that if (functiona==NULL) { assign
functiona } followed by if (functionb) { assign functionb } is.
We're implicitly assuming here that (thanks to alignment, etc.) each
pointer can be
The -dsaparam option to dhparam converts DSA parameters to DH and sets the
length parameter.
Note that this isn't actually safe to do in general; it's OK for ephemeral DH
with no re-use of private keys.
A shortcoming of our internal format (following from a similar shortcoming of
the TLS DH
For the record, I have reviewed Adam's versions of the code before these were
posted here, and Adam has resolved the problems that I pointed out. As of the
latest patch, I think the code is suitable for inclusion in OpenSSL. The final
missing part is support that makes it easy to build with or
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Sorry, my fault. I'll fix this.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
The fix will be in the next version.
Note that OpenSSL servers aren't expected to see TLS_FALLBACK_SCSV in
normal operation (the code is sufficiently version tolerant, etc.), and if
you've enabled TLS 1.2, there isn't even a higher protocol version that the
client could be falling back from, so
82 matches
Mail list logo
