Understanding Flaws in the Deployment and Implementation of Web Encryption

In recent years, the web has switched from using the unencrypted HTTP protocol to using encrypted communications. Primarily, this resulted in increasing deployment of TLS to mitigate information leakage over the network. This development has led many web service operators to mistakenly think that migrating from HTTP to HTTPS will magically protect them from information leakage without any additional effort on their end to guar- antee the desired security properties. In reality, despite the fact that there exists enough infrastructure in place and the protocols have been “tested” (by virtue of being in wide, but not ubiquitous, use for many years), deploying HTTPS is a highly challenging task due to the technical complexity of its underlying protocols (i.e., HTTP, TLS) as well as the complexity of the TLS certificate ecosystem and this of popular client applications such as web browsers. For example, we found that many websites still avoid ubiquitous encryption and force only critical functionality and sensitive data access over encrypted connections while allowing more innocuous functionality to be accessed over HTTP. In practice, this approach is prone to flaws that can expose sensitive information or functionality to third parties. Thus, it is crucial for developers to verify the correctness of their deployments and implementations. In this dissertation, in an effort to improve users’ privacy, we highlight semantic flaws in the implementations of both web servers and clients, caused by the improper deployment of web encryption protocols. First, we conduct an in-depth assessment of major websites and explore what functionality and information is exposed to attackers that have hijacked a user’s HTTP cookies. We identify a recurring pattern across websites with partially de- ployed HTTPS, namely, that service personalization inadvertently results in the exposure of private information. The separation of functionality across multiple cookies with different scopes and inter-dependencies further complicates matters, as imprecise access control renders restricted account functionality accessible to non-secure cookies. Our cookie hijacking study reveals a number of severe flaws; for example, attackers can obtain the user’s saved address and visited websites from e.g., Google, Bing, and Yahoo allow attackers to extract the contact list and send emails from the user’s account. To estimate the extent of the threat, we run measurements on a university public wireless network for a period of 30 days and detect over 282K accounts exposing the cookies required for our hijacking attacks. Next, we explore and study security mechanisms purposed to eliminate this problem by enforcing encryption such as HSTS and HTTPS Everywhere. We evaluate each mechanism in terms of its adoption and effectiveness. We find that all mechanisms suffer from implementation flaws or deployment issues and argue that, as long as servers continue to not support ubiquitous encryption across their entire domain, no mechanism can effectively protect users from cookie hijacking and information leakage. Finally, as the security guarantees of TLS (in turn HTTPS), are critically dependent on the correct validation of X.509 server certificates, we study hostname verification, a critical component in the certificate validation process. We develop HVLearn, a novel testing framework to verify the correctness of hostname verification implementations and use HVLearn to analyze a number of popular TLS libraries and applications. To this end, we found 8 unique violations of the RFC specifications. Several of these violations are critical and can render the affected implementations vulnerable to man-in-the-middle attacks

TorSNIP Hidden Service Proxy with End-to-End Security

The onion router (Tor) is a software that provides an opportunity to access the blocked content over the Internet. It also provides anonymity to its users with the help of a protocol called Hidden Service (HS) protocol. It provides the ability to the users to conduct confidential communication without the possibility of getting trace back. It allows the operators to publish anonymous content without compromising their anonymity. The ‘.onion’ address can only be accessed using Tor browser. To access the HS with a regular Internet browser, for example, Google Chrome, Firefox etc., a service called Tor2web is used. It is a proxy server, which receives the user’s request and forwards it to the targeted HS. The main issue identified in this service is that the service is not end-to-end secure and is prone to various attacks including content injection and content modification. One of the possible solutions to this problem is to make an HTTPS connection directly to the onion site, rather than decrypting the packet at the intermediate node. This could make the communication secure from the user’s browser until termination at the onion site i.e. makes it end-to-end secure. This is achievable with the deployment of TLS’s Server Name Indication (SNI), which identifies the server name in the initial request. The idea is to register a domain name and add an ‘A’ and ‘AAAA’ records and get a valid certificate from the certificate authority. Then create a hidden service and obtain its onion address. Map an onion:domain address and obtain a valid certificate for it. Modify the SNI script file according to the requirements and update the ‘Table’ field in the script. Finally, choose a virtual port and delegate the onion service name and all subsequent packets to the targeted hidden service

TLS/PKI Challenges and certificate pinning techniques for IoT and M2M secure communications

Transport Layer Security is becoming the de facto standard to provide end-to-end security in the current Internet. IoT and M2M scenarios are not an exception since TLS is also being adopted there. The ability of TLS for negotiating any security parameter, its flexibility and extensibility are responsible for its wide adoption but also for several attacks. Moreover, as it relies on Public Key Infrastructure (PKI) for authentication, it is also affected by PKI problems. Considering the advent of IoT/M2M scenarios and their particularities, it is necessary to have a closer look at TLS history to evaluate the potential challenges of using TLS and PKI in these scenarios. According to this, the article provides a deep revision of several security aspects of TLS and PKI, with a particular focus on current Certificate Pinning solutions in order to illustrate the potential problems that should be addressed

Analysis of the adoption of security headers in HTTP.

With the increase in the number of threats within Web-based systems, a more integrated approach is required to ensure the enforcement of security policies from the server to the client. These policies aim to stop man-in-the-middle attacks, code injection, and so on. This paper analyses some of the newest security options used within HTTP responses, and scans the Alexa Top 1 Million sites for their implementation within HTTP responses. These options scanned for include: Content Security Policy (CSP); Public Key Pinning Extension for HTTP (HPKP); HTTP Strict Transport Security (HSTS) and HTTP Header Field X-Frame-Options (XFO), in order to understand the impact that these options have on the most popular Web sites.The results show that, while the implementation of the parameters are increasing, they are still not implemented on many of the top sites. Along with this the paper shows the profile of adoption of Let’s Encrypt digital certificates across the one million sites, along with a way of assessing the quality of the security headers

"I Have No Idea What I'm Doing" - On the Usability of Deploying HTTPS

Protecting communication content at scale is a difficult task, and TLS is the protocol most commonly used to do so. However, it has been shown that deploying it in a truly secure fashion is challenging for a large fraction of online service operators. While Let’s Encrypt was specifically built and launched to promote the adoption of HTTPS, this paper aims to understand the reasons for why it has been so hard to deploy TLS correctly and studies the usability of the deployment process for HTTPS. We performed a series of experiments with 28 knowledgable participants and revealed significant usability challenges that result in weak TLS configurations. Additionally, we conducted expert interviews with 7 experienced security auditors. Our results suggest that the deployment process is far too complex even for people with proficient knowledge in the field, and that server configurations should have stronger security by default. While the results from our expert interviews confirm the ecological validity of the lab study results, they additionally highlight that even educated users prefer solutions that are easy to use. An improved and less vulnerable workflow would be very beneficial to finding stronger configurations in the wild

TLS on Android – Evolution over the last decade

Mobile Geräte und mobile Plattformen sind omnipräsent. Android hat sich zum bedeutendsten mobilen Betriebssystem entwickelt und bietet Milliarden Benutzer:innen eine Plattform mit Millionen von Apps. Diese bieten zunehmend Lösungen für alltägliche Probleme und sind aus dem Alltag nicht mehr wegzudenken. Mobile Apps arbeiten dazu mehr und mehr mit persönlichen sensiblen Daten, sodass ihr Datenverkehr ein attraktives Angriffsziel für Man-in-the-Middle-attacks (MitMAs) ist. Schutz gegen solche Angriffe bieten Protokolle wie Transport Layer Security (TLS) und Hypertext Transfer Protocol Secure (HTTPS), deren fehlerhafter Einsatz jedoch zu ebenso gravierenden Unsicherheiten führen kann. Zahlreiche Ereignisse und frühere Forschungsergebnisse haben diesbezüglich Schwachstellen in Android Apps gezeigt. Diese Arbeit präsentiert eine Reihe von Forschungsbeiträgen, die sich mit der Sicherheit von Android befassen. Der Hauptfokus liegt dabei auf der Netzwerksicherheit von Android Apps. Hierbei untersucht diese Arbeit verschiedene Möglichkeiten zur Verbesserung der Netzwerksicherheit und deren Erfolg, wobei sie die Situation in Android auch mit der generellen Evolution von Netzwerksicherheit in Kontext setzt. Darüber hinaus schließt diese Arbeit mit einer Erhebung der aktuellen Situation und zeigt Möglichkeiten zur weiteren Verbesserung auf.Smart devices and mobile platforms are omnipresent. Android OS has evolved to become the most dominating mobile operating system on the market with billions of devices and a platform with millions of apps. Apps increasingly offer solutions to everyday problems and have become an indispensable part of people’s daily life. Due to this, mobile apps carry and handle more and more personal and privacy-sensitive data which also involves communication with backend or third party services. Due to this, their network traffic is an attractive target for Man-in-the-Middle-attacks (MitMAs). Protection against such attacks is provided by protocols such as Transport Layer Security (TLS) and Hypertext Transfer Protocol Secure (HTTPS). Incorrect use of these, however, can impose similar vulnerabilities lead to equally serious security issues. Numerous incidents and research efforts have featured such vulnerabilities in Android apps in this regard. This thesis presents a line of research addressing security on Android with a main focus on the network security of Android apps. This work covers various approaches for improving network security on Android and investigates their efficacy as well as it puts findings in context with the general evolution of network security in a larger perspective. Finally, this work concludes with a survey of the current state of network security in Android apps and envisions directions for further improvement

Security First approach in development of Single-Page Application based on Angular

Recently a Single-Page Application (SPA) approach is getting attention even though this is based on JavaScript is not considered to be a safe programming language. In the SPA ecosystem developers often have to use many external dependencies. Detected vulnerabilities in these external dependencies are disclosed and updated in most cases by the community. Often, in-depth security analysis is not included during the development stage, due to project deadlines and other circumstances. It goes with number of complications. The most straightforward is to be vulnerable for cyber attacks which causes financial problems for companies. Currently law already includes penalties in case of data breaches. Moreover, detected vulnerable code delays projects due to necessary time to improve it. Sometimes it requires to change the whole architecture if the application was poorly designed or in case security was skipped completely in the early stage. It might lead even to putting changes in the architectural style once the application is already on the market. It does makes high pressure on software developers to fix it fast. The rush to deliver it as fast as possible can create new security risks, because in some scenarios it might take significant amount of time to change the design with security prioritization. Especially within the financial industry consequences of not including security during the design stage might be harmful. Companies in this industry are entrusted with high social trust and sensitive (personal) data. For such enterprises shortcomings in security might cause data, image and money loss. Cybercrime activities are intensifying and for some companies it might causes to be kicked out of business due to hacking. This important factor of software development is currently getting more attention. That is why providing security in an early stage of a project is important, as well should be considered as a prerequisite. Security should be integrally included in all parts of the development cycle: specification, design, implementation and testing. The desired result is a secure web application. Improving security might be done explicitly by using security analysis and enhance security accordingly to the results. However, implicit methods like clean code, programming best practices, proper architecture design also applies. Ideally, in a continuous security way. Programming best practices and countermeasures against web application security threats have been used to analyse and verify SPA security. In this research project, an Angular SPA has been developed with focus on security. It includes programming best practices, security analysis and number of different tests. The main goal was to develop a SPA based on the Angular framework with security first approach. An in-depth security analysis of the deployed application is then conducted with validation of these results

Understanding the trust relationships of the web PKI

TLS and the applications it secures (e.g., email, online banking, social media) rely on the web PKI to provide authentication. Without strong authentication guarantees, a capable attacker can impersonate trusted network entities and undermine both data integrity and confidentiality. At its core, the web PKI succeeds as a global authentication system because of the scalability afforded by trust. Instead of requiring every network entity to directly authenticate every other network entity, network entities trust certification authorities (CAs) to perform authentication on their behalf. Prior work has extensively studied the TLS protocol and CA authentication of network entities (i.e., certificate issuance), but few have examined even the most foundational aspect of trust management and understood which CAs are trusted by which TLS user agents, and why. One major reason for this disparity is the opacity of trust management in two regards: difficult data access and poor specifications. It is relatively easy to acquire and test popular TLS client/server software and issued certificates. On the other hand, tracking trust policies/deployments and evaluating CA operations is less straightforward, but just as important for securing the web PKI. This dissertation is one of the first attempts to overcome trust management opacity. By observing new measurement perspectives and developing novel fingerprinting techniques, we discover the CAs that operate trust anchors, the default trust anchors that popular TLS user agents rely on, and a general class of injected trust anchors: TLS interceptors. This research not only facilitates new ecosystem visibility, it also provides an empirical grounding for trust management specification and evaluation. Furthermore, our findings point to many instances of questionable, and sometimes broken, security practices such as improperly identified CAs, inadvertent and overly permissive trust, and trivially exploitable injected trust. We argue that most of these issues stem from inadequate transparency, and that explicit mechanisms for linking trust anchors and root stores to their origins would help remedy these problems