Port bound TLS certificates? (1 Self-signed & 1 CA)

Question

For my android game, I want to secure the connection between the server and its clients through TLS certificates on each side, because of the sensitive data that is beeing exchanged through a token based login system and other userdata. Webbrowsers should also access the same domain but get different data served.

Is it possible, to use two different kind of certificates on the servers domain bound to ports? Self-signed one for the server (without own CA) and a self-signed one (hardcoded in the gameclient) for gameclient connections to port 9443. One from a CA like letsencrypt.org for webbrowsers that connect to port 443?

Do I have to run 2 different http-servers for that on the same machine?

Example: A game client connecting to example.com (or the direct IP address with port 9443) gets authenticated as a valid client and therefore can register, login or update game data.

Browser who's connecting to example.com (port 443) sees a website, can access player profiles that are simple html pages.

My research so far: I already saw in the openssl example config file here, that using different subdomains as the common name for each certificate may will work? But no mention if something works bound to ports.

I appreciate your help. Thanks.

Answer 1

Is it possible, to use two different kind of certificates on the servers domain bound to ports?

Yes, it is possible to use different certificates on different ports.

Do I have to run 2 different http-servers for that on the same machine?

Web servers like nginx or apache support running the same server on multiple ports with different certificates at the same time. But it is also possible to run different servers on different ports.

Answer 2

At the time of writing, the particulars of TLS Token Binding are being actively drafted by the IETF "tokbind" Working Group and was initially proposed in RFC8471, "The Token Binding Protocol Version 1.0." The abstract of that RFC document states, "The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections." While it does not specifically restrict the token to a particular port number, it is clear that a TLS binding spanning multiple sessions/connections can naturally apply to a particular port number. In other words, the token is bound to the origin (i.e. scheme-host-port triple) of the URI where the HTTPS service is listening. This is to be expected since SOP, a.k.a. Same-Origin-Policy is one of the most fundamental web application security concepts.

Implementation of this token binding protocol requires support for the TLS extension in the client and server software. According to RFC8473, "Token Binding over HTTP", Section 4--the setup you're describing is known as a "first-party" or "same-site" scenario. This is in opposition to a federated scenario where an IdP (Identity Provider) binds the token across multiple TLS services.

Application layer modifications, i.e. HTTP headers such as Include-Referred-Token-Binding-ID and Sec-Token-Binding as defined by RFC8473 are not necessary in this case, although they are required for federation use cases where clients may have requests redirected to identity providers. A same-site/first-party (or as you referred to it, "port-bound") use case only requires transport layer support for the TLS token_binding extension whose protocol data is detailed in Sections 2 and 3 of RFC8472, "Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation". The TLS ClientHello and ServerHello protocol data units communicate support for the extension and its key parameters.

For more information about the protocol itself, see the referenced RFC documents and the TokenBinding GitHub account. There is also a mod_token_binding repository published by GitHub user zmartzone that has an Apache 2.4 module which implements this feature. Moreover, Google has published ngx_token_binding on GitHub which is an NGINX module supporting the TLS extension. According to this [Intent to Implement: Token Binding] document for Chromium, browser-side implementation is split between BoringSSL and Chromium's SSLClientSocket. The Windows IT Pro Center web site documents token binding for Windows Server 2016 and Windows 10. Hope this helps!