[openssl-dev] Using openssl with a remote private key

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[openssl-dev] Using openssl with a remote private key

Tigran Gyonjyan (BLOOMBERG/ 731 LEX)
Hi there!

Recently I had to work on an openssl project where due to security requirements I had to place the private key for the server certificate on another machine. In order to be able to make openssl ignore the fake private key in the certificate I had to "hack" some data structures to delegate the handshake decrypt to the remote machine so that the handshake could succeed.

I was wondering if this capability to delegate the decrypt function can be useful enough to incorporate into the official version.
In cases when the client and the server are located on user's machine it is a risk to keep the private key on that machine.

Let me know if there is a better solution for this problem.

Cheers,
Tigran

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Using openssl with a remote private key

Fedor Indutny
Hello Tigran!

I was using:


For quite a long time now. It seems that you have your own solution, but anyway posted it here in case you are interested.

Cheers!

On Tue, Mar 17, 2015 at 8:44 AM, Tigran Gyonjyan (BLOOMBERG/ 731 LEX) <[hidden email]> wrote:
Hi there!

Recently I had to work on an openssl project where due to security requirements I had to place the private key for the server certificate on another machine. In order to be able to make openssl ignore the fake private key in the certificate I had to "hack" some data structures to delegate the handshake decrypt to the remote machine so that the handshake could succeed.

I was wondering if this capability to delegate the decrypt function can be useful enough to incorporate into the official version.
In cases when the client and the server are located on user's machine it is a risk to keep the private key on that machine.

Let me know if there is a better solution for this problem.

Cheers,
Tigran

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



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

[openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

Erik Tkal-3
In reply to this post by Tigran Gyonjyan (BLOOMBERG/ 731 LEX)
In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour of a non-resumed EAP-FAST session.

RFC 4851 indicates that the server can go straight from the serverHello to changeCipherSpec to resume a session but can also fall back to a full handshake.  With 1.0.1l the client ends up issuing an unexpected message alert if the server continues with its certificate message.

I traced this to the following change:

    Set s->hit when resuming from external pre-shared secret.

    https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9

When processing the serverHello s->tls_session_secret_cb() is called to see if the client has a session secret, and if so the old code would set the flag that a CCS was acceptable at that point.  However, the above change now also sets s->hit, which then “requires* that a finished message is expected next, triggering the alert otherwise.

Also, another change is suspect in that the latest code no longer sets the flag that a CCS is acceptable at that point:

    Ensure SSL3_FLAGS_CCS_OK (or d1->change_cipher_spec_ok for DTLS) is reset


In order for EAP-FAST to work it seems that if the client does have a tls_session_secret that s->hit must NOT be set since there is no indication in the serverHello as to whether the session_ticket sent by the client is accepted by the server (the sessionTicket extension is not sent by the server in EAP-FAST), and that SSL3_FLAGS_CCS_OK has to be set since the server MAY continue immediately with a changeCipherSpec.

  Thanks,
  Erik

....................................
Erik Tkal


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

Karthikeyan Bhargavan-2
I would be very careful about this code. When we ran our tests on OpenSSL (www.smacktls.com), we found a bunch of issues that were narrowly prevented by a combination of flags (s->hit, SSL3_FLAGS_OK, s->s3->change_cipher_spec). 

Let’s carefully test any change here, so we do not re-enable CVE-2014-0224 (Early CCS Attack)


On 17 Mar 2015, at 18:53, Erik Tkal <[hidden email]> wrote:

In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour of a non-resumed EAP-FAST session.

RFC 4851 indicates that the server can go straight from the serverHello to changeCipherSpec to resume a session but can also fall back to a full handshake.  With 1.0.1l the client ends up issuing an unexpected message alert if the server continues with its certificate message.

I traced this to the following change:

    Set s->hit when resuming from external pre-shared secret.

    https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9

When processing the serverHello s->tls_session_secret_cb() is called to see if the client has a session secret, and if so the old code would set the flag that a CCS was acceptable at that point.  However, the above change now also sets s->hit, which then “requires* that a finished message is expected next, triggering the alert otherwise.

Also, another change is suspect in that the latest code no longer sets the flag that a CCS is acceptable at that point:

    Ensure SSL3_FLAGS_CCS_OK (or d1->change_cipher_spec_ok for DTLS) is reset


In order for EAP-FAST to work it seems that if the client does have a tls_session_secret that s->hit must NOT be set since there is no indication in the serverHello as to whether the session_ticket sent by the client is accepted by the server (the sessionTicket extension is not sent by the server in EAP-FAST), and that SSL3_FLAGS_CCS_OK has to be set since the server MAY continue immediately with a changeCipherSpec.

  Thanks,
  Erik

....................................
Erik Tkal

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


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

signature.asc (507 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Using openssl with a remote private key

David Woodhouse-7
In reply to this post by Tigran Gyonjyan (BLOOMBERG/ 731 LEX)
On Tue, 2015-03-17 at 15:44 +0000, Tigran Gyonjyan (BLOOMBERG/ 731 LEX)
wrote:

>
>
> Recently I had to work on an openssl project where due to security
> requirements I had to place the private key for the server certificate
> on another machine. In order to be able to make openssl ignore the
> fake private key in the certificate I had to "hack" some data
> structures to delegate the handshake decrypt to the remote machine so
> that the handshake could succeed.
>
>
> I was wondering if this capability to delegate the decrypt function
> can be useful enough to incorporate into the official version.
> In cases when the client and the server are located on user's machine
> it is a risk to keep the private key on that machine.
>
>
> Let me know if there is a better solution for this problem.
Yes, PKCS#11. Which is *all* about delegating the decrypt function.

If you install the OpenSC ENGINE_pkcs11 (which *really* ought to be part
of OpenSSL, either in ENGINE form or preferably just native PKCS#11
support like libp11), you can configure it to use a key in PKCS#11. And
it's relatively simple to have a PKCS#11 provider which does the RPC to
the remote machine or wherever the key is actually stored.

I have patches outstanding to ENGINE_pkcs11 which make it Just Work™
with PKCS#11 tokens which are configured in the system's p11-kit
configuration, and accept standard PKCS#11 URIs for them instead of the
bizarre format it currently requires.

--
dwmw2


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

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

David Woodhouse-7
In reply to this post by Erik Tkal-3
On Tue, 2015-03-17 at 13:53 -0400, Erik Tkal wrote:
> In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour
> of a non-resumed EAP-FAST session.

Erik, please could you explain what relevance this message has to the
message "Using openssl with a remote private key" from Tigran Gyonjyan,
to which it is a reply?

--
dwmw2


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

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

Erik Tkal-3
In reply to this post by Karthikeyan Bhargavan-2
I don’t disagree, but I’m looking for independent confirmation that the changes are not correct.  They do not appear to specifically have been made for any vulnerabilities.

In looking at RFC 5077 (the generic non-EAP-FAST scenario) section 3.1 shows that the server may send a certificate message to continue the handshake after receiving a sessionTicket from the client.  With the first change I noted below the possession of a tls_session_secret now implies by the setting of s->hit on the client that the session *will* be resumed, which is not the case.  The resumption requires determination of the next message.  In the case of a pure sessionID resumption that is the case since the server confirms it in the serverHello, but not when using the sessionTicket extension.

  Erik


On 17 Mar 2015, at 2:59 PM, Karthikeyan Bhargavan <[hidden email]> wrote:

I would be very careful about this code. When we ran our tests on OpenSSL (www.smacktls.com), we found a bunch of issues that were narrowly prevented by a combination of flags (s->hit, SSL3_FLAGS_OK, s->s3->change_cipher_spec). 

Let’s carefully test any change here, so we do not re-enable CVE-2014-0224 (Early CCS Attack)


On 17 Mar 2015, at 18:53, Erik Tkal <[hidden email]> wrote:

In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour of a non-resumed EAP-FAST session.

RFC 4851 indicates that the server can go straight from the serverHello to changeCipherSpec to resume a session but can also fall back to a full handshake.  With 1.0.1l the client ends up issuing an unexpected message alert if the server continues with its certificate message.

I traced this to the following change:

    Set s->hit when resuming from external pre-shared secret.

    https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9

When processing the serverHello s->tls_session_secret_cb() is called to see if the client has a session secret, and if so the old code would set the flag that a CCS was acceptable at that point.  However, the above change now also sets s->hit, which then “requires* that a finished message is expected next, triggering the alert otherwise.

Also, another change is suspect in that the latest code no longer sets the flag that a CCS is acceptable at that point:

    Ensure SSL3_FLAGS_CCS_OK (or d1->change_cipher_spec_ok for DTLS) is reset


In order for EAP-FAST to work it seems that if the client does have a tls_session_secret that s->hit must NOT be set since there is no indication in the serverHello as to whether the session_ticket sent by the client is accepted by the server (the sessionTicket extension is not sent by the server in EAP-FAST), and that SSL3_FLAGS_CCS_OK has to be set since the server MAY continue immediately with a changeCipherSpec.

  Thanks,
  Erik

....................................
Erik Tkal

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

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


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Using openssl with a remote private key

Tigran Gyonjyan (BLOOMBERG/ 731 LEX)
In reply to this post by Tigran Gyonjyan (BLOOMBERG/ 731 LEX)
Thank you for your responses, PKCS#11 could be the right way to go. I am hoping there is flexibility as per what functionality I want to delegate (just need the decrypt piece).
If I had to implement a fully fledged PKCS#11 module that would be an overkill. I hope that's not the case?


From: [hidden email] At: Mar 17 2015 16:02:44
To: [hidden email], [hidden email]
Subject: Re: [openssl-dev] Using openssl with a remote private key
On Tue, 2015-03-17 at 15:44 +0000, Tigran Gyonjyan (BLOOMBERG/ 731 LEX)
wrote:

>
>
> Recently I had to work on an openssl project where due to security
> requirements I had to place the private key for the server certificate
> on another machine. In order to be able to make openssl ignore the
> fake private key in the certificate I had to "hack" some data
> structures to delegate the handshake decrypt to the remote machine so
> that the handshake could succeed.
>
>
> I was wondering if this capability to delegate the decrypt function
> can be useful enough to incorporate into the official version.
> In cases when the client and the server are located on user's machine
> it is a risk to keep the private key on that machine.
>
>
> Let me know if there is a better solution for this problem.

Yes, PKCS#11. Which is *all* about delegating the decrypt function.

If you install the OpenSC ENGINE_pkcs11 (which *really* ought to be part
of OpenSSL, either in ENGINE form or preferably just native PKCS#11
support like libp11), you can configure it to use a key in PKCS#11. And
it's relatively simple to have a PKCS#11 provider which does the RPC to
the remote machine or wherever the key is actually stored.

I have patches outstanding to ENGINE_pkcs11 which make it Just Work™
with PKCS#11 tokens which are configured in the system's p11-kit
configuration, and accept standard PKCS#11 URIs for them instead of the
bizarre format it currently requires.

--
dwmw2



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Using openssl with a remote private key

David Woodhouse-7
On Tue, 2015-03-17 at 22:22 +0000, Tigran Gyonjyan (BLOOMBERG/ 731 LEX)
wrote:
> Thank you for your responses, PKCS#11 could be the right way to go. I
> am hoping there is flexibility as per what functionality I want to
> delegate (just need the decrypt piece).
> If I had to implement a fully fledged PKCS#11 module that would be an
> overkill. I hope that's not the case?

You don't have to have the *cert* in PKCS#11. Only the key. A module to
implement that much can be fairly trivial.


--
dwmw2


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

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Using openssl with a remote private key

Douglas E Engert
In reply to this post by Tigran Gyonjyan (BLOOMBERG/ 731 LEX)


On 3/17/2015 10:44 AM, Tigran Gyonjyan (BLOOMBERG/ 731 LEX) wrote:
> Hi there!
>
> Recently I had to work on an openssl project where due to security requirements I had to place the private key for the server certificate on another machine. In order to be able to make openssl ignore
> the fake private key in the certificate I had to "hack" some data structures to delegate the handshake decrypt to the remote machine so that the handshake could succeed.

Introducing another machine, will introduce addition trust issues, as to why the
"server" trusts the "other machine" holding the private key, how does the "other machine" trust the "server" and trust
the network connections between the two machines.
If not done correctly, the "other machine" could be attacked to decrypt requests from a man-in-the-middle
pretending to be the "server".

(The certificate contains the public key, the private key is not part of the certificate.)

>
> I was wondering if this capability to delegate the decrypt function can be useful enough to incorporate into the official version.
> In cases when the client and the server are located on user's machine it is a risk to keep the private key on that machine.

As pointed out in other replies, PKCS#11 and openssl_engine could be used. If used with a
smart card, the smart card could be on the "other machine". The PKCS#11 implementation
could be using PCSC to talk to the smart card, which can be used across a network. For example remote desktop, rdesktop or RDP
can transport the smart card APDUs across the network.

This is usually used by a user with a smart card at a remote terminal, and the trust model
is different then in your case of a "server" to the "other machine".

>
> Let me know if there is a better solution for this problem.
>
> Cheers,
> Tigran
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

--

  Douglas E. Engert  <[hidden email]>

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

John Foley-3
In reply to this post by Erik Tkal-3
Something does seem suspect here.  Maybe I'm misusing the API, but when using the attached patch for s_server, the client side does reject the NewSessionTicket message from the server.  This only happens when using SSL_set_session_secret_cb() on the server side.  When using this callback facility, the server changes the order of the handshake messages. 

The order without using SSL_set_session_secret_cb() is:

<-ServerHello
<-Certificate
<-ServerKeyExchange
<-ServerHelloDone
->ClientKeyExchange
->ChangeCipherSpec
<-NewSessionTicket
<-ChangeCipherSpec


The order when using SSL_set_session_secret_cb() is:

<-ServerHello
<-NewSessionTicket
<-ChangeCipherSpec
->Alert


The session ticket extension in the ClientHello is empty in both cases.  It appears the server thinks it's using a valid session ticket and proceeds directly to the ChangeCipherSpec.



On 03/17/2015 04:16 PM, Erik Tkal wrote:
I don’t disagree, but I’m looking for independent confirmation that the changes are not correct.  They do not appear to specifically have been made for any vulnerabilities.

In looking at RFC 5077 (the generic non-EAP-FAST scenario) section 3.1 shows that the server may send a certificate message to continue the handshake after receiving a sessionTicket from the client.  With the first change I noted below the possession of a tls_session_secret now implies by the setting of s->hit on the client that the session *will* be resumed, which is not the case.  The resumption requires determination of the next message.  In the case of a pure sessionID resumption that is the case since the server confirms it in the serverHello, but not when using the sessionTicket extension.

  Erik


On 17 Mar 2015, at 2:59 PM, Karthikeyan Bhargavan <[hidden email]> wrote:

I would be very careful about this code. When we ran our tests on OpenSSL (www.smacktls.com), we found a bunch of issues that were narrowly prevented by a combination of flags (s->hit, SSL3_FLAGS_OK, s->s3->change_cipher_spec). 

Let’s carefully test any change here, so we do not re-enable CVE-2014-0224 (Early CCS Attack)


On 17 Mar 2015, at 18:53, Erik Tkal <[hidden email]> wrote:

In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour of a non-resumed EAP-FAST session.

RFC 4851 indicates that the server can go straight from the serverHello to changeCipherSpec to resume a session but can also fall back to a full handshake.  With 1.0.1l the client ends up issuing an unexpected message alert if the server continues with its certificate message.

I traced this to the following change:

    Set s->hit when resuming from external pre-shared secret.

    https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9

When processing the serverHello s->tls_session_secret_cb() is called to see if the client has a session secret, and if so the old code would set the flag that a CCS was acceptable at that point.  However, the above change now also sets s->hit, which then “requires* that a finished message is expected next, triggering the alert otherwise.

Also, another change is suspect in that the latest code no longer sets the flag that a CCS is acceptable at that point:

    Ensure SSL3_FLAGS_CCS_OK (or d1->change_cipher_spec_ok for DTLS) is reset


In order for EAP-FAST to work it seems that if the client does have a tls_session_secret that s->hit must NOT be set since there is no indication in the serverHello as to whether the session_ticket sent by the client is accepted by the server (the sessionTicket extension is not sent by the server in EAP-FAST), and that SSL3_FLAGS_CCS_OK has to be set since the server MAY continue immediately with a changeCipherSpec.

  Thanks,
  Erik

....................................
Erik Tkal

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

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



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


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

recreate.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

Erik Tkal-3
In reply to this post by Erik Tkal-3
FWIW, RFC 5077 says:


3.4. Interaction with TLS Session ID

...
   When presenting a ticket, the client MAY generate and include a
   Session ID in the TLS ClientHello.  If the server accepts the ticket
   and the Session ID is not empty, then it MUST respond with the same
   Session ID present in the ClientHello.  This allows the client to
   easily differentiate when the server is resuming a session from when
   it is falling back to a full handshake.  Since the client generates a
   Session ID, the server MUST NOT rely upon the Session ID having a
   particular value when validating the ticket.  If a ticket is
   presented by the client, the server MUST NOT attempt to use the
   Session ID in the ClientHello for stateful session resumption.
   Alternatively, the client MAY include an empty Session ID in the
   ClientHello.  In this case, the client ignores the Session ID sent in
   the ServerHello and determines if the server is resuming a session by
   the subsequent handshake messages.

If I do not send a sessionID in the clientHello but do send a valid sessionTicket extension, the server goes straight to changeCipherSpec and the client generates an UnexpectedMessage alert.

This is slightly different from the issue I saw before, as I was trying to use stock OpenSSL instead of our application to recreate by making minor changes.  In this case I was *not* setting the session secret callback but instead using OpenSSL’s default mechanism and only removing the sessionId from  the client.  In the full case using EAP-FAST I’ll have to wire up session secret processing and the sessionTicket extension handling on both sides, but this shows something is definitely awry with the recent changes.

  Erik

write to 0x7fafcac26c60 [0x7fafcc004603] (467 bytes => 467 (0x1D3))
0000 - 16 03 01 01 ce 01 00 01-ca 03 03 a5 20 37 c1 48   ............ 7.H
0010 - 64 46 12 0a d0 1c 70 a8-28 7b 05 51 f0 14 31 7b   dF....p.({.Q..1{
0020 - 1c fe 52 c2 9c 37 74 d9-a9 17 57 00 00 94 c0 30   ..R..7t...W....0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a3 00 9f 00 6b   .,.(.$.........k
0040 - 00 6a 00 39 00 38 00 88-00 87 c0 32 c0 2e c0 2a   .j.9.8.....2...*
0050 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 2f   .&.......=.5.../
0060 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67   .+.'.#.........g
0070 - 00 40 00 33 00 32 00 9a-00 99 00 45 00 44 c0 31   .@.3.2.....E.D.1
0080 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f   .-.).%.......<./
0090 - 00 96 00 41 00 07 c0 11-c0 07 c0 0c c0 02 00 05   ...A............
00a0 - 00 04 c0 12 c0 08 00 16-00 13 c0 0d c0 03 00 0a   ................
00b0 - 00 15 00 12 00 09 00 14-00 11 00 08 00 06 00 03   ................
00c0 - 00 ff 01 00 01 0d 00 0b-00 04 03 00 01 02 00 0a   ................
00d0 - 00 34 00 32 00 0e 00 0d-00 19 00 0b 00 0c 00 18   .4.2............
00e0 - 00 09 00 0a 00 16 00 17-00 08 00 06 00 07 00 14   ................
00f0 - 00 15 00 04 00 05 00 12-00 13 00 01 00 02 00 03   ................
0100 - 00 0f 00 10 00 11 00 23-00 a0 d7 39 e6 23 d8 a1   .......#...9.#..
0110 - 41 bd a1 1a 55 4d 7f 07-6d 4d 1c 89 b0 f8 1d b4   A...UM..mM......
0120 - 15 a0 e4 96 73 6a 75 53-a3 0d d3 90 2a 48 92 ec   ....sjuS....*H..
0130 - be 57 15 fe 20 c3 0f 34-12 63 e9 87 d6 87 06 d1   .W.. ..4.c......
0140 - f2 28 5e 3e 7d 6c 96 79-f9 6d 76 27 51 07 fc a3   .(^>}l.y.mv'Q...
0150 - 16 83 64 e1 af 24 03 b0-34 c4 d1 a3 f9 2e f8 75   ..d..$..4......u
0160 - 30 18 27 55 54 3c 53 9a-70 1a cc 97 95 b7 a1 09   0.'UT<S.p.......
0170 - 02 ac ca fd 6d 17 21 fe-c4 22 b9 99 d5 f2 91 73   ....m.!..".....s
0180 - 85 b3 55 89 78 0d d3 c0-7e b6 a2 54 c3 d6 f6 f1   ..U.x...~..T....
0190 - 18 d5 4c 78 00 d4 61 ad-1e a8 68 e4 4b 6c 0d b0   ..Lx..a...h.Kl..
01a0 - 45 4c 33 a2 08 ca 2f 03-e2 ab 00 0d 00 20 00 1e   EL3.../...... ..
01b0 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02   ................
01c0 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f   ................
01d0 - 00 01 01                                          ...
read from 0x7fafcac26c60 [0x7fafcc000003] (5 bytes => 5 (0x5))
0000 - 16 03 03 00 36                                    ....6
read from 0x7fafcac26c60 [0x7fafcc000008] (54 bytes => 54 (0x36))
0000 - 02 00 00 32 03 03 89 9d-07 82 8f 74 e7 dd 44 6e   ...2.......t..Dn
0010 - 16 28 c9 15 f2 5c d5 5b-f8 70 03 c2 48 f6 1a b4   .(...\.[.p..H...
0020 - 54 d5 1f af ca 09 00 c0-30 00 00 0a ff 01 00 01   T.......0.......
0030 - 00 00 0f 00 01 01                                 ......
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "heartbeat" (id=15), len=1
0000 - 01                                                .
read from 0x7fafcac26c60 [0x7fafcc000003] (5 bytes => 5 (0x5))
0000 - 14 03 03 00 01                                    .....
read from 0x7fafcac26c60 [0x7fafcc000008] (1 bytes => 1 (0x1))
0000 - 01                                                .
write to 0x7fafcac26c60 [0x7fafcc801000] (7 bytes => 7 (0x7))
0000 - 15 03 03 00 02 02 0a                              .......
140735260517200:error:14094085:SSL routines:SSL3_READ_BYTES:ccs received early:s3_pkt.c:1340:
---



On 17 Mar 2015, at 4:16 PM, Erik Tkal <[hidden email]> wrote:

I don’t disagree, but I’m looking for independent confirmation that the changes are not correct.  They do not appear to specifically have been made for any vulnerabilities.

In looking at RFC 5077 (the generic non-EAP-FAST scenario) section 3.1 shows that the server may send a certificate message to continue the handshake after receiving a sessionTicket from the client.  With the first change I noted below the possession of a tls_session_secret now implies by the setting of s->hit on the client that the session *will* be resumed, which is not the case.  The resumption requires determination of the next message.  In the case of a pure sessionID resumption that is the case since the server confirms it in the serverHello, but not when using the sessionTicket extension.

  Erik


On 17 Mar 2015, at 2:59 PM, Karthikeyan Bhargavan <[hidden email]> wrote:

I would be very careful about this code. When we ran our tests on OpenSSL (www.smacktls.com), we found a bunch of issues that were narrowly prevented by a combination of flags (s->hit, SSL3_FLAGS_OK, s->s3->change_cipher_spec). 

Let’s carefully test any change here, so we do not re-enable CVE-2014-0224 (Early CCS Attack)


On 17 Mar 2015, at 18:53, Erik Tkal <[hidden email]> wrote:

In upgrading from 1.0.1i to 1.0.1l I found an issue in the behaviour of a non-resumed EAP-FAST session.

RFC 4851 indicates that the server can go straight from the serverHello to changeCipherSpec to resume a session but can also fall back to a full handshake.  With 1.0.1l the client ends up issuing an unexpected message alert if the server continues with its certificate message.

I traced this to the following change:

    Set s->hit when resuming from external pre-shared secret.

    https://github.com/openssl/openssl/commit/7b3ba508af5c86afe43e28174aa3c53a0a24f4d9

When processing the serverHello s->tls_session_secret_cb() is called to see if the client has a session secret, and if so the old code would set the flag that a CCS was acceptable at that point.  However, the above change now also sets s->hit, which then “requires* that a finished message is expected next, triggering the alert otherwise.

Also, another change is suspect in that the latest code no longer sets the flag that a CCS is acceptable at that point:

    Ensure SSL3_FLAGS_CCS_OK (or d1->change_cipher_spec_ok for DTLS) is reset


In order for EAP-FAST to work it seems that if the client does have a tls_session_secret that s->hit must NOT be set since there is no indication in the serverHello as to whether the session_ticket sent by the client is accepted by the server (the sessionTicket extension is not sent by the server in EAP-FAST), and that SSL3_FLAGS_CCS_OK has to be set since the server MAY continue immediately with a changeCipherSpec.

  Thanks,
  Erik

....................................
Erik Tkal

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

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



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

Dr. Stephen Henson
On Thu, Mar 19, 2015, Erik Tkal wrote:

>
> If I do not send a sessionID in the clientHello but do send a valid
> sessionTicket extension, the server goes straight to changeCipherSpec and
> the client generates an UnexpectedMessage alert.
>

Does the server send back an empty session ticket extension?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Using openssl with a remote private key

Tigran Gyonjyan (BLOOMBERG/ 731 LEX)
In reply to this post by Tigran Gyonjyan (BLOOMBERG/ 731 LEX)
This is a very valid security concern. The reason the private key shouldn't be on the same machine is that the Web server is installed on the client's machine (for various reasons). This means for security reasons the private key shouldn't be located on the client's (untrusted) machine. So one of the ways to enable ssl connection betwen client code and the local web server is to delegate decrypting of the pre-master key to another (owned and thus trusted) server which actually has the private key. 
So no smartcards are involved, just a problem caused by machine topology.

There might be other solutions for this, still researching...

From: [hidden email] At: Mar 17 2015 20:02:38
To: [hidden email]
Subject: Re: [openssl-dev] Using openssl with a remote private key


On 3/17/2015 10:44 AM, Tigran Gyonjyan (BLOOMBERG/ 731 LEX) wrote:
> Hi there!
>
> Recently I had to work on an openssl project where due to security requirements I had to place the private key for the server certificate on another machine. In order to be able to make openssl ignore
> the fake private key in the certificate I had to "hack" some data structures to delegate the handshake decrypt to the remote machine so that the handshake could succeed.

Introducing another machine, will introduce addition trust issues, as to why the
"server" trusts the "other machine" holding the private key, how does the "other machine" trust the "server" and trust
the network connections between the two machines.
If not done correctly, the "other machine" could be attacked to decrypt requests from a man-in-the-middle
pretending to be the "server".

(The certificate contains the public key, the private key is not part of the certificate.)

>
> I was wondering if this capability to delegate the decrypt function can be useful enough to incorporate into the official version.
> In cases when the client and the server are located on user's machine it is a risk to keep the private key on that machine.

As pointed out in other replies, PKCS#11 and openssl_engine could be used. If used with a
smart card, the smart card could be on the "other machine". The PKCS#11 implementation
could be using PCSC to talk to the smart card, which can be used across a network. For example remote desktop, rdesktop or RDP
can transport the smart card APDUs across the network.

This is usually used by a user with a smart card at a remote terminal, and the trust model
is different then in your case of a "server" to the "other machine".

>
> Let me know if there is a better solution for this problem.
>
> Cheers,
> Tigran
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

--

Douglas E. Engert <[hidden email]>

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


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

John Foley-3
In reply to this post by Dr. Stephen Henson
We've found a way to recreate the scenario using s_client/s_server.  We're using the -no_ticket option on the server.  Therefore, the ServerHello doesn't contain the session ticket extension.  It also doesn't send the NewSessionTicket message.  

To summarize the problem, when the client side is using SSL_set_session_secret_cb() and including a valid ticket in the ClintHello, then the logic in ssl3_get_server_hello() assumes the server is doing session resumption.  This puts the client-side state machine into the SSL3_ST_CR_FINISHED_A.  However, since the server side is configured to not do resumption via the -no_ticket option, the server continues with a normal handshake by sending the Certificate message.  The client aborts the handshake when it receives the Certificate message while in the SSL3_ST_CR_FINISHED_A state.


As Erik identified earlier in the thread, the cause of this appears to be the addition of setting s->hit in the following code:

    if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) {
        SSL_CIPHER *pref_cipher = NULL;
        s->session->master_key_length = sizeof(s->session->master_key);
        if (s->tls_session_secret_cb(s, s->session->master_key,
                                     &s->session->master_key_length,
                                     NULL, &pref_cipher,
                                     s->tls_session_secret_cb_arg)) {
            s->session->cipher = pref_cipher ?
                pref_cipher : ssl_get_cipher_by_char(s, p + j);
            s->hit = 1;
        }
    }

Why does the client-side now assume the server is doing session resumption simply because the session secret callback facility is being used?
________________________________________
From: openssl-dev [[hidden email]] on behalf of Dr. Stephen Henson [[hidden email]]
Sent: Thursday, March 19, 2015 11:49 AM
To: [hidden email]
Subject: Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

On Thu, Mar 19, 2015, Erik Tkal wrote:

>
> If I do not send a sessionID in the clientHello but do send a valid
> sessionTicket extension, the server goes straight to changeCipherSpec and
> the client generates an UnexpectedMessage alert.
>

Does the server send back an empty session ticket extension?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

Emilia Käsper-2


On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) <[hidden email]> wrote:
We've found a way to recreate the scenario using s_client/s_server.  We're using the -no_ticket option on the server.  Therefore, the ServerHello doesn't contain the session ticket extension.  It also doesn't send the NewSessionTicket message.

To summarize the problem, when the client side is using SSL_set_session_secret_cb() and including a valid ticket in the ClintHello, then the logic in ssl3_get_server_hello() assumes the server is doing session resumption.  This puts the client-side state machine into the SSL3_ST_CR_FINISHED_A.  However, since the server side is configured to not do resumption via the -no_ticket option, the server continues with a normal handshake by sending the Certificate message.  The client aborts the handshake when it receives the Certificate message while in the SSL3_ST_CR_FINISHED_A state.


As Erik identified earlier in the thread, the cause of this appears to be the addition of setting s->hit in the following code:

    if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) {
        SSL_CIPHER *pref_cipher = NULL;
        s->session->master_key_length = sizeof(s->session->master_key);
        if (s->tls_session_secret_cb(s, s->session->master_key,
                                     &s->session->master_key_length,
                                     NULL, &pref_cipher,
                                     s->tls_session_secret_cb_arg)) {
            s->session->cipher = pref_cipher ?
                pref_cipher : ssl_get_cipher_by_char(s, p + j);
            s->hit = 1;
        }
    }

Why does the client-side now assume the server is doing session resumption simply because the session secret callback facility is being used?

Because a developer (me) introduced a bug. With OpenSSL client behaviour, peeking ahead is only required for EAP-FAST. I got rid of the peeking while tightening up the ChangeCipherSpec handling and in the process, got it wrong for EAP-FAST. Anyway, apologies, I see the problem and am working on a patch.

While we're at it, you may be able to help me with the following question: how should the client handle callback failure? The old code (pre my refactoring which introduced the bug) did this

#ifndef OPENSSL_NO_TLSEXT
	/* check if we want to resume the session based on external pre-shared secret */
	if (s->version >= TLS1_VERSION && s->tls_session_secret_cb)
		{
		SSL_CIPHER *pref_cipher=NULL;
		s->session->master_key_length=sizeof(s->session->master_key);
		if (s->tls_session_secret_cb(s, s->session->master_key,
					     &s->session->master_key_length,
					     NULL, &pref_cipher,
					     s->tls_session_secret_cb_arg))
			{
			s->session->cipher = pref_cipher ?
				pref_cipher : ssl_get_cipher_by_char(s, p+j);
			}
		}
#endif /* OPENSSL_NO_TLSEXT */
This is surely wrong as it's just ignoring the failure?
Thanks,
Emilia
________________________________________
From: openssl-dev [[hidden email]] on behalf of Dr. Stephen Henson [[hidden email]]
Sent: Thursday, March 19, 2015 11:49 AM
To: [hidden email]
Subject: Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

On Thu, Mar 19, 2015, Erik Tkal wrote:

>
> If I do not send a sessionID in the clientHello but do send a valid
> sessionTicket extension, the server goes straight to changeCipherSpec and
> the client generates an UnexpectedMessage alert.
>

Does the server send back an empty session ticket extension?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

John Foley-3
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

attachment0 (12 bytes) Download Attachment
encrypted.asc (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

John Foley-3
In reply to this post by Emilia Käsper-2
Trying again w/o PGP...  :-)

Thanks for taking a look at this problem.  Regarding how to handle a failure in the session secret callback, the legacy logic would likely result in a "bad record mac" error because the master secrets on the client/server do not match.  It would be good to trigger an internal error to aid with troubleshooting.  Maybe something like:

        SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
        goto err;

It's debatable whether the alert needs to be sent to the server.  Since this is an internal error, it should be safe to send the alert.  Therefore, maybe you would actually want to do something like:

        SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
        al = SSL_AD_INTERNAL_ERROR;
        goto f_err;



On 03/23/2015 09:17 PM, Emilia Käsper wrote:


On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) <[hidden email]> wrote:
We've found a way to recreate the scenario using s_client/s_server.  We're using the -no_ticket option on the server.  Therefore, the ServerHello doesn't contain the session ticket extension.  It also doesn't send the NewSessionTicket message.

To summarize the problem, when the client side is using SSL_set_session_secret_cb() and including a valid ticket in the ClintHello, then the logic in ssl3_get_server_hello() assumes the server is doing session resumption.  This puts the client-side state machine into the SSL3_ST_CR_FINISHED_A.  However, since the server side is configured to not do resumption via the -no_ticket option, the server continues with a normal handshake by sending the Certificate message.  The client aborts the handshake when it receives the Certificate message while in the SSL3_ST_CR_FINISHED_A state.


As Erik identified earlier in the thread, the cause of this appears to be the addition of setting s->hit in the following code:

    if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) {
        SSL_CIPHER *pref_cipher = NULL;
        s->session->master_key_length = sizeof(s->session->master_key);
        if (s->tls_session_secret_cb(s, s->session->master_key,
                                     &s->session->master_key_length,
                                     NULL, &pref_cipher,
                                     s->tls_session_secret_cb_arg)) {
            s->session->cipher = pref_cipher ?
                pref_cipher : ssl_get_cipher_by_char(s, p + j);
            s->hit = 1;
        }
    }

Why does the client-side now assume the server is doing session resumption simply because the session secret callback facility is being used?

Because a developer (me) introduced a bug. With OpenSSL client behaviour, peeking ahead is only required for EAP-FAST. I got rid of the peeking while tightening up the ChangeCipherSpec handling and in the process, got it wrong for EAP-FAST. Anyway, apologies, I see the problem and am working on a patch.

While we're at it, you may be able to help me with the following question: how should the client handle callback failure? The old code (pre my refactoring which introduced the bug) did this

#ifndef OPENSSL_NO_TLSEXT
	/* check if we want to resume the session based on external pre-shared secret */
	if (s->version >= TLS1_VERSION && s->tls_session_secret_cb)
		{
		SSL_CIPHER *pref_cipher=NULL;
		s->session->master_key_length=sizeof(s->session->master_key);
		if (s->tls_session_secret_cb(s, s->session->master_key,
					     &s->session->master_key_length,
					     NULL, &pref_cipher,
					     s->tls_session_secret_cb_arg))
			{
			s->session->cipher = pref_cipher ?
				pref_cipher : ssl_get_cipher_by_char(s, p+j);
			}
		}
#endif /* OPENSSL_NO_TLSEXT */
This is surely wrong as it's just ignoring the failure?
Thanks,
Emilia
________________________________________
From: openssl-dev [[hidden email]] on behalf of Dr. Stephen Henson [[hidden email]]
Sent: Thursday, March 19, 2015 11:49 AM
To: [hidden email]
Subject: Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

On Thu, Mar 19, 2015, Erik Tkal wrote:

>
> If I do not send a sessionID in the clientHello but do send a valid
> sessionTicket extension, the server goes straight to changeCipherSpec and
> the client generates an UnexpectedMessage alert.
>

Does the server send back an empty session ticket extension?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



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


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

Emilia Käsper-2


On Tue, Mar 24, 2015 at 2:01 PM, John Foley <[hidden email]> wrote:
Trying again w/o PGP...  :-)

Thanks for taking a look at this problem.  Regarding how to handle a failure in the session secret callback, the legacy logic would likely result in a "bad record mac" error because the master secrets on the client/server do not match.

But only in case we are actually resuming - no? Does the client always have a PAC available - I would guess not? Seems the legacy logic is such that it "happens to work", but I'd like to clear it up.
 
  It would be good to trigger an internal error to aid with troubleshooting.  Maybe something like:

        SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
        goto err;

It's debatable whether the alert needs to be sent to the server.  Since this is an internal error, it should be safe to send the alert.  Therefore, maybe you would actually want to do something like:

        SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
        al = SSL_AD_INTERNAL_ERROR;
        goto f_err;




On 03/23/2015 09:17 PM, Emilia Käsper wrote:


On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) <[hidden email]> wrote:
We've found a way to recreate the scenario using s_client/s_server.  We're using the -no_ticket option on the server.  Therefore, the ServerHello doesn't contain the session ticket extension.  It also doesn't send the NewSessionTicket message.

To summarize the problem, when the client side is using SSL_set_session_secret_cb() and including a valid ticket in the ClintHello, then the logic in ssl3_get_server_hello() assumes the server is doing session resumption.  This puts the client-side state machine into the SSL3_ST_CR_FINISHED_A.  However, since the server side is configured to not do resumption via the -no_ticket option, the server continues with a normal handshake by sending the Certificate message.  The client aborts the handshake when it receives the Certificate message while in the SSL3_ST_CR_FINISHED_A state.


As Erik identified earlier in the thread, the cause of this appears to be the addition of setting s->hit in the following code:

    if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) {
        SSL_CIPHER *pref_cipher = NULL;
        s->session->master_key_length = sizeof(s->session->master_key);
        if (s->tls_session_secret_cb(s, s->session->master_key,
                                     &s->session->master_key_length,
                                     NULL, &pref_cipher,
                                     s->tls_session_secret_cb_arg)) {
            s->session->cipher = pref_cipher ?
                pref_cipher : ssl_get_cipher_by_char(s, p + j);
            s->hit = 1;
        }
    }

Why does the client-side now assume the server is doing session resumption simply because the session secret callback facility is being used?

Because a developer (me) introduced a bug. With OpenSSL client behaviour, peeking ahead is only required for EAP-FAST. I got rid of the peeking while tightening up the ChangeCipherSpec handling and in the process, got it wrong for EAP-FAST. Anyway, apologies, I see the problem and am working on a patch.

While we're at it, you may be able to help me with the following question: how should the client handle callback failure? The old code (pre my refactoring which introduced the bug) did this

#ifndef OPENSSL_NO_TLSEXT
	/* check if we want to resume the session based on external pre-shared secret */
	if (s->version >= TLS1_VERSION && s->tls_session_secret_cb)
		{
		SSL_CIPHER *pref_cipher=NULL;
		s->session->master_key_length=sizeof(s->session->master_key);
		if (s->tls_session_secret_cb(s, s->session->master_key,
					     &s->session->master_key_length,
					     NULL, &pref_cipher,
					     s->tls_session_secret_cb_arg))
			{
			s->session->cipher = pref_cipher ?
				pref_cipher : ssl_get_cipher_by_char(s, p+j);
			}
		}
#endif /* OPENSSL_NO_TLSEXT */
This is surely wrong as it's just ignoring the failure?
Thanks,
Emilia
________________________________________
From: openssl-dev [[hidden email]] on behalf of Dr. Stephen Henson [[hidden email]]
Sent: Thursday, March 19, 2015 11:49 AM
To: [hidden email]
Subject: Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

On Thu, Mar 19, 2015, Erik Tkal wrote:

>
> If I do not send a sessionID in the clientHello but do send a valid
> sessionTicket extension, the server goes straight to changeCipherSpec and
> the client generates an UnexpectedMessage alert.
>

Does the server send back an empty session ticket extension?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



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


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



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

John Foley-3
Someone that understands EAP better than myself should probably provide input.  But my limited understand of EAP-FAST is it contributes to the master secret calculation used for the TLS session.  See section RFC 4851 Section 5.1. My understanding is this logic applies to both new and resumed sessions.  Hence, tls_session_secret_cb() is always in play for EAP-FAST.


On 03/26/2015 02:13 PM, Emilia Käsper wrote:


On Tue, Mar 24, 2015 at 2:01 PM, John Foley <[hidden email]> wrote:
Trying again w/o PGP...  :-)

Thanks for taking a look at this problem.  Regarding how to handle a failure in the session secret callback, the legacy logic would likely result in a "bad record mac" error because the master secrets on the client/server do not match.

But only in case we are actually resuming - no? Does the client always have a PAC available - I would guess not? Seems the legacy logic is such that it "happens to work", but I'd like to clear it up.
 
  It would be good to trigger an internal error to aid with troubleshooting.  Maybe something like:

        SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
        goto err;

It's debatable whether the alert needs to be sent to the server.  Since this is an internal error, it should be safe to send the alert.  Therefore, maybe you would actually want to do something like:

        SSLerr(SSL_F_SSL3_GET_SERVER_HELLO, ERR_R_INTERNAL_ERROR);
        al = SSL_AD_INTERNAL_ERROR;
        goto f_err;




On 03/23/2015 09:17 PM, Emilia Käsper wrote:


On Tue, Mar 24, 2015 at 1:20 AM, John Foley (foleyj) <[hidden email]> wrote:
We've found a way to recreate the scenario using s_client/s_server.  We're using the -no_ticket option on the server.  Therefore, the ServerHello doesn't contain the session ticket extension.  It also doesn't send the NewSessionTicket message.

To summarize the problem, when the client side is using SSL_set_session_secret_cb() and including a valid ticket in the ClintHello, then the logic in ssl3_get_server_hello() assumes the server is doing session resumption.  This puts the client-side state machine into the SSL3_ST_CR_FINISHED_A.  However, since the server side is configured to not do resumption via the -no_ticket option, the server continues with a normal handshake by sending the Certificate message.  The client aborts the handshake when it receives the Certificate message while in the SSL3_ST_CR_FINISHED_A state.


As Erik identified earlier in the thread, the cause of this appears to be the addition of setting s->hit in the following code:

    if (s->version >= TLS1_VERSION && s->tls_session_secret_cb) {
        SSL_CIPHER *pref_cipher = NULL;
        s->session->master_key_length = sizeof(s->session->master_key);
        if (s->tls_session_secret_cb(s, s->session->master_key,
                                     &s->session->master_key_length,
                                     NULL, &pref_cipher,
                                     s->tls_session_secret_cb_arg)) {
            s->session->cipher = pref_cipher ?
                pref_cipher : ssl_get_cipher_by_char(s, p + j);
            s->hit = 1;
        }
    }

Why does the client-side now assume the server is doing session resumption simply because the session secret callback facility is being used?

Because a developer (me) introduced a bug. With OpenSSL client behaviour, peeking ahead is only required for EAP-FAST. I got rid of the peeking while tightening up the ChangeCipherSpec handling and in the process, got it wrong for EAP-FAST. Anyway, apologies, I see the problem and am working on a patch.

While we're at it, you may be able to help me with the following question: how should the client handle callback failure? The old code (pre my refactoring which introduced the bug) did this

#ifndef OPENSSL_NO_TLSEXT
	/* check if we want to resume the session based on external pre-shared secret */
	if (s->version >= TLS1_VERSION && s->tls_session_secret_cb)
		{
		SSL_CIPHER *pref_cipher=NULL;
		s->session->master_key_length=sizeof(s->session->master_key);
		if (s->tls_session_secret_cb(s, s->session->master_key,
					     &s->session->master_key_length,
					     NULL, &pref_cipher,
					     s->tls_session_secret_cb_arg))
			{
			s->session->cipher = pref_cipher ?
				pref_cipher : ssl_get_cipher_by_char(s, p+j);
			}
		}
#endif /* OPENSSL_NO_TLSEXT */
This is surely wrong as it's just ignoring the failure?
Thanks,
Emilia
________________________________________
From: openssl-dev [[hidden email]] on behalf of Dr. Stephen Henson [[hidden email]]
Sent: Thursday, March 19, 2015 11:49 AM
To: [hidden email]
Subject: Re: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST

On Thu, Mar 19, 2015, Erik Tkal wrote:

>
> If I do not send a sessionID in the clientHello but do send a valid
> sessionTicket extension, the server goes straight to changeCipherSpec and
> the client generates an UnexpectedMessage alert.
>

Does the server send back an empty session ticket extension?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



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


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




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