Re: [openssl-users] Bleichenbacher Vulnerability

[Bodo Moeller]

Hanno Böck :

> I was wondering when exactly (the version) was the OpenSSL library
> > patched for the Bleichenbacher Vulnerability?
>


> It was probably fixed some time in the late 90s. However according to
> https://www.openssl.org/news/changelog.html
>
> the countermeasures were accidentally removed in some 0.9.6 version.
>

The original countermeasure had been present back in SSLeay, but it also
had never actually worked at all until I accidentally removed it from
s3_srvr.c in 0.9.5 (not 0.9.6) and put it back in 0.9.6g with a fix. The
original implementation would have generated a randomized master secret but
then still ended the handshake with an error alert, thus achieving nothing.
The main takeaway from that is that good source code comments are
invaluable, because reverse-engineering the intentions underlying the code
can be particularly hard if said code doesn't actually do what it's
intended to do :-)

Of course, in the end the 0.9.6g fix didn't achieve too much (other than
adding a source code explaining what that randomization was all about),
because the RFC 2246 countermeasure was still subject to the
Klíma-Pokorný-Rosa attack discovered later (and first addressed in 0.9.6j).
And of course, as you've already pointed out, that still left timing
attacks.

> Wanted to know this, since my custom application uses an older version
> > of OpenSSL, and I wanted to be sure that it is not affected.
>


> Don't do this. Switch to a supported version. There's no way you will
> plausibly keep this secure. Bleichenbacher attacks may be the least of
> your worries.


I completed agree. If you're using an "older version of OpenSSL", likely
it's subject to a few vulnerabilities with and without logos, and thus is
not what you should be running today.

Bodo
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: SSL_MODE_SEND_FALLBACK_SCSV option

[Bodo Moeller]

Florian Weimer fwei...@redhat.com:

The purpose of the option is to make totally broken applications a bit less
 secure (when they happen to certain servers).


I'd claim it's meant to make totally broken applications a bit *more*
secure :-)


 From my point of view, there is only one really good reason to have this
 client-side option—so that you can test the server-side support.  That's
 why I implemented it for OpenJDK as well.  Application should *never* use
 it because it does not really solve anything.  If you have fallback code,
 your application is still insecure.


Right, ideally testing will be the only use of this option.

Bodo

Re: Patch to mitigate CVE-2014-3566 (POODLE)

[Bodo Moeller]

mancha manc...@zoho.com:

 Bodo Moeller wrote:


 I certainly think that the claim that new SCSV does not help with
  [the SSL 3.0 protocol issue related to CBC padding] at all is wrong,
  and that my statement that TLS_FALLBACK_SCSV can be used to counter
  CVE-2014-3566 is right.



 The point is more nuanced and boils down to there being a difference
 between CVE-2014-3566 (SSLv3's vulnerability to padding oracle attacks
 on CBC-mode ciphers) and POODLE (an attack that exploits CVE-2014-3566
 by leveraging protocol fallback implementations to force peers into
 SSLv3 communication).

 TLS_FALLBACK_SCSV does not fix or mitigate CVE-2014-3566. With or
 without 0x5600, SSLv3 CBC-mode cipher usage is broken.


Sure, I understand that. Disabling SSL 3.0 doesn't fix CVE-2014-3566
either, because SSL 3.0 remains just as broken even if you don't use it. In
both cases (TLS_FALLBACK_SCSV or disabling SSL 3.0), it's about avoiding
unwarranted use of SSL 3.0 to avoid the vulnerability.


Chrome, Firefox, etc. intentionally implement protocol fallback (which I
 presume is why there are no MITRE CVE designations for the behavior per
 se). However, one can make a strong case protocol fallback
 implementations that are MITM-triggerable deserve CVE designations.


I agree. If there was such a CVE, that would be the main CVE to point to
here.

Bodo

Re: Patch to mitigate CVE-2014-3566 (POODLE)

[Bodo Moeller]

Jeffrey Walton noloa...@gmail.com:


 Is there a way to compile without the patch? I think I would rather
 'config no=ssl3' and omit the additional complexity. Its additional
 protocol complexity and heartbleed is still fresh in my mind.


There's no way to compile without the patch, other than reverting it. It's
a tiny amount of extra logic.

Disabling SSL 3.0 is a good idea, but note the TLS_FALLBACK_SCSV also
addresses similar downgrade attacks to TLS 1.1 or TLS 1.0 (when you should
rather be using TLS 1.2).


Also, are there any test cases that accompany the patch? I'm trying to
 figure out when, exactly, SSL_MODE_SEND_FALLBACK_SCSV needs to be set
 (using the sources as a guide).


If you don't use fallback retries (in which you *intentionally* avoid the
latest protocol versions), you don't need to set it at all.

Presumably I should update the documentation to be more explicit about
this. Where did you look for documentation? Do you think that changing the
SSL_set_mode man page (SSL_CTX_set_mode.pod) would be sufficient, or do you
think that adding guidance to ssl.h is equally (or more) important?

Bodo

Re: Use of TLS_FALLBACK_SCSV

[Bodo Moeller]

Salz, Rich rs...@akamai.com:

Disabling ssl3 is a good thing.  But set the fallback because silently
 dropping from tls 1.2 to tls 1.1 is bad.


All this assumes that your client application *does* explicitly fall back
from TLS 1.2 to TLS 1.1, instead of just relying on automatic protocol
version negotiation. If you never do that (and I suspect you don't), your
client has no need for TLS_FALLBACK_SCSV. Do NOT set this, except for
fallback connections that downgrade the protocol version.

Bodo

Re: Patch to mitigate CVE-2014-3566 (POODLE)

[Bodo Moeller]

mancha manc...@zoho.com:


 Any reason for the s_client -fallback_scsv option check to be within an
 #ifndef OPENSSL_NO_DTLS1 block?


Thanks for catching this. No, there's no good reason for that; I should
move it elsewhere.

Bodo

Patch to mitigate CVE-2014-3566 (POODLE)

[Bodo Moeller]

Here's a patch for the OpenSSL 1.0.1 branch that adds support for
TLS_FALLBACK_SCSV, which can be used to counter the POODLE attack
(CVE-2014-3566; https://www.openssl.org/~bodo/ssl-poodle.pdf).

Note well that this is not about a bug in OpenSSL -- it's a protocol issue.
If SSL 3.0 is disabled in either the client or in the server, that is
completely sufficient to avoid the POODLE attack. (Also, there's only a
vulnerability if the client actively falls back to SSL 3.0 in case that TLS
connections don't work -- but many browsers still do that to ensure
interoperability with broken legacy servers.) If you can't yet disable SSL
3.0 entirely, TLS_FALLBACK_SCSV can help avoid the attack, if both the
client and the server support it.

Server-side TLS_FALLBACK_SCSV support is automatically provided if you use
the patch. Clients that do fallback connections downgrading the protocol
version should use SSL_set_mode(ssl, SSL_MODE_SEND_FALLBACK_SCSV) for such
downgraded connections.

The OpenSSL team will follow up with official releases that will include
TLS_FALLBACK_SCSV support. Meanwhile, if you can't simply disable SSL 3.0,
you may want to use this patch.

Bodo
diff --git a/apps/s_client.c b/apps/s_client.c
index 4625467..c2e160c 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -337,6 +337,7 @@ static void sc_usage(void)
BIO_printf(bio_err, -tls1_1   - just use TLSv1.1\n);
BIO_printf(bio_err, -tls1 - just use TLSv1\n);
BIO_printf(bio_err, -dtls1- just use DTLSv1\n);
+   BIO_printf(bio_err, -fallback_scsv - send TLS_FALLBACK_SCSV\n);
BIO_printf(bio_err, -mtu  - set the link layer MTU\n);
BIO_printf(bio_err, -no_tls1_2/-no_tls1_1/-no_tls1/-no_ssl3/-no_ssl2 - 
turn off that protocol\n);
BIO_printf(bio_err, -bugs - Switch on all SSL implementation 
bug workarounds\n);
@@ -617,6 +618,7 @@ int MAIN(int argc, char **argv)
char *sess_out = NULL;
struct sockaddr peer;
int peerlen = sizeof(peer);
+   int fallback_scsv = 0;
int enable_timeouts = 0 ;
long socket_mtu = 0;
 #ifndef OPENSSL_NO_JPAKE
@@ -823,6 +825,10 @@ int MAIN(int argc, char **argv)
meth=DTLSv1_client_method();
socket_type=SOCK_DGRAM;
}
+   else if (strcmp(*argv,-fallback_scsv) == 0)
+   {
+   fallback_scsv = 1;
+   }
else if (strcmp(*argv,-timeout) == 0)
enable_timeouts=1;
else if (strcmp(*argv,-mtu) == 0)
@@ -1235,6 +1241,10 @@ bad:
SSL_set_session(con, sess);
SSL_SESSION_free(sess);
}
+
+   if (fallback_scsv)
+   SSL_set_mode(con, SSL_MODE_SEND_FALLBACK_SCSV);
+
 #ifndef OPENSSL_NO_TLSEXT
if (servername != NULL)
{
diff --git a/crypto/err/openssl.ec b/crypto/err/openssl.ec
index e0554b4..34754e5 100644
--- a/crypto/err/openssl.ec
+++ b/crypto/err/openssl.ec
@@ -71,6 +71,7 @@ R SSL_R_TLSV1_ALERT_EXPORT_RESTRICTION1060
 R SSL_R_TLSV1_ALERT_PROTOCOL_VERSION   1070
 R SSL_R_TLSV1_ALERT_INSUFFICIENT_SECURITY  1071
 R SSL_R_TLSV1_ALERT_INTERNAL_ERROR 1080
+R SSL_R_SSLV3_ALERT_INAPPROPRIATE_FALLBACK 1086
 R SSL_R_TLSV1_ALERT_USER_CANCELLED 1090
 R SSL_R_TLSV1_ALERT_NO_RENEGOTIATION   1100
 R SSL_R_TLSV1_UNSUPPORTED_EXTENSION1110
diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index 6bde16f..82ca653 100644
--- a/ssl/d1_lib.c
+++ b/ssl/d1_lib.c
@@ -266,6 +266,16 @@ long dtls1_ctrl(SSL *s, int cmd, long larg, void *parg)
case DTLS_CTRL_LISTEN:
ret = dtls1_listen(s, parg);
break;
+   case SSL_CTRL_CHECK_PROTO_VERSION:
+   /* For library-internal use; checks that the current protocol
+* is the highest enabled version (according to s-ctx-method,
+* as version negotiation may have changed s-method). */
+#if DTLS_MAX_VERSION != DTLS1_VERSION
+#  error Code needs update for DTLS_method() support beyond DTLS1_VERSION.
+#endif
+   /* Just one protocol version is supported so far;
+* fail closed if the version is not as expected. */
+   return s-version == DTLS_MAX_VERSION;
 
default:
ret = ssl3_ctrl(s, cmd, larg, parg);
diff --git a/ssl/dtls1.h b/ssl/dtls1.h
index e65d501..192c5de 100644
--- a/ssl/dtls1.h
+++ b/ssl/dtls1.h
@@ -84,6 +84,8 @@ extern C {
 #endif
 
 #define DTLS1_VERSION  0xFEFF
+#define DTLS_MAX_VERSION   DTLS1_VERSION
+
 #define DTLS1_BAD_VER  0x0100
 
 #if 0
@@ -284,4 +286,3 @@ typedef struct dtls1_record_data_st
 }
 #endif
 #endif
-
diff --git a/ssl/s23_clnt.c b/ssl/s23_clnt.c
index 2b93c63..d4e43c3 100644
--- a/ssl/s23_clnt.c
+++ b/ssl/s23_clnt.c
@@ -736,6 +736,9 @@ static 

Re: Why fprintf(stder) within a *library*?

[Bodo Moeller]

Good point, this doesn't look right; this is not how OpenSSL normally
reports details. The DTLS code hasn't received the same attention as the
SSL/TLS code yet, because it's used a lot less. Filing a report to
r...@openssl.org makes sense -- it doesn't look as if this has been reported
before.

Bodo

Re: Is it possible that calling ssl_accept in multi-threading circumstance will result in app to crash?

[Bodo Moeller]

jeff jeff.2234...@gmail.com:

I keep getting some application crash in openssl module, I checked the
 dumps and stacks and found that although the stacks vary, the ssl_accept
 function is found on all of them, below are some of exmaples. I google the
 related information about this, looks like there is some problem when
 calling ssl_accept under multi-thread circumstance. My question is, is it
 possible that calling ssl_accept in multi-threading circumstance will
 result in app to crash?


Yes -- a single SSL object can't be used concurrently by multiple threads;
see https://www.openssl.org/support/faq.html#PROG1.

Bodo

Re: not fork-safe if pids wrap

[Bodo Moeller]

 Most other libraries I've seen handle this by saving the pid in a static
 variable, and then comparing the current pid to it.  This has the advantage
 of not needing pthreads, and also of only adding the entropy to the child
 if it is actually needed (i. e. it doesn't exec after fork).


We may have to do that, but we'll still want to always use the current PID
so that we don't end up relying on any kind of random device actually being
present (not all environments have that, so while we can try to reseed, we
can't be sure that this will work).

By the way, in case you wonder why OpenSSL doesn't try to detect forking at
all, that's because the PID may be differ between threads running on the
same memory. If I remember correctly, that was the case for Linux threads
in the ancient times when this code was written:

http://cvs.openssl.org/chngview?cn=1519
http://cvs.openssl.org/chngview?cn=1520

Bodo

Re: not fork-safe if pids wrap

[Bodo Moeller]

On Thu, Aug 22, 2013 at 4:50 AM, Bodo Moeller bmoel...@acm.org wrote:


 Most other libraries I've seen handle this by saving the pid in a static
 variable, and then comparing the current pid to it.  This has the advantage
 of not needing pthreads, and also of only adding the entropy to the child
 if it is actually needed (i. e. it doesn't exec after fork).


 We may have to do that, but we'll still want to always use the current PID
 so that we don't end up relying on any kind of random device actually being
 present (not all environments have that, so while we can try to reseed, we
 can't be sure that this will work).


(So we probably should use the current time in addition to the PID to get a
general solution to the PID wrap-around problem even on systems where
actual independent reseeding isn't possible.)

Re: not fork-safe if pids wrap

[Bodo Moeller]

  (So we probably should use the current time in addition to the PID to
 get a
  general solution to the PID wrap-around problem even on systems where
  actual independent reseeding isn't possible.)

 The FIPS PRNG uses a combination of PID, a counter and a form of system
 timer
 for the DT vector which is used on every invocation (a requirement of the
 standard).


Oh, good. (I guess it was before the NIST SP 800-90A deterministic random
bit generator that we couldn't use PID at all in NIST mode?)  Using the
same inputs with the different PRNGs certainly would make sense.

Re: Effect of EC_GROUP_precompute_mult when doing signature verification (ECDSA_verify)

[Bodo Moeller]

On Tue, Oct 9, 2012 at 12:29 PM, Rune K. Svendsen runesv...@gmail.comwrote:


 I've been researching if EC_GROUP_precompute_mult has any effect when
 verifying ECDSA signatures using ECDSA_verify, and my results are somewhat
 inconclusive. I see a small speedup, around 2-5%, but I'm not sure what the
 reason is for this.

 I can see the code that verifies signatures uses EC_POINT_mul, but I don't
 see a significant speedup as I did when using it to just generate public
 keys (q and m set to NULL in EC_POINT_mul). I can see that in the OpenSSL
 signature verification code q and m are not NULL in EC_POINT_mul, so it
 makes sense why the speedup wouldn't be as great as when they are NULL
 (since precomputations are only made for the generator point of the curve).
 But I don't understand why the speedup becomes so small when q and m are
 set, as I still did see a 5x speedup (from roughly 1000 us per execution of
 EC_POINT_mul to roughly 200 us) when q and m are NULL.


EC_GROUP_precompute_mult precomputation is based only on common group
parameters, not on the specific key. It would be possible to speed up ECDSA
verification similarly by doing something like that on a per-key level, but
it would only help if you verify multiple signatures signed by the same
key. That's why it is currently not supported by the OpenSSL API -- it
would be a bit cumbersome to use properly.

Bodo

Re: header file for EC_KEY

[Bodo Moeller]

 I noticed that EC_KEY (ec_key_st) is not defined in ec.h but in ec_lcl.h
 which is not a public header file, not like RSA(rsa_st) in rsa.h and DSA in
 dsa.h. Is that correct?



 Yes, this is intentional - this intentionally prevents applications from
accessing ec_key_st fields directly, forcing them to use the proper
exported APIs so that they won't depend on internal implementation
details.   Previously existing structs such as those for RSA and DSA were
never changed like that to restrict visibility (for one thing, this
probably would break applications that *do* depend on internal
implementation details, even though this is bad style).

Bodo

Re: header file for EC_KEY

[Bodo Moeller]

 My application requires me to constantly do things like:

 - return n, e, p from an openssl RSA key token
 - construct an openssl RSA public key token from n, e
 - construct an openssl RSA private key token from n, e, p

 I do this using the bignum-bin converters and knowledge of the RSA
 structure.  While this might be 'bad style', is there any better way?


That's one of the problems, actually -- there's often not really a good way
to do things without accessing the struct members directly.  (I.e., while
this is bad style, we can't really blame individual applications for it.
This goes back to SSLeay, and OpenSSL never had a good effort of cleaning
up the APIs; also, obviously, it's not clear that any such effort would
really have helped.)

Bodo

Re: header file for EC_KEY

[Bodo Moeller]

On Tue, May 8, 2012 at 9:00 PM, Bin Lu b...@juniper.net wrote:

  If that is the case, why EC_KEY is exposed in ec.h, and how do I make
 use of the functions that requires this object, e.g.
 EVP_PKEY_get1_EC_KEY()?


To use functions like these, you don't need the struct details (you'd only
need those to peek at struct members) -- what's exposed in EC_KEY is
sufficient. You can't declare EC_KEY variables in your application code,
but you can have EC_KEY * pointers and can use these with those APIs.
(This is like, for example, FILE * from the standard C library.)

Bodo

Re: Disabling kEDH on webservers for scaling?

[Bodo Moeller]

On Fri, Apr 27, 2012 at 2:29 PM, Jack Bauer mlsubscri...@gmail.com wrote:


 Currently I don't know, if the type of DH parameters can be configured
 in nginx. But I will investigate ..

 The only solution (for us, at the moment) seems to be to keep kEDH
 enabled and hope, that most browsers will use ECDHE_RSA in the future.


Presumably you can configure the ciphersuites to use (ECDHE and EDH are
separate sets ciphersuites), including something like -kEDH in your
ciphersuite specification.

Bodo

Re: clarification about CVE-2011-3210 (TLS ephemeral ECDH) and OpenSSL 0.9.8 branch

[Bodo Moeller]

On Mon, Nov 21, 2011 at 10:51 AM, Marco Molteni mmolt...@cisco.com wrote:


 The OpenSSL security advisory of 2011-09-06 (
 http://www.mail-archive.com/openssl-announce@openssl.org/msg00108.html),
 regarding TLS ephemeral ECDH crashes in OpenSSL states that the issue,
 for branch 0.9.8, applies to OpenSSL 0.9.8 through 0.9.8s.

 I understand that for branch 0.9.8 the workaround is to disable ephemeral
 ECDH ciphersuites if you have enabled them, and that one should use branch
 1.0.0. I just want to double check the status of the 0.9.8 branch and
 understand if it is still maintained or not.

 If I look at the repository for opensslv.h, branch 0.9.8 moved from 0.9.8r
 release to 0.9.8s-dev on 2011-02-08, and as of today it is still
 0.9.8s-dev. This means that the day that 0.9.8s becomes release, it will
 still be vulnerable to the TLS ephemeral ECDH crashes in OpenSSL? Or am I
 missing something? Is because by default 0.9.8 doesn't enable ephemeral
 ECDH ?


Sorry -- you've found an error in the advisory (which I'm fixing right now,
in the advisory as found at http://www.openssl.org/news/secadv_20110906.txt).
When writing the advisory, I must have thought that 0.9.8s was the latest
released version in that branch, when really that's 0.9.8r.  0.9.8s, when
released, will contain the fixes.

Bodo

Re: Support for ECDH-RSA cipher suites in 0.9.8

[Bodo Moeller]

On Fri, Nov 4, 2011 at 5:23 PM, John Foley fol...@cisco.com wrote:

 None of the ECDH-RSA cipher suites appear to work in 0.9.8r.  Yet they
 work in 1.0.0.  Is this expected?


Yes -- the OpenSSL 0.9.8 branch includes basic support for elliptic-curve
cryptography, but TLS integration wasn't finished.  This is because OpenSSL
0.9.8 doesn't include support for TLS extensions, which are required for
RFC-compliant ECC curve negotiation.


 Looking at s3_lib.c, all the older DH-RSA cipher suites are disabled
 (SSL_CIPHER-valid=0).  But the ECDH-RSA ciphers listed in s3_lib.c are
 enabled.  This leads to the following questions:

 1.  Is it a bug that the ECDH-RSA cipher suites are not working?
 2.  Or, is it a bug that the ECDH-RSA cipher suites are enabled?


Neither.  Note that not *all* DH-RSA ciphersuites are disabled -- there are
two classes of these:

- The server's public key is a DH key (signed by RSA).
- The server's key is an RSA key, the handshake uses an ephemeral DH key.

The ciphersuites that are disabled are the non-ephemeral DH ciphersuites
(OpenSSL knows their assigned numbers, but doesn't implement the actual
ciphersuites).  The ephemeral DH ciphersuites work in OpenSSL.

Bodo

OpenSSL 1.0.0d released

[Bodo Moeller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


   OpenSSL version 1.0.0d released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.0d of our open source toolkit for SSL/TLS. This new
   OpenSSL version is a security and bugfix release. For a complete
   list of changes, please see

   http://www.openssl.org/source/exp/CHANGES.

   The most significant changes are:

  o Fix for security issue CVE-2011-0014
[http://www.openssl.org/news/secadv_20110208.txt]

   We consider OpenSSL 1.0.0d to be the best version of OpenSSL
   available and we strongly recommend that users of older versions
   upgrade as soon as possible. OpenSSL 1.0.0d is available for
   download via HTTP and FTP from the following master locations (you
   can find the various FTP mirrors under
   http://www.openssl.org/source/mirror.html):

 * http://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.0.0d.tar.gz
  Size: 4025484
  MD5 checksum: 40b6ea380cc8a5bf9734c2f8bf7e701e
  SHA1 checksum: 32ca934f380a547061ddab7221b1a34e4e07e8d5

   The checksums were calculated using the following commands:

openssl md5 openssl-1.0.0d.tar.gz
openssl sha1 openssl-1.0.0d.tar.gz

   Yours,

   The OpenSSL Project Team...

Mark J. Cox Nils Larsch Ulf Möller
Ralf S. Engelschall Ben Laurie  Andy Polyakov
Dr. Stephen Henson  Richard Levitte Geoff Thorpe
Lutz JänickeBodo Möller



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQCVAgUBTVGBGapYnaxaapuFAQJltgP/UWoaBO5R7WAGB3p0TBPODCU6Aaw8MroO
p4qKI7363uBnLgLGQIgS8BBar0n8QARYv4t6c7O+HR3Kn7VCix8cErUm5MkoL79n
C2YJVRKPmpuwoPkLGwC6beB1fBiwvUaJd/n+BSU5LO534QcSzF+u4UKczsGnPX72
HSA/Mzf8C6w=
=Rpu4
-END PGP SIGNATURE-


--
Bodo Moellerb...@openssl.org
OpenSSL Project http://www.openssl.org/
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL Security Advisory: OCSP stapling vulnerability

[Bodo Moeller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [8 February 2011]

OCSP stapling vulnerability in OpenSSL
==

Incorrectly formatted ClientHello handshake messages could cause OpenSSL
to parse past the end of the message.

This issue applies to the following versions:
  1) OpenSSL 0.9.8h through 0.9.8q
  2) OpenSSL 1.0.0 through 1.0.0c

The parsing function in question is already used on arbitary data so no
additional vulnerabilities are expected to be uncovered by this.
However, an attacker may be able to cause a crash (denial of service) by
triggering invalid memory accesses.

The results of the parse are only availible to the application using
OpenSSL so do not directly cause an information leak. However, some
applications may expose the contents of parsed OCSP extensions,
specifically an OCSP nonce extension. An attacker could use this to read
the contents of memory following the ClientHello.

Users of OpenSSL should update to the OpenSSL 1.0.0d (or 0.9.8r) release,
which contains a patch to correct this issue. If upgrading is not
immediately possible, the source code patch provided in this advisory
should be applied.

Neel Mehta (Google) identified the vulnerability. Adam Langley and
Bodo Moeller (Google) prepared the fix.

Which applications are affected
- ---

Applications are only affected if they act as a server and call
SSL_CTX_set_tlsext_status_cb on the server's SSL_CTX. This includes
Apache httpd = 2.3.3.

Patch
- -

- --- ssl/t1_lib.c  25 Nov 2010 12:28:28 -  1.64.2.17
+++ ssl/t1_lib.c8 Feb 2011 00:00:00 -
@@ -917,6 +917,7 @@
}
n2s(data, idsize);
dsize -= 2 + idsize;
+   size -= 2 + idsize;
if (dsize  0)
{
*al = SSL_AD_DECODE_ERROR;
@@ -955,9 +956,14 @@
}
 
/* Read in request_extensions */
+   if (size  2)
+   {
+   *al = SSL_AD_DECODE_ERROR;
+   return 0;
+   }
n2s(data,dsize);
size -= 2;
- - if (dsize  size) 
+   if (dsize != size)
{
*al = SSL_AD_DECODE_ERROR;
return 0;

References
- --

This vulnerability is tracked as CVE-2011-0014.

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20110208.txt

OCSP stapling is defined in RFC 2560.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQCVAgUBTVGA/qpYnaxaapuFAQJSqAQAo3zal2kp+/ZcBcdhXnn98kuDDJaUhCqz
tG+IpnKRqQsGqprz72cOsdlB6C1pzlaLt5tofkxVlXBiAtx1Vn8YeJwQIXAj2CEi
6edgg/w+ni1hBASZBbCQUGLfAmW5tsOxp1ShxCovwh/I+7eetzuSeDfIbB+NYpz7
p3xrSBAVwTY=
=zV3P
-END PGP SIGNATURE-



--
Bodo Moellerb...@openssl.org
OpenSSL Project http://www.openssl.org/
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL 1.0.0d released

[Bodo Moeller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


   OpenSSL version 1.0.0d released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.0d of our open source toolkit for SSL/TLS. This new
   OpenSSL version is a security and bugfix release. For a complete
   list of changes, please see

   http://www.openssl.org/source/exp/CHANGES.

   The most significant changes are:

  o Fix for security issue CVE-2011-0014
[http://www.openssl.org/news/secadv_20110208.txt]

   We consider OpenSSL 1.0.0d to be the best version of OpenSSL
   available and we strongly recommend that users of older versions
   upgrade as soon as possible. OpenSSL 1.0.0d is available for
   download via HTTP and FTP from the following master locations (you
   can find the various FTP mirrors under
   http://www.openssl.org/source/mirror.html):

 * http://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.0.0d.tar.gz
  Size: 4025484
  MD5 checksum: 40b6ea380cc8a5bf9734c2f8bf7e701e
  SHA1 checksum: 32ca934f380a547061ddab7221b1a34e4e07e8d5

   The checksums were calculated using the following commands:

openssl md5 openssl-1.0.0d.tar.gz
openssl sha1 openssl-1.0.0d.tar.gz

   Yours,

   The OpenSSL Project Team...

Mark J. Cox Nils Larsch Ulf Möller
Ralf S. Engelschall Ben Laurie  Andy Polyakov
Dr. Stephen Henson  Richard Levitte Geoff Thorpe
Lutz JänickeBodo Möller



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQCVAgUBTVGBGapYnaxaapuFAQJltgP/UWoaBO5R7WAGB3p0TBPODCU6Aaw8MroO
p4qKI7363uBnLgLGQIgS8BBar0n8QARYv4t6c7O+HR3Kn7VCix8cErUm5MkoL79n
C2YJVRKPmpuwoPkLGwC6beB1fBiwvUaJd/n+BSU5LO534QcSzF+u4UKczsGnPX72
HSA/Mzf8C6w=
=Rpu4
-END PGP SIGNATURE-


--
Bodo Moellerb...@openssl.org
OpenSSL Project http://www.openssl.org/
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL Security Advisory: OCSP stapling vulnerability

[Bodo Moeller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenSSL Security Advisory [8 February 2011]

OCSP stapling vulnerability in OpenSSL
==

Incorrectly formatted ClientHello handshake messages could cause OpenSSL
to parse past the end of the message.

This issue applies to the following versions:
  1) OpenSSL 0.9.8h through 0.9.8q
  2) OpenSSL 1.0.0 through 1.0.0c

The parsing function in question is already used on arbitary data so no
additional vulnerabilities are expected to be uncovered by this.
However, an attacker may be able to cause a crash (denial of service) by
triggering invalid memory accesses.

The results of the parse are only availible to the application using
OpenSSL so do not directly cause an information leak. However, some
applications may expose the contents of parsed OCSP extensions,
specifically an OCSP nonce extension. An attacker could use this to read
the contents of memory following the ClientHello.

Users of OpenSSL should update to the OpenSSL 1.0.0d (or 0.9.8r) release,
which contains a patch to correct this issue. If upgrading is not
immediately possible, the source code patch provided in this advisory
should be applied.

Neel Mehta (Google) identified the vulnerability. Adam Langley and
Bodo Moeller (Google) prepared the fix.

Which applications are affected
- ---

Applications are only affected if they act as a server and call
SSL_CTX_set_tlsext_status_cb on the server's SSL_CTX. This includes
Apache httpd = 2.3.3.

Patch
- -

- --- ssl/t1_lib.c  25 Nov 2010 12:28:28 -  1.64.2.17
+++ ssl/t1_lib.c8 Feb 2011 00:00:00 -
@@ -917,6 +917,7 @@
}
n2s(data, idsize);
dsize -= 2 + idsize;
+   size -= 2 + idsize;
if (dsize  0)
{
*al = SSL_AD_DECODE_ERROR;
@@ -955,9 +956,14 @@
}
 
/* Read in request_extensions */
+   if (size  2)
+   {
+   *al = SSL_AD_DECODE_ERROR;
+   return 0;
+   }
n2s(data,dsize);
size -= 2;
- - if (dsize  size) 
+   if (dsize != size)
{
*al = SSL_AD_DECODE_ERROR;
return 0;

References
- --

This vulnerability is tracked as CVE-2011-0014.

URL for this Security Advisory:
http://www.openssl.org/news/secadv_20110208.txt

OCSP stapling is defined in RFC 2560.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQCVAgUBTVGA/qpYnaxaapuFAQJSqAQAo3zal2kp+/ZcBcdhXnn98kuDDJaUhCqz
tG+IpnKRqQsGqprz72cOsdlB6C1pzlaLt5tofkxVlXBiAtx1Vn8YeJwQIXAj2CEi
6edgg/w+ni1hBASZBbCQUGLfAmW5tsOxp1ShxCovwh/I+7eetzuSeDfIbB+NYpz7
p3xrSBAVwTY=
=zV3P
-END PGP SIGNATURE-


-- 
Bodo Moellerb...@openssl.org
OpenSSL Project http://www.openssl.org/
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: ECDSA PKV Validation Failure

[Bodo Moeller]

On Sep 4, 2009, at 12:29 AM, Will Bickford wrote:


In the following sample test case I get a false-positive from OpenSSL
1.0.0 Beta 3.  Note that this tests specifically for a vector larger
than should be allowed (192/32 = 6 32-bit integers, but Qy requires
7).  Other test cases succeed or fail as expected - this is an edge
case.

[P-192]
Qx = cd6d0f029a023e9aaca429615b8f577abee685d8257cc83a
Qy = 00019c410987680e9fb6c0b6ecc01d9a2647c8bae27721bacdfc

The correct result is a failure, but the following steps produce a
false positive.


Note that EC_POINT_set_affine_coordinates_GFp() does not imply an out- 
of-bounds check.  This will just reduce the coordinates as needed (so  
no error is expected if your input Qy has more than 192 bits).  If you  
need to verify that the inputs are in an accepted range, this is a  
step you'll have to do explicitly in your software.


Bodo




__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Openssl: bio/crypto orthoganalization

[Bodo Moeller]

On Sat, Jan 31, 2009 at 6:49 AM,  t...@terralogic.net wrote:

 I've not looked at the OpenSSL code for a few years now.  Last time I looked 
 the only way to do things was via a BIO and the BIO functions did the 
 crypto.

That's not right.  The BIO functions don't do crypto (well, you can
use BIO structures to access the SSL library, but you don't have to
and can use functions such as SSL_read and SSL_write instead).

The BIO functions normally do the I/O.  That's definitely not always
what you want.  Please take a look at BIO pairs
(http://www.openssl.org/docs/crypto/BIO_s_bio.html) as a way to avoid
having any actual I/O take place within the OpenSSL librarires.  The
SSL/TLS implementation for the Postfix mail server might provide
useful example code for this.

Bodo
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: ECC DH

[Bodo Moeller]

On Wed, Jul 23, 2008 at 7:06 PM, Keith Ellul [EMAIL PROTECTED] wrote:

 Basically, I see that ECDH is part of openSSL.  I have an ECC keypair, and I 
 have someone else's ECC public key.  I want to use ECDH to agree on some key 
 material.  Can I do this from the command line (ie, using the openSSL 
 executable)?  I was hoping for an openssl ecdh command, but, there doesn't 
 appear to be one.  I've read through the docs for ec, ecparam, and 
 dhparam, as well as various forum posts, and I can't find anything.  Is 
 there a command (or set of commands) to do what I want to do?

No, there's no command like that.  Most of the command line tools for
public-key crytography are just for generating and handling keys, but
not for actually using them for the respective cryptographic
operations -- you'd have to use some program on top of the OpenSSL
library for that.

Bodo
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: [SPAM] Re: SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER

[Bodo Moeller]

On Fri, Aug 24, 2007 at 01:33:17PM +0300, Arne Ansper wrote:
 On Mon, 26 Jun 2006, Darryl Miles wrote:
 Bodo Moeller wrote:

 When using SSL_write() over a non-blocking transport channel, you may
 have to call SSL_write() multiple times until all your data has been
 transferred.  In this case, the data buffer needs to stay constant
 between calls until SSL_write() finally returns a positive number
 since (unless you are using SSL_MODE_ENABLE_PARTIAL_WRITE) some of the
 calls to SSL_write() may read some of your data, and if the buffer
 changes, you might end up inadvertantly transferring incoherent data.
 To help detect such potential application bugs, OpenSSL includes a
 simple sanity check -- if SSL_write() is called again but the data
 buffer *location* has changed, OpenSSL suspects that this is a mistake
 and returns an error.

 Sorry, I deleted the Bodo's message, so I'm replying to Darryl.
 
 Many years ago I had a program that reallocated the buffers when needed. I 
 analyzed the SSL code (I hope my messages are still somewhere in the 
 archive) and found out that in fact SSL layer reads the data only once. I 
 did not found any condition where data was read twice from input buffer. 
 Since then we have always set the SSL_MODE_ENABLE_PARTIAL_WRITE flag and 
 does the buffer reallocation as needed.
 
 There is no need for the data buffer to stay constant between calls to 
 SSL_write.

The library won't look at any byte twice -- but if you have
particularly long writes (more than 16 K, and enough to fill up your
TCP write buffers or the buffers of whatever lower layer you are
using), it may take multiple library calls until the library has
looked at all of the bytes.  The application won't know which bytes
already have been processed and which haven't, thus generally the
application is expected not to change the buffer.  If the application
wants to reallocate the buffer, it should make sure to copy the data
around.  In this case, it is expected to use the
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER flag to disable the simple sanity
check.

The purpose of the SSL_MODE_ENABLE_PARTIAL_WRITE flag is exactly to
disable this default behavior of OpenSSLL.  With
SSL_MODE_ENABLE_PARTIAL_WRITE, you don't have to bother to maintain
the buffer state, since OpenSSL won't look at the buffer contents more
than once.  If you are trying to send 64 K of data, OpenSSL might tell
you it has only written 16 K of these.  This is similar to how the
usual write() system call behaves, but differs from previous OpenSSL
behaviour (which remains the default for compatibility) where
applications were expected to repeat write attempts until finally all
of the data had been sent.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: [PATCH] ECDHE-RSA-AES256-SHA failure with 0.9.9 SNAP 20070221

[Bodo Moeller]

On Thu, Feb 22, 2007 at 03:30:12AM -0500, Victor Duchovni wrote:

 --- ssl/ssl_lib.c 2007-02-19 12:01:04.0 -0500
 +++ ssl/ssl_lib.c 2007-02-22 03:07:27.0 -0500
 @@ -1946,7 +1946,7 @@
   alg_k = s-s3-tmp.new_cipher-algorithm_mkey;
   alg_a = s-s3-tmp.new_cipher-algorithm_auth;
  
 - if (alg_k  (SSL_kEECDH|SSL_kECDHr|SSL_kECDHe))
 + if (alg_k  (SSL_kECDHr|SSL_kECDHe))
   {
   /* we don't need to look at SSL_kEECDH
* since no certificate is needed for

The patch is now in the CVS.

Bodo
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: ALL vs DEFAULT or how to properly order anonymous ciphers?

[Bodo Moeller]

On Mon, Feb 19, 2007 at 02:19:27PM -0500, Victor Duchovni wrote:

   [...] I
 think it is cleaner to put the anonymous kEECDH and kEDH ciphers first,
 they use the strongest key-exchange mechanisms available, and best meed
 the authentication needs of apps that ignore authentication.

Allowing anonymous ciphersuites does not always mean that the
application will ignore authentication, though.  Many applications
will merely tolerate anonymous ciphersuites, but still prefer
authenticated ciphersuites if they can get one of those.


 I also think that kEECDH should be sorted ahead of kEDH, within the class
 of forward secrecy capable key-exchange mechanisms.

Yes, that's reasonable.  The current ciphersuite list processing code
doesn't keep the order of deleted ciphersuites sufficiently stable to
express this, but with some further changes this can be done:


Index: ssl_ciph.c
===
RCS file: /e/openssl/cvs/openssl/ssl/ssl_ciph.c,v
retrieving revision 1.68
diff -u -r1.68 ssl_ciph.c
--- ssl_ciph.c  20 Feb 2007 13:25:36 -  1.68
+++ ssl_ciph.c  20 Feb 2007 15:45:29 -
@@ -476,7 +476,7 @@
*head=curr-next;
if (curr-prev != NULL)
curr-prev-next=curr-next;
-   if (curr-next != NULL) /* should always be true */
+   if (curr-next != NULL)
curr-next-prev=curr-prev;
(*tail)-next=curr;
curr-prev= *tail;
@@ -484,6 +484,22 @@
*tail=curr;
}
 
+static void ll_append_head(CIPHER_ORDER **head, CIPHER_ORDER *curr,
+CIPHER_ORDER **tail)
+   {
+   if (curr == *head) return;
+   if (curr == *tail)
+   *tail=curr-prev;
+   if (curr-next != NULL)
+   curr-next-prev=curr-prev;
+   if (curr-prev != NULL)
+   curr-prev-next=curr-next;
+   (*head)-prev=curr;
+   curr-next= *head;
+   curr-prev=NULL;
+   *head=curr;
+   }
+
 static void ssl_cipher_get_disabled(unsigned long *mkey, unsigned long *auth, 
unsigned long *enc, unsigned long *mac, unsigned long *ssl)
{
*mkey = 0;
@@ -586,19 +602,27 @@
/*
 * Prepare linked list from list entries
 */ 
-   for (i = 1; i  co_list_num - 1; i++)
-   {
-   co_list[i].prev = (co_list[i-1]);
-   co_list[i].next = (co_list[i+1]);
-   }
if (co_list_num  0)
{
-   (*head_p) = (co_list[0]);
-   (*head_p)-prev = NULL;
-   (*head_p)-next = (co_list[1]);
-   (*tail_p) = (co_list[co_list_num - 1]);
-   (*tail_p)-prev = (co_list[co_list_num - 2]);
-   (*tail_p)-next = NULL;
+   co_list[0].prev = NULL;
+
+   if (co_list_num  1)
+   {
+   co_list[0].next = co_list[1];
+   
+   for (i = 1; i  co_list_num - 1; i++)
+   {
+   co_list[i].prev = co_list[i - 1];
+   co_list[i].next = co_list[i + 1];
+   }
+
+   co_list[co_list_num - 1].prev = co_list[co_list_num - 
2];
+   }
+   
+   co_list[co_list_num - 1].next = NULL;
+
+   *head_p = co_list[0];
+   *tail_p = co_list[co_list_num - 1];
}
}
 
@@ -679,22 +703,38 @@
int rule, int strength_bits,
CIPHER_ORDER **head_p, CIPHER_ORDER **tail_p)
{
-   CIPHER_ORDER *head, *tail, *curr, *curr2, *tail2;
+   CIPHER_ORDER *head, *tail, *curr, *curr2, *last;
SSL_CIPHER *cp;
+   int reverse = 0;
 
 #ifdef CIPHER_DEBUG
printf(Applying rule %d with %08lx/%08lx/%08lx/%08lx/%08lx %08lx 
(%d)\n,
rule, alg_mkey, alg_auth, alg_enc, alg_mac, alg_ssl, 
algo_strength, strength_bits);
 #endif
 
-   curr = head = *head_p;
-   curr2 = head;
-   tail2 = tail = *tail_p;
+   if (rule == CIPHER_DEL)
+   reverse = 1; /* needed to maintain sorting between currently 
deleted ciphers */
+
+   head = *head_p;
+   tail = *tail_p;
+
+   if (reverse)
+   {
+   curr = tail;
+   last = head;
+   }
+   else
+   {
+   curr = head;
+   last = tail;
+   }
+
+   curr2 = curr;
for (;;)
{
-   if ((curr == NULL) || (curr == tail2)) break;
+   if ((curr == NULL) || (curr == last)) break;
curr = curr2;
-   curr2 = curr-next;
+   curr2 = reverse ? curr-prev : curr-next;
 
cp = curr-cipher;
 
@@ -736,6 +776,7 @@
/* add the cipher if it has not been added 

Re: ALL vs DEFAULT or how to properly order anonymous ciphers?

[Bodo Moeller]

On Mon, Feb 19, 2007 at 02:19:27PM -0500, Victor Duchovni wrote:

 Regardless of the specific details, using a comparator makes the order
 more systematic. One can still quible over whether anonymous auth beats
 RSA auth, and I may not get my wish there, but I still think a sort based
 based on a linear order should be considered. Perhaps this is impractical,
 but it seems tempting to me...

One advantage of using ssl_cipher_apply_rule() for all of this in
ssl_ciph.c is that we can see how well ssl_cipher_apply_rule() does
this kind of job (in terms of bugs, and missing features) -- we
sort the ciphersuite list only in the kind of ways that are available
to textual ciphersuite list specifications.

Bodo

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: ALL vs DEFAULT or how to properly order anonymous ciphers?

[Bodo Moeller]

On Mon, Feb 19, 2007 at 03:22:44PM -0500, Victor Duchovni wrote:

 As far as the 0.9.9 patch is concerned, is it possible to cache the
 initial sorted order? Some applications process cipherlists for every
 connection (destination dependent cipher lists), and it would be nice to
 keep this efficient, provided that there is negligbible or no additional
 cost for applications that set the cipherlist only once.

It's true that the sorted order of ALL should be generated just
once, and then cached, for better efficiency.  Where and how to do
this caching, though, is an optimization decision that will introduce
certain complications, and should only be done once we are sure that
the ciphersuite sorting code itself is OK.

I'm thinking of caching the sorted list once per SSL_CTX, eventually.

Bodo

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: ALL vs DEFAULT or how to properly order anonymous ciphers?

[Bodo Moeller]

On Sat, Feb 17, 2007 at 11:45:58PM -0500, Victor Duchovni wrote:

 Currently the OpenSSL DEFAULT cipherlist serves two functions:
 
 - Sort the cipherlist to put the strongest, most desirable algorithms
 first.
 
 - Exclude ciphers that most applications should not be exposed to.
 
 Applications that don't need/want ciphers outside the DEFAULT list
 can further restrict the cipher choice with DEFAULT:!this:!that ...
 
 Things get more complicated for applications that want to support
 anonymous ciphers but still maintain a sensible cipher order: [...]

... since once you've used DEFAULT, which involves !ADH or
!ADH:!AECDH (both of which really should be !aNULL), you cannot
re-enable anonymous ciphersuites.

(!this unlike -this thoroughly disables the ciphersuite so that
even !this:this cannot add it.  E.g., RSA:!RSA:RSA is empty,
whereas RSA:-RSA:RSA is equivalent to RSA.  It is intentional
that DEFAULT is that strict.  In fact, DEFAULT should be just as
strict about ciphersuites without encryption, which it doesn't enable
but doesn't thoroughly disable either -- DEFAULT:RSA will enable
unencrypted authentication-only ciphersuites!  This is a bug to
be fixed.)



 I am therefore asking the team to consider splitting the two features:
 
   - Sensible default order
 
   - Non-default cipher exclusion
 
 into two parts. The first part (ordering), should I believe be a feature
 of the ALL cipher_alias:
 
 ALL = preferred:all:+low-pref:@STRENGTH
 
   (preferred = AES:CAMELLIA)
   (all = legacy ALL cipher list)
   (low-pref = +aECDH:+kRSA:+RC4)
 
 an then DEFAULT is simply a filter on the already ordered ALL list:
 
   DEFAULT = ALL:!aNULL.
 
 This would allow applications using ALL (or legacy ALL:+RC4:@STRENGTH
 which would be an equivalent more cumbersome way of getting the same
 result) to portably (release to release) arrive at a sensible cipherlist
 order.

Yes, this makes sense.  Currently, ciphers start being ordered by ID,
which is rather arbitrary.  Here's a patch that uses a reasonable
order for ALL instead, and also includes !eNULL in DEFAULT.
This will go into the 0.9.9 branch.

Bodo




+++ ssl/ssl.h   19 Feb 2007 18:39:53 -
@@ -315,8 +315,13 @@
 /* The following cipher list is used by default.
  * It also is substituted when an application-defined cipher list string
  * starts with 'DEFAULT'. */
-#define SSL_DEFAULT_CIPHER_LIST
AES:CAMELLIA:ALL:!ADH:!AECDH:+aECDH:+kRSA:+RC4:@STRENGTH
-/* low priority for ciphersuites w/o forwared secrecy (fixed ECDH, RSA key 
exchange), and for RC4 */
+#define SSL_DEFAULT_CIPHER_LISTALL:!aNULL:!eNULL
+/* As of OpenSSL 0.9.9, ssl_create_cipher_list() in ssl/ssl_ciph.c always
+ * starts with a reasonable order, and all we have to do for DEFAULT is
+ * throwing out anonymous and unencrypted ciphersuites!
+ * (The latter are not actually enabled by ALL, but ALL:RSA would enable
+ * some of them.)
+ */
 
 /* Used in SSL_set_shutdown()/SSL_get_shutdown(); */
 #define SSL_SENT_SHUTDOWN  1
Index: ssl/ssl_ciph.c
===
RCS file: /e/openssl/cvs/openssl/ssl/ssl_ciph.c,v
retrieving revision 1.66
diff -u -r1.66 ssl_ciph.c
--- ssl/ssl_ciph.c  17 Feb 2007 06:45:37 -  1.66
+++ ssl/ssl_ciph.c  19 Feb 2007 18:39:53 -
@@ -1120,6 +1120,40 @@
   disabled_mkey, disabled_auth, disabled_enc, 
disabled_mac, disabled_ssl,
   co_list, head, tail);
 
+
+   /* Now arrange all ciphers by preference: */
+
+   /* Temporarily enabled AES first (preferred cipher) */
+   ssl_cipher_apply_rule(0, 0, 0, SSL_AES, 0, 0, 0, CIPHER_ADD, -1, head, 
tail);
+
+   /* Temporarily enable everything else */
+   ssl_cipher_apply_rule(0, 0, 0, 0, 0, 0, 0, CIPHER_ADD, -1, head, 
tail);
+
+   /* Move anonymous ciphers to the end.  Usually, these will remain 
disabled.
+* (For applications that allow them, they aren't too bad, but we prefer
+* authenticated ciphers.) */
+   ssl_cipher_apply_rule(0, 0, SSL_aNULL, 0, 0, 0, 0, CIPHER_ORD, -1, 
head, tail);
+
+   /* Move ciphers without forward secrecy to then end */
+   ssl_cipher_apply_rule(0, 0, SSL_aECDH, 0, 0, 0, 0, CIPHER_ORD, -1, 
head, tail);
+   ssl_cipher_apply_rule(0, SSL_kRSA, 0, 0, 0, 0, 0, CIPHER_ORD, -1, 
head, tail);
+   ssl_cipher_apply_rule(0, 0, SSL_kPSK, 0, 0, 0, 0, CIPHER_ORD, -1, 
head, tail);
+
+   /* RC4 is sort-of broken -- move the the end */
+   ssl_cipher_apply_rule(0, 0, 0, SSL_RC4, 0, 0, 0, CIPHER_ORD, -1, head, 
tail);
+
+   /* Now sort by symmetric encryption strength.  The above ordering 
remains
+* in force within each class */
+   if (!ssl_cipher_strength_sort(head, tail))
+   {
+   OPENSSL_free(co_list);
+   return NULL;
+   }
+
+   /* Now disable everything (maintaining the ordering!) */
+   

Re: Cipher Negotiation

[Bodo Moeller]

On Fri, Jun 30, 2006 at 07:29:04AM -0400, Victor Duchovni wrote:

 Currently I specify the group (HIGH/MEDIUM/LOW) and remove some ciphers
 from a group (IDEA and ADH). I also remove AES at the beginning (Shif
 +=-AES:) and add it later because if I don't remove AES there is no
 way to separate AES128 and AES256.
 (Due to an OpenSSL bug, HIGH selects both AES128 and AES256)

It's not a bug that AES182 is classified as HIGH, although it is a
missing feature that there is no class that encompasses only the
256-bit ciphers.  That's why there now is @STRENGTH, which does
not add any ciphers and just sorts the one enabled so far.


 Is this a real problem? What's wrong with:
 
 
 !EXPORT:!LOW:!MEDIUM:DEFAULT:-DHE-RSA-AES128-SHA:-DHE-DSS-AES128-SHA:-AES128-SHA

 Sorry, I guess this (DEFAULT: should have been first) does not work,
 because removing the 128 bit ciphers also removes the 256 bit ciphers.
 
 With:
 
 $ openssl ciphers -v \
   'DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:@STRENGTH'
 DHE-RSA-AES256-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA1
 DHE-DSS-AES256-SHA  SSLv3 Kx=DH   Au=DSS  Enc=AES(256)  Mac=SHA1
 AES256-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1
 DHE-RSA-AES128-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(128)  Mac=SHA1
 DHE-DSS-AES128-SHA  SSLv3 Kx=DH   Au=DSS  Enc=AES(128)  Mac=SHA1
 AES128-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA1
 
 and
 
 $ openssl ciphers -v \
   'DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:@STRENGTH'
 DHE-RSA-AES256-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(256)  Mac=SHA1
 DHE-DSS-AES256-SHA  SSLv3 Kx=DH   Au=DSS  Enc=AES(256)  Mac=SHA1
 AES256-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1
 DHE-RSA-AES128-SHA  SSLv3 Kx=DH   Au=RSA  Enc=AES(128)  Mac=SHA1
 DHE-DSS-AES128-SHA  SSLv3 Kx=DH   Au=DSS  Enc=AES(128)  Mac=SHA1
 AES128-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA1
 
 producing the same results you are out of luck, if you want 256 bit AES,
 you always also get 128 bit AES.

It appears that you are using OpenSSL 0.9.8 or 0.9.8a here.  This is a
bug that should be fixed in OpenSSL 0.9.8b, so that the
DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA ciphersuite
specification (with or without :STRENGTH appended) will only yield the
three ciphersuites intended.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Cipher Negotiation

[Bodo Moeller]

On Fri, Jun 30, 2006 at 09:41:08AM -0700, Chris Clark wrote:

 It's not a bug that AES182 is classified as HIGH, although it is a
 missing feature that there is no class that encompasses only the
 256-bit ciphers.  That's why there now is @STRENGTH, which does
 not add any ciphers and just sorts the one enabled so far.

 I assume AES182 is a typo for AES128.

Yes, sorry.

 This is indeed a bug in OpenSSL according to the documentation at
 http://www.openssl.org/docs/apps/ciphers.html):
 
 HIGH -  with key lengths larger than 128 bits.
 MEDIUM -  those using 128 bit encryption.
 LOW -  those using 64 or 56 bit encryption algorithms excluding export 
 ciphers.
 
 But if I just use 'Medium' it does not select AES128.
 and If I use 'High' then it selects both AES128 and AES256.

Oh, I see.  Actually this is a bug in the documentation since it was
an intentional between from OpenSSL 0.9.8 and 0.9.8a to classify
AES128 as HIGH (like triple DES, elevating these over 128-bit RC4,
which remains MEDIUM).

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER

[Bodo Moeller]

On Thu, Jun 22, 2006 at 10:41:14PM +0100, Darryl Miles wrote:

 SSL_CTX_set_mode(3)
 
 SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
   Make it possible to retry SSL_write() with changed buffer 
 location (the buffer contents must stay the same). This is not the 
 default to avoid the mis-
   conception that non-blocking SSL_write() behaves like 
 non-blocking write().
 
 
 
 What is that all about ?  My application makes no guarantee what the 
 exact address given to SSL_write() is, it only guarantees the first so 
 many bytes are my valid data.  Why do I need to give it such guarantees ?

When using SSL_write() over a non-blocking transport channel, you may
have to call SSL_write() multiple times until all your data has been
transferred.  In this case, the data buffer needs to stay constant
between calls until SSL_write() finally returns a positive number
since (unless you are using SSL_MODE_ENABLE_PARTIAL_WRITE) some of the
calls to SSL_write() may read some of your data, and if the buffer
changes, you might end up inadvertantly transferring incoherent data.
To help detect such potential application bugs, OpenSSL includes a
simple sanity check -- if SSL_write() is called again but the data
buffer *location* has changed, OpenSSL suspects that this is a mistake
and returns an error.

But sometimes, you might want to change the buffer location for some
reason, e.g. since the SSL_write() data buffer is just a window in a
larger buffer handled by the application.  To tell OpenSSL that such
an address change is intentional in your application, and that the
application will make sure that any buffer contents will be preserved
until SSL_write() reports success, you can set the
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER flag.  This will not change
OpenSSL's operation in any way except disabling the sanity check,
since settings this flag indicates that your application does not
require this check.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL and multiple threads

[Bodo Moeller]

On Mon, Jun 26, 2006 at 08:49:19AM +0200, Leon wrote:

 I tracked the bug with gdb and found that it fails in RAND_poll(),
 called from SSL_accept(), when a new session key is generated. The
 strange thing is that after the file descriptor set is zeroed
 [(FD_ZERO(fset)] the call [FDSET(fd,fset)] to add the random device's
 file descriptor does not work. The set remains zeroed and once the
 select() has executed using this set, most of the parameters including
 the random devices file descriptor, becomes zeroed (NULL).
 
 It looks as if something is overrunning my stack - any ideas as to how
 to get the sucker? I had the same results on a dual xeon as well as a
 Athlon box. Using 0.9.7e.

What is the file descriptor number that you observe during these
calls?  Can a single-threaded application handle that many files (and
still do select()) on whatever OS platform it is that you're using?

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL and multiple threads

[Bodo Moeller]

On Mon, Jun 26, 2006 at 12:25:09PM +0200, Leon wrote:
 On Mon, 2006-06-26 at 11:44 +0200, Bodo Moeller wrote:

 What is the file descriptor number that you observe during these
 calls?

 The file descriptor is 1507 which seems correct since each thread opened
 a socket.

 Can a single-threaded application handle that many files (and
 still do select()) on whatever OS platform it is that you're using?

 I did increase the file descriptor to 100 using ulimit
 and /proc/sys/fs/max-file

This does not increase FD_SETSIZE, though.

It is probably an OpenSSL bug to try select() without considering
FD_SETSIZE, but RAND_poll(), where you encounter these problems, is
just OpenSSL's last resort when trying to seed its pseudo-random
number generator (PRNG).  The best thing to do is to have your
application initialize the PRNG with some high-quality randomness
before you start additional threads by using RAND_add() or
RAND_seed(); then OpenSSL won't have to use RAND_poll() in the first
place.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER

[Bodo Moeller]

On Mon, Jun 26, 2006 at 12:35:57PM +0100, Darryl Miles wrote:

 Some of the calls to SSL_write() may read some of your data, I am 
 still not such how the reading of data impacts the write operation.  Are 
 you saying that when WANT_READ is returned from SSL_write() the OpenSSL 
 library has already committed some number of bytes from the buffer given 
 but because its returning -1 WANT_READ it is failing to report that 
 situation back to the application during the first SSL_write() call ? 

Yes.  During the first call to SSL_write(), OpenSSL may take as many
bytes as fit into one TLS record, and encrypt this for transport.
Then SSL_write() may fail with WANT_WRITE or WANT_READ both before and
after this first record has been written, until finally all the data
has been broken up into records and all these records have been sent.


 An under reporting of committed bytes if you want to call it that.  This 
 would also imply you can't reduce the amount of data to SSL_write() 
 since a subsequent call that failed.  Or implies that OpenSSL may access 
 bytes outside of the range given by the currently executing SSL_write(), 
 in that its somehow still using the buffer address given during a 
 previous SSL_write() call.
 
 I still have not gotten to the bottom of the entire scope of 
 situation(s) can cause an SSL_write() to return -1 WANT_READ.  If its 
 only renegotiation that can; then this is always instigated by a 
 SSL_renegotiate() (from my side) or and SSL_read() that causes a 
 re-negotiate request (from the remote side) to be processed.

Yes.  The other party is always allowed to start renegotiation, so
your SSL_write() call might be during renegotiation; but OpenSSL won't
try to read data from the other party during SSL_write() unless it
already knows that a renegotiation is going on.


 It is still unclear how this would work, here is the strictest pseudo 
 code case I can think up.  This is where:
 
  * the exact address for the 4096th byte to send it always at the same 
 address for every repeated SSL_write() call and
 
  * I don't change or reduce the amount of data to be written during 
 subsequent SSL_write(), until all 4096 bytes of the first SSL_write() 
 have been committed into OpenSSL.

Exactly.  You should not change the amount of data (n), and you should
not change the contents of these n bytes.  You may change the address
of that buffer (provided that the contents remain the same) if you
set the flag that you asked about.  However ...


 char pinned_buffer[4096];
 int want_write_len = 4096;
 int offset = 0;
 int left = want_write_len;
 
 do {
   int n = SSL_write(ssl, pinned_buffer[offset], left);
   if(n  0) {
   sleep_as_necessary();
   } else if(n  0) {
   offset += n;
   left -= n;
   }
 while(left  0);

... once SSL_write() returns a positive number, this indicates that
this number of bytes, and *only* this number of bytes, has been
processed.  So any subsequent SSL_write() is detached from this
SSL_write(); OpenSSL does not care what you change in the buffer

Note that you'll have to set SSL_MODE_ENABLE_PARTIAL_WRITE to cause
OpenSSL to return success before *all* of the application buffer has
been written.  The default is that OpenSSL will write all the data,
using multiple records if necessary; with
SSL_MODE_ENABLE_PARTIAL_WRITE, SSL_write() will report success
once a single record has been written.


 In practice many applications may copy their data to a local stack 
 buffer and give that stack buffer to SSL_write().  This means the data 
 shuffles up and the next 4096 byte window is use for SSL_write().
 
 So what I am asking now is what is the _LEAST_ strict case that can be 
 allowed too if the one above the what I see as the most strict usage.
 
 
 
 The need for this dumbfounds me.  If SSL_write() is returning (= 0) 
 then it should not have taken any data from my buffer, nor be retaining 
 my buffer address (or accessing data outside the scope of the function 
 call).

If SSL_write() has started writing a first record, but delayed other
data to later records, then it may have to return -1 to indicate
a WANT_WRITE or WANT_READ condition.


 It is also valid for me to change my mind about exactly what 
 application data I want to write at the next SSL_write() call.  This 
 maybe a change of application data contents or a change of amount of 
 data to write (length).

Not if OpenSSL has already started handling the application data.
In that case you should buffer the application data so that you
can repeat the SSL_write() call properly.


 Infact I have an application that does exactly this, it implements a 
 priority queue of packetized data and the decision about what to send 
 next is made right at the moment it knows it can call write().
 
 
 But sometimes, you might want to change the buffer location for some
 reason, e.g. since the SSL_write() data buffer is just a window in a
 larger buffer handled by the 

Re: SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER

[Bodo Moeller]

On Mon, Jun 26, 2006 at 02:04:47PM +0100, Darryl Miles wrote:
 Bodo Moeller wrote:

 On Mon, Jun 26, 2006 at 12:35:57PM +0100, Darryl Miles wrote:
 Yes.  During the first call to SSL_write(), OpenSSL may take as many
 bytes as fit into one TLS record, and encrypt this for transport.
 Then SSL_write() may fail with WANT_WRITE or WANT_READ both before and
 after this first record has been written, until finally all the data
 has been broken up into records and all these records have been sent.

 Checky extra question: Out of interest what are the overheads for TLS 
 headers and block padding for bulk application data, is there an optimal 
 SSL_write() size that would align all of these factors in the encoded 
 output:
 
  * TLS header/protocol overhead
  * Cipher blocks and chaining modes (picking the most commonly used)
  * Blocking mode padding overhead
  * Ethernet 1500 MTUs
 
 I presume the minimum is 1 byte, to be send and flushed at the receiver.
 
 But maximum block size I read somewhere maybe around 16Kb ?
 
 So if we were looking in the 1500 to 6000 byte region for a nicely 
 aligned SSL_write() size, what are the magic numbers ?

If you want to minimize overhead, you should use records of maximum
length, which is 2^14 plaintext bytes (with a slightly longer
ciphertext).



 The only thing that matters relates to data contents and length:
 
  * that once data has been FIRST introduced with SSL_write(), even if 
 that returned -1, I'm not allowed to alter the contents or reduce the 
 length within that I've already presented before.
 
 I presume I am allowed to increase the amount of data in a subsequent 
 SSL_write() call, or does that break TLS block length previously setup ?

OpenSSL won't complain if you increase the length on subsequent
SSL_write() calls.

Bodo

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Error in 20060610 releases

[Bodo Moeller]

On Sat, Jun 10, 2006 at 06:25:33AM -0600, The Doctor wrote:

[...]
 making all in crypto/evp...
 make: don't know how to make e_camellia.o. Stop
 *** Error code 1

Oops ... a new file that I forgot to add to the CVS.  This will be
fixed in the next snapshot (20060611).

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Openssl multithreaded use with only 2 threads and SSL_CTX per thread

[Bodo Moeller]

On Sun, May 29, 2005 at 03:43:33PM +0200, Nadav Golombick wrote:

 If I am using only 2 threads with each thread containing its own SSL_CTX 
 object, do I still need to use locking functions?

Yes!  This is very important because OpenSSL uses some global data
structures that will be shared by all threads, with access coordinated
through locks.  (This includes error book-keeping and the
pseudo-random number generator.)

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: SSL_write error - SSL3_WRITE_PENDING

[Bodo Moeller]

On Mon, Jun 23, 2003 at 11:46:57AM +0530, Wilson wrote:

 Im facing a problem with SSL_write(). I have a server and client
 communicating over TLS. Initial handshaking is done successfully. But as I
 increase the load on server (Connecting more clients[5 to 10 ] and increaded
 the message size), it is observed that SSL_write() tend to fail. When I
 traced more deep into both client and server behaviour, it is observed that
 the client has received the message (Did an SSL_read) from server and come
 out (from SSL_read()). But the server SSL_write() has not completed
 execution which is causing the problem when the next SSL_write() happens (It
 is multi threaded)!

Have you verified that your locking callback works correctly?


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Timing attack

[Bodo Moeller]

Christopher Fowler [EMAIL PROTECTED] in epsilon.openssl.users:

 I'm using the openssl source and not redhat packages.  I recently got an
 email from Red Hat that had this header:
  
 Security Advisory - RHSA-2003:062-11

 Since I'm on source and not rpm, I'm looking for a patch.  Is there a
 patch available or a specific code snippet that fixes this problem?

http://www.openssl.org/news/secadv_20030219.txt
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Encryption / Decryption

[Bodo Moeller]

On Thu, Feb 06, 2003 at 01:38:11PM +, Séamus O'Toole wrote:

 I have recently downloaded the latest version of OpenSSL and I am using it 
 in the development of a Secure Voice over IP Project.
 
 Is there a way to extract the session key from the SSL session and use it to 
 encrypt the data, and then to decrypt the data?
 
 I am unable to use SSL_read()/ SSL_write() due to the nature of my 
 project..it uses datagram instead of stream sockets. But if there is a way 
 to use the libraries with datagram sockets I would be very grateful.
 
 After the SSL handshake is performed I would like to extract the session key 
 and use it to encrypt and decrypt the data.

The SSL/TLS protocols only work with streams.  You could use datagrams
to implement streams (look at BIO pairs for how to implement this on
top of OpenSSL), but if you want the protocol to tolerate packet loss,
you can't use SSL or TLS.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSL_accept hang

[Bodo Moeller]

On Fri, Feb 07, 2003 at 12:15:31PM -0800, David Schwartz wrote:
 On Fri, 7 Feb 2003 20:42:50 +0100, Jasper Spit wrote:

 My point was to make clear that your statement that 'it is almost always
 an error to use select() with non blocking sockets' is simply not true.
 I think that might be relevant to other openssl users.

   I stand by my point until and unless you can find some guarantee 
 that what 'select' tells you is true now will continue to be true in 
 the future when you get around to calling whatever I/O function you 
 were planning to call.

So you really meant It is almost always an error to use select() with
*blocking* sockets.

[...]
   If you are willing to block, there is no reason to call 'select'. If 
 you cannot block, you cannot do I/O on blocking sockets.

This way around, this especially true when using the OpenSSL API,
where a single function call such as SSL_read() or SSL_write() can
start multiple socket-level I/O operations.  (In a typical case,
SSL_read() will first read the record header, then the actual data.
In more complicated cases, SSL_read() or SSL_write() may have to
finish a complete TLS/SSL handshake before even starting with the
application data.)


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSL_poll() ???

[Bodo Moeller]

On Fri, Feb 07, 2003 at 03:57:17PM +0100, Alexander Biehl wrote:

 but, is there no way to use blocking sockets and to use poll() or
 select()?

When select() or poll() indicate that *some* data is available for
reading, there is no guarantee that it is enough data for OpenSSL to
continue without blocking.  If blocking is not acceptable, you always
should use non-blocking sockets.  You can also work with BIO pairs,
which are inherently non-blocking and allow you to handle the actual
network I/O in whatever way you like.  (A BIO pair is essentially an
OpenSSL-internal pipe; one end can be handled by the SSL library while
the other end is handled by the application -- you feed in to the SSL
library any data received from the network and transmit over the
network any data sent by the SSL library.)



-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSL_poll() ???

[Bodo Moeller]

On Fri, Feb 07, 2003 at 01:10:30PM +0100, Alexander Biehl wrote:

 is there any function SSL_poll()?
 i would like to see, if there is data I can read.

You can use SSL_pending(ssl) to check if data is available for
immediate reading.  However, this will just report on data that has
already reached the internal buffers and has remained from a previous
SSL_read() call; the library is oblivious of any data that has been
received from the network and is still waiting in TCP buffers.

There's also SSL_peek(), which works similar to SSL_read(), but leaves
the data it reads in the internal buffers so that a subsequent call
to SSL_read() (or to SSL_peek() again) will still find it.

So you could do the following: use non-blocking sockets in you
applications; call SSL_peek() with a small length (such as 1) when you
want OpenSSL to look for incoming TLS records (see SSL_get_error()
manpage) and afterwards, use the SSL_peek() result (or call
SSL_pending()) to see if there is data available for you application.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: no-err option

[Bodo Moeller]

On Thu, Jan 30, 2003 at 11:02:33AM +0100, Martin Witzel wrote:

 This refers to 0.9.7. I have not verified it with earlier versions
 
 When I setup the build process with the 'config no-err' option, I get a lot
 of _link_ errors in the apps directory, because the complete crypto/err
 directory is skipped in the build process (compliments of 'Configure' which
 modifies Makefile.org) and the applications which reference error functions
 do not find them.
[...]
 There are two options to make no-err work: go over the apps code which
 references error functions and exclude all references there when no-err is
 on. Then the code in crypto/err may be safely excluded altogether during
 the build process.  OR correct the compiler switches in crypto/err to make
 crypto/err compile and link some stripped down version of the error
 routines; in this case we could leave the references to functions in
 crypto/err in the apps code. The code which they call would not do much,
 however.

Another option is to abandon no-err instead of trying to make it work ...
some code systematically relies on the error queue being available
(look for ERR_peek_error() and ERR_peek_last_error()).

Do you think that there is a strong reason for keeping (and repairing)
no-err?


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: renegotiation in 0.9.7

[Bodo Moeller]

On Thu, Jan 30, 2003 at 10:41:08AM -, Nigel Spowage wrote:

 my client app calls SSL_renegotiate() and gets a return value of 1
 (success i presume, as i cann't find a man page for this
 function). this sets up internal flags in ssl ready to negotiate the
 connection.
 
 i call SSL_do_handshake() and get a return value of 1 (success),
 however, no network traffic is sent, tcpdump/ethereal shows no
 traffic sent at this point.

To guess what is going on, I'd have to know

- whether your application is operating as a client or a server
  (an SSL/TLS client apparently) and

- what protocol version is used.

SSL 2.0 does not have renegotiations.  For an SSL 3.0/TLS 1.0 client,
the above sequence of calls looks OK, and SSL_do_handshake() should
send data after you called SSL_renegotiate.

To find out if renegotiation has taken place, you can use
SSL_renegotiate_pending().  This function does not do anything
except returning a boolean value: it becomes true when you call
SSL_renegotiate() and remains true until a new handshake has
completed.

A possible explanation for why nothing happens when you call
SSL_do_handshake() would be that a previous SSL_write() operation has
not yet have completed.  But if, according to SSL_get_error(),
SSL_write() has completed, then for SSL 3.0 and TLS 1.0
SSL_renegotiate() followed by SSL_do_handshake() should send a
ClientHello message.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: renegotiation in 0.9.7

[Bodo Moeller]

On Mon, Jan 27, 2003 at 03:21:45PM -, Nigel Spowage wrote:

 okay, so the proper way to renegotiate a connection is  :
 
 1 - call SSL_renegotiate()
 2 - call SSL_do_handshake()
 3 - wait for either 
 3a- SSL_renegotiate_pending() to return 0, or
 3b- an acceptable amount of time (which means rengotiation has failed)
 4 - call SSL_renegotiate()
 5 - call SSL_do_handshake()
 
 is that right ?

SSL_renegotiate() will just set internal flags that tell
SSL_do_handshake() to renegotiate, so you will not have to call
SSL_renegotiate multiple times; but you may have to repeat the calls
to SSL_do_handshake(), which does the actual work.  Use
SSL_get_error() (as described on its manpage) to find out when
SSL_do_handshake() has finished.

You do not have to check the return value of SSL_renegotiate_pending()
unless you want to be really sure that an actual renegotiation has
taken place -- in some cases, if one party requests a renegotiation,
the other party can simply ignore this request.  (If
SSL_renegotiate_pending() returns non-zero, this does necessarily not
mean that calling SSL_do_handshake() again will accomplish
anything; maybe you're done and the question is just whether
the other party will comply with the request for renegotiation.)



-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: renegotiation in 0.9.7

[Bodo Moeller]

On Mon, Jan 27, 2003 at 10:33:44AM -, Nigel Spowage wrote:

 i'm currently trying to implement ssl renegotiation for an
 application which uses openssl in a non-blocking mode.

 SSL_renegotiate(ssl);
 result = SSL_do_handshake(ssl);
 /* result is okay at this point */
 
 /* my app waits for a while, actually, it call's poll() with a timeout of 5 seconds 
*/
 
 /* about 5 seconds later */
 result = SSL_do_handshake(ssl);
 /* no error returned here */
 
 pending = SSL_renegotiate_pending(ssl);
 /* pending is allways non-zero */

 am i missing something ? is there something extra i need to do ?

Yes, call SSL_renegotiate() to initiate a second handshake once the
first one has finished.  Otherwise SSL_do_handshake() does not think
that there is something to do for it.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Elliptic Curve module

[Bodo Moeller]

On Wed, Jul 24, 2002 at 04:07:46PM +0100, Haikel MEJRI wrote:

 I'm trying openssl-0.9.7-beta2, I want to know why the elliptic curve
 module is not included in the openssl command line tool?

0.9.7 includes just a library for elliptic curve arithmetic, but no
further ECC support.  This will change in 0.9.8; see the daily
(non-stable) snapshots at the OpenSSL project server.

 I want to know also if I can generate elliptic curve keys with standard
 or non standard domaine parameters and if I Can generate certificates
 for the ec public keys? (either programmatically or through the openssl
 command tool)

This will be possible in 0.9.8 (no curve generation, but key
generation over curves of your choice).


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [ANNOUNCE] OpenSSL 0.9.6g released

[Bodo Moeller]

Gregg Andrew [EMAIL PROTECTED]:

 That being said, are the fixes in 0.9.6g reliavant to upgrading
 0.9.6e on unix/solaris platform,

Unless you have already installed 0.9.6f, you may want to upgrade to
0.9.6g.  Most problems are fixed in 0.9.6e, but there's at least a
possibility of denial of service attacks (the code will call abort()
instead of properly reporting an error).


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: openssl 0.9.6 returning premature eof?

[Bodo Moeller]

On Fri, Jun 07, 2002 at 05:18:06PM +0200, Bodo Moeller wrote:
 On Wed, Jun 05, 2002 at 07:27:15PM -0400, Shekhar Mahadevan wrote:

 I'm trying to connect to https://secure01.principal.com/ using OpenSSL.
 Three other SSL toolkits (including JSSE) work OK, but OpenSSL results in
 the server side socket closing with a premature EOF.
[...]

 This is a bug in the server, which apparently cannot handle
 length-zero SSL 3.0 fragments.  These are used in OpenSSL 0.9.6d as a
 workaround for a security problem in the SSL 3.0/TLS 1.0 protocol.  As
 a workaround, you can use RC4-based ciphers ('-cipher RC4' when using
 s_client).

Starting with the next snapshots, the '-bugs' option to s_client
should restore the previous behaviour (i.e. not prevent the security
problems found in the protocol) and thus ensure interoperability with
such broken servers.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Interop problem iaik ssl 3.03 with 0.9.7-beta1

[Bodo Moeller]

On Tue, Jun 11, 2002 at 11:16:49AM +0200, Joerg Bartholdt wrote:

 trying the 0.9.7-beta1 I came across a problem with a OpenSSL097 server 
 (e.g. openssl s_server) and a iSaSiLk 3.03 client (demo.basic.SSLClient).
 When the Handshake took place, and the client send some initial data 
 (e.g. a GET / HTTP/1.0), the reponse of the server will be corrupted. 
 OpenSSL on the server-side sends a 24byte reply prior to the real 
 reply containing the data all in one TCP-packet:
[...]
 The last packet from the Server contains two TLS records in one packet. 
 I marked the beginning of each packet with two slashes (//) (dump from 
 ethereal):
 Secure Socket Layer
 TLS Record Layer: Application Data
 Content Type: Application Data (23)
 Version: TLS 1.0 (0x0301)
 Length: 24
 Application Data
 TLS Record Layer: Application Data
 Content Type: Application Data (23)
 Version: TLS 1.0 (0x0301)
 Length: 48
 Application Data
 
   00 00 08 00 45 00 00 86 74 d9 40 00 40 06 c7 96   E...t.@.@...
 0010  7f 00 00 01 7f 00 00 01 11 51 82 52 57 07 5a 0f   .Q.RW.Z.
 0020  57 28 c3 29 80 18 7f ff ac f8 00 00 01 01 08 0a   W(.)
 0030  0a d7 24 d9 0a d7 20 ff //17 03 01 00 18 2f 29 68   ..$... ../)h
 0040  d9 a7 0f 95 a7 09 45 a1 2d 75 f0 dc 8c 05 25 ee   ..E.-u%.
 0050  c2 4e cd be a4 //17 03 01 00 30 39 26 bd 0c e1 ec   .N...09
 0060  fb 37 19 b9 2f eb 02 a8 46 6b a8 4c 0d 89 90 4a   .7../...Fk.L...J
 0070  5e b0 b2 72 2c 13 29 ed de e7 0d 6c 89 54 19 2c   ^..r,.)l.T.,
 0080  62 2a a6 5d 16 66 b1 ff e6 a2 b*.].f

Starting with the next snapshots, you can use the new
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option to disable the SSL/TLS
vulnerability countermeasure that caused these interoperability
problems.  Most application protocols should not be vulnerable, so in
many cases the countermeasure may be safely disabled to ensure
interoperability with broken SSL/TLS implementations.  The new option
will also be part of SSL_OP_ALL, meaning that it will be automatically
enabled in software such as mod_ssl (for 'openssl s_server', use
the '-bugs' option).


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Problems with non-blocking sockets and SSL

[Bodo Moeller]

On Fri, Jun 14, 2002 at 04:17:58PM +0200, Martin Sjögren wrote:

 I'm having a few delicate problems, and I think at least one of them
 adheres to non-blocking sockets, which is what I use.
 
 1) Is it possible to get a WANT_WRITE error when I actually don't have
 anything to send (on my high-level layer)? [...]

Yes.  See the SSL_get_error() manpage,
http://www.openssl.org/docs/ssl/SSL_get_error.html


 2) Say I have a program that sends a tiny crucial piece of data to another
 program and can't do anything before it gets another tiny crucial piece of
 data back... Can this go wrong in the sense that the first (or second for
 that matter) piece of data isn't large enough to fill an SSL record, so
 that it won't get sent and everything locks down?  [...]

No.  Records can be tiny, the application does not have to worry about
this.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: problems with SSL_pending / SSL_want

[Bodo Moeller]

Magnus Kulke [EMAIL PROTECTED]:

 i'm writing an ssl client application for encrypted ftp. (i use SSL_set_fd 
 for IO) however i have the problem that performing an SSL_read, it delivers 
 only parts of the text. i have to perform SSL_read three times to (output 
 looks like this: 'break!200 break!PBSZ 0 successfulbreak!') get the full 
 message. once the message is read SSL_read hangs without returning. so i need 
 to determine wether i can read from the ssl or not. i tried SSL_pending and 
 SSL_want, but both always stated that there's nothing to read, even if a 
 succeeding SSL_read was successful.
 
 my questions are: 
 
 do i have any influence on this annoying message-splitting, clientwise? or is 
 this a server issue?

Message will usually be split into blocks of 16 KB.  If fragments are
shorter, this is because the server sends them like that.

 how can i tell wether there is something to read from the ssl, or what might 
 i did wrong that SSL_pending  SSL_want won't work the way they should.

You'll have to use non-blocking I/O, such as O_NONBLOCK if you use
Unix sockets.  SSL_pending only reports data that has already been
processed and buffered by the SSL library; it does not look at any
additional data that may have arrived via the network.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSL_pending() and SSL_ERROR_WANT_READ

[Bodo Moeller]

On Thu, Mar 14, 2002 at 01:00:46PM -0800, John Hughes wrote:

 Since s-rstate is set to SSL_ST_READ_HEADER prior to record
 decryption and decompression, wouldn't SSL_pending() still
 incorrectly indicate that there is data ready to be read in cases
 where either of these fail?

I guess so, but applications should not continue to use the SSL object
after such fatal errors.  I'm not sure what happens if you use
SSL_read() in this case -- wouldn't it return some (garbage) data
anyway even though decryption or decompression has failed?

Probably ssl3_get_record() should reset the record after such errors
to make the library more robust.  I think there may be more cases
where the library behaves strangely if an application uses an SSL
object after a failure for this object.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSL_pending() and SSL_ERROR_WANT_READ

[Bodo Moeller]

John Hughes [EMAIL PROTECTED]:

 I can confirm: There is a discrepancy between the SSL_pending()
 manpage and the source.  SSL_pending() returns rrec.length in
 ssl3_pending() (as of 0.9.6a, we also verify that the SSL record
 being processed is application data, else zero is returned).  This
 variable is updated in ssl3_get_record() when an SSL record header
 is processed.  If the remainder of that SSL record has not yet been
 received, SSL_pending() will return a non-zero value even though
 there may not be that amount of data ready.  This contradicts the
 SSL_pending() manpage, which indicates that its return value
 represents the amount of data immediately available.  I haven't yet
 examined whether SSLv2 connections experience the same problem.

This patch should fix the bug:

diff -u -r1.57 s3_lib.c
--- s3_lib.c2001/10/20 17:56:35 1.57
+++ s3_lib.c2002/03/14 19:20:58
@@ -943,6 +943,9 @@
 
 int ssl3_pending(SSL *s)
{
+   if (s-rstate == SSL_ST_READ_BODY)
+   return 0;
+   
return (s-s3-rrec.type == SSL3_RT_APPLICATION_DATA) ? s-s3-rrec.length : 0;
}
 


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Using SSL_clear to reuse SSL object

[Bodo Moeller]

Lutz Jaenicke [EMAIL PROTECTED]:
 On Wed, Feb 20, 2002 at 12:29:03PM +0200, Yoram Zahavi wrote:

 My server application is using SSL_clear to reuse the SSL object, instead of
 allocating a new one on every new connection. On first connection the client
 succeeds to connect the server, and later on to reuse the SSL sessions. As
 far as I understand connections are closed properly, assigning both
 SSL_RECEIVED_SHUTDOWN and SSL_SENT_SHUTDOWN masks, and closing the
 underlying socket as well.
 
 The Server starts facing problems when the Client tries to open a new
 connection asking not to  reuse the previous session. The SSL object still
 holds a valid Session (since previous connection was closed in the right
 way), which is not removed by SSL_clear. As far as I understand, the Server
 suppose to overcome such case and support the new connection by performing
 full handshake.
[...]
 Hmm. This brings up the question, what SSL_clear() should actually do.
 I would consider SSL_clear() to be not much different from doing
 SSL_free()/SSL_new(), but obiously it is. Unfortunately EAY did not leave
 documentation about his intentions...

Note that SSL_clear() is called by the {ssl23,ssl2,ssl3}_{connect,accept}
functions, so it should not reset too much.  In particular, it should
not unconditionally remove the session.

Connections to a previously used SSL object with a valid session fail
not because the servers insists on that particular session, but
because the server is restricted to the protocol version of that
particular session (and thus cannot handle a backwards-compatible
client hello).  This is intentional: SSL_clear() will reset the
protocol version (method) only if no session is set.  This behaviour
makes a lot of sense for SSL client objects.  It is not particularly
useful for SSL server objects,  but it would be bad to give up
consistency.  If you really want to reuse an SSL server object,
use SSL_set_session(s, NULL) before calling SSL_clear(s).


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: installing openssl in different directories

[Bodo Moeller]

On Mon, Jan 28, 2002 at 06:02:32PM -0600, Phil Howard wrote:

 Does OpenSSL integrate installation paths into its installed files?
 
 If the answer is NO, then that should mean it is safe to move the
 library files from /usr/lib to /lib, right?

The answer is yes, but it usually should be safe to move the library
files from /usr/lib to /lib anyway.  Unless the software uses
certain functions, the installation path does not matter.
Otherwise, it usually shouldn't hurt nothing is found there.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Problem with server_finished in SSL V2

[Bodo Moeller]

Steve Shanks [EMAIL PROTECTED]:

 We have a situation with a non-openssl server (version 2 of SSL,
 SSL_CK_RC4_128_EXPORT40_WITH_MD5) under development interfacing into an
 openssl client (I downloaded a windows binary of openssl 0.9.6b). Everything
 goes good until the server_finished is sent (which means that we have
 successfully sent the server_verify which has been decrypted and
 mac-checked, thus verifing all basic functions).
 
 At this point the mac verification fails. There was one message in the
 archives from last year which described the same sort of behaviour but to
 which no replies were forthcoming (see archives for message titled OpenSSL
 0.9.6a handshake problem.
 
 Any thoughts? Note that the mac failure is before the session id is checked
 for length or the message code is checked.
 
 The prior message, the server_verify was mac'ed as ssl record 1 and this
 record, the server_finished was mac'd as ssl record 2. The same logic (using
 an Atalla hardware card) was used to encrypt both records. Clearly, the
 demonstration of success with the client_finished and the server_verify
 demonstrate that both of the session keys have successfully been generated
 by both ends of the connection.
 
 Interestingly, there is no mac error if I change the server to send the
 server_finished (mac'ed now as record 1) when it should be sending the
 server_finished. Obviously, I get an error about the wrong message type
  ^^^
You mean should be sending the server_verify, apparently.

 received, but it gets through the decryption and mac check sucessfully. I
 did this to see if it were a data problem or not [called my routine
 ssl_send_sv_finished() in place of ssl_send_sv_verify() ].
 
 Either there's a problem in the server logic (which I am able to debug) or
 the openssl which I am not able to debug.

The message length looks okay in your message dump, so as decryption
apparently works, I'd guess the server hashes a different sequence
number than the OpenSSL client.  Are you totally sure that the message
number is exactly one more than for the server_verify message?



-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: nonblocking sockets and FTP

[Bodo Moeller]

On Mon, Jan 07, 2002 at 06:58:07PM +0100, Tomas Svensson wrote:

 1) Non-blocking SSL_accept()
 
 SSL_accept() always returns -1 and SSL_ERROR_WANT_READ (via
 SSL_get_error()) but when I do SSL_read() in response to the first
 error, [...]

Why do you do that?  Please read the SSL_get_error manual page:

 http://www.openssl.org/docs/ssl/SSL_get_error.html


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Problems re-using SSL connections with 0.9.6c...

[Bodo Moeller]

Rob Beckers [EMAIL PROTECTED]:

[...]
 I'm glad you can reproduce the problem, that's half the battle. I'm using 
 OpenSSL's internal cache (single threaded program using async sockets, so 
 no need for external cache), and as stated it's not re-using.
 
 There's no particular hurry to get this fixed on my side. The product this 
 is going in to is due for release in February, so that's still several 
 weeks (at least, as usualy with software projects this one is a bit behind 
 schedule). Just getting it fixed would be good since full SSL handshakes 
 are so hard on the server and really hurt performance...

The next snapshots (ftp://ftp.openssl.org/snapshot;type=d) will
contain a fix.  Please report if everything works as expected.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Sharing an SSL_connection across threads.

[Bodo Moeller]

On Mon, Nov 26, 2001 at 05:47:16PM -, Andy Schneider wrote:

 If I don't renogiate, can I put a read () and write () down in an
 SSL_connection in two different threads at the same time? 

No.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSL_pending()

[Bodo Moeller]

On Mon, Nov 26, 2001 at 11:39:26AM +0100, Rygg Christian Ingemann wrote:

 I'm making a few objects that are communicating with eachother using SSL. It
 almost works now, but I want my client to read from the connection until
 there are no more to read, without knowing how much the server is sending. I
 thought using SSL_pending() would do the trick. However, the call to
 SSL_pending() always returns 0, even though there is something to read: If I
 comment it out, the client reads line after line, but hangs when there is no
 more to read. Why does it return 0 if there is something to read?

SSL_pending() does not read new data from the network, it only looks
at any bytes that may be remaining from previous calls to SSL_read().

If you have to avoid hanging, you should use non-blocking sockets.
Then you can do trial SSL_read() calls to check for new data.  Make
sure to read the SSL_get_error() manual page (or its online version at
URL:http://www.openssl.org/docs/ssl/SSL_get_error.html)



-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: tru64 multi-threading needed

[Bodo Moeller]

Per F. [EMAIL PROTECTED]:

 Is it really that simple?

No.

 I'm asking because the Configure script told me that it configured 
 without threads support, see the command output below. Isn't something 
 like -threads or -D_REENTRANT needed in CFLAGS for thread support?

Many systems need a definition like this.  I don't know if Tru64 is
one of them -- check the system documentation (and maybe look into
system header files).

In any case, multi-threaded applications will have to provide locking
callbacks as described in the threads(3) manual page.  See also the
OpenSSL FAQ (question Is OpenSSL thread-safe?).
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSL renegotiation and SSL_bio (more data)

[Bodo Moeller]

Bodo moeller [EMAIL PROTECTED]:
 Andy Schneider [EMAIL PROTECTED]:

 I applied the patch and it has allowed me to perform a handshake even
 when there are writes in-flight. [...]

 Please try the following patch instead.  This should remove the cause
 of the problem.

Eric noticed that this mishandles session statistics and unnecessarily
calls the handshake callback.  Here's a new version of the patch.

(We do call the handshake callback with SSL_CB_HANDSHAKE_START before
sending a HelloRequest, but SSL_CB_HANDSHAKE_DONE is probably wrong
if there was no actual handshake.)


Index: s3_srvr.c
===
RCS file: /usr/local/openssl/cvs/openssl/ssl/s3_srvr.c,v
retrieving revision 1.49.2.6
diff -u -u -r1.49.2.6 s3_srvr.c
--- s3_srvr.c   2001/09/20 21:36:39 1.49.2.6
+++ s3_srvr.c   2001/09/21 06:51:22
@@ -167,6 +167,7 @@
long num1;
int ret= -1;
int new_state,state,skip=0;
+   int got_new_session=0;
 
RAND_add(Time,sizeof(Time),0);
ERR_clear_error();
@@ -270,9 +271,7 @@
 
case SSL3_ST_SW_HELLO_REQ_C:
s-state=SSL_ST_OK;
-   ret=1;
-   goto end;
-   /* break; */
+   break;
 
case SSL3_ST_SR_CLNT_HELLO_A:
case SSL3_ST_SR_CLNT_HELLO_B:
@@ -281,6 +280,7 @@
s-shutdown=0;
ret=ssl3_get_client_hello(s);
if (ret = 0) goto end;
+   got_new_session=1;
s-state=SSL3_ST_SW_SRVR_HELLO_A;
s-init_num=0;
break;
@@ -511,18 +511,23 @@
/* remove buffering on output */
ssl_free_wbio_buffer(s);
 
-   s-new_session=0;
s-init_num=0;
-
-   ssl_update_cache(s,SSL_SESS_CACHE_SERVER);
 
-   s-ctx-stats.sess_accept_good++;
-   /* s-server=1; */
-   s-handshake_func=ssl3_accept;
-   ret=1;
-
-   if (cb != NULL) cb(s,SSL_CB_HANDSHAKE_DONE,1);
+   if (got_new_session) /* skipped if we just sent a HelloRequest 
+*/
+   {
+   /* actually not necessarily a 'new' session  */
+   
+   s-new_session=0;
+   
+   ssl_update_cache(s,SSL_SESS_CACHE_SERVER);
+   
+   s-ctx-stats.sess_accept_good++;
+   /* s-server=1; */
+   s-handshake_func=ssl3_accept;
 
+   if (cb != NULL) cb(s,SSL_CB_HANDSHAKE_DONE,1);
+   }
+   
goto end;
/* break; */
 
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSL renegotiation and SSL_bio (more data)

[Bodo Moeller]

On Fri, Sep 21, 2001 at 10:09:37AM +0100, Andy Schneider wrote:

 This patch works. However it is also worth noting that my tests expose a
 minor caveat. If a client and server request handshakes thus:
 
 Server:
   Read
   Renegotiate
   Read
   Write
 
 Client:
   Write
   Renegotiate
   Read
   Write
 
 The client will hang stuck in this loop (in ssl3_get_message): [...]

Oops.  This should fix that bug:

Index: s3_both.c
===
RCS file: /e/openssl/cvs/openssl/ssl/s3_both.c,v
retrieving revision 1.22.2.1
diff -u -u -r1.22.2.1 s3_both.c
--- s3_both.c   2000/12/14 17:34:26 1.22.2.1
+++ s3_both.c   2001/09/21 11:12:02
@@ -383,7 +383,11 @@
 * if their format is correct. Does not count 
for
 * 'Finished' MAC. */
if (p[1] == 0  p[2] == 0 p[3] == 0)
+   {
+   s-init_num = 0;
skip_message = 1;
+   }
+   
}
while (skip_message);
 



-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL PRNG analysis

[Bodo Moeller]

On Fri, Sep 21, 2001 at 04:59:17PM +0300, Marko Asplund wrote:

 has anyone done an analysis of the OpenSSL PRNG which would be available
 for public? i've read the Random Number Generation chapter of Peter
 Gutmann's PhD thesis (The Design and Verification of a Cryptographic
 Security Architecture, http://www.cryptoapps.com/~peter/06_random.pdf)
 which contains an analysis of the design of OpenSSL PRNG but has anyone
 analysed the random numbers generated? does the PRNG contain mechanisms
 for statistically analysing its output? have there been any plans for
 including statistical randomness tests in the PRNG output? do these tests
 like the Maurer's universal statistical test catch PRNG errors in
 practice?

Some of the FIPS 140-1 tests are implemented in randtest.c, but
statistical tests on PRNG output are not really meaningful.  If a PRNG
fails them, this surely is a bad sign, but it is easy to implement a
bad PRNG that passes all the tests.  Hash function output looks
pretty random, but usually isn't.  Such tests are meaningful for
hardware implementations where you might have issues such as defective
wires (e.g. every byte is of the form r0rr -- seven random bits,
but one fixed bit).

For a concise description of a problem with earlier versions of the
OpenSSL PRNG that Peter Gutmann did not notice, see
URL:http://www.openssl.org/news/secadv_prng.txt.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSL renegotiation and SSL_bio (more data)

[Bodo Moeller]

Lutz Jaenicke [EMAIL PROTECTED]:

 There exists an address [EMAIL PROTECTED], but in fact the
 email is just forwarded to openssl-dev. Therefore, please send bug
 bug reports to [EMAIL PROTECTED]

No, to openssl-bugs please (which can be treated specially by programs
such as procmail).
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSL renegotiation and SSL_bio (more data)

[Bodo moeller]

Andy Schneider [EMAIL PROTECTED]:

 I applied the patch and it has allowed me to perform a handshake even
 when there are writes in-flight. For the record then (and those who have
 wrestled with SSL_renegotiate and have found this through a search):
 
 1) I use SSL_renegotiate () and SSL_read (ssl, 0, 0) on the server to
request a handshake and a monitor SSL_read/SSL_writes within a
 timeout
for a handshake. I do not fail if SSL_read (ssl, 0, 0) doesn't return
SSL_ERROR_WANT_READ because there maybe data in-flight.
 
 3) I use just SSL_renegotiate on the client when I want to request a
 handshake and apply the same logic as above.


Please try the following patch instead.  This should remove the cause
of the problem.

Index: s3_srvr.c
===
RCS file: /usr/local/openssl/cvs/openssl/ssl/s3_srvr.c,v
retrieving revision 1.49.2.6
diff -u -u -r1.49.2.6 s3_srvr.c
--- s3_srvr.c   2001/09/20 21:36:39 1.49.2.6
+++ s3_srvr.c   2001/09/20 23:57:27
@@ -270,9 +270,7 @@
 
case SSL3_ST_SW_HELLO_REQ_C:
s-state=SSL_ST_OK;
-   ret=1;
-   goto end;
-   /* break; */
+   break;
 
case SSL3_ST_SR_CLNT_HELLO_A:
case SSL3_ST_SR_CLNT_HELLO_B:
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSL_OP_NON_EXPORT_FIRST question

[Bodo Moeller]

On Wed, Aug 29, 2001 at 03:57:07PM +0200, Peter Sommerlad wrote:

 How do I ensure browsers with both export grade and non-export grade
 ciphers connect using stronger encryption? Or is that done 
 automatically today?

Yes, this should always happen automatically.  The client presents its
list of supported ciphers ordered by preference, which hopefully means
that full-strength ciphers come first.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSL_accept timeout

[Bodo Moeller]

On Fri, Sep 07, 2001 at 11:06:06AM +0300, Andrew Popov wrote:

 We need to set timeout on SSL_accept()
 Seting with SSL_CTX_set_timeout(SSL_CTX *ctx, long t) has no effect

No, this function is not about connection timeouts (it is about the
session cache).

To impose a timeout on SSL_accept, use non-blocking sockets and loop
around SSL_accept().  See the SSL_get_error() manual page for details.
You will have to do your own time bookkeeping and call select()
with appropriate timeouts.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Mod exp vs. mult

[Bodo Moeller]

On Tue, Jul 31, 2001 at 08:26:42PM -0700, Yongdae Kim wrote:

 I think my question is basically how much more expensive modular 
 exponentiation is compared to modular multiplication for the given 
 parameters using OpenSSL library?... And my simulation shows that it is 
 around 80 times...

 The number of squarings remains about the same, but many
 general multiplications can be saved.

 I think squaring should be roughly as expensive as multiplication of two 
 same numbers...

Nearly, yes.

 So we still need at least 160 1024-bit multiplication... So 
 I think 80 times is way smaller than I expected... Any think?

As I explained, BN_mod_exp uses Montgomery representation.  This makes
each modular multiplication a lot faster.

*Single* modular multiplications cannot profit from Montgomery
representation because there's a cost in converting the input into
Montgomery representation, and converting the result back in the end.
Modular exponentiation uses many multiplications, but each conversion
is needed just once, so (for large exponents) it pays out to
use Montgomery representation.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Generating certificate with large public key expoent value

[Bodo Moeller]

Jamshid Shoghli [EMAIL PROTECTED] in epsilon.openssl.dev:

 I am trying to generate certificates with public exponent of the public key
 with value 244 or higher,
  
RSA_generate_key(bits, exp, NULL, NULL);
 where bits is 1024, and exp is 244.
  
 But this call never comes back. I tried with exp value of 3 or 5 and it
 comes back after a few seconds. Is there a limitation on the exp value? Is
 there a solution for this? exp of 244 or higher is a requirement for my
 certificates.

RSA moduli must be odd numbers.  65537 is a usual choice.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: BSD-style MD5-based passwd (previous mail with wrong subject)

[Bodo Moeller]

On Wed, Mar 28, 2001 at 11:48:31AM +, Paulo Matos wrote:

 Changes between 0.9.7 and 0.9.6 (from CVS)
 *) Fix 'openssl passwd -1'.
 [Bodo Moeller]
 
 Changes between 0.9.6 and 0.9.5a
 *) Add BSD-style MD5-based passwords to 'openssl passwd' (option '-1').
 [Bodo Moeller]
 
   What was wrong?

The version in OpenSSL 0.9.6 incorrectly assumed that the magic string
was 4 bytes long (which is correct for the Apache variant ["apr1"],
but not for the original scheme ["1"]).


-- 
Bodo Mller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSL_peek problem

[Bodo Moeller]

On Mon, Mar 19, 2001 at 01:54:46PM -0500, ackka ackka wrote:

 [...]  When looking into this more I found that the infinite loop is caused
 on a SSL_peek call.

Please try the beta for OpenSSL 0.9.6a (available from ftp.openssl.org
or one of the mirrors, http://www.openssl.org/source/mirror.html) and
report if it solves your problem.  SSL_peek is known to be broken in
versions up to OpenSSL 0.9.6.

However note that in any case SSL_peek will actually read data from
the underlying socket if it can, just like SSL_read.  The difference
between SSL_read and SSL_peek is that the latter will keep decrypted
application data around for later SSL_read (or SSL_peek) requests.
If your goal is to avoid blocking, you have to use non-blocking sockets.


-- 
Bodo Mller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL poll()?

[Bodo Moeller]

On Mon, Mar 19, 2001 at 11:13:22PM -0700, Nathan Parker wrote:

 How can I poll the SSL layer to see if it has data I can read?  I want to 
 implement a function to read N bytes with a time limit, but using select() 
 messes me up -- it doesn't know if there is data available within SSL.

SSL_pending returns the number of bytes available for immediate
reading.  SSL_pending never does network I/O; it also will not look at
unencrypted data that may have been buffered elsewhere in the system.
Thus it probably does not solve your problem.

One possibility is to use non-blocking sockets and select() or poll().
It is true that select() does not know about SSL/TLS application data.
Instead of immediately calling select(), you should first
call SSL_read, then call SSL_get_error, and then (if necessary)
wait for the appropriate condition [*] before either retrying SSL_read
or giving up in case of a timeout.  You may have to iterate this,
so you should do some bookkeeping for the remaining time limit.

[*] See the SSL_get_error manual page,
http://www.openssl.org/docs/ssl/SSL_get_error.html.
You *must* read the manual page in order to handle non-blocking
I/O correctly!



-- 
Bodo Mller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Why no sig for openssl src?

[Bodo Moeller]

On Fri, Mar 09, 2001 at 09:30:10AM -0600, John Pliam wrote:

 I was trying to download the latest openSSL *and* check it's integrity.  
 But I could not find a signature or find a website that served the source 
 from an https URL.  (https://www.openssl.org/ redirects to a secure site 
 maintained by Ralf Engelschall, but on which I could not find openssl.
 ftp://ftp.openssl.org  denied me access).

URL:ftp://ftp.openssl.org/ is usually accessible and provides
PGP signatures for released versions of OpenSSL.  These can also
be found at various mirrors.  For a list of mirrors, see
URL:http://www.openssl.org/source/mirror.html.


-- 
Bodo Mller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: error when install ssl on SunOS5.8

[Bodo Moeller]

On Fri, Mar 09, 2001 at 10:19:47AM -0800, Marcos Mensalvas wrote:

 When I tried to install openssl on my solaris 5.8 box it responded with a
 error during the
 'make' command was executed:
 
 Error code 1
 make:Fatal error: Command failed for target 'cryptlib.o'
 
 Error code 1
 make: Fatal error: Command failed for target 'all'

Surely this was not the only output of the "make" process?
Read file INSTALL to find out what information is necessary
to give others at least a chance to find out what's going
wrong on your system without employing telepathic means.


-- 
Bodo Mller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSL_peek() not supported with SSLv23_server_method?

[Bodo Moeller]

Dan Kegel [EMAIL PROTECTED]:
 Bodo Moeller:
 Dan Kegel [EMAIL PROTECTED]:

 I just realized I have to accept either SSLV2 or SSLV3 (or TLS)
 connections, so I switched from SSLv3_server_method() to
 SSLv23_server_method().  But oops, that doesn't support SSL_peek()!
 What to do?

 Use SSL_accept first.  It will change the SSL object's method
 during the handshake.

 Like this?  Or are there unpleasant consequences to this
 (e.g. does SSL_accept block, or something silly like that)?
 This does seem to work in my one little test.
 
 --- ssl/s23_srvr.c.orig   Wed Mar  7 09:58:57 2001
 +++ ssl/s23_srvr.cWed Mar  7 12:54:02 2001

Why modify the library?  Simply call SSL_accept() in the application.
(Your are right that it is strange that the SSL23_methods support
SSL_read but not SSL_peek, but this should be fixed in s23_lib.c
and not in s23_srvr.c.)
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: /dev/urandom

[Bodo Moeller]

Michael Sierchio [EMAIL PROTECTED]:

 FreeBSD's implementation of /dev/random allows one to specify
 which interrupts stir the entropy pool.  This, from the /etc/rc.conf
 
   and_irqs="4 6 7 9 10 11 12 14 15"
 
 I haven't found anything similar on Linux, and would be grateful
 for suggestions.  Most systems seem to think that keyboard, mouse,
 etc. are good sources of entropy, but certainly not at all hours
 of the day, and not for servers (which may not have keyboards, mice,
 sound cards, etc.).

What's the problem?  If you don't have a keyboard, you don't have
to expect any keyboard interrupts, do you?  So there's no need
to mask them out.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: cipher suite issue?

[Bodo Moeller]

On Mon, Dec 04, 2000 at 04:34:52PM -0800, Jeffrey Ricks wrote:

[...]
 If I use my java client with the DES-CBC3-SHA cipher, everything works
 fine.  It's when I use that cipher with any openssl-based apps
 (including s_client) that things don't work.  If I run this:
 
 openssl s_client -connect myserver:443 -cert /tmp/s_client.crt -key
 /tmp/s_client.key -CAfile /tmp/s_clientCA.crt -tls1 -cipher
 DES-CBC3-SHA -state
 
 I get the following output:
 .
 .
 .
 GET /servlets/TestServlet HTTP/1.0 (I type this)
 
 SSL_connect:SSL renegotiate ciphers
 SSL_connect:SSLv3 write client hello A
 SSL_connect:SSLv3 read server hello A
 SSL_connect:SSLv3 read server certificate A
 SSL3 alert write:fatal:illegal parameter
 SSL_connect:error in SSLv3 read server key exchange A
 27309:error:1408E098:SSL routines:SSL3_GET_MESSAGE:excessive message
 size:s3_both.c:302:
 
 and the following shows up in my ssl_request_log:
 
 [04/Dec/2000:18:55:07 -0500] ipaddress TLSv1 (NONE) "GET
 /servlets/TestServlet HTTP/1.0" 289
 
 Notice the missing (NONE) cipher suite.
[...]
 [..] The DES-CBC3-SHA cipher only works if client authentication is off.

What happens if you connect to s_server instead, using options
similiar to that server's configuration?


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Solaris64 compile.

[Bodo Moeller]

On Tue, Nov 28, 2000 at 09:13:43AM -0800, Bill Browning wrote:

 Has anyone done a Solaris64 compile with openssl 0.9.6 ? I have tried to do
 so (commands  errors listed below) but am at a bit of a loss as to why this
 compile type works with the 0.9.5a tar file and not with the 0.9.6 tar file.

 ./Configure solaris64-sparcv9-cc
[...]
 cc -I. -I../include -KPIC -DTHREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
 -xtrget=ultra -xarch=v9 -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DULTRASPARC
 -DMD5ASM   -c cryptlib.c -o cryptlib.o
 ucbcc: Warning: "-Xa" redefines compatibility mode from "SunC transition" to "ASI"
  ^
 cg: assertion failed in file ../src/codegen/procgen.cc at line 967
 cg: make_entry: no IR_ENTRY - v9 abi calling requires it
 cg: 1 errors

If you intend to use the Sun Workshop compiler, make sure its binary
directory is your PATH (/opt/SUNWspro/bin); /usr/ucb/cc is not what
you want, but 'ucbcc' looks as if you're using that one.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: My session caching is flaky...

[Bodo Moeller]

On Sun, Nov 05, 2000 at 10:17:08PM -0600, Scott Goodwin wrote:

 The behavior:
 
 1. First hit from browser: session id is generated
 and stored in cache.
 
 2. Second hit: session id is found in the cache
 and used as expected.
 
 3. Third hit: session id is found, but *not* used;
 a new session id is created and stored in cache.
 
 This behavior is exhibited when the client is MSIE, Netscape
 or s_client.
 
 I'm maintaining my own cache in memory and using callbacks
 to manage it. Here's the portion that sets up session caching:
[...]

Take a look at ssl_get_prev_session in ssl/ssl_sess.c to determine
potential reasons for the session not being used (or, better,
look at this in a debugger): Maybe session context IDs don't
agree (make sure to define the session context ID for the
SSL_CTX *before* ever calling SSL_new), maybe the timeout
is triggered for some reason.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: RSA key generation on Windows

[Bodo Moeller]

On Wed, Nov 08, 2000 at 12:00:57PM +0100, Frédéric Gariador wrote:

 I'd like to use Openssl to generate a RSA key pair on Window NT.
 
 I wonder about some issues :
 
 - I use the -rand option to specify files used to seed the random number
 generator.
 According to the number of these file and their size, the number of
 semi-random bytes loaded by openssl vary (this values is outputted
 by the openssl command).
 
 What is a good value range for this number ?

This depends on how unpredictable your files really are.  If they
contain actual randomness, then 1024 bytes is plenty.


 - When the generation process ends, the following message is systematically
 outputted: "unable to write 'random state'"
 
   - What does that mean ?
   - Is that important ?

There's a default file for randomness, which is used even without the
-rand option: If environment variable RANDFILE exists, then the
filename in RANDFILE is used; otherwise, if environment variable HOME
is set, then file .rnd in directory $HOME is used; otherwise the file
is .rnd in the current directory.  Unless seeding was obviously
insufficient, the applications try to write back to that file so that
they have some random seeding the next time one of them is called.
That warning message means that writing to the file determined as
described above did not work, for whatever reasons -- maybe $HOME
is set incorrectly.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: multiple ssl servers on the same box?

[Bodo Moeller]

On Thu, Nov 02, 2000 at 08:46:15AM -0800, Geoff Thorpe wrote:
 On Thu, 2 Nov 2000, Alex Bourov wrote:

 If you have multiple network cards on the system with various IP addresses
 or you assigned several IP addresses to this server, then you can
 distinguished between then by using  VirtualHost my.ip.addy.xx:443. If you
 want to distinguish the web sites served by one server by the names they are
 accessed ( but the same IP address ) - you use  VirtualHost
 my1.domain.name:443.

 umm ... not quite. The latter point, "name-based virtual hosting", does
 not apply to SSL. The reason is quite straightforward - namely that "named
 host" is sent through as part of the clear-http request from the browser.
 In https, SSL encapsulates the entire transport to and from the server, so
 the server will only find out which host it is supposed to act as once it
 has already chosen a certificate and performed the SSL handshake. At that
 point, it's too late to change its mind and whether it is
 "my1.domain.name:443" or "my2.domain.name:443". :-) The only way to do
 this is to have the domains sitting on different IP/port combinations so
 that Apache (and its SSL module) knows *before* beginning the SSL
 handshake which virtual host it is supposed to be acting as.

my1.domain.name vs. my2.domain.name actually is a bad example, because
a certificate containing a hostname of "*.domain.name" should work
with both of these.  (I'm not sure if all browers actually support
this, but it would work for extranets if you tell users to avoid
certain browers.)

But if the server is both www.example.com and www.example.org,
then you're out of luck.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: (Another) Transport Layer Question

[Bodo Moeller]

On Tue, Aug 29, 2000 at 02:17:24PM +0200, Andreas Jungmaier wrote:

[...]
   After looking through the openssl-source code I figured (since there
 are BIO-class implementations for memory i/o, socket i/o as well as
 remote procedure call-based i/o and a BIO-null class template) that 
 it should be possible to adapt the OpenSSL in a way transparent to
 the transport protocol. 
   But how and where do you specify, that the SSL-functions
 (e.g. SSL_write(), SSL_read()) use a different BIO-class ?

The BIOs underlying an SSL object are set by calling the SSL_set_bio
function.  (You won't see this function in all applications because
if you have sockets, you can just call SSL_set_fd, which will
first create the necessary BIOs and then set them.)
Look, say,  at ssltest.c for an example involving BIO pairs.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: howto build without ssl2

[Bodo Moeller]

On Thu, Oct 19, 2000 at 06:03:02PM +0200, Thomas Leyer wrote:

 I want to use this in kernel mode, so I think the
 exclusion of ssl2 should take place while I build the
 libs...

Try compiling with -DNO_SSL2.  If this does not work out of the box,
send patches to openssl-dev.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: bad mac decode (Was: CodeWarrior and openssl)

[Bodo Moeller]

On Wed, Sep 20, 2000 at 04:48:39PM +0800, Michael Lee wrote:

[...]
 I have encountered exactly the same "bad mac decode" error before, although
 I am using VC++6 on Windows 98.  My HTTPS client application attempts to
 connect to its.bocgroup.com (210.177.52.102) using SSLv23_method, but fails
 and returns that message.  Even setting the SSL_OP_NO_TLSv1 option, which
 solves a lot of problem when using SSLv23_method, does not help.  However,
 it is strange that both SSLv2_method and SSLv3_method work fine with that
 site.

I can connect using
 openssl s_client -connect its.bocgroup.com:443 -debug -no_tls1
(both OpenSSL 0.9.5a and the current development version work),
which is SSLv23_method with SSL_OP_NO_TLSv1.
The negotiated cipher is 'RC4-SHA' (SSL 3.0).

Please try if connections work with s_client on your system.
If they do, but really fail when using your own client, then try
a test-run with the cipher string set to 'RC4-SHA'.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSLv2_method and SSLv23_method

[Bodo Moeller]

On Fri, Sep 15, 2000 at 09:22:24AM +0800, Michael Lee wrote:
 Bodo Moeller wrote:

 Note that SSLv2_method will fail for some servers because they
 no longer support SSL 2.0 (and stopping to support it is a good
 thing because of its deficiencies).  I suggest using
 SSLv23_method without SSL_OP_NO_TLSv1 in a first connection attempt;
 if this fails, try using the SSL_OP_NO_TLSv1 flag in a second
 connection attempt (or try SSLv3_method; some servers may even
 require TLSv1_method, but noone uses those :-).

 I have tried using SSv23_method in my client program without
 SSL_OP_NO_TLSv1, but in some cases SSL_connect returns no error and it is
 SSL_write that gives me a handshake failure error.
 
 Does that mean I have no way of knowing if the connection is really okay
 until I actually start sending/receiving data?

You can always use SSL_in_init(s) to check whether there is still
a handshake going on.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Serious Bug in ssl3_get_record

[Bodo Moeller]

On Sat, Sep 09, 2000 at 09:19:34AM +0800, Fung wrote:

 If you look at the source code, you will see the following
 static int ssl3_get_record(SSL *s)
 [...skipped]
   n=ssl3_read_n(s,SSL3_RT_HEADER_LENGTH,
SSL3_RT_MAX_PACKET_SIZE,0);
   if (n = 0) return(n); /* error or non-blocking */
   s-rstate=SSL_ST_READ_BODY;
 
   p=s-packet;
 
   /* Pull apart the header into the SSL3_RECORD */
   rr-type= *(p++);
   ssl_major= *(p++);-- WRONG!!
   ssl_minor= *(p++);-- WRONG!!
   version=(ssl_major8)|ssl_minor;
   n2s(p,rr-length);
 
 If you smart enough, you will see that ssl_major and ssl_minor is wrongly
 assigned and will NEVER get the correct version. Because the version number
 is stored at the 3rd and the 4th byte of p.

According to what specification?!  According to RFC 2246 (and,
similarly, the SSL 3.0 drafts), the version number immediately follows
the ContentType byte.  And that's also where it is located in real life:

$ openssl s_client -debug -connect www.microsoft.com:443
[...]
read from 00156C48 [0015E320] (7 bytes = 7 (0x7))
 - 16 03 01 02 a9 02 ..
0007 - SPACES/NULS
[...]
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Need some help with bio pairs

[Bodo Moeller]

On Thu, Sep 07, 2000 at 08:53:47PM -0700, David Schwartz wrote:

   It seems to be working now. It just seems that I need to keep churning the
 SSL engine more than once, even if both BIO_read functions return -1. Go
 figure.

During the SSL handshake (which always occurs when the connection is
new, and which may be repeated later), data must be sent in both
directions a couple of times.  So no application data will be
transported at first, but there should either be protocol data at
bio_io that must be sent over the network, or the SSL engine may need
to receive data via bio_io in order to continue.

You can check BIO_ctrl_get_read_request(bio_io) to test whether the
SSL engine tried to read something, and you can use
BIO_ctrl_pending(bio_io) to test whether there is data that
has to be sent over the network.

You also can check BIO_should_read(ssl_bio) to see if the SSL engine
tried to read data from the network; however note that the similar
test BIO_should_write(ssl_bio) often will return 0 even when there
is still data that has to be transferred over the network --
the return value 0 just means that there was enough space
in the buffer inside the BIO pair.  So it's better to use
BIO_ctrl_get_read_request and BIO_ctrl_pending to see what
I/O operations have to be done, and then call BIO_read(ssl_bio, ...)
or BIO_write(ssl_bio, ...) again if BIO_should_retry(ssl_bio)
returns true, and repeat the process until BIO_should_retry
finally returns 0.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSLv2_method and SSLv23_method

[Bodo Moeller]

On Fri, Sep 08, 2000 at 11:10:23AM +0800, Fung wrote:

 Do anyone know what is the diff. between SSLv2_method and
 SSLv23_method?? Once I used SSLv23_method to create SSL_CTX for my
 client program, handshake failure returned when connected to some
 web server. When I changed to use SSLv2_method to create SSL_CTX, no
 problem at all.

SSLv2_method allows only the old, defective SSL 2.0 protocol.
SSLv23_method enables automatic protocol version negotiation,
which may lead to use of SSL 2.0, SSL 3.0, or TLS 1.0, depending
on which protocol versions are supported by the peer.

There are still some buggy servers that will fail a client tries
to connect this way.  Instead of resorting to SSLv2_method,
try using the SSL_OP_NO_TLSv1 flag to negotiate an SSL 3.0 session
(SSL 3.0 is a lot better than SSL 2.0); this may work.
You can use s_client withe the '-no_tls1' option to test this.

Note that SSLv2_method will fail for some servers because they
no longer support SSL 2.0 (and stopping to support it is a good
thing because of its deficiencies).  I suggest using
SSLv23_method without SSL_OP_NO_TLSv1 in a first connection attempt;
if this fails, try using the SSL_OP_NO_TLSv1 flag in a second
connection attempt (or try SSLv3_method; some servers may even
require TLSv1_method, but noone uses those :-).
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Serious Bug in ssl3_get_record

[Bodo Moeller]

On Fri, Sep 08, 2000 at 05:44:35PM +0800, Fung wrote:

 I have found that there is a serious bug located in the static
 function ssl3_get_record in s3_pkt.c. The fault is that the function
 NEVER gets the version number of SSL and MUST returns "wrong version
 number" error. That means if I create SSL_CTX with SSLv3_method,
 then I get "wrong version number" error for all connections. (Very
 non-sense) Please let me know how to fix it. Thanks

I don't quite understand what the problem is that you say you have
observed -- 'openssl s_server -ssl3' and 'openssl s_client -ssl3'
certainly work, and they do use SSLv3_method.

SSLv3_data (ssl/s3_lib.c) starts with a 'version' component of SSL3_VERSION,
and this is copied into the SSL by SSL_clear (ssl/ssl_lib.c), which is
automatically invoked by SSL_new.  So s3_pkt.c *does* have access to
the correct version number.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: learning PRNG state on startup

[Bodo Moeller]

 Another one problem exists: the very first run of PRNG use only half
 of that hash that cuts the search space half. That is, even properly
 seed PRNG(several hundreds of bytes) will output first
 MD_DIGEST_LENGTH/2 bytes subject to search-it-all attack with search
 space MD_DIGEST_LENGTH/2 bytes.
 
 Solution is simple: output and forget first N*1023 bytes from PRNG.

Please take a look at the 'stirred_pool' variable in crypto/rand/md_rand.c
in OpenSSL snapshots.


 The minimum number of entropy-bits is 128 (=16bytes), which is also retrieved
 from /dev/urandom, if no other seeding was done.
 Compared to a key-size of 128bits (RC4-MD5) or even 168bits (3DES) and
 considering that bytes from the random pool may be used for other items,
 I would recommend to increase the mininum amount of seed to either 32 bytes.
 or even 48bytes with respect to the size of the premaster secret
 (#define SSL3_MASTER_SECRET_SIZE 48).

The minimum amount of seed is currently 20 bytes (snapshot versions),
i.e. the size of one DSA secret.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Memory BIOs size grows indefinitely

[Bodo Moeller]

On Wed, Aug 23, 2000 at 10:03:42AM +0530, Amit Chopra wrote:

   Steve mentioned that the size of the memory BIO can grow indefinitely
 until memory allocations fail. I assume what he is referring to is that
 when BIO_write is called a reallocation is done if the data to be
 written is more than the current size of the BIO buffer.

Yes.  If you don't like this, forget about memory BIOs and use BIO
pairs instead.  See example code in ssl/ssltest.c or in Postfix-TLS.
BIO pairs do buffer allocation only once.


-- 
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: transport layer question

[Bodo Moeller]

On Thu, Aug 10, 2000 at 09:32:36PM +0200, Richard Levitte - VMS Whacker wrote:

 Yep, it's all you need.  It should be stated in the TLS RFC; I

 Oh, and writing the BIO method for RTSP, not to be forgotten...

Or use memory BIOs or a BIO pair.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: SSLv2_client_method vs SSL_OP_NO_TLSv1|SSL_OP_NO_SSLv3

[Bodo Moeller]

On Tue, Apr 25, 2000 at 03:33:47PM +0200, Bodo Moeller wrote:
 On Fri, Apr 21, 2000 at 06:37:41PM -0400, Andrei Vvedenski wrote:

 What is the difference between SSLv2_client_method() and
 SSLv23_client_method() with SSL_OP_NO_TLSv1|SSL_OP_NO_SSLv3 options

 I assumed these should be the same, but SSLv2_client_method() works
 fine and SSLv23_client_method() returns with error "bad mac decode
 @ SSLv2 read server verify A"

 [...] I assume that the error is in OpenSSL [...]

Fixed in the next snapshot.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]