CurveCP: Usable security for the Internet
AddressingThis page discusses four advantages of CurveCP over TCP:
Server addressesBefore a client can create a CurveCP connection, it needs to know (1) the server's long-term public key and (2) the server's address. The server's address has four components:
These components are typically used as follows. Packets from the client are forwarded by Internet routers until they reach the gateway computer at this IPv4 address. Normally these routers ignore the UDP port (and extension), except that some firewalls limit the clients that can reach various UDP ports. Within the gateway computer, the operating-system kernel uses the UDP port to route the packet to a CurveCP-aware program. There are two common possibilities at this point:
The server's domain name is sent by the client (encrypted) inside the client's second packet, the Initiate packet. The server drops the Initiate packet if the domain name is wrong (i.e., does not match the server's locally configured domain name). If third parties set up unauthorized domain names that are aliased to the same server then CurveCP connections to those domain names will fail. "Virtual" servers allow several configured domain names and take different actions for different domain names.
Client addressesThe client's packets include (1) the client's short-term public key and (2) the client's address. The client's address has three components:
Current kernels do not contain analogous facilities for extensions. UNIX/Linux clients are encouraged to read 16 bytes (binary) from the file /etc/curvecpextension, and to re-read this file frequently to catch any updates; or to use 16 all-zero bytes if that file doesn't exist.
Backup serversAn Internet server can advertise multiple IP addresses, typically the addresses of two or three servers. If one server crashes then clients can connect to another server.
Unfortunately, a typical client will start by asking TCP to connect only to the first address. If that server is unresponsive, TCP will spend a long time trying many SYN packets to that address before aborting: typically 5 packets over 180 seconds. The client will then ask TCP to connect to the second address, but the user has already given up at this point; the connection is a failure from the user's perspective. Typical TCP implementations don't support a "connect to several addresses" feature.
A CurveCP client tries a Hello packet to the first address, then a Hello packet to the second address, etc. If one of the servers is up then the connection will succeed promptly. This drastically reduces the impact of a single-server outage: the outage typically wastes only 1 packet and only about 1 second with CurveCP, rather than 5 packets and 180 seconds with TCP.
Load-balancing DNS servers reduce the impact of outages in a different way, by quickly removing the advertisements for servers that are down. However, load-balancing DNS does not prevent failures for users who received an advertisement of a server just before that server crashed, while CurveCP does prevent these failures. Note that neither approach prevents failures when a server crashes in the middle of a connection.
Mobile clientsBob has an open SSH connection from his laptop in his hotel room. He closes the laptop, checks out of the hotel, walks down the street to an Internet cafe, opens the laptop, and acquires a new IP address. All his open SSH connections are now unresponsive, because the server is sending responses to the laptop's old IP address. Bob has to close the SSH connections and make new connections.
CurveCP supports mobile clients. If the server sees a new address attached to a verified packet from the client, the server tries sending its response to that address. If the client acknowledges that response from the same new address, the server switches to that address for subsequent packets, smoothly migrating the connection to that address.
The client does not cryptographically authenticate (and in general does not have any secure way to know) its own address. If an eavesdropping attacker takes a packet from the client, forges a new packet with the same contents but the attacker's address, and prevents the original packet from reaching the server (for example, by flooding the network), then the server will try sending its response to the attacker's address. If the attacker then forwards that response to the client and similarly modifies the address on the client's acknowledgment, then the server will send subsequent packets to the attacker's address. However, the client will continue sending packets from its original address, and the only way for the attacker to continue misdirecting the server's packets is to continue blocking the client's packets. An attacker with this much power can successfully deny service, but could also have denied service without any mobility features. Note that the attacker still cannot compromise the confidentiality and integrity of the connection.
VersionThis is version 2011.02.09 of the addressing.html web page.