SSL/TLS Session-Aware User Authentication

The unprecedented increase in web-based services and digital systems has prompted the dire need for secure information transmission all over the global networks. Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols form the basis of web communication that will provide confidentiality, authenticity, and integrity of data communication between different systems. In this work, we have critically compared and contrasted Transport Layer Security (TLS) and Secure Socket Layer (SSL), considering their design architectures, cryptographic mechanisms, and operational performance in modern applications. We took advantage of recent literature, global best practices, and international standards such as IETF RFC 8446 (TLS 1.3) and NIST SP 800-52 Rev.2 to evaluate security capability, vulnerabilities, and the strategies for migrations. TLS 1.3 is now the basic standard due to its enhanced efficiency, lower latency of handshake, and better encryption through AEAD (Authenticated Encryption with Associated Data) algorithms; however, compatibility with legacy systems and inconsistencies in configuration pose serious challenges. We concluded by recommending the best practices for developers, system architects, and cybersecurity professionals to build robust, standards-compliant web applications

Transport Layer Security (TLS), has become the de-facto standard for secure Internet communication. When used correctly, it provides secure data transfer, but used incorrectly, it can leave users vulnerable to attacks while giving them a false sense of security. Numerous efforts have studied the adoption of TLS (and its predecessor, SSL) and its use in the desktop ecosystem, attacks, and vulnerabilities in both desktop clients and servers. However, there is a dearth of knowledge of how TLS is used in mobile platforms. In this paper we use data collected by Lumen, a mobile measurement platform, to analyze how 7,258 Android apps use TLS in the wild. We analyze and fingerprint handshake messages to characterize the TLS APIs and libraries that apps use, and also evaluate weaknesses. We see that about 84% of apps use default OS APIs for TLS. Many apps use third-party TLS libraries; in some cases they are forced to do so because of restricted Android capabilities. Our analysis shows that both approaches have limitations, and that improving TLS security in mobile is not straightforward. Apps that use their own TLS configurations may have vulnerabilities due to developer inexperience, but apps that use OS defaults are vulnerable to certain attacks if the OS is out of date, even if the apps themselves are up to date. We also study certificate verification, and see low prevalence of security measures such as certificate pinning, even among high-risk apps such as those providing financial services, though we did observe major third-party tracking and advertisement services deploying certificate pinning.

Transport Layer Security (TLS) is a secure communication protocol that is used in many secure electronic applications. In order to establish a TLS connection, a client and server engage in a handshake, which usually involves the transmission of digital certificates. In this paper we present a practical speedup of TLS handshakes over bandwidth-constrained, high-latency (i.e. disadvantaged) links by reducing the communication overhead associated with the transmission of digital certificates. This speedup is achieved by deploying two specialized TLS proxies across such links. Working in tandem, one proxy replaces certificate data in packets being sent across the disadvantaged link with a short reference, while the proxy on the other side of the link restores the certificate data in the packet. Local or remote caches supply the certificate data. Our solution preserves the end-to-end security of TLS and is designed to be transparent to third-party applications, and will thus facilitate rapid deployment by removing the need to modify existing installations of TLS clients and TLS servers. Testing shows that this technique can reduce the overall bandwidth used during a handshake by 50% in test emulation and by over 20% of TLS session volume in practice. In addition, it can reduce the time required to establish a secure channel by over 40% across Iridium, a widely used satellite link in practice.

Transport Layer Security (TLS) is a widely used protocol for secure channel establishment. However, TLS lacks any inherent mechanism for validating the security state of the endpoint software and its platform. To overcome this limitation, recent works have combined remote attestation (RA) and TLS, named attested TLS. The most popular attested TLS protocol for confidential computing is Intel’s RA-TLS, which is used in multiple industrial projects. However, Intel has neither specified the protocol nor the desired properties. Moreover, despite its wide usage in security-critical use cases, there is no formal reasoning for the security of attested TLS for confidential computing in general and RA-TLS in particular. Using the state-of-the-art symbolic security analysis tool ProVerif, we formalized and found vulnerabilities in RA-TLS from both RA and TLS perspectives. We also propose mitigations for the vulnerabilities. During the formalization process, we found that despite several formal verification efforts for TLS to ensure its security, the validation of corresponding formal models has been largely overlooked. We demonstrate that a simple validation framework could discover crucial issues in state-of-the-art formalization of TLS 1.3 key schedule in ProVerif. Particularly, we found that 11 out of 14 keys in that formalization deviate from the corresponding TLS specifications. These issues have been acknowledged and fixed by the authors. Finally, we provide recommendations for protocol designers and the formal verification community based on the lessons learned in the formal verification and validation.

In-network middleboxes are vital for the Internet-of-Things (IoT) system security, but the widely adopted transport layer security (TLS) protocol blinds application-level middleboxes due to the encryption of traffic data. To resolve this problem, many solutions have been proposed to date. Among them, SplitTLS is widely adopted in the industry by proxy manufacturers. It requires TLS client to install customized root certificates and incurs additional security flaws, e.g., disabling server authentication and using weak cipher suites. Another approach is to customize the TLS protocol where middleboxes are enabled via either performing handshake directly with TLS endpoints or receiving session key materials in an out-of-band manner. Overall, current solutions would either jeopardize the original TLS handshake procedure or incur additional overheads on the endpoints. In this article, we design a new middlebox-enhanced TLS (ME-TLS), which enables endpoints to introduce authenticated middleboxes into a TLS session while control middleboxes' access permission and processing order of traffic data. Particularly, in our proposed ME-TLS, the handshake structure of TLS keeps unchanged and middleboxes work in a passive manner. That is, middleboxes in the ME-TLS could recover session key materials by monitoring handshake messages passively instead of interacting with endpoints; secondary secure channels for key transmission are also not needed in our ME-TLS. We implement our ME-TLS based on the TLS 1.3 protocol and evaluate its performances. The experimental results demonstrate that our proposal is practical and deployable for real-world IoT scenarios.

The Secure Sockets Layer (SSL) protocol and its standards-track successor, the Transport Layer Security (TLS) protocol, were developed more than a decade ago and have generally withstood scrutiny in that the protocols themselves haven't been found to have security flaws. Marsh Ray and Steve Dispensa discovered a design flaw in the TLS protocol that affects all versions of the protocol up to and including the current version.Whereas the vulnerability itself is serious, it need not affect many deployments once administrators apply suitable patches to disable renegotiation, leaving TLS sufficiently secure in most cases because exploiting the vulnerability requires the attacker to be an active man-in-themiddle, redirecting traffic between victims (for example, a browser and a Web server). However, because security problems only ever get worse, a change to the protocol is required. The vulnerability is an interesting attack in itself, but perhaps more interesting is the question, why didn't we see this earlier? In this article, the author explore this question but, unfortunately, can't answer it. Hopefully, simply asking the question might prompt developers to re-examine assumptions they've forgotten they've even made.

To provide secure content delivery, Transport Layer Security (TLS) has become a de facto standard over a couple of decades. However, TLS has a long history of security weaknesses and drawbacks. Thus, the security of TLS has been enhanced by addressing security problems through continuous version upgrades. Meanwhile, to provide fast content delivery globally, websites (or origin web servers) need to deploy and administer many machines in globally distributed environments. They often delegate the management of machines to web hosting services or content delivery networks (CDNs), where the security configurations of distributed servers may vary spatially depending on the managing entities or locations. Based on these spatial differences in TLS security, we find that the security level of TLS connections (and their web services) can be lowered. After collecting the information of (web) domains that exhibit different TLS versions and cryptographic options depending on clients' locations, we show that it is possible to redirect TLS handshake messages to weak TLS servers, which both the origin server and the client may not be aware of. We investigate 7M domains with these spatial differences of security levels in the wild and conduct the analyses to better understand the root causes of this phenomenon. We also measure redirection delays at various locations in the world to see whether there are noticeable delays in redirections.

By design, TLS (Transport Layer Security) is a 2-party, end-to-end protocol. Yet, in practice, TLS delegation is often deployed: that is, middlebox proxies inspect and even modify TLS traffic between the endpoints. Recently, industry-leaders (e.g., Akamai, Cloudflare, Telefonica, Ericcson), standardization bodies (e.g., IETF, ETSI), and academic researchers have proposed numerous ways of achieving safer TLS delegation. We present LURK the LURK (Limited Use of Remote Keys) extension for TLS 1.2, a suite of designs for TLS delegation, where the TLS-server is aware of the middlebox. We implement and test LURK. We also cryptographically prove and formally verify, in Proverif, the security of LURK. Finally, we comprehensively analyze how our designs balance (provable) security and competitive performance.

Transport Layer Security (TLS) and its precursor Secure Sockets Layer (SSL) are the most widely deployed protocol to establish secure communication over insecure Internet Protocol (IP) networks. Providing a secure session layer on top of TCP, TLS is frequently the first defense layer encountered by adversaries who try to cause loss of confidentiality by sniffing live traffic or loss of integrity using man-in-the-middle attacks. Despite its wide deployment and evolution over the last 18 years, TLS remains vulnerable to a number of threats at the protocol layer and therefore does not provide strong security out-of-the-box, requiring tweaks to its configuration in order to provide the expected security benefits. This paper provides a summary of the current TLS threat surface together with a validated approach for minimizing the risk of TLS-compromise. The main contributions of this paper include 1) identification of configuration options that together maximize security guarantees in the context of recent TLS exploits and 2) specification of expected flows and automated comparison with observed flows to flag inconsistencies.

Normally, secure communication between client-server applications is established using secure channel technologies such as Transport Layer Security (TLS). TLS is cryptographic protocol which ensures secure transmission of data and authenticity of communication at each endpoint platform. However, the protocol does not provide any trustworthiness assurance of the involved endpoint. This paper incorporates remote attestation in the TLS key exchange protocol to solve this issue.The proposed embedded attestation extension in TLS protocol will provide assurance of sender's platforms integrity to receiver, and vice versa.The CA responsibility in TLS is replaced using own Trusted Certificate Authority (TCA) in our protocol. The credibility of the proposed protocol is studied to secure against replay attack and collusion attack. The proof is performed using AVISPA with High Level Protocol Specification (HLPSL) through Dolev-Yao intruder model implementation of the proposed protocol.

Radio Frequency Identification (RFID) is a technology that has risen to prominence over the past decade. EPCglobal Network provides a standardized way to collect, store, and distribute data among various organizations. Low-Level Reader Protocol (LLRP) is a standard interface between RFID Readers and Clients. LLRP implements Transport Layer Security (TLS) to setup a secure connection. Authentication techniques in TLS protocol are mainly based on public key cryptography. Recently TLS supports Kerberos cipher suites that provide Kerberos-based authentication. It is a symmetric key cryptography. This paper introduces RFID Access Control system (RFID-AC) as approach and assesses its security vulnerabilities. The paper experimentally implements TLS LLRP endpoints and examines different possible security solutions. Experiments focus on comparing the commonly used authentication technique; authenticated certificate-based versus Kerberos credentials-based. Analysis was done to determine the most suitable one for access control that can satisfy the security concerns and Quality of Services (QoS) issues.

Mobile applications are granted access to large amounts of data both stored and sensed on a user’s device. While the data stored on these devices can be protected with encryption, where the private keys are protected through a combination of biometric authentication and passcodes, it is important to consider the security of data in transit and the many connections applications make to different domains. Often, these domains are unknown to the user where they can include third-party domains and tracking services. In this paper, we investigate the current state of transport layer security (TLS) utilization across the top information sharing applications in the iOS App Store. Through this study, we are able to better understand which domains follow best practices and use recommended ciphers and TLS versions. We also provide deeper insight into the prominent use of tracking services and how they differ in their utilization of TLS. Our study utilizes a proxy service to detect the domains that applications communicate with and then uses OpenSSL to analyze the supported ciphers, TLS versions, and certificate details. We also leverage domain analysis from DuckDuckGo Tracker Radar to differentiate tracking domains. From this study, we analyzed 965 unique domains and found that 935 (96%) use a cipher that is not recommended and only 23 (2%) of the domains strictly followed recommendations on cipher and TLS utilization. While most domains are utilizing recommended versions of TLS and recommended ciphers, this study shows there are many that still support vulnerable versions of TLS and vulnerable ciphers, leaving the user’s data at risk.

Transport Layer Security (TLS) is one of the most popular security protocols for end-to-end communications. The handshake process of TLS has high computation complexity and heavy delay, while the devices in Internet of Things (IoT) always have limited resources. Therefore, it is hard to deploy TLS in IoT. To tackle this problem, we propose a novel method to simplify the TLS handshake protocol based on Software Defined Network (SDN) for a general end-to-end communication scenario. Firstly, instead of doing the Diffie-Hellman key exchange to calculate the premaster secret of TLS, the controller is used to generate the premaster secret dynamically and then distributes this secret to the IoT devices through the encrypted channel between the SDN switch and the controller. Secondly, the certificate verification of TLS is transferred from the IoT devices to the more powerful controller. Furthermore, the security of our simplified protocol is validated by the deduction of BAN logic and the analysis for malicious attacks. The experimental results show that our protocol reduces both the latency in the whole handshake process and the computational overhead in the IoT devices compared with the traditional TLS.

Transport layer security (TLS) 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, this paper 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.

The short story is this: before you send sensitive data across a network, you need proof of the identity of the machine that you think is on the other end of the socket, and while sending the data, you need it protected against the prying eyes of anyone controlling the gateways and network switches that see all of your packets. The solution to this problem is to use Transport Layer Security (TLS). Because earlier versions of TLS were called the Secure Sockets Layer (SSL), nearly all of the libraries that you will use to speak TLS actually still have SSL somewhere in the name. KeywordsReplay AttackStandard LibrarySecure Socket LayerTransport Layer SecurityServer CertificateThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.