REBOL
Downloads Products Documents Community

Secure Sockets - SSL/HTTPS

SDK Documentation

2010 Update

This feature is now available in REBOL/View as of 2.7.7.

Contents

Overview
Supported standards
Using HTTPS
Using SSL/TLS
Limitations

Overview

Several REBOL products 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.

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.

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".

Example of reading text data:

data: read https://www.example.com

or for reading binary data:

data: read/binary https://www.example.com

HTTPS may not be initialized on all versions of REBOL/Command. To check for HTTPS and add it as a protocol (if it is not installed), insert these lines into your code:

if not find first system/schemes 'https [
    net-utils/net-install HTTPS make system/schemes/http/handler [] 443
]

The 443 is the default TCP port used for HTTPS. If your server uses a different port, change the 443 to the required value.

In addition, we suggest that you also set the HTTP user-agent field as it may be required within client or server code. The example below adds the standard REBOL user-agent field to the HTTPS protocol scheme, but you can use a Mozilla or IE signature as needed.

system/schemes/https: make system/schemes/https [
    user-agent: reform ["REBOL/Command" system/version]
]

Note that the HTTPS scheme object is cloned here to add the user-agent field.

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".

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.

Limitations

In its current version the REBOL SSL/TLS implementation has the following limitations. Future versions of REBOL may add support for these features.

About | Contact | Support | Privacy | LicenseREBOL Technologies 2016