Many organisations enhance the performance, security, and functionality of their managed networks by deploying middleboxes centrally as part of their core network. While this simplifies maintenance, it also increases cost because middlebox hardware must scale with the number of clients. A promising alternative is to outsource middlebox functions to the clients themselves, thus leveraging their CPU resources. Such an approach, however, raises security challenges for critical middlebox functions such as firewalls and intrusion detection systems. We describe ENDBOX, a system that securely executes middlebox functions on client machines at the network edge. Its design combines a virtual private network (VPN) with middlebox functions that are hardware-protected by a trusted execution environment (TEE), as offered by Intel's Software Guard Extensions (SGX). By maintaining VPN connection endpoints inside SGX enclaves, ENDBOX ensures that all client traffic, including encrypted communication, is processed by the middlebox. Despite its decentralised model, ENDBOX's middlebox functions remain maintainable: they are centrally controlled and can be updated efficiently. We demonstrate ENDBOX with two scenarios involving (i) a large company; and (ii) an Internet service provider that both need to protect their network and connected clients. We evaluate ENDBOX by comparing it to centralised deployments of common middlebox functions, such as load balancing, intrusion detection, firewalling, and DDoS prevention. We show that ENDBOX achieves up to 3.8× higher throughput and scales linearly with the number of clients.

No abstract

No abstract

CC-BY 4.0. This is the author's version of the work. The definitive version is published in the proceedings of the 2018 1st DSN Workshop on Byzantine Consensus and Resilient Blockchains (DSN-W/BCRB'18).

With the wide-spread use of blockchain technology, Byzantine fault-tolerant (BFT) protocols are explored as a means to achieve consensus on which transactions should be processed next. BFT protocols are not a one-size-fits-all solution: they should be chosen according to the blockchain's use case, which can range from supply chain management to decentralised storage, requiring specialisation e. g. regarding throughput, latency, or level of decentralisation. Previously, consensus protocols were usually hardcoded into the blockchain infrastructure and could not be exchanged, therefore inhibiting flexible use of an otherwise generic blockchain infrastructure. Hyperledger Fabric claims to provide modular consensus and support for crash-fault and Byzantine fault tolerant protocols. However, integrating a BFT protocol has shown that Fabric's architecture is currently not well-suited for this fault model as it requires substantial changes and thereby breaks Fabric's modularity. This also has to be repeated for each integrated BFT protocol.In this paper, we present BLOXY, a blockchain-aware trusted proxy running on the replica that encapsulates all BFT client functionality. BLOXY enables transparent access to generic BFT frameworks and preserves Fabric's modularity even for the Byzantine fault model. It runs inside a trusted execution environment based on Intel's Software Guard Extensions. BLOXY offers blockchain-specific communication mechanisms as well as short-term block storage to handle crashes or disconnects to ensure that all nodes receive block updates. We implemented two BLOXY-based ordering services based on PBFT and the hybrid BFT protocol Hybster. Our evaluation shows that our approach increases the throughput of the ordering component by up to 71 % compared to directly integrated BFT protocols.