Not a redirect — a transparent proxy upgrade

Chapters:

1. The Two Sides of the TLS Translate Bridge 💭

[ Ye Olde Box ]:80 ---> [[ [virtua7]:443 ]] <--> 443:[the Sh1re]:80:[Wiki]

The olde-boxes don't even know they are talking through a translator. They send http like they know how.
The message that knocks on the door of the sh1re is suitably prepared with https"

**virtua7:** “Not a redirect — a transparent reverse-proxy upgrade.”

### Front-end (Legacy)

**Role:** Accepts plain HTTP from *Ye Olde Boxes* that cannot use modern TLS  
**Port:** 80/tcp  
**Protocol:** HTTP/1.0 or 1.1  
**Controlled by:** 🔸 Local Operations (bridge owner)

The legacy client never speaks TLS.  
It connects using plain HTTP, and *virtua7* quietly upgrades the connection on its behalf.

---

### Back-end (Modern)

**Role:** Establishes secure outbound HTTPS (TLS 1.2+) to Sh1re → Wiki  
**Port:** 443/tcp → 8081  
**Protocol:** TLS 1.2 – 1.3 (HTTPS)  
**Controlled by:** 🔸 Network team (firewall / DMZ egress)

The bridge negotiates modern TLS with Sh1re, validates its certificate,
and forwards the legacy HTTP request upstream as a secure HTTPS transaction.

2. “Software Ports” vs “Network Ports”

Ports like 80, 443, and 8443 are **network ports** — they represent sockets on which software listens.
Software such as **NGINX** or **HAProxy** binds to these ports *inside* the bridge’s host or container.

If the bridge runs in a VM or container, ensure internal ports are open:

```bash
sudo firewall-cmd --add-port=80/tcp --permanent
sudo firewall-cmd --add-port=443/tcp --permanent
sudo firewall-cmd --reload

That’s our domain — the software layer IT controls.
Anything crossing subnets (DMZ ↔ internal) typically needs network team approval (firewall zones, ACLs, VLAN rules).

3. Typical Port Flow

[Legacy Client / Ye Olde Box]
     ↓ 80 (plain HTTP)
[TLS Translation Bridge on virtua7]
     ↓ 443 or 8081 (modern TLS 1.2+)
[Sh1re Reverse Proxy → Wiki]

Inbound: accepts plain HTTP from legacy systems (insecure side)
Outbound: upgrades to modern TLS 1.2+ toward Sh1re (secure side)

virtua7 terminates legacy HTTP and originates new HTTPS sessions;
no client-side TLS negotiation occurs.

🧭 4. Who Controls What

Layer	Examples	Who Usually Controls
Application / OS	NGINX listen ports, systemd service, SELinux context, local firewall-cmd	✅ Local Operations
Network Perimeter	VLAN ACLs, firewall between DMZ and internal subnet, NAT rules	🔒 Network Team
Certificate & TLS Policy	Server certificates, ciphers, TLS version restrictions	✅ Local Operations (app config)

Current Reference Host: virtua7 — active, working bridge (source of truth for config & flow validation)

🧭 Baseline System Summary

✅ TL;DR — Port Ownership and Flow

Flow	Port(s)	Purpose	Controlled by
Legacy Client (Ye Olde Box) → Bridge (virtua7)	80/tcp	HTTP only — legacy browser entry	🔸 Network team (enables ingress from legacy subnet)
Bridge (virtua7) → Modern Target (Sh1re → Wiki)	443 → 8081	HTTPS (TLS 1.2+) — secure proxy forwarding	🔸 Shared — Ops requests, Network approves
Local (loopback)	Any	Internal testing / diagnostics	🔸 Operations

🏁 In One Line

[ Ye Olde Box ]:80 ---> [[ [virtua7]:443 ]] <--> 443:[the Sh1re]:80:[Wiki]
Not a redirect — a transparent proxy upgrade.

Or to be just a little more precise...

🟩 **It is *not* a redirect.**
🟥 **It is a reverse proxy.**

---

### 🧠 Here’s the difference:

#### 🔁 Redirect:

* The server **tells the client** to go somewhere else.
* Usually done with a **`302` or `301` HTTP response**.
* The **client’s browser** or HTTP tool changes the URL and re-issues the request.

> Example:
> Client requests `http://virtua7/wiki`,
> Server responds: `302 → Location: https://sh1re/wiki`
> Client then connects directly to `sh1re`.

---

#### 🔁 Reverse Proxy:

* The client **thinks it's talking to `virtua7`**, but `virtua7` secretly **forwards the request to `sh1re`**, gets the response, and passes it back.
* The **client never sees the real backend** — all traffic flows **through** the proxy.

> Example:
> Client requests `http://virtua7/wiki`,
> `virtua7` makes a background request to `https://sh1re/wiki`,
> and returns the response to the client — **as if it came from `virtua7`**.

---

### ✅ So to answer clearly:

**virtua7 is a transparent reverse proxy**,
**NOT a redirect.**

It's the "middleman" between Ye Olde Boxes and the modern Sh1re. The legacy boxes never know or care that there's a newer TLS service behind it.

---

Let me know if you want a Wireshark-style breakdown or logs to show the difference in traffic.

Again, for those of you in the back who may have been drifting off...

A Wireshark-style breakdown of how virtua7 acts as a TLS-downgrading reverse proxy, NOT a redirect.

🧪 Scenario Setup

🖥️ Client (Ye Olde Box) makes an HTTP request → http://virtua7/wiki
🔁 virtua7 listens on HTTP/80 and HTTPS/443
- It accepts legacy clients (e.g., TLS 1.0 or plain HTTP)
- It reverse proxies to the Sh1re at https://sh1re/wiki
🏰 the Sh1re is the real destination (MediaWiki, TLS 1.2+)

📡 Wireshark-style Packet Flow

Step	Device	Protocol	Direction	Description
1️⃣	Client	HTTP	→ `virtua7:80`	`GET /wiki HTTP/1.1` (No TLS)
2️⃣	virtua7			Receives plain HTTP from legacy client
3️⃣	virtua7	HTTPS	→ `sh1re:443`	Forwards request as `GET /wiki` using TLS 1.2
4️⃣	sh1re	HTTPS	← `virtua7`	Responds: `200 OK`
5️⃣	virtua7	HTTP	← to client	Relays `200 OK` with MediaWiki HTML payload
🧼	Client			Thinks all traffic came from `virtua7`

🔍 Key Points in the Trace

What You’d See in Wireshark	Notes
`Frame 1: GET /wiki HTTP/1.1` → `virtua7`	No `Location:` header, so not a redirect
`Frame 2: TCP/TLS Handshake` → `sh1re:443`	Initiated by `virtua7`, not the client
`Frame 3: TLSv1.2 Application Data`	Inside the encrypted session → MediaWiki responds to `virtua7`
`Frame 4: HTTP/1.1 200 OK` ← returned to client	Response relayed by `virtua7`, not directly from `sh1re`

🎯 Summary

✔️ Client only sees:
http://virtua7/wiki → 200 OK

❌ Client does not see:

Any Location: https://... redirect
TLS connection with sh1re
Even know sh1re exists!

✔️ virtua7 does the lifting:

Upgrades insecure HTTP → TLS 1.2
Proxies requests + responses
Keeps the illusion alive

Absolutely — let’s break it down in plain terms and then reinforce it with technical accuracy.

What Does “Transparent Reverse-Proxy Upgrade” Mean?

Reverse Proxy

A reverse proxy is a server (like your virtua7) that receives client requests and forwards them to the real backend server (in your case, the Sh1re). The client only ever communicates with the proxy — it doesn't see the final destination.

Think of it like: a receptionist who takes your message and personally delivers it to the right office — you never talk to the person in the office directly.

TLS Upgrade

Your setup performs a TLS upgrade, also known as TLS bridging or TLS termination and re-initiation:

Incoming: Ye Olde Box speaks plain old HTTP (unencrypted) to port 80.
virtua7: Accepts the HTTP, wraps it in HTTPS, and forwards it to the Sh1re.
The Sh1re: Receives the request as if it had been HTTPS all along.

This is an upgrade from insecure HTTP to secure HTTPS — even though the Ye Olde Box doesn’t support HTTPS itself.

Transparent

It’s transparent because:

To the Ye Olde Box (the client):
It just sends HTTP to what it thinks is a normal server. It’s unaware that anything changed. No redirect, no error, no TLS handshake.
To the Sh1re (the destination server):
It receives a properly formatted HTTPS request. It doesn’t know the original client couldn’t do HTTPS. It thinks the request was always secure.
To the user or system operator:
There’s no browser warning, no redirect to https://, no break in the chain. Everything just works. Securely.

Summary (In One Line)

A transparent reverse-proxy upgrade means the proxy quietly converts insecure HTTP from an old client into HTTPS for a secure backend — without either end knowing or needing to change.

virtua7