DEV Community: Sveta.exe

🔒 What Actually Happens When You Visit an HTTPS Website?

Sveta.exe — Sun, 25 May 2025 19:05:04 +0000

After my last post on HTTP unexpectedly popped off (who knew headers were hot??💀), I figured we’d keep the beginner-friendly vibe going — but turn up the 🔐 security.

Let’s talk about HTTPS.

Everyone knows the little lock icon in your browser means “secure,” but what does that actually mean? What’s really happening when you type in a URL and hit Enter?

Let’s break it down like we’re on a mission.

📦 A Secret Agent Mission Analogy (TLS Handshake, but fun)

Let’s say your browser is a secret agent 🕵️‍♀️ who needs to deliver a message to a mysterious organization (the website), but they need to be sure:

It’s really them (not an impostor)
The message doesn’t get intercepted
They both use a secure code language no one else knows

That’s the TLS handshake — a spy-style trust test with keys, signals, and double-checks.

Here’s what happens step by step:
(We’ll skip over DNS for now — that’s a whole conversation by itself, and spoiler alert: it’s coming in my next post 👀)

🧷 Step 1: You (the browser) say hello.

Your browser reaches out and says:

"Hey https://some_website.com, I wanna start a secure chat. Here are the encryption methods I support."

This is the Client Hello. It includes:

Supported encryption algorithms
Random values for key generation
TLS version

📜 Step 2: The server says hello back + shows ID.

The server replies:

"Cool. I picked this encryption method. Here’s my certificate from a trusted source to prove I’m the real some_website.com."

This is the Server Hello and certificate. It includes:

Server’s digital certificate (issued by a Certificate Authority)
Server’s chosen encryption method

Your browser checks the certificate and verifies it against trusted CAs. (also a subject for my next post😈)

🔑 Step 3: Secret exchange (but make it safe)

Your browser generates a pre-master secret, encrypts it using the server’s public key (from the certificate), and sends it back.

Only the server can decrypt this because it has the private key. Now both of you can independently generate the same session key used to encrypt your data.

🔒 Step 4: Secure connection begins

Once keys are in place:

🔐 "Okay! We both have the same secret now. Let’s talk privately."

From now on, all messages are encrypted with the shared session key.

No eavesdropping. No tampering. No cap.

✅ Recap (TLS Handshake in Simple Terms)

Step	What Happens	Secret Agent Analogy
1	Client Hello	Agent contacts HQ, says what ciphers they can use
2	Server Hello + Cert	HQ replies, confirms identity with ID papers signed by trusted agency
3	Key Exchange	Agent sends secret passphrase encrypted so only HQ can read it
4	Encrypted Session	They now talk using their new shared code — no one else understands it 😎

🧠 Why It Matters (the big 3 of information security)

Privacy: Nobody else can read the messages
Integrity: Nobody can change them without being noticed
Authentication: You know the server is who it claims to be

All of this happens in milliseconds. Every time. And now, you know what's really going on under that little 🔒 icon.
P.S. I personally think it’s very cute that my browser and some distant server are out here shaking their imaginary binary hands just to protect my data 🥹🤝💻

💾 RAID Isn’t Just a Fancy Acronym – Why Storage Isn’t Boring

Sveta.exe — Sun, 18 May 2025 19:28:48 +0000

So I fell into a storage rabbit hole today — and somehow, it was actually… fun? 😅
Let me introduce you to RAID — a word that sounds like a boss fight but actually stands for Redundant Array of Independent Disks.

Basically, RAID is what you use when:

You want your data to survive a hard drive dying (RAID 1 vibes)
You want things to be super fast (RAID 0 zoom zoom)
Or you’re an enterprise sysadmin trying not to lose 10TB of customer data on a Monday morning

In this post, I’ll explain how RAID works, break down the most popular types — RAID 0, 1, 5, 6, 10, and 01 — and when you’d actually use them.

📦 What Is RAID (Actually)?

RAID combines multiple physical drives into one logical volume to improve performance, fault tolerance, or both.

There are two main types:

Hardware RAID — handled by a dedicated controller
Software RAID — managed by the OS (e.g. Linux mdadm, ZFS, or Windows tools)

Different RAID levels give different trade-offs. Let’s go through the main ones:

⚡ RAID 0 – Striping

Performance only, no redundancy.

RAID 0 splits ("stripes") your data across two or more drives. So if you’re saving a file, part of it goes on Disk A, part on Disk B, and so on. This makes read/write speeds super fast because the system can access data from multiple disks at once.

🚨 But: there's no backup. If even one disk fails, you lose everything — because no disk holds the full picture.

👩‍💻 Use it for: scratch disks, temporary files, gaming PCs scratch disks, temporary files, gaming PCs

🛡️ RAID 1 – Mirroring

Redundancy, but no performance boost.

RAID 1 copies ("mirrors") the exact same data to two or more disks. So every file you save is written identically on all drives in the array. If one disk dies, the other(s) have your back.

Performance isn’t better than a single disk, but reliability is great.

👩‍💻 Use it for: small business servers, boot drives, anything critical

⚙️ RAID 5 – Striping with Parity

Balanced performance and fault tolerance.

RAID 5 splits your data across all drives (like RAID 0), and also calculates a special bit of data called parity. That parity info is spread out too, and can be used to rebuild data if one disk dies.

It needs at least 3 disks: two to hold data, one for parity (though the parity is distributed). Reads are fast, and writes are decent.

🕳️ Write Hole Warning:
RAID 5 can suffer from something called a write hole, where the data and its parity get out of sync due to an unexpected power loss or system crash during a write. This can cause corruption that RAID can’t fix. Some systems mitigate this with battery-backed cache or journaling.

👩‍💻 Use it for: NAS systems, mid-size production servers NAS systems, mid-size production servers NAS systems, mid-size production servers

🧷 RAID 6 – Striping with Double Parity

Like RAID 5, but safer.

RAID 6 is just like RAID 5, but instead of one parity block, it uses two. That means it can survive two disk failures instead of one.

This adds more fault tolerance but slows down write performance a bit since more calculations are needed.

👩‍💻 Use it for: critical storage where uptime matters critical storage where uptime matters

🔀 RAID 10 (1+0) – Mirror + Stripe

Fast and fault-tolerant.

RAID 10 first mirrors your data (like RAID 1), then stripes it (like RAID 0). So you get the best of both: redundancy and speed.

It needs an even number of disks, minimum 4. If one disk in each mirrored pair fails, you’re still safe. But if both disks in a mirrored pair fail, then 💀.

👩‍💻 Use it for: databases, high-load systems databases, high-load systems

🧩 RAID 01 (0+1) – Stripe + Mirror

Similar to RAID 10, but riskier.

RAID 01 stripes first, then mirrors. So you create one striped set of drives (like RAID 0), and then clone that entire set onto another.

Sounds similar to RAID 10, but it’s more fragile: if one drive in the stripe fails, the whole stripe is lost — meaning one entire half of the mirror is gone. One more failure, and you’re done.

👩‍💻 Use it for: legacy setups (but RAID 10 is usually better) legacy setups (but RAID 10 is usually better)

That’s it for my RAID brain-dump! Hopefully now if someone says "RAID 10 is better than RAID 01" you’ll actually know why 😌📀

🛠️ Weekly Dev Recap – Automation, File Chaos & A Laptop Crying for Help

Sveta.exe — Fri, 16 May 2025 15:39:14 +0000

Heyo 👋 This week was light on work and heavy on chaos, so here’s what I’ve been up to:

🤖 Learning: Automation Testing 101

Since things were quiet on the project side, I focused on learning the tools behind automation testing — and ended up drafting a testing strategy we could actually use in our company.

I was mostly exploring new tools like SonarQube (which I already knew a bit from uni), Azure DevOps, Jenkins, and Applitools. The goal was to understand how they work, how they can fit into our workflow, and where we can start.

Right now, we don’t use any test automation at all, so I tried to come up with a solid starting plan — and my team lead actually approved it! Yay 🎉

📦 Work: Transferring ~20k Server Files (Help.)

So we had to migrate all our server files to a different domain this week. No big deal, just around 20,000 files.
That’s not a typo. Twenty. Thousand.

Let me tell you:
🧠 Me: “This is fine.”
💻 My laptop: wheezes in fan noise
⌛ ETA: “Forever. Maybe longer.”

It eventually finished. I survived. The files (mostly) made it. But for real — next time I’m scripting everything or rage-quitting IT.

🧘‍♀️ Vibe Check

Chill week overall, with a nice balance of ✍️ strategy work and 😵‍💫 minor breakdowns over file transfers.

If you’re also deep in automation or digital janitor mode, I feel you. We’re out here doing our best. See you next week 💅

Why Your App Breaks and Hackers Laugh: A Real Talk on HTTP

Sveta.exe — Fri, 16 May 2025 14:56:39 +0000

I used to think HTTP was just that thing before the 'S' in HTTPS. Then I broke my own login form with a missing header and learned the hard way: if you don’t understand how web requests work, they’ll break your app — or worse, someone else will break it for you. 💀

In this post, we’re not going to just "learn HTTP." We’re going to debug it like pros and understand how attackers abuse it, starting from one basic example.

🌐 Quick Primer: What Even Is HTTP?

HTTP (HyperText Transfer Protocol) is the language your browser and servers use to talk to each other. It’s how you log in, fetch posts, or accidentally leak your session cookie.

Key facts:

It’s stateless — every request is independent
It’s text-based — you can read it, edit it, break it 😈
It works over TCP, usually port 80 (or 443 for HTTPS)

A typical request includes:

a method (GET, POST, etc.)
a path and host
a bunch of headers with meta-info
and sometimes a body (like form data or JSON)

Most devs just let the browser handle this stuff. But if you’re building anything serious (or secure), you need to know what’s inside that HTTP envelope.

🧪 The Setup: A Simple Login Request

Let’s say you’re building a login page and want to send a POST request to your backend:

POST /login HTTP/1.1
Host: vulnerable-login.com
Content-Type: application/json
Content-Length: 55

{ "username": "admin", "password": "hunter2" }

Simple, right? You send credentials, server replies. Let’s debug what can go wrong here.

🧯 Real-World Mistakes from HTTP Misunderstanding

Let’s be honest: modern frameworks and browsers hide a lot of the HTTP complexity. But when you step outside the happy path — like building APIs, using proxies, or dealing with legacy systems — things get messy fast. Here's where real bugs and risks show up:

🐛 Misconfigured APIs

You think you're sending JSON, but the API expects form data. Or vice versa. Boom — silent failure. Always double-check Content-Type and payload format.

🕳️ Leaky Cookies

Cookies set without HttpOnly or Secure can be accessed via JavaScript or sent over plain HTTP. That means:

Anyone injecting a script (e.g. via XSS) can steal sessions
Unencrypted traffic can expose login tokens

💥 Reverse Proxy Shenanigans

Using Nginx or Apache as a reverse proxy? If you forward conflicting headers (Content-Length + Transfer-Encoding), you might open the door to request smuggling — where attackers sneak in requests behind yours.

🧪 Tool Differences: curl vs browser

Your request works in Postman but fails in production? That's because tools behave differently:

Browsers add headers you don’t see (Origin, Referrer, Accept)
curl doesn’t handle cookies unless told to
CORS might silently block requests in-browser

Knowing how HTTP really works = knowing when your tools are lying to you.

🔍 Lesson: HTTP is Not Just Syntax — It’s Behavior

Each line in that request isn’t a formality — it’s part of a contract between client and server. Breaking that contract causes bugs, and sometimes vulnerabilities.

Let’s turn our mistakes into lessons and build apps that don’t fall apart in production or in front of a bug bounty hunter 😌💻

Fixing Secrets, Fighting NGINX & Copying Like a Pro – My Week as a Junior DevOps 🔥

Sveta.exe — Fri, 09 May 2025 09:34:48 +0000

Hi again!
This week at work was... a mix of “why is nothing working” and “wow, I actually fixed that.”

So here’s a small roundup of the chaos, the tools I used, and a neat trick I learned 💻✨

💣 The Service Account That Took 2 Days
I needed to set up a super user on our project server, but of course, the required service account JSON file was... missing.
I waited 2 full days for it to arrive. Classic.
But once I got it, the real fun began...
🔥 NGINX Said No

When I tried to spin up the server config, NGINX threw a fit over port conflicts.
I ended up deep-diving into /var/log/nginx/error.log, checking what was already bound, and why the server was silently failing.
Logs eventually helped, but it was a ✨journey✨.

🔐 Migrating to Infisical v3
We had to move all our secrets to the new version of Infisical. And let me tell you:
Directory structures were wildly inconsistent (esp. env slugs)
Access tokens broke the UI layout
No scroll = no access 🤡

It worked out in the end, but it felt like defusing a bomb with gloves on.

💡 Terminal Trick of the Week:
Needed to copy an access token from file → clipboard quickly.
Found this gem:
cat yourfile.txt | xclip -i -selection clipboard

Paste-ready secret in your clipboard. No more manually highlighting junk in the terminal. 10/10 lifesaver.

✅ What I Learned

Logs are your besties
UI bugs are real and will betray you
A single shell command can make your day better
DevOps is 60% waiting, 30% debugging, 10% copying and pasting things that work

Thanks for reading!
If you’ve ever fought with NGINX or Infisical, I feel you 😭
Let’s suffer and learn together — see you next week!

Hi, I’m Sveta — DevOps Student & Aspiring Engineer 🌍

Sveta.exe — Thu, 08 May 2025 20:43:07 +0000

Hi everyone! 👋

I’m Sveta, a DevOps & networking student currently based in Prague 🇨🇿. Originally from Russia, I’m studying in the Czech Republic and learning everything I can about modern infrastructure, automation, and working in tech.

🛠️ What I’m Learning:

Computer networks & internet technologies
CI/CD, Docker, GitHub Actions
Basics of Linux & scripting
Working part-time in IT to gain real-world experience

🎯 My Goals:

Build a DevOps portfolio with real projects
Move to a country where I can grow, learn, and live fully

💡 What I’ll Be Posting(or try posting):

Simple, real-world DevOps projects
Tips I learn as a student working part-time

- My roadmap toward international studies & relocation

Thanks for reading!
If you're also learning DevOps, preparing to study abroad - let's connect! 💌