-
A Survey on Amazon Alexa Attack Surfaces
Authors:
Yanyan Li,
Sara Kim,
Eric Sy
Abstract:
Since being launched in 2014, Alexa, Amazon's versatile cloud-based voice service, is now active in over 100 million households worldwide. Alexa's user-friendly, personalized vocal experience offers customers a more natural way of interacting with cutting-edge technology by allowing the ability to directly dictate commands to the assistant. Now in the present year, the Alexa service is more access…
▽ More
Since being launched in 2014, Alexa, Amazon's versatile cloud-based voice service, is now active in over 100 million households worldwide. Alexa's user-friendly, personalized vocal experience offers customers a more natural way of interacting with cutting-edge technology by allowing the ability to directly dictate commands to the assistant. Now in the present year, the Alexa service is more accessible than ever, available on hundreds of millions of devices from not only Amazon but third-party device manufacturers. Unfortunately, that success has also been the source of concern and controversy. The success of Alexa is based on its effortless usability, but in turn, that has led to a lack of sufficient security. This paper surveys various attacks against Amazon Alexa ecosystem including attacks against the frontend voice capturing and the cloud backend voice command recognition and processing. Overall, we have identified six attack surfaces covering the lifecycle of Alexa voice interaction that spans several stages including voice data collection, transmission, processing and storage. We also discuss the potential mitigation solutions for each attack surface to better improve Alexa or other voice assistants in terms of security and privacy.
△ Less
Submitted 22 February, 2021;
originally announced February 2021.
-
Enhanced Performance and Privacy via Resolver-Less DNS
Authors:
Erik Sy
Abstract:
The domain name resolution into IP addresses can significantly delay connection establishments on the web. Moreover, the common use of recursive DNS resolvers presents a privacy risk as they can closely monitor the user's browsing activities. In this paper, we present a novel HTTP response header allowing web server to provide their clients with relevant DNS records. Our results indicate, that thi…
▽ More
The domain name resolution into IP addresses can significantly delay connection establishments on the web. Moreover, the common use of recursive DNS resolvers presents a privacy risk as they can closely monitor the user's browsing activities. In this paper, we present a novel HTTP response header allowing web server to provide their clients with relevant DNS records. Our results indicate, that this resolver-less DNS mechanism allows user agents to save the DNS lookup time for subsequent connection establishments. We find, that this proposal saves at least 80ms per DNS lookup for the one percent of users having the longest round-trip times towards their recursive resolver. Furthermore, our proposal decreases the number of DNS lookups and thus improves the privacy posture of the user towards the used recursive resolver. Comparing the security guarantees of the traditional DNS to our proposal, we find that resolver-less DNS achieves at least the same security properties. In detail, it even improves the user's resilience against censorship through tampered DNS resolvers.
△ Less
Submitted 13 August, 2019;
originally announced August 2019.
-
Accelerating QUIC's Connection Establishment on High-Latency Access Networks
Authors:
Erik Sy,
Tobias Mueller,
Moritz Moennich,
Hannes Federrath
Abstract:
A significant amount of connection establishments on the web require a prior domain name resolution by the client. Especially on high-latency access networks, these DNS lookups cause a significant delay on the client's connection establishment with a server. To reduce the overhead of QUIC's connection establishment with prior DNS lookup on these networks, we propose a novel QuicSocks proxy. Basica…
▽ More
A significant amount of connection establishments on the web require a prior domain name resolution by the client. Especially on high-latency access networks, these DNS lookups cause a significant delay on the client's connection establishment with a server. To reduce the overhead of QUIC's connection establishment with prior DNS lookup on these networks, we propose a novel QuicSocks proxy. Basically, the client delegates the domain name resolution towards the QuicSocks proxy. Our results indicate, that colocating our proxy with real-world ISP-provided DNS resolvers provides great performance gains. For example, 10% of our 474 sample nodes distributed across ISP's in Germany would save at least 30ms per QUIC connection establishment. The design of our proposal aims to be readily deployable on the Internet by avoiding IP address spoofing, anticipating Network Address Translators and using the standard DNS and QUIC protocols. In summary, our proposal fosters a faster establishment of QUIC connections for clients on high-latency access networks.
△ Less
Submitted 2 July, 2019;
originally announced July 2019.
-
Enhanced Performance and Privacy for TLS over TCP Fast Open
Authors:
Erik Sy,
Tobias Mueller,
Christian Burkert,
Hannes Federrath,
Mathias Fischer
Abstract:
Small TCP flows make up the majority of web flows. For them, the TCP three-way handshake induces significant delay overhead. The TCP Fast Open (TFO) protocol can significantly decrease this delay via zero round-trip time (0-RTT) handshakes for all TCP handshakes that follow a full initial handshake to the same host. However, this comes at the cost of privacy limitations and also has some performan…
▽ More
Small TCP flows make up the majority of web flows. For them, the TCP three-way handshake induces significant delay overhead. The TCP Fast Open (TFO) protocol can significantly decrease this delay via zero round-trip time (0-RTT) handshakes for all TCP handshakes that follow a full initial handshake to the same host. However, this comes at the cost of privacy limitations and also has some performance limitations. In this paper, we investigate the TFP deployment on popular websites and browsers. We found that a client revisiting a web site for the first time fails to use an abbreviated TFO handshake in 40% of all cases due to web server load-balancing using multiple IP addresses. Our analysis further reveals significant privacy problems of the protocol design and implementation. Network-based attackers and online trackers can exploit TFO to track the online activities of users. As a countermeasure, we introduce a novel protocol called TCP Fast Open Privacy (FOP). TCP FOP prevents tracking by network attackers and impedes third-party tracking, while still allowing 0-RTT handshakes as in TFO. As a proof-of-concept, we have implemented the proposed protocol for the Linux kernel and a TLS library. Our measurements indicate that TCP FOP outperforms TLS over TFO when websites are served from multiple IP addresses.
△ Less
Submitted 12 November, 2019; v1 submitted 9 May, 2019;
originally announced May 2019.
-
QUICker connection establishment with out-of-band validation tokens
Authors:
Erik Sy,
Christian Burkert,
Tobias Mueller,
Hannes Federrath,
Mathias Fischer
Abstract:
QUIC is a secure transport protocol that improves the performance of HTTPS. An initial QUIC handshake that enforces a strict validation of the client's source address requires two round-trips. In this work, we extend QUIC's address validation mechanism by an out-of-band validation token to save one round-trip time during the initial handshake. The proposed token allows sharing an address validatio…
▽ More
QUIC is a secure transport protocol that improves the performance of HTTPS. An initial QUIC handshake that enforces a strict validation of the client's source address requires two round-trips. In this work, we extend QUIC's address validation mechanism by an out-of-band validation token to save one round-trip time during the initial handshake. The proposed token allows sharing an address validation between the QUIC server and trusted entities issuing these tokens. This saves a round-trip time for the address validation. Furthermore, we propose distribution mechanisms for these tokens using DNS resolvers and QUIC connections to other hostnames. Our proposal can save up to 50% of the delay overhead of an initial QUIC handshake. Furthermore, our analytical results indicate that 363.6ms in total can be saved for all connections required to retrieve an average website, if a round-trip time of 90ms is assumed.
△ Less
Submitted 3 May, 2019; v1 submitted 12 April, 2019;
originally announced April 2019.
-
Surfing the Web quicker than QUIC via a shared Address Validation
Authors:
Erik Sy
Abstract:
QUIC is a performance-optimized secure transport protocol and a building block of the upcoming HTTP/3 standard. To protect against denial-of-service attacks, QUIC servers need to validate the IP addresses claimed by their clients. So far, the QUIC protocol conducts address validation for each hostname separately using validation tokens. In this work, we review this practice and introduce a new QUI…
▽ More
QUIC is a performance-optimized secure transport protocol and a building block of the upcoming HTTP/3 standard. To protect against denial-of-service attacks, QUIC servers need to validate the IP addresses claimed by their clients. So far, the QUIC protocol conducts address validation for each hostname separately using validation tokens. In this work, we review this practice and introduce a new QUIC transport parameter to allow a shared address validation across hostnames. This parameter indicates to the client, that an issued validation token can be used to abbreviate the address validation when connecting to specific other hostnames. Based on trust-relations between real-world hostnames we evaluate the performance benefits of our proposal. Our results suggest that a shared address validation saves a round-trip time on almost 60% of the required handshakes to different hosts during the first loading of an average website. Assuming a typical transatlantic connection with a round-trip time of 90ms. We find that deploying our proposal reduces the delay overhead to establish all required connections for an average website by 142.2ms.
△ Less
Submitted 22 March, 2019;
originally announced March 2019.
-
Enhanced Performance for the encrypted Web through TLS Resumption across Hostnames
Authors:
Erik Sy,
Moritz Moennich,
Tobias Mueller,
Hannes Federrath,
Mathias Fischer
Abstract:
TLS can resume previous connections via abbreviated resumption handshakes that significantly decrease the delay and save expensive cryptographic operations. For that, cryptographic TLS state from previous connections is reused. TLS version 1.3 recommends to avoid resumption handshakes, and thus the reuse of cryptographic state, when connecting to a different hostname. In this work, we reassess thi…
▽ More
TLS can resume previous connections via abbreviated resumption handshakes that significantly decrease the delay and save expensive cryptographic operations. For that, cryptographic TLS state from previous connections is reused. TLS version 1.3 recommends to avoid resumption handshakes, and thus the reuse of cryptographic state, when connecting to a different hostname. In this work, we reassess this recommendation, as we find that sharing cryptographic TLS state across hostnames is a common practice on the web. We propose a TLS extension that allows the server to inform the client about TLS state sharing with other hostnames. This information enables the client to efficiently resume TLS sessions across hostnames. Our evaluation indicates that our TLS extension provides huge performance gains for the web. For example, about 58.7% of the 20.24 full TLS handshakes that are required to retrieve an average website on the web can be converted to resumed connection establishments. This yields to a reduction of 44% of the CPU time consumed for TLS connection establishments. Furthermore, our TLS extension accelerates the connection establishment with an average website by up to 30.6% for TLS 1.3. Thus, our proposal significantly reduces the (energy) costs and the delay overhead in the encrypted web.
△ Less
Submitted 7 February, 2019;
originally announced February 2019.
-
Tracking Users across the Web via TLS Session Resumption
Authors:
Erik Sy,
Christian Burkert,
Hannes Federrath,
Mathias Fischer
Abstract:
User tracking on the Internet can come in various forms, e.g., via cookies or by fingerprinting web browsers. A technique that got less attention so far is user tracking based on TLS and specifically based on the TLS session resumption mechanism. To the best of our knowledge, we are the first that investigate the applicability of TLS session resumption for user tracking. For that, we evaluated the…
▽ More
User tracking on the Internet can come in various forms, e.g., via cookies or by fingerprinting web browsers. A technique that got less attention so far is user tracking based on TLS and specifically based on the TLS session resumption mechanism. To the best of our knowledge, we are the first that investigate the applicability of TLS session resumption for user tracking. For that, we evaluated the configuration of 48 popular browsers and one million of the most popular websites. Moreover, we present a so-called prolongation attack, which allows extending the tracking period beyond the lifetime of the session resumption mechanism. To show that under the observed browser configurations tracking via TLS session resumptions is feasible, we also looked into DNS data to understand the longest consecutive tracking period for a user by a particular website. Our results indicate that with the standard setting of the session resumption lifetime in many current browsers, the average user can be tracked for up to eight days. With a session resumption lifetime of seven days, as recommended upper limit in the draft for TLS version 1.3, 65% of all users in our dataset can be tracked permanently.
△ Less
Submitted 16 October, 2018;
originally announced October 2018.
