Secure Sockets Layer (SSL) Protocol
1.0 Introduction
What is SSL?
SSL is the ubiquitous security protocol used in almost 100% of secure Internet transactions. Essentially,
SSL transforms a typical reliable transport protocol (such as TCP) into a secure communications channel
suitable for conducting sensitive transactions.
i
The SSL protocol defines the methods by which a secure
communications channel can be established—it does not indicate which cryptographic algorithms need to
be used. SSL supports many different algorithms, and serves as a framework whereby cryptography can be
used in a convenient and distributed manner.
Uses for SSL
The uses for SSL are endless. Any application that needs to transmit data over an unsecured network such
as the Internet or a company intranet is a potential candidate for SSL. SSL provides security, and more
importantly, peace of mind. When using SSL, you can be fairly sure that your data are safe from eaves-
droppers and tampering.
SSL is relatively new to the embedded world because it has been too complex for traditional embedded-
systems microprocessors to handle. However, starting with Rev. A of the Rabbit 3000 microprocessor,
hardware assistance has been added to speed up some of the more complex SSL cryptography operations,
making SSL a viable solution in a market where standard (usually complex) security protocols have not
traditionally been supported. The applications for embedded applications are as numerous as those for the
PC world. The following are just a few potential applications for embedded SSL.
•
The Internet-enabled vending machine can now become a reality—SSL makes tampering with commu-
nications almost impossible.
•
Home automation systems can be Internet-enabled—forgot to turn off the oven? Just log into your
house from your computer at work and turn it off. SSL provides a secure means of protecting your
home from hackers.
•
Readings from medical devices can be sent over a standard network—SSL protects your privacy.
•
Make a telephone switch Web-configurable—SSL encrypts all data, so no one monitoring the network
can read your information. Since Web-based access means that your data will likely be travelling over a
competitor’s network, SSL makes a lot of sense.
•
Remote-entry configuration—change the passcode on all the doors of a building simultaneously. SSL
protects the passcode, allowing the doors to be connected to a standard corporate network, no need for
expensive proprietary hardware!
i. At the time of this writing, HTTP file upload over an SSL-secured channel is not supported.
020-0054 Rev. D
www.rabbit.com
1
•
Television cable box monitoring/billing—connect a cable box to the Internet to monitor use and provide
online billing.
•
Utilities monitoring/billing (gas, electric, water)—connect gas and electric meters to the Internet with-
out the worry of users tampering with the information sent.
SSL is designed to run over TCP/IP.
Figure 1
shows how the SSL protocol fits into the overall TCP/IP ref-
erence model.
Figure 1. How SSL Fits Into the 5-Layer TCP/IP Reference Model
HTTPS
Application Layer
SSL
Transport Layer
TCP
IP
Network Layer
ETHERNET
Data-Link Layer
NETWORK HARDWARE
Physical Layer
What can SSL do for my application?
SSL protects the communications channel. It also provides authentication (on the client side, optionally on
the server side) of communicating parties. SSL can secure any connection between two points, and no one
monitoring the connection can do anything destructive or gain unauthorized access to any sensitive infor-
mation. SSL provides a secure channel without the need for either end to meet to exchange keys. SSL is to
secure communications as TCP is to normal communications—it provides a standard communications
infrastructure that compliant applications can use easily and nearly invisibly.
SSL provides a vitally important component of any secure system. Basic authentication mechanisms such
as the Telnet password and basic HTTP authentication become very powerful security options when exe-
cuted using SSL instead of plain TCP—passwords are no longer sent plain-text, making these methods
much more useful. SSL encrypts the
connection,
not the data at either end, and does not contain any mech-
anism for user authentication or password protection (only the connection is authenticated—the security
fails if the machine at either end is compromised).
2
www.rabbit.com
SSL
1.1 Document Overview
This document is arranged to help you start developing applications with SSL right away. It also provides
more detailed information for interested advanced users. First,
Section 2.0
describes the hardware and soft-
ware requirements for developing with SSL.
Section 3.0
gives a brief history of SSL for context, and
Section 4.0
is a complete start-to-finish walkthrough that details the creation of an SSL certificate and set-
ting up a sample SSL application using HTTPS. A list of sample applications is given in
Section 5.0.
More advanced users with an interest in SSL can continue with
Section 6.0,
which covers the basics of the
SSL protocol, and
Section 7.0,
which covers some specific Rabbit SSL details.
Section 8.0
is a detailed
reference for the SSL certificate utility that covers the advanced interface in detail (the wizard interface is
covered in the walkthrough).
The appendices are primarily for reference. Appendix A introduces cryptography and some of the princi-
ples behind the design of SSL. Appendix B gives an in-depth explanation of SSL digital certificates, which
will help advanced users with certificate management and use. Appendix C is an API reference for the new
HTTPS socket wrapper functions, which are provided for direct socket access (for CGI) in SSL/HTTPS
applications.
2.0 Hardware and Software Requirements
2.1 Rabbit SSL Requirements and Performance Characteristics
The following minimum requirements must be met to run SSL on a Rabbit microprocessor.
•
•
•
•
•
•
Rev. A or later of the Rabbit 3000 microprocessor
Dynamic C v. 8.30 or better (to support Rev. A of the Rabbit 3000)
Minimum 256KB flash (512KB recommended)
Minimum 256KB RAM (512 KB recommended)
Network connectivity with TCP/IP
Single thread only with 2–4KB stack in µC/OS applications (some SSL functions are not re-entrant)
The Rabbit SSL implementation is about 45KB of code, not including the TCP/IP stack (the size varies,
depending on the options enabled). It uses 2–3KB of root memory and about 24KB of xmem for each con-
nection (one connection is usually enough). SSL uses at most 1KB of stack space, so any application run-
ning SSL should use a minimum 2KB stack.
The SSL performance is quite high with a Rabbit microprocessor, reaching a throughput of 120 kbits/s on
average on a Rabbit 3000 (Rev. A) running at 44 MHz (be aware that SSL imposes a large overhead to all
communications). Session establishment—the longest operation of any SSL connection—with the Rabbit
3000 hardware assist takes about 3 seconds, which is quite fast, considering many PC-based implementa-
tions can take almost as long for the same operation.
SSL
www.rabbit.com
3
2.2 Implementation with Dynamic C
One of the primary uses of SSL on the Rabbit is to secure HTTP communications by providing an HTTPS
server implementation to communicate with standard Web browsers. Dynamic C’s implementation of SSL
should work with any browser that supports SSLv3. Browsers earlier than Internet Explorer version 4 and
Netscape version 5 are not officially supported, but may work with the Rabbit SSL implementation. TLS is
only supported on newer browsers—starting with Internet Explorer version 5 and Netscape Communicator
version 6. Officially, Dynamic C’s implementation of SSL is supported only on browsers newer than Inter-
net Explorer version 5 and Netscape Communicator version 6.
3.0 History of SSL and TLS
The original Secure Sockets Layer (SSL) implementation was developed in the early 1990s by the
Netscape Communications Corporation to secure HTTP, which sends its data as plain text over the Inter-
net. The first official release was version 2.0, which gained widespread acceptance despite some design
problems with the protocol.
In the late 1990s it became apparent that SSL 2.0 was not secure. Netscape began working on SSL 3.0. In
conjunction with Netscape, the Internet Engineering Task Force (IETF, the Internet standards governing
body) began work on standardizing SSL, a project that became known as TLS (Transport Layer Security).
SSL 3.0 was not developed as rigorously as TLS, so it became available sooner and quickly overtook SSL
2.0 as the industry standard.
TLS was finalized in 2000, providing the first standardized protocol for SSL. Although SSL 3.0 is still in
widespread use, it is mostly obsolete for new development since almost all modern browsers support TLS.
4.0 SSL Walkthrough
This walkthrough explains the setup and execution of a simple HTTPS server on a Rabbit-based device.
There are six steps, which are listed here.
1. Create a digital certificate.
2. Import the certificate.
3. Set up TCP/IP for the sample application.
4. Set up the application to use SSL.
5. Set up the Web browser.
6. Run the application.
4.1 Create a Digital Certificate
The first step in setting up an SSL-enabled server is to create your SSL server certificate. This can be done
using the Rabbit SSL certificate utility, which is included in your SSL installation. The utility can be found
in the
Utilities\SSL_Utilities
directory under the root Dynamic C installation directory. Start
the SSL certificate utility by double-clicking
certificate.exe.
This walkthrough shows you how to
create your own Certificate Authority (CA) and its accompanying root CA certificate,
i
and how to create a
server certificate signed by that root CA. This is only one of the three types of certificates that can be cre-
ated using the certificate utility; see
Appendix B. “SSL Certificates,”
for more information on certificates.
4
www.rabbit.com
SSL
This walkthrough uses the certificate utility wizard interface. See
Section 8.3
for further information about
the advanced interface.
1. Start the wizard and set the output directory.
The utility should start in the wizard mode. This is the primary certificate utility interface, and it contains
everything you need to create your own certificates. The advanced interface is accessed by clicking
“Launch Advanced Interface” on the first wizard panel. For this walkthrough, just click “Next.”
The second panel displays the output directory edit box. It will default to the directory you executed the
utility from, and you can change the directory by clicking “Browse.” Set your output directory to be the
Samples\TCPIP\SSL\HTTPS\cert
directory (relative to your Dynamic C directory) for the sample
programs, and click “Next.” Note that several files will be generated for each certificate, so it is a good
idea to use an empty directory for your certificate output.
2. Select the signing options and create a root CA certificate.
Next, you need to select a signing option. Click the “Create your own CA” radio button on the signing
options panel, then click “Next.” You should see the “Create a New Certificate Authority” panel, where
you can enter the information for your new Certificate Authority (CA) that will be stored in your root CA
certificate. Enter “ca” in the Certificate Name field. Note that the certificate name is going to be used as a
base name for the certificate files, so this should only contain characters that are valid in file names. For
the Common Name, enter “My Root CA Certificate”. You can fill in the optional fields if desired, then
click “Next.”
Now you must select an output directory for your new root CA certificate—select the “private” directory
(a subdirectory under the directory where the utility executable is located), and click “Next.” The root CA
certificate will be created when you finish the wizard. This is the certificate that you will need to install in
your browser later in order for the browser to accept the server certificate you will create next. Remember
where your root CA certificate is for the browser setup.
3. Create the device server certificate.
Now you will create the certificate that will be loaded onto your device. For the Certificate Name, enter
“mycert”. Again, this will be used to generate file names, so only enter valid file name characters. For the
Common Name, enter the IP address of your device (e.g., 10.10.6.100), or if you access your device using
a text URL, enter the base Domain Name you access your device from. For example, if you access your
device from “http://www.foo.com/index.html”, your certificate’s Common Name should be
“www.foo.com”—no slashes or extra information.
Again, fill in the optional fields as desired, and then check the checkbox at the bottom of the panel to gen-
erate the certificate and exit the utility when you are finished. Click “Next.”
4. Create the certificates.
Now that you have finished the wizard, you need to generate your certificates. Check the summary on the
final panel of the wizard to make sure all the information is correct. Once you have verified your certifi-
cate information, click “Finish” to generate your root CA and server certificates.
i. A Certificate Authority (CA) provides the service of verifying the identity of a certificate owner using
conventional means, then signs that owner’s certificate using their own private key. The root CA certifi-
cate is a self-signed certificate that originates from a trusted source, and represents the ultimate guarantee
that a certificate being checked is genuine. See
Appendix B. “SSL Certificates,”
for more information.
SSL
www.rabbit.com
5
京公网安备 11010802033920号
EEWORLD
