Detecting LDAP Reconnaissance
School of PhishWeb dashboard for analyzing potential phishing links
This is a way to transfer your files directly from one device to another. To establish a connection to each other, you and the recipient exchange a set of generated "codes." After that, you can send the recipient as many files as you want (until you close the connection). Also note that there's a timeout while connecting, so type fast!
In peer-to-peer file transfer, your data gets sent directly to the recipient and doesn't have to travel through an intermediary server, so it's faster and more private. You also don't have to worry about the file size limits that exist in emails or texts.
This implementation uses WebRTC to establish a connection between browsers and is (almost) completely serverless. In order for peers to discover each other, a STUN (Session Traversal Utilities for NAT) server must be used. This server helps to find a network path between the two peers as a part of the ICE (Interactive Connectivity Establishment) protocol. The peer initiating the connection generates an SDP (Session Description Protocol) offer, which must be sent to the other peer. After the recipient receives the first peer's offer, they generate a SDP answer, which must be sent back to the first peer. After both peers complete the handshake, the connection can be established and data can start passing directly between them. Normally, a signaling server is used to send the initial handshake. However, I wanted to rely on as little external servers as possible (without hosting my own instance), so I decided to let the users send this data directly to each other. To make this feasible, the handshake had to be heavily compressed. The "code" generated is actually a key linked to encoded JSON handshake data. Please note, if the initial ICE connection fails, it's most likely an issue with a firewall or symmetrical NAT, so sending data directly between the two peers isn't possible.