Now that HTTPS has become popular on the Internet, HTTPA can come

HTTPS has brought us a more secure and private web. Thanks to it, none of our browsing can be spied on by third parties as it is encrypted. However, if the recipient is a cybercriminal, it does not matter that the path that the data takes is safe, since for example our credentials can end up in plain text in their hands. To improve security and prevent attacks, they are now working on HTTPA.

This new protocol, designed by two Intel workers, Gordon King and Hans Wang, would offer a more secure web thanks to several improvements. In an investigation that they have published this month, they detail all the changes that would offer the so-called HTTPS Attestable, or HTTPA, where Attestable means confirmation or attestation.

HTTPA: secure data at destination
Thus, as its name suggests, this new HTTPA system would allow websites and apps to obtain an additional guarantee that the data sent is being managed by reliable software in a secure environment. To do this, additional certificates and cryptography will be used to ensure that everything is running the way it should, without a hacker, hijacked system, intruder or malware modifying it.

The use of secure execution environments, or Trusted Execution Environments (TEE), takes an important step in improving web security. The move to HTTPS has greatly improved this security, but it is no longer sufficient to guarantee the safe execution of the code. Coincidentally, Intel offers a TEE solution: Software Guard Extensions, or SGX.

With SGX, an application can create so-called enclaves in memory, in which calculations or sensitive information are processed privately in isolation from the rest of the software. This is achieved thanks to the automatic encryption of data and code in memory. Thus, it should be possible to verify that everything that runs in the enclave is what is expected to run.

However, its creators affirm that the protocol is neutral and open to all participants in the technology industry who want to use it. Secure runtime environments have been used in web services in the past, but only in very limited cases and far from widespread use. Therefore, with HTTPA they want to standardize its use.

HTTPA assumes that the client is trusted, and that the server is not. Therefore, the client can use HTTPA to obtain a guarantee that the server can execute the code that the user requests in a safe way. However, HTTPA cannot guarantee that the server as a whole is secure, so we are again faced with limitations similar to those of HTTPS.

HTTPA requires an extension of the handshake process between the two parties. It does this by using three phases: HTTP preflight request and response; HTTP attestation request and response; and HTTP trusted session request and response. The first one checks if the server accepts HTTPA, and the rest are already in charge of the verification and the request to send information.

The researchers also propose the use of Mutual HTTPA, or mHTTPA. This system would be used in the event that a bilateral attestation is necessary from both the client and the server. However, this method can have bandwidth or latency problems, although its creators claim that there should not be much more than with HTTPS.