Overview

LocalSend’s native HTTPS uses self-signed device certificates, mutual TLS, and discovery fingerprints instead of public names. The client pins the expected server certificate during the TLS handshake, before metadata or file bytes are sent, while the server binds the registering client’s claimed fingerprint to its certificate. The guarantee begins after trust on first use; browser links may use HTTP and optional client authentication, so PINs and checksums do not restore native HTTPS assurances.

Learning outcomes

Native HTTPS validates a discovered certificate fingerprint during the handshake, before the client writes request metadata or file bytes.
Mutual TLS binds each peer’s claimed fingerprint to the certificate presented in the connection.
Trust on first use limits the initial guarantee, and browser links may use HTTP without the native client-certificate model.

Keywords

LocalSendHTTPSCertificatesFingerprintPinningBrowser

What LocalSend's HTTPS Security Actually Proves

LocalSend's HTTPS mode is not simply a switch that wraps a familiar HTTP transfer in encryption. It is a local identity system built from self-signed device certificates, mutual authentication, and fingerprints learned during discovery. This chapter explains what those mechanisms establish before metadata or file bytes are sent, where the first-contact exception remains, and why browser link sharing must be judged as a different security mode. The goal is a precise answer to “is this transfer secure?” rather than a single yes-or-no label.

Native HTTPS replaces public names with device identity

On the public internet, a browser commonly verifies a server certificate through a chain of public certificate authorities and checks that the certificate names the host being visited. LocalSend peers are usually addressed by local IP addresses, and their certificates are generated on the devices themselves. There is no practical public authority that could pre-issue a certificate for every laptop, phone, or temporary LAN address. LocalSend therefore uses a different identity rule.

A device generates a self-signed certificate and uses the uppercase hexadecimal SHA-256 hash of the certificate's DER representation as its fingerprint. The current Rust implementation generates an RSA-2048 key pair and certificate for the device's security context. The certificate's common name is not the user-facing identity; peers identify one another by the fingerprint. This is why a certificate can remain useful even though it does not have a hostname that matches an IP address.

The fingerprint connects discovery to transport. A multicast announcement carries the device's claimed fingerprint. When a discovering device responds over HTTPS, it can use that value as the expected fingerprint for the server certificate. The client verifier first checks that the certificate is structurally and cryptographically valid, then compares its calculated fingerprint with the expected value. A certificate signed by itself is not enough; it must be the certificate associated with the peer that discovery described.

LocalSend also uses mutual TLS for native peer communication. The client presents its own certificate to the server, and the server validates the presented certificate. The server then compares the fingerprint claimed in the registration payload with the fingerprint calculated from the certificate used in the TLS handshake. If the two disagree, the server does not emit a registration event for that peer. A remote device cannot simply put a trusted-looking fingerprint in JSON while presenting a different certificate.

This two-sided check gives the protocol a useful property: both parties can bind application-level information to a cryptographic connection. The sender can verify the server it intended to reach, and the receiver can verify that the registering client controls the certificate whose identity it claimed. The certificate is not trusted because a global authority endorses it; it is trusted because the LocalSend relationship associates its fingerprint with the discovered device and then enforces that association during the connection.

Self-signing does not mean that every certificate is accepted without inspection. The implementation still validates the certificate's signature and time validity, and it can compare the public key or fingerprint where the protocol requires it. What the system omits is the public-web assumption that a certificate's authority and hostname are enough to identify the peer.

Published by DeepMox

FAQ

How does LocalSend pin a self-signed certificate?

LocalSend uses the fingerprint announced during discovery as the expected server certificate, then compares it during the TLS handshake before sending HTTP data. A self-signed certificate must still pass the required validity checks.

What is LocalSend trust on first use?

LocalSend uses trust on first use because the client does not know a peer’s fingerprint before initial discovery and registration. It learns a valid certificate identity, then pins it for later connections, so first contact is not a complete defense against an active attacker.

Why are LocalSend browser links different from native HTTPS?

LocalSend browser links are different because browsers reject its self-signed certificates, so the web path may use unencrypted HTTP and optional client authentication. A PIN can gate access but cannot make that path equivalent to native HTTPS.

Previous8 minLocalSend Transfer Sessions

Next9 minLocalSend Flutter–Rust Architecture

LocalSend HTTPS Security

What LocalSend's HTTPS Security Actually Proves

Native HTTPS replaces public names with device identity

FAQ