Connection establishment

Immediately after establishing the TCP connection, the initiating side enables TLS. A TLSv1 client handshake MUST be sent. Backward compatibility to clients sending SSLv2 client hellos is only permitted on connections to leaves, however SSLv2 MUST NOT be negotiated. The initiating entity should use the TLS server name indication specified in RFC 4366. This may even be done on the default PSYC port, as the receiving side can use the following heuristic to determine if the initiating side is using TLS: The incoming connection is considered to be TLS if the first received byte is 0x16.

After the handshake the initiator and the recipient MUST also check the TLS certificates. If they are not valid and trusted, either side MAY break the connection. In case of an untrusted certificate, the certificate SHOULD be logged and the administrator SHOULD be notified of the failed communication attempt. See RFC 6125 for BCP regarding this check.

Note: the usage of a TLS-DHE ciphersuite with ephemeral Diffie-Hellman parameters is recommended.

Requesting a circuit feature

Same as TCP, client should not offer the _compression module, as this is handled by TLS already.

Recipient handling of a feature request

Same as TCP, server should ignore the _compression module if offered by the client.

Sender address verification

Sender address verification relies on X.509. The sender may use any host names contained in the subjectAltName/dNSName extension. The same applies for the receiving side. Use of a host name not listed MUST lead to an immediate termination of the circuit. DNS and its associated verification methods MUST NOT be used.