It started as a typical Wednesday.

I was deep in the usual routine when the news hit. In just six days, I would be traveling to one of the most technologically advanced countries in the world.

The destination was Shanghai, specifically the Lianqiu Lake R&D Center, to attend Huawei’s Pacific Plan Partner Training.

A Campus Built at City Scale

I spent three days at the newly opened Lianqiu Lake R&D Center. This is not a conventional corporate site. It is a purpose built research environment operating at city scale.

Spanning approximately 2,600 acres, it exceeds the size of Apple’s and Microsoft’s primary campuses combined. Yet despite its scale, it never felt overwhelming. One of the coolest parts is a vintage-style red tram system that connects the different parts.

Training Depth and Perspective

The Pacific Plan training brought together partners from diverse regions and technical backgrounds. The sessions were structured to focus less on configurations and more on architectural intent, trade-offs and system-level implications.

Questions were explored through reasoning rather than product features. This approach exposed gaps in my own understanding and provided a clearer sense of what I need to strengthen next.

Three Days of Deep Technical Focus

The three days followed a clear structure, each building on a different layer of the stack.

The first day focused mainly on DCS and full stack solutions, setting the foundation for how infrastructure components come together as complete systems rather than isolated products. The emphasis was on understanding how these pieces fit and how they shape broader architectures.

The second day went deeper into data centric workloads. This included AI data lake solutions, data protection products and architectures, OceanStor Dorado all flash storage platforms, along with discussions around OLTP databases and Kunpeng computing. Instead of treating these topics separately, the sessions showed how performance, protection, and compute decisions tend to overlap in real environments.

The final day shifted toward commercial and distribution market products and solutions, helping connect the earlier technical discussions to practical deployment and market realities.

Across the three days, the focus gradually moved away from individual technologies and toward understanding why systems are designed the way they are, with technical choices tied back to constraints, use cases, and long term impact.

Learning Beyond the Room

Some of the most valuable learning came from simply hearing about real projects being rolled out across different continents. Partners shared firsthand experiences from deployments in very different markets, each with its own constraints, scale, and regulatory realities.

Those conversations added practical context to the theory and sparked ideas for approaches I could realistically adapt and apply in my own environment.

Embracing My Inner Po

Not everything on campus was purely technical. After the day wrapped up, we spent an hour learning Kung Fu.

Between that and the impressive range of campus food options, it was hard not to lean into my inner Po.

An Unexpected Perspective

Visiting Shanghai was not something I had planned or put on my bucket list this year, but I am grateful for the experience.

It offered more than technical exposure. It provided distance from routine, space to reflect, and a clearer view of where my thinking needs to mature. Sometimes you have to go halfway across the world and practice some Kung Fu to realize exactly where you need to grow.

A while back, I set up Ghost CMS on my Linux server to power my blog. After getting the site running smoothly, I realized I needed a reliable analytics tool to track visitors and see how my content was performing. But I wasn’t looking for just any tool—I wanted something simple, privacy-focused and easy to integrate with my setup. That’s when I discovered Plausible Analytics.

Why I Chose Plausible for Tracking

Running a website means understanding what’s working and what isn’t but I wasn’t willing to compromise my visitors' privacy to get those insights. Most traditional analytics tools rely on cookies, complex data mining and extensive user tracking, which didn’t align with what I was comfortable with.

When I started looking into alternatives, I wanted something that prioritized privacy and was easy to use—without the clutter of unnecessary data. Plausible stood out to me for a few key reasons:

• Privacy-Focused: The biggest selling point was Plausible’s no-cookie approach. It doesn’t use invasive tracking or collect personal data, which means it complies with privacy laws like GDPR, CCPA and PECR. I could gather the insights I needed while respecting my audience’s privacy.
• Open Source: Since Plausible is open source, I had the option to self-host it which gave me complete control over my data. No need to hand it over to a big corporation that might store or sell it for their own purposes. It’s reassuring to know that my data stays with me, on my own server.
• Simplicity: Many analytics tools overwhelm you with data you don’t need, but Plausible has an incredibly clean, intuitive interface. It highlights key metrics like unique visitors, page views and bounce rates, making it easy to see what matters without getting lost in a sea of charts and filters.

For a detailed comparison between Plausible and Google Analytics, you can check out their official website.

Setting It Up

Setting up Plausible on my server was very straightforward. After installing Docker and cloning the Plausible Community Edition repository, I followed the instructions on GitHub and had it running in no time. The tracking script was simple to add to Ghost CMS—just a matter of pasting it into the header section. I also pointed my DNS to the Plausible server and everything worked flawlessly.

Using Plausible Analytics

Once Plausible was integrated, I started exploring the dashboard and honestly I was impressed. Even though the interface is minimal, it still delivers the core metrics that matter:

• Unique visitors: See how many people are visiting your site.
• Page views: Track the number of times pages are loaded.
• Bounce rates: Understand how many people leave your site after viewing just one page.

These insights have helped me better understand what content is engaging my readers and which posts are driving the most traffic. The best part is how easy it is to navigate—no unnecessary clutter or overly technical reports, just the data I care about.

A Quick Shoutout to Fathom

While exploring options, I also came across Fathom Analytics. Like Plausible, Fathom emphasizes privacy and simplicity.

My Takeaway

Overall, my experience with Plausible has been really positive. It helps me focus on the metrics that matter without the noise and it’s comforting to know that I’m respecting my visitors’ privacy while gaining valuable insights.

If you’re looking for an analytics tool that prioritizes privacy and simplicity, I highly recommend checking out Plausible. It could be just what you need for your website. It’s especially ideal for those who want a lightweight, ethical approach to web tracking.

On September 9th, 2024, Cyberstorm.mu had the privilege of attending a closed meeting at Labourdonnais Waterfront Hotel, where ICANN (Internet Corporation for Assigned Names and Numbers) presented the roadmap for their upcoming Next Round of New Generic Top-Level Domains (ngTLDs) and the Applicant Support Program. Mauritius is the first country to host an in-person discussion about the next round of new gTLDs, set to open in April 2026. Previous discussions were held online, with more face-to-face sessions planned in other countries.

ICANN and Its Role

For those unfamiliar, ICANN plays a crucial role in managing the DNS, which is essential to how the Internet functions. They ensure that domain names, IP addresses and top-level domains (TLDs) work together securely and efficiently. Without ICANN’s oversight, the Internet as we know it wouldn’t function as smoothly. Any changes or expansions they propose can directly shape the future of the online world, especially in underserved regions like Africa.

The Focus on Africa: Opportunities and Challenges

One of the key points raised was Africa's underwhelming participation in the last round of gTLD applications back in 2012. Out of 1930 applications globally, only 17 came from Africa, most of which were from South Africa. This imbalance was flagged as a serious issue. ICANN officials, including Pierre Dandjinou, Vice President of Stakeholder Engagement for the Africa region, emphasized the importance of empowering African nations to transition from being mere consumers of the Internet to becoming producers, capable of shaping the future of their digital economies and improving global representation.

Understanding the Top-Level Domains (TLDs)

ICANN's Senior Director of ngTLD Program, Bob Ochieng, provided an overview of the different categories of domain names:

• ccTLDs (Country-Code Top-Level Domains): These are two-letter domains like .mu for Mauritius or .ke for Kenya.
• gTLDs (Generic Top-Level Domains): Domains such as .com, .org or .info fall under this category. In the last round of applications, the number of gTLDs grew from 22 to over 1200.
• IDNs (Internationalized Domain Names): These can be either ccTLDs or gTLDs and use non-Latin scripts, allowing domain names to be written in languages like Arabic, Chinese and Japanese. For example, правительство.рф translates to government.ru.

Bob highlighted some challenges with new gTLDs. Domains like .africa or .capetown, while relevant, might face technical issues. For instance, longer domain names sometimes face issues in email deliverability, where emails can get dropped along the way.

Applying for a gTLD

Applying for a gTLD means taking on the responsibility of operating a domain registry, which involves significant technical and operational tasks. If you don’t have the technical capabilities to operate a gTLD registry, you can partner with an accredited Registry Service Provider (RSP) for a fee. RSPs offer the necessary infrastructure and expertise to manage the technical and operational aspects of running a gTLD.

Even if you have the technical capacity to manage a gTLD, you need to be accredited by ICANN to ensure that you meet the same high standards as all other operators. This accreditation process is crucial for maintaining uniformity and reliability across the global domain name system.

Managing a gTLD is a significant responsibility with substantial costs. For example, if a ccTLD like .mu goes down, it affects all users relying on that domain, from businesses to individuals. The same risk applies to gTLDs, making the role of a registry operator crucial and costly. This example underscores the high stakes involved in operating a TLD. This makes the domain system essential not just for personal or business use but for the national economy.

Why Should This Matter?

While .com is the dominant domain in North America, ccTLDs are more prevalent in other regions like Europe, Asia and Africa. In Africa, the market has grown to 7 million domain names in 2022. Compare that to around 20 million in China and you see the vast opportunity Africa has to improve.

Encouraging more African countries to participate in gTLDs is about more than just building Internet infrastructure—it’s about generating new revenue streams, asserting control over local digital policies and enhancing credibility in the global digital space. As Bob highlighted, gTLDs offer developing nations the potential to elevate their digital sovereignty and create monetization opportunities.

The Applicant Support Program – Making gTLDs Accessible

One of the standout issues from the 2012 round was the high cost of applying for a gTLD, with application fees set at $185,000 (Note that the application fees for the next round of new gTLDs is expected to be to be around $220,000). This posed a significant barrier for many organizations, especially in developing economies. To address this, the Applicant Support Program was enhanced to make applying for a gTLD more accessible to nonprofits, indigenous organizations, micro and small businesses and others who need financial assistance. Here’s how it works:

• Eligibility Criteria: Applicants need to meet certain criteria, including financial need and viability.
• Commitment Fee: The $1,500 commitment fee helps ensure that applicants are serious about their application.
• Successful applicants under the program receive an 85% reduction in the application fee.

The program offers financial support making the process more accessible to smaller players.

What Happens Next?

Looking forward, there are some key dates to keep in mind:

• November 19, 2024 – November 19, 2025: The application window for the Applicant Support Program will be open. You can apply to receive support without disclosing the specific domain name you’re applying for, maintaining confidentiality.
• May 2025: The Applicant Guidebook will be released, outlining the rules and requirements.
• April 2026: General applications for gTLDs will be accepted.

This new round of gTLDs will open up the possibility for more inclusive domain names, providing opportunities for groups to create their own space online.

More information can be found at https://newgtldprogram.icann.org/en.

Final Thoughts

ICANN's focus on global diversity and support for underserved regions is crucial for making the Internet more inclusive and representative.

For Mauritius and Africa, this initiative transcends domain names—it represents digital sovereignty and the chance to create opportunities for local communities. We are not just passive users of the Internet but have the potential to be active contributors to the global digital economy.

Let’s seize this opportunity to drive forward a more diverse, inclusive and locally-driven Internet landscape.

Recently, Cyberstorm.mu hosted a social event, featuring none other than Peter Schwabe, Scientific Director at the Max Planck Institute for Security and Privacy (MPI-SP) and part-time professor at Radboud University. He was joined by his partner Veelasha Moonsamy who is also active in research. As a co-author of the post-quantum cryptographic scheme CRYSTALS-Kyber, which has been selected for standardization by NIST, Peter's visit was a unique opportunity for our local community to engage with a renowned expert in the field.

A Relaxed Evening with a Cryptography Expert

The event took place in the welcoming setting of Happy Rajah in Grand Baie, providing an ideal atmosphere for engaging discussions. Over a delightful dinner, Peter Schwabe shared his experiences and insights into the world of post-quantum cryptography.

Discussions on Cryptography

In our conversations, Peter highlighted the importance of using specialized languages like Jasmin for cryptographic implementations. Unlike more popular languages such as C, Go or Rust, Jasmin provides a higher level of assurance in security through formal verification, which is essential for preventing vulnerabilities in cryptographic code.

We also touched on the Formosa project which focuses on creating high-assurance cryptographic software.

For more detailed insights on these topics, you can refer to Peter Schwabe's presentation slides from the 2023 CHES conference, available here.

Addressing Skepticism about Post Quantum Cryptography

In response to skeptics who question the need for post-quantum algorithms based on doubts about whether quantum computers will ever become a reality, Peter made it clear that these concerns are irrelevant. The fact is, standardization bodies are already advancing post-quantum algorithms regardless of whether quantum computers become a reality. The momentum in this field is undeniable and is driven by concrete actions.

Moreover, IBM has met all the milestones outlined in its quantum roadmap thus far, underscoring the tangible progress in the field. The urgency and necessity of developing robust post-quantum cryptographic solutions are clear and these advancements are happening now.

Pioneering Future Research in Mauritius

Cyberstorm.mu is committed to fostering collaboration and creating opportunities within the local community. As part of this mission, we invited Anwar Chutoo, a lecturer from the University of Mauritius, to join our event. This initiative aims to support local educational institutions by enhancing their engagement with international cryptography experts, cultivating local talent and strengthening Mauritius's role in post-quantum cryptography research.

Future Directions

Following our discussions, Peter and Veelasha proposed several initiatives to advance the field in Mauritius. Additionally, plans are underway for Peter to give a talk at the University of Mauritius in the coming weeks, further strengthening the connection between the local academic community and global cryptography research.

Addressing Broader Challenges

The event also included a discussion with Veelasha about the gender gap and challenges faced by researchers in computer science. These important topics highlighted the need for greater inclusivity and support for diverse talent in the field.

Looking Forward

The conversation with Peter Schwabe has left us with much to think about as we navigate the evolving landscape of cryptographic security. It was a reminder of the importance of staying informed and engaged with the latest advancements in the field.

Kudos to Cyberstorm.mu for organizing this insightful and engaging evening. We look forward to more opportunities to connect with leading experts and continue our journey into the world of technology and security.

We all know how important it is to protect our data, whether it's for personal projects, business documents or, in this example, your blog. Imagine losing all that precious content due to a server failure, hacking attempt or an accidental deletion. Yikes! That's why having a solid backup strategy is a must. In this guide, I’ll show you how to set up end-to-end encrypted backups using rclone. Let’s dive in and keep your data safe and sound!

Objectives

By the end of this guide, you’ll be able to:

• Understand the importance of backing up your data.
• Install and configure Rclone for encrypted backups.
• Enable API access and create OAuth credentials for your cloud storage provider (Google Drive).
• Automate the backup process with a script and cron jobs.
• Implement a retention policy to manage storage effectively.
• Verify and monitor your backups regularly.

1. Choose Your Backup Solution

First things first, let’s pick a reliable backup tool. Rclone is fantastic because it supports various cloud storage providers like Google Drive, Dropbox, OneDrive and more. Plus it offers top-notch encryption to keep your data secure whether it’s on the move or sitting in the cloud.

2. Installing Rclone

Time to get Rclone up and running. Download it from the official website or use package managers like apt for Linux or brew for macOS.

sudo -v ; curl https://rclone.org/install.sh | sudo bash

Verify the installation to make sure it’s all set:

rclone --version

3. Enable API Access

Next, we need to enable API access for your cloud storage provider. We’ll use Google Drive as an example but feel free to adapt this for your preferred service.

Enable Google Drive API

1. Head over to the Google Cloud Console.
2. Create a new project or select an existing one.
3. Navigate to APIs & Services > Library.
4. Search for "Google Drive API" and enable it.

4. Create OAuth Credentials

To securely access Google Drive (or another service), you need to create OAuth credentials. Don’t worry, it’s not as tricky as it sounds!

OAuth 2.0 is the de facto industry standard for online authorization, enabling applications like social media integrations (e.g., allowing a third-party app to post on your behalf on Facebook) without sharing your login credentials. This ensures secure access to your data while maintaining privacy and control over how it's used. While you can use the default Rclone credentials, it comes with limits.

Configure OAuth Consent Screen

1. Navigate to the Google Cloud Console and click on "Manage" for the Google Drive API.
2. Go to APIs & Services > OAuth consent screen.
3. Choose External or Internal based on your needs and click Create. In this case, select External.
4. Fill out the App Information (e.g., app name, user support email).
5. Under Scopes, add the following scopes:

• https://www.googleapis.com/auth/docs
• https://www.googleapis.com/auth/drive
• https://www.googleapis.com/auth/drive.metadata.readonly

7. Save and continue through the remaining setup steps.
8. Add your own account to the test users and publish your app.

Generating Client ID and Secret

1. Go to the Google Cloud Console.
2. Navigate to APIs & Services > Credentials > Create Credentials > OAuth client ID.
3. Select "Desktop app" as the application type.
4. Note down the generated Client ID and Client Secret for Rclone configuration. You can also download the client secret JSON file.

5. Configure Rclone

Now that we’ve got the OAuth credentials, let’s configure Rclone to use them.

Note that OAuth requires a web browser for authorization. If you are using a headless machine, there are several ways of going about this. You can use SSH tunnel to redirect the headless box port 53682 to the local machine thereby enabling browser access.

ssh -L localhost:53682:localhost:53682 username@remote_server

Fire up your terminal and start the Rclone configuration:

rclone config

Configuration

Follow the prompts:

1. Type n to create a new remote.
2. Name the remote (e.g., gdrive).
3. Select the cloud storage provider (e.g., 17 for Google Drive).
4. Enter the client_id and client_secret from your downloaded JSON file.
5. Leave the rest of the fields as default unless you have specific requirements.
6. Open the provided URL in your browser to authorize Rclone and get the token.

6. Set Up Encryption

Encrypting your backups ensures that even if someone gains access to your cloud storage, they can’t read your data without the encryption key. Let’s make sure your data stays safe.

Start Rclone configuration:

rclone config

Configure Encrypted Remote

Follow the prompts to add encryption:

1. Type n to create a new remote.
2. Name the remote (e.g., encrypted-gdrive`).
3. Select crypt for the storage type.
4. Choose the previously configured remote as the remote to encrypt and set the path where the encrypted data will be stored (e.g., gdrive:enc_backup). Ensure the path exists on Google Drive.
5. Choose a password and a salt for encryption. Make sure to store these securely.

7. Writing Your Backup Script

Creating a backup script is essential to automate and manage your backup process. Here's an example of a shell script (backup.sh) that not only performs the backup but also implements a retention policy to manage storage effectively by retaining a specific number of recent backups and deleting older ones.

#!/bin/bash

# Define variables
DB_NAME="blog_prod"
GHOST_CONTENT_DIR="/var/www/blog/content"
BACKUP_DIR="/home/keelan/backup"
REMOTE_NAME="encrypted-gdrive"
REMOTE_PATH="data-backups"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
MYSQL_DUMP="$BACKUP_DIR/ghost_prod-$TIMESTAMP.sql.gz"
TARBALL="$BACKUP_DIR/content-$TIMESTAMP.tar.gz"
COMBINED_TARBALL="$BACKUP_DIR/backup-$TIMESTAMP.tar.gz"
LOG_DIR="/home/keelan/log"
LOG_FILE="$LOG_DIR/backup_script.log"
MAX_BACKUPS=20

# Function to log messages
log_message() {
    echo "$(date +"%Y-%m-%d %H:%M:%S") : $1" >> "$LOG_FILE"
}

# Function to run a command and log it
run_command() {
    local cmd="$1"
    log_message "$cmd"
    eval "$cmd"
    local status=$?
    if [ $status -ne 0 ]; then
        log_message "Error: Command failed with status $status"
        exit $status
    fi
}

# Create backup directory if it doesn't exist
mkdir -p "$BACKUP_DIR"

# Create log directory if it doesn't exist
mkdir -p "$LOG_DIR"

# Dump MySQL database and compress it
run_command "mysqldump $DB_NAME --no-tablespaces | gzip > $MYSQL_DUMP"
log_message "Database backup created and compressed successfully."

# Create tarball of Ghost content directory
run_command "tar -zcvf $TARBALL -C $GHOST_CONTENT_DIR ."
log_message "Ghost content tarball created successfully."

# Combine MySQL dump and Ghost content into one tarball
run_command "tar -zcvf $COMBINED_TARBALL -C $BACKUP_DIR $(basename $TARBALL) $(basename $MYSQL_DUMP)"
log_message "Combined tarball created successfully."

# Copy tarball to Google Drive
run_command "rclone copy $COMBINED_TARBALL $REMOTE_NAME:$REMOTE_PATH"
log_message "Backup successfully copied to Google Drive."

# Clean up local files
run_command "rm -f $MYSQL_DUMP $TARBALL $COMBINED_TARBALL"

# Clean up old backups
backup_list=$(rclone ls "$REMOTE_NAME":"$REMOTE_PATH" | sort -r | awk '{print $2}')
backup_count=$(echo "$backup_list" | wc -l)

if [ $backup_count -gt $MAX_BACKUPS ]; then
  echo "$backup_list" | tail -n +$(($MAX_BACKUPS + 1)) | while read -r backup; do
    run_command "rclone deletefile $REMOTE_NAME:$REMOTE_PATH/$backup"
    log_message "Deleted old backup: $backup"
  done
fi

# Log backup activity
log_message "Backup process completed successfully."

echo "Backup process completed successfully."

Make the script executable:

sudo chmod +x backup.sh

Creating a dedicated MySQL user for backups ensures that your database access is secure and limited to only the permissions necessary for performing backups.

mysql> CREATE USER 'backup'@'localhost' IDENTIFIED BY 'backuppassword';
mysql> GRANT ALL ON blog_prod.* TO 'backup'@'localhost';
mysql> FLUSH PRIVILEGES;

Creating a ~/.my.cnf file simplifies the backup process by storing the MySQL credentials securely. This file is read automatically by MySQL client tools, so you don’t need to enter the username and password every time you run a backup.

[client]
user=backup
password="backuppassword"

Test the backup process:

./backup.sh

Sure enough, it gets uploaded to Google Drive and is encrypted.

8. Scheduling Automated Backups

Schedule the backup script to run automatically at regular intervals (e.g., daily or weekly) using cron jobs on Linux:

crontab -e

Add the following line to schedule the script to run every Sunday at 1 AM and log the output:

0 1 * * 0 /home/keelan/backup.sh >> /home/keelan/log/cron.log 2>&1

9. Testing and Monitoring Your Backups

Verification

Periodically test your backup strategy by restoring backups to ensure they are complete and functional.

Monitoring

Monitor backup logs for any errors or warnings related to backup operations.

Conclusion

Your data is more than just files—it’s your hard work, creativity, and possibly your livelihood. Protect it with a reliable backup strategy using Rclone and your chosen cloud storage provider. By following this guide, you've equipped yourself with the tools and knowledge to safeguard your data against unexpected loss. Take charge of your data protection today and ensure continuity in your work and personal projects. With backups in place, you can move forward with confidence, knowing that your content is securely backed up and ready for whatever the future holds.

In the ever-evolving world of the internet, new technologies like QUIC and HTTP/3 are reshaping how we browse and interact online. These protocols represent a significant leap forward in enhancing web performance, security and efficiency.

Understanding QUIC

QUIC, developed initially by Google and now standardized as IETF QUIC, stands out for its innovative approach to web connections. Unlike traditional TCP which requires a separate TLS handshake to establish encryption, QUIC operates over UDP and includes encryption by default. This design not only speeds up connection establishment but also ensures secure data transmission.

HTTP/3: Revolutionizing Web Communications

HTTP/3 builds upon the foundation of QUIC to improve the Hypertext Transfer Protocol (HTTP). By replacing TCP with QUIC’s advanced capabilities, HTTP/3 overcomes traditional limitations. It eliminates head-of-line blocking, a bottleneck where delays in one packet can stall others, thereby accelerating website load times. Additionally, HTTP/3 excels on mobile networks where it efficiently handles latency and packet loss issues, ensuring a seamless user experience. Moreover, QUIC has the ability to persist a connection across network changes.

Cyberstorm.mu’s Role in Advancing QUIC

Cyberstorm.mu, a dedicated community at the forefront of internet technology, has been contributing to the development of QUIC since 2019. Through active participation in IETF hackathons, Cyberstorm has refined QUIC implementations.

Academic Contributions

In addition to hackathons, Cyberstorm members have pursued groundbreaking research in QUIC. Jeremie Daniel's 2021 thesis focused on optimizing congestion control within QUIC crucial for maintaining efficient data transmission under heavy network traffic. Keelan Cannoo’s 2023 thesis explored the integration of post-quantum cryptography into QUIC, addressing future security challenges posed by quantum computing.

Embracing the Future of Web Protocols

As major platforms and services embrace HTTP/3, the impact of QUIC and HTTP/3 on the internet landscape becomes increasingly profound. From Google and Facebook to Cloudflare and Uber, adoption of these protocols underscores their transformative potential in delivering faster, more secure and reliable web experiences for users worldwide.

Setting up Ghost CMS on a Linux server from scratch can be an exhilarating journey into website creation. This guide will walk you through the process step-by-step, including integrating Cloudflare for enhanced security and performance. We'll cover everything from getting hosting and a domain to configuring firewalls and securing your admin dashboard. Let's dive in!

Objectives

By the end of this guide, you will:

• Learn how to set up a Ghost CMS on a Linux server.
• Set up your domain with the appropriate DNS configurations.
• Integrate Cloudflare for improved security and performance.
• Configure essential security measures, including disabling root SSH, setting up nftables, ipset and a droplet firewall.
• Add swap memory to your server.
• Backup your Ghost CMS installation regularly.
• Secure the admin dashboard with Cloudflare Zero Trust.
• Monitor your website's uptime with external tools like UptimeRobot.

Prerequisites

Before proceeding, ensure you have the following:

• A Linux server (preferably Ubuntu 20.04 or later).
• Basic knowledge of using the command line.
• Basic SSH knowledge

Step 1: Setting Up Your Hosting and Domain

1. Choose a Hosting Provider: Select a hosting provider that supports Linux servers. Popular options include DigitalOcean, AWS and Linode. For this guide, we'll use DigitalOcean.
2. Create a Droplet: Sign in to your hosting provider and create a new droplet (virtual server) with Ubuntu 22.04. After creation, the droplet will have a public IP address.
   
   In this case, we will create a droplet with 25GB SSD, 1GB RAM and 1 CPU Core. Choose SSH as the authentication method instead of a password.

Registering a Domain

3. Domain Registration: If you don't have a domain name yet, register one with Cloudflare. Other services like Namecheap, GoDaddy and Google Domains are popular choices.

Configuring DNS Settings on Cloudflare

Once registered, point your domain to your server's IP address. This step is crucial for connecting your domain to your server and making your site accessible online.

4. Configure to use DNSSEC by going at Domain Registrations > Manage Domains > your domain > Configuration

5. Configure DNS records. Head to websites>your domain >DNS Records. Add A and CNAME records as shown below:

Step 2: Initial Server Configuration

After setting up your hosting and domain, it's time to configure your server for secure operation.

1. Access Your Server: Use SSH to connect to your server.

ssh root@your_server_ip

2. Create a New User: For security, create a new user with sudo privileges.

adduser keelan
usermod -aG sudo keelan

3. Rsync SSH Configuration: Set up SSH keys and permissions for the new user.

rsync --archive --chown=keelan:keelan ~/.ssh /home/keelan

4. SSH Hardening:

• Open the SSH configuration file.

nano /etc/ssh/sshd_config

• To disable root SSH login, find and change PermitRootLogin to no.
• To disable Password Authentication, ensure PasswordAuthentication is set to no.
• Change SSH Port to something else. For example 8123.

5. Restart the SSH service.

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
sudo systemctl status ssh.socket ssh.service

6. SSH using newly created user.

ssh keelan@your_server_ip -p 8123

Step 3: Add Swap Memory

Adding swap memory can help improve your server's performance by providing additional memory space, which is particularly useful for preventing Out Of Memory (OOM) issues, especially on servers with low RAM.

1. Create a Swap File:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

2. Make the Swap File Permanent:

Add the swap file to /etc/fstab.

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Step 4: Install mysql, Ghost CLI and Node.js

Following the official ghost installation guide,

1. Update packages

sudo apt-get update
sudo apt-get upgrade

2. Install nginx

sudo apt-get install nginx

3. Install and configure mysql

sudo apt-get install mysql-server
# Enter mysql
sudo mysql
# Update permissions
ALTER USER 'root'@'localhost' IDENTIFIED WITH 'mysql_native_password' BY '<your-new-root-password>';
# Reread permissions
FLUSH PRIVILEGES;
# exit mysql
exit

4. Install Node.js

curl -sL https://deb.nodesource.com/setup_14.x | sudo -E bash -
sudo apt install -y nodejs


# Download and import the Nodesource GPG key
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg

# Create deb repository
NODE_MAJOR=18 # Use a supported version
echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_$NODE_MAJOR.x nodistro main" | sudo tee /etc/apt/sources.list.d/nodesource.list

# Run update and install
sudo apt-get update
sudo apt-get install nodejs -y

5. Install Ghost CLI

sudo npm install -g ghost-cli

Step 5: Secure with Cloudflare SSL/TLS

In the Overview tab, Set SSL/TLS Encryption Mode to Full (Strict).

Configure Edge Certificates on Cloudflare

• Go to the Edge Certificates tab in the SSL/TLS section.
• Ensure Always Use HTTPS is enabled to redirect all HTTP traffic to HTTPS.
• Set Minimum TLS Version to TLS 1.2.

Generate Private Key and Certificate with Cloudflare

1. Go to the Origin Server tab in the SSL/TLS section.
2. Click create certificate to generate private key and certificate with Cloudflare.

3. Paste Certificate and Private Key on the Origin Server.

sudo mkdir -p /etc/ssl/cloudflare
sudo nano /etc/ssl/cloudflare/your_domain.crt
sudo nano /etc/ssl/cloudflare/your_domain.key

Step 6: Set Up Ghost CMS

With the necessary tools installed, you can now set up Ghost CMS.

1. Create a Directory for Ghost

sudo mkdir -p /var/www/sitename
sudo chown newuser:newuser /var/www/sitename
sudo chmod 775 /var/www/sitename

2. Install Ghost

cd /var/www/sitename
ghost install

Follow the installation prompts to set up Nginx and SSL. The Ghost CLI will create initial Nginx and SSL configurations which we will adjust manually in the next step to use the SSL certificates from Cloudflare.

Step 7: Configure Nginx

Nginx will serve as the reverse proxy for your Ghost CMS. It's important to configure Nginx to pass the original IP address of clients to your application, use the SSL certificates obtained from Cloudflare, and secure your site by disabling direct IP access.

Block Direct IP Access

1. Edit the default Nginx configuration to block direct IP access:

sudo nano /etc/nginx/sites-available/default

# Disable direct IP access
server {
        listen 80 default_server;
        listen [::]:80 default_server;

        listen 443 default_server;
        listen [::]:443 default_server;

        server_name _;
        ssl_reject_handshake on;
        return 444;
}

Configure Nginx for Ghost

1. Edit Nginx Configuration for Ghost:

Replace with your own domain configuration file.

sudo nano /etc/nginx/sites-available/curiouskit.dev-ssl.conf 

2. Add the following configuration:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name www.curiouskit.dev curiouskit.dev;

    # setup our access and error logs
    access_log /var/log/nginx/curiouskit.dev.access.log;
    error_log /var/log/nginx/curiouskit.dev.error.log;

    # SSL certificate and key files
    ssl_certificate /etc/ssl/cloudflare/your_domain.crt;
    ssl_certificate_key /etc/ssl/cloudflare/your_domain.key;

    include /etc/nginx/snippets/ssl-params.conf;
    server_tokens off; # Hide Nginx version number

    # Cloudflare IP ranges to log original client IP
    # https://www.cloudflare.com/ips/
    set_real_ip_from 103.21.244.0/22;
    set_real_ip_from 103.22.200.0/22;
    set_real_ip_from 103.31.4.0/22;
    set_real_ip_from 104.16.0.0/12;
    set_real_ip_from 108.162.192.0/18;
    set_real_ip_from 131.0.72.0/22;
    set_real_ip_from 141.101.64.0/18;
    set_real_ip_from 162.158.0.0/15;
    set_real_ip_from 172.64.0.0/13;
    set_real_ip_from 173.245.48.0/20;
    set_real_ip_from 188.114.96.0/20;
    set_real_ip_from 190.93.240.0/20;
    set_real_ip_from 197.234.240.0/22;
    set_real_ip_from 198.41.128.0/17;
    real_ip_header CF-Connecting-IP;

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:2368;
    }

    client_max_body_size 1g;
}

SSL Parameters

Open the SSL parameters configuration file:

sudo nano /etc/nginx/snippets/ssl-params.conf

Add the following SSL parameters:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; # Requires nginx >= 1.5.9
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security 'max-age=63072000; includeSubDomains; preload';
add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
ssl_dhparam /etc/nginx/snippets/dhparam.pem;

3. Enable the Configuration:

# Test the Nginx configuration for syntax errors
sudo nginx -t

# Restart Nginx to apply the changes
sudo systemctl restart nginx

Step 8: Configure firewall

To protect your server from unauthorized access, you should configure nftables. This setup will deny all traffic by default, allow necessary traffic, and secure your Ghost CMS server. We'll use nftables to define rules that handle traffic appropriately.

Create or update the main nftables configuration file /etc/nftables.conf:

#!/usr/sbin/nft -f

flush ruleset

# Create the base table and chains
table inet my_table {
    # Define Cloudflare IPs set
    include "/etc/nftables.d/cloudflare-ips.conf"

    chain input {
        type filter hook input priority 0; policy drop;

        # Drop invalid packets.
        ct state invalid drop

        # Allow loopback traffic.
        iifname lo accept

        # Allow all ICMP traffic, but enforce a rate limit
        # to help prevent some types of flood attacks.
        ip protocol icmp limit rate 4/second accept

        # Allow SSH on port 8124
        tcp dport 8124 ct state new,established accept

        # Allow incoming HTTP/HTTPS responses
        tcp sport {80, 443} ct state established accept

        # Allow incoming DNS responses
        udp sport 53 ct state established accept
        tcp sport 53 ct state established accept

        ip saddr $cloudflare_ips tcp dport 443 ct state new,established accept

        # Log and drop everything else
        log prefix "nftables: INPUT DROP " drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy drop;

        # Allow all traffic on the localhost interface
        oif lo accept

        # Allow established SSH connections
        tcp sport 8124 ct state established accept

        # Allow outgoing HTTP/HTTPS requests
        tcp dport {80, 443} ct state new,established accept

        # Allow outgoing DNS requests
        udp dport 53 ct state new,established accept
        tcp dport 53 ct state new,established accept

        # Allow outgoing ICMP (ping) traffic
        ip protocol icmp accept

        # Allow outgoing HTTPS traffic to established connections
        tcp sport 443 ct state established accept

        # Log and drop everything else
        log prefix "nftables: OUTPUT DROP " drop
    }
}

Cloudflare IPs Configuration

Ensure that the Cloudflare IPs configuration file /etc/nftables.d/cloudflare-ips.conf is up-to-date:

define cloudflare_ips = {
    103.21.244.0/22,
    103.22.200.0/22,
    103.31.4.0/22,
    104.16.0.0/13,
    104.24.0.0/14,
    108.162.192.0/18,
    141.101.64.0/18,
    162.158.0.0/15,
    172.64.0.0/13,
    173.245.48.0/20,
    188.114.96.0/20,
    190.93.240.0/20,
    197.234.240.0/22,
    198.41.128.0/17
}

Script to Update Cloudflare IPs

#!/bin/bash

set -e

# Variables
NFTABLES_CONF="/etc/nftables.conf"
CLOUDFLARE_CONF="/etc/nftables.d/cloudflare-ips.conf"
BACKUP_DIR="/etc/nftables.d/backups"
LOG_FILE="/home/keelan/log/nftables-update.log"
TIMESTAMP=$(date +"%Y%m%d%H%M%S")

# Create backup directory and log directory if they don't exist
mkdir -p $BACKUP_DIR
mkdir -p $(dirname $LOG_FILE)
touch $CLOUDFLARE_CONF

# Function to fetch Cloudflare IP ranges
fetch_cloudflare_ips() {
    curl -s https://www.cloudflare.com/ips-v4
}

# Backup existing configuration
cp $NFTABLES_CONF $BACKUP_DIR/nftables.conf.$TIMESTAMP
cp $CLOUDFLARE_CONF $BACKUP_DIR/cloudflare-ips.conf.$TIMESTAMP

# Fetch the latest Cloudflare IP ranges
CLOUDFLARE_IPS=$(fetch_cloudflare_ips)

# Generate new Cloudflare configuration file
NEW_CLOUDFLARE_CONF=$(echo $CLOUDFLARE_IPS | tr ' ' '\n' | sed 's/^/    /' | sed '$!s/$/,/' | sed '1 i\define cloudflare_ips = {' | sed '$ a\}')
# Check if the configuration has changed
if ! cmp -s <(echo "$NEW_CLOUDFLARE_CONF") $CLOUDFLARE_CONF; then
    echo "Changes"
    # Update Cloudflare configuration file
    echo "$NEW_CLOUDFLARE_CONF" > $CLOUDFLARE_CONF

    # Validate the nftables configuration
    nft -c -f $NFTABLES_CONF

    # Apply the updated nftables configuration
    if nft -f $NFTABLES_CONF; then
        echo "$(date +"%Y-%m-%d %H:%M:%S") - Updated Cloudflare IPs and reloaded nftables configuration" >> $LOG_FILE
    else
        echo "$(date +"%Y-%m-%d %H:%M:%S") - Failed to reload nftables configuration" >> $LOG_FILE
        # Restore the previous configuration in case of failure
        cp $BACKUP_DIR/nftables.conf.$TIMESTAMP $NFTABLES_CONF
        cp $BACKUP_DIR/cloudflare-ips.conf.$TIMESTAMP $CLOUDFLARE_CONF
        systemctl restart nftables
        echo "$(date +"%Y-%m-%d %H:%M:%S") - Restored previous nftables configuration due to failure" >> $LOG_FILE
    fi
else
    echo "$(date +"%Y-%m-%d %H:%M:%S") - No changes in Cloudflare IPs" >> $LOG_FILE
fi

Step 9: Set Up a Droplet Firewall

1. Use Your Hosting Provider's Firewall: Configure the firewall through your hosting provider’s dashboard to allow only necessary ports (typically your SSH port, 80, 443).

Step 10: Secure Ghost Admin with Cloudflare Zero Trust

Restrict access to the Ghost admin panel using Cloudflare Zero Trust while allowing Content API.

1. Enable Zero Trust: In the Cloudflare dashboard, go to Zero Trust set up Access Policies to restrict access to the Ghost admin panel.

Create an Access Application for Ghost Admin:

• Go to Access > Applications.
• Click Add an application and choose Self-hosted.
• Name the application (e.g., "Ghost Admin").
• Set Application domain to yourdomain.com/ghost.
• Click Next.

Access Policy

• Name the policy (e.g., "Protect Ghost Admin").
• Set Action to Allow.
• Under Include, specify authorized email addresses or groups.
• Click Next and Add application.

Create a Bypass Rule for the Content API

5. Create a Bypass Application for Content API:
   • Go to Access > Applications.
   • Click Add an application and choose Self-hosted.
   • Name the application (e.g., "Ghost Content API").
   • Set Application domain to yourdomain.com/ghost/api/content.
   • Click Next.
6. Create Bypass Policy:
   • Name the policy (e.g., "Bypass Ghost Content API").
   • Set Action to Bypass.
   • Under Include, select Everyone.
   • Click Next and Add application.

Verify Configuration

7. Verify Access:
   • Go to https://yourdomain.com/ghost and ensure authentication is required.
   • Access https://yourdomain.com/ghost/api/content to confirm it is publicly accessible.

Step 11: Regular Backups

Ensuring regular backups of your Ghost CMS content is crucial to protect against data loss. For a comprehensive, step-by-step guide on setting up end-to-end encrypted backups using rclone, please refer to my detailed blog post:

Implementing End-to-End Encrypted Backups with Rclone

Learn how to set up a robust, end-to-end encrypted backup strategy for your data using Rclone. This tutorial ensures your valuable information remains secure and your hard work preserved by leveraging the power of cloud storage and encryption.

Keelan CannooKeelan Cannoo

Step 12: Monitor Website Uptime with UptimeRobot

Monitoring your website's uptime helps you ensure it's always available to your visitors.

1. Sign Up for UptimeRobot: Register an account at UptimeRobot.
2. Add a New Monitor:
   • Select “HTTP(s)” as the monitor type.
   • Enter your website URL.
   • Set the monitoring interval and enable notifications.
3. Set up a notification to be sent when your website is back online, ensuring you're aware of both downtime and recovery events.

Conclusion

Congratulations! You have successfully set up Ghost CMS on a Linux server with enhanced security and performance using Cloudflare. Your website is now live and ready to handle visitors securely. Remember to regularly update your server and Ghost installation to keep your site secure and running smoothly.

Happy blogging!

In recent cybersecurity news, a significant vulnerability has been uncovered in xzutils, a widely-used compression utility. xzutils is included by default in many Linux distributions. Tracked as CVE-2024-3094, this backdoor affects versions 5.6.0 and 5.6.1 of XZ Utils, posing a serious threat to users globally.

What Happened?

The threat actor Jia Tan started contributing to the XZ project almost two years ago, slowly building credibility until he was given maintainer responsibilities. Jia Tan's rise involved clever social engineering. Using fake accounts, he overwhelmed the original maintainer with feature requests and bug reports, creating pressure to add more help. This tactic secured Jia Tan a significant role in the project.

In 2023, after nearly two years of contributions, Jia Tan introduced changes in release 5.6.0, including a sophisticated backdoor. This revelation shocked the community, highlighting vulnerabilities in the open-source model.

Impact

The exploitation of CVE-2024-3094 enabled remote code execution (RCE), giving attackers unauthorized access to a very specific set of systems that relied on compromised versions of xzutils. This raised concerns about the integrity and security of these systems, highlighting the need for immediate action.

Response and Collaboration

In response to this critical discovery, Michael Scovetta, a security expert from Microsoft, initiated a community project aimed at conducting a comprehensive audit of various compression utilities. This proactive collaboration aimed to identify similar vulnerabilities in other tools and prevent potential threats before they could be exploited. Participants were encouraged to contribute and Cyberstorm.mu eagerly joined the effort to support this important work.

The Audit Process

The audit involved creating a list of widely used compression libraries including gzip, bzip2 and zip for scrutiny. A spreadsheet was used to track and flag binary test cases needing closer inspection. Detailed examinations of the code and binaries were conducted for these flagged entries and findings were documented to ensure continuous improvement of security.

The discovery of CVE-2024-3094 serves as a stark reminder of the vulnerabilities in the open-source ecosystem. It underscores the importance of vigilance, robust security measures and collaborative efforts to protect the integrity of essential software tools.

The open-source world is a remarkable place where collaboration and innovation thrive. For me, contributing to open-source projects has been a transformative experience, culminating in the incredible opportunity to meet and work alongside one of the original co-founders of FreeBSD, Rodney W. Grimes. This blog post shares my journey through open source, highlighting how contributions opened doors to this unique experience and how Cyberstorm.mu facilitated an inspiring talk by Rodney at our university.

Getting Started with Open Source

My journey into open source began during my second year at university, driven by a strong interest in networking and software development. My first contributions were a security patch for libevent and Dockerfiles for the OpenQuantumSafe project. Later, I started working on FRRouting (FRR) with Loganaden Velvindron and Sarvesh Dindyal. We persevered and started making meaningful contributions focusing on fixing memory leaks.

The Breakthrough

As we became more involved in the FRRouting project, we had the incredible opportunity to work under the guidance of Rodney W. Grimes, one of the three original founders of FreeBSD. Collaborating remotely, we continued to identify and fix memory leaks in FRRouting, aiming to improve the software's performance and stability. This collaboration eventually led to Rodney visiting Mauritius to work with us directly during my final year at university.

Meeting and Working with a FreeBSD Co-Founder

Meeting Rodney in person was an extraordinary experience. His deep understanding of system internals and network protocols was invaluable. During his visit to Mauritius, we had the opportunity to work together closely. He taught us advanced debugging techniques using GDB and provided hands-on training in software debugging and development practices. His mentorship provided us with insights into best practices and advanced concepts that significantly elevated our technical skills.

Bringing Knowledge Home

The impact of this collaboration extended beyond personal growth. Cyberstorm.mu recognized the value of sharing this opportunity with our local community. We organized a talk to disseminate the insights gained. The highlight was inviting Rodney W. Grimes to speak at our university. His talk was a resounding success, drawing a large audience of students, professors and local tech enthusiasts eager to learn from his experiences and insights.

The Importance of Community and Collaboration

This journey underscored the power of open-source communities. The collaborative spirit, the willingness to share knowledge and the drive to innovate create an environment where anyone can contribute and grow. Meeting and working with a pioneer like Rodney W. Grimes was a reminder of how much can be achieved through dedication and collaboration.

Conclusion

Reflecting on my open-source journey, I realize how contributing to projects like OpenQuantumSafe and FRRouting has profoundly impacted my professional development and community engagement. The opportunity to meet and work with Rodney W. Grimes was a significant milestone, illustrating the incredible possibilities that open-source contributions can offer. I encourage anyone interested in technology to dive into open-source projects—it's a gateway to learning, mentorship from experienced professionals and unique opportunities.

Public key cryptography is an integral part of our daily internet activities. Whether you're browsing your favorite website, watching the latest trending series, sending an email, online shopping or social media messaging, it's there, silently ensuring that your data remains secure. But with the advent of quantum computing, the security provided by traditional public key cryptography is under threat. This blog post aims to shed light on the need for new algorithms and the emergence of post-quantum cryptography.

Objectives

• Gain an understanding of the need for new algorithms
• Understand post-quantum cryptography

Traditional Public Key Cryptography: A Quick Primer

Before we dive into post-quantum cryptography, let's take a moment to understand the mechanism behind traditional public-key cryptography. What really makes these algorithms secure?

Traditional public key cryptography relies on two types of mathematical problems: prime integer factorization and the discrete logarithm. These problems are relatively straightforward to compute in one direction but extremely difficult to reverse without specific information.

Prime Integer Factorization

For example, given two huge prime numbers, it's easy to compute their product. However, given the product, it is exceedingly difficult to determine the original prime numbers.

For instance, while it’s simple to multiply 661 and 251 to get 165,911, figuring out the prime factors of 165,911 is significantly harder without knowing them in advance. Real-world applications use much larger prime numbers, adding to the complexity.

Discrete Logarithm

The discrete logarithm problem is another one-way function that is easy to compute but hard to reverse. In the context of cryptography, this often involves a large prime number p and a generator g. Given g and x, where y ≡ g^x  mod p, it is easy to compute y. However, given y, it is extremely difficult to determine x.

For example, if g = 5, p = 23 and y = 8, finding x such that 8 ≡ 5^x mod 23 is a hard problem. In real-world applications, g, p and y are much larger, making the problem even more challenging. In this example, x=6 satisfies 8 ≡ 5⁶mod 23.

In simple terms, public key cryptography relies on these mathematical problems to exchange keys for encryption and to create digital signatures.

The Quantum Threat

If these algorithms have been working fine, what's the issue? The problem lies in the advancements in quantum computing. With tech giants like IBM, Google and Microsoft investing hundreds of millions of dollars, significant breakthroughs in quantum computing are happening.

In 1994, the mathematician Peter Shor devised an algorithm that can quickly and efficiently solve the prime factorization and discrete logarithm problems. Fortunately, Shor’s algorithm only runs on quantum computers which are still in their infancy. However, it is only a matter of time before powerful enough quantum computers can be built to break the cryptographic algorithms we currently rely on.

Some might think, "There’s time left. Why worry now?". Unfortunately, that’s a misconception. Communications exchanged today can be intercepted and stored, only to be decrypted later when quantum computers become available. There is evidence suggesting that some entities might already be engaging in such activities as revealed by Edward Snowden. This means that today’s communications are at risk and need to be secured now to protect future data integrity.

NIST Post-Quantum Cryptography (PQC) Standardization

Recognizing the impending threat, the National Institute of Standards and Technology (NIST) launched a competition to develop new cryptographic algorithms that are resistant to quantum attacks. Researchers from around the world proposed new algorithms based on different mathematical problems such as lattice-based cryptography, code-based cryptography and others. Over several years and rounds, these algorithms were scrutinized and tested.

Some of these algorithms, such as CRYSTALS-Kyber and CRYSTALS-Dilithium, have emerged as leading candidates for standardization. While they haven't been fully standardized yet, they are being actively evaluated and adopted by various organizations. For example, the German Federal Office for Information Security (BSI) and the French ANSSI endorse FrodoKEM for post-quantum security.

Contributions from cyberstorm.mu

Cyberstorm.mu, has been actively working and contributing towards post-quantum algorithms. We have analyzed the impact of post-quantum cryptography in protocols such as QUIC and DNS, and contributed to open-source projects by OpenQuantumSafe. This hands-on experience has given us unique insights into the practical challenges and solutions for integrating post-quantum cryptography into existing systems.

Global Adoption

The adoption of post-quantum cryptography is gaining momentum globally. Singapore and the White House are among the entities that have embraced these new algorithms, signaling a shift towards quantum-resistant security measures.

Transitioning to Post-Quantum Cryptography

It’s important to note that post-quantum cryptographic algorithms have not yet withstood the test of time. As such, the transition is happening in a hybrid manner where traditional cryptographic methods are used alongside post-quantum algorithms to ensure a smooth and secure shift.

Conclusion

The era of quantum computing is on the horizon, bringing with it both incredible opportunities and significant challenges. While traditional public key cryptography has served us well, the advent of quantum computers necessitates the development and adoption of new cryptographic algorithms. By understanding and preparing for these changes now, we can ensure that our data remains secure in the future.

As we continue to explore the realm of post-quantum cryptography, it's crucial to stay informed and proactive. After all, securing tomorrow's data today is not just a necessity; it's a responsibility.

By the end of this guide, you will

• Have a basic understanding of how TLS 1.3 handshake works
• Be able to use curl to make request and get additional information such as the IP address of web server, TCP port, etc
• Be able to capture and filter packets using wireshark
• Be able to log pre-master secrets and use them to decrypt TLS traffic

Overview

TLS 1.3 is a major overhaul of the TLS protocol with enhanced speed, improved efficiency and better security. Ciphers and algorithms which are considered weak and insecure have been removed in the latest TLS version. These include RSA key exchange, 3-DES, DES and RC4 stream cipher among many more. As a result, the number of cipher suites dropped from 37 to 5. RSA key exchange was removed since it does not provide forward secrecy and is vulnerable to specific attacks such as Bleichenbacher attacks. This means that if the private key of the server is leaked in the future, the past ciphertexts can be decrypted.  In TLS 1.3 all key exchange algorithms were removed except for Diffie-Hellman (DH).

Additionally TLS 1.3 requires servers to sign the entire handshake including the cipher negotiation unlike TLS 1.2. Furthermore, TLS 1.3 takes only one round trip to complete a handshake whereas TLS 1.2 takes two round trips. This is possible because the client guesses the parameters the server will use and can therefore send the DH key share in the first handshake message itself (Client Hello). 

Prerequisites

• Wireshark

sudo apt install wireshark

• Curl

sudo apt install curl

Capturing the packets and SSL key log

1. Set SSLKEYLOGFILE Environment Variable

Open terminal and set the SSLKEYLOGFILE environment variable to the file path where you want to save the key log. Ensure you have write permission to the location you specify. Run: 

export SSLKEYLOGFILE=$HOME/Desktop/keylog

2. Open Wireshark in another tab in terminal and start capture

sudo wireshark

To open wireshark, run sudo wireshark.  Double click on the appropriate network interface to start capture. Alternatively, you can right click and choose "start capture".

3. Use curl to make request to a server which supports TLS 1.3

Ensure that you are in the same terminal in which you set the SSLKEYLOGFILE environment variable. You can run echo $SSLKEYLOGFILE  to ensure that it is set.

Note: If you want to access the website through chrome (google-chrome https://google.com) or firefox (firefox https://google.com), make sure you open the web browser from that terminal.

Close all browsers and run curl https://google.com -v.

The output will display the IP address of the web server (e.g., 172.217.170.174).

At this point, the key log file you specified in the first step should have been automatically created and written to. 

4. Stop capture and filter the packets

Use the following filter to display only packets involving the web server of that website and which uses TLS protocol:

tls && ip==172.217.170.174

Analyzing the packets

At first glance, it can be seen that:

1. The client first sends Client Hello to the server
2. The server responds with Server Hello followed by Change Cipher Spec unlike TLS 1.2.
3. The server also sends some encrypted application data along.
4. The client sends a Change Cipher Spec to the server together with some encrypted data. The rest of the conversation is encrypted as well.

Now we will use the client key log file to decrypt the TLS traffic.On Wireshark, go to Edit ->Preferences->Protocols->TCP. Then change the (Pre)-Master-Secret log filename to the location of the key log file and click OK.

Wireshark will convert the pre-master to the master key and decrypt all the encrypted application data of the conversation.

Making sense of the TLS 1.3 handshake

1.  Client sends Client Hello

It's odd to see the client request a TLS 1.2 handshake. This happens because TLS 1.3 is a victim of protocol ossification. A large number of servers implemented TLS version negotiation wrongly. When presented by the client with a version of TLS higher than what they support, those servers disconnect instead of replying with the newest TLS version which both of them support. 

In order to be compatible with previous versions, TLS 1.3 disguises itself as a TLS 1.2 handshake and introduces extensions to add functionality to it. 

The latest TLS version which the client supports is actually found in the supported_versions extension.

The Client Hello includes the latest version the TLS version, a list of Cipher Suites the client supports, the client random and the key_share extension.

The key_share contains the client parameter for key exchange.

The client guesses which key exchange method the server is likely to choose and its key share for that particular method is sent. If ever the guess is wrong, the server sends a Retry Hello Request Message.

2.  Server sends Server Hello and Change Cipher Spec

In the supported_versions extension, the server confirms the TLS version.

The key_share extension has the selected curve name and server key exchange parameter. 

The Server Hello also contains the server random.

At this point, the server has the client random, the server random and both the key shares of the client and the server. Therefore the server can generate the master secret from which the session key is calculated and can start encrypting messages. So it sends Change Cipher Spec to let the client knows that it has generated the session key and is switching to an encrypted environment.

3.  Server sends Encrypted Extensions, Certificate, Certificate Verify and Finished

All those messages are encrypted using the session key and sent to the client. 

The Encrypted Extensions message contains additional extensions which can be protected but which are not needed to establish the encrypted connection. If there is no such extension, the message is empty.

Certificate contains the server's digital certificate and any per-certificate extensions. 

Certificate verify : the entire handshake is signed using the private key of the server corresponding to the public key in the certificate message. 

Finished contains a MAC to ensure integrity of handshake. It is sent to indicate that handshake is done on the server side.

4.  Client sends Change Cipher Spec and Finished.

Change Cipher Spec is sent to let the server know that the client has generated the session key and is switching to an encrypted environment. 

Finished contains a MAC to ensure integrity of handshake. It is sent to indicate that handshake is done on the client side.

In the fast-paced world of software development, the absence of a reliable version control system can lead teams down a chaotic path. Without tools like Git, teams often resort to ad-hoc methods such as sharing files via email or using shared network drives. Unfortunately, this approach breeds confusion, conflicts, and the ever-present risk of losing track of critical changes. Sounds familiar, huh?

Objectives

By the end of this guide, you will:

1. Gain a comprehensive understanding of basic Git terminology.
2. Learn how to generate and use SSH keys for secure authentication with GitHub using openSSH.
3. Acquire the necessary skills to navigate GitHub efficiently and effectively.

Prerequisites

Before proceeding, make sure you have the following prerequisite:

• Git

sudo apt install git

• A Github account 
• OpenSSH

sudo apt install openssh-client

What is Git? 

Git is an open source version control system for tracking changes to files over time. With Git, developers can create snapshots of their code at different points making it easy to revert to previous versions if needed. It also helps programmers to collaborate on projects and synchronize their work.

What is GitHub? 

GitHub is an online code hosting platform for software development projects that use git. It enables programmers to share their code files and collaborate with other developers from anywhere around the globe. GitHub offers a rich set of collaboration tools including pull requests, issue tracking and project management features. Additionally, GitHub integrates seamlessly with CI/CD pipelines automating build, test and deployment processes for projects.

Git Terminology

Repository

It is a directory for storing all the files and folders related to a project as well as the history of changes made to the files of the project. A repository residing a local machine is called local repository whereas a repository that is hosted on a server is known as a remote repository.   

Commits

Commits are simply changes you have made in your branch since your last commit. A commit is basically a snapshot of your repository.

The staging environment

Also known as the index, it is an intermediate area where the files that are going to be part of the next commit are stored. For a file to be part of a commit, you must first add it to the staging environment.

Branch

A branch is a parallel version of your repository that allows you to work on new features or fixes without affecting the primary or master branch. Branches can be merged back into the main branch when changes are ready to be published.

Master

It is the repository’s primary/default branch. In recent years, GitHub has switched to using 'main' as the default branch name in repositories, reflecting a more inclusive and neutral terminology.

Push

Push means uploading your committed changes from your local repository to a remote one (in this case GitHub).  

Pull

Pull means downloading changes, that you or other people have made, from a remote repository to the repository on your local machine.

Pull request

Pull request is a way to notify the repository’s maintainers to review the commits you made to their code and, if acceptable, merge the changes into their master branch. 

Upstream branch

A local branch can be made to track a remote branch so that pushing and pulling become easier and less susceptible to mistakes. In such a case, the local branch is known as the tracking branch and the remote branch is known as the upstream branch.

Generating and testing an SSH key

Using SSH keys provides a secure and convenient way to access GitHub repositories without the need to enter a username and password for each interaction. It's recommended for anyone working with GitHub repositories to ensure secure access and protect sensitive information.

1.  To generate key using the Ed25519 algorithm, run the following command in your terminal:

ssh-keygen -t ed25519 -C "Enter your GitHub email address here"

When prompted to enter a file to which to save key, press Enter to accept default file location. You may enter a passphrase of your choice if you wish. 

 2.  Start the ssh-agent with the following command:

eval "$(ssh-agent -s)" 

ssh-agent is used to manage SSH keys and to keep track of passphrases. Read more about ssh-agent here.

 3.  Add SSH key to ssh-agent:

 ssh-add  ~/.ssh/id_ed25519

 4.  Copy your SSH public key to your clipboard using one of the following methods: 

i. Displaying the SSH Public Key: To view your SSH public key, use the command:

cat ~/.ssh/id_ed25519.pub

When copying the key, ensure that you do not introduce any additional characters, spaces or new lines.

ii. Copying the SSH Public Key to Clipboard: If you have the xclip utility installed, you can copy the public key directly to your clipboard with the following command:

xclip -sel clip ~/.ssh/id_ed25519.pub 

5.  Navigate to SSH and GPG keys on GitHub account settings.

i. Click on your profile picture on the top right corner of GitHub. Then click on Settings.

ii. Click on SSH and GPG keys.

6.  Click new SSH key.

7.  Enter a descriptive title for your key.

8.  Paste your public key in the key field.

9.  Click Add SSH.

10.  If prompted, enter password. 

11.  To verify your SSH key is properly authenticated to GitHub, run:

ssh -T git@github.com

Basic commands

1.  Initializing a Git Repository

Whether you're starting a new project or want to add version control to an existing one, initializing a Git repository is the first step.

mkdir myProject
cd myProject
git init

To initialize a git repository, run the git init command in the project directory as shown above. 

When you run git init, Git creates a hidden directory called .git in your project’s root folder. This directory houses all the necessary metadata for version control.

2. Managing Files in Git

After initializing the repository, you can start adding and managing files.

touch newFile.txt 
git status

git status displays the current state of the working directory and the staging area. It shows which changes have been staged, which changes are not yet staged for commit and which files are not being tracked by Git. 

• touch newFile.txt: Creates a new file within the project.
• git status: Checks the current status of the repository and lists any changes.

3.   Staging Changes

Before committing changes, you need to stage them for inclusion in the next commit.

git add . 

git add . stages all (new, modified, deleted) files in the current directory.

git add -A stages all(new,modified, deleted) files in the entire working tree and not just the current directory.

• git add .: Adds all new, modified and deleted files in the current directory and its subdirectories to the staging area.
• git add -A: Adds all changes, including deletions and file creations, to the staging area.

4.  Configuring Git Identity

Configure your username and email address for Git commits.

git config --global user.name "Enter your name here"
git config --global user.email "Enter your email here" 

These commands set the username and email that are associated with your Git commits.

--global specifies that the configuration is applied to the entire system and and is not specific to just that repository. If you want to use another username and email for specific projects in the future, you can run the command without the --global option when you are in those projects. 

Run git config user.name and git config user.email to view your Git username and email respectively.

5.  Creating commits

To create a commit, use the following command:

git commit -m "Your message about the commit" 

Make sure that the message is meaningful and related to the commit!

 6.  Branching out

Branching allows you to work on different features or versions of your project concurrently. Here are some common commands for managing branches:

To create a new branch called newBranch:

git branch newBranch

To switch to the branch called newBranch:

git checkout newBranch

To create a new branch called newBranch and switch to it in a single command:

git checkout -b newBranch

git branch displays all the branches and shows which branch you are currently on.

Using branches helps keep your work organized and enables easier collaboration by isolating different lines of development.

7.  Create a new GitHub repository 

Select new repository from the + dropdown menu next to your profile picture in the top right corner.

Enter a name for your repository and click Create repository. 

8.  Linking Your Local Repository to GitHub

After ensuring that SSH is selected, go to your GitHub repository page and copy the SSH URL of your repository. It should look something like git@github.com:username/repository.git.

git remote add origin git@github.com:username/repository.git

This command creates an entry in your Git configuration that associates the name origin with your GitHub repository URL. In this case the name is origin. However, feel free to rename it as you wish.

git remote -v

This command will list the remote repositories linked to your local repository, showing the name origin and the corresponding URL.

9.  Creating a pull request

Submit changes to other projects by creating pull requests on GitHub. This allows project maintainers to review and merge your changes.

Fork the repository:

If you do not have write access to the repository (i.e., it belongs to another person or organization), you need to create a personal copy of the repository by forking it.

• Navigate to the repository you want to contribute to on GitHub.
• Click the "Fork" button at the top-right corner of the page to create a copy of the repository under your GitHub account.
• Clone your forked repository to your local machine:

git clone https://github.com/your-username/repository-name.git
cd repository-name

To create a pull request, follow these steps:

i.  Switch to the branch where you have committed your changes.

git checkout newBranch

ii.   Push the branch to remote repository.  

git push -u origin newBranch

This command uploads your branch to the remote repository. The -u option sets the upstream branch, establishing a tracking relationship between your local branch and the remote branch.

iii.  Open your GitHub repository in a web browser and click Compare and pull request.

iv.  Create pull request.

10.  Merging a Pull Request

Merge branches to incorporate changes from one branch into another. 

• Open the Pull Request: Go to your GitHub repository and navigate to the "Pull requests" tab.
• Select the Pull Request: Click on the pull request you want to merge.
• Merge the Pull Request:Review the changes one last time to ensure everything is correct.Click the green "Merge pull request" button.Confirm the merge by clicking the "Confirm merge" button.

11.  Pulling changes

To update your local repository with changes from the remote repository, follow these steps:

1. Switch to the master Branch: Ensure you are on the master branch or the main branch you want to update.

git checkout master

2. Pull the Changes: Fetch and merge changes from the remote master branch into your local master branch.

git pull origin master

If you have set the upstream branch, you can simply run git pull.

12.  Merging two branches on your local repository

To merge changes from one branch into another:

i.  Check out the target branch that you want to merge into.

git checkout targetBranch

ii. Merge the Other Branch: Merge the changes from the specified branch into your current branch.

git merge branchX

13.  Viewing all commits made to a repository 

View the commit history to understand the evolution of your project.

git log