psyced allows you to provide additional ports for TLS for most protocols. Recent psyclpc also supports automatic TLS detection, so you can use the access ports of several protocols with or without TLS enabled from the start.
In the case of XMPP, STARTTLS is also supported by negotiation according to SASL. PSYC does not use STARTTLS, as we are in the lucky position of not having to be backward compatible to anyone. STARTTLS makes sense in SMTP where you have a large installation base and TLS is considered a goodie.
In PSYC, we don't want to automatically fall back to plain text if an encrypted channel could not be established. With PSYC we prefer reducing latency: Avoiding a negotiation procedure makes first messages get through quicker.
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.
Sometimes several host names need to go into the same certificate. http://wiki.cacert.org/wiki/VhostTaskForce helps you figure out how to do that.
from jabberds jadc2s:
used heuristic: - an incoming connection using SSLv3/TLSv1 records should start with 0x16 - an incoming connection using SSLv2 records should start with the record size and as the first record should not be very big we can expect 0x80 or 0x00 (the MSB is a flag) - unencrypted sessions should start with '<' but everything else is considered to be unencrypted
Configuration in psyced
This is a quick reference to creating a not necessarily secure certificate for testing TLS in your psyced install.
If you accepted installation defaults for TLS then you'll have a section in your psyced.ini that looks like this:
; Path leading to your private and public TLS keys ; (absolute or relative to the base) _path_PEM_key = key.pem _path_PEM_certificate = cert.pem
Run these commands to generate a quick and dirty self-signed certificate that does not require you to enter the pass phrase at start up:
openssl genrsa -des3 -out server.key 4096 openssl req -new -key server.key -out server.csr openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt openssl rsa -in server.key -out server.key.insecure mv server.key server.key.secure mv server.key.insecure server.key ln -s server.crt cert.pem ln -s server.key key.pem
Recently, we adapted a nice Makefile which generates certificates for you. It is taken from the prosody.im xmpp server. It resides in utility/gencert. See the Makefile for usage instructions. Beware that you need to remove the keyUsage line in the config file.