Subject: [TLS] SNI and tickets and resumption

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 Aug 2014 16:18:32 -0400

Can a client connect with an SNI extension and then later on resume or send a ticket with a different SNI value?

I couldn't find it documented anywhere. Am I missing something, or should we?

--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: [email-masked]<mailto:[email-masked]> Twitter: RichSalz

---

From: Adam Langley <[email-masked]>
Date: Fri, 8 Aug 2014 13:28:47 -0700

> a ticket with a different SNI value?

In practice, often yes. However, whether you want to allow that is a
different matter. If you share ticket keys between different servers
you would want to ensure that a client's connection to one of them
can't be redirected to another unless the servers are identical.

At Google, we share ticket keys between servers, but the servers will
reject a resumption if any part of the ClientHello causes a different
certificate to be selected than was presented on the original
connection. Then services that don't route requests based on the Host
header are then given their own certificates to partition them.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 Aug 2014 16:30:48 -0400

We do the same thing, but wasn't sure if it was legit. 

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: [email-masked] Twitter: RichSalz

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Aug 2014 14:08:37 -0700

> We do the same thing, but wasn't sure if it was legit.

We can probably do better than that.  And I'm sure that this goes
beyond SNI, though that's a pretty obvious one.

https://github.com/tlswg/tls13-spec/issues/76

---

From: [email-masked] (Martin Rex)
Date: Sat, 9 Aug 2014 01:06:53 +0200 (CEST)

Salz, Rich <[email-masked]> asked:
>
> Can a client connect with an SNI extension and then later on resume
> or send a ticket with a different SNI value?

AGL responded:
> connection.

> We do the same thing, but wasn't sure if it was legit. 

The words you're using are sufficiently ambiguous to get me worried.

Since the specification of the TLS extension "server name indication"
is also somewhat wrong (which I only noticed when I implemented it),
I would appreciate to get this clarified.

On a mismatch of SNI in combination of resumption with the original SNI
value (and I include _absent_ SNI on an initial SSLv2 CLIENT-HELLO
in this count!), the server should behave according to the
"Principle of least surprise", and **NOT** reject the connection
(i.e. *NOT* abort with a fatal alert).

If the server doesn't use SNI at all (which includes not supporting
TLS extension SNI), then it should continue to ignore SNI on resumption.

If the server uses SNI on initial full handshakes (those without any
kind of resumption proposed by the client), then the server should
perform a full TLS handshake if SNI differs from what was used for
the session that was proposed for resumption.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Sat, 9 Aug 2014 01:25:03 +0200 (CEST)

Ooops.  Somehow the previous message wasn't what I wanted to say.

When I implemented support for TLS extension SNI (at the lower levels
or our software stack), then I implemented the "principle of least
surprise" in the following fashion:

Essentially, whenever a full handshake would result in the use of the
same server certificate as the resumption proposed by the client,
my server will perform session resumption, and ingnore SNI mismatches.

-Martin

---

From: Adam Langley <[email-masked]>
Date: Fri, 8 Aug 2014 16:25:35 -0700

On Fri, Aug 8, 2014 at 4:06 PM, Martin Rex <[email-masked]> wrote:
> and **NOT** reject the connection

We're certainly not rejecting the connection - just the resumption,
i.e. we'll make do a full handshake.

Cheers

AGL

---

From: [email-masked] (Martin Rex)
Date: Sat, 9 Aug 2014 01:27:07 +0200 (CEST)

Adam Langley wrote:
[ Charset UTF-8 unsupported, converting... ]
> i.e. we'll make do a full handshake.

Great!  Thanks.

-Martin

---

From: Sajeev S <[email-masked]>
Date: Sun, 10 Aug 2014 21:46:39 +0530

As per RFC 6066--->Transport Layer Security (TLS) Extensions:
Extension Definitions

Note also that all the extensions defined in this document are
   relevant only when a session is initiated.  A client that requests
   session resumption does not in general know whether the server will
   accept this request, and therefore it SHOULD send the same extensions
   as it would send if it were not attempting resumption.  When a client
   includes one or more of the defined extension types in an extended
   client hello while requesting session resumption:

   -  The server name indication extension MAY be used by the server
      when deciding whether or not to resume a session as described in
      Section 3 <http://tools.ietf.org/html/rfc6066#section-3>.

   -  If the resumption request is denied, the use of the extensions is
      negotiated as normal.

   -  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.  In this case, the
      functionality of these extensions negotiated during the original
      session initiation is applied to the resumed session.

Regards,
Sajeev

On Sat, Aug 9, 2014 at 1:48 AM, Salz, Rich <[email-masked]> wrote:

> Can a client connect with an SNI extension and then later on resume or
> send a ticket with a different SNI value?
>
>
>
> I couldn’t find it documented anywhere. Am I missing something, or should
> we?
>
>
>
> --
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Brian Sniffen <[email-masked]>
Date: Mon, 11 Aug 2014 00:02:03 -0400

> my server will perform session resumption, and ingnore SNI mismatches.

So if a server has a giant SAN cert for `eff.org` and `nsa.gov`, and a
session with one is resumed to the other---that's unsurprising?  I don't
see a path all the way through to an attack, but it leads me to worry
about a web app and a web server interacting in this way.

At least for HTTP, the changing SNI will indicate a change of cookie and
same-origin context.  But RFC 6066 says:

   If there is a mismatch between the server name used by the client
   application and the server name of the credential chosen by the
   server, this mismatch will become apparent when the client
   application performs the server endpoint identification, at which
   point the client application will have to decide whether to proceed
   with the communication.

So maybe the client applications all carefully follow this tricky
advice.

On the other hand, RFC 6066 also says:

   A server that implements [SNI] MUST NOT accept the request
   to resume the session if the server_name extension contains a
   different name.  Instead, it proceeds with a full handshake to
   establish a new session. 

It doesn't sound like your server quite does that?

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Mon, 11 Aug 2014 05:28:43 +0100

> about a web app and a web server interacting in this way.

Yes, it *is* indeed unsurprising: this behavior is the standard in SPDY 
and in the current HTTP2 draft even though it goes against the spirit of 
RFC 6066 -- see my message in the thread "inter-protocol attacks".
Moreover, current webservers will also proceed with resumption even if 
the SNI provided by the client would have resulted in the server picking 
a different certificate. This is why resumption can be used to bypass 
certificate validation - this problem is related to yet another TLS API 
problem with the SNI callback. In many cases, the application may not 
even get to see the certificate selection callback from TLS when doing 
resumption.

Best,

Antoine Delignat-Lavaud

---

From: [email-masked] (Martin Rex)
Date: Mon, 11 Aug 2014 19:06:19 +0200 (CEST)

> It doesn't sound like your server quite does that?

Correct, my server doesn't follow that formally provable invalid wording
above in the spec.  As I said, I only realized this fallacy in the spec
when I implemented it.

TLS session resumption is a performance optimization that happens at
the TLS level.  TLS server endpoint identification and selection/provisioning
of suitable server credentials is a matter of the application on top
of TLS.  Whether and how often the server uses resumption from
the cache or full handshake is the result of the caching&resumption
strategies & lifetimes of client plus server combined.

The purpose of SNI a hint from the client to the server which kind
of server endpoint identification the client is going to perform,
and the server may use that hint in selecting the most appropriate
server certificate.  If a full handshake and a session resumption
will result in the use of the exact same server certificate, then
the Server can freely choose which way to go (resume or full handshake),
provided that the client offers session resumption and the server
is capable of accepting it.

The server endpoint identification performed by the client is
an application-level matter, and ought to be performed independent
of whether a TLS session resumption of a TLS full handshake is performed.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 11 Aug 2014 17:52:00 +0000

> about a web app and a web server interacting in this way.

With DANE TLSA records of the form:

    _443._tcp.www.nsa.gov. IN CNAME _443._tcp.www.example.net.
    _443._tcp.www.eff.org. IN CNAME _443._tcp.www.example.net.
    _443._tcp.www.example.net. IN TLSA DANE-EE(3) SPKI(1) SHA2-256(1) {blob}

and supposing that at some future date, browsers support RFC 6698
and updates, the name in the server certificate is entirely
irrelevant, the name to key binding is in DNS.  The HTTPS server
is then authenticated by its public key alone.  The clients will
then send SNI with either "www.nsa.gov" or "www.eff.org" (on the
off chance that the server cares), but there is nothing a-priori
wrong with a single certificate associated with multiple domains
(as unlikely as it may seem that eff.org and nsa.gov would choose
the same hosting provider).

>    different name.  Instead, it proceeds with a full handshake to

Some client caches are poorly designed, and their cache lookup key
might be only the peer IP:port and not the associated domain or
other relevant data.  Servers should tolerate this at least to the
extent performing a full handshake instead of resumption.

Resuming with mismatched SNI is perhaps in conflict with 6066, but
seems harmless from a server perspective, the error is on the client
side, and if there are security consequences, it seems to me that
the exposure is there as soon as the client offers to resumt the
mismatched session.

I think it is the client that SHOULD NOT resume sessions across
mismatched SNI values, since it can no longer be sure it is connected
to the intended server.  I see little harm in the server saying
yes if the certificate is the same in either case.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Mon, 11 Aug 2014 20:31:59 +0200 (CEST)

> RFC 6066 -- see my message in the thread "inter-protocol attacks".

It is not against the *spirit* (aka underlying design) of TLS extension
server name indication, only against the current, formally provable
defective ad-hoc wording that was used to describe one aspect of the
behaviour (keep in mind that RFC at the "Proposed Standard" maturity
level must be assumed to contain defects such as this one.)

> a different certificate.

This behaviour would be against the spirit of rfc6066, and against the
"principle of least surprise".  It would indicate a significant lack of
robustness when fiddling with the session cache lifetime on client or
sorver or when disabling the client-side or server-side session cache
would affect application behaviour / usage scenarios.

>
> This is why resumption can be used to bypass certificate validation
> - this problem is related to yet another TLS API problem with the
> SNI callback. In many cases, the application may not even get to see
> the certificate selection callback from TLS when doing resumption.

According to the TLS specification (last paragraph of Introduction),
the server endpoint identification is something that the application on
top of TLS performs, whereas TLS session caching and resumption is
something that happens transparently within the TLS protocol stack.

  Last sentence of Section 1. Introduction

  https://tools.ietf.org/html/rfc2246#page-4
  https://tools.ietf.org/html/rfc5246#page-5

                   how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of TLS.

The TLS client app ought to perform server endpoint identification
"interpret the authentication certificates exchanged" independent
of whether the TLS connection is established with a full TLS handshake
or and abbreviated TLS handshake (aka TLS session resume).

Normally, I would assume that the client-side session cache is organized/
indexed by the information that is used for server endpoint identification,
and a client should not be proposing session resumption of a cached session
that would fail server endpoint identification.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 11 Aug 2014 20:11:49 +0000

> that would fail server endpoint identification.

Exactly!  This is, for example, how the Postfix client session
cache is keyed.  With DANE, the session lookup key even covers the
current peer TLSA RRset, so that when TLSA RRs change, the client
negotiates a new session.  If the client proposes a session with
an SNI name it would not accept for the certificate chain of the
cached session, that's the client's fault.

-- 
	Viktor.