[gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

Tim Kosse-2
Hi,

I've recently been made aware of a problem [1][2] connecting the
FileZilla FTP client (linked against GnuTLS 3.5.13) to a recent ProFTPD
server (linked against OpenSSL). To prevent data connection theft, FTP
over TLS has to rely [3] on TLS session resumption for the data connection.

If using a certificate that has the status_request tlsfeatures X.509
certificate extension [4] ("OCSP must staple"), any handshakes using TLS
session resumption fail with GNUTLS_CERT_MISSING_OCSP_STATUS.

Unfortunately it looks like an oversight of RFC7633, it does not specify
how must-staple interacts with resumed session.

I'm not quite sure who who's at fault here and where to implement a fix:
GnuTLS or OpenSSL/ProFTPD?

Regarding GnuTLS: If using a resumed session, assuming the program using
GnuTLS did not deliberately ignore verification errors on the initial
handshake, we know that the initial session already had a properly
stapled OCSP response. Would it be feasible to just ignore a missing
OCSP response in resumed sessions?


Regarding the latter: Do the TLS specifications allow for a
CertificateStatus handshake packet to be sent in a resumed session? If
so, I think this issue is something TJ needs to investigate further in
ProFTPD, possibly escalating it as OpenSSL bug.

Regards,
Tim

[1] https://forum.filezilla-project.org/viewtopic.php?t=45684
[2] https://forums.proftpd.org/smf/index.php/topic,12187.0/all.html
[3] https://forum.filezilla-project.org/viewtopic.php?p=137191#p137191
[4] https://tools.ietf.org/html/rfc7633

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

Tim Kosse-2
Hi TJ,

On 27.06.2017 08:37, TJ Saunders wrote:
> Not all FTP servers require session resumption for their data
> connections, so to be thorough, I assume FileZilla would want to ensure
> that the TLS session for the data connection was indeed resumed, before
> going on to ignore a missing OCSP response for that resumed TLS session?

Correct, ignoring the missing OCSP response on a non-resumed session
would be a really bad idea.

> There *is* a ProFTPD (or rather, an OpenSSL) bug, for which I've filed
> this ticket:
>
>   https://github.com/proftpd/proftpd/issues/528
>
> The above specifically cites text from RFC 6066, which covers dealing
> with TLS extensions and resumed sessions.  That text, fortunately,
> covers the case of the "status_request" extension; it does not, sadly,
> also cover the case of the "must-staple" X509v3 extension.

Thanks for linking this issue.

I'm not sure your conclusion to not staple the OCSP response is quite
correct, note RFC 6606 saying "In this case, the
functionality of these extensions negotiated during the original
session initiation is applied to the resumed session."

The way I understand it, the server, even though replying with empty
extensions on server hello, must otherwise behave as if the extensions
were initially negotiated and thus the CertficateStatus handshake packet
should be sent.

Regards,
Tim


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

TJ Saunders

> I'm not sure your conclusion to not staple the OCSP response is quite
> correct, note RFC 6606 saying "In this case, the
> functionality of these extensions negotiated during the original
> session initiation is applied to the resumed session."
>
> The way I understand it, the server, even though replying with empty
> extensions on server hello, must otherwise behave as if the extensions
> were initially negotiated and thus the CertficateStatus handshake packet
> should be sent.

My understanding is based on this sentence in that section 1.1 portion
of RFC 6066:

  "If, on the other hand, the older session is resumed, then the server
   MUST ignore the extensions and send a server hello containing none of
   the extension types."

To me, this means that if the session is resumed, then the extensions
_in the ClientHello_ (including the status_request extension) are to be
ignored.  And if that client-sent extension is ignored, then this text,
from Section 8, becomes relevant, I think:

  "Note in addition that a server MUST NOT send the "CertificateStatus"
   message unless it received a "status_request" extension in the client
   hello message and sent a "status_request" extension in the server
   hello message.

If the "status_request" extension in the ClientHello is to be ignored
for resumed sessions, and we should send a ServerHello with none of the
extensions, then we cannot send a stapled OCSP response.

Cheers,
TJ

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

Ander Juaristi


On 27/06/17 09:05, TJ Saunders wrote:

>
>> I'm not sure your conclusion to not staple the OCSP response is quite
>> correct, note RFC 6606 saying "In this case, the
>> functionality of these extensions negotiated during the original
>> session initiation is applied to the resumed session."
>>
>> The way I understand it, the server, even though replying with empty
>> extensions on server hello, must otherwise behave as if the extensions
>> were initially negotiated and thus the CertficateStatus handshake packet
>> should be sent.
>
> My understanding is based on this sentence in that section 1.1 portion
> of RFC 6066:
>
>   "If, on the other hand, the older session is resumed, then the server
>    MUST ignore the extensions and send a server hello containing none of
>    the extension types."
>
> To me, this means that if the session is resumed, then the extensions
> _in the ClientHello_ (including the status_request extension) are to be
> ignored.  And if that client-sent extension is ignored, then this text,
> from Section 8, becomes relevant, I think:
>
>   "Note in addition that a server MUST NOT send the "CertificateStatus"
>    message unless it received a "status_request" extension in the client
>    hello message and sent a "status_request" extension in the server
>    hello message.
>
> If the "status_request" extension in the ClientHello is to be ignored
> for resumed sessions, and we should send a ServerHello with none of the
> extensions, then we cannot send a stapled OCSP response.
>

If things are this way then (and I understand this might not be a
GnuTLS-specific issue, but just popped out from my head), what happens if the
certificate has been revoked in the time span between the initial session
establishment and the later resumption?

The client can check that by sending a "normal" OCSP status request, but would
lose the benefit of stapled OCSP?

> Cheers,
> TJ
>
> _______________________________________________
> Gnutls-devel mailing list
> [hidden email]
> http://lists.gnupg.org/mailman/listinfo/gnutls-devel
>

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

Stefan Bühler
In reply to this post by TJ Saunders
Hi,

On 06/27/2017 09:05 AM, TJ Saunders wrote:

>
>> I'm not sure your conclusion to not staple the OCSP response is quite
>> correct, note RFC 6606 saying "In this case, the
>> functionality of these extensions negotiated during the original
>> session initiation is applied to the resumed session."
>>
>> The way I understand it, the server, even though replying with empty
>> extensions on server hello, must otherwise behave as if the extensions
>> were initially negotiated and thus the CertficateStatus handshake packet
>> should be sent.
>
> My understanding is based on this sentence in that section 1.1 portion
> of RFC 6066:
>
>   "If, on the other hand, the older session is resumed, then the server
>    MUST ignore the extensions and send a server hello containing none of
>    the extension types."
>
> To me, this means that if the session is resumed, then the extensions
> _in the ClientHello_ (including the status_request extension) are to be
> ignored.  And if that client-sent extension is ignored, then this text,
> from Section 8, becomes relevant, I think:
>
>   "Note in addition that a server MUST NOT send the "CertificateStatus"
>    message unless it received a "status_request" extension in the client
>    hello message and sent a "status_request" extension in the server
>    hello message.
>
> If the "status_request" extension in the ClientHello is to be ignored
> for resumed sessions, and we should send a ServerHello with none of the
> extensions, then we cannot send a stapled OCSP response.

I think "negotiated extensions" includes the extensions sent in the
ServerHello in the original session initiation.  If you sent a
status_request extension back then, the functionality applies to the
current session, which allows sending a stapled OCSP response.

cheers,
Stefan

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

TJ Saunders
In reply to this post by Ander Juaristi

> > To me, this means that if the session is resumed, then the extensions
> > _in the ClientHello_ (including the status_request extension) are to be
> > ignored.  And if that client-sent extension is ignored, then this text,
> > from Section 8, becomes relevant, I think:
> >
> >   "Note in addition that a server MUST NOT send the "CertificateStatus"
> >    message unless it received a "status_request" extension in the client
> >    hello message and sent a "status_request" extension in the server
> >    hello message.
> >
> > If the "status_request" extension in the ClientHello is to be ignored
> > for resumed sessions, and we should send a ServerHello with none of the
> > extensions, then we cannot send a stapled OCSP response.
> >
>
> If things are this way then (and I understand this might not be a
> GnuTLS-specific issue, but just popped out from my head), what happens if
> the certificate has been revoked in the time span between the initial session
> establishment and the later resumption?
>
> The client can check that by sending a "normal" OCSP status request, but
> would lose the benefit of stapled OCSP?

Or, if the client was wary of such an occurrence, it would simply not
offer the session ID (or session ticket) in its ClientHello, thus
preventing the possibly of a resumed session and forcing a full
handshake, with its stapled OCSP response.  Another refinement would be
for that client, if it sees a session resumed "too many times"
(determined by that client implementation/configuration), to then
connect to the server without session ID or ticket, requesting the
stapled OCSP response -- this way the client would get most of the
benefit of session resumption, and the benefit of OCSP stapling, with a
way to "double check" that certificate validation in the face of resumed
sessions.

Since the session resumption timing is ultimately left up to the server,
and that timing is not conveyed back to the client, it is something of a
question of trust.  Does the client trust the server to implement an
"acceptable" (for whatever that means) policy of session caching?  If
so, then it should trust the resumed session without its stapled OCSP
response.  If not, then perhaps that client should not be connecting to
the server at all.

Cheers,
TJ

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

TJ Saunders
In reply to this post by Stefan Bühler

> > My understanding is based on this sentence in that section 1.1 portion
> > of RFC 6066:
> >
> >   "If, on the other hand, the older session is resumed, then the server
> >    MUST ignore the extensions and send a server hello containing none of
> >    the extension types."
> >
> > To me, this means that if the session is resumed, then the extensions
> > _in the ClientHello_ (including the status_request extension) are to be
> > ignored.  And if that client-sent extension is ignored, then this text,
> > from Section 8, becomes relevant, I think:
> >
> >   "Note in addition that a server MUST NOT send the "CertificateStatus"
> >    message unless it received a "status_request" extension in the client
> >    hello message and sent a "status_request" extension in the server
> >    hello message.
> >
> > If the "status_request" extension in the ClientHello is to be ignored
> > for resumed sessions, and we should send a ServerHello with none of the
> > extensions, then we cannot send a stapled OCSP response.
>
> I think "negotiated extensions" includes the extensions sent in the
> ServerHello in the original session initiation.  If you sent a
> status_request extension back then, the functionality applies to the
> current session, which allows sending a stapled OCSP response.

If we are to ignore the ClientHello extensions for a resumed session,
then we would not send the stapled OCSP response.  The RFC 6066 Section
1.1 text, in my reading, says that the ServerHello emitted by the TLS
server, for a resumed session, MUST NOT contain any of the TLS
extensions -- and this would include the stapled OCSP response.  That
is, the ServerHello of the resumed session must be different; it is not
described as being a "replay" of the original ServerHello.

Cheers,
TJ

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

TJ Saunders
In reply to this post by Tim Kosse-2

> On 27.06.2017 08:37, TJ Saunders wrote:
> > Not all FTP servers require session resumption for their data
> > connections, so to be thorough, I assume FileZilla would want to ensure
> > that the TLS session for the data connection was indeed resumed, before
> > going on to ignore a missing OCSP response for that resumed TLS session?
>
> Correct, ignoring the missing OCSP response on a non-resumed session
> would be a really bad idea.

Also, on the topic of how a client might handle the case where the TLS
session is resumed, and the server certificate bears the "must staple"
X509v3 extension, I think Section 4.2.3.1 of RFC 7633 is relevant:

  https://tools.ietf.org/html/rfc7633#section-4.2.3.1

Specifically:

   "A client MAY accept a TLS configuration despite it being
   inconsistent
    with the TLS feature declaration if the validity of the certificate
    chain presented can be established through other means (for example,
    by successfully obtaining the OCSP data from another source)."

If the server does not provide the stapled OCSP response in the resumed
session (per RFC 6066), and the server certificate contains that "must
staple" X509v3 extension, then the client might choose to accept the
handshake anyway -- on the _assumption_ that the client did already
verify that a stapled OCSP response was provided as part of another
source -- the original TLS handshake.

Cheers,
TJ

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

Tim Kosse-2
In reply to this post by TJ Saunders
Hi,

On 2017-06-27 17:22, TJ Saunders wrote:
> If we are to ignore the ClientHello extensions for a resumed session,
> then we would not send the stapled OCSP response.  The RFC 6066 Section
> 1.1 text, in my reading, says that the ServerHello emitted by the TLS
> server, for a resumed session, MUST NOT contain any of the TLS
> extensions -- and this would include the stapled OCSP response.  That
> is, the ServerHello of the resumed session must be different; it is not
> described as being a "replay" of the original ServerHello.

The stapled OCSP reponse is sent in a separate CertificateStatus
handshake packet, it is not part even part of the ServerHello.

Regards,
Tim

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

TJ Saunders

> > If we are to ignore the ClientHello extensions for a resumed session,
> > then we would not send the stapled OCSP response.  The RFC 6066 Section
> > 1.1 text, in my reading, says that the ServerHello emitted by the TLS
> > server, for a resumed session, MUST NOT contain any of the TLS
> > extensions -- and this would include the stapled OCSP response.  That
> > is, the ServerHello of the resumed session must be different; it is not
> > described as being a "replay" of the original ServerHello.
>
> The stapled OCSP reponse is sent in a separate CertificateStatus
> handshake packet, it is not part even part of the ServerHello.

True, but if we are not to include the "status_request" extension in the
ServerHello (because we are ignoring the "status_request" extension in
the ClientHello, because it's a resumed session), then we should not
send the CertificateStatus message; the client would not know to look
for a CertificateStatus message unless there is also the
"status_request" extension in the ServerHello.

Cheers,
TJ

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

Tim Kosse-2
Hi,



On 2017-06-28 01:43, TJ Saunders wrote:

> True, but if we are not to include the "status_request" extension in the
> ServerHello (because we are ignoring the "status_request" extension in
> the ClientHello, because it's a resumed session),

Correct so far.

> then we should not
> send the CertificateStatus message; the client would not know to look
> for a CertificateStatus message unless there is also the
> "status_request" extension in the ServerHello.

The server must use the ServerHello (and thus the ClientHello) of the
original handshake as reference for the extensions:

"In this case, the functionality of these extensions negotiated during
the original session initiation is applied to the resumed session."

During the initial handshake, both ClientHello and ServerHello contained
the status_request extension, so the client is prepared to receive a
CertificateStatus.


There is an example for a different extension in RFC 6066, see the
description of the "truncated_hmac" extension in chapter 7, at the end
it says "The negotiated HMAC truncation size applies for the duration of
the session including session resumptions".

Even though the ServerHello of a resumed session does not include
"truncated_hmac" the HMACs would still be truncated if they originally were.


It's not stated explicitly in the RFC, but it follows for the client
that the contents of the extensions list in the ServerHello of the
resumed handshake are to be ignored, with the client having to use the
extensions negotiated with the original ServerHello.

This

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

Tim Kosse-2
In reply to this post by Ander Juaristi
Hi,

On 2017-06-27 09:13, Ander Juaristi wrote:> what happens if the>
certificate has been revoked in the time span between the initial
session> establishment and the later resumption?> > The client can check
that by sending a "normal" OCSP status request, but would> lose the
benefit of stapled OCSP?

It's not much of a deal. On a non-resumed handshake the server can still
use the revoked certificate for a while if it keeps stapling the old
OCSP response until it expires.


Regards,
Tim

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [gnutls-devel] Interaction between TLS session resumption and the OCSP must-staple certificate extension

TJ Saunders
In reply to this post by Tim Kosse-2

> > then we should not
> > send the CertificateStatus message; the client would not know to look
> > for a CertificateStatus message unless there is also the
> > "status_request" extension in the ServerHello.
>
> The server must use the ServerHello (and thus the ClientHello) of the
> original handshake as reference for the extensions:
>
> "In this case, the functionality of these extensions negotiated during
> the original session initiation is applied to the resumed session."
>
> During the initial handshake, both ClientHello and ServerHello contained
> the status_request extension, so the client is prepared to receive a
> CertificateStatus.

That is one interpretation, but not the only interpretation; "the
functionality of these extensions" is vague when applied in the context
of what happens during the handshake exchange itself.

> It's not stated explicitly in the RFC, but it follows for the client
> that the contents of the extensions list in the ServerHello of the
> resumed handshake are to be ignored, with the client having to use the
> extensions negotiated with the original ServerHello.

That is one possible reading, yes.  But not the only possible reading.
YMMV.  It would be interesting to survey existing TLS client
implementations to see how many (if they even implement code for these
edge cases being discussed) do that, and how many not.  Since it is not
explicitly stated in the RFC, we are in the area of "undefined
behavior".

Cheers,
TJ

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Loading...