From reSIProcate
Revision as of 14:07, 14 June 2005 by Mahoney (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Supports SSL v23 and TLS v1.

The default ciphersuite is export-restriction friendly. TODO: confirm with Rohan.

     AES256-SHA              SSLv3 Kx=RSA       Au=RSA  Enc=AES(256)  Mac=SHA1
     AES128-SHA              SSLv3 Kx=RSA       Au=RSA  Enc=AES(128)  Mac=SHA1
     DHE-DSS-AES256-SHA      SSLv3 Kx=DH        Au=DSS  Enc=AES(256)  Mac=SHA1
     DHE-DSS-AES128-SHA      SSLv3 Kx=DH        Au=DSS  Enc=AES(128)  Mac=SHA1
     DES-CBC3-SHA            SSLv3 Kx=RSA       Au=RSA  Enc=3DES(168) Mac=SHA1
     EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH        Au=DSS  Enc=3DES(168) Mac=SHA1

When validating a peer name, we can accept both subjectAltNames (preferred) and cnames (we can accept standard wildcards, TODO: need to confirm)

Domain names are compared using cname validation policy as specified in SSL and TLS: Designing and Building Secure Systems (Rescorla).

As a server, when you add the TLS transport, you give it a domain. There must be a domain cert and domain key in the security object for that domain. These can be stored in the file system or installed into the OS-specific cert management system.

You can set the passphrase on the security object using a callback.

If connect as a client, you will always validate the cert. If you provide a domain name, you'll require a cert from the peer.

When you connect with a TLS connection with a domain, mutual authentication is supported if the remote party asks for the cert.