Why didn't we spot that? [Practical Security

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

Chapter 59 - Virtual Private Networks

This paper presents the results of work by the author on application and comparative performance of IP Security (IPSec) and Secure Socket Layer (SSL) protocols in a Microsoft .NET 3-tier client-server network. To evaluate the performance of each security protocol, the author created a typical 3-tier client-server e-commerce model in which data communication passed through three distinct pathways: (1) channel between client and Web server over Internet, (2) channel between the Web server and application server, (3) channel between the application server and database server. The primary focus in this paper remains on the third channel where IPSec and SSL were used to connect the application server to the database server. A preliminary analysis of the collected data sheds light on performance of IPSec and SSL in Microsoft .NET environment. It also suggests that in pathways where SSL and IPSec could be used interchangeably, the selection of the most suitable security protocol ought to be dynamic.

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 as a means of protecting the security of data transmission has been widely used. In this paper, to reduce the impact of poor network transmission on the overall delay of SSL transmission in an unstable network environment, a novel SSL transmission delay optimization algorithm based on network path delay prediction is introduced. We propose a locally weighted linear regression prediction algorithm based on sliding window and singular spectrum analysis to better adapt to the characteristics of network time-delay sequence. In an unstable network transmission environment, when the predicted TCP transmission delay fluctuates beyond a certain threshold, the optimization algorithm will calculate a new parallel degree of SSL data encryption and compression to make sure of an optimized overall delay of SSL transmission. But, in a stable network transmission environment, the TCP transmission delay slightly fluctuates and the parallel process takes no effect. It is significant, especially for a heavy-duty server, that it can dynamically and reasonably use the multi-core resources. The final SSL transmission experiment verifies the effectiveness of the proposed optimization algorithm.

Chapter 10 - Java Secure Sockets Layer

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.

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.

The wide spread of using handheld devices offers an opportunity for mobile devices to be used as a universal payment method. However, some issues impede the widespread acceptance of mobile payment; for example: privacy protection, limited capability of mobile devices, and limited bandwidth of wireless networks. In ecommerce payment, Secure Socket Layer (SSL) protocol has been used to establish a secure channel between customers and merchants to secure the payment and the order information. SSL has some disadvantages regarding customer privacy that the customer payment information is revealed to the merchant. Secure Electronic Transaction (SET) has resolved SSL protocol disadvantages by dividing order message into: 1) order information which is revealed to merchant M, 2) payment information which is revealed to Payment Gateway (PG). Both SSL and SET assume the existence of Public Key Infrastructure (PKI) where extensive computations are carried out. In mobile payment, the same protocols of ecommerce payment are used but their application is limited due to heavy computations over wireless and GSM networks. A Modified Secure Electronic Transaction (MSET) protocol is proposed to minimize the extensive computations of SET protocol through replacing time consuming public key encryption and decryption algorithms by symmetric key cryptography.

System security is the most important aspect in an information system, weak system security increases the risk of attacks that can cause system damage. One of the attacks that often occurs is an attack on a web server, this is because the web server is connected to the internet network and is accessed by many users widely, so the risk of attack increases. For example, the New Student Admission web site of Universitas Muhammadiyah Bengkulu, which manages data on prospective new students who have registered themselves. So that a web server security system is needed to avoid potential attacks and to increase data security. One method of securing a web server is by using the Secure Socket Layer (SSL). SSL is often used to secure communication between client and server. The stages carried out in this study are scanning web servers that have not used SSL and those that have used SSL. This research aims to determine the security of web servers and anticipate various potential attacks on web servers.

Since the Internet of Things (IoT) will be entwined with everything we use in our daily life, the consequence of security flaws escalates. Smart objects will govern most of the home appliances and car engines yielding potential disaster scenarios. In this context, successful attacks could lead to chaos and scary scenarios (www.darkreading.com). Unprotected personal information may expose sensitive and embarrassing data to the public and attacks may threaten not only our computers and smart devices, but our intimacy and perhaps our lives too. Because persons and objects will be bonded with each other, user consent becomes critical. Therefore, thing, object, and user Identity will be the focus of future IoT security solutions, yielding a Trust, Security, and Privacy (TSP) paradigm, which may constitute the Achilles' heel of IoT. While security issues are quite straightforward, mainly from background knowledge, privacy issues are far more complex. Privacy constitutes a rather challenging task, even for the m...

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.

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.

The rapid advancement of digital communication technologies has increased the need for secure remote access within corporate environments.This study develops and implements a secure network architecture for PT Tanjungenim Lestari Pulp & Paper using Virtual Private Network (VPN) mechanisms based on Internet Protocol Security (IPsec) and Secure Socket Layer (SSL).The existing network, which utilizes a star topology and file-sharing mechanisms, was found to lack sufficient security, particularly in protecting data transmission to external partner companies.The proposed system integrates IPsecbased VPN tunneling to ensure encrypted communication channels and SSL certificates to safeguard FTP authentication processes.Data were collected through action research and document studies, followed by network design, IP addressing, router configuration, VPN deployment, FTP server installation (VSFTPD), and file transfer testing.The results demonstrate successful establishment of secure tunnels, encrypted data exchange, and protection against credential interception during authentication.This study concludes that implementing IPsec VPN and SSL-secured FTP significantly enhances remote access security, maintains data confidentiality, and strengthens the overall network infrastructure of PT Tanjungenim Lestari Pulp & Paper.

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.