Professional Documents
Culture Documents
Computers have become ubiquitous and indispensable today. Internet usage has multiplied
and is a vital global tool in technology.
2
Because of a flaw in the software code, however, it ended up exploiting vulnerabilities in
Unix and spread rapidly, infecting multiple machines multiple times and rendering them
unusable.
In 1994, Russian hacker Vladimir Levin broke into Citibank's cash
management system and embezzled $10 million into his own accounts. The stolen accounts
were unencrypted and all but $400,000 of the stolen cash was recovered and Levin was
arrested He pled guilty to conspiracy to commit computer, wire and bank fraud. On April 11,
1994, a full-scale epidemic broke out, caused by file and boot polymorphic virus called
'Tequila'. In September 1994, the same thing happened with the ‘Amoeba’ virus.
In 1996, the ‘Boza’ virus emerged, which was the first virus designed
specifically for Windows 95 files. In 1998, the first Java virus ‘Strange Brew’ affected
computers.
In 2005, the Bropia Worm affected the Internet. It targeted MSN messenger for
spreading.
The 2007 Storm Worm was a Trojan horse. It included an executable file as an
attachment. When the e-mail recipient opened the attachment, he or she unknowingly
became part of a botnet (a collection of infected computers) to spread viruses and Spam.
Once infected, a computer is called as a bot. It is an instance of adaptive malware. It has
been used in different kinds of criminal activities. The authors and the controllers, of the
Storm Worm, have not yet been identified.
3
CHAPTER 2
Introduction
In general :
SSL – Secure Socket Layer
• It provides a secure transport connection between applications (e.g., a web
– V2 1994 netscape
– V3 1996 netscape
• SSL version 3.0 has been implemented in many web browsers (e.g., Netscape
Navigator and MS Internet Explorer) and web servers and widely used on the
Internet.
• A protocol widely used on the Web
– Operates between the application and transport layers.
4
HTTP, FTP,SMTP
SSL TCP IP
Data Link
Physical
• Operations of SSL
– Negotiation for PKI
Server and browser negotiate to select cryptographic algorithm and
create a session secret key.
– Communications.
Encrypted by using the key that was negotiated.
5
followed in 1995, adding cryptographic methods such as Diffie-Hellman key agreement
(DH), support for the FORTEZZA key token, and the Digital Signature Standard (DSS)
scheme [SSL3].
The most recent draft of the SSL 3.0 specification was published in November of
1996 by Netscape. The intent was to be a “security protocol that provides communications
privacy over the Internet. The protocol allows client/server applications to communicate in
a way that is designed to prevent eavesdropping, tampering, or message forgery.” The goals
included cryptographic security, interoperability, extensibility, and relative efficiency.
Interoperability was a goal so that applications could be written to the standard and
expected to work with any other applications written to the standard. Interoperability, it was
noted, does not imply that two programs will always be able to connect. One might not have
the correct algorithm support or credentials necessary for the connection to the other.
Extensibility was descried as providing “a framework into which new public key and
bulk encryption methods can be incorporated as necessary.” It was noted that this should
prevent the need to implement a new security protocol entirely should a weakness be found
in one of the current encryption methods.
Cryptography, obviously, causes a higher CPU load than sending the data unencrypted. Still,
they made some effort to minimize the network traffic and allow for session caching.
6
Developed in 1995 by Microsoft. Privacy Communication Technology (PCT) v1.0
addressed some weaknesses of SSL v2.0, and was aimed to replace SSL. However, this
protocol has never gained as much popularity as SSL v3.0.
Released in 1996 by Netscape Communications. SSL v3.0 solved most of the SSL v2.0
problems, and incorporated many of the features of PCT. Pretty quickly become the most
popular protocol for securing communication over WWW.
Published by IETF in 1999 (RFC 2246). This protocol is based on SSL v3.0 and PCT and
harmonizes both Netscape's and Microsoft's approaches. It is important to note that although
TLS is based on SSL, it is not a 100% backward compatible with its predecessor. IETF did
some security improvements, such as using HMAC instead of MAC, using a different
calculation of the master secret and key material, adding additional alert codes, no support
for Fortezza cipher suites, and so on. The end result of these improvements is that these
protocols don't fully interoperate. Fortunately enough, TLS has also got a mode to fall back
to SSL v3.0.
re version numbers: Both SSL2 and SSL3 have 16-bit (two-byte) version number fields.
SSL2 interprets this as a single 16-bit integer, and the official number is 2, e.g. 0x0002.
SSL3 interprets two-byte version numbers as a one byte "major" number and a one byte
"minor" (or fractional) number. So the value 0x0002 is interpret by SSL3 as version 0.2, not
2.0.
7
In general :
TLS – Transport Layer Security
• TLS can be viewed as SSL v3.1,
• SSL v3.0 was specified in an Internet Draft (1996), it evolved into RFC 2246 and
was renamed to TLS (Transport Layer Security),
• V1.0 1999 RFC2246 IETF minor update from SSL v3.0,
All other SSL/TLS protocols reside inside of the Record protocol. This is laid out as:
8
Protocol Architecture :
9
CHAPTER 3
TLS connections begin with a 6-way handshake. The handshake protocol structure is:
10
0 HelloRequest
1 ClientHello
2 ServerHello
11 Certificate
12 ServerKeyExchange
13 CertificateRequest
14 ServerHelloDone
15 CertificateVerify
16 ClientKeyExchange
20 Finished
The record layer fragments the full data stream into records with a maximum size of 214
bytes and envelopes them cryptographically under the current session keys. Records contain
a keyed message authentication code (HMAC). The initial handshake presupposes a NULL
cipher suite applying no encryption and no HMAC. The record layer fully provides the use
of compression. However, for patent reasons the core specifications name no method
explicitly, except for the mandatory NULL algorithm, which practically makes compression
an incompatible, implementation-dependent feature.
11
Application Layer
ChangeCipherSpec
Message
Alert Messages
Record Layer
Transport Layer
12
State Changes
Here
Operating state
– currently used state.
Pending state
– state to be used,
– built using the current state.
13
• close_notify
• no_certificate
• bad_certificate
• unsupported_certificate
• certificate_revoked
• certificate_expired
• certificate_unknown
• In case of a fatal alert
– connection is terminated,
– session ID is invalidated,
– no new connection can be established within this session.
This Figure gives an overview of the SSL protocol variants. It comprises four different
handshake sequences, each identified by a capital letter:
S,C,E,R which denotes:-
• S denotes the server-authenticated message flow.
• C marks the sequence with additional client authentication.
• E shows the handshake variant with ephemeral Diffie-Hellman key agreement.
• R stands for the handshake of resumed sessions. Note, that the message pairs.
ChangeCipherSpec / Finished of client and server are drawn in reverse order; the
server message pair follows ServerHello immediately.
Process :-
First the client sends the Client Hello message which includes a 32-bit Unix format
timestamp and a 28-byte random number. The client may also specify a session identifier of
a current or previous session. Doing this allows for multiple secure connections without
going through the entire handshake process each time, although both Hello, the Change
Cipher Spec, and both Finished messages must still be exchanged and be valid.
15
SSL Protocol Sequence
The client then includes a list of acceptable Cipher Suites and Compression Methods.
Each cipher suite defines the algorithm for key exchange, the bulk encryption algorithm
with secret key and length, and the message authentication code (MAC).
The server then responds to this with the Server Hello message. The server hello
message will have the following data:
• The version number being used: the lower of the server’s highest supported
version and the version in the client hello.
• A random number generated by the server.
• The session identifier: if the Session ID is recognized, then a short
handshake is used and the following fields are filled in with the values from
the previous connection. Otherwise, the Server Hello generates a new
Session ID.
• The cipher suite chosen by the server, and
16
• The compression method chosen by the server.
If the server can not find an acceptable cipher suite and compression method, it will
respond with a handshake failure alert.
Unless the key exchange method is anonymous, the server will send out a Certificate
immediately after sending the Server Hello. The certificate is generally a X.509v3 certificate
public key and unless otherwise specified uses the same key exchange method and signing
algorithm previously decided on. After the server’s certificate, certificates from all the up
line servers necessary to get to one that the client trusts must be included. The order of these
should be such that each certificate validates the one before it.
If the server Certificate does not contain enough data for a premaster secret, then a
Server Key Exchange is sent with either a RSA public, or a Diffie-Hellman public key.
(This is the case for DHE_DSS, DHE_RSA, and DH_anon; but not for RSA, DH_DSS, and
DH_RSA key exchange methods.)
If it is appropriate, the server may request a certificate from the client with a
Certificate Request. This would immediately follow the Server Certificate, or if present the
Server Key Exchange. The Certificate request would specify the types of certificates the
server will accept and the Certificate Authorities the server trusts. The client, after receiving
the Server Hello Done would respond with a message identical in format to the Server
Certificate.
The Server Hello Done indicates to the client that server is done sending data and the
client should now verify the certificates and whatnot it has received.
If a Certificate Request was received, the client would now send the Certificate.
If RSA is used, the Client Key Exchange message includes an encrypted pre-master
secret which consists of a 48-bit number that is encrypted with the server’s public key.
If Diffie-Hellman is used, but not Fixed Diffie-Hellman, then the public key
parameters are sent here.
If the client sent a certificate, then it would send a Certificate Verify message hat this
point, in most cases. This would include a signature in the same format as defined for the
Server Key Message as well as an md5 sum of all of the previous messages and a SHA hash
of all of the previous messages.
17
The Client sends the Change Cipher Spec message indicating that all future traffic
will be computed with the Master Secret. The random numbers and the pre master secret are
used by both systems in a pseudorandom function to calculate the master secret.
The change cipher spec protocol is a single byte that will always have a value of 1. It
is encrypted and compressed under the current cipher (the pre master secret) and
compression method.
The client now sends the Finished Message. This consists of the master secret, the
finished label, an md5 of all previous messages and an SHA of all previous messages. All of
this is encrypted with the master secret. If the server can read all of this, then the server
knows that the key generation was successful.
The server responds with its own Change Cipher Spec and Finished messages which
verify to the client that the key generation was successful.
If any warning or fatal errors occur, an alert is sent. Alerts consist of a byte that
defines whether it’s a warning (1) or a fatal (2) alert, and a byte that indicates the specific
alert.
18
• internal_error(80),
• user_canceled(90),
19
CHAPTER 4
Hyper Text Transfer Protocol Secure (HTTPS) is a secure version of the Hyper Text
Transfer Protocol (http). HTTPS allows secure ecommerce transactions, such as online
banking.
20
Web browsers such as Internet Explorer and Firefox display a padlock icon to indicate that
the website is secure, as it also displays https:// in the address bar.
When a user connects to a website via HTTPS, the website encrypts the session with a
digital certificate. A user can tell if they are connected to a secure website if the website
URL begins with https:// instead of http://.
HTTPS is effectively HTTP using SSL (Secure Sockets Layer). SSL merely encrypts the
content of the packets before being sent from the server to client.
The encryption using a private key/public key pair ensures that the data can be encrypted by
one key but can only be decrypted by the other key pair. This is sometime hard to
understand, but believe me it works. The keys are similar in nature and can be used
alternatively: what one key emcrypts, the other key pair can decrypt. The key pair is based
on prime numbers and their length in terms of bits ensures the difficulty of being able to
decrypt the message without the key pairs. The trick in a key pair is to keep one key secret
(the private key) and to distribute the other key (the public key) to everybody. Anybody can
send you an encrypted message, that only you will be able to decrypt. You are the only one
to have the other key pair, right? In the opposite , you can certify that a message is only
coming from you, because you have encrypted it with you private key, and only the
associated public key will decrypt it correctly. Beware, in this case the message is not
secured you have only signed it. Everybody has the public key, remember!
One of the problem left is to know the public key of your correspondent. Usually you will
ask him to send you a non confidential signed message that will contains his publick key as
well as a certificate.
21
A SSL certificate does following tasks:-
transactions.
2. Each SSL Certificate contains unique, authenticated information about the certificate
owner.
3. A Certificate Authority verifies the identity of the certificate owner when it is issued.
The e-commerce business is all about making money and then finding ways to
make more money. Of course, it's hard to make (more) money, when consumers
don't feel safe executing a transaction on your Web site. That's where SSL
(Secure Socket Layer) comes into play.
SSL is all about encryption. SSL encrypts data, like credit cards numbers (as well other
personally identifiable information), which prevents the "bad guys" from stealing your
information for malicious intent. You know that you're on an SSL protected page when the
address begins with "https" and there is a padlock icon at the bottom of the page (and in the
Mozilla Firefox in the address bar as well).
The browser encrypts the data and sends to the receiving Web site using either 40-bit or 128-
22
bit encryption. Your browser alone cannot secure the whole transaction and that's why it's
incumbent upon e-commerce site builders to do their part.
At the other end of the equation, and of greatest importance to e-commerce site builders, is
the SSL certificate. The SSL certificate sits on a secure server and is used to encrypt the data
and to identify the Web site. The SSL certificate helps to prove the site belongs to who it
says it belongs to and contains information about the certificate holder, the domain that the
certificate was issued to, the name of the Certificate Authority who issued the certificate, the
root and the country it was issued in.
SSL certificates come in 40-bit and 128-bit varieties, though 40-bit encryption has been
hacked. As such, you definitely should be looking at getting a 128-bit certificate.
Though there a wide variety of ways in which you could potentially acquire a 128-bit
certificate, there is one key element that is often overlooked in order for full two-way 128-
bit encryption to occur. According to SSL certificate vendor VeriSign, in order to have 128-
bit encryption you need a certificate that has SGC (server grade cryptography) capabilities.
Imagine sending mail through the postal system in a clear envelope. Anyone with access to
it can see the data. If it looks valuable, they might take it or change it. An SSL Certificate
establishes a private communication channel enabling encryption of the data during
transmission. Encryption scrambles the data, essentially creating an envelope for message
privacy.
Each SSL Certificate consists of a public key and a private key. The public key is used to
encrypt information and the private key is used to decipher it. When a Web browser points
to a secured domain, a Secure Sockets Layer handshake authenticates the server (Web site)
and the client (Web browser). An encryption method is established with a unique session
key and secure transmission can begin. True 128-bit SSL Certificates enable every site
visitor to experience the strongest SSL encryption available to them.
Imagine receiving an envelope with no return address and a form asking for your bank
account number. Every VeriSign SSL Certificate is created for a particular server in a
specific domain for a verified business entity. When the SSL handshake occurs, the browser
23
requires authentication information from the server. By clicking the closed padlock in the
browser window or certain SSL trust marks (such as the VeriSign Secured Seal), the Web
site visitor sees the authenticated organization name. In high-security browsers, the
authenticated organization name is prominently displayed and the address bar turns green
when an Extended Validation SSL Certificate is detected. If the information does not match
or the certificate has expired, the browser displays an error message or warning.
Like a passport or a driver’s license, an SSL Certificate is issued by a trusted source, known
as the Certificate Authority (CA). Many CAs simply verify the domain name and issue the
certificate. VeriSign verifies the existence of your business, the ownership of your domain
name, and your authority to apply for the certificate, a higher standard of authentication.
VeriSign Extended Validation (EV) SSL Certificates meet the highest standard in the
Internet security industry for Web site authentication as required by CA/Browser Forum. EV
SSL Certificates give high-security Web browsers information to clearly display a Web site’s
organizational identity. The high-security Web browser’s address bar turns green and reveals
the name of the organization that owns the SSL Certificate and the SSL Certificate Authority
that issued it. Because VeriSign is the most recognized name in online security, VeriSign
SSL Certificates with Extended Validation will give Web site visitors an easy and reliable
way to establish trust online.
SSL Certificates can be issued by anybody using freely available software such as Open
SSL or Microsoft's Certificate Services manager. Such SSL Certificates are known as "self-
signed" Certificates. However, self-signed SSL Certificates are not inherently trusted by
customer's browsers and whilst they can still be used for encryption they will cause
browsers to display "warning messages" - informing the user that the Certificate has not
been issued by an entity the user has chosen to trust.
Such warnings are undesirable for commercial sites - they will drive away customers. In
order to avoid such warnings the SSL Certificate must be issued by a "trusted certifying
authority" - trusted third party Certification Authorities that utilize their trusted position to
make available "trusted" SSL Certificates.
24
Warning message IE users will see from a self-signed SSL Certificate
Warning message Netscape users will see from a self-signed SSL Certificate
25
The Microsoft trusted root CA store
SSL certificates issued by trusted Certification Authorities do not display a warning and
establish a secure link between website and browser transparently. In such circumstances,
the padlock signifies the user has an encrypted link with a company who has been issued a
trusted SSL Certificate from a trusted Certificate Authority.
Microsoft and Netscape have therefore determined the role of the Certification Authority -
to use their trusted status to "pass trust" to websites whom ordinarily would not be trusted
by a customer.
The key issue must now be addressed - before passing such trust, how does the CA know the
website can be trusted?
Step 1: Verify that the applicant owns, or has legal right to use, the domain
26
Name featured in the application.
Step 2: Verify that the applicant is a legitimate and legally accountable entity.
The compromise of either step endangers the message of trust and legitimacy provided to
the end consumer.
Companies such as GeoTrust, through its QuickSSL and FreeSSL products, and IPSCA, the
Spanish SSL Provider, perform only the first stage of the two-step validation process (as
employed by all other SSL Providers) by only verifying that the applicant owns the domain
name provided during Certificate application. This validation step relies on the use of
Domain Name Registrar details to validate ownership of a domain name and then a
challenge email is sent to the listed administrator of the domain name. If the challenge is
met with a successful reply, the Certificate will be issued.
27
There are several encryption algorithms available, using symmetric or asymmetric methods,
with keys of various lengths. Usually, algorithms cannot be patented, if Henri Poincare had
patented his algorithms, then he would have been able to sue Albert Einstein... So
algorithms cannot be patented except mainly in USA. OpenSSL is developed in a country
where algorithms cannot be patented and where encryption technology is not reserved to
state agencies like military and secret services. During the negotiation between browser and
web server, the applications will indicate to each other a list of algorithms that can be
understood ranked by order of preference. The common preferred algorithm is then chosen.
OpenSSL can be compiled with or without certain algorithms, so that it can be used in many
countries where restrictions apply.
4.1.2.5 Signing:
Signing a message, means authentifying that you have yourself assured the authenticity of
the message (most of the time it means you are the author, but not neccesarily). The message
can be a text message, or someone else's certificate. To sign a message, you create its hash,
and then encrypt the hash with your private key, you then add the encrypted hash and your
signed certificate with the message. The recipient will recreate the message hash, decrypts
the encrypted hash using your well known public key stored in your signed certificate,
check that both hash are equals and finally check the certificate.
28
The other advantage of signing your messages is that you transmit your public key and
certificate automatically to all your recipients.
There are usually 2 ways to sign, encapsulating the text message inside the signature (with
delimiters), or encoding the message altogether with the signature. This later form is a very
simple encryption form as any software can decrypt it if it can read the embedded public
key. The advantage of the first form is that the message is human readable allowing any non
complaint client to pass the message as is for the user to read, while the second form does
not even allow to read part of the message if it has been tampered with.
4.1.2.6 PassPhrase:
“A passprase is like a password except it is longer”. In the early days passwords on Unix
system were limited to 8 characters, so the term passphrase for longer passwords. Longer
is the password harder it is to guess. Nowadays Unix systems use MD5 hashes which have
no limitation in length of the password.
OpenSSL is an open source implementation of the SSL and TLS protocols. The core library
(written in the C programming language) implements the basic cryptographic functions and
provides various utility functions. Wrappers allowing the use of the OpenSSL library in a
variety of computer languages are available.
Versions are available for most Unix-like operating systems (including Solaris, Linux,
Mac OS X and the four open source BSD operating systems), OpenVMS and Microsoft
Windows. IBM provides a port for the System i (iSeries/AS400). OpenSSL is based on
SSLeay by Eric A. Young and Tim Hudson, development of which unofficially ended
around December 1998, when Tim and Eric both moved to work for RSA Security.
Algorithms :-
1. Ciphers
make
su
umask 022
make install
chown -R root:sys /usr/local/apache2
1. Create some sample web content, which will be served up via TLS/SSL:
2. Replace the default Apache configuration file (normally found in
/usr/local/apache2/conf/httpd.conf) with the new one, using the following content
(optimized with respect to security and performance).
3. Prepare the directory structure for web server's private keys, certificates and
certification revocation lists (CRLs):
31
4. Create a self-signed server certificate (it should be used only for test purposes -- your
real certificate should come from a valid CA such as Verisign):
/usr/local/apache2/bin/apachectl startssl
Apache/2.0.52 mod_ssl/2.0.52 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide us with the pass phrases.
After the server starts, we can try to connect to it by pointing the web browser to the URL of
the form: https://name.of.the.web.server.In few moments, we should see a warning message
saying that there is problem with verifying the authentication of the web server we want to
access.
The occurrence of the above warning is perfectly correct. We should receive this message
because of two reasons:
• The web browser does not know the Certificate Authority which issued the web
server's certificate (and cannot know, because we are using self-signed certificate)
• The CN (Common Name) attribute of the certificate does not match the name of the
website - at the moment it is "Test-Only Certificate", and it should be the fully
qualified domain name of the web server
there is a yellow lock at the bottom of the web browsers, which means that the SSL
connection has been successfully established. The value "128-bit" says that the symmetric
key that that is being used to encrypt the communication has the length of 128 bits, which is
strong enough (at least for the moment) to protect the traffic from unauthorized access.
If we double click the lock icon, we will see the properties of website's certificate.
32
4.4 SSL Standards
• RFC 5246: “The Transport Layer Security (TLS) Protocol Version 1.2”.
• RFC 2595: “Using TLS with IMAP, POP3 and ACAP”. Specifies an extension to the
IMAP, POP3 and ACAP services that allow the server and client to use transport-layer
security to provide private, authenticated communication over the Internet.
• RFC 2712: “Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)”.
The 40-bit ciphersuites defined in this memo appear 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”, distinguishes secured traffic from insecure traffic by
the use of a different 'server port'.
33
• RFC 3207: “SMTP Service Extension for Secure SMTP over Transport Layer
Security”. Specifies an extension to the SMTP service that allows an SMTP server
and client to use transport-layer security to provide private, authenticated
communication over the Internet.
• RFC 3268: “AES Ciphersuites for TLS”. Adds Advanced Encryption Standard (AES)
ciphersuites to the previously existing symmetric ciphers.
• RFC 3546: “Transport Layer Security (TLS) Extensions”, adds a mechanism for
negotiating protocol extensions during session initialisation and defines some
extensions. Made obsolete by RFC 4366.
• RFC 3749: “Transport Layer Security Protocol Compression Methods”, specifies the
framework for compression methods and the DEFLATE compression method.
• RFC 3943: “Transport Layer Security (TLS) Protocol Compression Using Lempel-
Ziv-Stac (LZS)”.
• RFC 4132: “Addition of Camellia Cipher Suites to Transport Layer Security (TLS)”.
• RFC 4162: “Addition of SEED Cipher Suites to Transport Layer Security (TLS)”.
• RFC 4217: “Securing FTP with TLS”.
• RFC 4279: “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)”, adds
three sets of new ciphersuites for the TLS protocol to support authentication based on
pre-shared keys.
• RFC 4347: “Datagram Transport Layer Security” specifies a TLS variant that works
over datagram protocols (such as UDP).
• RFC 4366: “Transport Layer Security (TLS) Extensions” describes both a set of
specific extensions, and a generic extension mechanism.
• RFC 4492: “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS)”.
• RFC 4507: “Transport Layer Security (TLS) Session Resumption without Server-Side
State”.
• RFC 4680: “TLS Handshake Message for Supplemental Data”.
• RFC 4681: “TLS User Mapping Extension”.
• RFC 4785: “Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for
Transport Layer Security (TLS)”.
34
CHAPTER 5
Presently, SSL/TLS become backbone of not only in E-commerce but in any secured
information exchange across Internet. Although the working advance TLS protocol provides
a better security mechnism then ssl but it still has some limitation which needs to overcome.
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.
In its current version the REBOL SSL/TLS implementation has the following limitations.
Future versions of REBOL may add support for these features.
In the next version above mentioned limitation needs to be corrected sothat secure
transmission of information can be gurrented.
37
REFERENCES
Websites:-
1. www.google.com
2. www.scribd.com
3. http://en.wikipedia.org/wiki/Ssl
4. www.openssl.org/
5. www.VeriSign.com
Books:-
38