TLS 1.3 PSK test server setup

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

TLS 1.3 PSK test server setup

Hubert Kario
How to start current master branch OpenSSL so that it will support static PSK
key exchange in TLS1.3?

with client running as:
openssl s_client -psk
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

I've tried:
openssl s_server -psk
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa -nocert

that produces
139823110240000:error:14201076:SSL routines:tls_choose_sigalg:no suitable
signature algorithm:ssl/t1_lib.c:2433:
and a handshake_failure alert sent to client

and I've also tried
openssl s_server -psk
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa -cert
cert.pem -key key.pem
(where cert and key pem are just self signed RSA cert and key)

that establishes a TLS1.3 connection, but the ServerHello does not include
pre_shared_key extension, just 43 (selected version) and 51 (key share), so
the PSK mode was not used

connecting with s_client -tls1_2 a PSK cipher is selected (DHE-PSK-AES256-GCM-
SHA384) and in TLS1.3 I see both the pre_shared_key extension and the
psk_key_exchange_modes extension in client hello, so I'm really confused why
it doesn't work.

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: TLS 1.3 PSK test server setup

Matt Caswell-2


On 14/02/18 19:39, Hubert Kario wrote:

> How to start current master branch OpenSSL so that it will support static PSK
> key exchange in TLS1.3?
>
> with client running as:
> openssl s_client -psk
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>
> I've tried:
> openssl s_server -psk
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa -nocert
>
> that produces
> 139823110240000:error:14201076:SSL routines:tls_choose_sigalg:no suitable
> signature algorithm:ssl/t1_lib.c:2433:
> and a handshake_failure alert sent to client
>
> and I've also tried
> openssl s_server -psk
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa -cert
> cert.pem -key key.pem
> (where cert and key pem are just self signed RSA cert and key)

For a PSK to be used in needs to be the correct length for the selected
ciphersuite. The ciphersuite is selected *first*. Next the available
PSKs are checked to see if they are usable with that ciphersuite.

By default s_client talking to s_server will select
TLS13-AES-256-GCM-SHA384. Because this is based on SHA384 we need a key
which is 48 bytes long (96 hex digits). Your key is 32 bytes long (64
hex digits) so the PSK is ignored.

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

Re: TLS 1.3 PSK test server setup

Matt Caswell-2


On 14/02/18 23:33, Viktor Dukhovni wrote:

>
>
>> On Feb 14, 2018, at 6:14 PM, Matt Caswell <[hidden email]> wrote:
>>
>> For a PSK to be used in needs to be the correct length for the selected
>> ciphersuite. The ciphersuite is selected *first*. Next the available
>> PSKs are checked to see if they are usable with that ciphersuite.
>
> Is that (choosing the cipher first) correct behaviour?  If the server
> is given a specific certificate it limits its ciphers to those that
> are compatible with the certificate's public key. It seems to me that
> "-psk" should not be different.  If we are doing PSK, we should likely
> filter the ciphers to those that work with the supplied PSK first.
>

As pointed out by Hubert in #5378 this is in accordance with the
recommendations in the spec:

   "Implementor's note: the most straightforward way to implement the
   PSK/cipher suite matching requirements is to negotiate the cipher
   suite first and then exclude any incompatible PSKs.  Any unknown PSKs
   (e.g., they are not in the PSK database or are encrypted with an
   unknown key) SHOULD simply be ignored.  If no acceptable PSKs are
   found, the server SHOULD perform a non-PSK handshake if possible."


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

Re: TLS 1.3 PSK test server setup

Matt Caswell-2


On 15/02/18 15:33, Viktor Dukhovni wrote:

>
>
>> On Feb 15, 2018, at 9:57 AM, Matt Caswell <[hidden email]> wrote:
>>
>> As pointed out by Hubert in #5378 this is in accordance with the
>> recommendations in the spec:
>>
>>   "Implementor's note: the most straightforward way to implement the
>>   PSK/cipher suite matching requirements is to negotiate the cipher
>>   suite first and then exclude any incompatible PSKs.  Any unknown PSKs
>>   (e.g., they are not in the PSK database or are encrypted with an
>>   unknown key) SHOULD simply be ignored.  If no acceptable PSKs are
>>   found, the server SHOULD perform a non-PSK handshake if possible."
>
> OK, it is "straightforward", but I am not sure it satisfies the
> principle of least surprise.  So I am asking you what you think
> users can reasonably expect...

TLSv1.3 PSKs are very different to TLSv1.2 PSKs. In TLSv1.3 they are
effectively the same thing as a session (they are indistinguishable on
the wire) - and are handled internally by the same logic. As with any
session the server may or may not choose to use it.

If we are talking about the "principle of least surprise" then I would
find it quite surprising if the server selected a non-preferred
ciphersuite when a mutually supported better one exists.

I suspect that most implementations will follow the advice above from
the spec, and again it would be quite surprising if we did something
different. Not only that it would add unnecessary complexity to the
logic in this area.

What is perhaps the source of any "surprise" that a user might
experience is that TLSv1.2 and TLSv1.3 share the same name for PSKs,
when really they are only related at a conceptual level: at an
implementation level they are totally different. Perhaps it would have
been better if they had been called something different. That is
slightly unfortunate - but not something we can do much about
(especially at this late stage).

I strongly feel this is the correct behaviour.

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

Re: TLS 1.3 PSK test server setup

Viktor Dukhovni


> On Feb 15, 2018, at 10:47 AM, Matt Caswell <[hidden email]> wrote:
>
> TLSv1.3 PSKs are very different to TLSv1.2 PSKs. In TLSv1.3 they are
> effectively the same thing as a session (they are indistinguishable on
> the wire) - and are handled internally by the same logic. As with any
> session the server may or may not choose to use it.

My understanding was somewhat in the other directions, in TLS 1.3 sessions
resumption was reimplemented as a PSK, simplifying the protocol, but this
does not mean that *all* PSKs are ephemeral sessions to be optionally
resumed.  Are there not PSKs that are long-term shared keys?

Do we provide a means to specify one of those and have it be used in
preference to (or to the exclusion of) all other handshake variants?

> If we are talking about the "principle of least surprise" then I would
> find it quite surprising if the server selected a non-preferred
> ciphersuite when a mutually supported better one exists.

Sure, with session resumption, but if a user expects to use a PSK with
some server for mutual authentication via a shared long-term secret, I
would be as surprised if it were not used.

Perhaps the technical similarity of session resumption with PSKs is
contrary to user intent.  The below are not the same:

        * A previously established resumable session
        * A long-term shared key PSK "established out of band"

Note also that perhaps you're thinking primarily about the server,
to which the RFC implementation note applies:

   Implementor's note: the most straightforward way to implement the
   PSK/cipher suite matching requirements is to negotiate the cipher
   suite first and then exclude any incompatible PSKs.  Any unknown PSKs
   (e.g., they are not in the PSK database or are encrypted with an
   unknown key) SHOULD simply be ignored.  If no acceptable PSKs are
   found, the server SHOULD perform a non-PSK handshake if possible.

But my concern is whether a client that specifies intentional use of
an out-of-band shared-key PSK will get its expected behaviour.

--
        Viktor.

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

Re: TLS 1.3 PSK test server setup

Matt Caswell-2


On 15/02/18 16:38, Viktor Dukhovni wrote:

>
>
>> On Feb 15, 2018, at 10:47 AM, Matt Caswell <[hidden email]> wrote:
>>
>> TLSv1.3 PSKs are very different to TLSv1.2 PSKs. In TLSv1.3 they are
>> effectively the same thing as a session (they are indistinguishable on
>> the wire) - and are handled internally by the same logic. As with any
>> session the server may or may not choose to use it.
>
> My understanding was somewhat in the other directions, in TLS 1.3 sessions
> resumption was reimplemented as a PSK, simplifying the protocol, but this
> does not mean that *all* PSKs are ephemeral sessions to be optionally
> resumed.  Are there not PSKs that are long-term shared keys?
>
> Do we provide a means to specify one of those and have it be used in
> preference to (or to the exclusion of) all other handshake variants?

Yes, this is of course possible. Just make sure any PSKs you have
available on the server are consistent with the hash function in your
preferred ciphersuites. If you don't want a non-long term key selected
then don't prefer a ciphersuite that is incompatible with it. If you
never want the possibility of a non-long term key being used then don't
configure a Certificate on your server.

>
>> If we are talking about the "principle of least surprise" then I would
>> find it quite surprising if the server selected a non-preferred
>> ciphersuite when a mutually supported better one exists.
>
> Sure, with session resumption, but if a user expects to use a PSK with
> some server for mutual authentication via a shared long-term secret, I
> would be as surprised if it were not used.
>
> Perhaps the technical similarity of session resumption with PSKs is
> contrary to user intent.  The below are not the same:
>
> * A previously established resumable session
> * A long-term shared key PSK "established out of band"
>
> Note also that perhaps you're thinking primarily about the server,
> to which the RFC implementation note applies:
>
>    Implementor's note: the most straightforward way to implement the
>    PSK/cipher suite matching requirements is to negotiate the cipher
>    suite first and then exclude any incompatible PSKs.  Any unknown PSKs
>    (e.g., they are not in the PSK database or are encrypted with an
>    unknown key) SHOULD simply be ignored.  If no acceptable PSKs are
>    found, the server SHOULD perform a non-PSK handshake if possible.
>
> But my concern is whether a client that specifies intentional use of
> an out-of-band shared-key PSK will get its expected behaviour.
>

A client can "encourage" the server to select a PSK if it only offers
ciphersuites that are compatible with it. If the server is OpenSSL and
has the PSK available it will use it (because all shared ciphersuites
will be compatible with it).

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

Re: TLS 1.3 PSK test server setup

Hubert Kario
In reply to this post by Matt Caswell-2
On Thursday, 15 February 2018 16:47:33 CET Matt Caswell wrote:

> On 15/02/18 15:33, Viktor Dukhovni wrote:
> >> On Feb 15, 2018, at 9:57 AM, Matt Caswell <[hidden email]> wrote:
> >>
> >> As pointed out by Hubert in #5378 this is in accordance with the
> >>
> >> recommendations in the spec:
> >>   "Implementor's note: the most straightforward way to implement the
> >>   PSK/cipher suite matching requirements is to negotiate the cipher
> >>   suite first and then exclude any incompatible PSKs.  Any unknown PSKs
> >>   (e.g., they are not in the PSK database or are encrypted with an
> >>   unknown key) SHOULD simply be ignored.  If no acceptable PSKs are
> >>   found, the server SHOULD perform a non-PSK handshake if possible."
> >
> > OK, it is "straightforward", but I am not sure it satisfies the
> > principle of least surprise.  So I am asking you what you think
> > users can reasonably expect...
>
> TLSv1.3 PSKs are very different to TLSv1.2 PSKs.
they're not, you have two values - identity and a secret. in TLS 1.2 identity
could be empty, in TLS 1.3 it can't be.

in TLS 1.3 _optionally_ the PSK can have a hash explicitly associated with the
secret. If a hash is not associated, the default sha-256  is used.

> In TLSv1.3 they are
> effectively the same thing as a session (they are indistinguishable on
> the wire)

that's not true - static PSKs are distinguished by the obfuscated_ticket_age
value being 0

> - and are handled internally by the same logic. As with any
> session the server may or may not choose to use it.

that's an implementation detail specific to OpenSSL, and I dare say, very
unexpected for a user

> If we are talking about the "principle of least surprise" then I would
> find it quite surprising if the server selected a non-preferred
> ciphersuite when a mutually supported better one exists.

except a server configured in version 1.1.0 to support just PSK will stop
working as soon as both client and server update to 1.1.1

I'd call that "surprising"

> I suspect that most implementations will follow the advice above from
> the spec, and again it would be quite surprising if we did something
> different. Not only that it would add unnecessary complexity to the
> logic in this area.

I've already talked with Nikos about situation in GnuTLS and it will support
PSKs transparently in TLS 1.2 and TLS 1.3, configurations won't break.
 
> What is perhaps the source of any "surprise" that a user might
> experience is that TLSv1.2 and TLSv1.3 share the same name for PSKs,
> when really they are only related at a conceptual level: at an
> implementation level they are totally different. Perhaps it would have
> been better if they had been called something different. That is
> slightly unfortunate - but not something we can do much about
> (especially at this late stage).

that's how you see it, and having just implemented support for them, I do not
agree
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

signature.asc (849 bytes) Download Attachment