State machine rewrite

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

State machine rewrite

Matt Caswell-2
I've just opened a github pull request to show recent work I have been
doing on rewriting the OpenSSL state machine (for version 1.1.0). See:
https://github.com/openssl/openssl/pull/394

My objectives for the rewrite were:

- Remove duplication of state code between client and server
- Remove duplication of state code between TLS and DTLS
- Simplify transitions and bring the logic together in a single location
so that it is easier to validate
- Remove duplication of code between each of the message handling functions
- Receive a message first and then work out whether that is a valid
transition - not the other way around (the other way causes lots of
issues where we are expecting one type of message next but actually get
something else)
- Separate message flow state from handshake state (in order to better
understand each)
  - message flow state = when to flush buffers; handling restarts in the
event of NBIO events; handling the common flow of steps for reading a
message and the common flow of steps for writing a message etc
  - handshake state = what handshake message are we working on now
- Control complexity: only the state machine can change state: keep all
the state changes local to the state machine component

The message flow state machine is divided into a reading sub-state
machine and a writing sub-state machine. See the source comments in
ssl/statem/statem.c for a more detailed description of the various
states and transitions possible. Also see ssl/statem/README for
additional info.

One issue is that the patch as it is currently removes support for
DTLSv1_listen. I have another patch to add that back in (in a completely
different way) - but it needs a bit more work yet.

I am interested in hearing any feedback you may have on the code
(ideally as comments in the pull request). I would also be keen to hear
of any problems you might encounter whilst using this code. You can
check it out from my github repo:
https://github.com/mattcaswell/openssl

See the state-machine-rewrite branch.

Thanks

Matt


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

Re: State machine rewrite

Salz, Rich

> I've just opened a github pull request to show recent work I have been doing
> on rewriting the OpenSSL state machine (for version 1.1.0). See:
> https://github.com/openssl/openssl/pull/394

Extended discussion should probably happen on openssl-dev, as conversations don't work too well on GitHub PR's.  Bsased on experience.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: State machine rewrite

John Foley-3
In reply to this post by Matt Caswell-2
+1

It's great to see improvements in the state machine along with
consolidated handlers for TLS/DTLS.  Having said that, have you
considered using a state transition table instead of long switch
statements to enforce the state transition rules?  This would improve
the maintainability of the code.  Here's a trivial example:

http://www.gedan.net/2008/09/08/finite-state-machine-matrix-style-c-implementation/



On 09/11/2015 10:34 AM, Matt Caswell wrote:

> I've just opened a github pull request to show recent work I have been
> doing on rewriting the OpenSSL state machine (for version 1.1.0). See:
> https://github.com/openssl/openssl/pull/394
>
> My objectives for the rewrite were:
>
> - Remove duplication of state code between client and server
> - Remove duplication of state code between TLS and DTLS
> - Simplify transitions and bring the logic together in a single location
> so that it is easier to validate
> - Remove duplication of code between each of the message handling functions
> - Receive a message first and then work out whether that is a valid
> transition - not the other way around (the other way causes lots of
> issues where we are expecting one type of message next but actually get
> something else)
> - Separate message flow state from handshake state (in order to better
> understand each)
>   - message flow state = when to flush buffers; handling restarts in the
> event of NBIO events; handling the common flow of steps for reading a
> message and the common flow of steps for writing a message etc
>   - handshake state = what handshake message are we working on now
> - Control complexity: only the state machine can change state: keep all
> the state changes local to the state machine component
>
> The message flow state machine is divided into a reading sub-state
> machine and a writing sub-state machine. See the source comments in
> ssl/statem/statem.c for a more detailed description of the various
> states and transitions possible. Also see ssl/statem/README for
> additional info.
>
> One issue is that the patch as it is currently removes support for
> DTLSv1_listen. I have another patch to add that back in (in a completely
> different way) - but it needs a bit more work yet.
>
> I am interested in hearing any feedback you may have on the code
> (ideally as comments in the pull request). I would also be keen to hear
> of any problems you might encounter whilst using this code. You can
> check it out from my github repo:
> https://github.com/mattcaswell/openssl
>
> See the state-machine-rewrite branch.
>
> Thanks
>
> Matt
>
>
> _______________________________________________
> 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: State machine rewrite

Daniel Kahn Gillmor
On Fri 2015-09-11 11:07:27 -0400, John Foley wrote:

> It's great to see improvements in the state machine along with
> consolidated handlers for TLS/DTLS.

Agreed.  Thanks for the work on this, Matt!

> Having said that, have you considered using a state transition table
> instead of long switch statements to enforce the state transition
> rules?  This would improve the maintainability of the code.  Here's a
> trivial example:
>
> http://www.gedan.net/2008/09/08/finite-state-machine-matrix-style-c-implementation/

I'm getting a 404 from this.  do you have another link?

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

Re: State machine rewrite

John Foley-3
Here's another trivial example if that URL still isn't working for you:  


On Sep 11, 2015, at 5:46 PM, Daniel Kahn Gillmor <[hidden email]> wrote:

On Fri 2015-09-11 11:07:27 -0400, John Foley wrote:

It's great to see improvements in the state machine along with
consolidated handlers for TLS/DTLS.

Agreed.  Thanks for the work on this, Matt!

Having said that, have you considered using a state transition table
instead of long switch statements to enforce the state transition
rules?  This would improve the maintainability of the code.  Here's a
trivial example:

http://www.gedan.net/2008/09/08/finite-state-machine-matrix-style-c-implementation/

I'm getting a 404 from this.  do you have another link?

   --dkg

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

Re: State machine rewrite

Matt Caswell-2
In reply to this post by John Foley-3


On 11/09/15 16:07, John Foley wrote:

> +1
>
> It's great to see improvements in the state machine along with
> consolidated handlers for TLS/DTLS.  Having said that, have you
> considered using a state transition table instead of long switch
> statements to enforce the state transition rules?  This would improve
> the maintainability of the code.  Here's a trivial example:
>
> http://www.gedan.net/2008/09/08/finite-state-machine-matrix-style-c-implementation/
>

Hi John,

That's a really good question that's going to need quite a long answer
(sorry!).

To summarise: the article states that any finite state machine can be
represented as a state transition table. The article shows such a table
with states along one axis, and events along the other. The contents of
each "cell" of the table are the new state to move to, and an action to
perform. The argument is that such an approach is easier to maintain
because changing the structure of the state machine does not change the
structure of the underlying code (you just change the table), whereas
traditional approaches do.

The article presents a very simplified table structure (for
understandable reasons). A real table approach (for SSL/TLS) would have
to be a bit more complicated than that. In particular the "events" we
are talking about here are the arrival of new messages (at least they
are when we are reading rather than writing). However we are working in
a security setting and we have to deal with the possibility of "illegal"
events. e.g. if you are server and the last message you read was
ClientKeyExchange and then you receive a ChangeCipherSpec - is that ok?
Well the answer is "it depends". Dependant on the preceding messages we
might need to have a CertificateVerify next. So transitions are actually
"guarded" - there is logic which determines whether a particular event
is "allowed" in the current scenario or not.

This is still fine from a table driven approach - it just means that the
contents of our "cells" have to include a transition guard entry as well.

The other thing to think about here is why is it that a table driven
approach is easier to maintain (assuming we accept the argument that it
is)? I would argue the reason is that each entry in the cells conforms
to a common interface. The logic that does all the hard work of moving
around that state machine can be generic, and all the state specific
work is contained within the functions implementing the individual cells
- which all have the same interface that the generic code can
understand. Therefore changing the state machine should not impact the
generic code - its just about changing the states/events/cells.

I would further argue that the mechanism that you use to implement the
table itself is fairly irrelevant - what is important is the generic
table "look up" code doing the work of moving around the state machine,
and the common interface to the state specific cells. The article
presents a fairly obvious table implementation: an array. In an array
based approach you first scan the "rows" of the table until you find
your current state, and then you scan the "columns" of the table until
you find the event. Now you've found the right cell.

This is not the only implementation approach however. You could
implement this in code directly:

switch(my_state) {
case state1:
        if (event1)
                cell_1_1_action();
        else if (event2)
                cell_1_2_action();
        else
                error();
        break;
case state2:
        if (event1)
                cell_2_1_action();
        else if (event2)
                cell_2_2_action();
        else
                error();
        break;
/* etc */
}

So why might you take this approach rather than an array based approach?
Well one reason is that if you have a lot of states and a lot of
possible events an array based approach ends up being quite large and
difficult to read...particularly if the table is quite sparsely
populated. In SSL/TLS (for reading messages) the current state will be
the last state that we read, and the event will be the arrival of the
next message. There are quite a large number of states (there are 37
entries in the HANSHAKE_STATE enum), so you're talking about a 37x37
array. That's going to get quite messy to maintain. Given that the table
is going to be sparsely populated I think the code based approach is
probably better. You could probably come up more complicated data driven
approaches that can cope with sparse data, but I reckon the code based
approach given above is equivalent, quite simple, and does the job
equally well.

There is another reason as well why the code based approach might be
preferable. I mentioned earlier about the necessity for transition
"guard" logic. This makes the code above look more like this:

switch(my_state) {
case state1:
        if (event1 && guard_1_1)
                cell_1_1_action();
        else if (event2 && guard_1_2)
                cell_1_2_action();
        else
                error();
        break;
case state2:
        if (event1 && guard_2_1)
                cell_2_1_action();
        else if (event2 && guard_2_2)
                cell_2_2_action();
        else
                error();
        break;
/* etc */
}

In an array based approach the guard logic would have to go into the
cell data. In practice this means that each guard would have to be a
function. That's going to see quite an explosion in the number of
functions required and will distribute the transition logic around the
code to wherever the functions are defined. In reality the guards are
often quite simple. There may be the odd occasion where the guards are
complicated enough to be functions, but more often than not you can just
inline the guards directly into the if statements. This has the
*significant* advantage that you can keep all the transition logic *in
one place*. This was actually one of my design goals for the whole
rewrite. The old state machine code has transition logic everywhere. Its
very difficult to reason about and verify its correctness. By keeping
everything together in one place the job of sanity checking that the
logic is correct is made much easier. I would also argue that code
maintenance is also much easier than having the logic distributed around
lots of different functions.

I have simplified things quite considerably. The whole thing is further
complicated by the need to handle non-blocking IO, and so the state
machine needs to be able to stop at any point, return control back to
the calling application in order to resume where it left off later. For
that reason (amongst others) the actual code implementation is slightly
more complicated than I have outlined. However I would argue that the
approach that has been taken is:
- still table driven (using a code based implementation approach)
- exhibits the core features of the table based approach: generic code
along with standard interfaces to the "cells" of the table
- benefits from the advantages of such an approach, i.e. code
maintainability

It's not an array based table which is what I think you were looking
for. But I think there are good reasons not to go down that path.

Matt


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

Re: State machine rewrite

Kurt Roeckx
On Sat, Sep 12, 2015 at 12:20:52AM +0100, Matt Caswell wrote:
> Dependant on the preceding messages we
> might need to have a CertificateVerify next. So transitions are actually
> "guarded" - there is logic which determines whether a particular event
> is "allowed" in the current scenario or not.

Does that just not mean you don't have all the states as real
states, but that you're combining 1 state with something like a
variable to determine between other states inside that state?

Please note that I'm not suggesting you turn everything into a
state.  You might end up with so much states that it gets more
complicated than it should, and that you'll end up duplicating
more code than you want.


Kurt

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

Re: State machine rewrite

Matt Caswell-2


On 12/09/15 11:22, Kurt Roeckx wrote:
> On Sat, Sep 12, 2015 at 12:20:52AM +0100, Matt Caswell wrote:
>> Dependant on the preceding messages we
>> might need to have a CertificateVerify next. So transitions are actually
>> "guarded" - there is logic which determines whether a particular event
>> is "allowed" in the current scenario or not.
>
> Does that just not mean you don't have all the states as real
> states, but that you're combining 1 state with something like a
> variable to determine between other states inside that state?

Yes, that is an excellent point and is indeed correct. I am "cheating" a
little by introducing guarded transitions. The implementation of these
guards inevitably goes off and inspects state that is held outside of
the state machine itself. The kind of state I'm talking about here are
things like the current ciphersuite; what extensions have been
sent/received; whether the client has sent a Certificate or not; etc. It
would of course be entirely possible to build a state machine which did
not rely on any of this external state - *all* of the state would be
locked into our current position within the state machine. For example,
this might mean that you need a different set of states and transitions
for handling (say) PSK ciphersuites to the set of states and transitions
that you need for other ciphersuites.

As you can imagine (and as you pointed out) this could lead to a real
explosion in the number of states that you need. There's more to it than
just that though. In the state machine as I have designed it the events
that trigger transitions are quite simple and the code can be generic
for handling them (at least for reading messages): an event is simply
the arrival of a message of a particular type. In this new extended
state machine that we are imagining where there are many more states,
the events are more complicated in order to distinguish between the many
more different transitions that we can now make. So for example in my
state machine an event might be "a ServerHello message has arrived",
whereas in the extended state machine the event might be "a ServerHello
with a PSK ciphersuite selected has arrived". This now means our event
detection logic is much more complicated - and is state specific. All we
have done is moved complexity out of the transition guards and into the
state machine structure *and* the event detection code.

On balance I think such an approach is not a good trade off. I much
prefer the simplicity of a one-to-one correspondence between messages
and states. Doing it the other way is much more likely to turn into a
code maintenance nightmare IMO.

Matt

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

Re: State machine rewrite

Matt Caswell-2
In reply to this post by Matt Caswell-2
Hi Karthik

Moving this to openssl-dev as per your suggestion. See my responses below.

On 13/09/15 11:18, Karthikeyan Bhargavan wrote:

> Matt,
>
> I’ve been looking through the code and before we begin testing it, my main question is:
> what protocol versions and ciphersuites are meant to be covered by this state machine?
>
> For example, did you intend for it to cover SSL2-TLS1.2? (Clearly, it does not cover TLS 1.3 yet).
> How about extensions like NPN? Did you intend for it to cover all PSK modes (PSK, RSA-PSK, DHE-PSK)? *_EXPORT_*?
>
> Having a succinct list of versions, extensions, and ciphersuites that are meant to be covered would
> be good documentation and quite useful.
>
> Best,
> Karthik
>

The state-machine-rewrite branch covers all the same ciphersuites,
protocol versions and extensions that the main master branch covers.
Obviously it depends on compile time and run time configuration options
as to exactly which ones you get at any one time. However the full list
of all those available are as follows.

For protocol versions we support:
SSLv3
TLS1.0
TLS1.1
TLS1.2
DTLS1.0
DTLS1.2

Note that SSLv2 support has been completely removed from master (and my
state-machine-rewrite branch). I'm not sure if your testing tools can
cope with DTLS or not, but nonetheless we support it.

The extensions we support are:

# define TLSEXT_TYPE_server_name                 0
# define TLSEXT_TYPE_status_request              5
# define TLSEXT_TYPE_elliptic_curves             10
# define TLSEXT_TYPE_ec_point_formats            11
# define TLSEXT_TYPE_srp                         12
# define TLSEXT_TYPE_signature_algorithms        13
# define TLSEXT_TYPE_use_srtp    14
# define TLSEXT_TYPE_heartbeat   15
# define TLSEXT_TYPE_application_layer_protocol_negotiation 16
# define TLSEXT_TYPE_padding     21
# define TLSEXT_TYPE_encrypt_then_mac    22
# define TLSEXT_TYPE_extended_master_secret      23
# define TLSEXT_TYPE_session_ticket              35
# define TLSEXT_TYPE_renegotiate                 0xff01
#  define TLSEXT_TYPE_next_proto_neg              13172

Note "use srtp" above is a DTLS only extension.

For ciphersuites we support:

$ ./openssl ciphers -v ALL
ECDHE-ECDSA-AES256-CCM8 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM8(256)
Mac=AEAD
ECDHE-ECDSA-AES256-CCM  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM(256)
Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256)
Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA
Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)
Mac=SHA384
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
DHE-PSK-AES256-CCM8     TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESCCM8(256)
Mac=AEAD
DHE-PSK-AES256-CCM      TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESCCM(256) Mac=AEAD
DHE-RSA-AES256-CCM8     TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM8(256)
Mac=AEAD
DHE-RSA-AES256-CCM      TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM(256) Mac=AEAD
ECDHE-PSK-AES256-CBC-SHA384 SSLv3 Kx=ECDHEPSK Au=PSK  Enc=AES(256)
Mac=SHA384
ECDHE-PSK-AES256-CBC-SHA SSLv3 Kx=ECDHEPSK Au=PSK  Enc=AES(256)  Mac=SHA1
SRP-DSS-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=AES(256)  Mac=SHA1
SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(256)  Mac=SHA1
SRP-AES-256-CBC-SHA     SSLv3 Kx=SRP      Au=SRP  Enc=AES(256)  Mac=SHA1
RSA-PSK-AES256-CBC-SHA384 SSLv3 Kx=RSAPSK   Au=RSA  Enc=AES(256)  Mac=SHA384
DHE-PSK-AES256-CBC-SHA384 SSLv3 Kx=DHEPSK   Au=PSK  Enc=AES(256)  Mac=SHA384
RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=AESGCM(256)
Mac=AEAD
DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESGCM(256)
Mac=AEAD
DH-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AESGCM(256)
Mac=AEAD
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256)
Mac=AEAD
DH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256)
Mac=AEAD
RSA-PSK-AES256-CBC-SHA  SSLv3 Kx=RSAPSK   Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-PSK-AES256-CBC-SHA  SSLv3 Kx=DHEPSK   Au=PSK  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256
DH-RSA-AES256-SHA256    TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AES(256)  Mac=SHA256
DH-DSS-AES256-SHA256    TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AES(256)  Mac=SHA256
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
DH-RSA-AES256-SHA       SSLv3 Kx=DH/RSA   Au=DH   Enc=AES(256)  Mac=SHA1
DH-DSS-AES256-SHA       SSLv3 Kx=DH/DSS   Au=DH   Enc=AES(256)  Mac=SHA1
ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA
Enc=Camellia(256) Mac=SHA384
ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA
Enc=Camellia(256) Mac=SHA384
ECDHE-PSK-CAMELLIA256-SHA384 SSLv3 Kx=ECDHEPSK Au=PSK  Enc=Camellia(256)
Mac=SHA384
RSA-PSK-CAMELLIA256-SHA384 SSLv3 Kx=RSAPSK   Au=RSA  Enc=Camellia(256)
Mac=SHA384
DHE-PSK-CAMELLIA256-SHA384 SSLv3 Kx=DHEPSK   Au=PSK  Enc=Camellia(256)
Mac=SHA384
DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=Camellia(256)
Mac=SHA256
DHE-DSS-CAMELLIA256-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=Camellia(256)
Mac=SHA256
DH-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH/RSA   Au=DH   Enc=Camellia(256)
Mac=SHA256
DH-DSS-CAMELLIA256-SHA256 TLSv1.2 Kx=DH/DSS   Au=DH   Enc=Camellia(256)
Mac=SHA256
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(256) Mac=SHA1
DH-RSA-CAMELLIA256-SHA  SSLv3 Kx=DH/RSA   Au=DH   Enc=Camellia(256) Mac=SHA1
DH-DSS-CAMELLIA256-SHA  SSLv3 Kx=DH/DSS   Au=DH   Enc=Camellia(256) Mac=SHA1
AECDH-AES256-SHA        SSLv3 Kx=ECDH     Au=None Enc=AES(256)  Mac=SHA1
ADH-AES256-GCM-SHA384   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(256) Mac=AEAD
ADH-AES256-SHA256       TLSv1.2 Kx=DH       Au=None Enc=AES(256)  Mac=SHA256
ADH-AES256-SHA          SSLv3 Kx=DH       Au=None Enc=AES(256)  Mac=SHA1
ADH-CAMELLIA256-SHA256  TLSv1.2 Kx=DH       Au=None Enc=Camellia(256)
Mac=SHA256
ADH-CAMELLIA256-SHA     SSLv3 Kx=DH       Au=None Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256)
Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH
Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)
Mac=SHA384
ECDH-RSA-AES256-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA1
ECDH-ECDSA-AES256-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA1
ECDH-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH
Enc=Camellia(256) Mac=SHA384
ECDH-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH
Enc=Camellia(256) Mac=SHA384
AES256-CCM8             TLSv1.2 Kx=RSA      Au=RSA  Enc=AESCCM8(256)
Mac=AEAD
AES256-CCM              TLSv1.2 Kx=RSA      Au=RSA  Enc=AESCCM(256) Mac=AEAD
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
CAMELLIA256-SHA256      TLSv1.2 Kx=RSA      Au=RSA  Enc=Camellia(256)
Mac=SHA256
CAMELLIA256-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(256) Mac=SHA1
PSK-AES256-CCM8         TLSv1.2 Kx=PSK      Au=PSK  Enc=AESCCM8(256)
Mac=AEAD
PSK-AES256-CCM          TLSv1.2 Kx=PSK      Au=PSK  Enc=AESCCM(256) Mac=AEAD
PSK-AES256-CBC-SHA384   SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA384
PSK-AES256-GCM-SHA384   TLSv1.2 Kx=PSK      Au=PSK  Enc=AESGCM(256) Mac=AEAD
PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
PSK-CAMELLIA256-SHA384  SSLv3 Kx=PSK      Au=PSK  Enc=Camellia(256)
Mac=SHA384
ECDHE-ECDSA-AES128-CCM8 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM8(128)
Mac=AEAD
ECDHE-ECDSA-AES128-CCM  TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESCCM(128)
Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128)
Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA
Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)
Mac=SHA256
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
DHE-PSK-AES128-CCM8     TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESCCM8(128)
Mac=AEAD
DHE-PSK-AES128-CCM      TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESCCM(128) Mac=AEAD
DHE-RSA-AES128-CCM8     TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM8(128)
Mac=AEAD
DHE-RSA-AES128-CCM      TLSv1.2 Kx=DH       Au=RSA  Enc=AESCCM(128) Mac=AEAD
ECDHE-PSK-AES128-CBC-SHA256 SSLv3 Kx=ECDHEPSK Au=PSK  Enc=AES(128)
Mac=SHA256
ECDHE-PSK-AES128-CBC-SHA SSLv3 Kx=ECDHEPSK Au=PSK  Enc=AES(128)  Mac=SHA1
SRP-DSS-AES-128-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=AES(128)  Mac=SHA1
SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(128)  Mac=SHA1
SRP-AES-128-CBC-SHA     SSLv3 Kx=SRP      Au=SRP  Enc=AES(128)  Mac=SHA1
RSA-PSK-AES128-CBC-SHA256 SSLv3 Kx=RSAPSK   Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-PSK-AES128-CBC-SHA256 SSLv3 Kx=DHEPSK   Au=PSK  Enc=AES(128)  Mac=SHA256
RSA-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=AESGCM(128)
Mac=AEAD
DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESGCM(128)
Mac=AEAD
DH-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AESGCM(128)
Mac=AEAD
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(128)
Mac=AEAD
DH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128)
Mac=AEAD
RSA-PSK-AES128-CBC-SHA  SSLv3 Kx=RSAPSK   Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-PSK-AES128-CBC-SHA  SSLv3 Kx=DHEPSK   Au=PSK  Enc=AES(128)  Mac=SHA1
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA256
DH-RSA-AES128-SHA256    TLSv1.2 Kx=DH/RSA   Au=DH   Enc=AES(128)  Mac=SHA256
DH-DSS-AES128-SHA256    TLSv1.2 Kx=DH/DSS   Au=DH   Enc=AES(128)  Mac=SHA256
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
DH-RSA-AES128-SHA       SSLv3 Kx=DH/RSA   Au=DH   Enc=AES(128)  Mac=SHA1
DH-DSS-AES128-SHA       SSLv3 Kx=DH/DSS   Au=DH   Enc=AES(128)  Mac=SHA1
ECDHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA
Enc=Camellia(128) Mac=SHA256
ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA
Enc=Camellia(128) Mac=SHA256
ECDHE-PSK-CAMELLIA128-SHA256 SSLv3 Kx=ECDHEPSK Au=PSK  Enc=Camellia(128)
Mac=SHA256
RSA-PSK-CAMELLIA128-SHA256 SSLv3 Kx=RSAPSK   Au=RSA  Enc=Camellia(128)
Mac=SHA256
DHE-PSK-CAMELLIA128-SHA256 SSLv3 Kx=DHEPSK   Au=PSK  Enc=Camellia(128)
Mac=SHA256
DHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=Camellia(128)
Mac=SHA256
DHE-DSS-CAMELLIA128-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=Camellia(128)
Mac=SHA256
DH-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=DH/RSA   Au=DH   Enc=Camellia(128)
Mac=SHA256
DH-DSS-CAMELLIA128-SHA256 TLSv1.2 Kx=DH/DSS   Au=DH   Enc=Camellia(128)
Mac=SHA256
DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
DH-RSA-SEED-SHA         SSLv3 Kx=DH/RSA   Au=DH   Enc=SEED(128) Mac=SHA1
DH-DSS-SEED-SHA         SSLv3 Kx=DH/DSS   Au=DH   Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(128) Mac=SHA1
DH-RSA-CAMELLIA128-SHA  SSLv3 Kx=DH/RSA   Au=DH   Enc=Camellia(128) Mac=SHA1
DH-DSS-CAMELLIA128-SHA  SSLv3 Kx=DH/DSS   Au=DH   Enc=Camellia(128) Mac=SHA1
AECDH-AES128-SHA        SSLv3 Kx=ECDH     Au=None Enc=AES(128)  Mac=SHA1
ADH-AES128-GCM-SHA256   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(128) Mac=AEAD
ADH-AES128-SHA256       TLSv1.2 Kx=DH       Au=None Enc=AES(128)  Mac=SHA256
ADH-AES128-SHA          SSLv3 Kx=DH       Au=None Enc=AES(128)  Mac=SHA1
ADH-CAMELLIA128-SHA256  TLSv1.2 Kx=DH       Au=None Enc=Camellia(128)
Mac=SHA256
ADH-SEED-SHA            SSLv3 Kx=DH       Au=None Enc=SEED(128) Mac=SHA1
ADH-CAMELLIA128-SHA     SSLv3 Kx=DH       Au=None Enc=Camellia(128) Mac=SHA1
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128)
Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH
Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-SHA256  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)
Mac=SHA256
ECDH-RSA-AES128-SHA     SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-ECDSA-AES128-SHA   SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA1
ECDH-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH
Enc=Camellia(128) Mac=SHA256
ECDH-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH
Enc=Camellia(128) Mac=SHA256
AES128-CCM8             TLSv1.2 Kx=RSA      Au=RSA  Enc=AESCCM8(128)
Mac=AEAD
AES128-CCM              TLSv1.2 Kx=RSA      Au=RSA  Enc=AESCCM(128) Mac=AEAD
AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
CAMELLIA128-SHA256      TLSv1.2 Kx=RSA      Au=RSA  Enc=Camellia(128)
Mac=SHA256
SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
CAMELLIA128-SHA         SSLv3 Kx=RSA      Au=RSA  Enc=Camellia(128) Mac=SHA1
IDEA-CBC-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=SHA1
PSK-AES128-CCM8         TLSv1.2 Kx=PSK      Au=PSK  Enc=AESCCM8(128)
Mac=AEAD
PSK-AES128-CCM          TLSv1.2 Kx=PSK      Au=PSK  Enc=AESCCM(128) Mac=AEAD
PSK-AES128-CBC-SHA256   SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA256
PSK-AES128-GCM-SHA256   TLSv1.2 Kx=PSK      Au=PSK  Enc=AESGCM(128) Mac=AEAD
PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1
PSK-CAMELLIA128-SHA256  SSLv3 Kx=PSK      Au=PSK  Enc=Camellia(128)
Mac=SHA256
ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
ECDHE-PSK-RC4-SHA       SSLv3 Kx=ECDHEPSK Au=PSK  Enc=RC4(128)  Mac=SHA1
RSA-PSK-RC4-SHA         SSLv3 Kx=RSAPSK   Au=RSA  Enc=RC4(128)  Mac=SHA1
DHE-PSK-RC4-SHA         SSLv3 Kx=DHEPSK   Au=PSK  Enc=RC4(128)  Mac=SHA1
AECDH-RC4-SHA           SSLv3 Kx=ECDH     Au=None Enc=RC4(128)  Mac=SHA1
ADH-RC4-MD5             SSLv3 Kx=DH       Au=None Enc=RC4(128)  Mac=MD5
ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
ECDHE-PSK-3DES-EDE-CBC-SHA SSLv3 Kx=ECDHEPSK Au=PSK  Enc=3DES(168) Mac=SHA1
SRP-DSS-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=3DES(168) Mac=SHA1
SRP-RSA-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=3DES(168) Mac=SHA1
SRP-3DES-EDE-CBC-SHA    SSLv3 Kx=SRP      Au=SRP  Enc=3DES(168) Mac=SHA1
RSA-PSK-3DES-EDE-CBC-SHA SSLv3 Kx=RSAPSK   Au=RSA  Enc=3DES(168) Mac=SHA1
DHE-PSK-3DES-EDE-CBC-SHA SSLv3 Kx=DHEPSK   Au=PSK  Enc=3DES(168) Mac=SHA1
DHE-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
DHE-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
DH-RSA-DES-CBC3-SHA     SSLv3 Kx=DH/RSA   Au=DH   Enc=3DES(168) Mac=SHA1
DH-DSS-DES-CBC3-SHA     SSLv3 Kx=DH/DSS   Au=DH   Enc=3DES(168) Mac=SHA1
AECDH-DES-CBC3-SHA      SSLv3 Kx=ECDH     Au=None Enc=3DES(168) Mac=SHA1
ADH-DES-CBC3-SHA        SSLv3 Kx=DH       Au=None Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
PSK-3DES-EDE-CBC-SHA    SSLv3 Kx=PSK      Au=PSK  Enc=3DES(168) Mac=SHA1
DHE-RSA-DES-CBC-SHA     SSLv3 Kx=DH       Au=RSA  Enc=DES(56)   Mac=SHA1
DHE-DSS-DES-CBC-SHA     SSLv3 Kx=DH       Au=DSS  Enc=DES(56)   Mac=SHA1
DH-RSA-DES-CBC-SHA      SSLv3 Kx=DH/RSA   Au=DH   Enc=DES(56)   Mac=SHA1
DH-DSS-DES-CBC-SHA      SSLv3 Kx=DH/DSS   Au=DH   Enc=DES(56)   Mac=SHA1
ADH-DES-CBC-SHA         SSLv3 Kx=DH       Au=None Enc=DES(56)   Mac=SHA1
DES-CBC-SHA             SSLv3 Kx=RSA      Au=RSA  Enc=DES(56)   Mac=SHA1
EXP-DHE-RSA-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=RSA  Enc=DES(40)   Mac=SHA1
export
EXP-DHE-DSS-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=DSS  Enc=DES(40)   Mac=SHA1
export
EXP-ADH-DES-CBC-SHA     SSLv3 Kx=DH(512)  Au=None Enc=DES(40)   Mac=SHA1
export
EXP-DES-CBC-SHA         SSLv3 Kx=RSA(512) Au=RSA  Enc=DES(40)   Mac=SHA1
export
EXP-RC2-CBC-MD5         SSLv3 Kx=RSA(512) Au=RSA  Enc=RC2(40)   Mac=MD5
 export
EXP-ADH-RC4-MD5         SSLv3 Kx=DH(512)  Au=None Enc=RC4(40)   Mac=MD5
 export
EXP-RC4-MD5             SSLv3 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5
 export


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

Re: State machine rewrite

Matt Caswell-2
In reply to this post by Matt Caswell-2


On 14/09/15 11:27, Karthikeyan Bhargavan wrote:
> [Could you forward to openssl-dev? I don’t seem to have permissions to post over there :(]

You need to be subscribed with the same email address that you are
posting from otherwise your posts will be rejected.

openssl-dev:  email from Karthik below along with my response.

>
> From a superficial look at the new state machine code, it seems to be missing a few boolean conditions.
>
> E.g. in statem_clnt.c after receiving a server CERTIFICATE, the client uses the function key_exchange_skip_allowed
> to check whether the next message must be a SERVER_KEY_EXCHANGE or not.
> In particular, if the kex is DHE or ECDHE, skipping SKE is allowed, otherwise not.
>
> However, this means that
> (a) If the kex is RSA or PSK, the peer is still allowed to send SKE
> (b) if the kex is RSA_EXPORT, the peer is allowed to skip SKE
>
> Do I have this right?
>
> I will continue my code inspection before trying to set automated tests for this state machnine
>
> Best,
> Karthik
>

Hmmm. There does seem to be a couple of problems here.

1) The logic around skipping SKE has changed very recently in master due
to the introduction of new PSK ciphersuites. I think there is a merge
error in reflecting these changes in the state-machine-rewrite branch.
In particular I think the condition in key_exchange_skip_allowed should
read:

    if (alg_k & (SSL_kDHE | SSL_kECDHE | SSL_kDHEPSK | SSL_kECDHEPSK)) {
        return 0;
    }

In other words there are more ephemeral ciphersuites that must not skip SKE.

2) In tls_process_key_exchange there is a check to ensure that if an SKE
has been sent for an RSA ciphersuite then it must be an export
ciphersuite. This is inherited from the existing master code. However
that check (whilst technically correct) is inconsistent with how the new
state machine code works. It should be moved into
key_exchange_skip_allowed. Similarly for checking non export RSA
ciphersuites.

I think it is correct that if PSK is selected that an SKE is allowed
since this can contain the identity hint.

I will add a new commit to address the above issues.

Matt



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

Re: State machine rewrite

Matt Caswell-2


On 14/09/15 13:27, Matt Caswell wrote:

> Hmmm. There does seem to be a couple of problems here.
>
> 1) The logic around skipping SKE has changed very recently in master due
> to the introduction of new PSK ciphersuites. I think there is a merge
> error in reflecting these changes in the state-machine-rewrite branch.
> In particular I think the condition in key_exchange_skip_allowed should
> read:
>
>     if (alg_k & (SSL_kDHE | SSL_kECDHE | SSL_kDHEPSK | SSL_kECDHEPSK)) {
>         return 0;
>     }
>
> In other words there are more ephemeral ciphersuites that must not skip SKE.
>
> 2) In tls_process_key_exchange there is a check to ensure that if an SKE
> has been sent for an RSA ciphersuite then it must be an export
> ciphersuite. This is inherited from the existing master code. However
> that check (whilst technically correct) is inconsistent with how the new
> state machine code works. It should be moved into
> key_exchange_skip_allowed. Similarly for checking non export RSA
> ciphersuites.
>
> I think it is correct that if PSK is selected that an SKE is allowed
> since this can contain the identity hint.
>
> I will add a new commit to address the above issues.

Right - new commit added. So hopefully this covers the following logic:

An SKE is required if:
- The ciphersuite is DHE, ECDHE, DHEPSK, ECDHEPSK or SRP based
- We have an export ciphersuite (must be RSA) and the key length in the
server certificate is greater than the maximum allowed.

An SKE is optional if:
- The ciphersuite is any PSK ciphersuite where the SKE is not mandatory

An SKE must not be sent:
- In any other circumstance

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

Re: State machine rewrite

Hubert Kario
In reply to this post by Matt Caswell-2
On Friday 11 September 2015 15:34:15 Matt Caswell wrote:
> I've just opened a github pull request to show recent work I have been
> doing on rewriting the OpenSSL state machine (for version 1.1.0).
> See: https://github.com/openssl/openssl/pull/394
>
> My objectives for the rewrite were:
> - Separate message flow state from handshake state (in order to better
> understand each)

Unfortunately, it doesn't look like the rewrite fixed
https://rt.openssl.org/Ticket/Display.html?id=3712&user=guest&pass=guest

I can still reproduce the issue:

openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt\
-nodes -batch
~/dev/openssl/apps/openssl s_server -key localhost.key -cert\
localhost.crt

pip install --pre tlslite-ng
git clone https://github.com/tomato42/tlsfuzzer.git

cd tlsfuzzer
PYTHONPATH=. python scripts/test-openssl-3712.py

The client reports Broken pipe

While the server reports:
140584857466520:error:140940F5:SSL routines:ssl3_read_bytes:unexpected
record:record/rec_layer_s3.c:1458:
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment