Professional Documents
Culture Documents
Document 22
Document 22
SSL (Secure Sockets Layer) is a standard security protocol for establishing encrypted
links between a web server and a browser in an online communication.
The usage of SSL technology ensures that all data transmitted between the web server
and browser remains encrypted.
An SSL certificate is necessary to create SSL connection. You would need to give all
details about the identity of your website and your company as and when you choose to
activate SSL on your web server. Following this, two cryptographic keys are created - a
Private Key and a Public Key.
The next step is the submission of the CSR (Certificate Signing Request), which
is a data file that contains your details as well as your Public Key. The CA
(Certification Authority) would then validate your details. Following successful
authentication of all details, you will be issued SSL certificate. The newly -
issued SSL would be matched to your Private Key. From this point onwards, an
encrypted link is established by your web server betwee n your website and the
customer's web browser.
SSL or TLS (Transport Layer Security) certificates are data files that bind a
cryptographic key to the details of an organization. When SSL/TLS certificate is
installed on a web server, it enables a secure connection between the web
server and the browser that connects to it. The website's URL is prefixed with
"https" instead of "http" and a padlock is shown on the address bar. If the
website uses an extended validation (EV) certificate, then the browser may also
show a green address bar.
What is SSL used for?
The internet has spawned new global business opportunities for enterprises
conducting online commerce. However, that growth has also attracted
fraudsters and cyber criminals who are ready to exploit any opportunity to st eal
consumer bank account numbers and card details. Any moderately skilled
hacker can easily intercept and read the traffic unless the connection between a
client (e.g. internet browser) and a web server is encrypted.
How Does SSL Work?
The following graphic explains how SSL Certificate works on a website. The
process of how an 'SSL handshake' takes place is explained below:
An end-user asks their browser to make a secure connection to a website
(e.g.https://www.example.com)
The browser obtains the IP address of the site from a DNS server then requests a secure
connection to the website.
To initiate this secure connection, the browser requests that the server identifies itself by sending
a copy of its SSL certificate to the browser.
That it confirms to required security standards on key lengths and other items.
That the domain listed on the certificate matches the domain that was requested by the user.
When the browser confirms that the website can be trusted, it creates a symmetric session key
which it encrypts with the public key in the website's certificate. The session key is then sent to the
web server.
The web server uses its private key to decrypt the symmetric session key.
The server sends back an acknowledgement that is encrypted with the session key.
From now on, all data transmitted between the server and the browser is encrypted and secure.
Single domain certificates allow you to secure one fully qualified domain name (FQDN).
Wildcard certificates secure a single domain and unlimited subdomains of that domain. For
example, a wildcard certificate for '*.domain.com' could also be used to secure
'payments.domain.com', 'login.domain.com', 'anything-else.domain.com'
Multi-domain certificates allow website owners to secure multiple, distinct domains on a one
certificate. For example, a single MDC can be used to secure domain-1.com, domain-2.com,
domain-3.co.uk, domain-4.net and so on.
Extended Validation certificates provide the highest levels of security, trust and customer
conversion for online businesses. Because of this, EV certificates contain a unique differentiator
designed to clearly communicate the trustworthiness of the website to its visitors. Whenever
somebody visits a website that uses an EV SSL, the address bar will turn green in major browsers
such as Internet Explorer, Firefox and Chrome.
SSL Certificates will contain details of whom the certificate has been issued to.
This includes the domain name or common name, serial number; the details of
the issuer; the period of validity - issue date and expiry date; SHA Fingerprints;
subject public key algorithm, subject's public key; certificate signature
algorithm, certificate signature value. Other important details such as the type
of certificate, SSL/TLS version, Perfect Forward Secrecy status, and cipher
suite details are included. Organization validated and extended validation
certificates also contain verified identity information about the o wner of the
website, including organization name, address, city, state and country.
How can I tell when a site uses SSL?
"https://" instead of "http://" before the website's address in the browser's address bar
A padlock icon in the address bar of the browser before the address.
With an Extended Validation Certificate, the address bar also shows the registered name of the
company that owns the website, the name of the issuing CA and, an additional green security
indicator.
Implementation flaws have always been a big problem with any encryption
technology, and TLS is no exception. The infamous Heartbleed bug was the
result of a surprisingly small bug in a piece of logic that relates
to OpenSSL's implementation of the TLS heartbeatmechanism, which is
designed to keep connections alive even when no data is being transmitted.
Although TLS is not vulnerable to the POODLE attack, because it specifies
that all padding bytes must have the same value and be verified, a variant of
the attack has exploited certain implementations of the TLS protocol that don't
correctly validate encryption padding.
The IETF officially took over the SSL protocol to standardize it with an open
process and released version 3.1 of SSL in 1999 as TLS 1.0. The protocol
was renamed TLS to avoid legal issues with Netscape, which developed the
SSL protocol as a key feature part of its original Web browser.
TLS 1.2 is the current version of the protocol, and as of this writing, the
Transport Layer Security Working Group of the IETF is working on TLS 1.3 to
address the vulnerabilities that have been exposed over the past few years,
reduce the chance of implementation errors and remove features no longer
needed. TLS 1.3 is still a draft and has not been finalized yet, but having an
updated protocol that's faster, more secure and easier to implement is
essential to ensure the privacy and security of information exchange and
maintain trust in the Internet as a whole.
Hypertext Transport Protocol Secure
(HTTPS)
Definition - What does Hypertext Transport Protocol Secure (HTTPS) mean?
Hypertext Transfer Protocol Secure (HTTPS) is a variant of the standard web transfer
protocol (HTTP) that adds a layer of security on the data in transit through a secure
socket layer (SSL) or transport layer security (TLS) protocol connection.
HTTPS enables encrypted communication and secure connection between a remote
user and the primary web server.
Mutual Authentication
An important application area is that of mutual
authentication protocols. Such protocols enablecommunicating parties to satisfy th
emselves mutually about each
other’s identity and to exchange sessionkeys. This topic was examined in Chapter 14.
There, the focus was key distribution. We return to this topic here to consider the
wider implications of authentication.
Central to the problem of authenticated key exchange are two issues: confiden-
tiality and timeliness. To prevent masquerade and to prevent
compromise of session keys, essential identification and session-
key informationmust be communicated in encrypted form. This requires the prior
existence of secret or public keys that
can beused for this purpose. The second issue, timeliness, is important because of the th
reat of
message replays. Suchreplays, at worst, could allow an opponent to compromise a ses-
sion key or successfully impersonate anotherparty.At minimum, a successful replay can
disrupt operations by presenting parties with messages that appeargenuine but are not.
[GONG93] lists the following examples of replay attacks:
• Simple replay: The opponent simply copies a message and replays it later.
• Repetition that can be logged: An opponent can replay a timestamped message
within the valid timewindow.
• Repetition that cannot be detected: This situation could arise because the
original message could have been suppressed and thus did not arrive
at its destination; only the replay message arrives.
• Backward replay without modification: This is a replay back to the message
sender. This attack ispossible if symmetric encryption is used and the sender cannot
easily recognize the difference between messages sent and messages
received on the basis of content.
One approach to coping with replay attacks is to attach a sequence number to
each message used in anauthentication exchange. A new message is accepted only if
its sequence number is in the proper order. Thedifficulty with this approach is that
it requires each party to keep track of the last sequence number for eachclaimant it
has dealt with. Because of this overhead, sequence numbers are generally not used
forauthentication and key exchange. Instead, one of
the following two general approaches is used:
• Timestamps: Party A accepts a message as fresh only if the message
contains a timestamp that, inA’s judgment, is close enough to A’s knowledge of
current time. This approach requires that clocks among the various participants be
synchronized.
• Challenge/response: Party A, expecting a fresh message from B, first sends B a
nonce (challenge) andrequires that the subsequent
message (response) received from B contain the correct nonce value.
It can be argued (e.g., [LAM92a]) that the timestamp approach should not be used
for connection-oriented applications because of the inherent difficulties with this
technique. First, some sort of protocol is needed to maintain synchronization
among the various processor clocks. This protocol must be both fault tolerant, to
cope with network errors, and secure, to cope with hostile attacks. Second, the oppor-
tunity for a successfulattack will arise if there is a temporary loss of synchronization
resulting from a fault in the clock mechanism ofone of the parties. Finally, because of
the variable and unpredictable nature of network delays, distributed clocks cannot
be expected to maintain precise synchronization. Therefore, any timestamp-based
proceduremust allow for a window of time sufficiently large to accommodate net-
work delays yet sufficiently small tominimize the opportunity for attack.
On the other hand, the challenge-response approach is unsuitable for a con-
nectionless type of application, because it requires the overhead of a handshake
before any connectionless transmission, effectively negatingthe chief characteristic
of a connectionless transaction. For such applications, reliance on some
sort ofsecure time server and a consistent attempt by each party to keep its clocks i
n syn- chronization may be thebest approach (e.g., [LAM92b]).
One-Way Authentication
One application for which encryption is growing in popularity is electronic mail (e-
mail). The very nature of electronic mail, and its chief benefit, is that it is not
necessary for the sender and receiver to be online at the same time. Instead, the e-
mail message is forwarded to the receiver’s electronic mailbox, where it is buffered
until the receiver is available to read it.
The “envelope” or header of the e-mail message must be in the clear, so that the
message can be handled by the store-and-forward e-mail protocol, such as the
Simple Mail Transfer Protocol (SMTP) or X.400.However, it is often desirable that
the mail-handling protocol not require access to the plaintext form of themessage,
because that would require trusting the mail-handling mechanism. Accordingly, the
e-mail message should be encrypted such that the mail-handling system is not in
possession of the decryption key.
A second requirement is that of authentication. Typically, the recipient wants
some assurance that themessage is from the alleged sender.