From 5d051df5a7c0c1551677e6fe9d25590b4c3a4f88 Mon Sep 17 00:00:00 2001 From: Larry Peterson Date: Tue, 8 Jul 2025 13:45:03 -0700 Subject: [PATCH 1/6] first pass over examples --- systems.rst | 169 +++++++++++++++++++++++++++------------------------- 1 file changed, 88 insertions(+), 81 deletions(-) diff --git a/systems.rst b/systems.rst index aa3b593..72e5873 100644 --- a/systems.rst +++ b/systems.rst @@ -1,5 +1,5 @@ -Chapter 9: Example Systems -============================== +Chapter 9: Other Examples +============================ .. Assuming we keep a substantial set of examples, we should look for ways to highlight the underlying open source software (and the @@ -10,56 +10,53 @@ Chapter 9: Example Systems It's likely also the case that these are "Other" Example Systems, since new chapters are system focused. -We have now seen many of the components required to provide one or two -aspects of security. These components include cryptographic algorithms, -key predistribution mechanisms, and authentication protocols. In this -chapter, we examine some complete systems that use these components. - -These systems can be roughly categorized by the protocol layer at which -they operate. Systems that operate at the application layer include -Pretty Good Privacy (PGP), which provides electronic mail security, and -Secure Shell (SSH), a secure remote login facility. At the transport -layer, there is the IETF’s Transport Layer Security (TLS) standard and -the older protocol from which it derives, Secure Socket Layer (SSL). The -IPsec (IP Security) protocols, as their name implies, operate at the IP -(network) layer. 802.11i provides security at the link layer of wireless -networks. This chapter describes the salient features of each of these -approaches. - -You might reasonably wonder why security has to be provided at so many -different layers. One reason is that different threats require different -defensive measures, and this often translates into securing a different -protocol layer. For example, if your main concern is with a person in -the building next door snooping on your traffic as it flows between your -laptop and your 802.11 access point, then you probably want security at -the link layer. However, if you want to be really sure you are connected -to your bank’s website and preventing all the data that you send to the -bank from being read by curious employees of some Internet service -provider, then something that extends all the way from your machine to -the bank’s server—like the transport layer—may be the right place to -secure the traffic. As is often the case, there is no one-size-fits-all -solution. - -The security systems described below have the ability to vary which -cryptographic algorithms they use. The idea of making a security system -algorithm independent is a very good one, because you never know when -your favorite cryptographic algorithm might be proved to be -insufficiently strong for your purposes. It would be nice if you could -quickly change to a new algorithm without having to change the protocol -specification or implementation. Note the analogy to being able to -change keys without changing the algorithm; if one of your cryptographic -algorithms turns out to be flawed, it would be great if your entire -security architecture didn’t need an immediate redesign. +Having focused on how to use the available cryptographic and +authentication building blocks to secure the transport and network +layers, we now turn our attention to other examples of how Internet +systems are secured. The examples are part of the overall +*defense-in-depth* strategy introduced in Chapter 2; they address +specific threats that remain even when mechansism like TLS and DNSSEC +are deployed. + +The systems described in this chapter are at different layers: some +are are built into applications, some run at the IP layer, and some +secure network links. While they address different layer-specific +threats, what the examples have in common is that they all leverage +the same set of security builing blocks. Seeing how these building +blocks can be assembled in different ways to build different solutions +is main value of this chapter. To this end, the following sections +focus on the use case and corresponding threat, with a brief +description of how the system addresses the threat; no new algoritms +or fundamental capabilities are required. + +It is also noteworthy that in addition to taking avantage of existing +building blocks, the example system are highly configurable. The idea +of making a security system algorithm independent is a good one, +because you never know when your preferred cryptographic algorithm +might be proved to be insufficiently strong for your purposes. It +would be nice if you could quickly change to a new algorithm without +having to change the rest of the system. Note the analogy to being +able to change keys without changing the algorithm; if one of your +cryptographic algorithms turns out to be flawed, it would be great if +your entire security architecture didn’t need an immediate redesign. 9.1 Pretty Good Privacy (PGP) ------------------------------- Pretty Good Privacy (PGP) is an approach to providing authentication, -confidentiality, data integrity, and nonrepudiation. Originally devised -by Phil Zimmerman in 1991, it has evolved into an IETF standard known as -OpenPGP. As we saw in a previous chapter, PGP is notable for using a -“web of trust” model for distribution of keys rather than a tree-like -hierarchy. +confidentiality, data integrity, and nonrepudiation for email. +Originally devised by Phil Zimmerman in 1991, it has evolved into an +IETF standard known as OpenPGP. As we saw in Chapter 4, PGP is notable +for using a “web of trust” model for distribution of keys rather than +a tree-like hierarchy. + +The other thing of note about PGP is that it is *not* widely used, in +large part because most users elect to trust their email provider (or, +at least, are not concerned about their email being used for marketing +purposes). On the other hand, PGP is an option for users that put a +premium on privacy and being certain of who they are exchanging +with. The availability of easy-to-use client software is now making +that option more viable. PGP’s confidentiality and receiver authentication depend on the receiver of a message having a public key that is known to the sender. To @@ -124,33 +121,40 @@ delayed or replayed email). ------------------------ The Secure Shell (SSH) protocol is used to provide a remote login -service, replacing the less secure Telnet used in the early days of the -Internet. (SSH can also be used to remotely execute commands and -transfer files, but we will focus first on how SSH supports remote -login.) SSH is most often used to provide strong client/server -authentication/message integrity—where the SSH client runs on the user’s -desktop machine and the SSH server runs on some remote machine that the -user wants to log into—but it also supports confidentiality. Telnet -provides none of these capabilities. Note that “SSH” is often used to -refer to both the SSH protocol and applications that use it; you need to -figure out which from the context. - -To better appreciate the importance of SSH on today’s Internet, consider -a couple of the scenarios where it is used. Telecommuters, for example, -often subscribe to ISPs that offer high-speed Internet access at home, and -they use these ISPs (plus some chain of other ISPs) to reach machines -operated by their employer. This means that when a telecommuter logs -into a machine inside his employer’s data center, both the passwords and -all the data sent or received potentially passes through any number of +service, replacing the less secure Telnet used in the early days of +the Internet. SSH can also be used to remotely execute commands and +transfer files. It is most often used to provide strong client/server +authentication/message integrity—where the SSH client runs on the +user’s laptop (for example) and the SSH server runs on some remote +machine that the user wants to log into—but it also supports +confidentiality. Telnet provides none of these capabilities. Note that +“SSH” is often used to refer to both the SSH protocol and applications +that use it; you need to figure out which from the context. + +To better appreciate the importance of SSH in today’s Internet, +consider two scenarios where it is used. Telecommuters often subscribe +to ISPs that offer high-speed Internet access at home, and they use +these ISPs (plus some chain of other ISPs) to reach machines operated +by their employer. This means that when a telecommuter logs into a +machine inside his employer’s data center, both the passwords and all +the data sent or received potentially passes through any number of untrusted networks. SSH provides a way to encrypt the data sent over these connections and to improve the strength of the authentication -mechanism used to log in. (A similar situation occurs when said employee -connects to work using the public Wi-Fi at a coffee shop.) Another usage of -SSH is remote login to a router, perhaps to change its configuration or -read its log files; clearly, a network administrator wants to be sure -that he can log into a router securely and that unauthorized parties can -neither log in nor intercept the commands sent to the router or the output -sent back to the administrator. +mechanism used to log in. (A similar situation occurs when said +employee connects to work using the public Wi-Fi at a coffee shop.) + +A second common usage of SSH is to login into a remote router, server, +or VM for the purpose of managing it; for example, changing its +configuration, reading its log files, or installing the latest +software. Clearly, an administrator wants to be sure that he can log +into a remote machine securely and that unauthorized parties can +neither log in nor intercept the commands sent to the machine or the +output sent back to the administrator. This use case is common enough +that SSH is often incorporated into more sophisticated management +software that automates some aspect of remote management. This is +increasingly the case for tools that support Cloud DevOps, with +GitHub, Docker, Ansible, and Jenkins being popular examples that use +SSH's remote execution feature. The latest version of SSH, version 2, consists of three protocols: @@ -211,7 +215,7 @@ connect; standard SSH-TRANS only authenticates the server by default. The main thing you should take away from this discussion is that SSH is a fairly straightforward application of the protocols and -algorithms we have seen throughout this chapter. However, what +algorithms we have seen throughout this book. However, what sometimes makes SSH a challenge to understand is all the keys a user has to create and manage, where the exact interface is operating system dependent. For example, the OpenSSH package that runs on most @@ -250,12 +254,17 @@ network (VPN) using SSH tunnels in this way. 9.3 IP Security (IPsec) ------------------------- -One of the earliest efforts to integrate security -into the Internet sits at the IP layer. Support for IPsec, as the -architecture is called, is optional in IPv4 but mandatory in -IPv6. Indeed, better security was one of the stated goals of IPv6, -although it turned out that the central ideas could also be retrofitted -into IPv4 . +One of the earliest efforts to integrate security into the Internet +sits at the IP layer. Support for IPsec, as the architecture is +called, is optional in IPv4 but mandatory in IPv6. Indeed, better +security was one of the stated goals of IPv6, although it turned out +that the central ideas could also be retrofitted into IPv4. It's also +noteworthy that while the original intent was for IPsec to be part +securing the network infrastructrue (as discussed in the previous +chapter), today IPsec is most commonly used to implement secure +tunnels running on top of the public IP substrate. These tunnels +are often part of a Virtual Private Network (VPN), for example, +connecting a remote user to their "home" enterprise. IPsec is really a framework (as opposed to a single protocol or system) for providing a broad set of security services discussed throughout this @@ -447,7 +456,6 @@ that attackers will keep using that option to breach user accounts. This is one of the problems that needs to be addressed in the deployment of passkeys. - The WebAuthn spec allows for considerable implementation flexibility, but there are two broad categories of passkey implementation. One approach binds the key to a specific piece of hardware, such as a USB @@ -506,7 +514,6 @@ sites. Those who have led their development hope that they start to replace the ubiquitous password for user authentication. - 9.5 Wireless Security (802.11i) --------------------------------- From d53aa10d07e4ba8c21c12e241c39d46bbde58ab4 Mon Sep 17 00:00:00 2001 From: Larry Peterson Date: Wed, 9 Jul 2025 11:17:26 -0700 Subject: [PATCH 2/6] mention ssh3 --- systems.rst | 117 ++++++++++++++++++++++++++++------------------------ 1 file changed, 64 insertions(+), 53 deletions(-) diff --git a/systems.rst b/systems.rst index 72e5873..6de8f9c 100644 --- a/systems.rst +++ b/systems.rst @@ -15,30 +15,29 @@ authentication building blocks to secure the transport and network layers, we now turn our attention to other examples of how Internet systems are secured. The examples are part of the overall *defense-in-depth* strategy introduced in Chapter 2; they address -specific threats that remain even when mechansism like TLS and DNSSEC -are deployed. +specific threats—associated with specific use case—that remain even +when mechansism like TLS and DNSSEC are deployed. The systems described in this chapter are at different layers: some are are built into applications, some run at the IP layer, and some -secure network links. While they address different layer-specific +secure network links. But while they address different layer-specific threats, what the examples have in common is that they all leverage the same set of security builing blocks. Seeing how these building blocks can be assembled in different ways to build different solutions is main value of this chapter. To this end, the following sections -focus on the use case and corresponding threat, with a brief +focus on the use case and corresponding threat, with a high-level description of how the system addresses the threat; no new algoritms or fundamental capabilities are required. It is also noteworthy that in addition to taking avantage of existing -building blocks, the example system are highly configurable. The idea +building blocks, the example systems are highly configurable. The idea of making a security system algorithm independent is a good one, because you never know when your preferred cryptographic algorithm -might be proved to be insufficiently strong for your purposes. It -would be nice if you could quickly change to a new algorithm without -having to change the rest of the system. Note the analogy to being -able to change keys without changing the algorithm; if one of your -cryptographic algorithms turns out to be flawed, it would be great if -your entire security architecture didn’t need an immediate redesign. +might be proved to be insufficiently strong for your purposes. Note +the analogy to being able to change keys without changing the +algorithm; if one of your cryptographic algorithms turns out to be +flawed, it would be great if your entire security architecture didn’t +need an immediate redesign. 9.1 Pretty Good Privacy (PGP) ------------------------------- @@ -51,10 +50,10 @@ for using a “web of trust” model for distribution of keys rather than a tree-like hierarchy. The other thing of note about PGP is that it is *not* widely used, in -large part because most users elect to trust their email provider (or, -at least, are not concerned about their email being used for marketing -purposes). On the other hand, PGP is an option for users that put a -premium on privacy and being certain of who they are exchanging +large part because most users elect to trust their email provider (or +rather, are not concerned about their email being used for marketing +purposes). In contrast, PGP is an option for users that put a premium +on privacy and being certain about who they are exchanging messages with. The availability of easy-to-use client software is now making that option more viable. @@ -96,20 +95,21 @@ application reverses this process step-by-step to obtain the original plaintext message and confirm Alice’s digital signature—and reminds Bob of the level of trust he has in Alice’s public key. -Email has particular characteristics that allow PGP to embed an adequate -authentication protocol in this one-message data transmission protocol, -avoiding the need for any prior message exchange (and sidestepping some -of the complexities described in the previous chapter). Alice’s digital -signature suffices to authenticate her. Although there is no proof that -the message is timely, legitimate email isn’t guaranteed to be timely -either. There is also no proof that the message is original, but Bob is -an email user and probably a fault-tolerant human who can recover from -duplicate emails (which, again, are not out of the question under normal -operation anyway). Alice can be sure that only Bob could read the -message because the session key was encrypted with his public key. -Although this protocol doesn’t prove to Alice that Bob is actually there -and received the email, an authenticated email from Bob back to Alice -could do this. +PGP is not strictly for email, but email has particular +characteristics that allow PGP to embed an adequate authentication +protocol in this one-message data transmission protocol. This avoids +the need for any prior message exchange (and sidestepping some of the +complexities described in the earlier chapter). Alice’s digital +signature suffices to authenticate her. Although there is no proof +that the message is timely, legitimate email isn’t guaranteed to be +timely either. There is also no proof that the message is original, +but Bob is an email user and probably a fault-tolerant human who can +recover from duplicate emails (which, again, are not out of the +question under normal operation anyway). Alice can be sure that only +Bob could read the message because the session key was encrypted with +his public key. Although this protocol doesn’t prove to Alice that +Bob is actually there and received the email, an authenticated email +from Bob back to Alice could do this. The preceding discussion gives a good example of why application-layer security mechanisms can be helpful. Only with a full knowledge of how @@ -120,9 +120,9 @@ delayed or replayed email). 9.2 Secure Shell (SSH) ------------------------ -The Secure Shell (SSH) protocol is used to provide a remote login -service, replacing the less secure Telnet used in the early days of -the Internet. SSH can also be used to remotely execute commands and +The Secure Shell (SSH) protocol provides a remote login service, +replacing the less secure Telnet used in the early days of the +Internet. SSH can also be used to remotely execute commands and transfer files. It is most often used to provide strong client/server authentication/message integrity—where the SSH client runs on the user’s laptop (for example) and the SSH server runs on some remote @@ -156,7 +156,7 @@ increasingly the case for tools that support Cloud DevOps, with GitHub, Docker, Ansible, and Jenkins being popular examples that use SSH's remote execution feature. -The latest version of SSH, version 2, consists of three protocols: +The latest version of SSH, Version 2, consists of three protocols:\ [#]_ - SSH-TRANS, a transport layer protocol @@ -167,6 +167,11 @@ The latest version of SSH, version 2, consists of three protocols: We focus on the first two, which are involved in remote login. We briefly discuss the purpose of SSH-CONN at the end of the section. +.. [#] Version 3 of SSH (SSH3) is also being defined, but it is + currently an experimental effort optimized for web-based use + cases. For example, SSH3 runs on top of QUIC (which is UDP-based) + instead of TCP. SSH2 remains the widely adopted standard. + SSH-TRANS provides an encrypted channel between the client and server machines. It runs on top of a TCP connection. Any time a user uses an SSH application to log into a remote machine, the first step is to set @@ -238,7 +243,7 @@ machines (i.e., they are used on the client side). Finally, SSH has proven so useful as a system for securing remote login, it has been extended to also support other applications, such as sending -and receiving email. The idea is to run these applications over a secure +and receiving email. The idea is to run the applications over a secure “SSH tunnel.” This capability is called *port forwarding*, and it uses the SSH-CONN protocol. The idea is illustrated in :numref:`Figure %s `, where we see a client on host A indirectly @@ -246,10 +251,16 @@ communicating with a server on host B by forwarding its traffic through an SSH connection. The mechanism is called *port forwarding* because when messages arrive at the well-known SSH port on the server, SSH first decrypts the contents and then “forwards” the data to the actual port at -which the server is listening. This is just another sort of tunnel, -which in this case happens to provide confidentiality and -authentication. It’s possible to provide a form of virtual private -network (VPN) using SSH tunnels in this way. +which the server is listening. + +This is effectively a tunnel, which in this case happens to provide +confidentiality and authentication. (In practice, it ma also get you +through a corporate firewall, which leaves port 22 open.) It is +possible to provide a kind of virtual private network (VPN) using SSH +tunnels in this way. But unlike the VPN mechanism described in the +next section, it is a tunnel to a single remote machine rather than to +a remote network. The latter gives you access to *any* machine on the +local network. 9.3 IP Security (IPsec) ------------------------- @@ -262,21 +273,21 @@ that the central ideas could also be retrofitted into IPv4. It's also noteworthy that while the original intent was for IPsec to be part securing the network infrastructrue (as discussed in the previous chapter), today IPsec is most commonly used to implement secure -tunnels running on top of the public IP substrate. These tunnels -are often part of a Virtual Private Network (VPN), for example, -connecting a remote user to their "home" enterprise. - -IPsec is really a framework (as opposed to a single protocol or system) -for providing a broad set of security services discussed throughout this -book. IPsec provides three degrees of freedom. First, it is highly -modular, allowing users (or more likely, system administrators) to -select from a variety of cryptographic algorithms and specialized -security protocols. Second, IPsec allows users to select from a large -menu of security properties, including access control, integrity, -authentication, originality, and confidentiality. Third, IPsec can be -used to protect narrow streams (e.g., packets belonging to a particular -TCP connection being sent between a pair of hosts) or wide streams -(e.g., all packets flowing between a pair of routers or locations). +tunnels running on top of the public Internet. These tunnels are often +part of a Virtual Private Network (VPN), for example, connecting a +remote user to their "home" enterprise network. + +IPsec is really a framework (as opposed to a single protocol or +system) for providing a broad set of security services. It provides +three degrees of freedom. First, it is highly modular, allowing users +(or more likely, system administrators) to select from a variety of +cryptographic algorithms and specialized security protocols. Second, +IPsec allows users to select from a large menu of security properties, +including access control, integrity, authentication, originality, and +confidentiality. Third, IPsec can be used to protect narrow streams +(e.g., packets belonging to a particular TCP connection being sent +between a pair of hosts) or wide streams (e.g., all packets flowing +between a pair of routers or locations). When viewed from a high level, IPsec consists of two parts. The first part is a pair of protocols that implement the available security From 86af1734b2818e32f48aef9d316e529df5735875 Mon Sep 17 00:00:00 2001 From: Larry Peterson Date: Wed, 9 Jul 2025 14:47:25 -0700 Subject: [PATCH 3/6] 5G sidebar --- systems.rst | 203 +++++++++++++++++++++++++++++++--------------------- 1 file changed, 120 insertions(+), 83 deletions(-) diff --git a/systems.rst b/systems.rst index 6de8f9c..54fe05f 100644 --- a/systems.rst +++ b/systems.rst @@ -13,23 +13,22 @@ Chapter 9: Other Examples Having focused on how to use the available cryptographic and authentication building blocks to secure the transport and network layers, we now turn our attention to other examples of how Internet -systems are secured. The examples are part of the overall -*defense-in-depth* strategy introduced in Chapter 2; they address -specific threats—associated with specific use case—that remain even -when mechansism like TLS and DNSSEC are deployed. +systems are secured. The examples address specific threats—associated +with specific use cases—that remain even when mechanism like TLS and +DNSSEC are deployed. The systems described in this chapter are at different layers: some are are built into applications, some run at the IP layer, and some secure network links. But while they address different layer-specific threats, what the examples have in common is that they all leverage -the same set of security builing blocks. Seeing how these building +the same set of security building blocks. Seeing how these building blocks can be assembled in different ways to build different solutions is main value of this chapter. To this end, the following sections focus on the use case and corresponding threat, with a high-level -description of how the system addresses the threat; no new algoritms +description of how the system addresses the threat; no new algorithms or fundamental capabilities are required. -It is also noteworthy that in addition to taking avantage of existing +It is also noteworthy that in addition to taking advantage of existing building blocks, the example systems are highly configurable. The idea of making a security system algorithm independent is a good one, because you never know when your preferred cryptographic algorithm @@ -136,7 +135,7 @@ consider two scenarios where it is used. Telecommuters often subscribe to ISPs that offer high-speed Internet access at home, and they use these ISPs (plus some chain of other ISPs) to reach machines operated by their employer. This means that when a telecommuter logs into a -machine inside his employer’s data center, both the passwords and all +machine inside their employer’s data center, both the passwords and all the data sent or received potentially passes through any number of untrusted networks. SSH provides a way to encrypt the data sent over these connections and to improve the strength of the authentication @@ -145,16 +144,16 @@ employee connects to work using the public Wi-Fi at a coffee shop.) A second common usage of SSH is to login into a remote router, server, or VM for the purpose of managing it; for example, changing its -configuration, reading its log files, or installing the latest -software. Clearly, an administrator wants to be sure that he can log -into a remote machine securely and that unauthorized parties can -neither log in nor intercept the commands sent to the machine or the -output sent back to the administrator. This use case is common enough -that SSH is often incorporated into more sophisticated management -software that automates some aspect of remote management. This is -increasingly the case for tools that support Cloud DevOps, with -GitHub, Docker, Ansible, and Jenkins being popular examples that use -SSH's remote execution feature. +configuration, reading its log files, or installing the latest software. +Clearly, administrators want to be sure that they can log into a +remote machine securely and that unauthorized parties can neither log +in nor intercept the commands sent to the machine or the output sent +back to the administrator. This use case is common enough that SSH is +often incorporated into more sophisticated management software that +automates some aspect of remote operations. This is increasingly the +case for tools that support Cloud DevOps, with GitHub, Docker, +Ansible, and Jenkins being popular examples that use SSH's remote +execution feature. The latest version of SSH, Version 2, consists of three protocols:\ [#]_ @@ -220,19 +219,20 @@ connect; standard SSH-TRANS only authenticates the server by default. The main thing you should take away from this discussion is that SSH is a fairly straightforward application of the protocols and -algorithms we have seen throughout this book. However, what -sometimes makes SSH a challenge to understand is all the keys a user -has to create and manage, where the exact interface is operating -system dependent. For example, the OpenSSH package that runs on most -Unix machines supports a command that can be used to create -public/private key pairs. These keys are then stored in various files -in directory in the user’s home directory. For example, file -``~/.ssh/known_hosts`` records the keys for all the hosts the user has -logged into, file ``~/.ssh/authorized_keys`` contains the public keys -needed to authenticate the user when he or she logs into this machine -(i.e., they are used on the server side), and file ``~/.ssh/id_rsa`` -contains the private keys needed to authenticate the user on remote -machines (i.e., they are used on the client side). +algorithms we have seen throughout this book. However, what sometimes +makes SSH a challenge to understand is all the keys a user has to +create and manage, where the exact interface is operating system +dependent. For example, the OpenSSH package that runs on most Unix +machines (e.g., Linux, MacOS) supports a command (``ssh-keygen``) that +can be used to create public/private key pairs. These keys are then +stored in various files in directory in the user’s home directory. For +example, file ``~/.ssh/known_hosts`` records the keys for all the +hosts the user has logged into, file ``~/.ssh/authorized_keys`` +contains the public keys needed to authenticate the user when he or +she logs into this machine (i.e., they are used on the server side), +and file ``~/.ssh/id_rsa`` contains the private keys needed to +authenticate the user on remote machines (i.e., they are used on the +client side). .. _fig-ssh-tunnel: .. figure:: figures/f08-14-9780123850591.png @@ -241,26 +241,26 @@ machines (i.e., they are used on the client side). Using SSH port forwarding to secure other TCP-based applications. -Finally, SSH has proven so useful as a system for securing remote login, -it has been extended to also support other applications, such as sending -and receiving email. The idea is to run the applications over a secure -“SSH tunnel.” This capability is called *port forwarding*, and it uses -the SSH-CONN protocol. The idea is illustrated in :numref:`Figure -%s `, where we see a client on host A indirectly -communicating with a server on host B by forwarding its traffic through -an SSH connection. The mechanism is called *port forwarding* because -when messages arrive at the well-known SSH port on the server, SSH first -decrypts the contents and then “forwards” the data to the actual port at -which the server is listening. - -This is effectively a tunnel, which in this case happens to provide -confidentiality and authentication. (In practice, it ma also get you -through a corporate firewall, which leaves port 22 open.) It is -possible to provide a kind of virtual private network (VPN) using SSH -tunnels in this way. But unlike the VPN mechanism described in the -next section, it is a tunnel to a single remote machine rather than to -a remote network. The latter gives you access to *any* machine on the -local network. +Finally, SSH has proven so useful for securing remote login that it +has been extended to also support other applications (e.g., sending +and receiving email). The idea is to run the applications over a +secure “SSH tunnel.” This capability is called *port forwarding*, and +it uses the SSH-CONN protocol. The idea is illustrated in +:numref:`Figure %s `, where we see a client on host A +indirectly communicating with a server on host B by forwarding its +traffic through an SSH connection. The mechanism is called *port +forwarding* because when messages arrive at the well-known SSH port on +the server, SSH first decrypts the contents and then “forwards” the +data to the actual port at which the server is listening. + +Port forwarding effectively creates a secure tunnel that provides +confidentiality and authentication. (In practice, it sometimes also +gets you through a corporate firewall, which often leave port 22 +open.) It is possible to provide a kind of virtual private network +(VPN) using SSH tunnels in this way, but unlike the VPN mechanism +described in the next section, SSH tunnels to a single remote machine +rather than to a remote network. The latter gives you access to *any* +machine on the local network. 9.3 IP Security (IPsec) ------------------------- @@ -271,7 +271,7 @@ called, is optional in IPv4 but mandatory in IPv6. Indeed, better security was one of the stated goals of IPv6, although it turned out that the central ideas could also be retrofitted into IPv4. It's also noteworthy that while the original intent was for IPsec to be part -securing the network infrastructrue (as discussed in the previous +securing the network infrastructure (as discussed in the previous chapter), today IPsec is most commonly used to implement secure tunnels running on top of the public Internet. These tunnels are often part of a Virtual Private Network (VPN), for example, connecting a @@ -374,15 +374,16 @@ destination. An IP packet with a nested IP packet encapsulated using ESP in tunnel mode. Note that the inner and outer packets have different addresses. -These tunnels may also be configured to use ESP with confidentiality and -authentication, thus preventing unauthorized access to the data that -traverses this virtual link and ensuring that no spurious data is -received at the far end of the tunnel. Furthermore, tunnels can provide -traffic confidentiality, since multiplexing multiple flows through a -single tunnel obscures information about how much traffic is flowing -between particular endpoints. A network of such tunnels can be used to -implement an entire virtual private network. Hosts communicating over a -VPN need not even be aware that it exists. +These tunnels may also be configured to use ESP with confidentiality +and authentication, thus preventing unauthorized access to the data +that traverses this virtual link and ensuring that no spurious data is +received at the far end of the tunnel. Furthermore, tunnels can +provide traffic confidentiality, since multiplexing multiple flows +through a single tunnel obscures information about how much traffic is +flowing between particular endpoints. And as mentioned in the +introduction to this section, a network of such tunnels can be used to +implement an entire virtual private network. Hosts communicating over +a VPN need not even be aware that it exists. 9.4 Web Authentication (WebAuthn) and Passkeys ----------------------------------------------- @@ -431,8 +432,8 @@ defined in the Web Authentication (WebAuthn) specification of the W3C efforts including those of the FIDO alliance (FIDO = Fast Identity Online). -The basic idea behind passkeys is simple enough: a user (or more -likely, a device owned by the user) creates a private/public key pair +The basic idea behind passkeys is simple: a user (or more likely, a +device owned by the user) creates a private/public key pair specifically for a single web site and provides the public key to the site. The user proves their identity to the web site using some other method such as a previously established user name and password. The @@ -440,7 +441,10 @@ web site stores the public key for subsequent use. The next time that the user wants to authenticate to the web site, the site issues a challenge to the user, who uses the locally stored private key to sign their response to the challenge. The web site uses the stored public -key to authenticate the user. +key to authenticate the user. Said another way, if you are familiar +with SSH's use of public/private key pairs to authenticate a user +logging into a remote server, you understand how passkeys are used to +log into a remote web service. The fact that the process is bootstrapped by getting the user to authenticate using a traditional approach (such as user name and @@ -475,18 +479,17 @@ names as the commercial offerings and standards around them have evolved. The generic names include U2F (universal second factor) and FIDO (from the FIDO Alliance). -Now that biometric -authentication, such as facial and fingerprint recognition, is -available on many devices, it is common to require biometric -authentication to access a passkey. So a passkey might be stored on a -mobile phone and require facial recognition of the owner before the -passkey can be accessed. - -The second class of passkey implementation allows the credentials to be -copied among multiple devices, typically using some sort of password -manager to keep the credentials secure and synchronized across -devices. In this case, the private/public key pair is stored in the -password manager and then is made available to the user across +Now that biometric authentication, such as facial and fingerprint +recognition, is available on many devices, it is common to require +biometric authentication to access a passkey. So a passkey might be +stored on a mobile phone and require facial recognition of the owner +before the passkey can be accessed. + +The second class of passkey implementation allows the credentials to +be copied among multiple devices, typically using some sort of +password manager to keep the credentials secure and synchronized +across devices. In this case, the private/public key pair is stored in +the password manager and then is made available to the user across different devices (laptops, mobile phones, etc.) when they need the passkey. @@ -543,10 +546,6 @@ corporate network if that same computer has, say, an Ethernet connection as well. Consequently, there has been considerable work on securing Wi-Fi links. -Somewhat surprisingly, one of the early security techniques developed -for 802.11, known as Wired Equivalent Privacy (WEP), turned out to be -seriously flawed and quite easily breakable. - The IEEE 802.11i standard provides authentication, message integrity, and confidentiality to 802.11 (Wi-Fi) at the link layer. *WPA3* (Wi-Fi Protected Access 3) is often used as a synonym for 802.11i, although it @@ -554,9 +553,47 @@ is technically a trademark of the Wi-Fi Alliance that certifies product compliance with 802.11i. For backward compatibility, 802.11i includes definitions of -first-generation security algorithms—including WEP—that are now known to -have major security flaws. We will focus here on 802.11i’s newer, -stronger algorithms. +first-generation security algorithms—including Wired Equivalent +Privacy (WEP)—that are now known to have major security flaws. We will +focus here on 802.11i’s newer, stronger algorithms. + +.. admonition:: Securing Mobile Cellular Networks + + The other widely used wireless networking technology is the Mobile + Cellular Network, today ubiquitously known as 5G. The biggest + difference between 5G and Wi-Fi is that the Mobile Network Operator + (MNO)—the counterpart of an enterprise network administrator—has + more direct control over the devices that are allowed to connect to + their network. Specifically, the MNO provides a Subscriber Identity + Module (SIM) card that must be present in the mobile device. This + SIM hosts a small database that includes a globally unique + identifier (known as an IMSI, for International Mobile Subscriber + Identifier) and a secret key. + + When a device first becomes active, it communicates with a nearby + base station over an unauthenticated radio channel. The base + station forwards the request to a backend server over a secure + backhaul connection, and that server (assuming it recognizes the + IMSI) initiates an authentication protocol with the device. There + are a set of options for authentication and encryption, but AES is + commonly used. Note that this authentication exchange is initially + in the clear since the base station to device channel is not yet + secure. (The 5G specification uses significantly more precise + terminology for all its components, but "backend server" conveys + the basic idea; it is analogous to the AS used by Wi-Fi.) + + Once the device and backend server are satisfied with each other's + identity, the server informs the other 5G components of the + parameters they will need to service the device (e.g., the IP + address assigned to the device and the appropriate QoS + parameters). It also instructs the base station to establish an + encrypted channel to the device and gives the device the symmetric + key it will subsequently use for the encrypted data channel with + the base station. This symmetric key is encrypted using the public + key of the device, so only the device can decrypt it. It does this + using the secret key on its SIM card. Once complete, the device can + use this encrypted channel to send and receive data over the + wireless link to the base station. 802.11i authentication supports two modes. In either mode, the end result of successful authentication is a shared Pairwise Master Key. From a55523e8dbdd071e0a99aead8b313209fe67310f Mon Sep 17 00:00:00 2001 From: Larry Peterson Date: Wed, 9 Jul 2025 15:07:41 -0700 Subject: [PATCH 4/6] fixed sidebar --- systems.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/systems.rst b/systems.rst index 54fe05f..beceb1e 100644 --- a/systems.rst +++ b/systems.rst @@ -557,9 +557,9 @@ first-generation security algorithms—including Wired Equivalent Privacy (WEP)—that are now known to have major security flaws. We will focus here on 802.11i’s newer, stronger algorithms. -.. admonition:: Securing Mobile Cellular Networks +.. sidebar:: Securing Mobile Cellular Networks - The other widely used wireless networking technology is the Mobile + *The other widely used wireless networking technology is the Mobile Cellular Network, today ubiquitously known as 5G. The biggest difference between 5G and Wi-Fi is that the Mobile Network Operator (MNO)—the counterpart of an enterprise network administrator—has @@ -568,9 +568,9 @@ focus here on 802.11i’s newer, stronger algorithms. Module (SIM) card that must be present in the mobile device. This SIM hosts a small database that includes a globally unique identifier (known as an IMSI, for International Mobile Subscriber - Identifier) and a secret key. + Identifier) and a secret key.* - When a device first becomes active, it communicates with a nearby + *When a device first becomes active, it communicates with a nearby base station over an unauthenticated radio channel. The base station forwards the request to a backend server over a secure backhaul connection, and that server (assuming it recognizes the @@ -580,9 +580,9 @@ focus here on 802.11i’s newer, stronger algorithms. in the clear since the base station to device channel is not yet secure. (The 5G specification uses significantly more precise terminology for all its components, but "backend server" conveys - the basic idea; it is analogous to the AS used by Wi-Fi.) + the basic idea; it is analogous to the AS used by Wi-Fi.)* - Once the device and backend server are satisfied with each other's + *Once the device and backend server are satisfied with each other's identity, the server informs the other 5G components of the parameters they will need to service the device (e.g., the IP address assigned to the device and the appropriate QoS @@ -593,7 +593,7 @@ focus here on 802.11i’s newer, stronger algorithms. key of the device, so only the device can decrypt it. It does this using the secret key on its SIM card. Once complete, the device can use this encrypted channel to send and receive data over the - wireless link to the base station. + wireless link to the base station.* 802.11i authentication supports two modes. In either mode, the end result of successful authentication is a shared Pairwise Master Key. From 9639b6dbe1220b237e7a08a4a9040ac330d78dfe Mon Sep 17 00:00:00 2001 From: Larry Peterson Date: Wed, 9 Jul 2025 19:52:02 -0700 Subject: [PATCH 5/6] renumber sections --- systems.rst | 117 ++++++++++++++++++++++++++-------------------------- 1 file changed, 59 insertions(+), 58 deletions(-) diff --git a/systems.rst b/systems.rst index beceb1e..86eed9c 100644 --- a/systems.rst +++ b/systems.rst @@ -1,4 +1,4 @@ -Chapter 9: Other Examples +Chapter 7: Other Example Systems ============================ .. Assuming we keep a substantial set of examples, we should look @@ -11,11 +11,10 @@ Chapter 9: Other Examples since new chapters are system focused. Having focused on how to use the available cryptographic and -authentication building blocks to secure the transport and network -layers, we now turn our attention to other examples of how Internet -systems are secured. The examples address specific threats—associated -with specific use cases—that remain even when mechanism like TLS and -DNSSEC are deployed. +authentication building blocks to secure the transport layer, we now +turn our attention to other examples of how Internet systems are +secured. The examples address specific threats—associated with +specific use cases—that remain even when TLS is deployed. The systems described in this chapter are at different layers: some are are built into applications, some run at the IP layer, and some @@ -38,7 +37,7 @@ algorithm; if one of your cryptographic algorithms turns out to be flawed, it would be great if your entire security architecture didn’t need an immediate redesign. -9.1 Pretty Good Privacy (PGP) +7.1 Pretty Good Privacy (PGP) ------------------------------- Pretty Good Privacy (PGP) is an approach to providing authentication, @@ -116,7 +115,7 @@ the application works can you make the right choices about which attacks to defend against (like forged email) versus which to ignore (like delayed or replayed email). -9.2 Secure Shell (SSH) +7.2 Secure Shell (SSH) ------------------------ The Secure Shell (SSH) protocol provides a remote login service, @@ -254,15 +253,16 @@ the server, SSH first decrypts the contents and then “forwards” the data to the actual port at which the server is listening. Port forwarding effectively creates a secure tunnel that provides -confidentiality and authentication. (In practice, it sometimes also -gets you through a corporate firewall, which often leave port 22 -open.) It is possible to provide a kind of virtual private network -(VPN) using SSH tunnels in this way, but unlike the VPN mechanism -described in the next section, SSH tunnels to a single remote machine -rather than to a remote network. The latter gives you access to *any* -machine on the local network. - -9.3 IP Security (IPsec) +confidentiality and authentication. It is possible to provide a kind +of virtual private network (VPN) using SSH tunnels in this way, but +unlike the VPN mechanism described in the next section, SSH tunnels to +a single remote machine rather than to a remote network. The latter +gives you access to *any* machine on the local network. In practice, +it is also the case that corporate firewalls often block port 22 (SSH's +well-known port) limiting the situations in which SSH works as a +VPN-like tunnel. + +7.3 IP Security (IPsec) ------------------------- One of the earliest efforts to integrate security into the Internet @@ -271,7 +271,7 @@ called, is optional in IPv4 but mandatory in IPv6. Indeed, better security was one of the stated goals of IPv6, although it turned out that the central ideas could also be retrofitted into IPv4. It's also noteworthy that while the original intent was for IPsec to be part -securing the network infrastructure (as discussed in the previous +securing the network infrastructure (as discussed in the next chapter), today IPsec is most commonly used to implement secure tunnels running on top of the public Internet. These tunnels are often part of a Virtual Private Network (VPN), for example, connecting a @@ -385,7 +385,7 @@ introduction to this section, a network of such tunnels can be used to implement an entire virtual private network. Hosts communicating over a VPN need not even be aware that it exists. -9.4 Web Authentication (WebAuthn) and Passkeys +7.4 Web Authentication (WebAuthn) and Passkeys ----------------------------------------------- While public key cryptography has been well understood for decades, @@ -528,7 +528,7 @@ sites. Those who have led their development hope that they start to replace the ubiquitous password for user authentication. -9.5 Wireless Security (802.11i) +7.5 Wireless Security (802.11i) --------------------------------- Wireless links are particularly exposed to security threats due to the @@ -557,44 +557,6 @@ first-generation security algorithms—including Wired Equivalent Privacy (WEP)—that are now known to have major security flaws. We will focus here on 802.11i’s newer, stronger algorithms. -.. sidebar:: Securing Mobile Cellular Networks - - *The other widely used wireless networking technology is the Mobile - Cellular Network, today ubiquitously known as 5G. The biggest - difference between 5G and Wi-Fi is that the Mobile Network Operator - (MNO)—the counterpart of an enterprise network administrator—has - more direct control over the devices that are allowed to connect to - their network. Specifically, the MNO provides a Subscriber Identity - Module (SIM) card that must be present in the mobile device. This - SIM hosts a small database that includes a globally unique - identifier (known as an IMSI, for International Mobile Subscriber - Identifier) and a secret key.* - - *When a device first becomes active, it communicates with a nearby - base station over an unauthenticated radio channel. The base - station forwards the request to a backend server over a secure - backhaul connection, and that server (assuming it recognizes the - IMSI) initiates an authentication protocol with the device. There - are a set of options for authentication and encryption, but AES is - commonly used. Note that this authentication exchange is initially - in the clear since the base station to device channel is not yet - secure. (The 5G specification uses significantly more precise - terminology for all its components, but "backend server" conveys - the basic idea; it is analogous to the AS used by Wi-Fi.)* - - *Once the device and backend server are satisfied with each other's - identity, the server informs the other 5G components of the - parameters they will need to service the device (e.g., the IP - address assigned to the device and the appropriate QoS - parameters). It also instructs the base station to establish an - encrypted channel to the device and gives the device the symmetric - key it will subsequently use for the encrypted data channel with - the base station. This symmetric key is encrypted using the public - key of the device, so only the device can decrypt it. It does this - using the secret key on its SIM card. Once complete, the device can - use this encrypted channel to send and receive data over the - wireless link to the base station.* - 802.11i authentication supports two modes. In either mode, the end result of successful authentication is a shared Pairwise Master Key. *Personal mode*, also known as *Pre-Shared Key (PSK) mode*, provides @@ -636,6 +598,45 @@ malicious AP. The end result of a successful authentication is a Pairwise Master Key shared between the wireless device and the AS, which the AS then conveys to the AP. + +.. sidebar:: Securing Mobile Cellular Networks + + *The other widely used wireless networking technology is the Mobile + Cellular Network, today ubiquitously known as 5G. The biggest + difference between 5G and Wi-Fi is that the Mobile Network Operator + (MNO)—the counterpart of an enterprise network administrator—has + more direct control over the devices that are allowed to connect to + their network. Specifically, the MNO provides a Subscriber Identity + Module (SIM) card that must be present in the mobile device. This + SIM contains a small database that includes a globally unique + identifier (known as an IMSI, for International Mobile Subscriber + Identifier) and a secret key.* + + *When a device first becomes active, it communicates with a nearby + base station over an unauthenticated radio channel. The base + station forwards the request to a backend server over a secure + backhaul connection, and that server (assuming it recognizes the + IMSI) initiates an authentication protocol with the device. There + are a set of options for authentication and encryption, but AES is + commonly used. Note that this authentication exchange is initially + in the clear since the base station to device channel is not yet + secure. (The 5G specification uses significantly more precise + terminology for all its components, but "backend server" conveys + the basic idea; it is analogous to the AS used by Wi-Fi.)* + + *Once the device and backend server are satisfied with each other's + identity, the server informs the other 5G components of the + parameters they will need to service the device (e.g., the IP + address assigned to the device and the appropriate QoS + parameters). It also instructs the base station to establish an + encrypted channel to the device and gives the device the symmetric + key it will subsequently use for the encrypted data channel with + the base station. This symmetric key is encrypted using the public + key of the device, so only the device can decrypt it. It does this + using the secret key on its SIM card. Once complete, the device can + use this encrypted channel to send and receive data over the + wireless link to the base station.* + One of the main differences between the stronger AS-based mode and the weaker personal mode is that the former readily supports a unique key per client. This in turn makes it easier to change the set of clients From 22c3c48082c34820f384ffc4475dcf8ad59a229b Mon Sep 17 00:00:00 2001 From: Larry Peterson Date: Wed, 9 Jul 2025 19:54:55 -0700 Subject: [PATCH 6/6] lint fix --- systems.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/systems.rst b/systems.rst index 86eed9c..1be8372 100644 --- a/systems.rst +++ b/systems.rst @@ -1,5 +1,5 @@ Chapter 7: Other Example Systems -============================ +======================================== .. Assuming we keep a substantial set of examples, we should look for ways to highlight the underlying open source software (and the @@ -38,7 +38,7 @@ flawed, it would be great if your entire security architecture didn’t need an immediate redesign. 7.1 Pretty Good Privacy (PGP) -------------------------------- +------------------------------------------ Pretty Good Privacy (PGP) is an approach to providing authentication, confidentiality, data integrity, and nonrepudiation for email. @@ -263,7 +263,7 @@ well-known port) limiting the situations in which SSH works as a VPN-like tunnel. 7.3 IP Security (IPsec) -------------------------- +-------------------------------- One of the earliest efforts to integrate security into the Internet sits at the IP layer. Support for IPsec, as the architecture is @@ -386,7 +386,7 @@ implement an entire virtual private network. Hosts communicating over a VPN need not even be aware that it exists. 7.4 Web Authentication (WebAuthn) and Passkeys ------------------------------------------------ +---------------------------------------------------------------- While public key cryptography has been well understood for decades, and forms the basis for authentication of web sites using Transport @@ -529,7 +529,7 @@ replace the ubiquitous password for user authentication. 7.5 Wireless Security (802.11i) ---------------------------------- +-------------------------------------------- Wireless links are particularly exposed to security threats due to the lack of any physical security on the medium. While the convenience of