Fix: corretti percorsi base per GitHub Pages

Author: EdoBll

src/content/blog/MITM_part3.mdx

@@ -6,12 +6,13 @@ heroImage: '../../assets/MITM_3.jpg'
 ---
 import { Image } from 'astro:assets';
 import mitmDiagram from '../../assets/MITM_final.png';
+import burpca from '../../assets/BurpCA,jpg';
 import Note from '../../components/Note.astro';
 
 <p>
 In the first two parts of the series, a Raspberry Pi was configured as a robust network monitoring station.<br />
-<a href="https://edobll.github.io/Personal-Blog/blog/mitm_part1/"> <i>**Part 1**</i></a>, established routing and monitoring on the Ethernet interface. 
-<a href="https://edobll.github.io/Personal-Blog/blog/mitm_part2/"> <i>**Part 2**</i></a>, introduced a dedicated Wi‑Fi Access Point, enabling IoT devices to connect and be monitored without cables.<br />
+<a href="https://edobll.github.io/Personal-Blog/blog/mitm_part1/"> **Part 1**</a>, established routing and monitoring on the Ethernet interface. 
+<a href="https://edobll.github.io/Personal-Blog/blog/mitm_part2/"> **Part 2**</a>, introduced a dedicated Wi‑Fi Access Point, enabling IoT devices to connect and be monitored without cables.<br />
 However, observing raw packet flows with `tcpdump` or `Wireshark` encounters a fundamental limitation: encryption. In contemporary networks, the majority of traffic is carried over HTTPS, which obscures application‑layer behavior and hinders interpretation of device activity.<br />
 To enable interception and interaction with HTTP/S requests, two proxy approaches are available: an <i>explicit proxy</i> and a <i>transparent proxy</i>. The explicit proxy is the simpler and more robust option, as it avoids routing complications and preserves TLS handling. However, it requires clients to be proxy‑aware, a condition commonly met by PCs and smartphones but often absent in many IoT devices.<br />
 In this article, for broader coverage and compatibility with different target devices, a **transparent proxy** will be implemented on the same network as wlan0. This configuration intercepts all HTTP traffic (port 80) associated with the wlan1 and eth0 interfaces and forwards it to **Burp Suite** for inspection and manipulation. Decrypting HTTPS traffic requires an additional step: generating <i>Burp’s Certificate Authority (CA)</i> and installing it on the test clients, since clients will otherwise reject the MITM connection as untrusted.<br />
@@ -125,7 +126,7 @@ As with previous steps, these modifications are persistent and will be automatic
 To complete the MITM chain, the Raspberry Pi must be configured to recognize Burp Suite as a trusted Certificate Authority (CA). Without this trust relationship, the system-level utilities and IoT applications running on the Pi will terminate encrypted connections when they detect the spoofed certificates generated by the proxy.<br />
 The first step involves obtaining the CA certificate from the host machine where Burp Suite is running: <br />
 <i>Burp Suite -> Proxy -> Proxy Settings -> Proxy listeners -> Import / export CA certificate -> Certificate in DER format</i>
-<Image src={mitmDiagram} alt="BURPCA" />
+<Image src={burpca} alt="BURPCA" />
 <br />
 
 **3.3 - Transferring and Converting the Certificate**<br />