diff --git a/assets/images/network/transport/TCP_header.png b/assets/images/network/transport/TCP_header.png new file mode 100644 index 0000000..36e772e Binary files /dev/null and b/assets/images/network/transport/TCP_header.png differ diff --git a/assets/images/network/transport/UDP.png b/assets/images/network/transport/UDP.png new file mode 100644 index 0000000..0746f16 Binary files /dev/null and b/assets/images/network/transport/UDP.png differ diff --git a/crypto/key-exchange.md b/crypto/key-exchange.md index aaf303b..601ac5a 100644 --- a/crypto/key-exchange.md +++ b/crypto/key-exchange.md @@ -64,7 +64,7 @@ As far as we know, there is no efficient algorithm to deduce $$S=g^{ab} \bmod p$ {% comment %} do we still need this paragraph? -peyrin sp21 {% endcomment %} -Here is how this applies to secure communication among computers. In a computer network, each participant could pick a secret value $$x$$, compute $$X=g^x \bmodp$$, and publish $$X$$ for all time. Then any pair of participants who want to hold a conversation could look up each other's public value and use the Diffie-Hellman scheme to agree on a secret key known only to those two parties. This means that the work of picking $$p$$, $$g$$, $$x$$, and $$X$$ can be done in advance, and each time a new pair of parties want to communicate, they each perform only one modular exponentiation. Thus, this can be an efficient way to set up shared keys. +Here is how this applies to secure communication among computers. In a computer network, each participant could pick a secret value $$x$$, compute $$X=g^x \bmod p$$, and publish $$X$$ for all time. Then any pair of participants who want to hold a conversation could look up each other's public value and use the Diffie-Hellman scheme to agree on a secret key known only to those two parties. This means that the work of picking $$p$$, $$g$$, $$x$$, and $$X$$ can be done in advance, and each time a new pair of parties want to communicate, they each perform only one modular exponentiation. Thus, this can be an efficient way to set up shared keys. Here is a summary of Diffie-Hellman key exchange: diff --git a/crypto/symmetric.md b/crypto/symmetric.md index 70a7ac2..7935156 100644 --- a/crypto/symmetric.md +++ b/crypto/symmetric.md @@ -20,7 +20,7 @@ A more formal, rigorous definition of confidentiality is: the ciphertext $$C$$ s We can further formalize this definition by designing an experiment to test whether the attacker has learned any additional information. Consider the following experiment: Alice has encrypted and sent one of two messages, either $$M_0$$ or $$M_1$$, and the attacker, Eve, has no idea which was sent. Eve tries to guess which was sent by looking at the ciphertext. If the encryption scheme is confidential, then Eve's probability of guessing which message was sent should be $$1/2$$, which is the same probability as if she had not intercepted the ciphertext at all, and was instead guessing at random. -We can adapt this experiment to different threat models by allowing Eve to perform further actions as an attacker. For example, Eve might be allowed to trick Alice into encrypting some messages of Eve's choosing. Eve might also be allowed to trick Alice into decrypting some ciphertexts of Eve's choosing. In this class, we will be focusing on the chosen-plaintext attack model, which means Eve can trick Alice into encrypting some messages, but she cannot trick Alice into decrypting some messages. +We can adapt this experiment to different threat models by allowing Eve to perform further actions as an attacker. For example, Eve might be allowed to trick Alice into encrypting some messages of Eve's choosing. Eve might also be allowed to trick Bob into decrypting some ciphertexts of Eve's choosing. In this class, we will be focusing on the chosen-plaintext attack model, which means Eve can trick Alice into encrypting some messages, but she cannot trick Alice into decrypting some messages. In summary, our definition of confidentiality says that even if Eve can trick Alice into encrypting some messages, she still cannot distinguish whether Alice sent $$M_0$$ or $$M_1$$ in the experiment. This definition is known as indistinguishability under chosen plaintext attack, or IND-CPA. We can use an experiment or game, played between the adversary Eve and the challenger Alice, to formally prove that a given encryption scheme is IND-CPA secure or show that it is not IND-CPA secure. @@ -292,7 +292,7 @@ operation](/assets/images/crypto/symmetric/CFB_decryption.png) $$ \begin{cases} - Z*0 = IV \\ Z_i = E_K(Z*{i-1}) \\ C_i = M_i \oplus Z_i + Z_0 = IV \\ Z_i = E_K(Z*{i-1}) \\ C_i = M_i \oplus Z_i \end{cases} $$ diff --git a/index.md b/index.md index 9f8c416..46aec4f 100644 --- a/index.md +++ b/index.md @@ -13,7 +13,9 @@ This is the textbook for [CS 161: Computer Security](https://cs161.org/) at [UC ## Corrections -As of the Spring 2024 semester, this textbook is still being actively maintained and updated. Please contact [cs161-staff@berkeley.edu](mailto:cs161-staff@berkeley.edu) for information regarding corrections. +As of the Spring 2024 semester, this textbook is still being actively maintained and updated. + +If you see any parts that needs to be corrected, please open a Github issue [here](https://github.com/cs161-staff/textbook/issues). ## Source and Changelog diff --git a/network/dos.md b/network/dos.md index 46ac381..3435156 100644 --- a/network/dos.md +++ b/network/dos.md @@ -18,7 +18,7 @@ Application level DoS attacks tend to target the resources that an application u 1. Identification: You must be able to distinguish requests from different users and require some method to identify or authenticate them (though this process might be expensive and itself vulnerable to DoS attacks) 2. Isolation: You must ensure that one user’s actions do not affect another user’s experience -3. Quotas: You must ensure that users can only access a certain proportion of resources. Possible implementations of this are that you could limit each user to 4 GB of RAM and 2 CPU cores or you could ensure that only trusted users can execute expensive requests. Another possible “defense” could include proof-of-work (like a CAPTCHA) wherein you force users to spend some resources in order to issue a request. The idea here is that the DoS attack becomes more expensive for the attacker as they have to now spend extra resources in order to succeed. +3. Quotas: You must ensure that users can only access a certain proportion of resources. There are many possible implementations of this. One method to implement this is to place specific limits on each user such as limiting users to only 4 GB of RAM and 2 CPU cores. Another example of is to assign specific roles to users such that only trusted people can execute expensive requests. Another possible “defense” would include proof-of-work (like CAPTCHA) wherein you force users to spend some resources in order to issue a request. The idea here is that the DoS attack becomes more expensive for the attacker as they have to now spend extra resources in order to succeed. ## 34.3. SYN Flood Attacks @@ -34,6 +34,6 @@ Essentially, what is happening here is that the server does not create state unt ## 34.4. Distributed Denial of Service (DDoS) -Today, most standard DoS attacks are impractical to execute from a single machine. Modern server technology allows websites to handle an enormous amount of bandwidth, much greater than the bandwidth that is possible from a single machine. Despite this however, DoS conditions can still be created by using multiple attacking machines in what is known as a Distributed Denial of Service (DDoS) attack. Here, malicious user(s) leverage the power of many machines (the number of machines could be in the thousands) to direct traffic against a single website in an attempt to create DoS conditions (i.e. prevent availability). Often, attackers carry out DDoS attacks by using botnets, a series of large networks of machines that have been compromised and are controllable remotely. +Today, most standard DoS attacks are impractical to execute from a single machine. Modern server technology allows websites to handle an enormous amount of bandwidth, much greater than the bandwidth that is possible from a single machine. However, DoS conditions can still be created by using multiple attacking machines in what is known as a Distributed Denial of Service (DDoS) attack. Here, malicious user(s) leverage the power of many machines (the number of machines could be in the thousands) to direct traffic against a single website in an attempt to create DoS conditions (i.e. prevent availability). Often, attackers carry out DDoS attacks by using botnets, a series of large networks of machines that have been compromised and are controllable remotely. Theoretically, there is no way to completely eliminate the possibility of a DDoS attack since the bandwidth that a server is able to provide its users is always going to be limited. However, measures can still be taken to mitigate the risks of DDoS attacks. For example, several servers incorporate DDoS protection mechanisms that analyze incoming traffic and drop packets from sources that are consuming too much bandwidth. Unfortunately, IP spoofing makes this defense extremely difficult by obscuring the identity of the attacker bots and providing inconsistent information on where network traffic is coming from. diff --git a/network/transport.md b/network/transport.md index 1a3cc89..2f2f526 100644 --- a/network/transport.md +++ b/network/transport.md @@ -32,12 +32,7 @@ The transport layer has 2 main protocols to choose from: TCP guarantees reliable The UDP header contains 16-bit source and destination port numbers to support communication between processes. The header also contains a checksum (non-cryptographic) to detect corrupted packets. -TODO: This diagram can be better. ~NN - -| 16 bits | 16 bits | -| :---------: | :--------------: | -| Source port | Destination port | -| Length | Checksum | +![UDP header](/assets/images/network/transport/UDP.png) ## 30.4. Protocol: TCP @@ -45,32 +40,7 @@ TODO: This diagram can be better. ~NN Like UDP, the TCP header contains 16-bit source and destination port numbers to support communication between processes, and a checksum to detect corrupted packets. Additionally, a 32-bit **sequence number** and a 32-bit **acknowledgment (ACK) number** are used for keeping track of missing or out-of-order packets. Flags such as SYN, ACK, and FIN can be set in the header to indicate that the packet has some special meaning in the TCP protocol. -TODO: This diagram can be better. ~NN - - - - - - - - - - - - - - - - - - - - - - - - -
16 bits16 bits
Source portDestination port
Sequence number
Acknolwedgement number
FlagsChecksum
+![TCP Header](/assets/images/network/transport/TCP_header.png) A unique TCP connection is identified by a 5-tuple of (Client IP Address, Client Port, Server IP Address, Server Port, Protocol), where protocol is always TCP. In other words, a TCP connection is a sequence of back-and-forth communications between one port on one IP address, and another port on another IP address. @@ -110,7 +80,7 @@ Connections can also be unilaterally aborted. If one side sends a RST packet wit ## 30.5. Tradeoffs between TCP and UDP -TCP is slower than UDP, because it requires a 3-way handshake at the start of each connection, and it will wait indefinitely for dropped packets to resent. However, TCP provides better correctness guarantees than UDP. +TCP is slower than UDP, because it requires a 3-way handshake at the start of each connection, and it will wait indefinitely for dropped packets to be sent again. However, TCP provides better correctness guarantees than UDP. UDP is generally used when speed is a concern. For example, DNS requires extremely short response times, so it uses UDP instead of TCP at the transport layer. Video games and voice applications often use UDP because it is better to just miss a request than to stall everything waiting for a retransmission. diff --git a/web/intro.md b/web/intro.md index d970df1..1bd6804 100644 --- a/web/intro.md +++ b/web/intro.md @@ -12,13 +12,13 @@ Every resource (webpage, image, PDF, etc.) on the web is identified by a URL (Un

- httphttp://www.example.com/index.html

-The first mandatory part is the _protocol_, located before in the URL. In the example above, the protocol is http. The protocol tells your browser how to retrieve the resource. In this class, the only two protocols you need to know are HTTP, which we will cover in the next section, and HTTPS, which is a secure version of HTTP using TLS (refer to the networking unit for more details). Other protocols include `git+ssh://`, which fetches a git archive over an encrypted tunnel using `ssh`, or `ftp://`, which uses the old FTP (File Transfer Protocol) to fetch data. +The first mandatory part is the _protocol_, located before in the URL. In the example above, the protocol is http. The protocol tells your browser how to retrieve the resource. In this class, the only two protocols you need to know are HTTP, which we will cover in the next section, and HTTPS, which is a secure version of HTTP using TLS (refer to the networking unit for more details). Other protocols include `git+ssh://`, which fetches a git archive over an encrypted tunnel using `ssh`, or `ftp://`, which uses the old FTP (File Transfer Protocol) to fetch data. The second mandatory part is the _location_, located after but before the next forward slash in the URL. In the example above, the location is www.example.com. This tells your browser which web server to contact to retrieve the resource. @@ -38,17 +38,17 @@ In summary, a URL with all elements present may look like this:

- http://http://evanbot@www.cs161.orgwww.cs161.org:161/whoami/whoami?k1=v1&k2=v2#anchor + >#anchor

-where http is the protocol, evanbot is the username, www.cs161.org is the computer location (domain), 161 is the port, /whoami is the path, k1=v1&k2=v2 are the URL arguments, and anchor is the anchor. +where http is the protocol, evanbot is the username, www.cs161.org is the computer location (domain), 161 is the port, /whoami is the path, k1=v1&k2=v2 are the URL arguments, and anchor is the anchor. _Further reading:_ [What is a URL?](https://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_is_a_URL) diff --git a/web/sqli.md b/web/sqli.md index 064f205..01e6661 100644 --- a/web/sqli.md +++ b/web/sqli.md @@ -84,7 +84,7 @@ Writing a malicious input that creates a syntactically valid SQL query can be tr - `garbage` is a garbage input to the intended query so that it doesn't return anything. - `'` closes the opening quote from the intended query. Without this closing quote, the rest of our query would be treated as a string, not SQL code. - `;` ends the intended SQL query and lets us start a new SQL query. -- `SELECT password FROM passwords WHERE username = "admin` is the malicious SQL query we want to execute. Note that we didn't add a closing quote to `"admin`, because the intended SQL query will automatically add a closing quote at the end of our input. +- `SELECT password FROM passwords WHERE username = 'admin` is the malicious SQL query we want to execute. Note that we didn't add a closing quote to `'admin`, because the intended SQL query will automatically add a closing quote at the end of our input. Consider another vulnerable SQL query. This time, we have a `users` table that contains the `username` and `password` of every user.