HTTPA/2: a Trusted End-to-End Protocol for Web Services

by   Gordon King, et al.

We received positive feedback and inquiries on the previous work of HTTPA [10] (HTTPA/1). As a result, we present the major revision of HTTPA protocol (HTTPA/2) to protect sensitive data in HTTPA transactions from cyber attacks. Comparatively, the previous work [10] is mainly focused on how to include Remote Attestation (RA) and secret provisioning to HTTP protocol in assumption of using Transport Layer Security (TLS) across Internet. In contrast, HTTPA/2 does not need TLS protocol, such as TLS 1.3 [19], for secure communication over Internet. The design of HTTPA/2 follows SIGMA model [12] to establish an L7 trusted communication, a secure communication between trusted (attested) endpoints at L7. Different from connection-based protocol, HTTPA/2 is transaction-based in which TEEs is considered as resources to be requested via Internet. In addition to protecting sensitive data for TEE-based Services (TServices), HTTPA/2 can potentially optimize the end-to-end performance of Internet or cloud backend traffics, thus saving energy and reducing the operational costs of Cloud Service Providers (CSPs). We envision that HTTPA/2 to further enable confidential web services and trustworthy AI applications in the future.


HTTPA: HTTPS Attestable Protocol

Hypertext Transfer Protocol Secure (HTTPS) protocol has become integral ...

Aurora: Providing Trusted System Services for Enclaves On an Untrusted System

Intel SGX provisions shielded executions for security-sensitive computat...

A Step Towards On-Path Security Function Outsourcing

Security function outsourcing has witnessed both research and deployment...

Blockchain-based TLS Notary Service

The Transport Layer Security (TLS) protocol is a de facto standard of se...

undeSErVed trust: Exploiting Permutation-Agnostic Remote Attestation

The ongoing trend of moving data and computation to the cloud is met wit...

The Struggle is Real: Analyzing Ground Truth Data of TLS (Mis-)Configurations

As of today, TLS is the most commonly used protocol to protect communica...

Building secure distributed applications the DECENT way

Remote attestation (RA) enables distributed applications that deploy tru...

1 Introduction

httpa/1 [orighttpa] is based on http extension to handle requests for remote attestation and secret provisioning so that Internet visitors can access a wide variety of services running in tee, where most applications are at the L7 endpoints and ought be protected at the L7. In this way, visitors’ pii and their private data are better protected when transmitting from a client endpoint to a service endpoint. The httpa/1 can support mutual attestation if the client endpoint runs inside tee as well. Although httpa/1 helps build trust between L7 endpoints with data-level protection, httpa/1 needs tls to defend against attacks over the Internet, e.g., replay attack and downgrade attack. Note that tls cannot guarantee end-to-end security for the https message exchange [httpsig] when the tservice is hosted behind a tls termination gateway or inspection appliance. Although the tls can provide confintauth to ensure the security of message exchange for httpa/1 protocol, it is not a complete end-to-end solution to mitigate attacks from middle boxes of tls termination. Both httpa/1 and tls need to establish a set of key materials respectively through similar key exchange and derivation processes, so there is room to further optimize the performance and reduce the complexity for them. As the limitation of tls mentioned above, an httpa with message-level security protection turns out to be a natural candidate to address those issues.
This paper aims to propose an upgrade protocol, httpa/2, which makes httpa transaction secure, even no tls presence or tls termination over untrustworthy middle-boxes. The httpa/2 is designed to improve the processes of key exchange, ra and secret provisioning. It enables an end-to-end more secure and trustworthy transaction, which is cryptographically tied to an attest-able service base which can be trusted by Internet visitors. The rest of the paper is organized as below. Section 2 provides necessary preliminaries. Section 3 elaborates on the protocol transactions. Section 4 talks about security considerations. Section 5 concludes the whole paper.

2 Technical Preliminaries

This section provides preliminaries related to the construction of httpa/2. We firstly introduce 2.1 Trusted Execution Environment (TEE) in a web service setting. Then we describe several important primitives to be used later.

2.1 Trusted Execution Environment (TEE)

In a tee, genuine codes are executed on data with CPU-level isolation and memory encryption inaccessible to anyone even with system-level privileges. The computation inside tee is protected in terms of confidentiality and integrity. A tee is usually considered more trustworthy than ree [ree] where codes are executed on data without isolation. Although most web services are deployed in ree, it is an emerging trend that web service started being deployed in the tee for better security. Upon implementation, a service initialized and run inside the tee is known as a Trusted Service, called tservice. tservice uses tee to effectively reduce its tcb, which is the minimal totality of hardware, software or firmware that must be trusted for security requirements, thus reducing the attack surface to as minimal as possible.
For some tee, such as sgx or tdx, it can provide evidence of identities and other security properties (or we call it ”atq” in the section 2.2) to its remote relying parties for ra [ra_review_2021] [remoteattestsrv] on its initial state or current state to make the tservice more trustworthy.
Not all tee are attestable, but the httpa is only applicable to attestable tee which can generate such evidence for the purpose of ra.

2.2 Attest Quote (AtQ)

atq is an opaque data structure signed by a qservice with a ak, and it can be called a quote [explore_ra_tee], which is used to establish trustworthiness through identities. Because of this, the quote encapsulates code identity, isv identity, tee identity, and various security attributes, e.g., svn of a tee [innocpuattest], associated with a tservice instance. A relying party can examine the quote to determine whether the tservice is trustworthy or not via verification infrastructure.
The quote is not a secret, and it must ensure its uniqintauth. The quote generation involves cryptographically measuring the instantiated tcb, signing the measurements with ak, and a nonce.
The atq accommodates a piece of user-defined information, called qudd. The qudd can provide extra identities specific to a tservice. Therefore, the atq can in turn help protect the integrity of ahl during the handshake phase which we will discuss in the section 3.2.
It’s worth noting that not all quotes are the same, especially, if they are structured by different vendors, so a label of quote type should be attached along with atq.

2.3 Attest Base (AtB)

atb is totality of computing resources serving client request handling, including hardware, firmware, software and access controls to work as a synergy to deliver trustworthy service quality with enforced security/privacy policy. It can also be considered as a group of collaborating tservice instances running in their own attestable tee respectively, which are capable of proving the state for execution.
In this paper, the computing resources of tservice is offered by atb to be accessible to the client through a series of trusted transactions. How to attest those trustworthy services are determined by specified policy in handshake phase. We suggest using a single tservice instance for each atb to reduce the complexity and attack surface as possible.
The atb, serving for a particular service tied to a uri, should be directly or indirectly attested by a client through httpa/2 protocol.
In the case of a atb formed by multiple tservice instances, an upfront tservice instance takes responsibility for performing local attestation on the rest of tservice instances to establish trustworthy relationship among them. After that, the upfront tservice can selectively collecting their quotes for client-side verification during httpa/2 handshake phase.

2.4 Three Types of Request

There are three types of request used in the httpa/2 protocol, including utr atr, and trr. utr is used in regular http transaction; atr is used in both transactions of aths and atsp; trr is used in trusted transaction. Also, we use the term, ”httpa/2 request”, to generally refer to either atr or trr for convenience. Before we explain the details of those three types of request, we first introduce two http concepts for such realization: http method and http header lines.
Regarding http method, we proposed an emerging http method, called ”ATTEST”, to perform the transactions of aths and atsp. The http request using ATTEST method is called atr. Regarding the concept of http header fields, we proposed to augment them with additional ones called ahf, they are all prefixed with string ”Attest-”. Without ahf, it must be a utr in terms of httpa/2.
The ahf are dedicated to httpa traffic. For example, they can be used to authenticate the identity of httpa/2 transactions, indicate which atb to request, convey confidential meta-data (see the section 2.7), provision secrets, present ticket (see the section 2.5) and etc.
Last one is ahl, it consists of ahf and its values in a standard form [rfc8941]. we use it to signify single piece of annotated data associated with current httpa/2 request.

2.4.1 Untrusted Request (UtR)

The utr is simply an ordinary type of http request, which does not use ATTEST method nor does it contain any ahl.
Before a utr reaching a tservice, the utr can be easily eavesdropped on or tampered with along communication path. Even protected by tls, it is still possible to be attacked when crossing any application gateway or L7 firewall since those intervening middle-boxes are untrusted and will terminate TLS connections hop by hop [httpsig]. Therefore, there is no any guarantees in terms of confintauth. That’s why the tservice cannot treat it as trustworthy request at all. But it is still possible for tservice to handle utr if allowed by service-side policy. So, We don’t suggest tservice to handle any one of them for the sake of security.

2.4.2 Attest Request (AtR)

The atr is a http request equipped with both ATTEST method and ahl for aths and atsp. If any atr was not successfully handled by corresponding tservice, subsequent trr, described in the section 2.4.3, will no longer be acceptable to this tservice anymore. We will explain some major differences of atr used in aths and atsp respectively as follows:


The atr used in aths is designed to request all necessary resources for handling both of atr used in atsp and trr. For example, one of the most important resources is atb (see the section 2.3), which could be scheduled or allocated by a server-side resource arbiter. Typically (but not always), an upfront tservice can directly designate itself as the atb to serve for this client. For the complete explanation in detail, see the section 3.2.

In addition, this atr should not be used to carry any confidential information because the key materials cannot be derived at this moment, but tservice can encrypt sensitive data in response message since it has already received required shared keys from client and be able to derive key materials for encryption.


The atr of atsp is optional and may not present in httpa/2 traffic flow, since in rare cases, the tservice won’t need any atb wide secrets provided by client to work. But in many cases, when tservice needs it to configure its working environment, such as connecting to databases, setup signing keys and certificates, you name it. This atr must be issued after all resources have been allocated through the atr used in aths.
It’s worth noting that this request is not required to be issued before any trr 2.4.3, this way provides certain flexibility for tservice to get extra information or do some operations beforehand through preceding trr.
Importantly, this atr is responsible to provision atb wide secrets to atb, such as key credentials, tokens, passwords and etc. Those secrets will be wrapped by encryption key derived from key exchange in aths phase 3.2. Furthermore, the tservice must ensure that those provisioned secrets will be eliminated after use or atb get released or any failure occurred in processing atr. For the complete explanation in detail, see the section 3.3.

The two kinds of atr briefly introduced above are the core of httpa/2 protocol. Both of them can be treated as GET request messages to save a rtt, and they can also be used to transmit protected sensitive data to both sides, except for the atr of aths due to the key exchange not yet completed as noted earlier.

2.4.3 Trusted Request (TrR)

The trr can be issued right after successful aths (see the section 2.4.2) where a atb get allocated. Although, trr does not use ATTEST method, it should contain ahl to indicate that it is trr not utr. In other words, the trr is nothing but an ordinary http request with some ahl. Within those ahl, one of them must be atb id to determine which atb is targeted in addition to the specified uri. With that, the trr can be dispatched to proper tservice to handle this request.
In essence, the trr is designed to interact with a tservice for sensitive data processing. The httpa/2 must ensure confintauth of a set of selected data, which may be scattered in the message body or even in the header or request line, for end-to-end protection. It turns out that not all message bytes would be protected under httpa/2 like tls does. As a result, the httpa/2 may not be suitable for certain scenarios, e.g., simply want to encrypt all traffic bytes hop by hop. However, in most cases, the httpa/2 can offer a number of obvious benefits without TLS. For example, it may not be necessary to use tls so as to not worry about data leaking due to tls termination, and saving the resources associated with the tls connections. In some special cases, the httpa/2 can be combined with TLS to provide stronger protection but the performance overheads might be significant (see the section 2.8).
There are many potential ways to optimize Internet service infrastructure/platform by means of adopting httpa/2 since the insensitive part of httpa/2 messages can be used as useful hints to improve the efficiency of message caching or routing/dispatching, risk monitoring, malicious message detection and so on, whilst help protect sensitive data in transit as well as in processing by client chosen trustworthy services.

2.5 Attest Ticket (AtT)

Each httpa/2 request needs to ensure the intauth of its ahl, except for the atr of aths, which will be discussed below. So, the att is introduced to serve this sole purpose. In addition, it is also required to be unique for single use, which can mitigate the replay attack.
Moreover, the att should be located at the very end of request body as a last trailer [rfc7230], as there might be trc or other trailers, which need to be protected by it as well.
Regarding the atr of aths, there is no att, because there is no derived keys available to use at such early stage. In order to protect atr of aths, we can use either client-side quote or pre-configured signing key to ensure the intauth instead of att. Typically, there are four situations to consider:

mhttpa enabled

With mutual httpa enabled, the client must be running on a tee as tclient, which is capable of generating a client-side atq. Which can be used to ensure the intauth of atr by means of stuffing the digest of ahl into its qudd, and the server-side should have a proper trusted attestation authority to verify it.
This is a recommended approach to build mutual trust between tclient and tservice, but the client-side usually lack of tee feature support.

Client with ca signed Certificate

In this case, the client can sign the ahl of atr using its own signing key, and tservice should be able to verify the signature with pki. This way can also help tservice to identify the user identity.
In addition, the mhttpa can be enabled at same time if possible to make it more secure and trustworthy on both sides. It’s worth noting that we should not use the private key to encrypt any secrets, as using long-term private key won’t satisfy pfs, especially, the private key is not an ephemeral key which was generated outside of tee.

Client with self signed Certificate

Under this situation, the client should sign the ahl of att using temporary signing key, and tservice should verify the signature using its self-signed certificate which enclosed in the same ahl. This approach is not safe choice since the tservice may receive compromised atr, but better than nothing.

Nothing to provide

There is no way to protect the integrity of ahl under this circumstances. we recommend at least using the temporary generated signing key with its self-signed certificate as last resort. It’s worth noting that even the ahl of att have been compromised, the client get the chance to detect it since the signature of ahl of att and ahl of its response will send back to client through atq of tservice.

There are nothing we can use to prove the identity of the client under last two situations, so we call them anonymous clients. Again we recommend the client to combine mhttpa and ca signed certificate approaches together to establish stronger trustworthy relationship between tclient and tservice. if it is not the case, the client must detect if any changes occurs in the ahl of att as an additional critical step to defend against mitm and downgrade attacks.

2.6 Attest Binder (AtBr)

To ensure the binding between httpa/2 request and its response. A ahl of atbr should be added into its response message as a trailer [rfc7230]. The atbr typically holds the mac on the two components: all ahl of the current response but itself, the value of att in its corresponding request. We can choose other cipher suites e.g., aad, aead [rfc5116] to protect the intauth of the atbr.
The atbr should present in all httpa/2 response messages, except the response of atr in aths phase 3.2. The reason is the quote of tservice can achieve the same purpose without the help of atbr.

2.7 Trusted Cargo (TrC)

The trc can appear in both of httpa/2 request and response messages, except for the atr of aths. The trc serves as a vehicle to carry sensitive or confidential information which need to be protected by encryption.
One of main use of trc is to protect sensitive metadata about type, location, size and key index which are used to indicate where to find the ciphertext or signed plaintext in message body and which key should be used to decrypt or verify. Admittedly, potentially, there are many useful metadata which can be included in trc, but we should keep it minimum as size limits might be enforced by middle-boxes or intermediaries.
The way to structure the metadata and how to parse it are not defined by this paper; we leave it to the future extensions of httpa/2 or it can be customized by application.
Finally, the trc should put in trailer [rfc7230] since its variable length affects the position information it contains. Again, the value of trc must be authenticated encrypted to protect it from eavesdropping on or manipulating by the means of ae.

2.8 Trusted Transport Layer Security (TrTLS)

httpa/2 protects the selected parts of HTTP message. If users wants to protect the entire HTTP message, httpa/2 can use tls to build a trusted connection at L5, called trtls. trtls handshake takes advantage of atr in aths to transmit hello messages of tls to the client and server as initial phase of transport layer protocol, e.g., tls[rfc8446]. This way can make the initial handshake of transport layer protocol trustworthy. We consider three cases of endpoints as follows:


In the case of tclient endpoint, the tclient leverages its qudd to ensure the intauth of client hello message to establish tls connection. Server-side verifier helps verify the qudd. If the attestation is successful, the trusted endpoint of tclient will be established as trtls. Note that the trtls module should be co-located in the same tee with tclient.

Frontend tservice

In the case of frontend tservice endpoint, the communication between the tservice and the client has no TLS termination. That is, tservice establish the transport layer connection directly with its client when tservice is located at the frontend. Thus, the intauth of server hello message can be protected by the qudd of tservice in a similar way described in the case of tclient but in reverse direction.

Backend tservice

In the case of backend tservice endpoint, the connection of transport layer will be terminated by at least one middle-box e.g., application gateway, reverse proxy, or L7 load balancer. Although tservice has no direct connection with its client, the trusted connection of tls between client and the first middle box can be established by checking the results of ra from the backend tservice. The middle box needs to consider the mapping of the request and the response with the backend tservice to be correct in order to decide whether to use the results of ra to build a trusted connection or not. Admittedly, this is the least trustworthy configuration in terms of full traffic encryption when it is compared with the two cases mentioned above, because the attack surface includes middle boxes for the trtls connection.

After such initial message exchange over the transport layer, the encrypted channel is established in parallel to httpa/2, and all following traffic will be encrypted whilst inheriting the attested assurances of the tee from httpa/2. In the case of a regular TLS connection prior to httpa/2, the trtls mechanism can disconnect the already built tls connection and then re-establish a trustworthy tls connection seamlessly.

3 Protocol Transactions

In this section, we specifically introduce all httpa/2 transactions in detail.

3.1 Preflight Check Phase

To start with httpa/2, a preflight request could be issued by a client to check whether the Web service, which is specified by uri in request line, is tee-aware and get ready for aths. In case the client is a Web browser, the preflight request would be automatically issued when the atr qualifies as ”to be preflighted”.
The reason why we need the preflight transaction is that it is a lightweight http OPTIONS [httpsemantics] request, which won’t need to consume a lot of computing resources, compared to the attest handshake transaction, while caching its result can avoid the re-check operation during a specified time window.
The preflight request also gives the Web service a chance to see what the actual atr looks like before it is made, so the service can decide whether it is acceptable or not accordingly. In addition, the browser performs the preflight check as a security measure to ensure that the visiting service can understand the ATTEST method, ahf and its implied security assurance.
Passing this check doesn’t mean that the atr can be successfully handled by this service for some reasons. For example, the tservice runs out of resource, or the client’s cipher suites are not supported and so on.
The preflight is an idempotent operation, it means there is no additional effect if it is called more than once with the same ahl, thus the client can also use it to detect the capabilities of atb 2.3, without implying an action.

Figure 1: Preflight transaction

As shown in Figure.1, an OPTIONS request should be honored by httpa/2 compliant tservice. In the preflight transaction, it has standard hf to specify the method and ahl which will be sent out later to the same tservice if they are acceptable.Those hf are described respectively as follows:

  1. hf in request message

    1. Access-Control-Request-Method
      This hf carries a list of methods indicating that ATTEST method will be used in the next request if the service can support.

    2. Access-Control-Request-Headers
      This hf carries a list of field names indicating that the ahf will be included in the next request if the service can support.

  2. hf in response message

    1. Allow
      This hf carries a list of supported methods by the visiting service. It must contain the ATTEST method for the client to proceed with atr; otherwise, the atr is not acceptable by this service, and will be denied if received it.

    2. Access-Control-Allow-Headers
      This hf carries a list of allowed ahf. The client needs to check that all of requested ahf should be contained in this resulting field.

    3. Access-Control-Max-Age
      This hf indicates how long the preflight check results can be cached for.

3.2 Attest Handshake (aths) Phase

Figure 2: Attest handshake (AtHS) transaction

The aths phase contains a core transaction of httpa/2. In a single round trip time (one rtt), the atr and its response accomplishes three major tasks, including key exchange, atb allocation and atq exchange, as shown in Figure.2:

  1. Key Exchange
    It is necessary to complete the key exchange process before any sensitive information can be transmitted between client and tservice. The exact steps within this will vary depending upon the kind of key exchange algorithm used and the cipher suites supported by both sides.
    In httpa/2, the key exchange process follows tls 1.3 [rfc8446] and recommends a set of key exchange methods to meet evolving needs for stronger security.
    Insecure cipher suites have been excluded, all public-key based key exchange mechanisms now provide pfs, e.g., ecdhe. Note that it is mandatory that the fresh ephemeral keys are generated and used, and destroyed afterwards [rfc8422] inside the tee of tservice.
    When the key exchange is completed, we recommend to use hkdf [rfc5869] as an underlying primitive for key derivation.
    We describe the key negotiation between client and the tservice in terms of ahf set in request and response respectively as follows:

    1. ahf in request message (or atr):

      1. Attest-Cipher-Suites
        It is a list of cipher suites which indicates the aead algorithm/hkdf hash pairs supported by the client.

      2. Attest-Supported-Groups
        It is a list of named groups [rfc7748] which indicates the (ec)dhe groups supported by the client for key exchange, ordered from most preferred to least preferred. The ahl of Attest-Key-Shares contains corresponding (ec)dhe key shares e.g., pubkeys for some or all of these groups.

      3. Attest-Key-Shares
        Its value contains a list of the client’s cryptographic parameters for possible supported groups indicated in the ahl of Attest-Supported-Groups for negotiation. We can refer to the corresponding data structure described in tls 1.3 [rfc8446]. It is a time consuming operation to generate those parameters (see 3.1 in Figure.2)

      4. Attest-Random
        It is 32 bytes of random nonce, which is used to derive the master secret and other key materials by tservice. The purpose of the random nonce is to bind the master secret and the keys to this particular handshake. This way mitigates the replay attack to the handshake as long as each peer properly generate this random nonce.

    2. ahf in response message

      1. Attest-Cipher-Suite
        It indicates the selected cipher suites, i.e. a symmetric cipher/hkdf hash pair for httpa/2 message protection.

      2. Attest-Supported-Group
        It indicates the selected named group to exchange ecdhe key share generated by the tservice.

      3. Attest-Key-Share
        Its value contains the tservice’s cryptographic parameters accordingly (see 3.7 in Figure.2).

      4. Attest-Random
        It takes the same mechanism as the Attest-Random in the request. Instead, it is used by the client to derive the master secret and other key materials.

    This handshake establishes one or more input secrets combined to create the actual keying materials. The key derivation process (see 3.9, 3.15 in Figure.2), which makes use of hkdf, incorporates both the input secrets and the ahl of handshake. Note that anyone can observe this handshake process if it is not protected by the encryption of transport layer, but it is safe since the secrets of key exchange process will never be sent over the wire.

  2. atb Allocation
    This task takes care of resource allocation. The upfront tservice needs to prepare essential resources before assigning an unique atb identifier to the atb, which is used by client to ask tservice to process its sensitive data on this atb (see 3.6 in Figure.2).

    1. ahf in request message (or atr:

      1. Attest-Policies
        It can contain various types of security policies, which can be selectively supported by this atb of tservice. There are two aspects to consider as follows:

        Instances attestation

        direct: all instances should be verified by the client.
        indirect: only the contact instance should be verified by the client remotely.

        Untrusted requests

        allowUntrustedReq: it allows utr to be handled by the tservice on this atb (disabled by default).

      2. Attest-Base-Creation
        It specifies a method used for the creation of atb. There might be several options available to select:


        It means that the atb should be newly created for client to use. If the contact tservice is a new one, then it can be assigned to this client immediately.


        This option allows reusable atb to be used by this client, but the atb should ensure that all traces associated with previous client are erased.
        So far, there is no such tee, which can achieve this security feature strictly, and we cannot fully rely on software to emulate it. As a result, the client should evaluate the risks before specifying this option.


        A shareable atb can be allocated to this client. The client don’t care whether it is a clean base or not. so use it with caution.

      3. Attest-Blocklist
        It indicates a list of blocked identities and other type of identifiers which allows tservice to filter out unqualified atb beforehand. This feature is used to optimize the performance of atb allocation, as it is quite expensive and inefficient to rely only on client to collect a set of tservice instances by allow list using trial and error method.

    2. ahf in response message:

      1. Attest-Base-ID
        This identifier signifies the allocated atb, which has been tied to this particular client who sent the aths request. It should be used in subsequent httpa/2 requests to ensure those request can be efficiently dispatched into tservice. Given that the httpa/2 request dispatcher may not be trustworthy, and won’t be capable to check the integrity of it. As a result, it cannot guarantee that those requests could be delivered into their matched atb. To remedy this problem, the dispatcher should be capable to identify invalid atb Id as possible, and the receiving tservice should validate it right after integrity check (see 4.2 in Figure.3, 5.2 in Figure.4).
        Note that the max-age directive set here indicates how long this atb could be kept alive at server-side.

  3. atq Exchange
    In httpa/2, a successful ra [ra_review_2021] increases client’s confidence by assuring the targeting services running inside a curated and trustworthy atb. The client can also determine the level of trust in the security assurances provided by tservice through atb.
    The ra is mainly aimed to provision secrets to a tee, In this solution, we leverage this mechanism to set it as the root trust of the httpa/2 transactions instead of certificate based trust, e.g., tls. To facilitate it, we integrate the ra with the key exchange mechanism above to perform a handshake, which passes the assurance to derived ephemeral key materials (see 3.9 in Figure.2). Those keys can be in turn used to wrap secrets and sensitive data designated by client or tservice on either directions.
    During ra process, the atq (see the section 2.2) plays a key role to attest tservice. It provides evidence (quote) to prove authenticity of the relevant tservice (see 3.8 in Figure.2). The client can just rely on it to decide whether the tservice is a trustworthy peer or not [draftrats].
    To appraise atq, we need a trusted authority to be the verifier to perform the process of atq verification, and reports issues on this atq, e.g.,tcb issues (see 3.12 in Figure.2). The result of verification produced by the verifier should be further assessed by the client according to its pre-configured policy rules and applied security contexts.
    Importantly, the tservice should ensure the integrity and authenticity of all ahl of atr and its response through the qudd of atq, and vice versa in case of mhttpa/2.
    The following ahf should be supported by httpa/2 protocol for ra.

    1. ahf in request message (or atr):

      1. Attest-Quotes
        It can only appear in mhttpa/2 mode to indicate a set of atq generated from the tclient for targeting tservice to verify. (see 3.2, 3.3, 3.4, 3.5 in Figure.2). These quotes should be used to ensure intauth of the ahl of this atr through their qudd.
        Note that the max-age directive indicates when these quotes are outdated and its cached verification results should be cleared up from atb to avoid broken assurance. In addition, all client-side quotes must be verified by server-side verifier and validated by tservice before a atb Id can be issued.

    2. ahf in response message

      1. Attest-Quotes
        It is mandatory for a atb to present its atq to the client for client-side verification. The intauth of both ahl of the atr and its response should be ensured by its qudd to protect the transaction completely.
        The client must verify the atq to authenticate its identities of remote atb (see 3.8, 3.10, 3.11, 3.12 in Figure.2). The client should not trust anything received from tservice before atq are successfully verified and evaluated. Whether the integrity of ahl is held should be determined by client-side security policies. Note that the tservice quotes can be selectively encrypted in its parts through trc to hide its identity information.

    There are several remaining ahf, which is important to this transaction as they provide other necessary information and useful security properties:

    1. ahf in request message

      1. Attest-Versions
        The client presents an ordered list of supported versions of httpa to negotiate with its targeting tservice.

      2. Attest-Date
        It is the utc when client initiates a aths.

      3. Attest-Signatures
        It contains a set of signatures, which are used to ensure intauth of ahl in this atr through client-side signing key (see the section 2.5).

      4. Attest-Transport
        As described in the section 2.8, the client hello message should be put in here. With this, the tservice can enforces a trustworthy and secure connection at transport layer, which is a bit similar to what hsts does [rfc6797].

    2. ahf in response message

      1. Attest-Version
        It shows client which version of httpa is selected by tservice to support.

      2. Attest-Transport
        Similarly, the tservice returns its hello message to the client for transport layer handshake.

      3. Attest-Expires
        It indicates when the allocated atb will go expired and its related resources will get released. It provides another layer security to reduce the chance of this atb being attacked.

      4. Attest-Secrets
        It is an ordered list of atb-wide secrets; which are provisioned by tservice if client expects them. This way can save a rtt of atsp (see the section 3.3) in case of tservice won’t demand secrets from client immediately.

      5. Attest-Cargo
        The usage of this field is described in the section 2.7. Note that ”Attest-Cargo” is a ahf while trc is the corresponding content which plays an important role on sensitive data encryption and authentication.

    Apart from those tasks above, this atr can act as a GET request, but it cannot be trusted due to incomplete key exchange at this moment, which means it cannot contains any sensitive data, but its response can be trusted as the key exchange process completed at tservice-side, and before it gets returned. Therefore, the tservice-side sensitive data can be safely transmit back to the client through the trc.

3.3 Attest Secret Provisioning (atsp) Phase

Figure 3: Attest secret provisioning (AtSP) transaction

As mentioned in the section 3, the main purpose of atsp is to securely deliver secrets to a trustworthy atb which has been verified by a server-side verifier. The atr of atsp is intended to be used for this purpose. To be precise, it is for atb-wide and client-wide secret provisioning. On the contrary, the request-wide or response-wide secrets should be carried by the trc (see the section 2.7) of httpa/2 transactions. In addition, the failure of atsp will causes atb termination immediately. As shown in Figure.3, the atsp transaction can be used to provision secrets in two directions since the atb and its key materials already got derived through aths (see the section 3.2) on both sides; thus, the ahl can be fully protected during this phase. Moreover, atr of atsp can be issued by the client any number of times at anytime after aths.
These ahl described in following:

  1. ahf in request message (or atr)

    1. Attest-Base-ID
      This identifier is used to specify which atb is targeted to handle this atr of atsp. With this ID, the tservice can firstly validate it against its serving list to make sure correctly handling of this request (see 4.2 in Figure.3). However, the tservice should quietly ignore it if the ID is not valid for its residing atb as the receiving tservice should not expose any information for adversary to exploit.

    2. Attest-Ticket
      The usage of this field is explained in the section 2.5. The value of this field must be unique to prevent replay attack. Also, it ensures the IntAuth of the ahl in this request.

    3. Attest-Secrets
      It contains an ordered list of secrets, which is wrapped up by means of ae as a standard way for strong protection. Moreover, each secret should be able to be referred to by the client later using the index. For example, specifying a provisioned secret which is used to decrypt embedded sensitive data. Again, the receiving atb should be terminated if any of these provisioned secrets cannot be validated or accepted by the atb (see 4.3 in Figure.3).

    4. Attest-Cargo
      This field is optional, it can be used to carry any sensitive information which is meaningful to tservice (see the section 2.7). Note that this paper is not intended to define the structure of its content, which could be addressed in another one.

  2. ahf in response message:

    1. Attest-Binder
      It is used to make sure the request to response binding and identify this transaction uniquely (see the section 2.6).

    2. Attest-Secrets
      In this hf, these contained wrapped secrets will be provisioned back to the client. As noted earlier, this can be merged into the response ahl in atr of aths (see the section 3.2).

    3. Attest-Cargo
      Similarly, it can be used to carry sensitive information/data back to the client (see the section 2.7).

3.4 Trusted Communication Phase

Figure 4: Trusted transaction

When atb is allocated for the client, it can subsequently issue trr (see the section 2.4.3) to do the real work. Basically, the trr is an ordinary http request with some extra ahl which are described in detail as follows:

  1. ahf in request message:

    1. Attest-Base-ID
      It specifies which atb to handle this request, and should be validated by targeting tservice (see 5.2 in Figure.4) before processing this request (see 5.3 in Figure.4).

    2. Attest-Ticket
      This field has been explained above (see the section 2.5), which is intended to authenticate this request, and prevent other ahl from being tempered with or being replayed.

    3. Attest-Cargo
      As noted earlier, this field is optional, and the client can use it to transfer arbitrary sensitive information to tservice (see the section 2.7).

    4. Attest-Base-Termination
      We can include this ahf if it is the last trr towards the atb. It is recommended way to terminate a atb actively.
      The termination method can be one of the following options:


      This means that the terminated atb can be reused by other clients.


      Specify this method, if the atb should not be reused or shared by any other clients.


      This allows atb to be shared with other clients. Be careful, this method is less safe as the residual data could be exploited and leaked to next client if any.

  2. ahf in response message:

    1. Attest-Binder
      As explained earlier, the httpa/2 uses it to ensure the intauth of both request and response together (see the section 2.6).

    2. Attest-Cargo
      As noted earlier, the tservice can leverage this mechanism to transfer arbitrary sensitive information back to its client (see the section 2.7).

3.5 Protocol Flow

Figure 5: httpa transaction workflow from the client view.

As shown in Figure.5, we illustrate those transactions from client perspective, including preflight, aths, atsp, and trusted request in a workflow diagram. In the design of httpa/2, only the phase of aths is required, which not only largely simplifies the interaction between the client and the tservice, but also improving the ux.

Figure 6: httpa transaction workflow from the tservice view

The Figure.6 shows the workflow, which can help understand how those transactions are distinguished in tservice.

4 Security Considerations

In this section, we discuss security properties and the potential vulnerabilities, as is necessary for understanding httpa/2.

4.1 Layer 7 End-to-End Protection

In cloud computing scenarios, intermediary nodes, such as L7 load balancer or reverse proxy, are used commonly to improve the network performance to deliver the best web experience. However, the great web experience does not come for free. The secure communication based on tls only protects transmitted data hop-by-hop at the layer 5 (L5). The intermediary nodes may need TLS termination to inspect HTTP message in plain text for better network performance. As a consequence, the intermediary nodes can read and modify any HTTP information at L7. Although tls itself is not the problem, but it cannot protect sensitive information above L5 where most Web services are located. That is the gap between L5 and L7 that causes the underlying vulnerability. Therefore, the trust model including intermediary nodes, which are over L5, is problematic [rfc8613], because, in reality, intermediary nodes are not necessarily trustworthy. Intermediary nodes may leak the privacy and manipulate the header lines of http message. Even in the case, where intermediaries are fully trusted, attacker may exploit vulnerability of the hop-by-hop architecture and lead to data breaches. httpa/2 helps protect ahl and the sensitive information of HTTP message end-to-end at L7. As long as the protection does not encrypt the necessary information against proxy operations [rfc8613], httpa/2 can provide guarantees that protected message can survive across middle boxes to reach the endpoint. Especially, httpa/2 provides encryption mechanism at the level of HTTP message, where only the selected information, some header lines or payloads, is encrypted rather than the entire message. Thus, the parts of httpa information without protection may be exploited to spoof or manipulate. If we want to protect every bit of httpa message hop-by-hop, tls is highly recommended in combine with httpa/2 for use. In the implementation, the tservice can make a privacy policy to determine to what degree the httpa message is protected to the L7 endpoint without tls for better network performance. If the message is highly sensitive entirely, tls can come to help in addition, but only up to security of the L5 hop point.

4.2 Replay Protection

A replay attack should be considered in terms of design and implementation. To mitigate replay attack, most AEAD algorithms require a unique nonce for each message. In atr, random numbers are used. In trr, a sequential nonce is used on either endpoints accordingly. Assuming strictly increasing number in sequence, the replay attack can be easily detected if any received number is duplicated or no larger than the previously received number. For reliable transport, the policy can be made to accept only trr with nonce that is equal to the previous number plus one.

4.3 Downgrade Protection

The cryptographic parameters of configuration should be the same for both parties as if there is no presence of an attacker between them. We should always negotiate the preferred common parameters with the peer. If the negotiated parameters of configuration are different for both parties, it could make peers to use a weaker cryptographic mode than the one they should use, thus leading to a potentially downgrade attack [bhargavan2016downgrade]. In httpa/2, tservice uses atq to authenticate its identity and the integrity of the aths to the client. In mhttpa/2, the client uses atq carried by atr for proving its own authenticity and the message integrity. Thus, the communication traffic of the handshake across intermediaries cannot be compromised by attackers.

4.4 Privacy Considerations

Privacy threats are considerably reduced by means of httpa/2 across intermediary nodes. End-to-end access restriction of integrity and encryption on the httpa/2 ahl and payloads, which are not used to block proxy operations, aids in mitigating attacks to the communication between the client and the tservice. On the other hand, the unprotected part of http headers and payloads, which is also intended to be, may reveal information related to the sensitive and protected parts. Then privacy may be leaked. For example, the http message fields visible to on-path entities are only used for the purpose of transporting the message to the endpoint, whereas the ahl and its binding payloads are encrypted or signed. It is possible for attackers to exploit the visible parts of HTTP messages to infer the encrypted information if the privacy preserving policy is not well set up. Unprotected error messages can reveal information of the security state in the communication between the endpoints. Unprotected signaling messages can reveal information of the reliable transport. The length of httpa/2 message fields can reveal information about the message. tservice may use a padding scheme to protect against traffic analysis. After all, httpa/2 provides a new dimension for applications to further protect privacy.

4.5 Roots of Trust (RoT)

Many security mechanisms are currently rooted in software; however, we have to trust underlying components, including software, firmware and hardware. A vulnerability of the components could be easily exploited to compromise the security mechanisms when the rot is broken. One way to reduce that risk of vulnerability is to choose highly reliable rot. rot consists of trusted hardware, firmware, and software components that perform specific, critical security functions [rootoftrust]. rot is supposed to be trusted and more secure, so it is usually used to provide strong assurances for the desired security properties. In httpa/2, the inherent rot is the atb or tee, which provide a firm foundation to build security and trust. With atb being used in httpa/2, we believe that the risks of security and privacy can be greatly reduced.

5 Conclusion

In this paper, we propose the httpa/2 protocol, a major revision of httpa/1. httpa/2 is a layer 7 protocol that builds trusted end-to-end communication between HTTP endpoints. An integral part of httpa/2 is based on confidential computing, e.g., tee, which is used to build the verifiable trust between endpoints with remote attestation. Communication between trusted endpoints is better protected across intermediary nodes which may not have tls protection. This protection helps prevent httpa/2 metadata and the selected HTTP data from being compromised by internal attackers, even with TLS termination.
In addition to security advantage, the httpa/2 also illustrates the performance advantages over httpa/1, as it is not mandatory to enforce tls; hence the overheads of tls can be saved. Furthermore, httpa/2 provides flexibility for service provider to decide which part of the HTTP message is required to be protected. This feature can potentially be leveraged by csp to optimize their networking configuration and service deployment to improve the throughput and response time. With those improvements, the energy of electricity can also be saved as well.

6 Future Work

To further realize httpa/2 into the real world, we will be focused on proof-of-concept (PoC) to demonstrate its validness and soundness. We will apply the PoC codes of httpa/2 to various use cases in practice. Lastly, we plan to release a reference implementation towards generalization to open source. In the future, we expect emerging private AI applications to leverage httpa/2 to deliver its end-to-end trusted service for processing sensitive data and protecting model IP. httpa/2 will enable Trust-as-a-Service (TaaS) for more trustworthy Internet. With httpa/2 and TaaS, Internet users will have freedom of choice to trust, the right to verify assurances, and the right to know the verified details. Users are able to make their decision out of free will based on the faithful results which they consider and choose to believe. It becomes possible that we can build the genuine trust between two endpoints. Thus, we believe that httpa/2 will accelerate the transformation process towards trustworthy Internet for the better digital world.

7 Acknowledgements

We would like to acknowledge the support from the httpa workgroup members, including our partners and reviewers. We thank their valuable feedback and suggestions.

8 Notices & Disclaimers

No product or component can be absolutely secure. [type=]