Many Transport Layer Security (TLS) servers use the ephemeral Diffie-Hellman (DHE) key exchange to support forward secrecy. However, in a survey of 473,802 TLS servers, the authors found that 82.9 percent of the DHE-enabled servers use weak DH parameters, resulting in a false sense of security. They compared the server throughput of various TLS setups, and measured real-world client-side latencies using an advertisement network. Their results indicate that using forward secrecy is no harder, and can even be faster using elliptic curve cryptography (ECC), than no forward secrecy.

We study the security of popular password managers and their policies on automatically filling in Web passwords. We examine browser built-in password managers, mobile password managers, and 3rd party managers. We observe significant differences in autofill policies among password managers. Several autofill policies can lead to disastrous consequences where a remote network attacker can extract multiple passwords from the user's password manager without any interaction with the user. We experiment with these attacks and with techniques to enhance the security of password managers. We show that our enhancements can be adopted by existing managers.

HTML5 changes many aspects in the browser world by introducing numerous new concepts, in particular, the new HTML5 screen sharing API impacts the security implications of browsers tremendously. One of the core assumptions on which browser security is built is that there is no cross-origin feedback loop from the client to the server. However, the screen sharing API allows creating a cross-origin feedback loop. Consequently, websites will potentially be able to see all visible content from the user's screen, irrespective of its origin. This cross-origin feedback loop, when combined with human vision limitations, can introduce new vulnerabilities. An attacker can capture sensitive information from victim's screen using the new API without the consensus of the victim. We investigate the security implications of the screen sharing API and discuss how existing defenses against traditional web attacks fail during screen sharing. We show that several attacks are possible with the help of the screen sharing API: cross-site request forgery, history sniffing, and information stealing. We discuss how popular websites such as Amazon and Wells Fargo can be attacked using this API and demonstrate the consequences of the attacks such as economic losses, compromised account and information disclosure. The objective of this paper is to present the attacks using the screen sharing API, analyze the fundamental cause and motivate potential defenses to design a more secure screen sharing API.

The SSL man-in-the-middle attack uses forged SSL certificates to intercept encrypted connections between clients and servers. However, due to a lack of reliable indicators, it is still unclear how commonplace these attacks occur in the wild. In this work, we have designed and implemented a method to detect the occurrence of SSL man-in-the-middle attack on a top global website, Facebook. Over 3 million real-world SSL connections to this website were analyzed. Our results indicate that 0.2% of the SSL connections analyzed were tampered with forged SSL certificates, most of them related to antivirus software and corporate-scale content filters. We have also identified some SSL connections intercepted by malware. Limitations of the method and possible defenses to such attacks are also discussed.

Timing attacks rely on systems taking varying amounts of time to process different input values. This is usually the result of either conditional branching in code or differences in input size. Using CSS default filters, we have discovered a variety of timing attacks that work in multiple browsers and devices. The first attack exploits differences in time taken to render various DOM trees. This knowledge can be used to determine boolean values such as whether or not a user has an account with a particular website. Second, we introduce pixel stealing. Pixel stealing attacks can be used to sniff user history and read text tokens.

Recent trends in public-key infrastructure research explore the tradeoff between decreased trust in Certificate Authorities (CAs), resilience against attacks, communication overhead (bandwidth and latency) for setting up an SSL/TLS connection, and availability with respect to verifiability of public key information. In this paper, we propose AKI as a new public-key validation infrastructure, to reduce the level of trust in CAs. AKI integrates an architecture for key revocation of all entities (e.g., CAs, domains) with an architecture for accountability of all infrastructure parties through checks-and-balances. AKI efficiently handles common certification operations, and gracefully handles catastrophic events such as domain key loss or compromise. We propose AKI to make progress towards a public-key validation infrastructure with key revocation that reduces trust in any single entity.

To encourage users to use stronger and more secure passwords, modern web browsers offer users password management services, allowing users to save previously entered passwords locally onto their hard drives. We present Lupin, a tool that automatically extracts these saved passwords without the user's knowledge. Lupin allows a network adversary to obtain passwords as long as the login form appears on a non-HTTPS page. Unlike existing password sniffing tools, Lupin can obtain passwords for websites users are not visiting. Furthermore, Lupin can extract passwords embedded in login forms with a destination address served in HTTPS. To determine the number of websites vulnerable to our attack, we crawled the top 45,000 most popular websites from Alexa's top website list and discovered that at least 28% of these sites are vulnerable. To further demonstrate the feasibility of our attack, we tested Lupin under controlled conditions using one of the authors' computers. Lupin was able to extract passwords from 1,000 websites in less than 35 seconds. We suggest techniques for web developers to protect their web applications from attack, and we propose alternative designs for a secure password manager.

Web Intents are a new web collaboration framework intended to bring the benefits of Android’s Intent model to the web. Web Intents are currently implemented as a JavaScript shim, supporting several major localStorageenabled browsers. A prototype native implementation is under development for Google Chrome. While Android’s Intent model has previously been the subject of significant security review, Web Intents has not yet received similar scrutiny. In this paper, we present several attacks on the prototype implementations of Web Intents. We have communicated our recommendations on mitigating these attacks to the Web Intents developers. Our concerns have been acknowledged by the developers and several of our suggestions were adopted.

Widespread growth of open wireless hotspots has made it easy to carry out man-in-the-middle attacks and impersonate web sites. Although HTTPS can be used to prevent such attacks, its universal adoption is hindered by its performance cost and its inability to leverage caching at intermediate servers (such as CDN servers and caching proxies) while maintaining end-to-end security. To complement HTTPS, we revive an old idea from SHTTP, a protocol that offers end-to-end web integrity without confidentiality. We name the protocol HTTPi and give it an efficient design that is easy to deploy for today's web. In particular, we tackle several previously-unidentified challenges, such as supporting progressive page loading on the client's browser, handling mixed content, and defining access control policies among HTTP, HTTPi, and HTTPS content from the same domain. Our prototyping and evaluation experience show that HTTPi incurs negligible performance overhead over HTTP, can leverage existing web infrastructure such as CDNs or caching proxies without any modifications to them, and can make many of the mixed-content problems in existing HTTPS web sites easily go away. Based on this experience, we advocate browser and web server vendors to adopt HTTPi.

Since the early days of Netscape, browser vendors and web security researchers have restricted out-going data based on its destination. The security argument accompanying these mechanisms is that they prevent sensitive user data from being sent to the attacker’s domain. However, in this paper, we show that regulating web information flow based on its destination server is an inherently flawed security practice. It is vulnerable to self-exfiltration attacks, where an adversary stashes stolen information in the database of a whitelisted site, then later independently connects to the whitelisted site to retrieve the information. We describe eight existing browser security mechanisms that are vulnerable to these “self-exfiltration” attacks. Furthermore, we discovered at least one exfiltration channel for each of the Alexa top 100 websites. None of the existing information flow control mechanisms we surveyed are sufficient to protect data from being leaked to the attacker. Our goal is to prevent browser vendors and researchers from falling into this trap by designing more systems that are vulnerable to self-exfiltration.

The Online Certificate Status Protocol (OCSP) is as good as dead. It imposes a massive performance penalty on web traffic and has failed to mitigate the recent high-profile certificate security breaches of certificate authorities. Citing these fundamental protocol flaws, Google Chrome, one of the world’s most popular browsers, is permanently disabling OCSP and taking direct ownership over certificate revocation. We will soon be living in a post-OCSP world where Google has become a single point of failure for certificate validation. We argue that certificate authorities should reassert control over the certificate revocation process by issuing certificates with a very short lifetime. These certificates complement browser-based revocation by allowing certificate authorities to revoke certificates without the cooperation of browser vendors, and without imposing a performance penalty on web traffic. We have implemented a prototype certificate authority and certificate update plugin for Apache that demonstrates feasibility of short-lived certificates. We have also implemented client-side pinning to short-lived certificates in the Chromium browser. Finally, we show that short-lived certificates complement browserbased revocation and address its major limitations; the two mechanisms can be combined to achieve secure, performant, and backwards-compatible browsing experience on the web.

Clickjacking attacks are an emerging threat on the web. In this paper, we design new clickjacking attack variants using existing techniques and demonstrate that existing clickjacking defenses are insufficient. Our attacks show that clickjacking can cause severe damages, including compromising a user's private webcam, email or other private data, and web surfing anonymity. We observe the root cause of clickjacking is that an attacker application presents a sensitive UI element of a target application out of context to a user (such as hiding the sensitive UI by making it transparent), and hence the user is tricked to act out of context. To address this root cause, we propose a new defense, InContext, in which web sites (or applications) mark UI elements that are sensitive, and browsers (or OSes) enforce context integrity of user actions on these sensitive UI elements, ensuring that a user sees everything she should see before her action and that the timing of the action corresponds to her intent. We have conducted user studies on Amazon Mechanical Turk with 2064 participants to evaluate the effectiveness of our attacks and our defense. We show that our attacks have success rates ranging from 43% to 98%, and our InContext defense can be very effective against the clickjacking attacks in which the use of clickjacking is more effective than social engineering.

A key bottleneck in a full TLS handshake is the need to fetch and validate the server certificate before establishing a secure connection. We propose a mechanism by which a browser can prefetch and prevalidate server certificates so that by the time the user clicks on an HTTPS link, the server’s certificate is immediately ready to be used. Combining this with a recent proposal called Snap Start reduces the TLS handshake to zero round trips. Prefetching and prevalidating certificates improves web security by making it less costly for websites to enable TLS and by removing time pressure from the certificate validation process. We implemented prefetching and prevalidation and studied the effects of four different prefetching strategies on server performance. Along the way we conducted a study of OCSP, a certificate validation mechanism. This data enabled us to evaluate the effectiveness of prefetching and prevalidating in reducing TLS handshake latency. In some cases we show a factor of four speed-up over a full TLS handshake.

Recent trends in public-key infrastructure research explore the tradeoff between decreased trust in certificate authorities (CAs), the level of security achieved, the communication overhead (bandwidth and latency) for setting up a secure connection (e.g., verified via SSL/ TLS), and the availability with respect to verifiability of public key information. In this paper, we propose TKI as a new public-key validation infrastructure, where we reduce the level of trust in any CA and increase the security by achieving increased robustness in the case of CA key compromise. Compared to other proposals, we reduce the communication overhead associated with certificate validation during the existing SSL/TLS connection handshake and provide site owners with an optional time window to review potentially malicious key changes. Our design deters CA misbehavior by using a public log that records all certificate events, thereby enabling CAs’ accountability for their actions. TKI will help reduce the trust in the hundreds of currently trusted CAs, reduce exposure to CA compromise, and enhance the security of SSL/TLS connection establishment.