an invention by thardeck
I have Raspberry Pi with WLAN and an additional network module which can be run as a WIFI access point.
Plan
- Analyze the security of HTTPS connections of common Linux applications I use besides webbrowsers. For example check if they verify the SSL certificates, prevent downgrade attacks and so on.
- Analyze the traffic of my smartphone. For example check if apps use SSL connections, if they verify certificates or pin their own ones.
- Analyze the traffic of "smart" devices like Smart TVs and WLAN speakers.
Current Results
Linux applications
All linux utils I have tested where verifying the CA properly and not accepting the man in the middle certificate, which is great.
I have tested: curl, wget, osc, zypper, rpm, git, bundle install, go get
If you know other relevant tools let me know.
Smartphone applications
At least on iOS there does not seem to be any app which does not verify the certificate which is great but expected.
Most do not seem to use Certificate pinning so I was able to watch most of their SSL traffic. It is interesting how many tracker are contacted from a regular app (even the ones with paid services).
The only exception I have found so far which used certificate pinning is Threema and also does not contact any trackers.
It is a little frighting how many different tracking sites are used by just one app. Some apps have a hidden button somewhere to disable tracking but usually there is not much someone can do.
Most also have a static ID or cookie id which can only be renewed by reinstalling the app.
The good news is that at least on iOS all the apps I have checked use exclusively encrypted connections and verify the certificate properly.
Apple seems to use an unknown binary format to transfer data and some connections like one to the iTunes server are not possible to intercept because of certificate pinning. This is something which needs more time to check out I suppose.
I have not intercepted an Android phone yet but I guess the SSL verification will be similar good, at least on the newer models. The question is if they enforce similar policies to encrypt as Apple does for the app developers.
Smart devices
PS4
The traffic is mostly encrypted and the certificate verified properly.
There are some HTTP connection though like for checking for new PS4 updates. But I am pretty sure that they verify the update files before installing them so it should be not an issue.
Additionally some "sticker" urls are provided unencrypted as json.
Smart TV
A LG Smart TV from 2016 does verify all HTTPs connections. HTTP was nearly not use except of for the Netflix app, but the master token seemed to be signed and it also tried to connect to an HTTPs Netflix server so I suppose it should be no problem.
The TV does also connect to an LG ad server but I could not intercept the traffic because it was also encrypted.
WLAN Speaker
The WLAN speakers are the first device which do not verify all HTTPs requests. Some https connections can be intercepted, others not. I will contact the support regarding this issue.
They also request the time via HTTP, which is interesting since there is Linux running on them and they could use NTP.
The also transfer a device ID and the services you have activated. These are transferred through an HTTPs connection but the certificate is not verified.
I have tried to understand the workings of Spotify Connect in detail but they do not seem to use HTTP[s] connections for streaming. Spotify also initiates one HTTP connection in the beginning but it is called esdk-fire-and-forget and there is no response which does make sense from the url name. I have to follow up on Spotify Connect with Wireshark.
In general the speakers have the issue that during the first setup through Wifi they transfer the WPA password in clear text through the air because they do not support WPS.
Wifi Printer from 2005
This was a pleasant surprise that the HP printer (which besides the age supports WPA2) did not connect to any Internet server at all. It did just send SSDP announcements to multicast ip ranges and that was it.
There is an HP Instant Share option in the menu but it seems it needed to be installed separately.
Sadly I could not check it with a more recent HP model but I am pretty sure they are much more talkative. At least I had to disable quite some online services in an HP Envy printer I have setup and I am pretty sure there is more.
The HP app for example does have quite some data sharing options enabled by default and even if you disable them it connects to facebook although this might be just related to some Facebook functionality in the app.
Looking for hackers with the skills:
This project is part of:
Hack Week 15
Activity
Comments
Be the first to comment!
Similar Projects
Help Create A Chat Control Resistant Turnkey Chatmail/Deltachat Relay Stack - Rootless Podman Compose, OpenSUSE BCI, Hardened, & SELinux by 3nd5h1771fy
Description
The Mission: Decentralized & Sovereign Messaging
FYI: If you have never heard of "Chatmail", you can visit their site here, but simply put it can be thought of as the underlying protocol/platform decentralized messengers like DeltaChat use for their communications. Do not confuse it with the honeypot looking non-opensource paid for prodect with better seo that directs you to chatmailsecure(dot)com
In an era of increasing centralized surveillance by unaccountable bad actors (aka BigTech), "Chat Control," and the erosion of digital privacy, the need for sovereign communication infrastructure is critical. Chatmail is a pioneering initiative that bridges the gap between classic email and modern instant messaging, offering metadata-minimized, end-to-end encrypted (E2EE) communication that is interoperable and open.
However, unless you are a seasoned sysadmin, the current recommended deployment method of a Chatmail relay is rigid, fragile, difficult to properly secure, and effectively takes over the entire host the "relay" is deployed on.
Why This Matters
A simple, host agnostic, reproducible deployment lowers the entry cost for anyone wanting to run a privacy‑preserving, decentralized messaging relay. In an era of perpetually resurrected chat‑control legislation threats, EU digital‑sovereignty drives, and many dangers of using big‑tech messaging platforms (Apple iMessage, WhatsApp, FB Messenger, Instagram, SMS, Google Messages, etc...) for any type of communication, providing an easy‑to‑use alternative empowers:
- Censorship resistance - No single entity controls the relay; operators can spin up new nodes quickly.
- Surveillance mitigation - End‑to‑end OpenPGP encryption ensures relay operators never see plaintext.
- Digital sovereignty - Communities can host their own infrastructure under local jurisdiction, aligning with national data‑policy goals.
By turning the Chatmail relay into a plug‑and‑play container stack, we enable broader adoption, foster a resilient messaging fabric, and give developers, activists, and hobbyists a concrete tool to defend privacy online.
Goals
As I indicated earlier, this project aims to drastically simplify the deployment of Chatmail relay. By converting this architecture into a portable, containerized stack using Podman and OpenSUSE base container images, we can allow anyone to deploy their own censorship-resistant, privacy-preserving communications node in minutes.
Our goal for Hack Week: package every component into containers built on openSUSE/MicroOS base images, initially orchestrated with a single container-compose.yml (podman-compose compatible). The stack will:
- Run on any host that supports Podman (including optimizations and enhancements for SELinux‑enabled systems).
- Allow network decoupling by refactoring configurations to move from file-system constrained Unix sockets to internal TCP networking, allowing containers achieve stricter isolation.
- Utilize Enhanced Security with SELinux by using purpose built utilities such as udica we can quickly generate custom SELinux policies for the container stack, ensuring strict confinement superior to standard/typical Docker deployments.
- Allow the use of bind or remote mounted volumes for shared data (
/var/vmail, DKIM keys, TLS certs, etc.). - Replace the local DNS server requirement with a remote DNS‑provider API for DKIM/TXT record publishing.
By delivering a turnkey, host agnostic, reproducible deployment, we lower the barrier for individuals and small communities to launch their own chatmail relays, fostering a decentralized, censorship‑resistant messaging ecosystem that can serve DeltaChat users and/or future services adopting this protocol
Resources
- The links included above
- https://chatmail.at/doc/relay/
- https://delta.chat/en/help
- Project repo -> https://codeberg.org/EndShittification/containerized-chatmail-relay
OSHW USB token for Passkeys (FIDO2, U2F, WebAuthn) and PGP by duwe
Description
The idea to carry your precious key material along in a specially secured hardware item is almost as old as public keys themselves, starting with the OpenPGP card. Nowadays, an USB plug or NFC are the hardware interfaces of choice, and password-less log-ins are fortunately becoming more popular and standardised.
Meanwhile there are a few products available in that field, for example
yubikey - the "market leader", who continues to sell off buggy, allegedly unfixable firmware ROMs from old stock. Needless to say, it's all but open source, so assume backdoors.
nitrokey - the "start" variant is open source, but the hardware was found to leak its flash ROM content via the SWD debugging interface (even when the flash is read protected !) Compute power is barely enough for Curve25519, Flash memory leaves room for only 3 keys.
solokey(2) - quite neat hardware, with a secure enclave called "TrustZone-M". Unfortunately, the OSS firmware development is stuck in a rusty dead end and cannot use it. Besides, NXP's support for open source toolchains for its devboards is extremely limited.
I plan to base this project on the not-so-tiny USB stack, which is extremely easy to retarget, and to rewrite / refactor the crypto protocols to use the keys only via handles, so the actual key material can be stored securely. Best OSS support seems to be for STM32-based products.
Goals
Create a proof-of-concept item that can provide a second factor for logins and/or decrypt a PGP mail with your private key without disclosing the key itself. Implement or at least show a migration path to store the private key in a location with elevated hardware security.
Resources
STM32 Nucleo, blackmagic probe, tropicsquare tropic01, arm-none cross toolchain
Exploring Rust's potential: from basics to security by sferracci
Description
This project aims to conduct a focused investigation and practical application of the Rust programming language, with a specific emphasis on its security model. A key component will be identifying and understanding the most common vulnerabilities that can be found in Rust code.
Goals
Achieve a beginner/intermediate level of proficiency in writing Rust code. This will be measured by trying to solve LeetCode problems focusing on common data structures and algorithms. Study Rust vulnerabilities and learning best practices to avoid them.
Resources
Rust book: https://doc.rust-lang.org/book/
Looking at Rust if it could be an interesting programming language by jsmeix
Get some basic understanding of Rust security related features from a general point of view.
This Hack Week project is not to learn Rust to become a Rust programmer. This might happen later but it is not the goal of this Hack Week project.
The goal of this Hack Week project is to evaluate if Rust could be an interesting programming language.
An interesting programming language must make it easier to write code that is correct and stays correct when over time others maintain and enhance it than the opposite.
vex8s-controller: a kubernetes controller to automatically generate VEX documents of your running workloads by agreggi
Description
vex8s-controller is an add-on for SBOMscanner project.
Its purpose is to automatically generate VEX documents based on the workloads running in a kubernetes cluster. It integrates directly with SBOMscanner by monitoring VulnerabilityReports created for container images and producing corresponding VEX documents that reflect each workload’s SecurityContext.
Here's the workflow explained:
- sbomscanner scans for images in registry
- generates a
VulnerabilityReportwith the image CVEs - vex8s-controller triggers when a workload is scheduled on the cluster and generates a VEX document based on the workload
SecurityContextconfiguration - the VEX document is provided by vex8s-controller using a VEX Hub repository
- sbomscanner configure the VEXHub CRD to point to the internal vex8s-controller VEX Hub repository
Goals
The objective is to build a kubernetes controller that uses the vex8s mitigation rules engine to generate VEX documents and serve them through an internal VEX Hub repository within the cluster.
SBOMscanner can then be configured to consume VEX data directly from this in-cluster repository managed by vex8s-controller.
Resources