HTTPA: HTTPS Attestable Protocol

by   Gordon King, et al.

Hypertext Transfer Protocol Secure (HTTPS) protocol has become integral part of the modern internet technology. It is currently the primary protocol for commercialized web applications. It can provide a fast, secure connection with a certain level of privacy and integrity, and it has become a basic assumption on most web services on the internet. However, HTTPS cannot provide security assurances on the request data in compute, so the computing environment remains uncertain risks and vulnerabilities. A hardware-based trusted execution environment (TEE) such as Intel Software Guard Extension (SGX) provides in-memory encryption to help protect the runtime computation to reduce risks of illegal leaking or modifying private information. The central concept of SGX enables the computation happening inside the enclave, a protected environment that encrypts the codes and data pertaining to a security-sensitive computation. In addition, SGX provides provide security assurances via remote attestation to the web client, including TCB identity, vendor identity and verification identity. Here we propose a HTTP protocol, called HTTPS Attestable (HTTPA), by including remote attestation process onto the HTTPS protocol to address the privacy and security concerns on web and the access over the Internet. With HTTPA, we can provide security assurances to establish trustworthiness with web services and ensure integrity of request handling for web users. We expect that remote attestation will become a new trend adopted to reduce web services security risks, and propose the HTTPA protocol to unify the web attestation and accessing services in a standard and efficient way.



page 4


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

We received positive feedback and inquiries on the previous work of HTTP...

BliMe: Verifiably Secure Outsourced Computation with Hardware-Enforced Taint Tracking

We present Blinded Memory (BliMe), a way to realize efficient and secure...

Who ya gonna call? (Alerting Authorities): Measuring Namespaces, Web Certificates, and DNSSEC

During disasters, crisis, and emergencies the public relies on online se...

A Survey of HTTPS Traffic and Services Identification Approaches

HTTPS is quickly rising alongside the need of Internet users to benefit ...

Why the Equifax Breach Should Not Have Mattered

Data security, which is concerned with the prevention of unauthorized ac...

Integrating Remote Attestation with Transport Layer Security

Intel(R) Software Guard Extensions (Intel(R) SGX) is a promising technol...

Accountable Javascript Code Delivery

The Internet is a major distribution platform for applications, but ther...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Privacy is deeply rooted in human rights as principles or even law. With recent hacks and breaches, more online consumers are aware of their private data being at risk. They have no much effective control over it. Cybersecurity anxiety is the new norm for our time. The demands for cybersecurity and data privacy are rising. There are many interrelated efforts to protect sensitive data at rest, in transit, and in compute. Many of them has been applied to cloud, web service and online business. Hypertext Transfer Protocol Secure (HTTPS) [uptls, https] is widely used to secure request data in motion, but the user data may be at risk i.e. data breach if the processing code is not fully isolated from everything else including the operating system on the host machine. A hardware-based TEE such as Intel© SGX enclave is specifically designed for this concern. Remote system or user can get evidence through attestation to verify a trusted computing base (TCB) identity and state of TEE. Note that TCB includes hardware, firmware, and software to enforce security policy while TEE provides an application with the secure isolation in run time on TCB. Most of existing TEE solutions for protecting web services are very narrowly fit for addressing specific domain problems [selvi2014bypassing]. We propose a general solution to standardize attestation over HTTPS and establish multiple trusted connections to protect and manage requested data for selected HTTP [httpmr] domains. Also, our solution leverage the current HTTPS protocol, so it does not introduce much complexity as other approaches [amann2017mission]. This paper first discusses threat modeling, then goes on to constructing a new protocol for attestation over HTTPS, which is called HTTPS Attestable (HTTPA). We hope this protocol can be considered as new standard in respond to current Web security concerns. Lastly, we suggest that there are two operation modes of it to discover.

2 Threat Modeling

HTTPA is designed to provide assurances for remote attestation and confidential computing between a client and a server under the use case of World Wide Web (WWW) over Internet. For one-way HTTPA, we assume the client is trusted and the sever is not trusted, so the client wants to attest the server to establish trust. The client user can verify those assurances to decide whether they can trust to run the compute workloads on the non-trusted server or not. However, HTTPA does not provide guarantees to turn the server into being trustful. HTTPA involves two parts: communication and computation. Regarding communication security, HTTPA inheres all the assumptions of HTTPS for secure communication, including using TLS and verifying the host identity via certificate. Regarding computation security, HTTPA protocol requires providing further assurance status of remote attestation for the computing workloads to run inside the secure enclave, so the client user can run the workloads in encrypted memory with proved enclave and proved TCB). As such, attack surface of the compute is the secure enclave itself, and everything outside the secure enclave is not trusted. We assume that attackers on the server end have privilege access to the system with the ability to read, write, delete, replay and tamper with the workloads on the un-encrypted memory. On the other hand, we assume software running inside the enclave is trusted if its certificate passes the client user’s verification. Furthermore, HTTPA protocol requires that software vendor identity, TCB, quote verification provider’s identity are verifiable, so the protocol allows the client user to only trust what it agrees to trust by making its custom allowed list and denied list. Also, the HTTPA provides an assurance to confirm the client’s workloads to run inside the expected enclave with expected verified software. As such, users can confirm their workloads are running inside the expected secure enclave in the remote and have the right to reject the computation when the verification results does not meet their security requirements. Running inside the secure enclave can significantly reduce the risks for user’s codes or data to be read or modified by the attack from outside the enclave. Therefore, HTTPA can further reduce attack surface of HTTPS from the whole host system to the secure enclave. Lastly, HTTPA provides freedom for users to determine whether they agree with the assurances results or not before proceeding to the computation and thus further reduces cyber-security risks.

3 Problem Statement

Currently, many software services are vulnerable, there is no sufficient assurance for the computing workloads and the communication among them. We argue that the current HTTPS is not sufficient at all to build the fundamental trust with users, so most people’s private information and digital assets are under great risks. Although we cannot solve the fundamental problem fully, but we can provide assurance to effectively reduce risks. We propose attestation-based assurance protocol to rescue.

4 HTTPS Attestable (HTTPA) Protocol

In this section, we first describe the standard HTTPS protocol on which we build our solution to establish an initial secure channel between the web server and the client. Then, we present the HTTPA protocol by adding a new HTTP method [httpsc] of attestation to establish multiple trusted channels. The new method unifies attestation [remoteattestsrv, dcapattest] and web access operations together for web applications in a general way.

4.1 Standard HTTP over TLS

The primary purpose of TLS [tls] is to protect web application data from unauthorized disclosure and modification when it is transmitted between the client and the server. The HTTPS/TLS security model uses “certificate” to ensure authenticity. The certificate is cryptographically “signed” by a trusted certificate authority (CA) [cmp]. It is the current standard practice for communication over Internet,

Figure 1: An overview of standard HTTPS (HTTP over TLS) handshake process.

Fig 1 shows the HTTPS handshake mechanism. In HTTPS, the communication protocol is encrypted using TLS. It provides authentication of the server to the client as well as integrity guarantees, forward secrecy and replay prevention. but it does not offer any of these security benefits to data that is in compute and at rest. Therefore, the request handling codes running in an untrusted environment which may expose sensitive data to attackers is not trusted. The client user cannot have enough confidence about their private information without being disclosed while the monitoring/notification processes are also running in an untrusted environment, as shown in Fig 1(a).

Fig 1(a) shows the possible attacks if only using HTTPS to protect the request data sent by remote web user or system. they can validate a certificate that represents the specific domain. To authorize a runtime environment is extremely difficult if not well protected by a hardware-based TEE because it is constantly changing. Therefore, the session keys, private key and cleartext are possible to be revealed if they are handled in untrusted environment.

4.2 Attestation over HTTPS

The Intel© SGX technology [intelsgx] is designed to provide hardware-based TEE to reduce the TCB and protect private data in compute. Smaller TCB implies reducing more security risks, because it reduces the exposure to various attacks and reduce the surface of vulnerability. Also, it can use an attestation service to establish a trusted channel. With hardware-based TEE, attestation mechanism can help rigorously verify the TCB integrity, confidentiality and identity. We propose to use remote attestation as the core interface for web users or web services to establish trust as a secure trusted channel to provision secrets or sensitive information. To achieve this goal, we add a new set of HTTP methods, including HTTP preflight [preflight] request/response, HTTP attest request/response, HTTP trusted session request/response, to realize remote attestation which can allow web users and the web services for a trusted connection directly with the code running inside the hardware-based TEE, as shown in 1(b)

(a) The current security status on the Internet by using HTTPS, which provides untrusted but secure service access. The attacker can perform privilege escalation attack to the server to hack the session. Once the attack obtains the secret session, the attacker can compromise the secure channel between the server and the client by using the key to decrypt packets.
(b) The possible future security status on the Internet by using the proposed HTTPA, which provides trusted and secure service access. The attacker cannot easily hack the session keys inside the secure enclave even though it has the privilege access to the server. Therefore, it is more difficult for the attacker to compromise the privacy and integrity of the client’s data on the server.
Figure 2: The proposed HTTPA protocol provides HTTP attestation methods to establish a trusted channel on top of the secure channel of HTTPS. Therefore, the HTTPA protocol significantly reduces the risks of exposing sensitive data than HTTPS does.
Figure 3: The proposed HTTPA supports establishing multiple trusted channels on top of the same secure channel as a scalable solution to the current Internet use case.

The TLS protocol supports the modification of the existing secure channel with the new server certificate and ciphering parameter; there are some efforts on exploring the way to weave attestation process into TLS layer [knauth2019integrating] [bhardwaj2018spx]; however, our method doesn’t rely on it replacing existing secure channel with trusted channel. The main reason is to allow creating multiple trusted channels inside a single TLS-secure channels, as shown in Fig 3.

Fig 4 shows the overview of proposed HTTPA handshake process. The HTTPA handshake process consists of three stages: HTTP preflight request/response, HTTP attestation request/response and HTTP trusted session request/response. HTTP preflight request/response will check whether the platform is attestation available, as shown in Fig 5, has nothing to do with security, and they have no bearing on web application. Rather, the preflight mechanism benefits servers that were developed without an awareness of HTTPA, and it functions as a sanity check between the client and the server that they are both HTTPA-aware. the following attestation request is not simple request, for that, having preflight requests is kind of a ”protection by awareness”. HTTP attestation request/response can provide the quote and quote verification features. HTTP trusted session request/response can establish a trusted session to protect HTTPA traffics in which only the verified TCB codes can see the request data. A trusted session which creates a trusted channel begins with session key generated and end with destroy of it. The trusted session can temporarily store information related to the activities of HTTPA while connected. We describe our HTTPA in terms of one-way HTTPA and mutual HTTPA (mHTTPA) in details in the following sections.

Figure 4: An overview of the proposed HTTPA protocol. The HTTPA protocol consists of three sets of HTTP methods, including HTTP preflight request/response, HTTP attest request/response, and HTTP trusted session request/response.
Figure 5: Following Figure 4, we specifically show how HTTP preflight request/response works in details. First client sends out HTTP preflight request to confirm whether the server has attestation capability. If the server does not have attestation capability, it responds with no content. Then the communication between the server and the client stops, because the server does not have capability to provide trusted assurances. If the server has attestation capability, it responds with OK to allow further attestation method to proceed.

4.3 One-way HTTPA

One-way HTTPA protocol is built on top of standard HTTPS. In this case, only client validates the server to ensure that it receives data from the expected TCB and its hosting server. Our methodology is to perform the HTTP attestation handshake over the established secure channel of HTTPS. Our one-way HTTPA is described as follows. The client and server establish a secure channel if the preflight request for each domain is successful. Preflight request checks if the attestation protocol is accepted by the server for using the “ATTEST” method and headers. It is an “OPTIONS request”, using one HTTP request headers: Access-Control-Request-Method. Following the preflight request/response, a new set of HTTP method is proposed to handle attestation message exchange, as shown in Fig 6. The set of HTTP methods includes HTTP attest request, HTTP attest response, HTTP trusted session request, HTTP trusted session response

First, HTTP attest request is generated by the client, using three new HTTP request headers as follows:

  1. Attest-Date
    This item contains the date and time at which the attestation quote material was generated on the client side. This is optional for one-way HTTPA protocol.

  2. Attest-session-ID
    A unique string identifies a session, Here it’s empty/null. If we had previously connected to a TEE a few seconds ago, we could potentially resume a session and avoid a full attestation handshake to happen again.

  3. Attest-Random
    This is a set of random bytes generated by the client for key derivation.

  4. Attest-Cipher-Suites
    This is a list of all of the encryption algorithms that the client is willing to support.

Second, the server will provide the received random bytes to the TEE once it got created and be ready to accept requests. The following is the HTTP attest response, including the headers.

  1. Attest-Date
    The date and time at which the attestation quote material was generated on server side.

  2. Attest-Quote
    This item contains a quote that was generated by a TCB hosting web service that will handle HTTPA request to the domain in question. the max-age indicates how long the results of ATTEST request can be cached.

  3. Attest-Pubkey
    This item contains a public key that was generated inside the TEE for exchanging secret keys. Its paired private key should never leave its TEE. In addition, it needs to be bound to the identity of its TCB, so the fingerprint of the public key should be carried by its TCB quote as payload, see Fig 7

  4. Attest-Random
    This item contains random bytes generated by the server. This will be used later.

  5. Attest-Session-Id
    The session id is generated by web service running inside the TEE of the server.

  6. Attest-Cipher-Suite
    This is an encryption algorithm picked by the server for trusted channel encryption.

Third, the client uses the received public key of TEE to wrap a secret which is the pre-session. The wrapped pre-session secret is later used for the key derivation. The web application should send the wrapped pre-session secret directly into the web service TEE, because the secret can only be unwrapped by its paired private key inside the TEE of the web service. HTTP trusted session request includes the following headers:

  1. Attest-Secret
    Contains a pre-session secret wrapped by server-side TEE public key.

Figure 6: Following Figure 5, we further show the details of HTTP attest request/response, and HTTP trusted session request/response. After confirming the server’s capability to provide attestation, the client sends HTTP attest request to the server, which includes client’s random bytes, cipher suites and meta information. The server generates the quote and sends HTTP attest response to respond to the client with its quote, random bytes, chosen cipher algorithm, and the meta information. Note that the server must create an enclave before it generates and sends out the quote, and the quote contains TEE’s public key, enclave identity measurements, vendor identity measurements, and etc. as assurances for the client to verify. The client received the quote and send the quote to the third party for quote verification. Note that quote verification is not part of the protocol. If the quote verification process by third party is not successful, the communication stops, because the client does not agree with the assurances from the quote. If the quote verification process is successful, and the client agrees with the verified results, the client sends HTTP trusted session request to the server with the secret which is the pre-session secret wrapped by the TEE public key, this HTTP request is used to provision the materials and notify service side of trust session keys generation. The server receives the secret of the wrapped pre-session secret and reply with the confirmation of HTTP trusted session response. For key derivation process, both parties use the pre-session secret and the random bytes of both sides to calculate the trusted session keys. Once the trusted session keys are derived in their own TEEs respectively, both sides establish trusted channel to communicate via the trusted session keys. Note that the trusted session keys never leave their TEE.

In the last step, HTTP trusted session response confirms the pre-session secret has been received by the server.

Thus far, both server and client sides (and only those sides) have a pre-session secret. Each party can calculate the “trusted session keys”, which is derived from the pre-session secret and the random bytes of both parties. To create the trusted session keys, including MAC keys, encryption keys and the IV for cipher block initialization, we need to use PRF, the “Pseudo-Random Function”, to create a ”key block” where we pull data from:

key_block = PRF(pre_session_secret,
                    "trusted session keys",
                    ClientAttest.random + ServerAttest.random)

The pre-session secret is the secret we sent earlier, which is simply an array of bytes. We then concatenate the random bytes sent via HTTP attest request/response from both server and client sides. We use PRF to combine the secrets with the concatenated random bytes from both server/client sides. The bytes from ”key block” are used to populate the following:


The use of Initialization Vectors (IVs) depends on which cipher suite selected at very beginning. Therefore, we need two Message Authentication Code (MAC) keys for each side. In addition, the encrypt keys that both sides will need as well. Both sides will use those trusted session keyss to make sure the encrypted request data haven’t been tampered with as well as only can be seen by the request handlers running in attested TCB.

Figure 7: The summary of the primary steps of HTTPA, including quote generation, third-party quote verification, obtaining TEE’s public key, pre-session secret to establish the trusted channel between the server and the client.

The client needs to verify the server quote to establish the trustworthiness with the platform, including verifying integrity of the codes running inside the TCB of web services. Usually, there are authorities offers such services, the client can request trusted attestation service to verify the server quote. A verifier quote may be returned to the client along with the verification result, thus, the client side can collect several identities to make a decision, the router, shown in Fig. 7, could be placed in untrusted part of web application to route service requests corresponding to HTTP header, the web applications is expected to create multiple isolated TCB to confidentially handle different kind of requests.

  1. Domain identity
    It is the identity issued by a Certificate Authority (CA), and it is used in TLS protocol

  2. TCB identity
    It is the identity of web service TCB, measured by hardware and it is embedded in a quote.

  3. Vendor identity
    It is a signing identity of web service provided by a CA, which signs the TCB prior to distribution

  4. Verifier identity
    The identity is received from a attestation service along with attesting result.

All those identities need to be validated by verifying their certificate chain. The user can selectively add any combinations of them to allowed list or denied list.

4.4 Mutual HTTPA (mHTTPA)

In addition to one-way HTTPA protocol, HTTPA includes another direction, so both client and server attest each other to ensure that both parties involved in the communication are trusted. Both parties share their quotes on which the verification and validation are performed.

Fig. 8 shows the handshake process of mHTTPA protocol. Compared to one-way HTTPA, see Fig. 6, the difference is that client will send its quote and its TEE public key to server in the first request to allow the server for verifying the quote, and then send a service quote back as response if the client quote got attested.

Figure 8: Comparing with Figure 6, the major difference of mHTTPA from one-way HTTPA is the step of HTTP attest request. After confirming the server’s capability to provide attestation described in Figure 5, the client generates its own quote for the server to verify. Then the client sends HTTP attest request to the server , which includes client’s generated quotes, TEE public key, random bytes, cipher suites and meta information. Then the server verifies the quote of the client. If client’s quote is not verified successfully, the communication stops. If the quote is verified successfully, the server generates its quote. Then the server sends HTTP attest response to respond to the client with server’s quote, TEE public key, random bytes, chosen cipher algorithm, and the meta information. After this part, the remaining steps follow the same as described in Figure 6 for each party.

There is a slight change to the key block generation as well, for now, both sides need to include two pre-session secrets for deriving session keys in their own TEEs respectively.

key_block = PRF(server_pre_session_secret, client_pre_session_secret,
                    "trusted mutual session keys",
                    ClientAttest.random + ServerAttest.random)

5 Conclusion

We demonstrate the proposed HTTPA protocol where attestation is used to provide assurances that a web service is properly instantiated on a trusted platform. We believe that we can reduce security risks by considering those assurances. The remote web user or system can then gain confidence that only such intended request handlers are running on the trusted hardware. This paper presents the HTTPA as a new protocol to unify the attestation process and HTTPS along with establishing a trusted channel over HTTPS for web service access in a standard and efficient way.