Autosave: 2025-02-09 13:31:44

neuron/ac6779a0-333b-484d-8504-e6927d39c983/Certificate_authorities.md

@@ -0,0 +1,65 @@
+---
+tags: [networks, server-management]
+created: Sunday, February 09, 2025
+---
+
+# Certificates and certificate authorities
+
+> HTTPS is a secure tunnel for data transmission, but the certificate is what
+> establishes trust and enables the secure tunnel in the first place.
+
+Before secure communication over HTTPS can commence between a client and a
+server, the client must confirm that the server is who it says it is. This is in
+order to prevent man-in-the-middle attacks where malicious actors attempt to
+impersonate legitimate websites.
+
+Certificates exist to authenticate domains, prior to the exchange of encrypted
+data. To do this, a server generates a certificate with a reputable Certificate
+Authority, thereby verifying its identity with the CA. It sends this certificate
+(which includes its [public key](bbdcb54f_public_key_cryptography.md)) when
+initiating a connection with a client.
+
+In addition to the public key, the certificate provides:
+
+- the domain name
+- the CA that certified the domain
+- the period of validity
+- a digital signature from the CA
+
+The client uses this data to validate the identity of the server it has sent a
+request to. Browsers come pre-installed with a list of trusted CAs.
+
+Certificates are called TLS/SSL certificates but the main protocol is TLS rather
+than SSL.
+
+Indications that a server is not to be trusted include:
+
+- expired certificates
+- certificates issued for the wrong domain
+- self-signed certificates not issued by a trusted CA
+
+## Certification process
+
+Standard domain-validated authentication proceeds as follows:
+
+1. Server generates public/private key pair
+2. Server creates a certificate signing request containing its public key and
+   domain name
+3. CA validates the domain and signs the certificate with its private key
+4. Server discloses its public key and CA signature
+5. Client knows CAs public key and uses this to verify the signature
+6. Server's public key is then trusted
+
+### How validation executes between CA and server
+
+To validate the domain (step 3 above), the CA gives the server a "challenge" to
+prove they control the domain. This can include:
+
+- Putting a specific token as a DNS TXT record (DNS validation)
+- Putting a file at a certain URL (HTTP validation)
+- Email validation: sending an email to standard admin address for the server.
+  Server owner clicks the link.
+
+### Related
+
+See [Let's Encrypt](Let's_Encrypt.md)

neuron/ac6779a0-333b-484d-8504-e6927d39c983/Firewalls.md

@@ -0,0 +1,44 @@
+---
+tags: [networks, server-management]
+created: Sunday, February 09, 2025
+---
+
+# Firewalls
+
+A firewall is a server mechanism that filters incoming requests for resources
+and services that it hosts.
+
+Based on data about the requester, derived from the
+[TLS](Transport_Layer_of_Internet_Protocol.md) packet headers, the firewall
+decides whether or not to grant access to the requested resource.
+
+It will typically comprise three actions:
+
+- accept
+- drop
+- reject
+
+Accept is obvious. To "drop" means to block the traffic without sending a reply.
+To "reject" is to block the traffic but reply with an "unreachable" error.
+
+An example of a firewall rule would be to drop incoming traffic from IP
+addresses of non-technical employees to the SSH port (22) but allow technical
+staff to access it.
+
+Network traffic is matched agains a list of firewall rules in a sequence from
+first to last. As you cannot cover all cases, you must specify a default action
+when a rule is not matched.
+
+Whilst firewalls are focused on incoming traffic, you can also apply rules to
+outgoing traffic. A server will permit most outgoing traffic since, after all,
+it can trust itself however you may want to stop the server connecting to known
+malicious actors.
+
+## Related software
+
+IPTables is the standard Linux software for managing firewalls. There is also
+Uncomplicated Firewall (UWF) which attaches to IPTables and simplifies the
+process.
+
+Another usefule software is Fail2ban which can automatically configure your
+firewall to block brute force login attempts and DDOS attacks.

neuron/ac6779a0-333b-484d-8504-e6927d39c983/HTTPS.md

@@ -1,5 +1,5 @@
 ---
-tags: [world-wide-web, internet, encryption]
+tags: [world-wide-web, internet, encryption, server-management]
 created: Friday, December 14, 2024
 ---
 
@@ -17,9 +17,10 @@ It utilises two types of encryption to send messages securely:
   - a single shared key between client and server to encrypt the messages sent
     between them
 - asymmetric encryption
-  - two keys are used: a public key to encrypt the data and a private key to
-    decrypt it. The public key can be shared freely so anyone can encrypt and
-    send data to a peer but only the peer can receive and decrypt it
+  - two keys are used: a [public key](bbdcb54f_public_key_cryptography.md) to
+    encrypt the data and a private key to decrypt it. The public key can be
+    shared freely so anyone can encrypt and send data to a peer but only the
+    peer can receive and decrypt it
 
 The encryption protocol used is TLS - the **Transport Layer Security Protocol**.
 Previously SSL (Secure Sockets Layer) was used but has been deprecated over
@@ -29,12 +30,12 @@ security concerns.
 
 - An initial handshake is shared between client and server, agreeing that
   communication will be encrypted. This is public. "Client hello" and "Server
-  hello". Some random numbers are exchanged at this point.
-- The server sends a digital certificate to the client along with its public
-  key. The client checks that the certificate is valid.
+  hello". Some random numbers are exchanged at this point
+- The server sends a digital [certificate](Certificate_authorities.md') key
+  The client checks that the certificate is valid
 - If valid, the client encrypts a string of bytes using the public key and sends
-  it to the server. This is called the "premaster secret".
-- This is decrypted by the server.
+  it to the server. This is called the "premaster secret"
+- This is decrypted by the server
 - The premaster secret, along with the random bytes from the handshake is then
   used to compute a shared secret key (symmetric) which is used to encrypt all
-  subsequent messages for the duration of the session.
+  subsequent messages for the duration of the session

neuron/ac6779a0-333b-484d-8504-e6927d39c983/Let's_Encrypt.md

@@ -0,0 +1,6 @@
+---
+tags: []
+created: Sunday, February 09, 2025
+---
+
+# Let's_Encrypt

neuron/ac6779a0-333b-484d-8504-e6927d39c983/index.md

@@ -13,12 +13,17 @@ computer science.
 
 <a href="https://thomasabishop.github.io/eolas/tags">View tags</a>
  
-**Build ID:** 3b3f3885-a969-4331-8766-b386e8dbd527
+**Build ID:** ac6779a0-333b-484d-8504-e6927d39c983
 
-**Published:** Mon 03 Feb 2025 12:48:43
+**Published:** Sun 09 Feb 2025 13:31:39
 
 ### Recent edits 
 
+- [[Certificate_authorities]] 
+- [[Let's_Encrypt]] 
+- [[Firewalls]] 
+- [[HTTPS]] 
+- [[Bash_colour_output]] 
 - [[e383b8b3_nginx_vs_traefik]] 
 - [[Proxies]] 
 - [[LineageOS_backup]] 
@@ -26,14 +31,9 @@ computer science.
 - [[c9d7492f_requerimiento]] 
 - [[Compile_Python_app_to_single_executable]] 
 - [[Sorting_lists_in_Python]] 
-- [[Algebra_key_terms]] 
-- [[Python_package_management]] 
-- [[Ping]] 
-- [[Monitor_DNS_resolution_and_internet_connectivity_script]] 
-- [[ICMP_Protocol]] 
 
 
-### All notes (523) 
+### All notes (526) 
 
 - [[0716531c_rewilding_the_internet]] 
 - [[241fe1a3_the_Web_versus_modem_BBSs]] 
@@ -113,6 +113,7 @@ computer science.
 - [[Capturing_user_input_in_Bash]] 
 - [[Case_statements_in_Bash]] 
 - [[Cells_and_batteries]] 
+- [[Certificate_authorities]] 
 - [[Cherry_picking]] 
 - [[Child_to_parent_data_flow_in_React]] 
 - [[Chipset_and_controllers]] 
@@ -214,6 +215,7 @@ computer science.
 - [[File_system_error_handling_in_Python]] 
 - [[Filesystems]] 
 - [[Find_Bash_command]] 
+- [[Firewalls]] 
 - [[Flip_flops]] 
 - [[Foreign_keys_in_SQL]] 
 - [[Formal_conventions]] 
@@ -281,6 +283,7 @@ computer science.
 - [[Latches]] 
 - [[Law_of_Non_Contradiction]] 
 - [[Law_of_the_Excluded_Middle]] 
+- [[Let's_Encrypt]] 
 - [[Lifecycle_methods]] 
 - [[LineageOS_backup]] 
 - [[Link_Layer_of_Internet_Protocol]] 

neuron/ac6779a0-333b-484d-8504-e6927d39c983/tags.md

@@ -4,7 +4,7 @@ unlisted: true
 ---
 
 # Tags
-[algebra](./tags#algebra), [algorithms](./tags#algorithms), [analogue](./tags#analogue), [android](./tags#android), [APIs](./tags#APIs), [arch-linux](./tags#arch-linux), [arithmetic](./tags#arithmetic), [ARPA](./tags#ARPA), [ARPANET](./tags#ARPANET), [awk](./tags#awk), [AWS](./tags#AWS), [aws-lambda](./tags#aws-lambda), [binary](./tags#binary), [bulletin-boards](./tags#bulletin-boards), [bus](./tags#bus), [C](./tags#C), [computer-architecture](./tags#computer-architecture), [computer-history](./tags#computer-history), [containerization](./tags#containerization), [CPU](./tags#CPU), [cryptography](./tags#cryptography), [csv](./tags#csv), [data-structures](./tags#data-structures), [data-types](./tags#data-types), [databases](./tags#databases), [design-patterns](./tags#design-patterns), [disks](./tags#disks), [docker](./tags#docker), [dynamodb](./tags#dynamodb), [ecopolsoc](./tags#ecopolsoc), [electricity](./tags#electricity), [electromagnetism](./tags#electromagnetism), [electronics](./tags#electronics), [encryption](./tags#encryption), [exponents](./tags#exponents), [file-system](./tags#file-system), [fleeting](./tags#fleeting), [fractions](./tags#fractions), [git](./tags#git), [graphql](./tags#graphql), [hardware](./tags#hardware), [IaC](./tags#IaC), [internet](./tags#internet), [javascript](./tags#javascript), [jest](./tags#jest), [json](./tags#json), [JSON](./tags#JSON), [kernel](./tags#kernel), [Linux](./tags#Linux), [linux](./tags#linux), [literature](./tags#literature), [logic](./tags#logic), [logic-gates](./tags#logic-gates), [memory](./tags#memory), [Microsoft](./tags#Microsoft), [middleware](./tags#middleware), [modems](./tags#modems), [mongo-db](./tags#mongo-db), [mongoose](./tags#mongoose), [nand-to-tetris](./tags#nand-to-tetris), [network-protocols](./tags#network-protocols), [networks](./tags#networks), [node-js](./tags#node-js), [number-systems](./tags#number-systems), [number-theory](./tags#number-theory), [OOP](./tags#OOP), [operating-systems](./tags#operating-systems), [packet-switching](./tags#packet-switching), [physics](./tags#physics), [ports](./tags#ports), [prealgebra](./tags#prealgebra), [privacy](./tags#privacy), [procedural](./tags#procedural), [propositional-logic](./tags#propositional-logic), [proxies](./tags#proxies), [python](./tags#python), [question](./tags#question), [raspberry-pi](./tags#raspberry-pi), [react](./tags#react), [recursion](./tags#recursion), [regex](./tags#regex), [REST](./tags#REST), [S3](./tags#S3), [set-theory](./tags#set-theory), [shell](./tags#shell), [SNS](./tags#SNS), [sound](./tags#sound), [SQL](./tags#SQL), [SQLite](./tags#SQLite), [SQS](./tags#SQS), [storage](./tags#storage), [surveillance-capitalism](./tags#surveillance-capitalism), [systemd](./tags#systemd), [systems-programming](./tags#systems-programming), [testing](./tags#testing), [theorems](./tags#theorems), [theory-of-computation](./tags#theory-of-computation), [time](./tags#time), [TOR](./tags#TOR), [Turing](./tags#Turing), [typescript](./tags#typescript), [unix](./tags#unix), [world-wide-web](./tags#world-wide-web), [yaml](./tags#yaml), 
+[algebra](./tags#algebra), [algorithms](./tags#algorithms), [analogue](./tags#analogue), [android](./tags#android), [APIs](./tags#APIs), [arch-linux](./tags#arch-linux), [arithmetic](./tags#arithmetic), [ARPA](./tags#ARPA), [ARPANET](./tags#ARPANET), [awk](./tags#awk), [AWS](./tags#AWS), [aws-lambda](./tags#aws-lambda), [binary](./tags#binary), [bulletin-boards](./tags#bulletin-boards), [bus](./tags#bus), [C](./tags#C), [computer-architecture](./tags#computer-architecture), [computer-history](./tags#computer-history), [containerization](./tags#containerization), [CPU](./tags#CPU), [cryptography](./tags#cryptography), [csv](./tags#csv), [data-structures](./tags#data-structures), [data-types](./tags#data-types), [databases](./tags#databases), [design-patterns](./tags#design-patterns), [disks](./tags#disks), [docker](./tags#docker), [dynamodb](./tags#dynamodb), [ecopolsoc](./tags#ecopolsoc), [electricity](./tags#electricity), [electromagnetism](./tags#electromagnetism), [electronics](./tags#electronics), [encryption](./tags#encryption), [exponents](./tags#exponents), [file-system](./tags#file-system), [fleeting](./tags#fleeting), [fractions](./tags#fractions), [git](./tags#git), [graphql](./tags#graphql), [hardware](./tags#hardware), [IaC](./tags#IaC), [internet](./tags#internet), [javascript](./tags#javascript), [jest](./tags#jest), [json](./tags#json), [JSON](./tags#JSON), [kernel](./tags#kernel), [Linux](./tags#Linux), [linux](./tags#linux), [literature](./tags#literature), [logic](./tags#logic), [logic-gates](./tags#logic-gates), [memory](./tags#memory), [Microsoft](./tags#Microsoft), [middleware](./tags#middleware), [modems](./tags#modems), [mongo-db](./tags#mongo-db), [mongoose](./tags#mongoose), [nand-to-tetris](./tags#nand-to-tetris), [network-protocols](./tags#network-protocols), [networks](./tags#networks), [node-js](./tags#node-js), [number-systems](./tags#number-systems), [number-theory](./tags#number-theory), [OOP](./tags#OOP), [operating-systems](./tags#operating-systems), [packet-switching](./tags#packet-switching), [physics](./tags#physics), [ports](./tags#ports), [prealgebra](./tags#prealgebra), [privacy](./tags#privacy), [procedural](./tags#procedural), [propositional-logic](./tags#propositional-logic), [proxies](./tags#proxies), [python](./tags#python), [question](./tags#question), [raspberry-pi](./tags#raspberry-pi), [react](./tags#react), [recursion](./tags#recursion), [regex](./tags#regex), [REST](./tags#REST), [S3](./tags#S3), [server-management](./tags#server-management), [set-theory](./tags#set-theory), [shell](./tags#shell), [SNS](./tags#SNS), [sound](./tags#sound), [SQL](./tags#SQL), [SQLite](./tags#SQLite), [SQS](./tags#SQS), [storage](./tags#storage), [surveillance-capitalism](./tags#surveillance-capitalism), [systemd](./tags#systemd), [systems-programming](./tags#systems-programming), [testing](./tags#testing), [theorems](./tags#theorems), [theory-of-computation](./tags#theory-of-computation), [time](./tags#time), [TOR](./tags#TOR), [Turing](./tags#Turing), [typescript](./tags#typescript), [unix](./tags#unix), [world-wide-web](./tags#world-wide-web), [yaml](./tags#yaml), 
 
 ### algebra 
 
@@ -668,10 +668,12 @@ unlisted: true
 - [[Application_Layer_of_Internet_Protocol]] 
 - [[Bluetooth]] 
 - [[c8173d17_TIMPs]] 
+- [[Certificate_authorities]] 
 - [[e383b8b3_nginx_vs_traefik]] 
 - [[e470bf3d_IMPs_in_the_ARPANET]] 
 - [[Example_scenario_internet_data_transfer]] 
 - [[f0f70a3c_ARPANET_motivations]] 
+- [[Firewalls]] 
 - [[Headless_Raspi_network_setup]] 
 - [[ICMP_Protocol]] 
 - [[Internet_fundamentals]] 
@@ -1003,6 +1005,11 @@ unlisted: true
 ### S3 
 
 - [[Bash_store_status_of_command_execution]] 
+### server-management 
+
+- [[Certificate_authorities]] 
+- [[Firewalls]] 
+- [[HTTPS]] 
 ### set-theory 
 
 - [[Axioms_of_set_theory]] 

zk/Certificate_authorities.md

@@ -0,0 +1,65 @@
+---
+tags: [networks, server-management]
+created: Sunday, February 09, 2025
+---
+
+# Certificates and certificate authorities
+
+> HTTPS is a secure tunnel for data transmission, but the certificate is what
+> establishes trust and enables the secure tunnel in the first place.
+
+Before secure communication over HTTPS can commence between a client and a
+server, the client must confirm that the server is who it says it is. This is in
+order to prevent man-in-the-middle attacks where malicious actors attempt to
+impersonate legitimate websites.
+
+Certificates exist to authenticate domains, prior to the exchange of encrypted
+data. To do this, a server generates a certificate with a reputable Certificate
+Authority, thereby verifying its identity with the CA. It sends this certificate
+(which includes its [public key](./bbdcb54f_public_key_cryptography.md)) when
+initiating a connection with a client.
+
+In addition to the public key, the certificate provides:
+
+- the domain name
+- the CA that certified the domain
+- the period of validity
+- a digital signature from the CA
+
+The client uses this data to validate the identity of the server it has sent a
+request to. Browsers come pre-installed with a list of trusted CAs.
+
+Certificates are called TLS/SSL certificates but the main protocol is TLS rather
+than SSL.
+
+Indications that a server is not to be trusted include:
+
+- expired certificates
+- certificates issued for the wrong domain
+- self-signed certificates not issued by a trusted CA
+
+## Certification process
+
+Standard domain-validated authentication proceeds as follows:
+
+1. Server generates public/private key pair
+2. Server creates a certificate signing request containing its public key and
+   domain name
+3. CA validates the domain and signs the certificate with its private key
+4. Server discloses its public key and CA signature
+5. Client knows CAs public key and uses this to verify the signature
+6. Server's public key is then trusted
+
+### How validation executes between CA and server
+
+To validate the domain (step 3 above), the CA gives the server a "challenge" to
+prove they control the domain. This can include:
+
+- Putting a specific token as a DNS TXT record (DNS validation)
+- Putting a file at a certain URL (HTTP validation)
+- Email validation: sending an email to standard admin address for the server.
+  Server owner clicks the link.
+
+### Related
+
+See [Let's Encrypt](./Let's_Encrypt.md)

zk/Firewalls.md

@@ -0,0 +1,44 @@
+---
+tags: [networks, server-management]
+created: Sunday, February 09, 2025
+---
+
+# Firewalls
+
+A firewall is a server mechanism that filters incoming requests for resources
+and services that it hosts.
+
+Based on data about the requester, derived from the
+[TLS](/zk/Transport_Layer_of_Internet_Protocol.md) packet headers, the firewall
+decides whether or not to grant access to the requested resource.
+
+It will typically comprise three actions:
+
+- accept
+- drop
+- reject
+
+Accept is obvious. To "drop" means to block the traffic without sending a reply.
+To "reject" is to block the traffic but reply with an "unreachable" error.
+
+An example of a firewall rule would be to drop incoming traffic from IP
+addresses of non-technical employees to the SSH port (22) but allow technical
+staff to access it.
+
+Network traffic is matched agains a list of firewall rules in a sequence from
+first to last. As you cannot cover all cases, you must specify a default action
+when a rule is not matched.
+
+Whilst firewalls are focused on incoming traffic, you can also apply rules to
+outgoing traffic. A server will permit most outgoing traffic since, after all,
+it can trust itself however you may want to stop the server connecting to known
+malicious actors.
+
+## Related software
+
+IPTables is the standard Linux software for managing firewalls. There is also
+Uncomplicated Firewall (UWF) which attaches to IPTables and simplifies the
+process.
+
+Another usefule software is Fail2ban which can automatically configure your
+firewall to block brute force login attempts and DDOS attacks.

zk/HTTPS.md

@@ -1,5 +1,5 @@
 ---
-tags: [world-wide-web, internet, encryption]
+tags: [world-wide-web, internet, encryption, server-management]
 created: Friday, December 14, 2024
 ---
 
@@ -17,9 +17,10 @@ It utilises two types of encryption to send messages securely:
   - a single shared key between client and server to encrypt the messages sent
     between them
 - asymmetric encryption
-  - two keys are used: a public key to encrypt the data and a private key to
-    decrypt it. The public key can be shared freely so anyone can encrypt and
-    send data to a peer but only the peer can receive and decrypt it
+  - two keys are used: a [public key](./bbdcb54f_public_key_cryptography.md) to
+    encrypt the data and a private key to decrypt it. The public key can be
+    shared freely so anyone can encrypt and send data to a peer but only the
+    peer can receive and decrypt it
 
 The encryption protocol used is TLS - the **Transport Layer Security Protocol**.
 Previously SSL (Secure Sockets Layer) was used but has been deprecated over
@@ -29,12 +30,12 @@ security concerns.
 
 - An initial handshake is shared between client and server, agreeing that
   communication will be encrypted. This is public. "Client hello" and "Server
-  hello". Some random numbers are exchanged at this point.
-- The server sends a digital certificate to the client along with its public
-  key. The client checks that the certificate is valid.
+  hello". Some random numbers are exchanged at this point
+- The server sends a digital [certificate](./Certificate_authorities.md') key
+  The client checks that the certificate is valid
 - If valid, the client encrypts a string of bytes using the public key and sends
-  it to the server. This is called the "premaster secret".
-- This is decrypted by the server.
+  it to the server. This is called the "premaster secret"
+- This is decrypted by the server
 - The premaster secret, along with the random bytes from the handshake is then
   used to compute a shared secret key (symmetric) which is used to encrypt all
-  subsequent messages for the duration of the session.
+  subsequent messages for the duration of the session

zk/Let's_Encrypt.md

@@ -0,0 +1,6 @@
+---
+tags: []
+created: Sunday, February 09, 2025
+---
+
+# Let's_Encrypt