SSL workings

• Previous message: Cheetah: "Identifying a computer"
• Next in thread: Trystano_at_aol.com: "Re: SSL workings"
• Maybe reply: Trystano_at_aol.com: "Re: SSL workings"
• Maybe reply: Boyer, G. T. IT2 ISSM Office: "RE: SSL workings"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: security-basics@securityfocus.com
Date: Wed, 3 Dec 2003 21:21:03 -0500 

-----Original Message-----
From: Boyer, G. T. IT2 ISSM Office
Sent: Wednesday, December 03, 2003 9:20 PM
To: 'dave kleiman'
Subject: RE: SSL workings

Taken from the Website http://en.wikipedia.org/wiki/Secure_Sockets_Layer

Transport Layer Security
(Redirected from Secure Sockets Layer)

Secure Sockets Layer or SSL is a protocol designed by Netscape
Communications Corporation to provide encrypted communications on the
Internet. SSL Version 3.0, released in 1996, was later used as a basis to
develop Transport Layer Security or TLS, an IETF standard protocol. TLS was
first defined in RFC 2246: "The TLS Protocol Version 1.0".

These protocols provide communications privacy over the Internet, using
cryptography. They allow client/server applications to communicate in a way
that is designed to prevent eavesdropping, tampering, or message forgery.

They are layered beneath application protocols such as HTTP, SMTP and NNTP
and above the TCP transport protocol, which is part of the TCP-IP protocol
suite. While both SSL and TLS can be used to add security to any protocol
that uses TCP, they are most commonly used in the HTTPS access method. HTTPS
is used to secure World Wide Web pages for applications such as Electronic
commerce. Both protocols use public key cryptography and public key
certificates to identify the identity of endpoints.

Like SSL, on which it was based, TLS is a modular protocol, designed to be
extended, with support for forwards and backwards compatibility and
negotiation between peers.

Both TLS and SSL involve a number of basic phases:

peer negotiation for algorithm support
public key encryption based key exchange and certificate-based
identification
symmetric cipher-based traffic encryption
Some early versions of SSL used 40-bit symmetric keys because of
restrictions on the export of cryptographic technology. These were quickly
abandoned as insecure: the 40-bit key space was simply too small, and could
be exhausted by means of a brute force search. Modern implementations use
128-bit keys for symmetric cipher encryption.

TLS has subsequently been extended by other RFCs including:

RFC 2712 "Addition of Kerberos Cipher Suites to Transport Layer Security
(TLS)". The 40-bit ciphersuites defined in this memo are included only for
the purpose of documenting the fact that those ciphersuite codes have
already been assigned.

RFC 2817 "Upgrading to TLS Within HTTP/1.1", explains how to use the Upgrade
mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an
existing TCP connection. This allows unsecured and secured HTTP traffic to
share the same well known port (in this case, http: at 80 rather than https:
at 443).

RFC 2818 "HTTP Over TLS", distinguishs secured traffic from insecure traffic
by the use of a different server port.

RFC 3268 "AES Ciphersuites for TLS". Adds enhanced by the addition of
Advanced Encryption Standard (AES) ciphersuites to the previously existing
symmetric ciphers, like RC2, RC4, International Data Encryption Algorithm
(IDEA), Data Encryption Standard (DES), and triple DES 3DES or TDES.
While an increasing number of client and server products can support TLS or
SSL natively, there are many that still do not. In these cases, a user may
wish to use standalone SSL products like Stunnel to provide SSL encryption.

-----Original Message-----
From: dave kleiman [mailto:dave@isecureu.com]
Sent: Tuesday, December 02, 2003 10:01 PM
To: Trystano@aol.com; security-basics@securityfocus.com
Subject: RE: SSL workings

As you establish the connection, the port your client uses may change as you
go from page to page within the SSL transaction. You will even establish a
temporary port connect to crl.verisign.com (or whomever the certificate is
issued by) to verify the Certificate. But you will always be connected to
0.0.0.0:https (443) by default.

Each piece of data is transmitted from the client port to the server port
that is established.

Is that what you are asking?

 
_______________________________
Dave Kleiman, CISSP, MCSE, CIFI
dave@isecureu.com
www.SecurityBreachResponse.com

"High achievement always takes place in the framework of high expectation."
Jack Kinder

-----Original Message-----
From: Trystano@aol.com [mailto:Trystano@aol.com]
Sent: Tuesday, December 02, 2003 20:08
To: dave@isecureu.com; security-basics@securityfocus.com
Subject: Re: SSL workings

Cheers, Dave, for the info.

I actually know all about what SSL does etc. Maybe I worded the question
wrong :-s

Maybe what I need to know lies a little deeper. I want to know that when a
client machine communicates with a server, out of what port does this
information travel from the clients machine.

And also, if a client and server communicate via SSL, is the data
transferred
in a secure state via the same port that data is normally sent, or is the
data transferred through a separate port??

Cheers all.

Tryst

---------------------------------------------------------------------------
----------------------------------------------------------------------------

---------------------------------------------------------------------------
----------------------------------------------------------------------------

• Previous message: Cheetah: "Identifying a computer"
• Next in thread: Trystano_at_aol.com: "Re: SSL workings"
• Maybe reply: Trystano_at_aol.com: "Re: SSL workings"
• Maybe reply: Boyer, G. T. IT2 ISSM Office: "RE: SSL workings"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]