Topic
SSL acceleration
About: SSL acceleration is a research topic. Over the lifetime, 76 publications have been published within this topic receiving 1497 citations.
Papers published on a yearly basis
Papers
30 Mar 2011
TL;DR: This paper shows that modern graphics processing units (GPUs) can be easily converted to general-purpose SSL accelerators and builds a transparent SSL proxy, SSLShader, that carefully leverages the trade-offs of recent hardware features such as AESNI and NUMA and achieves both high throughput and low latency.
Abstract: Secure end-to-end communication is becoming increasingly important as more private and sensitive data is transferred on the Internet Unfortunately, today's SSL deployment is largely limited to security or privacy-critical domains The low adoption rate is mainly attributed to the heavy cryptographic computation overhead on the server side, and the cost of good privacy on the Internet is tightly bound to expensive hardware SSL accelerators in practiceIn this paper we present high-performance SSL acceleration using commodity processors First, we show that modern graphics processing units (GPUs) can be easily converted to general-purpose SSL accelerators By exploiting the massive computing parallelism of GPUs, we accelerate SSL cryptographic operations beyond what state-of-the-art CPUs provide Second, we build a transparent SSL proxy, SSLShader, that carefully leverages the trade-offs of recent hardware features such as AESNI and NUMA and achieves both high throughput and low latency In our evaluation, the GPU implementation of RSA shows a factor of 226 to 317 improvement over the fastest CPU implementation SSLShader achieves 29K transactions per second for small files while it transfers large files at 13 Gbps on a commodity server machine These numbers are comparable to high-end commercial SSL appliances at a fraction of their price
199 citations
Journal Article•
TL;DR: Simple password authentication is often used e.g. from an email software application to a remote IMAP server, frequently done in a protected peer-to-peer tunnel, e.G. by SSL/TLS.
Abstract: Simple password authentication is often used e.g. from an email software application to a remote IMAP server. This is frequently done in a protected peer-to-peer tunnel, e.g. by SSL/TLS. At Eurocrypt'02, Vaudenay presented vulnerabilities in padding schemes used for block ciphers in CBC mode. He used a side channel, namely error information in the padding verification. This attack was not possible against SSL/TLS due to both unavailability of the side channel (errors are encrypted) and premature abortion of the session in case of errors. In this paper we extend the attack and optimize it. We show it is actually applicable against latest and most popular implementations of SSL/TLS (at the time this paper was written) for password interception. We demonstrate that a password for an IMAP account can be intercepted when the attacker is not too far from the server in less than an hour in a typical setting. We conclude that these versions of the SSL/TLS implementations are not secure when used with block ciphers in CBC mode and propose ways to strengthen them. We also propose to update the standard protocol.
132 citations
Patent•
6 May 2005TL;DR: In this paper, a load balancer detects HTTPS traffic and redirects it to an SSL offloading device for decryption and return to the load-balancer for reencryption, then the re-encrypted traffic is sent to the destination servers in the data center.
Abstract: A data center provides secure handling of HTTPS traffic using backend SSL decryption and encryption in combination with a load balancer such as a content switch. The load balancer detects HTTPS traffic and redirects it to an SSL offloading device for decryption and return to the load balancer. The load balancer then uses the clear text traffic for load balancing purposes before it redirects the traffic back to the SSL offloading device for re-encryption. Thereafter, the re-encrypted traffic is sent to the destination servers in the data center. In one embodiment, the combination with the back-end SSL with an intrusion detection system improves security by performing intrusion detection on the decrypted HTTPS traffic.
98 citations
Proceedings Article•
20 Aug 2014TL;DR: Four new Bleichenbacher side channels are presented, and two of them provide the first timing-based BleichenBacher attacks on SSL/TLS described in the literature, with timing differences between 1 and 23 microseconds.
Abstract: As a countermeasure against the famous Bleichenbacher attack on RSA based ciphersuites, all TLS RFCs starting from RFC 2246 (TLS 1.0) propose "to treat incorrectly formatted messages in a manner indistinguishable from correctly formatted RSA blocks".
In this paper we show that this objective has not been achieved yet (cf. Table 1): We present four new Bleichenbacher side channels, and three successful Bleichenbacher attacks against the Java Secure Socket Extension (JSSE) SSL/TLS implementation and against hardware security appliances using the Cavium NITROX SSL accelerator chip. Three of these side channels are timing-based, and two of them provide the first timing-based Bleichenbacher attacks on SSL/TLS described in the literature. Our measurements confirmed that all these side channels are observable over a switched network, with timing differences between 1 and 23 microseconds. We were able to successfully recover the PreMasterSecret using three of the four side channels in a realistic measurement setup.
93 citations
8 Apr 2001
TL;DR: An algorithmic approach for speeding up SSL's performance on a web server improves the performance of SSL's handshake protocol by up to a factor of 2.5 for 1024-bit RSA keys.
Abstract: We present an algorithmic approach for speeding up SSL's performance on a web server. Our approach improves the performance of SSL's handshake protocol by up to a factor of 2.5 for 1024-bit RSA keys. It is designed for heavily-loaded web servers handling many concurrent SSL sessions. We improve the server's performance by batching the SSL handshake protocol. That is, we show that b SSL handshakes can be done faster as a batch than doing the b handshakes separately one after the other. Experiments show that taking b = 4 leads to optimal results, namely a speedup of a factor of 2.5. Our starting point is a technique due to Fiat for batching RSA decryptions. We improve the performance of batch RSA and describe an architecture for using it in an SSL web server. We give experimental results for all the proposed techniques.
88 citations
Related Topics (5)
Performance Metrics
| Year | Papers |
|---|---|
| 2018 | 1 |
| 2017 | 1 |
| 2016 | 3 |
| 2015 | 4 |
| 2014 | 8 |
| 2013 | 1 |