Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases now! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
TLS Cryptography In-Depth
TLS Cryptography In-Depth

TLS Cryptography In-Depth: Explore the intricacies of modern cryptography and the inner workings of TLS

Arrow left icon
Profile Icon Dr. Paul Duplys Profile Icon Dr. Roland Schmitz
Arrow right icon
€18.99 per month
Full star icon Full star icon Full star icon Full star icon Half star icon 4.7 (3 Ratings)
Paperback Jan 2024 712 pages 1st Edition
eBook
€20.98 €29.99
Paperback
€37.99
Subscription
Free Trial
Renews at €18.99p/m
Arrow left icon
Profile Icon Dr. Paul Duplys Profile Icon Dr. Roland Schmitz
Arrow right icon
€18.99 per month
Full star icon Full star icon Full star icon Full star icon Half star icon 4.7 (3 Ratings)
Paperback Jan 2024 712 pages 1st Edition
eBook
€20.98 €29.99
Paperback
€37.99
Subscription
Free Trial
Renews at €18.99p/m
eBook
€20.98 €29.99
Paperback
€37.99
Subscription
Free Trial
Renews at €18.99p/m

What do you get with a Packt Subscription?

Free for first 7 days. $19.99 p/m after that. Cancel any time!
Product feature icon Unlimited ad-free access to the largest independent learning library in tech. Access this title and thousands more!
Product feature icon 50+ new titles added per month, including many first-to-market concepts and exclusive early access to books as they are being written.
Product feature icon Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.
Product feature icon Thousands of reference materials covering every tech concept you need to stay up to date.
Subscribe now
View plans & pricing
Table of content icon View table of contents Preview book icon Preview Book

TLS Cryptography In-Depth

1

The Role of Cryptography in the Connected World

In this introductory chapter, we try to provide some answers to the following questions:

  • Why are there so many insecure IT systems?

  • How can cryptography help to mitigate our security problems?

Our core argument is that the simultaneous growth of connectivity and complexity of IT systems has led to an explosion of the attack surface, and that modern cryptography plays an important role in reducing that attack surface.

After a brief discussion of how the field of cryptography evolved from an exotic field appreciated by a select few to an absolutely critical skill for the design and operation of nearly every modern IT product, we will look at some recent real-world security incidents and attacks in order to illustrate our claim. This will allow you to understand why cryptography matters from a higher strategic perspective.

1.1 Evolution of cryptography

Over the past four decades or so, cryptography has evolved from an exotic field known to a select few into a fundamental skill for the design and operation of modern IT systems. Today, nearly every modern product, from the bank card in your pocket to the server farm running your favorite cloud services, requires some form of cryptography to protect it and its users against cyberattacks. Consequently, it has found its way into mainstream computer science and software engineering.

Figure 1.1: Number of publications at IACR conferences on cryptology over the years

Figure 1.1: Number of publications at IACR conferences on cryptology over the years

Cryptography and its counterpart cryptanalysis were basically unknown outside of military and intelligence services until the mid 1970s. According to [172], Cryptography is the practice and study of techniques for secure communication in the presence of adversaries; it deals with the development and application of cryptographic mechanisms. Cryptanalysis is the study of cryptographic mechanisms’ weaknesses, aimed at finding mathematical ways to render these mechanisms ineffective. Taken together, cryptography and cryptanalysis form what’s called cryptology.

In 1967, David Kahn, an American historian, journalist, and writer, published a book titled The Codebreakers – The Story of Secret Writing, which is considered to be the first extensive treatment and a comprehensive report of the history of cryptography and military intelligence from ancient Egypt to modern times [93]. Kahn’s book introduced cryptology to a broader audience. Its content was, however, necessarily restricted to symmetric cryptography. In symmetric cryptography, the sender and receiver of a message share a common secret key and use it for both encrypting and decrypting. The problem of how sender and receiver should exchange the secret in a secure way was considered out of scope.

This changed in 1976, when the seminal paper New Directions in Cryptography by Whitfield Diffie and Martin Hellman appeared in volume IT-22 of IEEE Transactions on Information Security [49]. In that publication, Diffie and Hellman described a novel method for securely agreeing on a secret key over a public channel based on the so-called discrete logarithm problem. Moreover, they suggested for the first time that the sender and receiver might use different keys for encrypting (the public key) and decrypting (the private key) and thereby invented the field of asymmetric cryptography.

Figure 1.2: From left to right: Ralph Merkle, Martin Hellman, Whitfield Diffie [69]

Figure 1.2: From left to right: Ralph Merkle, Martin Hellman, Whitfield Diffie [69]

While there were scientific works on cryptography dating back to the early 1970s, the publication by Diffie and Hellman is the first publicly available paper in which the use of a private key and a corresponding public key is proposed. This paper is considered to be the start of cryptography in the public domain. In 2002, Diffie and Hellman suggested their algorithm should be called Diffie-Hellman-Merkle key exchange because of Ralph Merkle’s significant contribution to the invention of asymmetric cryptography [185].

In 1977, the three MIT mathematicians Ron Rivest, Adi Shamir, and Len Adleman took up the suggestion by Diffie and Hellman and published the first asymmetric encryption algorithm, the RSA algorithm [151], which is based on yet another well-known mathematical problem, the factoring problem for large integers.

Figure 1.3: From left to right: Adi Shamir, Ron Rivest, Len Adleman [152]

Figure 1.3: From left to right: Adi Shamir, Ron Rivest, Len Adleman [152]

The invention of asymmetric cryptography did not make symmetric cryptography obsolete. On the contrary, both fields have complementary strengths and weaknesses and can be efficiently combined in what is today called hybrid cryptosystems. The Transport Layer Security (TLS) protocol is a very good example of a hybrid cryptosystem.

Today, cryptography is a well-known (albeit mostly little understood in depth) topic in the IT community and an integral part of software development. As an example, as of July 2022, the OpenSSL library repository on GitHub contains over 31,500 commits by 686 contributors. Cryptography is also an integral part of numerous computer science and information security curricula, and numerous universities all over the world offer degrees in information security.

Why did this happen, and which factors led to this development and popularized cryptography within a comparably short period of time? To a large extent, this paradigm shift is a result of three—arguably still ongoing—developments in information technology that radically changed the role of cryptography in the modern connected world:

  • The advent of the internet and the ever increasing need to transfer large amounts of data over untrusted channels, which also fostered the development of TLS

  • The introduction of connectivity into nearly every new product, from toothbrushes to automobiles

  • The ever increasing complexity of IT systems, specifically increasing hardware and software complexity

We will now discuss each of these factors in turn.

1.2 The advent of TLS and the internet

We’ll now turn to the original theme of this book, TLS and the cryptographic tools it is made of. TLS is a protocol designed to protect data sent over the internet, so we’ll start with a brief look into the early history of the internet.

Despite its origins as a research project financed by the Defense Advanced Research Projects Agency (DARPA), the research agency of the Department of Defence of the United States, most of the main physical components of the internet, such as cables, routers, gateways, and so on, can be (and are) accessed by untrusted third parties. In the early days of the internet, this was not considered a problem, and very few (if any) security measures were introduced into TCP and IP, the internet’s main protocol workhorses, and none of them involved cryptography. However, with more and more people using the internet, and the ever increasing available bandwidth, more and more services kept appearing on the internet, and it was quickly realized that to do real business over the internet, a certain amount of trust was needed that sensitive data such as credit card numbers or passwords did not fall into the wrong hands. Cryptography provides the answer to this problem, because it can guarantee confidentiality (i.e., no one can read the data in transit) and authenticity (i.e., you can verify that you are talking to the right party). TLS and its predecessor SSL are the protocols that implement cryptography on the internet in a secure, usable way.

Starting in 1995, SSL was shipped together with Netscape Navigator to clients. While server-side adoption of SSL was slow at first, by the end of 2021, according to the Internet Security Research Group (ISRG), 83% of web pages loaded by Firefox globally used HTTPS, that is HTTP secured via TLS [87].

Figure 1.4: Percentage of web pages loaded by Firefox using HTTPS [88]

Figure 1.4: Percentage of web pages loaded by Firefox using HTTPS [88]

This is a huge success for TLS and the field of cryptography in general, but with it also comes a huge responsibility: we need to constantly monitor whether the algorithms, key lengths, modes of operations, and so on used within TLS are still secure. Moreover, we need to understand how secure algorithms work and how they can interact with each other in a secure way so that we can design secure alternatives if needed.

Maybe we should already stress at this early stage that TLS is not a remedy for all the problems mentioned here. TLS provides channel-based security, meaning that it can only protect data in transit between a client and a server. TLS is very successful in doing so, and how in detail TLS uses cryptography to achieve this goal is the main theme of this book. However, once the data leaves the secure channel, it is up to the endpoints (i.e., client and server) to protect it.

Moreover, cryptography by itself is useless in isolation. To have any practical effect, it has to be integrated into a much larger system. And to ensure that cryptography is effectively protecting that system, there must be no security holes left that would allow an attacker to circumvent its security.

There is a well-known saying among cybersecurity professionals that the security of a system is only as strong as its weakest link. Because there are so many ways to circumvent security – especially in complex systems – cryptography, or rather the cryptographic primitives a system uses, is rarely the weakest link in the chain.

There is, however, one important reason why cryptography is fundamental for the security of information systems, even if there are other security flaws and vulnerabilities. An attacker who is able to break cryptography cannot be detected because a cryptanalytic attack, that is, the breaking of a cryptographic protocol, mechanism or primitive, in most cases leaves no traces of the attack.

If the attacker’s goal is to read the communication, they can simply passively listen to the communication, record the messages and decrypt them later. If the attacker’s goal is to manipulate the target system, they can simply forge arbitrary messages and the system will never be able to distinguish these messages from benign ones sent by legitimate users.

While there are many other sources of insecurity (e.g., software bugs, hardware bugs, and social engineering), the first line of defense is arguably secure communication, which in itself requires a secure channel. And cryptography as a scientific discipline provides the building blocks, methods, protocols, and mechanisms needed to realise secure communication.

1.3 Increasing connectivity

Connectivity allows designers to add novel, unique features to their products and enables new business models with huge revenue potential that simply would not exist without it.

At the same time, connectivity makes it much harder to build secure systems. Similar to Ferguson and Schneier’s argument on security implications of complexity, one can say that there are no connected systems that are secure. Why? Because connecting systems to large, open networks like the internet exposes them to remote attacks. Remote attacks – unlike attacks that require physical access – are much more compelling from the attacker’s perspective because they scale.

1.3.1 Connectivity versus security – larger attack surface

While connectivity enables a multitude of desired features, it also exposes products to remote attacks carried out via the internet. Attacks that require physical access to the target device can only be executed by a limited number of attackers who actually have access to that device, for example, employees of a company in the case of devices in a corporate network. In addition, the need for physical access generally limits the attacker’s window of opportunity.

Connectivity, in contrast, exposes electronic devices and IT systems to remote attacks, leading to a much higher number of potential attackers and threat actors. Moreover, remote attacks – unlike attacks that require physical access to the target – are much more compelling from the attacker’s perspective because they scale.

Another aspect that makes remote attacks practical (and, to a certain extent, rather easy) is the fact that the initial targets are almost always the network-facing interfaces of the devices, which are implemented in software. As we have seen, complex software is almost guaranteed to contain numerous implementation bugs, a number of which can be typically exploited to attack the system. Thus, the trend of increasing software and system complexity inadvertently facilitates remote attacks.

1.3.2 Connectivity versus marginal attack cost

Remote attacks are easy to launch – and hard to defend against – because their marginal cost is essentially zero. After a newly discovered security vulnerability is initially translated into a reliably working exploit, the cost of replicating the attack an additional 10, 100, or 100,000 devices is essentially the same, namely close to zero.

This is because remote attacks are implemented purely in software, and reproducing software as well as accessing devices over public networks effectively costs close to nothing. So, while businesses need to operate large – and costly – internal security organizations to protect their infrastructure, services, and products against cybersecurity attacks, any script kiddie can try to launch a remote attack on a connected product, online service, or corporate infrastructure essentially for free.

1.3.3 Connectivity versus scaling attacks

To summarize, connectivity exposes devices and IT systems to remote attacks that target network-facing software (and, thus, directly benefit from the continuously increasing software complexity), are very cheap to launch, can be launched by a large number of threat actors, and have zero marginal cost.

In addition, there exists a market for zero-day exploits [190] that allows even script kiddies to launch highly sophisticated remote attacks that infest target systems with advanced malware able to open a remote shell and completely take over the infested device.

As a result, connectivity creates an attack surface that facilitates cybersecurity attacks that scale.

1.4 Increasing complexity

While it can be argued that the problem of increasing complexity is not directly mitigated by modern cryptography (in fact, many crypto-related products and standards suffer from this problem themselves), there is no doubt that increasing complexity is in fact a major cause of security problems. We included the complexity problem in our list of crucial factors for the development of cryptography, because cryptography can help limit the damage caused by attacks that were in turn caused by excessive complexity.

Following Moore’s law [191], a prediction made by the co-founder of Fairchild Semiconductor and Intel Gordon Moore in 1965, the number of transistors in an integrated circuit, particularly in a microprocessor, kept doubling roughly every 2 years (see Figure 1.5).

Figure 1.5: Increasing complexity of hardware: Transistors. Data is taken from https://github.com/barentsen/tech-progress-data

Figure 1.5: Increasing complexity of hardware: Transistors. Data is taken from https://github.com/barentsen/tech-progress-data

Semiconductor manufacturers were able to build ever bigger and ever more complex hardware with ever more features. This went so far that in the late 1990s, the Semiconductor Industry Association set off an alarm in the industry when it warned that productivity gains in Integrated Circuit (IC) manufacturing were growing faster than the capabilities of Electronic Design Automation (EDA) tools used for IC design. Entire companies in the EDA area were successfully built on this premise.

Continuously growing hardware resources paved the way for ever more complex software with ever more functionality. Operating systems became ever more powerful and feature-rich, the number of layers in software stacks kept increasing, and software libraries and frameworks used by programmers became ever more comprehensive. As predicted by a series of software evolution laws formulated by early-day computer scientists Manny Lehman and Les Belady, software exhibited continuing growth and increasing complexity [181] (see also Figure 1.6).

Figure 1.6: Increasing complexity of software: Source Lines of Code (SLOC) in operating systems. Data is taken from https://github.com/barentsen/tech-progress-data

Figure 1.6: Increasing complexity of software: Source Lines of Code (SLOC) in operating systems. Data is taken from https://github.com/barentsen/tech-progress-data

Why should increasing complexity be a problem? According to leading cybersecurity experts Bruce Schneier and Niels Ferguson [65], ”Complexity is the worst enemy of security, and it almost always comes in the form of features or options”.

While it might be argued whether complexity really is the worst enemy of security, it is certainly true that complex systems, whether realized in hardware or software, tend to be error-prone. Schneier and Ferguson even claim that there are no complex systems that are secure.

Complexity negatively affects security in several ways, including the following:

  • Insufficient testability due to a combinatorial explosion given a large number of features

  • Unanticipated—and unwanted—behavior that emerges from a complex interplay of individual features

  • A high number of implementation bugs and, potentially, architectural flaws due to the sheer size of a system

1.4.1 Complexity versus security – features

The following thought experiment illustrates why complexity arising from the number of features or options is a major security risk. Imagine an IT system, say a small web server, whose configuration consists of 30 binary parameters (that is, each parameter has only two possible values, such as on or off). Such a system has more than a billion possible configurations. To guarantee that the system is secure under all configurations, its developers would need to write and run several billion tests: one test for each relevant type of attack (e.g., Denial-of-Service, cross-site scripting, and directory traversal) and each configuration. This is impossible in practice, especially because software changes over time, with new features being added and existing features being refactored. Moreover, real-world IT systems have significantly more than 30 binary parameters. As an example, the NGINX web server has nearly 800 directives for configuring how the NGINX worker processes handle connections.

1.4.2 Complexity versus security – emergent behavior

A related phenomenon that creates security risks in complex systems is the unanticipated emergent behavior. Complex systems tend to have properties that their parts do not have on their own, that is, properties or behaviors that emerge only when the parts interact [186]. Prime examples for security vulnerabilities arising from emergent behavior are time-of-check-to-time-of-use (TOCTOU) attacks exploiting concurrency failures, replay attacks on cryptographic protocols where an attacker reuses an out-of-date message, and side-channel attacks exploiting unintended interplay between micro-architectural features for speculative execution.

1.4.3 Complexity versus security – bugs

Currently available software engineering processes, methods, and tools do not guarantee error-free software. Various studies on software quality indicate that, on average, 1,000 lines of source code contain 30-80 bugs [174]. In rare cases, examples of extensively tested software were reported that contain 0.5-3 bugs per 1,000 lines of code [125].

However, even a rate of 0.5-3 bugs per 1,000 lines of code is far from sufficient for most practical software systems. As an example, the Linux kernel 5.11, released in 2021, has around 30 million lines of code, roughly 14% of which are considered the ”core” part (arch, kernel, and mm directories). Consequently, even with extensive testing and validation, the Linux 5.11 core code alone would contain approximately 2,100-12,600 bugs.

And this is only the operating system core without any applications. As of July 2022, the popular Apache HTTP server consists of about 1.5 million lines of code. So, even assuming the low rate of 0.5-3 bugs per 1,000 lines of code, adding a web server to the core system would account for another 750-4,500 bugs.

Figure 1.7: Increase of Linux kernel size over the years

Figure 1.7: Increase of Linux kernel size over the years

What is even more concerning is the rate of bugs doesn’t seem to improve significantly enough over time to cope with the increasing software size. The extensively tested software having 0.5-3 bugs per 1,000 lines of code mentioned above was reported by Myers in 1986 [125]. On the other hand, a study performed by Carnegie Mellon University’s CyLab institute in 2004 identified 0.17 bugs per 1,000 lines of code in the Linux 2.6 kernel, a total of 985 bugs, of which 627 were in critical parts of the kernel. This amounts to slightly more than halving the bug rate at best – over almost 20 years.

Clearly, in that same period of time from 1986 to 2004 the size of typical software has more than doubled. As an example, Linux version 1.0, released in 1994, had about 170,000 lines of code. In comparison, Linux kernel 2.6, which was released in 2003, already had 8.1 million lines of code. This is approximately a 47-fold increase in size within less than a decade.

Figure 1.8: Reported security vulnerabilities per year

Figure 1.8: Reported security vulnerabilities per year

1.5 Example attacks

The combination of these two trends – increase in complexity and increase in connectivity – results in an attack surface explosion. The following examples shall serve to illustrate this point.

1.5.1 The Mirai botnet

In late 2016, the internet was hit by a series of massive Distributed Denial-of-Service (DDoS) attacks originating from the Mirai botnet, a large collection of infected devices (so-called bots) remote-controlled by attackers.

The early history of the Mirai botnet can be found in [9]: the first bootstrap scan on August 1 lasted about two hours and infected 834 devices. This initial population continued to scan for new members and within 20 hours, another 64,500 devices were added to the botnet. The infection campaign continued in September, when about 300,000 devices were infected, and reached its peak of 600,000 bots by the end of November. This corresponds to a rate of 2.2-3.4 infected devices per minute or 17.6-27.2 seconds to infect a single device.

Now contrast this with a side-channel or fault attack. Even if we assume that the actual attack – that is, the measurement and processing of the side-channel traces or the injection of a fault – can be carried out in zero time, an attacker would still need time to gain physical access to each target. Now suppose that, on average, the attacker needs one hour to physically access a target (actually, this is a very optimistic assumption from the attacker’s perspective, given that the targets are distributed throughout the globe). In that case, attacking 200,000-300,000 devices would take approximately 22-33 years or 270 to 400 months (as opposed to 2 months in the case of Mirai).

Moreover, any remote attack starts at a network interface of the target system. So the first (and, oftentimes, the only) thing the attacker interacts with is software. But software is complex by nature.

1.5.2 Operation Aurora

In mid-December 2009, Google discovered a highly sophisticated, targeted attack on their corporate infrastructure that resulted in intellectual property theft [73]. During their investigation, Google discovered that at least 20 other large companies from a wide range of businesses had been targeted in a similar way [193].

This series of cyberattacks came to be known as Operation Aurora [193] and were attributed to APT groups based in China. The name was coined by McAfee Labs security researchers based on their discovery that the word Aurora could be found in a file on the attacker’s machine that was later included in malicious binaries used in the attack as part of a file path. Typically, such a file path is inserted by the compiler into the binary to indicate where debug symbols and source code can be found on the developer’s machine. McAfee Labs therefore hypothesized that Aurora could be the name of the operation used by the attackers [179].

According to McAfee, the main target of the attack was source code repositories at high-tech, security, and defense contractor companies. If these repositories were modified in a malicious way, the attack could be spread further to their client companies. Operation Aurora can therefore be considered the first major attack on software supply chains [193].

In response to Aurora, Google shut down its operations in China four months after the incident and migrated away from a purely perimeter-based defense principle. This means devices are not trusted by default anymore, even if they are located within a corporate LAN [198].

1.5.3 The Jeep hack

At the BlackHat 2015 conference, security researchers Charlie Miller and Chris Valasek demonstrated the first remote attack on an unaltered, factory passenger car [120]. In what later became known as the Jeep hack, the researchers demonstrated how the vehicle’s infotainment system, Uconnect, which has both remote connectivity as well as the capability to communicate with other electronic control units within the vehicle, can be used for remote attacks.

Specifically, while systematically examining the vehicle’s attack surface, the researchers discovered an open D-Bus over an IP port on Uconnect, which is essentially an inter-process communication and remote procedure call mechanism. The D-Bus service accessible via the open port allows anyone connected to the infotainment system to execute arbitrary code in an unauthenticated manner.

Miller and Valasek also discovered that the D-Bus port was bound to all network interfaces on the vulnerable Uconnect infotainment system and was therefore accessible remotely over the Sprint mobile network that Uconnect uses for telematics. By connecting to the Sprint network using a femtocell or simply a regular mobile phone, the researchers were able to send remote commands to the vehicle.

From that entry point, Miller and Valasek attacked a chip in the vehicle’s infotainment system by re-writing its firmware to be able to send arbitrary commands over the vehicle’s internal CAN communication network, effectively giving them the ability to completely take over the vehicle.

1.5.4 Commonalities

What do these examples have in common and how does it relate to cryptography? In a nutshell, these examples illustrate what happens in the absence of appropriate cryptography. In all three cases discussed, there was no mechanism in place to verify that the systems were talking to legitimate users and that the messages received were not manipulated while in transit.

In the Mirai example, anyone with knowledge of the IoT devices’ IP addresses would have been able to access their login page. This information can be easily collected by scanning the public internet with tools such as nmap. So the designers’ assumption that the users would change the default device password to a strong individual one was the only line of defense. What the security engineers should have done instead is to add a cryptographic mechanism to give access to the login procedure only to legitimate users, for example, users in possession of a digital certificate or a private key.

In the case of Operation Aurora, the perimeter defense doctrine used by the affected companies treated every device within the trusted perimeter (typically, within a corporate network) as trustworthy by default. On this premise, every device inside the perimeter had access to all resources and systems within that perimeter.

As a result, anyone able to walk inside a company building or trick an arbitrary employee into clicking on a malicious link and infect their computer with malware would have been able to access all systems within the perimeter.

As a response to Operation Aurora, Google and other companies replaced perimeter defense with a zero trust security model that establishes trust by evaluating it on a per-transaction basis instead of basing trust on the network location (the perimeter) [155]. At the core of the zero trust security model is the ability to securely authenticate users and resources in order to prevent unauthorized access to data and services. Secure authentication, in turn, is built upon cryptography.

Finally, in the Jeep hack example, the open D-Bus over IP port allowed anyone connected to the vehicle’s infotainment system to execute arbitrary code in an unauthenticated manner. The possibility to access the vehicle remotely over the Sprint mobile network further increased the range of the attack. The system’s designers apparently assumed that the Sprint mobile network is a secure perimeter. What they should have done instead is to add a cryptographic mechanism to ensure that only legitimate users could log in to the Uconnect system.

1.6 Summary

In this chapter, we have provided an overview of the recent history of cryptography, starting in the 1970s, and identified some global trends that explain why cryptography has become more and more important over the last few decades, to a point where it is practically around you every time you access the internet or use a connected device. In the next chapter, you will learn about the general goals and objectives you can achieve with the help of cryptography. In particular, you will get to know cryptography’s main protagonists, Alice and Bob, and their ubiquitous opponents, Eve and Mallory.

Left arrow icon Right arrow icon

Key benefits

  • Learn about real-world cryptographic pitfalls and how to avoid them
  • Understand past attacks on TLS, how these attacks worked, and how they were fixed
  • Discover the inner workings of modern cryptography and its application within TLS
  • Purchase of the print or Kindle book includes a free PDF eBook

Description

TLS is the most widely used cryptographic protocol today, enabling e-commerce, online banking, and secure online communication. Written by Dr. Paul Duplys, Security, Privacy & Safety Research Lead at Bosch, and Dr. Roland Schmitz, Internet Security Professor at Stuttgart Media University, this book will help you gain a deep understanding of how and why TLS works, how past attacks on TLS were possible, and how vulnerabilities that enabled them were addressed in the latest TLS version 1.3. By exploring the inner workings of TLS, you’ll be able to configure it and use it more securely. Starting with the basic concepts, you’ll be led step by step through the world of modern cryptography, guided by the TLS protocol. As you advance, you’ll be learning about the necessary mathematical concepts from scratch. Topics such as public-key cryptography based on elliptic curves will be explained with a view on real-world applications in TLS. With easy-to-understand concepts, you’ll find out how secret keys are generated and exchanged in TLS, and how they are used to creating a secure channel between a client and a server. By the end of this book, you’ll have the knowledge to configure TLS servers securely. Moreover, you’ll have gained a deep knowledge of the cryptographic primitives that make up TLS.

Who is this book for?

This book is for IT professionals, cybersecurity professionals, security engineers, cryptographers, software developers, and administrators looking to gain a solid understanding of TLS specifics and their relationship with cryptography. This book can also be used by computer science and computer engineering students to learn about key cryptographic concepts in a clear, yet rigorous way with its applications in TLS. There are no specific prerequisites, but a basic familiarity with programming and mathematics will be helpful.

What you will learn

  • Understand TLS principles and protocols for secure internet communication
  • Find out how cryptographic primitives are used within TLS V1.3
  • Discover best practices for secure configuration and implementation of TLS
  • Evaluate and select appropriate cipher suites for optimal security
  • Get an in-depth understanding of common cryptographic vulnerabilities and ways to mitigate them
  • Explore forward secrecy and its importance in maintaining confidentiality
  • Understand TLS extensions and their significance in enhancing TLS functionality

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : Jan 29, 2024
Length: 712 pages
Edition : 1st
Language : English
ISBN-13 : 9781804611951
Category :
Concepts :

What do you get with a Packt Subscription?

Free for first 7 days. $19.99 p/m after that. Cancel any time!
Product feature icon Unlimited ad-free access to the largest independent learning library in tech. Access this title and thousands more!
Product feature icon 50+ new titles added per month, including many first-to-market concepts and exclusive early access to books as they are being written.
Product feature icon Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.
Product feature icon Thousands of reference materials covering every tech concept you need to stay up to date.
Subscribe now
View plans & pricing

Product Details

Publication date : Jan 29, 2024
Length: 712 pages
Edition : 1st
Language : English
ISBN-13 : 9781804611951
Category :
Concepts :

Packt Subscriptions

See our plans and pricing
Modal Close icon
€18.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
€189.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just €5 each
Feature tick icon Exclusive print discounts
€264.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just €5 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total 113.97
Network Architect's Handbook
€41.99
Defending APIs
€33.99
TLS Cryptography In-Depth
€37.99
Total 113.97 Stars icon

Table of Contents

29 Chapters
Part I Getting Started Chevron down icon Chevron up icon
Chapter 1: The Role of Cryptography in the Connected World Chevron down icon Chevron up icon
Chapter 2: Secure Channel and the CIA Triad Chevron down icon Chevron up icon
Chapter 3: A Secret to Share Chevron down icon Chevron up icon
Chapter 4: Encryption and Decryption Chevron down icon Chevron up icon
Chapter 5: Entity Authentication Chevron down icon Chevron up icon
Chapter 6: Transport Layer Security at a Glance Chevron down icon Chevron up icon
Part II Shaking Hands Chevron down icon Chevron up icon
Chapter 7: Public-Key Cryptography Chevron down icon Chevron up icon
Chapter 8: Elliptic Curves Chevron down icon Chevron up icon
Chapter 9: Digital Signatures Chevron down icon Chevron up icon
Chapter 10: Digital Certificates and Certification Authorities Chevron down icon Chevron up icon
Chapter 11: Hash Functions and Message Authentication Codes Chevron down icon Chevron up icon
Chapter 12: Secrets and Keys in TLS 1.3 Chevron down icon Chevron up icon
Chapter 13: TLS Handshake Protocol Revisited Chevron down icon Chevron up icon
Part III Off the Record Chevron down icon Chevron up icon
Chapter 14: Block Ciphers and Their Modes of Operation Chevron down icon Chevron up icon
Chapter 15: Authenticated Encryption Chevron down icon Chevron up icon
Chapter 16: The Galois Counter Mode Chevron down icon Chevron up icon
Chapter 17: TLS Record Protocol Revisited Chevron down icon Chevron up icon
Chapter 18: TLS Cipher Suites Chevron down icon Chevron up icon
Part IV Bleeding Hearts and Biting Poodles Chevron down icon Chevron up icon
Chapter 19: Attacks on Cryptography Chevron down icon Chevron up icon
Chapter 20: Attacks on the TLS Handshake Protocol Chevron down icon Chevron up icon
Chapter 21: Attacks on the TLS Record Protocol Chevron down icon Chevron up icon
Chapter 22: Attacks on TLS Implementations Chevron down icon Chevron up icon
Bibliography Chevron down icon Chevron up icon
Index Chevron down icon Chevron up icon
Other Books You Might Enjoy Chevron down icon Chevron up icon

Customer reviews

Rating distribution
Full star icon Full star icon Full star icon Full star icon Half star icon 4.7
(3 Ratings)
5 star 66.7%
4 star 33.3%
3 star 0%
2 star 0%
1 star 0%
Kamran Apr 30, 2024
Full star icon Full star icon Full star icon Full star icon Full star icon 5
The book gives you a deep dive into TLS and builds the necessary foundations
Amazon Verified review Amazon
Matthew Hibbert Apr 19, 2024
Full star icon Full star icon Full star icon Full star icon Full star icon 5
From its comprehensive exploration of TLS origins to its insightful coverage of vulnerabilities and solutions, this book is a treasure trove of knowledge for both seasoned professionals and eager learners alike.One of the book's standout features is its abundance of clear diagrams and practical examples, which make complex concepts accessible to readers of all levels. For instance, the authors skillfully illustrate how TLS works, guiding readers through its intricacies with clarity and precision.Moreover, the book doesn't shy away from addressing real-world challenges, delving into the various attacks on cryptography and TLS, and offering practical solutions. Whether it's discussing known vulnerabilities or exploring emerging threats, the authors provide valuable insights that are sure to resonate with readers.What truly impresses me is the sheer depth of information packed into this single volume. Despite the complexity of the subject matter, the authors manage to cover a vast array of topics without sacrificing clarity or coherence. It's evident that a tremendous amount of research and expertise went into crafting this book.
Amazon Verified review Amazon
Sanjeev Verma May 13, 2024
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
“TLS Cryptography In-Depth” is an applied cryptography book that illustrates how cryptographic principles are applied in real-world applications with TLS protocol as an example application. The book explains both the TLS protocol and cryptographic principles in considerable detail.This is a novel approach as most of the books focus on cryptography. This book goes a step further to explain how cryptographic principles are used in TLS, which is an underlying secure transportation protocol to access web resources. The book is well written and should be useful as an introductory text to university students and security professionals.This book is a good introduction to the subject matter. However, probably authors should have addressed advanced topics in cryptography such as post-quantum cryptography as industry has already started looking into that and will be most likely included in the next version of TLS.Also, advanced topics such as cryptographic binding of the bearer Tokens (such OAuth Token) to the underlying TLS protocol and client authentication (FIDO) could have been addressed by the author.I think that book needs some reorganization as well--the TLS topics and Cryptographic topics have been interleaved and that can be confusing to readers. There should be separation of topics and all the TLS topics should be included in a single Part of the book—say Part 2. Similarly, all the cryptographic concepts should be listed under a single Part of the book—say Part 3. Part 1 and Part 4 should remain as they currently are.In conclusion, the “TLS Cryptography In-Depth” is a well written book on a timely topic. It will be great if my suggestions regarding advanced topics and organization of the book can be incorporated in the next revision of the book. I will be more than happy to collaborate with the authors on improving the book if needed.
Amazon Verified review Amazon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

What is included in a Packt subscription? Chevron down icon Chevron up icon

A subscription provides you with full access to view all Packt and licnesed content online, this includes exclusive access to Early Access titles. Depending on the tier chosen you can also earn credits and discounts to use for owning content

How can I cancel my subscription? Chevron down icon Chevron up icon

To cancel your subscription with us simply go to the account page - found in the top right of the page or at https://subscription.packtpub.com/my-account/subscription - From here you will see the ‘cancel subscription’ button in the grey box with your subscription information in.

What are credits? Chevron down icon Chevron up icon

Credits can be earned from reading 40 section of any title within the payment cycle - a month starting from the day of subscription payment. You also earn a Credit every month if you subscribe to our annual or 18 month plans. Credits can be used to buy books DRM free, the same way that you would pay for a book. Your credits can be found in the subscription homepage - subscription.packtpub.com - clicking on ‘the my’ library dropdown and selecting ‘credits’.

What happens if an Early Access Course is cancelled? Chevron down icon Chevron up icon

Projects are rarely cancelled, but sometimes it's unavoidable. If an Early Access course is cancelled or excessively delayed, you can exchange your purchase for another course. For further details, please contact us here.

Where can I send feedback about an Early Access title? Chevron down icon Chevron up icon

If you have any feedback about the product you're reading, or Early Access in general, then please fill out a contact form here and we'll make sure the feedback gets to the right team. 

Can I download the code files for Early Access titles? Chevron down icon Chevron up icon

We try to ensure that all books in Early Access have code available to use, download, and fork on GitHub. This helps us be more agile in the development of the book, and helps keep the often changing code base of new versions and new technologies as up to date as possible. Unfortunately, however, there will be rare cases when it is not possible for us to have downloadable code samples available until publication.

When we publish the book, the code files will also be available to download from the Packt website.

How accurate is the publication date? Chevron down icon Chevron up icon

The publication date is as accurate as we can be at any point in the project. Unfortunately, delays can happen. Often those delays are out of our control, such as changes to the technology code base or delays in the tech release. We do our best to give you an accurate estimate of the publication date at any given time, and as more chapters are delivered, the more accurate the delivery date will become.

How will I know when new chapters are ready? Chevron down icon Chevron up icon

We'll let you know every time there has been an update to a course that you've bought in Early Access. You'll get an email to let you know there has been a new chapter, or a change to a previous chapter. The new chapters are automatically added to your account, so you can also check back there any time you're ready and download or read them online.

I am a Packt subscriber, do I get Early Access? Chevron down icon Chevron up icon

Yes, all Early Access content is fully available through your subscription. You will need to have a paid for or active trial subscription in order to access all titles.

How is Early Access delivered? Chevron down icon Chevron up icon

Early Access is currently only available as a PDF or through our online reader. As we make changes or add new chapters, the files in your Packt account will be updated so you can download them again or view them online immediately.

How do I buy Early Access content? Chevron down icon Chevron up icon

Early Access is a way of us getting our content to you quicker, but the method of buying the Early Access course is still the same. Just find the course you want to buy, go through the check-out steps, and you’ll get a confirmation email from us with information and a link to the relevant Early Access courses.

What is Early Access? Chevron down icon Chevron up icon

Keeping up to date with the latest technology is difficult; new versions, new frameworks, new techniques. This feature gives you a head-start to our content, as it's being created. With Early Access you'll receive each chapter as it's written, and get regular updates throughout the product's development, as well as the final course as soon as it's ready.We created Early Access as a means of giving you the information you need, as soon as it's available. As we go through the process of developing a course, 99% of it can be ready but we can't publish until that last 1% falls in to place. Early Access helps to unlock the potential of our content early, to help you start your learning when you need it most. You not only get access to every chapter as it's delivered, edited, and updated, but you'll also get the finalized, DRM-free product to download in any format you want when it's published. As a member of Packt, you'll also be eligible for our exclusive offers, including a free course every day, and discounts on new and popular titles.