Network security protects data traveling across internet connections between Ledger Live and external services. Multiple protocol-level protections ensure safe communication over potentially hostile networks where attackers might attempt interception or modification.
TLS/SSL Protocols
Transport Layer Security provides encryption and authentication for network communications.
Protocol versions:
Ledger Live enforces TLS 1.2 or newer refusing connections using older deprecated protocols. SSLv3, TLS 1.0, and TLS 1.1 contain known vulnerabilities making them unsuitable for secure communications. Protocol version enforcement prevents downgrade attacks attempting to force weaker protocols.
TLS 1.3 offers improved security and performance over TLS 1.2 through streamlined handshakes and removal of vulnerable features. Reduced round trips accelerate connection establishment while eliminating unnecessary cryptographic options simplifies security analysis. TLS 1.3 forward secrecy ensures past communications remain secure even if long-term keys compromise.
Cipher suite selection:
Strong cipher suites combining secure key exchange, encryption, and authentication algorithms ensure comprehensive protection. Ledger Live prefers ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) key exchange providing perfect forward secrecy. AES-GCM encryption provides confidentiality with authenticated encryption detecting modification attempts.
Weak cipher suites face explicit rejection preventing their use even if servers support them. RC4, DES, and export-grade cryptography lack sufficient security for protecting financial data. Cipher suite prioritization ensures strongest available options negotiate during connection establishment.
Connection establishment:
TLS handshake establishes encrypted channels before transmitting sensitive data. Client and server negotiate protocol versions and cipher suites, exchange certificates for authentication, and derive session keys for encryption. Multi-step process ensures both parties agree on security parameters before actual data transmission begins.
Server certificate verification during handshake confirms connection authenticity. Clients verify server certificates chain to trusted root certificate authorities. Invalid certificates, expired certificates, or hostname mismatches trigger connection refusal preventing man-in-the-middle attacks using fraudulent certificates.
Certificate Pinning
Certificate pinning provides additional authentication beyond standard certificate validation.
Public key pinning:
Applications expect specific public keys or certificate authorities for critical connections. Pinned expectations prevent attacks using fraudulent certificates from compromised certificate authorities. Even technically valid certificates not matching pins trigger rejection providing defense-in-depth beyond standard validation.
Pin configuration specifies accepted certificates or public keys for particular domains. Ledger infrastructure certificates or their issuing certificate authorities become pinned expectations. Connections presenting different certificates fail even if otherwise valid according to standard certificate validation rules.
Pin update mechanisms:
Pin updates occur through application updates ensuring current valid certificates remain accepted. Ledger certificate rotation requires corresponding pin updates in application code. Automated pin update through software releases prevents operational disruptions from certificate changes while maintaining security.
Backup pins enable smooth transitions during certificate rotation. Applications include pins for both current and upcoming certificates. This overlap ensures continuous operation during certificate transition periods without security compromises.
Pinning trade-offs:
Pinning provides security benefits but creates operational considerations. Incorrect pins or missed updates can break legitimate connections. Pin management requires coordination between certificate operations and application releases ensuring consistency.
Pinning proves most valuable for critical connections where additional security justifies operational complexity. Blockchain node connections, price data sources, and authentication servers benefit most from pinning protection.
Man-in-the-Middle Prevention
Multiple defenses prevent attackers intercepting and modifying communications.
Certificate chain validation:
Complete certificate chain verification from server certificates to trusted root authorities prevents acceptance of untrusted certificates. Chain validation ensures each certificate in path properly signs next certificate establishing trust path from server to known root authority.
Revocation checking verifies certificates haven't been revoked after issuance. Online Certificate Status Protocol (OCSP) queries check certificate status before accepting connections. Revoked certificates indicate compromise or misuse triggering connection refusal.
Certificate transparency logs provide public records of issued certificates enabling detection of improperly issued certificates. Monitoring transparency logs helps identify fraudulent certificates issued without authorization. This transparency makes certificate misissuance more difficult and detectable.
Hostname verification:
Certificate hostname validation ensures certificates match contacted domains. This prevents using valid certificates for different domains in man-in-the-middle attacks. Hostname mismatches trigger connection rejection preventing attackers using certificates for their own domains to intercept connections to legitimate services.
Subject Alternative Names (SAN) in certificates specify all valid hostnames. Multi-domain certificates list all covered domains in SAN fields. Validation checks ensure contacted hostname appears in certificate SAN or Common Name fields.
Perfect forward secrecy:
Ephemeral key exchange ensures past communications remain secure even if long-term keys compromise. Session keys generated through Diffie-Hellman exchange become immediately discarded after sessions end. Past session key reconstruction proves impossible even with later private key compromise.
This property protects recorded encrypted traffic from retroactive decryption. Attackers recording encrypted communications cannot decrypt them later even if obtaining private keys afterward. Forward secrecy requires both parties' session key agreement without either revealing long-term private keys.
DNS Security
Domain Name System security prevents attackers redirecting connections through DNS manipulation.
DNSSEC validation:
DNS Security Extensions cryptographically sign DNS responses enabling verification. Signed responses prevent attackers inserting fraudulent DNS records redirecting connections to malicious servers. Signature validation ensures DNS responses originated from legitimate authoritative servers.
Chain of trust from root DNS servers through intermediate zones to final responses provides end-to-end authentication. Each zone signs delegations to child zones creating verification path. This hierarchical trust model enables validating complete DNS resolution paths.
DNS-over-HTTPS:
Encrypted DNS queries prevent ISPs or network attackers observing or modifying DNS lookups. Traditional DNS queries travel unencrypted enabling monitoring and manipulation. DNS-over-HTTPS encapsulates queries in HTTPS protecting privacy and integrity.
DoH implementation uses standard HTTPS connections to DNS resolvers supporting encrypted queries. Encryption prevents network-level DNS filtering or modification. Privacy protection prevents observers correlating accessed services through DNS query monitoring.
Resolver selection:
Using trusted DNS resolvers improves security and privacy. Public resolvers from Google (8.8.8.8), Cloudflare (1.1.1.1), or other reputable providers offer better security than ISP defaults potentially implementing logging or filtering. Resolver choice affects both privacy and security.
Resolver validation ensures DNS responses originate from intended resolvers. Response verification prevents attackers substituting responses from different resolvers. This validation works with DNSSEC providing comprehensive DNS security.
For complete network security details, see our comprehensive Ledger Live security encryption and data protection guide.
Top comments (0)