Oi! Not encrypting RPC traffic? IETF bods would like to change that

RPC over TLS: You know it makes sense

An Internet Engineering Task Force group has turned its attention to how Remote Procedure Calls (RPC) travel over the internet, and decided a bit of (easy) encryption is in order.

RPC hasn't been updated in more than a decade, and while an attempt was made to bestow encryption upon it in 2016 (in RFC 7861, RPCSEC), take-up is low.

That's a problem, because even a cursory search turns up dozens of ways to attack RPC, and in the Windows world, RPC implementations are common across all platforms. For example, this vulnerability alone, which landed in April 2018, affected everything back to Windows XP.

Putting RPC behind a wall of encryption would improve more than privacy – it also helps protect the service itself, by removing its direct exposure to the Internet.

So Trond Myklebust (chief Linux kernel maintainer for the Networked File System, NFS) and Charles Lever, Oracle's Linux kernel architect, are having another shot at protecting RPC.

In this Internet-Draft, Myklebust and Lever said the issues that hampered RFC 7861 were: it was relatively difficult to keep per-host costs under control; it left some parts of the RFC header in clear text; it could consume host CPU resources; and was challenging if host identity management and user identity management were in different security domains.


We need to go deeper: Meltdown and Spectre flaws will force security further down the stack


Their alternative is to use a TLS mechanism that “can protect the privacy of each RPC connection transparently to RPC and Upper Layer protocols”.

TLS, they argue, would not only make it easier to develop encrypted RPC, because it would remove overheads like identifying hosts to a trust authority, generating additional keys, or provisioning a secured tunnel for the RCP traffic.

Transport-layer encryption also leaves the upper layer protocol intact, and encryption/decryption can be offloaded to hardware, so CPUs don't have to encrypt or decrypt “large RPC arguments and results”.

The basic unit of operation for RPC over TLS is an authentication flavour called AUTH_TLS, which quite simply indicates whether a server supports encryption.

A server that hasn't implemented TLS will respond with an authentication error, or responds without the STARTTLS string, the client knows it's not supported; otherwise, it will initiate TLS negotiation.

Even users of RPC-over-RDMA are protected, the document notes, because it's a higher-level protocol than TLS.

For environments where other authentication mechanisms have already been deployed, the draft said, they can be left in place and TLS used solely to encrypt traffic. Where RPCSEC is implemented, Kerberos can remain as the authentication mechanism, with TLS replacing the “costly” Generic Security Services (GSS) API's integrity or privacy services. ®

Similar topics

Broader topics

Other stories you might like

  • Stolen university credentials up for sale by Russian crooks, FBI warns
    Forget dark-web souks, thousands of these are already being traded on public bazaars

    Russian crooks are selling network credentials and virtual private network access for a "multitude" of US universities and colleges on criminal marketplaces, according to the FBI.

    According to a warning issued on Thursday, these stolen credentials sell for thousands of dollars on both dark web and public internet forums, and could lead to subsequent cyberattacks against individual employees or the schools themselves.

    "The exposure of usernames and passwords can lead to brute force credential stuffing computer network attacks, whereby attackers attempt logins across various internet sites or exploit them for subsequent cyber attacks as criminal actors take advantage of users recycling the same credentials across multiple accounts, internet sites, and services," the Feds' alert [PDF] said.

    Continue reading
  • Big Tech loves talking up privacy – while trying to kill privacy legislation
    Study claims Amazon, Apple, Google, Meta, Microsoft work to derail data rules

    Amazon, Apple, Google, Meta, and Microsoft often support privacy in public statements, but behind the scenes they've been working through some common organizations to weaken or kill privacy legislation in US states.

    That's according to a report this week from news non-profit The Markup, which said the corporations hire lobbyists from the same few groups and law firms to defang or drown state privacy bills.

    The report examined 31 states when state legislatures were considering privacy legislation and identified 445 lobbyists and lobbying firms working on behalf of Amazon, Apple, Google, Meta, and Microsoft, along with industry groups like TechNet and the State Privacy and Security Coalition.

    Continue reading
  • SEC probes Musk for not properly disclosing Twitter stake
    Meanwhile, social network's board rejects resignation of one its directors

    America's financial watchdog is investigating whether Elon Musk adequately disclosed his purchase of Twitter shares last month, just as his bid to take over the social media company hangs in the balance. 

    A letter [PDF] from the SEC addressed to the tech billionaire said he "[did] not appear" to have filed the proper form detailing his 9.2 percent stake in Twitter "required 10 days from the date of acquisition," and asked him to provide more information. Musk's shares made him one of Twitter's largest shareholders. The letter is dated April 4, and was shared this week by the regulator.

    Musk quickly moved to try and buy the whole company outright in a deal initially worth over $44 billion. Musk sold a chunk of his shares in Tesla worth $8.4 billion and bagged another $7.14 billion from investors to help finance the $21 billion he promised to put forward for the deal. The remaining $25.5 billion bill was secured via debt financing by Morgan Stanley, Bank of America, Barclays, and others. But the takeover is not going smoothly.

    Continue reading

Biting the hand that feeds IT © 1998–2022