Secure Sockets - SSL/HTTPS
REBOL/Command/SDK Developer Reference
Contents:
1. Overview
2. Supported standards
3. Using HTTPS
4. Using SSL/TLS
5. Limitations
1. Overview
REBOL/Command 2.0 and higher support client-side data encryption across a
TCP channel using the Secure Socket Layer (SSL) and Transport Layer Security
(TLS) standards.
REBOL provides two ways of using this feature: The HTTPS protocol (SSL
for HTTP) exists as a predefined scheme. Other schemes (e.g. SMTP across
SSL/TLS or POP3 across SSL/TLS) can be implemented based on the ssl://
and tls:// schemes, which implement SSL and TLS on top of TCP sockets.
2. Supported standards
REBOL currently supports SSLv2, SSLv3 and TLSv1. The supported encryption
algorithms include DES, 3DES and ARCFOUR, in all strengths defined in the
SSL/TLS standards. Both RSA keys and, for SSLv3 and TLSv1, DSA/DH keys are
supported.
The export version of REBOL only supports standards with are rated as
"export grade". Typically this means that 128-bit encryption is not
supported.
3. Using HTTPS
The https:// protocol can be used in exactly the same way as the http://
protocol. The differences are that HTTPS uses a default port number of
443 (80 for HTTP) and that HTTPS automatically performs SSL negotiation
and thus always sends data in encrypted form, i.e. web servers accessed
through https:// have to be "secure web servers".
REBOL supports automatic HTTP redirects between the http:// and https://
schemes, in both directions. Both SOCKS proxy servers and generic proxy
servers are supported in combination with HTTPS. Using HTTPS with generic
proxy servers is only possible with proxy servers that allow "tunnelling".
4. Using SSL/TLS
The ssl:// and tls:// schemes allow the establishement of connections to
SSL or TLS servers. The format and use of ssl:// and tls:// URLs is identical
to that of tcp:// URLs, i.e.
port: open/direct tls://myhost.example.com:5555
|
connects to the host "myhost.example.com" on port 5555.
The difference between the ssl:// and tls:// schemes is:
- ssl:// only attempts to negotiate the SSLv2 and SSLv3 protocols, not TLSv1.
This is intended for backward compatibility with older HTTPS web servers which
do not support SSL version negotiation correctly and have problems when
contacted by a client that supports TLSv1.
- tls:// attempts to negotiate one of SSLv2, SSLv3 or TLSv1. It is the prefered
choice for SSL/TLS-based connections, except for HTTPS connections.
After opening a port with ssl:// or tls:// the SSL/TLS protocols are NOT negotiated
automatically. Initially the port sets up the physical TCP connection only. In order
to initiate the SSL/TLS negotiation use the following call after opening the port:
set-modes port [secure: true]
|
After this call returns, all subsequent data exchanged through the port is sent
in SSL/TLS-encrypted form. It is possible to switch back to a regular TCP
connections by executing
set-modes port [secure: false]
|
Having control over when SSL/TLS is negotiated allows the implementation of
protocols that do not use SSL/TLS initially after connecting, but only as the
result of subsequent negotiation, e.g. SMTP with SSL/TLS extensions.
5. Limitations
In its current version the REBOL SSL/TLS implementation has the following
limitations. Future versions of REBOL may add support for these features.
- SSL/TLS server mode is not supported.
- Certificate handling is not supported. REBOL does check the validity of
server certificates internally, but no mechanism exists to access the
certificate chain from REBOL scripts, and client certificates cannot be defined.
| | REBOL/MakeDoc 2.0 | REBOL is a registered trademark of REBOL Technologies Copyright 2003 REBOL Technologies | 5-Aug-2003 |
|