Re: [openssl-dev] version script patch from Debian

[Matt Caswell]

On 21/01/16 16:53, Tom Kacvinsky wrote:
> I ran into this problem with the OpenSSL 1.0.1e I built from source on a
> Debian based system (Ubuntu):
> 
> libssl.so.1.0.0: no version information available (required by python)
> 
> Found this page:
> 
> http://ubuntuforums.org/showthread.php?t=1905963
> 
> to work around the issue, but the question is, is the version script
> they provide good enough for 1.0.1e?

A few things spring to mind here. Firstly 1.0.1e is really old
(pre-heartbleed) and really shouldn't be used. I'd suggest you upgrade
to 1.0.2e if you can (or 1.0.1q if it has to be 1.0.1).

The simplest fix for this is to ensure that system installed
applications always pick up the system installed libraries, and only use
your locally compiled version for applications that need it.

The version script that debian provide should be fine generally, but
there is always the risk of a mismatch, i.e. if there are symbols
defined in your local version not in the version script. The link in the
above thread is for precise which was based on 1.0.1 (not 1.0.1e) so if
there were any symbols added between 1.0.1 and 1.0.1e then you would be
missing those (generally new symbols are avoided in letter releases so
there may not be any).

Finally, I'd point out that I recently added symbol version information
(for linux) into the forthcoming 1.1.0, so in the future this
(hopefully) won't be a problem.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4141] GOST ciphersuites

[Matt Caswell via RT]

This one was fixed a while ago. Closing.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4213] Error defining ciphersuite 0x0300ff87

[Matt Caswell via RT]

Patch applied - thanks. Closing ticket.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length)

[Matt Caswell via RT]

Alessandro's patch has now been applied (thanks). Closing this ticket.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format

[Matt Caswell via RT]

On Mon Dec 28 23:53:02 2015, matt wrote:
> On Mon Dec 28 22:01:04 2015, rs...@akamai.com wrote:
> > Yes we would be interested in this but someone would almost
> > definitely
> > have to be provided as a complete patch because it seems unlikely
> > anyone on the team will get around to doing it by 1.1 release.
> >
>
> Actually I think this capability is already in 1.1.0...or rather it
> *was* but
> now seems to be broken.
>
> See commit 189ae368d91 and RT ticket 3352.
>
> I suspect the big apps cleanup broke it.

This is now fixed. Keeping this ticket open for now because of the request for
support beyond just the apps.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Backporting opaque struct getter/setter functions

[Matt Caswell]

On 11/01/16 18:29, Viktor Dukhovni wrote:
> 
>> On Jan 11, 2016, at 5:23 AM, Tomas Mraz  wrote:
>>
>> On Po, 2016-01-11 at 01:09 +, Peter Waltenberg wrote:
>>> The point of using accessor FUNCTIONS is that the code doesn't break
>>> if the structure size or offsets of fields in the underlying
>>> structures change across binaries.
>>>
>>> Where that mainly has an impact is updating the crypto/ssl libs
>>> underneath existing binaries is more likely to just work.
>>>
>>> #defines in the headers do not help at all here.
>>>
>>
>> The point is in achieving reverse API compatibility between 1.1 and
>> 1.0.2. No binary compatibility is expected between those branches.
>>
>> I think that having the API compatibility would be really useful thing
>> easing porting application code to 1.1 branch.
> 
> Yes, although in practice may users of 1.0.x will have previous releases
> that don't have the accessors, so the issue is difficult to address
> retroactively in OpenSSL.  In Postfix, I add the macros myself:
> 
> #if OPENSSL_VERSION_NUMBER < 0x1010L
> #define X509_up_ref(x) (CRYPTO_add(>references, 1, CRYPTO_LOCK_X509))
> #endif
> 
> Which means that interestingly enough adding these to 1.0.x would break
> my code and similar code elsewhere.
> 
> So on the whole forward-compatibility macros don't fully address the
> problem, and may do as much harm as good.
> 
> I think that applications porting to 1.1.0 can and should implement
> their own macros against a stable 1.0.x API that we don't change
> at the last minute.  Providing your own forward-compatible glue
> is easy enough...
> 

Perhaps someone from the community could contribute a (separately
maintained) compatibility layer to provide the relevant macros?

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption

[Matt Caswell]

On 06/01/16 06:14, Zi Lin wrote:
> Hi Matt,
> 
> thanks for your time. I am glad to see the big efforts done to make
> OpenSSL code better in the master branch (and v1.1.0+). I will find a
> way to start working on the master branch. A quick glance into the
> master branch state machine: the get_prev_session call happens in
> process_message "phase", and dealing with cert_cb happens in
> post_process_message "phase". Moving get_prev_session into
> post_processing_message "phase" seems non trivial as all those cipher
> check are in the process_messaage "phase", depending on resumed
> session.
> 
> Further, I see this comment. Can you clarify what that means?
> https://github.com/openssl/openssl/blob/master/ssl/statem/statem_srvr.c#L1150
> Only session ticket and further TLS1.3 session resumption are
> supported in v1.1+?

This comment is in specific reference to SSLv2 backwards compatible
ClientHellos. While support for SSLv2 itself has been removed from
1.1.0, we still accept SSLv2 backward compat ClientHellos. However we
will not allow session resumption in such an instance: if we are
resuming a session then we must have previously negotiated a version >
SSLv2 so it makes no sense for a client to send a backward compat
ClientHello.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH][OpenSSL-1.0.2] making it possible to do async session lookup during session resumption

[Matt Caswell]

On 05/01/16 22:44, Zi Lin wrote:
> Hi OpenSSL devs,
> 
> I want to propose a patch that makes OpenSSL compatible with
> asynchronous session lookup during session resumption. Currently, the
> session lookup expects the session callback to return immediately with
> success or failure. Now consider a cluster of hosts that want to pool
> the ssl session together to improve session resumption, we would like
> the session lookup callback to adopt the asynchronous paradigm of
> "cert_cb", i.e. cert_cb can be called repeatedly until cert_cb
> finished its job.
> https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/ssl/s3_srvr.c#L916
> 
> Piotr Sikora initiated this project with ideas borrowed from BoringSSL
> code base,
> and since we have put some efforts to make sure no bug is introduced.
> 
> Hence this attached patch to enable "get_session_cb" to return a fake
> session pointer that signals the pending session lookup, and the SSL
> state machines will adopts such signal to resume the client hello
> processing instead of err-out. It's not a small patch since we have
> touched multiple aspects of the SSL state machine. But this patch has
> been verified in CloudFlare's heavy traffic production environment for quite a
> while and we consider it is stable to be used by upstream.

Hi Zi

That is an interesting idea and something we may consider looking at.
However your patch in its current form cannot be accepted because it
targets 1.0.2. Such a change would be considered a new feature. The
1.0.2 branch only receives bug fixes. New features should target the
master branch.

If you take a look at master you will see that there have been
substantial and fundamental changes to the state machine code so your
patch would need significant work to bring it into line.

BTW, please email any future submissions to r...@openssl.org so that they
can be properly tracked.

Thanks

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4201] Feature Request: Support dumping session keys in NSS key log format

[Matt Caswell via RT]

On Mon Dec 28 22:01:04 2015, rs...@akamai.com wrote:
> Yes we would be interested in this but someone would almost definitely
> have to be provided as a complete patch because it seems unlikely
> anyone on the team will get around to doing it by 1.1 release.
>

Actually I think this capability is already in 1.1.0...or rather it *was* but
now seems to be broken.

See commit 189ae368d91 and RT ticket 3352.

I suspect the big apps cleanup broke it.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake

[Matt Caswell via RT]

On Wed Dec 23 16:48:20 2015, matt wrote:
> On Wed Dec 23 15:42:54 2015, d...@inky.com wrote:
> > Using the current master (head) code, this reproduces it:
> >
> > openssl s_client -connect mail.baggett.org:465
> >
> > This is my own personal mail server, so feel free to poke and prod
> > it.
> >
>
> Great, thanks. I can reproduce this now.
>
> The problem is that the server has been configured to allow client
> auth. The
> CertificateRequest message coming from the server seems very long
> (nearly 20k).
> This is primarily made up of a long list of acceptable CA names.
>
> The master code has the max size limit for this message as being
> SSL3_RT_MAX_PLAIN_LENGTH (16384 bytes). This is the maximum that can
> be put
> into a single TLS record. Previous versions had it set to s-
> >max_cert_list
> which is a configurable value that by default is 100k.
>
> The attached patch should resolve this issue (it just reverts the size
> limit to
> what it was before).

This patch has now been applied. Closing ticket.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4120] CertificateStatus message is optional

[Matt Caswell via RT]

Thanks for the report David. This has now been fixed in master/1.0.2/1.0.1

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake

[Matt Caswell]

On 23/12/15 17:21, Viktor Dukhovni wrote:
> On Wed, Dec 23, 2015 at 04:48:20PM +0000, Matt Caswell via RT wrote:
> 
>> The problem is that the server has been configured to allow client auth. The
>> CertificateRequest message coming from the server seems very long (nearly 
>> 20k).
>> This is primarily made up of a long list of acceptable CA names.
> 
> Probably the entire CA bundle was loaded into memory as a CAfile,
> rather than as a CApath, and now the server is spewing out a complete
> list of the DNs of its trusted CAs on every connection.
> 
> I am very tempted to say that this misconfiguration *should fail,
> it is far better to send an *empty* list of trusted CAs than send
> the Vladivostok phone directory.

I strongly disagree. As a supplier of a library for client side use (in
the scenario we are talking about), it is *not* our responsibility to
police server side configuration. I strongly suspect that no browser
(taking a browser use case as an example) would fail when presented with
such an over long CertificateRequest message so neither should we. From
a client side perspective it does little harm to the client to accept a
long message, but it does harm the client to reject (it prevents the
client from using that server). We have in previous versions accepted
this, so IMO we should as a minimum support what we used to support.

> 
>> The master code has the max size limit for this message as being
>> SSL3_RT_MAX_PLAIN_LENGTH (16384 bytes). This is the maximum that can be put
>> into a single TLS record. Previous versions had it set to s->max_cert_list
>> which is a configurable value that by default is 100k.
>>
>> The attached patch should resolve this issue (it just reverts the size limit 
>> to
>> what it was before).
> 
> Perhaps OpenSSL should suppress the default use of the contents of
> CAfile as a list of DNs to send in certificate requests when that
> list is longer than say 16 elements.  Applications can explicitly
> specify the list of CAs for the client certificate request as
> needed.  
> 
> Sending the whole bundle to every client is not a good idea.  The
> empty list works much better in every respect.  We could set the
> limit to 0 instead of the arbitrary 16, thereby requiring the list
> of client auth CAs to always be set explicitly.  With any luck as
> a result a lot fewer applications will end up sending the phone
> directory.
> 

This might be worthwhile as a *server side* solution. It should not
prevent us from accepting long CertifcateRequests on the client.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4197] [PATCH] Memory leak in state machine in error path

[Matt Caswell via RT]

On Tue Dec 22 17:02:07 2015, tsh...@akamai.com wrote:
> Hello OpenSSL org:
>
> I found the following issue via code inspection. In
> tls_process_client_key_exchange(), when EC is disabled, and an error
> occurs in ssl_generate_master_secret() or RAND_bytes(), the error path
> does not free rsa_decrypt.


Patch applied. Many thanks.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake

[Matt Caswell via RT]

On Wed Dec 23 15:42:54 2015, d...@inky.com wrote:
> Using the current master (head) code, this reproduces it:
>
> openssl s_client -connect mail.baggett.org:465
>
> This is my own personal mail server, so feel free to poke and prod it.
>

Great, thanks. I can reproduce this now.

The problem is that the server has been configured to allow client auth. The
CertificateRequest message coming from the server seems very long (nearly 20k).
This is primarily made up of a long list of acceptable CA names.

The master code has the max size limit for this message as being
SSL3_RT_MAX_PLAIN_LENGTH (16384 bytes). This is the maximum that can be put
into a single TLS record. Previous versions had it set to s->max_cert_list
which is a configurable value that by default is 100k.

The attached patch should resolve this issue (it just reverts the size limit to
what it was before).

Matt

>From 14202312b361b5b5c1ad719b96c02daeb1e2b0c0 Mon Sep 17 00:00:00 2001
From: Matt Caswell <m...@openssl.org>
Date: Wed, 23 Dec 2015 16:36:59 +
Subject: [PATCH] Increase the max size limit for a CertificateRequest message

Previous versions of OpenSSL had the max size limit for a CertificateRequest
message as |s->max_cert_list|. Previously master had it to be
SSL3_RT_MAX_PLAIN_LENGTH. However these messages can get quite long if a
server is configured with a long list of acceptable CA names. Therefore
the size limit has been increased to be consistent with previous versions.
---
 ssl/statem/statem_clnt.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/ssl/statem/statem_clnt.c b/ssl/statem/statem_clnt.c
index e7c9413..5f9d182 100644
--- a/ssl/statem/statem_clnt.c
+++ b/ssl/statem/statem_clnt.c
@@ -695,7 +695,11 @@ unsigned long ossl_statem_client_max_message_size(SSL *s)
 return SERVER_KEY_EXCH_MAX_LENGTH;
 
 case TLS_ST_CR_CERT_REQ:
-return SSL3_RT_MAX_PLAIN_LENGTH;
+/* Set to s->max_cert_list for compatibility with previous releases.
+ * In practice these messages can get quite long if servers are
+ * configured to provide a long list of acceptable CAs
+ */
+return s->max_cert_list;
 
 case TLS_ST_CR_SRVR_DONE:
 return SERVER_HELLO_DONE_MAX_LENGTH;
-- 
2.5.0

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4198] BUG: READ_STATE_MACHINE:excessive message size during handshake

[Matt Caswell via RT]

On Wed Dec 23 03:54:19 2015, d...@inky.com wrote:
> Openssl Version 1.1.0 (master as of 22-DEC-15)
> Mac OS X 10.11.2
>
> Connection to my SMTP server, which has a 4096-bit RSA key, fails
> with:
>
> Traceback (most recent call last):
> File "tls/_openssl.py", line 359, in handshake
> error: [Errno 5] 1: TLS handshake with server peer failed:
> error:14160098:SSL routines:READ_STATE_MACHINE:excessive message size

I've just tried this with s_server/s_client and a 4096 bit RSA key and I am
unable to recreate this issue. Are you able to send a wireshark packet capture?

Thanks

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1222] Please introduce versioned symbols

[Matt Caswell via RT]

This feature is now available in master (1.1.0). Closing this ticket.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OSTIF

[Matt Caswell]

Hi all

I've had some emails recently from Derek at OSTIF who has been talking
to me about their plans to do an audit (separate to the current CII one)
of OpenSSL next year. OSTIF is not associated or affiliated with
OpenSSL, but if you're interested you can learn more here:
https://ostif.org/

Regards

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] EAP-FAST and OpenSSL 1.1.x with new client TLS state machine

[Matt Caswell]

On 03/12/15 23:09, Jouni Malinen wrote:
> Any idea what happened with these OpenSSL client state machine changes
> and how to get this fixed to restore EAP-FAST functionality?

EAP-FAST is very strange. Normally you know whether you are resuming a
session or not based on the session id returned from the server. However
that's not the case with EAP-FAST - you have to wait to see what message
the server sends you next to determine what's happening (which is really
horrible).

The new state machine code waits until a message is received from the
peer and then checks it against its allowed list of transitions based on
its current state. If its not allowed then you get an unexpected message
alert. It looks like the check for the EAP-FAST session resumption case
is missing from the new code.

Please can you try the attached patch and see if that resolves the
issue? Let me know how you get on.

Thanks

Matt

From 07315256ab0a97e1172304a098c262a845833206 Mon Sep 17 00:00:00 2001
From: Matt Caswell <m...@openssl.org>
Date: Fri, 4 Dec 2015 10:18:01 +
Subject: [PATCH] Fix EAP FAST in the new state machine

The new state machine code missed an allowed transition when resuming a
session via EAP FAST. This commits adds the missing check for the
transition.
---
 ssl/statem/statem_clnt.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/ssl/statem/statem_clnt.c b/ssl/statem/statem_clnt.c
index 527101b..b49f498 100644
--- a/ssl/statem/statem_clnt.c
+++ b/ssl/statem/statem_clnt.c
@@ -283,6 +283,19 @@ int ossl_statem_client_read_transition(SSL *s, int mt)
 if (SSL_IS_DTLS(s) && mt == DTLS1_MT_HELLO_VERIFY_REQUEST) {
 st->hand_state = DTLS_ST_CR_HELLO_VERIFY_REQUEST;
 return 1;
+} else if (s->version >= TLS1_VERSION
+&& s->tls_session_secret_cb != NULL
+&& s->session->tlsext_tick != NULL
+&& mt == SSL3_MT_CHANGE_CIPHER_SPEC) {
+/*
+ * Normally, we can tell if the server is resuming the session
+ * from the session ID. EAP-FAST (RFC 4851), however, relies on
+ * the next server message after the ServerHello to determine if
+ * the server is resuming.
+ */
+s->hit = 1;
+st->hand_state = TLS_ST_CR_CHANGE;
+return 1;
 } else if (!(s->s3->tmp.new_cipher->algorithm_auth
 & (SSL_aNULL | SSL_aSRP | SSL_aPSK))) {
 if (mt == SSL3_MT_CERTIFICATE) {
-- 
2.5.0

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4167] Missing "include/openssl" in the latest tarballs

[Matt Caswell via RT]

The files in "include/openssl" get populated at configure time and are not
necessary to successfully build and install openssl.

Closing this ticket.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] test_ordinals causes make update to fail after make clean

[Matt Caswell]

On 04/12/15 15:41, Adam Eijdenberg wrote:
> On Thu, Dec 3, 2015 at 9:47 PM Viktor Dukhovni
> > wrote:
> 
> On Fri, Dec 04, 2015 at 03:05:28AM +, Adam Eijdenberg wrote:
> 
> > When I'm preparing a patch I've gotten myself used to the following
> > workflow to try to get my working environment into a sane state:
> >
> > ./config --strict-warnings
> > make clean
> > make update
> > make -j32
> > make tests
> >
> > Today I noticed that "make update" is failing with the following
> error:
> >
> > /Applications/Xcode.app/Contents/Developer/usr/bin/make
> TESTS=test_ordinals
> > test
> > /Users/aeijdenberg/src/openssl/util/opensslwrap.sh: line 25:
> > /Users/aeijdenberg/src/openssl/util/../apps/openssl: No such file or
> > directory
> 
> Since you're on Darwin, presumably using a 64-bit Intel CPU, have
> you considered instead:
> 
> ./Configure shared darwin64-x86_64-cc
> make clean
> make depend
> make -j32
> make tests
> 
> (note --strict-warnings is a developer option, no guarantee that
> it will work at all times on all platforms).
> 
> 
> Hi Viktor,
> 
> Yes, I understand it's a developer option, and that there are likely
> more appropriate build targets on Darwin, but I don't believe either are
> related to the issue that I'm trying to report (which I also get on my
> Linux workstation), which is that "make update" now won't work on a
> cleanly checked out source tree, whereas it did 2 days ago
> (before 
> https://github.com/openssl/openssl/commit/0aca86b313d286be979629a3193a12e17bf7171a).
> 
> Is that expected behavior or not?
> 
> (my understanding of "make update" is that it will call all the things I
> might need after making changes to the source, such as re-generating
> error files, safestack stuff, make depend etc, so it's kind of nice that
> it works before the source itself is built)
> 

This is definitely a problem. I am hitting the same thing.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] EAP-FAST and OpenSSL 1.1.x with new client TLS state machine

[Matt Caswell]

On 04/12/15 13:08, Jouni Malinen wrote:
> On Fri, Dec 04, 2015 at 10:27:48AM +0000, Matt Caswell wrote:
>> EAP-FAST is very strange. Normally you know whether you are resuming a
>> session or not based on the session id returned from the server. However
>> that's not the case with EAP-FAST - you have to wait to see what message
>> the server sends you next to determine what's happening (which is really
>> horrible).
> 
> Indeed. EAP-FAST is a good example of what can happen if a company
> designs a new EAP method and pushes that to the market without going
> through proper IETF review.. This part here is not the only difficult
> item in supporting EAP-FAST. :(
> 
>> The new state machine code waits until a message is received from the
>> peer and then checks it against its allowed list of transitions based on
>> its current state. If its not allowed then you get an unexpected message
>> alert. It looks like the check for the EAP-FAST session resumption case
>> is missing from the new code.
>>
>> Please can you try the attached patch and see if that resolves the
>> issue? Let me know how you get on.
> 
> Thanks! That fixes the issue. With this applied on top of the current
> master branch snapshot, I was able to pass all my EAP regression tests.
> 

This has now been committed to master.

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.0.1q released (corrected download)

[Matt Caswell]

On 03/12/15 19:10, Quanah Gibson-Mount wrote:
> make[5]: *** No rule to make target `../../include/openssl/idea.h',
> needed by `e_idea.o'.  Stop.

Hmmm. I don't get that. Can you post your build steps?

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL version 1.0.0t released (corrected download)

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

   Due to an error in the release process the original distribution
downloads were failing to build. New downloads have now been made
available on the website. Corrected checksums are given below.

   OpenSSL version 1.0.0t 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.0t of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

http://www.openssl.org/news/openssl-1.0.0-notes.html

   OpenSSL 1.0.0t 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.0t.tar.gz
  Size: 4092302
  MD5 checksum: 7b7e9f6039a97e4a453b596055912435
  SHA1 checksum: ab41cb253405a974063392063a034951a30076e9
  SHA256 checksum:
5ab6e348c6c2a95d457e7a00e0aa653bfc7eb4df7b24e7c9ab63163ac0299097

   The checksums were calculated using the following commands:

openssl md5 openssl-1.0.0t.tar.gz
openssl sha1 openssl-1.0.0t.tar.gz
openssl sha256 openssl-1.0.0t.tar.gz

   Yours,

   The OpenSSL Project Team.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWYJFjAAoJENnE0m0OYESR1d8H/3j6OADtQxQY6bLoQ6Nv65OM
oztdsyGQz9hU7ttWwaFi/n2h0sC71fRsEVPR2UkewwnCnX4+VyduVZMg+fhMBP5d
TyxN7fbNKfRZD7kus3odVIjUrJX/Rp0LdG5+5hc3fPlnvLJ/QSb+jAVZJy6HWLEO
4M5yJOvcPFaiWEuoVnIEhUuJ5K9xfKNk8nwURkA/aiFi88NgI1d/NZ10SX8IjyGV
1Znfe6ck2c09zA09iKLngmbXWDBwXMzFnvtBdk9Xni/Usn1m/fEkf0LehRVy8cKp
woVKGUcWKEGt85l6RitjFXkNmMrPuimRiBYoajFQ7JNTPYbUaqh+xtnowSemTbc=
=ygoc
-END PGP SIGNATURE-
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL version 1.0.1q released (corrected download)

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

   Due to an error in the release process the original distribution
downloads were failing to build. New downloads have now been made
available on the website. Corrected checksums are given below.

   OpenSSL version 1.0.1q 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.1q of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

http://www.openssl.org/news/openssl-1.0.1-notes.html

   OpenSSL 1.0.1q 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.1q.tar.gz
  Size: 4549898
  MD5 checksum: 54538d0cdcb912f9bc2b36268388205e
  SHA1 checksum: c65a7bec49b72092d7ebb97a263c496cc1e1d6af
  SHA256 checksum:
b3658b84e9ea606a5ded3c972a5517cd785282e7ea86b20c78aa4b773a047fb7

   The checksums were calculated using the following commands:

openssl md5 openssl-1.0.1q.tar.gz
openssl sha1 openssl-1.0.1q.tar.gz
openssl sha256 openssl-1.0.1q.tar.gz

   Yours,

   The OpenSSL Project Team.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWYJCeAAoJENnE0m0OYESRQqsIAL/W3CN6X1Lm5cySm0ludaxX
7GZTIIjQjoPLu5UFhgHb0MlYFxvU2CgeahpR8wCFI/s10/enGs7bD54chlBJMqZC
C+7+QWq6oY45f2Jnb5toGWK7jkWSW6ASkwTfvK086D+XlIGwgokI1cy3nL+UhdVl
YHPb5hoR51l6rMQBB3uR1k2SXp3CEanMnJ1vL81gY05gPkc8qGfFaDj7JrteyOcB
o+vwqaGg/J6VIPQIlxC46xeANAg6H3uDXHHjbOYyGHdNRhkQHaFx7c85dIHv8WJ5
J1XXcEmAae4Th+LCQkSu7IKr4Qezr0sw2xMnRgne7oytgYQpyY4xbkTdBFoFtTA=
=2dkv
-END PGP SIGNATURE-
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL version 0.9.8zh released (corrected download)

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

   Due to an error in the release process the original distribution
downloads were failing to build. New downloads have now been made
available on the website. Corrected checksums are given below.

   OpenSSL version 0.9.8zh 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 0.9.8zh of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

http://www.openssl.org/news/openssl-0.9.8-notes.html

   OpenSSL 0.9.8zh 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-0.9.8zh.tar.gz
  Size: 3818524
  MD5 checksum: c813c065dd53d7bd0a560a870ddd0af5
  SHA1 checksum: 3ff71636bea85a99f4d76a10d119c09bda0421e3
  SHA256 checksum:
f1d9f3ed1b85a82ecf80d0e2d389e1fda3fca9a4dba0bf07adbf231e1a5e2fd6

   The checksums were calculated using the following commands:

openssl md5 openssl-0.9.8zh.tar.gz
openssl sha1 openssl-0.9.8zh.tar.gz
openssl sha256 openssl-0.9.8zh.tar.gz

   Yours,

   The OpenSSL Project Team.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWYJIdAAoJENnE0m0OYESR2LoH/j+PPvqiLnh1AgcXMFXlJ+2L
1GxJXVhUVW/d6ws6P1u0ogvX8/W6VCtiWHEcP08zhzQKoQNrga6EvxYlSNQgE80s
z+GTC1fI2F8gnz9my1s4IowKQOCumSUKU39YhhZ+JpicbThj3tTE3eC07mnJtHYK
bCl3Ec6Q4K5HRq7KxHRFLPwD7Mt3gJ4SCMLgRLT/Q/kbHdV20luMFqS6YsI0tdpB
mPBZYeNrU0n8OtRS4aXu8O0+iYHN6xsnaLhGNGVtqkbb9cy3GFcU7clP990D67Td
R6XHEae4hA0gxsI91/ARfkRsbwr3HToOmjqasmYWdzS9YfULtyXCvHGwPYJv8O8=
=ps/C
-END PGP SIGNATURE-
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL version 1.0.1q released (corrected download)

[Matt Caswell]

On 03/12/15 19:28, Quanah Gibson-Mount wrote:
> --On Thursday, December 03, 2015 7:18 PM +0000 Matt Caswell
> <m...@openssl.org> wrote:
> 
>>
>>
>> On 03/12/15 19:10, Quanah Gibson-Mount wrote:
>>> make[5]: *** No rule to make target `../../include/openssl/idea.h',
>>> needed by `e_idea.o'.  Stop.
>>
>> Hmmm. I don't get that. Can you post your build steps?
> 
> Configure is:
> 
>./Configure no-idea enable-ec_nistp_64_gcc_128 no-mdc2 no-rc5
> no-ssl2 \
>  no-hw --prefix=/opt/zimbra/common --libdir=lib
> --openssldir=/opt/zimbra/common/etc/ssl \
>  shared linux-x86_64 -g -O2 -DOPENSSL_NO_HEARTBEATS
> 
> then:
> 
> LD_RUN_PATH=/opt/zimbra/common/lib make
> 
> I only see it on Ubuntu12 & Ubuntu14.  It works fine on RHEL6/RHEL7 with
> the same Configure parameters.  I see one difference, in that on RHEL,
> we're running make depend before running make all.
> 
> After adding "make depend" to occur before "make all", it now succeeds.
> However, this worked on prior releases, so it seems that requiring "make
> depend" is new to 1.0.1q.

Well the end of your output from Configure should look like this (even
on 1.0.1p):

 Since you've disabled or enabled at least one algorithm, you need to do
 the following before building:

 make depend

 Configured for linux-x86_64.

So it does explicitly tell you to run "make depend". I'm not sure I'd
call it a regression that you got away with it before!!

Matt



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Forthcoming OpenSSL releases

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Forthcoming OpenSSL releases


The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.0.2e, 1.0.1q, 1.0.0t and 0.9.8zh.

These releases will be made available on 3rd December between approx.
1pm and 5pm (UTC). They will fix a number of security defects, the
highest of which is classified as "moderate" severity.

Please note that the OpenSSL project has recently revised its severity
definitions by introducing a new "critical" level, i.e. the severity
levels are now: critical, high, moderate and low. Please see the
following page for further details:
https://www.openssl.org/policies/secpolicy.html

Please also note that, as per our previous announcements, the 1.0.0 and
0.9.8 releases will no longer be receiving security updates after the
end of this year. This means that, barring any unexpected significant
security issues between now and 31st December 2015, it is likely that
these releases will be the last ones for 1.0.0 and 0.9.8.

Yours

The OpenSSL Project Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWXG1kAAoJENnE0m0OYESR3vgH/0R7GCsN4moof7ezQIbZbxxN
qeiwH2SGj0a5KXM/J9Ee4jcQWA2n0SfUeFbgLSvqBO8BQdz3oTJMF45Z+gXjWFqZ
OiEQ+ZFayNm/Tb46OFhglbRBhfb7Je4sy4i8cSW6wGQ2EdWz3JN/xWC0q9KMqQpi
k8IwitBK3WxZ/Je+rHZvsDzABWd3Jf2+QlDjwHXxSfrW9UBc5Wr7e+d5XMQk2KML
FGJtkucAFs+AiOWvfsJ2WzFYy373M7pYQT38ODOuvT9HxMHzDY89kj2BsFjr8pZY
yIk9fAE1BTKRoNoUPETVuYi0Wq+xFHgV5urFQztxglWymcxAILHOZ+PZDyT/m5Q=
=QGvN
-END PGP SIGNATURE-
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

[Matt Caswell]

On 24/11/15 15:16, Jonathan Larmour wrote:
> On 23/11/15 20:34, Matt Caswell wrote:
>> On 23/11/15 17:49, Nico Williams wrote:
>>
>>> Still, if -lpthread avoidance were still desired, you'd have to find an
>>> alternative to pthread_key_create(), pthread_getspecific(), and friends.
>>
>> Just a point to note about this. The async code that introduced this has
>> 3 different implementations:
>>
>> - posix
>> - windows
>> - null
>>
>> The detection code will check if you have a suitable posix or windows
>> implementation and use that. Otherwise the fallback position is to use
>> the null implementation. With "null" everything will compile and run but
>> you won't be able to use any of the new async functionality.
> 
> I hope there will be the ability to plug in different operating systems
> and it's not hard coded to just these choices. There are embedded systems
> which use OpenSSL which do not have POSIX thread APIs (POSIX is very
> heavyweight for many).
> 
> For example, GCC abstracts their threading dependenencies with a "gthread"
> API which OS implementers can write against. What would be bad would be
> direct calls to pthread* dotted around the OpenSSL code base.

We are talking specifically about the new async functionality here. The
three implementations are all you get for that. That has no impact on
the rest of OpenSSL functionality. So if you happen to be on a non-posix
and non-windows platform then OpenSSL will function as it does today.
You just don't get the new async functionality on top.

There are pthread references in one (internal) header file and one c
source code file. If the new threading API discussed elsewhere in this
thread goes ahead, then those references would be replaced with calls to
that instead.

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

[Matt Caswell]

On 23/11/15 17:49, Nico Williams wrote:
> [Resend, with slight edits.]
> 
> [Viktor asked me for my advice on this issue and bounced me the post
>  that I'm following up to.  -Nico]
> 
> The summary of what I've to say is that making libcrypto and libssl need
> -lpthread is something that does require discussion, as it will have
> detrimental effects on some users.  Personally, I think that those
> detrimental effects are a good thing (see below), but nonetheless I
> encourage you to discuss whether this is actually what OpenSSL should
> do.  In particular, it may be possible to avoid -lpthread on some
> systems and still get a subset of lipthread functionality from libc or
> the compiler (e.g., thread-locals), and that may be worth doing.
> 
> On a slightly related note, I asked and Viktor tells me that fiber
> stacks are allocated with malloc().  I would prefer that they were
> allocated with mmap(), because then you get a guard page.  A guard page
> would allow one to safely tune down fiber stack size to the whatever
> OpenSSL actually needs for a given use.

Interesting. I'll take a look at that.

> Still, if -lpthread avoidance were still desired, you'd have to find an
> alternative to pthread_key_create(), pthread_getspecific(), and friends.

Just a point to note about this. The async code that introduced this has
3 different implementations:

- posix
- windows
- null

The detection code will check if you have a suitable posix or windows
implementation and use that. Otherwise the fallback position is to use
the null implementation. With "null" everything will compile and run but
you won't be able to use any of the new async functionality.

Only the posix implementation uses the pthread* functions (and only for
thread local storage). Part of the requirement of the posix detection
code is that you have "Configured" with "threads" enabled. This is the
default. However it is possible to explicitly configure with
"no-threads". This suppresses stuff like the "-DRENENTERANT" flag. It
now will also force the use of the null implementation for async and
hence will not use any of the pthread functions.

One other option we could pursue is to use the "__thread" syntax for
thread local variables and avoid the need for libpthread altogether. An
earlier version of the code did this. I have not found a way to reliably
detect at compile time the capability to do this and my understanding is
that this is a lot less portable.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

[Matt Caswell]

On 23/11/15 21:56, Paul Dale wrote:
> Somewhat tangentially related to this is the how thread locking in
> OpenSSL is slowing things up.

Alessandro has submitted an interesting patch to provide a much better
threading API. See:

https://github.com/openssl/openssl/pull/451

I'm not sure what the current status of this is though.

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Matt Caswell]

On 17/11/15 00:01, Viktor Dukhovni wrote:
> On Mon, Nov 16, 2015 at 11:23:52PM +0000, Matt Caswell wrote:
> 
>> Disabling algorithms isn't the right answer IMO. I do like the idea of a
>> "liblegacycrypto". That way people that only have need of current
>> up-to-date crypto can stick with the main library. Others who need the
>> older crypto can still get at it. Yes, that means we still have to
>> maintain this code - but I don't see it as that big a burden.
> 
> What becomes a bit tricky is having an EVP interface that can find
> the algorithms in liblegacrypto.  This I think means two different
> builds of the crypto library, one that depends on liblegacycrypto
> and provides its algorithms, and another than does not.

Is this just limited to
OpenSSL_add_all_algorithms()/OpenSSL_add_all_ciphers()/OpenSSL_add_all_digests()?

How about if those were macros that just picked up the relevant
implementation based on a define. So in evp.h, something like:

#ifdef OPENSSL_LEGACY_ALGS
void OpenSSL_add_all_legacy_algorithms();
void OpenSSL_add_all_legacy_ciphers();
void OpenSSL_add_all_legacy_digests();
#define OpenSSL_add_all_algorithms() OpenSSL_add_all_legacy_algorithms()
#define OpenSSL_add_all_ciphers() OpenSSL_add_all_legacy_ciphers()
#define OpenSSL_add_all_digests() OpenSSL_add_all_legacy_digests()
#else
void OpenSSL_add_all_main_algorithms();
void OpenSSL_add_all_main_ciphers();
void OpenSSL_add_all_main_digests();
#define OpenSSL_add_all_algorithms() OpenSSL_add_all_main_algorithms()
#define OpenSSL_add_all_ciphers() OpenSSL_add_all_main_ciphers()
#define OpenSSL_add_all_digests() OpenSSL_add_all_main_digests()
#endif

OpenSSL_add_all_legacy_ciphers() would call
OpenSSL_add_all_main_ciphers() and add all the legacy ones in too.
Similarly for the other functions.

Then you just compile apps which don't need legacy support with
"-lcrypto", and apps that do with "-DOPENSSL_LEGACY_ALGS -lcrypto
-lcrypto-legacy"


> 
> Systems might then ship with:
> 
>   libcrypto-legacy.so - Just the legacy algorithms
> 
>   libcrypto-compat.so - Libcrypto that supports the above
>   libcrypto-secure.so - Libcrypto with just the strong algos
> 
>   libcrypto.so- Symlink to one of the two above
> 
> Some applications might be linked directly to "-secure" or "-compat"
> to make sure they get one or the other.  This is a bunch of work.

I don't think you would need libcrypto-compat if you took the approach
above.

I'm wondering whether splitting libcrypto into 3 might be worthwhile:

libcrypto-core.so   - Core elements of libcrypto needed by libssl
libcrypto.so- Would depend on libcrypto-core. Adds mainstream and
current crypto stuff that isn't needed by libssl
libcrypto-legacy.so - Would depend on libcrypto and libcrypto-core. Just
the legacy algorithms.

That way users who only have an interest in libssl don't have to carry
around all the other stuff that libcrypto provides - only those bits
they need. Apps using libcrypto directly can mostly just forget about
libcrypto-legacy and just add it if they really need it.

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Fwd: Re: [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Matt Caswell]

Meant to send this to openssl-dev not openssl-users so resending...

On 16/11/15 15:51, Emilia Käsper wrote:
> Thanks all for your feedback!
> 
> I asked for mainstream use-cases for algorithms whose removal could
> cause widespread pain. Some individual users, undoubtedly, will be hit
> by this, and I acknowledge that they may not be reading this list. But I
> wanted to know if I'd missed something endemic. I also asked elsewhere:
> Adam Langley pointed me to the MD4 use-case and Steve confirmed that RC2
> must stay.
> 
> There is a tradeoff: by attempting to accommodate every single use-case,
> we will weaken the library for a substantial amount of our user base, by
> offering them bad defaults, or simply by virtue of the fact that our
> developer resources are not infinite. (Near)-dead code is a liability.

We can significantly reduce that liability by removing any assembler
optimisations. Also just because something is available doesn't mean it
has to be "default". We can have good defaults whilst keeping old crypto.


> 
> So far, excluding suspicions that something may be used somewhere, I've
> received one clear argument, for RC5. And, while I'm sympathetic to the
> cause, I believe this is the case where we have to balance one user's
> needs against everyone else's.
> 
> As for specific deprecation strategies:
> - Don't forget that all applications will have to recompile against 1.1.
> 
> - Disabling algorithms doesn't work well for us as it's just pushing the
> decision on the distros. It also wouldn't win us any resources as we'd
> still be responsible for keeping the code bug-free. The only win would
> be in default compiled code size.

Disabling algorithms isn't the right answer IMO. I do like the idea of a
"liblegacycrypto". That way people that only have need of current
up-to-date crypto can stick with the main library. Others who need the
older crypto can still get at it. Yes, that means we still have to
maintain this code - but I don't see it as that big a burden.

> 
> - We can leave OPENSSL_NO_XXX defines around so wrapper libraries
> (Python, PHP etc) who correctly account for the fact that an
> implementation may be missing (which they have to, anyway) will continue
> to work.
> 
> - Removing assembly support is a GREAT suggestion to simplify the
> complexity, and I think we should do this for anything we end up leaving
> in, and perhaps even for some things not yet on the hit list (RC4?).
> 
> - I appreciate OpenSSL's role as a "Swiss army knife" research tool but
> research needs shouldn't prevail over those of real applications. We are
> generally not on the frontline of deprecating things - RC4 isn't yet on
> the list. SSLv3 isn't yet on the list, etc. But we can't become the
> Internet Archive of All Old Crypto either, and there's some cleanup to
> do that's long overdue.

Being the "swiss army knife" is no bad thing (even where that includes
old crypto). We just have to find a way to separate the two concerns:
current crypto (and only current crypto) for most (and probably most
importantly for libssl users); broader crypto support for those that
want it (which is why I like the liblegacycrypto idea because it enables
us to do that).


> It seems to me that these can pretty safely go:
> 
> MD2 - (The argument that someone somewhere may want to keep verifying
> old MD2 signatures on self-signed certs doesn't seem like a compelling
> enough reason to me. It's been disabled by default since OpenSSL 1.0.0.)
> MDC2
> SEED
> RC5 

All candidates for liblegacycrypto IMO rather than deletion.

Whether this is the right thing to do in the 1.1.0 timeframe is another
consideration though. Viktor's arguments are quite convincing.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Matt Caswell]

On 15/11/15 21:16, Viktor Dukhovni wrote:
> Is the pain worth the gain?  I'm inclined to think that dropping
> TLS ciphersuite code points, and assembly support, is a rather
> sensible first step.

I agree with this. I am wary of dropping too much too quickly.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] procedure for adding new engine registration

[Matt Caswell]

On 13/11/15 11:16, Vemulapalli Jyothi wrote:
> Hi Matt,
> 
> Very useful information.
> 
> I too agree with you that we need not have a new engine distribution.
> 
> I see some options like dynamic engines and static engine support.
> 
> If we have built a library with dynamic engine interface, how can we do speed 
> test using openssl speed command.

As follows (on Linux):

OPENSSL_ENGINES=/path/to/my/engine/dir openssl speed -engine myengine


Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] procedure for adding new engine registration

[Matt Caswell]

On 12/11/15 18:21, Vemulapalli Jyothi wrote:
> Hi all,
> 
>  
> 
> We would like to add a new engine registration to openssl.
> 
>  
> 
> Can you please explain a procedure?
> 
>  
> 
> When we gone through the code, we could find an engines directory in
> openssl ,  but those files are not getting compiled.
> 
> Do we need to give some additional options. Can you please help.

Its not clear to me whether your asking "how do I create my own engine
for my own purposes?" or "how do I create an engine that I want to get
incorporated into the OpenSSL source and be distributed as part of
OpenSSL?". The answers to these two questions are slightly different.

For the former question I suggest you start with these two links:
https://www.openssl.org/blog/blog/2015/10/07/engine-school/
https://www.openssl.org/blog/blog/2015/10/08/engine-building-lesson-1-a-minimum-useless-engine/

There's also some content on the wiki on this topic:
https://wiki.openssl.org/index.php/Creating_an_OpenSSL_Engine_to_use_indigenous_ECDH_ECDSA_and_HASH_Algorithms

For the latter question the technical procedure is essentially the same
as above. However I am personally not keen on the introduction of new
engines that do not have a broad applicability to large groups of users.
That would typically rule out the introduction of manufacturer specific
engines requiring the presence of additional hardware.

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello

[Matt Caswell via RT]

On 03/11/15 17:43, David Benjamin via RT wrote:

> I'm not sure that fix quite works though. If BIO_flush completes
> asynchronously

Ahhh, yes good point. Updated patch attached.

> (hrm, it's missing an rwstate update),

Yes, just discovered that myself and then came back and reread your
email to find out you already pointed it out! Also addressed in updated
patch.


> then I believe you'll
> be in a state where you *do* want to repeat the init_off / init_num adjust.
> You might be able to get away with using init_off/init_num with some minor
> tweaks? Another problem: because the fragment headers clobber whatever was
> already written, msg_callback sees garbage.

Yuck. Not addressed that issue yet. I'll deal with that separately.

> Yeah, this part of DTLS (like much of it) is woefully underspecified. We
> keep stuffing things into ClientHellos, so if one does need to support
> fragmented ones, I think the right way to do stateless HelloVerifyRequest
> is to silently drop all non-initial ClientHello fragments and require the
> initial one be large enough to include the client_random and whatever else
> you figure into the cookie.

I really like that idea. I'll take a look at doing that in the new
DTLSv1_listen code.

Matt


>From d973a67f17917869ab2238c041c447996ff94976 Mon Sep 17 00:00:00 2001
From: Matt Caswell <m...@openssl.org>
Date: Tue, 3 Nov 2015 14:45:07 +
Subject: [PATCH 1/3] Fix DTLS handshake fragment retries

If using DTLS and NBIO then if a second or subsequent handshake message
fragment hits a retry, then the retry attempt uses the wrong fragment
offset value. This commit restores the fragment offset from the last
attempt.
---
 ssl/d1_both.c | 63 ---
 1 file changed, 43 insertions(+), 20 deletions(-)

diff --git a/ssl/d1_both.c b/ssl/d1_both.c
index c2c8d57..dfae56c 100644
--- a/ssl/d1_both.c
+++ b/ssl/d1_both.c
@@ -297,6 +297,39 @@ int dtls1_do_write(SSL *s, int type)
 frag_off = 0;
 /* s->init_num shouldn't ever be < 0...but just in case */
 while (s->init_num > 0) {
+if (type == SSL3_RT_HANDSHAKE && s->init_off != 0) {
+/* We must be writing a fragment other than the first one */
+
+if (s->init_off <= DTLS1_HM_HEADER_LENGTH) {
+/*
+ * Each fragment that was already sent must at least have
+ * contained the message header plus one other byte. Therefore
+ * if |init_off| is non zero then it must have progressed by at
+ * least |DTLS1_HM_HEADER_LENGTH + 1| bytes. If not something
+ * went wrong.
+ */
+return -1;
+}
+
+if (frag_off > 0) {
+/*
+ * This is the first attempt at writing out this fragment.
+ * Adjust |init_off| and |init_num| to add a new message
+ * header.
+ */
+s->init_off -= DTLS1_HM_HEADER_LENGTH;
+s->init_num += DTLS1_HM_HEADER_LENGTH;
+} else {
+/*
+ * We must have been called again after a retry so use the
+ * fragment offset from our last attempt. We do not need
+ * to adjust |init_off| and |init_num| as above, because
+ * that should already have been done before the retry.
+ */
+frag_off = s->d1->w_msg_hdr.frag_off;
+}
+}
+
 used_len = BIO_wpending(SSL_get_wbio(s)) + DTLS1_RT_HEADER_LENGTH
 + mac_size + blocksize;
 if (s->d1->mtu > used_len)
@@ -336,25 +369,6 @@ int dtls1_do_write(SSL *s, int type)
  * XDTLS: this function is too long.  split out the CCS part
  */
 if (type == SSL3_RT_HANDSHAKE) {
-if (s->init_off != 0) {
-OPENSSL_assert(s->init_off > DTLS1_HM_HEADER_LENGTH);
-s->init_off -= DTLS1_HM_HEADER_LENGTH;
-s->init_num += DTLS1_HM_HEADER_LENGTH;
-
-/*
- * We just checked that s->init_num > 0 so this cast should
- * be safe
- */
-if (((unsigned int)s->init_num) > curr_mtu)
-len = curr_mtu;
-else
-len = s->init_num;
-}
-
-/* Shouldn't ever happen */
-if (len > INT_MAX)
-len = INT_MAX;
-
 if (len < DTLS1_HM_HEADER_LENGTH) {
 /*
  * len is so small that we really can't do anything sensible
@@ -442,7 +456,16 @@ int dtls1_do_write(SSL *s, int type)
 }
 s->init_off += ret;
 s->init_num -= ret;
-frag_off += (ret -= DTLS1_HM_HEADE

Re: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello

[Matt Caswell via RT]

On 04/11/15 15:30, David Benjamin via RT wrote:
> On Wed, Nov 4, 2015 at 7:04 AM Matt Caswell via RT <r...@openssl.org> wrote:
> 
>>
>>
>> On 03/11/15 17:43, David Benjamin via RT wrote:
>>
>>> I'm not sure that fix quite works though. If BIO_flush completes
>>> asynchronously
>>
>> Ahhh, yes good point. Updated patch attached.
>>
>>> (hrm, it's missing an rwstate update),
>>
>> Yes, just discovered that myself and then came back and reread your
>> email to find out you already pointed it out! Also addressed in updated
>> patch.
>>
> 
> The new patch seems to almost work. I merged it into our codebase since we
> hadn't diverged too much on that function yet and ran it against our tests
> (fixed to actually stress low MTUs). The s->init_off <=
> DTLS1_HM_HEADER_LENGTH assertion is only true in the frag_off > 0 case.
> After moving it there, everything passes.
> 
> For reference, here's the merged version:
> https://boringssl-review.googlesource.com/#/c/6424/

Great! Thanks David.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello

[Matt Caswell via RT]

Hi David,

On 03/11/15 01:58, David Benjamin via RT wrote:
> Hey folks,
> 
> We found a small DTLS bug while writing some tests. I think it affects
> 1.0.1 and 1.0.2 too, so I thought I'd send you a note. (Note sure about
> master. I'm unfamiliar with the new state machine mechanism.)

Just from looking at the code I think master should be ok. In the new
state machine, writes go through a "pre-work" phase where
ssl3_init_finished_mac is called for DTLS. This pre-work is skipped if
the actual write needs a retry.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello

[Matt Caswell]

On 03/11/15 18:28, Viktor Dukhovni wrote:
> On Tue, Nov 03, 2015 at 04:16:37PM +0000, Matt Caswell via RT wrote:
> 
>> One other related point is that fragmenting ClientHellos is probably a
>> bad idea. The whole ClientHello/HelloVerifyRequest mechanism is meant to
>> be implemented without storing state on the server. That isn't possible
>> if you have to deal with fragment reassembly. In the new DTLSv1_listen
>> implementation in master we drop fragmented ClientHellos.
> 
> I assume you mean fragmentation across multiple TLS record layer
> packets, not UDP fragmentation into multiple IP layer fragments...

Yes - multiple DTLS record layer packets.

> 
> Presumably the kernel delivers reassembled UDP datagrams to user-land,
> so OpenSSL's DTLS never sees UDP fragmentation.

Yes.

> 
> I expect that DTLS is allowed to use UDP datagrams that are larger
> than the IP MTU, but if these MUST be fragmented at TLS record
> layer instead, then client HELLO packets can't carry very large
> extensions, and in particular session tickets could run into trouble...

OpenSSL tries to keep DTLS packets within the MTU if possible. I like
David's idea of dropping non-initial ClientHello fragments and only
requiring that the cookie needed for ClientHello/HelloVerifyRequest is
kept within the initial fragment, rather than requiring that the whole
ClientHello fits into a single fragment. I'll take a look at that.

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4119] DTLS resets handshake hash too frequently for ClientHello

[Matt Caswell via RT]

Hi David

On 03/11/15 01:58, David Benjamin via RT wrote:
> Hey folks,
> 
> We found a small DTLS bug while writing some tests. I think it affects
> 1.0.1 and 1.0.2 too, so I thought I'd send you a note. (Note sure about
> master. I'm unfamiliar with the new state machine mechanism.)
> 
> In DTLS, each ClientHello is supposed to reset the handshake hash (in case
> of HelloVerifyRequest). The old state machine calls ssl3_init_finished_mac
> in the SSL3_ST_CW_CLNT_HELLO_* states.
> 
> https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=ssl/d1_clnt.c;h=feeaf6d0656f5d0868121852d42b5037b8823111;hb=refs/heads/OpenSSL_1_0_2-stable#l317
> 
> If the ClientHello is fragmented and takes multiple iterations to write,
> the state machine is re-entered in SSL3_ST_CW_CLNT_HELLO_B, which
> calls ssl3_init_finished_mac again, and clobbers what was sampled to the
> handshake hash/buffer previously.
> 
> This requires the transport return a retriable error on write, which
> probably isn't common for DTLS. It came up because WebRTC uses a custom BIO
> with a fixed-size buffer, so it can actually do this. Even then, a
> ClientHello is unlikely to fill up the buffer. Our tests repro'd it in
> BoringSSL by forcing every write to take two iterations.

I can confirm this issue on 1.0.2 (and almost certainly 1.0.1). It does
not affect master.

Whilst investigating this I noticed another bug which is actually
probably more significant. My eyeball only look at the BoringSSL source
suggests that it is there too, so I'm not sure why you haven't seen it
in the test that you mentioned.

If a retry occurs on a second or subsequent fragment of a handshake
message then when we do the retry the wrong fragment offset and length
is used. The impact isn't that great because the messages got dropped by
the peer, and then when they get retransmitted they have the correct
values inserted...so the handshake succeeds - but it gets delayed.
Perhaps that is why you don't see it in your test.

This second issue occurs in all branches.

One other related point is that fragmenting ClientHellos is probably a
bad idea. The whole ClientHello/HelloVerifyRequest mechanism is meant to
be implemented without storing state on the server. That isn't possible
if you have to deal with fragment reassembly. In the new DTLSv1_listen
implementation in master we drop fragmented ClientHellos.

Patch attached for these two issues (patch against 1.0.2).

Matt


>From 35b6c161b032bd2e04e54e80120f72b5d586c031 Mon Sep 17 00:00:00 2001
From: Matt Caswell <m...@openssl.org>
Date: Tue, 3 Nov 2015 14:45:07 +
Subject: [PATCH 1/2] Fix DTLS handshake fragment retries

If using DTLS and NBIO then if a second or subsequent handshake message
fragment hits a retry, then the retry attempt uses the wrong fragment
offset value. This commit restores the fragment offset from the last
attempt.
---
 ssl/d1_both.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/ssl/d1_both.c b/ssl/d1_both.c
index c2c8d57..59a79a7 100644
--- a/ssl/d1_both.c
+++ b/ssl/d1_both.c
@@ -337,9 +337,26 @@ int dtls1_do_write(SSL *s, int type)
  */
 if (type == SSL3_RT_HANDSHAKE) {
 if (s->init_off != 0) {
+/* We must be writing a fragment other than the first one */
 OPENSSL_assert(s->init_off > DTLS1_HM_HEADER_LENGTH);
-s->init_off -= DTLS1_HM_HEADER_LENGTH;
-s->init_num += DTLS1_HM_HEADER_LENGTH;
+
+if (frag_off > 0) {
+/*
+ * This is the first attempt at writing out this fragment.
+ * Adjust |init_off| and |init_num| to add a new message
+ * header.
+ */
+s->init_off -= DTLS1_HM_HEADER_LENGTH;
+s->init_num += DTLS1_HM_HEADER_LENGTH;
+} else {
+/*
+ * We must have been called again after a retry so use the
+ * fragment offset from our last attempt. We do not need
+ * to adjust |init_off| and |init_num| as above, because
+ * that should already have been done before the retry.
+ */
+frag_off = s->d1->w_msg_hdr.frag_off;
+}
 
 /*
  * We just checked that s->init_num > 0 so this cast should
-- 
2.1.4


>From b0ff7bdae8e7ae6b46a1d95d73ef887673684d0a Mon Sep 17 00:00:00 2001
From: Matt Caswell <m...@openssl.org>
Date: Tue, 3 Nov 2015 15:49:08 +
Subject: [PATCH 2/2] Only call ssl3_init_finished_mac once for DTLS

In DTLS if an IO retry occurs during writing of a fragmented ClientHello
then we can end up reseting the finish mac variables on the retry, which
causes a handshake failure. We should only reset on 

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 02/11/15 10:16, Albe Laurenz via RT wrote:
> Hubert Kario wrote:
>> On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote:
>>> My concern though is broader than this specific case. I have given two
>>> *examples* of exploits that we may open ourselves up to if we attempt
>>> to process this application data without some fairly significant
>>> refactoring of the code to separate out state currently in the
>>> process of being negotiated from state for the current epoch. We
>>> could probably patch things up to work around these two specific
>>> examples but I worry that without the more significant refactoring
>>> work, we may open ourselves up to other attacks that we haven't
>>> thought of.
>>
>> unfortunately I have to agree. Those two examples show in rather clear
>> terms that openssl as it is now in stable branches, can't be easily
>> patched up to handle even specific situations of interleaved app data
>> with handshake data in renegotiated handshakes. So breaking such
>> connections is a safer option.
>>
>> That being said, Java behaviour is dangerous only if they expose to the
>> application the "in negotiation" context instead of the "currently
>> active" context. Not exactly easy to test.
> 
> Sorry for being obtuse, but I don't see yet why these concerns should
> prevent a simple fix.
> 
> If interleaved application data are only allowed
> a) before Change Cipher Spec
> b) during a renegotiation, i.e., when the connection is encrypted
> 
> your second example and similar exploits would not work, because the
> application data would have to be encrypted with a cipher that is
> known to be secure.

I don't they you have understood the exploit. In my second example the
*attacker* initiates the connection to the server *and* the subsequent
renegotiation. Therefore the attacker already knows the keys negotiated
during the initial handshake. She does *not* know the keys associated
with the session that is going to be renegotiated. But she doesn't need
to know those because she sends application data before that encryption
context is in place, but after the new identity has been associated with
the connection. This attack is about stealing an identity not about
eavesdropping encrypted data.


> 
> That leaves us with the first problem, namely that calls like
> SSL_get_peer_certificate() will return incorrect values when renegotiation
> has started but is not yet complete.
> 
> I agree that the window for such a mistake will be widened somewhat
> if the client were allowed to send application data after renegotiation
> has started, but the problem already exists in the current code, right?

No. In the current code, once renegotiation has started then no
application data will be returned to the application until it has
completed (or if application data is encountered then the connection
will abort). So there will never be a scenario where application data is
returned and the connection is in an intermediate state.

> 
> What keeps the client from first sending the application data that cause
> the dangerous call by the server and immediately afterwards starting a
> renegotiation with a certificate for which they have no private key?
> 
> So I think that that is a separate issue that should not be held against
> an improvement like the one this patch would provide.
> Maybe it can be fixed by disallowing callbacks that would return
> incorrect data while renegotiation is in progress.

It isn't just callbacks. A call to SSL_read will return to the calling
application mid-renegotiation if application data is encountered.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 25/10/15 11:12, Albe Laurenz via RT wrote:
> Matt Caswell wrote:
>> On 23/10/15 15:33, Albe Laurenz wrote:
>>> Matt Caswell wrote:
>>>> Imagine an attacker who is able to eavesdrop on messages between a
>>>> legitimate client who presents a client certificate to the server during
>>>> the initial handshake. As it is during the initial handshake this
>>>> happens in the clear, including the server responding with a session id.
>>>>
>>>> Ordinarily knowing the session id does not help very much because the
>>>> attacker does not know the associated keys so any attempt to reuse that
>>>> session id will fail. However with the proposed patch in place the
>>>> attacker can first establish a connection to the server anonymously.
>>>> Then they send a new ClientHello, but this time provide the eavesdropped
>>>> session id. The server updates the s->session value from the session
>>>> cache which *includes* the peer certificate. The exploit can then
>>>> proceed as before. The attacker does not continue the renegotiation
>>>> handshake but instead sends application data attempting a privileged
>>>> operation and the server application successfully verifies the identity.
>>>
>>> Do you mean that the attacker pretends to be the legitimate client
>>> and initiates renegotiation on their behalf?
>>>
>>> I thought that the ClientHello would have to be encrypted in that case,
>>> something which the attacker couldn't do.
>>
>> No, that's not what I meant. The attacker eavesdrops on the initial
>> handshake between a legitimate client (where that client has presented a
>> certificate) and the server and makes a note of the session id.
>>
>> The attacker then creates a completely new anonymous connection (they
>> don't use the session id yet). Then they initiate a renegotiation, but
>> this time present the stolen session id. Before they complete the reneg
>> handshake they start sending application data. That application data
>> will be processed by the server application in the context of the
>> certificate associated with the stolen session, but before the CCS has
>> been processed.
> 
> I think I get you - you are talking of an "abbreviated handshake" to duplicate
> an existing session.
> 
> But RFC 5246 writes:
> 
>When the client and server decide to resume a previous session or
>duplicate an existing session (instead of negotiating new security
>parameters), the message flow is as follows:
> 
>The client sends a ClientHello using the Session ID of the session to
>be resumed.  The server then checks its session cache for a match.
>If a match is found, and the server is willing to re-establish the
>connection under the specified session state, it will send a
>ServerHello with the same Session ID value.  At this point, both
>client and server MUST send ChangeCipherSpec messages and proceed
>directly to Finished messages.  Once the re-establishment is
>complete, the client and server MAY begin to exchange application
>layer data.
> 
> That seems to spell out in pretty uncertain terms that no application data
> may be exchanged until the handshake is complete, so OpenSSL should just
> error out in that case.

I don't think that it does say that. At least not the way I read it. The
Client does not know that its request to reuse a session has been
accepted by the server until it processes the ServerHello. I see nothing
in the above which says a client is not allowed to send application data
after it has sent its ClientHello but before it has processed the
ServerHello.

>From a server perspective if it receives ApplicationData after it has
sent the ServerHello it would have to assume that it is "in transit"
application data sent from the client before it has processed the
ServerHello.

My concern though is broader than this specific case. I have given two
*examples* of exploits that we may open ourselves up to if we attempt to
process this application data without some fairly significant
refactoring of the code to separate out state currently in the process
of being negotiated from state for the current epoch. We could probably
patch things up to work around these two specific examples but I worry
that without the more significant refactoring work, we may open
ourselves up to other attacks that we haven't thought of.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 23/10/15 15:33, Albe Laurenz wrote:
> Matt Caswell wrote:
>> On 16/10/15 16:05, Hubert Kario via RT wrote:
>>> we may actually be able to patch this up partially in 1.0.x
>>>
>>> the original problem description mentions server being unable to process
>>> application data before Certificate/Client Key Exchange, not in any
>>> place what so ever
>>>
>>> (Albe, please double check if you didn't saw Java sending app data at
>>> any different point)
>>>
>>> unless the server is completely asynchronous, it's unlikely it will send
>>> application data messages between handshake messages from a single
>>> flight, it will send app data only between different flights
>>>
>>> in other words, we should still be able to accept this data before the
>>> client responses had any chance to modify the certificates in the
>>> server.
>>
>> I think this is also not safe, in a slight amendment to my previous exploit.
>>
>> Imagine an attacker who is able to eavesdrop on messages between a
>> legitimate client who presents a client certificate to the server during
>> the initial handshake. As it is during the initial handshake this
>> happens in the clear, including the server responding with a session id.
>>
>> Ordinarily knowing the session id does not help very much because the
>> attacker does not know the associated keys so any attempt to reuse that
>> session id will fail. However with the proposed patch in place the
>> attacker can first establish a connection to the server anonymously.
>> Then they send a new ClientHello, but this time provide the eavesdropped
>> session id. The server updates the s->session value from the session
>> cache which *includes* the peer certificate. The exploit can then
>> proceed as before. The attacker does not continue the renegotiation
>> handshake but instead sends application data attempting a privileged
>> operation and the server application successfully verifies the identity.
> 
> Do you mean that the attacker pretends to be the legitimate client
> and initiates renegotiation on their behalf?
> 
> I thought that the ClientHello would have to be encrypted in that case,
> something which the attacker couldn't do.

No, that's not what I meant. The attacker eavesdrops on the initial
handshake between a legitimate client (where that client has presented a
certificate) and the server and makes a note of the session id.

The attacker then creates a completely new anonymous connection (they
don't use the session id yet). Then they initiate a renegotiation, but
this time present the stolen session id. Before they complete the reneg
handshake they start sending application data. That application data
will be processed by the server application in the context of the
certificate associated with the stolen session, but before the CCS has
been processed.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

[Matt Caswell via RT]

There seems a strong consensus to change this so:
https://github.com/openssl/openssl/commit/3fde6c9276c9cd6e56e8e06e756350a4fbdd7031

Closing this ticket.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 16/10/15 16:05, Hubert Kario via RT wrote:
> we may actually be able to patch this up partially in 1.0.x
> 
> the original problem description mentions server being unable to process 
> application data before Certificate/Client Key Exchange, not in any 
> place what so ever
> 
> (Albe, please double check if you didn't saw Java sending app data at 
> any different point)
> 
> unless the server is completely asynchronous, it's unlikely it will send 
> application data messages between handshake messages from a single 
> flight, it will send app data only between different flights
> 
> in other words, we should still be able to accept this data before the 
> client responses had any chance to modify the certificates in the 
> server.
> 
> of course, that doesn't allow us to fix it for the other side of 
> connection - where the application data is sent by server after Server 
> Hello Done and before server Change Cipher Spec

I think this is also not safe, in a slight amendment to my previous exploit.

Imagine an attacker who is able to eavesdrop on messages between a
legitimate client who presents a client certificate to the server during
the initial handshake. As it is during the initial handshake this
happens in the clear, including the server responding with a session id.

Ordinarily knowing the session id does not help very much because the
attacker does not know the associated keys so any attempt to reuse that
session id will fail. However with the proposed patch in place the
attacker can first establish a connection to the server anonymously.
Then they send a new ClientHello, but this time provide the eavesdropped
session id. The server updates the s->session value from the session
cache which *includes* the peer certificate. The exploit can then
proceed as before. The attacker does not continue the renegotiation
handshake but instead sends application data attempting a privileged
operation and the server application successfully verifies the identity.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

[Matt Caswell via RT]

On 15/10/15 20:53, Alexander Cherepanov via RT wrote:
> On 2015-10-15 15:41, Matt Caswell via RT wrote:
>> The purpose of the sanity check is not then for security, but to guard
>> against programmer error. For a correctly functioning program this test
>> should never fail. For an incorrectly functioning program it may do. It
>> is not guaranteed to fail because the test could be compiled away but,
>> most likely, it will. We can have some degree of confidence that the
>> test works and does not get compiled away in most instances because, as
>> you point out, an explicit check for it appears in packettest.c and, to
>> date, we have had no reported failures.
> 
> What was not entirely clear from the original bug report is that, while 
> the check is not compiled away, it's compiled into something completely 
> different from what is written in the source. Specifically, the check 
> "buf + len < buf" is optimized into "len >> 63" on 64-bit platform, i.e. 
> "(ssize_t)len < 0" or "len > SIZE_MAX / 2". This is not a check for 
> overflow at all, it doesn't even depend on the value of "buf".
> 
> If this is what was intended then it's better to write it explicitly. If 
> this is not what was intended then some other approach is required.

I'd say that is an instance of the compiler knowing better than us how
big |len| would have to be in order to trigger an overflow. Those rules
are going to be platform specific so we should not attempt to second
guess them, but instead let the optimiser do its job.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4093] Problem loading engine from config

[Matt Caswell via RT]

On Wed Oct 14 19:29:42 2015, beld...@gmail.com wrote:
> Hello!
>
> The attached patch fixes it.

Patch applied. Thanks!

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 16/10/15 11:57, Kurt Roeckx via RT wrote:
> On Fri, Oct 16, 2015 at 08:53:06AM +0000, Matt Caswell via RT wrote:
>>
>> So now I really don't know what the "right" way forward is. Should we be
>> applying the patch or not?
> 
> Has anybody contact Oracle about this issue?  It seems useful that
> they fix it on their end, regardless of what we do.

No, but according to the spec they are doing it right - nothing to fix.
That's part of the problem: the spec says one thing but the advice we
are getting from TLS WG says something slightly different.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 13/10/15 12:31, Hubert Kario via RT wrote:
> On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote:
>> On 12/10/15 17:19, Matt Caswell via RT wrote:
>>> On 12/10/15 16:39, Matt Caswell via RT wrote:
>>>> The value of "in_read_app_data" not being true when it is supposed
>>>> to
>>>> appears to be running into a slightly different bug. It's also
>>>> present in 1.0.2 but you have to switch off version negotiation.
>>>> So running s_server like this in 1.0.2 and rerunning Hubert's test
>>>> will hit it:
>>>>
>>>> openssl s_server -www -tls1_2
>>>>
>>>> The 1.0.2 version negotiation is hiding the issue. In master
>>>> version neg has been completely rewritten and simplified - but in
>>>> doing so no longer hides the problem. :-(
>>>
>>> Having done some more digging it seems the problem only occurs if
>>> you
>>> get the initial handshake, following by a second reneg handshake
>>> *and* interleaved app data all within the scope of a *single*
>>> SSL_read call. AFAICT if SSL_read returns between the first
>>> handshake and the second, you don't get the problem.
>>
>> Ok, updated version of the patch attached. This is for 1.0.2 but
>> should pass Hubert's tests even when you run s_server with "-tls1_2".
> 
> yup, looks good with -tls1_2 now too
> 
> for some reason my side can't negotiate TLS 1.1 or TLS 1.0 correctly so 
> can't test -tls1_1 or -tls1 (I'm likely generating malformed CKE there, 
> but need to check to be sure)

I raised the ambiguity in the spec about when in the handshake
interleaved app data is allowed with the TLS WG. You can see the thread
here:
https://www.ietf.org/mail-archive/web/tls/current/threads.html#18017

I got a few responses, not all of which were consistent, and giving
different views. To summarise what I interpret as the main points:

1) Where a view was given it seemed to concur with the views expressed
here that the most sensible interpretation of the spec wording is that
interleaved app data is allowed up until the CCS, but not between CCS
and Finished.
2) There was also a view expressed that, regardless of what the spec
says, allowing interleaved app data is *dangerous*!
3) There seemed to be differing views on just how dangerous ranging from
it being "a highly dangerous idea" to "...there is a need for caution,
but in reality, it's not like you can use renegotiation to hand-off to
someone else entirely.  The person you are talking to hasn't changed.
What is dangerous is making assertions about *new* things that the
renegotiation introduces", although the same person who made that last
observation also provided a list of very onerous mitigations that we
should put in place if were to do it (none of which are likely to be
adopted IMO without some form of official advice from the TLS WG).

So now I really don't know what the "right" way forward is. Should we be
applying the patch or not?

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell]

On 16/10/15 09:53, Matt Caswell via RT wrote:
> 
> 
> On 13/10/15 12:31, Hubert Kario via RT wrote:
>> On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote:
>>> On 12/10/15 17:19, Matt Caswell via RT wrote:
>>>> On 12/10/15 16:39, Matt Caswell via RT wrote:
>>>>> The value of "in_read_app_data" not being true when it is supposed
>>>>> to
>>>>> appears to be running into a slightly different bug. It's also
>>>>> present in 1.0.2 but you have to switch off version negotiation.
>>>>> So running s_server like this in 1.0.2 and rerunning Hubert's test
>>>>> will hit it:
>>>>>
>>>>> openssl s_server -www -tls1_2
>>>>>
>>>>> The 1.0.2 version negotiation is hiding the issue. In master
>>>>> version neg has been completely rewritten and simplified - but in
>>>>> doing so no longer hides the problem. :-(
>>>>
>>>> Having done some more digging it seems the problem only occurs if
>>>> you
>>>> get the initial handshake, following by a second reneg handshake
>>>> *and* interleaved app data all within the scope of a *single*
>>>> SSL_read call. AFAICT if SSL_read returns between the first
>>>> handshake and the second, you don't get the problem.
>>>
>>> Ok, updated version of the patch attached. This is for 1.0.2 but
>>> should pass Hubert's tests even when you run s_server with "-tls1_2".
>>
>> yup, looks good with -tls1_2 now too
>>
>> for some reason my side can't negotiate TLS 1.1 or TLS 1.0 correctly so 
>> can't test -tls1_1 or -tls1 (I'm likely generating malformed CKE there, 
>> but need to check to be sure)
> 
> I raised the ambiguity in the spec about when in the handshake
> interleaved app data is allowed with the TLS WG. You can see the thread
> here:
> https://www.ietf.org/mail-archive/web/tls/current/threads.html#18017
> 
> I got a few responses, not all of which were consistent, and giving
> different views. To summarise what I interpret as the main points:
> 
> 1) Where a view was given it seemed to concur with the views expressed
> here that the most sensible interpretation of the spec wording is that
> interleaved app data is allowed up until the CCS, but not between CCS
> and Finished.
> 2) There was also a view expressed that, regardless of what the spec
> says, allowing interleaved app data is *dangerous*!
> 3) There seemed to be differing views on just how dangerous ranging from
> it being "a highly dangerous idea" to "...there is a need for caution,
> but in reality, it's not like you can use renegotiation to hand-off to
> someone else entirely.  The person you are talking to hasn't changed.
> What is dangerous is making assertions about *new* things that the
> renegotiation introduces", although the same person who made that last
> observation also provided a list of very onerous mitigations that we
> should put in place if were to do it (none of which are likely to be
> adopted IMO without some form of official advice from the TLS WG).
> 
> So now I really don't know what the "right" way forward is. Should we be
> applying the patch or not?

I should add that another interesting point was that BoringSSL prohibits
interleaved app data.

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 16/10/15 10:56, Hubert Kario via RT wrote:
> On Friday 16 October 2015 08:53:06 Matt Caswell via RT wrote:
>> So now I really don't know what the "right" way forward is. Should we
>> be applying the patch or not?
> 
> I can't think of a way to exploit it if two assumptions hold:
>  1). we have secure renegotiation
>  2). API calls return metadata (certificates especially) from *active* 
>  context, not one currently negotiated

But here is where we come unstuck I think. I've given this some thought
and I think there is an exploit if we were to apply the patch as is.

Consider a reneg where the server has requested a client certificate.
The client responds with a valid certificate and chainbut where they
do not possess the private key, i.e. they are attempting to impersonate
someone else. The client sends the Certificate message and the server
extracts it and verifies it successfully.

On the server side the Certificate message is processed via the function
"ssl3_get_client_certificate()". At the end of this function there are
these two lines of code:

s->session->peer = sk_X509_shift(sk);
s->session->verify_result = s->verify_result;

|s->session->peer| stores the newly received Certificate away for future
use. Note that at this point the result of the verification (which is
successful) is stored in both |s->session->verify_result| and
|s->verify_result|.

Now, before sending the CertificateVerify message, the client sends
application data. Maybe that application data causes the application to
try to do something privileged that only authorised users are allowed to
do, so the application calls SSL_get_peer_certificate():

X509 *SSL_get_peer_certificate(const SSL *s)
{
X509 *r;

if ((s == NULL) || (s->session == NULL))
r = NULL;
else
r = s->session->peer;

if (r == NULL)
return (r);

X509_up_ref(r);

return (r);
}

And SSL_get_verify_result():

long SSL_get_verify_result(const SSL *ssl)
{
return (ssl->verify_result);
}

So these API calls will return the *new* certificate and verification
result *before* a CertificateVerify has been received.

Fixing this sort of problem is going to be *hard* and probably require
quite a lot of non-trivial changes - definitely not the sort of the
thing I want to be doing in a stable branch. Fixing this is an example
of what I meant by "onerous mitigations", but I now realise it is
absolutely necessary if we wanted to pursue this.

I think we should be marking this as a "won't fix" for all released
versions. The question is whether we should even attempt to fix it for
1.1.0 or not.

Matt





___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

[Matt Caswell via RT]

On 16/10/15 17:32, Viktor Dukhovni wrote:
> On Fri, Oct 16, 2015 at 04:09:57PM +, Kaduk, Ben via RT wrote:
> 
>> I hope I am not dragging this thread on too long, but with all due
>> respect, we are not asking the compiler/optimizer to detect overflow --
>> we are asking the compiler to instantiate undefined behavior in a way
>> that is convenient for us.  This will only happen by chance, as a side
>> effect of some other decisions made by the compiler authors, in the
>> present state of compiler development.
> 
> My take is that we should generally stay clear of relying on any
> remotely sensible outcome for undefined behaviour.  If this thread
> is about such a situation, then we may have to code around the
> issue.
> 

We are *not* relying on that. Or at least we are only to the extent that
we are talking about a scenario where something has gone wrong already
and undefined behaviour is inevitable. We are hoping that our undefined
behaviour is likely to be slightly less bad than the undefined behaviour
that we would get otherwise. We cannot know that it will be...but in
reality there is a reasonable chance that it will.

In a well-behaved program there is no undefined behaviour. The "buf +
len < buf" check will always evaluate to false, so in that sense is
useless but it *is* well defined.

In a non well-behaved program if we remove the check then undefined
behaviour is almost certainly inevitable. Who don't know what it will do
(it could do anything), but there is a reasonable chance that it could
result in the disclosure or use of memory it shouldn't be touching. A
CVE is quite a possible result of such undefined behaviour.

In a non well-behaved program if we keep the check then we still have
undefined behaviour. The check could do what we kind of expect that it
might, it might do nothing at all, or it could do something entirely
different. But without the check undefined behaviour is inevitable
anyway, so in that sense we are no better off one way or the other. In
reality however we have a reasonable hope that the check will do
something like what we hope it might, in which case we will prevent a
possible security issue.

That said the packettest test where we deliberately use -1 for a len, is
actually deliberately relying on undefined behaviour so perhaps should
be changed. It may also be reasonable to add an additional max length check.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

[Matt Caswell via RT]

On 15/10/15 04:11, Pascal Cuoq via RT wrote:
> As of 2015-10-14, the function PACKET_buf_init in ssl/packet_locl.h
> reads:
> 
> static inline int PACKET_buf_init(PACKET *pkt, unsigned char *buf,
> size_t len) { /* Sanity check for negative values. */ if (buf + len <
> buf) return 0;
> 
> pkt->curr = buf; pkt->remaining = len; return 1; }
> 
> Link:
> https://github.com/openssl/openssl/blob/310115448188415e270bb0bef958c7c130939838/ssl/packet_locl.h#L113
>
>  The rules of pointer arithmetics are such that the condition (buf +
> len < buf) is always false when it is defined. A modern compiler, or
> even an old compiler, could suppress the entire conditional from the
> generated code without a second thought and without a warning. Please
> read https://lwn.net/Articles/278137/ . Note that in that very
> similar instance, the GCC developers did not acknowledge any bug in
> their compiler, did not change the compiler's behavior, and simply
> regretted that "their project has been singled out in an unfair
> way".
> 
> That LWN story is not a about a compiler bug, or in any case, it is
> about a compiler bug that is here to stay. And according to GCC
> developers, to be common to several C compilers.

The LWN story is about secure coding, and a specific pitfall to be aware
of which may compile away a test for buffer underflow. Specifically they
are talking about a length value received from an untrusted source and
testing that it falls within the bounds of a buffer.

That is *not* the case here. This test is not about adding a critical
security check. The contract that PACKET_buf_init provides to code using
it requires that the buffer provided must be (at least) |len| bytes
long. It is for the calling code to perform this necessary security
checks prior to calling PACKET_buf_init. This code can assume that |len|
is from a trusted source.

The purpose of the sanity check is not then for security, but to guard
against programmer error. For a correctly functioning program this test
should never fail. For an incorrectly functioning program it may do. It
is not guaranteed to fail because the test could be compiled away but,
most likely, it will. We can have some degree of confidence that the
test works and does not get compiled away in most instances because, as
you point out, an explicit check for it appears in packettest.c and, to
date, we have had no reported failures.


> 
> As far as I can tell, no current compiler recognizes that the very
> same reasoning as in that old LWN story justifies the suppression of
> the conditional. I tested the compilers currently available on
> https://gcc.godbolt.org . However, any compiler willing to miscompile
> the examples in the LWN article would gladly miscompile the function
> PACKET_buf_init given the chance.
> 
> If the function is intended to return 0 for large values of len, then
> the test should look like:
> 
> if (len > (size_t)(SIZE_MAX / 2)) ...
> 
> Here I have chosen a constant that happens to give a behavior close
> to the one obtained by luck with current compilers. If another
> constant makes sense, then that other constant can be used. The
> current implementation is an invitation for the compiler to generate
> code that, even when len is above the limit, sets pkt->curr to buf,
> sets pkt->remaining to len, and returns 1, which is not what is
> intended, and could have serious security-related consequences latter
> on.

The biggest packet that I can think of that we will ever have to deal
with within libssl would be a handshake message. This has a maximum
length of 0xff plus 5 bytes of message header, i.e. 0x104. There
could be an argument to say we should test against this to ensure that
|len| is not too big.

However that does not necessarily guard against the pointer overflowing.
In an incorrect program where len is just a bit bigger than the actual
size of buf this could, theoretically, be sufficient to overflow the
pointer.


> 
> If, as the comment implies, the function is not intended to be called
> with a len so large that it causes (uintptr_t)buf + len to be lower
> than (uintptr_t)buf, then please, please, please simplify the
> function by removing this nonsensical "sanity check", and make this
> function, which cannot fail, return void-as the history of the rest
> of OpenSSL shows, remembering of testing all error codes returned by
> called functions is difficult enough, even when only functions that
> have reason to fail return such codes.

You are correct that this has historically been a problem. All the dev
team use the "--strict-warnings" parameter to config. One of the effects
of this is to treat warnings as errors and this will therefore fail on
any function declared with "__owur" where the return value is unused. We
should ensure that PACKET_buf_init is declared with this (and I believe
Emilia is making that change). Therefore this should not be an issue for
this code.

> 
> PACKET_buf_init is called with (size_t)-1 for len in
> 

Re: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init

[Matt Caswell via RT]

On 15/10/15 14:35, Salz, Rich via RT wrote:
> 
>> PACKET_buf_init. This code can assume that |len| is from a trusted source.
>>
>> The purpose of the sanity check is not then for security, but to guard 
>> against
>> programmer error. For a correctly functioning program this test should never
>> fail.
> 
> I would say that the combination of these two things means that it should be 
> an assert.

assert has its uses, but it depends what you are trying to achieve. If
you are developing new code and trying to track down a difficult to find
problem - very useful. Even potentially if you are trying to track down
a difficult issue in a production scenario, you could create a special
debug build to help you pinpoint what is going wrong. I'm sure there are
other scenarios which would be excellent uses of assert.

IMO this test is about protecting ourselves in the unlikely event that a
programmer error does not present itself until production. To protect
production code assert is useless because it gets compiled away.

If we are concerned about potential programmer errors not appearing
until we get into production then assert is not the right tool. You
could argue that you should use OPENSSL_assert(), but my views on that
are well known. OPENSSL_assert calls abort() even in production which is
wrong IMO and potentially dangerous. I know opinions differ on that
point within the dev team and this ticket is probably not the place to
reopen that particular debate. Suffice it to say I would not support the
use of OPENSSL_assert here.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 12/10/15 17:19, Matt Caswell via RT wrote:
> 
> 
> On 12/10/15 16:39, Matt Caswell via RT wrote:
>>
>>
>> On 12/10/15 16:03, Alessandro Ghedini via RT wrote:
>>> On Mon, Oct 12, 2015 at 01:45:20PM +, Hubert Kario via RT wrote:
>>>> On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote:
>>>>> On 09/10/15 19:02, Hubert Kario via RT wrote:
>>>>>> And for good measure, I also created a test script that
>>>>>> combines fragmentation with interleaving.
>>>>>
>>>>> Did you try my patch with it? And if so what happened?
>>>>
>>>> I'm using interleave-data-102.patch attached to this ticket.
>>>>
>>>> So, for state-machine-rewrite branch it doesn't apply, there's no 
>>>> ssl/s3_pkt.c file.
>>>>
>>>> For current 1.0.1 branch, the patch applies, test case results are as 
>>>> follows:
>>>>  * test-openssl-3712.py - pass
>>>>  * test-interleaved-application-data-in-renegotiation.py - pass
>>>>  * test-interleaved-application-data-and-fragmented-handshakes-in-
>>>> renegotiation.py - pass
>>>>
>>>> For current 1.0.2 branch, the patch applies, tests case results are as 
>>>> follows:
>>>>  * test-openssl-3712.py - pass
>>>>  * test-interleaved-application-data-in-renegotiation.py - pass
>>>>  * test-interleaved-application-data-and-fragmented-handshakes-in-
>>>> renegotiation.py - pass
>>>>
>>>> for current master the patch doesn't apply, just like with state-
>>>> machine-rewrite there's no ssl/s3_pkt.c file
>>>>
>>>> Note: the two latter test cases need the s_server run in -www mode, the 
>>>> first test case ignores server response so will work regardless, that 
>>>> may be why Alessandro testing doesn't show the issue as fixed
>>>
>>> Ah, yep, with -www it works for me too. Note that on master the file to 
>>> change
>>> should be ssl/record/ssl3_record.c. However, while the patch applies 
>>> cleanly to
>>> this file, all the tests fail (even with -www). It seems that the field
>>> in_read_app_data is never true, so the UNEXPECTED_MESSAGE alert is sent.
>>
>> The value of "in_read_app_data" not being true when it is supposed to
>> appears to be running into a slightly different bug. It's also present
>> in 1.0.2 but you have to switch off version negotiation. So running
>> s_server like this in 1.0.2 and rerunning Hubert's test will hit it:
>>
>> openssl s_server -www -tls1_2
>>
>> The 1.0.2 version negotiation is hiding the issue. In master version neg
>> has been completely rewritten and simplified - but in doing so no longer
>> hides the problem. :-(
> 
> Having done some more digging it seems the problem only occurs if you
> get the initial handshake, following by a second reneg handshake *and*
> interleaved app data all within the scope of a *single* SSL_read call.
> AFAICT if SSL_read returns between the first handshake and the second,
> you don't get the problem.
> 
> That's starting to sound like quite an unlikely scenario and we're only
> hitting it now because of the slightly artificial nature of Hubert's
> test. I'm wondering whether "will not fix" is the right response to this
> second bug? Thoughts? Having said that it would be nice to have a
> reliable test for the interleaved-app data issue.

Ok, updated version of the patch attached. This is for 1.0.2 but should
pass Hubert's tests even when you run s_server with "-tls1_2".

Matt


>From af12b252a13444fa7cb072b6cba172716304b289 Mon Sep 17 00:00:00 2001
From: Matt Caswell <m...@openssl.org>
Date: Fri, 25 Sep 2015 10:34:27 +0100
Subject: [PATCH 1/2] Allow interleaved app data in a renegotiation

Prior to TLS1.1 SSL3/TLS1.0 was ambigous about what to do with application
data received during a renegotiation handshake. The existing code (which
predates TLS1.1) disallows this. TLS1.1 clarifies the situation to
explicitly allow this. This patch enables interleaved app data up until the
point that the CCS is received. Whilst the RFC does not explicitly say so
it seems incorrect to allow it after this point.

RT#3712
---
 ssl/s3_pkt.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/ssl/s3_pkt.c b/ssl/s3_pkt.c
index 3798902..22a27cf 100644
--- a/ssl/s3_pkt.c
+++ b/ssl/s3_pkt.c
@@ -1608,18 +1608,14 @@ int ssl3_read_bytes(SSL *s, int type, unsigned char *buf, int len, int peek)
  * application data.  If the library was running inside ssl3_read()
   

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 13/10/15 11:55, Hubert Kario via RT wrote:
>>> The value of "in_read_app_data" not being true when it is supposed
>>> to
>>> appears to be running into a slightly different bug. It's also
>>> present in 1.0.2 but you have to switch off version negotiation. So
>>> running s_server like this in 1.0.2 and rerunning Hubert's test
>>> will hit it:
>>>
>>> openssl s_server -www -tls1_2
>>>
>>> The 1.0.2 version negotiation is hiding the issue. In master version
>>> neg has been completely rewritten and simplified - but in doing so
>>> no longer hides the problem. :-(
>>
>> Having done some more digging it seems the problem only occurs if you
>> get the initial handshake, following by a second reneg handshake *and*
>> interleaved app data all within the scope of a *single* SSL_read
>> call. AFAICT if SSL_read returns between the first handshake and the
>> second, you don't get the problem.
> 
> It's completely valid and not at all unlikely to have two record layer 
> records inside single TCP packet...

Oh, yes. That is common. I think what is less common is to have two
handshakes back-to-back with the first app data received being
interleaved in the second handshake.

In any case the new patch deals with this scenario anyway.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Engine removal

[Matt Caswell]

There are a number of engines within OpenSSL which, I believe, are
largely dead and unused. I would like to remove them from version 1.1.0.
Before I do so, I'd like to hear from anyone that can tell me about any
active use of these engines.

Specifically the ones I am currently looking at are:

4758cca: This provides support for the IBM 4758 PCI Cryptographic
Coprocessor which was discontinued in June 2005. It was replaced by the
4764 which was itself discontinued in December 2011. In its current form
this was added in 2002. There were a few emails about it to
openssl-users in 2002/2003 but not much since. I did find an email from
2006 from someone asking about support for the 4764.

aep: Believed to be developed by AEP Systems – which now does not seem
to exist. My guess is it is a predecessor of Ultra Electronics AEP. In
its current form the engine has been there since 2002. I found a
reference from 2004 of someone actually using it, and a post to
openssl-users in 2002, but that's about it. RT ticket 895 from 2004
describes a problem with the AEP engine not working with Linux pthreads.
No solution is recorded and the code as described in the ticket is still
present in the engine today.

atalla: Atalla is (now?) an HP brand (previously believed to be Compaq).
Earliest git log entry I could find was from 2000 (files have been
renamed since). Very little activity since. RT ticket 816 from 2004 has
a bug report filed by someone using the atalla engine (on HPUX). I found
a small number of openssl-users emails dating from between 2001-2004.
Nothing recent.

cswift: This is for the Rainbow Technologies CryptoSwift HSM
Cryptographic Accelerator. Rainbow Technologies was bought by SafeNet
Inc. RT825 provided a patch for the engine in 2004, which was applied in
2005. No significant activity since then. RT275 from 2002 also provided
a patch which was applied. I found a few openssl-users posts dating from
2001-2003 about it. Not much since then. I did find a post from 2007
about someone (unsuccessfully apparently) trying to get it going.

nuron: Google has failed me. I can't find anything out about this engine
at all. No posts to openssl-users. Moved as part of the engine rewrite
in 2002. No significant activity since then.

sureware: Engine for Sureware HSM from Baltimore Technologies, circa
2000.  I found some openssl-users enquiries about this from 2004. No
significant activity since the engine rewrite in 2002.

If anyone can tell me good reasons why these engines shouldn't go, then
please let me know!

Thanks

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4073] Segfault in engine processing

[Matt Caswell via RT]

On Tue Oct 06 20:08:12 2015, beld...@gmail.com wrote:
> Hello!
>
> I get a segfault when executing the command
>
> openssl dgst -engine gost -md_gost94 -mac hmac -macop
> key:123456901234567890123456789012
>

I assume this is on master? I can't reproduce this. Are you using your new GOST
engine or the one currently in master?

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 12/10/15 16:03, Alessandro Ghedini via RT wrote:
> On Mon, Oct 12, 2015 at 01:45:20PM +, Hubert Kario via RT wrote:
>> On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote:
>>> On 09/10/15 19:02, Hubert Kario via RT wrote:
>>>> And for good measure, I also created a test script that
>>>> combines fragmentation with interleaving.
>>>
>>> Did you try my patch with it? And if so what happened?
>>
>> I'm using interleave-data-102.patch attached to this ticket.
>>
>> So, for state-machine-rewrite branch it doesn't apply, there's no 
>> ssl/s3_pkt.c file.
>>
>> For current 1.0.1 branch, the patch applies, test case results are as 
>> follows:
>>  * test-openssl-3712.py - pass
>>  * test-interleaved-application-data-in-renegotiation.py - pass
>>  * test-interleaved-application-data-and-fragmented-handshakes-in-
>> renegotiation.py - pass
>>
>> For current 1.0.2 branch, the patch applies, tests case results are as 
>> follows:
>>  * test-openssl-3712.py - pass
>>  * test-interleaved-application-data-in-renegotiation.py - pass
>>  * test-interleaved-application-data-and-fragmented-handshakes-in-
>> renegotiation.py - pass
>>
>> for current master the patch doesn't apply, just like with state-
>> machine-rewrite there's no ssl/s3_pkt.c file
>>
>> Note: the two latter test cases need the s_server run in -www mode, the 
>> first test case ignores server response so will work regardless, that 
>> may be why Alessandro testing doesn't show the issue as fixed
> 
> Ah, yep, with -www it works for me too. Note that on master the file to change
> should be ssl/record/ssl3_record.c. However, while the patch applies cleanly 
> to
> this file, all the tests fail (even with -www). It seems that the field
> in_read_app_data is never true, so the UNEXPECTED_MESSAGE alert is sent.

The value of "in_read_app_data" not being true when it is supposed to
appears to be running into a slightly different bug. It's also present
in 1.0.2 but you have to switch off version negotiation. So running
s_server like this in 1.0.2 and rerunning Hubert's test will hit it:

openssl s_server -www -tls1_2

The 1.0.2 version negotiation is hiding the issue. In master version neg
has been completely rewritten and simplified - but in doing so no longer
hides the problem. :-(

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 12/10/15 16:39, Matt Caswell via RT wrote:
> 
> 
> On 12/10/15 16:03, Alessandro Ghedini via RT wrote:
>> On Mon, Oct 12, 2015 at 01:45:20PM +, Hubert Kario via RT wrote:
>>> On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote:
>>>> On 09/10/15 19:02, Hubert Kario via RT wrote:
>>>>> And for good measure, I also created a test script that
>>>>> combines fragmentation with interleaving.
>>>>
>>>> Did you try my patch with it? And if so what happened?
>>>
>>> I'm using interleave-data-102.patch attached to this ticket.
>>>
>>> So, for state-machine-rewrite branch it doesn't apply, there's no 
>>> ssl/s3_pkt.c file.
>>>
>>> For current 1.0.1 branch, the patch applies, test case results are as 
>>> follows:
>>>  * test-openssl-3712.py - pass
>>>  * test-interleaved-application-data-in-renegotiation.py - pass
>>>  * test-interleaved-application-data-and-fragmented-handshakes-in-
>>> renegotiation.py - pass
>>>
>>> For current 1.0.2 branch, the patch applies, tests case results are as 
>>> follows:
>>>  * test-openssl-3712.py - pass
>>>  * test-interleaved-application-data-in-renegotiation.py - pass
>>>  * test-interleaved-application-data-and-fragmented-handshakes-in-
>>> renegotiation.py - pass
>>>
>>> for current master the patch doesn't apply, just like with state-
>>> machine-rewrite there's no ssl/s3_pkt.c file
>>>
>>> Note: the two latter test cases need the s_server run in -www mode, the 
>>> first test case ignores server response so will work regardless, that 
>>> may be why Alessandro testing doesn't show the issue as fixed
>>
>> Ah, yep, with -www it works for me too. Note that on master the file to 
>> change
>> should be ssl/record/ssl3_record.c. However, while the patch applies cleanly 
>> to
>> this file, all the tests fail (even with -www). It seems that the field
>> in_read_app_data is never true, so the UNEXPECTED_MESSAGE alert is sent.
> 
> The value of "in_read_app_data" not being true when it is supposed to
> appears to be running into a slightly different bug. It's also present
> in 1.0.2 but you have to switch off version negotiation. So running
> s_server like this in 1.0.2 and rerunning Hubert's test will hit it:
> 
> openssl s_server -www -tls1_2
> 
> The 1.0.2 version negotiation is hiding the issue. In master version neg
> has been completely rewritten and simplified - but in doing so no longer
> hides the problem. :-(

Having done some more digging it seems the problem only occurs if you
get the initial handshake, following by a second reneg handshake *and*
interleaved app data all within the scope of a *single* SSL_read call.
AFAICT if SSL_read returns between the first handshake and the second,
you don't get the problem.

That's starting to sound like quite an unlikely scenario and we're only
hitting it now because of the slightly artificial nature of Hubert's
test. I'm wondering whether "will not fix" is the right response to this
second bug? Thoughts? Having said that it would be nice to have a
reliable test for the interleaved-app data issue.

Matt



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4072] dgst command incompatibility between 1.0.2 and 1.1.0

[Matt Caswell via RT]

On Tue Oct 06 19:53:30 2015, beld...@gmail.com wrote:
> Hello!
>
> I've found a difference in behaviour between openssl cmdline 1.0.2 and
> 1.1.0 versions.
> The -macopt cmdline option is not recognized, openssl dgst expects -macop
> instead.
>

Fixed. Thanks.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4089] NULL ciphersuites do not work in master

[Matt Caswell via RT]

Closing ticket.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 12/10/15 19:11, Kurt Roeckx via RT wrote:
> On Mon, Oct 12, 2015 at 04:19:43PM +0000, Matt Caswell via RT wrote:
>>
>> Having done some more digging it seems the problem only occurs if you
>> get the initial handshake, following by a second reneg handshake *and*
>> interleaved app data all within the scope of a *single* SSL_read call.
>> AFAICT if SSL_read returns between the first handshake and the second,
>> you don't get the problem.
>>
>> That's starting to sound like quite an unlikely scenario and we're only
>> hitting it now because of the slightly artificial nature of Hubert's
>> test. I'm wondering whether "will not fix" is the right response to this
>> second bug? Thoughts? Having said that it would be nice to have a
>> reliable test for the interleaved-app data issue.
> 
> Are you saying this is 1 TLS record with 2 handshakes in it?
> 
> From what I understand, the authentication could change.  Doesn't
> that mean we should make sure the client reads all data with
> SSL_read() before we tell it authentication changes and that we
> might have to delay processing some messages until that is done?
>

No. I'm saying it is within the scope of one SSL_read. libssl will read
1 record at a time from the network, process it, then read the next one,
and so on. It will continue until it returns back to the user code
because it ran out of data to read (NBIO), or it has filled the buffer
supplied by the user code. So there is not reason why it couldn't do
multiple handshakes within a single SSL_read if the buffer is big enough
(or not much app data is read between handshakes) and the data is coming
in from the network fast enough to prevent an IO block (e.g. such as
when we are running Hubert's test code on a single machine).

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 12/10/15 20:40, Kurt Roeckx via RT wrote:
> On Mon, Oct 12, 2015 at 06:54:46PM +0000, Matt Caswell via RT wrote:
>>
>>
>> On 12/10/15 19:11, Kurt Roeckx via RT wrote:
>>> On Mon, Oct 12, 2015 at 04:19:43PM +, Matt Caswell via RT wrote:
>>>>
>>>> Having done some more digging it seems the problem only occurs if you
>>>> get the initial handshake, following by a second reneg handshake *and*
>>>> interleaved app data all within the scope of a *single* SSL_read call.
>>>> AFAICT if SSL_read returns between the first handshake and the second,
>>>> you don't get the problem.
>>>>
>>>> That's starting to sound like quite an unlikely scenario and we're only
>>>> hitting it now because of the slightly artificial nature of Hubert's
>>>> test. I'm wondering whether "will not fix" is the right response to this
>>>> second bug? Thoughts? Having said that it would be nice to have a
>>>> reliable test for the interleaved-app data issue.
>>>
>>> Are you saying this is 1 TLS record with 2 handshakes in it?
>>>
>>> From what I understand, the authentication could change.  Doesn't
>>> that mean we should make sure the client reads all data with
>>> SSL_read() before we tell it authentication changes and that we
>>> might have to delay processing some messages until that is done?
>>>
>>
>> No. I'm saying it is within the scope of one SSL_read. libssl will read
>> 1 record at a time from the network, process it, then read the next one,
>> and so on. It will continue until it returns back to the user code
>> because it ran out of data to read (NBIO), or it has filled the buffer
>> supplied by the user code. So there is not reason why it couldn't do
>> multiple handshakes within a single SSL_read if the buffer is big enough
>> (or not much app data is read between handshakes) and the data is coming
>> in from the network fast enough to prevent an IO block (e.g. such as
>> when we are running Hubert's test code on a single machine).
> 
> Maybe I should go and re-reads the RFCs again, or I'm missing
> something, but I don't see how we could have 2 unprocessed
> handshakes in the buffers.  I expect that we need to write
> something before the 2nd can arrive.  But maybe it's something
> related to NPN or something like that?

You can't. That's not what I'm saying. They only need to be in the
buffer by the time you try to read the data. Or if you're using blocking
IO, it will just keep trying to read app data until its got some to
return, processing any handshake messages it encounters as it goes (and
processing means it may swap to writing handshake messages out).

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4059] Error processing set_serial parameter of the req command

[Matt Caswell via RT]

Fixed, thanks for the report.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4085] Bug in genpkey in master

[Matt Caswell via RT]

Fixed.

Thanks

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4086] s_server bug in master

[Matt Caswell via RT]

Fixed.

Thanks

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4084] correction to the message i sent earlier...

[Matt Caswell via RT]

Closing ticket.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 09/10/15 19:02, Hubert Kario via RT wrote:
> And for good measure, I also created a test script that
> combines fragmentation with interleaving.

Did you try my patch with it? And if so what happened?

Thanks

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 08/10/15 11:26, Dmitry Belyavsky wrote:
> Dear Matt, 
> 
> I have some questions.
> 
> On Thu, Oct 8, 2015 at 12:32 AM, Matt Caswell <m...@openssl.org
> <mailto:m...@openssl.org>> wrote:
> 
> 
> 
> On 07/10/15 21:44, Dmitry Belyavsky wrote:
> > Dear Matt,
> >
> > On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell <m...@openssl.org 
> <mailto:m...@openssl.org>
> > <mailto:m...@openssl.org <mailto:m...@openssl.org>>> wrote:
> >
> >
> >
> > On 07/10/15 14:29, Viktor Dukhovni wrote:
> > >
> > > Should applications generally enable async mode because that might
> > > be beneficial down the road?  Or is this just for exotic hardware
> > > not likely to be seen in most environments?
> >
> > It will only be helpful if you have an engine capable of supporting
> > async. I can't really answer the question because I don't know how
> > common this will be. My hope is that this will become relatively 
> common.
> > I have been toying with the idea of creating a multi-threaded async
> > engine where the engine manages a pool of threads to offload async 
> work
> > to which would then offer true async support even if you don't have
> > specialist hardware.
> >
> >
> > If we have an engine executing long crypto operations, how can we adopt
> > the engine and software using this engine to process them 
> asynchronously?
> 
> The engine needs to have a way of offloading the work to "something
> else" so that it can come back and pick up the results later. Typically
> for an engine this would mean some external hardware, but as I suggested
> above it could be done using threads.
> 
> From an engine perspective the work would be:
> - Receive a request to do some crypto work in the normal way via the
> engine API.
> - Offload the work to "something else"
> 
> 
> So what is a mechanism of such an offload? Can I, for example, get the
> (global) ASYNC_pool and add a job (function/pointer to context) to it?

The offload mechanism is entirely engine specific. We do not know how
any specific engine works or how to interface to the hardware. An engine
will be called in exactly the same way as now. The job of the engine
will be to take the parameters passed to it and initiate the work in the
engine hardware.

So in pseudo code it might look something like this:

static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx,
unsigned char *out, const unsigned char *in, size_t inl)
{
int jobid;

jobid = offload_cipher_to_hardware(ctx, out, in , inl);

/*
 * jobid holds a reference in the engine back to the work we just
 * started
 */

while(work_not_finished_yet(jobid)) {
/* Return control back to the calling application */
ASYNC_pause_job();
}

return get_results_from_hardware(jobid);
}

You will note that ASYNC_pause_job() does *not* do a "return" to return
control back to the user application...but calling ASYNC_pause_job()
will cause SSL_read (or whatever) to return with SSL_ERROR_WANT_ASYNC
nonetheless. The async job has its own private stack to enable this.
Recalling SSL_read from the user application will appear to the engine
like the function call ASYNC_pause_job() has returned.


> How will the SSL struct obtain a job id from the engine implementing,
> for example, "long" RSA_METHOD?

It does not need to. The SSL object has a reference to the ASYNC_JOB.
The engine can manage its own job ids - see the pseudo code above.

>  
> 
> 
> If using libcrypto then:
> - the application must determine which crypto operations it wants to
> perform asynchronously. Those operations should be wrapped in an
> application defined function.
> - the application initiates the async job by calling ASYNC_start_job and
> passing in a pointer to the function to be started as a job.
> - from an engine perspective it will work in exactly the same way as for
> libssl initiated crypto work.
> - ASYNC_start_job may return with an ASYNC_PAUSE response. The
> application can go off and do other work, and then resume the job at a
> later time by recalling ASYNC_start_job.
> 
> 
> So do I understand correctly that if I want to perform SSL operations
> asynchronously, 
> I'm able to wrap the SSL functions into the application defined
> functions and then behave as described
> herein before? 

If you are doing SSL operations you do not need to wrap them in a
function as described above (although you could do if you wanted to).
libssl will do all of this for you. You only have to define your own
function for the job if you are calling libcrypto directly. For an
application doing SSL it will work very much like non-blocking IO works
today.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 08/10/15 12:18, Dmitry Belyavsky wrote:
> 
> I see. So am I correct supposing that pseudo code for
> offload_cipher_to_hardware looks like this:
> 
> static int async_wrapper(void * args)
> {
> ...
> }
> 
> static ASYNC_JOB *offload (void *args)
> {
>   ASYNC_JOB *pjob = NULL;
>   int funcret;
>   size_t size = 0;
> 
>   int ret = ASYNC_start_job(, , async_wrapper, args, 
>   *args, size);
>   if (ret != ASYNC_PAUSE) return NULL;
>   return pjob;
> }
> 
> ?

No. I think you are confusing two different things.

1) How does an *application* perform asynchronous work (via libssl or
libcrypto) using an asynchronous capable engine?

2) How does an asynchronous capable engine offload async work to its
hardware?

These patches solve the first problem only. It provides an API and
mechanism for control to pass between the application and engine and
back again (perhaps multiple times) during the invocation of a long
running crypto operation. It also provides some mechanisms to enable an
engine to signal the completion of work to the application.

The second problem is entirely engine dependant. It will be a different
solution for different hardware. These patches do not provide a solution
to that problem.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Elliptical Cipher Suites

[Matt Caswell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 08/10/15 12:27, Aaron Jones wrote:
> On 07/10/15 13:54, Thirumal, Karthikeyan wrote:
>> Vik Am using 0.9.8a version. Am trying to fix few weak ciphers
>> in my SSL connection and also to make Elliptical cipher suites 
>> enable. I see that ECDHE ciphers are elliptical - need more info
>> on this.
> 
>> Thanks & Regards
> 
> 0.9.8 will be end-of-life in a matter of days, and does not
> support elliptic curve cryptography; that was introduced in version
> 1.0.0, also end of life soon if I recall correctly.
> 
> Version 1.0.1 is supported, and supports both ECC and TLSv1.2. I
> would recommend upgrading to atleast that.

Version 1.0.1 is EOL at end of 2016. An upgrade to 1.0.2 should be
considered.

Matt
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWFlslAAoJENnE0m0OYESRIJYIAK+jHwV2NuaLxU3FiVbYVswh
sBAczFvNTJggfZAQpaVK94S1rYK2XBeTlYz0bGv/zT74sARLtos2HxqqxLD10TgO
7yAw7OvtV5CxTu09Lf6UuYDTvATflKSREQOJQYXoMM/aK4pSQBvlChfkc7op9v+o
0RNHx4xK0A313B7tZ+fBPZnqwjruC/t1oDAVlVJ90W3y/Z0+w2cFZXbFXvUvkkPr
4HhTFXS8G1Yy+UjQ+tVbyKnHgAuR+xj6EuaLhS7xMAXJfVh34g0soB9zM36ygbHH
/Pa33tFp66QlGyTlFosFrymcq9U3PXeSIzs7HCuJZSoaHv6RGe1LJDA3qeUccb4=
=Glns
-END PGP SIGNATURE-
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4076] PROBLEM： there exists a wrong return value of function int_rsa_verify()

[Matt Caswell via RT]

On Thu Oct 08 08:55:45 2015, rucsoft...@163.com wrote:
> Bug Description:
> Function int_rsa_verify() defined in file crypto/rsa/rsa_sign.c would
> return 1 if a signature is valid, and 0 otherwise. The variable 'ret'
> keeps the return value, and it may be assigned to 1 if the condition
> in line 216 is satisfied. The signature is regarded as invalid if the
> conditions in line 241 are evaluated to be true, and the error message
> is dumped (in line 242) and the verify process is ended (in line 243).
> However, as variable 'ret' may keep value 1, this function will return
> 1 (in line 290) even if the signature is invalid, which will confuse
> the caller function whether the signature is really valid.

Thanks for your report. I think your analysis is partially correct. If the
condition on line 216 evaluates to true then this means that the signature data
is just a bare OCTETSTRING. Really there should be an "else" on line 225 to
prevent the other branches from occurring. As it is the code will fall through
to the "else" on line 233 and it will then attempt to parse the signature data
as DigestInfo (X509_SIG). This will clearly fail because we already know that
it is a bare OCTETSTRING. Therefore |sig| will be NULL and we will goto the
|err| label - which is exactly where we would have ended up anyway had there
been an else on line 225 as I suggest.

So there is no real impact to this. You will never get to the signature
validity test on line 241 as you suggest if line 216 evaluates to true (and
that test would not apply anyway in this case). Functionally then it is working
correctly (kind of). However I have applied a patch anyway to prevent the
erroneous attempt to parse sig, and to make things look a bit more sane:

https://github.com/openssl/openssl/commit/dffe51091f412dcbc18f6641132f0b4f0def6bce

Closing this ticket.

Matt


> The related code snippets in int_rsa_verify() is as following.
> 168 int int_rsa_verify(int dtype, const unsigned char *m,
> 169 unsigned int m_len,
> 170 unsigned char *rm, size_t *prm_len,
> 171 const unsigned char *sigbuf, size_t siglen, RSA
> *rsa)
> 172 {
> 173 int i, ret = 0, sigtype;
> ...
> 216 if (dtype == NID_mdc2 && i == 18 && s[0] == 0x04 && s[1] ==
> 0x10) {
> 217 if (rm) {
> 218 memcpy(rm, s + 2, 16);
> 219 *prm_len = 16;
> 220 ret = 1;
> 221 } else if (memcmp(m, s + 2, 16))
> 222 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE);
> 223 else
> 224 ret = 1;
> 225 }
> 226
> 227 /* Special case: SSL signature */
> 228 if (dtype == NID_md5_sha1) {
> 229 if ((i != SSL_SIG_LENGTH) || memcmp(s, m, SSL_SIG_LENGTH))
> 230 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE);
> 231 else
> 232 ret = 1;
> 233 } else { // dtype != NID_md5_sha1
> 234 const unsigned char *p = s;
> 235 sig = d2i_X509_SIG(NULL, , (long)i);
> 236
> 237 if (sig == NULL)
> 238 goto err;
> 239
> 240 /* Excess data can be used to create forgeries */
> 241 if (p != s + i || !rsa_check_digestinfo(sig, s, i)) {
> 242 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE);
> 243 goto err;
> 244 }
> ...
> 283 err:
> 284 if (sig != NULL)
> 285 X509_SIG_free(sig);
> 286 if (s != NULL) {
> 287 OPENSSL_cleanse(s, (unsigned int)siglen);
> 288 OPENSSL_free(s);
> 289 }
> 290 return (ret);
> 291 }
>
>
>
>
>

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3982] [PATCH] Fix unhandled error condition in sslv2 client hello parsing

[Matt Caswell via RT]

Patch was applied. Closing.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 08/10/15 18:56, Dmitry Belyavsky wrote:

> The second problem is entirely engine dependant. It will be a different
> solution for different hardware. These patches do not provide a solution
> to that problem.
> 
> 
> So I do not understand what you mean by "offload" :-(
> 
> I understand that it's an engine-dependent, but I can't imagine a
> corresponding pseudo code.

Ok. So this is the pseudo code I posted before for how an engine might
be implemented:

static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx,
unsigned char *out, const unsigned char *in, size_t inl)
{
int jobid;

jobid = offload_cipher_to_hardware(ctx, out, in , inl);

/*
 * jobid holds a reference in the engine back to the work we just
 * started
 */

while(work_not_finished_yet(jobid)) {
/* Return control back to the calling application */
ASYNC_pause_job();
}

return get_results_from_hardware(jobid);
}


So lets imagine an engine that works via threads and how those pseudo
code function call might be implemented. It could be something like this:

void initialise_engine(void)
{
start_thread(worker_main);
}

static int nextjobid = 0;

struct work_st {
int jobid;
EVP_CIPHER_CTX *ctx;
unsigned char *out;
unsigned char *in;
size_t inl;
int ret;
}

int worker_main(void)
{
struct work_st *work;

while(true) {
work = get_work_off_in_queue();
/* This is a long running operation */
work->ret = do_aes128_cbc_cipher(work->ctx, work->out, work->in,
work->inl);
put_work_in_finished_set(work);
}
}

int offload_cipher_to_hardware(EVP_CIPHER_CTX *ctx, unsigned char *out,
unsigned char *in, size_t inl) {
struct work_st *work;

work = malloc(sizeof *work);
work->ctx = ctx;
work->out = out;
work->in = in;
work->inl = inl;
work->jobid = nextjobid++;

add_work_to_in_queue(work);

return work->jobid;
}

int work_not_finished_yet(int jobid)
{
return !is_work_in_finished_set(jobid);
}

int get_results_from_hardware(int jobid)
{
struct work_st *work;

work = get_work_out_of_finished_set(jobid);

return work->ret;
}

In a hardware based engine everything in "worker_main" would be
implemented in the hardware. So the hardware gets on with the long
running crypto operation, whilst in the software control has returned
back to the application.

Does that make more sense?

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 07/10/15 21:44, Dmitry Belyavsky wrote:
> Dear Matt, 
> 
> On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell <m...@openssl.org
> <mailto:m...@openssl.org>> wrote:
> 
> 
> 
> On 07/10/15 14:29, Viktor Dukhovni wrote:
> >
> > Should applications generally enable async mode because that might
> > be beneficial down the road?  Or is this just for exotic hardware
> > not likely to be seen in most environments?
> 
> It will only be helpful if you have an engine capable of supporting
> async. I can't really answer the question because I don't know how
> common this will be. My hope is that this will become relatively common.
> I have been toying with the idea of creating a multi-threaded async
> engine where the engine manages a pool of threads to offload async work
> to which would then offer true async support even if you don't have
> specialist hardware.
> 
> 
> If we have an engine executing long crypto operations, how can we adopt
> the engine and software using this engine to process them asynchronously? 

The engine needs to have a way of offloading the work to "something
else" so that it can come back and pick up the results later. Typically
for an engine this would mean some external hardware, but as I suggested
above it could be done using threads.

>From an engine perspective the work would be:
- Receive a request to do some crypto work in the normal way via the
engine API.
- Offload the work to "something else"
- Call the new API function ASYNC_pause_job(). This will return control
back to the calling application.
- At sometime later, preferably when the application knows the work has
completed (* see below), the application will resume the async job. From
an engine perspective this just appears as the ASYNC_pause_job()
function call returning - so it just continues where it left off
- The engine should verify that the work offloaded to "something else"
has completed.
- If not it just calls ASYNC_pause_job() again as before.
- If it has completed then it collects the results and returns them back
in the normal way for an engine

>From an application perspective it depends whether it is using libcrypto
directly, or whether it is using libssl.

If libssl then:
- the application essentially operates as normal
- additionally it must call either SSL_CTX_set_mode() or SSL_set_mode to
set the SSL_ASYNC_MODE
- In any call to SSL_read/SSL_write/SSL_accept/SSL_connect etc, it must
be prepared to handle an SSL_ERROR_WANT_ASYNC response. This works in
essentially the same way as SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE,
i.e sometime later (* see below) it recalls
SSL_read/SSL_write/SSL_accept/SSL_connect and the async job is resumed.

If using libcrypto then:
- the application must determine which crypto operations it wants to
perform asynchronously. Those operations should be wrapped in an
application defined function.
- the application initiates the async job by calling ASYNC_start_job and
passing in a pointer to the function to be started as a job.
- from an engine perspective it will work in exactly the same way as for
libssl initiated crypto work.
- ASYNC_start_job may return with an ASYNC_PAUSE response. The
application can go off and do other work, and then resume the job at a
later time by recalling ASYNC_start_job.


So the next question is how does the application know when it is ok to
resume a job? There are two basic models:

- Event based...essentially the engine signals to the application that
the results are ready for collection
- Polling...in this model the application will have to periodically
restart the job to see if it is ready to be continued or not

There are API calls available for the event based model. See
ASYNC_wake(), ASYNC_clear_wake(), ASYNC_get_wait_fd(), and
SSL_get_async_wait_fd() in the documentation links I sent out previously.

There is some example code in the ASYNC_start_job() documentation. You
can also look at the source code for the dummy async engine.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Adding async support

[Matt Caswell]

Hi all

A number of people have expressed interest in the async work that I have
been doing in collaboration with Intel. This has now progressed to the
point where it is going through team review. I thought some of you might
like to get early sight of this so I have pushed it to my personal
github repo (see the "main-async" branch):

https://github.com/mattcaswell/openssl

Obviously there may be some tweaks that occur during the review process
but hopefully it is stable enough to give you an idea of how it will work.

I have also opened a github pull request so you can post comments on the
code there if you wish:

https://github.com/openssl/openssl/pull/433

The idea is that async aware application code will be able to use
OpenSSL to initiate crypto operations asynchronously. In order to work
this will require the presence of an async capable engine. For example
you could imagine an engine that could initiate work on some external
hardware and enable application code to come back at some later time for
the results.

This has been implemented through the concept of an ASYNC_JOB. At the
libcrypto level an application developer would write a function that
they wish to execute asynchronously which might call a number of
different crypto operations. They can then initiate that job using a new
API call "ASYNC_start_job()". The function will then execute until the
engine (or indeed anything - it doesn't have to be in an engine; it
could be user code) calls "ASYNC_pause_job()". At this point control
returns back to the application code. The job can be resumed later
through a second call to "ASYNC_start_job()" - it will pick up where it
left off. The main restriction here is that this must be done from the
same thread as the original ASYNC_start_job() call. A flagging mechanism
has been implemented to enable application code to know whether the
async job is "ready" to be resumed.

libssl has been made async aware through the introduction of a new mode
"SSL_MODE_ASYNC". The mode is set using a call to one of the existing
functions SSL_CTX_set_mode() or SSL_set_mode(). Having set that mode
calls to functions such as SSL_read/SSL_write etc, may now start
returning an SSL_ERROR_WANT_ASYNC response (if an async capable engine
is present). To resume you simply recall SSL_read/SSL_write in the same
way as you would if you got an SSL_ERROR_WANT_READ or
SSL_ERROR_WANT_WRITE. Similarly to above you must do this from the same
thread as the original call.

In order to enable people to test this out I have provided a "Dummy
Async" engine (dasync). This can't really do async work, but it pretends
it can :-). For certain crypto operations (currently only SHA1 and RSA)
it will call ASYNC_pause_job() at various points. Once you resume the
job it will just continue synchronously.

I have also added async support to s_server and s_client through the new
"-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an
effect you will obviously also need an async engine (such as dasync)
loaded through the "-engine" flag. Note that dasync will only be loaded
dynamically and thus OpenSSL must be built "shared" for this to work.

Documentation including some example code is available on all of this here:
https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod
https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod
https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod
https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod

I'd be interested to hear your thoughts.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 07/10/15 14:29, Viktor Dukhovni wrote:
> On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote:
> 
>> I have also added async support to s_server and s_client through the new
>> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an
>> effect you will obviously also need an async engine (such as dasync)
>> loaded through the "-engine" flag. Note that dasync will only be loaded
>> dynamically and thus OpenSSL must be built "shared" for this to work.
>>
>> Documentation including some example code is available on all of this here:
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod
>> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod
>>
>> I'd be interested to hear your thoughts.
> 
> Will existing applications doing non-blocking I/O with OpenSSL need
> to be modified to handle SSL_ERROR_WANT_ASYNC?  Or does that happen
> only if they explicitly request "async mode"?

No, they should not need to be modified. You will only get
SSL_ERROR_WANT_ASYNC if you have enabled SSL_MODE_ASYNC.

> 
> Should applications generally enable async mode because that might
> be beneficial down the road?  Or is this just for exotic hardware
> not likely to be seen in most environments?

It will only be helpful if you have an engine capable of supporting
async. I can't really answer the question because I don't know how
common this will be. My hope is that this will become relatively common.
I have been toying with the idea of creating a multi-threaded async
engine where the engine manages a pool of threads to offload async work
to which would then offer true async support even if you don't have
specialist hardware.

> For example, should Postfix enable "async" support?  It does timed
> non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}.

If applications already handle SSL_ERROR_WANT_READ/WRITE then IMO it is
not much extra effort to additionally handle SSL_ERROR_WANT_ASYNC so I
would encourage making the changes. You may want to consider making it a
configurable option. There is a small overhead with creating ASYNC_JOBs
and context switching into them when they start and finish.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Adding async support

[Matt Caswell]

On 07/10/15 16:57, Devchandra L Meetei wrote:
> 
> 
> On Wed, Oct 7, 2015 at 3:16 PM, Matt Caswell <m...@openssl.org
> <mailto:m...@openssl.org>>
> wrote:<https://github.com/openssl/openssl/pull/433>
> 
> 
> 
> libssl has been made async aware through the introduction of a new mode
> "SSL_MODE_ASYNC". The mode is set using a call to one of the existing
> functions SSL_CTX_set_mode() or SSL_set_mode(). Having set that mode
> calls to functions such as SSL_read/SSL_write etc, may now start
> returning an SSL_ERROR_WANT_ASYNC response (if an async capable engine
> is present). To resume you simply recall SSL_read/SSL_write in the same
> way as you would if you got an SSL_ERROR_WANT_READ or
> SSL_ERROR_WANT_WRITE. Similarly to above you must do this from the same
> thread as the original call.
> 
>  
> Does this also mean that there will not be any libssl API change?

There are no changes to the fundamental way the libssl API works. This
is about integrating a new source of async events i.e. the capability to
asynchronously process crypto operations by pushing the work off into
some async capable engine. It's not about changing the way async events
are presented to applications in libssl.

> 
> I have been developing async calls of TLS I/O using bio pair, for instance
> for SSL_read, it is something like
> 
>> int evt_tls_read( evt_tls_t *tls, void (*cb)(evt_tls_t* t, char *buf,
> int sz))
> 
> The cb will be called asynchronously whenever there is application data.
> 
> Will there be any such change? Such API's will make integrating OpenSSL
> with other
> async lib like libevent, libev and libuv etc.

There are no such changes planned.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4069] Malformed Client Hello messages are accepted (custom message padding and length)

[Matt Caswell via RT]

Fixed in master, 1.0.2 and 1.0.1. Closing ticket.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function

[Matt Caswell via RT]

On 01/10/15 15:18, Tiantian Liu via RT wrote:
> Hi,
> 
> Good morning! Thanks for your response.
> 
> I configured my OpenSSL with '-d' option to enable the debugging information. 
> Where I don't know how to use it during my application running.

Which version of OpenSSL did you download? My version 1.0.1p doesn't
match up with the line numbers in your backtrace below, i.e. line 209 in
s3_clnt.c is not 'SSL_clear(s);' as it appears to be for you.

> Loaded symbols for /usr/lib/libkrb5.so.3
> Loaded symbols for /usr/lib/libk5crypto.so.3
> Loaded symbols for /usr/lib/libptcoresdk.so.2
> Loaded symbols for /lib/libcom_err.so.2
> Loaded symbols for /usr/lib/libstdc++.so.6
> Loaded symbols for /usr/lib/libssl.so.1.0.0
> Loaded symbols for /usr/lib/libcrypto.so.1.0.0

Where did you install the version of OpenSSL that you compiled? Did you
replace the system supplied version in `/usr/lib`? If so that was
probably not a good idea.



> Loaded symbols for /lib/libdl.so.2
> Loaded symbols for /lib/i686/nosegneg/libpthread.so.0
> Loaded symbols for /lib/i686/nosegneg/libc.so.6
> Loaded symbols for /usr/lib/libkrb5support.so.0
> Loaded symbols for /lib/libresolv.so.2
> Loaded symbols for /lib/libgcc_s.so.1
> Loaded symbols for /lib/i686/nosegneg/libm.so.6
> Loaded symbols for /lib/ld-linux.so.2
> 0x009e6402 in __kernel_vsyscall ()
> (gdb) c
> Continuing.
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1231422576 (LWP 3480)]
> 0x00dd87e8 in SSL_clear (s=0xb4a03ec8) at ssl_lib.c:219
> 219 if (s->renegotiate) {

There is something not quite right about that. There is no way that line
should seg fault. The deref of `s` has already occurred several times by
the time it gets to that line so `s` should be sound. Either there is
some memory corruption going on, or that's not really the line we're on.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build

[Matt Caswell]

On 30/09/15 10:22, Alessandro Ghedini via RT wrote:
> On Wed, Sep 30, 2015 at 02:01:54am +, Rich Salz via RT wrote:
>> We fixed this in a slightly different way. We made BIO_new_file and 
>> BIO_s_file
>> return an alternate implementation that returns run-time failures. Almost all
>> of the OpenSSL code uses the BIO object, so we didn't have to remove that. We
>> did #ifdef out any routine that had a "FILE*" param or local variable.
> 
> Note that commit 984d6c6 causes mingw shared builds to fail again:
> https://travis-ci.org/openssl/openssl/jobs/82855661
> 
> The problem seems to be that entries 4991 and 4992 in libeay.num are used 
> twice.
> 

Fixed:

https://github.com/openssl/openssl/commit/dd35486db671dca36caffecc7ee1f5f6483b3a4b

> Since this is not the first time this happens, I was thinking that maybe 
> having
> a test for this would be useful.

Good idea:
https://github.com/openssl/openssl/commit/5530d5187c77877b610b11c4aadedd7107386afa

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4066] bug: openssl clean up crash

[Matt Caswell]

On 30/09/15 16:06, Haiyang Yin via RT wrote:
> Hello, I am using memory-based bio to handle dtls sessions. Crash
> happened after close notify received and SSL was cleaned up ? OpenSSL
> version is 1.0.2d. If more detailed information required, pls. let me
> known.

Your gdb output is impossible to read. At least it is for me - all line
breaks seem to have been removed. Can you post a more readable version?

How are you setting up your memory bios? The OpenSSL memory BIOs don't
really work too well with DTLS because they do not preserve packet
boundaries. Can you post some code?

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4066] bug: openssl clean up crash

[Matt Caswell via RT]

On 30/09/15 16:06, Haiyang Yin via RT wrote:
> Hello, I am using memory-based bio to handle dtls sessions. Crash
> happened after close notify received and SSL was cleaned up ? OpenSSL
> version is 1.0.2d. If more detailed information required, pls. let me
> known.

Your gdb output is impossible to read. At least it is for me - all line
breaks seem to have been removed. Can you post a more readable version?

How are you setting up your memory bios? The OpenSSL memory BIOs don't
really work too well with DTLS because they do not preserve packet
boundaries. Can you post some code?

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function

[Matt Caswell via RT]

I agree with everything Viktor said. In particular that you should
continue to use SSLv23_method. Some additional comments below:

On 28/09/15 16:31, Tiantian Liu via RT wrote:

>   sslerror = SSL_get_error(ssl, res);
>   if (sslerror == SSL_ERROR_WANT_READ) {
>   isexp = is_expired(exptime);
>   if (isexp == 1) {
>   strcpy(error, "SSL connect error");
>   return 0;
>   }
>   continue;
>   }
>   strcpy(error, "SSL connect error");
>   return 0;

You need to handle more that just SSL_ERROR_WANT_READ here. You should
also handle SSL_ERROR_WANT_WRITE. You could get either returned from a
call to SSL_connect.

Please can you supply a backtrace from your crash? Also a packet capture
between your application and the server would be useful.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function

[Matt Caswell via RT]

On 29/09/15 14:56, Tiantian Liu via RT wrote:
> Hi Matt & Vi
> 
> I tried the SSLv23_method(), and precluded/excluded all SSLv2, SSLv3, TLSv1. 
> I only enabled the TLSv1.2 by SSL_CTX_set_option().
> You can see my previous code:  
> 
> /*setup up by SSLv23_method*/
> meth = SSLv23_method();
> ctx = SSL_CTX_new(meth);
> 
> 
> /*Only allow TLSv1.2 protocol*/
> SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | 
> SSL_OP_NO_TLSv1);
> 
> 
> While the above code didn't work. I couldn't reach the server. Though the 
> SSL_connect() didn't crash, it returned as:
> 
> 17:49:12.939 [5499]- SSL_connect res : -1

What is the result of SSL_get_error()? Also check the OpenSSL error
queue (see ERR_print_errors or ERR_print_errors_fp).

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function

[Matt Caswell via RT]

On 29/09/15 15:45, Tiantian Liu via RT wrote:
> Hi Matt,
> Thanks for prompt response!
> While I confirm with you that my application crashed INSIDE the SSL_connect() 
> function.

Your previous email indicated it was not crashing with SSLv23_method():
"While the above code didn't work. I couldn't reach the server. Though
the SSL_connect() didn't crash, it returned as..."

So my advice was meant for that scenario.

> So SSL_connect has no chance to return the 'res' value to me for analysis. 
> Because I inserted a debug message before and after SSL_connect(). You can 
> see it in the following code.  
> 
>/*
> My debug statement wrote the " Going to call SSL_connect() 15" 
> into my trace file
> And this message string is THE LAST message in my trace file.
>   */  
> if (isDiag) {
>   SerialWriteTestLine_int_Time("Going to call SSL_connect()", 
> timeout, diag);
> }
>   res = SSL_connect(ssl);
>   /*
>Oooop!!! The following statement was not executed! No debug 
> message in my trace file anymore.
>   */
> if (isDiag) {
>   SerialWriteTestLine_int_Time("SSL_connect res ", res, diag);
> }
>   if (res <= 0) {
>   sslerror = SSL_get_error(ssl, res);
>   if (sslerror == SSL_ERROR_WANT_READ) {
>   isexp = is_expired(exptime);
>   if (isexp == 1) {
>   if (isDiag) {
>   
> SerialWriteTestLine_int_Time("ConnectSSL [SSL_connect(ssl)] failed Timeout", 
> timeout, diag);
>   }
>   strcpy(error, "SSL connect error");
>   return 0;
>   }
>   continue;
>   }
> 
> So, do you have any idea to get more information inside the SSL_connect?

If its actually crashing then we need to see a backtrace and a wireshark
packet capture.

> Should I re-compile and re-install OpenSSL lib?
> I tried to configure OpenSSL with option '-d' to enable the debug feature, 
> while I got compilation error.
> 

You should not get a compilation error. Please post the steps you took
to compile the library and the compilation error you received.


Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

On 28/09/15 12:35, Albe Laurenz via RT wrote:
> Matt Caswell wrote:
>> I've been looking into this issue. The reason this fails is because at
>> some point in the past there has been an explicit design decision to
>> disallow it.
> 
> Thank you for your work!
> I agree with your analysis.
> 
>> However, I have some concerns with the wording of the RFC. It seems to
>> place no limits whatsoever on when it is valid to receive app data in
>> the handshake. By the wording in the RFC it would be valid for app data
>> to be received *after* the ChangeCipherSpec has been received but
>> *before* the Finished has been processed. This seems dangerous to me
>> because it is not until the Finished is processed that we verify the
>> handshake data MAC - and yet we could already have acted upon app data
>> received. I assume the intent was to allow the interleaved app data only
>> up until the point that the CCS is received. I have attached a patch for
>> 1.0.2 that implements that logic.
> 
> The RFC writes:
> 
>Note: If a rehandshake occurs while data is flowing on a connection,
>the communicating parties may continue to send data using the old
>CipherSpec.  However, once the ChangeCipherSpec has been sent, the
>new CipherSpec MUST be used.  The first side to send the
>ChangeCipherSpec does not know that the other side has finished
>computing the new keying material (e.g., if it has to perform a
>time-consuming public key operation).  Thus, a small window of time,
>during which the recipient must buffer the data, MAY exist.  In
>practice, with modern machines this interval is likely to be fairly
>short.
> 
> Could that be interpreted to mean that the recepient should buffer
> all incoming Application Data messages that are sent between
> ChangeCipherSpec and Finished?

Thanks. I had missed that wording. I think this means that as soon as
the first party sends a CCS, they must not send any app data until they
have received a CCS back (they must buffer it until the CCS is seen). So
the second party should never expect to see app data between CCS and
Finished. It doesn't tell you anything about what the first party can
expect though, i.e. is the second party allowed to send app data between
the CCS and Finished?

> 
> However that may be, I tested your patch with PostgreSQL 9.4.4 and 
> OpenJDK 1.7.0_85 and it solves my problem, so it seems like Java does not
> try to send Application Data between ChangeCipherSpec and Finished.
> 
> If that patch gets applied, I expect it will make it into all active
> branches, right?

Well, that depends what you mean be active. 1.0.0 and 0.9.8 are only
receiving security fixes at the moment so this patch would not be
applied to those branches. It should be applied to master, 1.0.2 and
1.0.1. The patch is currently awaiting internal review.

> 
> If this bug gets closed, #2481 should probably get closed too.

I just closed it with a message pointing at this ticket. No point in
having both open.

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2481] Full-duplex SSL/TLS renegotiation failure (reproducible 100% of the time)

[Matt Caswell via RT]

This as a duplicate of 3712. Closing this ticket in favour of that one. See the
patch associated with that ticket.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4061] [PATCH] Request for new API to get role of SSL

[Matt Caswell via RT]

On 26/09/15 17:18, Devchandra L Meetei via RT wrote:
> Sure, Sorry for the noise.
> and Thanks Steve.
> 
> is the API introduced recently openssl 1.0.1f does not seem to have it?
> 
> if so, any plan to backport it?


This was introduced in 1.0.2. There are no plans to backport it.

Regards

Matt



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4064] Re: Client Hello longer than 2^14 bytes are rejected

[Matt Caswell via RT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 25/09/15 14:19, Hubert Kario wrote:
> Current OpenSSL-1.0.1, 1.0.2 as well as state-machine-rewrite
> branches reject Client Hello messages bigger than 2^14+4 bytes.


Right. The reason for that is that there is an explicit (deliberate)
check for it. Each message in its call to ssl_get_message specifies
the max size. For ClientHello:

n = s->method->ssl_get_message(s,
   SSL3_ST_SR_CLNT_HELLO_B,
   SSL3_ST_SR_CLNT_HELLO_C,
   SSL3_MT_CLIENT_HELLO,
   SSL3_RT_MAX_PLAIN_LENGTH, );

The max size here is the fifth param, i.e. SSL3_RT_MAX_PLAIN_LENGTH
(=16384, or the max possible size that can fit into a single record).
Every message has one of these defined. Some of them are quite
arbitrary values.

E.g. for ServerHello
n = s->method->ssl_get_message(s,
   SSL3_ST_CR_SRVR_HELLO_A,
   SSL3_ST_CR_SRVR_HELLO_B, -1, 2,
);

Why 2? No idea.

The same restriction exists in the state-machine-rewrite branches
because I'm ultra-cautious. I am reluctant to remove an explicit check
like that without understanding why it's there in the first place.
Especially if its not breaking anything. Are we ever likely to
encounter a ClientHello > 16384 bytes?

Matt
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWBWlUAAoJENnE0m0OYESR0GUIAKPpYctFSqG7RVtPI8mKdw75
Ml+18+fOh4QE6RoKVLoBB3FglAZujZ8RMXlOZ6bivF8KrLygoAT6ECF/a0ee3kpk
UAlYOY9HEHistlY+BeAs0jx2VsAKb10mO+Z+C6jV+Uql2GSTFqzrdGSdS6pxOuL1
EJr4WFh32sj+ApvTpDw6XVuvNypVpoEY5KeDj+4ZPKnQdp/TcoErLEzIgzIsGm7b
FNXkpgTy8Xamr+S6afQYgNi6MOlHIIRlOXkDqkOyRpjHfqLU748EympIUkWNq8EZ
dw8Sxk6PRTe9BqgtjX10benF3K7N9yuli2sLHoHFZvwTVqWvNqMgA2jyJIoCgM8=
=bEaO
-END PGP SIGNATURE-

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4064] Re: Client Hello longer than 2^14 bytes are rejected

[Matt Caswell via RT]

Gahhhdidn't mean to open this as a new ticket.

Closing.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected

[Matt Caswell]

On 25/09/15 17:05, Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 03:02:27pm +, Hubert Kario via RT wrote:
>> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote:
>>> As a matter of test I changed the ssl_get_message() in
>>> ssl3_get_client_hello() to use 0xFF (uint24 max) as maximum size,
>>
>> it doesn't have in theory, but it does in practice, as extensions can 
>> only be 2^16 long, same for cipher suites, and you can't have data 
>> trailing the messages, so the actual size is limited to something closer 
>> 2^18, so if the client hello parser is correct, it will be limited by it
> 
> Yeah, but OpenSSL first tries to "get" the handshake body and its length 
> before
> parsing it (this is done by ssl3_get_message()). So the "max" argument is
> intended to be used, I imagine, as a sanity check: if the message exceeds 
> that,
> then it's obviously broken and an "illegal parameters" alert is sent. This is
> done regardless of the message type, so the ClientHello parser has to do this
> as well.
> 
> This max length check is not exactly smart (e.g. the max size of the SSLv3
> ClientHello is very different from that of TLS) and could probably be removed
> completely, but I don't really know what the consequences of this would be. So
> the best next fix would simply be to provide an approximation of an absolute
> maximum length for the ClientHello (or just use 0xFF). I opened a pull
> request [0] with just this minimal fix. Anyone is very welcome to propose a
> better fix for this though.

0xff = 16777215 or 16Mb

Allowing a ClientHello as big as this could enable a DoS attack.

If I did my sums right I make the biggest possible valid ClientHello to
be 131396.

But should we allow something as big as this just because its
theoretically possible?

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4063] Client Hello longer than 2^14 bytes are rejected

[Matt Caswell via RT]

On 25/09/15 17:05, Alessandro Ghedini via RT wrote:
> On Fri, Sep 25, 2015 at 03:02:27pm +, Hubert Kario via RT wrote:
>> On Friday 25 September 2015 14:51:17 Alessandro Ghedini via RT wrote:
>>> As a matter of test I changed the ssl_get_message() in
>>> ssl3_get_client_hello() to use 0xFF (uint24 max) as maximum size,
>>
>> it doesn't have in theory, but it does in practice, as extensions can 
>> only be 2^16 long, same for cipher suites, and you can't have data 
>> trailing the messages, so the actual size is limited to something closer 
>> 2^18, so if the client hello parser is correct, it will be limited by it
> 
> Yeah, but OpenSSL first tries to "get" the handshake body and its length 
> before
> parsing it (this is done by ssl3_get_message()). So the "max" argument is
> intended to be used, I imagine, as a sanity check: if the message exceeds 
> that,
> then it's obviously broken and an "illegal parameters" alert is sent. This is
> done regardless of the message type, so the ClientHello parser has to do this
> as well.
> 
> This max length check is not exactly smart (e.g. the max size of the SSLv3
> ClientHello is very different from that of TLS) and could probably be removed
> completely, but I don't really know what the consequences of this would be. So
> the best next fix would simply be to provide an approximation of an absolute
> maximum length for the ClientHello (or just use 0xFF). I opened a pull
> request [0] with just this minimal fix. Anyone is very welcome to propose a
> better fix for this though.

0xff = 16777215 or 16Mb

Allowing a ClientHello as big as this could enable a DoS attack.

If I did my sums right I make the biggest possible valid ClientHello to
be 131396.

But should we allow something as big as this just because its
theoretically possible?

Matt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4065] Re: Client Hello longer than 2^14 bytes are rejected

[Matt Caswell]

On 25/09/15 20:19, Kurt Roeckx wrote:
> On Fri, Sep 25, 2015 at 04:23:27PM +, Hubert Kario via RT wrote:
>>
>> Given that TLSv1.3 has a 1RTT mode planned (so Client Key Exchange ends 
>> up as an extension, possibly multiple ones), and that quantum computing 
>> resistant algorithms usually require fairly large key sizes (large 
>> enough that protocol limitations itself are problematic), we may see 
>> Client Hellos larger than 16k in not so far future.
> 
> Since we don't actually know how things are going to change in the
> future and that they can change the maximum size of a Client
> Hello, it makes sense to me to not enforce a limit for the Client
> Hello message just because that's what the current version only
> supports.  For all other messages we should be able to tell what
> the maximum size is.

If the ClientHello message is longer than 131396 bytes then either we
are under some kind attack, or it is in some future format that we do
not understand and is not backwards compatible (a requirement of
backwards compatibility would be that it is under or equal to that
limit). Either way we should drop the message.

My concern is whether we should have a limit that is less than that. A
default s_client ClientHello on master at the moment is 364 bytes. A
default ClientHello with a ticket is 556 bytes. The biggest ClientHello
I can induce from s_client is one including a ticket and a cipher string
of "ALL:@SECLEVEL=0" which leads to 618 bytes. I recognise that we are
talking about future proofing; but the current limit of 16384 already
gives us the ability to accept ClientHello's 26 times bigger than the
biggest s_client can create today. That is significant room for future
growth.

On the other side of the coin handling very large ClientHello's is not
without cost and risk. There is bandwidth consumption, memory
consumption, CPU consumption handling any operations required from the
ClientHello (e.g. decrypting an enormous SessionTicket) etc. We also
have to bear in mind the OpenSSL doesn't necessarily just run on big
powerful servers in datacentres. It can also runs in very resource
constrained environments. We potentially open up our users to DoS
attacks by attempting to accept these "godzillagram" (as someone called
them) ClientHellos. Right now, today, if a server starts receiving
ClientHello's that big then it is almost certainly an attack. Increasing
the maximum size over what we have today increases the risk of attacks
right now.

Of course we don't know what the future will bring. I'm struggling to
foresee a scenario where we have a vast explosion in the ciphersuites
available (which is where a significant proportion of the "allowed"
ClientHello size is allocated) - but I guess it could happen. Possibly
more likely is some new extension(s) requiring very large extension data
blocks. Still, whatever that extension is, it would have to be
*massively* bigger than any extension we have today to blow the existing
limit - and absolutely HUGE to go anywhere near 131396. The latency
costs of managing such large ClientHello's would be significant so I am
really finding it hard to see a future where ClientHello's get even
close to approaching the kind of sizes we're talking about. So why would
we open up our users today to increased risks for a future that seems
quite unlikely?

So, what I'm trying to say is it's a balancing act. We shouldn't just
accept the biggest possible messages that we can just because that gives
us the best interoperability for the future. There are other
considerations.

Matt



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell]

On 25/09/15 11:25, Hubert Kario via RT wrote:
> 
>   A Finished message is always sent immediately after a change
>   cipher spec message to verify that the key exchange and
>   authentication processes were successful.

This is perhaps the key statement. It could do with being more explicit
if the intent here is to disallow interleaved app data.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell]

On 25/09/15 11:25, Hubert Kario via RT wrote:
> On Friday 25 September 2015 10:47:42 Matt Caswell wrote:
>> However, I have some concerns with the wording of the RFC. It seems to
>> place no limits whatsoever on when it is valid to receive app data in
>> the handshake. By the wording in the RFC it would be valid for app
>> data to be received *after* the ChangeCipherSpec has been received
>> but *before* the Finished has been processed. This seems dangerous to
>> me because it is not until the Finished is processed that we verify
>> the handshake data MAC - and yet we could already have acted upon app
>> data received. I assume the intent was to allow the interleaved app
>> data only up until the point that the CCS is received. I have
>> attached a patch for 1.0.2 that implements that logic.
> 
> yes, I think the only place in which the handshake protocol and 
> application data _can't_ be interleaved is between the CCS and Finished.

It would be nice to have a test for that wouldn't it ;-)

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell]

ore* the Finished has been processed. This seems dangerous to me
because it is not until the Finished is processed that we verify the
handshake data MAC - and yet we could already have acted upon app data
received. I assume the intent was to allow the interleaved app data only
up until the point that the CCS is received. I have attached a patch for
1.0.2 that implements that logic.

Matt

From 0260f9d34d81f5080bbbd602577f201922fd4062 Mon Sep 17 00:00:00 2001
From: Matt Caswell <m...@openssl.org>
Date: Fri, 25 Sep 2015 10:34:27 +0100
Subject: [PATCH] Allow interleaved app data in a renegotiation

Prior to TLS1.1 SSL3/TLS1.0 was ambigous about what to do with application
data received during a renegotiation handshake. The existing code (which
predates TLS1.1) disallows this. TLS1.1 clarifies the situation to
explicitly allow this. This patch enables interleaved app data up until the
point that the CCS is received. Whilst the RFC does not explicitly say so
it seems incorrect to allow it after this point.
---
 ssl/s3_pkt.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/ssl/s3_pkt.c b/ssl/s3_pkt.c
index 3798902..22a27cf 100644
--- a/ssl/s3_pkt.c
+++ b/ssl/s3_pkt.c
@@ -1608,18 +1608,14 @@ int ssl3_read_bytes(SSL *s, int type, unsigned char *buf, int len, int peek)
  * application data.  If the library was running inside ssl3_read()
  * (i.e. in_read_app_data is set) and it makes sense to read
  * application data at this point (session renegotiation not yet
- * started), we will indulge it.
+ * started), we will indulge it. RFCs 4346 & 5246 state that app
+ * data should be allowed during the handshake without any limits
+ * specified. This seems dangerous so we only allow it up until the CCS
+ * has been received.
  */
 if (s->s3->in_read_app_data &&
-(s->s3->total_renegotiations != 0) &&
-(((s->state & SSL_ST_CONNECT) &&
-  (s->state >= SSL3_ST_CW_CLNT_HELLO_A) &&
-  (s->state <= SSL3_ST_CR_SRVR_HELLO_A)
- ) || ((s->state & SSL_ST_ACCEPT) &&
-   (s->state <= SSL3_ST_SW_HELLO_REQ_A) &&
-   (s->state >= SSL3_ST_SR_CLNT_HELLO_A)
- )
-)) {
+s->renegotiate &&
+s->s3->change_cipher_spec == 0) {
 s->s3->in_read_app_data = 2;
 return (-1);
 } else {
-- 
2.1.4

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Matt Caswell via RT]

ore* the Finished has been processed. This seems dangerous to me
because it is not until the Finished is processed that we verify the
handshake data MAC - and yet we could already have acted upon app data
received. I assume the intent was to allow the interleaved app data only
up until the point that the CCS is received. I have attached a patch for
1.0.2 that implements that logic.

Matt


>From 0260f9d34d81f5080bbbd602577f201922fd4062 Mon Sep 17 00:00:00 2001
From: Matt Caswell <m...@openssl.org>
Date: Fri, 25 Sep 2015 10:34:27 +0100
Subject: [PATCH] Allow interleaved app data in a renegotiation

Prior to TLS1.1 SSL3/TLS1.0 was ambigous about what to do with application
data received during a renegotiation handshake. The existing code (which
predates TLS1.1) disallows this. TLS1.1 clarifies the situation to
explicitly allow this. This patch enables interleaved app data up until the
point that the CCS is received. Whilst the RFC does not explicitly say so
it seems incorrect to allow it after this point.
---
 ssl/s3_pkt.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/ssl/s3_pkt.c b/ssl/s3_pkt.c
index 3798902..22a27cf 100644
--- a/ssl/s3_pkt.c
+++ b/ssl/s3_pkt.c
@@ -1608,18 +1608,14 @@ int ssl3_read_bytes(SSL *s, int type, unsigned char *buf, int len, int peek)
  * application data.  If the library was running inside ssl3_read()
  * (i.e. in_read_app_data is set) and it makes sense to read
  * application data at this point (session renegotiation not yet
- * started), we will indulge it.
+ * started), we will indulge it. RFCs 4346 & 5246 state that app
+ * data should be allowed during the handshake without any limits
+ * specified. This seems dangerous so we only allow it up until the CCS
+ * has been received.
  */
 if (s->s3->in_read_app_data &&
-(s->s3->total_renegotiations != 0) &&
-(((s->state & SSL_ST_CONNECT) &&
-  (s->state >= SSL3_ST_CW_CLNT_HELLO_A) &&
-  (s->state <= SSL3_ST_CR_SRVR_HELLO_A)
- ) || ((s->state & SSL_ST_ACCEPT) &&
-   (s->state <= SSL3_ST_SW_HELLO_REQ_A) &&
-   (s->state >= SSL3_ST_SR_CLNT_HELLO_A)
- )
-)) {
+s->renegotiate &&
+s->s3->change_cipher_spec == 0) {
 s->s3->in_read_app_data = 2;
 return (-1);
 } else {
-- 
2.1.4

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4062] [PATCH] Fix build failure

[Matt Caswell via RT]

Patch applied. Thanks.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev