![allanswers.org - [SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.1.1](/logo.gif "allanswers.org - [SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.1.1"){kind=logo}
|
|
| Home > Software > computer-security > |
[SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.1.1 |
Section 1 of 2 - Prev - Next
Content-type: text/x-usenet-FAQ;
version=1.1;
title="[SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.1.1"
Archive-name: computer-security/ssl-talk-faq
Posting-Frequency: monthly
Last-modified: Nov 16 12:00:00 PST 1998
Version: 1.1.1 (text) Mon Nov 16 12:00:00 PST 1998
URL: http://www.consensus.com/security/ssl-talk-faq.html
Copyright-Notice: (c) Copyright 1996-1998 by Consensus Development Corporation -- All Rights Reserved
SSL-Talk FAQ
Secure Sockets Layer Discussion List FAQ v1.1.1
Mon Nov 16 12:00:00 PST 1998
FAQ Maintained by:
Shannon Appel
Consensus Development Corporation
Copyright (c) 1996-1998 Consensus Development Corporation - All Rights
Reserved
*********************************************************************
Due to the November 15, 1998 dissolution of the SSL-Talk mailing
list, this will be the last version of this FAQ in its current form.
It will be replaced by a more general TLS & SSL FAQ in the near
future that is not tied to any mailing list or newsgroup.
*********************************************************************
All information contained in this work is provided "as is." All
warranties, expressed, implied or statutory, concerning the accuracy
of the information of the suitability for any particular use are
hereby specifically disclaimed. While every effort has been taken to
ensure the accuracy of the information contained in this work,
the authors assume(s) no responsibility for errors or omissions or
for damages resulting from the use of the information contained
herein.
This work may be copied in any printed or electronic form for
non-commercial, personal, or educational purposes if the work is not
modified in any way, provided that the copyright notice, the notices
of any other author included in this work, and this copyright
agreement appear on all copies.
Consensus Development Corporation also grants permission to
distribute this work in electronic form over computer networks for
other purposes, provided that, in addition to the terms and
restrictions set forth above, Consensus Development Corporation
and/or other cited authors are notified and that no fees are charged
for access to the information in excess of normal online charges
that are required for such distribution.
This work may also be mentioned, cited, referred to or described
(but not copied or distributed, except as authorized above) in
printed publications, on-line services, other electronic
communications media, and otherwise, provided that Consensus
Development Corporation and any other cited author receives
appropriate attribution.
Comments about, suggestions about, or corrections to this document
are welcomed. If you would like to ask us to change this document
in some way, the method we appreciate most is for you to actually
make the desired modifications to a copy of the posting, and then to
send us the modified document, or a context diff between the posted
version and your modified version (if you do the latter, make sure
to include in your mail the "Version:" line from the posted
version). Submitting changes in this way makes dealing with them
easier for us and helps to avoid misunderstandings about what you
are suggesting.
Many people have in the past provided feedback and corrections; we
thank them for their input.
In particular, many thanks to:
Christopher Allen
Shannon Appel
Nelson Bolyard
Tim Dierks
Eric Greenberg
Charles Neerdaels
Bruce Schneier
Tom Weinstein
Jonathan Zamick
Remaining ambiguities, errors, and difficult-to-read passages are
not their fault. :)
------------------------------
CONTENTS
1) THE SSL-TALK LIST
2) GENERAL SSL QUESTIONS
3) USING PROXIES, GATEWAYS AND FIREWALLS WITH SSL
4) SSL PROTOCOL QUESTIONS
5) CERTIFICATE RELATED QUESTIONS
6) SSL IMPLEMENTATION QUESTIONS
6.1) NETSCAPE QUESTIONS
6.2) MICROSOFT QUESTIONS
7) SSL TOOLKIT QUESTIONS
7.1) SSLREF QUESTIONS
7.2) SSL PLUS QUESTIONS
7.3) SSLEAY QUESTIONS
------------------------------
1) THE SSL-TALK LIST
This section contains information about the SSL-Talk list.
1.1) What is the SSL-Talk List?
The SSL-Talk List was an email list intended for discussion of the
technical issues of implementing the SSL protocol. It ceased to exist
on November 15, 1998.
Past discussions included issues of software development,
cryptanalysis of the protocol and of its various implementations,
testing, interoperability, the applicability of SSL to additional
TCP-based applications, infrastructure growth questions, etc.
1.1.1) Do archives of the SSL-Talk List exist?
Yes. An archive is maintained at:
1.2.1) What is TLS?
TLS is the Transport Layer Security protocol. It is effectively SSL
3.1 and was submitted to the IETF standards committee for change
control in 1996. It should be close to release.
1.3) Has netscape replaced the SSL-Talk mailing list?
Yes. Netscape, the host of the old ssl-talk mailing list, has
replaced it with a newsgroup.
The newsgroup netscape.dev.ssl is now available via two means:
a) from
1.4) Are there any other SSL mailing lists?
Some people prefer mailing lists to newsgroups. Fortunately, several
other mailing lists exist to discuss SSL.
THE SSL DEVELOPER LIST
This is a mailing list specifically geared toward application
developers who are incorporating SSL or TLS into their products. It
is hosted by Consensus Development, a division of Certicom, who has
helped to develop the TLS specifications. To join, send a message to:
join-ssl-dev@lists.consensus.com
THE SSL LIST
As with the older SSL-Talk mailing list, the purpose of this
mailing list is to discuss any SSL & TLS related issues. It covers
the whole spectrum of issues, from beginners on up and is more
oriented toward users of SSL-enabled applications. To subscribe
simply send e-mail to:
ssl-subscribe@engine.ca
THE SSL-USERS LIST
This is a list concerning SSLeay, a public implementation of SSL. To
subscribe send mail to:
factotum@lists.cryptsoft.com
The command "subscribe ssl-users" must appear in the body of the
message.
THE IETF-TLS LIST
This is a mailing list dedicated to the writing of the TLS
specification for the IETF. To subscribe, send a message to:
join-ietf-tls@lists.consensus.com
------------------------------
2) GENERAL SSL QUESTIONS
This section contains general information on SSL and the SSL
protocol.
2.1) What is the current version of the SSL protocol?
The current version is SSL 3.0, as documented at
Errata to the SSL 3.0 Specification is periodically posted on
the SSL discussion list, and is available at
Netscape has submitted SSL 3.0 to the IETF-TLS Working Group
as an Internet Draft (see the section 4.5 of this FAQ for more
info on TLS). This will be TLS 1.0:
The previous version of SSL, version 2.0 is documented at
2.2) Where can I get a "management overview" of SSL and web security?
There is a brief introduction on how Netscape uses public key
cryptography in the SSL protocol called "Using Public Key
Cryptography" at
An overview on certificates and VeriSign's Digital IDs is at
.
General information on Netscape security can be found in a
set of web pages called "Network Security Solutions", at:
2.3) Where can I get a more in-depth look at SSL and web security?
The online version of the technical specifications for the SSL 3.0
protocol is at
A PostScript version is also available at
A FAQ for SSLeay, a freeware implementation which support SSL 2.0,
SSL 3.0, and TLS 1.0, is available at
SSL is not just for web servers and is supported by numerous other
internet clients and servers.
2.5) What are the laws regarding the import and export of cryptography in
various countries?
There is an impressive "International Law Crypto Survey" of
cryptographic laws and regulations throughout the world at
RSA Data Security, Inc. offers an Acrobat version of their
"Frequently Asked Questions: Export" at
Other information on US export issues can be found on
the Electronic Frontier Foundation's web site at
------------------------------
3) USING PROXIES, GATEWAYS, AND FIREWALLS WITH SSL
This section contains information on how the SSL protocol interacts
with proxy servers, security gateways, and firewalls.
3.1) What is a proxy server?
A proxy server is a computer program that resides on your firewall
and acts as a conduit between your computer and the broader
Internet. In addition to acting as network guardian and logging
traffic, a proxy server can also provide an enterprise cache for
files as well as replication and site-filtering services.
Any application which needs to communicate through a proxy has to
negotiate with the proxy first before continuing through the
firewall. Netscape Navigator works with many different types of
proxies (such as the CERN proxy server and their own Netscape Proxy
Server) and gateways that use the SOCKS protocol.
One problem with SSL-based traffic is that it does not allow
caching and replication with proxy servers. For a proxy server to
support SSL it must either support SOCKS (a protocol independent
proxy mechanism), or use a special SSL Tunneling protocol. The
Netscape Proxy Server supports both SOCKS and the SSL Tunneling
protocol.
3.2) How does SSL work through (application level) firewalls,
gateways and proxy servers?
SSL was designed to provide security between client and server and
to avoid any kind of 3-way man-in-the-middle attack. Thus SSL cannot
be proxied through traditional application level firewalls (such as
the CERN proxy server) because SSL considers a proxy server to be a
middleman.
The simplest alternative to this problem is to use a packet
filtering firewall. You set it up to open a reserved and trusted
port for the SSL+HTTP or SSL+NNTP services (443 or 563 respectively)
allowing all traffic on those ports to be passed through
unrestricted. The risk with this solution is that an internal
attacker could attempt to use these trusted ports without using SSL
and there is no way for the firewall to know.
SSL also can work with gateways that support the SOCKS protocol, a
protocol independent proxy mechanism. SOCKS is a generic byte
forwarding gateway between client and server and generally works
at the socket level. If all you want is TCP/UDP restrictions based on
client IP or server IP, SOCKS works fine.
However, most non-SSL HTTP proxies work at the protocol level and
have the ability to understand header information related to the
protocol. This goes beyond SOCKS to allow the firewall administrator
to use the header information for filtering and/or monitoring the
traffic. Also, SOCKS does not offer the firewall administrator
enough information about the request to let it decide whether to
allow it and whether to log the request.
A more secure approach is to use a firewall that supports the SSL
Tunneling CONNECT extension method as described in the Internet
draft
In SSL Tunneling, the client initiates an SSL connection via normal
HTTP then handshakes and creates a secure connection to the server
via a byte-forwarding tunnel. The proxy has access to the
client-proxy request headers, but the session is encrypted. Once
the handshake occurs, the proxy acts just like a SOCKS gateway. This
allows the firewall to monitor the requests, but not the traffic.
The biggest difference between the two methods is that when using
SOCKS, DNS resolution is the responsibility of the client, whereas
when requests are forwarded through a proxy, DNS resolution is the
responsibility of the proxy.
The are three additional things that the SSL Tunneling mechanism
does with the proxy server that do not happen when using SOCKS:
* The client sends a "user agent" message (for example,
"Mozilla/3.0/Macintosh").
* The proxy can send to the client an authorization request
allowing the administrator to use passwords to control external
Internet access.
* The standard is more easily extensible. For example, the client
could, in theory, send the URL being requested (or anything
else) to the firewall. However, there is no standard to support
this behavior and as far as we know there are no products which
do it.
The Netscape Proxy Server supports the SSL Tunneling CONNECT
extension method for tunneling SSL, and the use of the proxy is
described in
Another solution, also available using the Netscape Proxy Server, is
that the proxy server can spoof SSL on behalf of the internal client.
The proxy will initiate SSL between itself and other servers on the
Internet, but be unsecure inside the firewall between the proxy
server and the client.
This compromise means that client authentication is not possible;
only server authentication of the remote sites is available.
However, you gain the ability for client authentication between the
client and the proxy. The administrator must decide which is more
important, until such time as a better solution arises. The
description of this feature of the Netscape Proxy Server is at
Reverse proxies are a solution for serving secure content inside
a firewall to outside clients. For the Netscape Proxy Server
this is described at
It is possible for a proxy server to hold both client and server
keys for its internal clients. This allows SSL sessions to be
carried out twice: once between the client and proxy server, and
again between the proxy server and the secure server. Thus, the
proxy server can to listen in on the conversation without having the
private keys of external servers. Clearly this isn't reasonable for
the general internet, but it is a viable solution for corporate
requirements inside a firewall.
Netscape Proxy Server 3.5 supports this feature. It can be used as
described above, or simply to create a secure tunnel between sites
across an insecure network. This is really multiple sessions of SSL,
not an end-to-end secure connection.
This means that 3.5 has full SSL support as opposed to just SSL
tunneling. It can therefore do client authentication and serve
documents like a secure server, or request documents like an
SSL-enabled client. SSL doesn't allow recursive encryption, so by
using it this way you lose the transparency of the proxy and get
multiple segments of secure connections, rather than a single
end-to-end connection.
3.3) Since SSL is supposed to withstand replay attacks, does this
preclude proxy servers from caching the data?
A proxy server must pass SSL directly through without caching.
3.4) What ports does SSL use?
Theoretically SSL can transparently secure any TCP-based protocol
running on any port if both sides know the other side is using SSL.
However, in practice, separate port numbers have been reserved for
each protocol commonly secured by SSL -- this allows packet
filtering firewalls to allow such secure traffic through.
As of October 1998, SSL has the following port numbers reserved
with the Internet Assigned Numbers Authority (IANA), a part of the
Internet Engineering Task Force (IETF):
Keyword Decimal Description
------- ------- -----------
nsiiops 261/tcp IIOP Name Service over TLS/SSL
https 443/tcp http protocol over TLS/SSL
ddm-ssl 448/tcp DDM-SSL
smtps 465/tcp smtp protocol over TLS/SSL
nntps 563/tcp nntp protocol over TLS/SSL
sshell 614/tcp SSLshell
ldaps 636/tcp ldap protocol over TLS/SSL
ftps-data 989/tcp ftp protocol, data, over TLS/SSL
ftps 990/tcp ftp, control, over TLS/SSL
telnets 992/tcp telnet protocol over TLS/SSL
imaps 993/tcp imap4 protocol over TLS/SSL
ircs 994/tcp irc protocol over TLS/SSL
pop3s 995/tcp pop3 protocol over TLS/SSL
A listing of all IANA port assignments can currently be found at
.
3.5) Do you have any information on sftp?
SSL FTP has been assigned port 990 under the name ftps.
------------------------------
4) SSL PROTOCOL QUESTIONS
This section contains more detailed information on the SSL protocol.
4.1) Does SSL protect users from replay attack by eavesdroppers or
message interceptors?
Yes. The client and the server each provide part of the random data
used to generate the keys for a connection. (The random portions of
the connection that initiate a session, drawn from both the client
and the server, are used to generate the master secret associated
with that session.) Additionally, each record is protected with a
MAC (Message Authentication Code) that contains a sequence number for
the message.
4.2) Isn't encrypt-only SSL open to "man-in-the-middle" attacks?
Yes, even though SSL 3.0 defines an encrypt-only cipher suite (the
SSL_DH_anon_WITH_DES_CBC_SHA cipher suite), there are many possible
attacks against it, and some recommend against using it. SSL *MUST*
have strong server authentication or it becomes open to some attacks.
Netscape's browser and server products do not presently support
encrypt-only cipher suites for this reason.
4.3) When did MD5 get "disavowed"?
It hasn't been truly "disavowed", but weaknesses have been
discovered such that some people believe that an alternative should
be found. These weaknesses were found by Dr. Hans Dobbertin
of the German Information Security Agency
in a paper called "Cryptanalysis of MD5 Compress" dated May 2, 1996.
A postscript version of the paper is at
.
SSL uses MD5 in combination with SHA for all negotiation. It also
uses MD5 alone in most negotiated cipher suites. However, in these
cases it is used with the HMAC construction, which strengthens it
such that there are no known problems with this construction.
It has been proposed with TLS to start phasing out all use of MD5.
4.4) The record protocol sits underneath the other protocols, right?
It appears that information can be sent only in blocks. Does
there have to be a one-to-one mapping between write() calls on the
client/server and SSL records? Is there some other blocking
taking place when user data is being sent?
The record layer takes a data stream from the higher layers and
fragments it into records. If the write is longer than 2^14 bytes
(with headers), the record layer will generate multiple records.
Multiple writes can be condensed into a single record.
4.5) It appears that there is no way in the SSL protocol to
resynchronize blocks if they get out of synch. Is that true?
Yes. SSL relies on an underlying reliable protocol to assure that
bytes are not lost or inserted. There was some discussion of
reengineering the future TLS protocol to work over datagram
protocols such as UDP, however TLS 1.0 does not support this.
4.6) Why does SSL3 have Diffie-Hellman encryption at all? What good is
it? Exchanging random numbers that are encrypted with the server's (or
client's) public key would seem to be an adequate way of getting the
secret bits across. Why have DH as well?
Anonymous DH key exchange doesn't require the use of certificates.
Ephemeral DH allows you to use signing-only certificates, and it
protects the session from future compromise of the server's private
key. Another advantage of DH is that the patent expired in 1997.
4.7) What is TLS? What happened at these meetings? Has anything come
out of them yet?
TLS is the Transport Layer Security Working Group of the IETF
(Internet Engineering Task Force). It is the working group
responsible for moving transport layer protocols such as SSL
through the standards tracks.
IETF working groups do most of their activities through mailing
lists and thrice-annual IETF meetings. The first official IETF-TLS
Working Group meeting was June 1996 in Montreal. (Before then it was
an unofficial BOF "birds of a feather" group.)
The home page for the IETF-TLS Working Group is at
The discussion list for IETF-TLS is at IETF-TLS@CONSENSUS.COM. You
subscribe and unsubscribe by sending to IETF-TLS@CONSENSUS.COM with
subscribe or unsubscribe in the SUBJECT of the message. Archives of
the list are at
December 1997:
April 1997:
December 1996:
June 1996:
May 1996:
A number of internet-draft documents have been submitted to the
IETF-TLS Working Group.
The TLS Protocol 1.0 (Current Version 06):
Addition of Kerberos Cipher Suites to Transport Layer
Security (TLS):
ECC Cipher Suites for TLS
HTTP over SSL:
An Internet AttributeCertificate Profile for Authorization
TLS extensions for AttributeCertificate based authorization
The following internet drafts are expired, but are of historical
interest:
Addition of Shared Key Authentication to Transport Layer
Security (TLS):
(16885 bytes, expires May '97)
Modifications to the SSL protocol for TLS:
(9271 bytes, expires May '97)
Secure FTP over SSL:
(14238 bytes, expires June '97)
SSH Transport Layer Protocol (originally
)
(44411 bytes, expired December '96)
4.8) What is the purpose of pad1 and pad2, and why were the numbers 0x36
and 0x5c chosen?
The purpose of the construction of a "keyed-MAC" in the form of
HASH(K,pad2,HASH(K,pad1,text)). It was proposed by the cryptographer
Hugo Krawczyk of IBM as a much more secure alternative to traditional
MACs. In a paper last year he demonstrated a proof that even if the
hash function was relatively weak (as MD5 has since proven itself to
be) the addition of the secret key in the function makes it
significantly more secure. The particular method proposed by
Krawczyk is now known as an HMAC.
The particular construction that Netscape uses for SSL is based on
the original internet-draft, and since that time it has been revised
such that it XORs the pads rather than appending them -- a nice
consequence of which is that pads are of the same size whether you
use MD5 or SHA; it also allows for long keys and has some
security advantages. This version may now be found as RFC 2104:
In the proposals we've seen for the IETF-TLS Working Group the
scheme SSL 3.0 uses will be replaced by the official RFC HMAC
technique.
The particular pad bytes used are the ones defined in Krawczyk's
original HMAC paper. We believe that they are relatively arbitrary.
The salient property is that half the bits differ: the hamming
distance between 0x36 and 0x5c is 4 out of a possible 8. We don't
know if the fact that each of the pads also has a hamming weight of
4 is significant or not.
4.9) Are you aware of any SSL toolkits supporting client authentication?
SSLRef 3.0 and SSL Plus both support SSL 3.0 client authentication.
SSLeay supports SSL 2.0 and 3.0 client authentication as well as the
proposed TLS standard for client authentication.
4.10) What SSL implementations should I test against?
There is no formal conformance testing, but Netscape does currently
offer an interoperability test server that has been used to test
conformance with many other implementations of SSL 3.0. This server
is located at
VeriSign also has an "Authentic Site" program listing various sites
that use SSL authentication. Also included is a test page that
requires that you present a valid VeriSign client certificate.
More information on the Authentic Site program is at
Section 1 of 2 - Prev - Next
| Back to category computer-security - Use Smart Search |
| Home - Smart Search - About the project - Feedback |
© allanswers.org | Terms of use