The Lightweight Directory Access Protocol (LDAP) is the standard technology to query information stored in directories. These directories can contain sensitive personal data such as usernames, email addresses, and passwords. LDAP is also used as a central, organization-wide storage of configuration data for other services. Hence, it is important to the security posture of many organizations, not least because it is also at the core of Microsoft’s Active Directory, and other identity management and authentication services.

We report on a large-scale security analysis of deployed LDAP servers on the Internet. We developed LanDscAPe, a scanning tool that analyzes security-relevant misconfigurations of LDAP servers and the security of their TLS configurations. Our Internet-wide analysis revealed more than 10k servers that appear susceptible to a range of threats, including insecure configurations, deprecated software with known vulnerabilities, and insecure TLS setups. 4.9k LDAP servers host personal data, and 1.8k even leak passwords. We document, classify, and discuss these and briefly describe our notification campaign to address these concerning issues.

The advent of instantaneous communication via the Internet in the 80s and 90s has revolutionized the way we communicate. Suddenly, we could connect with people all over the world by sending emails and instant messages at a fraction of the previous cost. This advancement gave rise to countless social and political achievements, such as remote work and the climate movement, that might have been impossible without it. However, as we scaled from face-to-face to worldwide communication, opportunities for lawful as well as unlawful actors to monitor this communication scaled as well. In 2013, Edward Snowden’s revelations of widespread Internet surveillance made the public, as well as privacy and security experts, acutely aware of the dangers of pervasive monitoring. In response, many service providers have deployed transport encryption, such as TLS, to prevent passive monitoring on the Internet and local networks.

Despite these efforts, digital communication remains at risk from lawful inter- ception and attacks on service providers. The solution is end-to-end encryption, which protects messages from the sender all the way to the receiver. In this thesis, we investigate both transport and end-to-end encryption protocols to uncover corner cases in which they fail to deliver the promised security. The starting point of our analysis on transport encryption is a survey on the security of TLS and, specifically, the STARTTLS protocol. Through systematization and extension of knowledge on STARTTLS vulnerabilities, we develop practical attacks breaking the confidentiality, integrity, and authentication of STARTTLS connections.

Smartwatches explicitly marketed for children also use transport encryption to protect data in transit between the app or smartwatch and the manufacturers’ servers. We analyze this and the general security of these watches. Our analysis shows that a Meddler-in-the-Middle can break the authentication and confidentiality of TLS in one smartwatch ecosystem and another manufacturer’s custom encryption protocol. Additionally, a web attacker can compromise the API authorization and gain unauthenticated access to children’s sensitive data in the operators’ backends.

The issues we found with transport encryption and general data security underline the need for end-to-end encryption. Our end-to-end encryption research focuses on the security of email communication and common document formats. This research reveals that the email end-to-end encryption protocols S/MIME and OpenPGP insufficiently protect against Oracle Attacks—an attack class researchers formerly considered impractical against these protocols. With new techniques based on format oracles, an attacker can break end-to-end encrypted emails through traffic monitoring—independent of whether email client and server use transport encryption.

S/MIME and OpenPGP use cryptographic constructions repeatedly shown to be vulnerable to format oracle attacks in protocols like TLS, SSH, or IKE. However, format oracle attacks in the End-to-End Encryption (E2EE) email setting are considered impractical as victims would need to open many attacker-modified emails and communicate the decryption result to the attacker. But is this really the case?

In this paper, we survey how an attacker may remotely learn the decryption state in email E2EE. We analyze the interplay of MIME and IMAP and describe side-channels emerging from network patterns that leak the decryption status in Mail User Agents (MUAs). Concretely, we introduce specific MIME trees that produce decryption-dependent network patterns when opened in a victim’s email client.

We survey 19 OpenPGP- and S/MIME-enabled email clients and four cryptographic libraries and uncover a side-channel leaking the decryption status of S/MIME messages in one client. Further, we discuss why the exploitation in the other clients is impractical and show that it is due to missing feature support and implementation quirks. These unintended defenses create an unfortunate conflict between usability and security. We present more rigid countermeasures for MUA developers and the standards to prevent exploitation.

TLS is one of today’s most widely used and best-analyzed encryption technologies. However, for historical reasons, TLS for email protocols is often not used directly but negotiated via STARTTLS. This additional negotiation adds complexity and was prone to security vulnerabilities such as naive STARTTLS stripping or command injection attacks in the past.

We perform the first structured analysis of STARTTLS in SMTP, POP3, and IMAP and introduce EAST, a semi-automatic testing toolkit with more than 100 test cases covering a wide range of variants of STARTTLS stripping, command and response injections, tampering attacks, and UI spoofing attacks for email protocols. Our analysis focuses on the confidentiality and integrity of email submission (email client to SMTP server) and email retrieval (email client to POP3 or IMAP server). While some of our findings are also relevant for email transport (from one SMTP server to another), the security implications in email submission and retrieval are more critical because these connections involve not only individual email messages but also user credentials that allow access to a user’s email archive.

We used EAST to analyze 28 email clients and 23 servers. In total, we reported over 40 STARTTLS issues, some of which allow mailbox spoofing, credential stealing, and even the hosting of HTTPS with a cross-protocol attack on IMAP. We conducted an Internet-wide scan for the particularly dangerous command injection attack and found that 320.000 email servers (2% of all email servers) are affected. Surprisingly, several clients were vulnerable to STARTTLS stripping attacks. In total, only 3 out of 28 clients did not show any STARTTLS-specific security issues. Even though the command injection attack received multiple CVEs in the past, EAST detected eight new instances of this problem. In total, only 7 out of 23 tested servers were never affected by this issue. We conclude that STARTTLS is error-prone to implement, under-specified in the standards, and should be avoided.

OpenPGP and S/MIME are the two prime standards for providing end-to-end security for emails. We describe novel attacks built upon a technique we call malleability gadgets to reveal the plaintext of encrypted emails. We use CBC/CFB gadgets to inject malicious plaintext snippets into encrypted emails. These snippets abuse existing and standard conforming backchannels to exfiltrate the full plaintext after decryption. We describe malleability gadgets for emails using HTML, CSS, and X.509 functionality. The attack works for emails even if they were collected long ago, and it is triggered as soon as the recipient decrypts a single maliciously crafted email from the attacker.

We devise working attacks for both OpenPGP and S/MIME encryption, and show that exfiltration channels exist for 23 of the 35 tested S/MIME email clients and 10 of the 28 tested OpenPGP email clients. While it is advisable to update the OpenPGP and S/MIME standards to fix these vulnerabilities, some clients had even more severe implementation flaws allowing straightforward exfiltration of the plaintext.